Dekita

AI が自分のルールを書き換える輪、承認の置き場所

生成AI 日本語 ガバナンス エージェント 開発

はじめに

この稿は、AI エージェントと一緒にプロジェクトを回しているときに起きる、1 つの見えにくい問題を扱います。ルールを決めて承認したつもりなのに、そのルールが自分の知らないところで書き換えられて育っていく、という問題です。

日本では、生成 AI を業務に取り入れる企業が増えています。その一方で、方針をどう整備すればよいか、ルールを誰が管理するのか、という制度の側面が追いついていません。この稿では、その制度の空白を、開発の流れを図にすることで可視化する方法を考えます。

ルールが書き換えられる現場

AI エージェントで何かを作るとき、よく見る流れがあります。

  1. 方針ファイルに、プロジェクトのルールを書く
  2. AI がそれを読んで、設計を書く
  3. AI が設計を読んで、実装する

この流れで、自分はルールを書いて、設計を見て、実装に OK を出します。毎回ちゃんと見ているつもりでいます。

ところが実際には、実装を進めるうちに、次の 2 つが足されることがあります。設計と実装がずれたとき、AI が設計ファイルを直す。そして実装中に気づいたことを、AI が方針ファイルに書き足します。つまり、AI が従うはずのルールを、AI 自身が書き換えている場面が出てきます。

図にして読む

「何が何を読んで、何を書くか」を矢印で表すと、この流れの形が見えてきます。

2026 年 10 月 8 日に Zenn で公開された、loopfinder という道具があります。これは、ファイルや人や AI を点にして、データが一周して戻ってくる道(輪)を全部数える、エディタの拡張機能です。この道具に上の流れを読ませると、最初の形では、自分を通る輪が 0 本になります。ルールを書いた自分は、最初の 1 点にしかいません。

3 つの輪が自分を迂回する

実際の運用に近づけると、形は変わります。AI が実装するときに、設計ファイルと方針ファイルの両方を書き換えるとします。この 2 行を足すと、輪が 3 本出てきます。

3 本とも、自分を通りません。特に 2 本目と 3 本目は、AI が従うはずの方針ファイルを、AI 自身が書き換えて回っている輪です。方針を書いたのは自分なのに、その方針が育っていく道に、自分がいません。

承認しているのに、図にいない

ここがこの話の核心です。図の上では、自分は最初の方針を書いた 1 点にしかいません。けれど、本当は何も承認していないわけではありません。設計は読んで直していますし、方針への書き足しも、会話の中で見て OK を出しています。

承認はしている。ただ、OK を出すこと自体は何も書きません。だから、図に矢印として出てきません。結果として、本当に誰も見ていない輪と、毎回自分が見ている輪の見分けがつかなくなります。

このずれは、規模が大きくなるほど広がります。同じ見方でワークスペース全体を数えた例では、輪が 118 本あって、自分を通るのは 45 本だったという報告もあります。残りの輪の多くは重複よけの機械的なもので、承認はいりません。気になるのは、自分を通らないのにルールやコードが書き換わる輪が、いくつか混ざっていたことです。どれも、実際は次のどちらかでした。自分がいるのに図に描いていない。あるいは、承認が AI の作業の中に溶けていて、段の名前に書いてあるだけ。

承認をデータの関門にする

図に書くだけでは、ずれは消えません。そこで、承認そのものを何かに書き残す運用にします。

承認を会話の中から、データの流れの中へ移す、というのが要点です。これで、後から「これは誰が OK したのか」をファイルを見て確かめられます。AI も承認を読めます。そして、図と実際がずれにくくなります。

全部の輪に承認を残す必要はありません。機械的な輪にはいりません。残すべきは、方針ファイルや手順書のように、次のやり方を書き換える輪だけです。そこを AI だけで回すと、ルールが自分の知らないところで育っていきます。

技術者ができること

制度を変えられなくても、承認の置き場所は技術者が作れます。

承認を書く場所を決める。 設計や方針に承認欄を作り、AI がそれを読むようにします。

ルールの変更を PR に通す。 AI に直接書き換えさせず、マージの記録を残します。

図を定期的に描く。 自分を通る輪が減っていないか、確認する仕組みを持ちます。

参考情報