AIは従来のアプリケーションのように振る舞わない。状態を持たない処理ではなく、文脈を蓄積しながら振る舞いが変化する。検索や推論の経路も固定ではない。モデルの更新やデータの変化で、出力そのものが変わる。結果として、システムの振る舞いは時間とともに変化する。

　問題は、この違いを無視したまま運用を続けることだ。顧客対応や業務判断にAIが関与し始めると、「モデルドリフト」（誤答や性能低下、時間の経過とともにデータが現実の状況を正確に反映しなくなること）が業務に直結する。にもかかわらず、従来の監視指標では異常を検知できない。コストも説明しにくい。

　従来のクラウドは決定論的なロジックに基づいて動作する。入力と処理が決まれば、出力は安定する。一方AIは、「進化するシステム」だ。推論の過程に検索や文脈依存を含む。ベクトル検索や知識ストアへのアクセスによって、結果は変化する。

　この違いが、3つの構造的な問題を生む。1つ目は、状態の蓄積だ。検索結果や推論履歴が、次の出力に影響する。2つ目は、評価の継続性だ。モデルドリフトや誤答を検知するには、継続的な評価が必要になる。3つ目は、ガバナンス領域の拡大だ。複数のデータを横断するため、出所や権限の管理が不可欠になる。

　ここで迷うのは、「どこまでをインフラとして扱うか」だ。AIをアプリケーションの一部と見なすのか、それとも独立した基盤と見なすのか。この判断を誤ると、監視も制御も不十分になる。

よくある誤判断とその結果

　典型的なのは、検証環境と本番環境を分離しないケースだ。実験用の評価パイプラインが本番推論に影響する。テスト用モデルが意図せず反映される。結果として、出力品質が突然変わる。

　もう1つは、コスト管理の誤りだ。従来はトラフィック量でコストを予測できた。だがAIは、文脈長や検索深度、モデル選択でコストが変動する。推論1回ごとのコストが不透明になりがちだ。結果として、月額費用が急増する。クラウド運用のようには理由を説明できない。

　さらに、ハイブリッド環境での状態管理も問題になる。検索基盤が複数環境に分散し、同期が取れない。規制や遅延の制約も加わる。結果として、出力の一貫性が失われる。

どうすればいいのか

　判断の分岐は明確だ。AIを「ワークロード」として扱うか、「インフラ」として扱うかだ。前者を選べば短期での導入は容易だが、運用段階で破綻する。後者を選べば初期段階の負荷は高いが、長期的な制御が可能になる。

　検討に当たっては、データの出所管理、推論経路の可視化、ポリシーの動的適用、継続評価の仕組み、出力の制御機構が判断材料になる。これらを統合した「制御スタック」が必要だ。

　AIの導入は一気に完成形に到達するものではない。多くの企業は、3つの段階を経て進化する。

　まず第1段階は「アプリ内AI」だ。既存システムに機能として組み込む形で導入する。チャットbotや検索支援などが該当する。この段階では、従来のクラウド設計でも運用できる。だが、AIの挙動はブラックボックスになりやすく、品質やコストの変動に気付きにくい。

　次に第2段階は「プラットフォーム統合AI」だ。検索基盤（RAG）や評価機構を組み込み、複数の業務でAIを横断的に利用する。この段階では、状態管理が不可欠になる。どのデータを参照したか、どの経路で推論したかを把握できなければ、出力の説明責任を果たせない。ここで従来設計の限界が顕在化する。

　そして第3段階が「監視型AIインフラ」だ。AIを業務基盤として扱い、挙動を継続的に監視・制御する。専用の制御プレーンを設け、ポリシー適用やコスト管理、異常検知を横断的に実施する。この段階では、AIはもはやアプリケーションではなく、運用対象そのものになる。

　問題は、この進化を前提に設計していないケースだ。初期段階の延長で拡張すると、途中で制御不能になる。特に第1段階の設計を引きずったまま第2段階に進むと、状態やコストが可視化できず、運用が破綻する。

　つまり問われているのは、「今どの段階にいるのか」と「次の段階に進める設計になっているか」だ。AIを後付けの機能として扱うのか、それとも最初から基盤として設計するのか。この判断が、将来の運用負荷と説明責任の大きさを決定する。