EffectFence

EffectFence

公開レジストリ： Retry-Safety Indexには、回答が失われたときに一度だけ支払いを行うエージェント決済実装が掲載されています。安全性が確認されたもの、問題が見つかり修正されたもの（修正までの時間を含む）、検証を受ける方法を確認できます。各項目には、その証拠へのリンクがあります。

あなたのスウォームに必要なのは、記憶力の向上ではありません。ツールの副作用を因果的に制御するフェンスです。

無料： 金銭を動かすクライアント、ファシリテーター、SDK、ツールキットなら、ご自身のものでも他者のものでもご提出ください。内容を確認し、Retry-Safety Indexに無料で判定結果を掲載します。調査結果には、仕組み、ファイルと行番号、失敗するテストが含まれます。修正をリリースするまでは、件数に含めますが、お名前は公表しません。判定を申し込む →

⚡ effectfence — THE STORM
1,000 attempts to charge order #777 ($49.00): concurrent racers + late retries…

ACTUAL EXECUTIONS     :      1   ← the whole point
served sealed receipt :    995
told to stand down    :      4
elapsed               : 22.33ms

💰 double-charges prevented this run: $48,951.00
✅ ONE execution. Every other attempt was fenced, replayed, or refused.

攻撃を自分で実行してみましょう。

cargo run --release --example storm

マルチエージェントの縄張り争い

上の嵐は、ひとつのアクションに複数の競争者がいる状況です。より難しいのは、複数のエージェントが本番環境の同じリソースに対して 矛盾した 判断を下すケースです。これは、現在、本番環境のマルチエージェントシステム全体で報告されている協調の失敗です（2026年のマルチエージェント関連インシデントの約3分の1）。3つの自律型SREエージェントが、ひとつのレイテンシ急増に対応します。

cargo run --example turf_war

Agent A (autoscaler): scale node pool UP
  ADMITTED. Fence leased cluster:prod-us-east-1 — executing kubectl scale up.
  DONE. EffectCert minted — verify() -> true

Agent B (cost-optimizer): scale the same pool DOWN
  REFUSED before kubectl ran:
     read-set for `metrics:prod-us-east-1` is stale: B decided on seq 0, world is at seq 1.

Agent C (deploy-bot): roll the deployment BACK
  C's causal view is concurrent with A's: true
  -> escalated to a human instead of corrupting the cluster.

  Actions proposed: 3   executed: 1   cluster: intended, not corrupted.

各エージェントは、それぞれが読み取った状態に照らせば正しい判断をしていました。協調せずに並行実行すると、3つすべての kubectl 呼び出しが発行され、クラスターはどのエージェントも意図しなかった状態に陥ります。これが1億ドル規模の障害です。フェンスにより、実行できるのは必ず1つだけになり、残り2つは副作用が実行される前に拒否され、その理由も各エージェントに伝えられます。

上記の内容は一切モックではありません。すべて実際のクレートAPIを呼び出しています。

EffectFenceは、複数エージェントによるツール呼び出しのための因果的な並行制御フェンスです。複数のエージェント（またはリトライ、再ディスパッチ）が、同じ副作用を伴う操作（カードへの請求、送金、リソースのプロビジョニングなど）を実行しようとする可能性がある場合、EffectFenceはその操作を実行する試みが必ず1回だけとなるよう保証します。同時に発生した競合はアトミックな比較交換による予約で決着し、遅れて到着した重複呼び出しには、再実行する代わりに記録済みの結果を再生します。実行されたすべての効果には、因果的に基づく対象と連鎖したコンテンツアドレス指定可能な証明書が付与されます。

Rustライブラリ（effectfence::fence）と、3つのツール（fence_prepare、fence_commit、fence_abort）を公開するstdio MCP サーバーとして提供されています。これにより、エージェントは副作用を伴うツール呼び出しを互いに直接競合させるのではなく、フェンス経由で処理できます。

問題

マルチエージェントゲートウェイでは、複数の呼び出し元が同じ効果を実行しようとする可能性があります。

• 2つのエージェントが独立して、「注文 #123 の顧客への請求が必要だ」と判断し、同時に実行しようとします。
• スーパーバイザーがツール呼び出しの応答を待つ間にタイムアウトし、元の呼び出しがまだ処理中なのに再ディスパッチします。
• イベントのリトライや重複によって、最初の試みがすでに成功してから数分後に、同じ判断が再び実行されます。

