【解説】Tekken トークナイザーとは何か? 〜 Mistral が採用する新世代トークナイザーの特徴

【解説】Tekken トークナイザーとは何か? 〜 Mistral が採用する新世代トークナイザーの特徴

こんにちは!

本日は、Tekkenについて解説いたします!

皆さま Tekken と聞いて何を思い浮かべますか?

格ゲーの鉄拳でしょうか?

私は、昔プレイした Age of Empires に登場する鉄剣戦士を思い浮かべました🤗
ちょっと古いかもしれませんが、名作です!

さてつかみはこのくらいにして、、
LLMはご存じのとおり驚異的なスピードで進化しています。そんな中でひそかに注目されているのが、トークナイザーの改善です。

たとえば、Meta の Llama 系モデルのトークナイザーは Sentence Piece から BPE系へ進化するなど、LLM業界では従来よりも高効率なトークナイズ(テキスト分割)の方法を導入し始めています。

そして Mistral AI もまた、新たに「Tekken トークナイザー」という仕組みを採用し、大規模言語モデルの性能を底上げしています。

本記事では、Tekken トークナイザーの登場背景や技術的特徴、他のトークナイザーとの違い、さらには Mistral との関係などをわかりやすく解説していきます。


1. Tekken トークナイザーの登場背景

1-1. Mistral AI と長大コンテキストへの挑戦

Mistral AI(以下、Mistral)はLLM業界で最も注目されているスタートアップの1つで、従来モデル(例:Mistral 7B)に続き、大規模なコンテキスト長をサポートするMistral NeMoなどのシリーズをリリースしています。特に Mistral NeMo は 128k にものぼる巨大なコンテキスト長を持つことが特徴です。

先日(2025/1/30)に発表された Mistral Small 3 も32Kコンテクストをもっています。

このように大きなコンテキストを扱う上で非常に重要になるのが、1 トークンあたりの情報量を増やすことです。もしもトークナイザーが非効率だと、実際の入力テキストが “かさばって” しまい、128k トークンのコンテキストがあっても十分に使い切れません。

そこで Mistral は、従来の SentencePiece や BPE(Byte-Pair Encoding)の代わりに、Tekken トークナイザーを開発・導入し、より効率の良いトークナイズを実現しました。

1-2. リリース時期

Tekken トークナイザーが初めて一般公開向けに導入されたのは、2024年7月で、 Mistral AI と NVIDIA が共同開発したモデル群(通称:Mistral NeMo シリーズ)がリリースと同時にはっぴょうされています。


2. Tekken トークナイザーの技術的特徴

2-1. BPEベース + 多言語対応

Tekken トークナイザーは、いわゆる サブワード分割 と呼ばれる手法の一種で、OpenAI の tiktoken をベースにした Byte-Pair Encoding (BPE) を採用しています。これは、多言語やプログラミング言語における文字列を高効率に分割する方式です。

  • 多言語コーパスを大規模に学習しており、100以上の言語に対応
  • ソースコードや特殊文字を含む多種多様なテキストにも対応

特に、英語以外の言語に強い設計となっており、日本語や韓国語、中国語、アラビア語などの言語圏でも、従来のトークナイザーより少ないトークン数で表現できるようになっています。

2-2. 大規模ボキャブラリーと高い圧縮率

従来の LLM 用トークナイザー(たとえば SentencePiece を使う LLaMA など)は、語彙(ボキャブラリー)サイズが 3 万〜 6 万程度という場合が多いです。
一方、Tekken トークナイザーでは、約 13 万語 という非常に大きな語彙サイズを持ち、さらに 1000 個以上の制御トークン も含めることで、トータル 13 万超のトークンを扱えます。

語彙サイズを大きくする利点は、圧縮率(1 単語を何トークンに分割するか)の向上につながる点です。珍しい単語や長い固有名詞、プログラミング言語のキーワードなどをひとまとまりのトークンとして扱えるため、トークン分割後の列がより短くなります。結果として、「128k トークンでより多くの実テキストを読み込める」というわけです。

2-3. 特殊トークン(制御トークン)の導入

Tekken トークナイザーは最初の 10〜 14 個程度のトークンを制御トークンとして予約していることが挙げられます。

  • <unk>(未知語)、<s>(文頭)、</s>(文末) など標準的なもの
  • "[INST]", "[TOOL_RESULTS]", "[/INST]" など、Mistral がプロンプト内で使う特殊タグ

こうした制御トークンを、プロンプト設計の段階から明示的に挿入することで、プロンプトの構造を守りながらモデルとのやり取りが可能になります。また、プロンプトインジェクション対策やツール実行のプロンプト管理に役立つ仕組みもここに含まれており、通常のトークナイザーより高度な役割を担っています。


