PromptQuorumPromptQuorum
ホーム/プロンプトエンジニアリング/RTFフレームワーク：Role・Task・Formatのプロンプト構造（2026年）
Frameworks

RTFフレームワーク：Role・Task・Formatのプロンプト構造（2026年）

·6分で読める·Hans Kuepper 著 · PromptQuorumの創設者、マルチモデルAIディスパッチツール · PromptQuorum

RTFフレームワークは軽量な3要素プロンプト構造です。Role（モデルの役割）、Task（実行するタスク）、Format（出力形式）。GPT-4o、Claude Opus 4.7、Gemini 3.1 Pro、ローカルモデルで動作します。日常的なタスク（要約、コードレビュー、メール、レポート）に標準として使用し、より多くの構造が必要な場合のみCO-STARやSPECSにアップグレードしてください。

重要なポイント

  • RTF = Role（モデルの役割）、Task（何をするか）、Format（どう出力するか）。3つのシンプル要素。
  • ルーティンタスク（要約、コードレビュー、メール、レポート、会議メモ）に標準として使用します。
  • Format フィールドはRTFの力。明示的な構造は劇的に一貫性の高い出力を生成します。
  • RTFは日常的なLLMタスク80%に対応。CO-STAR（トーン/オーディエンス）、SPECS（constraints）、TRACE（推論）へはRTFが限界に達した場合のみ。
  • 良いRTFプロンプトは再利用可能なテンプレート。毎週ゼロから書き直す代わりに、年間52回再利用します。
  • GPT-4o、Claude Opus 4.7、Gemini 3.1 Pro、ローカルモデル（Ollama、LM Studio）で動作。
  • PromptQuorumで複数モデルを並べてRTFプロンプトをテストします。

RTFフレームワークとは

📍 In One Sentence

RTFは3つの部分のプロンプトスケルトン（Role、Task、Format）で、より大きなフレームワークのオーバーヘッドなしにルーティンタスクに適度な構造を提供します。

💬 In Plain Terms

AIに誰になるか（Role）、何をするか（Task）、答えをどう形式化するか（Format）を伝える。それだけ。3つのこと。日常タスク80%で機能。それ以上が必要になったらCO-STARやSPECSに移行します。

RTFフレームワークは3つの部分のプロンプトパターンで、モデルに誰なのか、何をするのか、答えがどう見えるべきかを正確に伝えます。 ぼんやりした質問を送る代わりに、Role、Task、Formatを明示的に指定します。これはGPT-4o、Claude Opus 4.7、Gemini 3.1 Pro、OllamaやLM Studioで実行するローカルモデルで動作します。

RTFは意図的に最小化されています。3つのフィールドだけなので、覚えやすく、埋めるのが速く、多くの日常タスクに柔軟。どのスペシャライズドフレームワークを使うか分からない時の「デフォルトプロンプトスケルトン」として機能します。

3つのRTFコンポーネント

強いRTFプロンプトは3つの要素を明確に定義し、モデルが自分の仕事について曖昧さを感じません。 ラベル付きの行として、または3つの部分すべてを含む1文として書けます。

典型的な定義：

  • Role：モデルが採用すべき視点または専門知識（例：「シニアデータアナリスト」）。
  • Task：望む具体的なアクション、1～2文で説明。
  • Format：出力の構造、長さ、スタイル（例：「3ポイント＋2文のサマリー」）。

🔍 Formatが実力

RoleとTaskは明白です。ほとんどの人はすでに何をしたいか言っています。Formatが真の価値を追加します。「3ポイント、各最大50語、Markdown」は「要約をください」より劇的に一貫性の高い出力を生成します。FormatフィールドはRTFの秘密兵器。

RTFが役立つ理由

RTFフレームワークは有用です。複雑なフレームワークのメリットをほぼすべて、オーバーヘッドなしで提供するからです。 3つの決定（誰、何、どう）をプロンプト送信前に強制します。

実用的なメリット：

  • ルーティン作業ではマルチセクションフレームワークより速いプロンプト作成。
  • フォーマットが常に明示的なので、モデル・実行間での一貫性向上。
  • チームメンバーは数分でRTFを学べて、どこでも再利用できます。

