こんにちは。皆さま、いかがお過ごしでしょうか？

“室長”こと吉島良平（Microsoft MVP for Business Applications|Microsoft Regional Director）です。

東北地方から戻り、本日は東京都・浅草方面から、このブログを書いています。

皆さん、いよいよサッカーワールドカップが開幕しましたね。

試合を観ていると、この舞台に立つことの重みと、そこに至るまでの積み重ねを、改めて強く感じます。

そんな中で、ひとつ胸に残ったニュースがありました。

日本代表の主将としてチームを牽引してきた遠藤航キャプテンが、怪我のためチームを離れ、そのまま代表引退を決断したという話です。

本人も、仲間も、スタッフも、きっと涙なしには受け止められなかったのではないでしょうか。

南野拓実選手・三笘薫選手同様、最後の舞台に立てない悔しさ。

積み上げてきたものを、思い描いた形で終えられない現実。

それでもチームのために判断を下すしかない瞬間。

そりゃ、泣けます。

仲間に別れの挨拶を「しないという選択肢」に至ったのには、理由があるのだろう。

「帰る前に、挨拶くらいしろよ」という方もいるかもしれません。

当事者意識をもてば、そりゃ、零れますって。たまらんですよ。

南野拓実選手のようにチームに帯同するもよし、

三笘薫選手のように離れて見守るもよし、

遠藤航選手のように、黙って去るもいいじゃないですか。

僕はそう思いました。

こういう時こそ、チーム・組織として「纏まる」必要がありますね。

報道を見ていて、強く感じたことがあります。

チームの中でキャプテンが担っているのは、単にプレーすることではなく、

• 状況を読み
• 判断し
• チームを動かし
• 最後の意思決定を引き受ける

そういった、見えにくい役割です。

だからこそ、その存在がいなくなるとき、それは単なる“選手の交代”ではなく、チームの構造そのものが揺らぐ出来事になります。

そしてこの感覚―どこかで見たことがあるように感じたのです。

少し誤解を恐れずに言うと、最近、自分の仕事の中で、自分の役割に、別の存在が入り込んできている、そんな感覚を覚える瞬間が増えてきました。

CopilotをはじめとしたAIを使う中で、「これ、自分がやるより早いな」と思うことは、もう珍しくありません。

しかし、それ以上に気になっているのはその中身です。

• 論点を整理すること
• 状況を把握すること
• 判断の選択肢を出すこと
• 次に取るべきアクションを決めること

そういった“キャプテン的な役割”に、AIが静かに入り込んできているように感じるのです。

これまで自分がやってきた仕事の本質に、少しずつ手が届き始めている。

それは便利でもあり、同時にどこか悔しさを伴う感覚でもあります。

ただ、この違和感をもう少し掘り下げてみると、一つのことに気づきます。

それは、「AIと人が競っている段階そのものが、すでに終わり始めている」ということです。

これまでのAIは、

• 人が問いを投げる
• AIが答える
• 人が判断する

という関係でした。

しかし、いま起きているのは違います。

それぞれの役割を持ったAIが、互いの出力を評価し、補正し、必要な情報を補いながら、次の意思決定を組み立てていく。

そして、そのプロセスは、人を介さず連続して進んでいきます。

つまり、「“キャプテン同士”が会話しているような世界」が、すでに立ち上がり始めています。

ここで、ひとつ問いが生まれます。

もし、チームの状況を読み、判断し、動かす存在が、一人ではなく、複数の“Agent”として存在したとしたら、仕事は、どう変わるのか。

そして、この変化は単なる延長ではない、という見方もあります。

MicrosoftのCEOであるSatya Nadellaは、この流れを「進化」ではなく、「プラットフォームの転換」だとあるイベントで説明していました。

アプリケーションを人が操作する世界から、エージェントが主体となって動く世界へ。

そして企業は、AIを使うだけでなく、自らのデータと知見をもとにAIを育て、独自の価値を作り出していく存在へと変わっていく。

ここまで考えていくと、一つの見え方が出てきます。

