監視のみのガバナンスをセットアップする（見るだけでブロックしない）

使用する適用面: 任意の適用面（SDK、ゲートウェイ、コーディングフック） 対応モード: Hosted Hybrid Local プラン: Free Solo Teams

実施すること

英語の原文 -- 翻訳は技術レビュー待ちです

Stand up Control Zero so it watches and records every governed AI and tool call -- and blocks nothing. Every decision lands in the audit log so you can see exactly what your agents do in production, what a stricter policy would have blocked, and where your real risk is, before you ever turn enforcement on.

これは、ガバナンスを一度も導入したことのないチームに導入する最も安全な方法です。初日に誰のワークフローも壊れず、実際のトラフィックに合ったポリシーを書くために必要な根拠を集められます。

このパスが適している理由

• まず可視性が欲しい場合です。「何が起きているか見せてほしい」は、「ブロックして何が壊れたか調べる」より優れています。
• ほかの人のエージェントやノートパソコンに展開していて、初日に誤検知によるブロックを許容できない場合です。
• レビュー、インシデント、コンプライアンスに関する話し合いのために監査証跡が必要だが、ブロックする姿勢にはまだ踏み切れない場合です。
• 本格的な許可リストを作成したいが、エージェントが実際にどのツール、モデル、リソースに触れているかがまだ分からない場合です。

これは、成熟したセキュリティツールの導入の仕方と同じです。まず検知モード、次に適用です。実際のトラフィックを観察し、それに合わせて調整し、その後で初めてスイッチを切り替えます。

このアプローチを使うべきでない場合

注意

監視のみでは、設計上、何もブロックしません。今すぐ止めなければならない既知の危険なアクション（たとえば「エージェントは本番で DROP TABLE を決して実行してはならない」）がすでにある場合は、監視のみで始めず、その 1 つのアクションに対する deny ルールを書き、ほかはすべて許容的なままにしてください。混在した運用方針については、Dev warns, prod denies を参照してください。

監視のみの仕組み

英語の原文 -- 翻訳は技術レビュー待ちです

Control Zero evaluates every call against your policy and records the decision.

呼び出しの判定の後に何が起きるかは、バンドルレベルの 1 つの設定 default_action で制御されます。これは、どのルールにも明示的に一致しない呼び出しの結果を決めます。

default_action	運用方針	どのルールにも許可されない呼び出しへの影響
allow	Observe	呼び出しは続行されます。判定は引き続きログに記録されます。何も壊れません。
warn	Soft	呼び出しは続行されますが、判定にフラグが付き、より厳しいポリシーなら何をブロックするかが分かります。
deny	Enforce	The call is blocked. This is the secure-by-default posture.

すべてを監視するロールアウトでは、default_action: allow を設定します。

英語の原文 -- 翻訳は技術レビュー待ちです

Every call is permitted and every decision is written to the audit trail.

許可してすべて監査するこの構成を、プラットフォームでは監査のみのロールアウトと呼びます。厳格にする準備ができたら、同じポリシーを warn（ブロックされるはずだった呼び出しを表示するソフトロールアウト）に移し、最後に deny に移します。

5分でできるセットアップ

Hosted（ダッシュボード管理）

1. app.controlzero.ai でサインアップし、プロジェクトを作成します（クイックスタートを参照）。
2. ダッシュボードで Project Settings を開き、プロジェクトの適用のデフォルトを Allow (audit-only) に設定します。これは default_action: allow に相当するプロジェクトレベルの設定です。
3. 任意のポリシー（空のスターターでも構いません）をアタッチし、適用面（ゲートウェイ、SDK、またはコーディングフック）を組み込みます。
4. 通常のワークロードを実行します。Audit Log が埋まっていくのを確認します。

デフォルトが allow の間は、何もブロックされません。これで、実際のポリシーを書くために必要なデータを収集できます。

Local / Hybrid（リポジトリ内のポリシーファイル）

この controlzero.yaml をプロジェクトに置きます。すべてをログに記録し、何もブロックしません。

version: '1'
settings:
  # Observation-only: anything no rule matches is allowed and logged.
  default_action: allow
  default_on_missing: allow
  default_on_tamper: warn
