Jevエコシステム観察（第2回）：30のエージェントガードレールプロジェクトは何を止め、何を通したか

前回の記事では、Jevエコシステムの4日間を概観しました。今回は主要なユースケースであるエージェントの監督を深掘りします。TypeSafeがJevをリリースしてから72時間以内に、「エージェントの安全性・監督」カテゴリだけで30以上のプロジェクトが生まれました。4日目にはコモディティ化が進み、実務者から「レッドオーシャン」と呼ばれるほどになりました。これは実需があることの裏付けです。本記事ではこれらを4つの形態に分類し、数値を示した事例を通じて比較したうえで、「自分のエージェントにはどのガードレールを使うべきか」という実践的な問いに答えます。

まず、エビデンスの前提を説明します。以下に示す各プロジェクトの数値は著者の自己申告であり（エビデンスの強さに応じてA/B/Cに分類）、レイテンシとコストはプロジェクト単位で測定されています。全事例を収録したリポジトリはjev-radarで公開されており、各エントリーには一次情報源が付いています。

ガードレールが急に機能するようになった理由

エージェントのガードレールは新しい発想ではありません。以前は採算が合わなかったのです。ツール呼び出しが危険かどうかをLLMに判定させると、1回の推論に数秒かかり、数セントのコストがかかりました。それをエージェントループの各ステップに組み込むと、そのままタイムアウトにつながりました。pi-wardenのREADMEには、新たな試算が示されています。1回のチェックあたり入力約1,000トークン、約$0.00004、約0.3秒です（著者による自己申告）。ガード呼び出しのたびにチェックを実行することが、初めて現実的になりました。ガードレールが最大のユースケースになったのはこのためです。レイテンシと単価の変化により、ステップごとの監督は贅沢品から標準設定へと変わりました。

4つのガードレールアーキテクチャ

30以上のプロジェクトを、何を判断するか、ブロックするかどうかで分類すると、4つのアプローチに分かれます。

• シャドー監督：ルールの遵守、ノイズ、停滞、テストなしでの完了の主張を判定します。ブロックはせず、判定結果をコンテキストに注入して自己修正を促します。例：pi-warden、Foreman。
• ハードな境界＋グレーゾーン判定：ホワイトリスト外の呼び出しを判定します。ブロックは行いますが、ハードルールが優先され、Jevはグレーゾーンのみを評価します。例：jevgate、rh-guard。
• 承認ゲート：高コストまたはリスクの高いステップの前の最終ゲートとして機能し、人間によるレビューのためにブロックするか、ダウングレードします。例：toolgate、noulgate、hermes-approvals。
• 申告の突き合わせ：エージェントの主張を実際に起きたことと突き合わせ、リアルタイムでブロックすることなく、実行後に食い違いを明らかにします。例：clear-head。

シャドー監督は、エビデンスが最も充実しています。pi-wardenはJevを使って書き込み内容をプロジェクトのルールファイルに照らして評価し、抵触したルールをエージェントのコンテキストに戻します。ユーザーが割り込まなくても、エージェントは修正指示を受け取ります。著者が自己申告している2つの指標は注目に値します。150組のヘッドレス実行を比較したところ、ガードレール無効時にはルール違反が6回、有効時には0回でした。321件の実セッション、17,160回のガード呼び出しのうち、実行が保留されたのはわずか42回でした（5回は著者の次のメッセージで解除され、37回は保留が維持されました）。効果的なガードレールは、すべてをブロックするのではなく、必要な場合にだけ介入します。もう一つ細かな点として、タスク逸脱を判定する機能が著者の評価で期待を下回った際、削除されるのではなく、軽い促し（ナッジ）に格下げされました。

