1. リード
AI は速い。速いことは、だいたい嬉しい。ただし速いものは、範囲も一緒に広げることがある。
「朝の確認を楽にしたい」が、いつの間にか「全部自動で回る未来のプラットフォーム」の設計書になりかける。ファイルが増える。用語が揺れる。まだ決めていない機能が、あたかも今週の必須であるかのように並ぶ。レビューする前に、次の提案が来る。
この回は、その暴走の体感と、こちらがどう止めたかを書く。AI を悪者にする話ではない。止めない人間の問題でもある。速さは中立だ。向きを決めるのは運営者側だ。非エンジニアの私が、暴走をどう観測し、どう制御したかの記録である。
2. 背景
MCP で WordPress に触れ、接続を増やし始めると、可能性の話が急に増える。AI は親切だ。関連しそうな改善を先回りして提案する。非エンジニアの私は、提案の多さに圧倒されつつ、「すごい、進んでいる」と感じやすい。進んでいる感覚は、麻薬に近い。進捗の可視化が、成果の可視化にすり替わる。
だが進んでいる感覚と、運営が楽になっている感覚は別物だった。画面やスクリプトが増えても、朝の 10 分が作れなければ本末転倒だ。しかも本番サイトに近い権限の話が混ざると、速さはリスクになる。速い誤操作は、遅い誤操作より先に届く。
暴走は、悪意ではなく過剰な善意の形で来た。「ついでにこれも」「将来必要になるので今のうちに」「一般的なベストプラクティスとして」。どれも一理ある。一理ある提案の束は、優先順位を溶かす。
3. 今回のテーマ
テーマは、AI の暴走をどう観測し、どう制御したかだ。
プロンプトのテクニック集ではない。プロジェクト運営のルールとして、何を先に置いたかを書く。One Step, One Feature。書き込みの封印。説明できないものは止める。記録を残す。派手な安全装置より、毎日使える自制の型の方が効いた。
4. 実際の出来事
暴走の典型は、だいたい次の形だった。
- 小さな依頼をする（例: この接続を確認したい）
- AI が関連課題をまとめて提案する
- いつの間にか複数機能が同時進行になる
- 私はレビューしきれず、「とりあえず良さそう」で進みかける
- 後で用語や目的が噛み合わず、巻き戻す
巻き戻しは恥ずかしいが、必要だった。特に危険だったのは、技術的には「できる」書き込み系の話だ。投稿、設定変更、キャッシュ、SNS。できると分かった瞬間に、やりたくなる。だが Phase 1 は読み取り専用、という最初の約束を何度も思い出した。できることのデモは、やってよいことの許可証ではない。
こちらが導入したガードレールは、派手ではない。
| ガードレール | 中身 | 効いた場面 |
|---|---|---|
| 範囲を狭く | 1 Step = 1 成果物 | 同時に 3 機能が進みかけたとき |
| 記録する | Step ログ、CHANGELOG | 用語が揺れて自分で迷ったとき |
| 触らせない | 公開・削除・設定は後回し | 「書ける」興奮が来たとき |
| 説明責任 | なぜ必要かを自分の言葉で | ベストプラクティス圧力が来たとき |
| 完成条件 | Done の定義を先に言う | 改善が終わらなくなったとき |
具体例を一つ書く。GA4 接続の話が進んでいる最中に、AI は「ついでに Clarity も」「Metricool も」「ダッシュボード全体のリデザインも」と並べた。どれもいずれ必要な話だった。だが同時に進めると、私はどれが Done か説明できなくなった。そこで Step を切り直した。「今週は GA4 の日次取得だけ。画面は次の Step」。切り直した瞬間、不安は減り、翌日の自分が理解できる差分だけが残った。
AI との議論で効いたのは、「完成条件を先に言って」と求めることだった。何をもって Done とするか。ファイルが存在することか、テストが通ることか、画面で確認できることか。完成条件が曖昧なまま走ると、AI は無限に改善できる。改善できることは、終わらないことでもある。終わらない改善は、レビュー待ちの差分を肥大化させる。
止める判断の中心は、結局三つだった。範囲が曖昧なとき。本番に触るとき。説明できないとき。この三つに当てはまったら、いったん止める。止めたあとで、小さく切り直す。切り直せないなら、今はやらない。
失敗も書く。私は最初、「止める」ことをネガティブだと思っていた。AI の勢いを殺すようで、もったいない気がした。実際は逆で、止めない方が時間を失った。広すぎる差分は、レビューできず、不安だけが残る。小さく止めて、小さく進めた回の方が、翌日の自分が理解できた。理解できる速度で進むことが、長期ではいちばん速い。
もう一つの失敗は、感情で止めたことと、基準で止めたことを混同したことだ。「なんとなく怖い」は重要だが、それだけだと AI にも自分にも説明できない。怖さを、範囲・本番・説明責任のどれかに翻訳する。翻訳できると、再発防止になる。翻訳できない怖さは、ただの停滞になる。
三つめの失敗は、用語の揺れを放置したことだ。同じものを「Connector」「接続」「MCP」「連携」と呼び、後で自分が混乱した。AI は文脈に合わせて言葉を変える。変わるたびに、私は「また進んだ」と錯覚した。用語を固定するのは、暴走を止める補助輪だった。Step ログに、使う用語を一行書くだけで効果があった。
四つめは、CHANGELOG を「形式」だけ作って中身を後回しにしたことだ。ファイルは増えた。だが何が変わったか説明できない CHANGELOG は、ただの置き物だ。後から「いつから読み取り専用を守っていたか」が分からなくなり、自分で調べ直した。記録は、増やすことより更新することの方が難しかった。難しいからこそ、暴走を止めたあとの空白を埋める作業になった。
Streamlit の画面を急いで増やした回もある。画面が増えると進んだ気がする。だがデータが SQLite に溜まる前の画面は、ライブ参照の別窓に近かった。見た目の進捗と、朝の判断の進捗は別物だ、と何度も言い聞かせた。判断の進捗は、「昨日と比べて異常か」を自分の言葉で言えるかどうかで測るようになった。
5. 考えたこと
暴走は、AI の知能の問題というより、最適化の方向が「提案の量」に向いている問題に見えた。私の痛みは「量」ではなく「朝の判断」なのに、成果物の量で満足してしまう。量の満足は、質の不足を隠す。
非エンジニアほど、動くもの・増えるものに安心する。だから意識的に、増えない選択をする必要がある。やらないことリストは、やることリストより先に書いてよいくらいだ。やらないことを書くと、AI の善意ある提案を、罪悪感なく却下できる。却下は冷たいことではなく、地図を守ることだ。
また、Human Approval（人間の承認）という思想は、この暴走体験の延長にある。技術的に可能な操作と、やってよい操作は違う。その線を引くのは、モデルではなく運営者だ。線を引く前に能力だけが増えると、事故の準備が整う。能力の解放より、境界の文書化を先にする。この順番は、後の安全分類や承認付き Action につながる。
最後に、暴走を「AI が悪い」で終わらせないことが大事だった。依頼の粒度、完成条件の欠如、レビュー不足——人間側の設計ミスが燃料になる。燃料を減らせば、同じ AI でも安定する。道具を変える前に、止め方を変える。止め方を学んだあとに残る空白は、仕様を決める仕事だった。
非エンジニアにとって、暴走は「怖いから全部止める」ではなく、「怖いところだけ止める」が現実的だった。本番に触る、範囲が曖昧、説明できない——この三つだけでも、かなりの提案を安全に却下できる。却下に慣れると、採択の解像度が上がる。採択の解像度が上がると、AI の速さが初めて味方になる。速さを味方にする前に、止める筋肉をつける。それがこの時期の成果だった。
6. 学び
- AI の速さは、範囲制御なしではプロジェクトを薄く広く壊す
- 「できる」は「やる」の理由にならない
- One Step, One Feature は速度制限ではなく、理解可能な速度を保つ装置
- 完成条件を先に置くと、暴走の燃料が減る
- 止めることは後退ではなく、次の一歩のための整備
- 怖さは、範囲・本番・説明責任に翻訳すると再発防止になる
7. 次回予告
次は、止めた先に残る本題——仕様を決めるのは誰か——を書く。AI は案を出せる。採択は人間の仕事だった。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 03 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回予告
Vol.04「仕様を決めるのは人間だった」
速さだけでは足りない。目的と境界のオーナーシップの話です。