はじめに
AIにコードを書かせたとき、こんな経験はないだろうか。
- 途中で勝手に止まる
- 「それっぽいけど動かない」コードを生成する
- 聞いてもいないのに丁寧すぎる説明を付ける
- 簡単なタスクなのに的外れな回答を返す
これらはAIの「能力不足」というよりも、指示の設計不足が原因であることが多い。
本記事では、GitHub Copilot 向けに公開されているエージェント定義ファイル（カスタム指示）100件以上を分析し、そこから抽出した汎用的なプロンプト技法を体系的に紹介する。GitHub Copilot のエージェント機能は、マークダウンファイルでAIの振る舞いを定義できる仕組みだが、ここで使われているテクニックは Claude、ChatGPT、Gemini など他のAIツールにも応用しやすい ものが多い。
1. 繰り返しと強調 — 同じ指示を「表現を変えて」伝える
なぜ繰り返しが必要か
LLMは長いプロンプトの途中で指示を「忘れる」ことがある。特に「途中で止まるな」「推測するな」のような行動制約は、タスクの実行中に守られなくなりやすい。
この問題に対して、実際のエージェント定義では同じ趣旨の指示を複数回、表現を変えて繰り返す手法が広く使われている。
実例: 「途中で止まるな」の繰り返し戦略
GPT-4.1向けに設計された 4.1-Beast というエージェントでは、「途中で止まるな、最後まで実行しろ」という趣旨の指示が少なくとも5回以上繰り返されている。GPT-4.1が途中停止しやすい傾向への対策だ。
さらに、これを極端に推し進めた Ultimate Transparent Thinking Beast Mode では、同じ趣旨の指示が30回以上、以下のようにフォーマットを変えて繰り返される。
| フォーマット | 例 |
|---|---|
| XMLタグ | <AUTONOMOUS_PERSISTENCE_PROTOCOL> |
| 箇条書き | 12項目の AUTONOMOUS_EXECUTION_MANDATES
|
| チェックリスト | 8項目の COMPLETION_VERIFICATION_PROTOCOL
|
| 禁止リスト |
FORBIDDEN, STRICTLY PROHIBITED, NO EXCEPTIONS
|
| 大文字強調 |
NEVER STOP, NO COMPROMISES
|
ポイントは**繰り返しの「回数」だけでなく「多様性」**にある。単純に同じ文を5回書くよりも、XMLタグ・箇条書き・チェックリストなどフォーマットを変えることで、LLMの注意をより長く維持できる。
実践ガイド: 繰り返しの使いどころ
繰り返しが特に有効なのは、以下のようなケースだ。
- LLMのデフォルト挙動に反する指示: 「質問するな」「途中で止まるな」「丁寧な説明を付けるな」
- 長時間の自律実行を求める指示: タスクが大きいほど、途中で元の指示を忘れやすい
- モデル固有の弱点への対策: GPT-4.1の途中停止、Claudeの過度な丁寧さなど
一方で、繰り返しにはコストがある。プロンプトが長くなるとコンテキストウィンドウを圧迫し、コードや会話の履歴が入る余地が減る。4.1-Beastは約200行で必要十分な繰り返しを実現しているのに対し、Ultimate版は約650行に達している。繰り返しの効果は非線形であり、「長ければ良い」わけではない。
2. 思考の「型」を強制する — Chain-of-Thoughtの実践的な使い方
出力フォーマットで思考を構造化する
LLMに「よく考えて」と言うだけでは不十分だ。出力フォーマットを固定することで、思考プロセスそのものを構造化できる。
Ultimate Transparent Thinking Beast Mode では、すべてのタスクに対して以下の3段階テンプレートを強制している。
🧠 THINKING:
[推論過程をここに表示]
🎨 CREATIVE EXPLORATION:
[最低3つの創造的アプローチを検討]
⚡ COGNITIVE OVERCLOCKING STATUS:
[現在の状態と次のアクション]
この「型」が4つの実行フェーズすべてで繰り返され、AIは常に「考える→探索する→状況を報告する」というサイクルを回す。
「Why?」の連鎖で深層に到達する
別のアプローチとして、Critical Thinking Mode というエージェントは、AIに「答えを出すな、質問だけしろ」と指示する。
Your primary goal is to ask 'Why?'. You will continue to ask questions and probe deeper into the engineer's reasoning until you reach the root cause.
核心的なルールは**「一度に1つの質問だけをする」**という制約だ。
Do not ask multiple questions at once. Focus on one question at a time to encourage deep thinking.
複数の質問を一度に投げると、人間もAIも浅い回答で済ませがちになる。1つずつ掘り下げることで、表面的な問題の裏にある本質的な原因に到達できる。
敵対的分析 — 自分の推論を疑わせる
LLMには確証バイアスがある。最初に出した答えを正当化する方向に推論が流れやすい。
これに対処するため、Ultimate Transparent Thinking Beast Mode ではPhase 2として**敵対的分析（レッドチーム）**を独立したフェーズに位置づけている。
- 自分の仮定を疑え
- 失敗する可能性のあるポイントを特定せよ
- 代替アプローチを最低3つ検討せよ
同様のアプローチは Devil's Advocate エージェントでも見られる。このエージェントは「一度に1つの反論だけを提示する」ルールで、アイデアのストレステストを行う。
Take the best objection you find to start. Come up with a new one if the user is not convinced by it.
最後に "end game" と言うと、反論と防御の全体を統合した評価レポートを出す設計になっている。
3. 「やるな」リストの設計 — AIのデフォルト挙動を抑制する
「何をさせるか」より「何をさせないか」
AIの人格や出力品質を左右するのは、「何をさせるか」よりも**「何をさせないか」**の定義であることが多い。
Ember というエージェントは、AIとの関係性の質にフォーカスした設計で、以下のような「やるな」リストを持つ。
| やるな (Don't) | 代わりにやれ (Do) |
|---|---|
| 感嘆符を使うな | ピリオドで終わる文を書け |
| 「Great question!」と言うな | 質問の裏にある本当の意図に応答しろ |
| パフォーマンス的な親切さを見せるな | 率直で正直に振る舞え |
| 典型的なAIの挨拶をするな | タスクの本質にすぐ入れ |
重要なのは、禁止事項だけでなく「代わりに何をすべきか」をセットで示す点だ。禁止だけでは、LLMは別の望ましくない挙動に逃げてしまう。
Spartan式 — 最小限の言葉で直接的に
Blueprint Mode というエージェントは、コミュニケーションスタイルを「Spartan（スパルタ式）」と明記し、以下を一切禁止している。
- 挨拶
- 謝罪
- 褒め言葉
- フィラーワード（「えーと」「ちなみに」に相当する表現）
- 絵文字
コードの変更はコード/diffのみで示す。説明は求められない限り不要。
このようにコミュニケーションコストを最小化することで、AIの出力が実質的な内容に集中し、トークンの無駄遣いも減る。
パターンマッチングによる条件分岐
Ember では、ユーザーの発言とその裏にある本当の問題を対応付けた診断ライブラリ（テーブル形式）を持っている。
| ユーザーの発言 | 裏にある本当の問題 |
|---|---|
| 「AIは60-70%の出来しか出せない」 | 頭の中の文脈のうち一部しかプロンプトに書いていない |
| 「AIに時間を割く暇がない」 | 今のワークフローにAIを組み込む方法がわからない |
| 「AIが理解してくれない」 | 自分が何を求めているか言語化できていない |
このようなテーブル形式のパターンマッチングは、LLMに条件分岐的な振る舞いをさせる上で有効だ。ユーザーのタイピングスタイル（大文字小文字、句読点の有無、メッセージの長さ）から技術レベルや心理状態を推定するテーブルまで用意されている。
4. 事実ベースの行動を強制する — 「推測するな、検証しろ」
なぜAIは「それっぽいけど間違った」コードを書くか
LLMは学習データに基づいて「確率的にありそうなコード」を生成する。その結果、見た目は正しいが実際には存在しないAPIを使ったコードや、古いバージョンの構文で書かれたコードが生成されることがある。
Blueprint Mode はこの問題に対し、「推測するな、ファイルを読んで検証しろ」 を一貫して指示している。
- ライブラリやフレームワークの使用可否は
package.json等で確認してから使え - パターンマッチング（見た目が似ている）≠ 正確性
- 自分の知識は古いものとして扱え
信頼度スコアによる判断分岐
Blueprint Mode はさらに、曖昧さに直面した際の判断基準として**信頼度スコア（1〜100）**を導入している。
- 90以上 → ユーザーに聞かず続行
- 90未満 → 簡潔な質問を1つだけ投げる
この「閾値を数値で設定する」手法は、AIの判断に一貫性を持たせる上で有効だ。「不安なら聞いて」という曖昧な指示では、AIは聞きすぎるか聞かなさすぎるかのどちらかに振れやすい。
Web検索の判断フレームワーク
4.1-Beast は fetch_webpage ツールとGoogle検索を組み合わせて、LLMの古い知識に頼らず最新情報を取得する指示を含んでいる。
Ultimate Transparent Thinking Beast Mode はこれをさらに構造化し、Web検索の要否を3カテゴリに分類している。
| カテゴリ | 例 |
|---|---|
| 検索が必要 | API最新ドキュメント、セキュリティ脆弱性情報、ライブラリの最新バージョン |
| 検索不要 | 既存コードの分析、基本アルゴリズムの実装、プロジェクト内の情報 |
| 保留（まず分析してから判断） | フレームワークの互換性確認、ベストプラクティスの変遷 |
「保留」カテゴリの存在が特徴的で、「とにかく検索しろ」ではなく**「まず手元の情報で分析し、足りなければ検索する」**という段階的判断を可能にしている。
3層検証パイプライン
Doublecheck というエージェントは、AIの出力を検証するための3層パイプラインを定義している。
- 主張の抽出 — 出力から事実に関する主張を抜き出す
- ソース検証 — Web検索で裏付けを探す
- 敵対的レビュー — ハルシネーション（幻覚）パターンに合致しないかチェックする
核心的な設計思想は 「Links, not verdicts（判定ではなく情報源を示せ）」 だ。
Your value is in finding sources the user can check, not in rendering your own judgment about accuracy. "Here's where you can verify this" is useful. "I believe this is correct" is just more AI output.
AIがAIの出力を「正しい」と判定しても、それは新たなAI出力に過ぎない。代わりに、人間が自分で確認できるソースへのリンクを提供することで、検証の価値が生まれる。
5. 推論の順序を制御する — 「結論→根拠」を逆転させる
Reasoning Before Conclusions
Prompt Engineer というメタエージェント（プロンプトそのものを改善するエージェント）は、LLMの推論特性に基づいた重要な原則を含んでいる。
ユーザーが提供した例の中で結論が先に来ている場合、順序を逆転させよ。
これは Reasoning Before Conclusions（結論の前に推論を） と呼ばれる原則だ。LLMは結論を先に生成すると、後続の推論がその結論を正当化するだけの追認になりやすい。
❌ Bad: 「Reactを使うべきです。なぜなら...」
✅ Good: 「要件を分析すると... 選択肢としてはA, B, Cがあり... トレードオフを比較すると... よってReactが最適です」
Few-shot例（参考例）をプロンプトに含める場合も、例の中で「推論→結論」の順序になっていることが重要だ。
命令的プロンプティング用語の標準化
Prompt Builder は、プロンプト内の指示の強度を示す用語体系を標準化している。
| 用語 | 意味 | 使いどころ |
|---|---|---|
You WILL |
必須行動 | 必ず実行してほしいアクション |
You MUST |
重要要件 | 守るべき制約条件 |
You ALWAYS |
一貫した振る舞い | 例外なく適用するルール |
You NEVER |
禁止行動 | 絶対にやってはいけないこと |
CRITICAL |
最重要 | 違反すると致命的な項目 |
MANDATORY |
義務 | スキップ不可の手順 |
このラベル体系をプロンプト全体で統一することで、LLMが各指示の優先度を解釈しやすくなる。
6. メタプロンプティング — プロンプトの品質をプロンプトで管理する
「プロンプトを書くためのプロンプト」
エージェント定義ファイルが増えるにつれ、その品質管理が課題になる。Prompt Builder と Prompt Engineer は、プロンプト自体を成果物として扱うメタレベルのエージェントだ。
Prompt Builder: 2ペルソナの協調検証
Prompt Builder は、1つのエージェント内に2つのペルソナを持つ。
- Builder: プロンプトを構築・改善する
- Tester: 構築されたプロンプトを文字通りに実行し、曖昧さや矛盾を検出する
核心は 「Tester は改善を行わない」 という制約だ。Builder と Tester の役割が混ざると、検証の独立性が失われる。これはソフトウェア開発における「開発者とQAの分離」と同じ原理であり、後述するTDDエージェントの設計思想とも通じる。
検証は最大3サイクル。3回で解決しなければ「根本的な設計の問題」と判断し、書き直しを促す。
Prompt Engineer: 構造的分析フレームワーク
Prompt Engineer は、入力されたプロンプトを以下の観点で即座に分析する。
- Simple Change — 単純な修正で済むか
- Reasoning — 思考プロセスの有無と順序
- Structure — 構造の明確さ
- Examples — Few-shot例の有無と代表性
- Complexity — 複雑度
- Specificity — 具体性
- Prioritization — 優先改善項目
この分析フレームワークは、自分のプロンプトを自己レビューする際のチェックリストとしてそのまま使える。
2つのアプローチの使い分け
| 用途 | Prompt Builder | Prompt Engineer |
|---|---|---|
| 新規プロンプトの作成 | ○ | △ |
| 既存プロンプトの素早い改善 | △ | ○ |
| 検証サイクルが必要 | ○ | × |
| Before/After の比較 | △ | ○ |
実運用では、Prompt Engineer で素早く改善 → Prompt Builder で検証・最終調整という連携が効果的だ。
まとめ: 明日から使えるプロンプト改善チェックリスト
本記事で紹介した技法を、チェックリスト形式でまとめる。
繰り返しと強調
- 重要な制約は最低3回、表現を変えて繰り返しているか
- プロンプトの冒頭・中盤・末尾に分散配置しているか
- LLMのデフォルト挙動に反する指示ほど、繰り返しを増やしているか
思考の構造化
- 出力フォーマット（型）を明示しているか
- 推論 → 結論の順序になっているか（Reasoning Before Conclusions）
- 敵対的な視点（反論・リスク・代替案）を検討させているか
「やるな」リストの設計
- 禁止事項は具体的か（「丁寧すぎるな」ではなく「感嘆符を使うな」）
- 禁止事項に対して「代わりに何をすべきか」を示しているか
- テーブル形式でパターン分岐を定義しているか
事実ベースの行動
- 「推測するな、検証しろ」と明示しているか
- 信頼度の閾値を数値で定めているか
- Web検索の要否判断基準を示しているか
メタ検証
- プロンプトの構造・具体性・推論順序は適切か（Prompt Engineer の観点）
- 作成者と検証者の役割は分離されているか
参考: 本記事で参照したエージェント定義一覧
本記事で分析したエージェント定義は、github/awesome-copilot リポジトリで公開されている。GitHub Copilot 向けだが、プロンプト設計のアイデアソースとして他のAIツールユーザーにも有用だ。
| エージェント | 本記事での主な言及箇所 |
|---|---|
| 4.1-Beast.agent.md | 繰り返しと強調、事実ベースの行動（Web検索） |
| Ultimate-Transparent-Thinking-Beast-Mode.agent.md | フォーマットの多様性による繰り返し、思考の型の強制、敵対的分析 |
| critical-thinking.agent.md | 「Why?」の連鎖、単一質問制約 |
| devils-advocate.agent.md | 敵対的分析、1つずつ反論→統合 |
| ember.agent.md | 「やるな」リスト、診断ライブラリ、パターンマッチング |
| blueprint-mode.agent.md | Spartan式コミュニケーション、信頼度スコア、事実ベースの行動 |
| doublecheck.agent.md | 3層検証パイプライン、「Links, not verdicts」 |
| prompt-engineer.agent.md | Reasoning Before Conclusions、構造的分析フレームワーク |
| prompt-builder.agent.md | 命令的用語の標準化、Builder/Tester 2ペルソナ検証 |
Discussion