powered by TechFeed
表示モード
Deep Dive

AIは「壊れても気づかれない」—本番運用の実践者が語る、サイレント障害・コードレビュー限界・エージェント管理の現実

10月16日、InfoQが「AI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governance」と題した記事を公開した。AIエージェントを本番環境に展開する際の運用課題と、それに対する実践的なアプローチを、第一線の実践者たちが語っている。

10月16日、InfoQが「AI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governance」と題した記事を公開した。AIエージェントを本番環境に展開する際の運用課題と、それに対する実践的なアプローチを、第一線の実践者たちが語っている。


InfoQのウェビナー「AI in Production: What Breaks, What Works, and Who Approves It?」では、ThoughtWorksのZichuan XiongおよびPrem Chandrasekaran、プライバシー専門家のKatharine Jarmul、金融AIの実践者Lan Chuが登壇した。モデレーターのHien Luuは冒頭、AIが従来のソフトウェアと根本的に異なる壊れ方をすると指摘した。クラッシュする代わりに、もっともらしい誤りを生成し続けるという点だ。

「サイレント障害」がいちばん怖い

本番AIシステムで最も対処が難しいのは、インフラの死活監視が全てグリーンのまま、業務ロジックだけが静かに壊れる障害だ。

Xiongは「セマンティックドリフト」(モデルが文脈や語義のズレを静かに蓄積していく現象)の実例として、テキスト→SQL変換エージェントが「member」という単語を営業部門とカスタマーサポート部門で同義に扱ってしまうケースを挙げた。標準的なトレーシングでは検出できず、下流のビジネス分析に静かに誤りが蓄積されていく。

さらに深刻なのはLan Chuが紹介した「埋め込みドリフト」(基盤となる埋め込みモデルの更新によってベクトル空間の分布が変化し、既存の閾値設定が無効化される現象)だ。金融コンプライアンスシステムで、禁止された投資アドバイスをベクトル類似度で遮断するエージェントを運用中、基盤となる埋め込みモデルがバックグラウンドで予告なく更新された。その結果、ベクトル距離の分布が変化し、本番トラフィックで偽陽性・偽陰性が急増した。しかし全てのインフラヘルスチェックはグリーンのままだった。

この2つの事例が示すのは、AIシステムの障害監視は従来のサーバー死活監視とは別レイヤーが必要だという事実だ。

その他の障害パターンとして、Chandrasekaran(ThoughtWorks テック&ビジネスサービスリード)はRAGパイプラインが意図せず機密文書を取得するリスクを指摘。Jarmulはモデルが学習データを記憶しており、匿名化情報の再識別やAPIキーの漏洩に悪用されうる点を強調した。ChandrasekaranはGitリポジトリの設定ファイル(.git/config)を悪用し、git cloneやgit pullなどの通常コマンド実行時にフック経由で不正コードを実行させるGitSpawn脆弱性にも言及している。AIコーディングエージェントが自律的にリポジトリを操作する場面が増えるなか、この攻撃ベクタはエージェントを介した広範なサプライチェーン侵害につながるリスクをはらむ。

コードレビューは「ハーネス」レベルで設計し直す

コーディングエージェントが人間のレビュー速度を超えるペースでプロダクションコードを生成している現状では、ライン・バイ・ラインのレビューはすでにスケールしない。

パネリストが提唱したのは次のアプローチだ:

  • CI/CDパイプライン内でスタイル・構文チェックを自動化し、人間のレビューはアーキテクチャ、ビジネスの意図、非機能要件に集中する
  • プルリクエスト生成前の「ハーネスレベル」での意図評価にシフトレフトする(Xiong)
  • ミューテーションテスト(mutation testing)の活用:意図的にコードに変異を導入し、テストスイートが表面的なカバレッジ率ではなく実際のロジックを検証しているかを確認する手法で、近年再評価されている

評価(eval)についてChuは、「リリース前の静的チェックリストではなく、永続的な生きたインフラとして扱うべき」と明言した。スパンレベルでの継続的なオンライントレーシング、ログフィルタリング、LLMによる障害パターンの分類を組み合わせ、本番のエッジケースをオフラインのベンチマークスイートに継続的に還流させる仕組みが必要だとした。

エージェントのガバナンスは「新人エンジニア」モデルで

自律エージェントの「爆発半径」を限定するため、Chandrasekaranはエージェントを新入りエンジニアとして扱うアプローチを提案した。具体的には:

  • エージェントに非人間アイデンティティ(個別のサービスアカウント等)を付与する
  • 読み取り専用・可逆書き込み・不可逆書き込みを区別した階層的アクセス制御を実装する
  • サードパーティのMCP(Model Context Protocol)依存関係をバージョン管理する
  • APIシークレットはエージェントのランタイム環境外(サンドボックス)に厳格に分離する

Jarmulはプロンプトエンジニアリングをシステム防衛の手段にすることを戒め、体系的なレッドチーミング、継続的な脅威モデリング、エージェントの機能スコープの厳格な定義を推奨した。これらのガバナンス施策は個別の対症療法ではなく、設計段階から組み込む「セキュリティ・バイ・デザイン」として一貫して実施されてはじめて機能する、というのがパネリスト全体の共通認識だ。

最後にパネリストが共通して強調したのは、デプロイの最終承認はエンジニアリング・セキュリティチームではなく、ビジネス側の戦略的意思決定であるという点だ。技術的なガードレールの検証は工学チームの仕事だが、「承認する」という行為の責任の所在を明確にしておくことが、エージェントガバナンスの前提になる。


詳細はAI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governanceを参照していただきたい。