IBMは、オープンな推論言語モデル群「Granite 4.2」を公開した。ラインアップは30億、80億、300億パラメータの3種類で、企業や開発チームが計算資源や用途に応じて選べる構成だ。これまでのGraniteが、指示に従って回答するアシスタントとしての性格を強く持っていたのに対し、4.2では回答前に問題を段階的に検討する「明示的な推論」が設計の中心に置かれた。ユーザー側は、十分に考えさせるモード、推論を省くモード、簡単な質問だけ短い推論予算で処理する低負荷モードを切り替えられる。



この切り替えは、企業システムで特に意味を持つ。複雑なコード修正や調査では推論時間を確保し、定型的な分類や短い要約では応答速度を優先する、といった運用設計が可能になるからだ。ただし、モデルが内部で生成する思考過程をそのまま利用者に見せるべきかは、情報管理やユーザー体験の観点から別途検討が必要になる。重要なのは、精度、待ち時間、計算コストのバランスを用途ごとに調整できる点にある。

3モデルはいずれも、後述するApache License 2.0で提供される。さらにIBMは同時に、音声を文字へ変換する「Granite Speech 5.0 Turbo CTC」も発表した。こちらは4億7,000万パラメータで、LLMを土台にしない音声認識モデルだ。今回の発表は、単に新しいチャットモデルを増やしたというより、推論、ツール実行、長文処理、音声認識を企業が自社環境へ組み込みやすい形でそろえる動きとして捉えると分かりやすい。

Granite 4.2の実務上の大きな特徴は、3モデルすべてがApache License 2.0で公開されたことだ。このライセンスでは、モデルのダウンロード、追加学習、商用環境での利用にライセンス上の大きな障壁が設けられていない。もちろん、実際の導入時にはデータの利用条件、生成物の扱い、セキュリティ、各業界の規制を個別に確認する必要があるが、少なくともモデル本体については、企業が検証から本番展開まで進めやすい選択肢になっている。



30億パラメータ版は、ノートPC上でOllamaやLM Studioを使って試す個人開発者やスタートアップを想定しやすい。原文では、計算量を抑えたGGUF量子化版としてQ4_K_Mまで提供される点が紹介されている。80億パラメータ版は、比較的新しい単体GPUを用意できる中堅企業や開発チームに適する位置付けだ。300億パラメータ版は、A100やH100クラスのGPU基盤を持つ企業、あるいはvLLM上でFP8やNVFP4といった低精度形式を使って配信する組織が主な対象となる。

モデルサイズの違いは、単なる精度差ではない。必要なメモリー、応答速度、同時処理数、導入費用、追加学習のしやすさが変わるため、最適な選択は業務によって異なる。機密情報を外部サービスへ送れない金融、医療、公共分野では、重みを自社環境に置けること自体が価値になる。一方、すべての業務に最大モデルを使うと費用対効果が悪化しやすい。まず30億または80億版で定型処理を検証し、難しいタスクだけ300億版へ振り分ける設計も、現実的な選択肢として考えられる。

Granite 4.2は、入力を受けて次のトークンを順番に生成するdecoder-only型の「密なTransformer」である。複数の専門ネットワークから一部だけを選んで動かすMixture of Experts（MoE）ではなく、各推論で基本的にモデル全体を使う構成だ。構造が比較的素直なため、既存の推論基盤や最適化技術へ載せやすい一方、同規模のMoEと比べた計算効率は、運用条件と実装を含めて評価する必要がある。



中核技術には、KeyとValueの計算を共有してメモリー負荷を抑えるGrouped Query Attention、長い系列で位置を表現するRoPE、活性化関数を組み込んだSwiGLU MLP、学習を安定させるRMSNormなどが採用された。KVヘッドは8、RoPEのθは10,000,000、RMSNormのεは1e-5で、入出力の埋め込みは共有されていない。数値精度はbfloat16が基本とされる。30億版は40層・埋め込み次元2,560、80億版は40層・4,096、300億版は64層で、MLPの中間次元は32,768と報告されている。