3. 他のトークナイザーとの違い

Tekken トークナイザーが注目される理由は、その圧倒的なトークン効率多言語・汎用性にあります。
従来モデルで採用されることが多かった SentencePiece や、GPT 系でよく使われる BPE でも十分に高品質ではありますが、Tekken は以下の点で優位性を持つとされています。

  1. 圧縮率が高い
    • 例えば日本語では約 1.5〜 2 倍、アラビア語では 2〜 3 倍効率的にトークン化できる事例が報告されています。
  2. 語彙サイズが大きい
    • およそ 13 万語をカバーしているため、テクニカルタームや複数の言語が混在したテキストも細かく分割し過ぎることなく処理しやすい。
  3. 制御トークンの標準搭載
    • プロンプトの構造管理や対話文脈の明確化に貢献するため、単なる “分かち書き” だけでなく、安全な対話フローの実装を下支えする。

もちろん、トークナイザーのボキャブラリーが大きければ大きいほど学習コストは増える可能性があり、一概に大きければ良いというわけでもありません。しかし、Mistral のように超長コンテキストを扱うモデルであれば、最終的な「使用トークンの総数」や「1 トークンあたりが抱える情報の密度」が向上するため、大きなメリットを得られると考えられます。

4.Tekkenトークナイザーが一番優れたトークナイザーなの?→「こたえはNO」

ここまで書くと、Tekkenが一番優れており、 Sentence Pieceより Tekkenのほうが上、のように勘違いしそうですが、そんなことはありません。

Sentence Piece というエンジンだけが存在するわけではなく、扱う言語をどう効率的に単位分割するか、ということになりますので、たとえば、日本語に特化したLLMを作る場合は、多言語13万トークンを抱えるTekkenよりも、3.2万トークン程度のSentence Piece のほうが、効率が高いということはふつうにあえります。

実際のトークン数をはかってみる

せっかくなので、実際に文章をトークナイズしてみましょう。

# 必要なライブラリのインストール
# !pip install transformers sentencepiece #colab使いたい場合はコメント解除

from transformers import AutoTokenizer
from huggingface_hub import login

# Hugging Faceにログイン
login(token="hf_xxxxxxxxxxxxxxxxxxx")

# Mistral Nemo(Tekken)のトークナイザー
mistral_tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-Small-24B-Instruct-2501")

# Llama3のトークナイザー
llama_tokenizer = AutoTokenizer.from_pretrained("tokyotech-llm/Llama-3-Swallow-70B-Instruct-v0.1")

# rinnaのトークナイザー(SentencePieceベース)
rinna_tokenizer = AutoTokenizer.from_pretrained("rinna/japanese-gpt-neox-3.6b")

# テスト用テキスト

text = """
人工知能は急速に進化しており、自然言語処理や機械学習の分野で革新的な成果を上げています。
特に大規模言語モデルの発展により、人間のような自然な対話や文章生成が可能になってきました。
"""
print("=== Tekken(Mistral Nemo)での処理 ===")
# トークナイズしてID列を取得
tokens_tekken = mistral_tokenizer.encode(text)
print("トークンID列:", tokens_tekken)
print("トークン数:", len(tokens_tekken))  # トークン数を表示

# ID列をそのままトークン文字に戻すと"部分バイト"が可視化されるため、文字化けのように見える
decoded_tekken = mistral_tokenizer.decode(tokens_tekken, skip_special_tokens=True)
print("decode()後の文字列:", decoded_tekken)

print("\n=== rinna(SentencePiece)での処理 ===")
tokens_rinna = rinna_tokenizer.encode(text)
print("トークンID列:", tokens_rinna)
print("トークン数:", len(tokens_rinna))  # トークン数を表示
# SentencePiece系はトークン文字列を直接見ても比較的読める形
tokens_rinna_decoded = rinna_tokenizer.convert_ids_to_tokens(tokens_rinna)
print("convert_ids_to_tokens:", tokens_rinna_decoded)
decoded_rinna = rinna_tokenizer.decode(tokens_rinna)
print("decode()後の文字列:", decoded_rinna)

実行結果

はい、このように、日本語特化したrinnaモデルの場合(rinna (japanese-gpt-neox-3.6b など)SentencePiece ベース)、Tekkenよりふつうにトークン効率がいいことがわかりました。