例：悪いRTFプロンプト vs 良いRTFプロンプト

RTF版はコンテンツについてどう考えるか、結果を他の人がすぐ使える形でパッケージ化する方法をモデルに正確に伝えます。

❌ 非構造化リクエスト

このミーティングを要約してください。

✅ RTFプロンプト

Role：プロジェクト進捗ミーティングを経営陣向けに要約するOperationsマネージャー。Task：記録を読み、ミーティングで議論された重要な決定、オープンなリスク、次のステップを識別。Format：Markdown、3セクション（決定、リスク、次のステップ）、各セクション3～5ポイント、総250語以下。

RTFをいつ使うか

RTFフレームワークを使うべきは、シンプルで再利用可能だが、明確さと構造を強制するパターンが必要な時です。 長い仕様や多ステップの推論トレースが不要な時の強い標準選択肢です。

典型的なユースケース：

  • メール・チャット向けの短いレポート、要約、概要。
  • 明確な構造での顧客・内部ステークホルダー向けレスポンス起案。
  • 指定された出力フォーマットでの小規模コードスニペット・リファクタリング生成。
  • 製品説明、FAQ項目、シンプルなチェックリストのような高速コンテンツ。

RTFが適切でない場合

シナリオRTF制限代わりに使用
顧客向けコンテンツでトーン・オーディエンスが重要明示的なAudience・ToneフィールドがないCO-STAR（Style、Audience、Toneを含む）またはCRAFT（Constraints、Role、Audience、Format、Tone）
厳密なデータ構造またはスキーマ強制が必要FormatフィールドはJSONをリクエストできるが制約構文がないSPECS（明示的なConstraintsフィールド）
マルチステップの推論または決定ロジックが必要ステップバイステップ推論フィールドがないTRACE（Trigger、Response、Action、Consequence、Evaluation）
条件ロジック付き複雑なワークフロープロンプトあたりRole/Task/Format単一APE（Action、Process、Examples）またはカスタムマルチターンワークフロー

比較表

RTFが他の主要フレームワークとどう比較するか：

次元別比較

次元RTFCO-STARSPECSTRACE
フィールド数3（Role、Task、Format）6（Context、Objective、Style、Audience、Response、Tone）5（Settings、Person、Examples、Pattern、Constraints）5（Trigger、Response、Action、Consequence、Evaluation）
セットアップ時間30秒2～3分3～5分2～3分
最良用途ルーティン・反復タスクトーン・オーディエンス制御厳密スキーマ・constraints明示的推論ステップ
出力一貫性良好優秀優秀良好
例が必要？いいえオプションはい（強力なパターン）いいえ

ペアワイズ比較（RTF vs その他）

比較リーダー理由
RTF vs CO-STARCO-STAR（オーディエンスが重要な場合）CO-STARは明示的なAudience・Toneフィールドを持ちます。RTFはトーンをRoleまたはFormatに押し込むと複雑化。声が重要でなければRTFが速い。
RTF vs SPECSSPECS（厳密な制約が必要）SPECSは専用Constraintsフィールド・例の期待。RTFはFormatで制約をリクエストできるが構造構文がない。SPECS勝利：JSON、CSV、構造化データ。
RTF vs TRACETRACE（推論が重要）TRACEは因果関係を明示的にモデル化（Trigger→Response→Action→Consequence）。RTFに推論ステップフィールドなし。複雑ロジックはTRACE、シンプル出力はRTF。
RTF vs Chain-of-Thought相補的RTFはロール・出力フォーマットを定義。CoTは推論を改善。組み合わせられます：RTFでプロンプト構造化、複雑な数学・ロジックに「ステップバイステップ」を追加。

RTFプロンプトの書き方

  1. 1
    Role：AIが演じる人を定義。 具体的なロール勝利。悪い：「役に立つ」。良い：「パフォーマンス回帰をレビューするシニアバックエンドエンジニア」。ロールが具体的なほど、出力が一貫性。
  2. 2
    Task：何をするか述べる。 具体的に。悪い：「これを要約」。良い：「議論された3つの重要な決定、オープンなリスク、次のステップを特定」。
  3. 3
    Format：構造、長さ、スタイル指定。 ここでRTFが価値を追加。悪い：（Formatなし）。良い：「3ポイント、各最大50語、Markdown、総200語以下」。
  4. 4
    TaskとFormatを分離。 ペースト状にするとどちらも十分な特異性を得られません。分離を保つ。
  5. 5
    Formatは明白に思えてもいつも含める。 明示的なFormatフィールドなしでモデルは散文段落がデフォルト。

5つの実世界RTF例

一般的なワークフロー用の5つのプロダクション対応RTFプロンプト：

例1：週次ステータスサマリー

Role : 経営陣向けに週次ステータスサマリーを書くOperationsマネージャー。

Task : 今週のプロジェクト進捗、重要な決定、特定されたリスク、来週の優先事項を要約。

Format : Markdown、4セクション（サマリー、決定、リスク、来週）、セクションあたり3～5ポイント、300語最大。

例2：コードレビューフィードバック

Role : メンテナビリティ、パフォーマンス、セキュリティをレビューするシニアバックエンドエンジニア。

Task : このコードブロックレビュー、問題を特定、改善を提案、全体品質を評価。

Format : Markdown、3セクション（見つかった問題、改善、品質評価1～5）、コード例用コードブロック。

例3：顧客メール下書き

Role : 顧客苦情への専門的で共感的な返答を書くカスタマーサクセスマネージャー。

Task : 懸念に対応、適切に謝罪、解決を説明、信頼を復元。

Format : メール形式（挨拶、2～3段落、締めくくり）、プロフェッショナルトーン、150～250語。

例4：ミーティングメモからアクション項目

Role : 生メモからアクション項目を抽出するプロジェクトコーディネーター。

Task : 決定、議論されたリスク、所有者と期限付き次のステップを特定。

Format : Markdown、3セクション（決定、リスク、アクション項目）、チェックボックスリスト形式、所有者と期限付き。

例5：非技術ユーザー向け製品ドキュメント

Role : 機能をシンプル言語で非技術ユーザーに説明するテクニカルライター。

Task : 機能の説明、ユーザーが使う理由、3シンプルステップで使い方を説明。

Format : 1文イントロ、3数字ステップと例、1文結論。ジャルゴン回避。

RTFと他のフレームワークを組み合わせる

RTFフレームワークは他と組み合わせるべき。RTFをライト標準として扱い、制約が増すとヘビーフレームワークに切り替える。 実用的パターン：

  • 大多数の新タスクはRTFから開始。すぐに明確な構造が必要。
  • 厳密なスキーマ、例、constraintsが必要ならSPECSに移行。
  • 最終答前に明示的推論ステップが必要ならTRACEまたはAPEを使用。
  • オーディエンス・トーンが中心ならCRAFTのようなクリエイティブフレームワークを使用。

よくあるRTFの間違い

❌ 曖昧なRole ——「役に立つアシスタント」

Why it hurts: 「役に立つ」はデフォルト。何も追加しません。曖昧なロール＝モデルが自分の視点を選ぶ、実行ごとに変わります。

Fix: 具体的に：「シニアバックエンドエンジニア」または「CFOを標的にするB2Bマーケティングマネージャー」。ロールが具体的なほど、出力が一貫性。

❌ TaskとFormatがペースト状

Why it hurts: 「このミーティングをポイントで要約」はTaskとFormatを混ぜます。混ぜると、どちらも十分な特異性を得られません。

Fix: 分離：Task = 「決定、リスク、次のステップを特定」。Format = 「Markdown、3セクション、3～5ポイント各、250語以下」。

❌ Format完全に省略

Why it hurts: 明示的なFormat指定なし＝モデルは散文段落がデフォルト。必ずしも何を必要としているか。「AIが壁のようなテキストをくれた」の#1原因。

Fix: Format指定は常に。「3ポイント」さえ、何もないより良い。

❌ トーン・オーディエンス制御が必要なタスクにRTF使用

