Kimi K3のようなオープンウェイトモデルと、クローズドモデルは何が違うのか

Claude・ChatGPT・Geminiとの違いと、企業にガードレールが必要な理由

2026年7月、中国のMoonshot AIがKimi K3のフルウェイトを公開しました。7月16日にAPIとアプリの提供を開始し、7月26日にウェイトを公開。その翌日の7月27日、Anthropic CEOのダリオ・アモデイが「Our position on open-weights models」と題した声明を発表しています。

この10日ほどの動きは、企業のAI導入にとって無視できない意味を持ちます。クローズドモデルに迫る能力を持つオープンウェイトモデルが、実際にダウンロードして自社環境で動かせる対象になったからです。

Kimi K3は、Moonshot AIが自社で最も高性能と位置付ける、オープンウェイトのネイティブマルチモーダル・エージェント型モデルです。総パラメータ数は2.8兆、推論時に活性化される有効パラメータは1,040億、コンテキスト長は約100万トークン（1,048,576トークン）。モデルウェイトはKimi K3 Licenseの下で公開されています。

企業が生成AIを導入する際の選択肢は、もはやClaude、ChatGPT、Geminiのようなクラウド型サービスだけではありません。学習済みモデルを自社のクラウドやデータセンターに配置し、企業自身が運用する選択肢も現実的になりました。

では、Kimi K3のようなオープンウェイトモデルと、Claude、ChatGPT、Geminiのようなクローズドモデルは、何が違うのでしょうか。

最も重要な違いは、モデルの「中身が公開されているかどうか」ではありません。

違うのは、モデルを誰が運用し、安全対策を適用し、利用状況を監視し、問題が見つかったときに停止する責任を負うのかという点です。

オープンウェイトモデルは、企業にモデルを選び、自社環境で動かし、用途に合わせて調整する自由を与えます。その一方で、クローズドモデルでは提供者が担っていた安全管理の一部を、導入企業自身が引き受けることになります。

したがって、企業が考えるべき問いは、次のような単純な二択ではありません。

オープンウェイトモデルを使うべきか、クローズドモデルを使うべきか。

本当に考えるべきなのは、次の問いです。

どのモデルを、誰が、どの用途で、どのデータを使って利用できるのか。 何をAIに実行させ、どこから人間の承認を必要とするのか。 その利用を企業として、どのように制御し、記録し、必要に応じて遮断するのか。

本記事では、Kimi K3を具体例として、オープンウェイトモデルとクローズドモデルの違いを整理します。そのうえで、Claudeを提供するAnthropic、ChatGPTやGPTモデルを提供するOpenAI、GeminiとGemmaを開発するGoogleの公式情報を確認し、企業がAIを安全に利用するために、なぜ「モデルの外側のガードレール」が必要になるのかを解説します。

この記事の結論

オープンウェイトモデルとは、学習済みAIモデルのパラメータである「ウェイト」が公開され、利用者が自らの環境で実行、調整、配備できるモデルです。

クローズドモデルとは、ウェイトが公開されず、通常は開発企業が管理するAPIやアプリケーションを通じて利用するモデルです。

オープンウェイトモデルには、次のようなメリットがあります。

• 自社環境で実行できる
• データを外部APIに送らない構成を作れる
• 用途に合わせて追加学習や調整ができる
• 利用するインフラや提供事業者を選びやすい
• 特定のモデル提供企業への依存を抑えられる

一方で、次のような課題もあります。

• モデル提供者による利用監視が届きにくい
• 安全対策を変更・除去できてしまう
• 公開後のウェイトを完全には回収できない
• インフラ、更新、権限、ログを利用企業が管理する必要がある
• 問題発生時の停止や調査を企業側で設計する必要がある

Anthropicは、オープンウェイトモデルを一律に禁止する立場ではありません。ただし、公開後はガードレールの適用や利用監視、ウェイトの回収が難しくなると指摘しています。

OpenAIは、自社でもgpt-ossというオープンウェイトモデルを公開しています。そのモデルカードでは、オープンウェイトモデルがクローズドモデルとは異なるリスク特性を持つこと、そして文脈によっては、APIや自社製品経由のモデルに組み込まれたシステムレベルの保護を企業側が再現する必要があることを明記しています。

GoogleもGemmaというオープンモデル群を公開し、同時にShieldGemmaやResponsible Generative AI Toolkitを提供しています。モデル単体ではなく、アプリケーションとシステムの両方で安全対策を設計する必要性を示しています。

3社の考え方を企業利用の観点から整理すると、共通する出発点は次のとおりです。

高性能なAIを企業で安全に使うためには、モデル自体の安全性だけでは足りず、システムレベルの安全設計が必要になる。

そして、企業に固有の統制——誰が、何に、どのデータで、どこまで実行してよいか——は、この「システムレベル」の中で企業自身が設計しなければならない領域です。本記事はここを論点の中心に置きます。

オープンウェイトモデルとは何か

オープンウェイトモデルの定義

オープンウェイトモデルとは、学習済みAIモデルの数値パラメータである「ウェイト」が、ダウンロードまたは取得可能な形で公開されているモデルです。

