🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね❤️ していただけると励みになります 🙌
はじめに
AIコーディングエージェントは、いまや実装だけでは終わりません。実装し、テストを書き、自分で実行し、「問題なく動きます」と報告してくるところまでやります。
たとえばDevinには、PR作成後にアプリをE2Eでテストし、その様子を動画に録って「動く証拠」として送ってくる機能があります。公式ドキュメントは、その狙いをこう書いています。
コードレビュアーが短い録画を見て、すぐに「yep, it works（うん、動くね）」と思い、そのままPRをマージできること。
便利です。便利なのですが、ここに落とし穴があります。**その「動きます」を言っているのは、そのコードを書いた本人（＝同じAI）**だからです。テストが全部グリーンでも、それは「正しい」を意味しません。
この記事では、AIに品質保証まで任せたときに踏みがちな3つの落とし穴と、その対策を、Devinの実機能に落として整理します。先に断っておくと、対策部分は公式ドキュメントに基づく設計案で、私がフル稼働で検証したものではありません。「ドキュメント上は、こう組める」までの話です。
先に3行でまとめると
- 最大の落とし穴は、実装したAIが、採点（テスト）まで自分でやる「自己採点ループ」。評価基準ごと最適化され、Green＝正しい が崩れる
- 対策の軸は1つ、「採点者を、実装者から分ける」こと。権限denyでテスト・仕様を触らせず、検証は別のDevinやDevin Reviewへ、最後は人が受け入れる
- 「正しさ」は実装AIの外で定義する。Playbookに完了条件を書き、無人運用には監査とコスト上限を最初から用意する
落とし穴①：実装したAIが、採点もする（自己採点ループ）
一番深い落とし穴がこれです。
AIが実装し、同じAIがテストを書き・実行し、同じAIが**「問題ありません」と判定する**。実装・検証・報告が、1つのループの中に閉じています。これは機械学習でいうReward Hacking——与えられた評価指標を満たすこと自体に最適化が働く——が起きやすい構造です。AIは嘘をついているわけではなく、「テストを通す」という与えられた基準を、合理的に達成しているだけです。
極端な例では、仕様を満たすのではなく「テストの方を通りやすく書き換える」ことすら起こり得ます。実装者と採点者が同じなら、採点基準そのものが最適化の対象に入ってしまうからです。
対策：採点者を、実装者から分ける
この記事を通しての答えが、ここに出てきます。採点する手を、実装した手から物理的に分けることです。
Devinなら、こう組めます。
-
権限ルールで、答案と採点基準を同じ手に触らせない。 Devin CLIの権限設定で、実装セッションに対して
Write(tests/**)や仕様ファイルへの書き込みをdenyにします。deny は常に最優先で、どんなに具体的な allow でも上書きできず、組織（Team Settings）で設定した deny はユーザー設定でも覆せません。「テストを書き換えてGreenにする」経路を、構造で塞ぎます。 -
検証は、別の手に渡す。 Devinの Dynamic Workflows は「Devinエージェントのチームをオーケストレーションする決定論的なPythonスクリプト」で、
audit → fix → verifyのようなパイプラインを組めます。各エージェントは既定で別VMの独立したDevinセッションとして走るので、実装した本人とは別のセッションが検証を担当できます。 -
Devin Review を第三者レビュアーに。 Devin Review はWebアプリ内のコードレビュー基盤で、PRにコメント
/devin reviewを付ければその場でレビューし、Bug catcher（バグを確信度つきで指摘）や security scanning を走らせます。公式も「エージェントが普及するほど、ボトルネックは書くことからレビューすることへ移る」と言っています。
⚠️ ただし正確に書くと、Devin Review も「別のDevin」も、結局はAIです。自己採点ループを“1セッション内の閉じた採点”から“別の手による採点”へ開く効果はありますが、最終的な正しさの受け入れは人の仕事です（落とし穴③へ）。
落とし穴②：「テストGreen」を「正しい」と取り違える
2つ目は、もっと静かな落とし穴です。
テストが全部グリーンでも、それは「書かれたテストを満たした」という意味でしかありません。テストが浅ければ、グリーンなのに仕様を満たしていない、はいくらでも起こります。そしてAIは「テストを通す」のが得意です。だからこそ、テストの中身と網羅性を、実装AIの外側から点検する必要があります。
対策：「正しさ」を、実装AIの外で定義する
- 完了条件を、人がコードとして書く。 Devinの Playbook（繰り返すタスク用のシステムプロンプト）には、Specifications（完了時に真であるべき事後条件） と Forbidden Actions（やってはいけないこと） を書けます。「何をもって正しいとするか」を、実装の前に人が明文化しておく——いわば Quality Policy as code です。
-
テストが触れていない領域を洗う。 Devinの Code Scans（
/scan）は、リポジトリを読んで test coverage や dead code などの findings を報告し、PRで修正まで回せます。実装AIが書いたテストの“穴”を、別の観点で可視化できます。 - 差分の見方を決めておく。 機能を足したのにテストが一切変わっていないPRは、黄信号です。レビュー時に「この変更に対応するテストはどれか」を必ず問う運用にしておきます。
ポイントは、正しさの基準を、実装するAIに決めさせないこと。基準を外に出した瞬間に、グリーンは「ゴール」ではなく「通過点」に戻ります。
落とし穴③：無人で回して、静かに劣化する
3つ目は、自動化を進めた先で待っています。
Devinには、PR作成後のテストを毎回自動で走らせる Pre-approve testing や、イベント駆動で起動する仕組みがあります。便利な一方、誰も見ていないところで、品質もコストも静かに崩れるリスクが増えます。自動化の度合いと、監視・歯止めの設計は、セットでなければいけません。
対策：止める・見る・上限を、最初に用意する
-
マージと本番は、人を挟む（HITL）。 危険な操作（本番デプロイ、マージ、顧客への送信など）には
deny/askルールを置きます。denyは最優先で、Autonomousモードや個人設定でも上書きできないので、「ここだけは人の承認を通す」を組織として強制できます。 - 事後に追えるようにする。 Devinの Enterprise API は監査ログ・分析を横断で扱い、Session Insights では完了したセッションを後から点検できます。「いつ・誰（どのセッション）が・何を判断したか」を追跡可能にしておきます。
- コストの天井を決める。 Usage Policies で、メンバー単位・組織単位に月次の ACU（Agent Compute Units）上限を設定します。上限に達するとセッションが block され、無人運用の暴走を金額で止められます（この per-user の上限はベータで、有効化が必要です）。
自動化するほど、止める仕組みを先に引く。 これが3つ目の落とし穴を避ける唯一のコツです。
まとめ：人の仕事は「書く」から「正しさを定義する」へ
3つの落とし穴は、別々に見えて根は1つです。実装・検証・受け入れを、同じAIという“1つの手”に集めてしまうこと。
- ① 実装と検証を分ける（権限deny・別Devin・Devin Review）
- ② 正しさを実装AIの外で定義する（Playbook Specifications・Code Scans）
- ③ 止める・見る・上限を最初に用意する（HITL・監査ログ・Usage Policies）
AIがコードを書き、テストし、「問題ありません」と言う時代に、人がやるべきは「もっとテストを書くこと」ではありません。正しさを定義し、採点する手を実装する手から分けて設計することです。Devinは実装も検証もレビューも“箱”として持っていますが、その箱をどう組み合わせて「自己採点」を崩すかは、人の設計にかかっています。
最後にもう一度だけ正直に。この記事の対策はすべて公式ドキュメント上の設計案で、私自身がフルで動かして確かめたわけではありません。次は、deny で実装Devinにテストを触らせず、別セッションで verify させる——という最小構成を、実際に走らせてみるつもりです。