【ITニュース解説】Moving Off OpenAI: What an Open-Weight Switch Costs

近年、AI技術の発展は目覚ましく、特にOpenAIが提供するような最先端のAIモデルは多くのサービスで利用されている。しかし、ここ数年でOpenAI以外の「オープンウェイトモデル」と呼ばれるAIモデルも大きく進化し、その品質は一般的な業務においてOpenAIと遜色ないレベルに達してきた。さらに、これらのモデルはOpenAIよりも低価格で利用でき、中にはモデルそのものをダウンロードして自社で運用できるものも登場している。これにより、AIモデルの提供元（サプライヤー）との関係性が変わり、OpenAIからの切り替えを検討する企業が増えている。

しかし、AIモデルの切り替えは単に利用するAPIを変えるだけで済むほど単純ではない。APIの呼び出し方自体はOpenAIと互換性がある場合が多いが、その周辺には多くの作業が隠れている。

まず、切り替え時にそのまま利用できる部分について説明する。多くのオープンウェイトモデルは、OpenAIと互換性のあるインターフェースを提供しているため、既存のプログラムコード（クライアントライブラリ、リクエストの形式、ストリーミング処理など）は大きく変更することなく利用できる場合が多い。また、AIモデルへのアクセスを管理する周辺のシステム、例えば、認証情報を保管するプロキシ、リクエストを一時的に溜めておくキュー、エラー発生時の再試行ロジック、利用状況を記録するログシステムなどは、利用するAIモデルに依存しないため、基本的にそのまま利用可能だ。ただし、もし開発時に特定のベンダーのクライアントプログラムをコード全体に直接組み込んでいる場合は、修正が必要となる。さらに、AIが情報を検索する際の仕組み、具体的には、テキストをAIが理解できる数値表現に変換する「埋め込み」データ、それを保存する「ベクトルストア」、そして長いテキストを扱いやすい大きさに分割する「チャンキング」といった戦略は、AIモデルの切り替えとは独立しているため、そのまま利用できる。ただし、新しいモデルの処理できる文字数（コンテキストウィンドウ）が大きく異なる場合は、チャンクサイズの見直しが必要になることもある。

次に、切り替え時に問題になりやすい点、つまり「静かに壊れる」部分について説明する。最も大きな問題は、AIに指示を出す「プロンプト」の移植性だ。プロンプトは、特定のAIモデルの言葉遣いやフォーマット、知らないことに対して「知らない」と答える傾向といった「癖」に合わせて、無意識のうちに調整されていることが多い。そのため、別のAIモデルに同じプロンプトを使っても、技術的には正しい出力が得られても、言葉の多さやフォーマット、あるいは回答のスタイルが期待と異なる結果になることが頻繁に発生する。新しいAIモデルに合わせてプロンプトを再調整する作業が、移行作業の大部分を占めると考えてよい。

また、AIに特定の構造（例えばJSON形式）で出力を求める場合、新しいモデルがそのスキーマ（データ構造の定義）をどれだけ厳密に守るかを確認する必要がある。モデルによっては、指定された形式を完全に保証しないものもあり、その場合、不正確な形式のデータが出力され、後続の処理でエラーを引き起こす可能性がある。

AIが外部のツール（例えば検索エンジンや計算機）を呼び出す機能（ツール・関数呼び出し）についても、呼び出しの形式自体は標準化されていても、その信頼性、複数のツールを連続して呼び出す能力、そして適切なツールがない場合の挙動はモデルによって異なる。AIが複数のステップで自動的にタスクをこなす「エージェント」のような複雑なワークフローでは、これらの細かな違いが複数のエラーを引き起こす原因となりやすい。

さらに、AIモデルの「推論の挙動と課金」にも注意が必要だ。一部のAIモデルは、最終的な回答を生成する前に内部で複雑な推論プロセスを行い、その推論にかかったトークン（情報量の単位）も出力トークンとして課金される場合がある。見かけ上の利用料金が安くても、このような推論が常に最大努力で行われるモデルでは、実際には元のモデルよりも高額な費用がかかる可能性があるため、料金モデルを事前に十分に理解することが重要だ。

AIモデルが不適切だと判断する内容の「安全性と拒否の境界線」も提供元によって異なる。現在利用しているモデルで問題なく処理できていたコンテンツが、新しいモデルでは「不適切」と判断されて拒否されたり、逆に現在のモデルで拒否されていたものが新しいモデルでは許容されるといったケースがある。特に、医療、法律、金融、またはコンテンツモデレーション（内容審査）に関わるアプリケーションでは、顧客から指摘される前に、この点を具体的にテストして確認する必要がある。

AIモデルを公平に比較するためには、ベンダーが公開しているベンチマーク（性能評価指標）だけでは不十分だ。自社の状況に合わせた評価方法を構築する必要がある。まず、本番環境のデータから、普段の運用で発生する多様なケースや、少し扱いにくいケースを含む30〜100程度の実際の入力データを収集し、それぞれの入力に対する「正しい」出力例を記録する。次に、比較対象の各AIモデルに対して、それぞれのモデルの特性に合わせてプロンプトを個別に調整した上でテストを実行する。同じプロンプトを使い回すのは、プロンプトの移植性の低さを示すだけで、公平な比較とは言えない。

