エージェントおよびプロンプトの実践

AI エージェントシステムとは#

エージェントシステムは、独立してタスクを完了できるシステムであり、従来のソフトウェアとは異なり、ユーザーの承認の下で高度に独立してワークフローを実行できます。
エージェントシステムの核心は、LLM を利用してワークフロー管理と意思決定を行い、必要に応じてツールを動的に選択して外部システムと対話することです。

AI エージェントシステムを構築すべき時#

エージェントシステムは、従来の自動化手法では処理が難しい複雑で多段階のタスクに適しています。例えば、複雑な意思決定が必要なシナリオや、維持が難しいルール、非構造化データに依存するシナリオです。
例えば、支払い詐欺分析において、エージェントシステムは経験豊富な調査員のように文脈を評価し、疑わしい活動を特定できます。

AI エージェント設計の基礎#

エージェントシステムは、モデル（LLM）、ツール（外部 API）、指示（明確な行動ガイドライン）の 3 つのコアコンポーネントで構成されています。
モデルの選択は、タスクの複雑性、遅延、コストのトレードオフに基づくべきです。
ツールは標準化された定義を持つべきであり、エージェントシステム間で柔軟に使用できるようにします。
指示は明確で具体的である必要があり、曖昧さを減らし、意思決定の質を向上させます。

オーケストレーションモデル#

単一エージェントシステム：1 つのモデルが適切なツールと指示を備え、ループ方式でワークフローを実行します。
複数エージェントシステム：ワークフローを複数の調整されたエージェント間で分散させ、「管理型」（1 つの中心エージェントが複数の専門エージェントを調整）と「非中央集権型」（複数のエージェントが平等にタスクを相互に引き継ぐ）に分かれます。

ガードレール#

ガードレールは、エージェントシステムが安全に運用されることを確保するための重要な要素であり、データプライバシーリスクや評判リスクを管理します。
ガードレールには、関連性分類器、安全性分類器、PII フィルター、コンテンツレビュー、ツールの安全性評価などが含まれる場合があります。
ガードレールの設定は、実際のリスクに基づくべきであり、新たな脆弱性が発見されるたびに調整されるべきです。

実施提案#

単一エージェントシステムから始め、徐々に複数エージェントシステムに拡張します。
柔軟なプロンプトテンプレートを使用して、メンテナンスと評価を簡素化します。
エージェントシステムに人間の介入メカニズムを実装し、高リスクまたは失敗の状況に対処します。

エージェントプロンプト実践#

openai エージェントプロンプトのベストプラクティス

Persistence (持続性)#

モデルにこれはマルチターンのキャラクターであり、問題が解決されるまで作業を続ける必要があることを伝えます。

You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.

-> 

あなたはエージェントです - ユーザーのクエリが完全に解決されるまで作業を続けてください。その後、あなたのターンを終了し、ユーザーに戻ります。問題が解決されたと確信したときだけ、ターンを終了してください。

Tool-calling (ツール呼び出し)#

不確かな場合は、モデルに積極的にツールを使用して情報を取得するよう促します。

If you are not sure about file content or codebase structure pertaining to the user’s request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.

->

ファイルの内容やコードベースの構造について不明な場合は、ツールを使用して関連情報を取得してください：絶対に推測したり、答えを作り上げたりしないでください。

Planning (計画)#

モデルに各ツール呼び出しの前に計画し、呼び出し後に反省するように導きます。これにより、モデルが「思考プロセスを言葉にする」ことができ、問題解決能力が向上します（推論モデルに依存しない）。

You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.

->

各関数呼び出しの前に詳細な計画を立て、前の関数呼び出しの結果について深く反省する必要があります。関数呼び出しだけでこのプロセス全体を行わないでください。そうすると、問題を解決し、洞察を持って考える能力が損なわれる可能性があります。

ツール呼び出しの正しい姿勢#

