AIコーディングエージェントを「放し飼い」にする技術 — 自律実行を安全に運用する3層ガードレール設計と実践プロンプト集

Posted at 2026-03-31

はじめに：2026年3月、AIが「手放し運転」を始めた

2026年3月。AIコーディングエージェントが、ついに「手放し運転」を始めた。

Claude Code の auto mode。Codex の subagents。Gemini CLI の Plan Mode。

これらが意味していることは、結構シンプルなんです。 AIが人間の承認なしに、自分で判断してコードを書き、ファイルを作り、テストを走らせる ということ。

寝てる間に PR レビューが終わっている。朝起きたらリファクタリングが完了している。そんな世界が、もう「未来」じゃなくて「今月の話」になっている。直近の業界調査でも、大多数のエンジニアがAIツールを日常的に使い始めているという結果が出ています。

...でも、正直「怖くないですか？」

僕の周りのエンジニアに聞いても、だいたい同じ答えが返ってくるんです。「便利なのは分かるけど、全部手動承認にしてる」と。

気持ちは痛いほどわかる。自分が見ていない間に、AIがデータベースのマイグレーションを勝手に走らせたら...。本番環境の設定ファイルを書き換えたら...。そう考えると、全部手動にしたくなる。

でも、それだとせっかくの自律実行モードが宝の持ち腐れになってしまう。

この記事では、 「安全に放し飼いにする」ための設計パターン を体系的に整理します。3層のガードレール設計と、そのまま使えるプロンプト例・コード例を厚めに用意しました。

読み終わった後に「ここまで設計すれば、安心して任せられるかも」と思ってもらえたら、書いた甲斐がある。

まず5分で試す：最小限の安全設定

いきなり設計パターンの話をしても、手を動かせないと意味がないので。まず各ツールで 「安全に自律モードを有効にする」最初の1ステップ から始めましょう。

Claude Code：サンドボックス付き auto mode

Claude Code の auto mode は、2026年3月にリリースされた機能で、ユーザーに代わって権限を管理してくれるモードです。

ただし、いきなりフルオートにするのはやめた方がいい。 まずは読み取り専用のタスクから始める のがコツです。

# auto mode を有効にする（Claude Code の設定）
# まずは安全なタスクから試す
claude --auto

# 自律モードでコードレビューだけ任せる例
claude "このPRの差分をレビューして、問題点をmarkdownで出力して。
ファイルの変更は一切しないで。読み取りだけでお願い。"

ポイントは「ファイルの変更は一切しないで」と明示的に伝えること。auto mode でも、 プロンプトで行動範囲を制約できる んです。

Codex CLI：サンドボックスモード

Codex CLI はデフォルトでサンドボックス実行になっているので、実は最初から安全寄りに設計されています。

# Codex CLI のサンドボックスモードは、ネットワークアクセスと
# ファイルシステム書き込みを制限した状態で実行される

# 安全にsubagentを試す（explorer = 読み取り専用）
codex "このリポジトリの構造を分析して、
改善提案をmarkdownにまとめて。
subagentはexplorerロールで実行して。"

Codex のsubagentには3つのロールがあるんです。

ロール	権限	用途
explorer	読み取り専用	コード分析、構造把握、レビュー
worker	読み書き可	実装、リファクタリング、テスト作成
default	標準	一般的なコーディングタスク

最初は explorer ロールだけで試す 。これが一番安全な入り口です。

Gemini CLI：Plan Mode で「計画だけ」見る

Gemini CLI の Plan Mode は、「まず計画を立てて、それを人間が確認してから実行する」というモードです。

# Plan Mode を有効にして、変更計画だけ出力させる
gemini --plan "このプロジェクトのテストカバレッジを80%まで上げるには、
どのファイルにどんなテストを追加すればいいか計画して。
まだ実行はしないで。"

Plan Mode のいいところは、 「AIがこれからやろうとしていること」を人間が事前に確認できる 点です。計画を見て「OK」と思えたら実行に移す。思えなかったら修正指示を出す。

この「計画 → 承認 → 実行」のサイクルが、自律実行の第一歩になる。

自律実行の「怖さ」を分解する：タスク分類マトリクス

「怖い」という感情を、もう少し構造化してみましょう。

なんでAIの自律実行が怖いのか。それは 「何をされるか分からない」 からですよね。逆に言えば、 「何をするか分かっていれば怖くない」 。