生成AIは、大量のデータを使った学習によって、膨大な数の数値パラメータを獲得します。このパラメータには、言語のパターン、単語や概念の関係、画像の特徴、推論の傾向など、学習を通じて獲得した能力が反映されています。

公開されたウェイトを利用することで、企業や開発者はモデルを自らの環境に配置できます。たとえば、次のような利用方法が考えられます。

• 自社のAWS、Google Cloud、Azureなどで稼働させる
• 自社データセンターで稼働させる
• インターネットに接続しない閉域環境で利用する
• PCやワークステーションでローカル実行する
• 特定の業務向けに追加学習する
• モデルを量子化して推論コストを抑える
• 独自のAIエージェントへ組み込む
• モデル内部の挙動を研究する

Kimi K3は、このオープンウェイトモデルに該当します。Moonshot AIはKimi K3を「open-weight, native multimodal agentic model」と説明し、モデルウェイトを公開しています。

GoogleのGemmaもオープンモデル群です。Google DeepMindは、Gemmaについて、クラウドサーバー、ノートPC、スマートフォンなど、利用者が必要とする場所で実行できるモデルとして説明しています。

OpenAIも、gpt-oss-120bとgpt-oss-20bというオープンウェイトモデルを提供しています。これらはChatGPTで提供される主要な商用モデルとは別に、ウェイトが公開されているモデルであり、利用者が管理するインフラやホスティング事業者上で実行できます。

オープンウェイトとオープンソースは同じではない

「オープンウェイトモデル」と「オープンソースモデル」は、日常的には同じ意味で使われることがあります。しかし、厳密には区別した方がよい言葉です。

モデルのウェイトが公開されていても、次の情報がすべて公開されているとは限りません。

• 学習に使用したデータ
• データの収集方法
• データの除外・選別基準
• 学習コード
• 学習時の設定
• 安全性学習に使用したデータ
• 人間による評価方法
• 学習に使用した計算資源
• 開発過程の実験結果
• 完全な再現手順

さらに重要なのは、ウェイトの利用条件はモデルごとに大きく異なるという点です。

OpenAIのgpt-ossは、Apache 2.0ライセンスとOpenAIの利用ポリシーの下で提供されています。

一方、Kimi K3のウェイトはKimi K3 Licenseという独自のライセンス文書の下で公開されています。前世代のKimi K2に付されていた「Modified MIT」という名称は使われておらず、Hugging Face上のライセンス表記も other です。

この違いは、日本企業にとって実務的な意味を持ちます。Kimi K3 Licenseは、MIT型の広い許諾（使用、複製、改変、結合、公開、頒布、サブライセンス、販売、そしてファインチューニングと派生物の作成）を与えたうえで、規模に応じた2つの条件を追加しています。

Kimi K3 Licenseの主な条件

第2条：Model as a Serviceに関する別途契約

ライセンシーまたはその関連会社が「Model as a Service」事業を営んでおり、かつライセンシーと関連会社の合計売上が連続する任意の12か月間で2,000万米ドルを超える場合、商用利用の前にMoonshot AIとの別途契約を締結する必要があります。

ここでのModel as a Serviceは、第三者に言語モデルの推論またはファインチューニングへのアクセスを与え、その第三者が入力、パラメータ、学習データに対して実質的な制御を行える形態（APIなど）と定義されています。次の2つは除外されます。

• モデルの能力が特定の機能やハーネスの内部にのみ埋め込まれたエンドユーザー向け製品
• 他者がホストするモデルへ、単にリクエストを中継するだけの形態

注意すべき点が2つあります。ひとつは、閾値がグループの合計売上であって、Kimi K3から得た売上に限定されていないこと。もうひとつは、条件を満たした場合に別途契約が必要になるのは「あらゆる商用利用」に対してである点です。

2,000万米ドルという水準は、日本の事業会社では決して高いハードルではありません。自社でK3をホストして顧客に推論を提供する形態を検討するSIerやクラウド事業者は、まずここに該当するかどうかを確認する必要があります。

第3条：大規模製品での表示義務

Kimi K3または派生物を用いた商用製品・サービスが、月間アクティブユーザー1億人超、または月間売上2,000万米ドル超のいずれかに該当する場合、その製品のユーザーインターフェース上に「Kimi K3」を目立つ形で表示する必要があります。

第4条：適用除外

第2条と第3条は、次の場合には適用されません。

• 社内利用。ソフトウェア、その出力、およびその基盤能力を第三者に提供しない利用と定義されています
• Moonshot AIの公式製品、または認定推論パートナー経由での利用

閉域環境での社内利用にとどめる限り、これらの条件は問題になりません。逆に言えば、出力を顧客に提供した時点で「社内利用」の定義から外れるため、自社サービスへの組み込みを検討する場合は第2条・第3条の判定が必要になります。

第5条は無保証・免責条項です。オープンウェイトモデル一般に言えることですが、モデルの出力に起因する損害について提供者は責任を負いません。企業として利用する以上、出力の検証と統制は自社の責任範囲に入ります。

出典 Moonshot AI, “Kimi K3 License.” https://huggingface.co/moonshotai/Kimi-K3/blob/main/LICENSE ライセンスに関する問い合わせ先として license@moonshot.ai が明記されています。

「オープンウェイトだから自由に使える」という理解は正確ではありません。モデルの性質を正確に表現する場合は、「オープンソースAI」と一括りにするより、オープンウェイトモデルと表現したうえで、個別にライセンスを確認する姿勢が適切です。

そしてこのライセンス条件そのものが、本記事の主題と直結します。どのモデルを、どの部署が、どの形態で使ってよいのかという判断は、モデルの性能や安全性だけでは決まりません。ライセンス条件、売上規模、提供形態を踏まえた企業側の統制が必要になります。

クローズドモデルとは何か

クローズドモデルとは、モデルウェイトが一般には公開されず、モデル開発企業が管理するAPI、クラウドサービス、アプリケーションなどを通じて提供されるモデルです。

代表例としては、次のものがあります。

• AnthropicのClaude
• OpenAIのGPTモデルおよびChatGPT
• GoogleのGemini

厳密には、ClaudeやGPT、Geminiはモデルまたはモデルファミリーを指し、ChatGPTはOpenAIが提供するアプリケーションです。ただし、一般の読者向けには「Claude・ChatGPT・Gemini」と表現した方が、利用体験の違いを理解しやすいでしょう。

クローズドモデルでは、利用企業がモデルウェイトを直接保有するのではなく、モデル提供者が管理するシステムへリクエストを送り、結果を受け取ります。

一般に、モデル提供者は次のような役割を担います。

• モデルウェイトの管理
• GPUインフラの運用
• モデルのアップデート
• 安全性評価
• 利用規約の適用
• 悪用行為の検知
• アカウントやAPIキーの停止
• システムレベルの入力・出力検査
• 脆弱性発見後の安全対策の更新

企業は、自ら大規模なGPU基盤を運用しなくても、高性能なモデルを迅速に利用できます。一方で、次のような点はモデル提供者の方針に依存します。

• 利用できるモデル
• モデルの提供期間
• APIの価格
• データの処理地域
• 保存・学習利用に関する条件
• 安全ポリシー
• 利用制限
• モデルの更新時期

オープンウェイトモデルとクローズドモデルの違い

どちらが一律に優れているというものではありません。

最新の高性能モデルを迅速に使いたい場合は、クローズドモデルのAPIが有力です。一方、データを外部に出したくない場合、閉域環境で利用したい場合、特定用途に深くカスタマイズしたい場合は、オープンウェイトモデルが有力になります。

企業にとって現実的なのは、どちらか一方だけを選ぶことではなく、用途、機密性、性能、コストに応じて両者を使い分けることです。

Claudeを提供するAnthropicは、オープンウェイトモデルをどう見ているのか

2026年7月27日、Anthropic CEOのダリオ・アモデイは、「Our position on open-weights models」と題した公式見解を公開しました。

この声明は、中国製のオープンウェイトモデルを米国企業が利用することを禁止すべきではないかという議論や、Anthropicが自社事業を守るために規制を求めているという批判を受けて発表されたものです。

Anthropicの立場は、単純な「オープンウェイト反対」ではありません。

Anthropicはオープンウェイトモデルの一律禁止に反対している

Original

“Anthropic has never advocated for a ban on open-weights models.”

日本語訳

「Anthropicは、オープンウェイトモデルの禁止を提唱したことは一度もありません」

※文意と日本語としての読みやすさを優先した独自訳です。逐語訳ではありません。

出典 Dario Amodei, CEO of Anthropic, “Our position on open-weights models,” July 27, 2026. https://www.anthropic.com/news/position-open-weights-models

アモデイは続けて、危険な能力を持たないオープンウェイトモデルを「公共財（public good）」と表現しています。動かすための計算資源以外にコストがかからず、企業、開発者、研究者に価値をもたらすものだという評価です。

つまり、Anthropicの主張は、オープンウェイトモデルをカテゴリーとして排除するものではありません。

ただし、声明の主眼はオープンウェイトそのものではない

ここは正確に読む必要があります。

アモデイは声明の中で、自身の安全保障上の懸念を明確に順位付けしています。

第一の懸念は、権威主義国家が米国よりも強力なAIモデルを構築し、軍事的優位や自国民への深刻な抑圧に用いることです。そして、この懸念については、そのモデルがオープンウェイトで公開されるかどうかは無関係であるとしています。むしろ最も危険なのは、秘密裏に訓練され、公開されないまま軍や治安機関にのみ渡されるモデルかもしれない、という指摘です。

第二の懸念として、強力なAIモデルがサイバー攻撃や生物学的攻撃に悪用されるリスク、および深刻なアライメント問題が挙げられます。オープンウェイトモデルのリスクが論じられるのは、この文脈です。

さらにアモデイは、米国企業によるオープンウェイトモデルの利用を禁止しても、このリスクには対処できないと述べています。悪意ある行為者は正規の米国企業ではないからです。そして、そうした禁止は米国のAI企業を競争から守ることにはなるが、それは自分の目的ではないと明言しています。

この文脈を落として「Anthropicがオープンウェイトのリスクを指摘した」とだけ要約すると、声明の主旨を取り違えることになります。

