AIエージェントの内製・自作において成否を分けるのは、ツールの機能差ではなく「タスクの不確実性に応じた自律度」と「権限境界の設計」です。プロンプトによる指示出しにとどまる「チャット型」、トリガーを起点にツールを自律選択する「自動化型」、そしてファイルシステムやシェル環境へ直接介入する「実行型」という3つのアーキテクチャの構造差を理解し、リスクに応じた権限統制を行うことが、エンタープライズ実装における最短の道筋となります。
AIエージェント3類型の技術構造とアーキテクチャ比較
AIエージェントの構築基盤は、どこで推論が走り、どの範囲まで実行環境へのアクセスを許容するかによって、大きく3つの型に分類されます。単一のLLMに対する入出力の反復から、API連携、自律的なコード実行ループへと抽象度と影響範囲が拡大します。
1. チャット型：コンテキスト注入と指示テンプレートの固定化
Geminiのスキル機能などに代表されるチャット型は、ユーザーの入力に対してあらかじめ定義されたシステムプロンプトやタスク制約を注入する構造です。推論環境は完全にプラットフォーム内部で完結しており、外部環境への破壊的変更のリスクが極めて低い点が特徴です。定型的な要約、情報抽出、ドラフト作成など「推論のみで完結する業務」に最適化されています。
2. 自動化型：イベント駆動と動的ツール選択（オーケストレーション）
n8nやDifyなどを利用する自動化型は、Webフックやスケジュール実行などの外部トリガーを起点とします。特徴的なのは、LLMが「次にどのツール（APIやスクレイピング機能など）を呼び出すべきか」をFunction Calling等を通じて自律判断する点です。固定的なワークフローと動的な推論が融合した構成を取り、情報収集からSlack通知、データベース更新などのパイプライン処理を無人運用できます。
3. 実行型：自律ループとローカル環境介入
Claude CodeやClaude Agent SDKなどに代表される実行型は、LLMがコードを生成し、ローカル環境でそれを実行して得られたエラーや出力を再評価しながらゴールを目指す、完全な自律ループ（ReActフレームワーク等）を備えています。ファイル操作やコマンドライン操作を伴うため、最も自由度が高い反面、環境汚染やデータ損失のリスクを直接内包します。
| アーキテクチャ類型 | 代表的な実装ツール | 自律判断の範囲 | 環境アクセス権限 | 主な業務適用領域 | ガバナンス難易度 |
|---|---|---|---|---|---|
| チャット型 | Geminiスキル、Claudeスキル | 指示解釈・テキスト生成 | サンドボックス内のみ | 会議録要約、一次ドラフト作成 | 低（安全） |
| 自動化型 | n8n、Dify | タスク達成のためのツール選択 | 認可されたWeb API/DB | 定期市場調査、監視アラート処理 | 中（API権限の分離が必要） |
| 実行型 | Claude Code、Agent SDK | コード生成・実行・デバッグループ | ローカルファイル、シェル環境 | データ分析パイプライン構築、開発補助 | 高（サンドボックス化が必須） |
ビジネス実装における「自律性・権限分離」の設計原則
AIエージェントを実務に組み込む際、最大の障壁となるのはLLM特有のハルシネーション（もっともらしい嘘）と、意図しない外部操作です。これを技術的に抑止するためには、以下の3原則に基づいたシステム設計が求められます。
1. 自律性の3段階レベル設計（Human-in-the-Loop）
初期導入時は全自動化を目指さず、業務影響度に応じて以下の順でエージェントの権限を段階的に昇格させる設計が不可欠です。
- Level 1（提案のみ）：エージェントは下書きや集計のみ行い、外部送信やDB更新は人間が手動実行する。
- Level 2（承認後実行）：エージェントが実行計画（APIパラメータ等）を作成し、Slack通知等で人間の承認ボタン押下を契機に実行する。
- Level 3（自律実行）：読み取り専用処理や低リスクな通知業務に限定し、人手を介さず完全自律で処理を完了させる。
2. 入力・出力スキーマの厳密な定義
エージェントの出力が後続のシステムや人間に引き渡される際、自然言語の揺らぎは重大なエラー要因になります。システムプロンプト内でJSON等の構造化出力形式を強制し、事前定義されたキー以外の出力を許可しないバリデーションレイヤーを挟むことで、ダウンストリーム側の誤動作を未然に防ぎます。
3. 最小権限原則（PoLP）に基づくクレデンシャル管理
特にn8n等の自動化型やClaude Code等の実行型において、APIキーの権限スコープは最小限に絞る必要があります。全権限を持つAdminキーを渡すのではなく、「特定チャンネルへのPostのみ」「特定ディレクトリのReadのみ」に制限したクレデンシャルを割り当てることが、インシデント発生時の被害極小化につながります。
実務担当者がとるべき導入ロードマップ
エージェント導入の成否は、業務の解像度に依存します。「情報収集を自動化する」といった抽象的な目標のままツール選定を進めると、要件定義の破綻を招きます。「毎朝8時に特定RSSから3件を抽出し、指定フォーマットでSlackに投稿する」といった単一責務のタスク（Single Responsibility）から着手し、プロンプトの調整とエラー耐性の検証を終えた段階で、後続処理を連携させていくアプローチが最も手戻りを抑えられます。
よくある質問
Q1. 社内機密データを扱う場合、どの型を選択すべきですか？
外部クラウドへのデータ送信ポリシーに依存しますが、セルフホスト可能な自動化型ツール（オンプレミス環境のn8n等）を採用し、社内プライベートクラウド上のLLMエンドポイントと接続する構成が安全です。実行型を用いる場合も、アクセス可能なディレクトリを厳格に制限したコンテナ環境内で動作させる必要があります。
Q2. チャット型から自動化型へ移行するタイミングの判断基準は何ですか？
「人間が能動的にチャットを開いて入力を促す回数」がボトルネック化したタイミングです。業務が時間起点（定時実行）またはイベント起点（メール受信、データ更新等）で発生し、かつインプットとアウトプットの形式がパターン化されている場合は、チャット型を廃止してn8n等による自動化型へ移行すべきです。
Q3. 実行型エージェントの導入コストとリスクはどう評価すべきですか？
実行型は推論と試行錯誤の反復（マルチターン）を伴うため、トークン消費量およびAPI利用料がチャット型に比べて数倍から数十倍に膨らむ傾向があります。また、コマンド実行権限を持つため、テスト環境のコンテナ分離（Docker等）を前提とした運用設計コストをあらかじめ織り込む必要があります。