WordPressの記事制作でChatGPTとClaude Codeを併用すると、企画から入稿までの流れは確かに進めやすくなりました。
ただ、二つのAIへ同じように仕事を振ると、今度は会話やファイル、承認箇所が散らかります。どちらに何を頼み、最後に誰が確認するのか。そこが曖昧なままでは、便利なはずのAIが新しい混乱の原因になりかねません。
そこで、役割を次のように分けました。
- ChatGPT：企画と判断
- Claude Code：ファイル管理と定型処理
- 人間：承認と画面確認
とはいえ、役割を分ければ、すべて順調に進むわけではありません。実際の記事制作では、日本語の文字化けや、本文内画像が消えるといった失敗も起きました。
この記事では、ChatGPTとClaude Codeの使い分けだけでなく、企画・調査・入稿・公開までの流れ、そして失敗後に決めた安全ルールまで紹介します。
この記事で分かるのは、次の4点です。
- ChatGPT・Claude Code・人間をどう使い分けているか
- WordPress記事を企画から公開までどう進めているか
- 制作中に起きた3つの失敗と、その対応
- 安全に運用するために決めたルール
WordPress記事制作で役割分担が必要になった理由
WordPressの記事制作には、企画、調査、執筆、画像の準備、入稿、確認、公開と、いくつもの工程があります。
サイトを立ち上げるまでの流れは、ロリポップでWordPressを始めた手順と費用にまとめました。
ここでChatGPTとClaude Codeの役割が曖昧だと、「どこで何を決めたのか」「最新の原稿はどれか」「公開してよい状態なのか」が分からなくなります。
必要だったのは、AIを増やすことではなく、作業の置き場所と承認ポイントを決めることでした。
もちろん、これから紹介する分担が唯一の正解ではありません。今の作業量と、一人で運営している状況に合わせた一例です。
ChatGPT・Claude Code・人間の役割を分ける
役割を決める前に、それぞれのツールが公式にどう説明されているかも確認しました。
ChatGPTの「プロジェクト」は、長期的な取り組みに関するチャット、参考ファイル、カスタム指示を一か所にまとめるためのワークスペースです。OpenAI公式でも、執筆や調査、計画など、継続して発展する作業に向いた機能として紹介されています（ChatGPT のプロジェクト｜OpenAI公式）。
企画や構成、過去に決めた方針など、考えを積み重ねる仕事をChatGPT側に置いているのは、この設計と相性がよいためです。
一方のClaude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行しながら作業を進めるエージェント型のツールです（Claude Code Overview｜Anthropic公式）。
そのため、決まった内容をファイルへ残す、原稿や画像を管理する、定型的な処理を実行するといった「手を動かす仕事」を任せています。
そして最後に残るのが、人間の役割です。
Claude Codeには、操作の前に確認を求める運用もあれば、一定範囲を自動承認する運用もあります（Permission modes｜Anthropic公式）。
私は、公開や外部接続を伴う操作には人間の確認を残す形を選びました。Claude Codeの唯一の使い方ではなく、失敗したときの影響を考えたうえでの運用判断です。
ChatGPTに任せること
主に任せているのは、戦略、企画、調査、構成、文章評価、優先順位づけです。
まだ形になっていない考えを整理したいときや、複数の案から進む方向を決めたいときに使います。正解が決まっていない段階を担当する役割、と考えると分かりやすいかもしれません。
Claude Codeに任せること
Claude Codeには、ファイルの作成、記録、定型処理、WordPress REST APIを使った下書き操作などを任せています。
すでに決まった内容を、決まった場所へ、決まった形で残していく役割です。作業の途中で日をまたいでも、原稿や進捗がファイルとして残っていれば再開しやすくなります。
Claude Codeには、特定のタイミングで処理を自動実行するHooksという仕組みもあります（Hooks｜Anthropic公式）。
コマンド型のHooksはローカル環境でシェルコマンドを実行するため、設定内容と実行される処理を十分に理解してから使う必要があります。
今のところHooksは使わず、公開や外部操作の前に手動承認を挟む方法を優先しています。便利さよりも、何が実行されるのかを自分で把握できることを選びました。
人間が判断すること
人間が担当するのは、承認、画面確認、公開判断、アカウント操作です。
AIから「完了しました」と報告が来ても、それで作業が終わったとは考えません。公開してよいか、実際の画面は崩れていないか、意図しない変更が入っていないか。最後の判断は人間側に残しています。
役割を簡単に整理すると、次のようになります。
| 担当 | 主な役割 | 任せないこと |
|---|---|---|
| ChatGPT | 戦略、企画、調査、構成、文章評価、優先順位 | WordPressへの直接公開、認証情報の管理 |
| Claude Code | ファイル作成、記録、定型処理、REST APIによる下書き操作 | 無断公開、無断削除、承認なしの外部操作 |
| 人間 | 承認、画面確認、公開判断、アカウント操作 | AIの完了報告だけを信じ、確認を省略すること |
これは、現在の運用で機能している分担です。作業量や人数が変われば、適切な境界も変わるでしょう。
実際のWordPress記事制作フロー
では、この役割分担を記事制作へどう落とし込んでいるのか。作業は、次の順番で進めています。
- ChatGPTで記事の目的と検索意図を決める 誰に何を伝えるのか、どんな検索から読まれる記事なのかを整理します。
- 公式情報を調査する 使用するツールやサービスの公式ドキュメントを中心に、記事の根拠となる事実を集めます。
- Fact Sheetと構成案をファイルへ残す 調査した事実、記事で扱う内容、公開してはいけない情報をClaude Codeに記録させます。数日後に作業を再開するときも、判断の経緯をたどれます。
- 原稿と画像を正式ファイルとして管理する 下書き原稿と使用する画像を、あとから確認できる状態で保存します。
- Claude CodeがWordPressへ下書き入稿する WordPress REST APIでは、投稿のステータスなどを指定して作成・更新できます（Posts – REST API Handbook｜WordPress公式）。最初から公開せず、必ず下書きの状態で入稿します。
- 人間が管理画面とプレビューを確認する APIの応答だけではなく、WordPress管理画面と実際の表示を目で確認します。
- 承認してから公開する 問題がないことを確認したあと、公開操作だけを別に実行します。
- 公開後にもう一度確認する 画像、リンク、日本語表示、スマートフォンでの見え方などを再確認します。公開した瞬間を完了とは考えません。
この流れで制作した実例が、ロリポップ×CocoonのWordPress初期設定の記事です。
ここまで読むと、整った制作フローに見えるかもしれません。ただ、実際にはいくつかの失敗も起きました。
実際に起きた失敗
成功した工程だけを並べても、AIを使った運用の実像は伝わりません。
ここからは、記事制作中に実際に起きた3つの失敗を紹介します。なお、具体的なIDや認証情報、内部の保存場所などは、安全上の理由から省いています。
日本語が文字化けした
WordPressへ下書きを入稿した際、完了報告上は「文字化けなし」とされていました。
ところが、管理画面を開くと、タイトルと本文の日本語が崩れていました。後からAPIで本文を取得し直したところ、取得した内容にも同じ文字化けが残っていました。
つまり、問題がなかったのではなく、完了確認の方法が足りなかったということです。
復旧には、ローカルへ保存していた正常な原稿を使いました。元の文章が別に残っていたため、文字化けした本文を推測で直さずに済みました。
根本原因は、今も確定していません。以後は、送信後に内容を取得し直す確認と、管理画面を人間が見る確認の両方を行うようにしました。
本文内画像が消えていた
画像ファイルのアップロードと、WordPressのメディア登録は正常に完了していました。本文へ挿入したという報告も受け取っています。
しかし、公開ページを開くと画像が見当たりません。
あらためて本文を確認したところ、画像が表示されていないだけではなく、画像ブロックそのものが本文から消えていました。
このときは、登録済みのメディアを再利用して、本文へ挿入し直しました。画像を新たにアップロードする必要はありませんでした。
こちらも原因は確定できていません。
この経験から、今は次の二つを分けて確認しています。
- メディアライブラリへ画像が登録されているか
- 記事本文に画像が残り、公開ページで表示されているか
「アップロードできた」と「記事内に表示された」は、同じ確認ではありません。
完了報告と実際の画面が一致しなかった
文字化けと画像消失に共通していたのは、AIの完了報告と実際の画面が一致していなかったことです。
APIの値やHTMLだけを見て「問題なし」と判断しても、読者が見るページまで正常とは限りません。
最終確認では、次の画面を見るようにしています。
- WordPress管理画面
- パソコンでの公開ページ
- スマートフォンでの公開ページ
- ログインしていない状態の公開ページ
今では、AIの完了報告を「作業終了の証明」ではなく、「人間が確認を始める合図」として扱っています。
安全に運用するために決めたルール
一連の失敗を踏まえ、次のルールを設けました。
- 下書きと公開を別の操作にする
- 公開直前には人間へ実行確認を出す
- 同じ記事が存在する場合は、上書きせず一度停止する
- 認証情報を本文、指示書、完了報告へ表示しない
- 指示されていないファイルやフォルダを探索しない
- 削除、公開、外部送信は人間の承認後に行う
- 更新後は文字化け、画像、リンクに加え、変更対象外の要素が維持されているかも確認する
- 大きな変更を一度に行わず、小さく進めて確認する
どれも特別な技術ではありません。むしろ、AIに任せる範囲を増やすほど、止まる場所を明確にすることが重要でした。
この方法が向いている人・向いていない人
この分担は、複数のAIツールを使っているものの、役割が曖昧になっている人に向いています。
効率化はしたい。ただし、公開や削除まで完全に任せるのは不安。そんな人にも取り入れやすい方法です。
一方、すべてを手放しで自動化したい人や、ファイルを残したり記録を整理したりする作業そのものを省きたい人には、合わないかもしれません。
この方法の目的は、確認をなくすことではなく、確認すべき場所を絞ることにあります。
テンプレート化すると再開しやすくなる
役割分担や確認項目を毎回ゼロから考えていると、記事を作るたびに同じ判断を繰り返すことになります。
そこで、実際に使っている運用ルールを、再利用できるテンプレートとして整理し始めました。
対象は、次のようなものです。
- 役割分担表
- Claude Codeへの初期指示
- WordPress記事制作の確認項目
- 公開前チェックリスト
- 完了報告の形式
テンプレートとして残しておけば、作業を途中で止めても、次に何をすべきかを判断しやすくなります。別の記事を作る際にも、同じ安全確認を使い回せます。
まだ整理の途中で、価格や公開時期は決めていません。内容がまとまり次第、あらためて案内する予定です。
まとめ
今回の運用で特に重要だったのは、次の4点です。
- ChatGPT、Claude Code、人間の役割を分ける
- 下書き、承認、公開を別々の工程として扱う
- 文字化けや画像消失は、実際の画面を見て確認する
- AIの完了報告を、確認開始の合図として受け取る
AIを使えば、記事制作の多くを効率化できます。
ただし、任せる範囲を増やすだけでは、運用は安定しません。誰が考え、誰が作業し、誰が最後に確認するのか。その境界を決めて初めて、AIを継続的な制作へ組み込めるようになりました。
役割分担を決めるまでの経緯は、ChatGPTとClaude Codeの役割を分けるまでにまとめています。