閉じた境界の中の LLM:規制対象企業が選べるものと、それぞれの選択にかかるコスト

要件は一文でやってくる。文書を境界の外に出してはならない、と。アーキテクチャの判断はその中に隠れている。境界を引ける場所は三つあり、どこに引くかによって、それを引いた企業が負うコストが変わるからだ。

モデルプロバイダーのホスティング型 API では、境界はそのプロバイダーとの契約の中にある。クラウドプラットフォームのマネージドモデルサービスでは、境界はクラウドの契約の中にある。あなたが運用するサーバー上のオープンウェイトモデルでは、境界はあなた自身のネットワークの中にあり、本来ならプロバイダーが担うはずの務めがすべてあなたに回ってくる。

選択肢を比べる前に、境界が何を禁じているかを書き出す

「境界の外に出せない」という言葉は、リスク管理の担当者、データ保護責任者、インフラチームにとって、それぞれ別のことを意味する。問いの形で書き出すと、各選択肢をそれに照らして確認できる要件になる:

• 社外の誰がプロンプトと出力を見てよいか。不正利用がないかを確認するプロバイダーのスタッフも含めて
• データをどのリージョンで処理してよいか。保存する場所だけでなく
• リクエストの後に何を保持してよいか、その期間はどれくらいか、そして誰が削除できるか
• 暗号化されていても、トラフィックが公衆インターネットを通ってよいか
• 暗号鍵と、誰が何にアクセスしたかを証明するログを、誰が保持するか
• 外部プロバイダーの利用によって、どの契約、登録簿、監査が必要になるか

答えはデータの区分によって異なりうる。すでに公開されている規制関連の通知と、顧客の身分証明書類とでは、同じ境界は必要ない。パイプラインは両者を別々のルートに振り分けることができる。

選択肢1:プロバイダーのホスティング型 API ― 境界は契約の中にある

ここでは、プロバイダーの契約とドキュメントが境界を定める。だからそれらを一行ずつ読むことになる。OpenAI の API データに関するドキュメントは、2023年3月1日以降、顧客がオプトインしない限り、API に送られたデータは同社のモデルの学習や改善に使われないと述べている。同じページは、プロンプトとレスポンスを含みうる不正利用監視のログがデフォルトで生成され、最大30日間保持されると述べている。ただし、より長い保持が法律で求められる場合や、サービスまたは第三者を危害から守るために合理的に必要な場合は、この限りではない。

どちらの範囲も絞り込めるが、その絞り込みはどれも、設定ではなく承認によって行われる:

• Zero Data Retention（データ保持ゼロ）または Modified Abuse Monitoring（不正利用監視の変更）は、OpenAI が顧客を承認すると、顧客コンテンツを不正利用監視のログから除外する。ドキュメントが対象外としているエンドポイントは、それでもアプリケーションの状態を保持することがあり、その一部は削除されるまで保持する。また OpenAI は、書面による通知をもって特定のモデルを対象外とする権利を留保している
• データレジデンシーはプロジェクトごとに設定するか、リクエストごとに選択する。利用資格は営業チームに確認し、米国以外のリージョンではいずれも、不正利用監視の管理機能に対する承認と Modified Retention amendment（保持条件を変更する契約修正）が必要になる
• データレジデンシーは、保存時の顧客コンテンツを選択したリージョンに置く。推論もそこで行われるのは、ドキュメントがリージョン内での処理に対応していると示しているリージョンに限られる
• データレジデンシーはシステムデータ、つまり顧客コンテンツを含まないアカウントデータ、メタデータ、利用データを対象にしておらず、これらは選択したリージョンの外で処理・保存されることがある
• 同じページは、2026年3月5日以降にリリースされた対象モデルについて、データレジデンシーのエンドポイントには10%の割増料金がかかると述べている

モデルもまた、プロバイダーのスケジュールに左右される。OpenAI の非推奨化（deprecations）のページは、安全性やコンプライアンス上の懸念からより早いスケジュールが必要な場合を除き、提供終了までの最短の通知期間を示している。一般提供モデルは少なくとも6か月、その特化型バリアントは少なくとも3か月、プレビューモデルはそれよりはるかに短く、たとえば2週間である。提供終了のたびに、その日までに後継モデルをあなた自身の文書で採点する必要がある。だから移行はインシデントではなく、繰り返し発生する計画的な作業になる。

選択肢2:あなたのクラウドプラットフォームのマネージドモデルサービス

クラウドプラットフォームは複数の開発元のモデルを提供しており、その一部は、企業がすでに結んでいるかもしれないクラウド契約のもとで提供される。Microsoft Foundry で Azure が販売するモデルについて、Microsoft のドキュメントは、プロンプト、補完、埋め込みを OpenAI やそれらのモデルのほかのプロバイダーが利用することはできないと述べている。同じカタログには、Microsoft が販売しないモデルも並ぶ。Microsoft Foundry の Claude モデルについて、そのドキュメントは Anthropic を販売者、運営者、そしてプロンプトと出力に関する独立したデータ処理者と位置づけており、ホスティングの選択肢の一つでは、それらを Anthropic のインフラ上で処理する。その場所は、選択した Azure リージョンの外である可能性がある。

