AIに自分のPRをマージさせない

🙅作った本人が、承認まで握らない

人間の開発現場でも、自分の変更を自分で承認して本流に入れるのは避けます。同じ考え方を、AI にもそのまま当てています。

ソフトウェア開発では昔から、自分の書いた変更を、自分だけの判断で本流に取り込むのは避ける、という習慣があります。作った本人は、自分のミスに気づきにくい。だから、 別の目を一つ通してから取り込む。「作る人」と「承認する人」を分ける、という考え方です。

この習慣は、相手が AI でも変わりません。むしろ AI は、自分の出したものを都合よく解釈しがちな性質があります。「できました」と胸を張って報告してくるのに、 中身がずれていることは起こります。だからこそ、 作った当人に最後のボタンまで握らせない線引きが、いっそう効いてくる。

👥二者に分ける——作る側と、承認する側

変更を作る役割と、それを本流に入れてよいと判断する役割。この二つを、必ず別の主体に持たせます。

私たちの運用は、役割を二者に分ける形になっています。AI は変更を作り、テストを通し、PR として提出するところまでを担う。 けれど、その PR を本流に取り込んでよいと最終的に判断するのは、別の主体です。作る側と承認する側が、同じ手であってはいけない。

この「二者で回す」形は、誰か一人（何か一つ）の思い込みが、そのまま本番に流れ込むのを止めるための仕組みです。作った側がどれだけ自信満々でも、承認する側が別にいれば、 取り込みの前にもう一度立ち止まれる。信頼しているから省く、ではなく、 信頼しているからこそ、確かめる工程を残す。そういう姿勢です。

🧑‍⚖️一人会社でも、承認は人が持つ

では承認する側は誰か。うちの場合は、コードに関わる変更の最後の一押しを、社長が持っています。作るのは AI、入れてよいと決めるのは人。

「一人会社なら、承認する人がいないのでは?」とよく聞かれます。 けれど、社長が 1 名いる。だから、コードに関わる変更を本流へ取り込む最後の一押しは、人が持つ形にしています。AI が作った PR は、人の承認を経てから本流に入る。

もちろん、細かい確認そのものは AI や機械のチェックに助けてもらいます。 テストが通っているか、決まりを守れているかは、機械が先に見てくれる。 人がやるのは、「これを本番に入れていいか」という最後の一線を引くことです。作業をぜんぶ人がやり直すわけではない。取り込みの許可だけは、人の手元に残す。 こうすることで、任せる範囲を広げても、暴走の余地を残さずに済みます。

🚪例外は作るが、勝手には作らせない

取り込みの影響が小さく、後から戻せるものは自動で流す道も用意しています。ただし、その線引き自体は人が決めていて、AI が勝手に広げることはできません。

とはいえ、何もかもを人が承認していては、自走の意味が薄れます。そこで、影響が小さく、あとから戻せる種類の変更――たとえば決まった形式の社内文書の更新のようなもの――には、 人の一押しなしで流せる道も用意しています。すべてを一律に止めるのではなく、 リスクの大きさで扱いを変える。

大事なのは、その「自動で流してよい範囲」を決めるのは人であって、AI ではないことです。AI が自分で「これは軽い変更だから通していい」と判断して、 勝手に範囲を広げることはできません。金銭が動く、外に公開する、取り返しがつかない―― こうした変更は、必ず人の承認に戻す。線を引く場所そのものを、AI に触らせないのが肝です。

🧭AIに開発を任せはじめた人へ

任せる範囲が広いほど、「作る」と「本流に入れる」を同じ手に握らせないことが効きます。承認だけは、人の側に残してください。

AI に開発を任せると、速さに驚きます。だからこそ、最後の取り込みまで任せてしまいたくなる。でも、そこだけは踏みとどまる価値があります。作る側と承認する側が同じになった瞬間、 チェックは形だけのものになるからです。

明日からの目安は、シンプルです。 変更を「作る役割」と「本流に入れてよいと決める役割」を、別の主体に分ける。 後から戻せる小さなものは自動で流してよいが、その線引きは人が決め、金銭・公開・取り返しのつかない変更は人の承認に戻す。この一線があるだけで、任せられる範囲は安心して広げられます。

あなたも、AI にコードを書かせていますか。 もしそうなら――最後のマージのボタンだけ、誰が押すのかを一度決めておいてください。