ここで使えるのが、タスク分類マトリクスです。

安全度の4段階

タスクを「安全度」で分類すると、こうなります。

レベル	名前	具体例	リスク
L1	Read-only	コード分析、レビュー、検索	ほぼゼロ
L2	Write-local	ローカルファイルの作成・編集	Git で戻せる
L3	Write-remote	API呼び出し、DB操作、デプロイ	取り消し困難
L4	Destructive	削除、マイグレーション、本番変更	不可逆

自律度の3段階

次に「自律度」で分類する。

モード	説明	人間の関与
Manual	毎回承認が必要	全タスク確認
Semi-auto	特定条件で自動実行	例外時のみ確認
Full-auto	完全自律	事後レビューのみ

マトリクスの使い方

この2軸を掛け合わせると、こういう判断ができる。

              Manual    Semi-auto    Full-auto
Read-only     △過剰      ○適切       ◎推奨
Write-local   ○安全      ◎推奨       ○条件付き
Write-remote  ◎推奨      ○条件付き   △要注意
Destructive   ◎必須      △要注意     ✕禁止

Read-only × Full-auto は、今すぐ導入して大丈夫 です。コードの読み取りしかしないので、壊れようがない。

逆に、 Destructive × Full-auto は「禁止」 。本番DBの削除を自動で実行するエージェントなんて、誰も欲しくないですよね。

大事なのは、自分のタスクがこのマトリクスのどこに位置するかを意識すること。それだけで「どこまで任せていいか」の判断ができるようになる。

Layer 1: Permission Gate（権限ゲート設計）

3層ガードレールの最初の層。 「AIが何をしていいか、何をしてはいけないか」を事前に定義する 層です。

パターン1: Allowlist（許可リスト）方式

「許可されたことだけやっていい」という最も安全なアプローチです。

<!-- AGENTS.md / CLAUDE.md に記述する権限定義の例 -->

## 自律実行の権限ルール

### 許可するアクション
- `src/` 配下のTypeScriptファイルの読み取り・編集
- `tests/` 配下のテストファイルの作成・編集
- `npm test` の実行
- `npm run lint` の実行
- `git diff` / `git status` の実行

### 禁止するアクション（これらは絶対に自律実行しない）
- `git push` / `git commit`（人間が確認してからコミット）
- `.env` ファイルの読み取り・編集
- `rm -rf` を含むコマンド
- データベース操作（migration, seed, drop）
- 外部APIの呼び出し（fetch, axios）
- `package.json` の依存関係変更

これを AGENTS.md に書いておけば、AIエージェントはセッション開始時にこのファイルを読んで、権限を理解した上で動いてくれます。

ちなみに AGENTS.md というのは、AIコーディングエージェント向けの設定ファイルで、README.md の「AI版」みたいなものです。プロジェクトの構造やコーディング規約、やっていいこと・ダメなことをMarkdownで書いておくと、Claude Code や Codex がセッション開始時に自動で読み込んでくれる。

パターン2: Scope-based（スコープ）方式

ディレクトリ単位で権限を分けるパターン。モノレポや大きなプロジェクトで特に有効です。

<!-- AGENTS.md に記述するスコープベース権限の例 -->

## ディレクトリ別権限

### `src/components/` — Full-auto OK
- UIコンポーネントの作成・編集を自律実行で許可
- テストファイルの自動生成も可

### `src/api/` — Semi-auto（計画のみ自律、実行は承認後）
- API層の変更は計画を出力した後、人間が確認してから実行
- エンドポイントの追加・変更は影響範囲が大きいため

### `src/db/` — Manual only（毎回承認必須）
- データベーススキーマ・マイグレーションは全て手動承認
- 一切の自律実行を禁止

### `infrastructure/` — Read-only
- インフラ設定は読み取りのみ許可
- 変更提案はmarkdownで出力し、人間が適用

パターン3: 権限チェックスクリプト

AGENTS.md だけでは不安...という場合は、実際にファイルシステムの変更を検知するスクリプトを組み合わせる方法もある。

#!/bin/bash
# scripts/agent-guard.sh
# AIエージェントの変更を監視し、禁止パスへの書き込みを検知する

FORBIDDEN_PATHS=(
  ".env"
  "docker-compose.prod.yml"
  "infrastructure/"
  "*.secret.*"
)

