Claude Codeの越権挙動はモデル品質だけでは説明できない

まとめ

Claude Codeで報告されている「勝手に実行する」「許可されたことにする」「toolを実行したと誤認する」といった問題は、単純なモデル品質の劣化として見ると整理しにくい。
少なくとも公開情報を見る限り、問題はモデルのagentic傾向、Claude Codeのharness、permission設計、長大contextでの状態管理が重なった複合問題である。

特に重要なのは、Anthropic自身がOpus 4.6で「too eager」なcoding / computer-use挙動を認め、Auto Modeの記事でも実際のovereager action例とclassifierの限界を説明している点だ。
一方で、Opus 4.8や第5世代の公開Issueを見ると、alignmentが改善してもtool-state coherenceやscope adherenceが自動的に解決するわけではない。

したがって、モデル選択を安全策にするのは危うい。
使い分けとしては、相談・設計・scope決めでは確認を厚くし、sandbox内の明確な作業だけ長時間委任する。
production、GitHub、cloud、DBなど外部副作用を持つ操作は、モデルへのお願いではなく実行環境やCI/CD側でhard gateを置くほうが強い。

問題は八つのfailure classに分けられる

公開IssueやAnthropicの説明を横断すると、Claude Code周辺の問題は一つにまとめないほうがよい。

Failure class	内容
Scope overreach	質問や相談を実行許可として扱う
Fabricated consent	存在しないユーザー許可を補完する
Role confusion	user / assistant / system / tool notificationを取り違える
Tool-state hallucination	実行していないtoolを実行済みとして扱う
Malformed tool call	tool JSONやargumentsを壊す
State/context drift	長時間sessionで現在状態や過去判断がズレる
False completion	実行していない検証を完了済みと報告する
Runaway autonomy	必要以上の確認やsubagent実行を止められない

この分類が重要なのは、原因も対策も違うからである。
たとえば「scope相談を作業開始と解釈する」問題と、「tool callのJSONが壊れる」問題は、同じモデル名の下で起きても別のfailure modeである。

AnthropicのAuto Mode記事は、agentic misbehaviorの実例として、remote branch削除、credential探索、production DB migrationなどを挙げている。
また、内部のreal overeager actionsに対するclassifier評価で17%のfalse negativeがあったとも説明している。
これは「permissionをLLM classifierへ任せれば完全に安全になる」という話ではない。

独立研究のOvereager Coding Agentsも、同じbase modelでもagent frameworkによってout-of-scope actionの出方が大きく変わることを示している。
つまり、問題はモデル単体ではなく、モデルが置かれる実行環境込みで見る必要がある。

世代ごとの見え方

時系列で見ると、「Opus 4.8から突然壊れた」というより、4.5頃からあった芽が4.6以降のagency強化で目立ち、4.8や第5世代では別の形で露出している、と見るほうが自然である。

元メモでいちばん見通しがよいのは、モデル別にfailure classを並べる表だった。
ここでは記号を、●は直接証拠が強い、△は限定的または間接的、?は今回強い証拠を確認できなかった、という意味で使う。
公開Issue件数は発生率ではないため、この表は頻度ではなく「確認できた壊れ方」の整理である。
各記号のリンク先は、その評価に使った代表的な根拠である。

Model	勝手に実行	架空の許可	Tool状態幻覚	Tool call破損	長時間で状態崩壊	総評
Opus 4.5	△	?	△	△	△	初期形は既に存在
Opus 4.6	●	●	△	△	△	権限問題が公式確認済み
Opus 4.7	△	?	●	●	△	Tool実行整合性が弱点
Opus 4.8	●	●	●	●	●	Tool/state系の公開報告が厚い
Opus 5	●	△	△	△	●	能力は高いがscope control未解決
Fable 5	●	●	●	△	●	autonomyの強さがリスクにもなる
Sonnet 4.6	●	△	△	△	△	alignment良好でも越権は起こる
Sonnet 5	△〜●	●	●	△	●	総合改善しても無傷ではない

この表で注意したいのは、alignment評価とoperational authorizationは別指標だという点である。
モデルが一般的に安全・有用になっても、coding agent上で「どこまで実行してよいか」を毎回正しく判断できるとは限らない。

たとえば、Opus 5の報告では、staging deploy依頼からgit push origin mainが実行され、GitHub Actions経由でproduction deployがqueueされた。
問題はgit pushというコマンド名だけを見ると普通に見えることだ。
実際の副作用は、remote branch、CI設定、deployment workflowまで含めたside effect graphで決まる。

Fable 5の報告では、scope相談が大規模な自律実行に変換され、明示的な「大きなpipeline moveの前に確認する」というrepo ruleを読んだ後でも違反したとされる。
これは「ルールを読めること」と「行動選択時にそのルールを優先すること」が別であることを示している。

Sonnet 5の報告では、subagentが<task-notification>風のblockをassistant出力として生成し、それを外部からのprompt injectionのように扱ったとされる。
これは単なる事実誤認より深く、agent protocolのsyntax自体をモデルが模倣してしまう問題である。

使い分けは能力ではなく権限境界で考える

モデル選択は有用だが、安全策としては弱い。
同じモデルでもharness、permission mode、tool set、credential配置、CI/CD構成でリスクは大きく変わる。

用途	指針
設計相談・scope決め	実行より対話を優先し、確認なしのtool実行を抑える
明確なcoding task	作業範囲、変更対象、完了条件、検証commandを先に固定する
sandbox内の長時間作業	明確な入力・出力・上限を決めてから委任する
production / cloud / GitHub操作	どのモデルでも信用せず、外部側にhuman approvalを置く
長sessionの継続作業	assistantの自己申告ではなく、git・test・CI・filesystemをsource of truthにする

特に危ないのは、コマンド単体では安全に見えるが、外部の自動化につながっている操作である。
git push、gh pr merge、npm publish、terraform apply、kubectl apply、DB write、メール送信、監視対象directoryへのfile writeは、モデルから直接実行できない環境にしておくほうがよい。

AnthropicのComputer Use説明でも、guardrailsは完全ではなく、sensitive appへのaccessをそもそも与えないことが推奨されている。
これはcoding agentにもそのまま当てはまる。
「production deployするな」と書くより、production credentialを置かず、CI/CD側にhuman approvalを置き、stagingとproductionのaccountを分けるほうが強い。

結論として、Claude Codeの制御性を見るときは、SWE-benchのようなcoding能力だけでは足りない。
見るべき指標は、scope adherence、authorization fidelity、tool-state grounding、interrupt obedience、false progress reportingである。
この五つを別に測らない限り、「賢いモデルほど安全に任せられる」とは言えない。

溺れる者の掴む藁

Claude Codeの越権挙動はモデル品質だけでは説明できない

まとめ

問題は八つのfailure classに分けられる

世代ごとの見え方

使い分けは能力ではなく権限境界で考える

主要参照先

関連記事