仕事そのものがなくなるわけではありません。

提案も、発注も、請求もー

日々の業務そのものが消えるわけではありません。

ただし、その中で“判断している存在”は、確実に変わり始めています。

これまで人が担ってきたのは、

• 情報を集め
• 状況を読み
• 判断し
• 調整し
• チームを動かすこと

でした。

それはまさに、遠藤キャプテンのような存在が担ってきた役割そのものです。

もしその役割を、一人の人間ではなく、複数のAgentが分担し、連携しながら担うようになったとしたら、

チームの構造はどう変わるのか。

仕事の進み方はどう変わるのか。

そして私たちは、どこで意思決定をし、どこに価値を出す存在になるのか。

もしかすると、これからの時代に問われるのは、「何ができるか」ではなく、どの役割を自分が担い、どの役割をAIに委ねるのか、なのかもしれません。

本稿では、この変化を抽象論ではなく、Dynamics 365を前提とした具体的なシナリオとして描いていきます。

• 提案依頼元のRFP Agentと、自社のProposal Agentが対話しながら提案書を仕上げる世界
• Demand AgentとSupplier Agentが、在庫・納期・物流・CO2排出といった条件を踏まえて発注内容を合意する世界
• Sales Invoice AgentとPayable Agentが、支払条件やキャッシュポジションをもとに取引条件を確定する世界
• Support Request AgentとDynamics 365 Contact Center Agent等が連携し、問題検知ら原因特定、暫定対応までを同時に進める世界
• Filing AgentとGovernment Agentが、提出前の段階で差分データをもとに整合性を確認し、報告内容の合意を形成する世界

これらは、それぞれ独立した業務ではありません。

提案から始まり、発注、請求、問題対応、そして社会との整合へと、意思決定そのものがAgent同士の対話として連続的につながっていく構造が見え始めています。

そしてその先にある、「企業と企業、企業と社会が、AI同士の対話でつながっていく世界」

それは、多くの企業にとって未だ現実のものになっていません。

ただし、遠い未来の話でもありません。

少なくとも、その兆しは、すでに見え始めているのですから。

第1章｜提案とプロジェクトは「設計するもの」ではない―RFPからProject Operationsまでが対話する世界―

チームにとってキャプテンが重要なのは、最終的な判断を引き受ける存在だからです。

試合の流れを読み、限られた時間の中で選択肢を整理し、「今、何を優先すべきか」を決める。その意思決定の連続が、チームの結果を左右します。

では、その役割が、ビジネスの現場ではどのように現れているのか。

一つ分かりやすい例が、RFP（Request for Proposal）と提案書のプロセスです。

これまで私たちは、こうしてきました。

お客様からRFPが届く。内容を読み解き、曖昧な部分を整理し、過去の類似案件を引き当てる。

そこから、スコープを定義し、工数を見積もり、必要なライセンスを算出し、価格と利益率を調整し、提案書としてまとめる。

というプロセスを、人が担ってきました。

一見すると「ドキュメント作成」のように見えますが、実際にはそうではありません。その本質は、

• 情報を読み解き
• 判断し
• 選択し
• 条件を調整し
• 合意可能な形に落とし込む

という、極めて“キャプテン的な仕事”です。

では、このプロセスに、複数のAgentが入り込んだらどうなるでしょうか。

RFP Agent（顧客側）
「D365 Financeの導入を前提とした提案を依頼します。対象は5カ国、開始は来年Q1を希望。」

Proposal Agent（自社）
「受領しました。過去の類似プロジェクトを検索します。該当する36件のプロジェクトから、スコープと工数モデルを抽出しました。」

ここで終わりではありません。

Time Analytics Agent
「実績ベースで平均工数は12,400時間。多国展開における遅延リスクを加味すると、+8%が妥当です。」

License Agent
「最新のMicrosoftライセンス体系を参照。ユーザー数とロールから最適構成を生成しました。」

Margin Control Agent
「社内基準粗利率18%を満たしています。承認プロセスはスキップ可能です。」

そして、さらに重要なのはここからです。

