はじめに
「この Confluence のスペース、全部 PDF にしておいたから、読んで基本設計書にまとめて」
渡されたファイルを開くと、合計 1,400 ページ超。プロジェクト管理、要件定義、詳細設計、カオスエンジニアリング試験手順――あらゆる情報がひとつのPDFに詰め込まれています。加えて、要件定義書、比較検討スライド、見積スプレッドシートも手元にある。これらを横断的に読み合わせて「整合性のある基本設計書」に仕上げる。気が遠くなる作業です。
本記事では、このような状況で LLM を使い、散らばった合意事項・既存設計・要件を統合して基本設計ドキュメントを生成した手法を紹介します。「AIでゼロから書く」話ではありません。すでにある情報を、整合性を保ったまま1つの文書にまとめ上げる話です。
背景 ─ 手元にあったもの
対象は、GCP上の既存Webアプリケーションに対して、Azure上にディザスタリカバリ環境を構築するプロジェクトです。基本設計の着手時点で、入力資料は以下のような状態でした。
| 資料 | 内容 | 問題 |
|---|---|---|
| ナレッジベースPDF（1,400p超） | Confluenceの全ページをPDFエクスポートしたもの | 情報が多すぎる。設計に必要な部分がどこかわからない |
| 要件定義書（PDF） | スコープ定義、ユースケース、対象外事項 | ページ数が多く、全体像を俯瞰しにくい |
| 対策案スライド（PPTX） | 複数のアーキテクチャ案を比較し、方針を合意済み | 他の資料との紐付けがない |
| 工数見積（XLSX） | 工程別の人日見積 | 設計項目との対応が不明瞭 |
人力でやると、まず全資料を読み通すだけで数日。そこから抜き出し、突き合わせ、再構成。ここに LLM を使えないか、という発想が出発点でした。
最初の失敗 ─ 「要約して」は使えない
最初に試したのは、PDFを分割してLLMに渡し、「内容を要約してください」 と指示するアプローチでした。
結果は使い物になりませんでした。LLMは律儀にページ順で均等に圧縮するため、設計方針のような重要な20ページも、週次レポートの150ページも同じ粒度で扱われてしまいます。週次報告の「今週はXXXを調査しました」が設計書の要件と同じ重みで出てくる。必要な情報の密度が薄まって、結局人間が全部読み直す羽目になりました。
ここで方針を切り替えます。内容ではなく構造を先に抽出する。これがブレイクスルーでした。
全体アプローチ ─ 3ステップのドキュメントパイプライン
試行錯誤の末にたどり着いたのは、以下の3ステップです。
Step 1: 構造抽出（巨大PDFから「何がどこにあるか」のインデックスを作る）
↓
Step 2: 優先順位付け（設計に必要な情報の選別 ＋ 不足の検出）
↓
Step 3: 統合再構成（章立てを先に確定し、複数資料を1つのドキュメントに統合）
重要なのは、1つのプロンプトで一気に設計書を出そうとしないこと。各ステップの中間成果物をファイルとして保存し、次のステップの入力にします。途中で問題が見つかれば、そのステップだけやり直せます。
Step 1: 構造抽出 ─ 地図を作る
「要約」ではなく「構造」を求める
悪い例：「このPDFの内容を要約してください」
良い例：「このPDFのセクション構造（見出し階層、各セクションの主題、ページ範囲）を
抽出してください。内容の要約は不要です。」
この指示の違いは劇的です。「構造を抽出して」と言えば、LLMは見出しの階層構造、各セクションがカバーするトピック、おおよそのページ範囲を返してくれます。「内容の要約は不要」と明示するのもポイントで、これがないとLLMは親切心で要約を始めてしまいます。
実装手順
1. PDFの先頭部分（目次に相当するページ）をまず読み込む
2. 目次から大分類・中分類の構造を把握する
3. 各セクションのページ範囲を特定する
4. セクション単位で読み込み、「何が書かれているか」をインデックスに追記する
1,400ページすべてを読む必要はありません。目次の構造が把握できれば、設計に関係しそうなセクションだけを選んで深掘りできます。結果として得られるのは、こんな構造マップです。
| 領域 | 内容の概要 | 充実度 |
|---|---|---|
| アーキテクチャ設計 | 設計方針、構成図、サービス一覧 | ◎ |
| ネットワーク設計 | VPC、DNS、CDN、LB、Firewall | ◎ |
| セキュリティ設計 | IAM、SCC、Secret Manager、Cloud Armor | ◎ |
| 耐障害性試験 | カオスエンジニアリング（ネットワーク/アプリ/IAM） | ◎ |
| 運用プロセス | 運用体制、障害対応フロー、変更管理 | △ |
| DR設計（Azure側） | 今回構築する環境の情報 | ✕（未掲載） |
この構造マップの作成にかかった時間は約30分です。1,400ページを斜め読みするよりはるかに速く、しかも網羅的です。
Step 2: 優先順位付け ─ ノイズを削り、不足を炙り出す
なぜ「全部読む」が悪手なのか
1,400ページの中で基本設計に直接必要な情報は、体感で全体の2〜3割程度です。残りは週次レポート、ツールの使い方ガイド、スプリントの振り返り記録など。ノイズを含んだままLLMに渡すと、出力にもノイズが混入します。
Step 1の構造マップがあれば、「設計に必要なセクション」を人間が選別できます。ここはLLMに丸投げしない方がいいです。何が設計に必要かの判断はドメイン知識に依存するので、構造マップという「地図」を見ながら人間が取捨選択するのが確実です。
最大の収穫 ─ 不足情報の自動検出
このステップで想定外に大きな価値を生んだのが、「あるべきなのに無い」情報の検出でした。
以下の構造マップと、一般的なクラウドインフラの基本設計で必要とされる領域を比較し、
不足している可能性のある情報領域を以下の3段階で分類してください。
- 確実に不足（設計着手前に解決が必要）
- 存在するが充実度の確認が必要
- 運用観点で不足の可能性あり
返ってきた結果がこちらです。
| 不足領域 | 深刻度 | 状況 |
|---|---|---|
| DR設計（Azure側） | 確実に不足 | 既存環境のマルチリージョン設計はあるが、DR先の構成は未掲載 |
| SLA/SLO定義 | 確実に不足 | RTO 2時間の記載はあるが、RPOや可用性目標が未明文化 |
| 運用体制・エスカレーション | 要確認 | 耐障害性試験は充実、だが実運用の対応フローが未定義 |
| CI/CDパイプライン | 要確認 | 方針記載はあり、構成図の有無は要確認 |
これ、従来なら設計レビューで初めて指摘される内容です。それが設計書を1行も書く前に手に入る。手戻りの予防という点で、この不足検出はパイプライン全体の中で最も費用対効果が高いステップでした。
数値の矛盾を自動で見つける
構造マップと並行して、他の関連資料とのクロスリファレンスも行います。見積資料と設計項目を突き合わせたところ、面白い発見がありました。
見積資料では「両パターン合算で79.2人日」と計上されていた工数を、設計項目ベースで積み上げ直すと90.0人日になったのです。分析すると、既存見積にはインフラのアーキテクチャ設計やセキュリティ設計の個別項目が明示されておらず、丸めた数字で見積もられていたことがわかりました。
見積精度の議論は別途必要ですが、こうした矛盾の検出自体はLLMに両方の資料を渡して突き合わせるだけで自動的に行えます。
Step 3: 統合再構成 ─ 設計書を組み立てる
まず章立てを確定する。本文はその後
多くの人がやりがちなのは、LLMに「設計書を書いて」と指示することです。これだと章構成がLLM任せになり、既存のドキュメント体系と合いません。
実際に有効だったのは 2段階方式 です。
ステップ1: 章立ての確定
以下の入力資料から、基本設計書の章構成を提案してください。
入力:
- 設計対象のスコープ定義（要件定義書から）
- 設計項目一覧（検討結果から）
- 既存のドキュメント体系（命名規則、章番号体系を踏襲）
制約:
- 各章のタイトルは [番号]. [名詞句] の形式
- スコープ外と定義された事項は明示的に除外
- 既存見積の工程区分と対応が取れること
ステップ2: 各章の内容生成
確定した章構成に基づき、第N章の内容を生成してください。
入力:
- 構造マップから該当セクションの詳細情報
- 要件定義書の関連ユースケース
- 合意済みの方針（対策案スライドから）
制約:
- 設計方針と設計内容を明確に分離
- 詳細設計で確定すべき項目は「詳細設計で確定」と明記し、仮の値を書かない
- 数値は根拠を併記
入力資料に「権威の序列」をつける
複数の入力資料がある場合、内容の矛盾は必ず発生します。要件定義書ではスコープ外とされた項目が、対策案スライドには含まれている、というケースです。
事前に「どの資料を優先するか」の序列を定義しておくと、LLMの出力が安定します。
資料間で矛盾がある場合の優先順位:
1. 要件定義書（スコープ・前提条件の最終権威）
2. 合意済み対策案スライド（技術方針の合意記録）
3. 既存環境の設計書（踏襲すべき技術仕様）
4. 見積資料（コスト・工数の参考値）
さらに、各資料の「役割」もプロンプト内で明示しました。
| 入力資料 | 役割 | プロンプト内の指示 |
|---|---|---|
| 要件定義書 | スコープの権威 | 「スコープ定義を最上位の制約として扱ってください」 |
| 見積資料 | 工数・コスト制約 | 「工数記載がある場合は設計項目との対応を示してください」 |
| ナレッジベースPDF | 技術仕様の参照元 | 「既存設計を踏襲する場合は該当セクションを参照として記載してください」 |
| 対策案スライド | 方針合意の記録 | 「合意された方針は設計の前提条件として扱ってください」 |
「スコープ外」の自動抽出 ─ 手戻り防止の決定打
基本設計で最も高くつく失敗は、スコープ外の作業をうっかり含めてしまい、後工程で手戻りが発生することです。
要件定義書にはたいてい「対象外事項」のセクションがあります。これを LLM に明示的に読み込ませて、設計書の冒頭にガードレールとして配置します。
要件定義書の「対象外事項」セクションの内容を抽出し、
設計書のスコープ定義に以下の形式で含めてください。
**スコープ外:**
- [対象外事項]（根拠：要件定義書 X.X.X節）
実プロジェクトでは、「高度なセキュリティ運用（SOC監視、SIEM連携等）の実装確約」「DR環境へのアプリケーション展開」などが自動抽出されました。レビュー時に「これも含めるべきでは？」と聞かれたとき、要件定義書の節番号付きで即答できます。
整合性チェック ─ 「書かせて終わり」にしない
ここまでで設計ドキュメントのドラフトが生成されます。しかし、そのまま成果物にするのは危険です。AIの生成物を「レビュー可能な品質」に引き上げる工程が不可欠です。
やったこと
数値の突合: 設計書内のコスト概算（約16,700円/月）や工数について、入力資料の値と計算過程を検証しました。内訳（Dataflowジョブ実行コスト、クロスクラウド転送コスト、Blob Storage保管コスト）がそれぞれの根拠と一致しているかを確認します。
ユースケースとの対応: 要件定義書のユースケース（例：「バックアップからのリストア」）に対して、設計書内に対応する設計項目があるかをマッピングしました。対応がないユースケースがあれば、それは設計の漏れです。
技術標準への準拠: 社内の技術アーキテクチャ標準（暗号化方式、アクセス制御方針など）の要件と、設計書の各項目が整合しているかを機械的にチェックしました。
これらはいずれも「LLMに整合性チェック自体を実行させる」ことが可能です。ただし、最終的な判断は人間が行うべきです。特に「矛盾があるが、意図的にそうしている」ケース（コスト削減のために標準を緩和する判断など）は、LLMには判断できません。
Before/After
| 観点 | Before | After |
|---|---|---|
| 入力資料の読み込み | 数日（斜め読みでも1〜2日） | 構造マップ作成で約30分 |
| 不足情報の検出 | 設計レビューで発覚 → 手戻り | 着手前に自動検出 → 手戻りゼロ |
| スコープ外の明示 | 暗黙知として共有（漏れやすい） | 根拠付きで自動記載 |
| 資料間の矛盾検出 | レビュアーの経験頼み | クロスリファレンスで自動検出 |
| 設計ドキュメント生成 | 1〜2週間 | 中間成果物含めて1日以内 |
| 見積との整合性確認 | 手動で突合（見落とし多い） | 設計項目ベースで自動再計算 |
数字上のインパクトもさることながら、一番大きかったのは不足情報の事前検出です。「設計レビューで初めてわかる」のと「設計に着手する前にわかる」のとでは、プロジェクトへの影響がまったく違います。
プロンプト設計の勘所
この手法を自分のプロジェクトに適用するためのポイントを3つに絞ります。
1. プロンプトではなくパイプラインで考える
1つのプロンプトで完璧な出力を求めるとほぼ破綻します。入力→中間成果物→最終成果物の流れを設計し、各ステップの入出力を明確にしてください。
[入力資料群]
→ 構造マップ（Markdown）
→ 優先セクションリスト + 不足情報リスト
→ 章構成（確定済み） → 各章の本文
→ 整合性チェック結果
→ 最終ドキュメント
中間成果物をファイルに残しておけば、途中からやり直せます。「Step 2の不足情報リストが甘かった」と思えば、Step 1からやり直す必要はありません。
2. 「やらないこと」を先に書く
LLMへの制約指示で最も効果が高かったのは、禁止事項の明示です。
制約:
- 「現行環境」「次期基盤」など時期依存の表現は使わない
→ 「オンプレ環境」「GCP環境」のように不変な表現にする
- 詳細設計で確定すべき項目は「詳細設計で確定」と明記し、仮の値を入れない
- スコープ外の事項に関する設計は含めない
「やること」は曖昧になりがちですが、「やらないこと」は具体的に書けます。LLMが親切心で余計なことを書いてしまうのを防ぐには、この「ネガティブ制約」が最も効きます。
3. 資料に役割と序列を与える
複数資料を入力する場合、「どの資料が正」かの優先順位を必ず定義してください。これがないと、LLMは矛盾を検出しても「両論併記」してしまい、設計書としては使えない出力になります。
おわりに
本記事で紹介した手法の核心は、「AIでゼロから作る」のではなく「AIで散らばった情報を統合する」 というアプローチです。
基本設計は新しい知識を生み出す作業ではありません。すでに合意された事項を、整合性を保って1つの文書にまとめ上げる作業です。それはまさにLLMが得意とする領域であり、人間が最も退屈で時間を費やしている領域でもあります。
ただし、注意点もあります。構造解析の精度は元PDFの品質に依存します。スキャンPDFやレイアウトが複雑な資料では精度が落ちるため、元資料がMarkdownやHTMLで管理されているプロジェクトほど効果は高いです。また、LLMは矛盾を検出できますが「どちらが正しいか」の判断はできません。ドメイン知識は依然として人間側に必要です。
LLMのコンテキストウィンドウは年々拡大しています。いずれ1,400ページのPDFを丸ごと入力できる日が来るかもしれません。しかし、「構造を抽出してから深掘りする」「不足を検出してから書き始める」というパイプラインの考え方は、コンテキスト制限が解消されても有効であり続けるはずです。問題の本質は「情報量」ではなく、「情報の統合と整合性の担保」にあるからです。