Amazon Bedrock のドキュメントは、各リージョンにモデルプロバイダーごとのモデルデプロイアカウントがあると説明している。このアカウントは Bedrock のサービスチームが所有・運用し、モデルプロバイダーはアクセスできない。そのため、プロバイダーが顧客のプロンプトや補完を目にすることはない。

それでもモデルが動くのは、あなた自身のネットワークではなく、クラウドが運用するインフラの上である。境界によってはこれも内側とみなされるが、三つ目の選択肢しか内側とみなされない境界もある。内側とみなされる場合、境界はテナント内で行う選択に左右され、ドキュメントはその帰結を具体的に説明している:

• 推論が実行される場所:Azure では、Global と名の付くデプロイの種類ではモデルがデプロイされているあらゆる地域で、Data Zone の種類ではデータゾーン内で、地域ベースの Standard または Provisioned の種類では顧客が指定した地域内で、プロンプトとレスポンスが処理されうる。いずれの場合も、保存データは顧客が指定した地域にとどまる
• 使えるモデル:Microsoft は、新しいモデルはまず Global Standard で提供が始まり、Data Zone やリージョン単位のデプロイの種類には後から提供され、すべてのデプロイの種類で提供される保証はないと述べている
• バージョンの寿命:Azure は一般提供モデルの提供終了日をリリースから18か月後に設定し、12か月の時点で新規顧客への提供を締め切る。Anthropic、DeepSeek、Fireworks、Mistral AI の一般提供モデルは12か月のライフサイクルに従う。また Microsoft は、通知期間を短縮した緊急の提供終了を行う権利を留保している
• トラフィックがモデルに届く経路:Amazon Bedrock はランタイム API 向けに、AWS PrivateLink を介したインターフェイス VPC エンドポイントをサポートしている。そのため、あなたの VPC からの呼び出しは、インターネットゲートウェイもパブリック IP アドレスも必要とせずにモデルに届く
• 誰がコンテンツに不正利用がないかを確認するか:Azure では、Limited Access（制限付きアクセス）の追加の利用資格基準を満たす顧客は、不正利用監視の変更を申請できる。承認されると、プロンプトと補完は人によるレビューのためには保存されなくなるが、自動のレビューは引き続き行われることがある

DORA の適用対象である EU の金融事業体にとって、クラウド契約はそれ自体がすでに ICT サードパーティとの取り決めである。2025年11月18日、欧州監督当局（European Supervisory Authorities）は、EU レベルの監督の対象となる重要な ICT サードパーティプロバイダーのリストを公表し、そこには Amazon Web Services EMEA、Google Cloud EMEA、Microsoft Ireland Operations が含まれている。欧州銀行監督機構（European Banking Authority）は、DORA が2025年1月17日に適用開始となったこと、そしてその適用対象の事業体は ICT サードパーティサービスプロバイダーとの契約上の取り決めについて登録簿を維持しなければならないことを指摘している。したがって、その事業体がこれまで契約したことのないモデルプロバイダーも、すでに結んでいるクラウド契約のもとでの新しいサービスも、アーキテクチャだけでなく、その登録簿の問題でもある。

選択肢3:あなたが運用するインフラ上のオープンウェイトモデル

オンプレミスであれ、あなた自身のクラウドアカウント内の仮想マシンであれ、セルフホストは推論を内側に取り込む。それは、プロバイダーが担っていた務めをすべて一緒に引き受けることでもある。最初の務めはライセンスを読むことだ。オープンウェイトモデルに共通のライセンスがあるわけではないからである。Mistral Small 3、Qwen3-32B、OpenAI の gpt-oss-120b は、Apache 2.0 のもとで Hugging Face に公開されている。Meta の Llama 3.3 Community License は、以下でハードウェアを見積もる Llama 3.3 70B モデルに適用され、その利用が利用規定（acceptable use policy）に従うことを求めている。さらに、リリース日の前の暦月に、関連会社のものを含めて自社の製品またはサービスの月間アクティブユーザーが7億人を超えていたライセンシーには、ライセンスを申請することを求めており、Meta はその独自の裁量によってライセンスを付与することができる。

ハードウェアはパラメータ数と精度から決まる。Llama 3.3 70B Instruct のパラメータ数は約706億である。パラメータあたり16ビットでは、重みだけで約141 GB（131 GiB）を占め、同時リクエストの key-value キャッシュ用にメモリを確保する前の段階ですら、80 GB のアクセラレータ1基には収まらない。gpt-oss-120b のモデルカードは、mixture-of-experts（混合エキスパート）の重みを MXFP4 で量子化することで、このモデルを単一の 80 GB GPU で動かせると述べている。