RFP Agent（顧客側）
「ローカル要件対応の範囲について確認したい。」

Proposal Agent
「過去案件ベースで回答します。標準テンプレート＋アドオンで対応可能です。必要に応じてPhase2で分離できます。」

RFP Agent
「理解しました。条件を更新します。」

この時点で、人はまだ何もしていません。

しかし、提案はすでに進み、条件は整理され、曖昧さは解消され、合意に向けた形が整い始めています。

そして最後に、

Proposal Agent
「条件反映済みの最終提案書を生成しました。契約ドラフトも同時に作成しています」

ここまで来ると、はっきりと一つのことが分かります。

提案書は“人が一から作るものではなくなりつつある”

それは、

• 過去の経験
• 現在の条件
• 将来のリスク
• 交渉すべき論点

それらを、複数のAgentが対話し、整理し、合意できる形に変換した結果に過ぎません。

これまで人がやっていたことは、PowerPointを開くことでも、Excelを作ることでもなく、「何が最適かを判断し続けること」でした。

そして今、その役割が、少しずつ分解され、外に出ていこうとしています。

提案が成立したあと、もう一つ重要なプロセスがあります。

それは、プロジェクトをどう組み立てるかです。

これまでのプロジェクト設計は、

スキルを持つ人を探し、稼働を確認し、コストと納期を調整し、チームを編成する。

という流れでした。

しかし、Dynamics 365 Project Operationsの世界で、Agentが入るとこうなります。

Project Design Agent
「このプロジェクトはD365 Finance、SCM、5カ国展開が要件です。必要スキルとリソース構成を生成します。」

Resource Agent
「利用可能なリソースを分析。最適構成を提示します。」

Profitability Agent
「収益性を評価。提案時点の粗利率を維持可能です。」

プロジェクトは「組むもの」ではなく、最適化された結果として“構成されるもの”に変わります

では、このように提案やその後のプロジェクトが、Agent同士の対話の中で形になっていくとき、実際の業務は、どのように動き始めるのでしょうか。

キャプテンが戦術を決めたあと、次に必要なのは実行です。

その実行が、自社の中だけではなく、企業と企業の間でどのように連携されていくのか。

第2章では、発注と受注という“企業間の意思決定”において、Agent同士がどのように会話するのかを見ていきます。

第2章｜発注と現場対応は「指示するもの」ではない―ERP（FO/BC)とCRM（Field Service）が対話する世界―

キャプテンの役割は、チームの中で完結するものではありません。

試合の中では相手チームが存在し、その戦術やコンディションを読みながら、自分たちの動きを調整していく必要があります。

つまり、本当の意味での“判断”とは、自分のチームの中だけでなく、相手との関係性の中で行うものです。

この構造は、ビジネスにおいてもまったく同じです。

特に、ERPやSCMの世界では、企業の外部とのやり取りこそが業務の中心になります。

• Dynamics 365 Finance and SCM (＝ Dynamics 365 FO)
• Dynamics 365 Business Central (= Dynamics 365 BC)

といったERP領域では、在庫、購買、発注、物流といったプロセスが、常に複数企業をまたいで動いています。

その代表的な例が、発注と受注の関係です。

これまでの発注プロセスはこうでした。

ERP（例えばDynamics 365 FOやBC）上で

• 需要を予測し
• 在庫を確認し
• 不足を洗い出し
• サプライヤーに発注または見積依頼を行う

そして相手から返ってきた条件を、

• 納期
• 価格
• 品質
• リスク

といった観点で、人が判断していました。

ここでもやっていることの本質は変わりません。

• 情報を読み
• 選択肢を比較し
• 判断し
• 合意する

という“キャプテン的な仕事”です。

しかし、Dynamics 365の世界にAgentというレイヤーが加わると、状況は変わります。

Demand Agent（Dynamics 365 FO / BC 上）
「販売予測を更新。部品Aが来月320個不足します。ERP上の在庫と安全在庫を考慮し、最適な調達条件を確認します。」

