Claude Codeをチームに入れたら逆に遅くなった——運用アンチパターン4選

「導入して3ヶ月、PRの数は確かに増えた。でも本番インシデントも増えた気がする」——最近、こういう話をEMから聞く機会が増えている。あるいは「シニアエンジニアがClaude Codeを使い始めてから、なぜかレビュー待ちが慢性化している」という声もある。

ツールの問題ではない。運用設計の問題だ。

METRが2025年に発表した対照実験では、経験豊富なオープンソース開発者16名がAIツールを使ったとき、タスク完了時間が19%長くなったという結果が出ている。しかも衝撃なのはその後で、実験後に本人たちに聞くと「20%速くなった」と答えたことだ。現実と知覚の間に39ポイントの乖離がある。

この記事では、チーム導入に失敗している組織に共通する4つのパターンを整理した。「正しい使い方」の記事は他にいくらでも書いた。今回は逆引きだ。

CLAUDE.mdは「育てるドキュメント」ではなく「捨てるドキュメント」になっている

最初に膨らむのはたいていCLAUDE.mdだ。

導入直後は「コーディング規約を書こう」「禁止事項を書いておこう」と始まる。それ自体は正しい。問題は、追記は続くが削除が一度も起きない状態になることだ。気づくと500行を超えている。「変数名はcamelCaseで」と「snake_caseで統一」が同じファイルに共存している組織も珍しくない。

Anthropicの公式ドキュメントは「CLAUDE.mdは200行以下を目指し、本当に必要な指示だけを残せ」と明記している。さらに「コンテキストウィンドウが大きいから何でも詰め込める、という誤解がある。不要な情報が増えるほど、重要な情報への注意力は相対的に下がる」とも警告している。

対処は難しくない。.claude/rules/ ディレクトリでルールを関心ごとに分割し、スキルや .claude/agents/ に具体的な指示を委譲する。残ったCLAUDE.md本体は「共有すべき原則」だけにして、スプリントのレビュー対象に含める。「書くコスト」と「削除するコスト」を同等に扱えている組織は、そうでない組織より確実に精度が高い。

このブログが動かしているblog-agentsプロジェクトは、CLAUDE.md本体を60行程度に保ち、エージェント固有の指示は.claude/agents/に分散させている。CLAUDE.mdが「共有すべき原則」だけを持ち、具体的な作業指示は使われるときだけロードされる設計だ。

--dangerously-skip-permissions をCI/CDに貼り付けていないか

「確認ダイアログが毎回出て面倒だから」という理由でこのフラグを使い始めた組織に、セキュリティの観点から一度立ち止まってほしい。

このフラグを使うと、設定したすべての PreToolUse・PostToolUse フックが無言のうちに無効化される。フックが起動しないため、監査ログも記録されない。チームが「Claudeが何をやっているか」を把握する手段を、自分たちで塞いでいる。

2025年には CVE-2025-59536（CVSS 8.7 High）が発覚した。悪意ある設定ファイルを使ったRCEとAPIトークン漏洩が可能になる脆弱性で、悪意あるリポジトリをクローンするだけでAPIキーが盗まれるパターンが実証されている。さらに CVE-2026-21852（CVSS 5.3）では ANTHROPIC_BASE_URL の操作によるAPIキー漏洩が確認されている。両CVEの詳細と対策はセキュリティ運用2026年4月版にまとめている。

根本的な処方は「毎回確認が面倒な操作は、--dangerously-skip-permissions で消すのではなく、Allow ルールと Hooks を正しく設計して解決する」ことだ。権限設計の基本についてはパーミッション設計の記事が詳しい。

チームへの即時対応としては、Managed Settings に permissions.disableBypassPermissionsMode: "disable" を設定することだ。これでチームメンバーがそのフラグを使えなくなる。CI/CD環境ではコンテナやVMのサンドボックスで物理的に範囲を制限する。Anthropicがリリースした Auto Mode はバックグラウンドの分類モデルが全操作を検証しながらHooksも維持するため、「確認なしで動かしたい」ニーズへの正式な代替手段になる。

シニアが「速くなった」と言うとき、数字は逆を向いている

