AIに「良い設計」をさせるためのプロンプト設計パターン集

Posted at 2026-04-12

設計書をAIに任せてみたものの、「なんか薄い」「実務で使えない」「結局自分で書き直した」——そんな経験はありませんか？

AIは使い方次第で、優秀なアーキテクトのように動いてくれることもあれば、教科書のコピペを返すだけのツールになってしまうこともあります。その差を生むのは、AIの性能ではなくプロンプトの設計です。

この記事では、AIに「良い設計」をさせるためのプロンプトパターンを体系的にまとめています。明日から設計書作成・レビュー・アーキテクチャ検討に即使えるテンプレートを揃えたので、ぜひ手元に置いておいてください。

結論：AIへの指示に「設計の文脈」を乗せることがすべて

AIによる設計の質が低くて悩んでいませんか？

「AIが出した設計、なんか表面的で使えない」
「何度聞いても同じような答えしか返ってこない」
「どう聞けばいいかわからなくて、結局自分で考えてしまう」

これらの悩みは、AIに「設計者の文脈」を渡せていないことが原因だと私は思っています。

AIは「優秀だが文脈を知らない新メンバー」です。どんなシステムか、どんな制約があるか、どんな判断基準で設計するかを教えてあげれば、驚くほど実用的な設計を返してくれます。

結論として、AIに良い設計をさせるプロンプトには以下の3要素が必要です。

要素	内容	例
文脈（Context）	システムの背景・技術スタック・チーム状況	「ECサイト、Next.js + PostgreSQL、5人チーム」
制約（Constraint）	非機能要件・既存の決定事項・禁止事項	「マイクロサービス化は不可、既存DBは変更禁止」
判断軸（Criteria）	何を重視した設計にするか	「可読性 > パフォーマンス、過度な抽象化は避ける」

なぜAIは「文脈なし」だと薄い設計しか返せないのか

AIは学習データの中から「もっともらしい設計」を返します。文脈がなければ、汎用的で無難な答えを選ぶしかありません。

たとえば「ユーザー管理機能の設計をして」とだけ伝えると、AIは次のように考えます。

どんな規模のシステムかわからない → 中規模を想定
どんな技術スタックかわからない → 一般的なREST APIを想定
セキュリティ要件がわからない → 標準的な対応を想定

結果として出てくるのは、どの現場にも当てはまりそうで、どの現場にも完全にはフィットしない設計です。

逆に言えば、文脈・制約・判断軸の3つを渡すだけで、AIの設計品質は劇的に変わります。私自身この3点を意識するようになってから、AIの出力をそのままレビューに出せるケースが増えました。

AIは「賢いツール」ではなく「優秀な実行者」です。何を重視して設計するかの判断は人間が担い、その判断を実行させるのがAIの役割——この役割分担を明確にするだけで、プロンプトの書き方が変わります。

プロンプト設計パターン集

パターン1：「役割付与 × 制約明示」パターン

AIに専門家の役割を与えつつ、守るべき制約を明示するパターンです。最も基本的かつ効果的な型です。

プロンプトテンプレート：
あなたはシニアバックエンドエンジニアです。以下の前提のもと、[設計対象]の設計を提案してください。
【システム概要】（例：月間10万PVのECサイト、Next.js + Node.js + PostgreSQL）
【問題】
ここのDBスキーマは変更不可
新規ライブラリの導入は原則禁止
処理はすべて同期処理で実装すること
【判断軸】
可読性・保守性を最優先
パフォーマンスは現状維持で可
待てない抽象化は迷惑
出力形式：設計方針（箇条書き）→ 具体的な実現案（コードまたは疑似コード）→ トレードオフの説明

なぜ効くか： 役割を与えることでAIの「モード」が切り替わり、制約を渡すことで現実に即した提案が返ってきます。

パターン2：「比較検討」パターン

複数の設計案を出させて、比較表とともにトレードオフを整理させるパターンです。アーキテクチャ選定や方式設計の初期段階に特に有効です。

プロンプトテンプレート：
以下の要件に対して、実現可能な設計案を３つ提案してください。それぞれについてメリット・育成・採用すべきケースを表形式でまとめてください。
【要件】（例：非同期でメール通知機能を実装したい）
【システム】（例：Node.js + AWS、あらゆるインフラはAWS Lambda + SQS利用中）
【重視するポイント】
コスト効率
実現のシンプルさ
障害時の影響範囲を最小化
出力形式：
各案の概要（2〜3行）
比較表（設計案 / メリット / 野球 / 採用ケース）
あなたのおすすめとその理由

ポイント： 「おすすめとその理由」を最後に求めることで、AIが主体的に判断を示してくれます。自分の考えと照らし合わせるのに使えます。

パターン3：「レビュアー視点」パターン

自分が書いた設計をAIに厳しくレビューさせるパターンです。設計の穴を自分では気づきにくい角度から指摘してもらえます。

