サッカー日本代表｜決勝トーナメント1回戦でブラジルに1-2の逆転負け

佐野海舟のゴールで先制したものの、後半に追いつかれ、終了間際に決勝点を許してしまいました。5度目の挑戦でも、W杯決勝トーナメント初勝利には届きませんでした。

悔しい結果です。でも、正直に言わせてください。室長が子供の頃、日本がブラジルを相手に前半リードして折り返すなんて、想像もできませんでした。ブラジルは「サッカーの王国」、こちらは追いかける側というのが当たり前の構図だったのです。それが今、堂々と先制点を奪い、後半まで分からない試合をする。時代は変わったんだな、と素直に感じました。

それでも結果は負け。SNSを見ていると、「あの選手交代が遅かった」「あのポジショニングが甘かった」「あの場面でボールを奪われた」と、個人のプレーを名指しで責める声が溢れています。サッカーというスポーツの性質上、これは仕方のないことかもしれません。一瞬のプレーが結果を分けるスポーツですから。

ただ、室長はこの数日、少し違う角度からこの代表チームを見ていました。今回の森保ジャパンのベンチには、名波浩（攻撃担当）、中村俊輔（攻撃・セットプレー担当）、長谷部誠（攻守の橋渡し役）、前田遼一（攻撃・セットプレー）、斎藤俊秀（守備戦術）、そして”化け物”フィジカルコーチの松本良一氏が揃っています。それぞれが明確に役割分担され、しかも監督自身が「自分のコピーではなく異なる視点を持ったスタッフがほしい」と語るように、互いの領域を越えて意見を出し合う文化がある。さらに、宮本恒靖会長、前々キャプテンの吉田麻也が帯同し、怪我で出場できない南野拓実、そして大会直前にコンディション不良で帰国した前キャプテン遠藤航の思いを背負う現キャプテン板倉滉、超ポジティブな長友佑都という、「個人の出来不出来だけでは勝負しない構造」がそこにあります。

この体制を見ていて、ふと思ったのです。

これは、スポーツの世界に限った話ではありません。むしろ、AI Agentが業務プロセスの中に入り込んでくる今のDynamics 365の世界—CRMとERP、そしてその間を泳ぐAI Agentたちの世界にこそ、強く当てはまる話だと感じています。

本稿では、ブラジル戦の悔しさから始まり、この「個人ではなくプロセスを見る」という思考を、AI Agent時代のCRM×ERPガバナンスに繋げていきたいと思います。最後までお付き合いいただけますと幸いです。

---

森保ジャパンの「体制図」を、プロジェクト視点で読み解く

少し、室長らしい視点でこの体制を分解してみます。これは紛れもなく、よくできた「プロジェクト体制図」です。

森保一監督を頂点に置くと、その下には機能別に分かれたコーチ陣がいます。名波浩コーチと中村俊輔コーチが攻撃領域、斎藤俊秀コーチが守備領域、前田遼一コーチが攻撃とセットプレー、そして長谷部誠コーチは特定の機能を持たず、攻守全般を見ながら選手とコーチの橋渡し役を担う。さらに松本良一フィジカルコーチが、攻撃にも守備にも関係なく、すべての土台となるコンディションを支えます。

これ、IT導入プロジェクトの体制図と全く同じ構造をしています。CRM（攻め）担当のコンサルタント、ERP（守り）担当のコンサルタント、そして両者を繋ぐインテグレーション担当。さらに、プロジェクト全体の進行を管理するPM。どのプロジェクトも、本当はこういう機能分担で組まれているはずです。

そして森保監督が明言しているのが、「自分のコピーではなく異なる視点を持ったスタッフがほしい」という方針です。中村俊輔コーチは「違う角度の意見を出さなければ意味がない」と語り、長谷部コーチは「選手と同じ目線でコミュニケーションを図ることが重要」と強調する。現役時代の上下関係や遠慮をほとんど感じさせない、自由に意見を出し合うカルチャーがあります。

これは、プロジェクトマネジメントにおける「心理的安全性」そのものです。CRM担当が「この要件、ERP側の都合で無理です」と言われた時に黙って引くのではなく、「いや、それでもこの設計の方がLead to Cashが繋がる」と言い返せる関係性。これがないプロジェクトは、だいたい途中でどこかの工程が機能不全を起こします。

ベンチにいる「出場できない当事者」たちの意味

さらに、この体制で見逃せないのが、出場できない選手たちの存在です。怪我で出場できない南野拓実。大会直前にコンディション不良で帰国した前キャプテン遠藤航。そして、彼の思いを受け止めて戦う現キャプテン板倉滉。彼らは試合に出られない、あるいは出られなかった。しかし、その「出られない当事者」が近くにいることが、チームに重みを持たせています。

