ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-07-14上級

AGENTS.md を一行直したら挙動が崩れた — 指示そのものを回帰テストする仕組み

エージェントに渡す指示(AGENTS.md やスキル文)を直すたびに、別のタスクが静かに壊れます。コードでなく指示を被験体にした回帰ハーネスを、固定タスク集と決定的アサーションで実装し、無人運用に組み込むまでを示します。

Antigravity328エージェント設計13回帰テスト2プロンプト管理無人運用5

プレミアム記事

AGENTS.md の一文を「なるべく既存の関数を再利用してください」から「既存の関数を優先的に再利用してください」に書き換えただけの日でした。意図は同じはずです。ところが翌朝の無人ランで、あるタスクだけが新しいユーティリティを毎回書き下ろすようになっていました。コードは一行も触っていません。壊れたのは指示の方です。

個人開発で Antigravity のエージェントに定期作業を預けていると、この種の事故がいちばん怖いと感じています。テストが赤くなるわけでもなく、例外が飛ぶわけでもない。ただ、以前できていたことが静かにできなくなる。しかも原因は自分が善意で直した指示文なので、気づくまでに時間がかかります。

コードには回帰テストを書くのに、なぜ指示文には書かないのか。ここ数週間、その問いに実装で答えを出そうとしてきました。被験体をコードではなく「エージェントに渡す指示」に置いた回帰ハーネスの話です。

指示は暗黙のコードだと考える

エージェントの振る舞いは、モデルの重みと、こちらが渡す指示文の合成で決まります。モデルは自分では変えられませんが、指示文はこちらが日々書き換えています。つまり AGENTS.md やスキル文は、実行時に解釈される一種のソースコードです。ソースコードなら、変更したときに退行していないかを測る仕組みがあってしかるべきです。

ただし普通の単体テストは使えません。関数の戻り値のように、同じ入力から同じ出力が返るとは限らないからです。同じ指示・同じタスクでも、エージェントの出力は毎回少しずつ違います。だから被験体を「出力そのもの」ではなく「出力が満たすべき性質」に置き換えます。性質さえ固定できれば、多少ゆらいでも合否は判定できます。

この発想は完了判定を外部化する考え方と地続きです。エージェントの自己申告を信じず、外から検証する設計は完了の自己申告から卒業させる完了契約の記事で扱いました。本稿はその一歩手前、「指示を変えた瞬間に、複数タスクをまとめて検証し直す」層を作ります。

fixture の粒度を先に決める

回帰スイートの中身は fixture の集合です。1 つの fixture は「タスクの指示」と「そのタスクが満たすべきアサーション」の組で表します。ここで粒度を欲張ると破綻します。私は最初、実際の業務タスクをそのまま fixture にしようとして失敗しました。1 ランに数分かかり、外部 API を叩き、結果が環境に依存する。回帰スイートとしては重すぎたのです。本番運用のタスクをそのまま持ち込むのは、この仕組みの最初の落とし穴でした。この重さを回避するために、いまは代表的で軽いタスクに絞っています。

いまは fixture を「代表的で、短く、副作用が閉じている」タスクに絞っています。目安は 1 fixture あたり 30 秒以内、外部ネットワークに出ない、生成物はサンドボックス内のファイルだけ。実業務そのものではなく、実業務で守ってほしい性質を最小の形で再現したものを置きます。

アサーション種別判定するもの揺らぎへの強さ
ファイル存在期待する成果物が生成されたか強い
grep パターン特定の関数・API を使ったか
終了コード生成物がそのまま実行・ビルドできるか強い
禁止語やめてほしい書き方をしていないか強い

意味的な正しさ(コードの意図が合っているか)まで機械では測りません。そこはモデル審査に頼ると揺らぎが増え、回帰検知の土台が崩れます。決定的に測れる性質だけをアサーションに置くのが、回帰スイートを信用できるものにする鍵でした。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
コードではなく指示文(AGENTS.md・スキル)を被験体にした回帰スイートの設計と、fixture の粒度の決め方
ファイル存在・grep・終了コード・禁止語の4種を組み合わせた決定的アサーションと、ベースライン差分での退行検知
確率的な揺らぎを退行と誤認しないための多試行スコアと、無人スケジュール実行への組み込み手順
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-06-15
Antigravity のエージェントを「完了の自己申告」から卒業させる — 完了契約と外部検証の実装メモ
Antigravity のエージェントが「完了しました」と報告したのに未完了だった事故を、完了判定をコードへ外部化する設計で潰してきました。完了契約・3層の自動検証・無人実行での扱い・CI 統合までを実装で示します。
Agents & Manager2026-05-06
エージェントに「審美眼」を持たせる — Antigravity × Gemini Vision で構築する UI 品質自動評価パイプライン
「このUIは良いか悪いか」という曖昧な判断をコードに落とし込む方法を探ります。Antigravity と Gemini Vision を組み合わせて、スクリーンショット取得からAI評価、改善提案、自動修正、CI/CD統合までを一本のエージェントパイプラインとして実装します。
Agents & Manager2026-05-04
Antigravity の Architect / Builder を『数理的に』設計する — 検索・分類・推論モデルから考えるエージェント設計
Antigravity の Architect / Builder の二段構成は、よくよく見ると検索エンジンや分類モデルの数学的構造とよく似ています。AIエージェント設計を『数理的思考』のレンズで捉え直し、より安定したエージェントを作るための視点を整理します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →