【解説】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="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")

# 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

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

こんにちは! 先日、dlibをつかったPythonアプリケーション(conda環境で動作する)作っていたところ、以下のようなエラーに遭遇しました。 ImportError: /home/mlu/anaconda3/envs/example_env/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/mlu/anaconda3/envs/example_env/lib/python3.10/site-packages/_dlib_pybind11.cpython-310-x86_64-linux-gnu.so) 「dlib_pybind11モジュールがGLIBCXX_3.4.32を要求してるけど、みつからない!」という感じのエラーですね。

By Qualiteg プロダクト開発部
LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

こんにちは! 今回はLLM推論基盤プロビジョニング講座 第2回です! STEP2 LLMサービスへのリクエスト数見積もり それでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。 リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。このバランスを適切に取るための基礎となるのがリクエスト数の見積もりです。 想定リクエスト数の諸元 リクエスト数を見積もるための5つの重要な要素(諸元)をみてみましょう。 1. DAU(Daily Active Users): 1日あたりの実際にサービスを利用するユーザー数です。これはサービスの規模を示す最も基本的な指標となります。 2. 1日

By Qualiteg コンサルティング
Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

こんにちは! 本日は、自動フレーミング映像の安定化に関するアルゴリズム・ノウハウを解説いたします 第1章 問題の背景と目的 バストアップ映像を撮影する際、特にオンラインミーティングやYouTubeなどのトーク映像では、人物がうなずく、首を振るなどの自然な動作をした際に「首まわりや肩がフレーム内で上下に移動してしまう」という現象がしばしば起こります。これは、多くの場合カメラや撮影ソフトウェアが人物の「目や顔を画面中央に保とう」とする自動フレーミング機能の働きに起因します。 撮影対象の人物が頭を下げた際に、映像のフレーム全体が相対的に上方向へシフトし、その結果、本来動いていないはずの肩の部分が映像内で持ち上がっているように見えてしまう現象です。 本稿では、この問題を撮影後の後処理(ポストプロセッシング)のみを用いて、高速、高い精度かつロバストに解決する手法をご紹介します。 前半では、従来のCV(コンピュータービジョン)の手法を使い高速に処理する方法をご紹介します。後半では、AIを使用してより安定性の高い性能を実現する方法について考察します。 第2章 古典手法による肩の上下

By Qualiteg 研究部
LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

こんにちは! 本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。 はじめに LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。 一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。 しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するに

By Qualiteg コンサルティング