Why it hurts: RTFに明示的AudienceまたはToneフィールドなし。顧客向けコンテンツ、声重要な場合、RTFはトーンをRoleまたはFormatに押し込む、複雑になります。

Fix: 声重要ならCRAFT（明示的なAudience・Toneフィールド）またはCO-STAR（Style・Audienceを分離）に切り替え。

❌ RTFプロンプトをテンプレートとして保存しない

Why it hurts: 毎週ゼロから「ミーティングサマリー」RTFプロンプト書き直し＝時間浪費・一貫性低下。

Fix: ワークするRTFプロンプトはPromptQuorumで名前付きテンプレートとして保存。入力データ交換して再利用。

PromptQuorumがRTFを実装する方法

PromptQuorumはマルチモデルAIディスパッチツールで、RTFフレームワークを組み込みプロンプト構造として含み、ユーザーがRole–Task–Format プロンプティングを一貫的に適用できます。 PromptQuorumでRTFオプションを選択すると、インタフェースはRole、Task、Formatのフィールドを公開し、単一の整形式指示に組み立てます。

PromptQuorumではRTFは可能にします：

  • Role、Task、Formatを一度埋めて、GPT-4o、Claude Opus 4.7、Gemini 3.1 Pro、OllamaやLM Studioで設定したローカルモデルのような25+モデルに同じ構造化プロンプトを送信。
  • RTFプロンプトをテンプレートで保存、反復ワークフロー用 —— 例：「週次ステータスサマリー」、「顧客返答下書き」、「バグレポート要約」。
  • RTFテンプレートをチーム全体で共有、非エキスパートも一貫性・構造化出力を作成するプロンプトを作れます。
  • 複数モデル並べて同じRTFプロンプトをテスト、ユースケースに最良のものを見つける。

よくある質問

RTFは何の略ですか？

RTFはRole、Task、Format — 3部構成のプロンプト構造で、Roleはモデルが何を演じるべきかを定義、Taskはモデルが何をするべきかを指定、Formatは希望する出力の構造を説明します。

RTFはCO-STARとどう異なりますか？

RTFは最小限で3つのフィールドに焦点：Role、Task、Format。CO-STARはより包括的で、Context、Style、Audience、Toneを追加。クイック・ストレートな課題はRTF；聴衆とトーンが重要ならCO-STAR。

RTFいつ使うべきですか？

Role明確に定義された構造化出力が必要なときRTF使用。例：会議要約、コード生成、特定形式のメール作成、ドキュメント作成。RTFはテンプレートベースワークフロー向き。

RTFを他のフレームワークと組み合わせられますか？

はい。初期出力生成にRTF使って、反復精化にRISEN適用。またはChain-of-Thoughtと組み合わせ推論追加。複雑ワークフロー向けフレームワーク混在。

Roleを何にするか不確かな場合？

タスク合致する最小Roleで開始：「技術ライター」、「プロダクトマネージャー」、「Pythonエキスパート」。具体的だが過度詳細なし。異なるRoleテストして、より良い結果見つける。

Role、Task、Formatの順序が重要ですか？

standard順序 Role → Task → Formatですが、モデルは順序関係なく意図理解。しかし標準順序保持で、プロンプト読みやすく、テンプレート化容易。一貫性が厳密順序より重要。

全LLMでRTF機能しますか？

はい。RTFフレームワーク独立。GPT-4o、Claude、Gemini、Llama 3.2のようなOSS、OllamaやLM Studio経由ローカルモデル動作。原則全指示従順LLMに汎用。

良いFormat仕様をどう書きますか？

具体的に："Format：いい出力"ではなく"Format：5箇条書き、各15語以下"。構造指定（箇条、段落、コードブロック、JSON）、長さ（語数、項目数）、トーン（フォーマル、カジュアル、技術的）。

これらのテクニックをPromptQuorumで25以上のAIモデルに同時に適用しましょう。

PromptQuorumを無料で試す →

← プロンプトエンジニアリングに戻る

RTF-Framework: Role, Task, Format Prompt-Struktur