【Claude Code】ブログ記事はプランモードで書くと修正が激減してラクだった｜非エンジニアの実体験

Claude Codeでブログ記事を書くなら、いきなり書かせる「オートモード」より、先に設計図を固める「プランモード」がおすすめです。出てくる下書きの精度が上がって、WordPressのプレビューを見ながらの修正が激減。結果、目視チェックがラクになり、時間も気力も、手直しに使うトークンまで節約できました。非エンジニアの42歳が、7本の記事を書き直して掴んだ実感をまとめます。

こんにちは、ヨウカンです。

ボクはエンジニアではありません。元小学校教師の42歳で、AI（Claude Code）にブログ記事を手伝ってもらいながらサイトを運営しています。最近、その「書かせ方」をひとつ変えただけで、作業がずいぶんラクになりました。

変えたのは、いきなり本文を書かせるのをやめて、先に「プランモード」で設計図を何回か直してから書かせるようにしたこと。たったこれだけで、いちばん面倒だった「あとからの直し」が劇的に減りました。この記事は、その体験をそのままお裾分けするものです。

結論｜プランモード最大の効果は「”んっ？”が激減すること」

先に正直なことを言っておきます。プランモードを使っても、直したい箇所がゼロになるわけではありません。どんな書き方をしても、出来上がった記事を読めば「ここはこう言い換えたい」は必ず出てきます。

でも、設計図を固めてから書かせると、出てきた下書きを読んだときの「んっ？ ここ違うな」という違和感が、オートモードのときより劇的に減りました。これが、いちばん大きい変化です。

なぜそれがラクにつながるのか。少しだけ、AIの裏側の話をさせてください。記事を1本「書き直す」とき、AIはまずその記事の全文を読み込みます。このとき使われるのが「コンテキストウィンドウ」——AIが一度に広げておける作業机のような領域です。机に全文を広げて（読み込んで）、そのうえで本文をまるごと書き直す。読み込む分も、書き直す分も、両方がトークン（AIが使う資源）を消費します。だから書き直しが多いほど、資源も時間も食う。さらに人間の側では、その都度プレビューを見比べる「目視チェック」という地味で重い作業が増える。ここが本当の負担なんです。

大事なのはここ。オートモードは「書かせる瞬間」はとてもラクです。でも負担の本体は、そのあとの目視と手直しにある。プランモードにすると、そのあとの目視がスムーズに進む＝タイパ（時間対効果）に直結するし、ボクの場合は精神的な疲労もずいぶん和らぎました。書き直しの手間が減れば、時間も気力も、結果的に手直しに使うトークンも一緒に減る、というわけです。

ビフォー｜今まではこういう書き方だった

少し前まで、ボクの執筆フローはこうでした。

この④が、地味にしんどい。下書きの完成度がそこそこだと、プレビューと睨めっこしながら直す箇所がどんどん増えて、メモ帳の箇条書きも長くなる。直す箇所が多いほど、こちらのタイピング量も増えていきます。

さらにさかのぼると、ブログを再開した最初の頃は——確かGeminiで壁打ちして、その内容をボクが伝書鳩のようにClaude Codeへ運んで、対話形式（チャット）でやり取りしながら書き上げていたと思います（このあたりはボクの記憶ベースなので、ちょっとうろ覚えです）。対話形式で延々やり取りすると、会話が長くなる＝さっきの”作業机”（コンテキストウィンドウ）がどんどん書類で埋まっていくし、Proプランの利用制限（一定時間ごとの上限）にも早く届く気がしていました。

👉 Gemini壁打ちからClaude Codeに移ってきた経緯は、この2本に書いています

アフター｜いまはプランモードで設計を「何回か」直してから書く

いまの流れは、こう変わりました。

ポイントは③です。本文になってから直すのではなく、設計図のうちに直す。一度で正しく、はなかなか行きません。でも何回か往復して設計を固めてから書かせると、本文の修正箇所がぐっと減って、結局ラクなんです。

そして地味に効くのが、クラスター（関連記事のまとまり）を一気に書くとき。柱になる記事・主力記事・小さな子記事をまとめてプランで出してもらって、整合性を見ながら直すと、数字やエピソードのズレが起きにくい。しかも、ぜんぶ1つのセッションの中で収まります。バラバラに書くより、設計段階で全体を見られるのが大きいんです。

記事7本を書き直して気づいた、正直な話

実際、ボクは関連する7本の記事をまとめて書き直しました。設計は7本ぶんを一気に練って、一気にWordPressへ流し込んだ。流し込むのは、確かに楽です。でも——その後が大変なんです。