公開後の監視・停止・回収が難しいという指摘

そのうえで、Anthropicはオープンウェイトモデルがクローズドモデルとは異なるリスク特性を持つことを明示しています。

Original

“Open-weights models […] do potentially present a higher risk than closed models, because it is very difficult to apply guardrails to them or monitor their usage, and once weights are released they cannot be withdrawn.”

日本語訳

「オープンウェイトモデルは、中国製か、その他の国で開発されたものかを問わず、クローズドモデルよりも高いリスクを伴う可能性があります。ガードレールを継続的に適用したり、利用状況を監視したりすることが非常に難しく、一度公開されたウェイトを回収することもできないためです」

※文意と読みやすさを優先した独自訳です。逐語訳ではありません。

出典 Dario Amodei, CEO of Anthropic, “Our position on open-weights models,” July 27, 2026. https://www.anthropic.com/news/position-open-weights-models

「潜在的に（potentially）」というヘッジと、「クローズドモデルとの比較において」という前提が付いている点が重要です。断定ではなく、比較の上での可能性として述べられています。

クローズドモデルであれば、モデル提供者は問題を発見した際に、APIアクセスを停止したり、安全フィルターを更新したり、モデルを差し替えたりできます。オープンウェイトモデルが第三者の環境へダウンロードされた後は、元の提供者が利用状況を把握したり、すべてのコピーを消去したりすることはできません。

なお、この指摘の根拠としてアモデイが脚注で参照しているのは、英国AI Security Instituteの報告です。オープン性がもたらす利点と、同じ openness が閉ざしてしまう安全策とが表裏一体である、という趣旨の分析です。

Anthropicが求めているのは、能力に応じた安全性試験

アモデイが声明で支持している政策は3点です。

• 強力なチップおよび製造装置を中国に販売しないこと、および密輸・迂回の取り締まり
• 産業規模の蒸留（ディスティレーション）操作への対策
• 十分に高い能力を持つすべてのモデルについて、オープンかクローズドかを問わず、公開前の安全性試験を義務化すること

企業のAI利用という観点から特に関係が深いのは3点目です。対象として挙げられているリスクは、サイバー攻撃能力、生物学的な悪用能力、そしてアライメント上の問題です。

ここで重要なのは、アモデイが「オープンモデルがリスクを高めるのか、そしてそのリスクを緩和できるのかは、あらかじめ決めるのではなく、試験によって明らかにされるべきだ」という立場を取っている点です。

モデルの公開形式や国籍だけで危険性を判断するのではなく、実際の能力を評価し、その結果に基づいて対応する。 これがAnthropicの主張の骨格です。

ChatGPTを提供するOpenAIは、オープンウェイトモデルをどう見ているのか

OpenAIは、ChatGPTやAPIで提供するクローズドモデルだけでなく、gpt-oss-120bとgpt-oss-20bというオープンウェイトモデルも公開しています。これらはApache 2.0ライセンスとOpenAIのgpt-oss利用ポリシーの下で提供されるテキスト専用の推論モデルで、エージェント的なワークフローでの利用を想定して設計されています。

OpenAIは、オープンウェイトモデルの価値として、次の点を挙げています。

• 自社環境やプライベートクラウドで実行できる
• データレジデンシーを維持できる
• 用途に合わせてカスタマイズできる
• オープンなツールでモデルを調整できる

一方で、gpt-ossのモデルカードでは、オープンウェイトモデルがクローズドモデルとは異なるリスク特性を持つことも明記しています。

OpenAIは「異なるリスクプロファイル」を明記している

Original

“They present a different risk profile than proprietary models.”

日本語訳

「オープンウェイトモデルは、提供企業が管理するクローズドモデルとは異なる種類のリスクを持ちます」

※“proprietary models”を、この記事の文脈に合わせて「提供企業が管理するクローズドモデル」と表現した独自訳です。逐語訳ではありません。

出典 OpenAI, “gpt-oss-120b & gpt-oss-20b Model Card,” August 5, 2025. https://openai.com/index/gpt-oss-model-card/

OpenAIは続けて、ウェイトが公開された後、意志の固い攻撃者が安全上の拒否を回避するようモデルをファインチューニングしたり、有害な行為へ直接最適化したりする可能性があると説明しています。その場合、OpenAIが追加の緩和策を適用したり、アクセスを取り消したりすることはできません。

企業が実装すべきなのは「システムレベルの保護の再現」

そして、この記事の論点にとって最も重要なのが次の一文です。

Original

“In some contexts, developers and enterprises will need to implement extra safeguards in order to replicate the system-level protections built into models served through our API and products.”

日本語訳

「文脈によっては、開発者や企業は、当社のAPIおよび製品を通じて提供されるモデルに組み込まれたシステムレベルの保護を再現するために、追加のセーフガードを自ら実装する必要があります」

※文意と読みやすさを優先した独自訳です。逐語訳ではありません。

出典 OpenAI, “gpt-oss-120b & gpt-oss-20b Model Card,” August 5, 2025. https://openai.com/index/gpt-oss-model-card/

ここで語られているのは、単に「気をつけましょう」という話ではありません。

