経緯

ChatGPT に AWS 設計書を書かせると 見栄えは綺麗だが本番では使えない
原因はだいたい同じ ── プロンプトに「やってはいけないこと」が書かれていないだけ
私が設計書連鎖 SaaS DocChain を作る中で見つけた NG 回避の 8 つの工夫 を共有します

こんなことありませんか

ChatGPT に「AWS の基本設計書を書いて」と頼んだら、いい感じの Markdown が返ってきた。
そのまま顧客に提出 ──

「Security Group が 0.0.0.0/0 全開放、これダメ」
「対象外が書かれてない、後で揉める」
「性能要件が『高速に応答』、何ミリ秒？」
「バックアップ世代 1 ？取り違えたら戻れないよ」

赤ペンが 30 箇所。差し戻し。週末に手直し。あるあるです。

これ、LLM のせいじゃありません。プロンプトの設計 で防げます。私が DocChain を作る中で何百回も生成を試した結果、見えてきた 8 つの工夫を紹介します。

工夫 1：「対象外」と「未決事項」を必ず書かせる

LLM は 対象機能 は得意ですが、対象外 と 未決事項 を勝手に省略します。
これが受託炎上 Top 1 の原因です。

やりがちな NG

## 機能要件
- 会員登録
- 予約
- 決済

数ヶ月後 ──「ポイント機能、当然入ると思ってた」と言われて泥沼。

改善

プロンプトに 必須セクション を明記する:

要件定義書には以下を必ず含めること:
- §2.1 対象範囲
- §2.2 対象外（最低 3 項目、表形式で「項目」と「対象外の理由」を併記）
- §2.3 前提・制約
- §9 未決事項（最低 5 項目、TBD-001 形式で連番、「期限」「決定者」必須）

ポイントは「LLM は省略していい項目があれば必ず省略する」と疑うこと。書け、と命令しないと書きません。

工夫 2：AWS 構成図は PlantUML AWS Icons で描かせる

「AWS 構成図を描いて」とだけ言うと、LLM は テキストで構成を説明 してきます。図にならない。

改善：awslib14（公式 AWS Icons）を指定

https://www.plantuml.com/plantuml/svg/<encoded> で SVG 化できます。

罠：パス名・関数名のブレ

LLM は高確率で 存在しないパス を生成します:

LLM が出すパス	正しいパス
`<awslib14/Storage/S3>`	`<awslib14/Storage/SimpleStorageService>`
`<awslib14/Networking/...>`	`<awslib14/NetworkingContentDelivery/...>`
`<awslib14/Security/IAM>`	`<awslib14/SecurityIdentityCompliance/IdentityAndAccessManagement>`
`S3(...)`	`SimpleStorageService(...)`

DocChain では 出力後の正規化関数 で機械的に置換しています:

function canonPuml(s) {
  s = s.replace(/<awslib14\/Storage\/S3>/g, "<awslib14/Storage/SimpleStorageService>");
  s = s.replace(/\bS3\(/g, "SimpleStorageService(");
  s = s.replace(/<awslib14\/Networking\//g, "<awslib14/NetworkingContentDelivery/");
  // ...
  return s;
}

これで PlantUML サーバの 200 OK 率が ほぼ 100% になりました。

工夫 3：性能要件で曖昧表現を禁止する

LLM は「高速に応答」「快適に動作」を平気で書きます。
顧客は必ず聞きます ── 「高速って何ミリ秒？」

改善：プロンプトで明示禁止

【避ける】
- "高速" "適切に" "快適に" などの曖昧表現
- 数字なしの性能要件

【必須】
- レスポンスタイム: p95 で N 秒以内
- 同時接続数: N ユーザー
- スループット: N rps
- 可用性: SLA N% (年 N 時間以内のダウンタイム)

実際にはユーザーから「同時接続数」を聞き出すのは大変なので、**Wizard の「規模: 中規模」**みたいな入力から コード側で N=1000 を導出してプロンプトに注入するのが安定します。

工夫 4：DB 設計で「監査列」と「文字コード」を必ず書かせる

LLM に DB 物理設計を書かせると、created_at updated_at を 書き忘れます。

改善：プロンプトで強制

全テーブルに以下の監査列を必ず含める（業務カラムの後に配置）:
- created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
- created_by VARCHAR(64) NOT NULL
- updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
- updated_by VARCHAR(64) NOT NULL
- (論理削除する場合) deleted_at TIMESTAMP NULL
- (楽観ロック必要な場合) version INTEGER NOT NULL DEFAULT 0

charset: utf8mb4 / collation: utf8mb4_0900_ai_ci を必ず明記

「監査列が抜けている」「文字コードが書かれていない」は DB 物理設計レビューで指摘される定番 Top 2。これを未然に防げます。

工夫 5：API エラーレスポンスは RFC 9457 (Problem Details) を強制

エラー設計を雑に書かせると { "error": "Bad Request" } のようなアドホック構造を出します。
クライアント側が困るやつです。

改善：RFC 9457 準拠で書かせる

error_responses:
  - status: 400
    content_type: application/problem+json
    body:
      type: "https://docs.example.com/errors/validation-error"
      title: "Validation Error"
      status: 400
      detail: "field 'email' is required"
      instance: "/api/v1/users/123"

ついでにこれも一緒に強制すると業界標準準拠になります:

OAuth 2.1（PKCE 必須） ── Implicit Flow は廃止された
API バージョニング: URL Path 方式（/api/v1/...）
SLO: p95_latency_ms, availability_target を全エンドポイントに付与
Rate Limit: X-RateLimit-Limit/Remaining/Reset ヘッダ
Idempotency: Idempotency-Key ヘッダ対応エンドポイントを明示

工夫 6：トレーサビリティマトリクス (RTM) は LLM に任せない

要件 → 基本 → 詳細 → テストの対応を表にまとめた RTM は監査時の必須資料です。
ただし LLM に書かせると「カバーした」と言うが実際にはしてない、という幻覚が高確率で起きます。

改善：コード側で deterministic に作る

DocChain では LLM ではなく 正規表現抽出 で RTM を生成しています:

// 要件定義書から ID を抽出
const reqIdRe = /F-[SABE]-\d{3,}/g;
const reqIds = Array.from(new Set(requirementsMd.match(reqIdRe) || []));

// 各 ID が下流ドキュメントに存在するかチェック
for (const id of reqIds) {
  const inBasic = basicDesignMd.includes(id);
  const inDetailed = detailedDesignYaml.includes(id);
  const inTest = testSpecYaml.includes(id);
  // ...
}

幻覚を防ぐコツは 「deterministic に書ける部分は LLM に任せない」。
ID の対応関係のような事実は、コード側で機械的に検証する方が信頼できます。

工夫 7：AWS パラシは「dev/stg/prd の三環境並列」を必須にする

SI 業界の Excel パラメータシートは「1 リソース 1 行 × 環境 N 列」がデファクト。
LLM は単一環境分しか書きません。

改善：per_environment_overrides を必須化

- resource_id: ec2-web-001
  resource_type: ec2_asg
  per_environment_overrides:
    dev:
      compute: { instance_type: t4g.small }
      scaling: { desired_capacity: 1 }
    stg:
      compute: { instance_type: t4g.medium }
      scaling: { desired_capacity: 2 }
    prd:
      compute: { instance_type: m7g.large }
      scaling: { desired_capacity: 3 }

ルールも合わせて指定:

prd は基本設計書の数値と一致させる
dev/stg は prd の 30〜50% スケールダウン（コスト最適化）
multi_az は dev/stg=false、prd=true

これで「Excel に貼ってそのまま三環境分のレビューに使える」品質になります。

工夫 8：「弾かれる典型 NG」をプロンプトに直書きする ── 最大の効果

最後にして最大の Tips です。

LLM は 「やってはいけないこと」を書かれていない場合、過去の学習データの平均的な実装を出します。
そして 平均的な実装は中小 SI のレビューで弾かれます。

改善：NG リストをプロンプトに直接書く

【SI 受託レビューで弾かれる典型 NG（絶対に出力しない）】

[インフラ パラメータシート]
- Security Group の ingress に 0.0.0.0/0（ALB の 80/443 を除き全面禁止）
- IAM Role に AdministratorAccess / *:* のワイルドカード
- バックアップ世代 1（最低 7 日 + Cross-Region 3 世代以上）
- ログ保持 7 日固定 / 無期限（dev=14, stg=30, prd=90 以上）
- インスタンスタイプ t3.medium 固定（Graviton t4g/c7g/r7g を既定）

[テスト仕様書]
- ハッピーパスのみ
- 「200ms 以下」だけで方法・ツール無し
- 多言語/絵文字テスト無し（𠮷野家, 👨‍👩‍👧 ZWJ, RTL）
- 「OWASP Top 10 網羅」だけで個別 TC なし

[詳細設計書]
- バリデーション null/必須チェックのみ（ビジネスルールチェック必須）
- DB index が PK のみ（検索条件・FK・ユニークの 3 種以上）
- 30 秒超処理が同期 API（非同期化必須・202 + ジョブ ID）

NG リストを書くだけで、生成品質が 「素人レベル」から「中堅 SE レベル」 に上がります。
体感、これが一番効きました。

まとめ

#	工夫	効果
1	対象外・未決事項を必須化	受託炎上 Top 1 原因の予防
2	PlantUML AWS Icons + 出力正規化	図のレンダリング成功率ほぼ 100%
3	曖昧表現禁止＋数値強制	「高速」「快適」を撲滅
4	監査列・charset の強制	DB 物理設計の典型抜け防止
5	RFC 9457 + OAuth 2.1 強制	API 仕様の業界標準準拠
6	RTM は deterministic 生成	幻覚回避＋監査資料化
7	dev/stg/prd 並列カラム必須	Excel 横展開可能なパラシ
8	NG リストをプロンプトに直書き	「素人 → 中堅」の品質ジャンプ

これら 8 つを全部入れた状態で生成した設計書を、自前の 36 項目の検証スクリプト でチェックしたところ、gpt-4o で 36/36（100%） 通過しました。

自分でやらなくてもいい場合

「これ全部自分のプロンプトに反映するの、正直しんどい」

そう思った方へ ── 上記 8 つの工夫を全部入れた SaaS が DocChain です。

中小 SIer / フリーランス SE 向け
AWS 専業（インフラ系）+ 開発系の 2 系統
アカウント登録不要で今すぐ試せます: https://app.getdocchain.com/wizard
ベータ枠先着 100 名募集中（完全無料）

「Wizard で 1 分入力 → 4〜5 種類の設計書が連鎖生成」の使用感、よかったらフィードバックください。

関連記事

AWS パラメータシート手書きの苦行を、AI で自動化する SaaS（DocChain）を作り始めた話 ── 制作の経緯

参考