※ここでいう「流し込み」は、できあがった原稿をWordPressへまとめて送り込む作業のこと。これにはちょっとした仕組みが要ります。話が膨らむのでここでは割愛しますが、興味のある方は、Claude Codeに「WordPressに記事を流し込みたい」と相談してみてください。トークンの消費は少し重くなりますが、手作業のコピペ地獄からは解放されます。

プランの良さは、7本ぶんを1つの画面でその場で直せるところ。これは本当に効きました。もしプランモードで設計していなかったら、後からの手直しはもっと増えていたはずです——これは、やってみて初めて体感で分かりました。

とはいえ正直に言うと、流し込んだ後に一気に直そうとしたら、2〜3本直したあたりでもう疲れてしまった（笑）。しかも実際に記事を見ると「あ、画像が足りないな」「ここ内部リンクが少ないな」と、設計のときには気づかなかったことが次々と出てきます。これはもう、やってみないと分からない部分です。

そこで学んだのが、「設計は一気でいい。でも、直して仕上げて公開するのは少しずつ」ということ。目視チェックは、思っている以上に重労働です。欲張って一度に仕上げようとすると、人間の方が先に力尽きます。

もうひとつ、トークンまわりで大事なことに気づきました。この7本はセッションをまたいで書いたのですが、実はセッションを移動するたびに、AIは運営方針（CLAUDE.mdという指示書）や文体ルールなどのファイルを毎回読み直します。つまり、セッション移動はそれ自体でトークンが割高になる。だから複数の記事をまとめて触るなら、できるだけ1つのセッションに収めた方が、整合性も取れてトークンも得なんです。プランモードでクラスターをまとめて設計するのは、この点でも理にかなっていました。

そしてもうひとつ、ボクなりの考えを。プランモード（設計）は、Opusのような賢いモデルでじっくり走り切った方が、後の手直しが少ないと感じています。軽いモデルでも設計はできますが、その場は速くても、出てきた本文の手戻りが増える気がする。設計こそ、いちばん賢い頭で固めておく。ここをケチると、あとで自分が苦労する——というのがボクの体感です。

ちょっと用語解説（非エンジニアのボクなりに）

「設計は無制限、仕上げて出すのは少しずつ」

プラン（設計図）は、何回練り直してもかまいません。ここは遠慮しなくていい。でも、実際に書いて・直して・公開する作業は、本数を絞った方がいい。
イメージは料理です。献立を7食ぶん考えるのは自由。でも、実際に作って・出して・片付けるのを一気にやると、人間が疲れてしまう。設計の段階でいくら盛り上がっても、仕上げは身の丈に合わせるのがコツでした。

「Exploreエージェント」＝下調べ専門の分身

プランモードのとき、Claude Codeは“下調べ専門の小さな分身”を動かすことがあります。これはボクが作った自作スキルではありません。Claude Codeが「ここは下調べが要るな」と自分で判断して呼び出す、標準の仕組みです。本体のAIが資料を全部読み込むと会話が重くなる（さっきの”作業机”がすぐ書類で埋まる）ので、分身に「この資料の要点だけ調べて」と頼んで、結論だけ持ち帰ってもらうわけです。

図書館で全部の本を自分で読む代わりに、調べ物係に「要約だけお願い」と頼むイメージ。何人かに手分けさせることもできます。
ただし注意点もあって、この分身を動かす分のトークンは、ちゃんと消費します。だから「プランモードにすれば即トークン節約」ではありません。節約の本体は、あくまで“あとからの手直しが減ること”。ここを取り違えないのが大事です。

今日から使える、ボクなりのコツ7つ

まとめ｜「書かせる」前に「設計する」だけで、後がラクになる

プランモードに変えても、修正がゼロになる魔法はありません。でも、出てくる下書きの「んっ？」が激減して、そのあとの目視と手直しが目に見えてラクになりました。タイパも上がるし、気力の消耗も減る。地味だけど、続けるブログにとっては大きな差です。

非エンジニアのボクでもできた、いちばんシンプルな改善は——「いきなり書かせる」のをやめて、「先に設計図を何回か直す」だけ。もし毎回の手直しに疲れているなら、次の1本だけ、プランモードから始めてみてください。

このブログの「中の仕組み」や、Claude Codeに作らせた自作スキルの具体的な作り方は、別の記事やNoteでもう少し踏み込んで書いています。よかったら、あわせてどうぞ。

👉 Claude Codeでブログを始める全体像と、自作スキルの中身はこちら

そもそも「デスクトップ版とCLI版、どっちを使えばいいの？」が気になった人は、こちらもどうぞ。黒い画面を避けていたボクが、ある夜とうとうCLI版に手を出した実話です。