LLMトークンカウンター

このページは DevUtilities でブラウザ内の LLM トークンを数えるための正規ガイドです。読みながら上の対話型 Prompt Budget Cockpit を使うか、下のトピックへジャンプしてください。すべて js-tiktoken 経由でクライアント側で動作し、プロンプトはマシンから出ません。

LLM Token Counter（Prompt Budget Cockpit）は、OpenAI が tiktoken に同梱するのと同じ BPE 表でテキストをトークン化します。3 つのエンコーディングを並べて比較し、トークン境界を可視化し、GPT-4o、GPT-4o mini、Claude 3.5 Sonnet の入力コストを見積もり、本番 API に届く前にプロンプトを縮小する助けになります。

得られるもの

• o200k_base（GPT-4o）、cl100k_base（GPT-4 / Claude 近似）、p50k_base（レガシー Codex）の同時カウント
• ホバー可能な Token ID 付きの色分け Token Boundary Map
• プロンプト重量を減らす Minify JSON と Strip Spaces アクション
• 静的な公開入力レートからのクエリ単位・月次コスト外挿
• 設計ドキュメントと予算レビュー向けのコピー可能なマルチエンコーディング指標

次のときに使う

• system prompt + tools + ユーザーメッセージがコンテキスト窓に収まるか知る必要がある
• モデル選定前に GPT-4o と Claude 系のトークン予算を比較する
• OpenAI や Anthropic API を呼ばずにローカルでプライバシー安全なカウントが欲しい
• コストを膨らませる RAG チャンク、few-shot 例、JSON スキーマを削る

期待しないこと

• バイト同一の Claude 請求 — Anthropic は別の本番トークナイザーを使い、cl100k_base は有用な英語近似です
• API が生テキストの周りに付けるチャットラッパーのオーバーヘッド（ロールタグ、ツールエンベロープ）
• ライブ市場価格 — コストパネルはずれる可能性のある静的公開レートを使います

Token ID はエンコーディング固有です。同じ英文でも o200k_base と cl100k_base では長さと ID が異なります。常に対象モデルが実際に使うエンコーディングで予算を立ててください。

特定モデルファミリーのマージを調べるときは、比較カードとは独立して Token Boundary Map のエンコーディングを切り替えてください。

初めてコックピットを開くときはこの手順に従ってください。その後の大半のセッションは貼り付け → 比較 → 最適化 → コピーです。

1. 関心のある完全なプロンプトペイロードを貼り付けます: システムメッセージ、ユーザーターン、ツール JSON、または連結した RAG コンテキストブロック。
2. 3 つの比較カードを読みます。最も高いエンコーディングをメモ — まだモデルを選ぶ必要がある場合の保守的予算です。
3. Token Boundary Map を開き、意外に長いスパン（URL、絵文字、インデント JSON）にホバーして具体的な Token ID を確認します。
4. 入力が JSON 中心なら Minify JSON をクリック。二重スペースや余白改行のある散文なら Strip Spaces をクリック。
5. 推定月間呼び出し量を入力し、GPT-4o、GPT-4o mini、Claude 3.5 Sonnet の入力支出を投影します。
6. メトリクス要約を設計ドキュメント、チケット、PR 説明にコピーし、チームが一つの数字を共有できるようにします。

「良い」状態の目安

• System + tools + 平均ユーザーターンが、選んだコンテキスト窓内でモデル応答の余地を残す
• 人間が整形コピーを編集しても、本番プロンプトでは JSON スキーマが minify されている
• コスト外挿が請求モデルに一致するエンコーディングを使う

問題: ポリシー、トーン規則、few-shot 例を 3 つ追加したあと、サポートエージェントのプロンプトが会話の途中で切り詰められる。

このツールの解決方法

1. 現在の system prompt だけを貼り付け、o200k_base（または cl100k_base）のカウントを記録します。
2. few-shot 例を 1 つずつ追加して差分をメモ — 価値の低い例から先に落とします。
3. 代表的なユーザーメッセージと毎回送る tools JSON を貼り付け、モデルのコンテキスト窓に対して合算します。
4. 散文に Strip Spaces、スキーマに Minify JSON を使い、再カウントして節約量を定量化します。
5. 最終予算をエージェントのランブックにコピーし、今後のプロンプト編集が同じ上限を守るようにします。

結果: どのセクションが予算を壊したか、各最適化が何トークン回復したかが正確に分かります — 次の本番切り詰めの前に。

問題: OpenAI の function-calling スキーマは可読性のためインデント付きで書かれ、ライブリクエストに貼られます。論理スキーマは変わっていないのにトークン支出が上がります。

このツールの解決方法

1. 整形済み tools 配列または parameters オブジェクトを入力パネルに貼り付けます。
2. API モデルが使うエンコーディング（通常 GPT-4o なら o200k_base）のトークン数をメモします。
3. Minify JSON をクリックして新しいカウントと比較 — 差は純粋な空白税です。
4. boundary map を確認: 繰り返しキーと長い enum リストが支配的なことが多いので、フィールドを切る前に説明を短くします。
5. API 呼び出しでは minify 済みスキーマを送り、整形コピーはソース管理または Agent Builder エディタだけに残します。

結果: ツール動作を変えずに、ツール有効な呼び出しごとの入力コストを下げます。

問題: モデルを数千回呼ぶ機能のローンチ前に、財務が月次 LLM 支出見積もりを求めます。

このツールの解決方法

1. 現実的な平均ペイロード（system + tools + 典型ユーザー文）を組み立ててここに貼ります。
2. 本番モデルに一致するエンコーディングの比較カードを確認します。
3. Estimated monthly volume を予測呼び出し数に設定します。
4. 同じペイロードでベンダー比較するため、GPT-4o、GPT-4o mini、Claude 3.5 Sonnet の月次列を読みます。
5. レートは静的な公開入力価格だと文書化し、ベンダーが価格ページを変えたら見積もりを更新します。