プロジェクトの世界で言えば、これは「過去の失敗を知る人がチームに残っている」状態に近いものです。同じ轍を踏まないように、過去の苦い経験が体制の中で生きている。これも一種のガバナンス機能です。

---

ここに「AI Agent」を組み込んだら、体制図はどうなるか

さて、ここからが本題です。この体制図に、もし「AI Agent」というメンバーを新たに加えるとしたら、どこに置くべきでしょうか。室長の答えは、こうです。AI Agentは、コーチ陣のどこか一つに所属するのではなく、コーチ陣全体の間を「泳ぐ」存在として置くべきです。

具体的なシーンで考えてみましょう。

営業担当者が、Sales Agentに「この顧客に追加提案をしたい」と相談します。Sales AgentはCRM（Dynamics 365 Sales）側のメンバーですが、提案を作るためには、それだけでは仕事になりません。ERP側に保管されている在庫数量を確認しに行き、与信残高に問題がないかを確認しに行きます。CRMの選手なのに、ERPのピッチにまで足を伸ばして、必要な情報を取りに行っているのです。

逆のケースもあります。ERP側にCollections Agentを構築すれば、ある顧客への支払い催促を進めようとしたとき、その顧客の現在の商談状況や、最近のクレーム履歴をCRM側に確認しに行くはずです。「この顧客、今ちょうど大型商談が進んでいるから、催促のタイミングと言い方は慎重に」という判断材料を、ERPの外から取りに行くわけです。

つまりAI Agentは、名波コーチでも斎藤コーチでもなく、長谷部コーチの立ち位置——攻撃にも守備にも所属しながら、両方のピッチを横断して動く存在に近いのです。

しかし、ここで重要な問いが生まれます。長谷部コーチが攻守を横断できるのは、その役割と権限の範囲が明確に決まっているからです。彼は「選手とコーチの橋渡し役」という機能の中で動いている。もし彼が突然、采配権限まで持ってフォーメーションを変えてしまったら、これは越権行為です。サッカーで言えば、「オフサイドライン」を越えてしまった状態に近い。

AI Agentも同じです。Sales AgentがERPの在庫データを「見に行く」のは良い。しかし、その先で「在庫が足りないから、自動で発注をかけてしまう」「与信に問題があるから、自動で取引を停止してしまう」という判断まで、CRM側のAgentが単独で下してしまっていいのか。これは、サッカーで言えば味方からのパスより先にディフェンスラインを越えて飛び出してしまった状態—オフサイドです。

CRMとERPを横断して動けることが価値である一方、どこまでの判断を自律的に下していいのか、どこからは人間の承認が必要なのか—この境界線を引かなければ、AI Agentは「攻守を横断する便利な存在」ではなく、「誰も制御できない暴走存在」になってしまいます。これが、サッカーの「オフサイドライン」を、AI Agentガバナンスに当てはめた最初の論点です。

---

オフサイドライン｜AI Agentの「どこまで」を決める境界設計

⚑ OFFSIDE LINE

オフサイドというルールを、改めて整理してみます。味方からのパスが出る前に、相手ディフェンスラインより前に出てしまっている選手にボールが渡ると、反則になる。これは「タイミング」と「位置」の両方が問われるルールです。フォワードがどれだけ優秀でも、パスが来る前に飛び出してしまえば、そのプレーは無効になります。

室長は最近、Business CentralのAgent配置を整理したマップをつくりました。モジュール体系（財務会計・販売管理・サービス管理など）の下に、マスタ・CRM（Relationship Management）・伝票・データという4層が並び、その全領域を横断する形で「Agent / Copilotレイヤー」が配置されています。Sales Order Agent、Payables Agent、Expense Agent、Bank Reconciliation Agent、そしてCopilot Studio（MCP）で作るCustom Agent。これらは、まさに長谷部コーチのように、特定の機能（モジュール）に所属しながら、全体を泳ぎ回る存在です。

そして、このAgentレイヤーのさらに下に置かれているのが、「Human-in-the-Loop—承認／監査／例外処理」という層です。図ではこう説明されています。「Agent自律実行 → 人間が最終承認。BCワークフロー・権限と連動」。

これが、まさにオフサイドラインです。Agentがどれだけ広いピッチを自由に動けても、最終承認という一本のラインを越える前には、必ず人間がボールに触れる。Sales Order AgentがCRM側の商談情報を見て受注処理の提案をしても、それを確定させる「パス」は人間から出る。Payables Agentが支払い処理の準備を整えても、最終承認は人間が行う。

