この記事で扱うこと
- AIエージェントがERP/CRM/HRISなどの基幹システムと連携する際のアーキテクチャ上の課題
- システムのAPI設計、アクセス権限、データ整合性、監査の現実的な問題
- 段階的に自律性を高める「Read → Recommend → Act」成熟モデル
- イベント駆動設計とAPIファサードによる実装アプローチ
- CIO/COO/CHRO/変革リーダーが問うべきチェック観点
なぜAIエージェントは基幹システムで止まるのか
経理チームが月次決算を自動化するAIエージェントを導入したとしよう。エージェントは請求書を読み取り、発注書と照合し、不一致を検出する。ここまでは順調だ。しかし次に、入庫が完了しているか、仕入先がアクティブか、請求書が支払い保留ワークフローに入っているかを確認しようとした瞬間、エージェントは停止する。
これはAIモデルの性能問題ではない。アーキテクチャの問題だ。
ERP、CRM、HRISといった基幹システムは、単なる「クエリできる巨大データベース」ではない。これらは業務状態の公式記録であり、すべてのトランザクションは検証され、制御されている。エージェントがその状態を理解できなければ、まともな判断はできない。しかし、ほとんどの基幹システムは、標準化とトランザクション制御のために設計されており、動的で半自律的なインタラクションを想定していない。
結果として、有望なエージェントPoCは壁にぶつかる。CIOはアーキテクチャ問題と見る。COOはプロセス設計問題と見る。CFOとCHROは統制と説明責任の問題と見る。全員が正しい。
Read（読み取り）からAct（実行）までの段階的アプローチが、エンタープライズ基幹システムにおける実践的な道筋を示す
ボトルネックはAIではなく「システム側の準備不足」
エージェントが実際の業務を処理しようとしたとき、何が起こるかを見てみよう。
リアルタイムアクセスの欠如
多くの基幹システムは依然としてバッチ処理や遅いポイントツーポイント統合に依存している。APIが存在しても、人間が操作する構造化アプリケーション向けに設計されており、エージェントが複数のエンドポイントを順次呼び出し、ポリシー検証で一時停止し、承認後に再開するという動作を想定していない。
アクセス制御のミスマッチ
基幹システムの権限は人間のロール向けに定義されている。「デジタルワーカー」に狭いスコープの権限を付与する設計になっていない。結果として、企業はエージェントに過剰な権限を与えるか、まったく与えないかの二択を迫られる。
セマンティックレイヤーの不在
実際の業務ルールはERPやCRMの中だけに存在するわけではない。スプレッドシート、ローカルのSOP、メール、ナレッジベース、文書化されていない運用習慣に散在している。基幹システムだけに接続したエージェントは、常にコンテキストを誤解する。
結論：システムが準備できているという前提は、ほぼ常に誤りである。
唯一必要な成熟度モデル：Read → Recommend → Act
最もよくある失敗は、エージェントにいきなりトランザクション実行を許可することだ。はるかに健全なアプローチは段階的である。このモデルは単なる技術ロードマップではなく、リスク管理、信頼構築、運用モデル成熟の手段でもある。
Stage 1: Read — 触らずに理解する
概要：読み取り専用アクセスから始める。エージェントの役割は、トランザクションコンテキストの理解、例外の検出、ステータスの要約、インサイトや優先順位の提示に限定する。
実装例：
- 経理：元帳データ、照合ステータス、例外履歴を読み取り、決算遅延リスクのある勘定をフラグ付け
- 購買：調達依頼、仕入先ステータス、契約、購買履歴を読み取り、適切な購買ルートを案内
- カスタマーオペレーション：有人対応前にケースサマリーを準備
- HR：オンボーディングの停滞をプロアクティブに通知
ビジネス価値：データ検索時間の短縮、例外の優先順位付け、手動ハンドオフの削減。ただし、読み取りだけではコスト構造は変わらない。意思決定やトランザクション作成は依然として人間が必要。
Stage 2: Recommend — 準備してから承認を得る
概要：エージェントは読み取りだけでなく、トランザクションのドラフト作成、ワークフローリクエストの生成、アクション推奨の作成、次のステップのトリガーを行う。ただし、すべて人間の承認が必要。
実装例：
- 買掛金：請求書不一致を検出し、根本原因分析を準備、解決ケースをドラフトしてレビューに回す
- 営業：アカウントマネージャーに次善策を準備、商談更新をドラフト
- HRIS：従業員データ変更をドラフトするが、承認はHRまたはライン管理者
- IT運用：テレメトリを収集し、根本原因を提案、Runbookアクションを準備するが、エンジニアが承認
注意点：承認ワークフローが貧弱だと、ボトルネックが「データ検索」から「エージェントドラフトの承認待ち」に移るだけになる。承認は本当に必要なアクションに限定し、十分なコンテキストと明確なSLAを設定すべき。
Stage 3: Act — 境界付きの自律実行
概要：最も成熟した段階。エージェントが基幹システム内で直接アクションを実行できる。キーワードは境界付き（bounded）。無制限のトランザクション作成ではなく、限定された自律性：特定のシナリオ、明確なポリシーと閾値、完全なログ、ロールバックまたは補償アクション、動作逸脱時のキルスイッチ。
実行可能な例：
- カスタマーサービス：チケットステータス更新、標準コミュニケーション送信、ポリシー範囲内の小口注文変更
- 債権管理：自動フォローアップ送信、支払い確約リマインダー作成
- IT運用：特定サービスの再起動など低リスクな復旧作業
- 購買：高度に標準化されたカテゴリの発注書ドラフト
絶対にStage 3にすべきでない領域：
- 重要な財務管理（例：材料仕訳転記）
- 高額な仕入先マスタ変更
- 従業員報酬決定
- 与信承認
- 高額な顧客ポリシー変更
これらは、はるかに長い間、人間をループに残すべきである。
「聞かれるのを待つ」エージェントから「変化に応答する」エージェントへ
多くの初期エージェント実装は受動的だ。ユーザーが質問したりボタンを押したりしたときだけ動作する。これはCopilotとしては問題ないが、エージェント運用モデルとしては、業務の変化に応じて能動的に動作するパターンの方がはるかに強力である。
エージェントは以下のようなシグナルを受け取ったときに最も効果的に動作する：
- 注文変更
- チケットエスカレーション
- 請求書期限超過
- 支払い失敗
- 在庫例外
- 従業員オンボーディング遅延
- 出荷リスク
実装パターン
イベントバス：エンタープライズシステムが運用イベントを共有プラットフォームに公開し、エージェントが関連するものだけを購読する。
Change Data Capture (CDC)：ネイティブイベントが利用できない場合、トランザクションデータの変更をキャプチャする。
イベント駆動設計は可観測性も向上させる。すべてのトリガー、判断、アクションがトレーサブルなイベントチェーンになる：イベント発生 → エージェント起動 → 追加データ取得 → ポリシーチェック → アクション実行またはエスカレーション。運用、リスク、監査チームにとって、これはエージェントが静かにバックグラウンドで動作するよりはるかに健全である。
システムが完璧になるのを待たない
企業が動き出せない理由の一つは、「すべての基幹システムをモダナイズしてからでないとエージェントは使えない」という前提だ。それは非現実的である。より良いアプローチは、優先ユースケースに基づいた選択的モダナイゼーションである。
APIファサードパターン
レガシーシステムが変更困難な場合、その前にAPIファサードまたはサービスレイヤーを構築する。これにより：
- 複雑性を単純化
- スキーマを正規化
- エージェントができることを制限
- スクリーンスクレイピングやデータベース直接アクセスを回避
エージェントは決して以下を行うべきではない：
- UIをクリックして操作する
- 基幹テーブルに直接クエリを実行する
- 一部の人間だけが理解している隠れたロジックに依存する
APIファサードはガバナンスも支援する：エージェントは検証され、ポリシーが適用され、完全にログが取られ、必要に応じて停止できるサービスを通じてのみ相互作用する、と決定できる。
リーダーシップへの示唆
エージェントを基幹システムに接続することは、単なるミドルウェアプロジェクトではない。エージェントがERP、CRM、HRISに触れた瞬間、ガバナンスの影響がすぐに表面化する。
各接続にはビジネスオーナーとテクニカルオーナーが必要
Read、Recommend、Actの境界は形式的に定義すべき。各チームが自律性レベルを個別に決めさせてはいけない。
監査証跡はシステム間で一貫している必要がある
エージェントのアクションは、基幹システムのトランザクションログとエージェントの判断ログが紐づけられなければならない。
ワークフォースへの影響を最初から考慮する
エージェントが基幹システムで読み取りと実行を行うようになると、人間の業務はデータ入力やステータス確認から、例外処理、承認、ポリシー改善へとシフトする。
各リーダーが問うべき質問
CIOへ：デジタルコアはエージェント実行プラットフォームとして機能する準備ができているか？それとも、アクセス困難な記録管理システムのままか？
COOへ：どのプロセスにおいて、本当のボトルネックは人ではなく、基幹システムからの業務状態へのアクセス遅延か？
CHROへ：エージェントがHRISで読み取りとワークフロー起動を始めたとき、どのロールが管理から監視・例外管理へとシフトするか？
変革リーダーへ：ロードマップは高価値ユースケースと現実的な統合能力から始まっているか？それとも、印象的なAIデモと触れる準備ができていない基幹システムの間に挟まれていないか？
これらの答えがまだ明確でないなら、次の優先事項はエージェントを増やすことではない。エージェントと基幹システムの間の安全な経路を明確にすることだ。そこからエージェント型エンタープライズは本当に始まる。
参考