Systems Design Meditation · Edition 1
エージェントはシステムそのものではない
なぜAIはインフラの問題になりつつあるのか
Edward Calderón
ソフトウェアアーキテクト
AIは、インフラの中へと姿を消しつつある。
重要性が下がったからではない。スタックのより深い層へと移動しつつあるからだ。
ここ数年、世間の議論はモデルに集中してきた。どのモデルがより優れた推論を行うか?どのモデルのコンテキストが大きいか?どのモデルがより優れたコードを書くか?こうした問いは今も有用だ。しかし、それだけではもはや十分ではない。
モデルは答える。エージェントは行動できる。システムが行動できるようになったとき、アーキテクチャは知能と同じくらい重要になる。
分析単位は変わった
言語モデルは、入力を確率的な出力へと写像する。運用エージェントは、そのモデルをメモリ、ツール、アイデンティティ、ポリシー、キュー、データベース、フィードバックで包み込む。チケットを読み、本番環境のテレメトリを照会し、設定を変更し、顧客に通知することもある。その一つひとつのステップが、信頼境界を越えていく。生成される文章の品質は、結果のごく一部にすぎない。
だからこそ、モデルはシステムではないのだ。モデルは、システムの中の一参加者にすぎない。
クラウドや分散型インフラを運用したことのある人にとって、今必要となる問いは見慣れたものだろう。エージェントは何にアクセスできるのか?その権限は誰が委譲したのか?何を変更できるのか?どのような状態を保持するのか?アクションはどのように観測されるのか?誤りだった場合どうなるのか?アクションは元に戻せるのか?誰が責任を負うのか?
ツールへのアクセスは、推論の誤りを、起こり得る状態遷移へと変えてしまう。チャットボットが返金ポリシーを捏造しても、誤っているのは出力だけだ。だがエージェントが返金を実行し、台帳を更新し、ケースをクローズしたら、周囲の組織は実際に変わってしまう。障害モデルは、もはやテキストにとどまらない。
限定されたアクションのために設計する
信頼できるエージェントインフラには、いくつかの境界が必要だ。アイデンティティは、共有のAPIキーではなく、ワークロードごとに固有のものにすべきだ。認可は、範囲が狭く、寿命が短く、許可されるリソースとアクションについて明示的であるべきだ。影響の大きい操作には承認ゲートが必要だ。すべてのツール呼び出しには、構造化された監査データが要る。実行者、委譲者、入力、ポリシーの判定、出力、そして結果として生じる状態である。
オブザーバビリティも、通常のリクエストトレーシングのレベルを超えなければならない。トレースは、呼び出しが成功したことを教えてくれるが、そのビジネスアクションが誤っていたことは教えてくれない。モデルの意思決定をツール呼び出しに、そしてツール呼び出しを永続的な影響につなげて捉える必要がある。注目すべき指標は、レイテンシやトークン使用量だけではない。意図した不変条件が依然として保たれているかどうかである。
ロールバックも同様に具体的な話だ。補償できるアクションもある。デプロイなら、以前のリビジョンに戻すことができる。しかし、真に取り消せないアクションもある。メールはすでに送信され、シークレットは漏えいし、支払いは確定してしまった。アーキテクチャは、アクションをエージェントが受け取る前に分類しておくべきで、インシデントの後に分類すべきものではない。
インフラ変更を支援するエージェントを考えてみよう。メトリクスの確認やパッチの提案は、安全に行える。そのパッチをサンドボックスに適用するには、スコープを限定したクレデンシャルが必要になるかもしれない。本番環境では、ポリシーの評価、リスクの高い変更に対する人間による承認、段階的ロールアウト、ヘルスチェック、そして自動停止条件が求められる。エージェントは、際限のない管理者と化すことなく、最初から最後まで関与できる。
このパターンが成熟したDevSecOpsに似ているのは、根底にある問題がよく知られたものだからだ。リスクの制御を失わずに、変更をシステムに通していくという問題である。エージェントはインターフェースをより柔軟にするが、柔軟性は運用上の規律をなくすわけではない。
能力は信頼性ではない
設計の拙いインフラの中に置かれた非常に有能なモデルは、脆いプロダクトを生み出す。一方、少し能力で劣るモデルでも、優れたアーキテクチャの中に置かれれば、はるかに信頼できるシステムを生み出すこともある。後者のシステムは、不確実性を抑え込み、障害を検知し、復旧することができる。
企業での導入にばらつきが出るのも、同じ理由による。デモンストレーションは、目に見える能力のために最適化される。本番システムは、アイデンティティのライフサイクル、データの境界、インシデント対応、コスト管理、規制対応の証跡、劣化した依存関係を扱えなければならない。こうしたレイヤーは、単なる周辺的な配管ではない。知能に仕事を任せられるかどうかを決めるのは、この部分だ。
台頭しつつあるエージェント標準は有用だが、プロトコルがアーキテクチャの代わりになることはない。エージェントフレームワークは、組織のリスク許容度を決定できない。モデルプロバイダーは、どの状態遷移が取り消し可能かを定義できない。そうした決定は、モデルを取り囲むシステムに属するものだ。
したがって、実践的な方向性は「あらゆる場面での自律」ではない。段階的な自律である。観測し、推奨し、狭い境界の中で行動し、測定された信頼性によって、より広範な権限を獲得していく。これにより、確率的な構成要素を決定論的であるかのように見せかけることなく、チームは学びを進めていける。
知能だけでは、信頼できるインフラは生まれない。
生むのは、アーキテクチャだ。