サービングレイヤーが、あなたのセキュリティ境界になる。vLLM のセキュリティドキュメントは、マルチノード構成におけるノード間の通信はデフォルトでは安全ではなく、ノードを分離されたネットワークに置いて保護しなければならないこと、そして API キーのオプションが保護するのは特定のパスプレフィックス配下のエンドポイントだけであり、同じサーバー上のほかの機微なエンドポイントには認証がないことを述べている。モデルファイルもまた、サプライチェーンの一部である。Python のドキュメントは、pickle モジュールは安全ではなく、悪意ある pickle データは unpickle の際に任意のコードを実行しうると警告している。だからこそ、pickle とは異なりテンソルを安全に保存するために作られた safetensors 形式が、重みにとってより安全な選択肢となる。

いまや企業が自ら運用するもの:

• ピーク時の量に合わせて見積もり、需要に先立って購入または予約したアクセラレータのキャパシティ。故障したノードの分の余裕も持たせる
• ドライバ、サービングエンジン、オペレーティングシステム。セキュリティと受け入れスコアの双方が許すスケジュールでパッチを当てる
• ネットワークの分離、モデルサーバーの前段での認証、そして監査人が読めるアクセスログ
• モデルのアップグレード:新しいオープンウェイトモデルが本番に届くのは、誰かがあなたの文書でそれを採点し、リリースしたときだけである
• モデルサーバーのオンコール。どのプロバイダーのステータスページも、それを対象にしていないからだ

コンプライアンスの証拠:それぞれの選択肢で監査人が求めるもの

GDPR 上の義務、そして企業が ISO/IEC 27001 の認証を受けている場合は同規格のもとでの義務も、どの選択肢を選んだとしても、またプロバイダーがその企業の処理者として行動する場合であっても、企業自身のものであり続ける。変わるのは、証拠がどこから来るかである:

• ホスティング型 API:プロバイダーのデータ処理条件、保持とレジデンシーの管理機能に対する承認、その再委託先、そして DORA の適用対象である金融事業体であれば、その取り決めの登録簿への記載
• マネージドモデルサービス:モデルデプロイごとのデプロイの種類とリージョン、プライベートエンドポイントの設定、不正利用監視について承認された変更があればその内容、そしてクラウドの既存の保証報告書が新しいサービスを対象範囲に含んでいるかどうか
• セルフホストのモデル:モデルサーバーとその周辺すべてについての自前の証拠。ネットワークの分離やアクセスログから、本番で使う各モデルのライセンスと各重みファイルの来歴まで。サーバーがクラウドアカウント内の仮想マシンであれば、既存のクラウドとの取り決めもこれに加わる

三つのどれでも、パイプラインが実行中に、どのデプロイ、リージョン、モデルが各文書を処理したかを記録していれば、証拠は安く済む。監査のために後から集めるなら、同じ証拠も再構成の作業になる。

レイテンシとスループット:共有のキャパシティか、自前のキャパシティか

共有のキャパシティでは、スループットの上限は他者のポリシーで決まる。OpenAI は、1分あたり・1日あたりのリクエスト数とトークン数で測るレート制限を課している。OpenAI は利用額の増加に応じて組織を自動的に上位の利用ティアに移し、それによって通常は制限が引き上げられる。また、制限の範囲内であっても、増え方が急すぎるトラフィックを減速させることがある。Microsoft は、プロビジョニング型のデプロイの種類ではスループットが保証され、レイテンシのばらつきが小さくなる一方、標準の種類はベストエフォートであると述べている。

予約済みキャパシティには、それ固有の条件が付く。Amazon Bedrock の Provisioned Throughput（プロビジョンドスループット）は、コミットメントなしで購入することも、1か月または6か月の期間で購入することもでき、その期間中は削除できない。Microsoft は、PTU クォータも予約も、リージョン内のキャパシティを保証するものではないこと、そしてプロビジョニング型のデプロイを削除またはスケールダウンするとそのキャパシティは解放され、同じキャパシティが後で利用できる保証はないことを指摘している。OpenAI は、トラフィックが日常的にランプレート制限に達するエンタープライズ顧客に対し、より予測可能なキャパシティのために Scale Tier を、GPT-5.6 以降のモデルについては Reserved Tier を案内している。

誰も結果を待っていない仕事には、そのキャパシティは必要ない。OpenAI の Batch API は、非同期のリクエストを50%低いコストで、24時間のターンアラウンドで処理する。ただし、OpenAI のデータに関するページは、バッチとファイルのエンドポイントを Zero Data Retention の対象外としており、それらのデータは削除されるまで保持される。Azure は、50%の割引が適用されるバッチ用のデプロイの種類を挙げている。そのうち Global Batch はモデルがデプロイされているあらゆる地域で処理することがあり、Data Zone Batch はトラフィックをデータゾーン内のデータセンターにのみ振り向ける。

