OpenAIは2025年8月、Apache License 2.0のもとでモデルウェイトを公開した gpt-oss-20b / gpt-oss-120b をリリースしました。重要な前提として、GPT-OSSは OpenAIのマネージドAPI（OpenAI API / ChatGPT）から直接呼び出して利用する提供形態ではありません。モデルをダウンロードし、ローカル環境(企業が自社で管理するGPU 基盤など)で実行できる「オープンウェイトモデル（モデルの学習済みパラメータが公開され、自社環境にダウンロードして実行・改変できる形態）」 として提供されます。

このように、これまでクローズドモデルの提供が中心だった OpenAI が、ユーザー自身の環境で実行可能なモデルを本格的に公開したことで、自己所有GPU＋オープンウェイトLLMを組み合わせた「ローカルLLM」として利用できる選択肢が広がりました。
OpenAI API の従量課金を伴わずに利用できるため、外部 API 課金に依存しないローカル LLM 基盤を構築しやすく、実質的に「API 利用料が発生しない」推論環境を自社で持てる点は、多くの企業にとって大きなメリットといえるでしょう。

本記事では、GPT-OSSの技術仕様、既存のオープンウェイトLLMとの違い、自社GPU環境での運用パターンを整理し、評価・安全性・再現性を考慮したローカルLLM設計のポイントを解説します。

1. GPT-OSSとは?

GPT-OSSは、OpenAIが2025年8月に公開した、Apache License 2.0のもとで提供されるオープンウェイトLLMです。OpenAIがモデルウェイトを公開するのはGPT-2以来およそ6年ぶりであり、ローカル環境(企業が自社で管理するGPU 基盤など)にダウンロードして実行・改変できる本格的なオープンウェイトモデルとして位置付けられます。

GPT-OSSは、gpt-oss-20b（約21Bパラメータ）とgpt-oss-120b（約117Bパラメータ）の2モデルで構成されており、それぞれ想定されるGPU要件やユースケースが明確に分かれたラインアップとなっています。性能面では、gpt-oss-20bは一般的な推論・知識系ベンチマークにおいてo3-miniと同様の結果を出し、わずか16 GBのメモリを搭載したエッジデバイスで実行でき、比較的軽量な推論モデルとして位置付けられます。一方、gpt-oss-120bは推論系ベンチマークにおいてo4-miniとほぼ同等の結果を達成します、AIME 2024 / 2025、HLE、MMLUなどの評価指標において、OpenAIのクローズドモデル（o3 / o3-mini / o4-mini）などの独自モデルよりも一部の reasoning ベンチマークで優れたパフォーマンスを発揮します。

2. GPT-OSSのモデル仕様

GPT-OSSを自社GPU環境で運用するには、モデルの技術的な仕様を理解する必要があります。ここでは、アーキテクチャの特徴と推奨構成を整理します。

2-1. モデル構成

GPT-OSSのコアとなるのは、gpt-oss-20bとgpt-oss-120bの2つのモデルで、いずれもApache 2.0ライセンスで提供されています。これらをベースに、安全性推論に特化したgpt-oss-safeguard-20b / 120bも公開されており、パラメータ数・アクティブパラメータ・コンテキスト長は、それぞれgpt-oss-20b / 120bと同じ構成になっています。

まず、gpt-oss-20b / 120b本体の基本構成を確認します。

上記のモデルは、テキスト専用モデルで、STEM・コーディング・一般知識に重点を置いた英語中心のデータセットで事前学習されています。トークナイザーは、o4-miniやGPT-4oで使われるもののスーパーセットとしてo200k_harmony（最大約20万トークンの長コンテキスト入力を前提とした、OpenAI共通のトークナイザー設定）が使われ、これもオープンソース化されています。

gpt-oss-safeguardは、上記gpt-oss-20b / 120bをベースに後続で追加された安全性・モデレーション用途の派生モデルとして公開されています。推論モデル(gpt-oss)と安全性モデル(gpt-oss-safeguard)をまとめて自社GPU上に配置できるため、ガバナンスを自前で設計したい企業にとって有用な構成となるでしょう。

2-2. アーキテクチャの特徴

GPT-OSSは、限られたGPUメモリで高性能な推論を実現するための効率化（MoE／MXFP4／長コンテキスト）に加え、ツール呼び出しや推論過程を統一的に扱うためのフォーマット（Harmony）など、いくつかの技術的工夫が施されています。

Mixture-of-Experts(MoE:専門家混合モデル)構成

パラメータ総数は20B / 120Bと大きいものの、全体を使うわけではなく必要な部分だけに限って使うことで、トークンごとにアクティブになるエキスパートは一部(4つ)に限られます。そのため、実行時計算量を抑えつつ、モデル全体としては大きな表現力を確保する設計となっています。
たとえばgpt-oss-120bでは、128個のエキスパートのうち4つのみがアクティブになるため、実際の計算負荷は約5.1Bパラメータ相当に抑えられます。この仕組みにより、大規模モデルでありながら推論速度とメモリ効率を両立できる構成となっています。

MXFP4量子化

GPT-OSSは、MoEの重みを中心にMXFP4（Microscaling FP4：Microscaling形式の4ビット浮動小数点フォーマット）を用いた量子化で効率化する設計が示されています。これにより、比較的小さいメモリ容量でも実行できることを狙った説明が公式に提示されています。MXFP4自体は、Open Compute ProjectのMicroscaling Formats(MX Formats)文脈で整理されている"マイクロスケーリング系"フォーマットです。実行時の性能・対応はGPUや推論ランタイムの実装に依存するため、採用時は利用するスタック側の対応状況を前提に検証が必要です。

コンテキスト長

GPT-OSSは、128kトークン(131,072トークン)の長コンテキストに対応しています。ただし、コンテキスト長を伸ばすほどKVキャッシュ（推論時に過去の入力情報を保持するメモリ領域）のメモリ使用量が増え、レイテンシ（リクエストから応答までの待ち時間）も伸びるため、実務では入力32k〜64k+出力数千トークン程度に抑えたうえで、バッチサイズを増やす設計が有効です。

Harmony Response Format

gpt-ossはHarmonyプロンプト形式（ツール呼び出し・推論過程・ロール指定などを統一的に扱うための、GPT-OSS専用のチャットテンプレート）で事後学習されているため、Harmonyに対応したテンプレート/ランタイムを前提に扱います。なおここは誤解が生まれやすい点ですが、「web browsing / Python code executionができる」=モデル単体が勝手にWebやPythonを実行するという意味ではありません。

モデルが出力するのはツール呼び出しの"指示(フォーマット)"なので、実際にWeb検索やコード実行を行うには、開発者側で対応ツール(検索・実行環境)を接続して"動かす"必要があります。

3. GPT-OSSを自社GPUで動かす

GPT-OSSを実際に運用する際には、用途や規模に応じた適切なGPU構成を選択する必要があります。ここでは、開発・検証から本番運用まで、代表的な構成パターンと推奨スペックを紹介します。

3-1. 開発・検証向けワークステーション1台構成(20b)

開発初期段階や検証で、単一ワークステーションでGPT-OSSを運用する場合には次のような構成が想定されます。

想定構成

• GPU：VRAM 16GB以上の単一GPU（RTX 4090等）
  OpenAI公式では「16GBメモリのエッジデバイスでも動作可能」と記載されています(参考：OpenAI)
• CPU・システムメモリ・ストレージ：推論エンジン（vLLM / Ollama等）の推奨要件に準じて選定
  20b想定の単一ワークステーション構成から始めると、将来的なGPUサーバー構成への移行もスムーズに行えるという利点があります。

3-2. 社内小規模推論基盤・運用検証向けサーバー構成(20b/120b)

検証段階を経て運用検証や小規模な社内展開へ進む際には、複数GPUやより大きなメモリを持つサーバー構成が有効です。

想定構成

• GPU：20b中心の場合： VRAM 16GB以上の単一〜複数GPU構成、120bの場合： VRAM 80GB以上のGPU（H100等）を追加し、20b用GPUと使い分け
  OpenAI公式では「120bは単一の80GB GPUで実行可能」と記載されています（参考：OpenAI)
• CPU・システムメモリ・ストレージ：推論エンジンおよび同時リクエスト数に応じて選定
  CPUメモリ側にもシステム用途・バッファ・推論サーバー管理領域としてある程度の余裕が必要です
• ネットワーク：社内LANからのアクセスを前提とした構成

3-3. ローカルLLMスタックとの組み合わせ方

実装面では、GPT-OSS単体ではなく、既存のローカルLLMスタックと組み合わせることが重要です。

• vLLM：
  高スループット（単位時間あたりに処理できるデータ量）・低メモリオーバーヘッドな推論エンジンです。OpenAIのガイドでも「GPT-OSSをサーバーとして構築する方法」が公開されており、Agents SDKとの連携も想定されています。
• Ollama / LM Studio：
  デスクトップ環境向けのGUIツールです。Harmonyフォーマットを内部で処理するため、初期検証に適しています。CI/CDへの組み込みには追加の設定が必要となる場合がありますが、ローカル検証には有用です。
• Transformers + openai-harmony：
  Pythonスタックで詳細なカスタマイズを行う場合の選択肢です。Transformersのchat templateや、openai-harmonyパッケージを用いてHarmonyを適用しつつ、独自の前処理・後処理を組み込むことができます。

いずれのパターンでも、GPUクラスに応じて、ローカルで処理する範囲とクラウドAPIや他モデルに委譲する範囲を決定することが運用設計上の重要なポイントとなります。

4. ローカルLLMとしてのユースケース

