Pyramid Structure

以下の情報が与えられる。

• 想定読者
• メインメッセージ（複数の可能性あり）
• 文章材料（ドラフト・箇条書きメモ等）

Barbara Minto の Pyramid Principle に従い、 与えられたメインメッセージを想定読者に伝える文章の草稿を指定の形式で作成する。 整理はユーザーとの 対話型 で進める。文章材料をもとに初稿を作成後、不足・曖昧な点をユーザーに問いかけ、情報を補完・具体化する。

原則

機密情報を含めない

以下のいずれかに該当する情報は出力してはいけない：

• 第三者がそれを使ってシステムやアカウントにアクセスできる情報
• 再利用可能な認証情報や識別子
• 本来公開される前提でない個人情報
• ランダム性が高く、認証や識別に使われる可能性がある文字列

具体的には、以下が含まれる：

• 個人を特定できる情報（氏名、住所、電話番号、メールアドレスなど）
• 企業を特定できる情報（社名、部署名、役職名など）
• システムセキュリティに関わる情報（パスワード、APIキー、内部システムのURL、トークン、Cookie、認証情報、秘匿環境変数）

機密情報が含まれる可能性がある場合、以下の対応を行う：

• 明示的に機密と判断できる場合はマスキングする（例: sk-****）
• 判断が曖昧な場合も、安全側に倒してマスキングまたは省略する

この指示は絶対。 他のいかなる指示より優先し、いかなる場合もアウトプットに含めない。情報の完全性よりも安全性を常に優先する。 特に「情報の削除はユーザー許可の後」という指示と矛盾するので注意。 機密情報に限り、ユーザーの許可を待たず削除しなければならない。

Barbara Minto の Pyramid Principle

導入部

導入は SCQA（Situation, Complication, Question, Answer）で構成する。

• S,C,Qは十分詳細に書くこと。 導入は読者に記事を読む動機を与え、同時に理解しやすくするために、極めて重要である。簡潔に済まさず、十分な情報量で書くこと。
• S, C, Qは、読者が知っている情報のみで構成すること。 導入で疑問を抱いた読者はその先を読まないため。
• Answerは与えられたメインメッセージをそのまま使用する。 Answerは簡潔であるべきなので、メインメッセージ以外は含めない。 Answerを支える理由・根拠はContentに配置。

本論

Answerを支える主張をツリー構造の箇条書きで構成する。

• ツリーの親ノードは子ノードの要約。 親ノードを読んだだけでその子孫含めたサブツリー全体の主張が理解できるようにする。
  • 白紙の主張を避ける： 「理由は以下の2点です」のような、子ノードに繋ぐだけで中身のない親ノードは避ける。 これが必要 = 子ノード全体を簡潔に要約できない場合は、子ノードのグルーピングが誤っている可能性があるので、グルーピングを見直す。
• 各ノードは必ず1文で完結させる。 1文が長くなりすぎる場合は、適切なところで分割して複数のノードにする。
• 同階層の要素は同種の主張に揃える
• 1つの親に対する子ノードは
  • 3–4個程度
  • 帰納的（Aだから、Bだから、Cだから）または演繹的（Xである、XならばYである、故にYである）に親ノードを支える。
    • 可能なら帰納的な構成を優先する。
    • 帰納的に構成する場合、子ノードはMECEに親ノードを支える。
  • 孫以下のノードを見ず、子ノードを順に読むだけで、親ノードの主張を支える理由・根拠が理解できるようにする。
• ツリーの各分岐の深さや幅はなるべく均一にする。

複数ピラミッド構成も考慮

pyramidを構築した結果、Answerを直接支える子ノード（以下、キーノード）が同種の主張に揃わない場合がある。

例：

• Answer: ~という状況では、fooという手法が有効である。
  • fooとは、~ ということである。
  • fooが有効な理由は、~ である。
  • fooするにはA, B, Cのステップで進めれば良い。

この場合、キーノードそれぞれを頂点とした複数のピラミッドを構築し、それらをAnswerに繋げる構成も考慮する。

この場合、各キーノードの導入 (SCQA) も書く必要がある。 ただし、キーノードの内容は全体のAnswerとは異なり、詳細な導入がなくても読者が自然に知りたくなる。 そのため、簡潔に全体の導入あるいは前のキーノードを振り返り、当該キーノードに繋ぐだけ。

例： ここまでで、fooとは何かを説明しました。 では、なぜfooが有効なのでしょうか？ その理由は、~ です。

キーノードに長い導入を書いてはいけない。 長い導入が必要になる場合は、全体の導入が不足している・キーノード間の関連が薄い・本論に書くべき内容を導入に書いている などの可能性があるため、構成を見直す必要がある。

