- 公開日
Open WeightかAPIかという名前だけでは、誰が運用や安全対策を担うかは決まりません。Open Weightはモデルの重みを入手できる形態、APIはプログラムから機能を呼び出す方法を表し、Open WeightモデルがAPIとして提供される場合もあります。比較するときは、利用許諾とホストする主体を分け、更新、アクセス制御、監視、障害対応を誰が行うか確かめます。
業務に必要な品質とデータの扱いを先に決め、対象版の利用条件、担当者、設定の三つを照合して選びます。
重みを入手できることと利用許諾を分ける
重みは、モデルが学習によって得た数値の集合です。これを入手して実行できても、用途、改変、再配布、提供方法にどのような条件が付くかは、対象モデルのライセンスによります。重みの公開という一つの属性から、商用利用も再配布も無条件に許されるとは判断できません。
具体例として、MetaのLlama 3.3 Community License Agreementには、利用や再配布に関する条件、表示やライセンス提供の条件、追加の商用条件などがあります。これは2024年12月6日公開のLlama 3.3に関するライセンスを、2026年10月25日に確認した例です。他のモデルや別の版へ同じ条件を当てはめません。
実際の選定では、モデル名だけでなく版、配布元、適用ライセンス、そのライセンスが参照する利用方針を確認します。改変したモデルを外部へ配布するのか、自社だけで推論するのかによって、確認すべき行為も変わります。個別の権利処理に解釈が必要なら、予定する行為と対象条項を整理して法務などの担当者へ確認します。
APIではサービスの契約条件も確認対象です。モデルの開発者、重みの配布者、APIの提供者が同じとは限りません。利用者に適用される条件を、モデルのライセンスだけ、またはAPIの機能説明だけで確認済みにせず、実際に利用する提供経路で照合します。
同じ業務を二つの運用案へ置く
架空の社内ヘルプデスクで、利用者の質問に対し、閲覧を許可された手順書から回答案を作る業務を考えます。回答は担当者が原文と照合してから利用者へ渡します。アカウントの変更や申請の実行はモデルへ任せません。
説明用の入力は「貸与端末が故障した場合、交換をどこへ依頼しますか」です。参照する架空手順書には「端末交換の申請は社内サポート窓口へ。申請時に資産番号を確認する」とあります。期待する回答案は、この窓口と確認事項を保ち、資料にない交換期限を加えないものです。
比較するA案は、入手した重みを自社が管理する実行環境で動かす自己ホストです。B案は、推論基盤を提供者が運用する管理されたAPIを使います。自己ホストもクラウド上に置けるため、ここでは社内設置か社外設置かだけを選択軸にしません。
同じ質問群、同じ版の手順書、同じ閲覧権限、同じ回答項目と合格基準を使い、想定する利用件数、同時利用、応答期限、障害時に許容する停止時間も揃えます。変えるのは推論基盤の提供・運用形態です。候補で同じモデル版を使えないなら、その差も含む構成比較として記録し、応答品質の差をホスト方式だけの効果とは断定しません。
業務の合格条件と比較軸の決め方そのものは、業務要件とテンプレート運用の安定性でLLMを選ぶで扱っています。品質の試験には、手順書に答えがない質問と、利用者が読めない資料を求める質問も含めます。前者は分からない範囲を示して担当者へ回し、後者は権限のない資料をモデルへ渡さないことを期待します。以下はこの業務を比較するための設計例であり、実在サービスでの試験結果ではありません。
担当者を作業ごとに決める
次の表はA案とB案で想定する分担です。B案の提供者が実際に担う範囲は、契約とサービス仕様で確認する必要があります。
| 作業 | A案の自己ホスト | B案の管理されたAPI |
|---|---|---|
| 推論基盤の更新 | 自社運用チームが実行器や依存ソフトウェアの更新を計画する。利用するクラウド基盤との分担は別に確認する | 提供者が担当する更新範囲と通知方法を確認し、自社は業務への影響を評価する |
| モデル版の変更 | 自社が入手・評価・切替え・復帰を管理する | 提供者の版指定、変更通知、提供終了条件を確認し、自社が移行を判断する |
| アクセス制御 | 自社が推論先の認証に加え、利用者と手順書の閲覧権限を設定する | 自社がAPI利用権限と資料の閲覧権限を管理し、提供者側の基盤制御との境界を確認する |
| 監視と記録 | 自社が稼働状態、異常な利用、ログの内容・保存・閲覧権限を管理する | 提供者から得られる監視情報と、自社のアプリ側で記録する情報を分ける |
| 障害対応 | 自社が復旧担当、連絡経路、代替処理を用意する | 提供者への連絡・復旧情報の取得と、自社側の受付制限・手動対応を結ぶ |
自己ホストでは、自社の管理範囲で基盤の設定や更新時期を選べますが、その作業を続ける人員と手順が要ります。APIでは提供者へ任せる基盤作業が増えますが、必要な監視情報を取得できるか、変更や障害の連絡が業務に間に合うかを確認します。単に「自社責任」「提供者責任」と一欄にまとめると、障害を誰が検知し、どの情報を添えてどこへ連絡するかが抜けます。
実在サービスの一例として、Amazon Bedrockのセキュリティ文書は責任共有の考え方を示しています。データ保護の説明でも、利用者が扱う内容やセキュリティ構成に関する責任を区別しています。APIを利用しても、どの手順書を誰のために送るかという業務上の判断は残ります。この分担を他社APIすべての契約へそのまま移すことはできません。
安全対策はデータの経路に沿って確認する
A案では、利用者の質問から、自社のアプリ、権限確認済みの資料取得、推論環境、回答案、人による照合へ進む経路を描きます。ここに監視サービス、ログ保管、バックアップが加わるなら、その送信先も記録します。推論を自己ホストしていても、別の監視先へ質問本文を送れば、その経路を含めて情報管理が必要です。
B案では、同じアプリからAPIへ何を送るかを確認します。質問全文、取得した手順書の一部、会話履歴などを区別し、返ってきた回答案がどこへ保存されるかも追います。提供者側の処理・保存と自社アプリ側の保存を別々に確かめ、「APIへ送った後は保存していない」という説明の対象がどこまでかを明らかにします。
Bedrockの前掲データ保護文書は、AWSが運営するModel Deployment Accountでの処理と、モデル提供者によるアクセスの制限を説明しています。これはそのサービスの記載条件に限る話であり、あらゆるAPIで保存がないことや、すべての地域で経路が同じことの保証ではありません。導入時には利用する機能、地域、設定、契約を、実際の構成と照合します。
回答内容を検査する仕組みがあっても、それだけで資料の閲覧権限を実現したことにはなりません。先ほどの業務なら、自社アプリが利用者の権限に沿って取得対象を絞り、回答を原文と照合できるようにします。モデルや提供サービスの安全機能は、その役割と限界を確認して組み合わせます。
契約の未確認と実装の未確認を別に残す
たとえばB案で「入力データの保持条件を契約で確認できていない」なら、契約条件が未確認です。一方、「契約上の条件は確認したが、アプリのログに質問全文が残るか調べていない」なら、実装が未確認です。前者を設定画面だけで解決したことにせず、後者を契約書だけで完了にしません。
A案でも同じです。対象版の利用許諾を確認していても、資料を読む権限やログの保管設定が正しいとは限りません。未確認の内容、必要な資料や試験、確認する担当者、利用を保留する範囲を残します。情報の持出し条件が未確認なら実データの投入を保留し、許可された架空データで独立して確認できる作業だけ進めます。
方式を選ぶ際は、同じ合格基準を満たすための基盤費用だけでなく、更新、監視、障害調査、人の確認に必要な作業も比べます。自己ホストを選ぶならその継続担当を確保できること、APIを選ぶなら任せる範囲と残る作業が業務要件に合うことが判断材料です。未確認の担当や契約条件をゼロの負担として扱わず、埋まっていない箇所を確認してから採用範囲を決めます。
ローカルLLMのモデルファイルを照合する方法は「ローカルLLMのモデルファイルをハッシュで照合し、提供元を別に確かめる」、Air-Gapped環境でモデルや脆弱性情報を更新する方法は「Air-Gapped環境でモデル・脆弱性情報をどう更新するか」で解説しています。
オンプレミスLLMが適する条件と運用負担は「オンプレミスLLMが適する条件と運用負担を比較する」で解説しています。
