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

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

決勝戦と、スクラムの話

今日、6月7日（日）—来日中の上司、フレディー(Technosoft CEO)と、ラグビーリーグワン2025-26シーズンのプレーオフ決勝を国立競技場で観戦してきました。

フレディはクボタスピアーズのジャージを着て、私が「Go! Go! KOBE!!」のボードを持つという、なかなかカオスな状態でのキックオフ（笑）

結果は、コベルコ神戸スティーラーズが22-13でクボタスピアーズを下し、優勝。入場者数は50,451人。ラグビー界にとって歴史的な盛り上がりを見せた一日でした。

神戸大学OBとして、大震災を経験したものとして、コベルコ神戸スティーラーズには思い入れがあります。クボタスピアーズは、Technosoftの大切なお客様(公開事例)で、私もクボタスピアーズファン。複雑な立場での観戦でした。クボタのサポーター、通称オレンジアーミーからすると、「マルコムマークス選手が試合に出ていればなぁ…（実は、室長の声）」という感じでしょうか。選手の皆さん、シーズンを締めくくる最高の試合、本当にお疲れ様でした。本当にかっこよかった。とても美しいノーサイドでした。

実は私は、試合を見ながら、先日のマスターデータに関する記事で書いた話を思い出していました。

「スクラムは、全員が同じ方向を向いて初めて機能する。一人でもズレると崩壊する。そして崩れたスクラムは、何度でも組み直せる。」

このブログを書いているのは、帰宅後の深夜。実はMicrosoft Buildの発表がとても気になっていました。MicrosoftのMAIファミリー、7つの新モデルと「Frontier Tuning」。試合の興奮が冷めやらぬまま、D365実装者として「これは流せない」と思ったので、忘れないうちに言語化しておきたいと思います。

整理整頓｜MAIとOpenAIは別の話

「また新しいモデルが増えた」で流してしまうには、もったいない発表なので、少し丁寧に整理しておきたいと思います。今回リリースされたMAI（Microsoft AI）は、OpenAIとは完全に別軸の、Microsoft自社開発モデルファミリーです。Mustafa Suleyman（DeepMind共同創業者）率いるチームが、第三者モデルの蒸留に頼らず、クリーンなデータでゼロから内製したらしいですね。「MicrosoftのモデルはOpenAI経由」という前提は、この発表で正式に終わったと言っていいのではないでしょうか。

ラインナップはこの7本です。

このうちD365実装者の文脈で関係してきそうなのは、Thinking-1、Transcribe-1.5、そして後述するFrontier Tuningです。MAI-Code-1-FlashはGitHub Copilot/VS Code専用のモデルですが、D365のカスタマイズや拡張開発にGitHub Copilotを使っている方にとっては、開発が速く・安くなるという意味でわりと身近な話になってくるかもしれませんね。

MAI-Transcribe-1.5：地味に大きいかもしれない

今回正式GAになったMAI-Transcribe-1.5。「43言語対応・ドメイン固有用語のバイアシング・競合比5倍の速度」という仕様は、D365 Sales/ServiceやCopilot in Dynamics 365での実務に直結してくる可能性があります。商談メモの自動生成、コールセンター起票、サービス記録の音声入力—「VIN番号」「ADAS」「ODO」「予防整備」といった業界固有語が正確に認識されるかどうかで、現場の定着率はかなり変わってくるんじゃないかと感じています。日本語対応の品質は引き続き注目していきたいですね。

本題：Frontier Tuningが変えるかもしれないこと

7モデルの発表と同時に公開された「Microsoft Frontier Tuning」が、今回の発表で最も気になるコンテンツです。仕組みをざっくり言うと、強化学習（RL）を使ってMAIモデルを”自社業務”に特化適応させるフレームワークです。学習の燃料になるのが「エージェントが実際に業務を完了した際のトレース」—ステップ・判断・アクションの連鎖。D365上でエージェントが動いた実績そのものが、モデルを賢くする素材になっていく、というイメージです。数字も出ています。Frontier Tuningを適用したExcel向けMAIが、GPT-4.1と同等の性能をコスト10分の1で実現したとのこと。ある大手企業での試験では、市場最高勝率モデルと同等の結果をコスト10分の1以下で達成したケースも報告されているようです。もちろんこの数字がそのままD365領域に当てはまるかはわかりませんが、方向性として注目に値すると思っています。

