多くの企業のAIチームは、最適化すべき対象を取り違えています。指示文を短くする、不要な表現を減らす、言い回しを圧縮するといった「プロンプトの整え方」に注力しがちです。しかし、トークン効率の本当の改善は、モデルがプロンプトを受け取る前の段階、つまり検索の精度、コンテキストの選び方、処理の組み立て方にあります。
企業AIにおけるトークン効率とは、必要最小限のコンテキストと計算処理で、質の高い回答を得る能力を指します。実際の運用システムでは、最大の改善余地はプロンプトそのものではなく、生成に先立って何を検索し、選び、モデルに渡すかにあることがほとんどです。
企業にとって、トークン効率はコストへの影響にとどまりません。応答速度、回答の品質、信頼性、そして利用者や業務にまたがって広げたときにシステムがどこまで持ちこたえるかにも関わります。モデルに送る不要な情報が少ないシステムは、より安く、より速く、より根拠に基づき、より信頼しやすくなる傾向があります。賢いトークン戦略とは、トークン数を何としても削ることよりも、1トークンあたりで最良の成果を引き出すことに重点を置きます。
企業AIにおけるトークン効率の本当の意味
トークン効率を「トークンを少なく使うこと」と定義すると、本質を見失います。より有用なのは次の定義です。トークン効率とは、強い結果を出しつつ、必要なコンテキストと計算処理を最小限に抑えてタスクを完了する能力です。つまり、モデルの指標であると同時に、業務の指標でもあります。
企業の環境では、トークン効率の向上は通常、次のことを意味します。
- 推論コストの低下
- 利用者への応答の高速化
- より信頼でき、根拠に基づいた回答
- チーム、業務、用途をまたいだ拡張性の向上
- モデルが処理すべき不要な情報の減少
コンテキストは多ければ良いというものではありません。大きなコンテキストウィンドウは、設計の弱さを一時的に覆い隠すことはできても、根本の問題を解決するわけではありません。無関係な情報を渡し続ければ、モデルは意味のある情報を見つける前に、不要な情報を処理しなければなりません。だからこそ、企業AIのトークン効率は、品質、応答速度、コストの問題がひとつに重なったものなのです。
トークンの無駄は本当はどこから生まれるのか
プロンプトもトークンを無駄にします。ただし企業システムでは、プロンプトの長さは見かけほど大きな要因ではないことが多いのです。無駄のより大きな原因には、次のものがあります。
- 文書を取得しすぎる
- 短い一節だけで足りるのに長い塊を送る
- 同じ情報をツール、やり取り、業務の各段階で重複させる
- 数行だけが関係するのに文書全体を渡す
- 雑多で順位付けの甘い根拠をモデルに推論させる
- 多段階の業務で、途中の状態を要約せずにコンテキストを繰り返す
よくある場面を考えてみましょう。AIアシスタントが人事ポリシーの質問に答える、財務ルールを説明する、社内のサポート案件を要約する、といったケースです。システムは長い文書を8件取得しますが、本当に関係するのはそのうち短い2つの一節だけです。言い回しが効率的かどうかにかかわらず、問題はプロンプトではありません。トークンの無駄は、システムが選別をほとんどせずに過剰な根拠を渡した、その上流の段階から始まっています。
なぜプロンプトの長さより検索が重要なのか
プロンプトを整えればいくらかトークンを節約できますが、検索を改善すれば、AIシステムのコスト構造と品質のあり方を根本から変えられます。同じ業務に2通りの調整を加える場面を想像してください。ひとつはプロンプトを15%短くすること、もうひとつは無関係な検索結果を60%減らすことです。
前者は少し役立ちます。後者は通常、コスト、応答速度、回答品質を同時に改善します。なぜなら、検索がモデルの思考前に読まねばならない内容を決めるからです。誤った文書、範囲の定まらない塊、順位付けの甘さは、回答に何も寄与しないコンテキストの処理にモデルがトークンを費やすことを意味します。場合によっては、その余分なコンテキストが回答をかえって悪化させ、モデルを脱線、古い情報、矛盾する根拠へと引き寄せます。
検索拡張生成（RAG）やエージェント型のシステムでは、リスクはさらに高まります。トークンの無駄は段階を追うごとに積み重なります。最初の検索段階が肥大化すると、そのコストが次の段階へ、さらにその次へと引き継がれます。業務が完了するころには、システムは質の悪いコンテキストに対して何度も対価を払っていることになります。
企業のチームは、トークンの最適化をまず検索の問題として、その次にプロンプトの問題として扱うべきです。
よく設計された企業AIシステムとは
大規模にトークン効率を実現するには、自社が持つ知識を把握したコンテキスト層が必要です。各ツールにある最新の知識から検索し、アクセス権を正確に守り、文書全体ではなく該当する一節を提示する層です。
GleanのWork AIプラットフォームは、Enterprise Context（エンタープライズ・コンテキスト）を中心に構築されています。これは、AIがより良い根拠を検索し、アクセス権を守り、現時点の社内知識に基づいて動くことを助ける、共有されたコンテキストの仕組みです。Gleanはすべての文書を切り離されたテキストの塊として扱うのではなく、検索を、組織の各システムにすでに存在する関係性、アクセス権、知識の構造とつなげます。その結果、まず検索の品質が高まり、塊の分け方、プロンプト、処理の組み立てといった判断が、いずれもより良い根拠から始まる土台ができます。
トークン効率のための企業向けフレームワーク
最も優れた企業のAIチームは、全体を通して最適化を行います。その最適化は、次の4つの層で構成されると考えられます。
第1層: 検索は少なく、しかしより的確に
検索の品質から始めます。システムは、強い回答を支えられる最小限の根拠を見つけるべきです。これは再現率（recall）だけでなく精度（precision）を高めることを意味します。ここでは順位付けと再順位付けの改善が欠かせません。メタデータ、アクセス権、所有者、新しさ、タスクのコンテキストによって検索範囲を絞ることも同様に重要です。
検索を適切に行うには、強固なコンテキスト層が必要です。システムは、どの内容が利用者に関係するのか、どの版が最新なのか、どの成果物がつながっているのか、そして利用者が実際に閲覧を許可されている情報はどれなのかを把握する必要があります。Gleanは、最新の社内知識、アクセス権、システム間の関係性に検索を根ざします。その結果、無関係なトークンがプロンプトに届く前に減らせます。
第2層: 本当に重要な根拠だけを渡す
適切な情報源を検索できたら、次の仕事は、すべてを渡したくなる誘惑を避けることです。企業システムは、塊の分割と一節の選択の機能を使い、数か所の一節で足りるのに文書全体を送ることを避けるべきです。目指すのは、意味のまとまった塊、一節単位の選択、重複の除去、必要に応じた圧縮です。ポリシーの質問に答える、サポート案件に対応するアシスタントに、wikiページ全体、Slackのスレッド全体、CRMのレコード全体は必要ありません。必要なのは、回答を支える特定の一節です。
これは、試作品と本番システムの最も明確な違いのひとつです。試作品は念のためとコンテキストを詰め込みます。本番システムは、選別することを身につけます。
第3の層: プロンプトは圧縮ではなく制御のために設計する
プロンプトの設計は依然として重要ですが、効率を左右する主な要因ではありません。企業向けの優れたプロンプトは、モデルに対して明確なタスク、明確な出力形式、そして必要最小限の背景情報を与えます。指示の繰り返し、同じ内容のポリシー文の重複、本来はシステムの別の部分で扱うべき広範なコンテキストは避けます。長く使えるプロンプト設計とは、圧縮ではなく制御に関わるものです。
- タスクを明確に示す。
- 出力形式を指定する。
- 必要に応じて回答に制約を設ける。
- システムがすでに把握している指示を繰り返さない。
- モデルを、取得した根拠に集中させる。
周囲のシステムがノイズだらけであれば、どれだけ簡潔なプロンプトを作ってもそれを補うことはできません。
第4の層: 処理のステップ全体を賢く調整する
トークン効率は、ワークフローの設計にも左右されます。AIエージェントや複数ステップから成るシステムでは、各ステップで同じ生のコンテキストを何度も送ってしまうことが、無駄の典型的な原因です。より良い方法は、作業を段階に分け、途中の出力を要約し、タスクを適切なツールに振り分け、本当に再び必要な場合を除いて同じ情報を読み込み直さないことです。
うまく機能する調整(オーケストレーション)は、性能を実際に高める手段になります。何を取得し、何を要約し、何をキャッシュし、何を繰り返さないかを判断するシステムは、より大きなコンテキストウィンドウを持ちながら連携の弱いシステムを上回ることがよくあります。企業のAIエージェントに必要なのは、モデルへのアクセスだけではありません。信頼できる情報取得、アクセス権を考慮したコンテキスト、そして無関係なコンテキストがモデルに届くのを防ぐワークフローの仕組みです。
回答品質を犠牲にせずにトークン効率を測る方法
トークン効率を測る際の誤ったやり方は、トークン数の最小化だけを目指すことです。削りすぎて必要な根拠を取り除いたり、重要なコンテキストをまとめて省いたりすると、安くはなっても同時に質の低い回答が生まれます。問うべきなのは、トークンあたりどのような成果が得られているか、という点です。
実務的な評価指標には、次のようなものがあります。
- 成功したタスクあたりのトークン数
- タスクあたりの応答時間
- タスクあたりのコスト
- 情報取得の精度
- 回答の品質、または根拠への忠実度
- コンテキストの活用率
特に役立つのがコンテキストの活用率です。最終的な回答に影響しない大量のコンテキストを日常的に渡しているなら、そのシステムはノイズに対してコストを払っていることになります。チームが知るべきなのは、使ったトークン数だけでなく、そのトークンが結果を改善したかどうかです。引用、出典へのリンク、明確な根拠のつながりを示すシステムであれば、この点を確認し、時間をかけて改善することが容易になります。
企業チームが陥りやすい誤り
いくつかのパターンが繰り返し見られます。
プロンプトの短縮を主な手段と捉えること。これにより、チームは言葉を削ることに集中しすぎて、より大きな問題を見落とします。情報取得の質の低さ、過大なチャンク(文書の分割単位)、重複したコンテキストなどです。
大きなコンテキストウィンドウが問題を解決すると考えること。ウィンドウを大きくすれば難しい設計判断を先送りにできますが、無関係なコンテキストが及ぼすコスト、応答時間、品質への影響はなくなりません。コストが見えにくくなるだけです。
コストだけを最適化すること。検証しにくく、根拠が薄く、質問者にとって役立ちにくい回答であれば、安くても優れた回答とは言えません。
情報取得の質を測らずにトークン数だけを測ること。問題の本当の原因が情報取得の層にある場合、トークン数だけでは、なぜ回答が高コストで一貫しないのかを説明できません。
コンテキストを圧縮しすぎること。コンテキストの圧縮が役立つのは、重要な詳細が残る場合に限られます。回答が依存する肝心な根拠を取り除けば、システムは安くなっても回答の質は下がります。
これらの誤りはいずれも、同じ本質的な間違いを反映しています。すなわち、トークン効率をプロンプト編集の作業として扱い、システム設計の領域として捉えていないことです。
トークンあたりの成果を高める設計を
企業AIにおけるトークン効率は、プロンプトの問題に見えて、実際にはアーキテクチャの問題です。プロンプトの短縮に注力するチームは、わずかにトークンを節約できるかもしれません。一方、情報取得、コンテキストの選択、処理の調整を改善するチームは、コスト、速度、回答品質をまとめて向上させられます。ただしそのためには、必要なコンテキストだけを適切なタイミングで送るAIシステムを設計する必要があります。
企業のAIチームが、より優れた情報取得と根拠付けによって回答品質と効率をどのように高めているかについては、Glean Platform をご覧ください。
よくある質問
トークン効率とコンテキストウィンドウのサイズは何が違いますか?
コンテキストウィンドウのサイズは、モデルの能力です。モデルが技術的にどれだけのテキストを受け取り処理できるかを指します。一方、トークン効率はシステム設計の領域であり、優れた回答を得るためにその能力をどれだけ実際に使う必要があるかを指します。コンテキストウィンドウが大きいほどシステムの作業余地は広がりますが、それだけでシステムが効率的になるわけではありません。質の低い情報取得や重複したコンテキストを大きなウィンドウで吸収しているチームは、本来必要のない余裕にコストを払っています。目標は、使える最大のウィンドウを埋めることではなく、正しい回答を得るために必要な最小限のウィンドウを使うことです。
企業AIにおけるトークン最適化にはどのような限界がありますか?
トークン最適化には下限があります。ある一定の水準を下回ると、コンテキストを削ることで、モデルが正確で根拠のある回答を出すために必要な材料まで取り除いてしまい、システムは安くなると同時に信頼性も下がります。また最適化は、根本的に弱い情報取得の層や、設計の不十分な処理の調整を補うことはできません。回答品質、情報取得の精度、コンテキストの活用率を測らずにトークン数だけに注目するチームは、結果として軽くはなっても質の劣るシステムに行き着くことがよくあります。
情報取得の質がトークンコストに大きく影響するのはなぜですか?
情報取得の質は、どれだけのコンテキストがモデルに届くかを直接左右します。そのため、企業AIシステムにおいて最も効果の大きい変数の一つです。情報取得が不正確だと、モデルは必要以上のトークンを受け取ります。文書が多すぎたり、分割の範囲が適切でなかったり、順位付けが甘く回答に何も寄与しない根拠が混ざったりします。特に、情報取得で補強する生成(RAG、検索拡張生成)のシステムでは問題が積み重なります。具体的でアクセス権を考慮した一節ではなく、幅広い類似一致を返す RAG パイプラインは、各ステップでモデルにノイズを処理させてしまいます。情報取得の精度を後回しにせず、最優先の設計上の制約として扱えば、トークン効率は自然とついてくる傾向があります。
トークン効率の観点で、エンタープライズサーチは標準的な RAG とどう違いますか?
基本的なRAG（検索拡張生成）の実装の多くは、類似度にもとづく検索に大きく依存しています。一方、エンタープライズ検索はこれに加えて、アクセス権、情報の新しさ、所有者、システム間の関連性といった情報を組み合わせます。こうした追加の情報があることで、エンタープライズ検索はより正確に対象を絞り込めます。幅広く類似する箇所をまとめて返すのではなく、関連性の高い少数の文章だけを返せるのです。トークンの効率という観点では、この違いが大きな意味を持ちます。Gleanのエンタープライズ検索はこうした仕組みを土台に作られています。そのため、プロンプトを長くしたりコンテキストウィンドウを広げたりして後から埋め合わせるのではなく、検索の段階でトークンの無駄を減らせます。
Gleanはエンタープライズ向けのAIシステムでトークンの無駄をどのように減らすのですか？
Gleanは、社内の最新情報、システムをまたいだアクセス権の管理、コンテンツ同士の関連性にもとづいて検索を行います。これにより、AIシステムは大量の文書をまとめて取り込むのではなく、関連性の高い少数の根拠だけを取得します。Gleanは「誰が質問しているか」「その人が何を閲覧できる権限を持っているか」「複数のツールにまたがるコンテンツが質問とどう関係するか」を把握しているため、文書全体ではなく必要な箇所だけを返せます。その結果、モデルに届く不要な情報が減り、コスト、応答速度、回答の品質が同時に改善されるのが一般的です。