クローズドモデルでは提供者側のシステムに組み込まれていた保護機構を、オープンウェイトモデルでは導入企業が自分の環境で再現しなければならない、という具体的な作業の話です。

この点をOpenAIは文書の性格そのものにも反映させています。gpt-ossは多様な事業者が構築・運用するさまざまなシステムの一部として使われるため、OpenAIはこの文書を「システムカード」ではなく「モデルカード」と呼んでいます。モデルはデフォルトでOpenAIの安全ポリシーに従うよう設計されているが、システムをどう安全に保つかについては、他の関係者もそれぞれの判断と実装を行うことになる、という整理です。

gpt-oss-safeguardが示す「モデル外部の安全性」

OpenAIは2025年10月29日、gpt-ossをファインチューニングした安全性分類モデル、gpt-oss-safeguard（120bおよび20b）をリサーチプレビューとして公開しました。オンライン安全性ツールの非営利団体ROOSTなどとの協業で開発され、Apache 2.0ライセンスで提供されています。

注目すべきは、これがOpenAIの社内ツールの実装公開だという点です。OpenAIは「Safety Reasoner」と呼ぶ仕組みを自社で運用しており、分類器を再学習させるよりも短い時間で安全ポリシーを本番環境に反映させるために使っていると説明しています。GPT-5やChatGPT Agent、画像生成やSora 2といったシステムでも、多層的な防御の一部として組み込まれているとしています。gpt-oss-safeguardは、その手法を外部の開発者が使える形にしたものです。

つまりOpenAIは、自社のクローズドなサービスにおいても、モデル内部の安全学習だけでは不十分だと判断し、モデルの外側に別建ての判定レイヤーを置いています。

gpt-oss-safeguardの特徴は、推論時に開発者が独自のポリシーを与えられる点です。あらかじめ固定された分類基準ではなく、企業が記述したポリシーを解釈して、ユーザー入力、モデル出力、会話全体などを分類します。判定結果とあわせて推論の過程も出力されるため、なぜその内容が問題と判断されたのかを確認できます。

たとえば、企業が次のようなポリシーを定義できます。

• 顧客の個人情報を外部AIへ入力してはならない
• 未公開の財務情報を送信してはならない
• 医療や法律に関する断定的判断を生成してはならない
• 差別的・攻撃的な表現を出力してはならない
• 特定の業務操作は人間の承認なしに実行してはならない

これは、OpenAI自身が、安全性をモデル内部だけで完結する問題として捉えていないことを示しています。モデルの前後に安全性分類を置き、企業やサービス固有のポリシーを適用する、システムレベルの多層防御が必要だという考え方です。

Geminiを提供するGoogleは、オープンモデルをどう見ているのか

Googleは、Geminiというクローズドモデル群を提供する一方で、Gemmaというオープンモデル群も公開しています。なお、Googleは自社の公開モデルを「オープンモデル（open models）」と呼んでいるため、本記事でもGoogleについてはその呼称を用います。

Google DeepMindはGemmaを、クラウドサーバー、PC、スマートフォンなど、利用者が必要とする場所で動かせるモデルとして位置付けています。

Googleは、モデルを公開するだけでなく、オープンモデルを責任ある形で利用するためのResponsible Generative AI Toolkitも提供しています。このツールキットには、次のような内容が含まれます。

• システムレベルの安全ポリシー設計
• モデルの安全性評価
• レッドチーミング
• 入力と出力のフィルタリング
• 安全性分類器
• モデル挙動のデバッグ
• 透明性と説明責任
• 継続的なモニタリング

Googleは、Gemmaのようなオープンモデルを利用する際には、アプリケーションとモデルの両方を含めた包括的なアプローチが必要だと説明しています。

ShieldGemmaは入力と出力を安全ポリシーに照らして判定する

Googleは、安全性分類モデルとしてShieldGemmaを提供しています。

ShieldGemmaは、Gemmaファミリーをベースにした、命令チューニング済みのオープンウェイト安全性分類器です。テキストまたは画像が安全ポリシーに違反しているかを、入力と出力の双方で判定します。

用途によってモデルが分かれている点に注意が必要です。

• ShieldGemma（初代）：テキストのコンテンツモデレーション用。Gemma 2ベースで、2B・9B・27Bの3サイズが提供されています。速度、性能、汎化性のバランスを用途に応じて選べます。
• ShieldGemma 2：画像のコンテンツモデレーション用。Gemma 3ベースの4Bモデルで、合成画像・自然画像の安全性を判定します。ビジョン言語モデルの入力フィルタ、または画像生成システムの出力フィルタとしての利用が推奨されています。

企業のテキストベースのAI利用に安全性判定を組み込む場合、対象となるのは初代ShieldGemmaです。

いずれもオープンウェイトとして提供され、用途に合わせてファインチューニングできます。

Googleの考え方も、OpenAIと同様に、モデルを提供して終わりではありません。モデルの入力と出力を外側から検査し、利用するアプリケーションのポリシーに沿って制御する仕組みを、モデルと合わせて提供しています。

出典 Google AI for Developers, “ShieldGemma | Responsible Generative AI Toolkit.” https://ai.google.dev/responsible/docs/safeguards/shieldgemma

