論文概要(Abstract)
Chain-of-Thought(CoT)Promptingは、大規模言語モデル(LLM)に中間推論ステップを生成させることで、複雑な推論タスクの正答率を大幅に向上させる手法です。Wei et al.(2022, Google Brain)は、Few-shot プロンプトの例示に「思考の連鎖」を含めるだけで、算術推論・常識推論・記号推論の3領域で一貫した性能向上を実証しました。特にPaLM 540Bモデルでは、GSM8K(数学文章題)ベンチマークでファインチューニング済みGPT-3+検証器を上回るState-of-the-Art精度を達成しています。
この記事は Zenn記事: 2026年版プロンプトテクニック大全:8手法の使い分けとコンテキスト設計 の深掘りです。
情報源
- arXiv ID: 2201.11903
- URL: https://arxiv.org/abs/2201.11903
- 著者: Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma et al.(Google Brain)
- 発表年: 2022(NeurIPS 2022採択)
- 分野: cs.CL, cs.AI
背景と動機(Background & Motivation)
LLMのスケーリングは翻訳・要約などの単純タスクでは劇的な性能向上をもたらしましたが、多段階の算術推論(「リンゴが5個あり、3個食べて2個もらったら?」のような文章題)や論理推論ではスケーリングだけでは不十分でした。従来のFew-shot prompting(入出力ペアの例示)では、モデルは最終回答のみを生成するため、中間的な推論過程が欠落し、複雑な問題で誤答しやすいという課題がありました。
人間が複雑な問題を解くとき、頭の中で段階的に思考を展開します。Wei et al.はこの直感をLLMに適用し、「例示の中に推論ステップを含めることで、モデル自身も推論ステップを生成するようになるのではないか」という仮説を検証しました。
主要な貢献(Key Contributions)
- 貢献1: Few-shotプロンプトの例示に中間推論ステップ(Chain of Thought)を含める手法を提案し、追加学習なしでLLMの複雑推論能力を大幅に向上
- 貢献2: 算術推論(GSM8K, SVAMP, ASDiv, AQuA, MAWPS)、常識推論(CSQA, StrategyQA)、記号推論(Last Letter, Coin Flip)の3領域・計10ベンチマークで一貫した有効性を実証
- 貢献3: CoTの効果がモデルスケールに依存する「創発的能力(emergent ability)」であることを発見。約100B以上のパラメータで効果が顕著に現れる
技術的詳細(Technical Details)
Chain-of-Thoughtの基本メカニズム
標準的なFew-shot promptingでは、入力 $x$ に対して出力 $y$ のペア ${(x_i, y_i)}{i=1}^k$ を例示として与え、新しい入力 $x{test}$ に対する出力を生成させます。
CoT promptingでは、各例示に推論ステップの系列 $c_i = (c_i^1, c_i^2, \ldots, c_i^m)$ を追加し、${(x_i, c_i, y_i)}_{i=1}^k$ の形式で提示します。
\[p(y \mid x) = \sum_c p(y \mid c, x) \cdot p(c \mid x)\]ここで、
- $x$: 入力(問題文)
- $c$: Chain of Thought(中間推論ステップの系列)
- $y$: 最終回答
- $p(c \mid x)$: モデルが入力に対して推論チェーンを生成する確率
- $p(y \mid c, x)$: 推論チェーンと入力から最終回答を導出する確率
直感的には、モデルが中間推論ステップ $c$ を明示的に生成することで、各ステップで「次に何を計算すべきか」が明確になり、最終回答 $y$ の精度が向上します。
例示の構造
CoTプロンプトの構造を具体例で示します。
標準Few-shot(CoTなし):
1
2
Q: ロジャーはテニスボールを5個持っている。テニスボールの缶を2つ買った。各缶には3個入っている。合計は?
A: 11
CoT Few-shot:
1
2
Q: ロジャーはテニスボールを5個持っている。テニスボールの缶を2つ買った。各缶には3個入っている。合計は?
A: ロジャーは最初5個持っている。2缶×3個=6個買った。5+6=11。答えは11。
この「A:」の部分に推論ステップを含めることがCoTの核心です。
アルゴリズム
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
from openai import OpenAI
def chain_of_thought_prompt(
question: str,
exemplars: list[dict[str, str]],
model: str = "gpt-4"
) -> str:
"""Chain-of-Thought Few-shot Promptingの実装
Args:
question: 解きたい問題文
exemplars: CoT例示のリスト。各要素は
{"question": str, "thought": str, "answer": str}
model: 使用するモデルID
Returns:
モデルの生成テキスト(推論ステップ+最終回答)
"""
client = OpenAI()
# Few-shot例示を構築
messages = [
{"role": "system", "content": "問題を段階的に考えて解いてください。"}
]
for ex in exemplars:
messages.append({"role": "user", "content": ex["question"]})
messages.append({
"role": "assistant",
"content": f"{ex['thought']}\n答えは{ex['answer']}。"
})
# 新しい問題を追加
messages.append({"role": "user", "content": question})
response = client.chat.completions.create(
model=model,
messages=messages,
temperature=0,
max_tokens=512
)
return response.choices[0].message.content
スケーリングとCoTの関係
論文の重要な発見は、CoTの効果がモデルサイズに強く依存することです。
| モデルサイズ | 標準Few-shot | CoT Few-shot | 改善幅 |
|---|---|---|---|
| ~1B | 2.0% | 2.1% | +0.1% |
| ~10B | 7.5% | 8.2% | +0.7% |
| ~100B | 17.7% | 43.0% | +25.3% |
| ~540B (PaLM) | 56.5% | 74.4% | +17.9% |
この結果は「創発的能力」として知られるパターンと一致します。小さなモデルでは推論ステップの質が低く、かえって精度が下がる場合もあります(100B未満では「幻覚的な推論チェーン」が生成されるリスク)。
実装のポイント(Implementation)
例示の設計指針
CoTの性能は例示の質に大きく依存します。論文から得られる実装の指針は以下の通りです。
- 例示数は8個が最適: 論文では8個の例示を使用。2-4個でも効果はありますが、8個で安定した性能が得られます
- 推論ステップは自然言語で: 形式的な数式よりも自然言語での説明が効果的です
- 多様なパターンを含める: 同じ種類の問題ばかりでなく、異なる推論パターンをカバー
- 正確な例示が重要: 誤った推論ステップを含む例示は性能を大幅に低下させます
よくあるバグ・落とし穴
- 回答抽出の失敗: モデルが推論ステップのみを生成し、最終回答を明示しないケース。「答えは」「したがって」等のマーカーを正規表現で抽出する処理が必要
- 推論ステップの肥大化: 過度に詳細な推論ステップはトークン消費の増加だけでなく、エラー累積のリスクも増加
- 小さなモデルへの適用: 100B未満のモデルに適用すると、推論チェーンの質が低下し、標準Few-shotより性能が悪化するケースがある
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import re
def extract_answer(response: str) -> str:
"""CoT応答から最終回答を抽出
Args:
response: モデルの生成テキスト(推論ステップ+回答)
Returns:
抽出された最終回答文字列
"""
# 「答えは」「したがって」パターンで抽出
patterns = [
r"答えは(.+?)。",
r"したがって[、,]\s*(.+?)。",
r"The answer is (.+?)\.",
]
for pattern in patterns:
match = re.search(pattern, response)
if match:
return match.group(1).strip()
# フォールバック: 最後の数値を抽出
numbers = re.findall(r"-?\d+\.?\d*", response)
return numbers[-1] if numbers else response.strip()
Production Deployment Guide
AWS実装パターン(コスト最適化重視)
CoTプロンプティングをプロダクション環境で運用する場合、推論ステップの生成により出力トークン数が増加するため、コスト管理が重要です。
トラフィック量別の推奨構成:
| 規模 | 月間リクエスト | 推奨構成 | 月額コスト | 主要サービス |
|---|---|---|---|---|
| Small | ~3,000 (100/日) | Serverless | $50-150 | Lambda + Bedrock + DynamoDB |
| Medium | ~30,000 (1,000/日) | Hybrid | $300-800 | Lambda + ECS Fargate + ElastiCache |
| Large | 300,000+ (10,000/日) | Container | $2,000-5,000 | EKS + Karpenter + EC2 Spot |
Small構成の詳細(月額$50-150):
- Lambda: 1GB RAM, 60秒タイムアウト(CoTは出力が長いため余裕を持たせる)$20/月
- Bedrock: Claude 3.5 Haiku, Prompt Caching有効(CoT例示のキャッシュで30-90%削減)$80/月
- DynamoDB: On-Demand, CoT結果キャッシュ用 $10/月
- CloudWatch: 基本監視 $5/月
コスト削減テクニック:
- CoT例示部分をPrompt Cachingでキャッシュ(固定部分が大きいCoTに特に有効)
- 単純なタスクはCoT不要 → ルーティングで振り分け(コスト50%削減可能)
- Bedrock Batch API使用で非リアルタイム処理は50%割引
- Spot Instances使用で最大90%削減(EKS + Karpenter)
コスト試算の注意事項: 上記は2026年2月時点のAWS ap-northeast-1(東京)リージョン料金に基づく概算値です。実際のコストはトラフィックパターン、リージョン、出力トークン数により変動します。最新料金はAWS料金計算ツールで確認してください。
Terraformインフラコード
Small構成 (Serverless): Lambda + Bedrock + DynamoDB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = "cot-inference-vpc"
cidr = "10.0.0.0/16"
azs = ["ap-northeast-1a", "ap-northeast-1c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
enable_nat_gateway = false
enable_dns_hostnames = true
}
resource "aws_iam_role" "lambda_cot" {
name = "lambda-cot-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "lambda.amazonaws.com" }
}]
})
}
resource "aws_iam_role_policy" "bedrock_invoke" {
role = aws_iam_role.lambda_cot.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"]
Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-haiku*"
}]
})
}
resource "aws_lambda_function" "cot_handler" {
filename = "lambda.zip"
function_name = "cot-inference-handler"
role = aws_iam_role.lambda_cot.arn
handler = "index.handler"
runtime = "python3.12"
timeout = 60
memory_size = 1024
environment {
variables = {
BEDROCK_MODEL_ID = "anthropic.claude-3-5-haiku-20241022-v1:0"
DYNAMODB_TABLE = aws_dynamodb_table.cot_cache.name
ENABLE_PROMPT_CACHE = "true"
COT_EXEMPLAR_COUNT = "8"
}
}
}
resource "aws_dynamodb_table" "cot_cache" {
name = "cot-response-cache"
billing_mode = "PAY_PER_REQUEST"
hash_key = "prompt_hash"
attribute {
name = "prompt_hash"
type = "S"
}
ttl {
attribute_name = "expire_at"
enabled = true
}
}
運用・監視設定
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import boto3
cloudwatch = boto3.client('cloudwatch')
# CoT出力トークン量の監視アラーム
cloudwatch.put_metric_alarm(
AlarmName='cot-output-token-spike',
ComparisonOperator='GreaterThanThreshold',
EvaluationPeriods=1,
MetricName='OutputTokens',
Namespace='Custom/CoT',
Period=3600,
Statistic='Sum',
Threshold=500000,
AlarmDescription='CoT出力トークン量が閾値を超過(コスト急増の可能性)'
)
コスト最適化チェックリスト
- ~100 req/日 → Lambda + Bedrock (Serverless) - $50-150/月
- ~1000 req/日 → ECS Fargate + Bedrock (Hybrid) - $300-800/月
- 10000+ req/日 → EKS + Spot Instances (Container) - $2,000-5,000/月
- CoT例示のPrompt Caching有効化(30-90%削減)
- 単純タスクのルーティング(CoT不要タスクを振り分け)
- Bedrock Batch API使用(非リアルタイム処理で50%削減)
- Spot Instances優先(EKS + Karpenter自動管理で最大90%削減)
- DynamoDB TTLで古いキャッシュ自動削除
- Lambda メモリサイズ最適化(CloudWatch Insights分析)
- AWS Budgets設定(月額予算の80%で警告)
実験結果(Results)
算術推論ベンチマーク
| ベンチマーク | 標準Few-shot (PaLM 540B) | CoT (PaLM 540B) | 改善率 |
|---|---|---|---|
| GSM8K | 56.5% | 74.4% | +17.9% |
| SVAMP | 79.0% | 86.6% | +7.6% |
| ASDiv | 74.0% | 81.3% | +7.3% |
| AQuA | 35.8% | 52.4% | +16.6% |
| MAWPS | 89.5% | 93.3% | +3.8% |
GSM8Kでは、CoT+PaLM 540Bがファインチューニング済みGPT-3+検証器(55%)を大幅に上回りました。
常識推論・記号推論
| ベンチマーク | 分野 | CoT改善幅 |
|---|---|---|
| CommonsenseQA | 常識推論 | +2.1% |
| StrategyQA | 戦略的推論 | +12.3% |
| Last Letter Concat | 記号推論 | +25.5% |
| Coin Flip | 記号推論 | +33.6% |
特に記号推論(形式的なルールの適用)で最大の改善が見られました。これは、記号推論がステップバイステップの処理と特に相性が良いことを示唆しています。
失敗分析
CoTでも解けなかったケースの分析から、以下のパターンが判明しています。
- 計算エラー(46%): 推論ステップは正しいが、途中の算術計算を間違える
- ステップ欠落(26%): 必要な推論ステップをスキップする
- 意味理解エラー(28%): 問題文の解釈自体を間違える
実運用への応用(Practical Applications)
CoTは以下の実務領域で特に効果的です。
金融分析: 財務諸表の多段階計算(利益率算出→前年比較→異常検知)において、CoTにより計算の透明性と正確性が向上。中間ステップが監査証跡として機能する点もコンプライアンス上有利です。
カスタマーサポート: 複雑な問い合わせ(返品条件の判定、保証適用可否の判断)で段階的な判断を明示化。CoTによる推論過程は、オペレーターの判断根拠の説明にも活用できます。
教育: 数学・理科の問題解説において、CoTの推論ステップがそのまま解説として利用可能。生徒の理解度に合わせた詳細度の調整も可能です。
関連研究(Related Work)
- Self-Consistency (Wang et al., 2022): CoTの出力を複数サンプリングし多数決で精度向上。CoTの自然な拡張として、特に高精度が要求されるタスクで有効
- Zero-shot CoT (Kojima et al., 2022): 「Let’s think step by step」の一文追加だけでCoT的な推論を引き出す手法。例示作成コストゼロという大きな利点がある
- Tree of Thoughts (Yao et al., 2023): CoTの線形的な推論を木探索に拡張。バックトラックや並列探索が可能となり、Game of 24等で74%の精度を達成
まとめと今後の展望
Wei et al.のChain-of-Thought Promptingは、LLMの推論能力を引き出すための最も基本的かつ効果的な手法です。追加学習不要で、プロンプトに推論ステップの例示を加えるだけという手軽さが最大の強みです。
実務では、まず標準Few-shotを試し、精度不足ならCoTに切り替える段階的アプローチが推奨されます。100B以上のモデル(GPT-4, Claude 3.5, Gemini Pro等)であれば安定した効果が期待できます。今後は、CoTの自動生成(Auto-CoT)や検証機構(Self-Consistency)との組み合わせが標準的なプラクティスとなるでしょう。
参考文献
- arXiv: https://arxiv.org/abs/2201.11903
- Related Zenn article: https://zenn.dev/0h_n0/articles/8d05ea9be7e0f3