そのPASSは、実行許可ではない。

AIエージェントに仕事を渡す前に、誰がどの役割を持ち、何を書き換えてよく、どのタスク種別を誰が担当し、誰がレビューするかを、あらかじめ宣言しておく開発チームが増えている。Agent Role Contractsは、その宣言をオフラインで検査するだけのツールだ。何かを実行することはない。

このチェッカーをエージェント実行の手前に置こうとしている人が最初に知っておくべきなのは、PASSがどこまでを保証するかという範囲だ。v0.1.0(コミットc987c44…)の時点で、PASSが保証する範囲はかなり狭い。その狭さは意図したものだ。PASSは、実行したコマンドの範囲内で、宣言に矛盾がなかったことしか意味しない。validateはbundleレベルのrole・authority・route整合性・reviewer宣言・relation cycle・knowledge referenceを検査する。explainはそれにtask routingとwrite scopeの検査を追加する。引き継ぎ(handoff)の整合性は、引き継ぎ文書を渡したときだけ動く独立したhandoffコマンドが検査する。エージェントが動き出してから起きることについて、PASSは何も語らない。

GitHubのv0.1.0は公開済みで、npmレジストリへの登録とインストール検証も完了している。 Agent Role Contractsはsuirindo/agent-role-contractsとしてMITで公開され、正確なHEAD c987c44f4e187a8ec4c8173142dfe1806f8b5125とタグv0.1.0に固定されている。2026年9月30日、@netsujo/agent-role-contracts@0.1.0をnpmレジストリから実際にインストールし、レジストリ配布物のSHA-256がGitHubリリース資産のSHA-256(12c07906…)と一致することを確認した。

• GitHub: suirindo/agent-role-contracts
• npm: @netsujo/agent-role-contracts

スターターを動かす

v0.1.0のスターター一式は、2つのroleを宣言する。implementerは宣言した範囲内でファイルを書き換えられる。reviewerは読み取り専用で、implementerとは異なるrole IDとして宣言される。スターターに含まれる唯一のタスクはimplementerへルーティングされる。

package.jsonが要求するNode.jsは22.5以上で、実行時依存関係もインストールスクリプトも宣言されていない。READMEにはAPIキーもネットワークも不要だとある。npmレジストリが未公開だった段階では、この記事はリポジトリ直下のコマンドしか示せなかった。現在はnpm install @netsujo/agent-role-contracts@0.1.0でインストールしたパッケージから、同じスターターをそのまま実行できる。

npm install @netsujo/agent-role-contracts@0.1.0
node node_modules/@netsujo/agent-role-contracts/bin/agent-role-contracts.mjs validate \
  --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json
node node_modules/@netsujo/agent-role-contracts/bin/agent-role-contracts.mjs explain \
  --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json \
  --task node_modules/@netsujo/agent-role-contracts/examples/starter-task.json --format text

2026年9月30日、Node.js v24でこの手順をそのまま実行した。validateは"valid": trueを返し、explainのテキストレポートには次の一行が出力された。

PASS: explain (declarations only; execution NOT authorized)

両方とも終了コードは0だった。括弧の中はPASS自身が付けた注記であり、JSON出力ではさらに7つの結果フィールドがすべてfalseになる。execution_authorized、runtime_enforcement、identity_verified、evidence_verified、source_files_checked、sensitive_data_scanned、output_schema_validatedだ。

スターターには、あえて失敗するタスクも用意されている。implementerに許可されていない範囲への書き込みを要求するタスクだ。

node node_modules/@netsujo/agent-role-contracts/bin/agent-role-contracts.mjs explain \
  --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json \
  --task node_modules/@netsujo/agent-role-contracts/examples/starter-task-outside-scope.json --format text

結果はFAIL、ルールコードはTASK_WRITE_SCOPE_OUTSIDE_AUTHORITY、終了コードは1だった。公開版のテストが期待する挙動と同じである。

PASSの中身にある規則

v0.1.0(c987c44…)に実装されている規則は、次の領域に分かれる。この表はこの正確なリリースの一覧であり、将来のバージョンでは変わりうる。

公開版が受け入れられたのは、決定的テスト、パッケージとフレッシュインストールのスモーク、宣言されたホスト型プラットフォームでの実行、独立したレビューを経たあとだ。個々のルールコードを、文書化された検査を超える範囲まで読み込まないほうがいい。

コマンドごとに検査する範囲が違う

3つのCLIコマンドは受け取る入力が違い、それぞれ入力が許す規則しか適用できない。

