こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director) です。

皆さん、いかがお過ごしでしょうか？　僕は今ベトナムのホーチミンにいます。気づくと、5月も半ばですね。

この時期は過ごしやすい気候で、とても好きなのですが、日本では地震があったりと、なんだか落ち着かない感じがしますね。

まぁ、何が起きてもいいように、準備だけはしておきましょうかね。備えあれば患いなしってことで。

さて、本稿では、2026年5月13日〜15日にベトナム・ホーチミンで開催されたDirections ASIA2026（アジアにおけるマイクロソフトのパートナー会）についてメモを残しておきたいと思います。

サマリーだけを時間をかけずに理解したい方は、👉こちら👈に情報を纏めておきました。

現場の雰囲気や実際のスライドをご覧になりたい方は、本編をご利用ください。

まず、このDirections ASIAは、👆の写真に写っているChristian・Torben・Frank・Daya（当時のDirections EMEAのコミッティーメンバー）がいなければ、そもそも始まっていなかったイベントです。

個人的には感謝に堪えません。冒頭、これだけは書いておきたくて。

Directions ASIA 2026から見えた「Agentic時代」の始まり

― Day 1：AIは業務を“支援するもの”ではなく、“実行するもの”へ

1.幕開け｜「今回の前提」を置く

Day1の最初にステージに立ったのは、Directions for Partnersを率いるTorben Kragelundです。スクリーンに映し出されたのは「AI is disrupting business at its core」この1行で、3日間のトーンが決まりました。

そして続けて、3日間のタイムテーブルが共有されます。Day1は9:00にKeynote、11:15からセッション、昼食を挟んで午後もセッションが続き、17:45からはExpo（ドリンクと軽食付き）。Day2は同じ流れの先にクルーズとCommunity Dinner Cruiseがあり、Day3はコーヒーとフェアウェルで閉じる。スケジュールとしては整っていますが、ここで重要なのは「Day1は最初に“前提”を叩き込む日として設計されている」という点です。

（※この段階ではまだ“イベント紹介”ですが、次のMike Morton登壇から空気が変わります。）

2.Mike Morton（肩書：Vice President, Dynamics 365 Business Central）の登場

まず「ここまで来た」を示し、次に「ここから変わる」を言い切る。

会場が満員の中、基調講演として登壇したのが、Dynamics 365 Business Centralの責任者であるMike Mortonです。

2-1.製品の歴史：

「進化の説明」ではなく「転換の前振り」

Mike Mortonはまず「Microsoft Dynamics 365 Business Central through the years」というスライドで、NAVから2026 Release Wave 1までの系譜を一直線に並べます。ここで言いたいのは、“昔からこう変わってきました”ではなく、「土台はできた。だから次の議論に入る」ということです。

2-2.グローバル展開：

242カ国・地域＝「もう世界に置かれている」次に提示されたのが「Business Central globally available!」というメッセージと、242カ国・地域という数字です。
この数字が効いてくるのは、後半です。なぜなら、世界に広がったERPが“Agentic”になると言われた瞬間に、影響範囲が一気に現実のものになるからです。

2-3.SMBのAI活用：

78％と39％が突きつける「使ってるのに変わってない」

ここで会場に刺さったのが「SMB Adoption is High But Transformation Lags」のスライドです。

AIをビジネス機能で活用している中小企業：78％
測定可能な成果を報告している中小企業：39％

この2つの数字が示すのは、AIの普及ではありません。

“変革の未達”です。使っているのに、成果が出ていない。ここがスタート地点だ、という宣言に近い問いかけでした。

3.「ERPの定義」を書き換える

People as Middleware→People as Agent Bosses

Day1の核はここだったと思います。Mike Mortonが放った一文が、会場の空気を変えました。

「ERP records what happened. People bridge the gaps.」

“ERPは過去を記録する。ギャップを埋めるのは人間だ”。

これが今までの現実（Today’s Reality）として提示され、構造としては「People as Middleware」と整理されます。

上がProductivity＆Office Apps、下がERPやCRMで、その間を人がつないでいる。

そして次に提示されたのが、Frontier Realityです。ここで人はMiddlewareではなく、Agent Bossesになります。

上にUX（M365 and Copilot）、中にAgentic Foundation（Copilot Studio / Dynamics 365 Agentsなど）、

下にHeadless Foundation（Dataverse / Fabric / Azure、MCPで有効化）。

つまり、アプリの中で人が頑張る世界ではなく、『エージェントが動く土台の上で、人が統括する世界に移る』、という宣言です。

ここで決定的なフレーズが重ねられます。

「Agents don’t just automate. They synthesize.」「Agentic ERP drives what happens next.」

“自動化ではなく合成”。そして“次を動かすERP”

ここまで言い切って初めて、Day1のテーマ「AIがビジネスの根幹を破壊する」が、比喩ではなく設計思想として立ち上がります。

この流れの中で、一度だけ映像が挟まれました。スクリーンには、「Infinity Group」のロゴとともに、外部の事例を紹介する短いビデオが流れました。詳細な説明が行われたわけではないのですが、ここでの意図は明確でした。ここまで語られてきた「Agentic」という概念が、すでにパートナーや顧客の現場に入り始めていることを、具体的な形で示すためのパートで。つまりこれは、理論ではなく、すでに現実の中で起き始めている変化であるという補強だったと感じました。

4.ライブポーリング｜答えは全員同じ「Not enough」

続いてMike Mortonが会場を巻き込むのが、AI adoptionのライブポーリングです。

問いは「How far along is your organization on AI adoption?」

5段階で投票させた上で、画面に出たのは「The correct answer is… Not enough.」

さらに「No matter what you picked — the answer is the same for everyone. The pace of change demands more from all of us.」と畳みかけます。

どの選択肢を選んだとしても、結論は同じで、「まだ足りていない」という評価に収束する。この時点で、会場全体が同じ前提に立たされる。

そこから間を置かずに、「Become an AI-first company」というメッセージが重ねられる。これは提案ではなく、前提条件として提示されている。Day1の中で語られてきた内容を踏まえると、ここで言われているのは「やるべきかどうか」ではなく、「やらなければ立てない」という位置づけに近い。

さらに続くスライドでは、「To ask your customers to embrace AI, you must embrace it first」といった形で、パートナー側の行動が明確に要求される。顧客に変革を求めるのであれば、自らが先に変わる必要があるという構造がここで言語化される。

そしてその直後に、CopilotやAgentを前提としたデモや画面に切り替わっていく。M365 Copilot CoWorkの画面や、実際の業務にエージェントが入り込んでいる様子が提示されることで、ここまでの話が単なるメッセージではなく、「すでに動き始めている現実」であることが示される。