3社の公式見解から言えること、言えないこと

ここで一度、論点を切り分けておきます。

3社の一次情報から言えること

Anthropic、OpenAI、Googleの立場は完全に同じではありません。

Anthropicは、国家安全保障、高性能モデルの危険能力、公開後の不可逆性を強く論じています。OpenAIは、自社でもオープンウェイトモデルを公開しつつ、導入企業がシステムレベルの保護を再現する必要性を明記しています。Googleは、Gemmaとともに安全性評価や入力・出力分類のためのツールを提供し、モデルとアプリケーションの両方で責任ある設計を行うよう促しています。

それでも、企業利用の観点から整理すると、次の共通点があります。

• オープンウェイトモデルには技術的・経済的価値がある
• オープンウェイトモデルを一律に排除することが答えではない
• 公開後は提供者による監視・停止・回収が難しくなる
• モデルの能力に応じた安全性評価が必要である
• 実際の利用時には、入力と出力を検査する必要がある
• 企業や開発者も安全対策を実装する責任を持つ
• 最終的なAIシステムの安全性は、モデル単体では決まらない

3社の一次情報だけでは言えないこと

ただし、ここで正直に線を引いておく必要があります。

3社が具体的に提供・言及しているのは、主として「コンテンツの安全性分類」までです。 gpt-oss-safeguardも、ShieldGemmaも、入力と出力が安全ポリシーに違反していないかを判定するモデルです。

一方、企業がAIを業務に組み込むときに実際に必要になる統制は、それだけではありません。

• 誰が利用できるか
• どの部署がどのモデルを利用できるか
• どのデータをどこへ送信できるか
• どの用途に利用できるか
• AIが何を実行できるか
• どの操作に承認が必要か
• どの程度のコストを許可するか
• どの履歴を保存するか
• 問題時にどこで遮断するか

これらは、モデル提供各社の公式文書が直接論じている範囲ではありません。ここから先は、各社の主張から論理的に導かれる、本記事の主張です。

各社が示しているのは「システムレベルで安全性を設計せよ」という原則であり、そのシステムに何を含めるかは、モデルを組み込む企業自身が決めなければならない領域だからです。OpenAIが自らの文書を「システムカード」ではなく「モデルカード」と呼んだ理由も、まさにここにあります。

この線引きを踏まえたうえで、以降では企業側が設計すべき統制の中身を扱います。

「安全なモデル」と「安全な利用」は同じではない

企業のAI導入では、「このモデルは安全ですか」という問いがよく使われます。しかし、この問いだけでは十分ではありません。

どれほど厳格な安全性評価を受けたモデルでも、誤った権限、誤ったデータ接続、誤った業務フローで利用すれば、事故は起こり得ます。

たとえば、一般的な文章生成モデルが安全に設計されていたとしても、次のような状況では企業リスクが生じます。

• 社員が顧客の個人情報を入力する
• 未公開の財務情報を外部モデルへ送る
• AIエージェントに管理者権限を与える
• AIが人間の確認なしに顧客へメールを送る
• 高額なモデルを無制限に呼び出す
• 問題発生時に利用履歴を追跡できない
• 退職者のAPIキーが残り続ける
• 未承認モデルが業務で利用される

これらは、モデルが有害な文章を出すかどうかだけでは防げません。企業固有の組織構造、データ分類、権限、予算、契約、業務フローを踏まえた統制が必要です。

モデルそのものの安全性

モデルそのものの安全性には、次のような論点があります。

• サイバー攻撃に悪用できる能力
• 生物・化学分野の危険能力
• アライメント上の問題
• 有害な回答を拒否する能力
• 学習データの品質
• モデルの堅牢性
• 脆弱性
• 安全性評価の結果

これらは、主としてモデル開発者、研究機関、評価機関が担う領域です。

企業における利用の安全性

一方、企業における利用の安全性には、次のような論点があります。

• 誰が使うか
• 何のために使うか
• どのデータを入力するか
• どのモデルへ送信するか
• どのツールやシステムへ接続するか
• AIに何を実行させるか
• どの操作に承認を必要とするか
• どの程度のコストを許可するか
• 何をログとして残すか
• 問題が起きた際にどう止めるか

これらは、導入企業が設計しなければならない領域です。

企業が管理すべき7つの要素

ここからは「何を統制するか」、つまり統制の対象を整理します。

株式会社Metelixは、この統制の対象をAIトークンガバナンスという管理カテゴリとして定義しています。企業内でのAI利用に伴うコスト、データ、行動、証跡、権限、利用モデル、監査、そして停止への備えを統制するための枠組みです。

情報セキュリティやITガバナンスの既存の枠組みは、人がシステムを操作することを前提に組み立てられています。AIが自ら判断し、外部システムを操作し、トークン単位でコストを発生させる状況は、その前提の外側にあります。ここで挙げる7つの要素は、その差分を埋めるために管理対象を整理したものです。

1. 利用者

誰がAIを利用できるのかを管理します。正社員、業務委託、取引先、顧客では、許可すべき範囲が異なります。部署や役職に応じて、利用できるモデル、データ、機能を分ける必要があります。

2. 用途

