仕様書・議事録・報告書をAIに書かせるときの前提条件の渡し方｜SE目線で解説

AIに仕様書や報告書を書かせてみたけど、なんか使えない——そう感じたことはありませんか？

「うちのシステムの事情を知らないから当然」「専門用語が多いから無理」と諦めている人も多いと思います。

でも、精度が低い原因のほとんどはAIに渡す「前提条件」が足りていないことです。AIはシステムの事情を知らないのではなく、教えてもらっていないだけです。

この記事では、仕様書・議事録・報告書の3種類のドキュメントに分けて、AIに渡すべき前提条件の構造と実際のプロンプト例をSE目線で解説します。

なぜ前提条件が重要なのか

AIに「〇〇の仕様書を書いて」と頼むと、一般的なフォーマットに一般的な内容が入った文章が出てきます。

問題は、現場のドキュメントは「一般的」ではないことです。

システムの制約・前提がある
会社・プロジェクト固有のルールがある
読む相手が決まっている（開発者向けか、経営層向けかで書き方が変わる）
過去の経緯があって、それを踏まえた内容にしなければならない

この情報をAIに渡さないと、「文章としては正しいが、現場では使えない」ドキュメントが出てきます。

前提条件の「5W1H」フレームワーク

どのドキュメントでも、以下の5W1Hを前提条件として渡すと精度が上がります。

項目	内容	例
Who（誰が読む）	読者の職種・知識レベル	非エンジニアの経営層 / 同じチームの開発者
What（何のため）	ドキュメントの目的	承認をもらうため / 引き継ぎのため
When（いつ使う）	タイミング・期限	来週の会議で使う / 半年後の保守作業で参照する
Where（どこで使う）	使用場所・媒体	社内Wiki / 紙で印刷して提出
Why（なぜ必要）	背景・経緯	システム障害の再発防止 / 新機能の追加開発
How（どう書く）	フォーマット・トーン	箇条書きで簡潔に / 図を入れる / 結論を先に

全部入れる必要はありませんが、Who・What・Howの3つは必ず入れると出力の精度が上がります。

①仕様書の前提条件の渡し方

仕様書でAIが使えない理由の多くは、「システムの制約と非機能要件が伝わっていないこと」です。

基本プロンプト構造：

以下の前提条件をもとに、機能仕様書を作成してください。

【Who：読む人】
担当開発者（バックエンドエンジニア、中級者）

【What：目的】
新機能「通知機能」の実装前の仕様確認

【システムの前提】
- 言語：Python 3.11 / フレームワーク：FastAPI
- DB：PostgreSQL 15
- 外部サービス連携：SendGrid（メール送信）
- 既存の認証機能と連携が必要（JWTトークン使用）

【非機能要件】
- レスポンスタイム：1秒以内
- 同時接続数：最大1000ユーザー

【機能概要】
（ここに実装したい機能の概要を箇条書きで記載）

【フォーマット】
- 概要・対象ユーザー・機能詳細・APIエンドポイント・エラーハンドリング・テスト観点の順で記載
- 推測で補完しない。不明な点は（要確認）と記載

実際の使用例：通知機能の仕様書

以下の前提条件をもとに、機能仕様書を作成してください。

【Who：読む人】
担当開発者（バックエンドエンジニア）

【What：目的】
ユーザー通知機能の実装仕様を確定させる

【システムの前提】
- Python 3.11 / FastAPI
- DB：PostgreSQL 15
- メール送信：SendGrid API v3
- 認証：JWTトークン（既存実装済み）

【機能概要】
- ユーザーが設定した条件（新着コメント・フォロー・システムメンテナンス）でメール通知を送る
- 通知設定はユーザーがON/OFFできる
- 管理者は全ユーザーへの一斉通知を送れる

【非機能要件】
- 通知メール送信はバックグラウンドジョブで処理（レスポンスをブロックしない）
- 1日あたりの送信上限：ユーザー1人につき50件

【フォーマット】
概要→対象ユーザー→機能詳細→APIエンドポイント（メソッド・パス・リクエスト・レスポンス）→エラーハンドリング→テスト観点
不明な点は（要確認）と記載

②議事録の前提条件の渡し方

別の記事でも解説しましたが、議事録に「プロジェクトの背景」を加えると精度が上がります。

仕様確認会議向け：

以下は開発チームの仕様確認会議の文字起こしです。
議事録を作成してください。

【プロジェクト背景】
- プロジェクト名：〇〇システム刷新プロジェクト
- フェーズ：設計フェーズ（実装は来月開始予定）
- 参加者の役割：田中（PM）、鈴木（バックエンド）、佐藤（フロントエンド）、山田（QA）

