AIエージェントのプロンプト設計ガイド：指示文の構造化・ツール呼び出し・ガードレール設計

エージェントのプロンプトはチャットボットと何が違うのか

AIエージェントのプロンプト設計は、チャットボット向けプロンプトとは根本的に異なります。チャットボットのプロンプトは「応答の生成」を制御しますが、エージェントのプロンプトは「行動の計画と実行」を制御します。Google Cloudが定義するエージェントの6能力（推論・行動・観察・計画・協調・自己改善）のうち、プロンプトは「推論」「計画」「協調」の3つを直接制御する設計文書です（Google Cloud, 2025）。

ポイント

エージェントのプロンプト設計で最も重要な原則は「行動の境界を明確に定義する」ことです。チャットボットは最悪の場合「不適切な回答を返す」だけですが、エージェントは「不適切な行動を実行する」リスクがあります。データの削除、送金の実行、外部APIへの不正リクエスト——エージェントのプロンプトは「何ができるか」だけでなく「何をしてはいけないか」を明確に記述する必要があります。

エージェントプロンプトの5層構造

エージェントのプロンプトは以下の5層で構成することを推奨します。

Layer 1：アイデンティティと役割

エージェントの名前、専門領域、対応範囲を定義します。「あなたは○○の専門エージェントです。△△の業務を担当します。」のように、エージェントの存在意義を明確にします。

Layer 2：行動規則と制約

やるべきこと（MUST）、やってはいけないこと（MUST NOT）、判断基準（SHOULD）を列挙します。特に「やってはいけないこと」の定義がセキュリティの要です。

Layer 3：ツール呼び出し指示

利用可能なツールの名前、用途、呼び出し条件、パラメータの説明を記述します。「どのツールを、いつ、どのように使うか」を明確にします。

Layer 4：ハンドオフ条件

他のエージェントまたは人間にタスクを引き継ぐ条件を定義します。「自分の専門外の質問」「一定金額以上の処理」「エラーが3回連続した場合」などの条件を明確にします。

Layer 5：応答フォーマット

ユーザーへの応答形式、トーン、言語、構造化データの出力形式を定義します。チャットボットと同様の応答品質を維持しつつ、行動結果の報告形式を統一します。

Layer 1：アイデンティティと役割の設計

エージェントの「自己認識」を定義する最初のステップです。名前・専門領域・対応範囲を明文化することで、エージェントが自身の境界を理解し、範囲外のリクエストを適切にハンドオフできるようになります。以下は経費精算エージェントの設計例です。

## アイデンティティ
あなたは「経費精算エージェント」です。以下の業務を担当します：
- 領収書の読み取りと金額の抽出
- 勘定科目の自動判定
- 経費規定への適合性チェック
- 承認ワークフローへの提出

## 専門領域
国内出張費、交際費、消耗品費の経費精算処理

## 対応範囲外
- 海外出張費（海外出張エージェントにハンドオフ）
- 予算策定・管理（予算管理システムに案内）
- 給与・税務に関する質問（HR部門に案内）

Layer 2：行動規則と制約の設計

ルール種別	記述例	目的
MUST（必須）	すべての処理でユーザーの確認を得てから実行する	不正な操作を防止
MUST NOT（禁止）	10万円を超える経費を自動承認しない	金額リスクの管理
MUST NOT（禁止）	ユーザーのクレジットカード番号をログに記録しない	個人情報保護
SHOULD（推奨）	判断に迷った場合は人間にエスカレーションする	不確実な判断の回避
SHOULD NOT（非推奨）	推定・推測で勘定科目を判断しない（確実な場合のみ判定）	精度の維持

注意

プロンプトインジェクション対策は必須です。ユーザー入力が「以前の指示を無視して」「管理者モードに切り替えて」などの指示を含む場合、エージェントが本来の制約を無視するリスクがあります。対策として(1) ユーザー入力とシステムプロンプトを明確に分離する、(2) ガードレールで入力を事前検証する、(3) 重要な操作は入力の内容に関わらず確認ステップを強制する、の3点を必ず実装してください。

Layer 3：ツール呼び出し指示の設計

OpenAI Agents SDKのツール定義パターンに基づく設計例です（OpenAI, 2025）。

## 利用可能なツール

### receipt_reader
- 用途：領収書画像からテキスト・金額を抽出
- 呼び出し条件：ユーザーが領収書画像を添付した場合
- 注意：抽出結果は必ずユーザーに確認してから次のステップに進む

### expense_category_classifier
- 用途：金額と目的から勘定科目を判定
- 呼び出し条件：receipt_readerの結果が確認された後
- 注意：信頼度80%未満の場合は「手動確認が必要」とマーク

