Fireworks AIは最近、プロンプトインジェクション問題を根本的に解決するための新しい安全メカニズムである「安全なトークン化（safe_tokenization）」を発表しました。これは、すべてのオープンモデルに保護を提供するものです。プロンプトインジェクションは、現在の大規模言語モデル推論サービスにおける一般的な脆弱性です。ユーザー入力内のテキスト文字列が、トークナイザーによってモデルの制御トークンとして誤ってエンコードされ、システムプロンプトやロール境界を改ざんする可能性があります。Fireworksは、シンプルなブール値パラメータを導入することで、プロンプトインジェクションに対する効果的な防御を実現しました。
Fireworksのチーフサイエンティストは、ブログ記事でこの問題の根本原因を詳しく説明しています。彼は、ほとんどのオープンモデルがHuggingFaceトークナイザーを使用しており、その標準的なプロセスは、最初にJinjaチャットテンプレートを使用して会話全体を単一の文字列にレンダリングし、次にその文字列をエンコードすることを指摘しています。このプロセスでは、ユーザーテキストとテンプレート内の制御トークンが混在し、トークナイザーはどのバイトがテンプレートから来たのか、ユーザーから来たのかを区別できません。その結果、ユーザー入力がモデルの制御トークン文字列（例：<|im_start|>など）を含む場合、それらは実際の制御トークンとしてエンコードされ、モデルの出力動作を変更する可能性があります。
記事では、Kimi K2.6モデルを使用した完全な攻撃のデモが示されています。攻撃者はユーザーメッセージ内に偽のシステムロール切り替え命令を埋め込み、元々英語に固定されたシステムプロンプトをスペイン語に上書きします。実験では、安全なトークン化がオフの場合、モデルは攻撃者のスペイン語の指示に従いましたが、安全なトークン化をオンにすると、モデルは元の英語のルールを守りました。この違いは、ログ確率（logprobs）で定量的に確認できます。
安全なトークン化の動作原理は、2つのレベルの修正を含みます。モデルロード時には、システムが完全な語彙表（特殊トークンと追加トークンの両方）をスキャンし、制御トークンがユーザー補間コンテンツから分離されるようにチャットテンプレートを前処理します。リクエスト時には、テンプレートからの構造トークンは本来のトークンIDとしてエンコードされ、ユーザーテキストの各セグメントは特別なトークン化ステップを経て、制御トークンになる可能性のあるバイトがサブワード単位に分割されます。2つのパスは設計上一致しているため、攻撃者はテンプレートとユーザーコンテンツの間に隙間を見つけることができません。
Fireworksは、安全なトークン化が通常のユーザー入力に対して完全に透過的であることを強調しています。ユーザーコンテンツが制御トークン文字列を含まない場合、安全パスとデフォルトパスは同一のトークンIDを生成します。さらに、このメカニズムの計算コストは非常に低く、モデルの再読み込みや追加のネットワークホップは必要ありません。ユーザーはAPIリクエストに「safe_tokenization: true」を追加するだけで、この保護を有効にできます。Fireworksがサポートするすべてのオープンモデル（DeepSeek、Kimi、Qwen、Llama、GLMなど）でこの機能が利用可能であり、ストリーミングと非ストリーミングの両方の補完に対応しています。
業界では、プロンプトインジェクションは現在のAI推論プラットフォームが直面する最大のセキュリティ上の脅威の1つと考えられています。Fireworksの安全なトークン化ソリューションは、業界にシンプルで効果的な解決策を提供します。記事が述べているように、「本番環境での推論は、悪意のあるユーザーコンテンツに耐えられる必要があります。safe_tokenization: trueは、Fireworksがトークンレベルでその保証を行う方法です。これにより、あなたのシステムプロンプトが、他の誰のものでもなく、あなたの製品を定義するのです。」