プロンプト分解 — 平坦なスナップショットを層構造へ
プロンプトは全条件を1つのコンテキストに同居させる。アーキテクチャは各条件を、それを最もよく 永続化 できる層へ分配する。良いプロンプトが持つ7つの条件は、5層が保持するために設計された7つの関心事と同じものである。
このドキュメントについて
本ドキュメントは、三層モデル (03-architecture)、Doctrine 層 (07-doctrine-and-intent)、Memory 層 (08-memory-and-knowledge) を前提に、それらを束ねる問いを扱う。毎回手で書くのをやめたとき、プロンプトの各部分は実際どこに棲むのか？
良いプロンプトには論理構造がある — 役割、前提、目的、入力、処理、出力形式、例示。
良いシステムは同じ構造を持つが、各部分は「最もよく永続化・再利用できる層」へ外部化されている。
設計・Skills・MCP・設定は、プロンプトの代替ではない — それらは、プロンプトの条件が永続的に棲みつく「住所」である。対象読者: 同種のプロンプトを繰り返し書いていて、何を プロンプトから抜き出して
CLAUDE.md/ Skill / MCP / サブエージェントに移すべきか、そして どの層 に各部分が属するかを判断したいエンジニア。
このページの位置づけ
01-vision（WHY — なぜブレない参照先が必要か）
→ 02-reference-sources（WHAT — 何を参照先とするか）
→ 03-architecture（HOW — どう構成するか）
→ 04-ai-design-patterns（WHICH — どのパターンをいつ選ぶか）
→ 05-solving-ai-limitations（REALITY — 現実の制約にどう向き合うか）
→ 06-physical-ai（EXTENSION — 三層モデルを物理世界へ拡張する）
→ 07-doctrine-and-intent（DOCTRINE — AIは何を基準に判断し行動すべきか）
→ 08-memory-and-knowledge（MEMORY — エージェントは何を記憶し、どう接続するか）
→ 本ページ（DECOMPOSITION — プロンプトは層へどう分解されるか）
メタ情報
| この章で固定するもの | プロンプトの7つの論理条件から5層への対応、条件の住所を決める2つの軸（種類と揮発性）、毎回すべてをプロンプトに書き直すアンチパターン |
| 扱わないこと | プロンプトエンジニアリングの技法そのもの（言い回し、Few-shot 構成）、平坦なプロンプトが劣化する内部的理由（→ 姉妹サイト なぜ） |
| 依存 | 03-architecture（対象となる層）、07-doctrine-and-intent（Doctrine 層）、08-memory-and-knowledge（Memory 層） |
| 誤用ポイント | 「設計 vs プロンプト」を二者択一と捉えること。層はプロンプトの 代替 ではなく、各条件を 永続化 して書き直さずに済ませるための住所である |
ドキュメントシリーズにおける位置づけ
| ドキュメント | 中心的な問い |
|---|---|
| 03-architecture | コンポーネントを どこに 配置するか？ |
| 07-doctrine-and-intent | AIは 何を基準に 判断するか？ |
| 08-memory-and-knowledge | エージェントは 何を記憶し、どう接続するか？ |
| 09-prompt-decomposition | プロンプトの構造は 層へどう分解されるか？ |
既存のプロンプトフレームワーク — 分解はすでに常識である
プロンプトを構成要素へ分解する発想自体は新しくない。広く使われるフレームワークはどれも、良いプロンプトを「複数の関心事の束」として扱うことを促す。
| フレームワーク | 構成要素 | 向いているユースケース |
|---|---|---|
| RTF | Role / Task / Format | 日常的なタスクや素早いプロトタイピングに最適 |
| CO-STAR | Context / Objective / Style / Tone / Audience / Response | ビジネス向けの文書作成や、トーン・対象読者を意識した出力に有効 |
| CRISPE | Context / Role / Instructions / Steps / Parameters / Example | 複数ステップを要する複雑な業務や、エージェント的な振る舞いを求めるときに有用 |
| Anthropic（Claude） | Clear and Direct / Examples / Let Claude Think (CoT) / XML Tags | Claude を使う際の最も強力な組み合わせの一つ |
TIP
Anthropic（Claude）特有の推奨、特に XML Tags + Examples + Think は、Claude を使用する際の最も強力な組み合わせの一つである。Context Engineering の観点からも、単なるプロンプト記述を超えた 「情報の構造化」 として機能する — そしてこの「構造化」こそが、本ページが層構造へと押し進める起点になる。
これらのフレームワークは分け方こそ違えど、いずれも 役割・文脈・目的・処理・出力形式・例 といった同じ関心事を指している。本シリーズはこれらを統合し、出力が変動しうる独立な軸として7つに整理する。
| 7条件 | 対応するフレームワーク要素 |
|---|---|
| 役割 | RTF: Role / CRISPE: Role / Anthropic: 人格規定 |
| 前提 | CO-STAR: Context, Audience / CRISPE: Context, Insight |
| 目的 | CO-STAR: Objective / CRISPE: Statement / Anthropic: Clear and Direct |
| 入力 | （各フレームワークでは暗黙。Anthropic: XML Tags で入力を区切る） |
| 処理・制約 | RTF: Task / CRISPE: Instructions, Steps, Parameters / Anthropic: Think |
| 出力形式 | RTF: Format / CO-STAR: Style, Tone, Response |
| 例示・検証 | CRISPE: Example / Anthropic: Examples (multishot) |
IMPORTANT
これらのフレームワークはいずれも 単一プロンプト内の書き方 である。関心事を一度の入力にどう並べるかを整えるが、整えた関心事はセッションが終われば消え、次回また書き直すことになる。
本ページが立てる問いはその先にある — これらの関心事を 前提として、層構造として、永続・再利用できる形にどう構造化するか？ まず関心事に名前を与え（次節の7条件）、次にそれぞれを最もよく永続化できる層へ分配する。
プロンプトの7条件
良いプロンプトは単一の指示ではなく、複数の独立した論理条件の束である。1つの段落として書かれていても、そこには分離可能な7つの関心事が含まれている。上記のフレームワークが分け方を変えながら指していたのも、結局この束である。
NOTE
この7条件への分解と後述の5層対応は、本シリーズ独自の体系化である。プロンプトエンジニアリング文献にも役割・目標・制約・形式といった類似の分解は複数存在するが、この正確な7分類と層対応は「普遍的な標準」ではなく 本アーキテクチャにおける推奨分解 として読んでほしい。
| # | 条件 | 何を規定するか |
|---|---|---|
| 1 | 役割の設定 | AIのアイデンティティと視点 |
| 2 | 前提・背景条件 | 共有知識と状況の基盤 |
| 3 | 目的・目標条件 | 達成すべき明確な成果 |
| 4 | 入力条件 | 処理対象のデータ・状態 |
| 5 | 処理・制約条件 | 推論ステップとルール |
| 6 | 出力形式条件 | 生成される結果の構造とデータ型 |
| 7 | 例示・検証条件 | 期待される結果の例と検証方法 |
なぜこの7つなのか
7条件は恣意的な分類ではなく、出力が変動しうる独立な軸を尽くしたものである。各条件は、指定されないとモデルが暗黙に埋めてしまう問い1つに対応する — 埋められた軸は、そのまま非決定性（毎回ぶれる箇所）になる。
| 指定しないと… | モデルが暗黙に決めてしまうもの |
|---|---|
| 役割 | どの視点・語彙・判断基準で答えるか |
| 前提 | 何を共有知識とみなすか |
| 目的 | 何をもって「成功」とするか |
| 入力 | 何を処理対象とするか |
| 処理・制約 | どのルールを守り、何を禁止とするか |
| 出力形式 | 結果をどの構造で返すか |
| 例示・検証 | 正否をどう判定するか |
NOTE
なぜ モデルがこの軸を自分で決められず暗黙に埋めてしまうのか（原理）は本サイトの範囲外である。LLM がトークンの統計パターンに反応し、指定の弱い軸を事前分布から埋める仕組みは姉妹サイトが扱う（末尾「さらに深く」参照）。
核心テーゼ — プロンプトは平坦なスナップショット
単発のプロンプトでは、7つの条件すべてが 1つのコンテキストウィンドウに同居 している。1ターンには便利だが、すべての条件が揮発性を帯びる。セッションが終われば消え、次回また書き直すことになる。
システム設計はその逆をする。各条件を取り出し、それを最もよく永続化・再利用できる層へ外部化 する。プロンプトは消えるのではなく、痩せる。安定した部分が別の場所に棲むようになるからだ。
IMPORTANT
「設計 vs プロンプト」は誤った二者択一である。5層はプロンプトを書くことの代替ではなく、プロンプトの条件を 再利用のために収める住所 である。本サイトのすべての層は、あるプロンプト条件を毎ターン述べ直さずに済むようにするために存在している。
対応関係 — 7条件から5層へ
| プロンプト条件 | 本質 | 主な住所（層） | 具体物 |
|---|---|---|---|
| 役割の設定 | アイデンティティ・視点 | Agent / Identity | system prompt の人格規定、CLAUDE.md の冒頭、.claude/agents/*.md、Agent ID / DID |
| 前提・背景条件 | 共有知識の基盤 | Memory + Skills | CLAUDE.md（プロジェクト恒久）、SKILL.md（ドメイン）、memory files / KG（関係性・履歴） |
| 目的・目標条件 | 達成すべき成果 | Doctrine | ミッション・意図の記述、判断基準 |
| 入力条件 | 処理対象データ・状態 | MCP | MCP server tools、ファイル / API / DB の取得 |
| 処理・制約条件 | 推論ステップとルール | Doctrine（制約） + Skills（手順） | RFC 2119 ラダー（MUST / SHOULD）、SKILL.md の手順、ガードレール |
| 出力形式条件 | 結果の構造・型 | Skills | docx / pptx / xlsx の format skill、スキーマ、テンプレート |
| 例示・検証条件 | 期待結果と検証 | Skills（例） + Doctrine（基準） + Agent（検証） | SKILL.md の例、合格基準、サブエージェント品質ゲート |
対応は厳密な1対1ではない点に注意。処理・制約条件 は Doctrine（制約 = 何が起きてはならないか）と Skills（手順 = どう実行するか）に割れる。前提・背景条件 は Memory（関係性・履歴の文脈）と Skills（安定したドメイン知識）に割れる。1つのプロンプト条件が複数の層へ分散しうる — ここから第二の軸が導かれる。
第二の軸 — 揮発性が住所を決める
第一の軸は 種類（上の表）。第二の軸は その条件をどれだけ長く持続させたいか である。同じ条件でも、寿命によって着地点が変わる。
| 寿命 | 棲む場所 | 例 |
|---|---|---|
| セッション限り（揮発） | プロンプト本文そのまま | 「今回のこのファイル、今日の特定の依頼」 |
| プロジェクト恒久 | CLAUDE.md / Skills / Doctrine | コーディング規約、標準の出力形式、エージェントの役割 |
| 横断・関係性 | Memory（KG、memory files） | 「前回どう決めたか」、システムをまたぐエンティティの関係 |
「前提」に単一の住所がない理由はここにある。今回のセッションだけ真の前提はプロンプトに残る。プロジェクト全体で真の前提は CLAUDE.md へ。過去の作業への 関係性 が本質の前提は Memory へ。判断するのは「前提はどの層か」ではなく、「この前提はどれだけ持続するか」である。
7条件を1つずつ辿る
役割の設定 → Agent / Identity。 プロンプトごとに1回述べる役割（「あなたは慎重なレビュアーである」）は、システムレベルでは system prompt の人格、CLAUDE.md の冒頭、または .claude/agents/ のサブエージェント定義になる。AgentID 時代には検証可能な識別子（DID）になる。役割は「一文」をやめ、エージェントが既定で何者か になる。
前提・背景条件 → Memory + Skills。 プロジェクトで安定した共有事実は CLAUDE.md や Skill に、過去の作業への 関係性 が本質の事実は Memory に棲む（08 参照）。見分け方: 前提が「何が真か」なら Skills 寄り、「何が起きたか」なら Memory 寄り。
目的・目標条件 → Doctrine。 達成すべき成果と「十分良い」の基準は、まさに Doctrine 層が保持するもの（07 参照）。毎プロンプトで目的を繰り返しているなら、それはプロジェクトの意図が Doctrine に固定されていないサインである。
入力条件 → MCP。 プロンプト内の「これがデータです」は、システムレベルではデータと状態をオンデマンドで 取得する MCP ツールになる（03 参照）。入力をプロンプトに貼るのは平坦化された形であり、MCP 境界がその永続的な形である。
処理・制約条件 → Doctrine + Skills。 この条件は割れる。制約（何が決して起きてはならないか、境界）は Doctrine に棲み、RFC 2119 の強度ラダー（MUST / SHOULD / MAY）で読まれる。手順（段階的なレシピ）は Skill の SKILL.md に棲む。
出力形式条件 → Skills。 「この列でテーブルを返せ」「.docx を生成せよ」「このスキーマに合わせよ」は、まさに format skill が符号化するもの（docx / pptx / xlsx skill が典型例）。形式は「記述される」ことをやめ、再利用可能なテンプレートになる。
例示・検証条件 → Skills + Doctrine + Agent。 具体例は SKILL.md に棲む。合格基準 は Doctrine であり、RFC 2119 ラダーで表現される。検証する行為そのもの は Agent 層の責務 — 検証ステップやサブエージェント品質ゲートである。
アンチパターン — 毎回すべてを書き直す
本章が防ごうとする失敗様式は、7条件すべてを永遠にプロンプトに残すこと — 役割・規約・形式・例を毎リクエストに貼り直すことである。
WARNING
平坦なプロンプトのコストは入力の手間だけではない。プロンプトが肥大すると LLM の 構造的 挙動が劣化する。安定した指示が今回の依頼と注意を奪い合い、中盤の内容が失われ、先頭のルールが減衰する。処方箋は「より長いプロンプト」ではなく、各安定条件をその層へ移すこと であり、これにより今回のプロンプトは「本当に今回新しいもの」だけを運ぶ。
条件を外部化すべきサインは単純だ。2回以上タイプした こと。毎セッション述べ直す役割は CLAUDE.md へ。毎回記述する形式は Skill へ。繰り返す制約は Doctrine へ。過去の作業についての前提は Memory へ。
設計判断 — いつ条件を外部化するか
IMPORTANT
プロンプト条件の外部化は 設計判断であり、反射ではない。条件の寿命がセッションを超え、かつ繰り返しのコストが層で維持するコストを上回ったときに、その条件を層へ移す。
外部化すべきシグナル:
- ✅ 同じ役割・制約・形式を多数のプロンプトで述べ直している
- ✅ その条件が自分だけでなくチーム全員に同一に当てはまるべきである
- ✅ 述べ忘れると結果が静かに変わってしまう
- ✅ その前提が本質的に過去の決定への 関係性 である（→ Memory）
プロンプトに残すべきシグナル:
- ❌ 今回の1リクエストでのみ真である
- ❌ 毎回変わる（実際のタスク、今日の特定の入力）
- ❌ 層に固定すると、将来の異なる作業を過剰に縛ってしまう
関連ドキュメント
- 03-architecture — HOW: 各条件が収まる層
- 07-doctrine-and-intent — DOCTRINE: 目的と制約の住所
- 08-memory-and-knowledge — MEMORY: 関係性を持つ前提の住所
- skills/vs-mcp — 出力形式・手順（Skills） vs 入力（MCP）
- faq/agent-vs-subagent-vs-skill — 役割と検証の収め先
🔗 さらに深く: なぜ平坦なプロンプトは劣化するのか
本ページは分解の 構造 (What/How) — どの条件がどの層に行くか — を扱った。「なぜ LLM がこの分解を強いるのか」「なぜすべてを1つのプロンプトに残せないのか」を理解したい場合は、姉妹サイトがコンテキストウィンドウのロード階層の仕組みから説明している。
- understanding-llm / Part 1: LLM の構造的問題 — Context Rot、Priority Saturation、Instruction Decay: 長く平坦なプロンプトが忠実度を失う理由
- understanding-llm / Part 3: 常時ロードされるコンテキスト — 役割と安定した前提を「常時ロード階層」（
CLAUDE.md）として持つ - understanding-llm / Part 4–5: 条件付き・オンデマンドのコンテキスト — 関連するときだけロードされる Skills
- understanding-llm / Part 6: ツールコンテキスト — 入力を貼るのではなくツール / MCP 経由で取得する
- understanding-llm / Prompt Sensitivity: 指定欠落 — なぜモデルは指定の弱い軸を自分で決められず、事前分布から暗黙に埋めてしまうのか
次へ: Concepts 全体像