公開されたアーキテクチャ表のシーケンス長は131,072トークン、一般に「128K」と呼ばれる規模だ。一方、5段階の事前学習には最大512Kトークンへ拡張する長文脈フェーズも含まれる。ここは混同しやすく、学習時に長い系列を扱ったことと、配布モデルで保証される実用上のコンテキスト長は同じ意味ではない。企業が長文RAGや大規模なコードベース分析へ使う場合は、公称値だけでなく、自社文書を使った検索精度、重要情報の見落とし、GPUメモリー消費を実測する必要がある。

Granite 4.2の技術的な中心は、モデル構造そのものより学習工程にある。3モデルは既存モデルの重みを流用するのではなく、およそ15兆トークンを用いてゼロから事前学習された。その後、約720万件、総量約1,000億トークンの教師あり微調整データが使われ、このうち学習対象として数えられるのは約650億トークンとされる。データ構成はエージェント型が31.6％、非エージェント型が68.4％で、エージェント型部分の69％をソフトウェアエンジニアリングが占めた。



学習用の実行履歴は、OpenHands、SWE-agent、Terminus-2、MiniSWE、Codex、Gooseなど複数のハーネスから生成された。ここでいうハーネスとは、モデルがコード編集、コマンド実行、結果確認を繰り返すための実験環境や制御枠組みを指す。品質管理ではGPT-OSS-120BとGemma 4を判定役として使い、ツール呼び出しとメッセージのフィールドにはSHA-256による重複排除を適用したと原文は説明している。さらに、IBMのCodeAlchemyパイプラインによる1兆トークンの合成コードも学習を支えた。

事後学習は1回の強化学習で終わらず、検証可能な報酬を使うRLVR、特定能力を伸ばすskill boosters、ソフトウェア開発、ターミナル操作、検索、最後に人間の選好へ合わせるRLHFという順序で進む。各段階は非同期GRPOとして個別に実行され、前段のチェックポイントを引き継ぐ。価値ネットワークの代わりにleave-one-out型の基準を置き、方策のずれを抑えるためtruncated importance samplingも用いる。難しい用語が並ぶが、要点は、正解判定や実環境での成否を段階的に学ばせ、最後に応答の望ましさを整える設計だ。

80億版と300億版には、実際に隔離されたサンドボックス環境でコードを編集し、ターミナルを操作し、Web検索を実行する「エージェント型強化学習」が組み込まれた。これは、ツールの使い方を文章として覚えるだけではなく、操作結果を観察して次の行動を選び、タスク完了まで試行を重ねる学習である。30億版は基礎的な強化学習とアラインメントのみで、このエージェント型ブロックは適用されていない。モデル規模間の能力差を見る際には、パラメータ数だけでなく、この学習工程の違いも考慮すべきだ。



学習にはNVIDIAのNeMo-RLとNeMo-Gymが使われ、CoreWeaveがホストするNVIDIA GB200 NVL72クラスター上で実行された。NeMo-Gymは、モデルが行動し、環境から結果や報酬を受け取る訓練の場を用意する。こうした実環境型の学習は、ソフトウェア修正、DevOps作業、深い調査を行う検索エージェント、構造化されたツール呼び出しなどに直結しやすい。推論を速めるため、将来の出力候補を先回りして検証するspeculative decodingの仕組みも用意された。

ただし、学習済みだからといって、企業の本番環境で無制限に操作権限を与えられるわけではない。コマンド実行には最小権限、書き込み可能な範囲の制限、ネットワーク接続先の許可リスト、操作ログ、重要変更に対する人間の承認が必要になる。エージェントの価値は自律性の高さだけでなく、失敗を閉じ込め、再現可能な形で監査できるかによって決まる。Granite 4.2はその実装基盤の候補だが、安全な業務フローの設計は導入企業側に残る。

IBMが示した結果では、300億版はSWE-Bench Verifiedで57.00、Terminal-Bench 2.1で29.24を記録した。80億版はそれぞれ47.67、20.56で、エージェント型学習のない30億版には両指標の値が掲載されていない。ツール利用を測るτ³-benchは30億、80億、300億版の順に50.99、66.34、68.05、関数呼び出しを評価するBFCL v4は52.41、50.29、61.39だった。モデルが大きければすべての評価で単調に伸びるとは限らないことも、この数値から読み取れる。



