AIシステムにおける「コンテキスト劣化」「オーケストレーションのズレ」「サイレント・フェイル」の台頭

私が企業の導入（エンタープライズ・デプロイメント）で見てきた中で最も高価な AIの失敗 は、エラーを出しませんでした。アラートは一つも鳴りません。ダッシュボードは赤くなりません。システムは完全に稼働していました。違っていたのは、常に、そして自信満々に、ただ間違っていたことです。これが信頼性（リライアビリティ）のギャップです。そして、ほとんどの企業向けAIプログラムは、その問題を検知するために作られていません。

私たちは過去2年、モデルの評価がかなり上手くなるよう努力してきました。ベンチマーク、精度スコア、レッドチーム演習、リトリーバル品質のテストです。しかし本番では、モデルが壊れる場所はめったにありません。壊れるのは、インフラ層です。モデルに餌を与えるデータパイプラインです。それを包むオーケストレーション（制御）ロジックです。それを基礎付けるリトリーバル（検索）システムです。さらに、出力を信頼する下流のワークフローです。つまり、その層はいまだ、別種のソフトウェアを前提に設計されたツールで監視されているのです。

誰も測れていないギャップ

この問題が見えにくい理由はシンプルです。運用的に健康で、行動として信頼できる（behaviorally reliable）ことは同じではなく、ほとんどの監視スタックはその違いを判別できません。

あらゆるインフラ指標で緑、SLA内のレイテンシ、通常のスループット、フラットなエラー率。にもかかわらず、6か月前の陳腐化した検索結果をもとに推論していたり、ツール呼び出しの後に劣化しているのに黙ってキャッシュされたコンテキストへフォールバックしていたり、エージェント的ワークフローの5ステップにわたって誤解を伝播させていたりすることがあります。こうしたことはPrometheusには出てきません。Datadogのアラートも何も引っかかりません。

理由は明快です。従来のオブザーバビリティ は「サービスが稼働しているか？」に答えるために作られていました。企業向けAIでは、さらに難しい問いに答える必要があります。「サービスは正しくふるまっているか？」—これは別の計測器です。

このギャップを埋めるには、インフラ側のテレメトリに加えて、行動（behavior）のテレメトリ層を追加する必要があります。既存のものを置き換えるのではなく、拡張して、サービスが応答したかどうかだけでなく、モデルが受け取ったコンテキストに対して実際に何をしたのかを捉えるようにするのです。

標準的な監視では捕捉できない4つの失敗パターン

ネットワーク運用、物流、オブザーバビリティの各プラットフォームでの企業向けAI導入を見ていると、同じような失敗パターンが繰り返し現れます。名前を付けられるほど一貫しているのです。

1つ目は、コンテキストの劣化です。モデルが、不完全または陳腐化したデータをもとに推論することで、エンドユーザーには見えない形で問題が発生します。答えは見た目だけは整っています。根拠（グラウンディング）は失われています。検知は通常、ずっと後になってから起きます。システムアラートという形ではなく、下流の結果として現れるのです。

2つ目は、オーケストレーションのドリフト（制御のずれ）です。エージェント的パイプライン は、1つのコンポーネントが壊れたからといって失敗することは稀です。失敗するのは、検索、推論、ツール利用、そして下流のアクションの間の相互作用のシーケンスが、現実の負荷下でズレ始めたときです。テストでは安定して見えたシステムが、ステップをまたぐレイテンシの積み重なりや、エッジケースの山積みによって、まったく別の振る舞いを示します。

3つ目は、サイレントな部分的失敗です。あるコンポーネントが期待を下回っていても、アラートしきい値を超えないため検知されません。システムは、運用的に劣化するより先に、行動として劣化します。こうした失敗は静かに蓄積し、最初に表面化するのはインシデントチケットではなく、ユーザーの不信です。シグナルがポストモーテムに届くころには、侵食（エロージョン）はすでに何週間も続いています。

4つ目は、自動化の影響範囲（ブラストレイディアス）です。従来のソフトウェアでは、局所的な欠陥は局所に留まります。しかしAI主導のワークフローでは、チェーンの初期で起きた1つの誤解が、ステップ、システム、そしてビジネス上の意思決定にまで広がって伝播します。コストは単に技術的なものに留まりません。組織的な問題になり、そして元に戻すのはとても難しくなります。

メトリクスは何が起きたかを教えてくれます。何が「ほとんど起きたか」は、めったに教えてくれません。

なぜ従来のカオスエンジニアリングでは不十分で、何を変えるべきか

