本文執筆・リライトはどこまで任せられるか【Claude Code実践】

Claude Codeで本文執筆・リライトを効率化する方法を解説した記事のアイキャッチ画像

Claude Codeをライター業務に使い始めて、一番「任せすぎた」のが本文執筆の工程でした。
このノートでは、下書き生成とリライトという2つの作業がどういう構造になっているのか、
どこまで任せられてどこで止まるのかを、実体験をもとに整理します。

今回はシリーズの#03として、「本文執筆・リライト」の工程に絞って検証します。

前回の#02では「構成作成」の工程を整理しました。
今回はその続きとして、構成が確定した後に何が起きているのかを見ていきます。

本文執筆工程は「生成(下書きを作る)」「整理 / 変換(リライトする)」に分かれます。
この2つを分けて考えることで、どこまでClaudeに任せられるかが明確になります。


目次

本文執筆という工程の正体

この作業は何をしているのか

本文執筆は、「骨格を文章に変換する作業」です。

構成(H1 / H2 / H3の骨格)があれば、各H2に肉付けしていく工程になります。
骨格がある状態での文章展開は、ルールを与えれば繰り返し可能な処理になります。
この点が、構造として理解するうえで重要です。

やっていることを分解すると、次の3つになります。

・骨格(H2 / H3)に対応するテキストを生成する
・読者が理解できる順序で展開する
・トンマナ(文体 / 語調 / 方針)を一貫させる

新しいことを考え出す作業ではなく、骨格に対してテキストを当てはめていく工程です。

リライトという作業の位置づけ

リライトは「既存情報の最適化」です。

ゼロから文章を作る「生成」ではなく、すでにある文章を目的に合わせて組み換える「整理 / 変換」に分類されます。

・既存テキストがある
・変換の方向性がある
・品質の基準がある

この3つが揃えば、Claude Codeが処理できる工程になります。


下書き生成の実態

Before(ChatGPT時代)

・トンマナ / 記事方針を毎回説明し直す必要があった
・記事全体を一度に生成しようとすると、後半で軸がブレていた
・リライトはテキストをコピーして都度依頼する手間があった
・前回の記事との関係性は毎回ゼロから伝え直しだった

After(Claude Code)

1. 構成 / トンマナ / 記事方針をセットで渡す(毎回ではなく初回設定)
2. H2単位で本文の下書きを出力させる
3. 出力を「素材」として受け取り、自分の言葉に変換する
4. 実体験 / 具体例を加えて完成させる

変わったのは速さではなく、「コンテキストを毎回渡し直さなくて良くなった」という継続性の変化です。記事の方針やトンマナを蓄積した状態で書き始められるため、最初の指示の精度が上がりました。

構成作成の工程と渡し方の考え方は前回の記事で詳しく書いています。
本文執筆に進む前に構成の精度を上げておくことが、この工程の質に直結します。


執筆工程の構造

執筆工程は、大きく2つに分かれます。

・生成(下書きを作る)
・整理 / 変換(リライトする)

この2つを分けて考えることで、どこまでClaudeに任せられるかが明確になります。
この構造に分解できると、執筆工程も再現可能な処理として扱えるようになります。

#02で整理した「構成作成」は「整理」の工程でした。今回の「本文執筆・リライト」は「生成+整理」の両方が入ります。

この構造に分解できると、執筆工程も再現可能な処理として扱えるようになります。


\ 自分でやる時間がない方へ。まるっとブログ記事運用代行します/
お気軽にご相談ください。


Claude Codeがやっていること / 人間がやっていること

Claude Codeに任せられる部分

・構成に沿った文章展開(生成)
・言い換え候補の生成(整理 / 変換)
・トンマナのパターン維持(指示を与えた場合)

これらはすべて「ルールに従って展開 / 変換する処理」であるため、再現性高く任せることができます。

人間が必ず触る部分

これはClaudeに任せられません
・実体験 / 具体例の挿入
・「自分の言葉」への変換
・事実確認 / 数値の精度チェック
・「この記事で何を伝えたいか」の判断

Claudeは「それらしい文章」は作れますが、「私がこの工程で実際に経験したこと」は書けません。
本文の説得力を支えている実体験の部分は、今も人間が足す必要があります。

Claude Codeが得意な業務・向いていない業務については、シリーズ#01の記事
で整理しています。生成と整理の分類はそこでも共通する考え方です。


品質の限界と、止まるポイント

Claude Codeの出力が使えなくなるとき

実際に使い続けてわかった、出力が「使えない」になるパターンがあります。

このときの出力はほぼ使えない
・指示が抽象的なとき(「自然な文体で書いて」「読みやすく」など)
・実体験を書かせようとしたとき
・記事の方向性が途中でズレているのに気づかずに進めたとき

特に「自然な文体」という指示は、何も決まっていないのと同じです。
何をもって自然とするかが人によって違うため、毎回結果がブレます。

「使えない」を減らす渡し方

使えない出力を減らすための渡し方には、パターンがあります。

・構成 / トンマナ / 記事方針の3点セットで渡す
・H2を1つずつ分割して指示する(1回で全部出させない)
・出力を受け取ったら方向性の確認を先にする

H2を一括で渡すと、後半になるにつれて軸がブレることがあります。
1つ出力させるたびに「これで合っているか」を確認しながら進めるほうが、修正コストが下がります。


この構造は他業務でも共通する

今回の執筆工程を言語化すると、次の構造になります。

・骨格がある状態でテキストを展開する(生成)
・既存テキストを目的に合わせて変換する(整理)
・判断が必要な部分だけ人間が触る

これはライティングに限りません。

同じ構造を持つ業務の例
・法律事務所の文書作成(雛形を案件に合わせて変換する)
・企画書のブラッシュアップ(素材を目的に合わせて最適化する)
・マニュアル更新(既存テキストを最新情報に合わせて修正する)

「骨格がある」「変換のルールがある」この2つが揃えば、Claudeが動ける工程になります。

この切り分けができるようになると、「自分の業務のどこが効率化できるか」を判断できるようになります。
すべてを任せるのではなく、任せる部分任せない部分を意識的に設計することが重要です。

次の#04では、入稿・整形・公開の工程を整理します。
「書いた後」の工程にどれだけ手間がかかっているかが、実は本文執筆より大きな発見でした。
工程自体は地味ですが、ここの設計次第で作業全体の重さが変わります。


\ 自分でやる時間がない方へ。まるっとブログ記事運用代行します/
お気軽にご相談ください。


よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

AIコンテンツ運用やオウンドメディア実務をテーマに、実際に動かしながら気づいたことをそのまま言葉に残している編集長です。

デザイン制作12年・サービス開発の運営担当3年のキャリアをベースに、「非エンジニア」ながらClaude Codeを活用したワークフロー設計に取り組んでいます。ワクワクし続けられるよう、AIコンテンツで仕事を回せるのかを実務の中で探っています。

目次