単純な実装では、どの場合も効果が二重に実行されます。結果を記憶せずに重複をすべて拒否するのも誤りです。最初の試みがクラッシュした場合は効果が一度も実行されず、成功後に届いた重複には必要な結果ではなくエラーが返されます。EffectFenceは、楽観的並行制御（OCC）とインテント台帳を組み合わせて、これらすべてを解決します。試み同士はブロックせず、実行されるのは必ず1つだけで、残りのすべての試みには実際に何が起きたかが伝わります。

アーキテクチャ

フェンシングプロトコルは、次の4つの要素で構成されています。

インテント台帳は、競合だけでなく、重複も防ぎます。すべての効果には intent が付与されます。これは論理アクションの安定した ID です（例："charge:order-123"）。同じインテントを共有する試行は、同一のアクションです。最初の試行が許可され、リースを保持します。同時に到着した重複試行には、試行が進行中であることが通知されます。成功後に到着した重複試行には、記録済みの証明書がそのまま再送されます。失敗後の重複試行は、明示的に解除されるまでフェンスされます（副作用が発生したかどうかは不明な場合があるため、無条件に再試行するのではなく、照合する必要があります）。保持者がクラッシュした場合は、TTL の経過後にリースが失効するため、アクションが永久に滞留することはありません。

ベクトルクロック（VectorClock）は、エージェント間の因果関係における「先行関係」を追跡します。エージェントごとに1つの論理カウンターを持ち、要素ごとの最大値を取る merge で結合し、部分順序 le で比較します。また、順序付けられないイベントを判定する concurrent チェックと、証明書に含めるための安定した SHA-256 digest も備えています。

OCC の読み取りセット（ReadSetEntry）は、決定の基になった因果依存関係を記録します。「アクションを実行すると決めた時点で、ドメイン D はシーケンス S にありました」という情報です。prepare_effect_fence と commit_effect_cert はどちらも、すべてのエントリーをライブ状態と照合します。変更があれば、古い情報に基づいて処理を実行させるのではなく、試行を古い状態として拒否します。

CAS によるドメインフェンシングは、同時に発生した競合を裁定する仕組みです。各ドメイン（名前付きの競合範囲。例："order:123"）には、AtomicU64 のシーケンスカウンターがあります。決定は単一のアトミックな compare_exchange で行われます。任意の期待シーケンスに対して、同時に呼び出された1つだけが成功できます。（精度に関する注記：カウンターの参照には短時間のミューテックスを使用します。ロックフリーなのは競合の決定自体のみです。完全にロックフリーな経路のアイデアを歓迎します。）

              ┌ intent gate ──────── already done? → Replay(recorded cert)   [do NOT run]
              │                      in flight / failed? → rejected          [do NOT run]
 EffectRequest┤
              ├ read-set check ───── dependency moved? → ReadSetStale        [do NOT run]
              │
              └ domain CAS ────────── lost the race? → DomainRace            [do NOT run]
                     │
                     └ Fresh(ticket) → run the effect → commit_effect_cert → EffectCert
                                                      ↘ abort_effect (failed; fenced until reconciled)

コミットされたすべての効果は EffectCert になります。これは {intent, parent, domain, seq, tool, args, result, vector_clock, read_set, agent} の内容に対する SHA-256 コンテンツハッシュで、因果関係の系譜を示すために parent 証明書ハッシュでチェーンされます。同じハッシュを持つ2つの証明書は、定義上、同じ効果の記録です。EffectCert::verify() はハッシュを再計算し、改ざんされていないこと、および手動で誤って構築されていないことを確認します。

対象範囲

これは単一プロセスのフェンスであり、永続的な台帳を備えています。すべての受け付け、結果、オペレーターによるクリアは JSON Lines ファイルに追記され、フェンスが応答する前に fsync されるため、プロキシを再起動しても、すでに実行された処理は記録に残ります。再起動後に重複が発生した場合は、再実行されず、記録が再生されます。プロセス終了時に実行中だった処理は、次回起動時に結果不明としてフェンスされます。保持していたプロセスは消えており、処理の効果が発生したかどうかを判断できないため、オペレーターが照合してクリアするまで保留されます。（ライブラリの利用者向け：EffectFence::open(path, config)。EffectFence::new() は引き続きメモリ内で動作します。同梱バイナリは $EFFECTFENCE_LEDGER を使用し、未設定の場合は ~/.local/state/effectfence/<name>.jsonl を使用します。EFFECTFENCE_LEDGER=memory を指定すると、永続化されません。）意図的に対応していないことが 2 つあります（現時点では）。

• 複数レプリカのフェンシング。 台帳は 1 つのファイルなので、複数レプリカを同時に保護するのではなく、1 つのゲートウェイプロセス（再起動をまたいで）を保護します。水平スケーリングされたゲートウェイには、同じインテント／ドメイン／読み取りセットのモデルを共有ストアで支える必要があります（例：Redis の SETNX+CAS、または Postgres の楽観的バージョン列）。ここにある型は、そのバックエンドにもそのまま適用できるよう設計されています。
• リース期間を超えて存続する保持プロセス。 実行中のリースは期限切れになると取得可能になります。これによってクラッシュから復旧できますが、期限切れになっても、保持プロセスが停止したのか、単に FenceConfig::lease_ttl（デフォルトは 60 s）より遅いだけなのか、フェンスには分かりません。そのため、何も通知せずにリース期間を超えて実行される処理は、別のプロセスに引き継がれて 2 回実行されます。これはまさに、このクレートが防ごうとしている事態です。対処法は 1 つ、処理の実行中に EffectFence::heartbeat(intent) を呼び出すことです（リース期間の約 3 分の 1 ごと）。wrap は転送するすべての呼び出しで自動的にこれを行います。fence_prepare を直接実行するエージェントは、fence_heartbeat ツールを呼び出してください。ハートビートが止まると予定どおりリースが期限切れになるため、本当に停止した保持プロセスは引き続き復旧されます。
• 強制。 フェンスは、処理を通過させるエージェントを保護します。フェンスを完全に迂回するエージェントを止めることはできません。エージェントが共有する唯一の関門（ツールを所有するゲートウェイプロセス）に導入してください。

メモリ使用量には上限があります。完了した結果は設定可能な TTL（FenceConfig::result_ttl）後に期限切れとなり、EffectFence::sweep によって一掃されます。クエリによって追跡状態が作成されることはなく、ドメインカウンターは小さく、手動で削除できます（evict_domain）。

クイックスタート：ライブラリ

use effectfence::fence::{
    prepare_effect_fence, commit_effect_cert, Admission, EffectFence, EffectRequest, VectorClock,
};

let fence = EffectFence::new();

let req = EffectRequest {
    intent: "charge:order-123".into(),   // same action -> same intent, always
    parent: None,                        // hash of the cert this follows, if any
    domain: "order:123".into(),          // contention scope
    tool: "charge_card".into(),
    args: serde_json::json!({"amount_cents": 1999}),
    read_set: vec![],                    // other domains this decision cross-checked
    agent: "agent-a".into(),
    known_clock: VectorClock::new(),
};

match prepare_effect_fence(&fence, req)? {
    Admission::Fresh(prepared) => {
        // This attempt won. Actually run the charge...
        let cert = commit_effect_cert(
            &fence,
            prepared,
            serde_json::json!({"charge_id": "ch_123"}),
        )?;
        assert!(cert.verify());
        // (on failure: abort_effect(&fence, prepared, "why") instead)
    }
    Admission::Replay(cert) => {
        // This exact action already ran -- use cert.result, charge nothing.
    }
}

同じインテントが並行して重複した場合は Err(FenceError::IntentInFlight) が返されます。ドメイン上で同時に競合した場合は Err(FenceError::DomainRace) が返されます。いずれの場合も、処理を実行してはなりません。

10 秒で試す（インストール不要、実際の処理は発生しません）

cargo install effectfence   # or: npx -y effectfence demo
effectfence demo

12 個のエージェントが同時に 49 ドルの請求処理を試みます。組み込みサーバーに生のまま送信すると、12 件すべてが重複請求されます。その後、同じ 12 件の呼び出しをフェンス経由で実行すると、ちょうど 1 件だけになります。このバイナリは自身に対して通信するため、実際の呼び出しは発生せず、動作を確認するためにサーバーを用意する必要もありません。

── Act 1: the raw server, no fence ──
  DISTINCT effects    : 12      PROVEN DOUBLE-FIRE
