システム開発プロジェクトにおいて、要件定義書・仕様書の作成は最も工数がかかる工程のひとつである。ヒアリング結果を整理し、機能要件・非機能要件に分類し、画面仕様・API仕様・データ定義書を揃えるまでに、中規模案件でも数週間から数ヶ月を費やすことがある。
Claude Codeは、このドキュメント作成プロセスを根本から変える。議事録や会話メモを読み込み、構造化された仕様書を生成し、矛盾や抜け漏れを指摘する。本記事では、SIer・ITコンサルが実際に活用できる具体的なプロンプトと活用パターンを詳述する。
要件定義書作成の構造的な重さ
要件定義・仕様書作成が重労働になる理由は、技術的な難易度だけではない。以下のような複合的な要因が重なっている。
情報の散在と変換コスト。顧客ヒアリングの内容はメモ・議事録・メール・口頭確認など複数の形式で存在する。これを「要件」という形式に変換し、開発チームが実装できる粒度まで落とし込む作業に大量の時間がかかる。
曖昧性の排除。「使いやすいインターフェースにしてほしい」「柔軟に対応できるシステムを」といった要望を、具体的な機能要件に変換する作業は経験とセンスが必要だが、文書化自体は単純作業の集積でもある。
ドキュメント間の整合性維持。要件定義書・機能仕様書・画面仕様書・API仕様書・DB設計書が相互に整合していなければならない。一箇所を変更すると、連鎖的に複数ドキュメントの修正が必要になる。
レビュー対応。顧客レビューで指摘を受けるたびに、複数ドキュメントを横断した修正と、変更履歴の管理が必要になる。
Claude Codeは、これらの「書く」「整理する」「整合性を確認する」という作業を大幅に自動化できる。
ヒアリング議事録から要件定義書への変換
最も即効性が高い活用パターンは、ヒアリング議事録から要件定義書のたたき台を生成することだ。
顧客との会議後、議事録を貼り付けて次のように依頼する。
以下はシステム開発プロジェクトの初回ヒアリング議事録です。
この内容をもとに、要件定義書のたたき台を作成してください。
【議事録】
参加者:〇〇株式会社 田中様、鈴木様 / 弊社 山田、佐藤
日時:2025年7月10日 14:00-16:00
現状の課題:
・在庫管理をExcelで行っているが、複数拠点間でのリアルタイム共有ができない
・発注業務が手作業で、発注漏れや二重発注が月に数件発生している
・売上集計に毎月2〜3日かかっており、月次会議に間に合わないことがある
(以下、議事録全文)
【出力形式】
以下の構成で要件定義書を作成してください:
1. プロジェクト概要(背景・目的・スコープ)
2. 現状業務の課題整理
3. 機能要件一覧(優先度: 高・中・低)
4. 非機能要件(性能・セキュリティ・可用性・保守性)
5. 制約条件
6. 前提条件・除外事項
7. 用語定義
なお、ヒアリングで確認できていない項目があれば「要確認事項」として別記してください。
このプロンプトに対してClaude Codeは、議事録の内容を分析して機能要件・非機能要件に分類し、「在庫数量のリアルタイム更新」「発注アラート機能」「売上レポート自動生成」といった具体的な機能要件に落とし込んだ構造化文書を生成する。
さらに重要なのは「要確認事項」の抽出である。「ユーザー権限管理はどうするか」「外部システム(会計ソフト等)との連携は必要か」「モバイル対応の要否」といった、ヒアリングで聞き忘れていた確認項目を自動的にリストアップする。
機能要件定義と機能一覧表の作成
要件定義書のたたき台ができたら、各機能の詳細を詰めていく。機能一覧表の作成には次のようなプロンプトが有効だ。
以下の要件定義書から、機能一覧表を作成してください。
【要件定義書(抜粋)】
(要件定義書の内容を貼付)
【機能一覧表の形式】
機能ID | 機能名 | 機能概要 | 対象ユーザー | 優先度 | 想定工数(人日) | 備考
以下の観点で機能を分類してください:
- マスタ管理機能
- トランザクション処理機能
- 帳票・レポート機能
- システム管理機能
- 外部連携機能
また、各機能について実装上の注意点や技術的考慮事項があれば備考欄に記載してください。
この機能一覧表は、後続の見積もり作業や開発計画立案の基礎資料となる。Claude Codeは要件から機能を過不足なく抽出するのが得意であり、ベテランSEが確認しても「そこまで気が付いたか」と感心するような抜け漏れの指摘をすることがある。
画面仕様書の作成
機能要件が固まったら、画面仕様書の作成に入る。Claude Codeを使えば、機能概要から画面項目・処理フロー・エラー処理まで一気に展開できる。
在庫管理システムの「発注画面」の画面仕様書を作成してください。
【前提情報】
- 発注担当者が発注先・商品・数量・納期を入力して発注データを登録する
- 発注上限金額のチェックが必要(担当者権限:50万円、係長権限:200万円、部長権限:制限なし)
- 発注後は発注先にFAXまたはメールで発注書を自動送信する
- 既存の基幹システムに発注データを連携する
【仕様書の形式】
- 画面概要
- 画面遷移(前画面・次画面)
- 画面項目一覧
- 項目名 / 種別 / 必須 / 入力規則 / 説明
- ボタン一覧
- ボタン名 / 活性条件 / 処理内容
- バリデーション一覧
- エラーメッセージ一覧
- 処理フロー(ステップ形式)
- 特記事項
Claude Codeは、こうした指示に対して「発注先コードの入力補完(サジェスト機能)の要否」「在庫数量との突合チェック」「承認ワークフローの設計」といった、指示には明示されていない設計上の検討点も「特記事項」として提示してくれる。
## API仕様書の作成
フロントエンドとバックエンドが分離したシステムでは、API仕様書が重要な設計ドキュメントになる。Claude Codeは機能要件からOpenAPI形式のAPI仕様書のたたき台を生成できる。
在庫管理システムのAPI仕様書を作成してください。 以下の機能についてRESTful APIの仕様を定義してください。
【対象機能】
- 商品マスタのCRUD
- 在庫照会・在庫更新
- 発注データの登録・照会
【出力形式】 各APIについて以下を定義してください:
- エンドポイント(URL・HTTPメソッド)
- リクエストパラメータ(ヘッダー・パスパラメータ・クエリパラメータ・リクエストボディ)
- レスポンス(成功時・エラー時)
- 認証・認可
- 呼び出し例(curl)
【前提条件】
- 認証はJWT認証を使用
- レスポンス形式はJSON
- エラーレスポンスは統一形式(code, message, details)
出力されたAPI仕様書は、フロントエンドエンジニアとバックエンドエンジニア双方が参照する設計資料として即座に活用できる。OpenAPI仕様のYAMLとして出力するよう指示すれば、Swagger UIでの表示にも対応できる。
## データ定義書・ER図の作成
システムの根幹を成すデータ設計ドキュメントも、Claude Codeで効率化できる。
以下の業務要件から、データベース設計のたたき台を作成してください。
【業務要件】
- 商品マスタ:商品コード、商品名、メーカー、単価、在庫数量、発注点、保管場所を管理
- 発注管理:発注先、発注商品、発注数量、発注日、納期、受領確認を管理
- 入出庫管理:入庫・出庫の日時、数量、担当者、関連発注を管理
【出力内容】
- テーブル定義書
- テーブル名 / 論理名 / カラム名 / データ型 / NOT NULL / デフォルト / コメント
- インデックス設計
- テーブル間のリレーション説明
- Mermaid形式のER図
- 設計上の考慮事項(パーティション・アーカイブ等)
なお、論理削除・作成日時・更新日時・バージョン管理カラムは全テーブルに追加してください。
Mermaid形式のER図を出力させれば、GitHubやNotionで視覚的に確認できる。テーブル定義書はExcelに貼り付け可能な形式で出力させると、既存の設計書フォーマットに合わせやすい。
## 非機能要件定義書の作成
非機能要件は抽象的になりがちで、後から「言った・言わない」のトラブルになりやすい箇所だ。Claude Codeを使えば、業界標準に照らした非機能要件のたたき台を素早く作成できる。
Webシステムの非機能要件定義書を作成してください。
【システム概要】
- 在庫管理・発注管理システム
- 利用ユーザー:社内150名(同時接続最大50名程度)
- データ量:商品マスタ1万件、発注データ年間5万件
- 重要度:基幹業務系(ダウンすると業務が止まる)
【定義する非機能要件の項目】
- 性能要件(レスポンス時間・スループット・処理件数)
- 可用性要件(稼働時間・RTO・RPO)
- セキュリティ要件(認証・認可・通信暗号化・ログ管理)
- 保守性要件(ログ出力・監視・アラート・バージョン管理)
- 移行要件(既存データ移行・並行稼働期間)
- 操作性要件(ブラウザ対応・レスポンシブ)
- 法令・規制対応(個人情報保護・データ保持期間)
各要件は測定可能な指標(数値・率・時間)で定義してください。
「測定可能な指標で定義してください」という指示が重要だ。これにより「高速に動作すること」ではなく「通常処理は3秒以内、帳票出力は30秒以内」という形で、開発完了時に検証可能な要件が得られる。
## テスト仕様書・受入条件の作成
要件定義書が完成したら、それに対応するテスト仕様書・受入条件をClaude Codeで作成できる。
以下の機能要件に対するテスト仕様書を作成してください。
【機能要件】 発注登録機能:
- ユーザーは発注先・商品・数量・希望納期を入力して発注を登録できる
- 発注金額が担当者権限(50万円)を超える場合は上長承認が必要
- 登録後、発注先にメールまたはFAXで発注書を送信する
【テスト仕様書の形式】 テストケースID | テスト項目 | 前提条件 | 入力値 | 操作手順 | 期待結果 | 確認方法
以下のテスト観点を網羅してください:
- 正常系(基本フロー・代替フロー)
- 異常系(入力値不正・権限エラー・外部連携エラー)
- 境界値(金額上限・文字数上限等)
- セキュリティ(不正アクセス・SQLインジェクション等)
このテスト仕様書は、QAエンジニアへの引き継ぎ資料としても、顧客との受入テスト計画書としても活用できる。
## 変更管理・トレーサビリティの維持
プロジェクトが進むにつれ、仕様変更が発生する。変更箇所を複数ドキュメントに反映し、変更履歴を管理する作業もClaude Codeで効率化できる。
以下の仕様変更依頼を受けました。 影響するドキュメントと修正箇所を特定し、修正案を作成してください。
【変更依頼】 「発注画面で複数商品を一括登録できるようにしてほしい」 (現状:1発注1商品 → 変更後:1発注で最大20商品を一括登録)
【関連ドキュメント】 (要件定義書・画面仕様書・API仕様書・DB設計書の該当箇所を貼付)
【出力内容】
- 変更影響範囲の分析
- 各ドキュメントの修正箇所と修正案
- 変更による追加工数の概算
- 変更履歴エントリ(日付・変更番号・変更概要・変更者欄)
変更影響範囲の分析は、経験の浅いSEが見落としやすい箇所だ。Claude Codeは「発注明細テーブルの新規追加が必要」「発注合計金額の計算ロジック変更」「メール送信処理での商品リスト生成」といった連鎖的な影響を体系的に指摘する。
## レビュー指摘対応と品質向上
作成した仕様書を顧客・チームメンバーにレビューしてもらった後の修正対応も、Claude Codeで効率化できる。
要件定義書のレビューで以下の指摘を受けました。 指摘内容を踏まえて、該当箇所を修正してください。
【レビュー指摘】
- 「権限管理の要件が曖昧。どのデータにどのロールがアクセスできるか明記すること」
- 「エラー発生時の業務継続手順が記載されていない。障害対応フローを追加すること」
- 「データ保持期間の根拠が不明。法令要件との関係を明記すること」
【現在の要件定義書(該当箇所)】 (文書の該当部分を貼付)
指摘を反映した修正案を作成し、修正前・修正後の対比形式で示してください。
こうした「指摘→修正」のサイクルをClaude Codeが支援することで、レビュー対応の工数を大幅に削減できる。
## claudecode道場
claudecode道場では、ITコンサルタント・SIerのSE・PMを対象に、要件定義から設計ドキュメント作成まで一連の業務をAIで効率化するカリキュラムを提供している。
実際の仕様書テンプレートに即したプロンプト演習、複数ドキュメント間の整合性チェック、顧客レビューを想定したQA対応演習など、現場で即使えるスキルを体系的に習得できる。
提案書作成の効率化(claude-code-sier-teiansh.md)と組み合わせることで、プロジェクト初期工程の全体的な工数削減が実現できる。
## まとめ
Claude Codeは、SIer・ITコンサルの設計ドキュメント作成業務を根本から変える。
ヒアリング議事録から要件定義書へのたたき台作成、機能一覧表・画面仕様書・API仕様書・データ定義書の各ドキュメント作成、非機能要件の定量的定義、仕様変更の影響分析、レビュー指摘対応——これらすべてにClaude Codeが活用できる。
設計ドキュメント作成の工数を削減することで、顧客との要件擦り合わせや設計品質向上に時間を集中できる。ドキュメントの品質と量を同時に高めながら、プロジェクト全体の生産性を底上げする——それがClaude Codeがもたらす変化である。
- claudecode道場の詳細はこちら: [claudedojo.com](https://claudedojo.com)
- AI活用支援の個別相談: [malna.co.jp/service-ai-agent/](https://malna.co.jp/service-ai-agent/)
---
*本記事で紹介したClaude Codeの活用例は、実際の業務プロセスを参考にした例示である。顧客情報・機密情報を含む実際の仕様書をAIに入力する際は、自社および顧客との契約・情報セキュリティポリシーに従って適切に取り扱うこと。*