結果: 「トークンは安い」という曖昧な推測ではなく、ペイロード固有の防御可能な予測になります。

問題: RAG パイプラインがクエリごとに 5 チャンクを取得。一部は空白や定型ヘッダーが多く、有用テキストが切り詰められてモデルが答えを逃します。

このツールの解決方法

1. 候補チャンクを個別に貼り付け、検索モデルのエンコーディングでトークン数を記録します。
2. より密なチャンクを優先: Strip Spaces、繰り返しナビヘッダー削除、ほぼ重複する段落の除去。
3. 送る予定の top-k セットを連結し、質問と回答の余地が残るか確認します。
4. boundary map で、人間には短く見えるトークナイザー高コスト列（長い URL、表、絵文字）を見つけます。
5. このツールで測った合計を使い、リトリーバーにクエリあたりのハードトークン予算を設定します。

結果: 検索がトークンあたりの信号を増やし、静かなコンテキスト切り詰めによる失敗が減ります。

症状: API 400 context_length_exceeded、切り詰められた completion、セッション途中で初期指示を「忘れる」エージェント。

なぜ起きるのか

system prompt、tools、履歴、ユーザーターンの合計がモデルのコンテキスト窓を超えます。整形 JSON と長い few-shot バンクはよくある静かな原因です。

診断

クライアントが送る正確なペイロードを貼る（または再構築する）。トークン合計をモデルのコンテキスト窓と比較。個別に数えて最大セクションを特定します。

修正

1. ツールスキーマを Minify JSON し、散文の余分な空白を削ります。
2. まれに使うポリシーを常時 system prompt からオンデマンド検索へ移します。
3. 各呼び出し前にチャット履歴を上限（要約または最古ターン削除）。
4. 測定後にのみより大きなコンテキストモデルへ切替 — 推測しない。

変更のたびに再カウント。8k トークンの tools ブロブで空白を 10% 削ると、短いポリシー段落を消すより余裕を取り戻すことが多いです。

症状: ローカルカウントは問題なさそうだが OpenAI 使用ダッシュボードと不一致 — または Claude の請求がスプレッドシートと違う。

なぜ起きるのか

誤ったエンコーディングで予算を立てたか、ロールとツールエンベロープでメッセージを包む API と生テキストを比較した。

診断

モデルの文書化されたトークナイザーを確認。GPT-4o ファミリーは o200k_base、GPT-4 / 3.5 は cl100k_base。ここでの Claude 数値は近似のみとして扱います。

修正

1. 比較フォーカスと boundary map を一致するエンコーディングに切り替えます。
2. 人間可読のプロンプト下書きだけでなく、SDK が実際に送るシリアライズ済みメッセージを数えます。
3. ハード上限を計画するとき、チャット整形用に小さなオーバーヘッドバッファ（しばしば数十〜数百トークン）を足します。
4. Anthropic 請求では、SLA を固める前に重要プロンプトを Anthropic 自身のカウンターで検証します。

症状: プロンプトの意味が変わらないのに、Minify JSON または Strip Spaces 後にトークン数が劇的に下がる。

なぜ起きるのか

BPE エンコーディングはインデント改行、整列スペース、繰り返し空行に課金します。人間は無視しますがトークナイザーはしません。

診断

整形ペイロードを貼り、カウントをメモし、Minify JSON / Strip Spaces を実行して比較。大きな差分は空白が主コスト要因だったことを意味します。

修正

1. 人間編集用の整形 JSON を git に保存し、リクエスト時に minify。
2. system prompt 内のパディング ASCII 図や巨大インデントログを避ける。
3. 長いポリシードキュメントの複数空行セクション区切りを折りたたむ。

boundary map は空白トークンを別色スパンとして可視化します — チームに minify の重要性を教えるのに有用です。

Token Boundary Map は各 BPE マージを色付きスパンとして描きます。色は視覚分離のためだけに循環し、トークンカテゴリを符号化しません。

読み方

• スパンにホバーして、選択中のマップエンコーディングの数値 Token ID を表示
• URL や base64 上の長い切れ目のないスパンは、短縮する価値のある高価な 1〜少数トークンチャンクを意味することが多い
• 絵文字と CJK テキストは、同じ見た目の長さのラテン散文より多くのトークンを使うことがある
• 同じ文字列を GPT-4o と GPT-4 がどう分割するか比較するときマップエンコーディングを変更

コストカードはローカルトークン数に静的公開入力レートを掛けます: GPT-4o $5 / 1M、GPT-4o mini $0.15 / 1M、Claude 3.5 Sonnet $3 / 1M。月次ボリュームがクエリ単価をスケールします。

注意点

• 出力トークンは含まれません — 完全な TCO には completion 見積もりを別途追加
• キャッシュ入力やバッチ割引はモデル化されていません
• ベンダー定価は変わります。数値は請求書ではなく計画補助として扱ってください

• 本番に一致するエンコーディングで予算を立て、チャットラッパーとリトライ用に 10–20% の安全余裕を残す
• system prompt だけでなく完全なリクエスト形（system + tools + 履歴 + ユーザー）を数える
• 機械消費 JSON は minify、人間用は整形コピーを残す
• few-shot 例、MCP 設定、長いポリシー付録を追加したら再カウント
• ローンチ前にコストが見えるよう設計レビューで月次ボリューム投影を使う
• 独自プロンプトはローカルカウントを優先 — このツールはテキストをアップロードしません

境界色は tiktoken のバイトペアエンコーディングに対応します。<|endoftext|> のような特殊トークンはリテラルテキストとして存在する場合にカウントされます。