Claude Codeで要件定義を進める — ヒアリングから要件定義書ドラフトまでの実践ワークフロー

チャットAIの壁打ちと何が違うのか

「作りたいシステムについてChatGPTに相談する」は、すでに多くの方が試している方法です。ただ、要件定義の実務で使い続けると3つの壁に当たります。現行業務の資料を毎回貼り付ける手間、会話が流れてしまい成果物がファイルとして残らないこと、そして要件定義は数日〜数週間かかる工程なのに1回の会話で完結しないことです。

Claude Codeは、チャット画面ではなくフォルダの中で作業するAIです。業務マニュアル・帳票・ヒアリングメモを置いたフォルダの中で作業させれば、実際の業務資料を参照しながら要件を組み立てられます。整理した結果は毎回ファイルとして保存されるので、翌日は続きから再開でき、関係者への共有もそのまま行えます。要件定義のような材料が多く、期間が長い文書作成ほど、この差が効いてきます。

要件定義のどこで使えるか — 3つの場面

• 壁打ち（構想の言語化） — 「こういう業務を楽にしたい」という漠然とした構想を、質問を返させながら目的・対象業務・期待効果に分解していく
• 文書化（ドラフト作成） — ヒアリングメモや現状資料から、要件定義書の型に沿ったドラフトを組み立てる。ゼロから書く負担がなくなる
• レビュー（抜け漏れ検出） — 書き上げた要件定義書を別の視点で点検させ、曖昧な要求・矛盾・考慮漏れを洗い出す

先に集める材料 — きれいでなくていい

最初にやることは、要件を書くことではなく材料をフォルダに集めることです。整理されていなくても構いません。散らかった材料の構造化こそAIの得意分野です。

• 現行業務がわかる資料 — 業務マニュアル・業務フロー図・実際に使っている帳票やExcel・画面のスクリーンショット
• 困りごとのメモ — 現場ヒアリングの走り書き、チャットでの愚痴、過去の会議の議事録など、生の声がわかるもの
• 既存システムの情報 — いま使っているツールの名前・画面・出力ファイル。連携や移行の検討材料になる
• イメージに近い参考例 — 「こういう感じにしたい」が伝わる他社サービスや社内の別システムのメモ

実践ワークフロー — 5ステップ

1. 1材料をフォルダに置く — 上で集めた資料を要件定義用フォルダに入れる。清書は不要
2. 2現状と課題を構造化させる — 業務フローの整理と、困りごとの分類・原因の整理をさせ、人が読んで直す
3. 3要求を一覧化して優先度を付ける — 「必須（must）」と「あれば嬉しい（want）」に分けた要求一覧を作らせ、優先順位は人が決める
4. 4構成を合意してからドラフトを書かせる — いきなり全文を書かせず、目次と各章の要旨を先に出させて方向を固める
5. 5人がレビューして関係者に確認する — 内容の最終判断と社内・開発側との合意は人の仕事。AIの出力を無確認で確定させない

materials/ に現行業務の資料とヒアリングメモを入れました。

1. 資料を読んで、受注から請求までの現状の業務フローを
   ステップごとに整理して
2. ヒアリングメモにある困りごとを「作業時間」「ミス・漏れ」
   「属人化」に分類して一覧にして
3. それぞれの困りごとを、システム化で解決できそうなもの／
   業務ルールの見直しで解決すべきものに分けて

まだ要件定義書は書かないで。現状整理を確認してから進めます。

ポイントは最後の一行です。「まだ書かないで」と工程を区切ることで、方向違いの大作が出来上がってから直すという最大のムダを防げます。これは提案書作成の自動化でも使っている、文書作成ワークフロー共通の鉄則です。

要件定義書テンプレートに入れる要素

ドラフトの品質を安定させる鍵は、指示の上手さではなく型の固定です。要件定義書のテンプレートを1枚作ってフォルダに置き、毎回それを参照させます。最低限、次の6要素が入っていれば実務で機能します。