Microsoft Automotive Summitで見えていたもの

先日のMicrosoft Automotive Summit 2026で、Frontier Tuningの文脈に重なる話がいくつかありました。今回の発表を受けて、改めて繋がって見えてきます。

BCGの滝澤氏が語った「DEPLOY→RESHAPE→INVENT」のフレームで読むと、Frontier TuningはまさにRESHAPE以上を支える仕組みになっていきそうです。「先進企業はAI投資の80%をReshapeとInventに集中させている」—あの場で強いインパクトを持って受け止められていた言葉が、Frontier Tuningの発表によってより具体的な意味を帯びてきたように感じています。

豊田自動織機の「データはあるが意思決定につながらない」という初期課題は、Frontier Tuningが向き合おうとしている問いの原型のひとつかもしれません。データが揃い、分析もできる。でも「どう判断するか」をエージェントに学習させるには、構造化された業務トレースが要る。Sight Machineで「数日→数時間」になったスピードが、良質なトレースの素材として活きてくる—そんな未来が見えてきます。

Woven by Toyotaが語ったHarness Engineering—「エージェントが自律的に働ける環境そのものを設計する」という思想は、Frontier TuningのRL環境設計と同じ発想に見えます。車載ソフトウェアの品質保証領域で提唱された考え方が、業務アプリケーション全体に適用可能な形でMicrosoftから出てきた—そう読めるんじゃないかと思っています。

BMWのDynamics CRM「ONE Platform」事例は、Frontier Tuningの可能性をリアルに想像させてくれました。顧客接点・ディーラー・コールセンター・Connected App・Power BIが統合され、顧客データ・行動履歴・販売履歴・入庫履歴が一元管理されていた。あの業務フロー全体が「エージェントの業務トレース」として蓄積され、Frontier Tuningで専用モデルが育っていくとしたら—単なる効率化ではなく、BMWの業務知識がモデルに内包されていく世界が見えてきます。

Directions ASIAとAgentic Engineering連載との接続

少し時計を戻したいと思います。5月にベトナム・ホーチミンで開催されたDirections ASIA 2026、MicrosoftのMike氏のキーノートで正式に宣言がありました。

「Dynamics 365 = Agentic Foundation」。この言葉を聞いたとき、「ついに来たか」と思いました。

自分が担当した「Beyond Buildable AI Agents」セッションでは、「パートナーの生存戦略4象限」をお伝えしました。縦軸にシステム構築→人間関係構築、横軸に問題解決→意味を創る、という2軸で4つのアーキタイプ（メカニック・テラピスト・アーキテクト・ガイド）を定義しました。AIに最も置き換えられやすいのが左下のメカニック。そして最も望ましい移行先として提示したのが右上のガイド—人間関係を構築しながら、意味を創る存在—です。もちろん、テラピストやアーキテクトへの移行もあり得ますし、メカニックがなくなるわけでもありません。ただ、Frontier Tuningの登場はこの問いをより鮮明にしてくれる気がしています。

Frontier Tuningは、「設計の腕がそのままモデルの品質に転化されていく」仕組みと言えるかもしれません。どんな判断フローを経てエージェントが動くかを設計した人間の知見が、そのままモデルの賢さになっていく。そう考えると、「誰のための何をどう実現するか」を問い続けるガイドとしての視点が、より代替されにくい領域になっていくんじゃないかと感じています。

Frontier Tuningはまた、Directions ASIAの後に一気に書いたAgentic Engineering全9回連載の延長線上にある話でもあります。あの連載で「L3（条件付き自律）」として設計していたエージェントの判断閾値や行動ルールが、Frontier Tuningによってモデル自体に内包されていく—「設定でコントロールしていたもの」が「モデルが学習して知っているもの」へと昇華していく、そんなイメージです。

