「その観点は？」の突っ込みを防ぐ！AIを最強の設計書レビュー相手にする方法

こんにちは！『となりのインフラエンジニア』の管理人です。

設計書を書き上げたとき、みなさんはどんな気持ちになりますか？「よし、完璧だ！」と思ってレビューに臨んだのに、先輩やマネージャー、あるいは組織の上位層から「この観点、 考慮漏れてない？」と突っ込まれ、冷や汗をかいた経験は誰しもがあるはずです。

人間はどうしても、自分が書いたものに対して「こう動くはず」「この手順で問題ないはず」という思い込み（認知バイアス）を持ってしまいます。そのため、どれだけ慎重にセルフレビューをしても、自分一人では「盲点（ブラインドスポット）」に気づくことができません。

そこで今、現場のエンジニアにぜひ試してほしいのが「生成AIを壁打ち相手にした設計書レビュー」です。

AIの最大の強みは、人間のような先入観を持たない「圧倒的な網羅性」にあります。今回は、現役マネージャーの視点から、AIに自分の盲点をバシバシ突いてもらい、技術面だけでなくマネジメント面も含めて設計書のクオリティを劇的に高めるプロンプト術を解説します！

設計書レビューでAIを使う最大のメリット：人間の「盲点」の克服

設計書のレビューにおいて、AIは単なる「文章の校正ツール」ではありません。あなたの設計を全方位から検証してくれる「視野の広いシニアアーキテクト 兼 厳格なITマネージャー」になります。

なぜ自力レビューには限界があるのか？

人間が設計書を見直すとき、どうしても「自分が知っている知識」や「目の前の技術要素」に視野が狭まりがちです。特に、締切に追われているときは「早く終わらせたい」という心理が働き、潜在的なリスクや、組織的なガバナンスといった「非技術的な盲点」に目をつぶってしまうことも少なくありません。

AIがもたらす「網羅性」という価値

AIには「これくらい大丈夫だろう」という妥協も、感情もありません。膨大な知識ベースからフラットに、かつ機械的にチェックを行うため、人間が「その発想はなかった！」と驚くような異次元の視点や、マネジメント層が気にする「組織的なリスク」を投げかけてくれます。

現役マネージャーの本音を言えば、「AIである程度叩かれ、技術面もマネジメント面もブラッシュアップされた設計書」をレビューに持ってきてもらえると、非常に助かります。基本的な抜け漏れが潰れているため、より本質的なアーキテクチャの議論やプロジェクトの成功に向けた戦略に時間を割くことができるからです。

未知の観点を引き出す！プロンプト3つのアプローチ

AIから「自分では気づけなかった観点」を引き出すためには、プロンプトの指示の出し方にコツがあります。以下の3つのアプローチを意識してみてください。

アプローチ①：「あえて自分の盲点を突いて」と直球で指示する

AIに対して「この設計書の良いところを褒めて」ではなく、最初から「私が無意識に前提にしてしまっていそうなリスクは何か？」と言語化させます。この「無意識の前提」を突かせる指示が、盲点を炙り出すトリガーになります。

アプローチ②：現場から経営層まで、多角的なペルソナ（役割）を同時に与える

「システムアーキテクト」の視点だけでなく、「運用保守の担当者」といった現場の目線、さらには「コストやガバナンスに厳しい組織の上位マネジメント層」の視点を一気に出させます。立場による関心の違いを強制的にぶつけることで、レビューの網羅性が跳ね上がります。

アプローチ③：「クリティカルシンキング（批判的思考）」を強制する

あえて意地悪な質問を投げかけます。「この設計の通りにシステムを構築したとき、運用開始後に最悪のシナリオ（大障害や予算オーバー）が起きるとしたら、原因は何になると思う？」と、失敗から逆算させる手法です。

【そのままコピーOK】盲点を炙り出す設計書レビュープロンプト

実際にAI（ChatGPT、Gemini、Claudeなど）に投げ込んで使える、マネジメント観点を含めた汎用的なレビューテンプレートを用意しました。Markdown形式のままコピーして、[ ]の中身を書き換えて使ってみてください。

Markdown

# 目的
あなたが非常に視野が広く、批判的思考に優れた「超一流のシニアシステムアーキテクト」および「組織のITインフラ部門統括マネージャー（上位層）」として、以下の設計書をレビューしてください。
私自身の「思い込み」や「無意識の前提」による【考慮不足・潜在的リスク・盲点】を網羅的に洗い出すことが目的です。

