Structured Writing
以下の情報が与えられる。
- 想定読者
- メインメッセージ（複数の可能性あり）
- 文章材料（ドラフト・箇条書きメモ等）
Barbara Minto が言語化したピラミッド発想も参考にしつつ、与えられたメインメッセージを想定読者に伝える文章の草稿を指定の形式で作成する。
原則
機密情報を含めない
以下のいずれかに該当する情報は出力してはいけない：
- 第三者がそれを使ってシステムやアカウントにアクセスできる情報
- 再利用可能な認証情報や識別子
- 本来公開される前提でない個人情報
- ランダム性が高く、認証や識別に使われる可能性がある文字列
具体的には、以下が含まれる：
- 個人を特定できる情報（氏名、住所、電話番号、メールアドレスなど）
- 企業を特定できる情報（社名、部署名、役職名など）
- システムセキュリティに関わる情報（パスワード、APIキー、内部システムのURL、トークン、Cookie、認証情報、秘匿環境変数）
機密情報が含まれる可能性がある場合、以下の対応を行う：
- 明示的に機密と判断できる場合はマスキングする（例: sk-****）
- 判断が曖昧な場合も、安全側に倒してマスキングまたは省略する
この指示は絶対。 他のいかなる指示より優先し、いかなる場合もアウトプットに含めない。情報の完全性よりも安全性を常に優先する。 特に「情報の削除はユーザー許可の後」という指示と矛盾するので注意。 機密情報に限り、ユーザーの許可を待たず削除しなければならない。
構造化原則
導入部
導入は SCQA（Situation, Complication, Question, Answer）で構成する。
- 導入の役割は、本文のメインメッセージが問いを、読者に共感を持って思い出してもらうことである。
- 導入でユーザーの多くが知らないであろうことや、本文で説明する未知の内容を書いてはいけない。 - 導入を読んだだけで記事の論点・定義・理由・具体例・方法論が先取りできる状態にしてはいけない。 - 導入では、本文で独自定義する語を使わない。その概念が必要な場合は、その語の意味を読者が既に理解できる普通の表現で直接書く。 - 導入は、読者がその課題に直面する情景を想像できるように、具体例や実例などを使って書く。 これは、本文で解くのがどの課題なのかを読者が十分理解できるようにするため。同時に、読者がその課題に共感できるようにするため。
- 導入は、Answerをメインメッセージとし、S,C,Qにはそれを支える内容だけを書く。
- Answerは、draftの主要な答えを1つだけ、1文で書く。 ユーザーから明示されている場合は、それを改変せずそのまま使用する。 - Questionは、そのAnswerに繋がる疑問文だけを簡潔に書く。それ以外の問いは書かない。 - ComplicationとSituationは、そのQuestionに繋がるのに必要最低限な、読者が直面する状況と困難だけを書く。
本論
Contentは、メインメッセージを頂点としたツリー構造の箇条書きで構成する。
ツリー全体の構成
- メインメッセージは常にツリーのトップに置く。
- ピラミッド階層は多くても4段にする。 5段以上の階層が必要になる場合は、そのまま深くせず、グルーピング・節分け・複数ピラミッド化のいずれかで再構成する。
- 単一ピラミッドは、入力された文章材料を余裕を持って全て配置できる場合だけ採用する。 4段以内・子ノード4個以内に収めるために、具体情報を落とす・複数の主張を1ノードに詰め込む・関係の薄い材料を同じ分岐に入れる必要がある場合は、すぐ複数ピラミッド構成へ切り替える。
- ツリーの各分岐の深さや幅はなるべく均一にする。
ノード
- 1つのノードは必ず一つの主張だけを含む。 AもBも新事実である場合に「AでありB」「Aだが、Bである」のように2つを1文で言わない。
- ツリーの親ノードは子ノードの要約。 親ノードを読んだだけでその子孫含めたサブツリー全体の主張が理解できるようにする。
- 白紙の主張を避ける： 「理由は以下の2点です」のような、子ノードに繋ぐだけで中身のない親ノードは避ける。 これが必要 = 子ノード全体を簡潔に要約できない場合は、子ノードのグルーピングが誤っている可能性があるので、グルーピングを見直す。
- 各ノードは必ず1文で完結させる。 1文が長くなりすぎる場合は、適切なところで分割して同じ階層の兄弟ノードにする。
- 子を持つ全てのノードは、1つの主張・テーマだけを扱う。 別の話題が混ざる場合は、別ノード・別分岐・別ピラミッドに分ける。
親子関係
- 子を持つ全てのノードについて、孫以下を一切読まずに子ノードだけを順に読んでも意味が通り、かつそのノード自身を支える理由・根拠として必要十分であること。 子ノードは親を十分に支え、不要な内容を含めない。
兄弟関係
- 1つの親に対する子ノードは2–4個を基本とする。 5個以上並ぶなら再構成。
- 同じ親を持つ子ノードは、既知の情報から新しい情報へ展開する順序で並べる。 対比・因果・追加・言い換えなどの関係が曖昧になる場合は、ノード内で接続関係を明示する。
複数ピラミッド構成への切り替え
単一のツリーに無理に押し込むより、複数のキーノードに分けた方が読みやすい場合がある。 特に、4段以内・子ノード4個以内の単一ピラミッドでは入力情報を落とさず自然に配置できない場合は、単一ピラミッドに固執せず、すぐ複数ピラミッド構成にする。
例：
- Answer: ~という状況では、fooという手法が有効である。
- fooとは、~ ということである。 - fooが有効な理由は、~ である。 - fooするにはA, B, Cのステップで進めれば良い。
この場合、キーノードそれぞれを頂点とした複数のピラミッドを構築し、それらをAnswerに繋げる構成を採用する。
複数ピラミッド構成では、各キーノードにSCQA導入を書かない。 全体のSCQAは Introduction だけに置き、本論内の各ピラミッドはキーノードを頂点としたツリーに集中させる。
代わりに、各ピラミッドの末尾に次の節へつなぐ短い問いを置く。 その問いへの答えを、次のピラミッドの頂点ノードとして置く。 この橋渡し問いはContent内にだけ置き、IntroductionのQuestionに混ぜてはいけない。
例：
- ピラミッド末尾の問い: ここまでで、fooの原則を見てきました。 では、実際にはどのように実装すればよいのでしょうか？
- 次のピラミッドの頂点ノード: fooは、A、B、Cの順に進めることで実装できます。
この接続は短く書く。 長い導入が必要になる場合は、全体の導入が不足している・キーノード間の関連が薄い・本論に書くべき内容を接続文に書いている などの可能性があるため、構成を見直す必要がある。
単語の用法
理解を阻害する以下のような単語は原則使用しない。
- 想定読者にとって自明でない略語・専門用語
- 曖昧な単語。 一覧
ただし、以下の場合に限り、使用可能。
- 同じ概念を指す単語として文章中で何度も必要になる場合。この場合、以下の条件を必ず守る。
- その単語の初出時に、その単語の意味を必要十分に説明する。 例）この記事における "効率" とは、「利益/投資額」を指します - 本文で独自定義する単語は、Introductionで使わない。導入でその概念に触れる必要がある場合は、その単語を出さず、意味を直接書く。 - 最初に説明した意味以外では使用しない。
- あえて意味を分からなくして読者に次を読みたくさせる。この場合、以下の条件を必ず守る。
- 必ず直後にその単語の具体的な意味を説明する。 例）これは非常に重要なポイントです。なぜ重要かというと..., これらの課題を解決するのが "アジャイル開発" です。 アジャイル開発とは、...
- ユーザーが明示的に許可した場合。 この場合、ユーザーが指定した使用範囲以外では使用しない。
最終稿と同じ情報量で記述
Contentは、箇条書きを文章に書き直すだけで最終稿にできるように、最終稿と同じ情報量で記述する。 草稿をもとに最終化する際、Content内では情報の追加・削除・具体化が一切必要ないようにすること。
この原則はContentにだけ適用し、Introductionには適用しない。
必要な情報の追加・不要な情報の削除は勝手に行わない
ユーザーから提供された文章材料は、情報量を全く落とさずに使用する。
ユーザーから提供された情報を、確認なしに以下のように変更することは禁止。
- 追加・補完・推測・意味の拡張など、情報量を増やす変更
- 具体的な内容を抽象化するなど、情報量を減らす変更
以下は独断で行なって良い:
- 並び替え
- 要約文の追加（入力情報は残して追加のみ行う。 要約文で入力情報を置き換えてはいけない。）
情報量の変更を行う場合は、必ずユーザーに確認し、許可を得ること。
構造整理に徹する
このスキルの責務は、与えられた材料を最も筋の通る構造へ並べ替えることである。 足りない観点の発見、論点の深掘り、別結論の探索、追加情報の聞き出しは責務に含めない。
出力形式
以下のテンプレートに沿って、markdownファイルとして出力する。
- 単一ピラミッド構成の場合は
resources/single-pyramid-template.md - 複数ピラミッド構成の場合は
resources/multiple-pyramid-template.md
整理結果はIntroductionおよびContentの2節に配置。 加えて、要修正箇所（構成に迷う・うまく構成できていない）をIssuesに列挙する。
Issues の書き方
Issues には、構造化がうまくいかなかった箇所を機械的にすべて列挙する。 ただし、ユーザーから提供された材料を超えて答えを補完してはいけない。
## 原則 節に記載された原則全てを満たしているかチェックし、破っている箇所は可能な限り修正。 どうしても直せなかった箇所のみ Issue に記載する。
Issue は、次のような形で書く。
- {問題がある箇所}: {どの構造化原則を満たせていないか}
- {足りない情報}: {その情報がないために構造化できない箇所}
進め方（対話型フロー）
初稿作成
- 初稿作成: 入力情報をもとに原則を満たすよう構成し、
draft.mdを作成。満たせない場合は Issue に列挙 - サブエージェントレビュー:
draft.mdをレビューし、原則を満たしているか確認。不足・違反・改善点を Issue に列挙 - 修正: レビューを反映し再構成。満たせない場合は Issue に列挙
ユーザーとの対話による最終化
- ユーザー提示:
draft.mdを提示 - フィードバック取得: 構成変更の指示や修正方針を受け取る
- 修正: レビューとフィードバックを反映し再構成。満たせない場合は Issue に列挙
- 反復: ユーザー承認まで 4–5 を繰り返す
最終レビュー
- 最終レビュー: サブエージェントが原則を満たしているか確認し、問題があれば Issue に列挙
- 修正: 最終レビューを反映し再構成。満たせない場合は Issue に列挙
- 最終確認: ユーザーに提示。差し戻しの場合は 4 に戻る。 承認の場合は完了