Supplier Agent（サプライヤー側ERP）
「現在280個は即納可能。残り40個は通常5日後。ただし別拠点からの振替で3日短縮可能です。」

ここにさらに、

Logistics Agent（SCM領域）
「標準ルートは港湾混雑の影響あり。代替ルートであれば納期遵守率97%です。」

Sustainability Agent
「代替ルートの方がCO2排出係数も低下します。」

そしてそれらを踏まえて、

Demand Agent（Dynamics 365側）
「では、280個は即納。残り40個は代替ルートで供給。CO2排出最小化条件で発注を確定します。」

ここで重要なのは、この判断が“単独のシステム”で完結していないという点です。

Dynamics 365（FO/BC）は、

• 需要情報
• 在庫情報
• 購買条件
• 契約条件

といった“自社の事実”を保持する基盤です。

一方で、サプライヤー側のERPや外部システムが、“供給可能性”の事実を持っています。

そしてその両者をつなぐのが、Agent同士の対話レイヤーです。

ここで起きているのは、単なるEDIやAPI連携ではありません。

企業と企業のあいだで、意思決定そのものがリアルタイムで協調されていく世界が見え始めています。

企業間のやり取りが進むと、最終的には“現場”での対応が必要になります。

例えばフィールドサービスです。

Service Request Agent（顧客）
「設備障害を検知。対応を依頼します。」

Field Service Agent（Dynamics 365 Field Service/CRM側）
「最適なエンジニアを割当。移動時間、スキル、部品在庫を考慮。」

Parts Agent（FO/BC）
「必要部品は最寄倉庫に在庫あり。」

Field Service Agent
「2時間以内の訪問を確定。」

従来のERPは、
「正しいデータを持つこと」
「正しいプロセスを回すこと」
が中心でした。

しかしこれからのDynamics 365 ERPは違います。

System of Record（記録）から、
System of Decision（意思決定）へ

進化していきます。

そしてこのとき重要になるのは、コストでも納期でもなく、「どれだけスムーズに“相手のAgentと会話できるか”」という能力です。

発注という行為は、“依頼する作業”ではなく、需要と供給が、その場で最適な形に合意するプロセスへと変わり始めています。

では、このように企業間のやり取りがリアルタイムに最適化されるとき、お金の流れはどう変わるのでしょうか。

第3章｜請求は「送るもの」ではない―Dynamics 365 ERPが支える、取引条件がその場で合意される世界―

キャプテン同士が会話しながら意思決定を行う世界では、当然、その結果は“数字”として現れます。

試合で言えば、スコアです。

そしてビジネスにおいて、そのスコアにあたるものが、お金の流れです。

発注と受注が決まり、モノが動き、サービスが提供される。

その結果として、請求と支払いが発生します。

これまでのプロセスは、シンプルでした。

Dynamics 365 FOやBCといったERPの中で、

• 請求書を発行する
• 顧客に送付する
• 入金を待つ
• 消込を行う

という、比較的直線的な流れです。

しかし、このプロセスもまた、その内側では“判断”に満ちています。

• いつ請求するのか
• 支払条件はどうするのか
• 値引きや割引は許容するのか
• キャッシュフローへの影響はどうか

つまりここでも、キャプテンが状況を読みながら判断しているという構造が存在しています。

では、この領域にAgentが入り込むとどうなるのか。

Sales Invoice Agent（Dynamics 365 FO/BC）
「納品完了を確認しました。契約条件に基づき、請求金額は12,450,000円です。標準条件は30日サイトですが、今週内支払いの場合、2.2%の早期割引を適用可能です。」

Payable Agent（顧客側ERP）
「受領しました。PO・納品・契約条件の整合を確認済みです。現在のキャッシュポジションを考慮すると、17日以内の支払いが最適です。割引条件を適用し、支払いを確定します。」

ここで終わりではありません。

Treasury/Bank Agent（Dynamics 365 FO/BC）
「該当支払いは資金計画に反映済みです。当日の資金移動は自動実行可能です。」

この一連の流れで、人は関与していません。

しかし実際には、