オフサイドラインがピッチ上に固定された一本の線ではなく、ディフェンスラインの位置によって常に動く「相対的な線」であるのと同じように、Human-in-the-Loopの境界も、業務やリスクの大きさによって動かすべき「相対的な線」です。室長は以前、この境界設計の考え方についてブログで書きました。

この2つの記事でお伝えしたのは、「AIに任せる／任せない」の二択ではなく、業務プロセスのどの工程に、どんな粒度で承認ポイント（オフサイドライン）を置くかという設計判断そのものが品質を決めるということでした。在庫確認や与信参照のような「情報を取りに行く」行為と、発注や支払確定のような「状態を変える」行為では、明確にラインの引き方が変わってきます。

審判は、このオフサイドラインを常に見ています。選手がラインを越えたかどうかを判定し、必要であればプレーを止める。AI Agentガバナンスにおける審判の役割—それが、次にお話しする「イエローカード」と「VAR」の話になります。

---

イエローカードとVAR｜違反を即レッドカードにしない仕組み

🟨 YELLOW CARD

イエローカード｜AI Agentの違反を、即レッドカードにしない仕組み

サッカーには、即退場（レッドカード）の前段階として、イエローカードという仕組みがあります。ルール違反があった瞬間にすべてを止めるのではなく、警告として記録し、改善を促す。これがあるからこそ、選手は安心してプレーを続けられます。

AI Agentのガバナンスにも、同じ「イエローカード」の仕組みが必要です。

室長は5月のDirections ASIA 2026で、まさにこの仕組みのライブデモを見ました。Business Central MCP Serverに接続したコンプライアンス監査Agent（「Stella’s Compliance Audit Maker」）が、架空のユーザー全員の権限設定を自動チェックし、重要度別の指摘事項と是正提案まで自動生成するというデモです。先ほどのBC Agent配置マップで言えば、マスタ層にある「ユーザーID／ロール／セキュリティ」を、Agentレイヤーが横から監査しに行く、という構図です。

これらは、いずれも「個人が悪意を持って不正をした」という話ではありません。権限設計とプロセス設計の不備です。AIがこれを検出し、「即刻アクセス停止」ではなく「レビューと是正計画」という、ちょうどイエローカードに相当するレベルで対応を提案している点が重要です。

そして、このコンプライアンス監査Agentが機能する土台になっているのが、Business Central MCP Serverに用意された一連の機能群です。Agent提案のレビュー、Agentのタイムライン（行動履歴）、権限とプロファイルの管理、機密性の高いアクションの事前レビュー、そして完全なAgentログ。これらはまさに、サッカーでいう「イエローカードの記録」「VARによる事後検証」に相当する仕組みです。

VAR｜後から検証できることが、信頼の土台になる

📺 VAR

サッカーにおけるVAR（ビデオ判定）の本質は、「その場の一回の判断を絶対にしない」という思想です。誤審の可能性がある場面では、後から映像を見返して検証する。これがあるからこそ、誤審への不満は残っても、判定そのものへの信頼は保たれます。

AI Agentにおける「VAR」は、ログと監査の仕組みそのものです。室長は別の記事で、AI Agentが取引と責任を繋ぐ時代における監査対応の変化について書きました。

これらの記事でお伝えしたのは、AI Agentが下した判断そのものよりも、「なぜその判断をしたのか」を後から追跡できることの方が、実は信頼性の本質に近いということです。サッカーの判定がルールという共通基盤に基づき、後から映像で検証可能であることによって公平性が保たれるのと同じく、AI Agentの判断も、ログという「映像記録」があってこそ、選手（業務担当者）は安心してAIに任せられるのです。

---

攻めと守りの具体的なシーン｜CRMとERPが交わる瞬間

ここまで、サッカーの審判システムをAI Agentガバナンスに当てはめてきました。ここからは、実際の業務でどんなシーンが生まれるのかを、具体的に見ていきます。

攻めと守りが連携するとき、AI Agentは「反則を恐れず」動ける

サッカーで、ディフェンスラインが整っているチームほど、フォワードは思い切って前に出ていけます。後ろが崩れていなければ、多少リスクを取った飛び出しも怖くない。

CRMとERPの関係も同じです。ERP側の与信・在庫・請求データという「守りの基盤」がしっかりしているからこそ、CRM側のAgentは思い切ったタイミングで提案や催促を打てる。逆に、守りの基盤が崩れている状態で攻めのAgentだけを高度化させると、オフサイドの判定（与信オーバーの受注、的外れな催促）が頻発し、AI Agentそのものへの信頼を失います。

「個人を責めるな、プロセスを責めよ」という思考は、ここでも同じ形で現れます。Agentが間違った判断をしたとき、「このAgentの設計が悪い」で終わらせるのではなく、「攻めと守りのどちらの基盤が、どこで崩れていたのか」を見ることです。

---