# git diffで変更されたファイルを取得
changed_files=$(git diff --name-only)

for file in $changed_files; do
  for pattern in "${FORBIDDEN_PATHS[@]}"; do
    if [[ "$file" == $pattern ]]; then
      echo "⚠️ 禁止パスへの変更を検知: $file"
      echo "この変更は自動ロールバックされます"
      git checkout -- "$file"
      exit 1
    fi
  done
done

echo "✅ 権限チェック通過"

<!-- AGENTS.md にフック設定を追記 -->

## 自動チェック
- コード変更後、必ず `bash scripts/agent-guard.sh` を実行すること
- このスクリプトが失敗した場合、変更を全てロールバックすること

こうすることで、AGENTS.md の「お願いベース」と、スクリプトの「強制ベース」の二重防御になります。

Layer 2: Runtime Monitor（実行時監視設計）

2層目は、 AIが動いている最中にリアルタイムで監視する 層です。

権限ゲートが「入口の門番」だとすれば、ランタイムモニターは「巡回中の警備員」みたいなものかなと。

パターン1: ファイル変更の差分監視

AIエージェントが作業中に、変更されたファイルの量と内容をリアルタイムで追跡する。

// scripts/monitor-changes.ts
// AIエージェントの変更を定期的に監視するスクリプト

import { execSync } from 'child_process';
import * as fs from 'fs';

interface ChangeReport {
  timestamp: string;
  filesChanged: number;
  linesAdded: number;
  linesDeleted: number;
  changedFiles: string[];
  alerts: string[];
}

function checkChanges(): ChangeReport {
  const diff = execSync('git diff --stat', { encoding: 'utf-8' });
  const files = execSync('git diff --name-only', { encoding: 'utf-8' })
    .trim().split('\n').filter(Boolean);

  const numstat = execSync('git diff --numstat', { encoding: 'utf-8' });
  let added = 0, deleted = 0;
  numstat.trim().split('\n').forEach(line => {
    const [a, d] = line.split('\t');
    added += parseInt(a) || 0;
    deleted += parseInt(d) || 0;
  });

  const alerts: string[] = [];

  // アラート条件
  if (files.length > 20) {
    alerts.push(`⚠️ 変更ファイル数が多すぎます: ${files.length}件`);
  }
  if (deleted > 200) {
    alerts.push(`⚠️ 大量削除を検知: ${deleted}行`);
  }
  if (files.some(f => f.includes('.env') || f.includes('secret'))) {
    alerts.push('🚨 機密ファイルへの変更を検知');
  }

  return {
    timestamp: new Date().toISOString(),
    filesChanged: files.length,
    linesAdded: added,
    linesDeleted: deleted,
    changedFiles: files,
    alerts,
  };
}

// 30秒ごとに監視
setInterval(() => {
  const report = checkChanges();
  if (report.alerts.length > 0) {
    console.error('=== ALERT ===');
    report.alerts.forEach(a => console.error(a));
    // ここでSlack通知やメール送信を追加できる
  }
  fs.appendFileSync(
    'agent-monitor.log',
    JSON.stringify(report) + '\n'
  );
}, 30000);

パターン2: コスト上限ガード

AIエージェントが外部APIを叩く場合、コスト爆発を防ぐガードが必要です。

<!-- AGENTS.md に記述するコスト制約の例 -->

## コスト制約ルール

### トークン予算
- 1タスクあたりの最大トークン消費: 100,000トークン
- 予算の80%を超えたら、現在の作業を中断して中間報告を出力すること
- 予算を超過する場合は、残りの作業内容をmarkdownで出力して人間に引き継ぐこと

### API呼び出し制限
- 外部API呼び出しは1タスクあたり最大10回
- 同一エンドポイントへの連続呼び出しは3回まで
- レート制限(429)を受けた場合は即座にタスクを中断すること

### 実行時間制限
- 1タスクの最大実行時間: 30分
- 15分経過時点で進捗レポートを出力すること

パターン3: 構造化ログの収集

AIエージェントの行動を後から追跡できるように、構造化ログを出力させるプロンプトパターンです。

<!-- AGENTS.md に追記する構造化ログルール -->

## 行動ログルール

タスク実行中、以下のフォーマットで行動ログを `agent-actions.jsonl` に追記すること:

