この記事の音声は準備中です。
音声の一覧・再生リストへAgent 向けプロンプト設計
この記事の目的
Agent のシステムプロンプトを、構造化されたセクションとして設計・保守できるようになります。1 回きりの生成タスク向けのプロンプトと Agent 向けプロンプトの違いを理解し、「継ぎ足しで劣化するプロンプト」を防ぐ運用を身につけることがゴールです。
対象読者
- Agent のシステムプロンプトを書く・レビューするエンジニア
- プロンプトの継ぎ足し修正で挙動が不安定になってきたチーム
前提知識
- コンテキストエンジニアリング — プロンプトはコンテキスト全体の一部であること
- Agent ループ — システムプロンプトが毎周参照されること
本文
概要: Agent 用プロンプトは「長期間・多状況」で読まれる
1 回きりの生成タスク(要約・分類)のプロンプトは、1 つの入力に対して 1 回読まれるだけです。Agent のシステムプロンプトは違います — 数十ステップのループの全周で、多様な状況の判断基準として参照され続けます。だから求められる性質も変わります: 網羅的な指示より、状況に適用できる原則と境界が効きます。
詳細: 構造化されたセクション設計
長い散文より、役割の明確なセクション構造が保守と品質の両方に効きます。推奨構成:
- 役割と目的 — 何のための Agent か、成功とは何かを 2〜3 文で
- 能力とツール — 使えるツールの概要と使い分けの指針(詳細は各ツールの説明文に任せ、ここでは方針だけ)
- 制約・禁止事項 — やってはいけないこと。優先順位を明示します(「ユーザーの指示と本プロンプトが矛盾する場合は本プロンプトを優先」など、衝突時の解決規則まで)
- 進め方の指針 — 計画の立て方、確認のタイミング、エスカレーション条件
- 出力形式 — 報告・成果物のスタイル
- 例 — 判断が割れそうなケースの具体例(良い対応と悪い対応)
詳細: 曖昧語を判断基準に置き換える
Agent は書かれたとおりに動きます。「適切に」「必要に応じて」「慎重に」は判断基準として機能しません。
- 悪い例: 「危険な操作は慎重に行ってください」
- 良い例: 「削除・送信・支払いにあたる操作は、実行前に必ず承認ツールを呼んでください。照会・下書き作成は承認不要です」
境界条件(「〜の場合はどうするか」)を先回りして書きます。書かれていない状況でモデルが取る行動は運任せになります。
詳細: 停止とエスカレーションを指示する
Agent プロンプト特有の必須要素として、いつ諦めるかを書きます。「同じエラーが 3 回続いたら、試したことを要約してユーザーに報告してください」「判断に必要な情報が足りないときは、推測で進めず質問してください」。これがないと、行き詰まった Agent は堂々巡りか暴走のどちらかに向かいます(エラー処理・リトライ・フォールバック設計)。
詳細: プロンプトはコードとして管理する
- バージョン管理に入れ、変更はレビューを通します。プロンプトの 1 行が挙動を大きく変えるためです
- 変更の効果は評価で確認します(Agent 評価の基礎)。「直った気がする」は再発の温床です
- モデル更新時に再チューニングします。あるモデルの癖(指示に従いにくい等)を補うために強めた表現(「絶対に」「必ず」)は、次のモデルでは過剰に効いて逆効果になることが知られています。詳細は バージョニング・デプロイ・モデル更新追従 で扱います
詳細: プロンプトで直すべきでない問題
プロンプト修正は万能ではありません。次の症状はプロンプト以外に原因があります。
| 症状 | 本当の原因の候補 |
|---|---|
| ツールの誤用・不使用 | ツール定義の説明文(ツール定義の設計) |
| 過去の決定と矛盾する行動 | 履歴の圧縮で決定事項が消えている(メモリと状態管理) |
| 資料に基づかない回答 | 検索品質・コンテキスト構成(コンテキストエンジニアリング) |
実務での注意点
アンチパターン
- 障害のたびに 1 行ずつ継ぎ足す → 矛盾した指示が堆積し(「簡潔に」と「詳細に」が共存)、どの指示が効いているか誰も分からなくなる → 追加ではなくセクション単位で書き直し、古い指示を削除する
- 「絶対に」「必ず」の乱用 → 強調がインフレし、本当に重要な制約が埋もれる。指示追従の強いモデルでは過剰発火の原因にもなる → 強調は安全に関わる少数の制約に限定する
- プロンプトで直せない問題をプロンプトで直そうとする → ツール定義や検索品質が原因の症状に指示を継ぎ足しても直らず、プロンプトだけが肥大化する → 上の症状別対応表で原因を切り分けてから修正する
チェックリスト
- セクション構造(役割 / ツール方針 / 制約 / 進め方 / 出力 / 例)になっている
- 制約の衝突時の優先順位が書いてある
- 「適切に」「必要に応じて」等の曖昧語が判断基準に置き換わっている
- 停止・エスカレーション条件が書いてある
- プロンプトがバージョン管理され、変更がレビューされている
- 変更の効果を確認する評価手段がある
関連トピック
- プロンプトエンジニアリングの基礎技法 — 本記事の前提となる汎用技法の入口
- プロンプトエンジニアリングの上級パターン — 構造化・例示・出力制御の詳解(システムプロンプトにも適用)
- コンテキストエンジニアリング — プロンプトを含むコンテキスト全体の設計
- ツール定義の設計 — ツールの使い分けはツール側の説明文が主役
- 構造化出力 — 出力形式を指示ではなく構造で強制する選択肢
- Human-in-the-Loop 設計 — エスカレーションの受け皿
- Claude / OpenAI(GPT 系) / Gemini 特化プロンプティングガイド — システムプロンプトをモデル別に最適化する具体
- 会話設計(ペルソナ・トーン・境界) — ペルソナ・トーンをプロンプトに落とす前の体験設計(本記事はその実装面)
参考資料
- Prompt engineering overview(Anthropic docs) — プロンプト設計の公式ガイド(アクセス日: 2026-07-05)