AI機能は、モデルを更新しただけなのに別の挙動まで変わることがあります。原因はコードのバグとは限りません。データ、評価、利用者の行動が絡み合うためです。
Googleの研究者らは2015年、この性質をCACE（Changing Anything Changes Everything：何かを変えると、すべてが変わる）と呼びました。10年以上前の論文ですが、ツールや記憶まで持つ生成AIエージェントを設計する今こそ、読み直す価値があります。
CACE原則とは何か
通常のソフトウェアでは、部品の境界を明確にすれば変更影響を局所化できます。しかし機械学習では、入力特徴の分布を1つ変えるだけで、残りの特徴の重みや使われ方まで変化し得ます。
論文は、CACEが入力データだけでなく、ハイパーパラメータ、学習設定、サンプリング方法、収束条件、データ選択など、ほぼあらゆる変更に及ぶと説明しています。つまり「モデルの差し替え」は、部品交換というより、車両全体の再適合に近いのです。
コードレビューだけでは見えない4つの負債
- データ依存：入力元の定義や生成方法が変わると、コードが同じでも挙動が変わります。
- 隠れたフィードバックループ：AIの出力が利用者や別システムの行動を変え、その結果が次の学習データへ戻ります。
- パイプライン・ジャングル：データ加工や接続の継ぎ足しが増え、全体像と変更影響が追えなくなります。
- 設定の負債：特徴量、しきい値、前処理、モデル版などの組み合わせが増え、設定自体が巨大な仕様書になります。
厄介なのは、これらがコンパイルエラーにならないことです。システムは動き続けながら、精度や安全余裕が静かに劣化します。
生成AIエージェントでは依存先がさらに増える
ここからは私の考察です。生成AIエージェントでは、モデル以外にもプロンプト、ツール定義、検索データ、記憶、権限、停止条件が出力を左右します。どれか1つを改善したつもりでも、別のタスクで悪化する可能性があります。
たとえばツール説明を詳しくすると、呼び出し精度が上がる一方、コンテキストを圧迫して長文タスクの品質が下がるかもしれません。記憶検索を増やせば継続性は上がりますが、古い情報を拾う確率も上がります。CACEは、LLM時代にもそのまま通用します。
PLが先に用意すべき3つの仕組み
- 依存関係をバージョン管理する：モデル名だけでなく、プロンプト、データ、ツール定義、評価セットを一組で記録します。
- 変更前後を同じ評価で比べる：平均点だけでなく、安全性、失敗率、応答時間、コストも回帰確認します。
- 本番の静かな劣化を監視する：入力分布、欠損率、ツール失敗、利用者の修正回数などを継続観測します。
Googleは2017年の別論文で、本番MLシステム向けに28項目のテストと監視ニーズを提示しました。また公式ガイド「Rules of Machine Learning」は、複雑なモデルより先に、堅牢なパイプライン、測定可能な目的、独立して試験できるインフラを整えるよう勧めています。
まとめ
AIの技術的負債は、ソースコードの行数では測れません。データとシステムの結びつきに隠れています。
だからAI開発では、「モデルが良くなったか」だけでなく、何を変えたら、どこまで再検証するかを先に設計する必要があります。CACEを前提にすれば、変更管理はブレーキではなく、安心して改善を続けるためのテストコースになります。