エージェントについて

https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

この内容について写経したものです。

エージェントとは？

ワークフロー実行の制御に LLM を使用しないアプリケーション（単純なチャットボット、シングルターンの LLM、感情分類器などを考えてみてください）は、エージェントではありません。

その経路を LLM が決めているかどうかが重要な観点になる。
つまり、あるタスクや目的を達成するためにどのような手順、順序、方法、経路を選ぶか、そしてその選択を LLM が自律的に判断・決定しているかどうか。

いつエージェントを利用すべきか。

例えば、支払い詐欺分析のような処理があるとして、従来のルールエンジンはチェックリストのように機能しますが、それに対して LLM エージェントは熟練した捜査官のように、文脈を評価し、微妙なパターンを考慮し、明確なルールが破られていない場合でも不審な活動を特定できます。このような微妙な推論能力こそが、エージェントが複雑で曖昧な状況を効果的に管理することを可能にします。

エージェントが価値を付加できる場所を評価する際は、特に従来の方法で問題が発生していたり、これまで自動化が困難だったワークフローを優先してください。具体的には以下の 3 つの基準に当てはまる場合です。

1. 複雑な意思決定: 微妙な判断、例外処理、文脈に依存する決定を伴うワークフロー。 例：カスタマーサービスにおける払い戻し承認。
2. 維持が困難なルール: 広範で複雑なルールセットのために扱いにくくなり、更新にコストがかかるかエラーが発生しやすいシステム。 例：ベンダーのセキュリティレビューの実施。（評価基準やチェックリストが多岐にわたり、都度更新が必要）金融商品の審査基準（法規制や社内規定の変更に即応する必要がある）助成金や補助金の申請審査（複数の条件や例外規定を組み合わせて判定）
3. 非構造化データへの強い依存: 自然言語の解釈、文書からの意味抽出、ユーザーとの対話が必要なシナリオ。 例：住宅保険の請求処理。（顧客が提出する説明文や証拠書類から状況を読み取る）

エージェントの基礎

• モデル (Model): エージェントの推論と意思決定を司る LLM (大規模言語モデル)。
• ツール (Tools): エージェントがアクションを実行するために使用できる外部の機能や API。
• 指示 (Instructions): エージェントの振る舞いを定義する明確なガイドラインや制約。

モデル選択の原則

1. 評価を設定し、パフォーマンスのベースラインを確立する。
2. 利用可能な最良のモデルで精度目標を達成することに焦点を当てる。
3. 可能な場合は、より大きなモデルを小さいモデルに置き換えることで、コストとレイテンシを最適化する。
   つまり、一番いいもので試して、ある程度測定を実施、その最高のモデルで目標達成して、あとは小さいモデルでも達成できるかを検討していくというプロセスを回す。

ツールの定義

• データ (Data): ワークフロー実行に必要な文脈や情報を取得することを可能にします。 例：トランザクションデータベースや CRM のようなシステムへのクエリ、PDF ドキュメントの読み取り、ウェブ検索。
• アクション (Action): データベースへの新しい情報の追加、レコードの更新、メッセージの送信など、システムと連携してアクションを実行することを可能にします。 例：メールやテキストの送信、CRM レコードの更新、カスタマーサービスのチケットを人間へ引き継ぐ。
• オーケストレーション (Orchestration): エージェント自体が他のエージェントのためのツールとして機能できます。オーケストレーションは「複数エージェントの連携・分担」。
  • あるエージェントが、他のエージェントを「ツール」として使い、より複雑なタスクを効率的に解決します。 例：払い戻しエージェント、リサーチエージェント、ライティングエージェント。

Configuring instructions（エージェントの振る舞いを定義する明確なガイドライン）

エージェントの振る舞いを一貫性のあるものにし、期待通りに動作させるためには、明確なガイドラインやガードレールを設定することが重要です。
その際に役立つ主な指針として、以下のポイントが挙げられます。

