# Answer First Writing > 読み手が最初の2文だけで「何を判断し、何をすべきか」分かる文書を作るスキル。バーバラ・ミントのピラミッド原則・SCQA・MECEを、役割の異なる5工程（構造設計→導入→論理監査→読者テスト→停止条件付き修正）の内部ループとして実行する。報告書、依頼・提案メール、Slack相談、企画書など意思決定を求めるビジネス文書の作成・書き直し（rewriteモード）と、エージェント自身が調査・監査・作業結果を報告するときの出力整形（reportモード）の両方で使う。「結論先行にして」「結論から書き直して」「answer-firstで報告して」「ピラミッド原則で構造化して」「この下書きを判断しやすくして」などで発動。また、エージェントがまとまった作業・調査の報告を求められたとき（「実行した内容を説明して」「セッションの成果をまとめて」「作業報告して」「何をしたか教えて」等）も report モードで発動する。※文単位の読みやすさ・修飾関係・敬語は akubun-writing、技術書・記事の執筆規範は japanese-tech-writing、学術原稿の推敲は tmllab-ja-prose-polish が担当。本 skill は文書の論理構造（結論の位置・論点の階層・検証ループ）のみを担う。 - Skill: `yosukeiida/answer-first-writing` (Agent Skill) - Install (CLI): `npx skillmds@latest add yosukeiida/answer-first-writing` - Raw SKILL.md: https://api.skillmd.com/api/skills/yosukeiida/answer-first-writing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: YosukeIida (https://skillmd.com/u/yosukeiida) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yosukeiida/answer-first-writing --- # Answer-First Writing ## 概要 多くの文書は、書き手が考えた順（背景→分析→結論）のまま書かれるため、読み手は結論を自分で探すことになる。この skill は情報を「考えた順」から「読み手が判断できる順」に並べ直す。結論を最上段に、理由を中段に、証拠を下段に置き、読者テストに合格するまで検証する。 判断基準は一つ：**想定読者が最初の2文だけを読んで、何が結論で、自分が何をすべきか分かるか。** 結論先行は情報を削ることではない。背景を捨てるのではなく下へ送る。明確さは冷たさではなく、読者の時間に対する敬意である。 ## 2つのモード - **rewrite モード**：ユーザーの下書き（メール・Slack・提案書・報告書・企画書）を再構築して最終稿を出す。 - **report モード**：エージェント自身が調査・監査・実装などの結果を報告するとき、この型で報告を組み立てる。読者＝依頼主、取ってほしい行動＝「次に何を判断・指示するか」を既定値とする。 ## 入力パケット（工程0） 作業前に以下を把握する。rewrite モードで会話から読み取れないものは仮定を置き、**解釈次第で結論が変わる場合に限り1回だけ質問する**。細部の不明点で作業を止めない。 - 読者（誰が読むか・その状況） - 文書の目的 - **読者に取ってほしい行動**（最重要。「説明したい」は目的ではない。「B案を承認してほしい」まで具体化する） - 期限・制約 - 絶対に残す情報・使ってよい根拠 置いた仮定は最終出力に明記する。 ## 内部ワークフロー（工程1〜5） 以下は役割の異なる5つのレンズであり、同じ確認の反復ではない。「もっと深く考える」を繰り返すのではなく、工程ごとに見るものを変える。途中経過は表示せず、最終出力だけを出す。 ### 1. ピラミッド設計 - 読者の中心的な問いを1つ特定する。 - 答え・提案・依頼を**1文**にする。立場を取ること。「〜について共有します」は題名であって結論ではない。 - **成果物・結論が複数あるときは、先にその数を認識する。**すべてを覆う結論を1つ立てるか、並列の成果物として最上段に並べる。一方の結論を他方の本文中段に埋めない。 - 結論を支える論点を2〜4個に整理する。同じ分類軸・同じ抽象度でそろえ、MECEにする。5個必要に見えたら結論が広すぎる。 - 各論点の下に証拠（数字・実名の事例・引用・実測）を置く。 - **事実・推論・仮定を分離する。根拠がないものは創作せず「未検証」「要確認」と明記する。**文章を強くするために事実を弱くしない。 ### 2. SCQA導入（長文のみ） 提案書・企画書・記事など長文で、結論をいきなり置くと唐突になる場合のみ作る。短いメール・Slack・報告では省略し、結論から始める。 - Situation（読者が同意できる事実）→ Complication（判断が必要になった変化）→ Question（読者の問い）→ Answer の順に**最大4文**。 - 「現代は変化が激しい」のような何にでも使える一般論は禁止。 - Answer はピラミッド最上段の結論と完全に一致させる。 ### 3. 論理監査 - 支持論点の分類軸を言語化する。軸が混在していれば直す（「市場が成長」「9月開始」「費用50万」は軸が違う）。 - 重複（言い換えただけの論点）・欠落（結論を支えるのに足りない論点）・飛躍（証拠から結論へ跳んでいる箇所）を探す。 - **読者が出しうる最も強い反論を1つ作り**、それに答える根拠があるか確認する。なければ未検証として明記するか、主張を弱める。 - 問題を致命的／重要／軽微に分類する。遠慮して数を減らさない。 ### 4. 読者テスト 実際の読者（工程0で特定した人物・状況）として判定する。 **第1段階**：最初の2文だけを読んで答える — (1) 結論は何か (2) 自分は何をすべきか (3) いつまでか。1つでも不明なら不合格。 **第2段階**：全文を読み、5軸を各0〜2点で採点する（合計10点）。 | 軸 | 2点の基準 | |---|---| | 行動の明確さ | 次に取る行動と期限が一意に分かる | | 論点の網羅性 | 判断に必要な論点が2〜4個で揃っている | | 証拠の十分さ | 主要な主張に具体的根拠がある（未検証は明示済み） | | 読者との関連性 | 読者の関心・権限・知識に合っている | | 簡潔さ | 結論・理由・証拠以外の文がない | **即不合格条件**：最初の2文で結論・依頼が不明／主要な主張に証拠がない／次の行動が不明／重大な反論が未処理。 ### 5. 停止条件付き修正 - 8点未満、または致命的問題がある場合**だけ**修正する。指摘された箇所以外を書き換えない。 - 修正後に工程4で再評価する。**書き直しは最大2回まで。** - **合格したら止める。**それ以上磨かない。十分に明確な文書を早く出すことが、完成しない完璧より価値がある。 - 2回書き直しても合格しない場合は、最良版と残る問題点（多くは根拠不足）を明示して出し、不足情報の提供をユーザーに求める。 ## 出力形式 - 短文（メール・Slack・短い報告）：チャットに最終稿を直接出す。 - 長文（報告書・提案書・監査結果）：md ファイルに書いて渡す。 - 常に添える：置いた仮定、未検証・要確認事項。最終スコア（5軸の内訳）は rewrite モードでは添え、report モードのチャット報告では省略してよい（求められたら出す）。 - 内部工程（ピラミッド図・監査ログ・各回の採点）は求められない限り出力しない。最終稿がそのまま送信・公開できることが完成条件。 ### report モードの標準形 ``` 結論（1〜2文。判断・依頼を含む） → 取ってほしい行動・判断（期限があれば期限） → 理由 2〜4個（同一軸・MECE） → 証拠（実測値・file:line・出典） → 仮定・未検証事項 ``` ## 禁止事項 - **経緯・時系列を本文の骨格にすること（考えた順で書かない）。**「ここに至る流れ」「まず〜次に〜」で段落を並べるのは、この skill が排除すべき構造そのもの。作業の経緯は結論を支える証拠になる場合のみ下層に置き、それ以外は削るか付録へ送る。 - 根拠の創作。数字がなければ「必要なデータ」を指摘する。 - 事実・推論・仮定の混同。 - 合格後の追加修正、合格部分の書き換え。 - 結論を弱める空疎なヘッジ（「かもしれません」「一応」「念のため」の乱用）。丁寧さが必要なら挨拶や配慮の文で足す。配慮と遠回りは別物である。