エピローグで書いた「最後にハンドルを握るのは人間だ」という言葉は、Frontier Tuningの文脈でも変わらないと思っています。むしろ逆説的に、モデルが賢くなればなるほど、「どこに人間を介在させるか（Human-in-the-Loop）」の設計が問われる場面は増えていくのかもしれません。

Frontier Tuning × Dynamics 365—領域別に何が変わるか

ここからが、D365実装者として個人的に一番考えておきたい話です。Frontier TuningがD365の各領域にどう効いてくるか、BCとFO、そしてCRM領域に分けて整理してみます。

Business Central（BC）：中堅企業の「全部入り」が最強の学習環境になるかもしれない

BCの構造的な強みは、Finance・SCM・販売・購買・在庫が単一データモデルで一体化していることです。エージェントが業務をまたいで動いた際のトレースが断片化せず、一つながりで積み上がっていく。これはFrontier Tuningにとって、素材環境として理想的なんじゃないかと思っています。

現状のBC向けCopilotは、Agentic Engineering連載で言うところのL1〜L2（提案・確認後実行）が中心です。ここにFrontier Tuningで自社業務に適応したモデルが入ってくると、L3（条件付き自律）の判断精度が上がっていく可能性があります。

在庫・購買領域では、こんなシナリオが見えてきます。「この品目はいつも月末需要が跳ね上がる」「このサプライヤーとは数量次第で価格交渉の余地がある」「前回のリードタイムは平均より3日長かった」——汎用モデルには学習できない、自社固有のサプライチェーン文脈をモデルが内包していく。発注タイミングと数量の判断精度が上がるだけでなく、「なぜその発注を推奨したか」のロジックが自社業務に根ざしたものになっていく、そんな未来が想像できます。

財務会計領域では、会社固有の勘定処理パターンや仕訳ルールをモデルが学習することで、エージェントが作る下書きの承認率が上がっていくかもしれません。承認コストが下がり、人間が本当に判断を要する例外ケースに集中できるようになる—連載第2回のHuman-in-the-Loop設計で書いたことの、モデル品質版とも言えそうです。

ただここでも、マスターデータ記事の「月末まとめ入力問題」が影響してきます。BCのトランザクションが月末集中入力であれば、学習素材の時間的分布が歪んでしまいます。「月末だけ賢いモデル」では実務では使いにくい。BCの導入設計においてリアルタイム入力の文化をどう根付かせるかが、Frontier Tuningを活かす上での前提条件になってくるんじゃないかと思っています。

Finance & Operations（FO：SCM / Finance）：グローバルの複雑性こそ、Frontier Tuningの出番かもしれない

FOはグローバル・大企業向けのERPです。複数法人・複数通貨・複数言語・複数会計基準という複雑性の中で動く。個人的には、この複雑性こそがFrontier Tuningの価値が最も大きく出てくる領域なんじゃないかと感じています。

SCM領域では、需要予測→発注→入荷→在庫調整→出荷という一連のサプライチェーントレースが、自社固有文脈を持ったモデルの育成素材になっていく可能性があります。Microsoft Automotive Summitで豊田自動織機が語った「データはあるが意思決定につながらない」という課題は、FOのSCM領域でも頻出です。Frontier Tuningはその「分析から判断へのギャップ」を、モデルが自社業務トレースから学習することで埋めていく—そんな方向性が見えてきます。

Finance領域では、「法人間取引の消去ルール」「原価計算ポリシー」「承認階層に応じた仕訳パターン」といった会社固有ルールは、汎用モデルには学習できません。グローバル展開しているFOユーザーにとって、現地法人ごとの会計処理の違いをモデルが学習・区別できるようになっていくとしたら、その価値はかなり大きいんじゃないかと思っています。

ここで考えておきたいのが、ノックフォワードの記事で書いたDual-writeの設計判断との関係です。FOとDataverseの間のデータ連携が適切に設計されていれば、CRM側のエージェントトレースとERP側のトレースが統合された学習素材になっていく可能性があります。一方で設計が雑だと、マスターデータが汚染された状態のトレースが積み上がってしまう。「繋ぐ前の設計」の重要性は、Frontier Tuning時代においてFO領域でより大きな意味を持ってきそうです。

