AIエージェントを使い始めると、次に迷うのは「どこまで実行させるか」だった。
書かせるだけなら怖くない。
でも、投稿・DB登録・CSS変更まで任せると、話が変わる。
Claude Codeでブログ運営を仕組み化してきて、企画と判断を担うhenshucho、本文を書くwriter、公開前チェックを担うcontent_managerという役割まで揃った。
AIに全部やらせれば、もっと早く回せると思っていた時期がある。
構成を決めるのも、本文を書くのも、WordPressに投稿するのも、DBに記録するのも、全部同じAIにやらせればいい。
そう思っていた。
でも、実際にそこまで任せる前に、怖くなった。
AIに全部任せれば楽になる、と思っていた
henshuchoが発注書を作り、writerが本文を書き、content_managerが下書きを保存する。
ここまでは仕組みになっていた。
残っていたのは、その先だった。
WordPress投稿。
articles.dbへの登録。
目次への反映。
CSSの調整。
このあたりも、全部AIにやらせれば早い。
最初はそう考えていた。
同じAIが「決めて」「書いて」「投稿して」「記録して」まで一気にやれば、俺は確認するだけでいい。
効率だけを見れば、正しい発想だった。
でも、判断と実行が同じAIの中にあるのは怖かった
今日、prompt-generator.htmlという固定ページを直す作業があった。
ローカルのHTMLファイルを修正した。
でも、公開ページには反映されなかった。
公開ページの実体は、ローカルのファイルではなかった。
WordPressの固定ページID 37だった。
ここでもし、AIが「直したから公開ページも直っているはず」と判断して次の作業に進んでいたら、俺は気づかないまま放置していた。
CSSの調整も同じだった。
直したいスタイルをそのままページに貼れば、サイト全体のCSSに影響する可能性があった。
1ページのための修正のつもりが、他の全ページの見た目を変えてしまうかもしれなかった。
excerptの設定も同じだ。
excerpt、要するにSNSでシェアされたときに表示される説明文を設定しないままだと、本文中の生のCSSコードをそのまま拾ってしまう可能性があった。
これは「本文を書くAIに任せる作業ではない」と感じた瞬間だった。
一つひとつは小さい。
でも、どれも「勝手に進めたら、気づかないうちに公開ページや他のページに影響が出る」作業だった。
書く判断と、実行する操作が、同じAIの中に同居しているのが怖かった。
だから、plan.md → GO → jissou に分けた
以前の記事で、記事を書く前に発注書という設計書を作る、という話を書いた。
同じ考え方を、公開作業にも当てはめた。
まず、何をどう変えるかをplan.mdに書く。
対象・現状・変更案・影響範囲・ロールバック手順を、実行する前に文章にする。
次に、俺がそれを読んでGOを出す。
GOが出るまで、何も変わらない。
plan.md → GO → jissou。
実行前に承認フローを挟んだ。
GOが出たあとだけ、実装担当、つまりjissouが、plan.mdの内容どおりに手を動かす。
提案するAIと、実行するAIを分けた。
決める人と、手を動かす人を、役割として切り分けた。
jissouに持たせた権限、持たせなかった権限
henshuchoは観測と提案までしかしない。
WordPressの本文・DB・CSSを直接変更する権限は持たせていない。
jissouには、承認済みのplan.mdどおりに実行する権限だけを持たせた。
plan.mdに書かれていない変更は、jissouもやらない。
読み取りは自由にさせている。
articles.dbの参照、WordPressの取得（GET）、ファイルの読み込み。
ここは止める必要がない。
書き込みは、GOが出たplan.mdの範囲だけに絞った。
POST・PUT・DELETEのような書き込み系の操作は、plan.mdにない限り実行しない。
バックアップも、実行の前提にした。
DBを触る前にバックアップを取る。
本文を変える前に、変更前の状態を保存する。
戻せない変更は、原則やらない。
分けたことで、止まれるようになった
判断と実行を分けてから、変わったことがある。
止められるようになった。
plan.mdの段階で「これは違う」と気づけば、実行の前に止められる。
実行が終わったあとで気づくのと、実行の前に気づくのでは、意味が全く違う。
戻せるようにもなった。
バックアップとbefore保存を前提にしたから、実行したあとでも元に戻せる。
便利になったわけではない。
むしろ、GOを出す手間は増えた。
でも、勝手に進まれる怖さがなくなった。
提案書を読んで、GOを出す場所が、俺の手元に残っている。
次は、この仕組みを別のブログにも広げる
判断と実行を分ける仕組みは、blog-sekkei一つのために作ったわけではない。
ずみ株式会社には、blog-sekkei以外にもブログがある。
このplan.md → GO → jissouの仕組みを、他のクライアントにも同じ形で使いたい。
ただし、ブログが増えれば、clientsフォルダの中身も増える。
AIが別のブログの作業範囲を混ぜてしまわないか、という新しい心配が出てくる。
その話は、次の記事に書く。
コメント