GPT-OSSをマネージドAPIではなくローカルLLMとして運用することで、どのような価値が得られるのでしょうか。ここでは、ローカルLLMならではの活用シーンと、そのメリットを整理します。

4-1. ローカルLLM・社内RAGの評価・チューニング

ローカルLLM+RAGの評価環境としての活用が考えられます。モデルバージョンや実行条件を固定できるため、再現性の高い評価が可能になります。

• 複数のオープンウェイトLLM(Llama / Mistral / Phiなど)とのベンチマーク比較
• 社内ナレッジベースを使用したRAGの再現性の高い評価
• APIモデル vs GPT-OSS vs 他オープンウェイトLLMの比較実験

こうした用途では、同じGPU・同じデータで繰り返し実験できることが重要な価値となります。API環境のみに依存すると、モデルアップデートやレートリミットの影響を受けやすく、実験の再現性確保が困難になる場合があります。ローカルに固定バージョンを保持する意義は大きいと言えます。

4-2. エージェント・ワークフローの再現性検証

GPT-OSSは、CoT(Chain-of-Thought)推論・ツール利用(tool calling)・エージェントタスクに最適化された設計となっています。エージェント開発では、プロンプトやツール設計の微調整が必要になることが多く、検証環境での再現性確保が重要です。

ローカルGPUサーバー上でGPT-OSSを運用することで、次のようなワークフローが実現できます。

• プロダクション環境ではo3 / o4 / Gemini / ClaudeなどのマネージドAPIを使用
• 検証環境ではGPT-OSSを使用して以下を実施
  • プロンプト・ツール設計のA/Bテスト
  • ログを使用した再プレイ(replay)
  • 失敗ケースの再現・デバッグ

注意点として、GPT-OSSが出力する「ツール呼び出し」を実際に実行するのはアプリ側です。つまり、Web検索やPython実行は接続したツールが動くのであり、モデルが単体で外部環境を直接操作するわけではありません。また、推論の強さはreasoning effort(low/medium/high)をシステムメッセージで指定して調整できます。

4-3. 安全性評価・コンプライアンス対応(gpt-oss-safeguardの活用)

安全性・コンプライアンスの観点では、gpt-oss-safeguardの活用が有効です。自社で定義した安全基準に基づくモデレーション基盤を、外部APIに依存せず構築できる点が重要な価値となります。

• 自社で定義した「安全ポリシー」「業界ガイドライン」「社内ルール」をプロンプト化
• gpt-oss-safeguardにログ・ドキュメント・会話履歴を入力して分類・スコアリング
• 必要に応じて、人間によるレビュー・エスカレーションフローへ接続

このようなBYOポリシー型のモデレーション基盤を、自社GPUのみで構築できます。

また、gpt-oss本体と同じクラスタ上で動かすことで、次のフローもAPIに依存せず社内環境のみで完結させることが可能です。

• 生成前後の安全チェック
• 高リスク出力のブロック/要レビュー化
• モデル更新時の安全性回帰テスト

5. まとめ

本記事では、OpenAIが公開したオープンウェイトLLM「GPT-OSS」について、その位置づけ、モデル仕様、自社GPUでの運用パターンを整理しました。クラウドAPIのみではコントロールしづらい「再現性」と「安全性」を、自社環境でモデルをホストすることで確保できる点が、GPT-OSSを採用する大きな意義になります。一方で、gpt-oss-20b / 120bの性能を引き出すためには、モデル規模やコンテキスト長に見合ったGPUメモリ、消費電力・設置条件を含めたハードウェア選定、RAGやエージェント基盤を見据えた構成設計が欠かせません。段階的に評価環境を立ち上げつつ、本番運用までを見通したGPU投資の計画が重要になります。

GPT-OSSやその他のオープンウェイトLLMを前提に、自社GPU上での評価環境・推論基盤の構築をご検討中の場合は、ワークロードやご予算、運用体制に合わせた最適なGPUサーバー／ワークステーション構成をご提案いたします。具体的な構成やコストの試算については、ぜひNTTPCまでご相談ください。
▶︎ お問い合わせはこちら

※「OpenAI」「ChatGPT」は、OpenAI, Inc.の商標または登録商標です。
※「Python」は、 Python Software Foundation (PSF)の商標または登録商標です。
※「vLLM」は、vLLM Projectの商標または登録商標です。
※「Ollama」は、米国のOllama Inc.の商標または登録商標です。
※「RTX」は、 NVIDIA Corporationの商標または登録商標です。
※「Llama」は、 Meta Platforms, Inc.の商標または登録商標です。
※「Mistral」は、 Mistral AI SASの商標または登録商標です。
※「Gemini」は、Google LLCの商標または登録商標です。
※「Claude」は、Anthropic, PBCの商標または登録商標です。

※本記事は2026年3月時点の情報に基づいています。モデルに関わる情報等は予告なく変更される場合がありますので、あらかじめご了承ください。Open AIが公表している最新の情報が優先されます。