• 既存のドキュメントを活用する
  • 既存のドキュメントを活用することで、指示作成の効率化が図れるだけでなく、組織内で既に確立されている手順や知識を LLM エージェントに反映させることができ、一貫性のあるエージェントの振る舞いを実現する上で重要
• タスクを分解させる
  • 大きなタスクや曖昧な指示は、そのままだとエージェントが誤った解釈をしやすくなります。
  • 例えば「レポートを作成して」という指示を、「情報収集」「構成案の作成」「本文執筆」「校正」といった小さなステップに分けることで、各ステップごとに明確な指示ができ、エージェントの動作が安定します。
• 明確なアクションを定義する
  • 「適切に対応してください」のような曖昧な表現ではなく、「メールを送信する」「データベースを更新する」など、具体的なアクションを明示することで、エージェントが迷わずに動作できます。
  • これにより、解釈のブレや想定外の動作を防ぐことができます。
• エッジケースを捉える
  • 通常のケースだけでなく、「例外的な状況」や「失敗時の対応」もあらかじめ想定し、条件付きで指示を用意しておくことが大切です。
  • 例えば「API がエラーを返した場合は再試行する」「必要な情報が不足している場合はユーザーに確認する」といったガードレールを設けることで、エージェントが様々な状況に柔軟に対応できるようになります。

オーケストレーション (Orchestration)

指示やツールといった基礎的な部品が揃った段階で、より複雑なタスクやワークフローを自動化・最適化するためには、エージェント同士の連携や役割分担（オーケストレーション）の設計が重要となります。

シングルエージェントシステムについて:

• 一つのエージェントでも、ツールを段階的に追加していくことで多くのタスクを処理できます。
• このアプローチは、複雑さを管理しやすく、評価やメンテナンスもシンプルになります。
• 新しいツールを追加することで能力を拡張でき、早急に複数のエージェントを導入する必要がありません。
• イメージ的には以下のような流れ
  • ユーザーから入力を受け取る
  • 必要に応じてツールや外部機能を呼び出す
  • ガードレールで安全性やルールをチェック
  • フックで追加処理を実行
  • 指示（ガイドライン）に従って出力を生成
  • ユーザーへ返答・アクションを実行
• 「実行 (run)」の概念: エージェントが動作する際の中心的な概念は「実行」であり、これは通常「ループ」として実装されます。エージェントは、特定の終了条件（ツールの呼び出し、特定の形式の出力、エラー、最大実行回数など）が満たされるまで動作を続けます。
• 複雑さの管理: シングルエージェントの複雑さを管理する効果的な戦略として、プロンプトテンプレートの使用が挙げられています。用途ごとに多数の個別プロンプトを用意する代わりに、ポリシー変数（ユーザー名、メンバー期間など）を受け入れる柔軟なベースプロンプトを使うことで、メンテナンスと評価が大幅に簡素化されます。

プロンプトテンプレートの例:

あなたはカスタマーサポート担当者です。
ユーザー名: {user_name}
会員期間: {membership_duration}年

ユーザーからの問い合わせ内容に対して、
丁寧かつ迅速に対応してください。
必要に応じて、会員期間に応じた特別対応も検討してください。

このように「ユーザー名」や「会員期間」などの変数を埋め込んで、個別対応ができるようにします。

複数のエージェントの作成を検討すべき時:

• 一般的な推奨としては、まずシングルエージェントの能力を最大限に引き出すべきです。

• 複数のエージェントは概念的な分離には役立ちますが、追加の複雑さや管理コストが増えるため、ツールを備えたシングルエージェントで十分な場合が多いです。

• 複数のエージェントを検討すべき状況:

  • 多くの複雑なワークフローに対して、複数のエージェントに分割することでパフォーマンスとスケーラビリティが向上する場合があります。
  • シングルエージェントが複雑な指示に従えなくなったり、一貫して誤ったツールを選択するようになったりした場合、システムを分割し、より明確に役割を分けられたエージェントを導入する必要があるかもしれません。

