今回はClaude Codeから直接WordPressに記事を投稿できるようにした話をします。
なお、技術的な設定やファイルの中身、サイト内部のアドレスにあたる情報は、悪用される可能性があるため具体的には載せていません。あくまで備忘録として実施した内容を記載します。
そもそも、なぜClaudeCodeをから投稿するのか
最近、記事の構成にClaude Codeというツールを使っています。これは、AIと対話しながらパソコン上のファイルを直接作ったり直したりできる、いわゆる「AIエージェント」と呼ばれる種類のものです。
ただ、記事づくりには手作業が残っていました。本文を書き上げたあと、WordPressの管理画面を開いて、本文をコピーして貼り付け、見出しやリンクの体裁を整え直し、カテゴリーや説明文を入力する、という工程です。文章が長くなるほど、この最後の詰めが面倒でした。
そこで今回は、書き終えたらそのままWordPressに記事ができあがっている状態を目指しました。管理画面を開かずに、Claude Codeから直接投稿できるようにする、という試みです。
そもそも、どうやって外部から投稿するのか
WordPressには、外部のプログラムから記事を読み書きするための窓口が最初から用意されています。プラグインを追加する必要はありません。ここに「記事のタイトルはこれ、本文はこれ、カテゴリーはこれ」という内容を送ると、記事ができあがります。
問題は認証です。誰でも投稿できてしまっては困るので、正しい持ち主であることを証明する必要があります。
ここで使ったのがアプリケーションパスワードという、WordPressに標準で備わっている機能です。名前のとおり「アプリケーション（プログラム）専用のパスワード」で、普段のログインパスワードとは別に発行できます。
いちばん大事な話: ログインパスワードを使ってはいけない
外部ツールとWordPressをつなぐとき、設定画面に「ユーザー名」と「パスワード」を入れる欄があると、つい普段のログインパスワードを入れたくなります。これは避けるべきです。
アプリケーションパスワードには、ログインパスワードにはない性質があります。
- 用途ごとに発行できる — 「この用途用」「別のツール用」と分けて作れる
- 1本ずつ取り消せる — 怪しいと思ったらその1本だけ無効にできる。他の用途に影響しない
- 管理画面にはログインできない — 万一漏れても、管理画面に侵入して設定を書き換えられることはない
- 二段階認証と両立する — 二段階認証を有効にしていても、外部ツールから接続できる
逆に言えば、ログインパスワードを設定ファイルに書いた瞬間、そのファイルが漏れること＝サイトを丸ごと乗っ取られること、と同じ意味になります。パスワードを分けておけば、被害を「記事を書かれる」程度に抑え込めます。
安全に組むために決めたこと
今回、次の7つを自分のルールとして決めました。
1. 認証情報は作業フォルダの外に置く
パスワードを書いた設定ファイルは、記事や作業ファイルを置いているフォルダの外に、別の場所を作って保管しました。作業フォルダの中に混ぜると、フォルダごと誰かに共有したときや、バックアップを取ったときに、一緒に流出してしまいます。
2. Claude Code自身にパスワードを読ませない
これは今回いちばん気を使った点です。AIエージェントに対して「この設定ファイルは読んではいけない」という制限を設定しました。
パスワードを扱うのは投稿用のプログラムだけで、AI自身は値を一度も見ません。AIが読んだ内容は対話の履歴に残るため、そこにパスワードが載らないようにしておくことが重要でした。
3. バージョン管理に含めない
作業ファイルはGitというツールで変更履歴を管理していますが、認証情報は履歴に残らないよう除外設定を入れました。1と合わせて二重の対策です。
4. 暗号化されていない通信では使わない
アプリケーションパスワードは、通信が暗号化されていないと、途中で盗み見られる可能性があります。WordPress側も暗号化されていないサイトではこの機能を有効にしませんが、ツール側でも暗号化されていない接続を拒否するようにしました。
5. 何も指定しなければ「下書き」にする
投稿コマンドで公開状態を指定しなかった場合、必ず下書きになるようにしました。書きかけの記事が事故で公開されるのを防ぐためです。公開したいときだけ、はっきりとそう指定します。
6. 記事を削除する機能はつくらない
消すためのコマンドは、あえて用意しませんでした。取り下げたいときは下書きに戻すだけにしています。取り返しのつかない操作は、そもそも実行できないようにしておくのがいちばん確実だと考えました。
7. 使わなくなったら失効させる
アプリケーションパスワードは、管理画面の一覧から1本ずつ取り消せます。このツールを使わなくなったら消す、と決めています。
どんなプロンプトで進めたか
「AIエージェントで作った」と書くと、さぞ凝った指示を書いたように思われるかもしれませんが、実際は逆です。最初の一言と、あとはエラーを貼る作業の繰り返しでした。ここが今回いちばん共有したい部分かもしれません。
最初の指示は「目的」だけ
最初に打ったのは、これだけです。
Claude CodeからWordPressに直接記事を投稿できるようにエージェントを組みたい。どうやればいい？
手順は一切指示していません。「何を実現したいか」だけを伝えて、方法は考えてもらう形です。
ポイントは末尾の「どうやればいい？」でした。いきなり「作って」と言わず、まず方針を出させたことで、着手前に前提の確認が入りました。
前提を先に確認させる
すると、逆に質問が返ってきました。
- 投稿先は自分で借りたサーバーのWordPressか、それとも公式のホスティングサービスか
- 公開まで自動でやってよいか、下書き止まりにするか
これに答えるだけで方針が固まりました。この2点を最初に確定させないと、まったく違うものができあがっていたはずです。
作り始める前に前提を聞き返してもらえるかどうかは、こちらの指示の出し方でだいぶ変わります。「どうすればいいか」と相談の形で入るのが有効でした。
いちばん効いたのは「エラーをそのまま貼る」
作業時間の大半は認証エラーの調査に消えました。そこでやったことは単純で、画面に出たメッセージをそのまま貼りつけるだけです。
「なんかエラーが出た」と書いたり、自分で要約したりすると、かえって原因から遠のきます。数字も記号も含めて丸ごと貼るのがいちばん早いです。
同じ理由で、設定ファイルの中身を見てほしいときも、自分で抜粋せずに該当箇所をそのまま渡しました。自分が「重要そう」と思って削った部分に原因があることは、けっこうあります。
安全のためのルールは、作業前に一度だけ書いておく
これは作業中のプロンプトではなく、事前の仕込みです。
作業用のフォルダに、AIが毎回必ず読むルールのファイルを置いてあります。そこに「元のファイルは書き換えない」「削除はせず退避する」「外部に影響する操作は勝手に実行しない」といった決まりを書いてあり、毎回の指示で言わなくても守られます。
今回の「認証情報のファイルは読まない」という制限も、この仕組みで設定しました。毎回のプロンプトで気をつけるのではなく、最初に一度書いておくほうがはるかに確実です。
記事そのものも、指示で直した
この記事自体もAIに書かせていますが、一発では通りませんでした。実際に出した指示です。
記事内容が読者を置いてけぼりにしている。自分が何者で、どんな作業を試みていて、何を実現しようとしたかを最初に記載してから文章を書いてほしい
具体的なコードとURLはハッキングのリスクがありそうなので載せるのを控えてほしい
「何が不満か」と「どう直してほしいか」をセットで伝えると、意図した方向に寄っていきます。「もっと良くして」だけでは、たいてい狙いから外れます。
つまずいた4つの失敗
ここからが本題です。設定を終えて接続を試したところ、「認証に失敗しました」というエラーが出続けました。原因にたどり着くまで、何度も行き来しました。
失敗1: ユーザー名を取り違えていた
設定ファイルの「ユーザー名」の欄に、レンタルサーバーの管理画面にログインするときのアカウント名を書いていました。ここに入れるべきなのはWordPressのログイン名です。
サーバー会社のアカウント名、WordPressのログイン名、ブログ上に表示される名前。これらは全部別々でありうる、ということを意識していませんでした。今回の原因は、突き詰めるとこれでした。
失敗2: 末尾に空白が混ざっていた
コピー＆ペーストしたときに、ユーザー名の最後に半角スペースが1つ紛れ込んでいました。画面を見ても分かりません。
結果的にはこれは原因ではありませんでしたが、疑う対象が増えて切り分けが長引きました。設定ファイルに値を貼るときは、前後の余分な空白に注意してください。
失敗3: 表示用の名前をログイン名だと思い込んだ
これがいちばん厄介でした。
WordPressから利用者の情報を取り出すと、ブログのURLに使われる表示用の短い名前が返ってきます。これを見て「ログイン名はこれだ」と判断したのですが、実はこれはログイン名とは別の項目でした。初期状態では両者が一致することが多いため、一度でも変更していると気づけません。
私の場合、この表示用の名前は「よくある管理者名」でしたが、実際のログイン名はまったく別の文字列でした。ここで完全に方向を見失いました。
確実な確認方法は、管理画面の利用者一覧を開いて「ユーザー名」の列を見ることです。 推測せず、正面から確認するべきでした。
失敗4: コピー＆ペーストで文字が1つ落ちて、エラーになった
テーマに数行のプログラムを追加する場面がありました。手元でコピーして管理画面の編集欄に貼り付けたところ、書式のエラーが出て保存できませんでした。
原因は、行末にあるべき記号が1つ抜けていたことでした。コピーの際に取りこぼしたようです。
幸いWordPressには、保存する前に致命的なエラーを検知して保存自体を止める仕組みがあり、サイトは無事でした。この保護がなければ、画面が真っ白になっていたところです。
教訓として、行数が多いものを管理画面に直接貼るのは避けたほうが安全です。テーマをまとめてアップロードし直す方法なら、貼り付けミスが原理的に起こりません。
エラーが出たときの、調べる順番
同じところで止まる人がいそうなので、切り分けの順番を残しておきます。
1. アプリケーションパスワードが本当に発行されているか確認する
WordPressは、そのサイトでアプリケーションパスワードが1本も作られていない状態だと、認証を試すことすらせず、いきなりエラーを返します。設定が合っていても失敗するので、まずここを見ます。
2. ログイン名を管理画面で直接確認する
失敗3のとおりです。表示用の名前から推測せず、利用者一覧の「ユーザー名」列を見ます。
3. 「パスワードが違う」のか「そもそも届いていない」のかを分ける
ここが最大のポイントです。
サーバーの設定によっては、外部から送った認証情報がWordPressまで届かないことがあります。この場合、パスワードが完全に正しくても認証に失敗します。
つまりエラーが出たとき、原因は「認証情報が間違っている」と「認証情報が届いていない」の2種類あります。この2つを区別しないまま調べ始めると、延々と間違った側を疑い続けることになります。 私はここで一番時間を溶かしました。
区別する方法として、WordPressには昔から使われている別の通信方式があり、そちらは認証情報の送り方が違うため、届く・届かないの問題と切り離して「パスワードそのものが正しいか」だけを確かめられます。これを試したことで「認証情報が間違っている」と確定でき、そこでようやくユーザー名の誤りに行き着きました。
4. 届いていないと分かった場合にだけ、サーバー設定に手を入れる
ここまで来て初めてサーバー側の設定ファイルを触る段階になります。サーバーの種類によって必要な記述が変わるため、契約しているサーバー会社の情報を確認するのが確実です。
この作業は最後です。 私は順番を間違えて、必要のないサーバー設定の変更を先に試してしまいました。結果的には無駄足でした。
まとめ
- ログインパスワードではなく、専用のアプリケーションパスワードを使う
- 認証情報は作業フォルダの外に置き、バージョン管理にもAIにも渡さない
- 何も指定しなければ下書き。取り返しのつかない操作は最初から実装しない
- エラーが出たら、サーバー設定を疑う前に、認証情報そのものを疑う
- ログイン名は管理画面で確認する。表示用の名前から推測しない
- 長いプログラムを管理画面に直接貼らない
- プロンプトは凝らなくていい。目的だけ伝えて、あとはエラーをそのまま貼る
- 守ってほしいルールは、毎回言うのではなく最初に一度書いておく
仕組みそのものより、うまくいかないときの切り分けのほうがはるかに難しい、というのが今回いちばんの実感でした。
今は、記事を書き終えるとそのまま下書きとしてWordPressに入っている状態になっています。この記事自体も、その仕組みを通して投稿されたものです。