「AIを使えば、ブログの自動投稿くらい簡単にできる」
そう思って試してみたら、最初の一歩で早速詰まった。
そんな経験、あなたにはありますか？
僕もまったく同じでした。
ClaudeCodeとCodexという2つのAIエージェントを使って
ブログ自動投稿の仕組みを作ろうとしたとき、
「すぐ動くだろう」という楽観的な見通しが
最初の数時間で完全に打ち砕かれました。
この記事では、僕が実際にぶつかった壁と、
そこから気づいた「自動化の正しい進め方」を
できるだけ正直にお伝えします。
技術的なチュートリアルというよりは、
「こういうところで止まった」「こう考え直した」という
体験談として読んでもらえると、一番届くかなと思っています。
ClaudeCodeとCodexは「同じAIエージェント」じゃなかった
最初に正直に言うと、
僕はClaudeCodeとCodexを「どちらも同じようなもの」だと
思っていました。
「AIがコードを書いてくれるツール」という理解で、
どちらを使っても結果は大して変わらないだろうと。
でも実際に使い始めると、すぐにその認識が間違いだとわかりました。
ClaudeCodeは、コードを書くというより
「エージェントとして動く」感覚が強いです。
指示を渡すと、ファイルを読んで、
状況を把握して、判断しながら進めてくれる。
「このファイルを修正して」と伝えると、
関連するファイルまで確認しながら動いてくれます。
一方でCodexは、
OpenAI系のコード補完・生成に強みがある印象です。
「この関数を書いて」という単体の依頼には強いけれど、
複数ファイルをまたいだ文脈の把握や、
プロジェクト全体の流れを追いながら動かすには
ClaudeCodeの方が馴染みやすかった。
この違いに気づくのに、
僕は無駄に何時間か使いました。
「なんかCodexだと指示が通りきらない」と感じながら
同じ指示を繰り返していたのですが、
そもそもツールの特性が違うという話でした。
どちらを使うかより「何をさせたいか」が先だった
ここで気づいたのが、
「ツールを選ぶより先に、何をどう動かしたいかを決めなければいけない」
ということでした。
自動投稿の仕組みを作ると言っても、
実際には細かい処理がたくさんあります。
- 記事のテーマをどう決めるか
- 本文を生成するAPIは何を使うか
- WordPressへの投稿はREST APIか、XMLRPCか
- 画像はどうするか、アイキャッチは自動生成か
- エラーが起きたときにどう通知するか
この設計が頭の中でふわっとしたまま
ツールを動かそうとしていたのが、
最初に詰まった本当の原因でした。
技術より先に「設計の甘さ」でつまずいていた
正直に言うと、
最初に詰まったのは技術的な問題じゃなかったんです。
エラーコードとか、APIの仕様とか、そういう話より先に、
「そもそも何をどういう順番で動かしたいのか」が
自分の中でぼんやりしていました。
ClaudeCodeに「ブログ自動投稿の仕組みを作って」と伝えると、
ClaudeCodeはちゃんと動こうとしてくれます。
でも、その前提として渡すべき情報が足りていない。
「WordPressのどのサイトに投稿するのか」
「記事のカテゴリはどう決めるのか」
「本文の文体や長さの基準はあるのか」
こういった情報を整理しないまま
「とりあえず動かして」という姿勢でいると、
AIエージェントは動けません。
あるいは動いても、想定と全然違うものが出てくる。
僕が最初に頭を抱えたのはまさにここでした。
「指示通りに動いてくれない」と感じていたけど、
実際は「指示が足りなかった」だけの話だったんです。
具体的にどこで詰まったか
実際にぶつかったポイントをいくつか書いておきます。
同じところで詰まっている人の参考になればと思います。
まず本文生成のプロンプト設計。
「ブログ記事を書いて」という雑な指示だと、
毎回バラバラなフォーマットの記事が出てきました。
文字数も、見出しの有無も、文体も統一されない。
プロンプトにテンプレートと文体の指定を入れて初めて、
再現性のある出力になりました。
次にWordPressへの投稿設定。
ConoHa WINGを使っているのですが、
REST APIのエンドポイントが普通と少し違います。
`/wp-json/wp/v2/posts` が動かなくて調べたら、
`?rest_route=/wp/v2/posts` の形式でないといけなかった。
これに気づくまでに結構な時間がかかりました。
そしてエラー処理。
自動投稿が「動いた」と思ったら、
一部の記事だけタイトルが空白で投稿されていたことがありました。
原因を追いかけると、APIのレスポンスが特定の条件で
期待した形式で返ってこない場合があって、
そこをケアしていなかったというミスでした。
「動いている」と「ちゃんと動いている」は別の話だ、
と痛感した瞬間でした。
「動かしながら直す」という考え方に切り替えた
詰まり続けた結果、
僕はある考え方に切り替えることにしました。
「完璧な仕組みを最初から作ろうとしない」ということです。
最初は「全部つながった自動化」を一気に作ろうとしていました。
記事生成→画像生成→WordPress投稿→SNS告知まで
一度に全部動かす仕組みを。
でもそれは、詰まる箇所が多すぎて
どこが問題かすら特定できない状態を作り出していただけでした。
そこで切り替えたのが、
plan-only → dry-run → draft
という段階的なアプローチです。
plan-only・dry-run・draftの順番で進む
まずplan-onlyの段階では、
「何を実行するか」だけを出力させて、
実際には何も動かさない。
ClaudeCodeに「このコードを実行したらどうなるか説明して」と
確認するイメージです。
次にdry-runの段階。
実際のAPIやサーバーには触らず、
ローカルやモック環境で動作を確認します。
「本番のWordPressには投稿しないけど、
投稿用のデータが正しく組み立てられているか」を確認する段階です。
そしてdraftの段階。
実際にWordPressに投稿するけれど、
ステータスは「下書き」で保存する。
投稿内容が期待通りかを人間が確認できる状態を作っておく。
- plan-only：何をするかの計画だけ確認する
- dry-run：実際には触らずデータの組み立てだけ確認する
- draft：本番環境に投稿するが、公開はしない
この3段階を経て初めて「自動公開」に進む。
そう決めてから、作業が格段にスムーズになりました。
一気に完成させようとして詰まり続けるより、
一段階ずつ確認しながら進む方が
結果的にはるかに早い。
遠回りに見えて、一番の近道だと実感できた瞬間でした。
失敗した箇所を記録しておくことの価値
もう一つ、やってよかったと思うことがあります。
詰まった箇所を、その都度メモしておくことです。
「ConoHa WINGではREST APIのエンドポイント形式が違う」
「プロンプトに文体指定がないと出力がバラバラになる」
「APIレスポンスの異常系をケアしないと空白投稿が起きる」
こういった詰まりポイントは、
次に同じ仕組みを作るときの設計書になります。
ClaudeCodeに渡す指示書にも転用できる。
「失敗した」で終わらせず、
「詰まったポイントを言語化して記録する」という習慣が、
自動化の精度を上げる一番のインプットになっています。
AIエージェントは、情報を渡せば渡すほど精度が上がります。
その情報の源泉が、自分自身の失敗の記録なんです。
ClaudeCodeに渡す「前提情報」が品質を決める
使い続けてわかったのは、
ClaudeCodeの出力品質は
「渡す情報の質」でほぼ決まるということです。
ツールが賢いかどうかより、
使う側がどれだけ文脈を整理して渡せるかが
出力の差に直結しています。
僕が今ClaudeCodeに渡している前提情報は、
Cehamのプロフィール・記事テンプレート・文体ルール・
投稿先のWordPressの仕様メモ、といった内容です。
これを用意してから、
生成される記事の質が明らかに変わりました。
「AIに書かせる」というより
「AIがちゃんと動けるだけの設計を整える」
という感覚が正確だと思っています。
まとめ｜自動化は設計から始めるより、動かしながら設計する
この記事で伝えたかったことを、最後に整理します。
- ClaudeCodeとCodexは役割が違う。用途に合わせて使い分けることが大事
- 最初に詰まるのは技術的な問題より「設計の甘さ」であることが多い
- plan-only → dry-run → draftの順番で、一段階ずつ確認しながら進む方が早い
自動化は魔法じゃありません。
「これを入れたらすべてうまくいく」という仕組みは存在しなくて、
詰まるたびに設計を見直して、一歩ずつ積み上げていくものです。
でも、その積み上げが終わったあとに動く仕組みは
本当に強い。
気合いで毎日記事を書き続けようとして3ヶ月で息切れした僕が、
今は仕組みに任せながら前に進めているのは
この考え方のおかげだと思っています。
まずは「
コメント