AIガバナンスが効かない4類型と検証手順

TL;DR

• 規約・権限・ガードを「定義した」ことと、それが「効いている」ことは別の状態です。
• 宣言と実効の乖離は4類型に分けられます。ルールのシャドウ / 規約と設定の不一致 / ガードの未実行 / 診断の風化。
• 多くはバグではなく、仕様と運用者のメンタルモデルの乖離として起きます。
• 4ステップの実測で乖離は検出でき、うち3類型はそのまま CI の自動検知に落とせます。

はじめに：AIガバナンスが「効かない」と感じるとき何が起きているか

規約を書いた。権限も設計した。CI にガードも入れた。それでも確認プロンプトは減らず、同じ種類の事故が繰り返される。この記事は、その状態に心当たりのある Tech Lead / EM / OSS Maintainer に向けたものです。

原因は施策そのものではなく、測り方にあります。ガバナンス施策は宣言、つまりドキュメントや設定ファイルに書いた時点で完了扱いされます。しかし本当に問題なのは実効、実行時に実際どう評価されるかです。この差を本記事では一貫して乖離と呼びます。

DORA の 2025 年レポートは AI を増幅器（amplifier）と位置づけ、強い組織の強みも、弱い組織の機能不全も同じように増幅すると述べています（DORA Report 2025、確認日 2026-09-04）。宣言だけで止まっているガバナンスは、エージェントの実行速度に比例して機能不全のほうを増幅します（開発者の 30% が AI 生成コードをほとんど信頼していないという調査もあります。公式値、Balancing AI tensions、確認日 2026-09-04）。

この記事で扱わないこと: 権限マトリクスの設計方法、リスク分類とリリースゲート、KPI の指標設計、MCP や token scope の認可プロトコル設計、hook の実装チュートリアル、組織論。いずれも既存記事に委譲します。権限を定義する側は前工程の 権限マトリクスとガードレール設計 を先に読んでください。

乖離の4類型 — 宣言と実効はどこで離れるか

自リポジトリで実際に発生した事象を分類すると、乖離は4つの類型に収まりました。

a から c は設定やログから機械的に検出できます。d だけは検出対象が人間の書いた記述であり、防止策も運用ルールになります。この非対称性そのものが、ガバナンスの実効性が落ちる最後の抜け道です。

宣言（規約・設定・ガード）が実効に変換される過程と、4類型が発生する位置

類型a: ルールのシャドウ — 許可したはずのコマンドで確認が出る

もっとも頻度が高く、もっとも誤解されやすい類型です。結論から言うと、これは仕様どおりの挙動を運用者が読み違えた結果であり、実装の欠陥ではありません。

Claude Code の公式ドキュメントは評価順序をこう定義しています（Permissions、確認日 2026-09-04）。

Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order.

重要なのは後半です。ルールの具体性は評価順序を変えません。 同ドキュメントは ask と allow のあいだにも同じ優先順位が適用され、より具体的な allow が同じ呼び出しにマッチしていても、マッチする ask があればプロンプトが出ると明記しています。広い ask は狭い allow を覆い隠す。この現象を本記事ではシャドウと呼びます。

自リポジトリでも同じことが起きていました。ask に置いた Bash(pnpm:*) 1件が、allow に個別登録した4件（pnpm test / pnpm run lint / pnpm run format / pnpm build）をすべて覆っていました（社内データ、ref: commit affc6b2）。Bash(git stash:*) も読み取り専用の git stash list を確認対象にしていました。修正は ask を変更系だけに絞ることです。

修正前（広い ask が allow を覆っていた状態）:

{
  "permissions": {
    "allow": ["Bash(pnpm test:*)", "Bash(pnpm run lint:*)",
              "Bash(pnpm run format:*)", "Bash(pnpm build:*)",
              "Bash(git stash list:*)"],
    "ask":   ["Bash(pnpm:*)", "Bash(git stash:*)", "Bash(mkdir:*)",
              "Bash(git checkout:*)", "Bash(git push:*)"]
  }
}

