Claude Codeを使うと、業務システムのコードを書く作業そのものは大きく短縮できます。その分、品質を左右するのは、何を作るかを文章で決めておく要件整理と、出来上がったものが業務で使えるかを確かめる動作確認です。この記事では、見積依頼を管理する小さな社内ツールを例に、Claude Codeで業務システムを作るときの進め方を、要件整理から動作確認まで順に説明します。
Claude Codeでできることと、この記事の前提
Claude Codeは、Anthropicが提供する開発用のツールです。公式ドキュメントでは、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携する「agentic coding tool」と説明されています。ターミナル、IDEの拡張機能、デスクトップアプリ、ブラウザで使えます。
できることが多い一方で、業務の事情はコードを読んでもわかりません。どの取引先が特別扱いなのか、承認は誰がするのか、月末に何が起きるのか。これらを文章で渡せるかどうかで、出来上がるものが変わります。以下は、業務の聞き取りがある程度済んでいる前提で進めます。
例：見積依頼の管理ツール
金属加工の会社で、営業担当がメールや電話で受けた見積依頼を、共有Excelで管理しているとします。困りごとは次のとおりです。
- 誰がどの依頼を担当しているかが分からず、回答漏れが月に数件ある
- 回答期限が近い依頼に気づけない
- 図面のファイルがメールに埋もれ、探すのに時間がかかる
これを、依頼の登録・担当の割り当て・期限の一覧・ステータス管理ができる社内向けのWebツールにします。
1. 作る前に要件を文章にする
最初にやるのは、Claude Codeへの指示を書くことではなく、作るものを1つのファイルに書き出すことです。最低限、次の項目を書きます。
| 項目 | この例での内容 |
|---|---|
| 目的 | 見積依頼の回答漏れをなくす |
| 利用者 | 営業担当（登録・更新）、営業課長（割り当て・一覧確認） |
| 扱うデータ | 依頼（顧客名、品名、数量、図面、受付日、回答期限、担当、ステータス） |
| ステータス | 受付 → 担当決定 → 見積中 → 回答済 → 受注／失注 |
| やらないこと | 原価計算、見積書PDFの自動作成（次の段階で検討） |
| 異常時 | 回答期限を過ぎた依頼は一覧で赤く表示し、課長に通知する |
| 完了の条件 | 既存Excelの過去3ヶ月分を取り込み、件数が一致する |
特に「やらないこと」と「完了の条件」を書いておくと、作業が広がりすぎるのを防げます。要件の書き方は要件定義書の書き方の記事で詳しく扱っています。
まだ決め切れていない点が多いときは、公式のベストプラクティスにあるように、仕様が書けるまで質問を出させ、答えた内容をファイルに書き出させる進め方もあります。質問に答えていくうちに、自分が詰めていなかった点が見えてきます。
2. プロジェクトの決まりごとをCLAUDE.mdに書く
CLAUDE.mdは、プロジェクトに置くMarkdownファイルで、Claude Codeがセッションの開始時に毎回読み込みます。公式ドキュメントでは、コードから読み取れないことだけを短く書くよう勧めています。業務システムなら、例えば次のような内容です。
# 確認方法
- テスト: npm test
- 1ファイルだけテスト: npx vitest run path/to/file.test.ts
# 決まりごと
- 日付は日本時間で保存・表示する
- 金額は税抜で保存し、画面でだけ税込を表示する
- 顧客データを削除する機能は作らない（無効化のみ）
業務ルールのうち、毎回守ってほしいものはここに置きます。ただし公式ドキュメントにもあるとおり、ここに書いた指示はほとんどの場合守られるものの、必ずではありません。絶対に破られては困るものは、テストや自動チェックで機械的に止める仕組みにします。
3. 計画を先に出させて確認する
いきなり作らせるより、先に計画を出させて読むほうが手戻りが減ります。Claude Codeには、コードを変更せずに調べて変更案を出す「プランモード（Plan mode）」があります。CLIでは Shift+Tab でモードを切り替えられます。
計画を読むときに見るのは、コードの書き方より業務の観点です。
- ステータスの遷移が、要件に書いたものと一致しているか
- 担当が未決定の依頼が一覧から漏れていないか
- 既存Excelの取り込みで、表記ゆれ（顧客名の株式会社の有無など）をどう扱うことになっているか
ずれていれば、この段階で修正を指示します。作った後に直すより、ずっと安く済みます。
4. 小さく作って、すぐ動かす
全部の機能を一度に作らせず、「依頼の登録と一覧表示」だけを先に作り、画面で触ってみます。次に担当の割り当て、その次に期限の表示、と1つずつ足していきます。
既存データの取り込みも同じで、まず数件で試し、結果を自分の目で確認してから全件に広げます。頼むときは、次のように結果の数字と根拠を出させると確認が楽になります。
- 取り込んだ件数と、元のExcelの行数を並べて出す
- 取り込めなかった行は、行番号と理由を一覧で出す
- 顧客名を統一した場合は、元の表記と統一後の表記の対応表を出す
黙って直された結果は、後から正しいかどうか判断できません。
うまくいかない方向に進んだときは、元に戻す手段があります。公式ドキュメントによると、/rewind（または空の入力欄で Esc を2回）で、コード・会話、またはその両方を以前の時点に戻せます。ただし対象はClaude Codeが自分のファイル編集機能で変えたファイルで、シェルのコマンドで変更したファイルは戻らないとされています。git でこまめにコミットしておくのが確実です。
5. 業務の観点で動作確認する
テストが通ったことと、業務で使えることは別です。動作確認では、正常な流れに加えて、現場で実際に起きる場面を試します。
| 観点 | 確かめること |
|---|---|
| 正常系 | 登録 → 割り当て → 回答済 まで一通り操作できるか |
| 期限 | 回答期限を過ぎた依頼が赤く表示され、課長に通知が届くか |
| 同時操作 | 2人が同じ依頼を同時に更新したとき、片方の変更が消えないか |
| 権限 | 営業担当が他人の依頼を勝手に失注にできないか |
| データ | 過去3ヶ月分の件数が元のExcelと一致するか |
| 入力 | 図面の大きなファイルや、数量に「100個」のような文字が入ったときにどうなるか |
確認するときは、「確認済み」という出力の一文だけで済ませず、実行したコマンドとその出力、画面のスクリーンショットなど、根拠を出させます。公式のベストプラクティスでも、結果だけでなく証拠を求めることが勧められています。最後は、実際に使う営業担当に触ってもらい、普段の手順どおりに操作できるかを見ます。動作確認の考え方は動作確認の基本の記事にまとめています。
よくある失敗
- 要件を書かずに「見積管理ツールを作って」と頼む：一般的な見積管理の機能が並び、自社の流れに合わない
- 一度に全部作らせる：どこで間違えたのか分からなくなり、確認に時間がかかる
- 計画を読まずに進める：ステータスの定義が要件と違うまま画面が増えていく
- テストが通ったことを完成とみなす：期限切れや同時更新など、業務の場面を試していない
- 既存データの取り込み結果を数えない：件数のずれに本番で気づく
この記事のまとめ
- Claude Codeで作るときも、品質を決めるのは要件整理と動作確認
- 目的・利用者・データ・ステータス・やらないこと・完了の条件を先に文章にする
- 毎回守ってほしい決まりごとはCLAUDE.mdに短く書き、絶対に守るべきものは機械的なチェックにする
- プランモードで計画を出させ、業務の観点でずれを直してから作る
- 小さく作ってすぐ動かし、件数と根拠を出させて確認する
- 動作確認は期限・同時操作・権限・データ件数など業務の場面で行い、最後は利用者に触ってもらう
この記事の内容は、ロードマップのStep 6「進めて作る」にあたります。作るものを決める段階はStep 5「決める」で扱っています。体系立てて学ぶなら、FDEガイドの現場導入のための要件定義、動作確認入門、AIプロダクト開発カリキュラムを参照してください。演習とテストはlecture.iplot.jpで取り組めます。