AIエージェントが作成したコードを本番環境へデプロイする前には、以下の条件がすべて満たされていなければなりません。テストスイートを通過していること、リントおよび型チェックを通過していること、差分（Diff）のサイズとスコープが計画で合意した範囲に収まっていること、プロジェクト全体のビルドが成功すること、セキュリティスキャンで新たな脆弱性が検出されないこと、そして人間がDiffを確認して承認していることです。これらはいずれも「検証ゲート（Verification gate）」であり、次の開発ステージへ進む前に必ずクリアしなければならない関門です。さらに、コードが一行も書かれる前に機能する最重要ゲートが存在します。それが「計画（Plan）に対する人間の承認」です。事前に却下された計画の実行コストは完全にゼロであるため、このゲートが最も大きなコスト削減効果をもたらします。本記事ではゲートの定義を明確にし、エージェントのコードに必要な重要ゲートを整理した上で、Ivy Tendrilがこれらをどのように実行するかを解説します。

検証ゲートとは何か

ゲートとは、開発ステージ間の遷移に設定される必須条件です。ステージNの作業は、その条件が満たされない限りステージN+1に進むことはできません。条件は常に同一の基準で機械的・客観的に評価され、後から監査できるように判定結果が記録されなければなりません。

単なる「推奨事項」や「確認リスト」と真のゲートを分けるのは、以下の3つの性質です。

ブロッキング（遮断）性： ゲートを通過できなければ、後続への遷移は即座に停止します。失敗しても処理が進んでしまう検査は単なる「通知」であり、ゲートではありません。
自動化または明示的判定： プログラムが客観的に判定する（テスト、リント、ビルド）か、指定された担当者が判断を明示的に記録する（コードレビュー）かのいずれかです。「誰かが見たはず」といった曖昧な運用はゲートと呼べません。
明確な失敗時ルート： ゲートを通過できなかった際、作業の戻り先があらかじめ定義されている必要があります（エージェントへの差し戻し、計画段階への差し戻し、あるいは人間による対応）。検査に失敗したコードがどこにも割り当てられずに放置されることこそ、エージェントの作業が迷宮入りする最大の原因です。

人間が書いたコードも、継続的インテグレーション（CI）やPull Requestレビューといったゲートを通過します。エージェントの出力における決定的な違いは「ボリューム」です。一人の開発者が1日に20件ものPRを作成できるようになると、人間のレビューが致命的なボトルネックになります。したがって、人間がDiffを読む前に、レビュー前のゲートによって問題のあるコードを最大限自動的に排除しなければなりません。コーディングエージェントのオーケストレーションパターンでは、検証がキューイング、プロセスの分離、コスト管理とどのように結びつくかを解説しています。

エージェント生成コードに必要な重要ゲート

ゲート	チェック内容	失敗が意味すること
計画の承認	人間が計画書を読み、アプローチとスコープに同意している	要件の定義不足、または技術的アプローチの根本的な誤り
テスト	既存テストの通過および新規機能に対するテストの網羅	既存機能のデグレ、または変更点に対するテスト不足
リント＆型チェック	プロジェクトの規約に適合し、正常にコンパイルが通る	ルール違反、不要コード、テストを通すために導入された型エラー
Diffのサイズとスコープ	変更ファイルが計画と一致し、レビュー可能な差分量である	計画外のファイル変更、または無関係なコードの勝手なリファクタリング
ビルド	ブランチからプロジェクト全体が正常にビルドできる	単体では動くものの、システム全体として統合できていない
セキュリティスキャン	漏洩シークレット、脆弱な依存関係、禁止パターンの不在	APIキーの混入、危険な依存ライブラリの追加、安全でない呼び出し
Diffの承認	人間がコード差分を精査し、マージを承認している	自動ゲートでは判定できない領域（意図の合致、命名、設計思想、仕様適合）

最初の6つは人間が介在する前に実行されます。計画ゲートはコード実行の前に走り、残りの自動ゲートはエージェントのWorktree内で実行直後に判定されます。特に重要な2点について補足します。

LLM生成コード特有のリスク（安全でない出力処理、サプライチェーンへの悪意ある依存関係の混入、シークレット漏洩など）は、OWASP Top 10 for LLM Applicationsにまとめられており、セキュリティゲートが何を検知すべきかの実践的な基準になります。

Diffのサイズとスコープはチームが見落としがちなゲートですが、人間よりもエージェントにおいて重要性が増します。エージェントに簡単なnullチェックの修正を依頼すると、ファイル全体のフォーマット変更、変数名の書き換え、周辺の呼び出し箇所の修正などを勝手に行うことがあります。その結果、本来10行で済むはずのレビューが300行の巨大なDiffへと膨れ上がります。スコープゲートは、変更されたファイルやモジュールを計画と照合し、計画外の肥大化を未然に防ぎます。

セキュリティスキャンは、シークレット、依存パッケージの脆弱性、危険な構文パターンをブロックします。エージェントは周囲の既存コードからパターンを学習するため、リポジトリに不安全な実装が1箇所でもあると、それを真似て同様のコードを拡散させてしまう傾向があります。

なぜ計画チェックポイントが無駄な実行を防ぐのか

コード実行後に走るすべてのゲートには共通の弱点があります。それは「失敗が判明した時点で、すでにトークンとコストが消費されている」という点です。テスト、リント、ビルド、スキャンは、実行が失敗したことを事後的に知らせるに過ぎません。これに対し、計画ゲートだけはコストが発生する「前」に問題を防ぐことができます。

