前に401エラーの沼にハマった話を書いたと思うんだけど、今日はその後日談。実際にこの「AIがブログの下書きを自動でWordPressに送ってくれる仕組み」を、ちゃんと日々の記事制作フローに組み込むところまでやってみたので、その中身と、実際に組んでみて分かった「人間の目が絶対に必要な部分」を紹介するね。これを読むと、同じような自動化を考えている人が、最初からつまずきポイントを避けて仕組みを作れるようになると思う。
前回はパスワードの話で沼にハマってましたもんね。今回はちゃんとうまくいったんですか?
この前の記事で「画像だけはWAFにブロックされて手動アップロードに切り替えた」って書いたんだけど、あれ、実は正確じゃなかった。正しくは、WAFを手動で一時オフにしてから、その後は自動でアップロードされる、というのが実態。完全手動じゃなくて、「一部だけ手動のスイッチが必要」ってのが、もう少し正確な言い方だったので、この場で訂正させてね。
仕組み自体はちゃんと動くようになったよ。でも正直に言うと、私は最初「本当にこんなの全自動でできるのかな」って半信半疑だったの。世の中には「寝てる間に記事が勝手に増えてる」みたいな、AIに全部お任せしちゃうやり方も紹介されてるみたいなんだけど、私はそこまでは怖くてできなかった。で、実際に使ってみたら、その心配は当たってたの。
Claude Code + post_to_wordpress.pyのプロジェクトフォルダ。
作った仕組み:「下書きまで自動、公開は人」
まず、実際に組んだ仕組みを説明するね。名前はそのままpost_to_wordpress.py。Claude Codeに記事の下書き(Markdown)を渡すと、それをWordPressの下書きとして送ってくれるプログラムなの。ポイントは、「下書きを作るところまでは自動、でも公開ボタンを押すのは絶対に私」っていう設計にしたこと。
なんで公開だけは人がやる、っていうルールにしたんですか?
AIに全部任せると、変な内容のまま世に出ちゃうリスクがあるでしょう。それに、実は9月頭に参加したセミナーで「AIには読者が読みやすい『形』(構成・下書き・仕組み化)を任せて、人は読者を惹きつける『中身』(経験・視点・判断)を担う」っていう考え方を教わってね。今回の設計は、まさにそれを自分なりに実践した形。それに、AIが全部書いた記事を放置で量産するようなやり方は、Googleの広告審査(AdSense)で「有用性の低いコンテンツ」って判定されるリスクもあるみたいで、そこも気になってたポイント。
じゃあ「公開は人」っていうのは、こだわりというより保険でもあるんですね。
そうなの。それと、この仕組みはいつも使っているパソコンと、塾のパソコンのどちらからでも動くようにしてある。WordPressには「アプリケーションパスワード」っていう、プログラム専用の合鍵を発行できる機能があるんだけど、この合鍵をパソコンごとに別名で発行して使い分けてるの。
🔑 もし同じことが試したいなら
複数のパソコンから同じ仕組みを使いたい場合は、アプリケーションパスワードを1個だけ発行して使い回すのはおすすめしません。片方を作り直すと、もう片方が使えなくなる事故が実際に起きました。パソコンごとに別名で発行しておくと安全です。
実際に使ってみたら…案の定、問題が起きた
さっきの「半信半疑」の話に戻るんだけど、実際に401エラーを乗り越えて、本番の記事(前回の401エラー記事そのもの)を投稿してみたの。そうしたら、公開した後にこんなことが起きた。
何が起きたんですか?
記事内に貼ったスクリーンショットの中に、個人のフォルダ名やユーザー名、それに本来隠すべきパスワードの一部まで、うっかり写り込んじゃってたの。しかも1回直したつもりが、別の画像にも同じような写り込みが見つかって、結局2日がかりで修正することになった。
えっ、それはヒヤッとしますね……
それだけじゃなくて、キャプションと実際の画像の中身がズレてる箇所も複数見つかったの。本来の内容とは全然違う画面が入ってたり。全部自動でうまくいくと思ってたけど、結局「人間の目でひとつずつ確認する」作業が、公開前にどうしても必要だったんだよね。
🔑 もし同じことが起きたら
「下書きまでは自動、公開は人」にしていても、公開直前の画像チェックを人力の目視だけに頼ると、見落としが起きます。特に、スクリーンショットを大量に使う記事ほど、機械的なチェックを一段挟むことをおすすめします。
だから作った:image-checkerという「もう一人の目」
この痛い目にあったのがつい昨日のことでね。それで「じゃあ次からどうする?」って考えて、Claude Codeの中に、画像だけを専門にチェックする「image-checker」という新しい担当(サブエージェント)を作ることにしたの。
担当を新しく作ったんですか?
そう。実はもともと、記事の事実確認をする「fact-checker」っていう担当がいるんだけど、それとは完全に別の係。image-checkerの仕事は2つだけに絞ってる。
- 配置整合性チェック:キャプションと、実際に貼られている画像の中身が一致しているか
- 個人情報漏洩チェック:実名・ユーザー名・パスワードの実値・個人のフォルダパス・メールアドレスなどが写り込んでいないか
事実確認とは別なんですね。
うん、事実確認・文章のトーン・内部リンクの提案は今まで通りfact-checkerの仕事のまま。image-checkerは画像のことだけ見る、って役割をはっきり分けたの。それと、これは「必要な時に呼び出す手順書」(Skill)じゃなくて、「独立した判断をする担当」(サブエージェント)として作った。理由は、記事を書いた本人がそのまま画像もチェックすると、「自分は正しく配置したはず」っていう思い込みが混ざりやすいから。まっさらな目で見る別人格のほうが、見落としに気づきやすいの。
なるほど、あえて他人目線にしたんですね。(ちなみに、Claude Codeサブエージェントの作り方を実践でも、fact-checkerを作ったときの話をもう少し詳しく書いているから、気になる人はそちらもどうぞ。)
それと、image-checkerは問題を1件でも見つけたら、アップロード処理を自動で止めて、一覧を報告してから私の指示を待つ、っていう設計にしてある。「まあ大丈夫だろう」で通しちゃうと、また同じことが起きるからね。
導入手順:同じ仕組みを作るには
同じような仕組みを作りたい人向けに、実際にやった手順をまとめておくね。
- 担当ファイルを作る:
.claude/agents/image-checker.mdというファイルを、Claude Codeのプロジェクトフォルダの中に作る。中身は「役割」「やらないこと」「実行手順」「出力フォーマット」を書いたテキストファイル
実際のimage-checker.mdの中身。
- 既存の担当と同じ場所に置く:すでにfact-checker等の担当がいる場合は、同じ
.claude/agents/フォルダに並べて置く
3つの担当ファイルが並んでいる様子。
- チームで共有する場合はGit管理に乗せる:
git add→git commit→git pushで、複数のパソコンから同じ担当を呼び出せるようにする
gitへのコミット・プッシュが完了した画面。
- 呼び出すタイミングを決める:私の場合は「WordPressに画像をアップロードする直前」に必ず呼ぶ、というルールにした
- 問題発見時の挙動を決める:自動で処理を止めるのか、参考情報として一覧だけ出すのか、あらかじめ決めておく
手順自体はそんなに難しくないんですね。
仕組みを作ること自体は、実はそんなに大変じゃないの。大変なのは、「どこに人間のチェックを残すべきか」を、痛い目にあって初めて気づくところなんだよね。
用語のミニ解説
今日も専門用語が出てきたから、簡単にまとめておくね。
- Claude Code:AIにパソコン上の作業(ファイル編集・プログラム実行など)を任せられるツール
- サブエージェント:Claude Codeの中で、特定の役割だけを持つ「別人格」の担当。記事を書く担当とは別に、チェック専門の担当を作れる
- Skill:必要な時に参照する、固定の手順書。判断や処理停止はしない(プロジェクトとスキルの使い分けについてはこちらも参考に)
- アプリケーションパスワード:普段のログインパスワードとは別に発行する、プログラム専用の合鍵(前回の記事で詳しく解説)
まとめ
今日の話をまとめると、「下書きまで自動、公開は人」という仕組み自体はちゃんと動くようになったけど、公開前のチェックを人の目だけに頼ると見落としが起きる、というのが今回の一番の学び。だからこそ、image-checkerという「もう一人の目」を機械的に用意した、という話でした。
半信半疑からのスタートだったけど、ちゃんと対策までたどり着いたんですね。
うん。前回の401エラーの話と合わせて読むと、「自動化の裏側で実際に何が起きるか」がまるっと分かると思うから、気になる人はぜひそちらもどうぞ。
コメント