経緯
- 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 種類の設計書が連鎖生成」の使用感、よかったらフィードバックください。