- 何が起きた: Aleph Alphaは10月3日、ドイツ語と英語に特化したAIモデル「Kolibri」の学習済み重みをApache 2.0ライセンスで公開した。
- なぜ重要か: 言語ごとに最適化した学習データと効率化技術により、企業や行政機関が自ら管理する設備で内部文書を扱える選択肢が増える。
- 次に見るべき点: 実際の独英文書でどれだけ誤回答するか、応答にかかる時間、必要なGPUメモリ容量が導入判断を左右する。
ドイツのAI企業Aleph Alphaは2026年10月3日、ドイツ語と英語に特化した大規模言語モデル「Kolibri」の学習済み重みを公開した。総パラメータ数は約781億だが、1トークンを処理する際に実際に使われるのは約34.6億で、Apache 2.0ライセンスの下、自社で管理する設備へ導入できる。
企業や行政機関にとっては、内部文書を外部のAI推論サービスへ送らずに処理するための新たな選択肢になる。最大約100万トークンという長い文脈長に加え、注目すべきなのは、ドイツ語の学習データを集める段階から、根拠がない質問には回答を控える訓練まで、業務利用を意識して設計している点だ。そこに、同社が掲げる「AI主権」の具体的な姿が見えてくる。
781億パラメータでも、毎回使うのは約34.6億
Kolibriは、入力に応じて使う部分を切り替えるMixture-of-Experts（MoE）型のモデルだ。各層では384個の専門ネットワークの中から6個を選び、常に使う共有ネットワークと組み合わせて計算する。
その結果、1トークン当たりに実際に有効になるパラメータは、全体の約4.4%に相当する約34.6億に抑えられる。多数のパラメータを備えながら、毎回すべてを計算しないことで処理量を抑える設計だ。
ただし、計算時に使うパラメータが少なくても、モデル全体の重みを保存するためのメモリは必要になる。公式モデルカードによると、FP8形式の重みだけで約78GBを占める。
最小構成の例として、NVIDIA H100 SXM5なら2基、H200やB200なら1基が挙げられている。さらに、長い文書を処理したり複数ユーザーの要求を同時に処理したりする場合には、途中の計算結果を保持するためのメモリも必要になる。
そのため、「実際に使うのは約34.6億パラメータ」という数字だけを見て、小規模なGPUでも容易に動かせるモデルと考えると、必要な設備を過小評価することになる。
長文処理の計算負荷についても、モデル構造で抑えている。全50層のうち40層は近傍の512トークンだけを参照し、残り10層が文脈全体を見る。
すべての層が全文を参照する方式に比べ、局所的な処理を担う層では、文書が長くなった際の計算量やメモリ消費を抑えやすい。
最大文脈長は1,048,576トークンだが、学習の最終段階で使用した文脈長は262,144トークンだった。
モデルカードでは、それを超える長さまで拡張して品質や運用効率を検証したとしている一方、応答速度や処理量を重視する用途、複雑なタスクでは262,144トークン以下を推奨している。
つまり、約100万トークンは技術上対応できる上限であり、約26万トークンは実運用でまず検討すべき長さという位置付けになる。
利用者は、回答前にどれだけ計算を使うかも「なし・低・中・高」の4段階から選べる。文書から項目を抽出するような単純な処理と、複数資料を突き合わせる複雑な処理で、計算量を調整できるわけだ。
日本語は主な対象言語に含まれていないため、ドイツ語や英語での性能から、日本語業務への適性をそのまま判断することはできない。
ドイツ語の行政文書を学習データから落とさない
Aleph Alphaは、Kolibriの事前学習に20兆トークンを使い、そのうち2割以上をドイツ語に割り当てた。
同社によれば、ドイツ語の性能を高めるには、英語の文章を単に翻訳して追加するだけでは不十分だった。ドイツ語データの構築について説明した同社ブログでは、翻訳文が文法的に正しくても、扱う地理、人口、制度などの偏りは元になった英語Webデータを引き継ぐと指摘している。
元からドイツ語で書かれた文章を残すためには、収集後のフィルタリングも言語に合わせる必要がある。
例えば、極端に長い単語を含む文章を除外する英語向けの基準をそのまま適用すると、複合語の多いドイツ語の行政文書まで誤って除外してしまう可能性がある。
同社はこうした基準をドイツ語向けに調整し、Common Crawlから約1.3兆の重複しないドイツ語トークンを収集した。
さらに、ドイツ語の原文を百科事典風の説明文や質疑応答形式へ書き換え、約1兆トークンの合成データも生成した。
これは新しい知識を追加するというより、同じ情報を異なる表現で学習させる手法だ。元の地域的・制度的な文脈を維持しながら、量の限られるドイツ語データを補う狙いがある。
文章をトークンへ分割する仕組みも、ドイツ語を意識している。
語彙数128,000のトークナイザー「UniBPE」は、ドイツ語の複合語を意味のまとまりに沿って分割するよう設計された。10月3日公開の技術報告書のFigure 5によると、同じドイツ語Webデータ「FineWeb-2」を処理した場合、1トークン当たりに含まれるUTF-8の平均バイト数はKolibriが4.90、GPT-5のトークナイザーが4.35だった。
Aleph Alphaが公表した平均値から計算すると、同じドイツ語Webコーパスを表現するためにKolibriが必要とするトークン数は、GPT-5のトークナイザーより約11.2%少ない。
同じバイト数の文章を処理する場合、必要なトークン数は1トークン当たりの平均バイト数に反比例するため、削減率は「（1−4.35÷4.90）×100」で求められる。
ただし、これは公開された平均値から算出した結果だ。個々の文書でトークン数が必ず11.2%減るわけではなく、応答時間や運用コストが同じ割合で下がることを意味するものでもない。
また、同じ学習データと語彙数を使った標準的なBPEでも平均4.89バイトと、UniBPEとほぼ同じ結果だった点には注意が必要だ。
技術報告書も、圧縮効率そのものは標準BPEと同等だと説明している。そのため、GPT-5との差をすべてUniBPE独自のアルゴリズムによる効果と考えることはできない。
ドイツ語を十分に含むデータを使ってトークナイザーを作る効果と、単語の構造を意識して分割する効果は分けて評価する必要がある。
根拠がなければ、無理に答えないよう訓練
Kolibriは、検索で取得した文書を基に回答するRAGや、外部ツールを呼び出す業務での利用を想定している。
行政手続きや工業製品の仕様を調べる場合、文章が流暢であること以上に、回答が渡された資料の内容に基づいているかどうかが重要になる。
質問自体がもっともらしくても、資料の中に答えがなければ、推測せず回答を控えることが求められる。
Aleph Alphaは、この挙動を学習させるために「Merlin-Arthur」と呼ぶ仕組みを使った。
学習対象のモデルをArthurとし、Merlinは質問に答えるために必要な情報を含む文書を作る。一方、Morganaは、その回答に必要な根拠を取り除いた文書を作る。
Arthurには、どちらの文書が与えられたかを知らせない。そのうえで、根拠が存在する場合には回答し、根拠がなければ回答を控えるよう訓練する。
例えば製品文書から特定部品の使用条件を答える課題なら、その条件が書かれている文書と、該当部分だけを取り除いた文書を用意する。
後者に対して、モデルが知識や推測だけで偶然正しい答えを出したとしても、正解とは扱わない。重要なのは答えそのものだけでなく、「この資料から答えられるか」を判断できることだからだ。
従来の「正しい回答を出せば評価される」訓練に加え、答えるべき状況と答えるべきでない状況を区別する能力を学ばせる仕組みといえる。
同社の評価では、非公開の先行モデルKolibri Originと比べ、根拠への忠実性や回答を控える能力が改善したとしている。
ただし、すべての質問で誤回答を防げるわけではなく、ベンチマークによって競合モデルとの優劣も変わる。
実際の業務で導入するなら、根拠がないのに答えてしまう割合と、本来答えられるのに回答を控えてしまう割合の両方を、自社や行政機関が実際に使う文書で測る必要がある。
「低コスト」という評価は測定条件まで見る必要がある
Aleph Alphaが公表した評価では、Kolibriは数学や専門知識のベンチマークで、同程度の活性パラメータを持つQwen3.6-35B-A3Bを上回った。
一方、ツール呼び出しや長文処理ではQwenの方が高い項目もある。
| 評価項目 | Kolibri | Qwen3.6-35B-A3B |
|---|---|---|
| AIME 2025（英語・数学） | 96.9 | 84.6 |
| GPQA Diamond（英語・専門知識） | 84.3 | 83.4 |
| BFCL v4（ツール呼び出し・総合） | 61.4 | 67.2 |
| LongBench Pro（長文処理） | 64.5 | 70.8 |
数値は10月3日の同社発表によるもので、いずれも高い方が良い。
得意分野があることは確認できるが、ドイツ語向けであることや学習済み重みが公開されていることを理由に、あらゆる用途で最も高性能だと判断することはできない。
同社が掲げる「品質と運用コストのパレート最適」という評価にも、前提となる測定条件がある。
技術報告書のAppendix Aでは、NVIDIA B200を8基搭載した1ノード上でvLLMを使用し、多数の要求を同時に処理した場合の生成速度を測定している。
複数の並列化方式を試し、途中の計算結果を保持するメモリをほぼ使い切る条件まで同時処理数を増やしたうえで、最も高い生成処理量を採用した。
コストの代わりに使われた指標は、GPU1基当たり毎秒どれだけの出力を生成できるかという処理効率だ。
モデルごとにトークンの分割方法が異なるため、単純に1秒当たりのトークン数だけを比較すると公平にならない。そこで同社は、トークン数に1トークン当たりの平均バイト数を掛け、実際に生成した文字列の量に近い指標へ換算している。
これは、大量の要求を並列処理するサービスでの生成効率を比較するには有用だ。
一方、文書を読み込む時間やツールの応答待ち、GPUの購入費、電力、運用人員などを含めた業務全体のコストを示すものではない。
また、比較モデルでは品質を主にBF16で測定し、生成速度はFP8で計測している。FP8へ量子化しても品質が十分に維持されるという前提も含まれている。
したがって、Kolibriについて同社が主張しているのは、比較したモデル群の中で、品質と大量生成時の処理効率を高い水準で両立したということだ。
少人数の利用者が長い文書を一件ずつ処理するような用途では、最大処理量よりも、文書を入力してから最初の回答が返るまでの待ち時間の方が重要になる可能性がある。
欧州で開発しても、供給網まで欧州だけで完結するわけではない
Kolibriはドイツのチームによって開発され、ドイツとフィンランドの計算基盤で学習された。事前学習にはNVIDIA B200を768基使用している。
さらに技術報告書では、追加学習用の合成データを生成する主要な教師モデルとして、GLM-5.2、GLM-5.3、Qwen3.8-27Bを挙げている。
つまり、欧州で自らモデルを設計・学習する能力を持つことと、ハードウェアや学習に使うモデルまですべて欧州製でそろえることは別である。
Aleph Alphaは、中国で開発された教師モデルが政治的に敏感な話題で偏りを持つ可能性についても認めている。
そのうえで、欧州の民主的価値観に沿った訓練データを追加し、教師モデルが生成した回答を検査した。
自由記述を含むデータについては、対話全体をgpt-oss-120bで分類し、中国共産党の見解に沿った回答を含む対話を除外する工程も開示している。
国際的に開発されたモデルを利用しながら、どの出力を自社モデルの学習に使うかは自ら管理するという考え方だ。ただし、この処理によって教師モデル由来の偏りを完全に取り除けたことまで実証されたわけではない。
学習データについても、同じように管理方法を明示している。
10月5日の発表によると、同社は450万件以上のURLを含むブロックリストを使って学習データを検査し、第三者データセットについてもライセンスや出所、利用拒否の意思表示への対応を確認した。
EUの汎用AI行動規範にも署名しているが、欧州委員会はこの規範を、AI Actの義務へ対応するための任意の手段と位置付けている。
行動規範へ署名したことや学習済み重みを公開したことだけで、導入先でのあらゆる利用方法が法的に問題ないと保証されるわけではない。
もう一つの特徴が、学習工程を継続的に管理できる体制だ。
同社は「Model Factory」と呼ぶ仕組みで、データ処理から学習、評価までを一連の工程として管理し、学習途中のモデルも継続的に検査した。
21日間の事前学習中に発生した38回の予期せぬ中断についても、自動的に復旧したとしている。
内部モデルKolibri Originは6月11日に事前学習を終え、Kolibriは9月11日に事前学習を完了した。この間隔は、短い期間でモデルを改良し、再び大規模学習を実行できる開発体制を示している。
ただし、Aleph Alphaが社内の学習工程を自ら管理できることと、すべての学習データや訓練コードが公開され、第三者が同じモデルを完全に再現できることは別である。
企業としての体制も変化している。
同社は10月5日時点で、Cohereとの統合に向けた合意を公表している。ただし、取引は規制当局の承認待ちで、完了するまでは両社が独立して運営されるとしている。
欧州の「AI主権」を評価する際には、モデルやサーバーがどこに置かれているかだけでなく、今後の改良方針や提供条件を誰が決定できるかも重要になる。
Kolibriを採用する企業や行政機関にとって、最終的な判断材料になるのは、自分たちが実際に使うドイツ語・英語文書に対する誤回答率、回答を控える割合、必要なGPUメモリ、実際の応答時間と処理量だ。
これらを自ら測定し、どこでモデルを運用し、どのように更新していくかまで選べる体制を整えて初めて、公開された学習済み重みを、日常業務で自ら管理できるAIへと変えられる。
