何が起きたか

2025年初頭にClaude Sonnet 3.5で構築された自然言語からAPI呼び出しを生成するシステムが、Sonnet 4.5へのアップグレード後に動作不良を起こしました。VentureBeatのゲスト投稿で報告された事例です。

このシステムはアナリストや営業担当者の質問を、description・api_call・post_bodyの3フィールドを持つJSONに変換し、Salesforceや社内ポータルと連携。2025年半ばには月数百件のレポートを生成する基幹ツールに育っていました。3.7、4.0へのアップグレードは無事通過したものの、4.5で2つの致命的な失敗が発生します。

第一に、モデルがpost_bodyの内容をdescriptionフィールドに混入させ、本来のpost_bodyが空になる現象。結果、フィルタ条件がAPIに届かず全期間・全地域のデータが返るか、500エラーが発生しました。第二に、構造化JSONを返すべき場面で4.5が確認質問を返すケース。システムは「必ずAPI呼び出しが返ってくる」前提だったため処理不能に陥りました。

なぜ重要か

筆者らはLLMシステムが「無限のブラスト半径」を持つと指摘します。モデルのバージョンアップは差分更新ではなく、機能の丸ごと置換だからです。

ポストモーテムで判明したのは、プロンプトに「descriptionは自然言語の文字列であり、他フィールドの直列化表現を含んではならない」と明示していなかったこと。旧モデルは文脈から暗黙に推論していましたが、4.5は別の解釈を選びました。

提案される解決策

筆者らは「評価スイート（Evals）こそがシステムの正式な仕様書」であり、プロンプトは実装、モデルはインタプリタにすぎないと主張します。evalは入力・満たすべき性質・採点関数の三つ組で表現され、本番トラフィックからの回帰テスト生成やLLM-as-judgeによる定性評価も可能です。

ただし課題も明確です。evalは構築・維持コストが高く、製品変更に伴いドリフトし、何より「仕様化された失敗モード」しか捕捉できません。今回も「descriptionにcurlコマンドが入るはずがない」というアサーションを誰も書いていませんでした。

💼 事業会社視点：これは自社にどう効くか

日本企業の事業責任者は何を準備すべきか

LLMを業務に組み込むSaaS事業者、社内BI/レポーティング自動化を進める大企業の情シス部門、生成AI受託開発のSIerにとって、これは「他人事ではない運用リスク」の典型例です。

特に注視すべきは、月数百件の業務利用に耐えていたシステムが、マイナーバージョンアップ一発で壊れたという事実。日本企業でよくある「PoCを本番に昇格させたが、CI/CDに乗っていない」「プロンプトの仕様書がエンジニアの頭の中にしかない」状態は、同じ落とし穴に直結します。

経営者が今日決めるべきは3点です。第一に、自社のLLMアプリで「モデル差し替え時の受け入れ基準」が明文化されているかの監査。第二に、評価データセット構築をプロンプトエンジニアリングと同格の投資対象として予算化すること。第三に、本番トラフィックのログを匿名化して回帰テスト資産に変換する仕組みを整えること。受託開発側は「プロンプト納品」から「Evalスイート込み納品」への契約書ひな形変更が、差別化の打ち手になります。