AI エージェントの構築と運用を学ぶ

ほぼすべてのエージェントは、どのようなフレームワークで作成されたものであっても、同じ少数の部品から組み立てられています。障害はそれらに沿って明確に局所化されるため、デバッグのほとんどはそれらを区別することを学ぶことになります。

モデルは推論エンジンです。現在の状態を読み取り、次に何が起こるかを決定します。モデルの選択は、デフォルトではなく、実際のエンジニアリング上の決定です。モデルが大きいほど、あいまいな指示にも耐えやすく、モデルが小さいほど、コストが数分の一で、応答が速くなります。成熟したエージェントは複数のモデルを使用することが多く、真に判断が必要なステップのために高価なモデルを確保しておきます。

通常、システム プロンプトとして提供される指示は、人格ではなく契約です。これらは、役割、制約、出力形式、そして何よりも完了の定義を確立します。あいまいな指示は、エージェントが堂々巡りしたり途中で止まったりする最も一般的な唯一の原因です。

コンテキストとは、この特定のステップ中にモデルが認識できるすべてのものです。タスク自体、取得したレコード、以前のツール呼び出しの結果です。コンテナではなく予算として扱います。無関係なマテリアルにトークンが費やされるたびにコストがかかり、レイテンシが追加され、実際に重要な 1 行に対するモデルの注意が薄れます。

記憶は、ステップ間および実行間で存続するものです。短期記憶は通常、実行中の記録にすぎません。長期記憶は意図的な行為です。持続する要約、過去の決定の記録、ユーザーのプロフィールなどです。この 2 つを混同すると、エージェントはセッション間で記憶喪失になったり、徐々に自分の歴史に溺れたりすることになります。

ツールはアクション スペースであり、エージェントが呼び出すことができる型指定された関数です。モデルはそれらを読み取ることでツールを選択するため、それらの名前と説明はプロンプトの一部です。説明のない processData というツールの選択は間違っており、モデルのせいになります。

決定ステップは、モデルが引数付きのツール呼び出しまたは最終応答を出力した瞬間です。上流のすべては、その 1 つの選択を適切に行うために存在します。

実行はランタイムです。実際にツールを呼び出し、ループと再試行の制限を適用し、資格情報を添付し、エラーを処理し、何が起こったかを記録するコンポーネントです。フレームワークは推論部分を提供します。ランタイムは、結果を他の人の前に安全に公開できるようにするものです。

組み立てると、サイクルは次のようになります。状態を観察し、アクションを 1 つ選択し、それを実行し、結果を観察し、繰り返します。何か問題が発生した場合、その症状は通常 1 つの部分に現れます。確信を持って間違った答えは、通常、文脈が欠落しています。不適切なアクションとは、通常、ツールの説明が不十分であることを指します。決して終了しない実行は、通常、完了の定義が欠落しています。

エージェントの能力は、渡されたアクションと情報によって決まります。これは、実際のエンジニアリングのほとんどが存在する場所です。

ツールを幅が狭く動詞の形になるように設計します。顧客の注文を読み取るツールは、データベースを管理するツールよりも優れています。限定的なツールは明確な決定を生成し、許可するのが簡単ですが、解釈できる方法で失敗します。幅広いツールはモデルに即興演奏を促しますが、その即興演奏が苦痛なのです。

同僚に対してではなく、モデルに対して説明を書きます。ツールが何をするのか、いつ使用するのか、いつ使用しないのか、そして何を返すのかを説明する必要があります。引数を入力して検証します。ここでのスキーマは官僚的なものではなく、拒否された呼び出しと運用システムへの不正な書き込みの違いです。

投機的にツールを追加しないでください。アクション空間が大きくなるにつれて、選択の品質は低下します。30 個のツールが利用できるため、モデルはタスクではなく選択に推論を費やし、間違った選択をすることが多くなります。 2 つのツールが重なっている場合は、それらを結合するか、一方を削除します。

コンテキストはダンプではなく取得する必要があります。このタスクに必要な特定のレコードを取得し、それらを渡します。ソースが大きい場合は、ドキュメント全体を貼り付けるのではなく、ソースを適切に分割し、関連性によって取得します。引用を返してもらい、答えを生み出した文章をたどることができます。

読むことと書くことを分けてください。ほとんどのエージェントは広範な読み取りアクセスと非常に狭い書き込みアクセスを必要とし、これらを 1 つの権限として扱うことで、要約エージェントは最終的にレコードを削除できるようになります。書き込みが不可逆的な場合は、書き込みの前に人間を置きます。

統合では、これがコーディングの問題ではなく組織の問題になります。すべてのチームが同じ上流システムに独自の接続を配線すると、資格情報が重複し、ポリシーが一貫性がなく、監査証跡が 1 つも存在しません。 MCP などのオープン スタンダードにより、互換性のあるエージェントは、チームごとに 1 つではなく、上流システムごとに 1 つのバインディングを使用して、同じ管理された統合を再利用できます。

資格情報には独自のルールが必要ですが、それは簡単です。エージェントは決して秘密を保持しません。これはアクションを要求し、プラットフォームはアウトバウンド呼び出しの時点で資格情報を添付します。そうすれば、漏洩したプロンプト、詳細ログ、または共有トランスクリプトが漏洩キーになることはありません。

最後に、部分的な障害に備えて計画を立てます。実際のシステムでは、レート制限、ページネーション、タイムアウトが行われ、半分の応答が返されます。すべてのツールの応答を成功として扱うエージェントは、自信を持って何にも基づいて構築されません。モデルが推論できる構造化データとしてエラーを返し、どのエラーを回避するのではなく実行を停止すべきかを事前に決定します。

