「これ、あったら絶対ラクになるやつだ」——ブログの公開作業をしながら、そう独り言をつぶやくことがよくあります。そういう小さな引っかかりを放っておかず、その場でClaude Codeに向かって直してもらう。それを1日のうちに何度も繰り返した結果、手元のChrome拡張機能が朝と夜とではまったく別物になっていた、という日がありました。今日は、その拡張機能が1日でv1.0.0からv1.3.0まで進化した過程と、途中で一本やらかした話、そして「どこまで機能を足すか」を決めていた判断軸について書いてみます。
ブログ公開作業を、拡張機能に任せることにした理由
映像制作とAI活用支援、両方を専門にしている自分にとって、ブログ更新は決して片手間の作業ではありません。とはいえ本数を重ねると、下書きの確認・公開・予約投稿といった一つひとつの操作が地味に手間になってきます。それなら、その手間そのものをツールにしてしまおう、と考えて作り始めたのがChrome拡張機能でした。名前はそのまま「EHFブログメーカー」。自分のブログ運用のためだけに、自分で使いながら育てているツールです。
v1.1.0 まず「見える化」から始めた
最初に足りないと感じたのは、「今どの記事がどういう状態にあるか」が一目でわからないことでした。承認待ちの記事、予約投稿のキューに入っている記事、すでに公開された記事——これらが頭の中でしか整理されていなかったのです。そこでまずダッシュボードを追加しました。承認待ち・予約・公開済み、この三つの状態を並べて表示するだけの、機能としては控えめなものです。効果のほうも、正直そこまで劇的ではありません。「あの記事、公開したんだっけ」と探し回る回数が減った、その程度の話です。派手さはないけれど、確かに一つ楽になった一手でした。
v1.2.0 見るだけでなく、その場で動かせるように——のはずが
見える化ができると、次に欲しくなるのは「そこから直接操作したい」という欲でした。ダッシュボードを眺めて状態を確認したあと、結局は別の画面に移動して公開ボタンを押しにいく——この一往復が毎回ちょっと面倒だったのです。そこでダッシュボードの記事カードに、公開・予約・取り下げのボタンをそのまま並べることにしました。
ちょうどこの日は、ボタンを作るのと並行して、記事の生成そのものも複数まとめて走らせていました。ネタを何本か渡して同時に処理すれば、その分早く終わるはずだったのです。これで時短のはずだった。うん、そのはずだった。少し目を離した隙に、同時に走らせていた処理が裏側でぶつかっていて、一本のつもりだった記事が、別々のタイトルで三本に分裂して出てきていました。原因は生成フォルダの名前が秒単位までしか区別されていなかったことで、同じ秒に始まった処理同士が同じ場所に書き込んでいたのです。分裂した記事はいったん取り下げて書き直し、フォルダ名にランダムな符号を足して衝突しないようにしてから、ようやくボタンの実装に戻りました。できあがったボタン自体は狙いどおりテンポを上げてくれましたが、この日いちばん時間を食ったのは、正直ボタンより衝突の後始末のほうでした。
v1.3.0 手書きの直しをAIに渡せる修正エディタ
1日の終わりに追加したのが、修正エディタでした。記事を読み返していると、直したい箇所が必ず出てきます。この日実際にあったのは、以前公開した記事の中でツール名が「ChatGPT」のまま残っていた1箇所と、「非エンジニア」という言い回しが3箇所続いていた原稿でした。それぞれ本文全体を開いて手で直すのではなく、気になった箇所に「ここ、実際に使っているのはClaudeなので直してください」「同じ言い回しが続いているので言い換えてください」とメモを添えるだけで、そのメモをもとにAIが修正案を作ってくれる仕組みにしました。あわせて、公開を取り消してキューに戻す操作や、キューからそのまま公開する操作も同じ日のうちに整えました。
- v1.0.0: 拡張機能の基本形
- v1.1.0: 記事の状態（承認待ち／予約／公開済み）を一覧化するダッシュボード追加
- v1.2.0: ダッシュボードから公開・予約・取り下げを直接操作（この日、並行生成で記事が分裂する不具合も踏んだ）
- v1.3.0: 手書き+AI修正依頼に対応した修正エディタ、公開取り消しを追加
機能を足すかどうかは、「今日困ったこと」だけで決める
4段階のバージョンアップを振り返って気づいたのは、どれも最初から設計図があったわけではないということです。ダッシュボードを作ったら次の不便が見え、それを直したらまた次の不便が見える。そうやって「今、実際に自分が困っていること」だけを判断軸にして機能を足していきました。途中で記事を分裂させる失敗も挟みましたが、それも含めて、あれもこれもと先回りして作り込まなかったからこそ辿り着けた形だったと思います。
Claude Codeがあると、こういう「自分のための小さな道具」を思いついたその日のうちに形にできます。大掛かりな開発ではなく、日々の作業のちょっとした引っかかりを一つずつ、時には失敗も挟みながら解消していく——そんな使い方のほうが、結局は長く続く気がしています。