ハードな境界とグレーゾーン判定を組み合わせる設計は、取り入れる価値があります。rh-guardは、採点プログラムの改ざん、隠しテストの覗き見、評価プロセスの操作といった、コーディングエージェントによる報酬ハッキングを対象としています。そのアーキテクチャ上の方針はREADMEに明記されています。まず構造化されたハードルールで拒否し、残ったグレーゾーンをJevが評価します。記録されたデモでは、sedによるアサーションの書き換えはブロックされ、無害なechoコマンドは通過しています。同系統の設計者は、この原則をさらに端的に表現しています。jevgateは実行してよいものを証明するホワイトリストとして機能し、リスト外の部分をJevが判定します。ソフトな判定が単独で拒否権を発動することはありません（フェイルオープン）。較正された確率は外れることがあるため、唯一のゲートにはできないのです。この系統では、Jevを使うべきでない場面を扱う設計判断レイヤー（Augustus）まで開発されています。

承認ゲートは、コストの高いステップの前にチェックポイントを設けます。hermes-jev-approvalsは貴重な比較数値を示しており、元のソリューションと比べて処理速度が8.7倍、コストが4分の1だと自己申告しています。toolgateはデフォルトでシャドーモードで動作し、信頼が確立されてゲートを開くまでは、観察とログ記録のみに徹します。

申告の突き合わせは、最も新しく最も軽量なアプローチです。clear-headは、エージェントが完了を報告した時点で、読み取ったと申告した対象を実際のディスク読み取り履歴と照合し、実際には行われていない読み取りの申告を特定します。

反例

WebMCPベンチマーク（nekuda-ai、オープンソースで再現可能）は、ガードレールプロジェクトの実力を見極めるうえで有用です。ブラウザハーネスに接続した素のJevは49件のWebタスクのうち25件を解決しましたが、クリック操作の連続を単一のツール呼び出しにまとめるWebMCPレイヤーを追加すると49/49に向上しました。この結論はガードレール設計にも当てはまります。選択可能なボタンの中から正しいものを選ぶことと、正しい次の一手を選ぶことは同じではありません。判断レイヤーの価値は、与えられる状態表現によって決まります。ガードレールも同様で、絞り込んだ問いと正確な状態があってこそ、信頼できる判断が得られます。

ガードレールを実装するなら

30以上のプロジェクトから導き出した5つの設計原則を、重要度順に紹介します。

1. ハードルールを優先し、グレーゾーンはJevが判断する：ホワイトリストや構造化ルールで表現できるタスクについては、確率的な判断に頼るべきではありません。Jevはルールでカバーできない領域を担当します。
2. フェイルオープンとし、ソフトな判断だけで一方的に拒否しない：較正された確率は外れることがあります。その場合は、ワークフローを停止するのではなく、人による確認を促すべきです。
3. 強制適用の前にシャドーモードで運用する：まず介入せずにログと記録だけを行い、誤検知率を評価してからゲートを開きます（toolgateのデフォルトと同じです）。
4. 問いを絞り込む：主観的な品質評価ではなく、不可逆性や意図との整合性など、答えの選択肢を列挙できる限定的な問いを評価します（Supercovの教訓はそのままガードレールに当てはまります）。
5. 期待を下回る機能は削除せず格下げする：権限を制限して機能を残すほうが、完全に削除するより多くのシグナルを保てます（pi-wardenがタスク逸脱を扱う方法と同様です）。

レッドオーシャンの先にある機会

10以上のプロジェクトで単一形態の実装が相次いだ結果、新規プロジェクトが差別化する道筋は明確になっています。特化したホストを狙う（Neovim向けのjury.nvim、Emacs向けのjev.el、GitHub Actions向けのgit-judge-jev、OpenCodeプラグイン）、新しい判断タイプを探る（rh-guardによる評価の完全性、clear-headによる申告の突き合わせ）、あるいは設計レイヤーに注力する（Jevを使うべきでない場面を扱うAugustus）といった方向です。新規参入者にとっての示唆は、汎用ガードレールの枠はすでに埋まっているものの、新しいホストや境界違反が現れるたびに、新たなゲートを設ける余地が生まれるということです。

判断レイヤーについての議論は以上です。次は、このエコシステムのもう一つの側面である失敗サンプルを見ていきます。判断レイヤーにデータを投入する必要がある場合、レビュー、センチメント、価格を確実に収集することはEveryInfraの中核となる強みです。まずは統合データAPIガイドからお始めください。