1. リード
つながったあとに来るのは、いつも同じ問いだ。「じゃあ、AI にやらせていいのはどこまで？」技術的にできることと、運営として許すことは、一致しない。一致しないまま進むと、速さは事故になる。Kagoshimaniax OS では、その境界に Human Approval という名前を付けた。人間の承認。短い言葉だが、思想として長く効く。
私はコードを書けない。だから「承認フローを実装した」というより、「承認なしでは進めない文化を置いた」感覚に近い。文化は、ボタンより強いことがある。ボタンは迂回される。文化は、会話の最初に戻る。
2. 背景
Vol.03 で AI の暴走を書いた。止め方は、範囲を狭くすること、書き込みを後回しにすること、記録を残すことだった。Connector Platform で読み取りと日次蓄積が回り始めると、次の诱惑が来る。「読めるなら書けるのでは？」「提案まで自動化できたのだから、実行も？」
诱惑は悪意ではない。効率化の延長だ。だが地域メディアの本番は、実験場ではない。記事、SEO 設定、キャッシュ、SNS——一つのミスが、検索と信頼に効く。効くものを、モデルの自信に委ねる理由はない。モデルは責任を引き受けない。引き受けるのは、朝の 10 分を使う人間だ。
だから思想を先に置いた。AI は提案者。本番の変更は、人が承認する。
3. 今回のテーマ
テーマは、Human Approval を思想として採用し、操作の安全分類まで落とし込んだことだ。
自動化してよい領域と、承認が要る領域を分ける。コネクタによる日次取得、レポート生成、バックアップ——こうした読み取り中心の処理は、原則として自動化の側に置ける。一方、公開、削除、設定変更、SNS 投稿——本番に触れる操作は、承認なしでは実行しない。これは機能のリストではなく、運営の約束だ。
4. 実際の出来事
思想が文書になったのは、書き込み系 MCP の棚卸しからだった。WordPress、SEOPress、WP Rocket、Imagify、Obsidian、Metricool——「できること」は、一度並べると怖いほど多い。並べたあと、色を付けた。Green、Yellow、Red。色は、直感を助ける。直感は、非エンジニアの判断速度を上げる。
docs/action-safety-policy.md と docs/automation-policy.md に落ちた言葉は、難しくない。「提案までは自動でよい。本番操作は Human Approval 必須。」繰り返し書くことで、AI への依頼文にも染み込む。染み込むと、いきなり「設定を変えて」と言われにくくなる。
思想を試すには、小さな Green 操作が要った。Step45 で Obsidian の create-note を、Human Approval 付きで実装した。承認チェックがないとボタンは動かない。ロジックでも拒否される。上書きはしない。監査ログには本文ではなくハッシュだけ。本番サイトには触れない。失敗しても傷が浅い場所で、承認の型を学ぶ。
Step46 では WP Rocket の retest-page-insights を同じ枠に載せた。キャッシュ系は怖い。だから承認前に Safety 表示、実行後の確認、JSONL の監査——共通フローを再利用した。再利用は、思想が機能になった証拠だ。
失敗談: 私はしばしば、「Green なら承認いらないのでは？」と言いかけた。早く楽になりたい気持ちは分かる。だが Version 0.5 では、Green でも Human Approval を付けると決めていた。付ける理由は、習慣を作るためだ。最初から例外を増やすと、例外が標準になる。標準が「とりあえず実行」になると、Red の操作が紛れ込む。
もう一つの失敗は、承認を形だけにすることだ。チェックボックスに印を付けて、内容を読まない。形だけの承認は、承認の否定だ。だから確認画面に Safety 表示を置いた。何が起きるかを、実行前に言葉にする。言葉にできない操作は、実行しない。
三つめは、まだ開放していない操作への焦りだった。SEOPress のタイトル変更、Imagify の圧縮——将来の Must 候補として見えている。だがロールバック方針が固まらないものを、承認付きだから安全、とは言えない。思想は、未準備の操作を止める力にもなる。
信頼は、一発の自動化ではなく、何度も承認を挟んだ履歴から生まれる。履歴は、監査ログとテストに残した。承認なし実行不可を単体テストで確認できたとき、初めて「思想」が「仕様」になった感覚があった。
Actions 画面を初めて開いた日のことを覚えている。ボタンは目立つ。目立つボタンは、押したくなる。押したくなる設計は、危ない。だから承認チェックがないと disabled のままだ、と確認した。確認は、子どもの頃の「押すな」と書いてあるボタンと同じ安心感だった。遊びではなく、本番の隣で遊ばないための UI だ。
Obsidian の create-note を試したとき、上書きできない仕様が逆に心強かった。失敗しても既存ノートは壊れない。壊れないことは、非エンジニアが初めて書き込みに触れる条件だ。条件が揃って初めて、WP Rocket のような本番近い操作に進める。順番を飛ばしたくなる気持ちは、毎回来る。来るたびに思想が止めてくれる。
Metricool の OAuth や日次コネクタは、承認なしで回る側に置いた。ここを混同すると、「全部承認」も「全部自動」もどちらも破綻する。破綻は、現場の言葉で言うと「何を信じていいか分からない」状態だ。その状態が一番、朝の 10 分を奪う。
Vol.03 で暴走を止めた話は、今読み返すと Human Approval の前置きにも見える。止め方は「やらない」だった。思想は「やるが、承認する」へ進化した。進化は、否定からではなく、境界の精密化から来た。精密化は、レビューと文書が支えた。支えがなければ、思想はスローガンで終わる。
SNS や公開の話が出たとき、私はいつも一度手を止めた。止める理由を言語化するのが苦手だった。苦手なまま進むと、あとで「なぜ許したか」が説明できない。説明できない許可は、事故の温床だ。だから automation-policy に「投稿は Human Approval 必須」と明文化した。明文化は、未来の自分への手紙だ。
5. 考えたこと
Human Approval は、AI 不信ではない。AI を使い続けるための条件に近い。提案は歓迎する。調査、下書き、比較、リスク列挙——ここは任せた方が速い。任せた先で、最後の一押しだけ人が持つ。一押しの重さを知っているから、提案の質も上がる。上がるのは、責任の所在が明確だからだ。
また、承認は遅さではない。遅さは、判断を省略しないことのコストだ。省略した判断は、夜に返ってくる。返ってきたときの方が高い。朝の 10 分は、承認を含めた設計で守るべき時間だ。
非エンジニアにとって思想は、コードより書ける。書いた思想は、ADR や CHANGELOG と一緒に育てられる。育てると、レビューの基準になる。基準があると、実装の速さに振り回されにくい。
Human Approval は、将来の AI 機能を先送りするための言い訳ではない。むしろ逆で、AI を本番に近づけるための条件だ。提案の質が上がれば、承認する判断も速くなる。速くなるのは、内容を理解しているからだ。理解は、丸投げからは生まれない。対話と文書と、一度だけの小さな実行が、理解を積み上げる。
Red の操作を未配線のまま残すことも、思想の一部だ。「できるが止めている」は、弱さではなく設計だ。設計を語れるようになると、ステークホルダー——この場合は未来の自分——に説明できる。説明できることは、運営 OS の資産になる。
6. 学び
- 技術的に可能なことと、運営として許すことは別物
- コネクタ・レポート・バックアップは自動化、本番変更は承認
- Green でも最初は承認を付け、習慣を作る
- 小さくて浅い操作で承認フローを検証できる
- 監査ログとテストが、思想を仕様に固定する
- 未準備の操作は、承認があっても開放しない
7. 次回予告
次は、思想を支えたもう一つの柱——レビューと文書化——を書く。実装より、レビューの方が効いた日々の話だ。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 07 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回予告
Vol.08「レビューの方が実装より重要だった」
Documentation First、ADR、Architecture Review——止まって見えた時間の話を書きます。