Michael JohnsonAIエージェントは、ネットワーク接続の障害原因を特定し、本番インフラに影響する修正を提案できる。10月13日のエンジニアリング記事で、Microsoftは多層アーキテクチャを解説し、個別のソフトウェアルールでエージェントのアクセスと操作を制限する仕組みを示した。
記事の執筆者で、MicrosoftのAzure Networking担当プリンシパルエンジニアであるアルン・マリクは、データセンターで接続が不安定になる状況を取り上げている。エージェントはデバイスの状態とテレメトリーを収集し、最近の変更と照合して障害を分類し、要約を作成する。その後、アーキテクチャに組み込まれた制御手段を通じて、ユーザートラフィックを扱うデバイスのBGPセッションを停止するなどの修正に進むことができる。
Microsoftが説明する境界は、アイデンティティ、ツール、変更、時間の4つだ。エージェントは呼び出したユーザーの権限の範囲で動作し、制御されたインターフェースを通じてシステムにアクセスする。本番環境の状態を変更する前には人間の承認を待ち、成功した反復可能な手順は、時間をかけて決定論的な手順として固定できる。
エージェントの権限はユーザーの権限に従う
最初の境界は認証情報だ。提案されている設計では、エージェントはユーザーに代わって動作し、そのユーザー以上の権限を得ない。サービスアカウントが必要な場合は、その権限をさらに狭くする。これにより、ログやツールの応答に含まれる誤りや悪意あるテキストの影響を抑えられる。モデルが、ユーザーや専用アカウントにない権限を取得することはできない。
2つ目の境界はツールだ。各操作は型付きインターフェースを介して行い、個別の認可を受け、構造化された入力を受け取り、ログに記録する。マリクは、制限する対象はコマンドラインそのものではなく、管理されていないシェルへのアクセスだと説明する。範囲を絞ったコマンドは制御されたツールとして提供できる一方、自由に使えるシェルでは権限の分離や監査が難しくなる。
読み取りと変更には別々のルールが必要
説明されたアーキテクチャでは、診断は自動で実行できる。本番システムの状態を変える操作は、人間が承認するまで一時停止する。執筆者によれば、この制限はモデルへの指示だけに頼らず、実行環境のコードで担保する必要がある。モデルはデバイスからの非構造化出力を解析できるが、操作の決定と権限の確認はプログラムロジックが担う。
記事ではネットワークインターフェースの例を挙げている。モデルがコマンド出力を構造化フィールドに変換し、バリデーターがスキーマと照合したうえで、決定論的な条件に基づいて次の操作を選ぶ。設定を変更する手順では、承認されるまで実行を待つ。こうして、タスクの記述とネットワークを変更する権限を切り分ける。
4つ目の境界は反復可能性に関わる。Microsoftは、検証済みの診断手順を決定論的な手順として固定し、既知の状況では新たにモデルを呼び出さずに実行できるようにすることを提案している。同社によれば、これにより推論を繰り返すコストを抑え、再現性を高め、エラーや攻撃の余地を減らせる。記事には、本番導入の定量的な成果は示されていない。
導入時に確認したいこと
Microsoftの記事はアーキテクチャとシナリオのエンジニアリング上の説明であり、完成した製品の信頼性を独立に評価したものではない。独自のエージェントを設計するチームにとって実務上の手順となるのは、操作をユーザー本人に結びつけ、許可する操作を列挙し、呼び出しを型付けして記録し、読み取りと書き込みを分離し、変更には明示的な承認を求めることだ。反復可能なケースは、起動条件と結果を検証した後で、通常の手順に置き換えられる。
要点は役割を分けることにある。モデルは未知の障害の分析を支援し、構造化された出力を作る。一方、実行システムは許可する操作と承認が必要なタイミングを決める。Microsoftは、オペレーターへの提案からネットワークインフラの制限付き自動化へ移行するために、この分離を提案している。