=== Tekken(Mistral Nemo)での処理 ===
トークンID列: [1, 1010, 3405, 26247, 7422, 15928, 2312, 36783, 42135, 2650, 38500, 23403, 5013, 48267, 1749, 43090, 7565, 15199, 5747, 1166, 12894, 5115, 23496, 28883, 1176, 12104, 12904, 1146, 2439, 5020, 23585, 2701, 38980, 11795, 2713, 2768, 5862, 9890, 4187, 66142, 2973, 29062, 1844, 50775, 5368, 47960, 86061, 7565, 15199, 24222, 69030, 2439, 9045, 60288, 74112, 1749, 113283, 2439, 98915, 43090, 2768, 22949, 8888, 5115, 117160, 7360, 5862, 3322, 31470, 52139, 6409, 8294, 25004, 1844]
トークン数: 74
decode()後の文字列: 
人工知能は急速に進化しており、自然言語処理や機械学習の分野で革新的な成果を上げています。
特に大規模言語モデルの発展により、人間のような自然な対話や文章生成が可能になってきました。


=== rinna(SentencePiece)での処理 ===
トークンID列: [263, 30008, 271, 16351, 8152, 1041, 264, 1770, 1920, 3001, 296, 2483, 3744, 16174, 13952, 618, 9655, 15104, 18732, 265, 263, 1085, 9273, 1920, 1120, 8824, 364, 264, 1609, 1976, 1770, 334, 17585, 296, 9572, 5195, 5778, 3642, 454, 5736, 265, 3]
トークン数: 42
convert_ids_to_tokens: ['▁', '人工知能', 'は', '急速に', '進化', 'しており', '、', '自然', '言語', '処理', 'や', '機械', '学習', 'の分野で', '革新', '的な', '成果', 'を上げ', 'ています', '。', '▁', '特に', '大規模', '言語', 'モデル', 'の発展', 'により', '、', '人間', 'のような', '自然', 'な', '対話', 'や', '文章', '生成', 'が可能', 'になって', 'き', 'ました', '。', '</s>']
decode()後の文字列: 人工知能は急速に進化しており、自然言語処理や機械学習の分野で革新的な成果を上げています。 特に大規模言語モデルの発展により、人間のような自然な対話や文章生成が可能になってきました。</s>

またLlama3 (Swallow 70B など)SentencePiece ではなく、GPT 系統の Byte-Pair Encoding (BPE→tiktoken ベース) ですがこれも状況によりトークナイザーの果たすトークン化効率は異なるため、横で比較して Tekken,Llama3,Sentence Piece のどのトークナイザーが優れてるかという事を議論することにあまり意味はないでしょう。(そもそもトークナイザーの効率だけを議論することにあまり意味ないですね)

5. Mistral における採用理由と利用状況

5-1. 多言語モデル性能の向上

Mistral は多言語対応に力を入れており、英語だけでなく、日本語や中国語、韓国語などさまざまな言語で高い性能を目指しています。そのためには、言語ごとのトークナイズが適切であることが不可欠です。Tekken が高い圧縮率と汎用性を備えていることは、多言語モデルで真価を発揮します。

5-2. 長大コンテキストを活用しやすい

前述の通り、Tekken はトークン数を減らせるため、同じコンテキスト長でもより大量の実テキストを扱えます。Mistral NeMo は 128k トークンという長さをサポートするので、従来よりもずっと長い文章やドキュメント、ソースコードを一度に処理するユースケース(例:ドキュメントアナリティクス、コードレビューなど)で大きなアドバンテージを得られます。

5-3. 安全で柔軟なプロンプト構造

Tekken トークナイザーには、プロンプトを構造化するための制御トークンがビルトインされています。これは、Mistral が将来的に進めようとしている「エージェント機能やツール呼び出しの活用」において特に重要です。


エージェントが外部サービスを呼び出して結果を受け取る際、"[TOOL_RESULTS]" のような特殊トークンで区切られたテキストをモデルが安全・確実に扱えるというメリットがあります。これにより、プロンプトインジェクションへの耐性を高めたり、ユーザ入力とツール出力を混同しにくくしたりできるわけですね。


6. まとめ 〜 Tekken トークナイザーがもたらす進化

Tekken トークナイザーは、

  • 多言語・コード対応
  • 高圧縮・大ボキャブラリー
  • 制御トークンによる安全・柔軟なプロンプト構造

といった特徴を兼ね備えた新世代のトークナイザーです。Mistral が大規模コンテキストを活用するうえで、「可能な限り 1 トークン当たりの情報量を増やしたい」という要望を実現し、さらに対話型 AI が活躍する未来のために、プロンプト構造を活用しやすい仕組みを組み込みました。

今後、Mistral 以外のモデルやフレームワークでも Tekken を採用する動きが広がるかもしれません。