つまりこの一連の流れは、まず「現状は足りていない」と全員を同じ位置に揃え、次に「AI-firstになること」を前提として突きつけ、その上で「それが実際にどう動くのか」を具体的に見せるという構造になっている。Day1の中でも、この部分が最も“言葉ではなく行動を要求するパート”になっていた。

5.Copilot

SCANとMATCHで「人の仕事の形」をそのまま再現する。ここからは“概念”ではなく、“見える形”に落とし込んでいきました。Mike Mortonが見せたのは、住宅売却後の税務申告に必要な資料をまとめるCopilotのデモシナリオです。プロンプトは、メールと領収書、PDFや画像が散らばっている状況で「助けて」と頼む内容でした。

そして仕事は2つのプログラムで実行されます。

Program1：SCAN（Organize）＝PDF、画像、手書き領収書を読み取り、理解し、カテゴリ別に整理
Program2：MATCH（Identify）＝メールの購入確認と突合し、デポジットと残金をマッチし、単一プロジェクトの支払いを束ね、IRS引用付きで資本改善項目を判定

結果として生成されたのが「Capital Improvements Report」

総額$82,086.55、28件、期間は2013〜2025年の改善項目が自動でまとまる。

ここで重要なのは“便利”ではなく、人が普段やっている「集める→整理する→突合する→判断する」の流れを、そのまま機械側に移した点です。

そしてその直後、ステージの内容は一気に具体へと切り替わる。

ここでは、Business Centralの開発におけるテストデータ生成が、AIによってどのように変わるのかが示されました。

Agents→Agent Connectivity→Tools/Benchmarking＆Evaluation→The Hiveの4段階

このデモは、先ほど提示されたAI Assisted Developmentのロードマップとも明確に対応している。AgentsやAgent Connectivityが前提として成立した上で、ここで示されているのは、ToolsおよびBenchmarking・Evaluationのフェーズである。つまり、単にエージェントが動くという段階ではなく、そのエージェントやシステムをどのように開発し、検証し、現実の業務に耐える形に仕上げていくのかという工程そのものが、AIによって実行されていることを意味している。実際にこのスライドでは、プロンプトによってリアルな業務データを生成し、そのデータをもとにシナリオを組み立てていく様子が示されており、これはまさに開発とテストの領域がAIによって再構成されていることの具体例となっている。

提示されているのは、「Krazy Karting」という架空の企業を前提としたシナリオであり、ゴーカート、アーケード、フード、イベントといった複数の業態を持つ企業の業務データを生成するようにプロンプトが与えられています。ここで重要なのは、単純なダミーデータではなく、実際の業務に近い形で、取引データ、固定資産、ジョブ、サービス管理、銀行・照合といった複雑なデータが含まれている点です。

さらに、このデータには季節性やマルチユーザーの挙動、さらには意図的なデータ品質の問題までが含まれるよう設計されています。これはテストのためのデータでありながら、実運用に近い“現実のノイズ”まで再現しようとしていることを意味しています。

ここで示されているポイントは明確である。これまで開発者が手作業で用意していたテストデータの設計や生成が、AIへのプロンプトによって一度に実行されるようになっているという点である。つまりこのデモは、単に「開発を支援する」ものではなく、開発プロセスそのものがAIによって置き換わり始めていることを示しています。

続いて、パートナーの各ロールでＡＩがどう働き方を変えているかが、具体的な人物を通じて紹介されました。

パートナー各ロールの事例：Jacob WintherとChristina Buhelt

「Business Central Partners — Consultants. Developers. Sales. Support. Business development.」として、AIが仕事をどう変えたかが紹介されます。

Christina Buhelt（Product Management）は、顧客フィードバック、使用シグナル、技術制約を要求仕様に統合し、実行前に整合を取りました。

Jacob Winther（Designer）は忠実にUIモックを素早く作り、探索を加速しました。

BCの導入パートナーのコンサルタント、開発者、営業、保守サポート、ビジネス開発の皆さまもAIで働き方が変わっていくと説明。

境界が変わっていることを示す「Even Group Product Managers…」のスライドにも繋がります。

6.思想を製品の現実へ落とす

ここでステージはJannik Bausager（肩書：Principal Group Program Manager）へ移る。

Day1の面白さは、ここから先が“機能紹介”では終わらない点です。Mike氏の世界観を、製品として現実に落としていく流れになっています。

受注処理を行うSales Order Agentと、請求・支払領域を扱うPayables Agentである。これらのエージェントが、Business Centralのデータをもとに業務を処理し、その結果を画面に返す流れに関する説明がありました。

デモは、「AIが操作を支援する」という段階ではなく、受注や請求といった日常業務が、エージェントによって処理される姿そのものです。ここまでの流れで語られてきた「Agentic ERP」が、概念ではなく実際の業務として動いていることを示すパートになっていた。

Sales Order AgentとPayables AgentのGA（全世界で一般提供）：

ここで明確に発表されたのが、Sales order agentとPayables agentのGAです。

「Business Centralが提供されているすべての国・地域でGA」

顧客の声として引用されたのが、Naomi Fowler（Head of Finance）のコメントです。

毎月数百件の請求書処理における手作業が大幅に削減され、運用の学習、コーディング構造の認識、高ボリューム処理の高速化、

継続的なレイアウト設定不要、といった効果が述べられました。

Payables Agentに関するデモンストレーション

ベトナム語も大丈夫だよと補足

7.Expense Agent

Day1のクライマックスは、Expense Agentです。Monica Ahuja（Principal Software Engineer, Dynamics 365 Business Central）がその場でデモをする演出自体が、“構想ではなく現実”というメッセージを参加者に与えていました。

7-1.正式発表：

スライドは「Introducing Expense Agent — Available in Public Preview」

すでに2026年5月8日からBC29.0（2026 Release Wave 1）でPublic Previewが始まっており、会場のパートナーはその場で試せる状態、と説明がありました。

7-2.従来のBCエージェントと違うExpense Agentの設計思想：

対象ユーザー：ERPを日常的に使わない人（フィールドワーカー、ドライバー、技術者、出張者、一般スタッフ）
アクセス：専用Web、Outlook、Microsoft 365 Copilot Chat（coming next）、Business Central
ライセンス：経費提出のみならBCライセンス不要、Copilot Creditsで従量課金　*室長補足/Entra IDが必要
設計思想：AI-firstでゼロから新規構築（BCにネイティブ経費管理がなかった）
自律性：Autonomy is configurable（設定可能）
初期提供：英語・米国のみ、追加は2026年7月から順次

