writing-ecosystem — 人間向け執筆の手順

人間読者向けコンテンツ（記事・エッセイ・ブログポスト・ニュースレター）を書く手順と、関わる skill・agent の 役割分担の正本。

書き始める前に ~/MyAI_Lab/writing/.claude/rules/writing-principles.md（執筆の背骨: 著者の方針と原理 6 本）を読む。 この repo で作業していれば rules として常駐しているが、別 repo からの --add-dir や他 skill からの参照では載っていない。 判断は背骨から導き、本 skill は手順・役割・受け入れの規律だけを持つ。

Scope

人間 primary のコンテンツのみ扱う。AI-facing ドキュメント（llms.txt / llms-full.txt / FAQ ページ等）には llms-txt-writer skill を使う。audience 判定と役割分担は llms-txt-writer skill の SKILL.md の「Audience Separation: Human vs AI」節を読む。

媒体名・語尾・frontmatter・文字数・reviewer 構成・公開 command は channel contract が持つ。記事全体を 扱う task では最初に <project>/.claude/rules/*.md の publication channel contract を読み、対象 path を 1 channel へ解決する。contract が無い、または複数 channel に一致する場合は推測せず停止する。

執筆時の規範は、背骨の rule・local contract・本 skill の手順だけである。ADR と memory は経緯と事例の記録で、 規範は背骨に一本化してある。過去セッションを素材にするときは session-theme-mining が選んだ一次 pointer、collect-context が作る evidence dossier の順に限定して受け取る。

Ecosystem Map

執筆関連コンポーネントの役割分担。どの phase で誰が何を持つか。

flow の外へ route する先は末尾の Related。

Canonical workflow

1. Route and discover

local contract から出力 channel と読者を決める。テーマ未選択なら session-theme-mining が 0〜3 件の同格候補を出し、著者の選択で止まる。選択済みの問いは §2 へ進む。テーマ候補は同格のまま 著者に渡し、選ぶのは著者である。

2. Collect, interview, then brief

方向は著者へのインタビューから見つけ、著者が選ぶ。構成・plan・節表は、方向が決まって brief を書くまで作らない （材料から先に骨組みを作ると、対話がその骨組みの確認になる）。

2a. 集める。 過去セッションや複数 repo の記録を素材にするときは collect-context で evidence dossier を作る （fact-checker に渡す台帳になる）。dossier は lookup material であり、本文へ全部入れる coverage checklist ではない。 記録の無い稿（考えが材料のエッセイ、外部の言説への意見、まだ実装していない仮説）は 2a を飛ばし、2b から入る。 「〜をやった話」なら記録がある、「〜と思っている話」なら無い。

2b. 聞く。 .claude/skills/article-interview/SKILL.md を読み、その手順で著者に聞く。dossier があればその path を 持って入る。台帳は dossier 末尾の ## インタビュー 節に書き、方向は著者が選ぶ。session-theme-mining で選ばれた問いと dossier の Claims は聞き手の準備で、方向の材料ではない。方向（何を問う記事にするか）は orchestrator が代わりに決めない — 候補を同格で並べ、著者が選ぶ。

2c. 差分を集める。 選んだ方向で要るのに dossier に無い出来事（著者が語った出来事を含む）を、collect-context で 足す。稿が外部言説に対する新規性を主張するときは、選んだ方向の同型の主張だけを skill: search-first で調べ、結果を brief の Out of scope か Entry bridge へ入れる。広い調査が要るときは Deep Research の prompt を書いて著者に渡す （著者が別ツールで実行し、結果を会話に貼る）。経験の報告では命題が外部言説との差分に依存しないので、この調査は要らない。

2d. brief。 台帳と dossier から次の editorial brief を docs/plans/<slug>.md に書く（reviewer の dispatch prompt に この path を渡す）。著者に確認を求めるのは Causal spine だけで、他の欄は台帳と dossier から埋める — 方向は 2b で著者が 選んでいる。進め方の plan が要るときは brief の後に書く。

Reader: <台帳③「読者について出た語」の原文 1 行。無ければ channel contract の読者と書き、「著者の発言なし」と添える>
Channel: <local contract の channel>
Author's words: <台帳①からの転記だけ。要約・言い換えをしない（reviewer が確度をこの欄と照らす）。記録（ログ）から採った発言は「記録から（session id）」と分けて書く>
Central thesis: <台帳⑥で著者が選んだ方向を、この原稿が成立させる命題一文にしたもの。必ず一つ。確度は Author's words のまま（背骨 1）>
Entry bridge: <読者の出発点から、なぜ中心命題を考える意味があるかが伝わる場面・観察・問いを1〜2文で。既定は台帳②の 1 件目>
Figure plan: <内容 GO の後に埋める。節 → 形（対比 / 流れ / 階層 / 2 軸 / 並列）→ 図の有無。並列は list のまま>
Causal spine: <観察 / 問題 → 緊張 → 機序 → 著者の判断（決めたこと・決めなかったこと）。観察は台帳②、緊張は台帳④、機序は台帳①の発言と orchestrator の展開から>
Selected evidence:
- <evidence id>: <因果線での役割。台帳②の出来事との対応>
Out of scope:
- <先頭に台帳⑥の捨てた方向、⑤の入らないと言われた記録。次に面白いがこの命題を進めない論点。記録や計測で確かめられる推論は、ここへ落とす前に著者へ聞く（背骨 4）。著者が通読で捨てた段落は聞き直さずに置く>

読者が何を知っているかを確かめるのは著者の通読である。Entry bridge は既存の疑問への接続と、新しい疑問が 生まれる入口の両方を含む。著者の体験も、その問いの意味を読者へ伝えるなら入口になる。

実用 how-to では central thesis を「読者が得る一つの成果または判断則」としてよい。

3. Outline and draft

導入は Entry bridge の場面・観察・問いで開く。執筆理由や背景は、読者を場面に置いた後に、その場面が 要る分だけ書く。読者が共有していない前提は本文で補う。各 load-bearing section に causal spine 上の役割を 一つだけ割り当て、採用 evidence を紐付ける。並列の agenda を節として足さない。語・節の切れ目・時間・ 証拠の置き方は背骨の 2・5・6 に従う。本文は orchestrator の文章で書く。brief の Author's words と台帳は素材で、 答えの順や言い回しをなぞって並べない（背骨 2・4）。読者を入れる場面、節の順、例、機序の説明は orchestrator が組み立て、 因果線の各段を自分の推論で展開する。執筆中に別の中心命題が現れたら混ぜずに停止し、editorial brief を 再確認する（背骨 4）。out-of-scope は本文から外す — details に押し込むと、読者には本文の一部として届く。

翻訳は prose-translation を使い、承認済み central thesis、causal spine、selected evidence、 out-of-scope を保持する。翻訳先の local contract へ route し直す。

3.5. Persona read（著者が頼んだときだけ）

既定の flow には入れない。著者が頼んだときだけ skill: persona-read-loop の article preset で回し、読み手の人選は その skill が持つ。記録は drafts/<slug>/persona/ に置く（経緯: ADR-0015 の 2026-11-14 注記）。

4. Review and content GO

初稿ができたら、観点別レビュー 5 本・fact-checker・初見の読みを、同じ版に対して 1 回ずつ並列に回す。 レビューに渡した版は drafts/<slug>/review.md に写して残し、処分記録の冒頭にその path を書く。稿はこの後も著者の通読で 動くので、写しは「どの版への report か」を残すためのもので、構造を止める宣言ではない。写しと処分記録の組は、reviewer を 変えるときに replay して確かめる材料になる。レビューの前に命題が動いたら、brief を書き直してから渡す（reviewer は brief を照合の 相手にする）。

観点別レビュー。 review-structure（構造）・review-certainty（確度）・review-explanation（説明と証拠）・review-prose（文章と語）・ review-conventions（規約）。各 agent は自分の観点だけを見て、総合評価を出さない（共通の約束は references/review-output-format.md）。観点を一つの agent にまとめると、観点どうしと全体の 判断が滲む（eval-foundations 原則 5）。記事全体の判断は著者の通読が持つ（原則 4）。dispatch prompt には稿の path、channel、 承認済み brief の path、dossier の path（末尾の ## インタビュー 節が確度照合の一次資料）、AI が本文を生成したかを書く。 同じ文面で 5 本に渡し、ほかの agent の結果は渡さない。全 channel で 5 本を回す（channel の違いは各 agent が contract の該当行から読む）。

事実。 fact-checker の dispatch prompt には証拠台帳と一次資料の path（repo、出力ファイル）を名指しで渡す — code / path / 出力の 照合はこの agent が持ち、観点別レビューは判断だけを持つ。

初見の読み。 Claude と別系統のモデルが担う — 同じ系統の reviewer は orchestrator と同じ所を読み飛ばす（原則 3）。 Codex plugin（openai/codex-plugin-cc）の codex:codex-rescue agent を background で起動し、references/first-contact-read.md の文面をそのまま渡す（文面を毎回組み立てない。原則 8）。central thesis・causal spine・成功基準は渡さない — 答えを持って読むと 「何をしたのか分からない」を検出できなくなる（経緯は ADR-0013）。中継役の agent が返ってこないときは、Codex 側の結果を node ~/.claude/plugins/cache/openai-codex/codex/*/scripts/codex-companion.mjs status → result <job-id> で取り出す。 Codex が使えないときは Claude で代替せず、処分記録に「別系統の読み: なし（理由）」と書き、著者への報告に 1 行で添える （同じ系統で埋めると、別系統の読みがあったように見える）。