BCとFOで共通して言えることがあります。Frontier Tuningは「良いERPの使い方」をしている企業をさらに加速させる可能性がある一方で、データ品質が低く、入力が散漫で、業務フローが曖昧なERP運用では、その粗雑さがモデルに刻み込まれていってしまうかもしれません。Garbage In, Garbage Out—ERPにおいても、この原則は変わらなそうです。

D365 Sales：「勝ちパターン」がモデルに内包されていくかもしれない

D365 Salesにおけるエージェントのトレースは、商談フロー全体にわたります。リード獲得→初回コンタクト→商談進捗更新→見積提示→クローズ—この流れでエージェントが何を調べ、何を提案し、担当者がどう判断したか。そのトレースが積み上がっていくと、「この顧客セグメント×この製品カテゴリ×この行動パターン」という自社固有の勝ちパターンをモデルが学習していく可能性があります。

汎用のSales AIが「業界一般のベストプラクティス」しか持てないのに対して、Frontier Tuning済みのモデルは「この会社の、このチームの、この市場での勝ち方」を知っている—そんな差が生まれてくるかもしれません。それは競合他社が複製しにくい差別化になっていく気がしています。

一方で、ここにも「月末まとめ入力問題」が忍び込んできます。月末集中入力の営業文化では、Frontier Tuningが学習できるトレースの質が根本的に低下してしまいます。Frontier TuningがSales領域で活きるためには、CRM入力をリアルタイムで行う組織文化の変革がセットで必要になってくるんじゃないかと思っています。テクノロジーの問題というより、行動変容の問題—Microsoft Automotive Summitで津坂社長が示した『AIファーストで業務プロセスを刷新する』という処方箋が、まさにここにも当てはまってきます。

D365 Customer Service / Contact Center：MAI-Transcribe-1.5との組み合わせが面白い

Customer Service領域は、Frontier Tuningと今回のMAIモデル群が最も直接的に組み合わさってくる領域かもしれません。コールセンターでのエージェント判断トレース——「何を調べ、どう回答し、どのタイミングでエスカレーションしたか」—が学習素材になっていきます。そこにMAI-Transcribe-1.5が加わると、音声→テキスト変換の精度が上がり、トレースの素材品質そのものが向上していきます。「VIN番号」「ODO」「ADAS」といった業界固有語が正確に書き起こされたトレースと、認識精度の低いトレースとでは、学習素材としての価値がかなり変わってきそうです。

さらに、Agentic Engineering連載第5回「エージェントを信頼できるか—ログ・監査・コンプライアンスの設計」で書いた話がここに接続してきます。Customer ServiceにおけるエージェントのログはFrontier Tuningの素材であると同時に、コンプライアンス監査の証跡でもある。「なぜそのエージェントがそう回答したか」を追跡できる設計が、Frontier Tuning時代には二重の意味で大切になってくるんじゃないかと思っています。

D365 Customer Insights（CDP）：名寄せトレースが、名寄せモデルを育てていくかもしれない

正直、この接続に気づいたとき、少し鳥肌が立ちました。マスターデータ記事で「Customer Insightsにおける名寄せ・マージ運用」を詳しく書きました。マッチングルールの設定、マージポリシー、AIによる重複検出—そして「これは同一人物、これは別人」という人間の判断の積み重ね。

この判断トレースそのものが、Frontier Tuningの素材になっていく可能性があります。「このケースで同一と判定した理由」「このケースは確率が高かったが別人とした理由」—そういうドメイン固有の名寄せ判断が積み上がることで、自社のビジネスエコシステムに最適化された名寄せモデルが育っていくかもしれない。

グローバル展開においては、言語・文字コード・姓名構造の壁があります。でも自社の海外現地法人が積み上げてきた「アラビア語×ローマ字翻字での同一人物判定トレース」があれば、Frontier Tuningはその文脈を学習していける可能性があります。汎用LLMではカバーしきれない、自社固有のグローバルマスターデータ文脈をモデルが内包していく—これはマスターデータ管理の「ラスボス」に対する、新しいアプローチのひとつになるかもしれません。

CRM × ERP全体：Lead to Cashトレースの完全統合という未来