自前のキャパシティでは、外部のレート制限も共有のキューもなく、上限は購入または予約したハードウェアで決まる。どの選択肢でも、出力の長さは効いてくる。OpenAI のレイテンシガイドは、トークンの生成をほぼ常に最もレイテンシの大きいステップだとし、一般的な経験則として、出力トークンを50%減らせばレイテンシも約50%減りうると述べている。したがって、散文ではなく簡潔な構造化レコードをモデルに求めることは、三つのどれでも役に立つ。

人員配置:それぞれの選択肢で、誰がオンコールを担うのか

選択肢ごとに違うのは、社内に残る仕事のリストである:

• どの選択肢でも:パイプラインそのもの、その受け入れスコア、そしてそれを運用する担当者
• ホスティング型 API:ベンダー管理、保持とレジデンシーの承認、レート制限を踏まえた計画、そしてプロバイダーの提供終了スケジュールに合わせた移行
• マネージドモデルサービス:クラウドについての同じ仕事に加え、リージョンごとのデプロイの種類、クォータ、予約済みキャパシティ、そしてプライベートネットワークの構成
• セルフホストのモデル:アクセラレータのインフラ、サービングエンジン、セキュリティパッチの適用、モデルのアップグレード、そしてパイプラインが稼働している時間すべてをカバーするオンコール

パイロットならオンコールなしで何か月も動かせるが、本番はそうはいかない。運用する人員を含めずにセルフホストの選択肢を見積もると、モデルのコストとサービスの価格を比べることになる。

選択肢の併用はルーティングのルールであり、難しいのはそのルールのほうだ

選択肢は排他的ではない。パイプラインは、公開文書をホスティング型のモデルに送り、制限付きの区分をセルフホストのモデルにとどめることができる。ただしそれが成り立つのは、ルーティングがコードで強制され、証拠を残す場合に限られる:

• 分類はモデルを呼び出す前に行い、分類できない文書は最も制限の厳しいルートを通す
• ルートごとに、専用の認証情報を持つ別々のデプロイにする。制限付きのルートには、外部モデル用の認証情報も、外部モデルへのネットワーク経路もない。そのため、誤ったルートに振り分けられた文書は、境界の外に出る代わりに処理が失敗して止まる
• すべてのルートを同じ受け入れセットで採点する。一つのパイプラインに二つのモデルがあれば、品質の水準も二つあることになるからだ
• 通ったルートを文書ごとにログに記録する。どのプロバイダーがどの文書を処理したかという監査の問いに、記録から答えられるようにするためだ

閉じた境界が、あなたの代わりにモデルを選んでくれるわけではない。境界が選ぶのは、どの仕事があなたの手元に残るかである。契約を読み込んで承認を待つことか、適切なリージョンでキャパシティを予約することか、それともサーバーを運用し、夜中にアラートで起こされることか。

これをあなたの境界の内側で構築する会社は、まず境界について尋ねる

この記事の背景にある問いは、どのエンジニアリング会社が、オンプレミスやプライベートクラウドで、クライアント自身の境界の内側に LLM による文書とチケットの処理を構築しているのか、というものだ。会社同士の違いは、モデルを提案する前に何を尋ねるかに表れる:

• パイプラインがどの区分のデータを扱い、それぞれについて境界が何を禁じているかを、あなたのリスク管理チームとデータ保護チームが使う言葉で尋ねる
• すでにどのクラウド契約、リージョン、承認済みのプロバイダーを持っているか、そして新しい用途を DORA が求めるような登録簿に記載する必要があるかを尋ねる
• 最大のモデルが勝つと決めてかからず、少なくとも二つのデプロイの選択肢を、あなた自身の文書で、同じ受け入れセットを使って比べる
• ホスティング型のどの選択肢についても、保持、レジデンシー、提供終了の条件を、それを読んだ日付とともに引用する
• セルフホストの場合は、計測したトークン量からハードウェアを見積もり、誰がサーバーにパッチを当て、誰がオンコールに就くかを名指しする
• 各文書を処理したデプロイ、リージョン、モデルのバージョンを、パイプラインがどう記録するかを示す

これらの点を尋ねる前にモデルを推薦する会社は、そうとは言わないまま、あなたの境界を選んでしまっている。

デプロイの判断は、文書の区分ごとに、あなたの会社がどの仕事を担う用意があるかに行き着く。契約と承認か、リージョン内のキャパシティか、サーバーとオンコールか。

上の要約で述べた本番のインテグレーション以外に amBrain が公に裏付けられること:amBrain は2019年からソフトウェアを作ってきた。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。