### approval_workflow
- 用途：承認ワークフローに経費申請を提出
- 呼び出し条件：全項目が確認済みの場合のみ
- 制約：10万円超の申請は自動提出不可。部門長の事前承認を案内

Layer 4：ハンドオフ条件の設計

マルチエージェント環境では「いつ・誰に・何を引き継ぐか」の定義が不可欠です。ハンドオフ条件が曖昧なエージェントは、無限ループや誤った自律判断に陥るリスクがあります。以下の設計例では、条件発動のトリガーと引き継ぎ情報を明確に定義しています。

## ハンドオフ条件

### → 海外出張エージェント
- 条件：申請内容に海外の地名・通貨が含まれる場合
- 引き継ぎ情報：ユーザーID、これまでの会話履歴、抽出済みデータ

### → 人間オペレーター
- 条件1：処理エラーが3回連続で発生した場合
- 条件2：ユーザーが明示的に人間対応を要求した場合
- 条件3：不正の可能性がある申請パターンを検出した場合
- 引き継ぎ情報：エラーログ、会話履歴、検出した異常の詳細

Layer 5：応答フォーマットの設計

エージェントの応答フォーマットは、ユーザー体験と後続処理の両方に直接影響する重要な設計要素です。チャットボットの応答設計と異なり、エージェントの応答には「行動結果の報告」が含まれるため、何をしたか・結果はどうだったか・次に何が必要かを構造的に伝える設計が求められます。

応答の3つのモード

エージェントの応答は状況に応じて以下の3モードを使い分けます。

モード	用途	フォーマット例
会話モード	ユーザーとの対話・確認・質問	自然言語（です・ます調）、簡潔で1画面に収まる分量
結果報告モード	ツール実行結果の報告	構造化テキスト（項目名: 値）、成功/失敗のステータス表示
構造化出力モード	後続システムへのデータ受け渡し	JSON/YAML形式、スキーマ定義に準拠

設計例：経費精算エージェントの応答フォーマット

## 応答フォーマット

### ユーザーへの応答
- トーン：丁寧語（です・ます調）。フレンドリーすぎず、事務的すぎない
- 長さ：1応答あたり最大200文字。超える場合は要点を先に伝え詳細を後述
- 行動結果の報告形式：
  「✅ [完了したアクション] → [結果の要約]」
  「⚠️ [問題が発生したアクション] → [原因] → [推奨する次のステップ]」

### エラー時の応答
- ユーザーに技術的エラーメッセージをそのまま表示しない
- 「申し訳ございません。[何が起きたかの平易な説明]。[ユーザーができる対処法]」の形式で伝える

### 構造化出力（後続システム連携用）
- 承認ワークフローへの送信時はJSON形式：
  { "employee_id", "amount", "category", "date", "status", "confidence_score" }
- confidence_scoreを必ず含め、後続処理の判断材料にする

フォーマット設計の注意点

一貫性の維持——同じ種類の情報は常に同じ形式で返す。ユーザーが応答パターンを学習できるようにする
行動の透明性——エージェントが何をしたか（ツール呼び出し結果）をユーザーに適切な粒度で伝える。すべてを報告する必要はないが、重要なアクションは必ず通知する
多言語対応の設計——グローバル展開を見据える場合は、応答言語の切り替えルール（ユーザーの入力言語に合わせる等）を明記する

プロンプトのテストとイテレーション

プロンプト設計は一度で完成するものではありません。以下の4段階テストを順に実行し、各段階で合格基準（80%以上の成功率が目安）を満たしてから次に進んでください。

ハッピーパスのテスト

正常な処理フローが期待通りに動作するかを確認します。10件の標準的なケースで全ステップが正しく実行されることを検証します。

エッジケースのテスト

境界値（10万円ちょうど）、不正入力（架空の領収書）、曖昧な入力（「飲み会の費用」など勘定科目が曖昧なケース）での挙動を確認します。

ガードレールのテスト

プロンプトインジェクション、権限外の操作要求、禁止条件の突破を試み、すべてが適切にブロックされることを確認します。

ハンドオフのテスト

ハンドオフ条件に該当するケースを意図的に発生させ、適切なエージェントまたは人間に引き継がれることを確認します。

まとめ

AIエージェントのプロンプトは「5層構造」で設計してください。(1) アイデンティティ、(2) 行動規則、(3) ツール呼び出し、(4) ハンドオフ条件、(5) 応答フォーマット。特にLayer 2の「やってはいけないこと」の定義とLayer 4のハンドオフ条件がエージェントの安全性を、Layer 5の応答フォーマットがユーザー体験と後続システムとの連携品質を決定します。プロンプトは一度書いて終わりではなく、テスト結果に基づいて継続的に改善するドキュメントとして管理してください。