このブログの記事は、実はすでにいくつかのAIが分担して作られています。
- 記事本文:Claude(チャット版)に整理してもらい、そこに「今日のひとこと」だけ自分の言葉で加えている
- アイキャッチ画像:記事の内容をChatGPTに渡して生成を依頼
- 今回のテーマ:記事とアイキャッチ画像をWordPressに下書き投稿するところまでを自動化する仕組みを、Claude Codeにお願いして作ってもらった
今回のポイントは、「自分でコードを書いた」のではなく、「プログラミング未経験の自分が、Claude Codeに”こういう仕組みが欲しい”と伝えるだけで、実際に動くツールが出来上がった」という体験そのものです。
かかった時間
正確なストップウォッチ計測はしていませんが、ファイルの更新時刻から辿ると、大きく2回の作業に分かれていました。
- 1回目(仕組みの構築・初回テスト):30〜40分程度
- 2回目(実記事投稿・機能追加):40〜50分程度
要件のヒアリングやレビューなど記録に残っていない時間もあるため、実態としては1〜2時間程度というのが近い感覚です。コードを書く時間がほぼゼロだったことを考えると、かなり早いペースだったと思います。
使った技術要素
自分でコードを書いたわけではなく、Claude Codeとの会話の中で「こういう動きにしてほしい」「ここは危ないから確認を挟みたい」といったやり取りを重ねる中で、以下の技術が使われることになりました(すべてClaude Codeが選定・実装)。
- 言語:Python
- 主なライブラリ:
requests(WordPressとの通信)、markdown(Markdown文章をHTMLに変換)、python-dotenv(パスワードなどの秘密情報を安全に読み込む) - 通信先:WordPressの「REST API」という、プログラムから記事の投稿・編集ができる窓口
- 認証方式:WordPressの「アプリケーションパスワード」機能。普段ログインに使うパスワードとは別に、アプリ専用の合鍵のようなものを発行できる仕組みで、万が一漏れても個別に無効化できる
大まかな処理の流れ(これも全部Claude Codeが設計)
- 設定ファイルを読み込み、通信が暗号化されているかなどの安全チェック
- 記事ファイル・画像ファイルの存在確認、フォーマットの事前チェック
- カテゴリー名をWordPress内部の管理番号に変換
- 同じ番号の記事がすでに投稿されていないか重複チェック
- 投稿内容を画面に表示し、人が「OK」を押すまで待つ
- 画像をアップロードし、代替テキストを設定
- 記事本文・タイトル・カテゴリー・画像をまとめて送信し、「下書き」として保存
- 完了後、管理画面で確認できるURLを表示
自分がやったことは、「こういう機能が欲しい」と伝える、実際に動かして「ここが変だ」とフィードバックする、最後に人間の目で下書きを確認する、という3つだけです。コードは一行も書いていません。
つまずいたポイント
つまずいた、というより「Claude Codeと一緒に試行錯誤しながら発見した」という表現の方が近いかもしれません。
- 正しいはずの通信方法が拒否された:WordPressの仕様通り「PATCH」という更新方法で通信したところ、レンタルサーバー側のセキュリティ機能(WAF)にブロックされました。「POST」という別の方法に変えたら解決。
- 「画像が表示されない」と思ったら実は正常だった:テスト用の1ピクセルしかないダミー画像でサムネイルが生成されず、一瞬「バグでは」と焦りましたが、単に画像が小さすぎただけでした。
- セキュリティの実例コードがブロックされる:SQLインジェクションやXSSの攻撃コード例を記事に書こうとすると、サーバーの警備(WAF)に「攻撃だ」と誤解されてブロックされることが判明しました。
- 下書きの記事が検索に出てこなかった:重複チェック機能を作りましたが、WordPressの検索は標準だと「公開済み」の記事しか対象にしないため、下書きが最初は検索に引っかかりませんでした。
いずれも、自分一人では原因すら想像がつかなかったであろう問題です。Claude Codeが実際にAPIを叩いて検証し、原因を特定してくれました。
工夫した点・こだわった点
- 必ず「下書き」止まりにした:いきなり公開まで自動化せず、必ず自分の目で最終確認してから手動で公開する運用にしました。これは自分から最初に伝えた要望です。
- 通信の暗号化を必須にした/投稿前に内容確認を挟んだ/記事フォーマットの自動チェックを入れた/コメント欄は最初から閉じる設定にした:これらは主にClaude Code側から「事故防止のためこうしたほうがいい」と提案を受け、採用したものです。
- セキュリティは「緩める」のではなく「書き方を変える」で対応:WAFのブロック問題が見つかったとき、サーバー側の警備を緩める案も一瞬出ましたが、セキュリティを生業にしている立場としてそれは選びませんでした。ここは自分の専門性で判断した部分です。
- AI2体によるダブルチェック体制:機能を追加するたびに、「シニアエンジニア役」「UI/UXデザイナー役」という視点の異なる2つのAIにレビューさせ、両方が納得するまで直す、というプロセスを自分から指示して仕組み化しました。
今回の作業を通しての気づき・学び
- プログラミングスキルがなくても、動くツールが作れる:今回、自分は一行もコードを書いていません。「こういうものが欲しい」と伝え、実際に動かした結果を見て「ここが気になる」とフィードバックし、最後は自分の目で成果物を確認する。この3つの役割さえ果たせば、Claude Codeが設計・実装・テストまで一通りやってくれます。これは今回の一番の発見であり、この記事で一番伝えたいことでもあります。
- 「作る」の中身が変わった:これまで「自動化ツールを作る」というと、自分でプログラミングを学んで書くことを想像していましたが、今回体験したのは「AIに要件を伝え、動かして確認し、判断を下す」という全く別の関わり方でした。非エンジニアでも、意思決定者としてものづくりに参加できる時代になっていると感じます。
- 実際に動かして初めて見つかる問題がある:「画像が表示されない」「通信方法が拒否される」といった問題は、事前の設計段階では気づきにくく、実際に動かしてみて初めて発覚しました。これはAIが相手でも変わらない、ものづくりの基本だと再確認しました。
- セキュリティは”守りを緩める”のではなく”攻め方(やり方)を変える”もの:壁(WAF)にぶつかったとき、「壁を低くする」のではなく「壁を壊さない歩き方を探す」という判断を、AIに提案されるだけでなく自分の専門性で下せたのは、今回のプロセスの中で一番自分らしさが出た場面でした。