• 分割に関する実践的なガイドライン:

  • 複雑なロジック: プロンプトに多くの条件分岐（if-then-else）があり、プロンプトテンプレートでの拡張が難しくなった場合、ロジックの各部分を別々のエージェントに分割することを検討します。
  • ツール過負荷: 問題はツールの数だけでなく、それらの類似性や重複です。ツールの名前、パラメータ、説明を明確にしても、ツールが分かりにくく、シングルエージェントでのパフォーマンスが改善しない場合（特に重複するツールが多い場合）、複数のエージェントの使用を検討します。（明確に定義されたツールであれば多数扱える場合もありますが、重複が多いと少数でも問題になりうる、と指摘されています。）

マルチエージェントシステム (Multi-agent systems)

1. マネージャーパターン (Manager pattern) - 「ツールとしてのエージェント」
   • 仕組み: 中央に存在する「マネージャー」となる主要なエージェントが、複数の専門的なタスクや領域を扱うエージェントを「ツール」として呼び出すことで、全体のワークフローを調整・指揮します。
   • 特徴: マネージャーが中心的な制御権を持ちます。ユーザーとの直接的なやり取りは主にマネージャーが行い、専門エージェントはマネージャーからの指示（ツール呼び出し）を受けて処理を行い、結果をマネージャーに返します。マネージャーはこれらの結果を統合してユーザーに提示します。
   • 適したケース:
     • ワークフローの実行を一元的に制御したい場合。
     • ユーザーとのやり取りを単一のエージェントに任せたい場合。
     • 例: ユーザーからの複雑な要求（例：「これをスペイン語、フランス語、イタリア語に翻訳して！」）に対して、マネージャーエージェントが各言語の翻訳を専門とするエージェントをツールとして順次呼び出すようなシナリオ。
2. 分散パターン (Decentralized pattern) - 「エージェント間のハンドオフ」
   • 仕組み: 複数のエージェントが対等な立場で存在し、必要に応じてタスクの実行責任を**他のエージェントに「ハンドオフ（引き渡す）」**することでワークフローを進めます。ハンドオフは一方通行の制御の引き渡しであり、多くの場合、特定のツールや関数の呼び出しとして実装され、ハンドオフが発生すると、その時点での会話の状態なども含めて制御が新しいエージェントに移ります。
   • 特徴: 中央を制御するエージェントはいません。各エージェントは自身が制御権を持ったときに、必要であればユーザーと直接やり取りします。
   • 適したケース:
     • 中央集権的な制御や、単一エージェントによる結果の統合が必要ない場合。
     • 各専門エージェントが特定のタスクで完全に制御を引き継いで処理を進めたい場合。
     • 例: カスタマーサービスのトリアージ（振り分け）。最初に対応したエージェント（トリアージエージェント）が問い合わせ内容（例：「注文の配送状況を教えてください」）を聞き、それが注文管理に関する内容だと判断したら、注文管理を専門とするエージェントに制御をハンドオフし、以降はその注文管理エージェントがユーザーとやり取りするようなシナリオ。

（補足）宣言型 vs 非宣言型グラフ:

これは、これらのマルチエージェントの連携構造を、フレームワーク上でどのように定義・実装するか、というスタイルの違いについて軽く触れている部分です。

• 宣言型: ワークフロー全体の構造（どのエージェントがいて、誰にハンドオフするか、条件分岐など）を、コード実行前にあらかじめ全て定義する方式。（見た目は分かりやすいが、複雑なシナリオや動的な変更に弱い場合がある。）
• コードファースト（Agents SDK のアプローチ）: 従来のプログラミング言語の構文（if 文や関数呼び出しなど）を使って、より柔軟かつ動的にワークフローのロジックを記述していく方式。事前に全てを定義しなくても良い。（より柔軟だが、全体像はコードを読まないと把握しにくい場合がある。）

