API か、セルフホストか、ハイブリッドか:規制対象企業は LLM による文書処理をどう動かせるのか、そして誰がそれを本番に導入するのか

規制対象企業が LLM による文書処理を動かす方法は、契約のもとでプロバイダーの API を使うか、自社のサーバーで動かすか、その二つを組み合わせたハイブリッドにするかである。どの区分の文書も契約のもとで外に出してよいなら API を使い、一つも出せないならセルフホストにする。ハイブリッドが割に合うのは、両側にそれぞれ多くの文書がある場合だけだ。二つのシステムを運用し、ルーティング表にも責任を持つことになるからである。こうしたシステムを本番に導入したことのある会社を見分けるには、そのシステムが残す記録を見せてもらう。

三つの方式はどう違うのか

これらは、上でリンクした閉じた境界についての記事が詳しく比べている。プロバイダーの API の場合、データを守るのは契約と、プロバイダーが約束するデータ管理の仕組みである。2026年10月8日に閲覧した OpenAI のデータ管理（data controls）のページによれば、2023年3月1日以降に同社の API に送られたデータは、オプトインしない限り学習に使われない。

同じページによれば、OpenAI が不正利用の検知に使い、プロンプトとレスポンスを含みうる不正利用監視のログは、デフォルトで最大30日間保持される。法律が求める場合や、OpenAI のサービスまたは他者を危害から守るために合理的に必要な場合は、それより長く保持される。自社のコンテンツをこのログから外すには、OpenAI の事前の承認が要る。

クラウドプラットフォームのマネージドモデルサービスでは、クラウド事業者があなたに代わってモデルを動かし、その一部のモデルは、すでに結んでいるかもしれないクラウド契約のもとで販売されている。Microsoft のドキュメントによれば、Azure が販売するモデルについては、プロンプトとモデルの回答を OpenAI やそれらのモデルのほかのプロバイダーが利用することはできない。Amazon Bedrock のドキュメントによれば、モデルプロバイダーは顧客のプロンプトとモデルの回答にアクセスできない。それでもモデルはクラウドのサーバー上で動く。それを自社の境界、つまり自社が管理するネットワークとシステムの内側とみなすかどうかは、リスク管理チームが決める。

セルフホストのオープンウェイトモデル、つまり開発元が誰でもダウンロードして動かせるように公開しているモデルは、自社が管理するサーバー上で動くので、文書がモデルプロバイダーに渡ることはない。その代わり、サーバーとモデルの運用は自社のチームの仕事になる。

ハイブリッド構成は実際にはどういう形になるのか

ハイブリッドは、外部のルート（プロバイダーの API またはクラウドのマネージドサービス）と内部のルートを一つのパイプラインにまとめる。各文書の行き先を決めるロジックはルーターと呼ばれる。基本的な設計は三つあり、組み合わせることもできる:

• 公開済みの規則やガイダンスのような公開文書やリスクの低い文書は API に送り、顧客の本人確認書類は内部にとどめる
• すべての文書をまずセルフホストのモデルに送り、そこで処理できなかった文書は、その区分が許す場合に限って外に出す
• 名前などの識別子を、テキストを API に送る前に、境界の内側でプレースホルダーに置き換える

どの文書を API に送ってよいかは誰が決めるのか

決めるのはリスク管理またはデータ保護の担当で、エンジニアリングがその決定をコードに落とし込む。まずは短い表として紙に書く。ここではそれをルーティング表と呼ぶ。この表には、文書の区分ごとに、許されるルート、マスキングが必須かどうか、プロバイダーがテキストをどれだけの期間保持してよいかを書く。

次に、パイプラインは各文書の区分を割り出さなければならない。自社が管理できるシグナルのほうが、モデルの判断より安全である。文書が届いた経路、送り手、文書の種類がそれにあたる。シグナル同士が食い違えば、より厳しい区分を採り、誰も分類できない文書は内部にとどめる。

この判定は境界の内側で行う。文書を外に出してよいかを外部の API に尋ねる判定は、その時点で文書をすでに送ってしまっている。ルーティング表の変更は、ほかのコード変更と同じくレビューを通し、バージョン番号と日付を付ける。

テキストをマスキングすれば、それでも API に送れるのか

場合によっては送れるが、限度がある。Presidio のようなオープンソースのツールは、名前、口座番号などの識別子をプレースホルダーに置き換えるか、鍵で暗号化する。鍵を内部に置いておけば、回答が戻ってきたときに Presidio の復号のステップが本来の値を元に戻す。プレースホルダーを使う場合は、どのプレースホルダーがどの値を表すかの対応表を自分で持つ。このようにマスキングしたデータは、仮名化されたデータと呼ばれる。

