日: 2026年9月12日

前回はWP-CLIを都度実行方式でラップし、Claude Codeからssh経由で下書き投稿できるようにするところまでをお届けしました。今回はその周辺、「ネタをどう受け渡すか」と「画像をどう埋め込むか」で実際に転んだ話です。技術的には地味な話が多いですが、同じ構成を検討している人には割と参考になるはずです。

ネタ出しの受け渡し：Google Driveを間に挟む

記事のネタは、普段使いのclaude.ai側（チャット・プロジェクト機能）で思いつくことが多いのですが、これをどうClaude Code側に連携するかが最初の課題でした。jagha上にネタ帳ファイルを置いてSSHクライアントアプリ経由で書き込む案や、claude.aiプロジェクトへ手動でコピペする案も検討しましたが、しっくりこず。最終的に落ち着いたのは、Google Driveのフォルダを間に挟む方式です。

• Google Drive上にマイドライブ/claude BLOGフォルダを用意
• claude.aiプロジェクト側にこのフォルダへの書き込みを許可
• Google Drive for Desktopでこのフォルダを作業PCにローカル同期
• Claude Code（ローカルセッション）は同期されたローカルパスをそのままRead/Bashで参照できる

手動コピペを挟まずに、claude.ai側の書き込みをClaude Codeが直接読みにいける状態になりました。ネタファイルの命名規則はYYYYMMDD-短い見出し.md、1ネタ1ファイル。処理済み（記事化して下書き投稿まで済んだ）ネタはposted/サブフォルダに移動し、投稿IDと編集URLを追記する運用にしています。

実際に動かしてみると、claude.aiプロジェクト側の相棒がネタファイルを書き出し → Claude Code側が読み取って実機と事実確認（SSH設定やプラグイン名などの整合性チェック）→ 記事化 → wp-autopost.shで下書き投稿 → ネタファイルをposted/に移動、という一連の流れが問題なく機能することを確認できました。

画像を入れたい：featured_imageとinline_images

手持ちの写真や技術記事用のSVG図解を投稿に入れたい、という要望に応えるため、wp-autopost.shにJSON payloadで指定できるオプションを追加しました。

{
  "title": "...",
  "content": "本文...\n\n(プレースホルダ)\n\n続き...",
  "status": "draft",
  "inline_images": [{"placeholder": "(プレースホルダ)", "filename": "photo.jpg", "alt": "..."}]
}

画像ファイルは呼び出し側が事前にscpでjagha上のステージングディレクトリに置いておき、スクリプトが処理後にそのディレクトリを毎回空にする方式です。ここから、いくつかの壁にぶつかりました。

ハマりどころその1：SVGアップロードの権限エラー

SVGをメディアライブラリにアップロードしようとすると、「このファイルタイプをアップロードする権限がありません」というエラーで弾かれました。原因は、SVGアップロードを許可しているsvg-supportプラグイン側の権限チェック（管理者権限相当）を、WP-CLI実行時のユーザーコンテキストが満たしていなかったことです。wp media importに--user=1（WordPress側の管理者ユーザーとして実行する指定。dockerの--userオプションとは別物です）を付けることで解決しました。

ハマりどころその2：権限600問題

Google Driveから取得した画像ファイルは-rw-------（600）権限のことがあり、scpでステージングした後もコンテナ内のwww-data（uid33）から読めずPermission deniedになることがありました。chmod 644を挟むことで解決。地味に踏み抜きやすいポイントなので、ネタ受け渡しの運用ルールにも「元画像は他人も読めるパーミッションで置く」という注記を追加しています。

ハマりどころその3：アイキャッチが全幅バナーになる事件