• 契約条件
• 請求金額
• 支払タイミング
• 割引
• キャッシュフロー

といった複数の要素が同時に評価され、最適な意思決定が行われています。

ここで起きているのは、単なる自動化ではありません。

“お金に関する条件そのものが交渉されていく流れが見え始めている”

という変化です。

従来の請求は、「条件を固定して提示する」ものでした。

しかしこれからは違います。

条件は固定ではなく、

• 支払い能力
• キャッシュフロー
• 信用
• 関係性

といった要素を踏まえながら、

“その場で最適な条件が合意されていく”

プロセスになります。（特に海外では、動きがはやそう。）

つまりここでは、一方的に請求が送られるのではなく、

売り手と買い手の“キャプテン同士”が、リアルタイムにお金に関する条件をすり合わせている状態です。

そしてここで重要なのは、Dynamics 365 ERP（FO/BC）の役割が変わり始めているという点です。

これまでのERPは、

取引を記録する
財務情報を管理する

いわば、System of Record（記録のシステム）でした。

しかし、Agentが入ることで、

条件を評価し、意思決定を支援し、最適なアクションを実行する。

System of Decision（意思決定のシステム）へと進化し始めています。

そしてこのとき、企業にとって重要になるのは、単に正しく記録できることではなく、どれだけ賢く“お金の交渉ができるか”

という能力です。

では、このように

• 提案
• 発注
• 請求

がすべてAgent同士の対話で進んでいくとき、現場で起きる“問題”はどう変わるのでしょうか。

ここまで来ると、提案も、発注も、請求も、すべてが“対話”として行われていることが見えてきます。

キャプテンは、プレーを決めるだけでなく、その価値をどう成立させるかまで関与する存在です。

では、その流れの中で、避けては通れない「例外」はどうなるのでしょうか。

第4章では、障害対応や問い合わせといった“現場の問題”に対して、Agentがどのように向き合うのかを見ていきます。

第4章｜顧客対応は「受けるもの」ではない―Dynamics 365 Customer ServiceとMarketingが対話する世界―

ここまで見てきたように、

• 提案
• 発注
• 請求

といったプロセスが、Agent同士の対話によって進むようになってくると、ひとつの疑問が自然に湧いてきます。

では、問題が起きたときはどうなるのか。

どれだけ高度なシステムであっても、現場には必ず“例外”が存在します。

• 想定外のデータ
• オペレーションのずれ
• システム間の不整合
• 顧客からの問い合わせ

そしてこれまで、そのすべてを人が受け止めてきました。

特に、Dynamics 365 Customer ServiceやContact Centerの領域では、

• 顧客からの問い合わせ
• インシデント対応
• サポートチケット
• コンタクトセンターオペレーション

といった“現場の対応”が、価値の中心にありました。

従来の流れは、こうです。

顧客が問題を認識する
→ コンタクトセンターに問い合わせる
→ オペレーターが内容をヒアリングする
→ チケットを起票する
→ 技術チームにエスカレーションする
→ 調査・分析を行う
→ 対応方法を決定する

この一連の流れの中で人がやっていることは明確です。

• 状況を把握する
• 顧客の意図を理解する
• 影響範囲を見極める
• 原因を仮説立てする
• 解決までの道筋を決める

つまりここでも、キャプテンが試合中に状況を見て判断している構造があります。

では、この領域にAgentが入り込んだらどうなるのか。

Support Request Agent（顧客側）
「インシデントを検知。請求処理でエラーが発生。影響ユーザー数は27名。業務停止リスクあり。」

Dynamics 365 Contact Center Agent（自社）
「問い合わせ内容を受領。顧客情報、契約条件、過去の問い合わせ履歴を参照します。」

ここで重要なのは、“ヒアリング”という工程が存在しないことです。すでに必要なコンテキストは揃っています。

Case Intelligence Agent（Customer Service）
「類似ケースを3件検出。原因候補はカスタムワークフローとの競合です。」

Telemetry Agent（SCM / Finance連携）
「本番環境ログを分析。想定通り、競合状態を確認します。」