欧州データ保護会議（European Data Protection Board）は2025年1月16日、仮名化に関するガイドライン 01/2025 を、パブリックコンサルテーション用の版として採択した。ガイドラインによれば、追加の情報によって特定の人物と結びつけられるなら、そうしたデータは引き続き個人データにあたる。さらに、マスキングしたテキストとその情報が別々の当事者のもとにある場合、たとえばプロバイダーがテキストを持ち、自社が対応表や鍵を持つ場合でも、このことは変わらないとしている。

EU 司法裁判所は2025年9月、EU の機関に適用されるデータ保護規則のもとで争われた C-413/23 P 事件で、同じ問題を取り上げた。判決は、仮名化されたデータがあらゆる場合に、また誰にとっても個人データであるわけではないとした。状況によっては、マスキングによって、データをマスキングした企業以外の者がそこに含まれる人物を特定できなくなることがある。対応表や鍵を持つ自社にとっては、そのデータは個人データのままである。自社の契約にとって何を意味するかは、データ保護を担当する法律顧問に確認する。

二つ目の限度は検出である。Presidio は、人名、地名、組織名を見つけるモデルと、口座番号のような既知の形式に一致するルールとで、個人データを見つける。そのドキュメントは、検出が自動で行われるため、「Presidio がすべての機微な情報を見つけるという保証はない」と述べている。文書を扱う仕事での典型的な見落とし:

• スキャン画像をテキストに変える光学文字認識（OCR）が名前を読み違え、検出器がそれを名前と認識しなくなる
• 名前がなくても人物が特定される。小さな会社での役職名や、特定の日付の一意な金額からである
• マスキングした項目こそが必要な項目である。カウンターパーティの名前を抽出するのが仕事なら、マスキング後のテキストにはもうそれが含まれていない

マスキングを使うルートを誰かが承認する前に、自社の文書のサンプルで、人の手ですべての識別子に印を付けてもらい、検出器が何を見落としたかを数える。

文書が誤ったルートに流れたらどうなるのか

ハイブリッドでは、漏洩とはルーティングのバグである。定型の通知に添付されたパスポートのスキャン画像や、転送メールの末尾に引用された顧客のメッセージが、制限付きの内容を外部のルートに乗せてしまうことがある。添付ファイルは一つずつ分類し、スレッド内の引用された過去のやり取りも内容の一部として扱う。

判断を誤ったときに、文書が外に送られるのではなく止まるようにシステムを作る。ネットワーク面は、上でリンクした閉じた境界についての記事が扱っている。内部のルートは、外部プロバイダー用の鍵もパスワードも持たず、そこへのネットワーク経路もない。ここに一つルールを加える。セルフホストのモデルが止まっているときは、そのキューは待機するか人に回し、決して API に切り替えない。

それでも文書が誤って外に出た場合は、どの文書が、いつ、どのプロバイダーに出たかをルートログが示す。プロバイダーがそれをどれだけの期間保持してよいかは、プロバイダーとの契約に書かれている。これをインシデントとしてデータ保護チームとともに扱い、報告が必要かどうかはデータ保護チームが判断する。

二つのモデルが仕事をするとき、品質はどう確かめるのか

受け入れセットとは、それぞれに正解を付けた実際の文書の集まりで、システムが合格かどうかの判定に使う。ハイブリッドの二つのモデルは答え方が違うので、パイプライン全体で一つのスコアしか出さないと、弱いほうのルートが見えなくなる。

また、制限付きの文書は API 側に送れないので、API のモデルをそれで試すことはできない。そのため、閉じた境界についての記事がすべてのルートに勧めている共通の受け入れセットには、両方のルートで許される文書しか入れられない。それを使って二つのモデルを比べ、さらに各ルートには、そのルートが扱う区分から集めた、より大きな専用のセットを用意する。プロバイダーが API のモデルの提供を終了するときは、切り替えの前にそのルートを改めて採点する。

両方のルートを運用するには何が必要か

ハイブリッドでは契約が倍になる。プロバイダーの利用条件とデータ処理契約に加え、セルフホストのモデルを支えるハードウェアまたはクラウドの契約が要る。欧州銀行監督機構（European Banking Authority）は、EU のデジタル・オペレーショナル・レジリエンス法（DORA）が2025年1月17日から適用されていることを指摘している。その適用対象となる EU の金融事業体は、ICT（情報通信技術）サードパーティサービスプロバイダーとの契約上の取り決めについて登録簿を維持しなければならない。外部のモデルプロバイダーを加えることはその登録簿の問題であり、答えるのはコンプライアンス部門である。