「ガードレール (Guardrails)」と「人間による介入（Human intervention）」

ガードレール (Guardrails)について:

• 目的: LLM（大規模言語モデル）ベースのアプリケーションにおいて、データプライバシーリスク（例：システムプロンプトなど内部情報の漏洩を防ぐ）や評判リスク（例：ブランドイメージを損なうような不適切な振る舞いをしないようにする）を管理するための安全機構です。
• 仕組み: ガードレールは「多層的な防御機構」として機能します。一つのガードレールだけでは不十分なことが多く、複数の専門的なガードレールを組み合わせることで、より堅牢なエージェントになります。これは、強力な認証・認可プロトコルや厳格なアクセス制御、標準的なソフトウェアセキュリティ対策と組み合わせて実装されるべきです。
• ガードレールの主な種類:
  • 関連性分類器 (Relevance classifier): 入力がエージェントの担当範囲や話題から外れていないかチェックします。
  • 安全性分類器 (Safety classifier): ジェイルブレイク（システム制限を回避しようとする試み）やプロンプトインジェクション（悪意のある指示の注入）といった、システム脆弱性を突こうとする入力を検出します。
  • PII フィルター (PII filter): エージェントの出力に個人情報（PII: Personally Identifiable Information）が含まれていないか確認し、情報漏洩を防ぎます。
  • モデレーション (Moderation): ヘイトスピーチやハラスメントなど、有害または不適切な入力を検出します。
  • ツール安全策 (Tool safeguards): エージェントが使用できる各ツールにリスクレベル（低・中・高）を割り当て、リスクの高いツールの実行前に自動的なチェックを入れたり、人間に確認を求めたりする仕組みです。
  • ルールベースの保護 (Rules-based protections): 事前に定義されたルール（禁止語リスト、文字数制限、正規表現など）に基づいて、既知の脅威を防ぎます。
  • 出力検証 (Output validation): エージェントの応答がブランドの価値観に合っているか、不適切な内容を含んでいないかチェックします。
• ガードレールの構築: まずは既知のリスクに対処するガードレールを設定し、実際の運用で発見されたエッジケースや失敗に基づいて新しいガードレールを追加していくのが効果的です。セキュリティとユーザー体験のバランスを取りながら調整していくことが重要です。
• Agents SDK での実装: Agents SDK ではガードレールが重要な要素として扱われます。エージェントの主要な処理と並行して実行され、違反が発生すると例外を発生させる方式（optimistic execution by default）を取っています。ガードレールは関数や、特定のポリシーを実行するエージェントとして実装できます。

人間による介入（Plan for human intervention）について:

• 目的: エージェントが単独では適切に処理できない、あるいは処理すべきでない状況で、スムーズにタスクの制御を人間に引き渡すための重要な安全策です。これは特にデプロイ初期に、エージェントの失敗パターンや想定外のケースを発見し、エージェントの改善や評価に役立てる上で不可欠です。
• 仕組み: エージェントがタスクを完了できないと判断した場合に、制御を人間に引き渡します。例えば、カスタマーサービスでは担当者へのエスカレーション、コーディングアシスタントならユーザー自身にコード編集の制御を戻す、といった形になります。
• 介入をトリガーする主な条件:
  • 失敗しきい値の超過: エージェントが何度もタスクの完了を試みたが失敗し続ける、あるいはユーザーの意図を理解しようと複数回試みたが成功しない、といった場合に設定された上限を超えたとき。
  • 高リスクのアクション: ユーザーの注文キャンセル、多額の返金の承認、支払い実行など、敏感で、元に戻すのが難しく、あるいは大きな影響を与える可能性のあるアクションを実行しようとする際。エージェントへの信頼性が十分に高まるまでは、このような高リスクのアクションは人間による確認を必須とするべきです。