ここから一気に流れが変わります。

Resolution Agent
「暫定対処案を提示。該当ワークフローを一時停止すれば処理再開可能です。」

Customer Policy Agent
「業務影響とリスクを評価。暫定対応の適用を許可します。」

Contact Center Agent
「対応を適用。顧客へ自動通知。処理は正常化しました」

そして、その裏側では、

Root Cause Agent
「恒久対策を生成。次回リリースで修正を推奨します。」

Release Planning Agent
「修正内容をバックログ登録。次スプリントに組み込みます。」

ここまでの流れで、人はほとんど関与していません。

しかし実際には、

• 顧客理解
• 状況把握
• 原因特定
• 暫定対応
• 恒久対策

すべてのプロセスが、同時に進行しています。

現場対応ですら、リアルタイムの意思決定として自動的に最適化されていきます。

ここで起きている変化は、単なる効率化ではありません。

問題の捉え方そのものが変わり始めているのです。

これは対応の速度ではなく、構造の変化です。

“問題が起きてから対応する世界”から、“問題に対して即座に構造的に応答する世界”への転換です。

従来のサポートは、「問題が起きたあとに、順番に処理していく」プロセスでした。

しかしこれからは、問題が検知された瞬間に、解決までの流れが同時に走り始めるプロセスへと変わり始めています。

ここでもやはり、キャプテンの役割が変わり始めています。

問題が起きたあとに判断する存在ではなく、問題が起きた瞬間に、複数の判断を同時に動かせる構造を設計する存在へと変わっていく。

そしてもう一つ重要なのは、この段階になると、「問題対応」という言葉そのものが変わっていくという点です。

問題は、発生 → 検知 → 対応ではなく、

学習 → 予測 → 事前回避へとシフトしていきます。

では、このように

• 提案
• 発注
• 請求
• サポート

がすべてAgent同士の対話によって完結する世界において、企業はどのように“社会”とつながっていくのでしょうか。

ここまで来ると、問題は「発生してから対応するもの」ではなく、その瞬間に構造的に解決されていく方向へと変わり始めています。

キャプテンの役割もまた、トラブルに対応する存在から、どのように解決を動かすかを設計する存在へと変わっていきます。

そしてこの構造は、企業の中や顧客との関係だけにとどまりません。

意思決定そのものが社会と接続されたとき、企業の振る舞いはどのように変わるのでしょうか。

次章では、政府、税務、制度といった“社会そのもの”と、Agent同士がどのように連携していくのかを見ていきます。

第5章｜企業は「組織」ではなくなる―Dynamics 365が支える、社会・制度・人材の世界―

ここまで見てきた変化は、

• 社内の意思決定
• 企業間の調整
• お金の交渉
• 現場の問題解決

すべてに共通するものでした。

つまり、キャプテンが判断していた領域が、Agent同士の対話によって分解され始めているということです。

ただし、企業の活動はここで終わりではありません。

企業は常に、

• 政府
• 税務当局
• 規制機関
• 補助金制度

といった、「社会のルール」の中で動いています。

そしてこの領域こそ、最も“人が頑張っている”領域の一つです。

例えば、

• 四半期報告
• 税務申告
• 補助金申請
• ESGレポート

これらはすべて、データを収集し、整合性を確認し、解釈を調整し、書類として提出する。

というプロセスで成り立っています。

ここでもやっていることの本質は同じです。

• 情報を整理し
• 条件を満たしているか判断し
• 相手に誤解なく伝え
• 合意できる形にする

つまり、ここにも“キャプテン的な役割”が存在しているということです。

では、この領域に、Agentが入り込んだらどうなるのでしょうか。

Filing Agent（自社）
「四半期報告データを生成。売上、輸出入、雇用、環境データを統合しました。提出前に整合性の確認を行います。」

Government Agent（規制側）
「データ受領。前回提出との差分に不自然な増減を検知しました。追加説明を推奨します。」

Filing Agent
「拠点追加および販売チャネル変更によるものです。証跡データを添付します。」

