今回の論文
今回取り上げるのは、Silei Xu、Wenhao Xie、Lingxiao Zhao、Pengcheng He による論文「Chain of Draft: Thinking Faster by Writing Less」です。2025年2月25日に arXiv へ投稿され、2025年3月3日に改訂版が公開されています。公開元は arXiv、研究分野は LLM の推論手法と推論効率化です。URL は https://arxiv.org/abs/2502.18600 です。
この論文を選んだ理由は、モデル自体を変えず、プロンプト設計だけで推論コストと遅延をかなり下げられるからです。推論重視の AI アプリでは、精度だけでなくレスポンス速度と API コストも重要です。そのバランスを考えるうえで、かなり実務的な示唆があります。
どんな技術か
Chain of Draft は、LLM に長い思考過程を説明させる代わりに、必要最小限の「短い下書き」を積み上げて推論させる技術です。
通常の Chain-of-Thought では、モデルに「順を追って考えてください」と促し、途中の reasoning を文章で詳しく出させます。これは精度向上に効く一方で、出力トークンが増えやすく、応答も遅くなります。特に本番の API 利用では、この冗長さがそのままコストと待ち時間になります。
Chain of Draft はここを変えます。途中の思考を完全に消すのではなく、各ステップを短いメモのように圧縮します。つまり、「考えない」のではなく、「必要なことだけ短く書いて考える」方式です。人が計算やロジック問題を解くときに、長文説明ではなく式や要点だけを紙に書く感覚に近いです。
課題
この技術が解決しようとしているのは、推論性能を上げるための Chain-of-Thought が、実運用では重すぎるという問題です。
何が難しいのかというと、複雑な問題では途中の状態を一切外に出さないと、モデルが計算や条件整理を安定して進めにくいことです。そのため direct answer だけでは精度が落ちやすく、何らかの中間推論は欲しくなります。
一方で、既存の方法ではどこに限界があるのかというと、Chain-of-Thought は有効でも、途中説明が長くなりすぎがちです。算数なら文章で状況を言い直し、常識推論なら前提を何度も繰り返し、記号的推論でも細かい言い換えが増えます。これは読者向けの説明としては親切でも、モデルが答えにたどり着くためだけなら不要な部分が多いです。
なぜこの課題を解く必要があるのかというと、AI システムは研究デモではなく、継続的な API 呼び出しの上で動くからです。エージェント、検索支援、コード支援、業務自動化などでは、1回の推論で増える数百トークンが、そのまま月間コストや体感速度に効いてきます。
実際の AI システムでは、複数ツールを呼ぶエージェント、長いユーザー入力を処理するチャット、反復的に推論するワークフローなどで問題になります。1回ごとの差は小さく見えても、推論回数が多いプロダクトほど冗長な reasoning のコストが積み上がります。
用語解説
- Chain-of-Thought
- LLM に途中の思考過程を段階的に書かせる prompting 手法です。精度向上に有効ですが、出力が長くなりやすく、この記事の主題である CoD はその冗長さを削ろうとしています。
- Few-shot prompting
- いくつかの入出力例を先に見せてから本番の問題を解かせる方法です。この論文では、CoD の書き方をモデルに覚えさせるために few-shot 例が重要で、ゼロショットでは性能が落ちることが示されています。
- 推論トークン
- 最終回答に至るまでにモデルが出力する途中の reasoning トークン群です。CoD はこの部分を短くし、性能をなるべく落とさずにコストと遅延を下げる狙いがあります。
- レイテンシ
- ユーザーが応答を待つ時間です。推論品質が同じでも、途中出力が長いと応答完了までの時間が伸びます。CoD は単なる token 節約ではなく、実時間の短縮も重視しています。
- ゼロショット
- 手本を与えずに、その場の指示だけで解かせる設定です。CoD は「短く考える」スタイル自体をモデルに誘導する必要があるため、few-shot ありとなしで挙動差が大きい点が重要です。
技術の仕組み
Chain of Draft の仕組みはシンプルですが、発想はかなり実務的です。ポイントは「推論を消す」のではなく、「1ステップあたりの表現量を絞る」ことです。
基本アイデア
CoD の基本アイデアは、推論の各ステップを短い草案に制限することです。論文では、各 reasoning step を最大5語程度に抑えるようにモデルへ指示しています。重要なのは厳密なルールで縛るのではなく、短く書くスタイルへ誘導している点です。
たとえば通常の CoT なら「まず合計個数を確認し、次に現在残っている数を引きます」のように説明しがちですが、CoD では「20 - 12 = 8」のように、本当に必要な変換だけを残します。説明文を圧縮し、状態更新だけを残すイメージです。
モデル構造は変えない
この手法は新しいモデル構造を必要としません。Transformer を改造したり、追加学習をしたりするのではなく、既存の汎用 LLM に対してプロンプトだけで適用できます。
この点が大きな利点です。モデルの再学習や蒸留を伴わないので、すでに使っている API モデルにそのまま試しやすいです。研究としては軽量ですが、プロダクト適用のしやすさは高いです。
few-shot で「短い考え方」を教える
論文では、Standard、CoT、CoD の3種類の prompting を比較しています。CoD では、「考え方を短く書く」few-shot 例を人手で用意し、モデルにそのスタイルを真似させます。
ここで効いているのは、答えだけを短くするのではなく、中間表現のフォーマットまで手本として見せていることです。つまり CoD は、回答長の制御というより、推論スタイルの誘導です。
推論方法は段階を保ったまま圧縮する
CoD は direct answer のように途中ステップを完全に捨てるわけではありません。段階的な推論そのものは維持します。ただし、各段階を自然言語の長文説明ではなく、式、短い記号、状態の要約に寄せます。
この発想は重要です。精度改善に効いていたのは「推論の存在」なのか、「長い説明」なのかを分けて考えているからです。論文の立場は、精度に効く本体は前者であり、後者はかなり削れるというものです。
タスクごとに固定総予算ではなく、各ステップを短くする
既存研究には、全体の reasoning token 予算を見積もる方法もあります。ただしその方式だと、問題ごとの難しさ推定や追加の LLM 呼び出しが必要になることがあります。
CoD はそこを避けています。総量を先に決めるのではなく、各ステップを短く保つだけなので、途中で必要ならステップ数は増やせます。つまり「長考は禁止」ではなく、「冗長な言い回しは禁止」に近い設計です。
実装上は prompt template と出力整形で試せる
実装面では、CoD は比較的導入しやすいです。たとえば system prompt や few-shot テンプレートに「各推論ステップは短い草案で書く」「必要最小限の記号と中間結果だけ出す」といった制約を加えるだけでも近い挙動を試せます。
もちろん本論文どおりの性能を出すには、タスクごとの few-shot 例や出力抽出を丁寧に作る必要があります。ただ、モデル重みを触らずに改善余地があるというのは、かなり実践的です。
実験と結果
論文では、算術推論、常識推論、記号推論の3系統で CoD を評価しています。比較対象は direct answer の Standard prompting と、従来の CoT です。モデルは GPT-4o と Claude 3.5 Sonnet が使われています。
何を検証したのか
検証の主眼は、CoD が CoT に近い精度を保ちながら、出力トークン数とレイテンシをどれだけ下げられるかです。つまり「速いが雑」では意味がないので、精度と効率を同時に見ています。
どんなデータセットや評価指標を使ったのか
算術推論では GSM8K、常識推論では BIG-bench の date understanding と sports understanding、記号推論ではコイン反転タスクが使われています。評価指標は主に accuracy、出力 token 数、Latency です。
GSM8K では精度を大きく保ったままトークンを約8割削減
GSM8K では、GPT-4o の Standard が 53.3% だったのに対し、CoT は 95.4%、CoD は 91.1% でした。Claude 3.5 Sonnet でも Standard 64.6%、CoT 95.8%、CoD 91.4% です。
精度だけ見ると CoT が最良ですが、token 数は GPT-4o で 205.1 から 43.9、Claude 3.5 Sonnet で 190.0 から 39.8 まで減っています。論文では、平均出力 token 数を約80%削減し、レイテンシも GPT-4o で 4.2 秒から 1.0 秒、Claude 3.5 Sonnet で 3.1 秒から 1.6 秒へ短縮したと報告しています。
これは、「CoT の精度を完全に維持する」のではなく、「実用上十分高い精度を残しつつ、推論コストを大きく下げる」設計だと読むのが適切です。
常識推論では CoT を上回る場面もあった
date understanding では、GPT-4o の CoD は 88.1% で CoT の 90.2% にやや届きませんでしたが、Claude 3.5 Sonnet では CoD が 89.7% で CoT の 87.0% を上回りました。
sports understanding ではさらに顕著で、GPT-4o は CoD が 98.3%、CoT が 95.9%、Claude 3.5 Sonnet は CoD が 97.3%、CoT が 93.2% でした。しかも Claude 3.5 Sonnet では token 数が 189.4 から 14.3 へ減っており、論文でも 92.4% 削減と報告されています。
この結果から言えるのは、長く説明すること自体が常に推論品質を上げるわけではないということです。タスクによっては、余計な説明を減らしたほうがむしろブレが少なくなる可能性があります。
記号推論では精度を落とさず高速化できた
コイン反転タスクでは、GPT-4o と Claude 3.5 Sonnet の両方で CoT と CoD が 100% 精度を達成しています。つまりこの種の問題では、長文の reasoning はほぼ不要だったことになります。
一方で token 数は、GPT-4o で 52.4 から 16.8、Claude 3.5 Sonnet で 135.3 から 18.9 に減っています。ルールベース寄りの多段処理では、短い状態更新だけでも十分な場合が多いことを示しています。
限界実験では few-shot 依存性が見えた
ゼロショット GSM8K では CoD の性能がかなり落ちています。GPT-4o では CoT 94.8% に対し CoD 84.4%、Claude 3.5 Sonnet では CoT 90.4% に対し CoD 65.5% でした。
論文では、CoD 形式の reasoning が学習データ中で十分一般化されていないため、手本なしでは「短いが有効な推論」を安定して作りにくいのではないかと考察しています。ここは実務でも重要で、短縮プロンプトは雑に入れるだけでは効かない可能性があります。
何に使える？
Chain of Draft は、推論の正確さが欲しいが、毎回の reasoning を長く出したくない用途で特に使いやすいです。
エージェントの内部推論コスト削減
ツール呼び出し型エージェントでは、1タスク中に何度も推論が走ります。各ステップで長い CoT を出していると、待ち時間も API コストも膨らみます。CoD 的な短い内部メモへ置き換えると、推論の足場を残しつつオーバーヘッドを減らしやすいです。
コード支援や SQL 生成の中間思考の短縮
コード生成や SQL 生成でも、モデルに段階を踏ませたい場面があります。ただし、毎回長文で説明させる必要はありません。変数、条件、変換方針だけを短く列挙する CoD 風の出力にすれば、品質を保ちながら速度改善が見込めます。これは論文の直接評価対象ではないため推測を含みますが、推論構造が似たタスクでは十分試す価値があります。
高頻度チャットや業務自動化のコスト管理
社内チャットボットや業務支援ツールでは、単発精度より月間コストの最適化が重要になることがあります。CoD はモデルを変えずに token 使用量を減らせるので、まず試す価値のある改善策です。
モバイルやリアルタイム UI の体感速度改善
ユーザーが待ち時間に敏感なプロダクトでは、数秒の差が継続利用率に響きます。CoD は長文 reasoning を減らして応答完了までを短くできるため、リアルタイム寄りの体験設計と相性が良いです。
開発や事業へのヒント
この論文から得られるヒントは、推論強化を「もっと大きいモデルを使う」だけで考えなくてよいという点です。推論の書かせ方そのものが、コスト構造を大きく変えます。
まずは内部プロンプトの無駄を測る
自分で AI アプリを作るなら、最初に見るべきはモデル精度ではなく、内部 reasoning の長さかもしれません。もしツール呼び出し前後で毎回長い説明を出しているなら、そこは削減余地があります。CoD は、その削り方に具体的な型を与えてくれます。
「説明用出力」と「計算用出力」を分ける
既存サービスの改善に使えそうな考え方として、ユーザーへ見せる説明文と、モデル内部で必要な推論メモを分離する設計があります。内部では CoD で短く考えさせ、最終出力だけ人間向けに整えるほうが合理的な場面は多いです。
小規模プロダクトでも導入しやすい
CoD の良いところは、インフラ変更や学習基盤がなくても試せることです。few-shot テンプレートの改善だけで検証できるため、小規模 SaaS や個人開発でも取り入れやすいです。特に API 利用料が重い段階では、かなり効きやすいはずです。
今後は「長く考える」より「短く正確に考える」最適化が重要
今後注目しておくべき方向性は、推論 token を増やす競争だけではありません。どの情報を中間表現として残せば十分か、どこまで省略しても壊れないかを最適化する流れです。推論モデル、エージェント設計、推論キャッシュなどとも相性が良い考え方です。
限界
まず、CoD は万能ではありません。論文でもゼロショット設定では性能が落ちており、短い推論の書き方を手本で示すことが重要です。つまり、プロンプトを短くしただけで必ず良くなるわけではありません。
次に、小さいモデルでは CoT との差が広がりました。論文の小規模モデル実験では、CoD は direct answer より改善するものの、CoT ほどの精度には届きませんでした。モデルに十分な推論力がない場合、圧縮しすぎると途中状態を保持しきれない可能性があります。
また、数学や記号操作のように中間状態が明確な問題では相性が良い一方、探索的で曖昧な問題では最適な短さが変わるはずです。どのタスクでも「5語以内」が最適とは限りません。
実装面では、few-shot 例の設計が甘いと、単に雑な省略になってしまうおそれがあります。短いこと自体が目的ではなく、必要情報だけを残した compact reasoning を作ることが本質です。
最後に、この論文は主に算術、常識、記号推論で評価されています。RAG、コード生成、業務フロー自動化、マルチステップエージェントでの効果は有望ですが、そこは追加検証が必要です。
よくある質問
Q. Chain of Draft は Chain-of-Thought を置き換える技術ですか？
A. 完全な置き換えというより、実運用での軽量版と考えるのが近いです。最高精度だけを狙うなら CoT が有利な場面もありますが、CoD は精度を大きく落とさずに token 数と遅延を減らせるのが強みです。
Q. どんなタスクで特に効きやすいですか？
A. 算術、記号操作、条件整理のように、中間状態を短いメモで表せるタスクで効きやすいです。ルールベースの推論や構造化された意思決定にも相性があります。
Q. few-shot 例は必須ですか？
A. この論文の結果を見る限り、かなり重要です。ゼロショットでは CoD の性能が落ちているため、少なくとも代表例を数本与えて「どう短く考えるか」を示したほうがよいです。
Q. 小さいモデルでも使えますか？
A. 使えますが、効果は限定的な可能性があります。論文では 3B 以下のモデルで CoD は CoT より低精度でした。小規模モデルでは、まず推論自体を安定させる工夫と併用するほうがよさそうです。
Q. 本番環境で導入するときの注意点は何ですか？
A. 「短くさせる」ことだけを目標にしないことです。短くても必要な状態遷移が残っているか、タスクごとに評価する必要があります。精度、token 数、応答時間を一緒に測って判断するのが安全です。
今日の学び
この論文は、Chain-of-Thought が推論精度を上げる一方で、出力トークンと遅延を増やしてしまう課題を扱いました。
それに対して Chain of Draft は、途中の思考を長文ではなく短い下書きとして出させることで、推論の足場を保ちながらコストを下げようとしました。
そこから得られるヒントは、AI アプリの品質改善はモデル選定だけではなく、内部推論のフォーマット設計でも大きく進められるということです。