プロンプトテンプレート：
あなたはシニアエンジニアとして、以下の設計書をレビューしてください。
【レビューを見る】
セキュリティリスク
パフォーマンスのボトルネック
障害時の行動・回復方法
保守性・拡張性の問題
仕様の悩みさ・抜け漏れ
【設計書】（ここに設計内容をそのままペースト）
出力形式：
強度：高/中/低
問題点の説明
改善策
問題がない箇所についての例外は不要です。

ポイント： 「辛口で」「問題がない箇所は不要」という一文が重要です。これがないと、AIは褒めてから指摘するという遠回りな回答をしがちです。

パターン4：「段階的深掘り」パターン

最初に大枠の設計を出させ、気になる部分を掘り下げていく会話形式のパターンです。複雑な設計や、最初から細部まで決まっていない場合に有効です。

ステップ1：大枠を出させる
[機能名]のシステム設計の全体像を教えてください。詳細はまだ不要で、コンポーネントの役割と関係性だけをまとめてください。

ステップ2：気になる部分を深掘り
特に[気になる点]について、具体的な実装パターンを知りたいです。

ステップ3：エッジケースを聞く
この設計で、[異常系・エッジケース]が発生した場合の挙動を教えてください。

なぜ効くか： 一度に全部を聞くよりも、段階的に絞り込んでいく方が各ステップの出力精度が上がります。

エンジニアなら読むべき本を紹介しています。
→記事を読む

パターン5：「アンチパターン検出」パターン

設計の問題点をアンチパターンの観点から指摘させるパターンです。設計レビューの前に自己チェックとして使うと効果的です。

プロンプトテンプレート：
以下の設計に対して、代表的なアンチパターンに該当する箇所を指摘してください。
【チェックするアンチパターン】
God Object（何でも知っているクラス）
Shotgun Surgery（変更が多くのファイルに反省する）
時期尚早な最適化（早すぎる最適化）
Leaky Abstraction（抽象化が漏れている）
オーバーエンジニアリング（過剰設計）
【設計内容】（ここに設計書・コード・クラス図などをペースト）
出力形式：
該当するアンチパターン名
該当箇所の説明
リファクタリング案

パターン6：「ドメイン特化 × 前提共有」パターン

業務ドメインの知識をAIに共有したうえで設計させるパターンです。ECサイト・医療・金融などドメイン知識が設計に影響する場合に特に有効です。

プロンプトテンプレート：
以下のビジネスルールと用語をご理解いただいた上で、[設計対象]の設計を提案してください。
【ドメイン知識・ビジネスルール】
「注文」は「カート確定」→「支払い完了」→「出荷」→「配達完了」の状態遷移完了
キャンセルは「支払い完了」までのみ可能
返品は「配達完了」から7日以内のみ受け付ける
在庫は「引当」と「確保」の２段階で管理する
【設計対象】注文ステータス管理のDB設計とAPIの設計
出力形式：テーブル定義 → ステータス遷移図（Mermaid） → API一覧（表形式）

ポイント： ドメイン知識を渡すことで、AIが業務ルールを反映した設計を提案できるようになります。Mermaidなどの図も出力させると、設計書としての完成度が上がります。

パターンの選び方：シーン別早見表

シーン	おすすめパターン
新機能の設計をゼロから始める	パターン1（役割付与 × 制約明示）
アーキテクチャを複数案から選びたい	パターン2（比較検討）
自分の設計書をレビューしてもらう	パターン3（レビュアー視点）
複雑な機能の設計を段階的に進めたい	パターン4（段階的深掘り）
設計の問題点を自己チェックしたい	パターン5（アンチパターン検出）
業務ドメインが複雑なシステムの設計	パターン6（ドメイン特化）

AIに良い設計をさせるための「プロンプト共通原則」

どのパターンにも共通する、覚えておきたい原則をまとめます。

原則	悪い例	良い例
出力形式を指定する	「設計を教えて」	「表形式でメリット・デメリットを出して」
判断軸を渡す	「良い設計にして」	「可読性 > パフォーマンスで設計して」
ネガティブ条件を入れる	（指定なし）	「マイクロサービス化は考慮しない」
具体性を上げる	「ECサイトの設計」	「月間10万PV、商品数1万点のECサイト」
役割を与える	「設計して」	「シニアエンジニアとして設計して」

まとめ

AIへのプロンプトには**「文脈・制約・判断軸」の3点セット**を必ず含める
場面に応じた6つのパターン（役割付与、比較検討、レビュー、段階的深掘り、アンチパターン検出、ドメイン特化）を使い分ける
出力形式・判断軸・ネガティブ条件を明示することで設計の精度が上がる
AIは「優秀な実行者」——判断は人間が、実行はAIが担うという役割分担を意識する

プロンプト設計は、一度型を作ってしまえばあとは使い回せます。この記事のテンプレートをベースに、自分のプロジェクトに合わせてカスタマイズしてみてください。