── Act 2: the SAME twelve calls, behind the fence ──
  DISTINCT effects    : 1       12 callers, 12 clean answers, one execution

まず、あなたのスタックで本当に二重実行が起きるか確認しましょう（プローブ）

フェンスを導入する前に、自分のサーバーで検証してください。デモではなく、実際に必要かどうかを確かめましょう。 probe はシンプルな MCP クライアントです。任意の MCP サーバーを指定すると、1 つのツールに対して、バイト単位で同一の呼び出しを N 個並行して実行します。これは、2 つのエージェントが同じアクションを試みた瞬間に発生する競合を再現し、実際に反映された個別の処理数を報告します。

effectfence probe --tool charge_card --args '{"amount":4900}' --calls 12 -- npx -y @your-org/your-mcp-server

EffectFence probe — twin-caller race report
--------------------------------------------
  identical calls   : 12
  DISTINCT effects  : 12

  PROVEN DOUBLE-FIRE. 12 byte-identical calls produced 12 DIFFERENT
  results. Each distinct result is a separate real execution of one
  intended action — the duplicate side effect you cannot take back.

指定した 1 つのツールだけを、指定した引数そのままで呼び出します。サーバーを無差別に列挙して連続呼び出しすることはありません。また、確認できることだけを正直に報告します。異なる結果が得られれば、二重実行が起きた確かな証拠です。同一の結果の場合は、ゼロ件だと証明できないため、応答からは判定不能と報告します。

次に、同じプローブをフェンス経由で再実行し、DISTINCT effects が 1 に減ることを確認してください。

effectfence probe --tool charge_card --args '{"amount":4900}' --calls 12 -- effectfence wrap -- npx -y @your-org/your-mcp-server

これが、2 つのコマンドだけで伝えたいことのすべてです。まず実行の痕跡を確認し、次にロックします。

クイックスタート：既存の MCP サーバーをラップする（まずはこちら）

EffectFence を使う最も手早い方法は、すでに実行しているツールサーバーの前段に配置することです。エージェントが何かを呼び出すことを覚えておく必要はありません。すべてのツール呼び出しが自動的にフェンスされます。

agent/client ──MCP──> effectfence wrap ──MCP──> your real tool server

cargo install effectfence

次に、危険なツールを持つ任意のサーバーをラップします。

effectfence wrap -- npx -y @your-org/your-mcp-server

ツール一覧は子サーバーのものと1対1で同じです（名前、スキーマ、ドキュメントも同じ）ので、エージェント側を変更する必要はありません。変わるのは、同一の重複呼び出し（同じツール、同じ引数）は子サーバーで一度だけ実行され、後続の重複呼び出しには記録済みの結果が再生されることです。また、同時に発生した同一の呼び出しは、二重実行を防ぐため拒否されます。

ワンペーストの手順：クラスターを変更するサーバーをフェンスする

この仕組みが必要となるのは、複数のエージェントが同じクラスターで kubectl を使うケースです。

Claude Code：

claude mcp add k8s-fenced -- effectfence wrap -- npx -y kubernetes-mcp-server

Cursor（~/.cursor/mcp.json）または Claude Desktop（claude_desktop_config.json）：

{
  "mcpServers": {
    "k8s-fenced": {
      "command": "effectfence",
      "args": ["wrap", "--", "npx", "-y", "kubernetes-mcp-server"]
    }
  }
}

kubernetes-mcp-server を、書き込みを伴うツールを持つ任意のサーバー（クラウド API、デプロイツール、決済サーバーなど）に置き換えてください。すべてのエージェントをフェンスされた名前に接続し、未加工のサーバーにはアクセスできないようにします。フェンスが唯一の入口でなければ、フェンスの意味がありません。

fence_stats で動作を確認できます（下記参照）。replayed と refused は、実行されなかった重複呼び出しの数です。

ラップの適用範囲について

現時点ではツールのみが対象です（リソース／プロンプトのパススルーには対応していません）。意図は hash(tool + canonical args) から導出されるため、バイト単位で同一の引数は同じアクションとして扱われます。エージェントが引数のタイムスタンプを変えると重複排除は機能しませんが、その場合も安全側に失敗します。呼び出しは実行されますが、何も破損しません。状態はラップ対象のコマンドごとに永続化されます（子サーバーのコマンドごとに台帳ファイルが1つ作成されるため、同じ名前のツールを持つ2つのサーバーが互いをフェンスすることはありません）。本番環境を変更するツールのセットごとに、フェンスされたゲートウェイを1つ実行してください。