採用した指摘は orchestrator が反映し（回数と戻り条件は下の処分規律）、out-of-scope が本文へ戻っていないことを 確認してから著者が本文を通読し、内容 GO を出す。内容が確定するのはこの GO であり、タイトル作業はその後に置く。 GO の時点で、通読の指摘数と、そのうちレビューが先に挙げていたのに orchestrator が処分で落とした件数を evals/read-through-log.md に 1 行足す（全 channel。下の処分規律の「処分の偏りを見張る」）。

図は内容 GO の後に起こす（brief の Figure plan をここで埋める。形の選び方と手順は channel ごとに決まる — Zenn は zenn-format の Figures、 note / Substack のエッセイは references/essay-figures.md の動く図。 図の規約を持たない channel では Figure plan は「なし」と書く）。 図の文字と本文の差分だけを fact-checker に回し、図を足した稿は著者がもう一度通読する。図と、 それに添える alt や直後の 1 文の追加は構造変更ではないので、この通読は確認であり、内容 GO とタイトル選択は やり直さない。

指摘の処分規律

このレビューと処分規律を改修するときは、先に skill: eval-foundations（判定と eval の共通の原則）を読む。

• CRITICAL の意味: 読者への約束・事実・中心命題を壊すもののみ。規約と運用実態の衝突は CRITICAL でなく「裁定要求」として報告し、裁定者は著者
• 裁定の書き戻し: 裁定結果は memory でなく channel contract に書く（fresh-context reviewer に 届く唯一の層）。著者が同種指摘を 2 回却下したら、その場で contract の該当行を更新または削除する
• 著者の通読指摘は種類への指摘: 1 箇所を指摘されたら、同じ型を全文から探して直す
• レビューの回数: 観点別レビュー・初見の読み（Codex）は 1 本の稿に各 1 回。レビュー修正を確かめるのは著者の通読で、reviewer ではない。修正を reviewer に読み 直させると、読むたびに新しい指摘が生まれて終わらず、限定句と段落分割が積もって本文が 防御的になる
• 処分記録: orchestrator は指摘ごとに採用・不採用と理由を 1 行ずつ残し、quality-gate へ レビューに渡した版への report と並べて渡す。受け入れの証跡は「その report + 処分記録 + 著者の 内容 GO」で、反映後の稿への reviewer verdict は要らない
• 著者の指摘を積む: 著者の発言が brief・構成・本文・タイトルのどれかを変えたら、反映と同じターンで drafts/<slug>.corrections.md（gitignore 下、非公開）に 1 件ずつ足す。1 件は著者の発言をそのままコピーした原文・対象・ 修正前後の抜粋（各 2 行まで）・Trigger（何が起きて指摘したか）・Expect（修正が外れていたと分かる観測）。1 つの発言が 複数箇所を変えたら原文は 1 回で対象を並べる。ここに積むのは著者の指摘で、reviewer と機械の指摘は上の処分記録が持つ
• 著者の撤回: 著者が反映を却下・撤回した件は、その件に撤回と書いて残す
• commit へ写す: その変更を含む記事の commit 本文に、積んだ件を 1 件 1 ブロック（指摘: 原文 / Trigger: / Expect:）で Context: / Decision: / Review-when: の後ろに写す。写す前に project の公開安全規約（writing repo は CLAUDE.md の Public-repository safety）を原文にも当て、個人のパス・秘密・第三者の非公開情報を [略] にし、何を伏せたかを同じ行に書く。 修正前後の抜粋は drafts/ にだけ置く。写し終えた件には drafts/ 側に commit の SHA を書き足す。雛形は references/author-corrections.md
• 通読で命題が動いたとき: 著者の通読で命題が動いたら、記事を書き直し（背骨 4: 継ぎ足さずに書き直すかを著者に聞く）、 brief は記録として後から合わせる。reviewer は走らせ直さない — 書き直した稿を確かめるのは著者の次の通読
• 報告の扱い: 観点別レビューの「記録だけするもの」（著者の発言が無い一人称の判断など）は、処分記録に残すだけで著者に回さない。 構造再設計の提案も、著者に別立てで聞かず、orchestrator が採るか捨てるかを決めて処分記録に書く。著者は通読で気になった所だけを言う
• 処分の偏りを見張る: 処分は書き手の orchestrator が持つ（受け入れを著者の通読が持つので、書き手の文脈での判断が許される。 eval-foundations「判定者の文脈」）。書き手は自分の稿への指摘を落とす側に偏るので、内容 GO の時点で、著者の通読の指摘のうち レビューが先に挙げていたのに orchestrator が不採用・部分採用にした件を数え、evals/read-through-log.md に書く。 この件数が 2 本続けて 1 以上なら、事実・帰属・カテゴリのすり替えの指摘を orchestrator が落とせないようにするか、 処分を別の agent に移すかを著者に聞く
• fact-checker の回数: 著者の通読の前に 1 回。以後は、本文に新しい引用・数値・外部ソースが 入ったときだけ、その差分を対象に回す。全文の再照合は構造が動くたびに同じ主張を払い直すことになる