• validateはbundle(--bundle)と出力形式(--format、省略可)を受け取る。ロールとルートの整合性、権限の矛盾、レビュアー宣言、循環参照、ナレッジ参照といったbundleレベルの規則を検査する。タスク文書を持たないため、TASK_TYPE_UNROUTEDやTASK_WRITE_SCOPE_INVALID、TASK_WRITE_SCOPE_OUTSIDE_AUTHORITYのようなタスク依存の検査は動かない。
• explainはタスクを1つ追加で受け取る(--bundle、--task)。そのためタスクのルーティングと書き込み範囲の検査も動く。
• handoffはbundle、タスク、引き継ぎ文書の3つを受け取る(--bundle、--task、--handoff)。引き継ぎ文書を検査できるのはこのコマンドだけで、HANDOFF_*のコードを返せるのもこのコマンドだけだ。

つまり、スターターのexplainがPASSしても、引き継ぎについては何も語っていない。explainには引き継ぎ文書を読む経路がなく、--handoffを渡すとCLI_ERROR、終了コード2になる。スターター自体にも引き継ぎ用のfixtureは含まれていない。公開版が引き継ぎの例として使っているのは、より大きなbundleであるteam.jsonだ。coordinator、implementer、reviewerの3ロールを宣言している。

node node_modules/@netsujo/agent-role-contracts/bin/agent-role-contracts.mjs handoff \
  --bundle node_modules/@netsujo/agent-role-contracts/examples/team.json \
  --task node_modules/@netsujo/agent-role-contracts/examples/task.json \
  --handoff node_modules/@netsujo/agent-role-contracts/examples/handoff.json --format text

2026年9月30日の実行ではPASS: handoff (declarations only; execution NOT authorized)が出力され、終了コードは0だった。役割の間で引き継ぎ文書を渡して仕事を移す運用なら、その文書1つずつをhandoffへ通す必要がある。explainの結果はbundleとタスクだけをカバーし、そこで止まる。

書き込み範囲とhuman_only