【この会議の目的】
通知機能の仕様を確定させる。未決事項があれば担当者と期限を決める。

【フォーマット】
■ 日時：
■ 参加者：
■ 議題：
■ 決定事項：
■ 技術的な前提条件・制約：
■ 保留・未決事項（担当者・期限つき）：
■ 次回アクション：

【注意点】
推測で補完しない。不明な点は（要確認）と記載

【文字起こしデータ】
（ここに貼り付ける）

③報告書の前提条件の渡し方

報告書は「読む人のレベル」によって書き方が大きく変わります。これを明示するのが最重要です。

障害報告書（経営層向け）：

以下の情報をもとに、障害報告書を作成してください。

【Who：読む人】
経営層（技術的な知識はない。ビジネスへの影響を知りたい）

【What：目的】
今回の障害の原因・影響・再発防止策を報告して承認をもらう

【障害の概要】
- 発生日時：〇月〇日 14:00〜17:30（3時間30分）
- 影響範囲：〇〇サービスの注文機能が使えなかった（影響ユーザー：約500件）
- 推定損失：〇〇万円相当の受注機会損失
- 原因：デプロイ時のコンフィグ設定ミスによるタイムアウト
- 対応内容：設定修正・サービス再起動
- 再発防止策：デプロイ前チェックリストの追加・レビュー体制の強化

【フォーマット】
概要（3行以内）→発生経緯→影響範囲→原因→対応内容→再発防止策→今後のスケジュール

【トーン】
- 技術用語は使わず、ビジネス言語で書く
- 感情的な表現は避ける
- 事実と対策を淡々と伝える

障害報告書（開発チーム向け）：

同じ障害について、開発チーム内向けの技術的な障害報告書も作成してください。

【Who：読む人】
開発エンジニア（技術的な詳細を理解できる）

【What：目的】
原因の技術的な詳細と再発防止策を共有する。次回のデプロイで同じミスを防ぐ。

【追加情報（技術詳細）】
- 原因詳細：本番環境のDB接続タイムアウト設定が30秒→デプロイ時に誤って3秒に変更された
- 検知方法：監視ツール（Datadog）のアラートで14:08に検知
- 対応手順：①Datadogアラート確認→②本番ログ確認→③設定ファイルの差分確認→④修正・デプロイ→⑤動作確認

【フォーマット】
タイムライン→根本原因分析（なぜなぜ分析）→対応手順→再発防止策（技術的な詳細つき）→今後のアクション

「推測で補完しない」を必ず入れる理由

AIに文書を書かせるとき、「推測で補完しない」「不明な点は（要確認）と書く」は必須の指示です。

特に仕様書・報告書では、AIが「それっぽい数字」「それっぽい技術仕様」を補完することがあります。読み返さずに使うと、存在しない仕様や誤った数値が入ったドキュメントが流通してしまいます。

AIが（要確認）と書いた箇所を自分で確認して埋めるのが、精度を保ちながら効率を上げる正しい使い方です。

前提条件をテンプレート化して使い回す

毎回前提条件をゼロから書くのは手間なので、プロジェクトごとのテンプレートを作って使い回します。

テンプレートに含める固定情報：

プロジェクト名・システム概要
技術スタック（言語・フレームワーク・DB・外部サービス）
チームメンバーと役割
非機能要件（パフォーマンス・セキュリティ要件）
よく使うフォーマット

NotionやConfluenceに「AIプロンプトテンプレート」ページを作って、ドキュメント種別ごとに管理しておくと、必要なときにコピーして使えます。

よくある質問

Q. 社内の技術情報をAIに渡してもセキュリティ上問題ない？

A. 渡す情報の機密度によります。システム構成・技術スタック・障害の詳細などは、会社のセキュリティポリシーで外部サービスへの送信が制限されている場合があります。ChatGPT TeamやEnterpriseプランは学習への使用を制限できます。社内規定を確認した上で、機密情報は固有名詞をダミーに置き換えてから渡す習慣をつけるのが安全です。

Q. AIが書いたドキュメントを社内に提出していい？

A. 最終確認をした上であれば問題ありません。重要なのは「AIが書いた」かどうかではなく「内容が正確かどうか」です。特に数字・固有名詞・技術仕様の正確性は必ず確認してから提出します。（要確認）が残ったまま提出しないことが最低限のルールです。

Q. Claude（このAI）は仕様書や報告書の生成が得意？

A. 得意です。特に構造化されたドキュメント（仕様書・報告書・提案書）は、前提条件を渡すと高精度な出力が得られます。ChatGPTと比較すると、長いドキュメントの整合性を保ちながら生成する精度が高い印象があります。用途に合わせてChatGPT・Gemini・Claudeを使い分けるのが現実的です。