ChatGPT と 6 ラウンドの設計レビュー — 設計書を v1 から v5 まで磨いた話

構築を始める前に、まず 設計書を作ってからコードを書く 方針を取りました。AWS サーバレスは最初の構成判断が運用コストにそのまま跳ね返るので、雑に始めると後悔します。

ただし設計書を 1 人で書くと自己満で終わりがちです。そこで ChatGPT (gpt-4o) を相互レビュアーに使い、6 ラウンドの設計レビュー を回しました。本記事はその記録です。

レビューに使ったツール

ChatGPT との往復は、自前の CLI ツール consult_chatgpt.py を使いました。会話履歴を JSON で保存できて、複数ラウンドの設計議論を引き継げます。

# 単発相談
chatgpt --prompt "AWS サーバレスポートフォリオの設計書をレビューして"

# ファイル渡し + 履歴引き継ぎ
chatgpt --file design-v1.md --conversation iigtn_design --save-to round1.md
chatgpt --prompt "1 番目の指摘を具体化して" --conversation iigtn_design --save-to round2.md

これで「設計書 v1 を渡す → R1 レビュー → 反映 → v2 → R2 レビュー → …」のループが回ります。

R1 (v1 → v2) — 運用視点の追加

v1 は「9 つの章で AWS サービスごとの採用理由を書いた仕様書」でした。技術的には正確ですが、ChatGPT の最初の指摘はこうでした:

これを受けて v2 で追加したのは:

• 運用証拠の確認方法章: CloudFront 配信確認 / CloudWatch ログ / DynamoDB / GitHub Actions ログ をどう確認するかの手順
• Runbook: よくあるトラブル 12 件の対応手順 + 障害発生時の調査順序
• コスト設計: 月額試算 + トラフィック増加時のコスト変動 + 最適化策
• 採用しなかった選択肢: Amplify / Vercel / ECS / EC2 をなぜ採用しなかったか
• ビジネス応用: クライアント案件への展開構想

R2 (v2 → v3) — 個人ストーリーと現場感

v2 は分量が増えて読み応えが出ましたが、次のレビューで違う角度から指摘されました:

そこで v3 では:

• Personal Motivation 章: なぜこの構成にしたかの個人的な背景（ただし「実体験を fabricate しない」方針で、雛形＋編集可能なプレースホルダーで対応）
• 実障害事例集 (Incident Logs): 意図的に再現する障害も含めて、Case 1〜N で記録するテンプレ
• サービス視点の品質目標: Core Web Vitals / CVR / SEO の数値目標
• Lessons & Open Questions: 失敗・反省・現在悩んでいることを書く章

R3 (v3 → v4) — 文書役割の分離と事実訂正

v3 は内容が分厚くなりすぎて、1 つのファイルで「技術ドキュメント / 営業資料 / 面接対策 / キャリア戦略」が混在する状態に。R3 で次の指摘:

• README として読むとノイズ過多
• CloudFront Invalidation は requests 単位 という記述が誤り（正しくは paths 単位）
• Lambda / API Gateway を「0 円」と書いているが、CloudWatch Logs の取込課金で実際は月数十円〜
• SES コストを固定額表記しているが、送信数で変動
• WAF 動的 ON/OFF やマルチリージョンの構想が「盛りすぎ」感を醸す

v4 では 1 つの大きなファイルを 7 ファイルに分割 しました:

R4 (v4 → v5) — 実運用データと泥臭さ

v4 はファイル分離で読みやすくなりましたが、もう一段、レビューで突っ込まれました:

• 実運用データ（p95 / Hit 率 / Lambda Duration / アラート発火履歴）が無い
• 判断の「揺らぎ」が見えない（全部合理的に決めたように見える）
• 技術的な「敗北」が書かれていない（選んだけど苦戦したもの）
• 人間的運用ミス（アラート見逃し / 翌朝対応など）が無い
• 「OS / プラグイン脆弱性が原理的に存在しない」は断定が強すぎる（Lambda ランタイム・Node・npm 依存・OSS の脆弱性は当然存在する）

v5 では:

• 新規 metrics.md: 実運用メトリクスの計測項目と取得元、月次レポート Template
• motivation.md に「揺らぎ」章: EC2 から切替えた経緯 / Next.js は流行で選んだ / Terraform 3 回書き直し など
• lessons.md に C(人間的運用ミス) / D(技術的敗北) / E(妥協・後回し) セクション
• runbook.md に Case 7(アラート翌朝対応) / Case 8(Secret 誤公開) 追加
• interview.md の各回答に「⚠️ ただし正直に言うと…」を併記
• 「セキュリティ」断定の撤回（脆弱性は存在する旨を明記）

R5 (v5 で合意)

R5 のレビューで、ChatGPT は 「合意」 と判定しました:

5 ラウンドのレビューで、設計書は 「優秀なテンプレ」から「この人だから作れた設計書」 へと変わったと言えるレベルになりました。

R6 (実装後の確認)

実装が一段落した時点で、もう 1 ラウンド、ChatGPT に「これで本当に十分か」を確認しました。これも合意。設計フェーズはここで終了し、実装フェーズに入りました。

レビューで一番効いた指摘

6 ラウンドを通じて、一番効いたフィードバックは:

つまり、「全部の判断が合理的」よりも「ここで悩んだ／妥協した／失敗した」を残すほうが、設計書としての説得力が増す。これは技術ブログの書き方にも共通する気づきでした。

このレビューを 1 人でやろうとしていたら

もし ChatGPT を使わずに 1 人で書いていたら、おそらく v2 か v3 で止まっていたと思います。「もう完成」と思った瞬間に外部から客観的に突っ込まれることで、初めて気付ける欠落がある。これは 技術ブログ・ポートフォリオを作るすべての人にお勧めできる方法 です。

次の記事

設計書ができたところで、いよいよ実装に入ります。次の記事では AWS のマルチアカウント運用 (dev / prod) と、Terraform を回す前提となる IAM の初期設定について書きます。