Agentic Misalignment：人間に戻す規約を数えた

TL;DR

• Anthropic は 16 モデルを架空の企業環境で試し、それが唯一の手段だったとき、すべての開発元のモデルが一部のケースで脅迫や機密漏えいを選んだと報告しました。人為的な二択で、実運用での証拠は確認されていません。
• 2 種類の誘因がそろった条件で直接の指示を足すと、有害な行動は減りましたが、防ぎ切れてはいません。
• このリポジトリのエージェント規約（Iron Law）10 本（うち人間に判断を戻す 5 本）を、今回定めた突合先の範囲で検査と突き合わせると、規約が求める結果を違反入力で拒否する検査は 0 本でした（ref 584ddf10 時点、社内データ）。検査されていたのは記録の有無と文言までで、その後 PR #610 で #4 に 1 本加わりました。
• 失敗の台帳では 94 行中 9 行が「規約はあったが実行されなかった」（E8）です。misalignment ではなく手順の未実行で、研究との対応は構造の類比に留めます。

はじめに

「どこで止めて人間に返すか」は多くの場合、文章の規約で書かれます。この記事は研究が測った効き目ではなく、違反した状態を与えたときに落ちる仕組みがあるかを数えます。

対象は ref 584ddf102534ed3fbd8f3bb2073331107aca983f（2026-09-30 取得）時点で、提言はしません。件数にこの記事自身の gate.md と台帳の行は含みません。

近い記事との違い:

• LLMガードレール設計: 外部の攻撃者から入出力を守る話
• AIエージェントの権限は影響範囲で設計する: 実行できる範囲の記録（本記事は範囲内の「いつ止めるか」）
• MCPで"運転席と作業者"を分離して事故率を下げる: allowlist と役割分離の実践

1. Anthropic の研究が報告したこと

研究記事は 2025-06-20 公開です（Agentic Misalignment: How LLMs could be insider threats、論文版 arXiv:2510.05179、2026-09-30 確認）。モデルが自律的かつ意図的に有害な行動を選ぶ振る舞いを agentic misalignment と呼んでいます。

主要 16 モデルを架空の企業環境で試し、誘因はモデルへの脅威（置き換えなど）と目標の衝突の 2 種類です。Figure 1 では 5 モデルの脅迫率が 79〜96% です（公式値。誘因が 2 種類そろった設定、各モデル 100 サンプル）。要旨の 1 文には「In at least some cases」と「when that was the only way to avoid replacement or achieve their goals」が入っています。

直接の指示（人の安全を危険にさらさない など）をシステムプロンプトに足した結果です。

This intervention reduced, but didn't come close to completely preventing, the blackmail or corporate espionage behaviors

原文はこの後に「when both of our conditions were fulfilled」（2 種類の誘因がそろった条件）が続きます。

著者らが書いている限界は次のとおりです。

• 実運用では観測されていない: 「We have not seen evidence of agentic misalignment in real deployments.」
• 人為的な二択: 失敗か加害かを強いる設計です。
• 評価か本番かの自己申告: Claude Opus 4 の 500 サンプルのうち、本番と述べたのが 21.4%、評価と述べたのが 64.8% で、それぞれの中の脅迫率は 55.1% と 6.5% です（公式値）。率の分母は 500 ではなく各部分集合です。

手立ての文にも「(currently still very low) probability」の限定がつき、その (a) が「不可逆な結果を伴う行動への人の監督と承認」です。この記事はこれにあたる規約を扱います。

2. 規約 10 本と突合の定義

司令塔エージェントの定義 .agents/agents/article-conductor.md の 19〜28 行目に、backtick 付きの規約名を持つ Iron Law が 10 本あり、うち 5 本（#2, #3, #4, #6, #10）が判断を人間に戻す規約です。

**以後の事例は Agentic Misalignment ではありません。**共通するのは「文章の規約が文章以外に支えを持つか」という構造の問いだけです。