7-3.デモ（Outlook→Business Central→設定）：

ステップ1はOutlookの受信トレイ

「Hi Jannik, Your expense report has been processed.」という通知メールが届き、本文には出張期間（5月）と、DRIVE（Leander Ventures ApS）のDKK476.00、Asia Hotels Groupの£18,964.00が記載されていました。

ステップ2はBusiness Central

「Good morning, Jannik. You have 1 report ready to submit.」と表示され、「Directions Asia May 2026」のレポートが自動作成済み。金額はUS$1,147.92（Reimbursable）。カテゴリはGROUNDTRANとHOTELSに自動分類され、画面上は「Review」中心の体験として提示されています。

ステップ3は「Configure Expense Agent」

会計デフォルト（Number series、Payment methods、Expense posting groups、Include expense categories）と、管理デフォルト（Expense locations、Include management rules）が整理され、右側パネルには「EA Expense Agent — Configured by CIPRIAN.IORDACHE」と表示されていました。

さらにPayables Agentの稼働例として、wwi\_invoice\_282044.pdf（Wide World Importers）上で「Payables Agent found: The agent made the best possible selection based on the invoice’s information. Review the agent selection.」が示され、AI処理の可視化が続きます。

8.「業務の地味な現実」を押さえる

Jannik Bausagerが再登壇し、Day1を“経費デモの盛り上がり”で終わらせず、業務領域を広げていきます。

Quality Management：Purchase Receipts→Test Parameters→Sampling→Quarantine→Certificateの流れ

Subcontracting enhancements：Production Order→Send to Vendor→External Processing→Receive Finished Goods→Complete、加えて返品、チェーン、価格リストなど

Withholding taxes：オーストラリア、ニュージーランド、インド、イタリアを除く国で利用可能

Excise taxes：Tax Types、Entry Types、Duty Rates、Itemsへの割当、Auto Calculation、税基準は重量、体積、数量、砂糖、アルコール、活性含有量

Self Billing Invoice：仕入先に払う予定の金額から受領予定の請求書を発行できるようになりました。

Drop Shipment：利便性が向上しました。

Shopify：コネクタ機能が拡張されました。

Analytics：Power BIや分析系レポートが拡充されました。

More Improvements：Dataverse連携フィールド、承認ワークフロー、外部ドキュメントストレージ（SharePoint/OneDrive）、Planning without SKUs、Purchase
quotes for contacts、転記制限のDate formulas、New permission overview、Fixed assets improvements（ボーナス減価償却など）

ここが効きます。なぜなら、Agenticの話は派手ですが、実際に現場が動くのはこの“地味な業務の積み重ね”だからです。Day1はそこまで含めて、ちゃんと網羅されていました。

9.AI-firstはスローガンではなく結論

そして最後に、Mike Mortonが再び前に出てDay1を締めます。

このパートでは、それまでのデモを受けて、メッセージが一段引き上げられる。まず提示されるのが、「One Planet, One Microsoft, One Copilot」というスライドである。ここで示されているのは、単なる製品の話ではない。

Dynamics 365、Microsoft 365、そしてCopilotが個別に存在するのではなく、一つの体験として統合されていくという前提が明確に置かれる。

その上で、「Microsoft 365 Copilot in Business Central」という形で、Business Centralの中にM365 Copilotの体験が組み込まれていく方向性が示される。ここで語られているのは機能の追加ではない。業務の中で使われるインターフェースそのものが、Copilotを前提に再構成されていくという変化である。

さらに続くスライドでは、開発や業務の進め方そのものが変わっていく構造が提示される。エージェント、接続、ツール、評価、そしてそれらが連携していく全体像が示され、単一の機能ではなく、システムとしてAIが組み込まれる世界が描かれる。ここまでくると、単なるデモの話ではない。Agentic ERPという考え方が、個別の機能やユースケースではなく、Microsoft全体のプロダクト戦略として一貫した方向を持っていることが明確になる。

そして最後に、「Visit the Microsoft booth」というスライド、続いて「Thank you」で締めくくられる。

ブースでは、BCのロゴをフェイクタトゥーとして入れられるよと、とてもシュール。

ここまでの一連の流れは、単なるキーノートの締めではなく、ビジョンを提示し、それを製品に落とし込み、その構造まで示した上で終わるという、非常に意図的な構成になっていた。

Day1は、最初に“前提を壊す”話をして、途中で“現実に触れさせて”、最後に“結論として迫る”という構造でした。とても巧妙につくられていたと思います。

― Day2：AIは“ツール”ではなく、“業務そのものを動かす主体”へ

1.幕開け｜「今日の流れ」と“参加者の行動”を整える

Day2はFrankがキックオフを担当し、まず「Keynote Day 2 Agenda」を明示します。内容はWelcome、Sessions、Party、eONE（スポンサー）、Microsoft（Microsoftキーノート）という並びでした。

ここでDay2の特徴が出ます。Day1が“前提を壊す日”だとすると、Day2は“具体を積み上げる日”です。そのため、セッション評価（Overall rating／Speaker／Session value）への参加を促し、「評価して当てよう」という呼びかけまで含めて、参加者を“聞くだけ”から“関わる側”へ寄せていきます。

また、イベント規模として「100+ Sessions at all」「65 Sessions to host from Directions team」「240+ Submissions」が再提示され、スポンサー構成（Platinum／Gold／Lounge／Silver／Bronze／Media）も改めて共有されました。

2.アジアを「成長エンジン」として定義し、AIの波を“市場側”から固定

Day2のMicrosoftキーノートは、GustavoFunchs（VP Asia Channels）が担当しました。

ここでの役割は明確で、Day1で語られた“Agentic”を、アジア市場という現実のスケールに乗せることです。

2-1.「Asia is Microsoft’s Growth Engine」：

世界人口に占めるアジアの割合：57%
2030年の世界GDPに占めるアジア：58%
今後6年間の新規GDP成長：67%
2025年のテクノロジー支出成長率：7.6%
世界AIパテントに占めるアジアの割合：75%
世界の開発者のうちアジア出身の割合：2/3
世界の若者労働力（2040年）：55%
アジアのSME割合（WW SMEs）：約57%
アジアの組織のうちSMEの割合：98%　等

ここまでやるのは、単に市場が大きいと言いたいのではありません。

Day1の“Agentic”をアジアの構造変化（人口・GDP・労働力・AI特許・開発者）に結びつけるためです。

2-2.「Asia: Accelerating Growth with AI」— TAMとMomentum：

さらに、AIを絡めた整理として以下が示されます。

