これからのDynamics 365エンジニアに何が求められるか｜最終回
こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。
皆さん、いかがお過ごしでしょうか？ このシリーズもいよいよ最終回になりました。
振り返ると、このシリーズは複数の「種」から生まれています。
まず3月にDynamics 365 2026 wave 1のアップデートを一通り追いかけ終わったとき、「今回のwaveは単なる機能アップデートではなく、構造的な変化だ」という感覚がありました。その感覚を言語化しようとして書いたのが、FY25年度の振り返りの後半にある【ある製造業の物語】という架空のストーリーと、ミュージシャン（MISIA・oasis・Bryan Adams）のメタファーを用いたAI時代のIT生存戦略でした。「エージェントが動く世界では、ビジネスアプリケーションの役割が変わる」——その直感をBlogに残してきました。
その直後に参加したMicrosoft AI Tour TokyoとMicrosoft AI Tour for Partnersでは、Agentic AIというキーワードが至るところに登場しました。「これは本物の波だ」という確信が深まりました。
4月にはPower Apps Weekly NewsとPower BI Weekly Newsにゲスト出演し、実装者にとって何が重要かを改めて整理する機会をいただきました。
そして5月のDirections ASIA 2026です。3日間のキーノートを見ながら、私の頭の中では「これはシリーズとして書かなければ伝わらない」という思いがどんどん強くなっていきました。3日間の基調講演の詳細はこちらの総合レポートにまとめてあります。自分が担当したセッションの準備をしながら考えていたことも含め、3日間で頭の中に溜まっていたものを、このシリーズという形で一気に出しました。
誤字脱字チェックとHTML化にツールのサポートを借りながら、でも内容はすべて自分の言葉で。そういう形で書き切ることができました。読んでくださった皆さんに、心から感謝します。
では最終回、行きましょう。
Series #07 — Agentic Engineering × Dynamics 365
これからのDynamics 365エンジニアに何が求められるか
Agentic Engineering時代の生存戦略——「統率する人間」であり続けるために
第7回（最終回）
Dynamics 365
エンジニア
生存戦略
ここで重要なのは、スキルが増えるかどうかではありません。
役割そのものが変わるという点です。
従来は「どのように作るか」を考えることがエンジニアの中心的な役割でした。しかしこれからは、「どこまでをエージェントに任せるか」を設計し、その結果に責任を持つことが求められます。
すべてを自分で実装しようとする人と、全体を構造として捉えて統率する人。この差は、これからの数年で決定的なものになります。
第1回でエージェントの定義と自律性の段階を、第2回でHuman-in-the-Loopの設計原則を、第3回でデータモデルを、第4回でCopilot Studioの実装パターンを、第5回で監査・コンプライアンスの設計を、そして第6回でDynamics 365のデザインパターンと統合設計の全体像を整理してきました。このシリーズを通じて一貫して問い続けてきたことがあります。「エージェントが自律的に動く世界で、人間は何をすべきか」——これです。エージェントはコードを書きます。エージェントは発注します。エージェントはケースに回答します。エージェントはコンプライアンス違反を検知します。では人間は何をするのか。その問いへの答えが、このシリーズの締めくくりとなるテーマです。このテーマについて書くのは、今回が初めてです。Agentic Engineeringが現実のものになった今だからこそ、初めて正面から書けると思いました。また、書くからには、ITmediaでの過去の連載を超える内容にしないといけないとも感じていました。
What changes
Agentic Engineeringが変えるエンジニアの仕事
このシリーズを通じて繰り返し出てきた言葉があります。「プロセスを作るから、エージェントを統率するへ」——これが、Agentic Engineeringがエンジニアの仕事に与える最も根本的な変化です。
従来のDynamics 365エンジニアの仕事を思い浮かべてください。Power Automateでフローを組む。プラグインを書く。フォームをカスタマイズする。要件定義書をもとに業務プロセスをシステムに落とし込む。これらはすべて「人間が設計したプロセスをシステムとして実装する」仕事でした。
エージェント型AIが登場すると、この構造が変わります。プロセスはエージェントが組み立てます。エンジニアはプロセスを実装するのではなく、エージェントが正しく動くための環境を設計します。ゴールを定義し、ガードレールを設け、閾値を決め、エスカレーションの条件を設計し、判断ログを監視してチューニングする——これが新しい仕事の中心です。
このシリーズではスポーツの例えを多用してきました。野球のキャッチャー・サッカーのトップ下・ラグビーのスタンドオフ・アメフトのレシーバー——「球を受け取って判断する役割」としてのエンジニアのイメージです。別のアングルから同じことを考えたいという方には、MISIA・oasis・Bryan Adamsのメタファーで紐解くAI時代のIT生存戦略というスライドも参考にしてみてください。Power BI Weekly Newsでのゲスト出演時に使ったものですが、今回のシリーズと根底にある問いは同じです。「AI時代に、人間は何で価値を出すのか」——アーティストのメタファーはその問いへの、もうひとつの答え方です。
しかしここで大切なことを言っておきたいです。これは「コードを書かなくてよくなる」という話ではありません。むしろ逆です。エージェントが複雑なことをできるようになればなるほど、「どこに境界線を引くか」「何を人間が担うか」という設計判断の難しさが増します。浅い理解では設計できない。業務の本質を深く理解し、リスクを正確に評価し、組織の文化まで踏まえて判断できる人間が求められる時代になります。
Three rules
求められる3つのルール——AI時代にアップデートするエンジニア像
「これからのDynamics 365エンジニアに何が求められるか」という問いへの答えを、私はアーティストのメタファーで整理しました。MISIAとoasisとBryan Adams——三者三様のスタイルは、AI時代を生き抜くエンジニアの3つの姿勢と重なります。そして3つが揃ったとき、「AIに仕事を奪われるのではなく、AIを使いこなす組織になるためのOS」が完成します。
Data Ready——変えないことを決める
oasisはルールを作りません。グローバルスタンダードなロックのど真ん中を、圧倒的なクオリティで鳴らします。AIエージェントも同じです。特殊ルール・魔改造・独自実装は、エージェントを迷わせます。Dynamics 365の標準機能・標準データモデル・標準プロセスを採用することが、エージェントにとって「最短の指示書」になります。「うちは独自の業務があるから標準化できない」という声をよく聞きます。しかしAgentic Engineeringの世界では、標準化は妥協ではありません。グローバル標準を守り「変えないこと（やらないこと）を決める」という境界線を引くことが、エンジニアの重要な仕事のひとつになります。Data Readyな組織だけが、エージェントに正確な球を出せます。
Agile Ready——揺れを前提に設計する
MISIAは何十年もトップアーティストであり続けています。時代が変わっても、音楽のスタイルが変わっても、MISIAはMISIAであり続ける。その秘密は「コアを守りながら周辺を柔軟に変えられる」構造にあります。AIモデルは明日アップデートされます。Wave Releaseごとに新しい機能が追加されます。環境・要件の変化を抑え込もうとすると、システムは壊れます。固めすぎたシステムではなく、揺れを前提にした疎結合な設計——常に新しい知能を差し替えられる「遊び」を意図的に組み込むことが、Agile Readyな設計の本質です。これが組織の生命線になります。
Mind Ready——ハンドルを離さない
Bryan Adamsは45年以上、ブレずに自分の音楽を鳴らし続けています。流行に媚びない。しかし時代を超えて届く。その根底にあるのは「自分が信じるものを信じ続ける覚悟」です。AIは「確率」で動きます。100%の正解を出すことはありません。AIが80%の確信で提案するとき、残りの20%を人間が判断しなければなりません。「AIがそう言ったから」という理由で判断を放棄した瞬間、人間の価値は消えます。不完全な状況でも判断を止めず、責任を引き受け続けるレジリエンス——これがBryan Adamsルールです。Mind Readyなエンジニアがいる組織だけが、エージェントを本当の意味で「使いこなす」ことができます。
Message
Dynamics 365エンジニアへのメッセージ
このシリーズの最後に、Dynamics 365に関わるすべてのエンジニアに伝えたいことがあります。
Agentic Engineeringの波は、確かに来ています。エージェントはコードを書き、発注し、ケースに回答し、コンプライアンス違反を検知します。「自分の仕事がなくなるのではないか」という不安を感じている方もいるかもしれません。
しかし私はそう思いません。
Dynamics 365のエンジニアは、単なる「技術者」ではありません。顧客の業務を深く理解し、どのシステムで何を実現するかを設計し、データの正確性を保ち、組織の変革を技術で支える存在です。その価値は、AIが登場しても消えません。むしろ、より鮮明になります。
エージェントが自律的に動けば動くほど、「何を自律させるか」を判断する人間の重要性が増します。エージェントが大量のデータを処理できれば処理できるほど、「何がデータの正か」を定義する人間の重要性が増します。エージェントが複雑な処理を実行できれば実行できるほど、「どこに人間を置くか」を設計する人間の重要性が増します。
Oasisルールで標準化の境界線を引き、MISIAルールで変化に耐える疎結合な設計をし、Bryan Adamsルールでハンドルを離さない覚悟を持つ——この3つが揃ったエンジニアが、これからの時代に最も必要とされます。
スタンドオフ（フライハーフ）がどれだけ優れていても、正確な球を出せるスクラムハーフがいなければゲームは動きません。AIエージェントがどれだけ賢くなっても、正確なデータをリアルタイムに提供できるシステムと、それを設計できるエンジニアがいなければ、エージェントはノールックパスを出せません。皆さんの仕事は、これからも続きます。形は変わっても、本質は変わりません。
Action plan
Directions ASIA 2026 Day 2が示したもの——Agentic Engineeringを自分たちのものにする
このシリーズを書くきっかけになった場面を、もう少し具体的にお伝えしたいと思います。
Directions ASIA 2026の2日目（5月14日）のキーノートは、「Agentic Engineeringの実践」をテーマに構成されていました。3日間の詳細は基調講演 総合レポートにまとめてあります。
2日目で特に印象的だったのは3つのセッションです。
3日間で頭の中に積み上がったものを一気に言語化したのが、このシリーズです。
しかし本当に大事なのはここから先です。キーノートを見て「うっひょーっ、すごいな」で終わらせてはいけません。「これを自分たちのものにするにはどうするか」——これが問いです。
Directions ASIA 2026の私のセッションに参加したインドのチームは「うちのチームでワークショップに使わせてもらうね」と言ってくれました。オーストラリアの方は「絶対これだ」、ドイツの方は「別イベントのコンテンツに使いたい」と言ってくれました。自分が知識を得ることと、それを組織に浸透させることは全く別の仕事です。
アクションプラン——今すぐできる3つのこと
自分のアーキタイプを知る
Directions ASIA 2026で私が発表したセッションでは、システム開発に関わる人間を4つのアーキタイプ（メカニック・テラピスト・アーキテクト・ガイド）に分類しています。縦軸が「システム構築→人間関係構築」、横軸が「問題解決→意味を創る」という2軸で整理したとき、左下（システム構築×問題解決）はAIに置き換えられる可能性が最も高い領域です。あなたは今どこにいますか。そして5年後、どこにいたいですか。
3つのルールで自分の組織を診断する
OasisルールのData Ready・MISIAルールのAgile Ready・Bryan AdamsルールのMind Ready——この3つの視点で、今の自分の組織を正直に評価してみてください。
チームでワークショップをやってみる
「知る」だけでは変わりません。チームで話すことで初めて変わります。そのための素材をすべて公開しています。
Summary
まとめ
このシリーズも、これで終わりです。
プロローグから第7回まで、「Agentic Engineering × Dynamics 365」というテーマを8回にわたって書き続けてきました。3月のwave 1を追いかけながら感じた「これは構造的な変化だ」という直感から始まり、Microsoft AI Tour・Power BI Weekly News・Directions ASIA 2026の3日間のキーノートを経て、この数ヶ月間ずっと頭の中にあり続けたもの・メモしていたものを、このシリーズという形で一気に言語化しました。
このシリーズの構成
Agentic Engineeringとは何か——「作る対象」から「統率する存在」へ
どこに人間を置くか——Human-in-the-Loopの設計原則
エージェントはデータをどう使うか——CRMとERPのデータモデル
エージェントを組み立てる——Copilot Studioで何ができて何ができないか
エージェントを信頼できるか——ログ・監査・コンプライアンスの設計
これからのDynamics 365エンジニアに何が求められるか ← 本記事
「AIに仕事を奪われるのではないか」という不安は、正直だと思います。しかしその不安は、変化の入口でもあります。ハンドルを離さない覚悟を持ち続けるBryan Adamsのように、変化を恐れないMISIAのように、そしてプライドという境界線に拘るoasisのように、不完全なAIと向き合いながら、最後の一線で判断し続けるエンジニアであってほしいと思います。Dynamics 365は、そのエンジニアの「球出しの基盤」として、これからも進化し続けていくことでしょう。私も頑張ります”(-“”-)”
以上、室長でした。
- dx365jp
24年ほど、Microsoft Dynamics ERP（NAV/AX)＋CRMの導入コンサルティングに従事し、日本を含む34か国において導入コンサルティングを経験してきました。グローバル環境における“プロジェクト”と“マーケティング”を生業としております。
最近は、【CRM/MKTG（攻めのDX）⇔ ERP（守りのDX）】＋【ローコード】というDX365な活動に奮闘中です。Microsoft Dynamics 365 ビジネスで地球を90周中です。＃DX365 #DynamicsIoT
Microsoftの運営する外部技術者グローバル組織「Microsoft MVP（*日本165名/世界3023名）・ Microsoftのトラスティッドアドバイザーである「Microsoft Regional Director （*日本4名/世界189名）」として、複数のITコミュニティーにて活動中。（*2022/07/06時点）
プロフィールはこちら→bit.ly/Dynamics365JP
- 監査対応はなくなる？｜取引と責任を繋ぐAIエージェントの世界 2026年6月14日
- 請求も、発注も、提案も消えない、それでも“仕事をするのは人ではなくなる？” ｜ Dynamics 365が変える企業間取引の新しい当たり前 2026年6月13日
- AIはどこまで任せ、どこで止めるのか？｜Business Centralに実装された“境界設計”の正体 2026年6月10日
- Microsoft自社開発MAI、7モデル一挙発表—「D365（CRM/ERP）× Frontier Tuning」が描く、ちょっと面白い未来 2026年6月8日
- Microsoft Build 2026｜Dynamics 365 実装者・アーキテクトが押さえるべき変化 2026年6月6日