後段のゲートが何を検知しているかを振り返ってみてください。エージェントが要件を誤解したことによるテスト失敗は「計画の問題」です。タスクで指定されていないモジュールを変更したことによるスコープ違反も「計画の問題」です。依存関係を考慮せずに特定パッケージを変更したことによるビルド失敗も「計画の問題」です。これらはすべて、レビュー担当者が書かれた計画を2分間確認していれば、実行コストゼロで未然に防ぐことができたはずのエラーです。

Ivyが提唱する「計画・実行・検証・レビュー」の反復プロセスであるソフトウェアファクトリーが、人間のチェックポイントを厳密に2箇所に限定し、そのうちの1つをコード作成の前に配置しているのはこのためです。計画のチェックポイントでスコープ、手法、優先順位を確定し、Diffのチェックポイントで実装の正しさを確定します。その間にあるすべての検証は完全に自動化されます。

Ivy Tendrilが検証ゲートを実行する仕組み

Ivy Tendrilは、タスクを計画からレビュー済みPull Requestまで導くローカルファーストのデスクトップアプリケーション（macOS、Windows、Linux）です。2つの人間チェックポイントと、その間に位置する自動ゲートがライフサイクルに組み込まれています。UIの詳細はReviewアプリのドキュメントを参照してください。

計画ゲート： 計画はドラフト（下書き）として作成されます。人間がそれを読み、詳細化（Expand）、分割（Split）、更新（Update）を行うか、ドラフトにインラインでコメントを記入して再生成させます。計画が承認されるまでコード実行は一切行われません。
環境の完全分離実行： 各計画は専用の独立したgit worktreeおよび専用ブランチ上で実行されます。したがって、検証はその計画による変更点のみを正確に対象とし、他の作業と干渉しません。並列AIエージェントのためのGit Worktree活用法では、分離がゲートの信頼性を担保する理由を詳しく解説しています。
検証タブ： 実行完了後、Reviewアプリにはテスト、リント、Diffが個別のタブとして表示され、レビュアーは意思決定を行う前に3つの観点を一目で把握できます。
ProプランでのCI連携： CI環境（GitHub Actionsなど）でゲートを実行しているチームは、Proプランにてその実行結果をReviewアプリ内に直接インポートできます。別の管理画面を行き来する必要はありません。
失敗時の自動修復ルート： 検証が失敗した場合、タスクはエラー出力全文とともにエージェントへ差し戻されます。エージェントは要約ではなく生のテストやリントのエラーログを受け取り、同一Worktree内で修正を再試行します。Jobs画面では、修正中のエージェントのログやツール呼び出しがリアルタイムでストリーミング表示されます。
Diffゲート： すべての自動検証をパスし、人間がDiffを承認して初めて、TendrilはGitHub上にPull Requestを作成します。二重の承認なしにコードが提出されることはありません。

コストは計画単位および各ジョブ単位で記録されるため、検証合格までに3回の試行を要した計画ではリトライ費用の内訳が可視化されます。これにより、「計画ゲートをもっと厳密に運用すべきだったか」を客観的データに基づいて振り返ることができます。

導入手順

現在のゲートを棚卸しする：多くのチームでは、テストとコードレビューは存在するものの、リントがどこで走っているか、それがマージをブロックしているかが曖昧になっています。
Tendrilのインストール：curl -sSf https://cdn.ivy.app/install-tendril.sh | sh（macOS、Linux）またはirm https://cdn.ivy.app/install-tendril.ps1 | iex（Windows）。詳細はインストール手順を参照。
1つの計画をライフサイクルに沿って実行し、Diffを見る前にテストタブとリントタブを確認します。Diffだけを見ていたら見落としていたであろう問題点に気付くはずです。
計画レビューにスコープチェックを追加する：エージェントが変更を許可されたファイル一覧が、計画と過不足なく一致しているかを確認します。

Tendrilは無料で利用可能であり、Functional Source Licenseのもとでソースコードが公開されています。CI検証のインポート、チーム機能、オンプレミス運用、SSOなどはProおよびEnterpriseプランで提供されています。

よくある質問

検証ゲートは自動でブロックすべきですか、それともレビュアーへの通知に留めるべきですか？

テスト、リント、型チェック、ビルドは自動で厳格にブロックすべきです。コンパイルすら通らないDiffの確認に人間が時間を費やすべきではありません。一方で、スコープやセキュリティ警告については、正当なオーバーライドの理由が存在する場合もあるため、内容を提示した上で人間が判断して続行できる柔軟性を残すのが適切です。

検証失敗時、エージェントに何回までリトライを許容すべきですか？

上限回数を明確に設定し記録してください。検証の連続失敗は、実行能力ではなく計画自体の不備に起因することがほとんどです。5回目の無駄な試行に費用を投じるよりも、計画作成のステージへ差し戻すのが賢明です。ジョブごとのコスト追跡により、リトライ費用の無駄を即座に特定できます。

自動ゲートをすべて通過した場合でも、人間によるDiffレビューは必要ですか？

はい、絶対に必要です。自動化されたゲートは事前に明確にルール化できる項目しか検証できません。その変更がチケットの真の意図を満たしているか、将来にわたって保守しやすい構造になっているか、計画自体が妥当であったかまでは判断できないからです。だからこそ、Diffチェックポイントは省略不可能な2大人間ゲートの1つとして位置付けられています。

Ivy Tendrilで開発を加速する

開発者レベルの並列エージェントオーケストレーションを体験しませんか？

ソースコードを確認: GitHubのIvy Tendrilリポジトリ（オープンソース）
技術ドキュメント: tendril.ivy.appの統合ガイドを参照
アーキテクチャ相談: renco@ivy.appまでお気軽にお問い合わせください（30分の技術相談）

検証ゲート：AIエージェントのコードを本番投入する前に満たすべき必須条件