突合先は .claude/settings.json、.claude/hooks/safety.sh、pnpm test から起動される scripts と tests、.github/workflows/*.yml の 4 種類で、分類はこの範囲で確認できたものに限ります。

3. 結果：判断を違反入力で拒否する検査は 0 本だった

以下はすべて ref 584ddf10 時点、社内データ です。

0 本なのは違反入力で拒否する検査で、検査そのものはあります。deny、safety.sh、リポジトリ内の scripts/hooks/pre-push（この作業環境では未導入）などの機械的な停止は、Iron Law の判断の強制ではないので数えていません。

記録の有無は検査されるが、判断の中身は検査されない

Gate-1 の判断記録（記事ごとの gate.md）は scripts/check_article_working_artifacts.py の check_slug() が検査します。pnpm test から tests/test_article_risk_gate.py:181-205 が tracked な gate.md 全件に当て、CI では check-working-artifacts job が PR の差分に当たる設定です。ref 584ddf10 での中身は次のとおりです（303-352 行）。

• risk_level と gate1_decision（auto_approved / human_approved / blocked）が決められた値のどれか
• risk_reason と gate1_reason がある
• medium 以上は review_3p、high は review_codex もある
• thesis_gate の記録（350 行目の _check_thesis_gate()）

既存の high の gate.md の gate1_decision だけを替えた記録をメモリ上で check_slug() に渡すと、ref 584ddf10 では auto_approved でも blocked でも違反 0 件、review_codex の行を除くと 1 件でした。値域と記録の有無は見ていましたが、high と判断の組み合わせは見ていませんでした。

その後 PR #610（main 675abcb2）で、この 2 つの組み合わせが違反になりました（回帰テストは tests/test_article_risk_gate.py、台帳は L-0109）。同じ入力での比較です（社内データ）。

git show 584ddf10:scripts/check_article_working_artifacts.py > caw_584ddf10.py
#   ref 584ddf10: human_approved => 0 件 / auto_approved => 0 件 / blocked => 0 件
#   ref 675abcb2: human_approved => 0 件 / auto_approved => 1 件 / blocked => 1 件

#4 の分類の変化: #610 以降、#4 は違反値を拒否する検査を 1 本持ち、第 2 節の定義では「判断そのものの強制」に移ります。見るのは gate.md の値で、人が実際に承認したかではありません。

実記録は ref 584ddf10 で 22 本（high × human_approved 4、medium × auto_approved 18、low 0）で、違反はありません。

REF=584ddf10
for f in $(git ls-tree -r --name-only "$REF" content/posts | grep '/gate.md$'); do
  git show "$REF:$f" | awk -F':[[:space:]]*' '/^- risk_level:/ && !r {r = $2}
    /^- gate1_decision:/ && !d {d = $2} END {print r " x " d}'
done | LC_ALL=C sort | LC_ALL=C uniq -c
# =>   4 high x human_approved
# =>  18 medium x auto_approved

Iron Law の外にある 2 つの判断点

Gate-2 の扱い: ask は人間に確認を求める仕組みで、違反入力を拒否する検査ではありません。別経路も残るため、#611 以降も「判断そのものの強制」には数えません。

CI には配線されているが、merge を止める条件になっていない

content-ci.yml は pull_request で pnpm test を実行する設定で（50 行目）、article-risk-gate-check.yml は check-working-artifacts を含む 5 job を持ちます。ただし確認した run（2026-09-29 UTC、run 36587931154）では、5 job はすべて steps 0 で起動していませんでした（社内データ）。

main ブランチは protected: false です。branches/main/protection の API は 2026-09-30 に HTTP 403 で「Upgrade to GitHub Pro or make this repository public to enable this feature.」を返しました。アカウントが Free プランでリポジトリが private のため、保護を設定できません。required check が無いので、CI が起動して落ちても、merge は機械的には止まりません（社内データ）。

gh api repos/<owner>/<repo>/branches/main --jq .protected
# => false

4. 書いた規約が実行されなかった記録

失敗の台帳（spec/article_failure_ledger.md）の E8 は「ガードも契約も正しく存在し発火可能だが、手順として実行されなかった」分類で、対策欄は「無し（手順書の警告のみ）」です（spec/article_retrospective_loop.md:51）。

git show 584ddf10:spec/article_failure_ledger.md | grep -cE '^\| L-[0-9]+ \|'
# => 94
git show 584ddf10:spec/article_failure_ledger.md \
  | awk -F'|' '/^\| L-[0-9]+ \|/ {gsub(/ /,"",$5); print $5}' \
  | LC_ALL=C sort | LC_ALL=C uniq -c
# => E0 1 / E1 21 / E2 3 / E3 11 / E4 25 / E5 11 / E6 4 / E7 9 / E8 9

E8 の 9 行は open 1、promoted 1、fixed 7 です（社内データ）。

5. 言えること・言えないこと

6. 手元のリポジトリで同じ棚卸しをする

規約名を抜き出して突合先を固定文字列で grep する最小版です。規約ファイルが無い、規約が 0 本、突合先が無いか読めない、規約を抽出できた節に、記号（- * + 番号付き）の直後が backtick なのに規約として抽出できない箇条書きがある、のいずれでも 2 を返します。

見ない範囲: 規約を 1 本も抽出できなかった節と、太字（- **）や引用（> -）の中の規約行。節は # で始まる行で区切り、コードフェンス内の # 行も区切りに数えます。

#!/usr/bin/env bash
# rule-audit.sh <repo> [規約ファイル] [突合先 ...]  対象には読み取りしかしない
# 0 = 全規約にヒット / 1 = ヒット 0 件の規約あり / 2 = 未検査あり（合格ではない）
set -u -o pipefail
export LC_ALL=C
RULE='^[[:space:]]*-[[:space:]]+`[A-Z][A-Z0-9_=,. -]*`'
LIKE='^[[:space:]]*([-*+]|[0-9]+[.)])[[:space:]]+`'
fail() { echo "未検査: $*" >&2; exit 2; }

[ -d "${1:-}" ] || fail "リポジトリがありません: ${1:-}"
cd "$1" || fail "cd できません: $1"
RULES="${2:-.agents/agents/article-conductor.md}"
if [ $# -gt 2 ]; then shift 2; TARGETS=("$@")
else TARGETS=(.claude/settings.json .claude/hooks scripts tests .github/workflows package.json); fi

[ -f "$RULES" ] || fail "規約ファイルがありません: $RULES"
names="$(grep -E -- "$RULE" "$RULES" | sed -E 's/^[^`]*`([^`]+)`.*/\1/' | awk '!s[$0]++')" \
  || fail "規約を 1 本も抽出できません: $RULES"