```json
{
  "timestamp": "ISO-8601",
  "action": "read|write|execute|api_call",
  "target": "ファイルパスまたはコマンド",
  "reason": "なぜこのアクションを取ったかの1行説明",
  "result": "success|failure|skipped",
  "details": "結果の詳細（エラーメッセージ等）"
}

必ず全てのアクションをログに記録すること。ログを書かないアクションは禁止。


これが地味に効く。AIの行動ログが残っていれば、何か問題が起きた時に **「いつ、何を、なぜやったか」を追跡できる** 。これは人間のデバッグでも同じですよね。

---

## Layer 3: Recovery Pipeline（リカバリ設計）

3層目は、 **「それでも壊れた時にどう戻すか」** の設計です。

正直に言うと、ここが一番大事かもしれない。完璧な権限設計と完璧な監視をしても、想定外は起きる。だからこそ、リカバリを最初から設計しておく。

### パターン1: Git Worktree 戦略

AIエージェントの作業を、メインブランチから隔離する最もシンプルな方法です。Git worktree というのは、1つのリポジトリから複数の作業ディレクトリを作れるGitの機能です。ブランチを切り替えなくても、別フォルダで別ブランチの作業ができる。

```bash
#!/bin/bash
# scripts/agent-workspace.sh
# AIエージェント用の隔離されたワークスペースを作成する

PROJECT_DIR=$(pwd)
AGENT_BRANCH="agent/task-$(date +%Y%m%d-%H%M%S)"
AGENT_DIR="/tmp/agent-workspace-$(date +%s)"

# 1. エージェント用ブランチを作成
git branch "$AGENT_BRANCH"

# 2. worktree で隔離ディレクトリを作成
git worktree add "$AGENT_DIR" "$AGENT_BRANCH"

echo "✅ エージェント用ワークスペース作成完了"
echo "  ブランチ: $AGENT_BRANCH"
echo "  ディレクトリ: $AGENT_DIR"
echo ""
echo "AIエージェントにはこのディレクトリで作業させてください。"
echo "作業完了後、PRとしてレビューできます。"
echo ""
echo "後片付け:"
echo "  git worktree remove $AGENT_DIR"
echo "  git branch -D $AGENT_BRANCH  # 不要な場合"

この方法のいいところは、 AIが何をやっても、メインブランチには一切影響しない こと。作業が終わったら PR として確認できるし、ダメだったらブランチごと捨てればいい。

パターン2: 自動ロールバックスクリプト

監視スクリプトと連携して、異常を検知したら自動でロールバックする仕組み。

#!/bin/bash
# scripts/auto-rollback.sh
# 異常検知時の自動ロールバック

SNAPSHOT_TAG="agent-snapshot-$(date +%Y%m%d-%H%M%S)"

# 作業開始前にスナップショットを作成
create_snapshot() {
  git stash push -m "$SNAPSHOT_TAG" --include-untracked
  git stash pop
  git tag "$SNAPSHOT_TAG"
  echo "📸 スナップショット作成: $SNAPSHOT_TAG"
}

# ロールバック実行
rollback() {
  echo "🔄 ロールバック実行中..."
  git checkout -- .
  git clean -fd
  git reset --hard "$SNAPSHOT_TAG"
  echo "✅ $SNAPSHOT_TAG の状態に復元しました"
}

# テスト実行で検証
verify() {
  echo "🧪 変更後の検証中..."
  if npm test 2>/dev/null; then
    echo "✅ テスト通過"
    return 0
  else
    echo "❌ テスト失敗 — ロールバックします"
    rollback
    return 1
  fi
}

パターン3: 人間エスカレーションフロー

「自動で解決できない」場合に、人間に引き継ぐフローを事前に設計しておく。

<!-- AGENTS.md に記述するエスカレーションルール -->

## エスカレーションルール

以下の状況が発生した場合、作業を即座に中断し、人間にエスカレーションすること:

### 即座にエスカレーション（作業中断）
1. テストが3回連続で失敗した
2. 予期しないエラーが発生し、原因が特定できない
3. 機密ファイル（.env, secrets, credentials）への操作が必要になった
4. 外部サービスのAPI制限に到達した
5. 変更の影響範囲が当初の想定を大きく超えた

