source.mdを先に書いたらAI初稿の直しが減った話

"ChatGPTやClaudeに丸投げして直しが増えていた運用を、source.mdで読者・結論・構成を先に固める形へ変更した実測体験です。何が変わったか、向く人／向かない人、次に読む手順記事まで整理します。"

ChatGPTやClaudeに「ブログ記事を書いて」と頼むと、一見それっぽい文章は出ます。ただしToolArcの制作環境では、読者像や結論が曖昧なまま生成させると、公開前の直しが毎回積み上がっていました。

本記事は手順の網羅ではなく、source.mdを先に書く運用へ変えたあとの実測体験に絞ります。型そのものの手順は、記事末で本命のフロー記事へ接続します。

この記事でわかること

今日の結論

丸投げは「速さ」はあるが、直しの量で帳消しになりやすい

読者・結論・構成を先に固めると、レビューの主戦場が事実確認に寄る

体験談だけでは型は身につかない。手順は専用のフロー記事で再現する

初稿の直しが多い人ほど参考になる

次のどれかに当てはまるなら、この体験談は判断材料になります。

状況	読む価値
AI初稿の直しに毎回1時間以上かかっている	高い（同じ失敗の回避策として）
source.mdという設計メモの存在は知っているが効果が実感できない	中（実測の前後差が参考になる）
すでに設計→初稿→レビューの型が安定している	低い（手順記事だけで足りる）

失敗は、だいたい同じ型でした。

結果として、書く時間より直す時間の方が長くなりました。特別な仕掛けはなし。前提が渡っていないのに、前提を含む記事を期待していただけです。

対策は単純で、AIに書かせる前に読者・結論・構成を1枚のsource.mdに固めることです。特別なツールは不要で、メモ帳でもObsidianでも構いません。

最低限書く項目は次の8つです。想定読者／検索意図／キーワード／記事の結論／構成案／収益導線／内部リンク候補／免責。

この順番にした理由は、結論のない構成案が一番手戻りを生むからです。結論を先に決めてから見出しを切ると、AIへの依頼文も短く済みます。

環境は Windows＋Obsidian（source.md管理）＋Claude（初稿）＋Cursor（公開実装）

ToolArc（本サイト）の記事制作で運用しています。

「絶対に直しがゼロになる」わけではありません。設計が曖昧なら初稿も曖昧なまま返ってきます。ただし、直しの種類が変わるだけで、公開までの疲れ方ははっきり変わりました。

学びの順番から整理したい場合は、無料セミナーなどの学習導線を先に見る選択肢もあります。一方、テーマと読者像が決まっているなら、独学で型から入る方が早いです。

向く人: AI初稿の直しが多く、読者・結論を後付けで埋めている人。実測の前後差を知りたい人。

向かない人: すでに設計→初稿→レビューが安定している人。体験談よりチェックリストだけ欲しい人（その場合は手順記事へ）

Q1. source.mdは何分書けば十分ですか？

ToolArcでは15〜30分を目安にしています。それ以上かかる日は、テーマ自体が固まっていないサインです。

Q2. ChatGPTだけでも同じ効果がありますか？

あります。効いているのは「設計を先に固める」ことであって、特定ツールの魔法ではありません。

Q3. 既存の長い記事にも遡って適用すべきですか？

まず新規1本で試すのがおすすめです。全記事への遡及適用はコストが高いためです。

Q4. 体験談だけでフローは再現できますか？

不完全です。再現手順は専用のフロー記事にまとめています。

丸投げをやめてsource.mdを先に書くようにしたあと、直しは「構成の作り直し」から「事実と導線の確認」に変わりました。次の一歩は、source.mdの8項目を1枚埋めてから初稿を依頼することです。

手順の全体像（依頼文例・公開前チェックリスト含む）は、次の記事で再現できます。

少人数チームでChatGPT BusinessとClaude Teamのどちらから契約するか迷っている方は、比較の整理記事も参照してください。

Doraverseの無料トライアルに不安がある方は、制限・やめとけ不安の整理記事も参照してください。

本記事は執筆時点（2026-07-20）のToolArc制作環境での実測・体験に基づきます。AIツールの仕様・料金は変更され得るため、重要な判断は各公式情報で確認してください。