何のためにAIを使うのかを管理します。社内文章の要約と、採用選考、契約審査、医療判断、顧客への自動回答では、求められる統制水準が異なります。リスクの高い用途については、利用を禁止するか、人間の確認を必須にする必要があります。

3. データ

どの情報をAIへ送信できるのかを管理します。個人情報、営業秘密、顧客データ、契約情報、未公開財務情報、認証情報、ソースコード、社外秘資料などについて、モデルや処理環境ごとに送信ルールを定める必要があります。

4. モデル

どのモデルを利用できるのかを管理します。モデルごとに、性能、価格、提供地域、ライセンス、データ処理条件、安全性、利用可能期間が異なります。用途や機密性に応じて、許可するモデルを切り替える必要があります。

5. 実行権限

AIが文章を生成するだけなのか、外部システムを操作できるのかを管理します。メール送信、顧客情報の変更、ファイル削除、コード実行、決済、契約承認などは、生成文章とは異なるリスクを持ちます。AIエージェントが普及するほど、回答内容だけでなく、実行できる操作を制御することが重要になります。

6. コスト

モデルの利用量と予算を管理します。クローズドモデルではAPI利用料、オープンウェイトモデルではGPU、電力、ストレージ、運用人員などの費用が発生します。部署、ユーザー、プロジェクト、モデルごとに利用量を把握し、上限を設定する必要があります。

7. 証跡

誰が、いつ、どのモデルへ、何を入力し、どのような回答や処理が行われたのかを記録します。監査ログは、インシデント調査、内部監査、顧客への説明、法令・規制対応、コスト分析、モデル品質の評価、不正利用の検知といった目的で必要になります。

この7要素が、AIトークンガバナンスとして管理すべき範囲です。オープンウェイトモデルを使うかクローズドモデルを使うかにかかわらず、企業側で設計しなければならない領域はここに集約されます。

AIゲートウェイという実装手段

前節が「何を統制するか」だとすれば、AIゲートウェイは「どう実装するか」にあたります。

なぜモデルの外側に必要なのか

モデル内部のガードレールは重要です。モデルが危険な要求を拒否したり、有害な回答を避けたりするための学習や制御は、安全なAI利用の基礎になります。

しかし、企業のすべてのルールをモデル内部だけで実現することはできません。企業ごとに、組織、データ、契約、業務、承認方法が異なるためです。

たとえば、ある企業では顧客名を外部AIへ送信できない一方、別の企業では専用契約を結んだ環境に限って送信できるかもしれません。同じ会社でも、人事部門と開発部門では、利用できるデータやモデルが異なります。社内FAQの回答は自動化できても、取引先へのメール送信には承認が必要かもしれません。

一般的なモデルの安全ポリシーは、こうした企業固有のルールまでは判断できません。そのため、モデルと利用者の間に、企業独自の統制を適用するレイヤーが必要になります。

AIゲートウェイの機能

AIゲートウェイとは、利用者、業務アプリケーション、AIエージェントと、AIモデルの間に配置される統制レイヤーです。利用者やアプリケーションがモデルへ直接接続するのではなく、AIゲートウェイを経由することで、共通の企業ポリシーを適用します。

前節の7要素に対応させると、次のようになります。

これに加えて、問題が見つかったモデル、ユーザー、アプリケーション、用途を迅速に停止する緊急遮断の機能が必要です。

また、入出力の安全性判定については、gpt-oss-safeguardやShieldGemmaのような安全性分類モデルを、このレイヤーに組み込むこともできます。3社が提供している部品を、企業のポリシーの中で使う形です。

ここで挙げたのは、AIゲートウェイという仕組みが一般に担う機能の整理です。個々の機能を具体的にどう実装するかは製品によって異なります。

RiN Gatewayのような仕組みを利用する価値

RiN GatewayのようなAIゲートウェイの役割は、特定のモデルを「絶対に安全なモデル」に変えることではありません。モデルそのものの能力や安全性試験は、モデル開発企業や評価機関が担う領域です。

AIゲートウェイが担うのは、モデルを企業のルールの中で利用できる状態にすることです。

正確には、次のように表現できます。

RiN Gatewayは、オープンウェイトモデルとクローズドモデルを含む複数のAIモデルを、企業の権限、データ、用途、コスト、監査のルールに基づいて利用するための統制基盤です。

念のため明記しておきます。Anthropicの声明は、RiN Gatewayを直接評価・推薦したものではありません。OpenAIやGoogleの発表も、RiN Gatewayに言及したものではありません。

しかし、3社の公式情報は、モデル内部の安全対策だけでなく、利用時の外部統制が必要であることを示す論拠として参照できます。特に、OpenAIがオープンウェイトモデルの導入企業に対して「システムレベルの保護を再現する必要がある」と明記している点、そしてOpenAIとGoogleがいずれも別建ての安全性分類モデルを提供している点は、システムレベルのガードレールが必要であることを示しています。

そのうえで、前述のとおり、安全性分類はシステムレベルの統制の一部にすぎません。認証、権限、モデル選択、機密情報、利用量、外部システム操作、承認、監査ログは、企業が別途設計する必要があります。AIゲートウェイは、これらを一つの企業ポリシーとして管理するための基盤になります。

