FailproofAI レビュー: 12 のエージェントハーネスにフックを当て、危険なツール呼び出しを実行前に止める

エージェントの「止められなさ」を埋める位置づけ

コーディングエージェントの運用で困るのは、失敗の事後解析よりも、危険なツール呼び出しが実行されてしまう前に止められないことだ。ログを後から読んでも rm や認証情報の読み出しは既に終わっている。FailproofAI はこの順序を逆にし、実行の記録と遮断を同じ層で扱う。README の説明では「blocking dangerous tool calls before they execute」とあり、観測だけでなく拒否権を持つ点を前面に出している。対象は 12 のハーネスで、10 がコーディング CLI、2 がチャットおよびアシスタントのゲートウェイ (Hermes、OpenClaw) という分類になっている。同じイベント、同じポリシー、同じセッション履歴がハーネスをまたいで共有されるという主張で、複数の CLI を併用しているチームほど恩恵が大きい設計だ。想定読者は、エージェントを個人の実験ではなくチームの作業フローに組み込み始めたが、監査や統制の説明責任をまだ果たせていない層になる。

フックとポリシー評価という仕組み

README とトピック一覧から読み取れる構成は素直だ。各ハーネスにフックを差し込み、ツール呼び出しのイベントを捕捉し、ポリシーで判定し、危険と判断されたものを実行前に止める。記録されたイベントはセッション履歴として蓄積され、ローカルのダッシュボードから見る。判定はローカルで完結すると README は述べており、アカウントなしでも動くと書かれている。クラウド側には無料枠が用意されているという記述もあるが、ローカル動作とクラウド送信の境界がどこにあるのかは README からは判別できない。ポリシーは 39 または 40 と、README 内でも数字が揺れている。冒頭の説明文は 39、リポジトリの説明文は 40 だ。どちらが現行の件数かは一次ドキュメントで確認する必要がある。12 ハーネスを同じイベントモデルに正規化している点が実装上の要で、ハーネスごとに異なるツール呼び出しの表現を吸収しなければポリシーを共通化できない。

導入は npm から、ただし README は途中で切れている

README の Install セクションはコードブロックが「npm」の一行で途切れており、続くコマンドはこの素材からは確認できない。npm パッケージ名はバッジとリポジトリ情報から failproofai であることが読み取れる。SDK は別パッケージとして failproofai-sdk が公開されており、リリース一覧に failproofai-sdk-v0.0.1b2 がある。対応ハーネスに当てはまらないエージェントは Python SDK 経由で報告する、というのが README の案内だ。この SDK が提供するのは tracing、sessions、audits の 3 つで、enforcement は含まれない。遮断まで必要なら自前のランタイムにフックを実装する必要があり、README はその相談窓口としてサポートのメールアドレスを案内している。つまり導入経路は 2 本あり、ハーネス対応済みならフックを当てるだけ、非対応なら記録のみ、という非対称な構造になっている。設定キーやポリシー定義のファイル形式は、この素材には現れていない。

遮断できない経路という明確な限界

一番大きな制約は、enforcement がハーネス側のフック機構に依存していることだ。README は対応外のエージェントについて「Enforcement there needs a hook in your own runtime」と明記しており、Failproof 側だけでは完結しない。Python SDK を使えば記録はできるが、それは観測であって統制ではない。危険な操作を確実に止めたいという目的に対して、SDK 経由のエージェントは要件を満たさない。もう一点、README が「Zero latency」と書いているが、計測条件、対象経路、比較対象は示されていない。フックを挟む以上、呼び出しごとに判定コストが乗るのは構造上避けられない。この主張は独立に検証されるまでは採用判断の根拠にしないほうがよい。加えてバージョンが v1.0.4-beta.4 と beta 系で、直近のリリース間隔も短い。ポリシー定義やイベント形式が安定する前だと考えるのが妥当だ。

汎用の LLM トレーシング基盤との違い

同じ「エージェントの観測」を名乗る道具として、OpenTelemetry 系のトレーシング基盤がある。違いは介入点だ。一般的なトレーシングはエージェントやアプリ側に計装を入れ、スパンとして送信する。送信は事後であり、ツール呼び出しを止める権限は持たない。FailproofAI はハーネスのフック点に寄生する形でイベントを取り、判定結果を呼び出し元に返して実行を拒否させる。計装を自分で書かなくてよい代わりに、対応ハーネスの一覧に載っていない runtime では何もできない。逆に、自前のエージェントフレームワークを内製していて計装を自由に書けるチームにとっては、汎用トレーシングのほうが柔軟で、ベンダー固有のポリシー記法を覚える必要もない。どちらが優れているという話ではなく、フック点を誰が持っているかで選ぶべきものだ。

ライセンス表記の揺れと更新コスト

リポジトリのメタデータでは License が NOASSERTION となっている。一方 README のバッジは MIT + Commons Clause を指し、LICENSE ファイルへのリンクを張っている。この 2 つは一致していない。GitHub が NOASSERTION を返すのは、ライセンス本文が標準テンプレートとして認識されなかった場合だ。Commons Clause は MIT に付加される制限であり、ソフトウェアの販売を含む商用利用に条件を課す。社内利用なのか、製品に組み込んで再配布するのか、ホスティングサービスとして提供するのかで結論が変わるため、法務判断は各自で行う必要がある。更新コストの面では、beta 系のリリースが続いていること、ポリシー件数の表記が README 内で揺れていることを踏まえると、ポリシーを自前で書き足す運用は定義形式が固まるまで保留するのが現実的だ。バージョンを固定して追従するほうが、破壊的変更のたびに書き直す手間より安くつく。

どのチームが使い、どのチームが待つか

向いているのは、README に列挙された 12 ハーネス、具体的には Claude Code、Codex、GitHub Copilot CLI、Cursor Agent CLI、OpenCode、Pi、Hermes、OpenClaw、Factory Droid、Devin CLI、Antigravity CLI、Goose のいずれかでエージェントを動かしているチームだ。複数の CLI を併用していて、セッション履歴を横断して見たい場合に効く。向かないのは、独自ランタイム上のエージェントが主で、かつ遮断まで求める場合である。この場合は SDK で記録だけを取り、遮断は自前のフックで実装する分割構成になる。判断を保留すべきは、ポリシーを自組織向けに大量に書き換える予定がある場合だ。定義形式が beta の間に固定される保証はない。確認すべきは、ローカル動作とクラウド無料枠の境界、39 と 40 のどちらが現行のポリシー件数か、そして LICENSE ファイルの実際の文面の 3 点になる。

編集部の結論

Claude Code、Codex、Copilot CLI、Cursor Agent CLI など README に列挙された 12 ハーネスのいずれかでエージェントを動かしており、危険なツール呼び出しを実行前に止めたいチームは検討する価値がある。逆に、独自ランタイム上のエージェントが中心で、遮断まで求めない場合は、Python SDK が tracing、sessions、audits を提供するとはいえ enforcement には自前のフックが必要になるため、まず自社ランタイムにフック点があるかを確認すべきだ。導入前に確かめるべきは 3 点で、ひとつは LICENSE ファイルが NOASSERTION と表示される以上、npm パッケージの公開ライセンス表記とリポジトリの LICENSE を突き合わせて MIT + Commons Clause の適用範囲を自組織で解釈すること。ふたつめは v1.0.4-beta.4 という beta 系のバージョン番号が示すとおり API とポリシー定義が動きうる前提で、ポリシーを自前で書くなら設定ファイルの形式が固定されるまで待つか、バージョンを固定して追従すること。みっつめは、README が謳う zero latency がどの経路の計測値なのかを一次ドキュメントで確認すること。この 3 点が自組織の基準を満たさないなら、ポリシー適用は自前のフックで書き、Failproof は記録層としてだけ使う分割導入のほうが安全である。

公式情報源

1. FailproofAI/failproofai on GitHub
2. Issues
3. Project website
4. README
5. Releases