• 世界のSMEの57%がアジアに存在
• 世界労働力の64.6%
• テクノロジー支出増加の50%以上がアジアから
• Asia SME\&CのTAM：FY26時点で$223B

2-3.2026 Work Trends Index：

次の波は“機能”ではなく“業務に埋め込まれたエージェント”

ここはDay2の空気を決めたパートです。新データとして、Copilot会話の49%が認知的業務をサポート、組織的AIインパクト67% vs 個人的努力32%、アクティブエージェント前年比15倍が提示され、「次の波はフィーチャーではなく、業務とワークフローに組み込まれたエージェントだ」と明言されます。

そして「Asia Business Central Momentum」として、Reach +30%、Frequency +4%、Yield +21%が提示されます。

2-4.ビジネス実績とパートナーへの機会提示：

「FY26 is our best year on record…」として、Customer Adds／Seats Adds／Market Shareが過去最高、かつ「年はまだ終わっていない」と続けます。

さらに「Your Opportunity」として、アジアSMB SaaS ERPの5年CAGR +15%、M365 Copilot有料ユーザー +20M、そして“AIテストをプロセス適合ユースケースに転換し、エージェントを開発・展開・サポートする”という方向が示されます。

最後に「Frontier Transformation: Lead the Channel in FY27」として

5つの柱（Customer Zero／Technical Intensity／Agentic GTM／Value Alignment／Precision Velocity）が提示され、Day2は「市場としてのアジア」と「エージェントの波」を一本の線にします。

3.「作り方」を見せ、Techの地面を固める

Day2のTechセッションは、3人が連続して担当する構成になっていた。最初にKennie Pontoppidanが「作って動かす」を見せ、次にDmitryが「なぜそうなるのか」を言い切り、最後にPeter Borringが「仕組みとして閉じる」。この順番自体が、Agentic Engineeringの論理を体現していました。

このパートでは、これまでのデモとは明確に異なるテーマが扱われている。ここで提示されているのは、Agent時代におけるパートナーやコンサルタントの役割そのものである。

まず前提として、従来のコンサルタントの役割がそのままでは成立しないという問題提起が置かれる。その上で、業務がどのように分解され、どの部分がエージェントに置き換わっていくのかが段階的に示されていく。

スライドでは、単一のAIがすべてを行うのではなく、複数のエージェントが役割を分担しながら連携する構造が提示される。販売、財務、調達、モニタリングといった各領域ごとにエージェントが存在し、それぞれが状態を共有しながら全体の業務を動かすモデルである。

さらに重要なのは、コンサルタントの仕事そのものがこの構造の中に組み込まれている点である。要件定義、設計、実装、検証、運用、さらには戦略アドバイザリーに至るまで、すべてのフェーズにおいてエージェントが関与する形が示される。

つまりここで語られているのは、生産性向上ではない。コンサルタントの仕事が、プロセス単位で再構成されているという変化そのものである。
3-1.コンプライアンス・監査対応：

冒頭、Kennie氏のパートでは、単にエージェントを利用するのではなく、それをどのように構築するのかという点に踏み込んだ話が展開された。

最初に提示されるのは、レポーティングやKPI管理といった業務要件である。どの指標を追うべきか、どのデータをもとに意思決定を行うのかといった観点から、エージェントに求められる役割が整理される。ここでは、単なる機能ではなく、業務そのものをどのようにエージェントに落とし込むかがテーマになっている。

その上で、M365 Copilot上で「Reporting & KPI Agent」を実際に構築するプロセスが示される。プロンプトとして要件を入力することで、エージェントの構造や処理ロジックが生成されていく様子が、そのまま画面上に表示される。ここでは、設計と実装の境界が曖昧になり、要件を記述することそのものが開発行為になっていることが分かるという説明だった。

さらにその処理は継続し、エージェントの構成やロジックが具体的な形として組み上がっていく過程が示される。ここまでくると、AIは単なる補助ツールではなく、業務要件の整理からエージェントの生成までを一貫して担う存在として機能していることが明確になる。

つまりこのデモで示されているのは、業務を実行するだけでなく、その業務を支える仕組みそのものを構築するプロセスまでが、AIによって担われるようになるという変化なのだ。

次のパートでは、先ほどのKPIエージェントの構築に続き、より具体的なユースケースとして「ITコンプライアンス監査」をテーマとしたエージェント構築デモが行われる。
まず、「Building IT compliance agent」というテーマが提示される。ここで示されているのは、単なる自動化ではなく、監査という専門性の高い業務そのものをエージェントとして実装するというアプローチのようだ。

Step 1：M365 Copilotで監査人が実施するコンプライアンスチェック（20件以上）を生成。職務分離と承認ワークフローを中心に、BCコアモジュール全体へ均等に分散するよう指示。

Microsoft Copilot Studioを使い、Business Central向けのコンプライアンス監査エージェントをリアルタイム構築していく。

3-2.デモ手順：

M365 Copilotの画面が表示され、実際にプロンプトを通じて要件を定義していく流れに入る。ここでは、監査人が通常行うコンプライアンスチェックの内容を自然言語で記述し、それをもとにエージェントの振る舞いを定義していくというプロセスが示される。

その後、入力された要件に基づいて、具体的なエージェントが生成されていく。ここでは、「Stella’s Compliance Audit Maker」といった形でエージェントが構成されていく様子が確認でき、単なるテンプレートではなく、実業務に近い監査ロジックが組み上がっていく過程が可視化される。

さらにデモは進み、生成されたエージェントがBusiness Centralの環境と接続され、実際のデータに対してコンプライアンスチェックを実行していく様子が示される。ユーザー、権限、トランザクションといった情報に対して、AIが自動的に監査処理を行う流れが確認できる。

Step 2：生成したチェックリストをファイル化し、「Directions Asia 2026 demo」のKnowledgeとして登録。

続いて、エージェントの設定や挙動がさらに具体化されていき、どのような条件でチェックが行われるのか、どのような結果が返されるのかといった実行ロジックが明確になっていく。

その結果として、問題のある設定やリスクのある操作が抽出され、改善が必要なポイントが可視化される。ここでは、単なるデータ処理ではなく、分析・判断・提案までを含めた一連の監査プロセスが自動化されていることが示される。

さらに処理は継続し、複数の条件や業務シナリオに基づいたチェックが実行されていくことで、エージェントが単発の処理ではなく、継続的な監査機能として動作することが確認できる。

Step 3：Copilot StudioのToolsで「Dynamics 365 Business Central MCP（Preview）」を設定。EnvironmentはAS0253\_PS0221\_US\_29-0、MCP Server ConfigurationはAudit APIs、CompanyはCRONUS USA, Inc.。