運用も倍になる。プロバイダーは1分あたりに送れるリクエスト数に上限を設け、自社のスケジュールでモデルの提供を終了するので、誰かがその両方を見張っていなければならない。自前のサーバーにはキャパシティ計画と、夜間のオンコール担当が要る。ルーターとマスキングの層を運用するのは、自社だけである。

各ルートに流れる文書の割合を、区分ごとに毎日見る。すべての文書をまずセルフホストのモデルに通す構成で、API に送られる割合が増えているなら、外に出る文書が増え、API の請求額も膨らんでいるということだ。原因は、内部のモデルが読めない新しい文書テンプレートであることが多い。

監査証跡には、文書ごとに何が残っているべきか

文書の区分とそれを決めたシグナル、ルーティング表のバージョン、通ったルートを保存する。さらに、マスキングしたかどうかとその検出器のバージョン、そして回答したプロバイダーと正確なモデルのバージョンも加える。この記録があれば、「この区分の文書のうち、前四半期に境界の外に出たものをすべて見せて」という依頼も、データベースへのクエリ一本で済む。

ハイブリッドが誤った選択になるのはどんなときか

すべての文書が一つのデータ区分に収まるなら、ルートは一つで足りる。量が少なければ、二つ目のルートは節約できる額より費用のほうが大きく、セルフホストのモデルが読めないものは人が処理すればよい。また、セルフホストのサーバーの夜間対応に穴があれば、ハイブリッドはそれをそのまま引き継ぐ。そして、自社のリージョンにあるクラウドのマネージドサービスがすべての区分についてルールを満たすなら、契約も運用も一つで済む。

会社がこれをパイロットから本番まで持っていったことを、どう確かめるのか

この記事はどの会社もランク付けしない。どの会社でも、自社のウェブサイトに「本番運用の AI」と書くことはできるからだ。本番で動いているシステムは、パイロットでは残らない記録を残す。だから、クライアントの情報を取り除いたうえで、次のものを見せてもらう。

• バージョン管理された文書としてのルーティング表と、変更を承認する人の名前
• ルートログの数行。文書ごとに区分、ルート、ルーティング表のバージョン、モデルのバージョンが載っているもの
• 制限付きの文書を外部プロバイダーに向けて送り、それが止められることを示すテストの、直近の実行結果
• ルートごと、リリースごとの受け入れスコア。プロバイダーがモデルの提供を終了したときに行ったリリースも含む
• 設計がテキストをマスキングするなら、クライアント自身の文書で計測した検出器の見落とし
• ルートごとの障害に備えたランブック（運用担当者向けの手順書）と、誰がオンコールに就いているか
• いまそのシステムを運用している人との通話

危険信号は何か

• マスキングがプライバシーへの答えのすべてとして示され、見落としの率は計測されていない
• 何を外に出してよいかを決める判定が、外部の API そのものに尋ねている
• 内部のモデルが止まるとトラフィックが API に切り替わり、制限付きの文書も一緒に外に出てしまう
• ルートごとのスコアがなく、パイプライン全体の精度の数字が一つあるだけ

amBrain はどこに位置づけられるか

amBrain が公に説明している言語モデルのプロジェクトは、次の一件だ:「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではない。クライアントの名前は挙げず、そのプロジェクトでモデルがどこで動いていたかも開示しない。amBrain がどのクライアントのためにもハイブリッド構成、マスキングの層、ルーターを構築したと主張するものではなく、価格や期間も示さない。

amBrain は、別のチームのもとで停滞したプロジェクトを引き継ぎ、本番稼働まで持っていく。

amBrain は2019年からソフトウェアを作っている。働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。顧客は、amBrain の再利用可能なコンポーネントを除き、プロダクトとコードの完全な所有権を保持する。

これらの選択肢を比べているなら、話をするすべての会社に、amBrain も含めて、自社の文書の区分と上の記録のリストを持っていく。

よくある質問

• マスキングすれば、すべての文書を API に送れるのか。送れない。特定の人物にたどり直せるマスキング済みのテキストは、自社にとっては依然として個人データであり、検出器は一部の識別子を見落とす。マスキングは、すでに外に出してよい区分について、露出を減らすために使う
• セルフホストのモデルは、品質で API のモデルに並べるのか。文書の種類によっては並べる。仕事をどう分けるかを決める前に、両方のルートで許される文書からなる共通のセットで、両方を採点する
• まず一つのルートで始め、二つ目は後から加えられるか。加えられる。しかも、そのほうが安く済むことが多い。初日からルーターとルートログを作っておけば、後で二つ目のルートを加えるときにパイプラインを作り直さずに済む