RISENフレームワークとは
📍 In One Sentence
RISENは5段階反復ループで、「これを改善して」を構造化された再現可能なワークフロー with 監査証跡に変えます
💬 In Plain Terms
「改善して」と言うのではなく、修正させ（Refine）、変更をリストアップさせ（Inspect）、新バージョンを説明させ（Summarize）、自己評価させ（Evaluate）、次の改善を提案させます（Next Steps）。完了まで繰り返します。
RISENフレームワークは、複数改善サイクルを通じてドラフト、分析、計画を改善する反復パターンです。 各プロンプトを1回限りの作業ではなく、GPT-4o、Claude 4.6 Sonnet、Gemini 2.5 Proなどのモデルを構造化された再現可能ループで導きます。これにより、ワークフローは試行錯誤よりも継続的編集に見えます。
RISENは、既に第1版がある場合、すなわちドラフト記事、戦略ノート、コードスニペット、分析があり、制御可能で追跡可能な方法でモデルに改善させたい場合に特に有用です。各RISENステップは明確な目的を持っており、改善を焦点を絞ったものにします。
フレームワークは5つのステップから名前が付いています：Refine（ドラフト改善）、Inspect（変更を特定）、Summarize（変更内容を説明）、Evaluate（基準に対して評価）、Next steps（改善を推奨）。
RISENの5つのコンポーネント
強いRISENプロンプトは5つのフェーズを明示的に要求し、各フェーズは明確な出力を持ちます。 これらのフェーズを1つの長いプロンプトに組み合わせるか、コントロール希望に応じて連続プロンプトに分割できます。
- Refine : 既存ドラフトを目標に従って改善（明確さ、構造、精度、簡潔さ、オーディエンス適合など）。モデルが原文を書き直すか改善します。
- Inspect : 具体的な変更を特定 — 何が書き直され、どの詳細が追加され、どの問題が解決されたか。これが監査証跡を作成します。5～7個の具体的な編集と正当性を要求します。
- Summarize : 新バージョンが何を言うか、または達成するかの簡潔な説明 — コンテンツの繰り返しではなく、メタレベルの説明。
- Evaluate : 明確な基準に対して結果を批評（トーン、精度、完全性、オーディエンス適合、明確さ）。1～5スケールで、基準ごと1文の正当性。
- Next steps : 次の反復に向けた3つの焦点を絞った改善を推奨。常に次のステップが明確です。
RISENが有用な理由
RISENは「改善して」をブラックボックスではなく透明な再現可能なワークフローに変えたい場合に有用です。 モデルに生成するだけでなく、自分の仕事を分析・批評させます。
実用的なメリット：
- バージョン間で何が変わったかの明確な可視性 — Inspectステップが完全記録を強制
- 弱点、ギャップ、機会を露出させた構造化された自己批評
- 次の反復への組み込みロードマップ。次に何を試すかで行き詰まらない
- 再現可能なプロセス。テンプレート化、チーム共有、標準化可能
- コンプライアンスや知識管理のための監査証跡 — 各改善を正当化できる
悪いvs良いRISENプロンプト例
非構造化編集要求とRISEN要求の違いは、同じドラフトに両方を適用すると明らかになります。 製品説明改善の実例。
【悪いプロンプト】
"この製品説明を改善して。"
【良いRISENプロンプト】
"あなたは製品マーケティングエディタ。ドラフト説明を与えます。RISENプロセスを使用：Refine : 明確さと簡潔性のため書き直し、全事実詳細は保持。目標120～160語。Inspect : 実施した5～7個の具体的編集をリストアップ（例：「利点X明確化」「繰り返し文Y削除」）。Summarize : 2～3文で新バージョンが何を強調するか説明。Evaluate : 明確さ（1～5）、説得力（1～5）、B2Bオーディエンス適合（1～5）で1～5スケール評価、各1文正当化。Next steps : 今後のプロンプトで要求できる3つの焦点を絞った編集を提案。ドラフト：【ここに挿入】"
RISEN版は曖昧な要求をミニプロセスに変え、改善説明だけでなく完全監査証跡とプランを生成。
RISENを使うべき場合
既に資料があり、各変更がどう大切かをケアする反復改善タスクにRISENを使用します。 RISENは改善、初期ドラフト生成ではありません。
- ブログ記事、ドキュメント、ヘルプセンター記事を複数ラウンドで改善
- セールスデッキ、ピッチスクリプト、役員サマリーをポリッシング
- プロンプト自体の確認・改善、特に本番環境の複雑なもの
- 長い分析をイテレーティブに締め付けて、より明確で実行可能に
- 複数人が変更を見る必要があるチームコンテンツレビューワークフロー
- コードレビューとドキュメント改善
比較表：CoT vs Single-Pass vs RISEN
| 次元 | Chain-of-Thought（CoT） | Single-Pass | RISEN |
|---|---|---|---|
| 構造 | 線形単一パス（「段階ごとに考えて」） | 1回の生成試み | サイクル付き5段階反復ループ |
| コアアクション | モデルが推理を書き、その後回答 | モデルが出力を生成 | Refine → Inspect → Summarize → Evaluate → Next Steps → 繰り返し |
| 監査証跡/変更追跡 | いいえ — 推理表示、改訂なし | なし — 出力は最終版 | はい — Inspectステップが各変更を記録 |
| 最適用途 | 数学、論理、説明（単一正解） | 高速生成、簡単タスク | 反復改善、複雑ドキュメント、チームレビュー |
| トークン原価 vs ベースライン | ~1.5～2×（推理追加） | ベースライン（1×） | 変数（深さ依存で2～5×/サイクル） |
| 複数プロンプト必要？ | いいえ — 推理+回答1プロンプト | いいえ | 長プロンプト、または5連続プロンプト（選択） |
| 組み込みモデル比較 | いいえ | いいえ | はい（GPT、Claude、Gemini同時） |
RISENプロンプトを書く方法
- 1問題と期待出力を述べます。 「あなたは【役割】。タスク：【資料タイプ】をRISENで改善。」
- 2Refine目標を明確に定義。 「改善先：【基準：明確さ、精度、簡潔さ、トーン、適合】。目標【長さまたは形式】。」
- 3Inspect出力を指定。 「リストアップ5～7具体的編集。各について何を変え、なぜか述べる。」
- 4Evaluate基準を指定。 「【3～5名付き次元、例：明確さ、精度、説得力】を1～5スケール評価。各1文正当化。」
- 5アクション可能なNext Stepsを要求。 「次サイクルに向けた3つの焦点を絞った改善を推奨。」
重要なヒント
🔍 Inspectステップは秘密兵器
Inspectステップはフレームワーク間でRISENを独特にする理由です。ほとんどのフレームワークは出力を生成します。RISENはモデルに具体的な各変更を文書化し、永続的な監査証跡を作成するよう強制します。他のフレームワークにはこの組み込み責任がありません — これが規制産業、学術研究、トレーサビリティが重要なチーム協業にRISENが不可欠な理由です。
🔍 「これを改善して」が失敗する理由
「これを改善して」や「改善して」のような曖昧な改善要求は、モデルに制約をゼロ与えます。明示的な基準と構造がないと、モデルはさまようり、矛盾した結果を生成します。RISENが機能するのは、各ステップが制約付きの特定の名前付き出力を持つためです。具体性が品質を駆動します。
⚠️ RISENを使ってはいけない場合
初期ドラフト生成にRISENを使わないでください。RISENは改善する既存資料が必要です。ゼロから何か作成する必要がある場合は、最初にCO-STAR、CRAFT、またはSingle Stepを使用してください。その後、反復的改善のためRISENに切り替えます。存在しない資料でRISENを使用することはトークンを浪費し、無意味なInspect出力を生成します。
🔍 2つのフレームワーク戦略
最適なパターン：CO-STARまたはCRAFTを使用して初期ドラフトを生成します。その後、反復的改善と自己批評のためRISENに切り替えます。この分離は、モデルが2つの根本的に異なる認知タスク——「作成」と「改善」——を混在させるのを防ぎます。各フレームワークは特定のフェーズで優れています。
RISEN使用時の一般的な誤り
❌ 初期ドラフト生成にRISENを使う
Why it hurts: RISENは改善資料が必要。ドラフト提供なしで「Refine」要求は、ゼロから生成、Inspectが報告すべきなし
Fix: 初期ドラフトにCO-STAR、CRAFT、Single Step使う。改善資料がある場合のみRISEN
❌ Inspectステップをスキップ
Why it hurts: Refineから直接Evaluateに飛ぶ。Inspect無しでは監査証跡失う — 何が変わり、なぜか不可視
Fix: 常にInspectを含める。5～7具体的編集と簡潔な正当化を要求。これが監査証跡を作成
❌ 曖昧なEvaluate基準
Why it hurts: 「品質で評価」はモデルに評価対象なし。基準なしで自己評価は無意味
Fix: 3～5命名基準を数値スケールで指定。例：「明確さ（1～5）、精度（1～5）、適合（1～5）。」
❌ 1つのRISENサイクルのみ実行
Why it hurts: 1パスが本番品質に到達しない。RISENは反復用設計 — Next Steps出力が次Refineに
Fix: 2～4サイクル計画。評価が安定し、提案が軽微になったら停止
❌ RISEN出力をモデル間で比較しない
Why it hurts: モデルは異なるように改善。Claudeは簡潔；GPTは詳細；Geminiはユーザー体験。1モデルは視野限定
Fix: PromptQuorumで同じRISENをGPT-4o、Claude 4.6 Sonnet、Gemini 2.5 Proに並行実行。比較
PromptQuorumでのRISEN
PromptQuorumはマルチモデル AI ディスパッチツールで、RISENを組み込みプロンプト構造として提供。 RISENオプション選択時、アプリが各ステップの自動フィールドを提供し、再利用可能命令に合成。
PromptQuorum内でRISENは：
- 既存ドラフト挿入で「Refine–Inspect–Summarize–Evaluate–Next steps」パターンを適用。メタプロンプト自作不要。
- 同じRISEN命令を複数モデル — GPT-4o、Claude 4.6 Sonnet、Gemini 2.5 Pro — 並行送信、各改善方法を比較
- RISENテンプレート保存で繰返ワークフロー（「ブログ改善」「製品コピーレビュー」など）、チーム共有
- 各RISENサイクルの完全改版履歴。改善プロセスが透明で追跡可能
RISENを他のフレームワークと組み合わせる
RISENを他フレームワークと組み合わせ、RISENを改善フェーズに割り当て、生成フレームワークを早期に使用します。 実用パターン：
この分離は「作成」と「改善」を混在させないようにします — 2つの根本的に異なる認知タスク。
- 1CO-STAR、CRAFT、Single Step使い初期ドラフト作成
- 2RISENに切り替え反復改善、自己批評、計画
- 3最終出力が厳格スキーマに従う必要ならSPECS（オプション）
よくある質問
RISENは何を意味していますか？
RISENはRefine、Inspect、Summarize、Evaluate、Next Steps。既存ドラフトを構造化改訂サイクルで改善するための5段階フレームワーク。
RISENとCO-STARやCRAFTはどう異なりますか？
CO-STARとCRAFTは生成フレームワーク — 初期ドラフト作成。RISENは改善フレームワーク — 既存資料を追跡可能反復で改善。
RISENと他フレームワークはいつ使い分けますか？
既存ドラフトで制御改善ならRISEN。一般初期ドラフト生成ならCO-STAR、創造的コンテンツならCRAFT、役割指定ならRTF、推理理解ならTRACE。
RISENサイクルは何回必要ですか？
通常2～4サイクル。評価が安定（連続サイクル同スコア）し、提案が軽微になったら停止。
ローカルモデルでRISEN使えますか？
はい。指示を遵守するLLMなら — OllamaやLM Studioの地元モデルを含む。大きいモデル（13B+）が多段階対応良好。
Inspectステップが特別なのはなぜですか？
Inspectはモデルに各変更具体的に記録させ、監査証跡作成。バージョン間で何が変わり、なぜかが見えます。
RISENをマルチモデルテストと組み合わせられますか？
はい。PromptQuorumで同じRISENをGPT-4o、Claude 4.6 Sonnet、Gemini 2.5 Proに同時送信。改善方法を比較。
RISENはトークンコストを増やしますか？
はい。各サイクルは単一パスの2～5倍output生成（改善コンテンツ、変更ログ、評価、推奨）。戦略的に選択使用。
センシティブ資料処理時、規制考慮はありますか？
機密ドキュメント改善時、クラウドAPI利用に注意（OpenAI、Google、Anthropicは非EU処理）。規制敏感作業にはOllama、LM Studio利用、またはAnthropicのEU対応オプション検討。
RISENはチーム複数人レビューに役立ちますか？
はい。Refineを初期作者、Inspectを上級レビュア、Summarizeをリード、Evaluateを決定者で処理。分割が客観性向上と多視点捕捉を実現。
関連資料
参考文献
- Schulhoff et al., 2024. "The Prompt Report: A Systematic Survey of Prompting Techniques." arXiv:2406.06608. 58+プロンプティング技法を反復改善パターン含め分類。
- OpenAI Prompt Engineering Guide. https://platform.openai.com/docs/guides/prompt-engineering — 公式プロンプティング現在慣行、反復改善戦略含め。
- Anthropic Prompt Engineering Documentation. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering — Claude特有、複数段階プロンプトワークフロー指針。