GPT OSSで自社LLMの開発が可能に!? 機密情報が漏洩せずLLM利用の最大のリスク「セキュリティ問題」が解決!
はじめに
この記事の概要
生成AIは業務効率化や意思決定の迅速化に大きな効果をもたらしていますが、企業が本格導入に踏み切れない最大の理由の一つが「セキュリティと機密情報保護」です。
特にクラウド型のAIサービスでは、入力したデータが外部サーバを経由するため、情報漏洩の懸念は常につきまとっています。
しかし2025年8月、OpenAIがGPT OSSを公開。オープンソースかつApache 2.0ライセンスで利用可能な大規模言語モデル(LLM)が登場したことで、 ”完全に自社管理できる“オンプレミスAI” という選択肢が現実になりました。
本記事では、このGPT OSSの特徴、セキュリティ面でのメリット、コスト、具体的な導入シナリオについて解説します。
対象読者
- AI導入に伴うセキュリティが気になっている方
- 自社LLMの開発について気になっている方
本記事で得られること
- クラウド型LLMとGPT OSSの違いが理解できる
- GPT OSSのライセンス(Apache 2.0)を理解できる
- 従来のセキュリティリスクと、それをGPT OSSがどう解決するかを把握できる
- 自社LLM開発やGPT OSSを使ったPoCの費用感を具体的に理解できる
- 有効な活用事例がイメージできる
GPT OSS, OpenAI APIの違い
項目 | OpenAI API | GPT OSS |
---|---|---|
提供形態 | API | モデル重み(OSS) |
実行場所 | OpenAIクラウド | 自社サーバや任意環境 |
データ送信 | 必須 | 不要(ローカル完結可) |
カスタマイズ | API連携+パラメータ調整 | モデル改変・再学習可能 |
ライセンス | サービス利用規約 | Apache 2.0 |
GPT OSSはモデル自体をダウンロードし、自社の閉域環境で稼働できるため、クラウド型とは根本的にセキュリティ特性が異なります。
ここでは、OpenAIの「OpenAI API」「GPT OSS」という2つの提供形態を比較しました。
GoogleのGeminiやMicrosoft Copilotも、同じ観点(提供形態/実行場所/データ送信要否/カスタマイズ範囲/ライセンス)で整理できます。
位置づけの違い
サービス | 位置づけ | 主な利点 | 注意点 |
---|---|---|---|
OpenAI API | 高性能モデルをAPIで利用 | インフラ不要、運用が楽 | ベンダ依存・データは外部送信 |
GPT OSS | モデル重みを取得して自前運用 | 最高のコントロールとデータ主権 | インフラ準備・運用は自社責任 |
使い分けの指針
判断軸 | 推奨 | 補足/ポイント |
---|---|---|
セキュリティ/データ主権最優先 | GPT OSS | 閉域運用・ログレス設計が可能(データを外部に出さない) |
即導入・開発コストを低くする | OpenAI API | インフラ不要で即利用、運用負荷が小さい |
高度なカスタマイズ(微調整・推論最適化・コスト最適化) | GPT OSS | 重み・推論ランタイムを制御でき、最適化の余地が大きい |
コスト | API:従量課金 OSS:自前GPU+運用コスト |
GPU/運用コスト ⇔ トークン課金 のトレードオフ (初期費用はAPIが低い) |
Apache 2.0ライセンスが意味すること
Apache 2.0は、企業が安心して使える「ゆるめのルール」のオープンソースライセンスです。
-
商用利用が自由
→ 作ったシステムやサービスに組み込んで販売してもOK。追加の契約や許可は不要。
-
改造や再配布も自由
→ モデルの中身を自社向けに改良したり、社内専用版を配布してもOK。
-
守るべきルールは少ない
→ 著作権表示と免責表示を書くだけで利用OK。
-
特許も安心して使える
→ もし開発元が持つ特許が関係していても、利用のための許可がセットでついてくる。
つまり、
「制限が少ないため、非常に自由に自社のAIシステムを作ることができる」
ライセンスです。
従来のLLM(Cloud版)のリスクとGPT OSSによるセキュリティ革新
従来のリスク
- クラウド送信時にデータがサーバ上に保持される可能性
- 入力データがモデルの再学習に利用されるリスク
- 機密性の高い文書(契約書、設計図、顧客情報)を外部送信できない制約
※ Azure OpenAIなど一部は学習利用を明確に制限していますが、多くのクラウドLLM(APIなど)では、モデルの学習にデータが利用される利用規約となっています。
💡 社内機密情報がモデル学習に利用され、情報が漏洩する危険があった!
GPT OSSでの変化
- モデルを社内環境に完全配置可能
- 外部送信ゼロで推論実行
- 学習やデータ保持もすべて自社管理下
💡 情報漏洩の可能性を構造的に排除
有効な実装ケース
(1) RAGボット
- 社内ナレッジベースと連携し、閉域ネットワーク内で稼働
- FAQ、契約書レビュー、技術仕様検索などに活用
- 機密データも安全に扱える
(2) オンプレミス環境での業務AI化
- 法務・監査・研究開発など、外部送信が許されない領域
- 金融・医療・製造業などコンプライアンスが厳しい業種
- 社内限定のドキュメント生成や分析業務
GPT OSS利用のための具体的な費用感
前提
(※ 技術担当者以外は、結論以降は読み飛ばしてください。)
- 20Bでは、Google Colaboratory pro版 でPoCすることと、AWSのEC2上にデプロイすることを目指します。
- 120Bでは、AWSのEC2上にデプロイすることを目指します。
結論
【PoC】
LLM | GPU/環境 | サービス | コスト |
---|---|---|---|
20B | A100(Colab Pro) | Google Colaboratory Pro | 約 1,200円/月 |
【AWSにデプロイ】
LLM | GPU | インスタンス タイプ |
オンデマンド料金(USD/h, 東京) |
---|---|---|---|
20B | NVIDIA L4 24GB | ・g6.2xlarge ・g6.4xlarge |
1.41781〜1.91903 |
120B | NVIDIA A100 80GB H100 80GB |
・p4de.24xlarge ・p5.48xlarge |
37.6223〜68.80 |
20Bモデル:PoC
Google Colaboratory proのA100 GPUを利用します。
気になる方は、このコードを参考に動かしてみてください。
'''
【GPT OSS 20BをGoogole Colaboratoryで動かす】
1. 「ランタイム」→「ランタイムのタイプを変更」
2. 次のどれかのGPUタイプを選ぶ
- T4 GPU
- L4 GPU
- A100 GPU
3. 「パッケージのインストール」セルを実行
4. 「LLM推論」セルを実行
'''
# パッケージのインストール
!pip install -q --upgrade torch
!pip install -q git+https://github.com/huggingface/transformers triton==3.4 git+https://github.com/triton-lang/triton.git@main#subdirectory=python/triton_kernels
!pip uninstall -q torchvision torchaudio -y
!pip install --upgrade accelerate transformers kernels
# LLM推論
%env PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
from transformers import pipeline
import torch
model_id = "openai/gpt-oss-20b"
system_prompt = 'You are a smart assistant. Reply simply'
input_message = 'Where is the capital of Japan?'
def generate(input_message):
pipe = pipeline(
"text-generation",
model=model_id,
torch_dtype="auto",
device_map="auto",
)
messages = [
{"role": "system", "content": system_prompt},
{"role": "user", "content": input_message},
]
outputs = pipe(
messages,
max_new_tokens=256,
)
return outputs[0]["generated_text"][-1]["content"]
output_message = generate(input_message)
print(output_message)
20Bモデル:EC2上にデプロイ
Hugging Face公式情報より、
The models are trained with native MXFP4 precision for the MoE layer, making
gpt-oss-120b
run on a single 80GB GPU (like NVIDIA H100 or AMD MI300X) and thegpt-oss-20b
model run within 16GB of memory.
と記述があり、
- 16GB GPU
のスペックが必要です。
AWSのEC2では、
- g6.2xlarge(L4×1, vCPU 8, GPU VRAM 24 GiB, システムRAM 32 GiB)
- g6.4xlarge(L4×1, vCPU 16, GPU VRAM 24 GiB, システムRAM 64 GiB)
の順にインスタンスを試すことが推奨されます。
g6.2xlarge では、
Single GPU VMs — g6.2xlarge: GPU 1, GPU Memory 24 GiB, vCPUs 8, Memory 32 GiB, Network “Up to 10 Gbps”.
G6 instances feature up to 8 NVIDIA L4 Tensor Core GPUs with 24 GB of memory per GPU
AWS公式情報より、
24GiB GPU(g6.2xlargeの性能) > 24GB GPU > 16GB GPU(GPT OSS 20Bの要件)
であり、最初の手段として試すと良いです。
次に g6.4xlarge は、g6.2xlargeでスループットや同時実行に余裕がない場合に試してみると良いです。
Single GPU VMs — g6.4xlarge: GPU 1, GPU Memory 24 GiB, vCPUs 16, Memory 64 GiB, Network “Up to 25 Gbps”.
AWS公式情報より、CPU/RAM/ネットワーク(最大25 Gbps)の増強で同時実行・KVキャッシュ・入出力の余裕が得られます。
120Bモデル:EC2上にデプロイ
Hugging Face公式情報より、
The models are trained with native MXFP4 precision for the MoE layer, making
gpt-oss-120b
run on a single 80GB GPU (like NVIDIA H100 or AMD MI300X) and thegpt-oss-20b
model run within 16GB of memory.
と記述があり、
- 80 GB GPU(単一GPUで収まる仕様)
AWSのEC2では、80GB VRAMを持つGPUを搭載するインスタンスが必要で、候補は以下の通りです。
- p4de.24xlarge(A100×8, GPU VRAM 80 GiB/枚, システムRAM 1.1 TiB)
- p5.48xlarge(H100×8, GPU VRAM 80 GiB/枚, システムRAM 1.9 TiB)
120Bを動かすには両方ともオーバースペックですが、要件を満たすこれより小さいインスタンスが存在しないため、コストが嵩んでしまいます。
まとめ
GPT OSSは、これまで企業が抱えていた**「生成AI導入の最大の障壁であるセキュリティ懸念」**を根本から解消します。
オンプレミス運用により、機密データが外部に出るリスクをゼロに近づけながら、高性能な生成AIの恩恵を享受できます。
Discussion