Claude Codeをライター業務に導入して、一番「見落としていた」のが入稿・整形・公開の工程でした。
このノートでは、この工程がどういう構造になっているのか、
どこまで効率化できてどこで止まるのかを、実体験をもとに整理します。
今回はシリーズの#04として、「書いた後の工程」を扱います。
前回の#03では「本文執筆・リライト」の工程を整理しました。
今回はその続きとして、「入稿・整形・公開」の工程に絞って検証します。
入稿・整形・公開はブラウザ操作を伴うため、そのままではClaude Codeに任せることはできません。ただし、操作の前後は構造化できます。「操作の前後を設計する」という考え方が、今回のポイントです。
入稿・整形・公開という工程の正体
この工程で何が起きているのか
入稿・整形・公開は、「文章を公開可能な状態に変換する作業」です。
やっていることを分解すると、次の3つになります。
・完成した文章をCMSに入力する（入稿）
・見た目 / 構造を整える（整形・装飾）
・確認して公開する（公開）
新しいものを作る工程ではなく、完成した文章を「公開できる状態」に変換する工程です。
ただし、ここには重要な前提があります。この工程はブラウザ操作を伴います。
ブラウザUI上の操作・視覚ベースの整形は、Claude Codeに任せることはできません。
ただし、操作そのものは任せられなくても、その前後の工程は構造化できます。
この「操作の前後を設計する」という考え方が、今回のポイントです。
この設計を行うのは人間の役割です。
Claude Codeに渡せる部分・渡せない部分
ルールと前提が揃っていれば、処理は高い再現性で任せられます。
構成あり・方向性あり・チェック項目が明確な状態が揃って初めて、安定して動きます。
判断が必要な部分や、曖昧な確認が残っている部分は、人間が調整する必要があります。
このように、条件が揃った処理は再現性高く任せることができます。
実際のフロー（Before / After）
Before（Claude Code導入前）
・入稿のたびに「何から確認するか」が曖昧だった
・チェック漏れが起きやすかった（descriptionを忘れる、リード文にキーワードが入っていないなど）
・公開後に管理ファイルの更新を後回しにして、状況把握がズレることがあった
・公開するたびに「どのファイルを更新すべきか」を思い出す必要があった
After（Claude Code導入後）
1. 執筆完了 → Claude Codeが入稿前チェックリストを実行
2. 指摘箇所を確認・修正する（人間）
3. WordPressに入稿・整形・公開する（人間のブラウザ操作）
4.「入稿しました」と報告 → Claude Codeが公開後の管理作業を自動実行
変わったのは「速さ」ではなく「抜け漏れのなさ」です。公開前の確認と公開後の管理更新がセットで動くことで、記事を出すたびに発生していた手間と見落としがほとんどなくなりました。
＼ 自分でやる時間がない方へ。まるっとブログ記事運用代行します／
お気軽にご相談ください。
Claude Codeがやっていること
入稿前：チェックリストの実行
公開前に必ず確認する項目があります。以前はこれを毎回手動で確認していました。
今はClaude Codeがチェックリストを実行します。
確認項目は次の通りです。
・metaのdescription（120〜140文字・メインキーワードを含むか）
・リード文：冒頭150文字以内にメインキーワードが入っているか
・内部リンク：関連記事2〜3本が入っているか
・文字数：ターゲット文字数に達しているか ・タイトルと本文の内容が一致しているか
・表記揺れ（Claude Codeの表記統一など）
これらをチェックして問題があれば指摘します。
調整するのは人間ですが、確認漏れがほぼ起きなくなりました。
入稿後：管理作業の自動化
記事を公開した後にも、管理上の更新作業が発生します。
記事のステータス変更・一覧への追記・次の記事への引き継ぎなど、公開のたびに繰り返す処理です。
「入稿しました」の一言を受けたら、Claude Codeはこれらをセットで自動実行するようにしています。
以前はすべて手動でやっていました。
1つでも漏れると管理情報がズレるため、毎回慎重に確認していました。
今は報告の一言で動くため、公開後の手間がなくなりました。
これらはすべてルールに基づいた処理のため、一度設計すれば再現性高く回すことができます。
人間が必ずやる部分
ブラウザ操作・整形・装飾
入稿・整形・公開の操作は、今もすべて手動です。
・WordPressのブロックエディタへの入力
・SWELLのカスタムブロック（ポイント・チェック・アラートなど）の設定
・アイキャッチ画像の生成・アップロード・設定 ・プレビューでの最終確認
・公開ボタンを押す
これらはブラウザ上の操作を伴うため、Claude Codeには任せられません。
ここは人間の作業として割り切っています。
現実的な落とし所は、「入稿の操作は人間がやる。前後の処理をClaude Codeに任せる」という分担です。
完全自動化を目指すより、この設計の方が安定して回ります。
仮にWordPress REST APIを経由した直接連携が実現できたとしても、
SWELLのカスタムブロックや細かなデザイン調整は、今の段階では、人間が確認・修正する工程が残ると考えています。
コンテンツ運用が続かない理由と仕組みの作り方
で書いた「止まらない設計」の考え方と同じで、詰まる工程を先に潰しておくことが継続の鍵になります。
この構造は他の業務でも共通する
今回の工程を言語化すると、次の構造になります。
・操作（ブラウザ / 視覚ベース） → 人間
・処理（確認 / 更新 / 整理） → Claude Code（ルールと前提が揃えば高い再現性で）
・設計（前後の構造を決める） → 人間
これはライティング業務に限りません。
「その作業は操作なのか、処理なのか」を分けて考えることで、
どこまで効率化できるかの判断ができるようになります。
操作はできない。でも前後は設計できる。
「その作業は操作なのか、処理なのか」を分けて考えることが、
自分の業務のどこまでを効率化できるかを判断する出発点になります。
この中でも特に重要なのは「設計」の部分です。
どこを分けて、どう回すかを決めるのは人間の役割です。
次の#05では、Claude Codeでも効率化できなかった工程を整理します。
うまくいった話だけではなく、「向いていない記事」「今も手動の部分」「使うべきでないケース」を正直にノートに残します。
＼ 自分でやる時間がない方へ。まるっとブログ記事運用代行します／
お気軽にご相談ください。