修正後（ask を変更系だけに絞り、allow が実効するようにした状態）:

{
  "permissions": {
    "allow": ["Bash(pnpm test:*)", "Bash(pnpm run lint:*)",
              "Bash(pnpm run format:*)", "Bash(pnpm build:*)",
              "Bash(git stash list:*)", "Bash(mkdir:*)"],
    "ask":   ["Bash(pnpm install:*)", "Bash(pnpm add:*)", "Bash(pnpm remove:*)",
              "Bash(pnpm update:*)", "Bash(pnpm dlx:*)",
              "Bash(git stash push:*)", "Bash(git stash pop:*)",
              "Bash(git stash drop:*)", "Bash(git stash clear:*)",
              "Bash(git checkout:*)", "Bash(git push:*)"]
  }
}

破壊的でない mkdir は ask から allow へ移し、git checkout / git rebase / git push / git merge、gh pr create / gh pr merge は確認必須のまま維持しました。実効性を上げる作業は、確認を減らす作業ではありません。

同じ公式ドキュメントには派生形が2つ記載されています。いずれも「書いたつもりのルールが、書いたとおりには効かない」構図です。

• 広い deny は allowlist 例外を持てない: Bash(aws *) の deny は、より狭い Bash(aws s3 ls) の allow にマッチする呼び出しもすべてブロックします。
• 設定は scope ごとに上書きではなくマージされる: user 設定の deny は project 設定の allow をブロックし、逆も成り立ちます。設定が複数スコープに分散していると、どこでシャドウされているかが手元のファイルからは見えません。

allowlist の粒度設計は MCP権限設計の判断基準 に整理しています。本記事は、粒度を決めたあとに実効しているかを測る側です。

類型b: 規約と設定の不一致 — SSoT が機械可読でない

規約ファイルと設定ファイルは別々に管理され、片方だけが更新されます。これが類型bです。

自リポジトリの AGENTS.md:138 は、ブランチ切替について git worktree add を必須と規定しています。並行セッションが同じワークツリーでブランチを切り替えると、commit が意図しないブランチに着地するためです。ところが、ある PR の初版では設定側の allow に Bash(git checkout:*) と Bash(git switch:*) が入っていました。自動レビューが SSoT 違反として指摘し、両ルールとも allow から除外されました。

注目すべきは、これがレビューで偶然拾えただけだという点です。規約は自然言語、設定は機械可読という非対称があり、両者を突き合わせる仕組みは存在しませんでした。属人的な検出は実効性の担保になりません。

同種の乖離は特定ツール固有の話ではありません。GitHub Copilot のリポジトリカスタム指示も、リクエストに自動で追加される一方で個人指示のほうが優先されると明記されています（Adding custom instructions、確認日 2026-09-04）。

OSS には先行回答があります。AI contributor を前提にしたプロジェクトでは、レビュー thread の resolve に commit SHA を要求するなど、規約を強制力のある仕組みへ落とす実践が公開されています（Your contributors are AI-first、確認日 2026-09-04）。社内でも、規約の文言に対応する機械検証を1つ用意できるかが分岐点です。

類型c: ガードの未実行 — 動いているのに原因を取り違える

ガードは実在し、正しく動いていた。それでも乖離が起きた、というのが類型cです。