Government Agent
「整合性を確認。本提出時は同内容で問題ありません。」

ここで起きている変化は明確です。

提出前に、すでに“合意が形成されていくプロセス”が見え始めています。

従来のプロセスは、
提出する
→ 審査される
→ 指摘される
→ 修正する
という“後追い”の構造でした。

しかしこれからは、

「提出の前に対話が完結していくようなプロセス」へと変わります。

税務の領域でも同じです。

Tax Agent（自社）
「越境取引における税区分を確認します。」

Tax Authority Agent
「2件、軽減税率の適用に追加説明が必要です。」

Tax Agent
「契約条件と輸送証跡を添付します。」

Tax Authority Agent
「適用条件を満たしています。処理を確定してください。」

ここでは、

• 解釈のズレ
• 判定の曖昧さ
• 後からの指摘

といった“税務の不確実性”が、リアルタイムで解消されていきます。

さらにこの構造は、補助金やESGにも広がります。

Sustainability Agent（自社）
「製品のCO2排出原単位を更新します。」

Supplier ESG Agent
「原材料の排出係数を更新済みです。」

Logistics Agent
「輸送ルート変更により排出量が5%低減可能です。」

Customer Procurement Agent
「低排出製品として調達優先度を引き上げます。」

ここでは、単なる「報告」が、企業間の交渉要素そのものに変わっています。

そしてもう一つ重要なのが、
“人”の領域です。

Workforce Agent
「今後6か月のプロジェクトからスキル需要を予測します。」

HR Agent
「不足スキルを特定。採用および育成計画を生成します。」

Learning Agent
「個人ごとの育成プランを最適化します。」

組織ですら、固定された構造ではなく、「需要に応じて動的に最適化される存在」へと変わっていきます。

ここまで来ると、ひとつの見え方が出てきます。

従来の企業活動は、「制度に合わせて人が対応するもの」でした。

しかしこれからは、「Agent同士が制度と整合しながら対話していくもの」へと変わり始めています。

そしてそのとき、キャプテンの役割はさらに変わります。

制度を“理解して対応する存在”ではなく、どの意思決定を、どこまで社会と共有し、どこまで自律的に委ねるのかを設計する存在へと進化していきます。

ここまで見てきたように、

• 社内
• 企業間
• 顧客接点
• 社会

すべてがAgent同士の対話でつながり始めています。

キャプテンは、もはや一つのチームの中で判断する存在ではなく、「社会全体の中で、意思決定の流れを設計する存在」へと変わりつつあります。

ではこのとき、企業の競争力はどこで決まるのでしょうか。

最終章では、ここまでの変化を踏まえ、「人は何をするのか」という問いに向き合います。

最終章｜キャプテンの役割はどこへ行くのか―人は“意思決定をする存在”であり続けるのか―

ここまで見てきたように、

• 提案
• 発注
• 請求
• 顧客対応
• 社会との接続

すべての領域で、意思決定そのものが、Agent同士の対話として行われていく未来が見え始めています。

それは単なる効率化ではありません。業務のスピードが上がる、といった話でもありません。

「誰が判断しているのか」という前提そのものが、変わり始めているのです。

これまで企業の中で行われてきた意思決定は、必ずどこかに“キャプテン”がいました。

• 提案をまとめる人
• 発注を決める人
• 価格や条件を調整する人
• 顧客対応の最終判断をする人
• 社会や制度と向き合う人

それぞれの場面で、最終的に判断を引き受ける存在がいたからこそ、組織としての整合性が保たれてきました。

しかし今、その役割は変わり始めています。

意思決定は、一人の中で完結するものではなく、

「複数のAgentが連携しながら、その場で最適化され続けるプロセス」へと変わりつつあります。

Dynamics 365に代表されるERPやCRMのプラットフォームも、

記録する仕組み（System of Record）から
判断を支える仕組み（System of Decision）へ

と進化してきました。

そしてその上で、
Agentというレイヤーが加わることで、

判断そのものが、分散し、つながり、流れ始めている

これが、今起きている変化です。