• cross-model 指摘の採用: 初見の読みの findings と、カテゴリのすり替え・事実誤り・帰属の誤りを 採用候補にし、ヘッジや限定句の追加を求める指摘は採用しない。全採用は一文ずつ正しくして通読を重くする。 既定の裁定:

  finding の型	既定
  ヘッジ済み思弁への「根拠不足」	不採用（発見調は仮説明示つきの思弁を許す）
  カテゴリのすり替え（実行↔動機、順番づけ↔確率の近さ 等）	常に採用検討
  概念・歴史的接続の過大主張、帰属の誤り	常に採用検討
  文体規約違反（register 混在・意図外の常体）	採用（意図的ブレイクと照合の上で）
  構造再設計の提案	orchestrator が採否を決め、理由を処分記録に書く

5. Title

内容 GO 済みの本文に対して headline-craft で候補を広く作り、その初見読みと約束の監査を見て 著者がタイトルを選ぶ。headline-craft には本文のほかに、brief の中心命題と Author's words、台帳①（著者の語）、 下の Title Conventions を渡す。候補を落とす条件は Title Conventions の「著者が決めること」に従う。 タイトル選択後に本文の構造を変えたら、内容 GO とタイトル選択を やり直す。表現修正だけなら再実行しない。

6. Acceptance