転送された呼び出しは子サーバーの実行中にハートビートを送るため、リースより時間がかかるツールも、引き継がれて二重実行されることなく要求を保持できます。必要に応じて、どちらの期間も明示的に設定できます。EFFECTFENCE_LEASE_SECS（デフォルトは 60）と EFFECTFENCE_RESULT_TTL_SECS（デフォルトは 86400）です。EFFECTFENCE_LEDGER では永続台帳の保存先を設定します（デフォルトは ~/.local/state/effectfence/wrap-<hash>.jsonl、無効にするには memory を指定します）。wrap を再起動すると、すでに実行された処理の結果が再生され、停止時に呼び出し中だった処理はフェンスされます。

---

クイックスタート：MCP サーバー（明示的なフェンス）

wrap が自動的に導出するものよりも細かな制御（read_set、parent、known_clock）を使って、エージェントに明示的にフェンスさせたい場合に使用します。

公式 MCP Registry に mcp-name: io.github.aurumflux20/effectfence として登録されています。

インストール

Rust ツールチェーンを使う場合（rustup.rs）：

cargo install effectfence

または、このリポジトリをクローンしてビルドします。

cargo build --release   # binary at ./target/release/effectfence

Claude に追加する

Claude Code（コマンド1つ）：

claude mcp add effectfence -- effectfence

（cargo install ではなくソースからビルドした場合は、フルパスを使ってください：claude mcp add effectfence -- /path/to/target/release/effectfence。）

Claude Desktop — claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "effectfence": {
      "command": "effectfence"
    }
  }
}

任意のプロジェクト（チームで共有） — プロジェクトのルートに .mcp.json をコミットします。

{
  "mcpServers": {
    "effectfence": {
      "command": "effectfence"
    }
  }
}

これで完了です。アカウントも必須の設定もありません。サーバーは台帳を ~/.local/state/effectfence/server.jsonl に保持するため（EFFECTFENCE_LEDGER で変更可能）、すでに実行された処理はサーバーを再起動しても保持されます。

ツール

以下を公開します。

• fence_prepare — { intent, domain, tool, args, agent, read_set?, parent?, known_clock? } → この試行が勝者の場合は {status: "fresh", prepared}（ツールを実行してから結果を報告してください）、この完全に同一のアクションがすでに実行されている場合は {status: "already_done", cert}（記録された結果を使用し、ツールは実行しないでください）。エラーが発生した場合は実行しないでください。

• fence_commit — { prepared, result } → {status: "committed", cert}。以降、同じ intent の重複はこの cert を再生します。

• fence_abort — { prepared, reason } → {status: "aborted"}。intent は調整して解除されるまでフェンスされたままです。

• fence_stats — 引数なし → プロセス開始以降のリアルタイムカウンター： admitted（実行された副作用）、replayed（記録済みの結果が渡された重複）、 原因別に分類された refused（stale_read_set、domain_race、in_flight、 prior_failure）、さらに total_attempts と prevented。重要なのは prevented の数です。副作用が実行されなかった試行の総数を示します。

  effectfence since boot: admitted=1 replayed=995 refused(stale=0 race=4 in-flight=0 failed=0) total=1000 prevented=999
  

ツールの入力スキーマは Rust の型から（schemars を介して）自動生成されるため、どの MCP クライアントからでも tools/list でイントロスペクトできます。

テスト

cargo test    # unit tests + chaos tests
cargo clippy --all-targets

tests/chaos_test.rs は実際の OS スレッドを使って、2 つの保証をそれぞれ検証します。強制的に同時刻に発生させるドメイン競合（衝突が起きることを期待するのではなく、必ず起きるよう意図的に同期を構成）では、毎回ちょうど 1 つの試行だけが勝者として認められます。また、1 つの intent に対する 16 個の同時重複試行では、ちょうど 1 回だけ実行が認められ、後から届いた重複試行にはコミット済みの cert が再生されます。さらに、32 スレッドのストレステストでは、シーケンス番号が重複して割り当てられないことも確認します。

独自の MCP サーバーをスキャンする