API の tools フィールドを使用することを強くお勧めします：プロンプトにツールの説明を手動で挿入するのはやめましょう！公式のテストによると、API を通じてツール定義を渡すことで、エラーを減らし、モデルのパフォーマンスを向上させることができます（SWE-bench で 2% 向上）。
良い名前を付け、用途を明確に記述します：ツール名と説明は明確であるべきで、パラメータも同様です。これにより、モデルがツールを正しく使用できるようになります。
複雑なツールの使い方は例に入れます：ツールが複雑な場合は、システムプロンプト内に特別に「# Example」セクションを設け、説明を簡潔に保つのが最善です。

推奨される指示作成プロセス#

まず全体の要求を示します：「指示」または「返信ルール」というタイトルで基本的な要求を列挙します。
ポイントごとに詳細を説明します：具体的な行動については、サブタイトルを使って詳細に説明します。
手順の順序を明確にします：特定のプロセスに従う必要がある場合は、順序付きリストで明確に示します。
デバッグと最適化：
- 指示間に矛盾がないか確認します。
- 望む結果を示す明確な例を提供します。
- 全て大文字や感嘆符などの強調手段を慎重に使用します。これにより、モデルがこれらの点に過度に注意を向ける可能性があります。

よくある落とし穴と解決策#

必ず XXトラップ：例えば、「毎回の返信前に必ずツールを呼び出す」と強制することは、モデルが乱雑に呼び出す原因となる可能性があります。解決策：情報が不足している場合は、まずユーザーに尋ねることを補足します。
例をそのままコピーの問題：モデルが提供された例を直接コピーする可能性があります。解決策：明確に「参考にするが、これらの例に限定されず、状況に応じて柔軟に調整する」と説明します。
話が長すぎる問題：時にはモデルが過剰な説明や不必要な形式を出力することがあります。解決策：指示の中で簡潔で具体的な形式を要求します。

コンテキスト処理#

能力の限界：基本的な能力は強いですが、膨大な情報から多くの情報を検索したり、全体的な情報を必要とする複雑な推論を行う際には、パフォーマンスが低下する可能性があります。
ベストプラクティス：指示をコンテキストの冒頭と末尾にそれぞれ繰り返して配置します。
モデルに提供された情報のみを使用して回答するのか、それとも自身の知識ベースを組み合わせることができるのかを明確に指示できます。

思考の連鎖#

モデルに人間のように「考えさせ」、複雑な問題を小さなステップに分解して解決する簡単な思考の連鎖指示を導きます（推論モデルに依存しない）。

...まず、クエリに回答するために必要な文書について慎重に考え、各文書のタイトルとIDを印刷します。次に、IDをリスト形式に整形します。

->

    ...まず、クエリに回答するために必要な文書について慎重に考えます。次に、各文書のタイトルとIDを列挙します。最後に、IDをリスト形式に整形します。

進化した CoT：モデルの思考プロセスに偏差が見られた場合、より具体的な指示を通じてその思考戦略を規範化できます。例えば、ガイドラインには、モデルにクエリ分析（Query Analysis）を先に行い、その後コンテキスト分析（Context Analysis）を行い、最後に統合（Synthesis）するように求める例が示されています。

推奨されるプロンプト構造テンプレート#

# 役割と目的
# 指示
## より詳細な指示のサブカテゴリ
# 思考ステップ（例：思考の連鎖指示）
# 出力形式
# 例
## 例1
# コンテキスト（あれば）
# 最終指示と段階的に考えるためのプロンプト（例：CoTのスタート）

-> 

# 役割と目的
# 指示
## より詳細な指示のサブカテゴリ
# 思考ステップ（例：思考の連鎖指示）
# 出力形式
# 例
## 例1
# コンテキスト（あれば）
# 最終指示と段階的に考えるためのプロンプト

区切り文字の選択#

最優先は Markdown：タイトル、リスト、コードブロックなど、明確で直感的です。
XML も良好：内容を正確に包むのに適しており、ネストが容易です。
JSON は相対的に煩雑：構造は強いですが、プロンプト内ではエスケープが必要な場合があります。
長文書シーン：XML (<doc id=1 title=”...”>...</doc>) と類似表形式 (ID: 1 | TITLE: ... | CONTENT: ...) フォーマットが効果的で、JSON はパフォーマンスが劣ります。