Step 4：「Stella’s Compliance Audit Maker」として稼働し、全ユーザーのフルコンプライアンスチェック、全ユーザーのステータスサマリーと重大度、リメディエーション提案まで含めて実行。

3-3.結果（Must-Do Recommendations）：

出力例として、Jannik Bausager、Mike Morton、Stella（いずれもデモ上のユーザー名）に対する指摘が提示されます。たとえばJannikはSUPER\_ACCESSや自己承認などの組み合わせが即時レビュー対象、Mikeは購買発注書の自己承認ループが問題、Stellaは支払処理と銀行照合の二重役割を分離すべき、という内容です。

エージェントが生成したレポートや提案内容が整理され、実際にどのようなアクションにつなげるのかという視点まで含めたアウトプットが提示される。

そして最後に、こうしたエージェントが単体で動くのではなく、複数のエージェントと連携しながら全体の業務を支える構造が改めて示され、このデモが単なるユースケースではなく、今後のシステム全体像の一部であることが強調される。

ここでの意味は、監査の話そのものではありません。「エージェントは“業務を回す”だけでなく、“統制を回す”側にも入る」という現実を、Copilot Studio×MCPで“作って見せた”ことだと思っています。

4.Agentic Engineeringの中心として「ソフトウェアが“やる側”へ移る」

Day2の中核がDmitry　Chadayev　（Principal Group Product Manager）が示した『Agentic Engineering』です。

これは、今回の3日間の中で個人的に一番ヤバかったところです。

エージェントを業務に組み込む際に必要となる運用モデル全体が整理されているスライドが提示されました。

ここで示されているのは、単にエージェントが業務を実行するという話ではない。

そのエージェントをどのように管理し、制御し、監査するのかという、実運用の観点です。

エージェントが生成した提案は人間がレビューできるようになっており、重要な操作については事前に確認を挟む仕組みが用意されている。

また、エージェントの権限やアクセス範囲は細かく制御され、どのデータに対してどの操作を行えるのかが明確に管理される。

さらに、エージェントの実行履歴はすべて記録され、どの処理がどの順序で実行されたのかを追跡できる。

加えて、AIの判断についても補足情報として提示されるため、その結果に至った理由を理解することができる。

つまり、ここで提示されているのは「AIが業務を代替する」という話ではなく、AIが業務を担うことを前提としたガバナンスと透明性の設計そのものである。

エージェントが単なるデモや実験段階に留まらず、すでに実務として成立しつつあることが示されている。

まず、実際のパートナーや顧客の事例が紹介され、エージェントが現場の業務に組み込まれていることが強調される。これは、AI活用が検証段階ではなく、すでに価値を生み始めていることを意味している。

続いて、エージェントの実装が具体的にどのように行われるのかが示される。ここでは、エージェントがコードやロジックとして設計されるものであり、単なるブラックボックスではなく、制御可能なシステムであることが明確にされる。

さらに、PoCレベルの検証から本番運用へと移行するための考え方が提示される。単に試すだけではなく、業務として成立するレベルに引き上げることが求められている。

そして最後に、実際にパートナー企業が開発している様々なエージェントが一覧として示され、この流れが個別の取り組みではなく、エコシステムとして広がり始めていることが強調される。

4-1.パラダイムシフトの宣言：

ソフトウェアは支援するものから、実行するものへ

「We are moving from software that helps you do work to systems that do the work for you.」

Day1が“ERPが次を動かす”だったとすると、Day2は“開発が次を動かす”という話に移ります。

つまり、プロダクトの話ではなく、作り方そのものの話です。

このパートでは、「Agentic engineering」という概念が提示される。ここで語られているのは単なるAI活用ではない。ソフトウェアの役割そのものが変わるという前提である。これまでのシステムは、人の業務を支援するものだった。しかしここで提示されているのは、業務そのものをシステムが実行する世界である。これは単なる自動化ではなく、ソフトウェアの役割の根本的な変化を意味している。

AIの進化によってソフトウェア開発のハードル自体が大きく下がったことが示される。コードを書くという行為はすでにボトルネックではなくなり、「ソフトウェアは誰でも作れる」という状態に近づいていることが示唆される。ここで重要なのは、技術が進化したことではない。何が価値であるかの基準が変わったという点である。

4-2.Agentic Loop（開発は直線ではなくループになる）

その上で提示されるのが、「ボトルネックの再定義」である。問題はコーディングの速度ではない。むしろ、「Signal（気づき）からAction（実行）」までの時間こそが、開発における最大の制約であるとされる。

従来の開発プロセスは、要件定義、バックログ、計画、実装、レビュー、テスト、リリースといった複数の工程に分断されている。これらの工程が人の手によって順番に処理される構造そのものが、変化のスピードを遅らせている。ここで示されているのは、開発が直線的なプロセスではなく、Observe／Reason／Act／Repeatというループとして再設計されるべきであるという考え方である。

在庫管理を例に、OBSERVE（安全在庫を下回る）→REASON（LTや閾値を分析）→ACT（発注）→FETCH DATA→VERIFY→MEMORY→次のOBSERVE、というループが示されます。

続くデモでは、これらの工程がエージェントによってどのように再構成されるかが提示される。タスク管理、レビュー、実装、検証といった一連の処理が分断された作業としてではなく、一つの流れとして連続的に処理されていく様子が示される。

さらに、Prompting（Human asks, Model answers）からAgentic Loop（Observe, Reason, Act, Repeat）へ進化した点が整理されます。

エージェントは単に処理を実行するだけではなく、コードの生成やロジックの実装といった開発行為そのものを担う存在として機能していることが明確になる。ここまでくると、開発は「人が考え、人が作る」というモデルから、エージェントが観測し、判断し、実行し続けるループ型のモデルへと移行していることが理解できる。

4-3.Multiple Agents, Shared Goals（単一AIではなく、連携するエージェント群が業務を動かす）：

Service Monitoring、Sales Signal、Orchestration（Agent Coordinator）、Finance Budget、Demand Forecast、Vendor Data、Procurementなど、複数エージェントが協調し、目標を共有する構成が示されました。

提示されたのは、エージェントの構造そのものの変化。スライドでは「The core building blocks of an AI Agent」という形で、業務がどのように分解され、どのような単位でエージェントとして構成されるのかが示された。従来は一つのシステムで一つの処理を完結させる構造が前提だったが、ここで示されているのは、業務そのものを複数の機能単位に分解し、それぞれをエージェントとして扱う設計である。

