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

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

コンテキスト処理#

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

思考の連鎖#

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

...First, think carefully step by step about what documents are needed to answer the query. Then, print out the TITLE and ID of each document. Then, format the IDs into a list.

->

    ...まず、どの文書がクエリに答えるために必要かを慎重に考えます。次に、各文書のタイトルと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 はパフォーマンスが低い。