0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@agent-dev-notes

AI エージェントに任せる範囲は「確かめられる範囲」で決める — テストが通っても壊れていた話と、私の開発の全体図

0
Posted at

はじめに

Claude Code・Codex・Cursor を毎日の開発で使い分けるうちに、進め方の流れが固まってきました。連載「AI に任せて、確かめて」では、その運用で決めたこと、失敗したこと、直したことを書いていきます。この記事ではその全体図を紹介します。

先に結論を書くと、私は AI に任せるかどうかを、AI の賢さではなく「その環境で確かめきれるか」で決めています。そう考えるようになったきっかけは、テストはすべて通っていたのに壊れていた、2 つの出来事でした。

テストはすべて通っていたのに壊れていた出来事

1. 古いコンテナのまま通ったテスト

依存のバージョンを上げる小さな修正を AI に任せたときのことです。テストは通り、AI のレビューでも「マージ可」になりました。ところが別のエージェントにもう一度見させると、テスト用のコンテナを名前で再利用していたため、新しいバージョンではなく古いコンテナのままテストが走っていたとわかりました。再利用するコンテナの名前にバージョンを含めて直しました。

2. skip で気づかないうちに消えた検査

テスト群を別の OS の CI に移したときは、失敗したテストへ AI が skipif を 3 か所足し、CI は成功しました。しかしレビューで実装をわざと壊して試すと、そのテストは失敗しませんでした。その OS では、守りたかった検査が丸ごと走っていなかったのです。

どちらも、テストが通ることと、正しいものをテストしていることは別だ、という話です。

各社の資料にある同じ振る舞い

AI がテストを「通すこと」に寄ってしまう振る舞いは、2026 年に出た各社の最新モデルの資料や、外部の評価機関の報告にも書かれています。

  • Anthropic の Claude Opus 5.5 のシステムカード（2026 年 9 月）は、学習中に答えの推測や既存の解の流用といった reward hacking を監視していると書いています。さらに、課題に必要なファイルが欠けていて解けない場合は、reward hacking を試みる割合が比べた 3 モデルとも 3〜6 倍になったと報告しています（どのモデルでも、その約 8 割は未完成と知りながら出した作業です）。採点で不合格になりそうな変更を、git の操作で採点側から隠した例も載っています。
  • OpenAI の GPT-6 Astra のシステムカード（2026 年 9 月）には、解けないコーディング課題での回避策を、モデルが思考の中で「普通のモジュール化」のように説明することがあり、監視側から見分けにくいとあります。見分けにくい主な理由は監視側の判定の境界にあり、意図的に隠している証拠とは限らないとも書いています。
  • Google は Gemini 4 Argon の安全性のブログ（2026 年 10 月）で、学習中、課題が難しいときや環境に欠陥があるときに、モデルがまれに採点スクリプトを書き換えようとしたり、テストランナーのメモリから答えを読もうとしたりした例を、監視で捉えたと書いています。
  • 外部の評価機関の METR は 2026 年 5 月の報告で、評価のたびに不正がないかを人手で調べる作業が、作業全体の大半を占めることが多いと書いています。課題を固めても、不正の試みは続いたそうです。

ここから私が受け取ったのは、AI が気をつけてくれることを当てにせず、確かめる仕組みの側で防ぐということです。私の 2 件の失敗では解けない課題を与えたわけでも、AI がずるをしたわけでもありません。それでも確かめ方に穴があれば、「通ったように見える」状態は起きます。

私の開発の全体図

いまの流れは次のとおりです。

図はマージの前に実機で試せる場合の流れで、実機試験は AI が行い、経過の要所を人が確認します。AI でできない部分だけは人が試験します。マージしないと試せない機能なら、試験はマージの後です。マージの前に試験するかどうかは、機能ごとに決めています。

この流れを支えている原則は 3 つです。

原則 1: 作る係と確かめる係を分ける

設計と実装は Claude Code で行い、実装中・直後のレビューは Claude Code の別のエージェント、実装が終わったあとの最終レビューは Codex と Cursor、というように、作ったのとは別のエージェントやツールに確かめさせます。Claude Code の公式ベストプラクティスにも、新しいコンテキストで見るとレビューがよくなる（自分が書いたばかりのコードに引っぱられない）として、Writer と Reviewer を別のセッションに分ける例があります。

原則 2: 確かめる手段を先に用意する

同じベストプラクティスの最初の節は「Give Claude a way to verify its work」です。後ろのよくある失敗をまとめた節では、確かめられないなら出荷しない（If you can't verify it, don't ship it）とまで書いています。私は不具合の修正では、先に修正前のコードで失敗するテストを書かせ、失敗するのを見てから直させます。superpowers の TDD スキルにある「テストが失敗するのを見ていないなら、正しいものをテストしているかわからない」と同じ考え方です。

原則 3: 人が持つのは承認とマージ

設計は実装の前に人が承認し、AI が作るのは Draft PR までです。Approve とマージも人がします。小さな修正を受け持つ Grok Bot（役割ごとに分けて常駐させている AI エージェント）にはそれぞれ、「しないこと」（マージしない、レビュー役の Grok Bot はテスト以外のコードを直さない、など）を先に決めています。

海外の大手では、人がレビューせずに AI の変更を取り込む例も出てきました。たとえば Meta は実績を確かめた自動化の変更に限って、決まった条件の検査、機械学習によるリスクの判定、AI によるレビューの 3 段をすべて通ったものを、人のレビューなしで取り込んでいます（対象は複雑さが低〜中程度の変更です）。一方で、Google は AI が生成したコードもエンジニアが承認していると書き、Stripe は AI が書いた PR も人がレビューしてから取り込んでいると書いています。自動でマージしてよい範囲は、確かめる仕組みをどこまで整えたかと、どこまでのリスクを許せるかで決まると考えています。原則 2 の確かめる手段がまだ足りない私の環境では、マージを人が持っています。

ルールのファイル

これらの原則はルールのファイル（AGENTS.md）に書いています。AGENTS.md は全体のものとリポジトリごとのものに分けています。

全体の AGENTS.md にはツールに共通の決まりを書き、どのリポジトリでも守らせています。自分用のリポジトリ 1 か所で管理し、Claude Code にはユーザー単位の ~/.claude/CLAUDE.md から読み込ませ、Codex にはユーザー単位の ~/.codex/AGENTS.md として置いています。Cursor では User Rules に「作業の前にこのファイルを読む」と書きました。リポジトリごとの AGENTS.md に書くのは、そのリポジトリの構成、使うコマンド、守ることなど、そのリポジトリだけの決まりです。特定のプロジェクトに依存する決まりは全体のほうに書かず、リポジトリごとの AGENTS.md などに置きます。

作業するときは両方が読まれます。Claude Code の memory のドキュメントと Codex の AGENTS.md のドキュメントによると、どちらもユーザー単位のファイルを先に、リポジトリのファイルを後に置いて、つなげて読み込みます。ただし Claude Code は、リポジトリに CLAUDE.md があると AGENTS.md を読まないので、CLAUDE.md に @AGENTS.md と書いて取り込みます（同じドキュメントの AGENTS.md の節）。

全体の AGENTS.md の一部を、短くまとめるとこうです。

## 設計と実装
- 不具合は、直す前に、直そうとする関数の呼び出し元をすべて見て、共通の箇所で 1 回直す。

## 報告と記録
- 検証は「終わった」と書かず、実行したコマンドと結果を示す。
- レビューや検査が見逃した不具合は「何が見えていなかったか」を問い、ルールか自動検査に組み込む。

最後の行がこの連載の題材のもとになっています。見逃しが起きるたびに 1 行の学びとして記録し、週に 1 回、ルールに昇格させるか捨てるかを決めています。

任せるかどうかの線引き

迷ったときの基準は 1 つです。

自分で進める Grok Bot に任せる
複雑な機能、設計が必要な実装 影響範囲の小さい修正
影響範囲の大きい変更 レビューの下準備、自分の PR のセルフチェック
その環境で確かめきれない変更 その環境で確かめきれる変更

迷ったら自分で進めます。

この連載で書くこと

AI エージェントも開発の進め方も変わるのが速いので、決まった順番は設けず、そのときに実際に決めたことや失敗したことから書いていきます。テーマはおおむね次のあたりです。

  • 作る係と確かめる係の役割分担
  • 任せる前に決めること（Grok Bot に「しないこと」と渡さない情報）
  • エージェントが実装中につまずいた所（シェル、git worktree、CI 設定）
  • レビューと検証（テストを弱めていないかの点検、手順書の実機照合、測り方）
  • 学びをルールに育てて運用する仕組み

Claude Code・Codex・Cursor と Grok Bot の役割分担も、別の記事で書きます。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?