> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # ポリシーをテストする > 既存のトラフィックに対してドラフトをバックテストし、ブロックすべき操作を確実に止め、許可すべき操作を確実に通過させることを、実際に適用される前に検証します。 ポリシーは必ず2つの方法でテストしてください。エージェントが既に生成したトラフィックに対するテストと、必ず通過させなければならない正当な操作に対するテストです。安全でないケースしか確認していないポリシーは、テスト済みとは言えません。 ## ドラフトをバックテストする ポリシーエディタは、公開前にドラフトをフリート（全エージェント群）が実際に行った呼び出しに対して再実行します。 1. **Admin → policy editor** でドラフトを開きます。エディタはJavaScriptとして正しくパースされることを確認します。 2. **backtest** で、再実行するエージェントと時間ウィンドウを選択します。デフォルトは **every agent** と **30d** です。範囲を絞り込みたい場合を除き、最後のフィルターは **everything** のままにしてください。 3. **run backtest** を選択します。 JavaScriptとして正しくパースされるドラフトの下にあるバックテストパネル。3つのフィルターとrun backeastアクション、その上のpublish versionが表示されている。 結果は、ドラフトがそれらの呼び出しに対してどのような動作をしたかを示します。**正常に動作していた**呼び出しのうち、どれだけが中断されていたかも含まれます。これは、エージェントが実際に遭遇する前に発見された誤検知です。その数が許容できるレベルになるまで、ドラフトを調整して再実行してください。 バックテストはダッシュボードの機能です。ターミナルからは、代わりに以下の方法で自分で定義したイベントに対してポリシーを実行できます。 ## 自分で定義したイベントに対して実行する `fp policies test` は、ポリシーファイルをローカルマシン上で合成イベントに対して実行し、判定結果を確認します。何も公開されず、クラウドにも何も送信されません。 ```bash theme={null} fp policies test ./checkout.policy.mjs --command "git push --force" --expect deny fp policies test ./checkout.policy.mjs --command "git push" --expect allow ``` `--event`、`--tool`、`--command`、`--file` でイベントの内容を指定します。ポリシー自身の `match` フィルターは引き続き適用されるため、指定したイベントをカバーしていないポリシーは判定ではなく `skipped` を返します。これはたいていの場合、`match` の範囲が意図より狭くなっているサインです。 ## 1台のマシンで実行する 次に、自分のマシン上で自分のエージェントに対して実際に適用してみます。 ```bash theme={null} failproofai policies --install --custom ./checkout.policy.mjs --scope project failproofai policies ``` 最初のコマンドはファイルを検証してインストールします。2番目のコマンドは、このマシンで適用されている他のすべてのポリシーとともに、正しく読み込まれたことを確認します。ポリシーがブロックする操作をエージェントに試させて拒否されることを確認し、次に正当な操作を試させて通過することを確認します。他の誰にも影響はありません。 クラウドに接続されたマシンでは、**Observe → policy** で両方の判定結果を確認します。ポリシー名でフィルタリングし、リンクされた各セッションを開いて、マッチしたツール入力と返された理由を確認してください。 ## 壊れたケースをテストする インストールは、ファイルが存在しない場合、構文エラー、未解決のインポート、トップレベルの例外、またはロード中にタイムアウトするモジュールがある場合に失敗します。そのため、ファイルまたはインポートしているものを変更するたびに再実行してください。適用時には、同様に壊れたファイルはログに記録され **skipped** されるため、他のすべてのポリシーは引き続き実行されます。本番ログのロード警告は適用の欠落として扱ってください。Conventionファイルはインストールコマンドなしで読み込まれるため、CIには明示的な `failproofai policies --install --custom ` ステップを含めてください。これが壊れたポリシーでビルドを失敗させる仕組みです。 次に、期待する入力だけでなく、エージェントが実際に送信するものをすべて与えてテストしてください。フィールドの欠落、`Write` や `Edit` などの別のツール名、Windowsパス、不正な形式の入力などです。すべてのコードパスで意図的に `allow`、`instruct`、または `deny` を返し、関数を決定論的に保ち、外部呼び出しには短いタイムアウトを設定してください。 ## 公開して観察する バックテストは、既存のトラフィックに対してポリシーが何をしたかを示しますが、まだ見ていないトラフィックがどう動くかは示せません。エディタで **publish version** を選択（または `fp policies publish` を実行）し、まず **observe** モードで[デプロイ](/ja/policies/deploy)してください。このモードでは判定結果が記録されるだけで何もブロックされません。マッチした結果が安全でない操作と正当な操作を正しく分離できていることを確認してから、実際の適用に切り替えてください。