数学推論のAIME25は78.33、86.67、89.17、大学院水準の科学知識を含むGPQAは54.80、64.14、66.41、幅広い知識と推論を見るMMLU-Proは67.84、74.04、77.60だった。128Kの長文処理を測るRULERでは55.30、71.41、81.38と、モデル規模に伴う差が比較的明瞭に表れている。これらは、300億版が難しい推論や長文処理で有力である一方、80億版にも性能と運用コストのバランスを狙える余地があることを示す材料になる。

もっとも、ベンチマークは導入判断の出発点であって結論ではない。公開スコアは特定のプロンプト、推論設定、評価環境に依存し、実務データの品質やツール構成によって結果が変わる。企業は、正答率だけでなく、誤ったツール実行の頻度、タスク完了までの時間、GPU当たりの処理量、根拠提示、再試行時の安定性を測るべきだ。特にBFCLで80億版が30億版を下回るような項目は、モデルサイズのみで選定せず、目的別の小規模な実証実験が欠かせないことを示している。

言語モデルと同時に公開されたGranite Speech 5.0 Turbo CTCは、4億7,000万パラメータの音声認識モデルである。CTCはConnectionist Temporal Classificationの略で、音声フレームと文字列の厳密な位置合わせを事前に用意しなくても、音声からテキストへの対応を学習できる方式だ。今回のモデルはLLMバックボーンを完全に外し、音声認識に絞った構成を採用した。生成能力を広く持たせるより、高速な文字起こしへ資源を集中させた設計といえる。



IBMの報告では、H200を1基使った場合のRTFxは約12,600で、Open ASR Leaderboardにおける当時の高速モデルのおよそ6,000を上回るとしている。RTFxは、一定時間の音声を実時間の何倍の速さで処理できるかを示す目安で、値が高いほど大量音声を短時間で処理できる。ただし、この比較も音声の長さ、バッチ処理、精度条件、実装によって変化するため、数字だけで自社環境の速度を断定してはいけない。ブラウザ技術のWebGPUで試せるデモも公開されたと原文は伝える。

想定される用途は、コンタクトセンターの大量通話の文字起こし、会議録作成、字幕生成、音声アーカイブの検索可能化などだ。企業で重要になるのは速度だけでなく、日本語を含む対象言語の精度、専門用語や固有名詞への対応、話者分離、雑音環境での頑健性、個人情報のマスキングである。モデルをオンプレミスで運用できれば機密音声を外部へ出さずに済む可能性があるが、実際の対応言語や利用条件、必要な周辺処理は技術資料と検証環境で確認する必要がある。

Granite 4.2が示すのは、企業向け生成AIの競争軸が、チャット回答の自然さから「考え、道具を使い、業務を完了できるか」へ広がっていることだ。オープンな重みを使えるモデルでは、機密データを自社管理下に置き、業務固有の追加学習や推論設定を施しやすい。ソフトウェア開発、金融、医療、通信、公共分野など、監査性やデータ所在が重視される領域では、この自由度が採用理由になり得る。ただし、これは市場への影響に関する見方であり、個々の組織における適合性を保証するものではない。



導入は、まず業務を「文章生成」「長文検索」「コード変更」「端末操作」「音声認識」に分解し、各タスクの成功条件を定義するところから始めたい。次に、30億版で速度とローカル実行性、80億版でエージェント能力とコストの均衡、300億版で難しい推論や長文処理を検証する。同じ評価データを使い、正確さ、遅延、計算費、危険な操作、担当者による修正量を比較すれば、モデルの大きさではなく業務価値で選べる。RAGを使う場合は、モデル評価と同時に検索対象文書の更新、アクセス権、引用元の表示も設計する必要がある。

本番化では、推論モードを業務リスクに合わせて固定または切り替え、ツールごとに権限を分離することが重要だ。読み取り専用の検索から始め、コード提案、人間の承認付き変更、限定環境での自動実行へと段階的に広げると、効果と危険を観察しやすい。また、日本語の敬語や社内用語、国内法令に関わる回答は、英語中心の公開ベンチマークでは判断できない。日本語の実データを匿名化して評価セットを作り、誤りを止める仕組みまで含めてPoCを設計することが、Granite 4.2を企業資産へ変える現実的な一歩となる。