続く画面では、こうしたエージェントが実際にどのように動くのかが具体的に示された。個別のプロンプトや設定を通じて、それぞれのエージェントに役割が与えられ、それに基づいて処理が進行していく。

ここで重要なのは、単一の指示で完結する処理ではないという点である。エージェントは連続的に入力を受け取りながら処理を進め、状況に応じて振る舞いを変化させていく。

さらに、各エージェントは単独で動くのではなく、業務の中で相互に関係しながら動作する。例えば、あるエージェントの出力が次のエージェントの入力となり、それが連鎖することで1つの業務が形成される。

この一連のスライドでは、タスクの分解と再構成が繰り返し示されている。これは単なるプロセス改善ではなく、業務の構造そのものが変わっていることを意味する。各ステップが個別の処理ではなく、エージェントの連携として再構築されていく。

ここで見えてくるのは、エージェントが「実行する存在」から「判断し続ける存在」へと変化している点である。単発の処理をこなすのではなく、状態を保持しながら継続的に意思決定を行う構造が成立している。

さらにデモは、これらのエージェントが並列的に動作し、複数のタスクが同時に進行する様子へと展開していく。ここでは、タスクの優先順位付けや進行管理、結果の反映までが一体となって処理される。この構造では、個々の処理を最適化するのではなく、複数のエージェントが協調して全体最適を実現することが前提となる。

この流れは最終的に「Business Central Agentic Engineering」という全体像に集約される。ここで示されているのは個別機能の進化ではない。エンタープライズシステム全体がエージェント前提で再設計されることを意味している。

最後に、この変化は単なる技術の進化ではなく、システムと人の関係そのものに影響を与えるものであることが示唆される。ここまでの流れが、次に語られるコンサルタントの役割の変化へと自然に接続されていく。

4-4.New golden age of consultants（コンサルの価値は作業から構造設計へ）：

ここから議論は、システムやエージェントの構造そのものから、「その上で人は何をするのか」という問いへと移っていく。

提示されるのは、エージェント単体ではなく、それらを支える「Agentic tools」としての全体像であり、価値は個々の機能ではなく、組み合わせと活用の設計にあることが示される。

続いて示されるのは、Agentic engineeringがもたらすビジネスインパクトである。

ここでは、開発効率やコスト削減といった従来の評価軸ではなく、意思決定のスピードや価値創出の構造そのものが変わることが強調される。

ここで提示されるのが「Engineers in the loop」という考え方である。

重要なのは、AIに置き換わるのではなく、役割が再配置される点にある。エージェントが実行を担い、人間は判断・設計・優先順位付けに集中する。

これは効率化ではなく、仕事の分担構造の再設計である。

さらに、Business CentralにおけるAgentic engineeringの全体像が提示される。

複数のエージェントが業務や開発プロセスの各フェーズに入り込み、全体として価値を生み出す構造が整理される。

ここで初めて、「部分最適ではなく全体設計」が必要になることが明確になる。

この変化は「Engineering Transformation」という言葉で定義される。

つまり、開発という行為そのものが再定義されている。

そしてここで、コンサルタントの役割が直接的に示唆される。

従来は「要件を集めて、設計して、実装する」役割であったが、この構造ではそれらのプロセスにエージェントが入り込む。

その結果、人間の役割は、個々の作業から離れ、プロセス全体を設計する側へと移行する。

「AI supports consultants by boosting every process from idea to impact」

つまり、コンサルタント業務の全フェーズにエージェントが入る例が提示されます。

ここでのポイントは“便利”ではありません。

コンサルの価値が「作業」から「プロセス全体を押し上げる」へ移る、というDay3への伏線にもなっています。

ここまで見てきたのは、Agentic Engineeringによって仕事の構造そのものが変わるという話でした。

では、この変化はどのように現場で成立するのだろうか？

5.“仕組み”を定義し、Techの話を締め切る

ここで一度、全体を整理し直しておきたい。

先のパートで示されたのは、Agentic Engineeringという「考え方」と、開発や業務の前提そのものが変わるという話だった。

しかし、定義だけでは現場は動かない。必要なのは、それを実際に作り、つなぎ、運用し、継続的に回せる状態に落とすための「仕組み」である。

以降は、その仕組みを構成する要素が順番に提示されていく。ここからは、それらを改めて確認していく。

5-1.Business Central MCP Server（aka.ms/bcMCP）：

最初に示されたのは、エージェントがBusiness Central上で“業務として動く”ための接続面である。提示される特徴は、Broad surface（全アプリドメインがエージェントから利用可能）、Easy admin（馴染みのあるセキュリティ概要と管理）、Available tools（Dynamic tool discovery：読み取り専用／Built-in & custom API pages：読み書き／Soon：API queries）、Available hosts（Microsoft Copilot Studio／OAuth2.1対応ホスト）という整理である。ここで強調されているのは、エージェントが勝手に何でもできる世界ではなく、どこまで触れてよいか、どう接続するかを“仕組みとして定義する”という前提だ。

5-2.エージェント機能の概要（8機能）：

次に、エージェントを企業の業務に入れるための“運用モデル”が、機能として明示される。Review agent suggestions、Agent timeline、Permissions & Profiles、Activation & configuration、Natural language instructions、Reasoning toolbox、Review sensitive actions、Complete agent log。ここで示されているのは、AIが業務を代替するという話ではない。AIが業務を担うことを前提に、管理・制御・監査できる状態を最初から用意するという設計そのものだ。

5-3.Red Carpet Agent Program（パートナーのエージェント例）：

続いて示されるのが、パートナーが実際に開発しているエージェントの具体例である。Time registration agent、Configurator agent（OA first attitudes）、Timesheet agent（nab°）、Manifest and sales claim agents（Aptean）、Permission agent（2CONTROL）、Bank accounts & deferral of payment agents（AXIANS）、Contract renewal agent（Binary Stream）、Sales return agent（soesolutions）、Membership automation agent（EGWS）、Subscription renewal（LS Retail）、Inventory recall agent（PRINTVIS）、Payroll agent（Salety）、Sales return agent（TRIMIT）、Purchase checker agent（yaveon）、Maintenance intake agent（社名未記載）などが列挙される。ここは「いつか誰かが作る」ではなく、すでにエコシステムが動き始めていることを視覚で固定するパートになっている。

5-4.ボトルネックはコーディングではなく「Signal→Action」：