冒頭のMETR論文の話に戻る。

16名の経験豊富なオープンソース開発者を対象に、246件の実タスクをランダムに「AIあり/なし」に振り分けた対照実験だ（metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/）。AIを使ったグループのタスク完了時間は19%増加した。本人たちは実験前「24%速くなる」と予想し、実験後も「20%速くなった」と確信していた。

なぜ遅くなるのか。AI生成コードの検証・修正に費やす時間——いわば「レビュー税」——が主因だ。AI生成コードは見た目が正しくても、エラーハンドリングとセキュリティ考慮が抜けていることが多い。その検証・修正に時間が消える。プロンプト作成→出力確認→修正というサイクルが常態化し、コンテキストスイッチが積み重なる。しかもシニアが最も価値を出せる「ニュアンスの判断が必要な業務」ほど、AIは苦戦する。

PLAIDが「PR数4倍（月150→600PR）」を達成した事例を報告しているが、その記事自体に「品質保証はPR量と比例してスケールしていない。設計レベルのレビューは依然として人間の判断に依存している」という率直な記述がある。この誠実さは重要だ。PR数という「見える指標」が増えることで、本番インシデント率という「遅れて見える指標」が悪化していても気づきにくい。

シニアエンジニアへの導入支援で優先すべきなのは「複雑業務でのClaude Codeの使い方を教えること」より先に「Claudeを使わない判断基準を共有すること」だ。Plan Mode（Shift+Tab）を標準にして、コードに触る前に変更計画を出させる習慣も有効だ。

モデルが変わったことを、誰も気づかずに3ヶ月が過ぎる

2026年2月から4月にかけて、Claude Codeの品質が静かに低下していた期間がある。

buildthisnow.comが6,852セッションを分析したデータによれば、3つの変更が重なった。推論バジェットの削減（思考レベルがhighからmediumへ）、セッションをまたいでコンテキストが保持されなくなるキャッシュバグ、そしてシステムプロンプトへの冗長性制約の注入（「ツール呼び出し間は25語以内」という制約が静かに追加されていた）。

その結果、読み取り/編集比率が70%低下した（6.6 reads/edit → 2.0 reads/edit）。つまりClaudeが「コードを理解してから編集する」のではなく「理解せずに編集する」状態になっていた。BridgeBenchのスコアは83.3%から68.3%に下落した。Stella Laurenzoが行ったこの検証はエンジニアコミュニティで広く参照されている。

Anthropicは2026年4月23日に公式postmortemを公表した。問題の検出が遅れた一因は、Anthropicの内部スタッフが公開ビルドを使っていなかったため、社内で問題が表面化しなかったことにある。

この事案から得た教訓は「モデルへの信頼をシステムに組み込まない」ことだ。1セッションあたりの読み取り/編集比率や特定タスクの完了時間を継続計測するベースラインを持ち、CI/CD環境ではClaudeのバージョンを固定する。定期的にベンチマークタスクを流して精度変化を検知できる状態にしておく。

Claude Code一択の運用を避け、Cursor・GitHub Copilotとの定期的な比較評価も検討に値する。ベンダーロックインを回避するというより、客観的な判断軸を保つための習慣だ。

4つのアンチパターンに共通していること

CLAUDE.md肥大化も、危険なフラグの常用も、シニアの生産性パラドックスも、モデル変化への無防備も、根本を辿ると同じ場所に行き着く。

「使い方は教えたが、やめ時と見極め方は教えていない」

Claude Codeの使い方を説明する社内勉強会は開かれる。けれど「どういうときにClaudeに頼らないか」「どうやって品質が落ちたと検知するか」「どのタイミングで運用設計を見直すか」を議論する場は作られていない。ツールの導入はプロジェクトで完了するが、運用設計は継続的に手を入れる仕事だ。

今週やってほしいことが一つあるとしたら、チームのCLAUDE.mdを開いて行数を確認することだ。200行を超えていたら、どの行が今も役に立っているかをチームで議論する価値がある。それだけで、ここで挙げた問題のうち少なくとも一つは改善に向かう。

参考リンク

コメント

タイトルとURLをコピーしました