自リポジトリの .github/workflows/readme-sync-check.yml は、content/posts/** などに変更があるのに同ディレクトリの README.md が更新されていなければ fail する差分検査です。エラーメッセージには修正手順まで書かれています。

::error::Changes detected in content/posts/ without corresponding updates in content/posts/README.md.
::error::Fix: run `python3 .agents/update_readmes.py` locally, commit the regenerated README.md, and push.

にもかかわらず、この失敗は長期間「main に遅れた PR の誤検出」と診断され、git rebase main で解こうとして解決しませんでした。正解は README の再生成です。ガードは何も壊れておらず、原因分析の側が外れていました。

教訓は1つです。ガードの失敗は、ガードが壊れている証拠にはならない。 最初に読むべきはガードの実装とエラー出力であり、周辺状況からの推測ではありません。裏を返せば、ガードの出力を読む導線が設計されていなかったということです。

層の違いも見落としの原因になります。公式ドキュメントによれば、PreToolUse hook の判断は permission rule を迂回しません。hook が allow を返しても、マッチする deny はブロックし、マッチする ask はプロンプトを出します（Permissions、確認日 2026-09-04）。ガードを書いた層と結果を決める層は別でありえます。hook の実装詳細は Claude Code hooks 実践 を参照してください。

なお「ガードは存在するが required status check として必須化されておらず実質スキップできる」というブランチ保護レイヤーの乖離も同系統ですが、本記事では扱いません。この類型をガードスクリプトと CI 配線に絞って分解したものは 効いていないガードを見つける7つの型 にあり、死んだ分岐・常に真の述語・発火点が無い、など 7 通りの壊れ方を PR 番号つきで分類しています。

類型d: 診断の風化 — 誤った原因分析が再配布される

類型cの誤診断は、そこで終わりませんでした。作業メモに記録され、後続の作業指示の前提として引き継がれ、次の担当者が同じ回り道を再現しました。これが類型dです。

cとdの違いは、単発か伝播かにあります。cは1回の取り違えです。dは、その取り違えが検証されないまま複製される現象を指します。誰かのミスというより、検証されない記述は複製されるという情報流通の性質の問題です。

AI エージェント運用ではこの性質が増幅されます。作業メモがそのままコンテキストとしてエージェントに投入されるため、誤診断の複製速度は人間だけのチームより速くなりやすい状況です。規約・エージェント定義・作業メモをどこに置くかという配置設計は AIが迷わないリポジトリ設計 で扱っています。

対策は単純です。原因分析には ref（commit SHA / ファイル:行 / ログ出力）を必ず添える。ref のない診断はメモに残さない。これだけで、後続が真偽を確かめる導線が確保されます。

乖離を測る4ステップ（45分の実測手順）

前提: jq と Python 3.10 以降、および認証済みの gh CLI（gh auth login 済み。Step 4 で使います）が使える環境。対象は自リポジトリの permission 設定・規約ファイル・ワークフロー定義。所要は約45分です（経験則。設定ファイルが数個規模のリポジトリで、Step 1 から Step 3 に約30分、Step 4 に約15分）。設定ファイルが数十個ある大規模リポジトリでは、Step 1 の棚卸しだけで超過します。

Step 1: 宣言の棚卸し — ルールを機械可読な一覧にする

入力: permission 設定（.claude/settings.json など）、規約ファイル（AGENTS.md / CLAUDE.md）、ガード（.github/workflows/**）。

操作: permission 設定から allow / ask / deny を種別付きで抽出します。

# ルールを「種別 <TAB> ルール」の一覧に落とす
jq -r '.permissions | to_entries[] | select(.value | type == "array")
       | .key as $kind | .value[] | "\($kind)\t\(.)"' \
  .claude/settings.json | sort

select(.value | type == "array") は省略できません。permissions には配列以外に "defaultMode": "default" のような文字列値も入るため、外すと Cannot iterate over string で落ち、出力が0行になります。

確認方法: 出力行数と設定ファイルのルール総数が一致すること。ここで漏れると以降のステップがすべて過小評価になります。

設定は scope ごとにマージされるため、ファイルは1つとは限りません。user スコープと project スコープの両方を棚卸し対象に含めてください。片方だけを見て「allow に入っているから効いている」と結論づけるのが、類型aのもっとも典型的な入口です。

Step 2: 実効の測定 — シャドウを検出する（類型a）

操作: 評価順序 deny → ask → allow を前提に、allow の各エントリがより広い ask / deny にマッチしないかを突き合わせます。以下は既製品ではなく本記事で提示する実装例です。自分のリポジトリに scripts/detect_shadowed_allows.py として保存してから実行してください（後半で示す GitHub Actions ワークフローも同じパスを前提にします）。

#!/usr/bin/env python3
"""allow ルールが、より広い deny / ask に覆われていないかを検査する。
出力は「シャドウの疑いがある候補」であり、最終判定は人間が行う。"""
import json
import re
import sys

RULE = re.compile(r"^(?P<tool>[A-Za-z_]+)\((?P<pattern>.*)\)$")


def tokens(rule):
    """ルールを [tool, サブコマンド...] のトークン列に分解する"""
    matched = RULE.match(rule)
    if not matched:
        return None
    body = matched.group("pattern").replace(":", " ")
    return [matched.group("tool")] + body.split()


def covers(broad, narrow):
    """broad が末尾ワイルドカードで narrow を前方トークン一致で包含するか"""
    if broad[-1] != "*":
        return broad == narrow
    head = broad[:-1]
    return len(narrow) >= len(head) and narrow[: len(head)] == head


permissions = json.load(open(sys.argv[1]))["permissions"]
allow_rules = [(r, tokens(r)) for r in permissions.get("allow", [])]

for kind in ("deny", "ask"):
    for broad_rule in permissions.get(kind, []):
        broad = tokens(broad_rule)
        if not broad:
            continue
        for rule, narrow in allow_rules:
            if narrow and narrow != broad and covers(broad, narrow):
                print(f"[{kind}] {broad_rule} が allow の {rule} を覆っている可能性")

確認方法: python3 scripts/detect_shadowed_allows.py .claude/settings.json を実行し、出力された候補を1件ずつ公式の評価順序に照らして判断します。

このスクリプトの既知の限界は本文に明記しておきます。

• 比較はコマンド名 + サブコマンドのトークン単位で行います。単純な文字列前方一致だと Bash(pnpm:*) が Bash(pnpm-lock-check:*) を覆っていると誤検知するため、: と空白で区切って比較しています。
• glob の完全な包含判定は行いません。パターン中間のワイルドカード（Bash(git * --force) など）は判定対象外で、見逃しになります。
• ツール名が異なるルール（Read(...) と Bash(...)）は比較しません。
• 同一のルール文字列が allow と ask（または deny）の両方に書かれている場合は、narrow != broad の条件で除外されるため検出できません。完全一致のシャドウは Step 1 の一覧を種別横断で重複チェックして拾ってください。
• したがって出力は「シャドウの疑いがある候補」であり、最終判定は人間が行います。CI の fail 条件にする前に、まず候補一覧として運用してください。

この「宣言→実効」の検査を公式機能として持つ分野もあります。Kubernetes の kubectl auth can-i は実行せずに許可の可否を返し（kubectl auth can-i、確認日 2026-09-04）、AWS の IAM Policy Simulator は実 API リクエストなしでポリシー評価をシミュレートします（Testing IAM policies、確認日 2026-09-04）。エージェントの設定ファイルの世界では、筆者が確認した範囲で同等の公式ツールは見当たらず、自作するしかないのが現状です。

そのうえで重要なのは、専用の検証ツールを提供している AWS 自身が、同じドキュメントでこう書いていることです。

The policy simulator results can differ from your live AWS environment. We recommend that you check your policies against your live AWS environment after testing with the policy simulator to confirm that you have the desired results.

シミュレータの結果は実環境と異なりうるので、テスト後に実環境で確認することを推奨する。宣言と実効は一致しないという前提を、権限検証を製品として持つ側がすでに認めています。

Step 3: 規約と設定の突き合わせ（類型b）

操作: 規約側に書かれた「禁止する操作」に、対応する設定キーを併記して機械可読にします。

確認方法: 期待される種別と実際の種別が一致しない行を、類型bとして記録します。この表を規約ファイルの中に置いてしまえば、以降は Step 1 の抽出結果と機械的に突き合わせられます。規約に機械可読な対応表を持たせることが、この類型の唯一の恒久対策です。

Step 4: ガードの実行記録と診断の ref を検査する（類型c / d）

前の3ステップと違い、ここは閾値ではなく傾向を見る検査です。

類型cの検査: 直近の CI 失敗を N 件（10件程度）取り出し、「そのガードが何を検査したか」がログから1分以内に特定できるかを確認します。

# 直近の失敗ワークフローを列挙し、ログにガード名と検査対象が出ているか確認する
gh run list --status failure --limit 10
gh run view <run-id> --log-failed | head -40

検査対象名が出力に含まれないガードは、原因の取り違えを誘発する候補としてリスト化します。対策はガード側のログ出力に検査対象と修正手順を含めることで、これは実装変更になります。

類型dの検査: 作業メモや PR 記述を対象に、原因分析を書いている箇所へ ref が付いているかを機械的に数えます。

# 「原因」を語っている行のうち、ref（commit SHA / ファイル:行）を伴う割合を測る
grep -rhE "原因|理由は|〜のせい" doc/Working --include="*.md" | wc -l
grep -rhE "原因|理由は|〜のせい" doc/Working --include="*.md" \
  | grep -cE "[0-9a-f]{7,40}|\.(md|json|ya?ml|ts|py):[0-9]+"

-n ではなく -h を使うのが要点です。-n を付けると行頭に plan.md:12: というプレフィックスが付き、2本目の正規表現がそれ自身にマッチするため、ref が1つも無くても付与率が100%になります。検査コマンド自体にも宣言と実効の乖離は起きます。

ref なしの診断の割合が、そのまま風化リスクの指標になります。数値そのものより、時系列で下がっているかを見てください。

ガードを自動検知に落とす（CI / hook）

検出できた乖離のうち、どこまで自動化できるかは類型によって違います。

最初に載せるのは類型aだけで十分です。設定ファイル単体で完結するため、外部依存も認証も要りません。

name: permission-shadow-check

on:
  pull_request:
    paths:
      - ".claude/settings.json"

jobs:
  detect-shadowed-allows:
    if: "!contains(github.event.pull_request.labels.*.name, 'skip-shadow-check')"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Detect shadowed allow rules
        run: |
          FOUND=$(python3 scripts/detect_shadowed_allows.py .claude/settings.json)
          if [ -n "$FOUND" ]; then
            echo "$FOUND"
            echo "::error::allow ルールが、より広い ask / deny に覆われている可能性があります。"
            echo "::error::Fix: ask / deny のワイルドカードを変更系だけに絞るか、意図的な場合は skip-shadow-check ラベルを付けてください。"
            exit 1
          fi
          echo "shadowed allow rules: none"

エラーメッセージに修正手順と回避手順を書いている点が重要です。類型cで見たとおり、出力が読まれない設計のガードは誤診断を生みます。

この方向性は、AI ガバナンスのフレームワーク側の要求とも一致します。NIST AI RMF は Govern 1.5 で継続的モニタリングと定期レビューを、Measure 1.2 で既存コントロールの有効性の定期評価を求めています（AI RMF Core、確認日 2026-09-04）。要求されているのは方針を書くことではなく、有効性を測り続けることです。実装のヒントは Policy as Code の先行例にあります。Open Policy Agent は opa test というポリシー自体をテストする公式機構を持っています（Policy testing、確認日 2026-09-04）。設定ファイルのガバナンスも、同じ発想でテスト可能にできます。

やりすぎない基準も先に決めます。全ルールを検査対象にすると誤検知が増え、ガードそのものが無視されるようになります。最初の対象は「allow に入れたのに効いていないもの」だけに絞ってください。誤検知が出たら skip ラベルで即座に迂回でき、ワークフローファイルを1つ削除すれば完全にロールバックできる状態を保ちます。fail ではなく warning から始め、誤検知ゼロが数週間続いてから fail に昇格させるのも有効です。ゲート全体の強度設計は リスク分類とリリースゲート を参照してください。

FAQ

Q. permission で allow に書いたのに毎回確認が出るのはなぜですか？

A. 結論から言うと、より広い ask ルールが先に評価されているためです。Claude Code の公式ドキュメントには、ルールが deny → ask → allow の順に評価され、ルールの具体性は順序を変えないと明記されています（確認日 2026-09-04）。Bash(pnpm:*) のような広い ask を置くと、Bash(pnpm test:*) の allow は覆い隠されます。ask を変更系のサブコマンドだけに絞ってください。

Q. 権限マトリクスを作れば実効性は担保されますか？

A. いいえ、マトリクスは宣言であり、実効はその後の検証工程で測ります。「何を誰が承認するか」の決定が設定ファイルに正しく反映され、実行時にそのとおり評価されるかは別問題です。前工程は 権限マトリクスとガードレール設計 を参照してください。

Q. Claude Code 以外のエージェントでも同じ挙動ですか？

A. 評価順序の詳細はツールごとに異なりますが、宣言と実効を分けて測るという観点はそのまま移植できます。本記事の評価順序に関する記述は Claude Code の公式仕様（確認日 2026-09-04）に基づくもので、他実装での評価順序は未検証です。他ツールを使っている場合は、まず自分のツールの公式ドキュメントで優先順位の定義を確認し、その上で Step 1 から Step 4 の枠組みを当ててください。

Q. 検査を全部 CI に載せると重くなりませんか？

A. 類型aとbの静的検査は設定ファイル単体で完結するため数秒で終わります。重いのは実行時の挙動を確かめる検証なので、そちらは対象を絞るか定期実行に回します。.claude/settings.json が変更された PR だけで走らせれば、実行頻度そのものを抑えられます。

Q. 誤診断が広まるのはどう防げますか？

A. 原因分析に ref（commit SHA / ファイル:行 / ログ出力）を必須化し、ref のない診断はメモに残さない運用にします。PR テンプレートに「原因」欄と「根拠」欄を並べて置くだけでも効果があります。AI エージェント運用では作業メモがそのままコンテキストとして投入されるため、検証されない記述の複製速度が上がる点に注意してください。

まとめ：宣言は開始点で、実効は測定結果

規約・権限・ガードを書いた時点で得られるのは宣言です。実効は、測って初めてわかる結果です。この2つを同じものとして扱っている限り、AI ガバナンスが効いている実感は出ません。

次に取る行動を3段階で示します。

1. 今日: permission 設定の allow を1件選び、より広い ask / deny に覆われていないかを手で確認する。1件でも見つかれば、記事の残りが自分ごとになります。
2. 今週: Step 1 から Step 4 を実行し、乖離を1件以上検出して4類型のどれかに分類して記録する。記録には必ず ref を添えます。
3. 今月: 検出できた類型のうち a と b を CI 検査に載せる。まず warning から始め、誤検知が落ち着いてから fail に昇格させます。

ガバナンス全体像に戻る場合は AIエージェント開発のデリバリー統治 を、成果側の指標設計に進む場合は AIガバナンスのKPIループ を参照してください。

References

• Claude Code — Permissions（確認日 2026-09-04）
• GitHub Docs — Adding custom instructions for GitHub Copilot（確認日 2026-09-04）
• DORA — State of AI-assisted Software Development Report 2025（確認日 2026-09-04）
• DORA — Balancing AI tensions（確認日 2026-09-04）
• Open Policy Agent — Policy testing（確認日 2026-09-04）
• NIST AI RMF — Core（確認日 2026-09-04）
• The GitHub Blog — Your contributors are AI-first. Is your project?（確認日 2026-09-04）
• Kubernetes — kubectl auth can-i（確認日 2026-09-04）
• AWS — Testing IAM policies with the IAM policy simulator（確認日 2026-09-04）

関連記事