プロンプト
フレームワーク
RGC、CRISPE、RTF、CoT、Few-shot、ReAct。主要6フレームワークの使い分けを、日本語の実例と比較で徹底解説。
2026年版: ChatGPT、Claude、Gemini、Perplexityでの適用例つき。
フレームワークは使い分けが命。
プロンプトの質を決めるのは「何を書くか」ではなく「どう構造化するか」です。研究でも実務でも、同じ内容の指示でも構造が違うだけで出力品質が2〜5倍変わることが確認されています。フレームワークは、その構造を誰でも再現可能な形にしたものです。
本ページでは、2026年時点で最も効果的な6つのフレームワーク(RGC、CRISPE、RTF、Chain-of-Thought、Few-shot、ReAct)を、実例と比較表、使い分けのフローチャートで解説します。すべての例は日本語のまま動作し、ChatGPT、Claude、Gemini、Perplexity で動作確認済みです。
迷ったら RGC から始めてください。日常業務の9割はRGCで十分です。そのうえで、複雑な推論が必要なら CoT、形式重視なら RTF、事実ベース分類なら Few-shot、ツール連携なら ReAct、長文戦略文書なら CRISPE へと拡張していくのが実務的な進め方です。
01
RGC
Role / Goal / Context(役割・目的・文脈)
いつ使う: 日常業務の9割をカバーする汎用フレームワーク。メール、ブログ、要約、分析など、出力形式が比較的明確なタスクに最適。
構造テンプレート
# 役割 あなたは[専門性と経験年数]を持つ[肩書き]です。 # 目的 [望む出力を1〜2文で具体的に] # 文脈 - 対象: [誰のためか] - 背景: [この出力が置かれる状況] - 制約: [文字数、禁止事項、トーン] # 出力 [具体的な出力形式]
実例(日本語)
# 役割 あなたは10年のB2B営業経験を持つアカウントエグゼクティブです。 # 目的 商談後のフォローアップメールを日本語で書いてください。 # 文脈 - 相手: 大手製造業の情報システム部長 - 商談で合意: PoCを来月開始 - 懸念: 既存ベンダーとの統合コスト # 出力 件名30字以内、本文180字以内、次のアクションを箇条書き
強み
- ・短い指示で高品質な出力を安定的に得られる
- ・どのモデル(ChatGPT、Claude、Gemini)でも効果
- ・初心者でも10分で習得できる
弱み
- ・複雑な推論が必要なタスクには不十分
- ・ツール連携やマルチステップ処理には不向き
02
CRISPE
Capacity / Role / Insight / Statement / Personality / Experiment
いつ使う: 提案書、戦略文書、複雑な意思決定など、情報密度とトーンの両方が重要な長文出力に使う。
構造テンプレート
# Capacity(能力) [モデルに求める専門能力のレベル] # Role(役割) [具体的な肩書きと経験] # Insight(洞察) [この出力が生み出すべき洞察の質] # Statement(指示) [やってほしいことの明確な指示] # Personality(人柄) [トーン、語り口、スタイル] # Experiment(実験) [試したいバリエーションや比較]
実例(日本語)
# Capacity あなたはマッキンゼーで10年以上、消費財業界のリストラクチャリングを手がけた戦略コンサルタントです。 # Role 日本の大手小売チェーンのCEOに対する戦略アドバイザー。 # Insight 競合各社が見落としている、店舗面積あたり収益性の改善機会を特定する。 # Statement 次の四半期に着手すべき3つの施策を、インパクト×実行難易度でランク付けして提案してください。 # Personality データドリブンで断定的、ただし意思決定者への敬意を保つ。 # Experiment 各施策について、保守的ケースと積極的ケースの2シナリオを提示。
強み
- ・出力の深さとトーンの制御が同時にできる
- ・長文の提案書や戦略文書で特に威力を発揮
- ・複数の側面を網羅的に指示できる
弱み
- ・プロンプト自体が長くなる(300〜500字)
- ・短文タスクでは過剰設計
- ・各要素を埋める時間コストが高い
03
RTF
Role / Task / Format(役割・タスク・形式)
いつ使う: 出力形式が最重要なタスク。表、JSON、Markdown構造化、特定スキーマの返却など、機械的に処理される出力に適する。
構造テンプレート
# Role [専門性を持つ役割] # Task [実行するタスク] # Format [出力の正確な形式、スキーマ、構造]
実例(日本語)
# Role
あなたはデータクリーニングを専門とするデータアナリストです。
# Task
次の顧客データから、有効なメールアドレスと電話番号を抽出してください。
# Format
JSON形式で返却:
{
"records": [
{"name": "...", "email": "...", "phone": "..."}
],
"invalid_count": N
}
余計な説明は不要。JSONのみを出力してください。強み
- ・プログラムから呼ぶ際に最適
- ・パース可能な出力を安定的に得られる
- ・構造的な指示でハルシネーションを減らせる
弱み
- ・創造性を要するタスクには向かない
- ・Formatの厳密さが曖昧な指示では効果が薄い
- ・文脈情報が欠けると質が落ちやすい
04
CoT
Chain-of-Thought(思考の連鎖)
いつ使う: 多段階推論、数値計算、意思決定、コード解析など、最終回答に至るプロセスが重要なタスク。
構造テンプレート
[通常のRGCプロンプト] # 思考プロセス 次の順序で、各ステップを明示的に書いてから最終回答を出してください: 1. 問題の分解 2. 各要素の分析 3. 選択肢の列挙 4. トレードオフの評価 5. 最終回答 各ステップの見出しを明示し、推論を省略しないでください。
実例(日本語)
# 役割 あなたは慎重な思考プロセスを重視するシニアエンジニアです。 # 目的 次のコードにあるバグを特定してください。 [コード] # 思考プロセス 1. <観察> コードが何をしているかを1段落で記述 2. <期待> 何が起きるべきかを明確化 3. <実際> 実際に何が起きているかを記述 4. <仮説> 考えられる原因を最低3つ列挙 5. <検証> 各仮説を、コードと入力から検証 6. <結論> 最も可能性の高い原因と修正案 各ステップを見出し付きで出力してください。
強み
- ・複雑な推論の正確性が劇的に向上(論文では10〜30%改善)
- ・モデルの推論過程を検証できる(間違いの発見が容易)
- ・数学、論理、コードデバッグで特に強力
弱み
- ・出力が長くなる(トークン消費が増える)
- ・単純なタスクでは冗長
- ・ステップ定義が曖昧だと効果が半減
05
Few-shot
Few-shot Learning(少数例学習)
いつ使う: 出力の形式やトーンが特殊で、説明より例で示した方が早いタスク。分類、言い換え、特殊な書式変換など。
構造テンプレート
# タスク [タスクの1文説明] # 例 入力: [例1の入力] 出力: [例1の期待出力] 入力: [例2の入力] 出力: [例2の期待出力] 入力: [例3の入力] 出力: [例3の期待出力] # 本番 入力: [実際の入力] 出力:
実例(日本語)
# タスク 顧客からの問い合わせを、トピックごとに分類してください(請求、技術、営業、その他)。 # 例 入力: 「先月分の請求書が届いていません」 出力: 請求 入力: 「APIがタイムアウトします」 出力: 技術 入力: 「エンタープライズプランの見積もりをください」 出力: 営業 # 本番 入力: 「ログイン時に500エラーが出ます」 出力:
強み
- ・ゼロショットより精度が平均15〜40%高い
- ・説明文なしで挙動を教えられる
- ・特殊な形式変換に非常に強い
弱み
- ・例の質がそのまま出力の質になる
- ・例が古いと出力も時代遅れになる
- ・多様性のない例はバイアスを生む
06
ReAct
Reasoning + Acting(推論と行動)
いつ使う: ツール使用、外部データ取得、マルチステップタスクを行うエージェント的ワークフロー。Function Calling、LangChain、Tool Use と組み合わせる。
構造テンプレート
# タスク [ユーザーの最終目的] # 使用可能ツール - ツールA: [何ができるか] - ツールB: [何ができるか] # 思考プロセス 次のサイクルを繰り返してください: 1. Thought: 今何を考えているか 2. Action: どのツールを使うか 3. Observation: ツールの結果 4. Thought: 結果から次に何をするか 目標に達したら「Final Answer:」と書いて終了してください。
実例(日本語)
# タスク
東京の明日の天気と、それに合わせたランチ提案を教えてください。
# 使用可能ツール
- get_weather(city, date): 天気予報を返す
- suggest_restaurant(cuisine, weather): レストランを提案
# 思考プロセス
Thought: 天気を知る必要がある
Action: get_weather("Tokyo", "2026-04-21")
Observation: 雨、最高気温15℃
Thought: 雨で寒いので、温かい料理が良さそう
Action: suggest_restaurant("ramen", "rainy cold")
Observation: 一蘭 渋谷店、一風堂 新宿店
Final Answer: 明日の東京は雨で15℃と肌寒いです。温かいラーメンが合いそうなので、一蘭の渋谷店をおすすめします。強み
- ・エージェント的な複雑タスクを分解できる
- ・推論過程を検証可能な形で残せる
- ・外部データと推論の統合に強い
弱み
- ・テキストのみのタスクには不要
- ・ツールの設計が悪いと効果が出ない
- ・トークン消費が多い
フレームワークは組み合わせると強い。
実務では単独より組み合わせが効果的です。代表的な組み合わせパターンを紹介します。
RGC + CoT: 意思決定系タスクの鉄板
RGCで役割と目的を明示したうえで、「思考プロセス」セクションを追加してCoTを組み込む。新規事業のGo/No-Go判断、技術選定、採用可否など、根拠の検証が必要な判断に最適。反対意見の明示を強制することで、確証バイアスを抑制できる。
RTF + Few-shot: API連携向けの最強構造
出力形式を厳密に指定したいタスクで、例を3〜5件示すことでフォーマット遵守率が跳ね上がる。JSON返却、CSV生成、特定スキーマへの変換など、プログラムから呼ぶ用途で圧倒的な安定性を発揮する。
CRISPE + CoT: 長文戦略文書の深度設計
CRISPEで専門性とトーンを指定し、CoTで思考過程を明示させる。投資家向け提案書、競合分析、中期戦略など、最終出力の質と根拠の透明性を両立したいケースで使う。コストは高いが、重要文書では投資対効果が大きい。
Few-shot + CoT: 複雑分類タスクの精度向上
分類基準が微妙なタスク(例: 顧客の購買意欲スコアリング)で、各例に「なぜその分類か」の推論を添える。モデルが同じ推論パターンを本番入力にも適用するため、単なるFew-shotより精度が高い。
どれを選ぶべきか、5秒で判断。
出力の性質は?
├─ テキスト中心(メール、記事、要約)
│ ├─ 短い → RGC
│ └─ 長い・重要文書 → CRISPE
├─ 機械処理が目的(JSON、CSV、表)
│ ├─ 形式が単純 → RTF
│ └─ 例示のほうが早い → RTF + Few-shot
├─ 推論が重要(判断、分析、デバッグ)
│ ├─ 単純 → RGC + CoT
│ └─ 複雑 → CRISPE + CoT
├─ 分類やパターン抽出
│ └─ Few-shot(2〜5例)
└─ ツール連携・エージェント
└─ ReAct迷ったら RGC から始めて、出力を見ながら必要なフレームワークを足していくのが最も実務的です。最初から完璧な組み合わせを狙う必要はありません。
フレームワーク通りに作るのは面倒ですか?
ジェネレーターを使えば、役割と目的を入力するだけで、フレームワーク適用済みの3バリエーションが自動生成されます。
よくある質問。
フレームワークはどれを選べば良いですか?
最もバランスが良く汎用性が高いのはRGC(役割-目的-文脈)です。日常業務の9割はRGCで十分に対応できます。複雑な推論が必要ならChain-of-Thought、事実ベースの作業ならFew-shot、ツール連携ならReActを選んでください。複数の組み合わせも有効です。
RGCとCRISPEの違いは何ですか?
RGCは3要素(役割、目的、文脈)のミニマル版、CRISPEは6要素(Capacity、Role、Insight、Statement、Personality、Experiment)の詳細版です。RGCは短文でも効果が出るため日常向き、CRISPEは長文になるため重要な出力(提案書、戦略文書)向きです。迷ったらRGCから始め、不足を感じたらCRISPEに拡張するのが実務的です。
Chain-of-Thought(CoT)はどんな時に使いますか?
多段階の論理推論、数値計算、コード解析、意思決定など、最終回答に到達する過程が重要なタスクに使います。「ステップバイステップで考えてください」と追記するだけでも効果がありますが、より効果的なのは各ステップを明示的にラベル付けする(<分析><仮説><検証><結論>)手法です。
Few-shotは何例が最適ですか?
2〜5例が一般的に最適です。1例では偶然的解釈のリスクが高く、6例以上はモデルが過学習気味に例を真似しすぎる傾向があります。例の多様性(典型、境界、例外を1つずつ)が数より重要です。例が古くなっていないか定期的に見直すことも重要です。
ReActフレームワークはどこで使えますか?
ReAct(Reasoning + Acting)はツール使用や外部データ取得を伴うエージェント的タスクで活躍します。ChatGPTのFunction Calling、ClaudeのTool Use、LangChainのエージェントで標準的に採用されています。単なるテキスト生成には不要なので、会話的な用途では使わないでください。
フレームワークは組み合わせられますか?
はい、組み合わせが最も効果的です。例えば『RGC + CoT + Few-shot』で、役割と目的を明示し、2〜3の入出力例を提示し、ステップバイステップで考えさせる、という構造は非常に強力です。本ページの後半では組み合わせ例も掲載しています。
モデルごとにフレームワークの効き方は違いますか?
違います。Claude は XML タグ(<役割>など)で区切るとより正確に解釈します。ChatGPT は Markdown 見出し(# 役割)を好みます。Gemini は構造化Markdownと自己評価ブロックで精度が上がります。同じRGCでも、モデルに合わせた表記を選ぶと効果が10〜20%向上します。
プロンプトが長すぎる場合はどうしますか?
長すぎるプロンプトは逆効果です。目安は「指示200〜600字、参照資料を含めても3000字以内」。それを超える場合、(1)参照資料を別タスクで要約する、(2)Few-shot例を削る、(3)マルチターン対話に分割する、のいずれかで短縮してください。Claudeの200K、Geminiの2Mコンテキストは長文読解用で、プロンプト自体は短く保つのが原則です。