2026 年 5 月、InfoQ が Inside Claude Code Auto Mode: Anthropic’s Autonomous Coding System with Human Approval Gates を公開し、Claude Code が長時間の自律実行を許容する「Auto Mode」と、人による承認ゲートを組み合わせた運用が一気に注目を集めています。夜間に何百ステップも進めつつ、危険な操作の前で必ず人を呼ぶという発想は、受託開発の現場で長年悩まされてきた “AI に任せる範囲” 問題に明確な答えを出しつつあります。
本記事では、Auto Mode を受託で安全に運用するためのヒューマン承認ゲート設計、差分レビューの仕組み、回帰検出の組み立てまでを整理します。
Auto Mode は何を変えたのか
これまで Claude Code は「数手先まで進める → 人が確認 → 次の数手」というインタラクティブモデルが主流でした。Auto Mode の最大の変化は、「人を呼ぶタイミングをエージェントが選ぶ」点にあります。InfoQ の解説と Anthropic の公式ドキュメントを読み比べると、運用上のキモは次の 3 点に集約されます。
| 観点 | 従来モード | Auto Mode |
|---|---|---|
| 進行の主導権 | 人が次の指示を出す | エージェントが進め、節目で承認を求める |
| 危険操作の扱い | 毎回確認 | 事前定義した「重要操作リスト」に該当した場合のみ確認 |
| 監査ログ | 会話履歴のみ | 各ステップの意思決定ログが構造化保存 |
| 並列性 | 1 セッション 1 タスク | 複数セッションを同時に走らせる前提 |
特に 「重要操作リスト」を契約・案件単位で事前合意する運用は、これまで Cursor や GitHub Copilot CLI で曖昧だった “どこまで AI に任せていいか” を契約書に書ける形に落とせる点で大きな進歩です。
受託で押さえる承認ゲートの 3 階層
Auto Mode を受託で運用する際、承認ゲートは 「自動許可」「同期承認」「非同期承認」 の 3 階層で設計します。
[Tier 1: 自動許可（Auto Allow）]
├ 読み取り操作（git status, ls, grep, read_file）
├ ローカルテスト実行（npm test, pytest）
├ ドラフトブランチへの commit
└ Pull Request の draft 化
[Tier 2: 同期承認（Sync Approval）]
├ npm install / 依存追加
├ DB マイグレーション（dev 環境）
├ main / develop へのマージ提案
└ 環境変数の参照
[Tier 3: 非同期承認 + 二重確認（Async + Double Check）]
├ 本番 DB への接続
├ シークレットの読み取り（.env, GitHub Secrets）
├ 外部 API への送信（Slack 投稿、メール送信、決済 API）
└ git push --force / branch 削除Tier 3 の操作は 「人が複数いないと進めない」設計にし、Slack / Teams で承認権限者 2 名以上のリアクションが揃ってから初めて実行する運用にします。これは AI エージェント本番DB削除ガードレール で扱った “AI が破壊的操作を直接実行できない” 思想と一体で組み立てるべきテーマです。
受託契約書に書く「Auto Mode 利用条項」のひな型
Auto Mode を受託で安全に使うには、契約段階で顧客と利用範囲を合意することが最大の予防策です。条項として押さえておきたいポイントを以下に示します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象環境 | dev / staging のみ。本番は人手のみ | ”本番には AI が直接触れない” 明記 |
| 重要操作リスト | 案件ごとに別紙で定義 | リストに過不足がないか |
| 監査ログ保管 | 全セッションの意思決定ログを 1 年間保管 | ログの所有権・閲覧権 |
| モデルバージョン固定 | 案件中はモデルを固定、変更時は事前通知 | 切替時の検証期間 |
| 責任分界 | AI による誤コードの責任を受注側が負う旨を明記 | 顧客が直接 AI を操作した場合の扱い |
| 学習除外 | 顧客コードを学習データに含めない | API プランの確認（Bedrock / Vertex 経由など） |
特に モデルバージョン固定は実務で重要で、案件途中で Claude のマイナーアップデートが入ると コード生成の癖が変わって回帰することがあります。anthropic-version をピン止めし、月初に検証環境で互換性確認するフローを契約に組み込みます。
差分レビューの仕組み — “AI が書いた量を可視化する”
Auto Mode を回すと 数千行規模の自動コミットが日常化します。受託で品質を担保するには、AI が書いた量と人がレビューした量の比率を可視化する仕組みが欠かせません。
案件ダッシュボードに置いておきたいメトリクスは次の 4 つです。
- AI 自動コミット率 = AI が直接 push したコミット数 / 総コミット数
- 人レビュー率 = 人が approve した PR の行数 / 総追加行数
- CI 通過率 = AI 提出 PR のうち初回 CI 通過率
- 回帰発生率 = AI 由来コミットに起因するバグ数 / AI 由来コミット数
人レビュー率が下がりすぎると顧客への説明責任が果たせなくなるため、Auto Mode の自動マージは禁止し、全 PR は人がボタンを押すところまでを既定線にしておくのが無難です。これは Claude Code 2026年最新機能まとめ や Vercel Open Agents による受託保守 で扱った “夜間バッチ AI” の運用と地続きの考え方です。
回帰検出 — 受託品質の最後の砦
Auto Mode が便利になるほど、人の目では追いきれない範囲のコードが日々入ります。回帰検出のレイヤを多重化しないと、半年後に “誰も覚えていないコード” が壊れて顧客から問い合わせが来る、というシナリオが現実になります。
| レイヤ | ツール例 | 検出対象 |
|---|---|---|
| 静的解析 | semgrep / eslint / typescript —strict | 構文・型・既知のアンチパターン |
| 単体テスト | Vitest / Jest / pytest | 関数単位の振る舞い |
| 結合テスト | Playwright / Cypress | UI フロー全体 |
| ビジュアル回帰 | Chromatic / Percy | スクリーン差分 |
| パフォーマンス回帰 | Lighthouse CI / k6 | レスポンスタイム |
| セキュリティ回帰 | trivy / gitleaks / semgrep —rules security | 脆弱性混入 |
特に AI が一晩で 50 ファイル触るような案件では、ビジュアル回帰とパフォーマンス回帰が決定的に重要です。npm run test だけ通っても、UI の崩れやページの遅延に気付くのは顧客自身が触ったタイミングになりがちです。これは Vitest 4.1 の AI Agent Reporter で扱った “AI 時代のテスト戦略” と一体で組むべきテーマです。
コスト構造の見誤りに注意
Auto Mode で開発速度が上がる一方、ヒューマン承認・回帰検出・契約書整備の運用コストは増える点は、見積り段階で顧客と共有しておくべきです。
Auto Mode を入れるだけでコストが下がるわけではない、という点が顧客への重要な説明ポイントになります。「速く出るが、検証と契約整備のコストが増える」を最初に握っておくと、後から「思ったより安くならなかった」と言われずに済みます。承認権限者の人数、夜間稼働の有無、回帰検出をどのレイヤまで敷くかによって必要な体制は大きく変わるため、体制設計とコストは案件ごとに詰めるほかありません。
ハマりやすい 4 つの落とし穴
最後に、Claude Code Auto Mode を受託で運用するときに踏みやすい落とし穴を挙げます。
落とし穴 1: 「重要操作リスト」が古いまま放置される
開発が進むと新しい外部 API・新しい DB テーブルが増え、初回に決めたリストが現実と乖離します。スプリントごとにリスト棚卸しを必ず行います。
落とし穴 2: 監査ログが容量で消える
Auto Mode は 1 セッションで数 MB のログを生成します。デフォルト設定で運用すると、半年後にインシデント調査時にログが残っていない事故が起きます。S3 / R2 への日次アーカイブを最初に組みます。
落とし穴 3: モデル更新の “お試し” が本番に紛れる
新しいモデルが出ると試したくなりますが、案件途中で切り替えると回帰が出ます。検証用ブランチを別建てし、本番案件のモデルは固定します。
落とし穴 4: 顧客が直接 AI を触る誘惑
顧客側の担当者が「自分でも Claude Code を触りたい」と要望することがあります。直接アクセスを許すと責任分界が崩壊するため、「実行は受注側の環境経由、ログは全て共有」を原則にします。
まとめ — “速さ” と “顧客資産の保全” を両立する
Claude Code Auto Mode は、長時間の自律実行を現実的なコストで提供する画期的な仕組みですが、受託で使うには契約・承認・監査・回帰検出の 4 点セットを最初に揃えることが不可欠です。
Auto Mode を受託に持ち込めるかどうかは、突き詰めると Tier 3 に何を積めるかで決まります。本番 DB とシークレットを人の手に残せる案件なら夜間実行は現実的な選択肢ですし、そもそも環境が分離できていないなら、Auto Mode より前に片付けるべきものがある、というだけの話です。
自分の案件がどちら側にあるか判断がつかない段階でも構いません。既存の承認フローと重要操作リストの叩き台を突き合わせるところから、必要な体制の輪郭は見えてきます。そこから先の設計は案件の環境構成と契約形態でまるごと変わるので、まずは現状を お問い合わせフォーム でお聞かせください。
