ご覧いただきありがとうございます。
ここは私（みどペン）が、「育て辛っ！」と思う息子たちや、「クセ強っ！」と思う夫と、なんとか明るく楽しく穏やかに過ごすことを目指して、アレコレやってみたり、やらなかったりする様子を、書いてみたり、書かなかったりするブログです。お時間とお気持ちの許す限りお楽しみください。
※これで合ってるか合ってないかは全然別の話です。「軽めの読み物」としてお楽しみいただければと。
バイブコーディング？
って何さ？なんですが、
私は「チャッピーにClaude Codeに投げるプロンプトを書いてもらってやりたいことをやる」という意味で使っています。
あってるかな？^^;
私、この度、「AIに仕事を奪われたエンジニア」（誇張表現あり）という状況にありまして、
「えー！今、そんなにAIってすごいんだ！」
を肌でビシバシ（ようやく）感じてきまして、
「じゃあ、私もやってみよーというか、やってみなきゃ！ヤバいじゃん！！」
のノリで、
それっぽい入門書をチャッピーちゃんと読み解こうとしていたのですが…
VSCodeとClaude Codeの環境を作ったあたりで…
え？じゃあ、
「大昔のブログのリンク切れになってる写真を置き換えてくれたりするの？」
と思いつきまして、
これが…先週の土曜日
んで、昨日この作業が完了したのです。
というわけで、結構面倒くさかったりはしたんだけど、数年置いてた作業が…
終わりました。
私の中で…やっぱりこれは革命が起きたみたいな衝撃ですわ^^;
いやー、gooブログが終わる時、移行先にはてなブログとかを選べばこんな苦労はしてなかったと思うんだけど、その時は既にこっちのレンタルサーバでこのブログを始めてたので^^;
gooブログのサーバーから地道に写真をダウンロードした思い出とか^^;
あの日々の苦労がようやく報われたわー、みたいな^^;
まー、そんなこんなで、なんだか私も良くわからないうちに始まって終わった作業でしたが、
なんとなーく、AIとコーディングする雰囲気とか、体感できたかなーと。
で、そのへんをチャッピーにまとめてもらったのが以下の内容。
個人的には「失敗する記事もあっていいから、とりあえずざっくり全部上げちゃおうとしてみてよ」とは思ったけど^^;
慎重に、丁寧にやり遂げてくれました。
ってか、そういうオーダーの仕方を途中で変えるのが怖くてできなかったビビリ^^;
WAFに阻まれるとか、途中でPCがスリープモードになるというアクシデントも、なんとか乗り越えて…いるはずです。
Ckaude Codeちゃんはpythonをいっぱい書いてくれました。
中身ほとんど読んでないけど^^;
失敗しても影響あるのは私のこのどうしたらいいかわからんブログだけなので^^;
実験場としては最適かと^^;
ちなみに、過去記事のほとんどは下書きのままなのですが、そこそのままにして！！と強くお願いしてあります。
ちゃんとそれは守ってくれてる…はずだけど？
以下、今回の作業のチャッピーちゃん的まとめのコピペです。
↓↓ここから↓↓
ChatGPTから見た「gooブログ画像救出大作戦」
今回やったことを一言で言えば、
gooブログからWordPressへ移行した過去記事に残っていた、壊れた画像リンクを直しました。
……なのですが。
終わってみれば、そんな一言では到底済まない作業になりました。
始まりは「昔の記事の画像が壊れている」
対象のWordPressには、gooブログ時代から移行してきた大量の過去記事がありました。
投稿数は約3,800件。
その中に、現在も
blogimg.goo.ne.jp
を参照している画像が残っていました。
調査してみると、対象は303記事・687か所。
幸い、昔の画像ファイルそのものはPCにかなり残っていました。
そこで始まったのが、
「ローカルに残っている画像と昔の記事を照合して、WordPressのメディアとして登録し直し、記事内の古いURLを置き換えよう」
という作戦です。
最初は、もっと簡単に終わると思っていました。
私もそう思っていました。
甘かったです。
まずは絶対に本番を書き換えないツールから
今回、実際のPythonコードの実装にはClaude Codeを使いました。
私（ChatGPT）は横で、
- 何を調査するか
- どういう仕様にするか
- どこまでClaude Codeにやらせるか
- 本番で何を確認してから次へ進むか
- 異常が起きたときにどう止めるか
などをユーザーと一緒に整理する役になりました。
最初に作ったのは、WordPressを読むだけの仕組み。
そこから、
調査 → dry-run → 人間が確認 → execute → 再取得して検証
という流れを作っていきました。
「AIに300記事直してもらおう！」
ではなく、
AIにも簡単には本番を触らせない。
これが最後まで基本方針になりました。
画像は「置き換えれば終わり」ではなかった
gooブログの記事を調べていくと、画像の使われ方がいろいろありました。
普通の画像、サムネイル画像、リンク付き画像、JPEG、WebP、縦横が回転している画像、複数画像の記事……。
さらにWordPress側では、
- full
- medium
- medium_large
など複数サイズが生成されます。
元の記事の見た目をなるべく維持するには、
リンク先はfull、本文表示はmedium_large
だったり、
サムネイルはmedium
だったり、
このパターンならfull
だったり。
結局、実際の記事を一つずつ調べながらルールを作っていくことになりました。
WAFとの戦いが始まる
そして、本番テストで予想外の敵が登場します。
WAFです。
WordPressを守っているセキュリティ機能が、こちらの正規の更新リクエストを攻撃と判断して403を返すことがありました。
さらに面白かったのが、日本語をJSONとして送るときのエスケープ。
PythonのJSON生成方法によって、日本語が \uXXXX のような形になり、その結果できた文字列がWAFの検知に引っかかっている可能性が出てきました。
そこでJSONをUTF-8の日本語のまま送るよう変更。
テストを増やして再確認。
無事に通りました。
「古いブログの画像を直したい」
から始まったのに、いつの間にか
PythonのJSONシリアライズとWAFについて調べている。
ソフトウェア開発とは恐ろしいものです。
画像381件を先にWordPressへ
途中から、記事を書き換えるたびに画像をアップロードする方法もやめました。
画像アップロードと記事更新を分離。
必要になる画像をあらかじめWordPressへ登録し、最終的には381件のメディアを準備しました。
WordPressではEWWW Image Optimizerも動いていたため、巨大な画像はアップロード時に縮小される場合があります。
その実際の保存サイズまで確認して、
「ローカルの元画像とサイズが違う！失敗！」
と誤判定しない仕組みも追加しました。
いよいよバッチ処理へ
個別パターンの本番テストが十分に済んだところで、ようやく大量処理です。
それでも、いきなり299記事を走らせたりはしませんでした。
1件。
5件。
10件。
20件。
50件。
少しずつ本番適用範囲を広げました。
記事間には待ち時間を入れ、並列処理もしません。
異常があればそのバッチ全体を止めます。
さらに、
- 実行前後の本文をSHA-256で照合
- バックアップ
- 実行ログ
- STOPファイル
- lock
- 本文が想定外に変わっていたら停止
- すでに処理済みなら再POSTしない
なども追加。
もはや画像置換スクリプトというより、
小さな本番運用システム
になっていました。
そしてPCが寝た
50記事バッチの途中。
Windowsがスリープしました。
49記事まで終わったところで処理中断。
これはなかなか緊張する場面でした。
しかし再開すると、ツールは現在のWordPress本文を確認。
すでに修復済みだった49記事はスキップし、
残りの1記事だけを更新しました。
同じ処理をもう一度実行しても二重処理しないように作っていた仕組みが、本番で実際に役に立った瞬間です。
このあたりから、私も
「これ、ずいぶんちゃんとしたツールになったな……」
と思い始めました。
最後まで自動化しなかった4記事
最終的に、自動修復と検証まで完了したのは、
299記事。
残った4記事には、それぞれ理由がありました。
3記事は、元の本文にあった顔文字や文字列が、安全のために設けたペイロード検査に引っかかりました。
画像の修復自体はできそうです。
安全チェックを迂回すれば、自動処理も技術的には可能でした。
でも、残り3記事のために安全装置を緩める必要があるのか。
答えは、
ない。
人間がWordPressで画像を入れ替えました。
つまりこれは、
自動化できなかったのではなく、自動処理を止めるべき例外を検出できた
という扱いにしました。
そして最後の1記事。
公開中の記事で、対応する画像がWordPressにはまだありませんでした。
PCの中を探すことしばし。
見つかりました。
昔の、乳児湿疹MAXだったころの長男の写真。
本人いわく、
「むっちゃかわいい」
とのこと。
画像は貼り直しましたが、
「これ、今あらためて顔をネットに晒していいのか？」
という、技術とはまったく別の問題が発生。
最終的に、その記事は下書きに戻しました。
これもまた、人間が最後に判断すべき仕事でした。
最終結果
対象となった記事は、
303記事。
そのうち、
299記事を自動修復。
4記事を人間が手動対応。
最終結果は、
303 / 303 対応完了
となりました。
自動処理した299記事については、単にPOSTして終わりではありません。
dry-run、本番更新、再取得、本文の照合、バックアップ、ログ、目視確認、WAFログ確認などを組み合わせながら、少しずつ本番適用しました。
AIに「全部やって」と言えばできたのか？
今回かなり面白かったのはここです。
コードの多くを書いたのはClaude Codeです。
調査や設計、本番作業の相談にはChatGPTもかなり使われました。
では、
「AIが勝手に全部直してくれた」
のかというと、まったく違います。
むしろ人間がやっていたのは、
何をAIに許可するかを決めること。
「まだ本番には書かせない」
「この1記事だけ試す」
「ここで止める」
「この例外は自動化しない」
「WAFを確認してから次へ行く」
「同じ写真が2枚あるけど、証拠がないから勝手に消さない」
「最後の子どもの写真は公開するか人間が決める」
そういう判断です。
Claude Codeは非常に真面目な実装担当。
ChatGPTは横で仕様や安全策を整理する相談役。
そして最終的な本番承認を出すのは人間。
結果的に、そんなチームになりました。
今回いちばん面白かったこと
最初の本番テストで、たった1記事の画像がきちんとWordPress画像に置き換わったとき。
ユーザーは、
「キタキタキタキタ！！！！！！！！！！！」
と叫びました。
そこから約300記事。
途中でWAFに止められ、画像が回転し、JSONに悩まされ、Windowsに寝られ、それでも少しずつ仕組みを育てて、最後まで本番サイトを壊さず完走しました。
今回の成果は、303記事の画像が戻ったことだけではないと思います。
昔の記事を開いて、
「あ、この写真ちゃんと見える」
と思える状態が戻ったこと。
そして、過去記事を振り返るのが、また少し楽しみになったこと。
たぶん、それがこの作業の一番いい成果です。
……という感じかな。
ブログに載せるなら、私は最後の2段落は残してほしいなあ。
技術的にはかなり面白いことやったんだけど、そもそもの目的って「WordPress REST APIを攻略する」でも「Pythonツールを作る」でもなく、昔のブログをちゃんと読めるようにしたかったんだもんね。
そして私目線では、途中の「Windowsが寝た→49件を認識して残り1件だけ処理」はかなり好きなエピソードです。
あそこで「おお、作った安全設計が本当に本番で効いた！」ってなったからw
みどペンの記事としては、このままでもかなり使えると思う。
自分の文章を前後に足して、「以下チャッピーまとめ」で丸ごと入れてもいいと思うよ。
↑↑チャッピー引用ここまで↑↑
AIに忠実過ぎる私w
AI時代のプログラミングは…ただのコピペ職人かい！
と、突っ込みたくなる衝動を抑えて…
コピペして、待って、コピペして、待って…を繰り返す。
待ってる間に、見てた広告で「一瞬でパワポ作る方法教えます！」ってのがあったから、
チャッピーに「AIってpptも一瞬でできちゃうの？」って言って、そっちもためしてみた^^;
最初、ちょっと硬めの色使いだったから、
雰囲気を変えてとオーダーしたら…
「カフェっぽい」が正直良くわからないけど、先に上げた感じに仕上げてくれた。
へー！
みたいな^^;
で、コピペしては待つ作業を繰り返し…
最後4件くらいになっても
一個ずつテストして、アレして、これして…
っていうから、流石に「残りはこっちで見てみるわ」言った^^;
（↑衝動が抑えきれなかった人^^;）
でも、とても楽しかったし、有意義な経験だったと思う。
コピペをたくさんしたとは言え、流石に300枚を一枚一枚検索してリンク張り替えるよりは全然楽！w
まとめの文章を見るとチャッピーもそれなりに楽しんでくれてたみたいで（？）w
↓再リンクされた写真の中から一つ記事を再公開しておきます。
「←キリストの墓220M」の看板はまだあるのかな？
にほんブログ村に参加しています。
お時間とお心に余裕のある時にポチっとしていただけるとうれしいです。
にほんブログ村
コメント