### エスカレーション時の報告フォーマット
```markdown
## エスカレーション報告

**状況**: [何が起きたか]
**原因**: [なぜ起きたか、または不明]
**影響範囲**: [どのファイル/機能に影響があるか]
**試したこと**: [自分で試した対処法]
**提案**: [人間にやってほしいこと]
**現在の状態**: [コードは安全な状態か、ロールバック済みか]

エスカレーション報告は agent-escalation.md に出力すること。


この3つのパターン — **隔離・自動復旧・エスカレーション** — を組み合わせることで、「壊れても大丈夫」な状態を作れます。

ここまで設計できていれば、「もしAIが変なことをしても戻せる」という安心感がある。その安心感があるからこそ、自律実行モードを思い切って使える。ガードレールは制約じゃなくて、 **安心して飛ばすための安全ベルト** なんです。

> ※ ここで紹介したスクリプトはあくまで例示です。本番環境に適用する前に、必ずチーム内でレビューし、ステージング環境で検証してください。

---

## チーム運用チェックリスト

個人で試すのと、チームで導入するのでは話が変わってくる。チームで自律実行モードを導入する時に確認すべき項目をまとめました。

### 導入前チェック（10項目）

```markdown
## AIエージェント自律実行 導入チェックリスト

### 権限設計
- [ ] AGENTS.md に許可/禁止アクションを明記した
- [ ] ディレクトリ別の権限レベルを定義した
- [ ] 機密ファイルのパスを禁止リストに追加した

### 監視体制
- [ ] ファイル変更の差分監視スクリプトを用意した
- [ ] コスト上限（トークン/API/時間）を設定した
- [ ] 構造化ログの出力ルールを定義した

### リカバリ
- [ ] Git worktree / ブランチ戦略を決めた
- [ ] 自動ロールバックの条件とスクリプトを用意した
- [ ] エスカレーションフローと報告フォーマットを定義した

### 段階導入
- [ ] まずRead-only タスクから開始し、段階的に権限を拡大する計画を立てた

段階的な権限拡大のロードマップ

一気にフルオートにするのは、やっぱりリスクが高い。こういう段階で進めるのが現実的かなと。

週	フェーズ	許可範囲	人間の関与
1-2週目	Observer	Read-only タスクのみ	全結果をレビュー
3-4週目	Assistant	+ ローカルファイル編集	差分をレビュー
5-6週目	Worker	+ テスト実行、lint修正	アラート時のみ
7-8週目	Autonomy	+ PR作成、コミット	事後レビュー

各フェーズで 1週間以上トラブルがなかったら次に進む 。問題が起きたら前のフェーズに戻る。

この「段階的に信頼を積み上げる」アプローチは、実は人間の新メンバーのオンボーディングと同じ発想なんです。最初から全権限を渡す会社はないですよね。AIエージェントも同じ。

まとめ：「放し飼い」は設計でできる

ここまでの内容を振り返ると、3層ガードレールはこうなります。

┌─────────────────────────────────────┐
│  Layer 1: Permission Gate           │
│  「何をしていいか」を事前定義       │
│  → AGENTS.md / allowlist / scope    │
├─────────────────────────────────────┤
│  Layer 2: Runtime Monitor           │
│  「何をしているか」をリアルタイム監視│
│  → diff監視 / コスト上限 / 構造化ログ│
├─────────────────────────────────────┤
│  Layer 3: Recovery Pipeline         │
│  「壊れた時にどう戻すか」を事前設計 │
│  → worktree / auto-rollback / 人間  │
└─────────────────────────────────────┘

この3つが揃っていれば、AIコーディングエージェントを「安全に放し飼い」にできる。

ちょっと考えてみてほしいんです。

2026年4月の今、ほとんどのエンジニアがAIツールを毎週使っている。でも「自律実行モードを設計込みで運用している」人は、まだそんなに多くないと思う。

ここに差がつくポイントがある。

AIの進化は止まらない。来月にはもっと賢い自律モードが出てくるかもしれない。でも、今日この記事で整理した 「権限ゲート」「実行時監視」「リカバリパイプライン」 の3層構造は、どんなツールが出てきても応用できる設計思想です。

人間の仕事は、もう「コードを書くこと」じゃない。

「AIが安全に動ける環境を設計すること」 。

それが、2026年のエンジニアの新しい役割なんだと思います。

参考

※ ツールのバージョンアップにより設定方法や機能が変わる場合があります。最新の公式ドキュメントを併せて確認してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up