doc-coauthoringスキルでClaudeと文書を共同で書き上げる手順
Anthropic公式のdoc-coauthoringスキルは、文脈集め、構成の磨き込み、読者テストの3段階で文書を仕上げます。導入方法と各段階の進み方、Claude Codeでの読者テストの回し方をまとめました。
doc-coauthoringは、Anthropicが公開しているスキルのリポジトリ(anthropics/skills)に入っている、文書の共同執筆用スキルです。書き手に質問を重ねて文脈を引き出し、節ごとに案出しと取捨選択を繰り返して本文を作り、最後に「何も知らないClaude」に読ませて穴を探します。白紙のプロンプトに「設計書を書いて」と投げる方法との違いは、この三段の手順がスキルとして固定されている点です。
doc-coauthoringスキルは何をするものか
SKILL.mdの説明文には、ドキュメント、提案書、技術仕様、意思決定の文書など構造のある文章を書くときに使うとあります。想定される呼び出しの言い回しは「write a doc」「draft a proposal」「create a spec」「write up」などで、PRD、設計書、決定ドキュメント、RFCといった文書の種類を挙げただけでも提案が始まります。
流れは3段階です。
| 段階 | 目的 | Claudeの役割 |
|---|---|---|
| 1. Context Gathering(文脈集め) | 目的書き手の頭の中と、Claudeの知識の差を埋める | Claudeの役割質問し、情報の吐き出しを受ける |
| 2. Refinement & Structure(構成の磨き込み) | 目的節ごとに本文を作る | Claudeの役割案を出し、取捨選択を受けて下書きする |
| 3. Reader Testing(読者テスト) | 目的読み手が迷う箇所を見つける | Claudeの役割事前知識のないClaudeで文書を試す |
スキルは最初に、この3段階を説明したうえで「この流れで進めるか、自由に書くか」を尋ねます。断れば自由形式に切り替わり、受けると段階1に入ります。段階を飛ばしたいと伝えた場合も、飛ばすか自由に書くかを確認する作りです。
導入方法 — Claude CodeとClaude.aiで違う点
Claude Codeに入れる
anthropics/skillsはClaude Codeのプラグインマーケットプレイスとして登録できます。doc-coauthoringは、マーケットプレイス定義の中でexample-skillsというプラグインに含まれています。
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills/plugin install はセッション内ではすぐに入れず、/plugin のパネルを詳細画面で開きます。内容を確認し、導入の範囲(スコープ)を選んでから確定します。入ったら、スキルの名前を挙げて依頼するだけで使えます。リポジトリのREADMEもPDFスキルを例に、スキルは名前に触れれば使えるとしています。
example-skillsには、doc-coauthoringのほかにbrand-guidelines、skill-creator、webapp-testing、mcp-builderなど12本が束ねられています。1本だけ使いたい場合でも、プラグイン単位で入ります。不要なスキルまで一覧に並ぶのが気になるときは、/skills で表示を切り替える方法があります。詳しくはClaude Code /skillsコマンドの使い方にあります。
SKILL.mdだけを手元に置く運用もできます。個人用なら ~/.claude/skills/doc-coauthoring/SKILL.md、リポジトリで共有するなら .claude/skills/doc-coauthoring/SKILL.md に置きます。同名のスキルが複数の場所にあれば、個人用がプロジェクト用より優先されます。
Claude.aiで使う
READMEによれば、リポジトリ内のサンプルスキルは、Claude.aiの有料プランでは最初から使えます。自分で取り込む場合や組織で配る場合の手順は、ClaudeのSkillsを組織全員に配布する手順が詳しいです。
段階1 — 文脈集めで何を聞かれるか
最初に5つの質問が来ます。
- 文書の種類(技術仕様、決定ドキュメント、提案書など)
- 主な読み手
- 読んだ人にどんな行動や理解を起こしたいか
- 従うテンプレートや書式の有無
- そのほかの制約や前提
回答は箇条書きでも走り書きでも構いません。次に、背景、過去の議論、他の案を採らない理由、組織の事情、期限、技術的な依存関係、関係者の懸念を「整理せずに全部出してほしい」と促されます。Slack、Google Drive、MCPサーバーなどの連携が使える環境なら、チャンネルや共有文書から直接読み込めます。連携が無いClaude.aiでは、コネクタを有効にするか、内容を貼り付ける案内が出ます。
吐き出しが一段落すると、Claudeは抜けている点を5〜10個の番号付き質問にして返します。「1: はい、2: #設計チャンネル参照、3: 後方互換性のため不可」のように、番号に短く答えれば足ります。
この段階の終了条件が実務的です。基本の説明が要らなくなり、エッジケースやトレードオフを尋ねられる状態になれば、文脈は足りているとみなします。そうなったところで「まだ足したい情報はあるか、下書きに進むか」と確認されます。
既存の共有文書を直すとき
すでにある共有文書の編集では、連携機能で現在の内容を読み、alt textの無い画像がないかも見ます。無い場合は、Claudeがその文書を読むときに画像の中身を把握できないと説明され、生成するか尋ねられます。希望すれば、画像をチャットに貼って説明文を作ります。
段階2 — 節ごとに案を出して絞り込む
構成が決まっていなければ、文書の種類に合わせて3〜5個の節が提案されます。決まった構成は、プレースホルダーだけを置いた雛形として作られます。アーティファクトが使える環境ではアーティファクトに、使えなければ作業ディレクトリのMarkdownファイル(decision-doc.md のような名前)になります。Claude Codeでは後者です。
書く順番は、未確定の事柄が最も多い節からです。決定ドキュメントなら中心となる提案、仕様書なら技術的なアプローチで、要約は最後に回します。1つの節は、次の6手順で進みます。
- 含めるべき内容について5〜10個の質問に答える
- その節に入れうる項目を5〜20個、Claudeが番号付きで挙げる
- 残す、削る、統合する項目を番号で指定する
- 抜けている大事な点がないか確認する
- 選んだ項目をもとに、プレースホルダーを本文に置き換える
- 修正の指示を出し、部分的な書き換えで直していく
番号での指定は「1、4、7、9を残す」「3は削除(1と重複)」「11と12を統合」といった短い形で足ります。理由を一言添えると、次の節以降でClaudeが好みを学びます。「いいですね、ただ…」のような自由な返事でも、Claudeが残す点と削る点を読み取って進めます。
ひとつ癖のある指示があります。最初の節の下書きを出すとき、スキルは「文書を直接編集するのではなく、変更したい点を言葉で伝えてほしい」と頼むよう定めています。「Xの箇条書きは削除、Yに含まれているため」「3段落目をもっと簡潔に」のように伝えると、Claudeが書き手の文体を学べるからです。直接書き換えた場合は、文書を読み直すよう頼めば変更点を踏まえて次に進みます。
修正は全文の再出力ではなく、部分置換で行います。3回続けて大きな変更がなくなると、削っても情報が失われない箇所がないか聞かれます。全体の8割ほどが書き上がった時点で、文書全体を読み直し、節同士の流れ、重複や矛盾、中身のない定型的な文、一文ごとの必要性を点検します。
段階3 — 読者テストで穴を探す
最後の段階が、このスキルで最も特徴的な部分です。書き手と対話してきたClaudeは文書の背景をすべて知っているため、文書そのものが分かりやすいかは判断できません。そこで、会話の文脈を持たない新しいClaudeに文書だけを渡して試します。
サブエージェントが使える環境(Claude Codeなど)では、ユーザーの手を借りずに次の流れで自動実行されます。
- 読み手が実際に尋ねそうな質問を5〜10個予測する
- 文書の本文と質問だけを渡したサブエージェントに質問ごとに回答させ、正誤を集計する
- 曖昧さ、誤った前提、矛盾がないかを別のサブエージェントで調べる
- 見つかった問題を報告し、該当する節の磨き込みへ戻る
サブエージェントが無いClaude.aiでは、手作業になります。新しい会話を開いて文書を貼り、予測された質問を順に尋ねます。各質問には「回答」「曖昧だった点」「文書が既知としている知識」の3つを答えてもらい、さらに次の3つも聞きます。
- この文書で読み手が曖昧に感じる点はどこか
- 読み手が既に持っているはずの知識を、この文書は何と想定しているか
- 内部に矛盾はないか
新しいClaudeが質問に安定して正解し、新たな抜けも出さなくなれば完了です。仕上げに、書き手自身が通読して事実、リンク、技術的な詳細を確かめ、狙った効果が出ているかを判断するよう勧められます。文書の責任は書き手にある、という立場です。
Claude Codeで読者テストを手元でも回す
スキルの自動テストに加えて、手元で同じことを再現しておくと、修正のたびに何度でも回せます。Claude Codeには -p で動く非対話モードがあり、--bare を付けるとフックやスキル、CLAUDE.md、自動メモリの読み込みを省きます。書き手のセッションの前提が混ざらないので、「何も知らない読み手」に近づきます。ただし --bare はOAuthやキーチェーンの認証情報を読まないため、環境変数 ANTHROPIC_API_KEY(または apiKeyHelper)でAPIキーを渡す必要があります。サブスクリプションのログインだけでは認証できません。
claude --bare -p "decision-doc.md を読み、次の質問に答えて。
質問: この提案を採用すると、既存の連携先への影響はどうなるか。
回答のあとに、文書の中で曖昧だった点と、
文書が前提にしている知識を挙げて" \
--allowedTools "Read"質問は、スキルが予測した5〜10個をそのまま使えます。回答が書き手の意図とずれたら、そのずれが文書の穴です。手元の環境にはCLAUDE.mdや自動メモリが入っているので、通常の -p では「新しいClaude」になりません。--bare を外さないことが、このテストの要点です。
使いどころの見分け方
スキルの冒頭の条件は、実質的な文章を書き始めそうなときです。逆に、数行のメモや定型の返信に使うと、質問と案出しの手数が見合いません。
| 場面 | 向き不向き | 理由 |
|---|---|---|
| 設計書、提案書、RFC | 向き不向き向く | 理由読み手が複数で、前提知識の差が大きい |
| 意思決定の記録 | 向き不向き向く | 理由他の案を採らない理由を引き出す質問が効く |
| 社内ヘルプ記事 | 向き不向き条件次第 | 理由読者テストが効く。短いものは段階2を簡略化する |
| 議事録、日報 | 向き不向き向かない | 理由事実の記録が中心で、案出しの工程が不要 |
テンプレートがある文書でも使えます。段階1の質問で書式の有無を聞かれるので、テンプレートのパスや共有リンクを渡せば、節の構成がそれに沿います。要件定義書を毎回同じ型で作りたい場合は、スキルの共同執筆とは別に、型そのものをスキル化する方法があります。Claude CodeとCoworkで要件定義書をSkill化する手順で扱っています。
自分の文書に合わせて調整する
READMEは、リポジトリのスキル群の多くがオープンソース(Apache 2.0)で、docx、pdf、pptx、xlsxの4つだけが参照用のソース公開(source-available)だと区別しています。doc-coauthoringはこの4つに含まれません。SKILL.mdの冒頭にライセンスの記載はないため、複製して配る前に、リポジトリ側の表示を確認してください。
調整するなら、SKILL.mdの次の箇所が候補です。
- 段階1の初期質問の5項目を、自社の文書種別に合わせて差し替える
- 段階2の案出し「5〜20個」の幅を、自分の読みやすい数に変える
- 段階3の質問数を、文書の長さに合わせて増減する
書き換えた版は、プロジェクトの .claude/skills/ に置いてチームに配ります。ブランドの書式をあわせて適用したいときは、ClaudeのブランドガイドラインをSkill化して資料に自動適用するの方法で、書式の側を別のスキルに切り出せます。
よくあるつまずき
- 質問が多すぎると感じる: 段階1と段階2の質問は、短い番号付きの回答で足ります。それでも重いときは「段階2は省略して自由に書く」と伝えると、自由形式に切り替わります。
- Claude.aiで読者テストが勝手に走らない: サブエージェントを使えない環境では、新しい会話に文書を貼って手作業で行う設計です。
- 直接編集したら学習されない: 直接直した場合は、文書を読み直すよう依頼します。変更点を踏まえて次の節に進みます。
- ブレインストームがアーティファクトに載る: 案出しの番号付きリストは、アーティファクトにしない決まりです。会話で出すものとされています。
まとめ
doc-coauthoringの価値は、文章の生成そのものより、質問と読者テストという工程を手順として固定した点にあります。書き手の頭の中を先に吐き出させるので、下書きが一般論に流れにくくなります。そして最後に「何も知らないClaude」で試すので、書き手が気づかない前提の抜けを事前に拾えます。導入はプラグイン1本、--bare での読者テストも、APIキーを用意すればコマンド1つで再現できます。
白紙から書き始めるか、スキルを呼び出すかは、読み手の数と前提知識の差で見分けられます。読み手が多く、前提が揃っていない文書ほど、段階3の効果が大きくなります。