AIエージェントに運用ルールを読ませる話

同じフォルダで複数のAIコーディングエージェントを動かしています。ある日、その1つが 運用ルールを一度も読んでいなかったことに気づきました。 エラーは出ません。読んでいないだけで、それらしく動きます。 なぜそうなるのか、どうやって気づけるのかを、Google の Antigravity 2.0 と Antigravity CLI で実際に確かめた記録です。

1. ルールファイルの置き場は、製品ごとに違う

AIコーディングエージェントには「このフォルダではこう作業して」という指示を ファイルで渡せます。ところがそのファイル名と置き場所が、製品ごとに違います。

私のフォルダには CLAUDE.md しか置いていませんでした。 つまり Antigravity 側は、運用ルールを1行も受け取らないまま動いていたことになります。 ビルドの手順も、触ってはいけないフォルダも、何も知らない状態です。

怖いのはエラーが一切出ないことです。ルールが無ければ、 エージェントは一般的な知識で普通に答えます。答えが返ってくるので、気づけません。

2. 「ファイルがある」と「読まれている」は別

実は .agents/rules.md というファイルは置いてありました。中身も正しく、 「運用ルールの正本はこちら」と書いてあります。それでも読まれていませんでした。

読まれるのは .agents/rules/ というディレクトリの中の .md で、 .agents/rules.md というファイルではなかったからです。 半歩ずれていただけで、内容がどれだけ正しくても届きません。

3. ルールは「会話単位」で読み込まれる

ファイルを正しい場所に置いても、すでに始まっている会話には効きません。 読み込まれるのは会話の開始時だけです。

これを知らないと「置いたのに効かない」と判断してしまいます。 私も一度そう誤診しかけました。新しい会話を始めてから確かめるのが正解です。

4. 文章で指示しても、必ず読むとは限らない

ここが一番の発見でした。ルールファイルに「まず正本を読むこと」と書いておいても、 読む時と読まない時があります。

プロジェクト名を含むビルドの質問では、素直に読みに行きました。 ところが「実機の画面を操作したい」という質問では一度も読まずに即答し、 一般的な手順を答えました。私の環境では手順が違うので、そのまま実行すれば事故になります。

おそらく「プロジェクト固有の知識が要る」と判断した時だけ読みに行っています。 一般的な知識で答えられそうな質問ほど、読まずに済ませてしまう。 危ないのは、まさにそういう質問の方です。

対処として、入口のファイルから裁量を取り除きました。 「どんな質問でも読むこと。一般的な知識で答えられると思った時ほど読むこと。 この環境は標準の手順と違う」と書き足したところ、実機操作の質問でも読むようになりました。

ただし、これは保証ではありません。効いたのは文面に挙げた範囲だけで、 挙げていない領域では同じことが起きます。文章による誘導である限り、確実にはなりません。

5. 確実に止めたいなら、フックを使う

Antigravity には hooks.json という仕組みがあり、 エージェントがコマンドを実行する直前に割り込めます。 外部のスクリプトを呼び、その返事が deny なら実行そのものが止まります。 モデルの判断が入りません。

危険なコマンド（取り消せない削除、意図しない一括操作など）をここで止めるようにしたところ、 実際にブロックされることを確認できました。エージェント側にも 「フックによって実行がブロックされた」と表示されます。

ここでも2つ、静かにハマる落とし穴がありました。

説明用のキーを足すとファイルごと無効になります。 hooks.json はトップレベルのキーをすべてフック名として解釈するため、 コメント代わりに "_comment" のような項目を1つ書いただけで、 全体が読み込まれなくなります。エラーは出ません。フックが1つも動かないだけです。

フックの出力は ASCII に寄せた方が安全です。 フックはシェル経由で呼ばれるので、受け取り側の文字コードが想定と違うと JSON が壊れて読めなくなります。日本語の理由文をそのまま返して失敗したので、 エスケープした形（\uXXXX）で返すようにしました。 ここが壊れるとガードが黙って無効になるので、 「動いているつもり」が一番危ない場所です。

6. 利用枠は2つのグループに分かれている

Antigravity CLI は複数のモデルを切り替えて使えますが、 利用枠（クォータ）はモデルごとではなく、2つのグループで共有されています。

それぞれに週単位と5時間単位の2種類の枠があり、残量は /usage で確認できます（/credits は従量課金のクレジットで別物です）。

グループが分かれているということは、片方を使い切っても、もう片方で作業を続けられる ということです。私はエージェントを2つ立ち上げ、片方を Gemini 系、 もう片方を Claude 系に固定して使い分けるようにしました。

7. コマンドライン版は、待機中もCPUを使い続ける

これは実測していて驚いた点です。Antigravity CLI は 一度でも応答を生成すると、その後ずっと待機中でもCPUを使い続けます。

5分おきに30分、さらに時間を置いて計46分観測しましたが、下がりませんでした。 会話をクリアしても戻らず、プロセスを終了して起動し直すと 0.6% に戻ります。 2つ動かしていたので、合計で1コアの半分ほどを待機中に消費していた計算になります。

測り方は単純で、プロセスのCPU使用時間を一定間隔で2回読み、その差を経過時間で割っただけです。 なお同じ環境で、GUI版（Antigravity 2.0）は待機中ほぼ 0% でした。メモリは使いますが、 CPUは使っていません。

対策は「使わない時は終了する」に尽きます。起動は10秒ほどなので、 必要になってから立ち上げ直す方が安く済みます。

8. おまけ：自分の誤診の話

このCPUの原因を探していて、設定項目を1つ変えたら 6.4% が 0.8% に下がりました。8分の1です。原因が分かったと思いました。

違いました。設定を変えた方だけ、再起動していたのです。 もう一方を再起動して測り直すと数字が入れ替わり、設定は無関係だと分かりました。 「1回生成すると上がる」という本当の原因にたどり着いたのは、その後です。

変えたものと変わった結果の間に、変えていないつもりの差が挟まっていないか。 AIに手伝ってもらう検証でも、ここは人間側が疑うしかない部分だと思いました。

まとめ

どれもエラーが出ないまま無効になっている類の話でした。 動いているように見えるので、探しに行かないと見つかりません。 複数のAIエージェントを同じフォルダで動かしている方の参考になれば幸いです。