評価する項目としては、以下の4つが挙げられる。一つ目は「出力品質」で、これは自社の基準で判断する。二つ目は「総コスト」で、推論にかかるトークンも含めた実際の費用を確認する。三つ目は「遅延（レイテンシ）」で、ユーザーが実際に感じるレベルでの遅延（例えば上位95%のユーザーが体験する遅延）を測定する。そして四つ目が「失敗のパターン」で、これは最も重要でありながら見落とされがちな項目だ。例えば、平均的な出力品質がわずかに劣っていても、決して不正な形式の出力をしないモデルの方が、自動化されたシステムにおいてはより良い選択となる場合がある。これらの評価を行った後、実際のユーザーからのアクセスの一部を新しいAIモデルに送り、その応答は使わずに、実際の運用環境での挙動を1週間程度比較する「シャドウデプロイメント」を実施するとよい。これにより、テスト環境では見つけにくい、様々な稀なケースや長期的な問題を特定できる。

OpenAIからの移行による費用削減が本当に見込めるかどうかは、ワークロードによって大きく異なる。大量の定型的な作業（例えば、情報の分類、抽出、要約、リクエストのルーティングなど）がある場合、これらのタスクは必ずしも最先端のAIモデルの能力を必要とせず、頻繁に実行されるため、トークンあたりのコスト差が累積して大きな費用削減につながる可能性が高い。これが移行の最も強力な根拠となり、通常、移行にかかるエンジニアリングコストを正当化できる。一方で、利用頻度の低いインタラクティブな機能の場合、数千件の会話を月に処理するようなサポートアシスタントでは、コスト差が小さく、移行にかかるエンジニアリング工数の方が、年間で削減できる費用を上回る可能性がある。前述したように、推論トークンが常に出力として課金されるモデルでは、見かけの低料金が相殺され、費用削減が幻想となる場合もあるため、実際のプロンプト長を考慮して慎重に費用を試算する必要がある。

金銭的なメリット以外にも、AIモデルをダウンロードして自社で運用できるという点は、将来的な「出口戦略」となり得る。もし現在の提供元が利用しているモデルのサポートを終了したり、契約期間中に料金を変更したり、自社の運用に合わないレート制限を課したりした場合でも、別の選択肢があるというのは非常に価値がある。

多くの場合、最適な答えは「一つのAIモデルに固定するのではなく、複数のモデルを状況に応じて使い分ける」というものだ。これを「切り替え」として捉えるのは間違いであり、複数のAIモデルを一つのインターフェースの背後で使い分けることが、最も効果的な戦略だ。

例えば、大量に発生する定型的な作業は、評価をクリアした中で最も安価なモデルに振り分ける。長い文脈を処理する能力が必要なタスクや、AIが自動的に複数のステップで作業を進めるエージェント的なタスクは、それらを最も得意とするモデルに送る。そして、最高の回答が必要で、コストが最優先ではないごく一部のリクエストには、最先端のモデルを温存しておくといった使い分けが可能だ。

また、データの内容によってもルーティングを分けることができる。例えば、自社の管理下から出してはいけない機密情報を含むリクエストは、自社でホストしているモデルに処理させ、それ以外の一般的なリクエストは外部のAPIを利用するといった方法だ。AIモデルへのアクセスを統一的に扱う「抽象化レイヤー」を事前に構築しておくことで、アプリケーション側はどのAIモデルが使われているかを意識することなく、これらの振り分けを柔軟に行うことができる。これにより、将来的にAIモデルを変更する際も、設定の変更だけで済むため、変更コストを大幅に削減できる。

最後に、OpenAIからの移行を「しない方が良い」ケースについても触れておく。まず、AIモデルの利用頻度が低い場合、移行にかかるエンジニアリングコストが、得られる費用削減効果を上回ってしまうため、移行は適切ではない。その時間は、アプリケーションの機能開発に使うべきだ。次に、現在のAIモデルにしかない独自の機能に強く依存しており、代替のモデルではその機能が提供されていないことが、実際にテストで確認されている場合も移行すべきではない。単なる思い込みではなく、具体的な検証が重要だ。また、安全性が非常に重視されるアプリケーションで、現在の提供元の安全基準が自社の要件に完全に合致しており、実際に十分なテストを通じてそのことが確認されている場合も、安易な移行は避けるべきだ。その信頼関係を別の提供元で再構築するには、大きなコストと時間がかかる。

そして、最も重要なこととして、もしAIモデルを評価する仕組み（評価ハーネス）がまだない場合、まずはそれを構築すべきだ。評価仕組みがないまま移行すると、AIの出力品質が低下しても、顧客からの指摘があるまで気づけないという事態になりかねない。評価ハーネスは、移行するかどうかにかかわらず、長期的なAIモデル運用において非常に有用なツールとなる。