featured_image（アイキャッチ）を設定した投稿で、画像が記事幅に対して明らかに大きすぎるという指摘を受けました。原因を追うと、このテーマ（catch-base）のアイキャッチ機構はそもそも記事上部に出る全幅バナー用の仕組みで、表示サイズはサイト全体のCustomizer設定（featured_image_size）で決まる作り。現在の設定値full（原寸大）がそのまま反映されていました。本文中のinline画像側にも、実は<img>タグにサイズ指定が一切なく、元写真の解像度（4032×3024など）そのままで埋め込まれていたことも判明。inline側はstyle="max-width:50%; height:auto; display:block; margin:0 auto;"を追加して解決しましたが、アイキャッチについては「サイト全体の表示設定を変える」か「この用途では使わない」かの二択になり、今回は後者を選択。当面featured_imageオプションは使わず、本文中のinline画像だけで運用する方針にしました。

ヒヤリハット：画像の元ファイルを控えなく削除

ネタ処理後、mdファイルはposted/にアーカイブする運用にしていたのですが、ある回で添付写真の元ファイルを控えを残さずrmで消してしまいました。WordPressのメディアライブラリにはアップロード済みで実害はなかったのですが、元ファイルの単体控えが手元から失われる事故です。以降は「添付画像がある場合は画像もposted/にコピーしてから元を削除する」という運用ルールに直し、再発防止を図りました。

「正本」をjagha側に一元化する

ここまでの運用ルール（投稿手順、画像埋め込みのお約束、ネタの受け取り方）が積み上がってくると、次に問題になったのがルールの置き場所です。CLAUDE.mdはClaude Codeの作業ディレクトリとその親を辿って自動読み込まれる仕組みなので、「jagha上に置くだけ」だと、jagha上で直接Claudeを起動した場合にしか自動適用されません。今回のように手元のPCからsshでjaghaを遠隔操作する形だと、jagha側のCLAUDE.mdは自動では読まれない上、複数PCを使い分けているとルールをどこか1箇所にベタ書きした場合、他のPCやセッションでは反映されない・古くなるリスクもあります。

そこで採用したのが、「正本はjagha側の1ファイルに集約し、手元PC側のCLAUDE.mdには『作業前に必ずこれを読みに行け』という指示だけを書く」という方式です。実はこの記事自体も、この仕組みに沿って作業前にjagha側の正本を読みに行った上で書いています。運用ルールを更新したくなったら、jagha側の1ファイルを直すだけでどのPC・どのセッションからでも最新のルールに追従できる、というわけです。

今のところの運用と、残っている宿題

今のところは、Claude Codeが本文と画像を用意してwp-autopost.shで下書き投稿し、管理画面でユーザーがレビュー・仕上げ・公開する、という手動レビュー付きのフローで落ち着いています。status値のバリデーションや、カテゴリ・タグへの対応はまだ手つかずですが、必要になったタイミングで追加していく予定です。この2回に渡ってお届けした自動投稿の仕組み自体、実はこの記事を投稿するのにも使われています。

ここ最近このブログに続けて投稿した「さくらVPSを引っ越す」「さくらVPSを守る」の各シリーズ、実はどちらも下書きの作成から下書き投稿までを毎回Claude Codeにやらせています。今回はその裏側、つまり「Claude Codeがどうやって下書きをWordPressに投げ込んでいるか」という、ブログ運用そのものを支えるインフラの話です。ネタというより資料の色が強い回になりますが、同じようにWP-CLI経由の自動投稿を検討している人の参考になれば、というのが今回の狙いです。

まずは現状把握、WP-CLIは入っていなかった

このWordPress（blog.marochanet.org）はdocker composeで動いていて、db・php-fpm・nginxの3コンテナ構成です。php-fpm側は公式のwordpress:php8.4-fpmイメージで、ドキュメントルートはホスト側のディレクトリをbind mountしています。まず調べたのは、そもそもWP-CLIが使える状態になっているかどうかでした。結果は「未導入」。ホスト（jagha）にもwpバイナリはなく、稼働中のphp-fpmコンテナの中にもありません（公式PHP-FPMイメージにはWP-CLIは同梱されていない仕様です）。ただし面白いことに、公式のwordpress:cliイメージだけは以前pull済みで、docker imagesにちゃっかり残っていました。過去に検討だけして手を付けずに放置していたようです。

