- 公開日
国内リージョン制約で利用モデルが変わったら、地域要件への適合と、業務プロンプトの互換性を別々に判定します。許可された地域で使えるモデルと機能を確定し、変更前後で同じ業務例を用いて、入力を受け取れるか、必要な処理ができるか、出力が業務の合格条件を満たすかを確認します。
文章が前と一字一句違っていても、業務に必要な条件が保たれていれば互換性を満たせる場合があります。たとえば要約なら、重要な事実、例外、未確定事項、根拠参照が保たれているかが判断対象です。先に維持すべき意味と形式を決めておくと、文体の違いだけで不合格にしたり、流暢さだけで誤りを見逃したりすることを避けられます。
国内リージョンの名称から機能を推定しない
ここでは、原文と回答の保存・推論を日本国内に限定するという、架空の社内要件が既に承認されていると仮定します。なぜその要件が必要かという判断は済んでおり、試験の担当者が品質を理由に緩めることはできません。これは実在の法令がすべての企業へ課す義務を述べたものではありません。
確認する単位は、サービス、契約・プラン、モデルの版、API、配置方式、リージョン、利用機能の組合せです。同じモデル名でも、別の地域や配置方式で同じ機能を使えるとは限りません。カタログに載っていることと、自社アカウントで使えることも別に確認します。利用資格、利用量の割当て、実際の配置設定を記録してください。
2026年10月27日に確認したMicrosoftの地域別提供一覧では、Standard/Regionalのjapaneastにgpt-4.1-miniの2025-04-14版が掲載されています。同文書はこの配置方式でのプロンプトと応答の処理を配置リージョン内と説明しています。ただし、この記載だけで個別API機能、利用枠、監視、バックアップ、契約適合まで確認したことにはなりません。GlobalやData Zoneの表と混ぜないことも必要です。
また、OpenAI APIのData controlsでは、同確認日のJapanは保存対応と処理対応が異なり、ProcessingはNoです。この資料の対象はAPIであり、ChatGPT全プランの説明ではありません。地域設定には対象エンドポイント・モデル等の条件や米国外の追加要件があり、system dataや第三者サービスも同じ保証に含まれるとは限りません。「Japanを選べる」という理由だけで、国内推論必須の試験対象へ採用しないでください。
これらは候補を絞るための仕様確認です。実際の移行では、Azure販売モデルのデータ保護説明などの対象範囲と、自社の契約・設定・経路を照合します。検索、文字認識、ログ、トレース、障害時の切替も追い、該当する国内要件を満たせない経路は修正または保留にします。本文で挙げた実在モデルの導入や試験は行っていません。
変更前後の構成を一枚の記録にする
試験の開始時に、旧構成Aと国内条件へ移す候補Bについて、次の情報を残します。Bが公式一覧に載っていても、未確認欄を合格へ置き換えないでください。
| 記録するもの | 照合する資料・設定 | 未確認・不一致なら |
|---|---|---|
| モデル・版・配置方式・地域 | 提供一覧、実デプロイ設定、利用枠 | 候補を絞り直すか提供者へ確認する |
| 入力形式と長さ | 対象APIの仕様、文書変換の設定 | 対応形式へ変換する案を別条件にする |
| 必須機能 | 構造化出力、検索、画像、ツール等の対応 | 必須なら停止し、代替を使う場合は別構成にする |
| データ経路 | 契約、設定、保存先、通信・運用の記録 | 当該情報を流さず、経路適合を保留する |
| 業務の出力契約 | 項目、型、根拠、許容する未確認表示 | 合格条件を業務責任者と確定する |
| 比較を再現する条件 | プロンプト版、入力集合、生成設定、評価基準 | 記録不足の比較を採用根拠にしない |
ここでいう出力契約は、業務アプリが受け取るデータの約束です。項目名だけでなく、「未確認」と「対象外」をどう表すか、途中終了した結果を通常の回答として渡してよいかまで決めます。地域の変更に合わせてモデル、API、前処理を同時に変更すると、差の原因が追いにくくなるため、変更点は一つずつ記録します。
旧構成が新しい国内要件を満たさなくなった場合は、比較のために本物の機密データを送り直してはいけません。利用が認められた過去の記録を使うか、情報分類上その経路で使えると確認した架空資料で比較します。旧環境を試せない場合は、その制約を残し、新構成が業務基準を満たすかを単独で評価します。比較不能を理由に地域要件を回避しない運用です。共通の業務条件とモデル固有の挙動を分けたプロンプトの作り方は「モデル変更・ローカルLLM移行に備えたプロンプトの共通化と再評価」で扱っています。
同じ資料から期待結果を先に作る
以降は、社内の機器貸出ルールを要約する架空の業務例です。担当者が閲覧権限を持つ資料だけを渡し、AIは案内文を下書きします。申請の登録や承認は行いません。地域経路の確認とは別に、次の短い資料を品質試験の入力にします。
- P1：通常の貸出は、利用開始の5営業日前までに申請する
- P2：緊急の貸出は担当窓口へ相談し、対応可否の確認を受ける。相談しただけでは貸出確定にならない
- P3：貸出期間の延長案は次回会議で審議する。新しい期間と適用日は未決定
依頼は「通常と緊急の手続きを分け、申請期限、必要な確認、未決定事項を示してください。各説明へ根拠のページを付け、資料にない日付や承認結果は補わないでください」とします。差し替えるのは原文と原文IDで、通常・例外を区別し未決定を残す条件は固定します。回答後は、ページの内容と各主張を照合します。
期待する出力は、通常では「5営業日前」、緊急では「担当窓口の確認が必要で未確定」、延長案では「審議予定、期間・適用日とも未決定」です。「5日前」と営業日の条件を落とす、「相談すれば借りられる」と確認を省く、会議日を適用日へ変える出力は不合格にします。実際の日付を計算させる場合は、営業日カレンダーなど別の入力と基準が必要です。
期待結果は旧モデルの回答をそのまま正解にして作りません。原資料と業務責任者の判断から作り、旧構成にも同じ採点をします。旧構成に誤りが見つかっても、それを新構成に再現させる必要はありません。
入力・機能・内容を分けて試験する
まず、P1〜P3の同じテキストをAとBへ渡す比較を設計します。原文、指示の意味、根拠ID、出力項目、許可範囲を固定し、変えるのは対象モデルと接続に必要な変換です。API固有の設定を同じ値にできない場合は、その差も記録し、同じ数値であることを同じ生成条件と決め付けません。
次に、実際の業務に近い文書を通して、読み取りから出力までを評価します。テキスト比較と文書全体の比較を分けるのは、文字認識の失敗をモデルの要約能力の差と混同しないためです。たとえば画像化されたP2の「確認を受ける」が欠落すれば、回答の不備は入力段階から始まっています。原画像、抽出テキスト、モデルへ渡した内容を照合します。
| 試験ケース | 期待結果・確認方法 | 不合格・未確認時の対応 |
|---|---|---|
| P1〜P3をそのまま入力 | 通常・緊急・未決定を区別し、ページと意味が一致 | 原文、指示、出力のどこで条件が失われたか調べる |
| P3の適用日を質問 | 未決定と答え、日付を創作しない | 日付補完を重大な誤りとして切替を保留する |
| 旧版と新版が混在 | 版と適用条件を照合し、決められなければ保留 | 新しいファイル名だけで採用せず原本管理を確認する |
| P2が画像のみ | 例外条件を読み取るか、読み取れない範囲を示す | 国内条件を満たす文字認識か、人の転記へ切り替える |
| 長い資料で途中終了 | 未完了を表示し、欠落した例外を含む回答を確定しない | 分割・取得範囲を見直し、再評価する |
| 許可されないツールを要求 | 操作せず、案内文作成の範囲を維持する | 権限設定と呼出し境界を確認する |
| 文書内に指示の書換え要求 | 資料の文字として扱い、業務指示を変更しない | 正当な要約も不必要に止めていないか別に調べる |
この表は未実施の試験計画です。通信失敗や権限不足を与えるケースは、承認された試験環境で外部への副作用を起こさない方法を選びます。拒否の文章が出たかに加えて、禁止された操作が発生していないかを実行記録で確認する設計にしてください。
文書内の不正な指示を見つけた結果、許可された要約まで止めるなら、それは危険な操作の阻止とは別の問題です。不正な指示を含む場合の過剰な停止と、普通の資料を誤って危険と判定する場合も区別します。安全性と業務継続を一つの成功率へまとめると、どの修正が必要かが見えにくくなります。
機能が足りない場合は、代替処理を新しい構成として評価する
国内候補Bで必要な機能が使えない、または対応を確認できない場合は、代替処理と残る制約を並べます。以下は設計上の選択肢であり、特定製品で実装済みの機能表ではありません。
画像入力に対応しない場合は、国内条件を満たす文字認識処理を前段へ置くか、人が転記します。その場合は、図表の対応、読めない箇所、ページ位置が失われる可能性を評価し、画像を直接理解したという説明をしません。前段サービスにも保存・処理・監視の経路確認が必要です。
構造化出力が使えない場合は、テキスト出力をアプリ側で解析し、項目・型・根拠を検証する案があります。ただし、業務が提供者側の制約機能自体を必須としているなら、その代替では要件を満たしません。認められる場合も、解析不能は失敗として返し、欠落項目を推測で埋めないようにします。再生成の回数や費用も、変更前と同じ前提で比較します。
外部検索や長い会話状態を引き継げない場合は、承認済み資料を明示的に渡す、必要な履歴を整理して渡す、といった方法があります。その代わりに資料の鮮度管理や履歴の条件確認を自社が引き受けます。引き継げなかった権限や以前の承認を、モデルに推測させる設計にはしません。
OpenAI Agents SDKのModelsも、接続経路の互換性と個々の機能対応を区別しています。アダプターを使った結果、非対応の項目が省かれたまま呼び出しだけ成功する可能性を点検します。必須機能が失われるなら事前に止め、任意の省略なら利用者が分かる結果として残してください。具体的な挙動は導入するSDK・アダプターの版で確認します。
代替処理を追加したBは、元のBとは評価条件が違います。まず元のプロンプトでの結果を残し、次に修正版や前処理を加えた結果を別に記録します。地域、モデル、文字認識、プロンプトが同時に変わった比較から、品質差の原因をモデルだけに帰属させないことが必要です。
集計では「未確認」を成功に含めない
試験用の資料は、修正に使う集合と、合否を見るために残す独立した集合に分けます。失敗するたびに評価用の全問へ合わせてプロンプトを直すと、見たことのない資料でも条件を保てるかを確かめにくくなります。通常、例外、未決定、長文などの区分を両方へ含め、資料の重複やほぼ同じ文面の混入も確認します。
説明用に、独立した24ケースの結果を集計すると仮定します。内容の判定ができた20ケースのうち正しいものが17、誤りが3、残る4ケースは資料不足などで判定できないとします。この数字は測定結果ではありません。全24ケースに占める確認済みの誤りは3÷24＝12.5％、判定できた20ケースに占める誤りは3÷20＝15％、未確認は4÷24で約16.7％です。最後の割合は小数第1位に丸めています。
未確認4ケースが正しいとは分からないため、12.5％を全体の誤りの完全な把握と説明できません。形式不正、タイムアウト、地域経路の確認不足も、それぞれ別の状態として残します。形式に合っていても「緊急なら確認なしで借りられる」と出したものは、内容の合格にはできません。
変更前後の比較では、同じケースが両側で評価できたかも示します。Aだけで結果があるケースを含む全体平均と、A・Bの両方で判定できたケースの比較は分け、不足した結果を黙って除外しません。
同じ入力を繰り返す試験では、ケース数と実行回数も分けます。24ケースを3回ずつ試す計画は72回の実行に当たりますが、独立した72種類の業務資料を調べたことにはなりません。応答が得られなかった回は、その状態を残します。ケースごとの揺れを見たいのか、資料の種類を広げたいのかに合わせて計画し、失敗した応答だけを都合よく集計から外さないでください。
品質だけでなく、応答時間、再生成回数、利用費、人の修正時間を同じ範囲で記録します。前処理や再試行を加えた案で、モデルの応答時間だけを比較すると、業務全体の待ち時間を過小に扱います。平均値だけでなく遅いケースや途中終了の件数を見て、繁忙時にも許容できるかを確認します。ここで一律の性能閾値は置かず、業務の許容範囲を試験前に決めます。
二つの判定をそろえて移行を決める
最終記録では「地域要件への適合」と「業務互換性」を別欄にします。地域要件が不適合または未確認なら、品質が良くても、その要件がかかる情報の本番利用は保留です。地域が適合していても、営業日の条件や緊急時の確認を落とすなら、その用途では切替できません。
架空の貸出案内なら、重大な条件の欠落を一件でも確認したら修正後に再評価する、未確認ケースが残る入力区分は利用対象から外す、といった判定を事前に置けます。これはこの業務で選ぶ方針です。対象外とした区分を人へ回せるか、全体の目的を果たせるかも責任者が判断し、除外したケースを隠して全面互換と報告しません。
両方の基準を満たした構成について、対象業務、モデル・API・配置の版、プロンプト、検証資料、結果、代替処理、利用から外した範囲を保存します。機能の廃止、モデル更新、経路変更、プロンプト修正があれば、影響する項目を再試験します。障害時に旧環境へ戻す手順も、現在の地域要件を満たすときだけ選べます。戻せない場合は、国内条件を満たす別構成か人の作業へ引き継ぐ計画を用意してください。
LLMを複数ベンダーへ切り替えるための抽象化層の作り方は「LLMを複数ベンダーへ切り替える抽象化層の作り方」、国内リージョン固定が必要な業務でのモデルとデータ経路の選び方は「国内リージョン固定が必要な業務で、モデルとデータ経路を選ぶ」で解説しています。
