Fastlyが発表した内容
Fastlyは9月21日、AI Runtime Control（ARC）を発表しました。ARCは、アプリケーションやエージェントと、公開またはセルフホスト型のモデルエンドポイントとの間に、一つのマネージドエンドポイントを置きます。アプリケーションはモデル事業者の生の認証情報ではなく、Fastlyが発行する仮想キーで認証します。顧客は既存のモデル事業者との契約と認証情報を維持します。仮想キーはアプリケーション、環境、チーム、開発者を識別し、ルーティングと利用上限を持たせられます。
Fastlyによると、ARCはモデルへのリクエストと応答、トークン数、事業者、モデル、仮想キー、任意のセッション識別子を記録します。リクエスト数とトークン数のレート制限、通知または遮断を選べる月次金額予算、順序付きの事業者フェイルオーバーに対応します。AI Firewallは別契約のアドオンで、プロンプトと応答のプロンプトインジェクション検査を行えます。これらは運用統制ですが、一つの経路への集約は新たな権限と可用性の境界も生みます。
仮想キーは呼び出し元を識別しても、操作を認可しない
アプリケーション単位のキーは、共有されたモデル事業者の秘密情報より大きな改善です。失効、帰属、上限設定、ローテーションを細かく制御できます。一方、特定の利用者がツール呼び出しを許可したこと、操作がエージェントの委任範囲内であること、モデル出力が金融や業務のポリシーを満たすことは証明しません。ゲートウェイ認証を操作認可とみなすと、別の二つの統制基盤を混同します。
本番エージェントでは、重大なツール呼び出しごとに、認証済み主体、範囲を限定した権限、承認された意図、判定に使ったポリシーバージョンを結び付けるべきです。ARCキーは推論を要求できるワークロードを識別し、下流サービスはデータ参照、決済開始、設定変更、その他の不可逆な処理をそのワークロードに許可するか独立して判断します。キーのローテーションも、利用者セッションやツール認証情報とは分けて検証する必要があります。
モデルのフェイルオーバーは単なる再試行ではなく、動作変更である
ARCは優先事業者がリクエストを処理できない場合、順序付きリストの次の事業者へ送り、復旧後は優先先へ戻せます。可用性は向上しますが、ツール呼び出し形式、コンテキスト上限、拒否動作、遅延、トークン計測、安全性が二つのモデルで完全に一致することはまれです。技術的に成功した切り替えでも、意味上は互換性のない結果になり得ます。
ワークフローごとに代替モデルの組み合わせを承認し、可能ならモデルバージョンを固定し、すべての切り替え先へ同じ契約テストと安全性評価を実施すべきです。記録には、本来の送信先と実際に処理した事業者の両方を残します。重大な処理では、縮退運転、読み取り専用、実行待ち、停止のどれを選ぶか明示し、自動切り替えによってエージェントの実質的な権限を暗黙に拡張してはいけません。
検査モードとストリーミングが実際の適用範囲を決める
Fastlyのドキュメントでは、AI Firewallにログモードと遮断モードがあります。送信前に入力を検査し、信頼できないデータと命令を区別するための境界トークンを追加し、完了した応答にインジェクションの痕跡がないかを検査します。一方、ストリーミングリクエストでは応答検査を行わずに中継され、構造的分離のために追加したトークンもモデル事業者の課金対象になると明記されています。
これらは脅威モデルへ組み込むべき条件です。ログモードは検知であり防止ではありません。遮断モードには誤検知への対応と、安全な失敗表示が必要です。ストリーミングは応答を蓄積する場合と統制範囲が異なります。プロンプトインジェクション検知だけで、出力スキーマ、ツールの許可リスト、引数検証、最小権限の認証情報、取引シミュレーション、重大操作の人間承認を代替することもできません。名称から保証を推測せず、回避手法と障害時動作を検証する必要があります。
集約ログは機密データを扱うシステムになる
プロンプトと応答の完全なログは、インシデント対応、コスト帰属、監査を大きく改善できます。同時に、顧客情報、ソースコード、誤ってプロンプトへ含めた認証情報、検索で取得した文書、モデルが生成した機密情報を集約する可能性があります。可視性を高めるゲートウェイが、AI基盤のプライバシー影響と漏えい時の被害を拡大することもあります。
本番トラフィックを流す前に、データ分類、地域別ルーティング、保持期間、秘匿化、アクセスレビュー、エクスポート、削除要件を定義すべきです。セッション識別子を管理されていない個人識別子にしてはいけません。さらに、仮想キー、予算、事業者の順序、検査モードの設定変更にも証跡が必要です。リクエストログだけでは、実行時にどのポリシーが適用されるべきだったかを説明できないためです。
Ineezaの見解
Fastly ARCが時宜を得ている理由は、本番AIシステムに決済やAPI基盤と同じ規律、すなわち範囲を限定した認証情報、計測可能な消費、決定済みの障害時方針、確認可能な証跡が必要になっている点です。重要なのは複数のモデルURLを一つへ置き換えることだけではありません。ゲートウェイを統制された本番依存先として扱いながら、操作認可、モデル互換性、データガバナンス、下流の照合を独立させることです。集約が力を発揮するのは、統制基盤自体が誤る、停止する、または不完全である場合まで設計したときです。