エージェント構築のベスト プラクティス

既存の業務プロセスに埋め込まれた、正確で回復力のあるエージェントを構築するための設計原則とワークフロー マッピングのガイダンス。

エージェントを実際のワークフロー用に設計する

効果的なエージェントとは、スタンドアロンのボットではなく、十分に理解しているワークフローに組み込まれているものです。業務プロセスにすでに存在するワークフローから始めて、判断が必要なステップ (構造化されていない入力の解釈、コンテキストの評価、有効なオプションの選択) を特定します。

これらのステップは、エージェントによる自動化の候補です。エージェントは目標ベースです。つまり、エージェントに目標を与えると、エージェントはそれを達成する方法を計画します。反復可能なルールベースのステップは、RPA または決定論的なワークフローに属します。

構築の前に、ワークフローのマッピングの演習を実施します。

• 判断ポイントと入力/出力形式を特定する。
• 変数やあいまいな入力を含む明確に定義されたプロセスを探します (チケットのトリアージ、コンプライアンスの確認など)。
• エージェントをワークフローの代用として設計することを避ける。エージェントは、ワークフロー内での意思決定を可能にするコンポーネントです。

ヒント:

プラグ アンド プレイ エージェントのパターンを使用すると、リスクを管理しながら迅速に拡張できます。

スコープを絞って業務特化型にする

エージェントは、タスク固有で責任に制限がある場合に、最高のパフォーマンスを発揮します。複数のロールを持つエージェントに過負荷をかけないようにします。各エージェントは常に 1 つの責任 (請求書データの抽出、顧客の意図の分類など) に集中させることをお勧めします。

狭いスコープを設定することの利点:

• デバッグと反復処理が容易になる
• パフォーマンスと評価の安定性が向上する
• 不整合やハルシネーションのリスクが減少する

明確で反復的なプロンプトを設計する

エージェントの動作の中心にあるのは、プロンプトの設計です。エージェンティック プロンプトを使用します。これはプロンプトの進化したスタイルであり、以下を含みます。

• 定義済みの役割とペルソナ
• 明示的なタスクの内訳と推論の指示
• 出力形式とエラー処理のガイダンス

たとえば、「このドキュメントを要約してください」と指示する代わりに、「あなたはコンプライアンス アナリストです。このポリシー文書をいくつかのセクションに分割してください。セクションごとに、2 つの文で要約し、潜在的な政策ギャップにフラグを立ててください。ドキュメントをどのようにセグメント化したかを説明してください。」

タスクを説明するために、入力にマップされた代表的な例をプロンプトにいくつか含めます。ただし、網羅的なエッジ ケースのサンプルをハードコーディングすることは避けてください。代わりに、構造化された評価セットを使用して、エッジ ケースとシナリオをカバーします。これにより、エージェントの堅牢性が増し、反復が容易になります。

プロンプトを体系的に反復処理する

• 構造、役割、推論パスを調整します。
• 精度、カバレッジ、およびタスクの成功の変化を追跡します。
• プロンプト リンティングや Agent Builder のプレイグラウンドなどのツールを使用して実験を行います。

ヒント:

英語を既定の言語として使用します。エージェントは、プロンプト、スキーマ定義、ツールの指示が英語で記述されている場合に最高のパフォーマンスを発揮します。英語以外の文字を使用すると、ツールの呼び出しや機能の解析に影響する可能性があります。

構造化された入力を使用する

データがエージェントに到達する前にデータを前処理します。Document Understanding や IXP などのテクノロジを使用して、構造化された入力を抽出します。生のデータやノイズの多いデータをエージェントに提供すると、出力品質が低下し、プロンプトの複雑さが増します。

達成基準と評価戦略を定義する

信頼できるエージェントにするには、明確で測定可能な目標が必要です。次のような KPI と評価メカニズムを設計します。

• 精度のしきい値
• 信頼度スコア
• 回答の一貫性
• 推論の透明性

「正常に動作した」時点で終わらずに、どのように動作したかを確認します。トレース ログとジョブ ログを使用して、ツールの呼び出し、判断チェーン、コンテキストの使用状況を評価します。

エッジ ケース、コンテキストの変動、ドメイン固有の条件をテストする評価データセットを作成します。以下を含める必要があります。

• 敵対的入力
• コンテキストの少ないクエリ
• 予期しない形式
• システム境界テスト

人間参加型 (HITL) のエスカレーションを実装する

エージェントは、いつサポートを求めるべきかを理解している必要があります。以下を処理するために、HITL のエスカレーション パスを組み込みます。

• データなし
• ツールの障害
• あいまいな判断
• 規制またはビジネス ルールの例外

エージェントの実行中に一時停止し、続行する前に人間による入力を求める方法を提供します (たとえば、ツールの呼び出しや機密データの使用を承認する場合など)。エージェントの出力が下流に渡される前に承認するために、周囲のプロセスに個別の人間によるレビュー ステップを追加します。

各エスカレーションでは、以下を行う必要があります。

• 今後のエージェントの動作に情報を提供する
• ツールの使用法の改良をサポートする

ガードレールと命名規則を使用する

ツールを定義する際は以下に従います。

• 小文字の英数字の名前を使用する
• 特殊文字やスペースを使用しない
• 機能に基づいたわかりやすいラベルにする (例: web_search、document_analysis)

これにより、LLM の解析および呼び出しロジックとの相互運用性が確保されます。

次のようなガードレールを使用して、安全性とガバナンスを適用します。

• ツールの安全でない入力をフィルター処理またはブロックする
• 必要に応じて、ツールの使用法を人間にエスカレーションする
• コンプライアンスのために、ツールのやり取りを記録および監視する

デプロイ後にエージェントを監視する

エージェントはデプロイしたら完成ではありません。次のような監視と再調整のループを設定します。

• パフォーマンスを実行時のデータに対して確認する
• ツールの使用法やロジックのドリフトを探す
• 一貫した方法でベンチマークする
• トレースに対してフィードバック インターフェイスを使用して、今後の動作を改善します。

注:

ハード ビジネス ルールを含む、長くて決定論的なワークフローをエージェント内に直接モデリングしないようにしてください。代わりに、標準のオートメーションまたは BPMN オーケストレーションを使用します。