【2026年7月版】

AIエージェント時代の「作らない技術」(2) ― 本家に振り回される実装

公開日: 2026/07/25
読了時間: 約 13分

第1回では、生成AIブーム初期のサービスの多くが本家の標準機能へ吸収されていく事例を紹介した。そのなかで、依存していたAPIが変わったり廃止されたりするたびに、実装が負債になっていくことにも軽く触れた。第2回では、その実装の側をさらに詳しく扱う。AIの上に築いたものがなぜ長くもたないのかを、具体的なメカニズムに分けて説明する。

古くなるのか、消えるのか

一般的なアプリケーション開発において、旧APIやライブラリが非互換・非推奨とされてから廃止されるまで、たいてい数年はかかる。新しいWebフレームワークが出ても、古いフレームワークで作ったアプリケーションはすぐには止まらない。データベースにいたっては、製品やAPIのライフサイクル寿命は極めて長い。数十年前のSQL言語や設計が、いまも現役で使われている。

AIでは事情が違う。土台にしたAPIが変われば動かすために直しを迫られ、廃止されれば作り直すか捨てるしかない。モデルが一段賢くなれば、プロンプトそのものだけでなく前処理、後処理、補正、分割、再試行、選択ロジックなどの前後の処理がまとめて変わってしまう。さらに、解決すべき問題そのものが消え、処理が丸ごといらなくなる。新しいライブラリが古いものを置き換えるのとは、話の次元が違う。こうした形が、少なくとも三つある。

APIはある日まるごと廃止される

提供終了そのものは、AIに限らない。AWSのようなクラウドサービスにも、API廃止の予定は存在する。ただ、そちらは数年がかりで、頻度も低い。AIモデルは違う。公開から一年ほどで次の世代に置き換わり、そのまま終了していく。公開と終了が、短い周期で入れ替わり続ける。

Anthropicの例は分かりやすい。2024年3月のClaude 3 Opusは2026年1月に、2024年6月のClaude 3.5 Sonnetは2025年10月に終了した。初期のモデルは、それでも一年半から二年はもった。しかし新しい世代ほど、その間隔は縮んでいる。2025年2月公開のClaude 3.7 Sonnetは2026年2月に、2025年5月のSonnet 4とOpus 4は2026年6月に終了し、2025年8月のOpus 4.1は2026年8月に終了が予定されている。いずれも、公開からおよそ一年だ。GoogleのGemini APIも同じく、モデルごとの非推奨化と停止日を公開しており、停止後はエンドポイントそのものが利用できなくなる。

あるモデルを選んだら数年そのまま使える、という前提はもう通らない。モデルIDを書き換えるだけで移行できる場合もあるが、応答傾向、思考方式、ツール利用、対応パラメータが変われば、プロンプト、評価、テスト、エラー処理まで見直すことになる。

実際に世代交代では、パラメータの前提が変わる。Anthropicの現行モデルでは、適応的思考(adaptive thinking)が標準になり、従来の手動指定であるbudget_tokensは指定するとエラーになる。temperatureなどのサンプリングパラメータも非デフォルト値を送るとエラーになる。昨日まで有効だった細かな最適化が、翌世代では受け付けられない設定になる。AI開発では、APIを使い始めた瞬間から移行計画が必要になる、と考えておくのが安全だ。

賢いモデルが周辺コードを消す

以前のLLMは、決められたJSON形式を安定して返せなかった。そのため開発者は、JSON部分を正規表現で抜き出す、Markdownのコードフェンスを除去する、壊れたJSONを修復する、必須項目がなければ再質問する、列挙値が不正なら補正する、パースに失敗したら別のプロンプトで再実行する、といった処理を書いた。

しかし、各社は構造化出力を提供するようになった。OpenAIのStructured OutputsはJSON Schemaへの適合を保証する機能として提供され、strictモードでの評価ではスキーマ適合率100%を報告している。もちろん内容の正しさまで保証されるわけではない。それでも、「モデルが壊れたJSONを返す」という前提で組み上げたパーサー、修復器、リトライ制御の多くは、モデル側機能によって価値を失った。

同じことはツール呼び出しにも起きている。以前はモデルに「使用するツール名と引数を次の形式で出力せよ」と指示し、文字列を解析して関数を呼び出していた。現在では各社が構造化されたツール呼び出しをAPIの基本機能として提供している。自作のツール選択構文やパーサーは壊れていないのに不要になる。

広がるコンテキスト、縮む長文処理

長い文書やコードベースをLLMへ渡すため、多くのシステムが複雑な処理を実装してきた。固定長チャンクへの分割、意味単位の分割、階層的要約、要約の再要約、ベクトル検索、リランキング、会話履歴圧縮、関連部分の動的選択、古い履歴の削除。

これらがすべて不要になったわけではない。大規模データ、検索精度、コスト、アクセス権限を扱う場合には依然として必要だ。しかし、モデルのコンテキスト長が数十万から数百万トークンへ広がると、小規模な文書集合や一つのリポジトリに対して、複雑なRAGを先に構築する必要は薄くなる。

Anthropicは2026年のClaude Opus 4.8について、標準で100万トークンのコンテキストと最大12万8千トークンの出力を案内している。Gemini APIも数百万トークンの長文入力を主要機能として示している。半年かけて階層要約システムを作っている間に、全文をそのまま投入したほうが安く、簡単で、高精度になる可能性がある。

とはいえ、RAGを捨てろという話ではない。順序が逆なだけだ。まず全文入力で試し、精度やコストで問題が測れたところにだけ、必要なRAGを足していく。先回りして大掛かりなRAG基盤から始めるから、多くが無駄になる。

技術的な「座礁資産」

技術的負債は通常、短期的な便宜のために設計品質を犠牲にし、後で修正費用を払う問題として説明される。しかし、AI分野で起きることは少し違う。丁寧に設計しても、十分なテストを書いても、公式の推奨方式に従っても、土台のAPIやモデルの変化しだいで、実装は動かなくなるか、要らなくなる。

これは設計の善し悪しとは別の話だ。外部環境が進歩し、投資した技術の経済的・実用的な価値そのものが失われていく。技術的負債というより、「技術的座礁資産」(座礁資産:stranded asset、金融の用語で、規制・技術・市場といった外部環境の変化により、想定していた寿命より前倒しで価値を失った資産のこと。)と呼ぶほうが近い。

モデルが長文を読めないために作った要約階層は、モデルが全文を読めるようになれば不要になる。
JSONを正しく返せないために作った修復器は、構造化出力が安定すれば不要になる。
ツールを選べないために作ったルールエンジンは、モデルのツール利用能力が向上すれば不要になる。
モデルが高価だから作ったルーターやキャッシュは、同等性能のモデル価格が下がれば投資を回収できない。

価格の下落も速い。一定の能力水準あたりの推論価格は年々大きく下がり続け、分析によっては年に数分の1というペースの試算もある。API料金を数千円節約するために作った最適化基盤が、完成する前に、最適化対象の価格そのものが消えていることさえある。

コードは動き、テストも通る。それでも使う価値が消失する。これがAI時代の座礁資産だ。

AIには延ばせない実装の寿命

従来なら非推奨から廃止まで数年あった猶予が、いまは数か月から一年しかない。AIがコードを書くことで、作るのは速く安くなった。だが、生成が安くなったぶん、短命な実装をより多く抱えることになる。効いてくるのは、速く作る力ではなく、何を作らずに済ませるかの判断だ。

次回(第3回)は、それでも作るときの工程を扱う。使い捨てのコードは、もう人ではなくコーディングエージェントが「ループ」の中で書く。