本文へスキップ
Starone

AIエンジニアリング

信頼できるAIエージェントの設計

エージェントとは、ツールを持ちループの中で動くモデルであり、有用さをもたらす性質のすべてが、同時に信頼しにくさの原因にもなります。信頼性はモデルを取り囲むハーネスから生まれます。上限のあるループ、冪等なツール、管理されたコンテキスト、そして軌跡全体の評価です。

· 5分で読めます · Starone エンジニアリング

エージェントとは、次の一手を自ら決める言語モデルです。目標とツール群を与えられ、ツールを呼び出し、結果を読み、タスクが完了したと判断するまで選択を繰り返します。このループがあるからこそ事前にスクリプト化できない作業を扱えますが、同時にあらゆる信頼性の問題の源でもあります。制御フローが、確率的なコンポーネントによって実行時に選ばれるからです。

私たちの見解では、エージェントの信頼性は大部分がシステムの問題です。モデルが良くなればステップあたりのエラー率は下がりますが、長いタスクではステップごとのエラーが積み重なります。そのため、実際の操作を任せられるかどうかを決めるのは周辺のエンジニアリングです。

まずエージェントが必要かどうかを問う

手順が事前に分かっているなら、ワークフローを書きます。コードが順序を決める固定的なモデル呼び出しの連なりは、より安価で、速く、テストしやすく、監査人にも説明しやすいものです。ルーティング、抽出、要約、そして文書処理の大半はこの形に収まります。

エージェントが正当化されるのは、経路が途中で判明する内容に左右される場合です。インシデントの調査、データに不整合のある複数システム間でのレコードの照合、コードベースを読み進める作業などが該当します。優れた設計の多くはハイブリッドで、決定的なワークフローが、範囲を限定したサブタスクを一つだけエージェントに委ねます。

ループに上限を設ける

特徴的な失敗がツール呼び出しのループです。エージェントが、失敗する同じ呼び出しをわずかに変えて繰り返したり、二つのアクションの間を行き来したりして、外部の何かが止めるまでトークンを消費し続けます。すべてのエージェントには、プロンプトで依頼するのではなく、ハーネスが強制するハードリミットが必要です。

  • タスクあたりの最大ステップ数と、トークンまたはコストの予算
  • 実時間でのデッドラインと、その内側に設けるツールごとのタイムアウト
  • 同一呼び出しの繰り返しの検知。検知時は実行を終了するか、別の戦略を取らせます。
  • 断念する場合の定義済みの終了状態。試みた内容を報告し、人に引き継ぎます。

ツールを二度呼んでも安全にする

エージェントはリトライします。ネットワーク呼び出しが結果不明のままタイムアウトすれば、ハーネスもリトライします。ツールが決済の実行、チケットの作成、顧客へのメール送信を行うものであれば、リトライは副作用を繰り返します。状態を変更するツールはすべて、タスクとステップから導出した冪等性キーを受け取り、繰り返しの呼び出しに対しては再実行せず元の結果を返すようにすべきです。

ツールの設計はプロンプトの設計と同じくらい重要です。ツールは一つのことだけを行い、引数を厳密なスキーマで検証し、どのフィールドが不正で、どの値が許容されるのかといった、モデルが対処できるエラーを返すべきです。曖昧なエラー文字列は、やみくもなリトライを招きます。任意のSQLやシェルコマンドを受け付ける汎用ツールよりも、用途を絞ったツールを選びます。権限が強制されるのはツールの境界だからです。

読み取りと実行を分離する

エージェントが読むテキストには、どれにも指示が含まれている可能性があります。Webページ、サポートチケット、ファイル、別のツールの出力などです。これが間接プロンプトインジェクションであり、プロンプトの文言でこれを確実に防ぐことはできません。現実的な防御は、モデルは誘導されうるものと想定し、その影響を限定することです。

エージェントはタスクに必要な最小権限で実行し、共有のサービスアカウントではなく、代理する対象のユーザーにスコープを絞った認証情報を使います。ツールは可逆性で分類します。読み取りは自由に実行でき、取り消し可能な書き込みはログを取ったうえで実行でき、取り消せない操作や影響の大きい操作には、実行される内容を人が正確に確認できる承認ステップが必要です。一回の実行の中で、非公開データへのアクセス、信頼できないコンテンツへの接触、データを外部に送出できる経路の三つが重なる場合には、最大限の注意を払います。

これらの統制にはコストがあります。承認ゲートは作業を遅くし、用途を絞ったツールはエージェントが解決できる範囲を狭めます。人がマージ前にレビューするブランチ上で作業するコーディングエージェントのように、本番の認証情報を持たないサンドボックス内であれば、すべての操作が取り消せるため、広い自律性を与えることは妥当です。統制の水準は、エージェントに対する漠然とした不安ではなく、ミスが起きたときの影響範囲に合わせるべきです。

コンテキストウィンドウを意図的に管理する

長いタスクではコンテキストがツール出力で埋まっていき、ハードリミットに達する前に品質が低下します。初期の指示の影響力は薄れ、古い中間結果が最新のものとして扱われ、エージェントは当初の目標から逸れていきます。このコンテキストドリフトは徐々に進むため、短いテストでは見えにくいものです。

対策は構造的なものです。大きなツール結果は、コンテキストに入る前に切り詰めるか要約します。計画、下した判断、確定した事実といった永続的な状態は、スクロールで流れていくに任せず、外部ストアに保持して読み直します。決められた時点で履歴を圧縮します。自己完結したサブタスクは、新しいコンテキストを持ち結論だけを返すサブエージェントに委任します。

実行を永続化し、観測可能にする

数分から数時間にわたって動くタスクは、デプロイ、レート制限、クラッシュによって中断されます。ステップごとに状態を永続化し、最初からやり直して副作用を繰り返すのではなく、最後のチェックポイントから再開できるようにします。Temporalのようなデュラブル実行エンジンはこの用途に適しており、各ツール呼び出しを記録されたアクティビティとして扱えます。

軌跡の全体を記録します。モデルへのすべての入力、ツール呼び出し、引数、結果、トークン数、所要時間を、実行IDで紐付けます。エージェントが想定外の動きをしたとき、その理由を知る唯一の手段がこのトレースです。

回答だけでなく軌跡を評価する

最終回答が正しくても、許容できない経路が隠れていることがあります。タスクに不要なレコードを読んでいたり、4ステップで済むところに40ステップをかけていたりする場合です。そのため評価では、現実的なツールを備えたサンドボックスで固定のタスクスイートを実行し、軌跡全体を対象にします。

  • タスクの成否。エージェント自身の完了報告ではなく、環境の最終状態で確認します。
  • 経路の質:ステップ数、コスト、禁止されたツールやデータに触れていないか
  • 障害注入下での振る舞い。ツールのエラー、タイムアウト、ツール出力に注入された指示を含みます。
  • 同一タスクを繰り返し実行したときのばらつき。一度通ったタスクが5回に1回は失敗することがあるためです。

同様の課題に取り組んでいる方へ

ぜひ意見を交換させてください。この記事を書いたエンジニアが直接お話しします。