推論スキル再利用でトークンを削減する
TRS（Thinking with Reasoning Skills）の仕組みと実務への応用
推論LLMは問題を解くたびに長い思考トークンを消費する。TRS（Thinking with Reasoning Skills）は過去の推論軌跡をコンパクトなスキルに蒸留してRAG的に再利用し、トークンを削減しながら精度を維持する。数学・コーディング実験の結果と実務実装パターンを解説する。
o1 や DeepSeek R1 などの推論モデルは「考えてから答える」設計のため、複雑な問題ほど思考トークン（chain-of-thought の出力）が膨れ上がる。API コストが 10 倍、20 倍になるケースも珍しくなく、LLM アプリの本番運用で頭を抱えているエンジニアは多い。
この記事では、arXiv 2604.21764 として公開された論文「Thinking with Reasoning Skills: Fewer Tokens, More Accuracy」（Guangxiang Zhao ほか、Qiyuan Tech・清華大学・HKU・北京大学、2026-04 公開）が提案する TRS（Thinking with Reasoning Skills） の仕組みを解説し、実務にどう応用できるかを考える。なお本論文は 2026-04 時点で arXiv の査読前プレプリントであり、今後の改訂で内容が変わる可能性がある点はあらかじめ断っておく。
推論モデルのトークンコスト問題
ChatGPT o1 や DeepSeek R1 に代表される推論モデルは、答えを出す前に「内部思考（thinking）」を出力する。この思考プロセスが精度の源泉である一方、出力トークン数が通常の LLM の数倍〜数十倍になるという副作用を持つ。
例として、数学の難問を o1 に投げると思考トークンだけで 2,000〜5,000 トークンになることがある。同じ問題を 1,000 回処理すれば、それだけで数百万トークンのコストが積み上がる。
より根本的な問題がある。同じパターンの問題が繰り返し来るケース——たとえばカスタマーサポート、定型コード生成、数学ドリルアプリ——でも、推論モデルは毎回「ゼロから推論」する。似た問題で以前やった推論の知識を活かさず、同じような思考プロセスを何度も一から実行してしまうのだ。
TRS はこの「ゼロから推論の繰り返し」を解決するアプローチとして提案されている。
TRS の仕組み：オフライン蒸留とオンライン推論
TRS のコアアイデアは、「過去の推論軌跡を再利用可能な形にコンパクトに圧縮する」ことだ。大きく オフライン蒸留 と オンライン推論 の 2 フェーズに分かれる。
オフライン蒸留：推論軌跡 → 推論スキル
訓練データや過去ログなどの問題セットに対して、推論モデルが生成した長い chain-of-thought を分析し、「推論スキル（Reasoning Skills）」 としてコンパクトに要約・格納する。
論文が定義する推論スキルは次の 3 要素で構成される。
| 要素 | 内容 |
|---|---|
| トリガー条件 | このスキルが使えるのはどんな問題か（例：「2 変数の連立方程式を含む最適化問題」） |
| 解法パターン | そのクラスの問題でうまく機能する推論ステップの骨格 |
| 落とし穴（Pitfall） | 同類問題でよくある間違いや陥りやすい誤りの注意点 |
「落とし穴」を明示的に含める点が特徴的だ。単なる解法テンプレートではなく、「ここで間違えやすい」という知識も圧縮することで、精度低下を抑えている。
これらのスキルを集めて スキルライブラリ を構築する。蒸留は一度だけ行えばよく、以降の推論フェーズでは追加の学習コストは発生しない。
オンライン推論：RAG 的なスキル注入
新しいクエリが来たとき、TRS は以下の流れで推論を誘導する。
- スキル検索: 入力クエリに意味的に近い推論スキルをライブラリから検索（ベクトル類似度検索など）
- プロンプト注入: 取得したスキル（トリガー条件・解法パターン・落とし穴）をシステムプロンプトまたはユーザープロンプトに挿入
- 推論誘導: 注入されたスキルをヒントに推論モデルが思考を進める
この流れは RAG（Retrieval-Augmented Generation）と非常に似ている。ドキュメントの代わりに「推論の知識」を検索・注入するイメージだ。
実験結果（原論文に基づく範囲）
論文では数学とコーディングの 2 ドメインでベンチマーク評価が行われている。以下は論文で報告された主な結果の要約であり、引用する数値はすべて原論文（arXiv 2604.21764）の記載に依拠している。
数学ベンチマーク（DeepMath-103K）
DeepMath-103K は難度の高い数学問題を大量に含むベンチマークで、推論モデルの評価に広く使われる。
TRS を適用した場合と reasoning from scratch（通常の推論）を比較した実験では、思考トークン数を削減しながら同等以上の精度を維持 する結果が報告されている。特に難問サブセット（問題難度が高いものに絞った評価）でも精度の低下が抑えられた点が注目される。
論文によれば、難問サブセットで TRS の効果がより顕著に現れており、「難しい問題ほど適切な推論スキルの注入が効く」という傾向が示唆されている。
コーディングベンチマーク
コーディングタスクでも同様の傾向が確認されており、推論スキルの注入によってトークン消費を抑えつつ正答率を維持できることが示されている。
弱いモデルでの効果
パラメータ数が少ない「弱いモデル」でも TRS の効果が確認されている。スキルライブラリから関連知識を注入することで、モデル単体では難しい問題でも精度が改善するケースが報告されている。これは、スキルライブラリが「外付けの推論知識ベース」として機能していることを示す。
実務への示唆：どんな場面で使えるか
TRS が効果的な場面
同種の問題が繰り返し発生するアプリケーションでこそ、TRS 的アプローチの効果が出やすい。
適用候補:
- カスタマーサポート自動化: 「返金手続きの問い合わせ」「配送遅延の問い合わせ」など、似たパターンの問い合わせが大量に来る。スキルライブラリにパターン別の対応知識を蓄積することで、毎回ゼロから推論させるコストを削減できる。
- 定型コード生成: 「Django モデルのシリアライザーを書く」「SQL の JOIN クエリを最適化する」など、似た問題が繰り返すコード支援ツール。
- 数学ドリル・教育アプリ: 問題カテゴリが限定されており、解法パターンが体系化しやすい。
- コンプライアンス・規約審査: 同じ種類の条文チェックを大量に処理するケース。
共通するのは「問題の種類（クラス）が事前にある程度予測できる」「同じクラスの問題が繰り返し来る」という条件だ。
TRS が不向きな場面
以下のような場面では TRS 的アプローチの恩恵が小さいか、逆に精度低下のリスクがある。
- 毎回まったく新しい問題: スキルライブラリに類似スキルが存在しない場合、不適切なスキルを注入することで推論を誤誘導するリスクがある。
- 探索的・創造的タスク: ブレインストーミング、小説生成、戦略立案など、型にはまらない自由な思考が求められるタスク。
- ドメインが急速に変化する領域: スキルライブラリが陳腐化しやすく、維持コストが高くなる。
実装パターン：3 ステップ
TRS 的なアプローチを自前で実装する場合、以下の 3 ステップが基本構造になる。
ステップ 1: スキルライブラリの設計と構築
まず、自社タスクの問題セット（過去ログ、テストケースなど）から推論軌跡を収集する。推論モデルに長い chain-of-thought を生成させ、それを短いスキル記述に圧縮する作業が必要だ。
# スキル蒸留の概念コード（擬似コード）
def distill_reasoning_skill(problem: str, long_cot: str, llm) -> dict:
prompt = f"""
以下の問題と推論軌跡を分析し、コンパクトな「推論スキル」を抽出してください。
【問題】
{problem}
【推論軌跡】
{long_cot}
出力形式（JSON）:
{{
"trigger_condition": "このスキルが適用できる問題の特徴",
"solution_pattern": "有効な推論ステップの骨格",
"pitfalls": ["よくある間違い1", "よくある間違い2"]
}}
"""
return llm.json_generate(prompt)ステップ 2: RAG 検索
クエリが来たら、スキルライブラリからベクトル類似度検索で関連スキルを取得する。
# スキル検索（OpenAI Embeddings + ベクトルDB 例）
def retrieve_skills(query: str, skill_library, top_k: int = 3) -> list:
query_embedding = embed(query)
results = skill_library.similarity_search(query_embedding, top_k=top_k)
return results # 関連度の高いスキルを返すステップ 3: プロンプト注入
取得したスキルをシステムプロンプトに挿入して推論モデルに渡す。
def build_prompt_with_skills(query: str, skills: list) -> str:
skill_text = "\n".join([
f"【推論スキル {i+1}】\n"
f"適用条件: {s['trigger_condition']}\n"
f"解法パターン: {s['solution_pattern']}\n"
f"注意点: {', '.join(s['pitfalls'])}"
for i, s in enumerate(skills)
])
system_prompt = f"""以下の推論スキルを参考に問題を解いてください。
{skill_text}
ただし、スキルが問題に当てはまらない場合は無視して構いません。"""
return system_prompt, queryコスト試算の考え方
TRS によるコスト削減の大まかな試算は次のように考えられる。
- ベースライン測定: スキル注入なしで 100 問程度サンプリングし、平均思考トークン数を測定する
- 削減率の確認: スキル注入ありで同じ問題セットを実行し、思考トークンの削減率を確認する
- 損益分岐点の計算: スキルライブラリ構築コスト（蒸留に使ったトークン数）÷ 1 クエリあたりの削減トークン数 = 損益分岐クエリ数
たとえば蒸留コストが 100 万トークンで、1 クエリあたり 1,000 トークン削減できるなら、1,000 クエリ以降は純粋なコスト削減になる計算だ。実際の効果はタスクとスキルライブラリの品質に大きく依存するため、本番投入前に小規模 A/B テストを行うことを強く勧める。
限界と注意点
TRS を実務に適用するうえで見落としてはいけない制約を整理する。
1. arXiv 査読前プレプリント（2026-04 時点）
本論文は 2026-04 に arXiv に投稿された査読前プレプリントであり、独立した査読を経た成果ではない。報告されている実験結果が再現されるかどうかは、自社環境での検証が必要だ。
2. スキルライブラリの構築コスト（オフライン蒸留）
スキルライブラリを作るためには、まず大量の問題に対して推論モデルに長い CoT を生成させ、それをスキルに蒸留するオフライン作業が必要だ。この初期コストは無視できない。特に問題の種類が多いドメインでは、ライブラリ構築自体に相当のコンピュートリソースが必要になる。
3. ライブラリの品質・カバレッジ依存
スキルライブラリに品質の低いスキルや不正確な「落とし穴」が混入していると、推論を誤誘導するリスクがある。また、ライブラリに収録されていない種類の問題では効果が出ない（あるいは逆効果になる可能性がある）。スキルの品質評価と定期的なメンテナンスが運用上の課題になる。
4. 未見ドメインへの一般化の限界
論文の実験は数学とコーディングという比較的構造化されたドメインで行われている。より非構造的なタスク（クリエイティブライティング、オープンエンドな問答など）でどの程度機能するかは、論文の範囲外であり未確認だ。自社タスクが論文の実験設定と異なる場合は、効果を過信せず検証ファーストで臨む必要がある。
よくある質問（FAQ）
TRS についての Q&A
実装と適用に関するよくある疑問
TRS はファインチューニングが必要ですか？
不要です。TRS は training-free の手法であり、モデルの重みを変更しません。OpenAI API や Anthropic API などのブラックボックス推論モデルにそのまま適用できます。スキルライブラリの構築（オフライン蒸留）は必要ですが、これはモデルへの追加学習ではなくプロンプトエンジニアリングの範疇です。
どんなベクトルDBを使えばいいですか？
スキルのスケールによります。スキル数が数百〜数千程度なら、シンプルな FAISS（Meta の近似最近傍ライブラリ）でも十分機能します。本番運用でスキルが数万件を超えたり、リアルタイム更新が必要な場合は Qdrant、Weaviate、Pinecone などのマネージドベクトル DB が選択肢になります。検索の精度より、スキル自体の品質のほうが精度に大きく影響するため、まず小規模で実験することを推奨します。
スキルライブラリはどのくらいの量が必要ですか？
論文では具体的な推奨スキル数は示されていませんが、問題のパターン数に比例して必要なスキル数が増えます。実務的には、まず問題をクラスタリングして主要なパターンを 20〜50 程度に分類し、各パターンにつき数件のスキルを蒸留するところから始めるのが現実的です。ライブラリを育てながら効果を測定する反復的なアプローチが適しています。
精度が下がる心配はありませんか？
スキルの品質が低い場合や、問題とスキルのミスマッチが起きた場合には精度が下がるリスクがあります。TRS は「スキルが合わなければ無視してよい」という指示をプロンプトに含めることで緩和しています。実装時は「スキルあり」「スキルなし」のA/Bテストを小規模で行い、精度が維持されていることを確認してから本番適用するのが安全です。
o1 や DeepSeek R1 以外の推論モデルでも使えますか？
はい。TRS は特定のモデルに依存せず、プロンプトで推論を誘導できるモデルであれば原理的に適用可能です。ただし論文の実験が特定のモデルで行われているため、他のモデルでの効果は自前の検証が必要です。また、モデルによって推論プロセスの扱い方（thinking トークンの仕様など）が異なる点にも注意してください。
まとめ
TRS（Thinking with Reasoning Skills）は、推論モデルの「ゼロから推論の繰り返し」という非効率を解消するアプローチだ。過去の推論軌跡をコンパクトな「推論スキル」に蒸留してライブラリ化し、RAG 的に検索・注入することで、思考トークンを削減しながら精度を維持する。
実務での適用が有望な場面は、同種の問題が繰り返し発生するアプリケーション——カスタマーサポート、定型コード生成、教育・数学アプリなど。逆に、毎回異なる探索的タスクや急速にドメインが変化する領域には向かない。
実装の基本構造はシンプルで、「スキルライブラリ構築（蒸留）→ RAG 検索 → プロンプト注入」の 3 ステップだ。Training-free でブラックボックス API と互換性があるため、既存の LLM アプリに段階的に組み込める。
ただし、本論文は 2026-04 時点の arXiv 査読前プレプリントであり、スキルライブラリの構築コストやライブラリ品質への依存、未見ドメインへの一般化といった課題もある。導入前に自社タスクでの小規模 A/B テストを行い、効果を定量的に確認することを強く勧める。
次に読むおすすめ
この記事で TRS の概要をつかんだら、次は実践編として LLM 実装のコストと品質をどう両立するかを深掘りしてみてほしい。推論コスト削減の考え方を実務にどう落とし込むか、さらに具体的な視点で書いた記事を用意している。