tools/fencescan.py は、同じ副作用を 2 回発生させる可能性のある MCP サーバー内のツールを見つけます。インストール不要、依存関係なし、ネットワーク接続なしで使えます。

python3 tools/fencescan.py /path/to/your-mcp-server

根拠を伴う候補を報告しますが、意図的に判定は行いません。リポジトリを読むだけの外部の人には、通常、二重実行を証明できないためです。ガードは多くの場合、リポジトリが呼び出すサービスや兄弟関係にある SDK にあり、書き込みを行うような名前のツールでも、別の人が署名するためのペイロードを返すだけかもしれません。出力には、確認できない対象も明示的に列挙されます。

手作業で検証した結果、最初の 7 件の「確定」のうち 4 件が誤りだと判明したため、書き直しました。それぞれの失敗は、今では注意書きではなく修正済みの動作になっています。

誤った内容	理由	現在の動作
読み取り専用ツールにフラグを立てた	ツール名の後の範囲を単純に切り取っていたため、次のツールまで対象になり、読み取りツールが書き込み用の語彙を引き継いでいました	波括弧を対応付けて各ツール固有のブロックを識別します。名前に読み取りを表す動詞があれば対象から除外します
冪等性を扱うモジュール全体があるリポジトリを、冪等性がないと判定した	\b(idempot…) は deriveIdempotencyKey に一致できません。camelCase の大文字の前には単語境界がないためです	アンカーを削除しました。同じ見落としで requestId と clientToken も検出できていませんでした
書き込みが一切ないと判定した	書き込み処理はツール宣言ではなく、共有ヘルパーにあります	リポジトリごとに補足情報として収集します。「このツールが書き込む」とは主張しません
method: cond ? "POST" : "GET" を見落とした	一致判定の前に文字列リテラルを除去していたため、HTTP 動詞そのものが削除されていました	加工前の行を対象に一致判定します
「AT RISK」と表示した	これは非難にあたる表現であり、7 件中 4 件で誤っていました	判定フィールドはありません

お使いのサーバーで何かにフラグが立ち、別の人にも確認してほしい場合は、issue を作成してください。誤った指摘は見落としよりも大きな損害につながるため、ここでの誤検出も報告する価値があります。

関連プロジェクト — once（Python）

同じ課題を、別のランタイムで解決します。once（pip install once-kernel）は、同じ考え方に基づく Python 製の冪等性カーネルです。リトライ、Webhook の再配信、並行ワーカーのもとでも、副作用を正確に 1 回だけ実行します。耐久性をさらに高めており、Postgres ストア、リースが再取得された後に古いワーカーが復活できないようにするフェンストークン付きハートビートリース、RFC 8785 準拠の正規化されたペイロードフィンガープリントを備えています。

フェンスが Rust 内、または MCP サーバーの前段にある場合は EffectFence を、Python で副作用を実行し、永続ストアが必要な場合は once を使用してください。effectfence wrap が once 自身の MCP サーバーをフェンシングできることは実証済みです。

商用サポート

ライブラリは無料で、今後も無料です。

リトライ安全性レビュー — $1,200。問題が見つからなければ全額返金します。 コードベース内の資金に関わる処理を 1 つ読み、優れたエンジニアリングをもってしても残る欠陥を探します。「冪等性キーがあるかどうか」ではなく（大半の優れたチームにはあります）、支払いが曖昧な状態で失敗したときに何が起きるかを調べます。決済が完了した後にタイムアウトしたリクエスト、新しいノンスを生成するリトライ、実際には失敗していなかった処理の失敗を理由に解放される予約などです。5 営業日で、お客様のファイル名と行番号に紐づけた書面のレポートを提出します。通話はありません。

私たちが公開の場で調査しているのは、まさにこの種の欠陥です。hpp-io/x402-mcp-bridge では調査結果に基づく 2 つの修正がリリースされ、mcp-server-kibana では 2 件の PR がマージされました。詳細はSUPPORT.mdをご覧ください。開始するには、こちらから予約し、領収書への返信でリポジトリと、最も重要な資金関連の処理をお知らせください。事前に相談したい場合は、まず[email protected]までメールでお問い合わせください。

適合しない場合はその旨をお伝えします。また、何も見つけられそうにないと判断した場合は、問題がなかったという結果に対して請求するのではなく、その旨をお伝えします。

ライセンス

MIT — LICENSEをご覧ください。