では、このとき―人の役割はどこへ行くのでしょうか。

キャプテンは、いなくなるのでしょうか。

おそらく、答えは「NO」です。

ただし、その意味は大きく変わります。

これまでのキャプテンは、

• 判断する人
• 決める人
• 最終責任を持つ人

でした。

しかしこれからは、

「どの判断を、どこまでAIに委ねるのかを決める人」へと変わっていきます。

あるいは、

複数の意思決定が正しく流れるように、

「その“構造”を設計する人」と言い換えることもできます。

AIが判断すると言っても、それは無限に自由に動くわけではありません。

• どのデータを使うのか
• どの範囲まで許容するのか
• どの判断をエスカレーションするのか

そのすべてを決めているのは、依然として「人」です。

つまり、

意思決定そのものではなく、意思決定の流れを設計すること

これが、次の時代におけるキャプテンの役割なのかもしれません。

ここで、最初の問いに戻ります。

キャプテンは、一人である必要があるのか。

もし意思決定が、一人の中ではなく、複数のAgentの対話の中で行われるとしたら、

キャプテンは、「一人の“役割”ではなく、組織の中に分散された“仕組み”」になるのかもしれません。

そしてそのとき、企業の競争力はどこで決まるのか。

それは、どれだけ優秀な人材がいるかではなく、

「どれだけ優れた意思決定の構造を持っているか」に移っていきます。

どのAgentが存在し、どのデータとつながり、どのように判断し、どこで人が介在するのか。

その設計そのものが、企業の価値になります。

遠藤キャプテンのように、判断し、チームを動かし、最後の責任を引き受けてきた存在がいたからこそ、チームは成り立ってきました。

これからも、その役割は必要です。

ただしそれは、「一人が背負うものから、構造として実装されるもの」へ、変わっていくのかもしれません。

そのとき、私たちは何をするのか。

「どこで判断し、どこに責任を持ち、どこに価値を出す存在になるのか」

その問いに向き合うことが、これからの仕事の出発点になるはずです。

終章｜室長からひと言

ここまでお読みいただき、ありがとうございました。

今回書いてきた内容は、すぐにすべてが現実になる話ではありません。

ただ少なくとも、その方向に向かっていること、そしてその前提が揃い始めていることは、日々の仕事の中でも感じるようになってきました。

AIが進化すると、「人はいらなくなるのか」という話になりがちですが、実際に起きている変化は、少し違うのではないかと思っています。

これまで自分たちが“当たり前”だと思っていた役割が、少しずつ外に出ていく。

そして代わりに、「それをどう組み合わせるか」という仕事が増えていく。

どちらかがなくなるのではなく、役割そのものが入れ替わりながら、再定義されていく感覚です。

遠藤キャプテンの話に戻ると、あのように、状況を読み、判断し、最後の責任を引き受ける存在は、これからも間違いなく必要です。

ただし、それは―一人の中に閉じるのではなく、チームや仕組みの中に広がっていくものになるのかもしれません。

だからこそ今、自分は「どこで判断し」「どこに責任を持ち」「どこに価値を出すのか」

その問いだけは、人にしか持てないものとして、最後まで残り続けるのではないかと思います。

そして最後に。

これは少しだけ、今回の話にも重なるのですが、ピッチの上では、一人のキャプテンだけで試合が決まるわけではなく、

味方との連携、相手との関係、状況の変化の中で、常に意思決定が重なり続けています。

その中で、どの一瞬に自分が関わり、どの判断を自分が引き受けるのか。

それが、チームとしての強さを決めているのだと思います。

日本代表の皆さんへ。

結果だけではなく、その一つひとつの判断と選択の積み重ねが、確実にチームの力になっているはずです。

「どこで判断し」「どこに責任を持ち」「どこに価値を出すのか」

どうか最後まで、自分たちらしいサッカーを。

そして、その姿はきっと、私たちがこれから迎える変化の中で、「時代に見合った働き方」を考えるヒントになるはずです。

今回の記事が、少しでもそのきっかけになれば嬉しいです。

以上、室長でした。