Tekken に限らずトークナイズの効率化はモデル性能向上の一端を担いますので、大規模言語モデル業界においては引き続き熱いトピックとなるでしょう!

Read more

発話音声からリアルなリップシンクを生成する技術 第5回(前編):Transformerの実装と実践的な技術選択

発話音声からリアルなリップシンクを生成する技術 第5回(前編):Transformerの実装と実践的な技術選択

こんにちは!リップシンク技術シリーズもいよいよ終盤となりました。 前回(第4回)では、LSTMの学習プロセスと限界について詳しく解説しました。限られたデータでも効果的に学習できるLSTMの強みを理解する一方で、長距離依存の処理に限界があることも明らかになりました。そして、この問題を解決する革新的なアプローチとして、すべての位置の情報を同時に参照できるTransformerのSelf-Attention機構を紹介しました。 第5回の今回は、 Transformerの具体的なネットワーク設計から始め、その実装上の課題を明らかにします。(前編※) そして、LSTMとTransformerの長所を組み合わせたハイブリッドアプローチを紹介し、実際の製品開発における技術選択の指針を示します。最後に、感情表現への拡張という次なる挑戦についても触れていきます。(後編※) ※Transformerの仕組みは複雑であるため、第5回は前編と後編に分けて解説させていただく予定です。 1. Transformerベースのネットワーク設計 1.1 全体アーキテクチャ図 では、さっそく、Tran

By Qualiteg 研究部, Qualiteg コンサルティング
大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

こんにちは、今回はシリーズ第2回ドメイン環境の構築 - 検証環境の構築手順について解説いたします! 連載の構成 第1章:基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 【★今回です★】第2章:ドメイン環境の構築 - 検証環境の構築手順 第3章:クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 第4章:プロキシサーバーと統合Windows認証 第5章:ブラウザ設定と認証 - 各ブラウザでの設定方法 第6章:トラブルシューティング - よくある問題と解決方法 第7章:セキュリティとベストプラクティス - 本番環境での考慮事項 第8章:実践的な構成例 - AIセキュリティツールとの統合事例 第2章:ドメイン環境の構築 2.1 ドメイン名の設計 2.1.1 ドメイン名の命名規則 Active Directoryを構築する際、

By Qualiteg コンサルティング
AIがよく間違える「クロージャ問題」の本質と対策

AIがよく間違える「クロージャ問題」の本質と対策

こんにちは! 本日は「クロージャ問題」に関する話題となります。 Pythonでループ内に関数を定義したことはありますか? もしあるなら、あれれ?な挙動に遭遇したことがあるかもしれません。 本稿では、Pythonプログラマーなら一度は経験する「クロージャ問題」について、初心者にもわかりやすく解説してみたいとおもいます クロージャとは何か? そもそも ”クロージャ” とは何でしょうか。 クロージャ(closure)とは、関数が自分の定義されたスコープの変数を覚えて持ち運ぶ仕組み のことです。 もう少し分解すると、次の2つがポイントとなります 1. 内側の関数が、外側の関数の変数を使える 2. 外側の関数が終了しても、その変数は生き続ける 普通の関数とクロージャ―を使った関数を比較してみましょう 普通の関数との比較 まずは普通の関数から、 def add(x, y): return x + y print(add(3, 5)) # 8 print(add(3, 7)

By Qualiteg プロダクト開発部
フリーランスHub様にQualiteg Blogをご紹介いただきました

フリーランスHub様にQualiteg Blogをご紹介いただきました

この度、フリーランス向け案件検索サービス「フリーランスHub」様の特集記事「トレンドをキャッチアップ!AIに関する情報が得られるメディア・ブログまとめ」にて、弊社が運営する「Qualiteg Blog」をご紹介いただきました。 掲載記事について フリーランスHub様の記事では、AI技術の最前線で活躍するエンジニアや開発者の方々に向けて、価値ある情報源となるメディア・ブログが厳選して紹介されています。 その中で、Qualiteg Blogを「AI技術の専門知識を実践的なビジネス活用につなげる貴重な情報源」として取り上げていただきました。 特に以下の点を評価いただいております * 実践的なビジネス活用事例の提供 AI新規事業創出や事業選定方法など、経営者やビジネスリーダーが直面する課題への具体的な解決策 * 技術的な深掘りコンテンツ リップシンク技術など、実際のサービスで使用されている技術の開発現場目線での詳細な解説 * 多様な情報発信 代表執筆記事、AIトピックス、講演会動画など、幅広いフォーマットでの情報提供 今後も価値ある情報発

By Qualiteg ニュース