9月21日、David Linthicumが「The quiet rise of AI technical debt」と題した記事を公開した。企業がAI導入を加速させる中で静かに蓄積されていく「AI技術的負債」の実態と、CIOが今すぐ取るべき対策について詳しく論じた内容だ。
27バリアントに分裂したAIアシスタント
記事は、著者が匿名で紹介する製造業企業「Northbridge」の事例から始まる。
調達チームがサプライヤー契約の要約・更新日検出・リスク条項フラグ立てを行うAIアシスタントを構築した。実用的で範囲も絞られており、パイロットは成功。CIOも喜んで成果を披露した。
ところがそこから要望が殺到する。法務部門は独自バージョンを要求し、財務は支払い条件と紐づけた要約を求め、コンプライアンスは地域ごとのポリシーチェックを追加し、営業は顧客契約への同パターン適用を求めた。各チームがプロンプトを調整し、検索ソースを追加し、例外ルールを設け、微妙に異なるシステムへ接続した。
1年後、Northbridgeには同一パターンのAIが27バリアント存在していた。 それぞれが独自のプロンプト、データソース、アクセスルール、モデル選択、評価ロジック、障害モードを持つ状態だ。モデルをアップグレードした際にどのワークフローが影響を受けるか誰も把握できず、要約文にハルシネーション（幻覚）——AIモデルが事実と異なる情報を自信を持って生成してしまう現象——が混入しても、原因がモデルなのかプロンプトなのか検索レイヤーなのか元文書なのかトレースできなかった。
AIの技術的負債は「従来型」と何が違うか
技術的負債自体は新しい概念ではない。Linthicumは「クライアント・サーバー、Webアプリ、SOA、クラウドと、35年間同じパターンを繰り返してきた。今度はAIで、しかも恐ろしい速さで起きている」と述べる。
従来の技術的負債はコード・インフラ・アーキテクチャに宿る。AIの技術的負債はプロンプト、エンベディング、ベクターデータベース（テキストや画像を数値ベクトルとして格納し意味的な類似検索を可能にするデータベース）、ファインチューニングの判断、学習データ、アクセスポリシー、評価セット、ワークフローの前提、モデル依存関係に宿る。 しかもその多くはノートブック、ベンダーツール、ローコード環境、部門実験、シャドーAIワークフローの中に散らばり、ソフトウェアのように管理されていない。
記事が特に強調するのは、この点だ。
「カスタマーサポートワークフローを動かすプロンプトは、単なるプロンプトではない。それはビジネスロジックだ。コンプライアンスアシスタントに情報を供給する検索パイプラインは、単なる実験ではない。それは情報のサプライチェーンだ。」
最悪の負債は技術ではなく「オーナーシップの不在」
パイロットが政治的成功を収めた瞬間、ハードコードされた回避策がアーキテクチャになり、サンプルデータのパスがデータ戦略になり、プロンプトライブラリが事実上の共有ビジネスロジックになる。「金曜日のデモに間に合わせるため」に取った近道が、そのまま本番環境に昇格する。
Linthicumは自身の経験も明かす。90年代にRAD（ラピッドアプリケーション開発）でモックアップを作り、「後でちゃんとする」と言い続けたまま本番リリースし、そのシステムが今も稼働しているという。「3週間で下した判断の利息を、その後3年かけて払い続ける」という構図は、AIでも同じだと指摘する。
そしてこの問題の核心に、オーナーシップの不在がある。規制が変わったときプロンプトを誰が管理するか。ビジネスプロセスが変わったとき検索ソースを誰が検証するか。モデルプロバイダーがアップデートを出した後、出力品質を誰がモニタリングするか。ハルシネーションが欠陥なのか学習問題なのかデータ品質問題なのか許容リスクなのか、誰が判断するか。
多くの企業では、答えは「誰もいない」だ。
こうして負債は複利で膨らむ。チームがチャットボットを作り、別チームがコピーし、ベンダーがSaaSに同機能を埋め込み、従業員がコンシューマーツールで非公式ワークフローを作り、セキュリティチームが承認されていないシステムを流れる機密データを発見する。CIOが全体像を把握したとき、企業にあるのはAIアーキテクチャではなく「AIのガラクタ引き出し」だ。
過大評価されているものと、本当に重要なもの
Linthicumは三点を「市場が過大評価している」と断言する。
- モデル選択：どのモデルが今四半期わずかに優れているかの議論に時間を使いすぎている
- エージェントフレームワーク：共通ポリシー・オブザーバビリティ・ロールバック機構なしに各部門が自律的アクションをビジネスシステムへ接続すれば、負債を除去するより増やす
- **AIセンター・オブ・エクセレンス**：標準とパターンを定義できても、ビジネスがワークフローを所有し、ITがプラットフォームを所有し、運用上の結果を誰も所有しなければ、善意のミュージアムになる
本当に重要なのは地味な話だ。共有アーキテクチャパターン、再利用可能なデータコントラクト、評価の規律、ライフサイクル管理、明確な意思決定権限。 派手なキーノートにはならないが、トラブルを回避できる。
CIOが今すぐ取るべき3つのアクション
プロンプト、検索パイプライン、評価セット、モデル設定をエンタープライズ資産として扱う。 バージョン管理、オーナー、レビュー、廃止ルールが必要だ。ビジネス成果に影響するなら、インフォーマルな成果物ではない。
すべてのAIパイロットに、実験フェーズを超える前に本番移行計画の提出を義務付ける。 誰が運用するか、どのデータに依存するか、品質をどう計測するか、モデルが変わったらどうするか——答えられないチームはスケールする準備ができていない。
AIデット（負債）レジスタを構築する。 アプリケーション合理化、クラウド支出、セキュリティ例外、レガシーリスクと同様に、モデル・プロンプト・データソース・インテグレーション・エージェント・ビジネスオーナーをカタログ化し、重複・未管理・安全でないものを特定する。
記事は次の言葉で締めくくられる。「AIで勝つ企業は、パイロットが最も多い企業ではない。AIを印象的なデモの連続ではなく、長期的なアーキテクチャとして管理することを学んだ企業だ。負債は必ず返済期限が来る。AIでは、ほとんどのCIOが思うより早く請求書が届く。」
詳細はThe quiet rise of AI technical debtを参照していただきたい。