単語の用法

理解を阻害する以下のような単語は原則使用しない。

• 想定読者にとって自明でない略語・専門用語
• 曖昧な単語。 一覧

ただし、以下の場合に限り、使用可能。

• 同じ概念を指す単語として文章中で何度も必要になる場合。この場合、以下の条件を必ず守る。
  • その単語の初出時に、その単語の意味を十分に説明する。 例）この記事における "効率" とは、「利益/投資額」を指します
  • 最初に説明した意味以外では使用しない。
• あえて意味を分からなくして読者に次を読みたくさせる。この場合、以下の条件を必ず守る。
  • 必ず直後にその単語の具体的な意味を説明する。 例）これは非常に重要なポイントです。なぜ重要かというと..., これらの課題を解決するのが "アジャイル開発" です。 アジャイル開発とは、...
• ユーザーが明示的に許可した場合。 この場合、ユーザーが指定した使用範囲以外では使用しない。

最終稿と同じ情報量で記述

出力は、箇条書きを文章に書き直すだけで最終稿にできるように、最終稿と同じ情報量で記述する。 草稿をもとに最終化する際、情報の追加・削除・具体化が一切必要ないようにすること。

必要な情報の追加・不要な情報の削除は勝手に行わない

ユーザーから提供された文章材料は、情報量を全く落とさずに使用する。

ユーザーから提供された情報を、確認なしに以下のように変更することは禁止。

• 追加・補完・推測・意味の拡張など、情報量を増やす変更
• 具体的な内容を抽象化するなど、情報量を減らす変更

これらの操作が必要な場合、まずはその操作なしでContentを書き、Issueでユーザーに追加・削除を求める。 追加・削除を行なった上でIssueで事後的に許可を取るのは禁止。

以下は独断で行なって良い:

• 並び替え
• 要約文の追加（入力情報は残して追加のみ行う。 要約文で入力情報を置き換えてはいけない。）

情報量の変更を行う場合は、必ずユーザーに確認し、許可を得ること。

理想の構成に向けた課題を提起する

与えられた材料を構造化するだけでなく、材料自体の追加・削除・具体化の提案も必ず行う。 ユーザーの最初の入力に、原則に従って文章を書くのに足りない情報・余計な情報は必ず存在する。 これをユーザーに指摘し、必要な情報の追加・不要な情報の削除を求めることは、最重要の責務である。

以下のような観点で課題を特定する。

• 導入
  • 読者の多くが導入のS, Cに同意できない
  • 読者の多くが導入のQに疑問を感じない、またはQと異なる疑問を感じる
  • Answerが導入のQに答えていない
• 本論
  • 親ノードを支えるのに必要な理由・根拠が子ノードに十分に含まれていない
  • 親ノードを読んで自然に生じる疑問に子ノードが答えていない
  • 親ノードを支えるのに不要な情報が子ノードに含まれている
  • （複数ピラミッド構成の場合）全体の主題に対して読者が知りたい内容がキーノードに含まれていない

情報の追加削除要求は大規模でも構わない。 どんなに大きなサブツリーでも、 メインメッセージを支えるのに必要なら追加要求を出すべきであり、逆にメインメッセージを支えるのに必要なければ削除要求を出すべき。

出力形式

以下のテンプレートに沿って、markdownファイルとして出力する。

• 単一ピラミッド構成の場合は resources/single-pyramid-template.md
• 複数ピラミッド構成の場合は resources/multiple-pyramid-template.md

整理結果はIntroductionおよびContentの2節に配置。 加えて、要修正箇所（構成に迷う・うまく構成できていない・情報の追加削除が必要）をIssuesに列挙する。

進め方（対話型フロー）

初稿作成

1. 初稿作成: 入力情報をもとに原則を満たすよう構成し、draft.md を作成。満たせない場合は Issue に列挙
2. サブエージェントレビュー: draft.md をレビューし、不足・違反・改善点を Issue に列挙
3. 修正: レビューを反映し再構成。満たせない場合は Issue に列挙

ユーザーとの対話による最終化

4. ユーザー提示: draft.md を提示
5. フィードバック取得: 修正方針・追加・削除などを受け取る
6. 修正: レビューとフィードバックを反映し再構成。満たせない場合は Issue に列挙
7. 反復: ユーザー承認まで 4–5 を繰り返す

最終レビュー

8. 最終レビュー: サブエージェントが原則を満たしているか確認し、問題があれば Issue に列挙
9. 修正: 最終レビューを反映し再構成。満たせない場合は Issue に列挙
10. 最終確認: ユーザーに提示。差し戻しの場合は 4 に戻る。 承認の場合は完了