従来のカオスエンジニアリングは、適切な種類の問いを投げます。「物事が壊れたらどうなる？」ノードを殺す。パーティションを落とす。CPUをスパイクさせる。観測する。これらのテストは必要であり、企業は実行すべきです。

しかしAIシステムの場合、最も危険な失敗は、ハードなインフラ障害によって引き起こされるわけではありません。失敗は、データ品質、コンテキストの組み立て、モデルの推論、オーケストレーションのロジック、そして下流のアクションの相互作用層で発生します。インフラに対して一日中ストレスをかけても、あなたにとって最もコストが大きい失敗モードを表面化させないことがあり得ます。

AIの信頼性テストに必要なのは、意図（インテント）ベースの層です。システムが「すべてが正しく動くときにどうあるべきか」だけでなく、「劣化した条件下で何をしなければならないか」を定義します。次に、その意図を揺さぶる特定の条件をテストします。検索層が技術的には正しいが6か月前の内容を返したらどうなる？ 要約エージェントが、上流で想定外のトークン膨張によってコンテキストウィンドウの30%を失ったら？ ツール呼び出しは構文としては成功するのに、意味的に不完全なデータを返したら？ エージェントが劣化したワークフローを通してリトライし、そのたびに自分自身の誤りを各ステップで増幅させてしまったら？

これらのシナリオは、エッジケースではありません。本番で起きている姿です。これは、企業向けインフラストラクチャのために信頼性システムを構築する際に私が適用してきた枠組みです。分散コンピューティング環境における意図ベースのカオスレベル作成です。重要な洞察はこうです。意図がテストを定義し、障害（ファルト）だけが定義するのではない、ということです。

インフラ層に実際に必要なこと

これらは何一つ、スタックを作り直す必要はありません。必要なのは、4つのことを拡張することです。

インフラのテレメトリに加えて、行動（behavior）のテレメトリを追加します。レスポンスが根拠付けられているか、フォールバック挙動がトリガーされたか、信頼度が意味のあるしきい値を下回ったか、そして出力が入ってきた下流のコンテキストに対して適切だったかを追跡します。これは、他のすべてを解釈可能にするオブザーバビリティ層です。

本番前の環境に、意味的なフォルト注入を導入します。意図的に、陳腐化した検索、コンテキスト組み立ての不完全性、ツール呼び出しの劣化、トークン境界の圧力をシミュレートします。目的は見世物のようなカオスではありません。目的は、ステージング環境よりも少しだけ悪い条件のときに、システムがどう振る舞うかを把握することです。もちろん、本番は常にそうした条件になりがちです。

展開の前に安全な停止条件を定義してください。最初のインシデントの後ではありません。AIシステムには、推論レイヤーにおける回路遮断器に相当するものが必要です。システムがグラウンディングを維持できない場合、コンテキストの整合性を検証できない場合、または信頼できるだけの十分な確信をもってワークフローを完了できない場合は、きれいに停止し、失敗を明示し、人間または決定論的なフォールバックへ制御を引き渡すべきです。円滑な停止は、ほとんどの場合、流暢なエラーよりも安全です。自信のある出力が正しさの錯覚を生み出すため、動き続けるように設計されたシステムがあまりにも多すぎます。

エンドツーエンドの信頼性について、共同の責任（シェアド・オーナーシップ）を割り当ててください。組織における最も一般的な失敗は、モデルチーム、プラットフォームチーム、データチーム、アプリケーションチームの間で、きれいに分離されてしまっていることです。システムが運用上は稼働しているのに挙動としては誤っている場合、誰もそれを明確に所有していません。セマンティックな失敗にはオーナーが必要です。オーナーがいなければ、失敗は蓄積します。

成熟のカーブが変わってきている

過去2年間、エンタープライズAIの差別化要因は導入でした――最も早く本番環境に到達できたのは誰か、ということです。このフェーズは終わりつつあります。モデルがコモディティ化し、ベースラインの能力が収束していくにつれ、競争優位は、よりコピーしづらい何かから生まれます。つまり、現実の条件、現実の結果のもとで、AIを信頼性高く大規模に運用する能力です。

昨日の差別化要因はモデルの導入でした。今日のそれはシステム統合です。明日のそれは、本番運用におけるストレス下での信頼性になるでしょう。

そこへ最初に到達する企業は、最も先進的なモデルを持っているわけではありません。彼らは、その周囲に最も規律あるインフラを持っています――本番環境で実際に直面する条件に対してテストされたインフラです。パイロットがうまく見えるようにした条件ではありません。

モデルだけがリスクではありません。モデルの周りにある、未検証のシステムがリスクです。

サイアリ・パティルは、AIインフラストラクチャおよびプロダクトのリーダーです。