- 公開日
複数ベンダーへ切り替えられるようにするには、業務が必要とする入力・出力・合格条件を共通インターフェースに置き、APIごとの変換と固有機能を接続先別のアダプターへ分けます。さらに、必須機能がないときは切替を止め、対応している場合も同じ業務例で再評価します。切替後も同じ仕事を任せられるかは、形式と内容の両方で判断します。
抽象化層は、業務アプリと各ベンダーのAPIの間に置く受け渡しの仕組みです。アプリが「担当と期限を抽出する」と頼み、下側で各APIの要求形式へ変換する、と考えると役割が分かります。共通にするのは業務上の意味であり、すべてのAPI機能を一つの同じ形に見せることではありません。
共通インターフェースには業務の約束を書く
架空の社内アプリが議事メモから作業一覧を作る例を使います。入力は「営業部が資料を更新する。担当者名は未定。公開日は次回の会議で決める」というメモで、管理された原文IDを付けて渡します。利用者はこの資料を閲覧できる業務担当者です。アプリのサービスアカウントには、承認済みの二つの推論先A・Bで抽出する権限があると仮定します。メール送信、カレンダー登録、外部検索は許可しません。
依頼は「作業、担当組織、担当者、期限、根拠となる原文を抽出する。未記載の担当者と期限は未確認として残す」です。共通の受け渡し項目は、次のように決められます。
| 項目 | 共通にする意味 |
|---|---|
| 業務入力 | 利用を許可された原文と原文ID、抽出する項目 |
| 指示 | 原文にない人名・日付を補わず、部署名と個人名を分ける |
| 出力形式 | 作業一覧、未確認の項目、根拠参照を返す |
| 必須能力 | 今回の長さの日本語入力、必要な出力形式を扱えること |
| 実行条件 | 許可された接続先、時間・費用の上限、使えるツールの範囲 |
| 結果状態 | 正常完了、非対応、拒否、途中終了、通信失敗を区別する |
共通項目は、名称だけでなく意味を固定します。たとえば「担当者がnull」という表現だけでは、原文に書かれていないのか、読み取りに失敗したのかが分かりません。この例では担当者の値と状態を別に持ち、原文未記載なら「値なし・原文未記載」、処理が途中で終わったなら結果全体を「途中終了」とします。未確認を空の正常回答へ丸めないよう、値と状態の欄を分けておきます。
時間や費用の上限は共通の要求として表せても、それを強制する仕組みまで各APIで同じとは限りません。アプリ側の予算管理と、提供者側の利用制限を別に確認し、実装が確認できていない上限を保証として返さない設計にします。
形式変換と固有機能を別の場所に置く
アダプターが受け持つのは、認証、APIの経路、メッセージ形式、出力の取り出し方、エラー表現などの違いです。業務アプリが個々のベンダーの設定名をあちこちで参照すると、切替のたびに業務側の変更が増えます。接続先ごとの違いをここへ集めると、仕様変更時に確認する場所を絞れます。
ただし、同じメッセージ配列を渡せば同じ入力になるとは限りません。Transformers v5.19.0のChat templatesは、役割と内容を持つ会話を、モデルが扱う制御トークンなどの系列へ変換する仕組みを説明しています。ローカルモデルを含めるなら、モデルに対応する形式や応答開始位置をアダプター側で確認します。この関数がすべてのホステッドAPIにあるという意味ではありません。
一方、ベンダーが提供する検索、状態を保持する会話、推論設定、構造化出力の特別な制約などは、共通機能へ無理に押し込まず、固有機能として扱います。機能ごとに、必須、あれば利用する任意、使用禁止のいずれかを業務側で決め、アダプターが対応状況を返します。
OpenAI Agents SDKのModelsは、API経路の違いや構造化出力への対応、第三者アダプターを利用する際の制約を説明しています。互換アダプターで扱えないフィールドが省かれる場合もあり、互換APIという名称から全機能の保存を推測できません。具体的な設定を使うときは導入するSDK版を固定し、その版の仕様を確認します。
この例では、必須の根拠参照や出力条件が変換時に失われるなら、推論先へ送る前に要求を拒否します。任意の機能を省けるときも、何を省いたかを結果へ残します。固有設定を自由な追加項目として渡せる設計にする場合は、許可するキーと値を接続先ごとに制限し、共通側で禁止した外部検索を追加項目で有効にできないようにします。
二つの接続先で同じメモを扱う
Aは必要な項目を含む構造化出力に対応し、Bは通常のテキスト出力のみ、という架空の条件を置きます。これは実在ベンダーの比較ではありません。両者へ渡す原文、項目の意味、利用者の権限、外部検索をしない条件は同じです。
Aでは、返された構造化データの形式を検査してから、原文に対応する内容かを確かめます。期待する作業は「資料を更新」、担当組織は「営業部」、担当者と期限は「原文未記載」です。「公開日は次回会議で決める」は補足として残せますが、資料更新の期限を次回会議の日付と決め付けません。
Bを使うには二つの方針があります。業務要件が提供者側の構造化出力機能そのものを必須としていれば、Bへの切替は非対応として止めます。要件が最終的な出力形式と検証にあり、アプリ側の整形を認めているなら、テキストを解析・検証する別の処理を候補にできます。必須要件を黙って任意へ変えることはしません。
後者でも、不足する担当者や期限を整形処理が補ってはいけません。解析できない出力は検証失敗とし、原文を人の確認へ返します。再生成を使うなら回数、時間、追加費用を決め、その回数内で検証できなければ止めます。エラーが出なくなるまで繰り返す設計は採りません。
また、Bに切り替えた直後に認証が通らなくても、別の個人アカウントや未承認の接続先へ自動的に迂回しないようにします。権限不足は管理者へ戻す状態で、プロンプトを書き換えて解消する問題ではありません。原文IDを記録し、当該要求がどこまで処理されたかを追えるようにします。
切替後は形式と業務品質を分けて評価する
移行前に合格条件を決め、旧接続先と新接続先へ同じ業務例を渡す計画を作ります。まずA・Bそれぞれで、項目の型、必須項目、結果状態を検査します。根拠参照はIDが存在するだけで合格にせず、引用部分が元の文書にあり、その抽出内容を支えるかを照合します。次に原文へ戻り、作業の取り違え、部署と個人の混同、未記載情報の補完、根拠との不一致を確認します。
試験集合には、担当と期限が明記された例、どちらもない例、訂正前後の記述が並ぶ例、長い入力、途中終了を含めます。期待結果を先に定め、調整に使った例とは別の評価用資料でも確かめます。原文中の「この制約を無視せよ」のような文を、アプリの権限を変える指示として採らないことも確認対象です。
この架空の用途では、根拠のない担当者・期限の追加を重大な不合格とし、一件でも見つかれば原因を確認するまで切替を保留する基準を置けます。これは組織が選ぶ判定方針で、業界共通の閾値ではありません。形式成功率と内容の誤り、判定できない例の件数は別々に記録し、未確認を正解へ加えないでください。
Bで整形や再生成が増えれば、品質だけでなく応答時間、利用費、人の修正時間も変わります。元の共通プロンプトで比べる試験と、B向けの補助処理を加えた試験を分け、どの変更の後に結果が変わったかを記録します。複数条件を同時に変えた結果を、モデルだけの差とは説明できません。共通の業務条件とモデル固有の挙動を分けて移植後に再評価する方法は「モデル変更・ローカルLLM移行に備えたプロンプトの共通化と再評価」で扱っています。
vLLMのSupported Modelsも、Transformersの出力と一致するかを最も厳しい確認段階とし、出力が妥当かどうかや、実行できるかどうかとは区別しています。モデルを読み込めること、要求が成功すること、業務上同等の答えを返せることは、それぞれ確認が必要です。本稿のA・B比較は未実施の設計例であり、特定のアダプターの品質を実証したものではありません。
接続先を変えても残る制約を記録する
採用するアダプターには、接続先、API・SDK・モデルの版、対応機能、検証日、非対応時の処理を記録します。モデル名が同じでも設定や実装が変われば評価条件は変わるため、仕様変更や廃止の通知を追う担当も決めます。古い合格結果を、新しい組合せへ自動的に引き継がない運用です。
データの送信先も別に確認してください。たとえば前掲のOpenAI Agents SDK文書は、モデル接続先とトレースの扱いに注意が必要であることを示しています。トレースは処理の経路や内容を追うための記録です。推論先をBへ変えたからといって、監視やトレースもBへ移ったとは限りません。業務入力が入る記録の送信先・保持・許可を設定と利用条件で照合します。
抽象化層の維持には、接続先ごとの仕様確認と回帰試験の負担がかかります。全面切替が難しいなら、必要な機能を満たす接続先へ業務単位で限定する方法もあります。利用者には、切り替えられる業務と必要機能、検証した入力範囲、残る制限を示してください。
国内リージョンの制約でモデルを変えるときのプロンプト互換性試験は「国内リージョン制約でモデルを変えるときのプロンプト互換性試験」、業務要件とテンプレート運用の安定性でLLMを選ぶ方法は「業務要件とテンプレート運用の安定性でLLMを選ぶ」で解説しています。