書き込み範囲の検査は、タスクがルーティングされた先の実行役がauthority_modeとしてwrite_scopedまたはoperatorを宣言している場合にだけ動く。対象のタスクでは、inputs.scopeにポータブルな相対スコープを1つだけ持たせる必要がある。文字・数字・.・_・-で構成され、先頭は文字か数字、.や..だけのセグメントを含まず、末尾だけ/**にできる。これ以外の値はTASK_WRITE_SCOPE_INVALIDになる。書式は正しくても、実行役のallowed_write_scopesのどれにも含まれない場合はTASK_WRITE_SCOPE_OUTSIDE_AUTHORITYになる。

「含まれる」は2つの宣言のあいだの文字列比較にすぎない。要求されたスコープが、宣言済みスコープと完全に一致するか、末尾が/**で終わる宣言済みスコープの配下にあるかのどちらかだ。チェッカーはファイルパスに一切触れず、globも展開せず、何の権限も付与しない。

human_onlyは機械による権限をゼロにするロールを表す。宣言上、capabilitiesとallowed_write_scopesの両方が空配列になる。人間が判断・承認する地点を示すロールであり、機械が何かを変更する権限は持たない。human_onlyのロールにどちらかの配列へ値を入れると、AUTHORITY_CONTRADICTIONになる。

PASSの外側にあるもの

7つのfalseは、チェッカー自身が「これはやっていない」と出力の形で示しているものだ。PASSは、次の問いも未解決のまま残す。

• 計画した作業が正しいか、安全か、そのモデルに実際にできることか
• bundleで名指しされたレビュアーが、実際のレビュー時点で独立して動いたか
• 身元や証拠が本物か
• ソースファイルを読んだか、秘密情報を探したか
• ランタイムの権限が実際に強制されたか、本番へmergeやdeployをしてよいか
• チェッカー自身に抜けやバグがないか

CLIのヘルプによれば、どのコマンドもエージェントを起動せず、evidenceコマンドやネットワークリクエストを実行せず、ファイルへの書き込みも行わない。ナレッジのURIは取得されないままで、evidenceコマンド文字列は不活性なデータとして扱われる。候補のテストの1つは、コア実装をメモリ上のVMへ読み込みfetchを封じたうえでvalidate・explain・handoffを実行し、アプリケーションI/Oがゼロであることを確認している。

このチェッカーの作り自体に由来する制約もある。スキーマ検証はJSON Schema Draft-07のキーワードのうち閉じた部分集合に限られており、それ以外のキーワードを使ったスキーマは明示的に失敗する。ランタイム固有の検査が把握しているのは、少数の設定キーと.claude・.codexのパス形式だけだ。どれにも当てはまらなければ検査は通過するが、その通過が意味するのはそれだけである。宣言のランタイム中立性を保証せず、セキュリティ上の問題やシークレット、マルウェア、プロンプト安全性もスキャンしない。

終了コードと拒否の実例

CLIのヘルプには3つの終了コードが定義されている。

準備段階の検証と、公開候補の最終受け入れの両方を通して確認された拒否の実例。

• typeに明示ルートがないタスクはTASK_TYPE_UNROUTED(「明示ルートがなく、フォールバックも実行されない」)、終了コード1になった。チェッカーは既定の実行役を勝手に選ばない。
• examples/invalid-self-review.jsonのfixtureはSELF_REVIEW_DECLAREDとREVIEWER_NOT_READ_ONLY、終了コード1になった。
• 未知のフィールドを持つタスクはスキーマエラー、終了コード1になった。
• 存在しないパスを指すタスクファイルはCLI_ERROR、終了コード2になった。
• explainへ--handoffを渡すとCLI_ERROR、終了コード2になった。

パイプラインでは、終了コード0だけを次の工程へ通す。1なら宣言を書いた側へ差し戻す。2ならコマンドラインと入力ファイルを確認する。この終了コードは宣言についての判定を何も持たない。

ランタイムの権限やコードレビューはすでにあるのだから、宣言まで検査する意味は薄いという見方もあるだろう。この検査が加えているのは、タイミングと、結果をきれいに分ける仕組みだ。ロールが自分の仕事をレビューする、書き込み範囲が許可された権限の外にある、タスク種別にルートがない、といった自己矛盾した計画を、エージェントやプロバイダ、ファイルシステムへの操作が起きる前に止める。終了コード1と2は「宣言が誤っている」と「検査自体が走らなかった」を区別したまま保つ。もっとも、これ自体は何かを強制する仕組みではない。ワークフロー側が終了コード0以外での実行開始を拒まない限り、この検査を走らせても何も変わらない。

隣接する問いを担当する既存ページ

周辺の概念については、Netsujoはすでにページを公開しており、このチェッカーはそこへ新しい用語を持ち込まない。各行が、隣接する問いを担当するページと、PASSがその問いに答えられない理由を示す。

このチェッカーはNetsujo Agent OS(日本語のみのページ)でもない。Netsujo自身のAIエージェント開発を支える社内運用基盤だ。候補版のREADMEには、このパッケージは「ランタイムのサンドボックスでも実行コントローラでもなく、既存の社内Agent OSの代替でもない」とあり、続けて「このパッケージは社内設定を一切読み込まない」と明記されている。v0.1のリリース計画が引いた境界は「現行の宣言チェッカーだけを出荷する」というものだ。エージェントの起動やプロバイダ呼び出し、ランタイムやOSレベルの権限強制、身元・証拠の認証、マージ・デプロイの権限、ランタイムアダプタ、コンソール、課金は、すべてv0.1の外にある。

公開状況

ソース権利のゲートはv0.1.0の対象範囲について閉じており、NetsujoはMITでの公開を承認した。非公開の準備用リポジトリをそのまま公開する代わりに、新しい公開履歴を作成している。公開候補は正確にc987c44f4e187a8ec4c8173142dfe1806f8b5125、tree 54d40645161944190e37a3ffc26a110fade580fe、タグv0.1.0に固定されている。

この候補は198件中198件の決定的テストに通過した。pack→fresh install→ルートAPI→スキーマのインポート→通常のCLI→意図的なfail-closedのスモークという順番も通過している。ホスト型のマトリクスは、Ubuntu/Node 22.5、Ubuntu/Node 24、macOS/Node 22、Windows/Node 22のすべてで成功した。独立したレビューが正確な公開HEAD/treeを対象に行われ、P0=0、P1=0、P2=0、APPROVE、SAFE_TO_RELEASE=YESという結果を返している。

GitHubの境界はすでに公開済みで、未認証の読み取りでもリポジトリ本体、MITのLICENSE、v0.1.0タグに紐づくスキーマまで確認できる。

2026年9月30日、npm側の境界も閉じた。レジストリから@netsujo/agent-role-contracts@0.1.0を取得し、配布されたtarballのSHA-256が、GitHubリリース資産のSHA-256(12c07906fd8016f627ebd063248fbe78553bc9d64696e3578911e859f10c31a8)と一致することを確認した。クリーンな環境へnpm install @netsujo/agent-role-contracts@0.1.0でインストールし、validate・explain・handoffのいずれも、リポジトリ直下で実行したときと同じ結果を返した。

残っていたnpmの空白が埋まったことで、この記事が示す挙動は、GitHub上のソースだけでなく、実際にインストールして手元で再現できる状態になった。