技術記事

Claude Code を初めて使って C# WebAPI を 0 から 100 まで構築した話

はじめに Claude Code を使って、C# の WebAPI をイチから構築しました。初めての利用だったので試行錯誤もありましたが、最終的には想像以上のスピードで実装が完了しました。 その過程で感じたこと、うまくいったこと、つまずいたことをまとめておきます。 前提条件 今回の開発にあたって、私自身の状況を書いておきます。 普段は Java を使っていて、C# はほぼ触ったことがない C# での WebAPI 実装経験がない（Java での WebAPI は十分に経験あり） C# にどんなライブラリがあるかも知らない もし自分でイチから実装しようとしていたら、
　まず C# の基本文法から学び、
　ASP.NET Core の仕組みを理解し、
　Entity Framework Core などのライブラリの使い方を調べ…
と、かなりの学習コストがかかっていたはずです。 今回は Claude Code にほぼすべてを任せる形で進めたため、この学習コストをほとんどスキップできました。
もちろん生成されたコードを理解する必要はありますが、ゼロから学ぶのと動くコードを読みながら学ぶのでは、効率が全く違いました。 最初につまずいたこと リミットにすぐ到達 Claude Code の扱いに慣れていなかったため、最初は抽象的な指示を出してしまうことが多かったです。 // 悪い例 「いい感じに API を作って」 「DB 周りをよしなにやって」 このような指示だと Claude Code が何度も確認や提案を繰り返すため、あっという間にリミットに達してしまい、5時間間隔のリセットまで使えない状態が何度かありました。 具体的に何をしてほしいかを明確に伝えること＝プロンプトの書き方＝が大事だと学びました。 実装の進め方 以下の流れで実装を進めました。 1. Excel の DB 定義書を読み込ませる まず Claude Code に Excel 形式の DB 定義書を読み込ませました。 Claude Code は読み込み用の Python プログラムを自分で作成し、定義書の内容を解析してくれました。ただ、完璧ではありませんでした。 背景色で「無効」を表現している箇所が読み取れない セル結合があると構造がうまく解釈されない こういった部分は人間の手で補足・調整が必要でした。Excel の読み込みはそこまでスムーズではなかったです。 2. API Blueprint で作成された API 仕様書を読み込ませる API 仕様書はチームメンバーが API Blueprint 形式で作成していました。 仕様書には API ごとに DB のどのテーブルを使うかが記載されていたので、Claude Code はこれを参照しながらスムーズに実装を進めてくれました。 3. 仕様書・定義書に基づいて実装 DB 定義書と API 仕様書の両方を読み込ませた状態で、実装を指示しました。 ○○ API を実装して。 DB 定義書の △△ テーブルを使って、API 仕様書の通りに作って。 このように具体的に指示すると、期待通りのコードを生成してくれました。 うまくいったこと CLAUDE.md の活用 事前に CLAUDE.md に C# のベーシックなコーディング規約を記載しておきました。 命名規則 ディレクトリ構成 基本的なコーディングスタイル これにより、生成されるコードが最初から規約に沿った形になり、後からの修正が少なくて済みました。 DB アクセス方式の切り替え 当初、Claude Code は古い方式で DB とのやり取りを実装していました。新しい方式に切り替えたいと指示したところ、スムーズに対応してくれました。 DB アクセスを Entity Framework Core を使った方式に変更して。 既存の実装をすべて書き換えて。 Docker 環境の構築 DB コンテナやローカル実行環境の構築も、こちらの要望を伝えるだけで Claude Code がすべて用意してくれました。 docker-compose.yml の作成 初期データ投入用のスクリプト ローカル実行用の設定ファイル リファクタリング 実装が一通り完了した後、リファクタリングも依頼しました。 実装内容を確認して、処理の共通化や最適化を行って。 指示した通りに、重複コードの共通化や不要な処理の削除を行ってくれました。 仕様変更への対応 開発中は度重なる仕様変更がありましたが、以下のような簡単なプロンプトで対応してくれました。 ○○ API の △△ の処理を □□ に修正して。 修正後は、処理分岐パターンを網羅したテストを実施して。 人間では到底追いつけないスピードで実装してくれました。 人間がやったこと Claude Code に実装を任せることで、人間は以下の作業に時間をかけることができました。 コードレビュー：生成されたコードが仕様通りか、セキュリティ上の問題がないかを確認 テスト：実際に動かして期待通りの動作をするかを検証 仕様の判断：曖昧な部分の仕様を決定し、Claude Code に伝える 実装作業そのものはほぼ Claude Code に任せ、人間は確認と判断に集中する形になりました。 感じたこと 今回初めて 0 から 100 まで Claude Code に作業してもらいました。 率直に言って、もう人間がプログラミングする機会は劇的に減っていくだろうと感じました。
近い将来、コードを書くこと自体がなくなるかもしれません。 便利でとても楽ではあるのですが、正直なところ少し寂しい気持ちもあります。
プログラミングが好きで始めた仕事なので、複雑な気持ちになりました。 ただ、だからこそ「何を作るか」「どう設計するか」「品質をどう担保するか」という上流の部分が、これまで以上に重要になってくるのだと思います。 まとめ Claude Code を使えば、WebAPI の実装を大幅に効率化できます 抽象的な指示ではなく、具体的に伝えることが大事 CLAUDE.md に規約を書いておくとスムーズ Excel の読み込みなど、完璧ではない部分もある 人間はコードレビューとテスト、仕様判断に集中できる プログラミングの在り方が変わっていくことを実感しました