ここで再び、ボトルネックの定義に戻る。「AI made software creation accessible to everyone…」に続き、「The bottleneck is no longer coding capacity. It’s the time from signal to action.」が提示される。そして工程別リードタイムとして、Signal 3〜8 days、Backlog 2〜3 weeks、Planning 1〜2 weeks、Coding 5〜7 days、Review 1〜2 days、Testing 1〜4 weeks、Release 1〜2 weeksが示され、「Every handoff loses time, intent, and context」と繋がる。ここで言っているのは、技術が足りないという話ではない。分断されたプロセスそのものが速度を奪うという主張だ。

5-5.GitHub上のAgentic Loop実演（Boardとカラム件数）：

次に、その「Signal→Action」を“ループとして回す”具体像が、GitHubの画面で示される。Business-Central-Cronus-Demoリポジトリ上でAgentic Boardのカラムと件数が提示され、Signal 4件、Triage 2件、Plan 2件、Implement 2件、Review 1件といった状態が見える形で並ぶ。さらにラベル（Agents-Tested／Agent-Triaged／RCAed／Integrationなど）が自動付与され、エージェントが各フェーズを処理する様子が示される。ここは「自動化の紹介」ではなく、工程そのものをループとして再設計して回すという実演である。

5-6.Agentic Engineering Process — Vision と各エージェントの役割：

続いて、ループを“設計図”として定義する。Signal Agent→Triage Agent→Planning Agent→Development Agent→Review Agent→Shipping（CI/CD）という流れが示され、基盤はGitHub／AL-Go for GitHub。各エージェントの役割も、Signal Agent（テレメトリ・ユーザーフィードバック・BC Issues・GitHub Issues）、Triage Agent（評価・分類・複雑性・コード影響分析・タグ付け）、Planning Agent（実装計画・設計・テスト戦略・ドラフトPR説明）、Development Agent（MCPツールで実装・テスト・コンパイル・実行）、Review Agent（レビュー自動化・セキュリティ・パフォーマンスチェック）として整理される。ここで初めて、「工程が回る」ことが、役割分解された“仕組み”として定義される。

5-7.BC Bug Fix SKILL（SKILL.md）の公開：

さらに、やり方を“スキルとして定義する”段に入る。SKILL.mdとして、Phase1 Investigate and Plan、Phase2 Write Test and Establish Baseline（最大5回反復）、Phase3 Implement Fix（最大5回反復）、Phase4 Commit、Phase5 Summaryが示される。重要なのは、属人的なコツではなく、反復可能な工程として明文化されている点だ。

5-8.BCQualityとBC-Bench（オープンソース）とリーダーボード：

次に、品質と評価の仕組みが提示される。BCQuality（品質知識・スキル、カテゴリ別ナレッジ、ルール／ベストプラクティス／アンチパターン）と、BC-Bench（100件以上の実世界ALタスクでエージェントをベンチマーク、業界標準手法に準拠）が紹介され、ベースラインリーダーボードの数値が列挙される。ここでの意図は明確で、AIの性能を“雰囲気”で語らず、測って改善を回すための基盤として提示している。

5-9.Engineers in the loop（～30%をAIが担当）

ここで人の役割が再定義される。OBSERVE→REASON→BUILD→PUBLISH→VERIFYの循環としてエンジニアの役割が示され、～30%の作業をAIが担当というデータとともに、AL-Go→Commit→BCQuality（Knowledge）→BC-Bench（Evaluate）という全体像が併記される。ここで言っているのは、人が不要になるという話ではない。人はループを設計し、検証し、知識を積み上げる側に回るという整理だ。

5-10.やってはいけない／目指すべき姿

ここで強い線引きが入る。Adding AI to engineeringではなく、Redesigning engineering around agents。AI magic, Autonomous chaosではなく、Disciplined, enterprise-grade engineering transformation。つまり、AIを足して終わりではなく、統制された変革として再設計することが必要だというメッセージである。

5-11.2026 Wave 1新機能トピック：

最後に、Wave 1の新機能トピックがまとめて列挙される。Performance improvements（In-client index management、Scheduled Performance Profiler追加インサイト、Base64変換効率化、内部メモリ最適化）、Document reporting（Wordアドイン更新、レイアウトライフサイクル、送信ドキュメントの会社レベルデフォルト言語、ドキュメントレポート用新API10種類）、Security/audit reporting（権限分析ページ、承認分析ページ、ユーザー管理の強化分析タブ、Permission API、Approval API）、Ship Analysis Views as apps、MCP Tools for administrators（Public Preview：Environment lifecycle management、Operation result analyses、App management、Session management、Updates management、Environment settings）、Custom Cloud Migrations（SQLベース移行、コードなしのテーブル選択、v14からの再実装移行：オープンソース、28.2から）、vNext online environment、Partner Sandbox（BCライセンス5購入、Sandbox environments 3取得）である。

ここは“機能紹介”で終わらず、エージェント前提の世界を支える土台を製品と運用の両面で積み上げるという整理になっていた。

5-12.Call to action（締め）：

最後にCall to actionが提示される。Make AI an executive priority、Establish agent governance、Elevate tech talent to process owners。Techの話を「仕組み」の話として閉じるために、ここで論点が経営と組織へ引き上げられる。

Day2は、順番そのものに意味がありました。

Frankが「今日の導線」を整え、Gustavo Funchsが“アジア×AI”を市場の現実として固定する。

その上で、Kennie PontoppidanがCopilot Studio×MCPによって「作って動かす」ことを示し、

DmitryがAgentic Engineeringの中心として「ソフトウェアが“やる側”へ移る」と言い切ります。

さらにPeter Borringが、その変化を現実に落とすための仕組み―

―MCP Server、Agentic工程、オープンソース（BCQuality／BC-Bench）を含めて具体化し、

最後はDmitryのメッセージによって全体が意味づけられ、締めくくられます。

＜おまけ＞

このパートは、直前のJannikの領収書デモと地続きになっている。

Expense Agent領収書のデモでは、散在するデータを集め、整理し、突合し、最終的な判断までをAIが実行していた。

今回のスライドで行われているのは、そのプロセスを別の領域に展開したものだ。

手の写真という一見すると曖昧な入力に対して、その特徴を解釈し、適合するエージェンシーを提示し、さらには理由となるコメントまで生成している。

つまりここで示されているのは、単なる画像認識ではない。

「どこに提案すべきかを考える」という、人が担っていた判断プロセスそのものが、エージェントによって実行されているということだ。

領収書の処理では自然に受け入れられるこの流れが、クリエイティブや営業といった領域に拡張されたことで、

「そこまでやるのか」というギャップが生まれ、会場の笑いに繋がっていた。

― Day3：AIは“効率化”ではなく、“稼ぎ方と価値の定義そのもの”を破壊するものへ