• 背景・目的 — なぜやるのか。何がどう変われば成功なのかを数行で言い切る
• 現状業務と課題 — ステップ2で整理した業務フローと困りごと。開発側が業務を理解する土台になる
• 機能要求 — システムにやってほしいこと。must / want の区分と優先順位を付ける
• 非機能要求 — 利用人数・扱うデータ量・権限管理・セキュリティなど、機能以外の条件
• スコープ外 — 今回はやらないこと。ここを明記した要件定義書は見積もりのブレと期待値のズレが大幅に減る
• 用語集 — 社内用語・略語の定義。開発側との誤解を防ぐ

現状整理と要求一覧の内容を確認しました。
この内容で要件定義書のドラフトを作成してください。

- templates/yoken-teigi.md の型に沿って書く
- 要求一覧の must / want の区分をそのまま反映する
- 判断に迷った箇所は本文に埋め込まず、末尾に
  「確認事項リスト」としてまとめる
- requirements/2026-08_販売管理システム.md として保存して

「迷った箇所は確認事項リストへ」という指示が実務では重要です。AIがもっともらしく埋めてしまうと、決めていないことが決まったことのように文書化されるリスクがあります。迷いを表に出させれば、そのリストがそのまま次の社内確認・関係者ヒアリングのアジェンダになります。

抜け漏れレビュー — 視点を変えて点検させる

ドラフトができたら、今度は書き手ではなくレビュー担当としてClaude Codeを使います。立場を指定して読み直させると、1人で書いた要件定義書の死角が浮かび上がります。

• 開発者の視点 — 「実装する立場で読んで、曖昧で作れない要求・解釈が分かれる表現を指摘して」
• 運用の視点 — 「導入後の運用担当として読んで、例外時の業務・権限・既存データの移行で考慮が漏れている点を挙げて」
• 発注の視点 — 「開発会社に見積もりを依頼する前提で、見積もりに必要な情報が足りているか点検して」

この使い方は、自分たちで書いた既存の要件定義書や、開発会社から受け取ったドキュメントの読み解きにも応用できます。書く前・書いた後・受け取った後のどの局面でも、視点を指定したレビューは機能します。

要件定義書がそのまま「開発の指示書」になる

Claude Codeで要件定義を行う隠れた利点は、成果物がAIに読ませられるテキストファイルとして残ることです。社内の業務ツールや自動化スクリプト程度の規模なら、その要件定義書を渡してClaude Code自身に開発まで任せる選択肢があります。

その際に使うのが、ファイルを読んで実装計画を先に提示し、承認するまで編集を始めないプランモードです（2026年8月時点の公式仕様）。詳しくはClaude Codeのプランモードで解説しています。

開発を外部の会社に発注する場合でも、業務フロー・要求一覧・用語集が構造化されたテキストで揃っていること自体が資産になります。開発側もAIを使って読み解ける形になっているため、認識合わせの往復が減ります。

注意点 — AIに渡してはいけない仕事

• 要求の決定と優先順位の最終判断 — 何を作り、何を諦めるかは事業判断そのもの。AIは選択肢と論点を整理する係で、決めるのは人
• 関係者の合意形成 — 現場・上長・開発側との合意はAIが代替できない。AIの役割は、たたき台を早く出して合意形成の回数と質を上げること
• 入力してよい情報の線引き — 顧客データや機密性の高い社内情報を扱う前に、入力可否のルールを決めておく。線引きの作り方はClaude Codeの禁止事項と社内ルールの作り方にまとめています

要件定義は「業務の言語化」のトレーニングそのもの

要件定義で行う業務の棚卸しと言語化は、AI活用全体の地力になります。ここで作った業務フロー・用語集・テンプレートは、議事録作成や提案書・マニュアル作成の自動化にもそのまま使い回せます。

エンジニアではない部門がこうした業務基盤を作っていく道筋は非エンジニアがClaude Codeを業務基盤にする4ステップをご覧ください。

自社の業務に合わせた要件定義テンプレートの設計や、企画部門への展開は、Claude Code法人研修で実際の業務資料を使いながら伴走支援しています。