RiN Gatewayにおける各機能の仕様、対応モデル、導入方法についてはRiN Gatewayのページに記載しています。

オープンウェイトとクローズドを同じポリシーで管理する

企業のAI環境は、今後さらに複雑になります。すべての業務を一つのモデルだけで処理するのではなく、用途に応じて複数のモデルを使い分ける形が現実的です。

たとえば、次のような構成です。

• 高度な推論にはClaude
• 一般的な業務支援にはGPT
• Google Workspaceとの親和性が必要な業務にはGemini
• 閉域環境にはKimi K3やGemmaなどのオープンウェイトモデル
• 日本語特化業務には国内モデル
• 大量処理には低コストモデル
• 機密性の高い処理には自社専用環境

しかし、モデルごとに認証、権限、ログ、コスト管理を別々に設計すると、企業の統制は分断されます。さらに、社員やアプリケーションが各モデルへ直接接続すれば、どの情報がどのモデルへ送信されたかを把握できなくなる可能性があります。

そこで、モデルの種類にかかわらず、利用経路を共通化します。オープンウェイトモデルでもクローズドモデルでも、同じ入口を通し、同じ企業ポリシーを適用する。これにより、接続先のモデルを変更しても、企業のガバナンスを維持しやすくなります。

モデルを選ぶ自由と、利用を統制する責任

オープンウェイトモデルの普及は、企業にモデルを選ぶ自由をもたらします。企業は性能、コスト、処理速度、データ所在地、ライセンス、カスタマイズ性、マルチモーダル対応、コンテキスト長、利用可能なハードウェア、サポート体制などを比較し、自社に適したモデルを選択できます。

一方で、その自由は、利用を統制する責任と表裏一体です。

モデル提供者のAPIを離れ、自社環境でモデルを運用するほど、安全対策、アクセス管理、利用監視、ログ管理、インシデント対応の責任は企業側へ移ります。OpenAIが「システムレベルの保護を再現する必要がある」と書いたのは、まさにこの移転を指しています。

したがって、オープンウェイト時代の企業AI戦略は、モデルの選定だけでは完結しません。モデル層と業務層を直接接続するのではなく、その間に統制層を置くことが設計の要点になります。

企業がオープンウェイトモデルを導入する際のチェックリスト

モデルとライセンス

• 商用利用が認められているか
• 改変や再配布が認められているか
• 禁止用途が定められているか
• 派生モデルに条件があるか
• 第三者に推論・ファインチューニングを提供する形態（Model as a Service）に該当するか
• 売上規模による追加条件があるか（Kimi K3 Licenseの場合、MaaS事業を営みグループ合計売上が連続12か月で2,000万米ドルを超えると、商用利用前にMoonshot AIとの別途契約が必要）
• 大規模利用時のブランド表示義務があるか（Kimi K3の場合、月間アクティブユーザー1億人超または月間売上2,000万米ドル超で「Kimi K3」のUI表示が必要）
• 社内利用の定義に自社の使い方が収まるか（出力や基盤能力を第三者に提供すると社内利用ではなくなる場合がある）
• 提供者の免責範囲はどこまでか
• ライセンス変更時の対応を決めているか

モデルの安全性

• どの安全性評価が実施されているか
• サイバー、生物、化学リスクを評価しているか
• 第三者評価が存在するか
• レッドチーミングが行われているか
• 安全対策を変更していないか
• ファインチューニング後に再評価しているか

インフラとセキュリティ

• モデルファイルの取得元は正しいか
• ハッシュ値や署名を確認したか
• モデル読み込み時の任意コード実行リスクを確認したか
• 推論サーバーに脆弱性がないか
• GPU環境へのアクセスを制限しているか
• 管理者権限を最小化しているか

データ管理

• 入力データはどこに保存されるか
• ログに機密情報が残らないか
• バックアップへ情報が残らないか
• 部署間のデータ境界を維持できるか
• 学習や改善に再利用されないか
• 保存期間を定めているか

権限管理

• 誰がモデルを利用できるか
• 誰が追加学習できるか
• 誰がシステムプロンプトを変更できるか
• 誰が外部ツールを接続できるか
• 誰が監査ログを閲覧できるか
• 退職・異動時に権限を停止できるか

入出力の安全性

• 個人情報を検知できるか
• 機密情報を検知できるか
• 不適切な入力を遮断できるか
• 不適切な出力を遮断できるか
• 独自ポリシーを適用できるか
• 誤検知と見逃しを継続評価しているか

AIエージェントの実行

• AIが何を実行できるか定義しているか
• 高リスク操作に承認を設けているか
• 最小権限になっているか
• 実行回数や金額に上限があるか
• 実行結果を追跡できるか
• 緊急停止できるか

監査と運用

• 誰がいつ利用したか記録されるか
• どのモデルとバージョンを使ったか分かるか
• 入力と出力を追跡できるか
• ポリシー判定結果を記録しているか
• 実行した操作を追跡できるか
• モデルの更新前後で評価しているか
• インシデント対応責任者が決まっているか

よくある質問

参照した一次情報

記事情報

改訂履歴