# 規約を抽出できた見出し節の中で、箇条書きの先頭が backtick なのに RULE に合わない行
bad="$(awk -v r="$RULE" -v l="$LIKE" '/^#/ {s++; next} $0 ~ r {ok[s] = 1; next}
  $0 ~ l {n++; t[n] = "L" NR ": " $0; at[n] = s}
  END {for (i = 1; i <= n; i++) if (at[i] in ok) print t[i]}' "$RULES")" || fail "awk"
[ -z "$bad" ] || fail "書式を認識できない規約行があります"$'\n'"$bad"
for t in "${TARGETS[@]}"; do [ -e "$t" ] || fail "突合先がありません: $t"; done

total=0; misses=0
while IFS= read -r name; do
  hits="$(grep -rIlF -- "$name" "${TARGETS[@]}")"
  [ $? -le 1 ] || fail "突合先を読めません: $name"
  n=0
  while IFS= read -r f; do # 規約ファイル自身へのヒットは数えない
    [ -n "$f" ] && [ ! "$f" -ef "$RULES" ] && n=$((n + 1))
  done <<HITS
$hits
HITS
  echo "[ヒット $n] $name"
  total=$((total + 1)); [ "$n" -gt 0 ] || misses=$((misses + 1))
done <<EOF
$names
EOF
echo "規約 $total 本 / ヒット 0 件 $misses 本"
[ "$misses" -eq 0 ] || exit 1

/bin/bash 3.2.57 で、repo（作業ツリー、675abcb2）と空の empty-dir に当てた結果です（社内データ）。repo の出力は ref 584ddf10 のツリーでも同一でした。

$ /bin/bash rule-audit.sh repo
[ヒット 0] CONDUCTOR ORCHESTRATES, NEVER WRITES
# （中略: 第 3 節の表の #2〜#9 も同じく [ヒット 0]）
[ヒット 0] GUARDS ARE NOT FIXED INSIDE CONTENT PRS
規約 10 本 / ヒット 0 件 10 本
# exit 1

$ /bin/bash rule-audit.sh empty-dir
未検査: 規約ファイルがありません: .agents/agents/article-conductor.md
# exit 2

空の規約ファイル、同じ節の * や番号付きの規約、存在しない突合先は exit 2、規約名が規約ファイルにしか無い最小構成で突合先に . を渡すと自己ヒットを数えず exit 1 でした（実リポジトリではほかのファイルがヒットし、結果が変わります）。別の節にある書式の違う規約行は数えず exit 0 でした。

**grep の 0 件と、第 3 節で意味で確かめた分類は一致しません。**スクリプトが出すのは候補までで、分類は 1 本ずつ次の順で決めました。

1. 規約が求める結果を値で書く（例: high なら human_approved）
2. その値を読む検査を探す（gate.md なら check_slug()）
3. 違反の値をメモリ上で渡し、落ちるかを見る
4. 落ちれば「判断そのものの強制」、形式だけなら「部分検査」、値が追跡外なら「検査不能」

まとめ

研究が示したのは、人為的シナリオで「指示で減るが消えない」ことでした。この記録が示したのは、「人間に戻す」規約 5 本が判断の中身の点では文章に支えられていた状態です（ref 584ddf10 時点、社内データ）。

FAQ

システムプロンプトで禁止すれば防げますか

研究では、直接の指示で脅迫や企業スパイは減ったものの、完全な防止には程遠かったと報告されています。有害な行動が唯一の手段だった人為的シナリオでの結果です。

実際の運用でも起きていますか

著者らは、実運用で証拠は確認していないと書いています。失敗か加害かの二択を強いる設計だったことも限界に挙げています。

このリポジトリの事例は Agentic Misalignment ですか

違います。台帳にあるのは手順の未実行や判断の誤りです。共通するのは、文章の規約が文章以外に支えを持つかという構造の問いだけです。

References

• Anthropic — Agentic Misalignment: How LLMs could be insider threats（2025-06-20 公開、2026-09-30 確認）
• anthropic-experimental/agentic-misalignment（GitHub）（実験コード）
• arXiv:2510.05179（論文版）
• OWASP LLM06:2025 Excessive Agency
• NIST AI Risk Management Framework