はじめに
LLMベースのエージェントが実用域に入りつつあります。Claude Computer Use、GitHub Copilotのように、コンピュータ操作そのものを委ねるプロダクトが登場し、「いつか来る話」だったものが「今すぐ設計しなければならない話」になりました。
一方で、AIへの委任範囲が曖昧なまま使い始めたことで、思わぬ事故が起きるケースも目立ってきました。たとえば、AI主導でコードを書き進める開発スタイルの中で .env ファイルが成果物に混入し、そのままリポジトリへ push されて機密情報が露出する、といったリスクです。ここで重要なのは、個別の事故の真偽そのものではありません。委任の設計が先にないまま自律度だけを上げると、同種の事故は十分に起こりうるという構造です。
これは単純なヒューマンエラーとして片づけるべき話ではありません。何を AI に任せるのか、どこで人が承認するのか、どの操作を禁止するのか、何を監視するのか。こうした境界条件が未設計のままでは、エージェントは便利な自動化ではなく、責任の所在が曖昧な実行主体になってしまいます。
こうした問題に対して、エージェントを安定して動かすための外側の仕組みとして整理されつつあるのが「エージェントハーネス」です。ハーネスは、コンテキスト管理、ルール、ツール接続、評価と検証、安全と制御という 5 つの要素で、エージェントの振る舞いを外側から支える考え方です。
ここで言う「エージェント化」の対象は、実行時の業務システムだけではありません。AI が生成したコードを高い比率で採用しながら進める開発スタイル、GitHub Copilot Workspace、Devin のような自律型開発支援も、見方を変えれば同じ問題を抱えています。どちらも本質的には、権限、承認点、観測、停止条件をどう設計するかという委任設計の問題だからです。
この記事では、既存システムをいきなり全面的にエージェント化するのではなく、ハーネスを段階的に組み込みながら進める考え方を整理します。まず、なぜ「機能実装」より先に「委任設計」が必要なのかを確認します。次に、実行システムと開発プロセスを同じフレームワークで捉える理由を示します。そのうえで、どの順番で自律度を上げれば安全に導入できるかを考えていきます。
前提：「完全制御」と「完全自律」の間にある設計空間
従来のシステム設計は「完全制御」が前提でした。コードに書いた通りに動きます。予測可能で、監査しやすいです。
一方、LLMエージェントは「完全自律」の方向に引力を持ちます。目標を与えれば自分で計画し、ツールを使い、完了まで動きます。
この2つは対立ではなく、スペクトラムです。設計者の仕事は「どの操作をスペクトラムのどこに置くか」を決めることになります。
完全制御 ←─────────────────────────────→ 完全自律
固定ルール 確認ゲート付き委任 監視委任 完全委任
そして現実には、一つのシステムの中に複数の段階が混在するのが正しい姿です。経費精算の送信は完全制御のままで、日報の下書き生成は自律に委ねる、というように。
このフレームワークが適用できる2つの領域
このスペクトラムは、実行時システムと開発プロセスの2つの領域に同時に成立します。
| フェーズ | 実行時システムの例 | 開発プロセスの例 |
|---|---|---|
| フェーズ1（Read-only） | ログ解析・RAG回答・会議メモ抄録 | コードレビュー支援・ドキュメント要約・バグ候補リスト |
| フェーズ2（確認ゲート付き） | メール下書き → 承認して送信 | AIコード生成 → diffレビュー → 適用（バイブコーディング） |
| フェーズ3（自律実行） | 発注処理・データパイプラインの自律実行 | Issue → 実装 → PR作成まで完結（Devin等） |
バイブコーディングはフェーズ2の開発者版です。AIが提案し、開発者がdiffを確認して承認する。確認ゲートを人間が担っている構造は、業務システムの承認フローとまったく同じです。
ハーネスとの対応関係
ハーネスの「安全と制御」とは、危険な操作を止め、権限を絞り、実行範囲を限定する仕組みのことです。ここが弱いと、AIが賢くても「やってはいけないこと」を実行してしまいます。
この記事が体系化するのは、その「安全と制御」をどう段階的かつ3軸で設計するかです。
| ハーネスの5要素 | 本記事の扱い |
|---|---|
| コンテキスト管理 | 本記事のスコープ外 |
| ルール | 認証認可スコープとして具体化 |
| ツール接続 | 本記事のスコープ外 |
| 評価と検証 | コスト制御の再試行上限として一部扱う |
| 安全と制御 | 本記事の中心：3軸（認証認可・CRUD・コスト）に細分化 |
段階的エージェント化：3フェーズで進める
フェーズ1：読み取り専用エージェント
委ねるもの： 情報収集・集計・分析・提案生成
与えない権限： 書き込み・送信・削除
最初のステップとして最も安全なのが、エージェントに「読む権限」だけを与える形です。エージェントはデータを参照して提案しますが、実行は人間がします。
失敗しても「提案がおかしかっただけ」で済みます。責務の境界が最も鮮明なのがこのフェーズです。
実行システムの例：
- 過去の会議メモを読んでアクションアイテムを抽出する
- ログを解析して異常の候補を一覧化する
- 複数ドキュメントを横断して回答を生成する（RAG）
開発プロセスの例：
- コードレビューの指摘点をAIが洗い出す（読むだけ、修正はしない）
- ドキュメントを読み込んで実装方針の候補を提案する
- テスト結果を解析してバグ候補を一覧化する
このフェーズで確認すること：
- エージェントの出力品質は業務に耐えるか？
- どの情報ソースにアクセスさせるかは適切か？
- ログは残せているか？
フェーズ2：書き込みあり・確認ゲート付き
委ねるもの： 実行計画の立案＋実行
人間の関与： 実行前のGO/NO、または実行後のレビュー
書き込み・送信・更新を伴う操作に踏み込むフェーズです。ここからAgent Workflow（n8nなど）が制御インフラとして登場します。
Agent Workflowの役割は処理の自動化ではなく、**「人間の判断が必要なタイミングを設計・管理・実行するインフラ」**です。
エージェント → [計画・実行案を生成]
↓
Agent Workflow → [承認通知をTeams/メール等で送信]
↓
人間 → [GO / NO / 修正を返答]
↓
Agent Workflow → [実行 or キャンセル]
実行システムの例：
- 提案メールの下書きをエージェントが生成 → 人間が確認して送信
- データ更新SQLをエージェントが作成 → DBAが確認して実行
- 発注の候補リストをエージェントが作成 → 承認者がワンクリックで実行
開発プロセスの例（これがバイブコーディングの設計）：
- AIが実装コードを生成 → 開発者がdiff確認してGO/NO → 適用
- AIがテスト追加案を提示 → レビュー後にコミット
- AIがリファクタリング案を出す → 影響範囲を確認してから適用
2種類の確認ゲート：
| タイプ | タイミング | 用途 |
|---|---|---|
| 実行前確認 | エージェントが計画提示 → 人間がGO/NO | 予算使用・外部送信・重要ファイル更新 |
| 実行後確認 | エージェントが実行 → 結果を人間がレビュー | 下書き生成・分析レポート・提案資料 |
n8n フロー構成例：フェーズ2 承認ゲート
フェーズ3：自律実行（停止権限は保持したまま委任）
委ねるもの： 目標達成までの自律的な計画・実行
人間の関与： 異常時の通知受信・強制停止権限の保持
最も自律度が高いフェーズです。エージェントが複数ステップにわたって自律的に動きます。
ここでもAgent Workflowは不要にはなりません。むしろ役割が変わって、監督インフラとして機能します。
エージェント（自律実行中）
↓
Agent Workflow → ログ収集・ステップ追跡
↓
[閾値超え・想定外の動作]
↓
Agent Workflow → 自動停止 or 人間への通知
「いつでも止められる状態」を維持することが、フェーズ3を安全に運用する唯一の方法です。
開発プロセスの例：
- Devinなどのコーディングエージェントが Issue → 実装 → PR作成まで自律的に完結する
- CIが通った変更を自動マージ・デプロイする
- 依存パッケージの更新を自律的に検知・PR作成・マージする（Renovate / Dependabot系）
いずれも「ブランチ保護ルール」や「必須レビュアー設定」が機能していれば、人間はいつでも止められます。これがフェーズ3における「停止権限の保持」です。
n8n フロー構成例：フェーズ3 監視・自動停止
3つの制御設計：ハーネスの「安全と制御」を実装する
ハーネスの5要素のうち「安全と制御」は、実際の設計では3つの独立した軸として考えると扱いやすいです。フェーズを進める際に必ず設計すべき3軸を紹介します。この3つを守ることで、段階を踏んでいくたびに責務の境界が鮮明になります。
制御軸① 認証認可スコープ（操作を制御する）
エージェントに与える権限は「タスクに必要な最小限」に絞ります。これは最小権限の原則（Principle of Least Privilege） の、エージェント時代への応用です。
OWASPは2025年のLLMセキュリティTop 10で**LLM06：Excessive Agency（過大な権限）**をトップリスクに挙げ、「本来不要な権限やツールがLLMに与えられることで、攻撃やエラーが発生した際の影響範囲が広がる」と指摘しています。
段階移行の設計例：
フェーズ1：読み取り権限のみ（特定テーブル・フォルダのみ）
フェーズ2：特定テーブルへの INSERT のみ（DELETE不可）
フェーズ3：操作範囲を明示した上で Write 権限付与（外部送信は別途承認）
Agent Workflowの役割： IAMポリシーの動的切り替えゲート、権限の付与・剥奪を人間が承認するフローを担う。
開発プロセスへの適用：
- AIエージェント（Devin・Copilot Workspace等）にアクセスさせるリポジトリ・ブランチを明示的に制限する
- 本番ブランチへの直pushを禁止し、PR経由のみに絞る（ブランチ保護ルールがゲートとして機能する）
-
.envや認証情報ファイルへの読み取りを禁止する（.gitignoreに加え、エージェント設定でも明示）
n8n フロー構成例：制御軸① 権限スコープゲート
制御軸② 情報のCRUD制御（プライバシー漏洩・誤消失を防ぐ）
エージェントへの情報アクセスは「操作の種類（CRUD）」単位で段階管理します。
委譲の順序原則：
Read（参照）→ Create（新規作成）→ Update（更新）→ Delete（削除）
右に行くほどリスクが高くなります。Deleteは最後に、かつ「復元可能な設計が完成してから」委譲します。
具体的な設計指針：
- 個人情報・機密情報： エージェントに渡す前にマスキング処理をAgent Workflowで差し込む
- Update操作： 変更前後のdiffをログに残し、ロールバック手順を先に整備してから委譲
- Delete操作： 論理削除（ソフトデリート）＋バージョン管理が揃っていない段階では委譲しない
- 大量データ操作： 件数上限（例：一度に100件まで）をAgent Workflowで強制する
判断の目安はシンプルです。 そのエージェントが暴走・誤作動したとき、人間が5分以内に元に戻せるかどうかです。Yesなら委譲して構いません。Noなら先にインフラを整えましょう。
開発プロセスへの適用：
コードベースでも委譲の順序は同じです（Read → Create → Update → Delete）。
- Update（大量変更）はゲート必須： リファクタリングは「Update大量発生」です。変更ファイル数・行数に上限を設け、diffレビューを強制します
- Delete委譲の条件： Gitで全履歴が追跡可能 かつ 復元手順が整備済みの状態になってから
-
機密情報の隔離：
.env・シークレット管理ファイルはエージェントの読み取りスコープから除外します
制御軸③ トークン・コスト制御（無限ループと費用暴走を防ぐ）
LLMエージェントには「ループ暴走」というリスクがあります。自己レビュー（Reflection）や再計画を繰り返す設計では、終了条件が曖昧だと際限なくトークンを消費します。
設定すべき制限の種類：
| 制限の種類 | 設定値の例 | 担当 |
|---|---|---|
| 最大ステップ数 | 1タスク最大20ステップ | Agent Workflowで強制終了 |
| 最大トークン数 | 1タスク最大50,000トークン | LLM呼び出しレイヤーで制限 |
| タイムアウト | 最大10分 | Agent Workflowのタイムアウトノード |
| API費用閾値 | 1日 $10 超えたら停止＋通知 | コスト監視・Webhook通知 |
Agent Workflowの役割：
LLM APIへの呼び出し自体をAgent Workflowがゲートウェイとして中継することで、呼び出し頻度・費用・ステップ数の追跡が一元管理できます。
これはエージェントの自律度が上がるほど重要になります。フェーズ3では必須の設計です。
開発プロセスへの適用：
- 1PRあたりのAIイテレーション上限を設ける（際限なく修正ループさせない）
- CIの自動再実行回数に上限を設ける（失敗が続いても3回まで、それ以上は人間が確認）
- コーディングエージェントのタイムアウト設定（1タスク30分など）
n8n フロー構成例：制御軸③ ステップカウンタ＋タイムアウト
まとめ：責務の境界線が引けた設計が「エージェント化の完成形」
段階移行とは「エージェントに任せる範囲を少しずつ広げること」ではありません。
「その操作の責任を誰が持つか」を、一つひとつ明示的に設計していくプロセスです。
フェーズを踏むほど、３つの制御軸を設計するほど、「ここからここまではエージェントの責務、ここからは人間の責務」という境界が鮮明になります。
その境界が引けたとき、初めてシステムは「エージェント化できた」と言えます。
ハーネスを段階的に構築するということ
先のハーネス記事は「ハーネスとは何か」を整理しています。ではハーネスは一度に構築すべきでしょうか？
そうではありません。既存システムであれ、開発プロセスであれ、フェーズに合わせてハーネスの要素を段階的に組み込むことが現実的で安全です。
| フェーズ | 主に構築するハーネス要素 |
|---|---|
| フェーズ1（Read-only） | ルール定義・コンテキスト管理 |
| フェーズ2（確認ゲート付き） | 安全と制御（認証認可・CRUD）＋ツール接続 |
| フェーズ3（自律実行） | 安全と制御（コスト制御）＋評価と検証（停止判定） |
Agent Workflowがハーネスの実装基盤になる
Agent Workflow（n8nなど）は、このハーネスをコードを書かずに実装できる基盤として機能します。
自律型エージェントがどれだけ進化しても、以下の設計はAgent Workflowの仕事であり続けます。
- 人間の判断が必要なタイミングを決める（承認ゲートの設計）
- エージェントを監視・停止する（監督インフラ）
- コスト・権限・CRUD操作を制御する（安全インフラ）
これらは「処理の自動化」ではなく「委任の境界を管理する設計」です。そしてそれは、エージェントが自律化するほど重要になります。
参考
- Anthropic "Building Effective Agents" (2024/12) — Workflow vs Agentの公式定義
- OWASP LLM Top 10 2025 — LLM06: Excessive Agency
- Andrew Ng "Agentic Design Patterns" (2024/3, DeepLearning.AI)
Discussion