quality-gate が local contract の証跡を集約して PASS を出した後、著者が公開 GO を判断する。 公開操作は contract が指す project-local publishing skill に渡す。

Citation & Sources Workflow（出典をエッセイに入れる）

fact-check で確定した一次資料を、本文の出典セクションに編入するのがエッセイ公開前の標準ステップ。

所有と分離

• embedding はこのワークフローが所有する。fact-checker は report-only（記事を編集しない / author-reviewer 分離）のままで、検証済みソースを「出典セクションに落とせる形」で返すだけ。本文への編入は著者 / orchestrator が行う。
• fact-checker の出力（verdict が ✅ / ⚠️ のソース URL 群）が canonical input。

手順

1. fact-check 通過後、verdict が ✅ ACCURATE / ⚠️ PARTIALLY のソースを集める（❌ / ❓ のソースは載せない）。
2. ブロックの構成規則（テーマ別グループ化・重複 URL 排除・一次資料優先）は fact-checker agent が持つ（report を出す側が実値を持つ）。ここでは再掲しない。
3. 本文末に出典セクションを作る。
4. 本文で著者自身の既発表（DOI / repo / 論文）に言及していれば、それも出典に含める。

媒体別ポリシー

引用ごとに要る検証の深さ（帰属・中身・評価）は references/publication-procedures.md を読む。