横断的なテスト設計を考慮したプロジェクト設計について

はじめに この記事は、プロジェクトの立ち上がりからサービスインまでの作業や考慮すべきポイントなどを、
テスト設計を念頭においた全体的な流れとしてまとめたものです。 背景 実装として参加したプロジェクトで必要な情報が不足していると思うことが多かった さまざまな案件で必ずといっていいほど遭遇していると思いますが、何故この段階でこの整理がされていないのだろうと思うことがよくあります。 このような事がなぜ起きるのかはともかく、仕様漏れや手戻りが起きにくくなるようテスト設計を念頭に置き、
各フェーズで漏れを洗い出せる確率の高いプロジェクトの流れを整理します。 全体的な流れと各フェーズの成果物 0. 発端・課題の整理・定義 ここをしっかりしないと「作ってはみたものの誰も使わない」みたいな話になります。 目的と位置づけ 発案 (例: 社内要望 / 顧客要望 / 競合対抗 / 売上施策 / 業務改善) なぜ作るのか、何を解決するのかを明確にする(言語化) 主な作業 課題・背景整理 価値仮説立案 ※KPI(成果指標) 仮置き ※スコープ上限・下限定義 (何をどこからどこまでやるか) 成果物 企画メモ / 1枚企画書 課題仮説リスト KPI 草案 スコープ定義書 1. 企画・要件定義 (前半) 目的と位置づけ 「何を作るか」の大まかな外形とリリースにまつわる制約を整理する 主な作業 機能要件定義 非機能要件定義 ユースケース整理 対応 OS / 端末条件整理 ※(その他)法務・セキュリティ・ストア審査観点確認 成果物 要件定義書(ドラフト) ユースケース一覧 非機能要件一覧 2. 情報アーキテクチャ設計（InformationArchitecture設計） よくIAと略されます。これが曖昧なままだと、DBのテーブル定義には存在するけど、どこから入ってくる情報なのかよく分からないみたいな事態になります。
（過去の案件では画面デザインに入力UIがなく、終盤になって発覚し慌てて実装を追加しました。） 目的と位置づけ 要件を「構造」に落とし込んでいく工程 このあとの要件定義（後半）と UX / UI 設計（前半）の橋渡し 主な作業 情報・機能の洗い出し 用語・概念整理 グルーピング・階層化 ナビゲーション構造設計 情報の入出力整理(データフロー整理) 成果物 概念マップ 用語定義表 コンテンツ / 機能一覧 サイトマップ / 機能マップ ナビゲーション構造図 3. 企画・要件定義（後半） ＋ テスト観点洗い出し（前倒し） 目的と位置づけ 要件を「確認可能な仕様」として確定させる 主な作業 IA を踏まえた要件確定 正常系 / 異常系 / 境界値洗い出し 完了条件（受入基準）定義 非機能テスト観点整理 おまけ：次のMinimumViableProduct 判断条件整理 成果物 要件定義書（確定版） テスト観点一覧（高レベル） 受入基準（双方の認識合わせを行って書面化しておくほうが間違いが起きづらい） 4. MVP(Minimum Viable Product)設計・リリース戦略 ＋ 検証範囲定義 この部分については、発注側であれば最低限これだけあればリリースできるという線引になります。
(MVPにいくつか機能を追加したものを発注し時間が足りなくなった時などに、どの機能を次回リリースに回すかといった判断がしやすくなります。) 目的と位置づけ 初回リリースで成立する価値を決める 主な作業 MVP スコープ切り出し フェーズ分割（MVP / 拡張） リリース方式設計（β / 段階公開） MVP 必須テスト範囲定義 KPI 達成 / 未達時の判断基準設定 成果物 MVP 定義書 リリースロードマップ 段階公開計画 MVP テスト範囲定義 5. 体制・作業フロー設計 目的と位置づけ 開発・テストを回す仕組みを作る 主な作業 役割・責務定義 開発プロセス選定 チケット運用などタスク管理の方法の設計 レビュー・完了基準策定 成果物 体制図 プロセス定義 チケットテンプレート 6. UX/UI設計 ＋ 画面・状態テスト設計 目的と位置づけ IA を画面と操作に落とし込む 主な作業 画面遷移設計 状態遷移設計 ワイヤーフレーム作成 デザイン作成 画面単位のテスト観点定義 表示条件 入力制限 エラー表示 OS 差分整理（iOS / Android） 成果物 画面遷移図 通常遷移 エラー時の表示・遷移先など 状態遷移図 ワイヤーフレーム デザインデータ（Figma 等） 画面別テスト観点表 7. 技術設計 ＋ テスト前提設計 目的と位置づけ 保守性・テスト容易性を担保する 主な作業 アーキテクチャ設計 データ / API 設計 認証・セキュリティ設計 Mock 前提の責務分離 エラー分類・ログ設計 テストレベル設計（単体 / 結合 / UI） 成果物 技術設計書 アーキテクチャ図 API 仕様書 エラーコード定義 8. 基盤設計・構築 ＋ テスト環境整備 目的と位置づけ 安定した開発・検証環境を用意する 主な作業 環境分離（dev / stg / prod） CI / CD 構築 ※自動ビルド環境は出来ればあった方がよい 証明書・署名設定 (ものによっては無いと作業が止まります) テストアカウント / テストデータ準備 自動テスト実行基盤構築 ※自動テストを導入する場合 成果物 環境設定資料 テストアカウント一覧 CI / CD 設定 (もしくはビルド・テストリリース手順) 自動テスト実行環境 ※自動テストを導入する場合 9. 実装 ＋ 単体テスト並走 目的と位置づけ 設計通りに安全に実装する 主な作業 機能実装 UseCase / Repository 単体テスト実装 Mock を用いた異常系検証 コードレビュー 成果物 実装コード 単体テストコード レビュー記録 ※ここで単体テストが実行できる状態なら 生成AIを用いた作業もやりやすくなります。 10. テスト実行 (結合・統合) 目的と位置づけ 全体として期待通りに動くか確認する 主な作業 単体テスト実行 結合テスト（API / 認証 / 課金） UI テスト（重要導線） 端末・OS バージョン検証 非機能テスト（性能 / 安定性） 成果物 テスト結果報告書 不具合一覧 改修履歴 11. リリース前最終確認 目的と位置づけ 可能な限り安全にサービスインする事 主な作業 ストア提出情報確認 審査観点最終チェック 監視・アラート確認 障害対応手順確認 成果物 ストア提出物一式 運用・障害対応手順書 リリース判定資料 12. サービスイン（リリース） 主な作業 段階公開 初期監視 不具合即応 成果物 公開済アプリ 初期運用レポート(主にサーバ側) 13. サービスイン後 (受託においては担当外) 目的と位置づけ 期待通りの効果が出ているか測定する 継続的に価値を高める 主な作業 KPI 分析 改善施策立案 テスト観点更新 技術負債解消 成果物 分析レポート 改善バックログ 更新済テスト設計 まとめ お客さまとやり取りするしながら受託プロジェクトを進めていく場合には、実装までに必要な情報が揃っているかをチェックし、
揃っていない場合は実装開始までに必要なものが揃うよう交渉していきましょう。 必要な情報がないまま実装したとしても、結局、仕様確認や調整に無駄なコストがかかったり、後戻りする羽目になります。 基本的に、情報アーキテクチャ設計とUX/UI設計が曖昧になっていると、
実装のタイミングで仕様確認や調整に時間をかけてカバーすることになります。 あとから実装を追加したり変更すると、不要な処理になったりいびつな処理になることが多く、このような部分が負債となって積み上がっていきます。
そのような状況を避け、後戻りの少ないプロジェクトにするためにも事前にテストを想定した進め方を心がけるようにしましょう。