rules:
  # A single permissive rule keeps the bundle non-empty and makes the
  # observe-everything intent explicit. Every call is still audited.
  - id: observe-all
    allow: '*'
    reason: 'Observation-only: allow and audit every action.'

エージェントにはほかに何も変更を加えずに、SDK に組み込みます。

from controlzero import Client

# Local mode: policy on disk, audit to a local file. No blocking while
# default_action is "allow"; every guard() decision is still recorded.
cz = Client(policy_file="./controlzero.yaml")

# Your agent calls guard() before each tool call, exactly as it would
# under enforcement. In observation-only the decision is "allow" and the
# call proceeds -- but it lands in the audit log either way.
result = cz.guard("database", method="SELECT", args={"sql": "SELECT id FROM orders"})
print(result.decision)  # "allow"

cz.close()

AI コーディングアシスタントを監視のみで統制するには、フックをインストールして、同じ許容的なポリシーを使用します。フックは 1 つのコマンドで組み込まれます。

controlzero install claude-code

インストーラーはスターターポリシーを書き込みます。監視のみのフェーズでは、これを default_action: allow に緩めてください。

英語の原文 -- 翻訳は技術レビュー待ちです

The assistant keeps working exactly as before; every tool call it makes is recorded.

動作の確認

1. Hosted: プロジェクトの Audit Log を開きます。統制対象の呼び出しごとに 1 行が表示され、decision は allow、ツール、メソッド、タイムスタンプが記録されているはずです。

2. Local: SDK はローテーションする監査ファイル（デフォルトは ./controlzero.log）を書き込みます。次のコマンドでリアルタイムに追います。

   controlzero tail --log ./controlzero.log

3. より厳しいポリシーならブロックすると想定される呼び出し（書き込み、削除、未承認のモデル）が、引き続き許可されてログに記録されることを確認します。これがまさに目的です。何も止めることなく、それらを確認できるようになります。

適用への移行

監視のみは、目的地ではなくスタートラインです。検知モードのセキュリティツールと同じ、推奨される道筋は 3 つのステップです。

1. Observe（観察）。 1 ～ 2 週間、default_action: allow で実行します。エージェントが実際に何をしているかを、監査ログで確認します。

2. Soft rollout（ソフトロールアウト）。 止めたいアクションに対する deny ルールを作成しますが、default_action: warn のままにします。これで、新しいルールがブロックするはずだったすべての呼び出しに、ブロックされることなく、監査ログでフラグが付きます。警告を確認し、allow ルールを広げて誤検知を修正します。

   version: '1'
   settings:
     # Soft rollout: would-be blocks are flagged, not enforced yet.
     default_action: warn
     default_on_missing: deny
     default_on_tamper: warn
   rules:
     - id: allow-reads
       allow: 'database:read'
       reason: 'Reads are fine.'
     - id: block-writes
       deny: 'database:write'
       reason: 'No writes from this agent (soft: surfaced as a warning for now).'

3. Enforce（適用）。 警告が正しく見え、誤検知率が許容範囲になったら、default_action を deny に切り替えます。allow ルールが許可される操作の完全なリストとなり、それ以外はすべてブロックされます。

   version: '1'
   settings:
     # Enforce: only explicitly allowed actions proceed.
     default_action: deny
     default_on_missing: deny
     default_on_tamper: quarantine
   rules:
     - id: allow-reads
       allow: 'database:read'
       reason: 'Reads are the only permitted database operation.'
     - id: block-writes
       deny: 'database:write'
       reason: 'Writes are blocked.'

3 つのフェーズを通じてポリシーファイルは同じで、変わるのは default_action だけなので、ルールを 1 つも書き換えずに、dev、staging、prod へと昇格させられます。

よくある次のステップ

• 「dev ではソフト、prod ではハードな 1 つのポリシーが欲しい」 -> Dev warns, prod denies
• 「最初の本格的な許可リストを書きたい」 -> Read-only database
• 「そもそも組織内で AI はどこで使われている？」 -> シャドーAIの発見
• 「自分の役割に合ったセットアップは？」 -> 役割別セットアップ

リファレンス

• コンセプト: 適用時の動作（default_action / default_on_missing / default_on_tamper の設定項目）
• コンセプト: ポリシー
• ガイド: 完全オフラインで実行する（Local モード）
• API: API リファレンス