翻訳記事の出典

prose-translation で訳した記事は、原文の出典セクションを引き継ぐ。URL / DOI は保持し、description のみ英訳する。

Genre shapes

どの shape も central thesis と causal spine に従属する。複数論点を統合できるのは、同じ中心命題の因果線で 上下関係を持つ場合だけである。

エッセイの 4 段構成（Hero's Journey 型）

essay の既定構成（出典: Kaguura 2026、ADR-0007）:

1. Calm Story — Entry bridge の場面で開き、低認知負荷で読者を著者の声に慣れさせる
2. Plunge（緊張） — 読者が乗ったところで、大きな問題・不都合な真実・パラドックスを提示する
3. Solution — フレームワーク・中核ルールを提示して読者を引き上げる
4. Higher Ground — 開始時より高い位置で終える。未解決のまま残すこと自体が Higher Ground になりうる

Environment-dependent implementation handoff

local path・既存設定・認証・権限に依存する変更を読者へ渡す記事では、人間向け本文だけで問題・判断則・ 採用境界を完結させた後に、読者の coding agent へ渡す standalone prompt を置ける。prompt は read-only で 環境を調査して実装 plan を返し、人間の承認前に編集・install・commit・publish しない。

Voice

register と語尾の実値は channel contract が持つ。contract が無い task では推測しない。AI slop と voice drift の兆候を見つけたときと、日本語稿を公開前に推敲するときに references/style-diagnostics.md を読む。 推敲では、同じファイルの「日本語の構文の手当て」の照合を通った案だけを採る。推敲は表現修正なので 内容 GO とタイトル選択はやり直さず、推敲後の稿を著者が通読する。 AI が本文を書いた稿は、全 channel で references/publication-procedures.md の「AI 開示」の型で末尾に開示を書く。

Title Conventions

目的

一覧で題を見た読者が、何についての記事かが分かり、著者の問いに引っかかること。

守ること

• 誠実さ: 本文が回収しない約束をしない。数字は本文の実測値・件数だけを使う — 判定は「その数字は記事の中身の証拠か、器の飾りか」
• 検索語: 記事の対象であるツール名・固有名詞を題に残す
• channel 制約: 字数と記法は project の channel contract が正本で、ここには書かない

著者の題の形

第一の形は前提を問う。著者や読者が当然としている前提を疑う問いを、著者の言葉のまま題に置く。 問いは、読者も自分のこととして持てるものにする。 素材は editorial brief の Author's words と台帳①、本文が引用する著者の発言、本文の節見出し。

形を示す例（著者の既存の題。語を写すためのものではない）:

• Claude Codeに「お前自身がLLMだろ」と言った日
• 自律エージェントにオーケストレーション層は本当に必要か
• 業務の中にいる人は、それを「ドメイン」とは呼ばない

成り立つ条件は、その問いに本文が答えているか、答えられなかったことを本文が正直に書いていること。

著者が決めること

誠実さ以外の理由では候補を落とさない。採否は著者が決める。

この節は規範の正本。候補生成と、本文から切り離した初見読み・約束の監査は headline-craft が正本。

How to Extend (Project Overlay)

プラットフォーム固有の値（文字数上限、タグ仕様、組織固有の禁止表現など）は project の .claude/rules/<publishing-channels>.md に置く。contract は背骨と本 skill の手順を再掲しない。

Related（この flow の外へ route する先）

• prose-translation skill — 日英双方向の voice 保持翻訳。一文・一段落の翻訳はこちらだけで足りる
• social-post skill — 記事の告知と著者の断片を X / Bluesky / Substack Notes の Buffer 下書きにする（Voice は SNS register への意図的分岐）
• public-comment skill — 公開 thread への返信
• readme-writer skill — README / repo トップページ（Voice は ですます への意図的分岐）
• llms-txt-writer skill — AI 向けドキュメント（llms.txt / FAQ 等）
• headline-craft skill — 「開かせる一行」の候補生成。規範は本 skill の Title Conventions