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

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 はパフォーマンスが劣ります。