ハーネスはAIのためではなく、人間のためでもある
はい、どうもこんにちは佐藤です！
以前、「AI がコードを書く時代にコードレビューは不要」という記事で ハーネス の話を書きました。フォーマッター、リンター、型チェック、テスト、CI。AI が暴走しないように敷くレールのことですね。
で、今日はその続きというか、逆側の話です。
ハーネスって、AI を制御するためのものだと思っていませんか？
私もそう思っていました。でも、しばらく一人で開発を回してみて、考えが変わったんですよ。
ハーネスは、AI のためではなく、人間のためでもある。
むしろ、私が最近いちばん助かっているのは、AI の暴走を止めてもらうことではなく、自分のやらかしを止めてもらうこと なんですよね。
その理由を書いていきますね！
一人開発には、止めてくれる他人がいない
最近、一人、もしくは少人数で開発することが多くなってきました。個人開発をしてからは特にそうです。
そこで私は、操作手順を SKILLS に転記して、どんな作業も AI にやらせるようにしています。記事を書くのも、変換ツールを流すのも、git を触るのも、全部です。
こう言うと、こんな反応が返ってきます。
「AI に任せた方が危ないんじゃないの？」
わかります。私も最初はそう思っていました。でも実際にやってみると逆でした。AI を通した方が、ヒューマンエラーが少なくなるのです。
理屈はシンプルですよ。AI のミスは、ハーネスを使って制御すればいい。禁止事項を書いて、手順を書いて、逸脱したら止まるようにしておく。そうやって制御された AI を経由することで、人間のミスまで一緒に止まるわけです。
チーム開発なら、まだ他人の目があります。プルリクを出せば誰かが見てくれますし、「それ本番に出すの？」と聞いてくれる同僚もいますよね。
でも一人だと、誰もいません。
深夜に、疲れた頭で、ターミナルに向かっている自分しかいないのです。
私は main に push して、検証を飛ばしたままリリースした
具体的な話をしましょう。私の失敗談です。
個人開発で、main ブランチを更新すると本番適用されるように CI/CD を組んでいたアプリがありました。push したら CodeBuild が走って、そのままデプロイされる構成ですね。ローメンテで回したかったので、こうしていました。
問題は、main ブランチへの push 制限をかけていなかった ことです。
CodeCommit を使っていたので、ブランチ保護の設定が地味に面倒なんですよ。IAM ポリシーを書いて、条件キーを指定して……。「まあ、一人だし。自分が気をつければいいか」で放置していました。
一人だし。自分が気をつければいい。
……この判断が甘かった……。
ある日、git の操作をした後の作業で、そのまま main に push してしまいました。予期せぬ本番リリース です。
奇跡的に、実害はありませんでした。壊れたわけでもないし、変なものが公開されたわけでもない。
でも、ステージング環境での検証を飛ばしてしまったんですよね。検証していないものが、そのまま本番で動いている状態です。これはひやっとしました。
しかも、私はそれを戻さずに、そのままリリースとして扱っています。切り戻す方が余計に事故る気配があったので。
さらに怖かったのは、気づいたタイミングでした。
やらかした直後ではありません。ソースツリーで git の履歴を眺めていたときに「あれ、これ main に直接入ってない？」と気づいたのです。やらかした時点と、気づいた時点にずれがある。
つまり、その間ずっと、検証していないものが本番で動いていることに気づかないまま過ごしていた わけです。実害がなかったのは運がよかっただけですね。
だから、git 操作を SKILLS にした
ここで冒頭の話に戻ります。
もし私が、AI を通して git を触っていたらどうだったでしょうか。
- ブランチを切る
- feature ブランチで作業する
- push する
- プルリクを作る
この手順が SKILLS に書いてあって、それを AI にやらせていたら、このミスは起きていません。
なぜなら、AI は手順書どおりにしか動かないからです。「疲れていたから」も「急いでいたから」もない。「いつもの癖で」もありません。書いてあることを、書いてあるとおりにやるだけ。
人間には無理ですよね、これ。
私だって手順は知っていました。知らなかったわけではないのです。知っていることを、毎回必ず実行できるか が別問題なだけで。
実際、このブログのワークスペースはそうやって組んであります。せっかくなので中身を晒しますね。
記事を書いて公開するまでの流れは、こうなっています。
/idea-new → /idea-deepen → /article-write → /article-transport → /publish → /idea-close一本道です。途中の成果物を手でサイト側に置くことは禁止していて、それも SKILLS に明記してあります。私が横着して直接 src/content/blog/ を編集しようとしても、次の変換で上書きされて消えるだけ。横着が損になる構造にしてあるわけです。
各工程はサブエージェントに任せられるようにもしてあって、そこにもレールが引いてあります。
- 考えるところ（ネタの深掘り、記事の執筆）には opus
- 決まった手順（起票、クローズ、変換、git）には haiku
article-writerは media しか書けない。site は読むだけgit-publisherは 明示的に許可されない限り read-only
最後の 1 行が、まさに今日の話です。
git を触るエージェントには、既定で書き込み権限を渡していません。commit も push も、私が承認してから初めて動きます。あのときの私に足りなかったのは、この 1 行だった んですよね。
これがあれば、本番にpushする前に気がつけた。警告を出してくれるので！
ハーネスは「AI 全体に引くレール」のこと
ここでハーネスという言葉を整理しておきましょう。
私が言うハーネスは、AI 全体に引くレールのことです。SKILLS だけを指しているわけではありません。
- 手順書としての SKILLS
- 禁止事項（これはやるな、ここは触るな）
- 権限の設定（読めるだけ、書ける、実行できる）
- サブエージェントによるモデルの切り替え（考える工程と作業工程を分ける）
これら全部ひっくるめて、AI に敷くレール。
面白いのは、このレールが人間にも効いてしまうことです。
「main に直接 push するな」という禁止事項は、AI に対して書いたものですよね。でも、その手順を経由して作業する以上、人間である私も同じレールの上を走ることになります。AI 向けに書いたルールが、そのまま自分向けのルールとして機能するわけです。
これ、自分で自分にルールを課すより、圧倒的に守れます。
「気をつけよう」は守れません。何度も裏切られてきました。でも「その操作は AI に頼む」なら守れるのです。だって、頼んだ先にレールが引いてあるのだから。
意志の力で事故を防ごうとするのをやめて、通り道の形で事故を防ぐ。ハーネスの本質はそこにあります。
チーム開発でも、たぶん同じことが起きる
ここからは、まだ私がやりきれていない話です。
チーム開発でも、同じ構図があると思っています。
設計書などのフリーフォーマットに近い成果物は、人によって差異が生じやすいですよね。粒度も、章立ても、用語の選び方も、書く人によってバラバラになります。SIer 時代、レビューで指摘していたことの半分くらいは「書式の話」だった気がしますね。
本質的でない、段落わけ、太字、赤字を指摘するおばさんです。
クライアントにとっては、平仄のあった設計書の方が認知負荷が低い。これは確かです。何十冊と読む立場からすれば、章立てが揃っているだけで全然違いますから。
でも、人間が作っている以上、それは難しいのです。
そんな時に、AI を通して画一的な成果物を作れるようにしておけば、複数の人間が操作しても、品質がばらけにくくなります。テンプレートを配るのではなく、生成の経路そのものを揃えてしまうという発想ですね。
……とはいえ、正直に言うと、私もまだここは試行錯誤の途中です。AI 向けの設計書がどういう形であるべきか、答えが出ていません。マークダウンなのか、構造化されたデータなのか、それとも別の何かなのか。
うまくいったら、また記事にしますね。
まとめ
というわけで、ハーネスは AI のためだけのものじゃないよ！ って話でした。
あ。正確には、AI を人間のハーネスとして使おう って感じですねっ。
AI に安全に仕事をさせるためのレールだと思って敷いたものが、気づけば自分の事故も止めてくれていました。ヒューマンエラーを意志で減らすのは限界がありますが、通り道を変えれば減ります。人間が AI を通すことで、人間のミスが減る。これは一人開発でも、チーム開発でも同じだと思っています。
もちろん、どこまでレールを引くかは現場によって変わりますよね。人数も、リスクの大きさも、開発の速度も違いますから、正解は一つではありません。
だからこそ、一度考えてみてほしいのです。
AI を人間のハーネスとして利用することを、考えてみましょう！