Agentic Engineering連載第6回で「CRMとERPをまたぐエージェント—統合設計の全体像」を書きました。Lead to Cashフロー全体をエージェントが横断するアーキテクチャです。このフロー全体のトレースが積み上がっていくと、「見込み客の段階でどんな行動をした顧客が、最終的にどんな取引になったか」という一気通貫の文脈をモデルが学習できる可能性があります。CRM側だけのトレース、ERP側だけのトレースではなく、商談から請求までを貫く業務の流れ全体が素材になっていく。これはDataverse SoRハブ設計が整っていると、より活きてくる話です。CRM・ERP・DMSがバラバラのまま「繋がっているつもり」の状態では、Lead to Cashのトレースが途中で断絶してしまいます。ノックフォワードしないデータ連携設計—あれはFrontier Tuningのための地ならしにもなっていくんじゃないか、と今改めて感じています。

今から考えてみてもいいかもしれないこと

断言はできませんが、こういう方向で考えてみると面白いんじゃないかと思っていることを3点、整理しておきます。

1．業務トレースの「設計品質」が、じわじわ差になっていくかもしれない

Frontier Tuningの品質は業務フロー設計の品質に依存してきます。Directions ASIAのセッションで話した4象限で言えば、左下（メカニック）的な「仕様通りに実装する」仕事は、より代替されていく可能性があります。構造化された判断フローを設計し、エージェントに意味のあるトレースを積ませる—そういうガイド的な視点を持った実装者の関わり方が、Frontier Tuning時代には面白くなっていくんじゃないかと思っています。

2.「業種特化モデル」という未来が、少し近づいてきたかもしれない

Mayo Clinicとの医療特化モデル共同開発が発表されました。完成後はMicrosoft Foundry経由で他の医療機関へ提供予定とのこと。この構造を自動車・製造・金融に置き換えてみると、D365 for Field Service、D365 Finance、D365 Supply Chain Management—それぞれの業種向けFrontier Tuning済みモデルが展開されていく世界が、少し現実的に見えてきます。そうなったとき、自社の業務トレースをどう積み上げてきたかが、問われるかもしれません。

3.Human-in-the-Loopの設計は、むしろ重要度が上がっていくかもしれない

Agentic Engineering連載第2回で「どこに人間を置くか」を丁寧に設計することが安全思想の本質だと書きました。Frontier Tuningによってモデルが賢くなればなるほど、この設計判断はむしろ重要になっていく気がしています。自律度が上がるほど、「どこで人間が介在するか」の設計が問われる—逆説的ですが、これがAgentic Engineeringの本質であり、Frontier Tuning時代においても変わらないんじゃないかと思っています。最後にハンドルを握るのは、やっぱり人間です。

まとめ｜MAIはD365の「下回り」になっていくのかもしれない

今回の7モデル発表、表面上はモデルスペックの話です。でも構造で見ると、MicrosoftがAIスタックを垂直統合している過程の一里塚として見えてきます。

「D365が動く」→「業務トレースが溜まる」→「Frontier TuningでMAIが育つ」→「D365がさらに賢くなる」

この循環が機能していくとしたら、その前提になるのがマスターデータの設計であり、ノックフォワードしない連携設計であり、リアルタイム入力の文化です。それらが揃ってきたとき、Frontier Tuningは「Garbage In, Garbage Out」を「Better In, Better Out」に変えていく可能性があります。

Directions ASIAのキーノートで「D365 = Agentic Foundation」と宣言された瞬間から、こういう未来が少しずつ見えていました。その絵が、今回の発表で一段と具体的になってきた気がしています。

名寄せは組み直し続けるもの。スクラムは崩れても組み直せる。モデルも、育て続けるものです。

OpenAIとのパートナーシップは当然続くとして、Microsoftが内製モデルで「自走できる体制」を着々と整えているという事実は、D365の長期的な方向性を考える上で頭の片隅に置いておいて損はないかもしれません。ちょっと面白い未来になるかもしれない。そんな期待を持たせるMicrosoft Buildだったように思います。

それでは、今日のところはこのくらいで。Let’s Enjoy our DX365LIFE！