1.幕開け｜3つの前提が「壊れた」と宣言

最終日のキーノートは、これまでと明確に違うトーンで始まる。スクリーンに映し出されたのは「Three assumptions just broke.」という一文だった。この一言で、これまで積み上げてきた前提がすでに通用しなくなっている。

ここで語られたのは、パートナービジネスを長く支えてきた3つの柱である。専門知識、時間課金、そして顧客が専門性に依存する構造。この3つが同時に圧力を受けているというのが出発点になる。

さらにその内訳として、変化の中身が具体的に説明される。これまで時間をかけていた執筆や開発、テストやドキュメントといったコア業務がAIによって圧縮されていくこと、長年の積み上げだった製品知識がプロンプトで取り出せるようになること、そしてツールとして扱っていたAIがエージェントという形で新しい労働力として扱われ始めること。この3つの変化によって、これまでのビジネスの成り立ちが同時に崩れていく。

ここで提示されているのは技術の進化ではない。何で価値を出し、何でお金をもらってきたのかという前提そのものが崩れているという宣言である。

2.コミュニティキーノート

聞く場から、参加して向き合う場へ変わる

Day3の中心となるのはCommunity Keynote Partner Panelである。ここまでの流れでは、Day1で方向性が示され、Day2でそれが技術として具体化された。それに対してDay3では、現場がそれをどう受け止めているのかが問われる。このセッションの特徴は、会場とのインタラクションを前提としている点にある。Slidoを使ったライブ投票を軸に、参加者の回答をその場で可視化し、その結果をもとに議論を進める構成になっている。つまりここでは、登壇者が正解を提示するのではなく、その場にいる全員が自分たちの現在地を数字として突きつけられ、その上で議論が進む形になる。これによって、話は一気に抽象から現実へ引き戻される。

3.パネルの構図

異なる立場が同じ温度で並ぶ

パネルの構成も意図的に設計されている。Microsoft側のプロダクト責任者と開発責任者に加え、パートナー企業の経営者、そしてコミュニティ側の実践者が同じステージに並ぶ。この並びによって、理想論だけでもなく、現場の話だけでもない状態が生まれる。Day1とDay2で語られてきた「こうなる」という方向に対して、「実際にどうなっているのか」「どう受け止めているのか」がそのまま重なる構造になる。この時点で、セッションの目的ははっきりしている。未来を説明することではなく、今の状態を正しく見つめることにある。

4.Slido投票が突きつける現実

このセッションで最も印象的だったのは、投票結果そのものだった。最初の質問は、AI-firstな未来に対して自社がどれくらい準備できているかというものだった。その結果、最も多かった回答は「社内ではパイロットをしているが、顧客向けには何も出していない」というものだった。

ここで重要なのは、多くの企業が何もしていないわけではないという点である。AIは使い始めている。しかし、それを顧客に提供するレベルにはまだ到達していない。このギャップが、そのまま数字として現れる。

Day1でAI-firstを求められ、Day2で実装の現実を見たうえで、Day3の最初に自分たちの位置がここにあると明確になる。この流れによって、会場全体の温度が一段変わる。

次の質問では、顧客が今後何に対してプレミアムを払うかが問われる。その結果、最も多かったのは「努力ではなく、契約で保証された成果」という回答だった。ここで示されているのは単純な嗜好ではない。価値の定義が変わっていることが、参加者自身の選択として現れている。これまでのように、どれだけ時間をかけたかではなく、何を結果として出したのかが評価される。ここでも、最初に提示された前提の崩壊と、会場の認識が一致してしまう。

＜参考｜パネルディスカッションのお題目と集計結果＞

5.どう変わるかではなく、どう向き合うか

この投票結果を受けて、パネルの議論はより現実的な方向に進んでいく。話題になるのは、AIをどう使っているかではなく、それをどうビジネスに組み込んでいるか、あるいは組み込めていないかという部分である。提案の骨子作成や動画作成にAIを使う、社内の合意形成に活用する、外部の専門家を入れて変革を進めるといった取り組みはすでに始まっている。しかし同時に、従来の業務が置き換わることで役割が曖昧になり、どこに価値を置くべきかが見えなくなっているという課題もそのまま出てくる。ここで語られているのは成功談ではない。変わり始めているが、まだ整理されていない状態、そのものが共有されている。

6.ビジネスモデルの変化：時間から価値へ

この流れの中で、方向性だけは明確に見えてくる。時間で課金するモデルが維持できなくなるということ、その代わりに求められるのは価値、アウトプット、そして結果に対する責任であるということ。時間をかけたことではなく、どのような成果を出したのかが評価されるようになる。この変化は抽象的な議論ではなく、先ほどの投票結果と一致する形で現れている。つまり理論として語られた未来ではなく、参加者自身が選んだ結果として、同じ方向が示されている。

7.最終的に変わるのは自分自身である

パネリストの一人だった私（吉島良平）からは、会社として外部からAIのコンサルタントを入れてAI時代に見合った働き方へ変えようとしている。提案依頼を受けた際に、いくつかのAIを活用し、提案対応の骨子資料やVIDEOを作って社内でコンセンサスをとるための準備を行ったりしていること、導入・保守、製品開発領域においても、各チームでの取り組みが着実に進んでいることが説明された。

また、課題というかチャレンジとして、彼が昨日担当したセッションの中で説明した、　４象限のメカニック領域（課題解決＋システム導入）はAIに置き換えられる可能性が高く、ここに位置するリソースをどのように他の領域のリソースとして育成していくか？等について解説していた。AIは時間（での請求）を崩壊させ、そのかわりに価値、アウトプット、説明責任等がそれらの代わりになっていくと補足した。

最後に、私（吉島良平）からは、ITをやっている以上、お客様も自分たちも時代に見合った働き方ができるように貢献していく事が重要で、お客様に製品を導入して変革をしていってもらうためには、自らが日々変化していく事が必要だと説明。Let’s Get out of comfortable zoneというフレーズで締めくくった。

Day1で考え方が変わり、Day2で作り方が変わり、Day3ではその先にある生き方と稼ぎ方の変化が示される。そして最後に、それを実行する主体は自分自身であると突き付けて終わっている。

Day3は、最初に前提の崩壊を宣言し、次に会場の現実を数字で可視化し、その現実を受けて議論を行い、ビジネスモデルの変化を確認し、最後に個人の行動へと落とし込むという流れで構成されていました。

3日間を通して見ると、Day1は考え方を変える日であり、Day2は作り方を変える日であり、Day3はその結果として、生き方と稼ぎ方をどう変えるのかを問う日だったように感じています。