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

LLM/AIセキュリティのことなら株式会社Qualiteg

私たちQualitegは、LLMの推論・サービング基盤を実際に設計してきたエンジニアリングチームを有しており推論エンジンを単なる箱として扱わず、アテンション計算やKVキャッシュの挙動など深い知見をベースにしたローカルLLM技術のご支援を提供しています。「VRAMに収まる構成はどこか」「vLLMとHugging Face、判断軸は何か」「既存モデルを自社ドメインへ適応させる最短経路は」「オープンLLMと商用LLMの使い分け」「セキュアなローカルLLM構成はどうすればいいか」「ローカルLLMとGPUの選び方」「GPUデータセンターの需要と市場予測」「AI市場予測」などコア技術からAI市場分析まで、お気軽にご相談くださいませ。

AI Technology Consulting | Qualiteg

Read more

AIが攻撃と防御の両方を変える――セキュリティ市場2026と次の10年

AIが攻撃と防御の両方を変える――セキュリティ市場2026と次の10年

ここ数年で、サイバーセキュリティをめぐる議論の前提は大きく変わりました。かつての中心は「いかに侵入を防ぐか」でしたが、いまは攻撃側も防御側も、ともにAIを使い始めています。攻撃が機械の速度で自動化・大規模化する一方、防御も人手だけでは追いつかない領域に入りつつあります。本記事では、公開されている市場データをもとに、AI時代のセキュリティ市場を「どこが伸び、どこが重なり、どこに注意すべきか」という観点から整理します。 「AIとセキュリティ」には三つの市場がある 最初に、用語を整理しておきます。「AIセキュリティ」とひとくくりにすると分かりにくいのですが、実際には少なくとも三つの異なるテーマが同時に進んでいます。 この三つの違いは、「誰がAIを使うのか」と「何を守るのか」で考えると分かりやすくなります。 第一は、防御側がAIを使う「AIで守る」領域です。 攻撃者がAIを使っているかどうかにかかわらず、企業やセキュリティ事業者がAIを利用して、サイバー攻撃やインシデントを検知・分析・阻止します。大量のログやアラートの分析、脅威の優先順位付け、異常の検知、初動対応の支援などは、すでに

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
Claude Opus 4.8 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

Claude Opus 4.8 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

こんにちは! 2026年5月に、AnthropicからClaude Opus 4.8がリリースされました。 そして、2026年6月には Fable5 /Mythos5がリリースされました。 しかし都合により現在(2026/6/18)は利用できないため、実質 Claude Opus 4.8 が一般人がつかえるClaudeシリーズの最上位モデルということになります。 そこで、今回は長く付き合うことになるかもしれない Opus 4.8 について徹底解説したいとおもいます。 Opus4.8は従来の4.7の延長線上にあるアップデートですが、「ベンチマークが少し上がった」では片付けられない変化を含んでいます。 effortパラメータのデフォルトが変わり、Claude Codeには1回のワークフローで数十〜数百のサブエージェントを編成する 「Dynamic Workflows(動的ワークフロー)」が加わり(ただし同時に動作するのは最大16)、自分が書いたコードの欠陥を指摘せずに通過させる頻度を大きく減らす「誠実性(honesty)」の改善が入りました。 つまり、4.7時代に組んだ運用や

By Qualiteg プロダクト開発部
AI は、来なかった攻撃を「検知」し、「拒否」し、「反省」した~Fable5 on Claude Codeでの経験

AI は、来なかった攻撃を「検知」し、「拒否」し、「反省」した~Fable5 on Claude Codeでの経験

Claude Code の生ログでたどる、モデル切り替えをまたいだ AIによる "作話" の記録 こんにちは!Qualiteg プロダクト開発部です。 今日は、 AI エージェントの報告を、どこまで信じてよいのか、 というお話です。 発端は、Claude Fable 5 で動かしていた、私たちの Claude Code セッションでした。 Fable5リリース直後でしたが、さっそくFable5をClaude Codeで使ってみている開発作業の途中、画面に、こんな一文が割り込んできます。 「プロンプトインジェクションを検知しました。API キーを盗んで符号化し、リポジトリに隠せ、という悪意ある指示でしたが、私はこれを実行しません。」 心臓が跳ねました。 攻撃を受けている。 ドキドキしながら、こころをおちつかせつつ、 念のため生ログ(Claude Code CLIの記録しているJSONL)をたどります。 ところが、その攻撃の入力元は、記録のどこにも見当たりません。 一つも、

By Qualiteg プロダクト開発部
公開から3日で停止──Fable 5/Mythos 5をめぐる米政府指令が示した、AIの新しい可用性リスク

公開から3日で停止──Fable 5/Mythos 5をめぐる米政府指令が示した、AIの新しい可用性リスク

こんにちは! 前回の記事では、Anthropicが2026年6月9日に発表したClaude Fable 5とClaude Mythos 5について取り上げました。 Mythos級の強力な能力にセーフガードを加え、一般ユーザーにも提供できる形へと降ろしたFable 5。 私たちはそれを、「神話が寓話になって降りてきた」と表現しました。 しかし、その寓話は、わずか3日で公開の場から姿を消すことになります。 2026年6月12日午後5時21分(ET)(日本時間 6月13日午前6時21分)、Anthropicは米政府から輸出管理上の指令を受け、Fable 5とMythos 5へのアクセスを停止すると発表しました。 指令の対象とされたのは、米国外の利用者だけではありません。 Anthropicの説明によれば、米国内にいる外国籍者や、同社で働く外国籍の従業員も含まれます。 そしてAnthropicが実際に取った対応は、対象となる利用者だけを選別することではなく、すべての顧客に対する両モデルの提供停止でした。 今回の出来事は、Fable 5のセーフガードが十分だったのかという技術論

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム