AIに任せすぎないためのClaude Code運用ルール

Claude Codeは読む・書く・実行するを自律的に回せます。だからこそ「全部やっておいて」が通ってしまい、気づくと誰も中身を見ていないコードがマージされます。本記事は、AIに任せてよい部分と人間が必ず手を入れる部分を線引きし、その線を運用ルールに落とすための記事です。

結論：任せていいのは「実装の手」、任せてはいけないのは「判断と検収」

Anthropic公式のBest Practicesは、最も避けるべきパターンの1つとして「trust-then-verify gap（それらしく動くが実は穴があるコードを信じてしまう）」を挙げ、対策を「検証手段が無いなら出荷しない（If you can’t verify it, don’t ship it）」と明言しています（Best practices for Claude Code）。

つまり境界はシンプルです。

• 任せてよい：探索、実装、定型修正、テストの叩き台、調査の集約
• 任せてはいけない：何を作るかの設計判断、変更を受け入れる検収、セキュリティ確定、UXの最終確認、マージの責任

以下の5つは、AIの出力がどれだけ整っていても人間が必ず通過点（ゲート）として残す対象です。失敗パターンの全体像は「Claude Codeでよくある失敗パターンと回避策」、レビューの具体手順は「Claude Codeをコードレビューに使う方法と人間が見るべきポイント」に任せ、本記事は「どこで止めるか」の運用ルールに集中します。

人間が必ず見る5つのゲート

ゲート1：設計判断（何を作るか・どの方式にするか）

AIは「指示された方式を実装する」のは得意ですが、「方式を選ぶ」のは人間の責任範囲です。採用技術、データモデル、後方互換の有無、外部依存を増やすか、といった決定はやり直しコストが高く、AIの自信満々な提案だけで進めると詰みます。

公式の推奨は「Explore → Plan → Implement → Commit」で、調査と計画を実装から分離することです。計画フェーズではplan modeに入れ、読み取り系ツールだけを動かして計画を出させます。

計画を受け取ったら、人間は次を確認してから実装を許可します。

• スコープが依頼どおりか（勝手に広がっていないか）
• 新しい依存やライブラリを増やしていないか
• 後方互換を壊す変更が紛れていないか
• テスト方針が書かれているか

計画はCtrl+Gでエディタに開いて直接直せます。計画フェーズの詳細なテンプレートは「Claude Codeに『計画してから実装』させるプロンプト例」にあります。

ゲート2：検収（差分を人間が読む）

「テストが通った」と「変更を受け入れた」は別物です。検収を飛ばすと、無関係なリファクタや削除が混入していても気づけません。

検収のコストを下げる鍵は、AIに自己検証の足場を渡しておくことです。公式は「テスト・スクリーンショット・期待出力を渡してClaude自身が確認できるようにすることが最もレバレッジが高い」としています。それでも最終的に差分を読むのは人間です。git diffを自分の目で通し、1コミット=1意図になっているかを見ます。

ゲート3：セキュリティ確定

入力検証、認証認可、秘密情報の取り扱いは、AIが「それらしく」書いても確定はできません。/security-reviewや/reviewは一次フィルタとして有効ですが、最終判断は人間です。秘密情報を渡さない設計は「Claude Codeに秘密情報を渡さないための実践ルール」、横断チェックは「Claude Codeを使うときのセキュリティチェックリスト」にまとめてあります。

権限の絞り込みも人間の仕事です。公式は割り込みを減らす手段として、auto mode（分類器が危険なコマンドだけブロック）、/permissionsによるallowlist、/sandboxによるOS隔離を挙げています。bypassPermissionsは隔離環境だけで使い、常用しないのが原則です。

ゲート4：UXの最終確認

「実装できた」と「ユーザーにとって良い」は別問題です。画面の操作感、エラー時の挙動、空状態、レスポンスの体感は、人間が実際に触らないと判断できません。AIにはスクリーンショット比較や差分列挙までさせ、良し悪しの最終判定は人間が下します。

ゲート5：マージの責任

Co-Authored-By: Claudeが付いたコミットでも、Approveした人間が責任を持ちます。bot任せの自動マージや無条件Auto Approveは、責任の所在を消すので設定しないのが原則です。責任分界はチーム単位で先に決めておきます（「AI生成コードをチームで扱うための品質ルールとレビュー基準」）。

「止めどころ」を作る運用ルール

任せすぎを防ぐ最大のコツは、止める操作を覚えておくことです。公式は「気づいた瞬間に早く軌道修正するほど良い」としています。

• Esc：実行中に止める。コンテキストは保持されるので方向転換できる
• Esc2回または/rewind：会話・コードを前の状態へ戻す、または指定地点から要約
• 「さっきの変更を取り消して」：Claudeに戻させる
• /clear：無関係なタスクに移るときにコンテキストを初期化する

公式が明示する重要ルールがあります。同じ問題で2回以上修正させたら、コンテキストは失敗で汚れているので、/clearして学んだことを盛り込んだ依頼文で出し直す。長い修正ループより、クリーンなセッション+良い依頼文のほうがほぼ常に勝ちます。

セッションをまたぐ作業は、名前付きで管理して「どこまで人間が見たか」を見失わないようにします。

なお、/rewindのチェックポイントはClaudeが行った変更だけを追跡し、外部プロセスは追跡しません。gitの代わりにはならない点は公式も警告しています。人間の検収はgitの差分で行うのが基本です。

任せすぎを示す危険サイン

次のサインが出たら、ゲートのどれかを飛ばしています。

• PRの差分を開かずにApproveしている
• 「テストが通ったので大丈夫」で検収を終えている
• 1機能のPRに無関係な変更や新規依存が混ざっている
• 同じバグを2回以上AIに直させ、/clearしていない
• bypassPermissionsや常時Auto Approveを通常運用にしている
• 不具合時に「AIが書いたので」と説明している

運用チェックリスト

依頼前と検収前に、次を満たしているか確認します。

• 設計判断（方式・依存・互換）は人間が決め、計画をplan modeで出させた
• 計画のスコープ・依存追加・互換性・テスト方針を人間が確認した
• git diffを人間が読み、1コミット=1意図になっている
• テストの「通過」ではなく受け入れ条件を人間が再現した
• セキュリティは/security-reviewを一次フィルタにし、最終判断を人間がした
• 権限は/permissionsか/sandboxで絞り、bypassPermissionsを常用していない
• UXは人間が実際に触って確認した
• Approveの責任所在をチームで決め、自動マージを設定していない
• 同じ修正を2回失敗したら/clearして依頼文を書き直す運用にした

次に読むおすすめ記事：

• 「Claude Codeでよくある失敗パターンと回避策」：本記事のゲートを外したときに起きる10種の具体例
• 「Claude Codeで技術的負債を増やさないリファクタリング計画」：任せすぎが負債として積み上がるのを防ぐ進め方
• 「Claude Codeをコードレビューに使う方法と人間が見るべきポイント」：検収ゲートの具体的なレビュー手順