都度実行か、常設サービスか

WP-CLIを動かす入れ物のイメージは決まったので、次に考えたのは「そのコンテナをどう常用するか」です。選択肢は大きく2つありました。

• ①都度実行方式：docker run --rmでコマンドの度に使い捨てのコンテナを起動する
• ②常設サービス方式：docker-compose.ymlにwp-cliサービスを追記し、docker compose execで呼び出す

比較した観点は以下の通りです。

観点	①都度実行	②常設サービス
平常時の攻撃面	実行の瞬間だけ存在、終われば消える	DBに常時到達可能な橋頭堡が起動し続ける
SSH都度実行との相性	◎ 1ssh=1完結アクションで監査が明快	△ execする入口が常に開いている
メモリ消費（2GB VPS）	実行中のみ、完了後解放	アイドルでも常時占有
compose変更要否	不要。本番composeに手を入れずに済む	追記が必要（破壊的変更に準じる）

結論は①都度実行方式。理由は、SSH経由で1コマンド＝1完結アクションという運用モデルと相性がいいこと、メモリ2GBのVPSで常駐コンテナを増やしたくないこと、そして慎重に育ててきた本番のdocker-compose.ymlに触れずに済むこと、の3つです。

実装で地味に嵌った3点

叩き台のコマンドはこんな形でした。

ssh jagha "sudo docker run --rm --network shared \
  -v /path/to/blog:/var/www/html --user www-data \
  -e WORDPRESS_DB_HOST=db -e WORDPRESS_DB_USER=webdata \
  -e WORDPRESS_DB_PASSWORD=*** -e WORDPRESS_DB_NAME=wpdata \
  wordpress:cli wp post create --post_title='...' --post_status=publish --path=/var/www/html"

ここから~/bin/wp-autopost.shというラッパースクリプトに仕立てる過程で、いくつか地味な壁がありました。

• 本文・タイトルをssh引数で渡すとクォート崩れやインジェクションのリスクがあるため、stdinでJSONを渡す方式に変更（複数行の本文にも安全に対応できる）
• ホスト側のblog/ディレクトリはuid=33（www-data）所有だが、wordpress:cliイメージ内部のwww-dataはuid=82（Alpine系）でホストとズレている。--user www-dataではなく--user 33:33を明示指定することで権限不一致を回避した
• wp-config.phpはDB接続情報を環境変数から読む実装のため、コンテナには--env-fileでDB接続情報を渡す必要がある（wp-config.php自体に直書きはされていない）

最終的な呼び出し方はこうなりました。

cat <<'EOF' | ssh jagha 'bin/wp-autopost.sh'
{"title": "タイトル", "content": "本文\n複数行もOK", "status": "draft"}
EOF

標準出力に返るのは作成された投稿IDのみ。処理ログはすべてstderrに逃がしているので、呼び出し側は投稿IDだけを綺麗に受け取れます。あわせて投稿者（post_author）の扱いも決めました。WordPress側にclaudeという専用ユーザー（author権限）を作成し、スクリプトのデフォルト値として設定。JSON側でauthorキーを指定すれば上書きもできます。これでどの投稿がClaude作なのかが管理画面上でも一目瞭然になりました。

できあがった運用フロー

「Claude Codeが本文を作成 → SSH経由でwp-autopost.shに下書き投稿 → 管理画面でユーザーがレビュー・仕上げ・公開」という一連の流れがこれで機能するようになりました。ちなみにjaghaの~/.ssh/authorized_keysには元々14個の鍵（複数PC・複数クライアント分）が登録済みだったため、スクリプトと接続情報をjagha側だけに置く設計にしたことで、追加のSSH鍵作業なしでどのPCからでもこの仕組みを使えるようになったのは嬉しい誤算でした。

次回は、この「本文を作る」部分の周辺の話です。ネタをどうClaude Codeに渡すか、そして画像を投稿に混ぜようとして何度も転んだ顛末をお届けします。