# システムの概要・制約条件
- システム概要: [例: AWS上に構築するWeb3層構造の社内基幹システム]
- 主要な制約: [例: 予算が限られている、2か月後のリリースが必須、既存のオンプレミスDBと連携が必要]

# レビューしてほしい設計書（一部抜粋または要約）
---
[ここに設計書のテキストを貼り付ける]
---

# あなたへの指示
上記の設計書を読み込み、以下の6つの観点から「設計者が気づいていない可能性が高い、潜在的なリスクや考慮不足のポイント」を厳しく指摘してください。単に一般的な正論を述べるのではなく、この設計の記述から読み取れる「一歩踏み込んだ懸念点」を具体的に挙げてください。

1. 【テクノロジー】技術選定や構成、サイジングにおける死角（本当にこれで要件を満たせるか？）
2. 【運用・保守】リリース後の運用回し、監視、バックアップ、トラブルシューティング時の盲点
3. 【移行・切り戻し】現行環境からの移行手順や、万が一の際の切り戻しプランの妥当性
4. 【セキュリティ】権限管理、ネットワーク境界、データ保護における潜在的な脆弱性
5. 【人間・プロセス】運用担当者のスキルセットや、手順の複雑さによるヒューマンエラーのリスク
6. 【マネジメント・ガバナンス】コスト最適化、組織の標準化ルールへの準拠、顧客や経営層への説明責任（SLA/SLOの妥当性など）における死角

# 出力フォーマット
各指摘について、以下の形式で出力してください。
- **【指摘内容】**: どこに、どのような盲点・リスクがあるか（どの観点かも明記）
- **【なぜそれがリスクなのか】**: 発生しうる最悪のシナリオ（技術的影響、またはビジネス・組織への影響）
- **【改善のための代替案】**: 具体的にどう修正・考慮すべきかのヒント

AIの指摘から「真の気づき」を得るための壁打ちのコツ

プロンプトを投げて、AIから回答が返ってきたら、そこで終わりにしないでください。ここからが本当の「壁打ち」です。

「なぜそう思った？」と理由を深掘りする

AIが意外な指摘（例：「この構成は将来的な拡張時にベンダーロックインが発生し、マネジメント上のリスクになります」など）をしてきたら、「なぜこの構成だとそのリスクが発生するの？」「その指摘の背景にある一般的なベストプラクティスは何？」と、さらに理由を深掘りして質問してみましょう。

トレードオフの議論を戦わせる

AIの指摘がすべて正しいとは限りません。プロジェクトの予算や期間の都合上、あえてリスクを受け入れている場合もあります。 そんな時は、「確かにマネジメント観点でそのリスクはあるが、今回は予算の制約でA案にしている。その制約の中で、上位層への説明責任を果たしつつ、リスクを最小限に抑える現実的な回避策（暫定対応や運用でのカバー案）はある？」と返してみてください。より現実的で泥臭い、現場に即したアイデアを提案してくれます。

AIレビューを利用するときの注意点

非常に便利なAI壁打ちですが、以下の2点だけはエンジニアとして絶対に守る必要があります。

• 機密情報のマスキング（セキュリティの担保）
  • 顧客名、具体的なIPアドレス、本番環境の生パスワード、機密性の高いビジネスロジックなどは、必ず「XXX」などにマスキングしてからAIに投入してください。組織のセキュリティポリシーに従うことが大前提です。
• ハルシネーション（嘘）への警戒
  • AIは「それらしい観点」を提示するのは大得意ですが、特定の製品の細かい仕様や最新バージョンでの変更点などにおいて、時々嘘（ハルシネーション）をつきます。AIが指摘した仕様の成否については、必ず公式ドキュメントで裏取りを行ってください。

最終的な決定を下し、設計に責任を持つのは、AIではなく「人間（あなた）」です。

まとめ：AIは24時間いつでも付き合ってくれる、最高の先輩でありマネージャー

これまでは、設計書のクオリティを上げるためには、忙しい先輩やマネージャーの時間を無理に割いてもらい、時には厳しい突っ込みに耐えながらブラッシュアップするしかありませんでした。

しかし今では、プロンプトを工夫するだけで、24時間365日、嫌な顔一つせず、何度でも自分の設計の技術的な盲点やマネジメント上のリスクを突いてくれる「最高の相棒」を画面の向こうに召喚できます。

「完璧だ！」と思った設計書こそ、ぜひ一度AIの前に差し出してみてください。マネジメント層を「お、ここまで考えてあるのか」と唸らせるような、完成度の高い設計書に仕上がるはずです。

次回の設計書作成から、まずは1つのセクションだけでもこのプロンプトを試してみませんか？