エージェントが作成されたマシン上でのみ実行されるエージェントはプロトタイプです。パッケージ化は、他の人、チーム、環境が質問することなく実行できるものに変えるものです。

まずは再現性から始めましょう。最新の解決策を受け入れるのではなく、依存関係を固定します。スキーマを使用して入力と出力を入力すると、呼び出し元は何を送信し、何が返されるかを正確に知ることができます。構成をコードの外側に保持することで、同じアーティファクトを編集せずにステージングおよび運用環境に対して実行できます。

一緒に持ち込んではいけないものを明確にしてください。シークレットはもちろんですが、環境固有のエンドポイント、ハードコードされたアカウント識別子、および絶対パスも含まれます。値がないとエージェントを起動できない場合は、実行の途中ではなく、起動時にどの値が欠落しているかを大声で通知して失敗する必要があります。

エージェントが動作するために必要な契約を宣言します。つまり、エージェントが期待するツール、それらのツールに必要な権限、想定されるモデル、実行あたりのおおよそのコストなどです。レビュー担当者は、その宣言だけから承認するかどうかを決定できる必要があります。

ソフトウェアと同じようにバージョン管理を行います。それが本質的なものだからです。 Git 内に保持し、ブランチではなく特定のバージョンを指定し、2 つのバージョンを比較してプロンプトとコードの何が変更されたかを確認し、変更が見た目よりも悪いことが判明した場合は 1 つのコマンドでロールバックできます。

評価セットをエージェントと一緒に発送します。これは、エージェントが行うべきことについての唯一の正直な記述であり、これを継承する人は、出力を信頼する前に、自分の環境があなたの環境と同じように動作するかどうかを確認できます。

最後に、このエージェントの目的、絶対に実行してはいけないこと、所有者、障害が発生した場合の対処方法など、境界をわかりやすい言葉で書き留めます。このメモには 10 分かかりますが、それが採用されるエージェントと静かに見捨てられるエージェントの違いになります。

1 つのエージェントが 1 つのプロジェクトです。エージェントが 30 名になるのは運用上の問題であり、ほとんどのチームが予想するよりも早く、通常は誰もそうすべきだと決めることなく到着します。

この変化は量的ではなく質的です。エージェントが 1 つあれば、それが何をするか覚えています。 30 のチームがあり、それぞれが独自のフレームワークを選択しているため、全体像を把握している人は誰もおらず、何が実行されているのか、誰が所有しているのか、何に触れることができるのか、何をしたのか、そして私たちにどのようなコストがかかるのかなど、重要な疑問は答えられなくなります。

他のすべては在庫に依存するため、在庫が最優先されます。すべてのエージェントは、それを作成したものに応じて、ID、所有者、およびバージョンを保持します。プラットフォームの外部に構築されたエージェントは、プラットフォーム上に構築されたエージェントと同じ条件でカタログ化されます。これが、インベントリを正確に保つ唯一の方法です。

制御は一元的に適用され、均一に施行されます。プラットフォーム チームがポリシーを一度設定すると、実行時にランタイムがそれをすべてのチームのエージェントに適用します。これは、各エージェントに許可を求めたくないエンジニアリング部門と、目に見えないものを承認できないセキュリティ部門の間の通常の対立を解決する取り決めです。

フリート規模での可観測性は、ログの保持以上の意味を持ちます。トレースを使用すると、個々の実行をリプレイできます。不変の監査証跡には、代理ユーザー、使用された資格情報、および生成された出力が記録されます。 Evals スコアは、動作、構造、レイテンシ、コストを対象として定義した基準に対して継続的に実行され、重要なチェックに失敗すると、レポートを提出するのではなくエージェントが停止します。これは、パッシブなロギングからアクティブな品質強制へのステップです。

コストは、チームが最後に発見し、最も後悔する要素です。エージェント、ワークスペース、ユーザー、プロバイダー、モデル別に支出がトークンではなく通貨で表示されるため、説明のつかない請求書が意思決定のリストに変わります。サーキットブレーカーの予算により、それが実行可能になります。80 パーセントで警告し、100 パーセントでブロックし、事後報告するのではなくオーバーランを阻止します。アラートは警告します。実際に支出を止めるのはブレーカーだけです。

コストが可視化されれば、逸話的ではなく体系的に削減できます。最適化は 4 つの手段で機能します。つまり、より小さなモデルを試す、プロンプトとコンテキストをトリミングする、結果を改善せずにコストを追加するツールを削除する、決定論的なステップをモデルから通常のコードに移動する、です。それぞれの推奨事項は、適用される前に自分自身の評価と比較して測定されるため、質の高い節約を静かに購入することはできません。

統合は同じ中央の方法で管理されます。各チームが独自の接続と資格情報のコピーを確立するのではなく、アップストリーム システムごとに 1 つのバインディング、チームがリクエストできる承認済みのカタログ、およびそのすべてにわたる単一の監査証跡。

大規模になると、調整が非常に重要になります。エージェントは相互に手作業で作業し、2 つのチームが同じ問題を個別に解決する場合は相互に複製し、同じレート制限を目指して競合します。再利用可能なエージェントとスキルを含む共有カタログは、重複を最も安価に解決できる方法であり、エンジニアの最初のエージェントを数週間ではなく数時間で出荷できる理由でもあります。

最後に、フリートにはライフサイクルがあるものとして扱います。エージェントは実験から本番環境に昇格し、より優れたエージェントが存在すると非推奨となり、タスクがなくなると引退します。チームごとの導入、エージェントごとのコスト、評価に対するパフォーマンスを測定することによって、会話は実験のカウントを超えて、単に AI を使用するのではなく AI で運用する方向に進みます。