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

皆さん、いかがお過ごしでしょうか？

僕は、久しぶりに発熱して、数日間しっかりと死んでいました。

体調不良を理由にお仕事をお休みできない、残念な昭和人のようです。

職務を全うしないといけませんからね。

若い頃は、

「大人は惰性で仕事をしているものだ。」

と勝手に思っていました。

ところが、自分が歳を重ねていくうちに、少し考え方が変わってきました。

「僕に何を期待して、このボール（タスク）を、仲間たちは渡してくれたのだろうか？」

「会社はいくら投資して、このボール（タスク）が僕の手元にあるのだろうか？」

そんなことを、ふと考えてしまいます。やっぱり、歳は取りたくないですね（苦笑）

よく分かりませんが、今回の体調不良は花粉が起因しているような気がして、

先ほど、加湿機能付き空気清浄機をポチリました。

結構な出費ですが、仕方ないですね…

さて、今日は冒頭に、3 つのお知らせをさせてください！

【お知らせ1】DX365LIFEのSpotifyポッドキャストがスタートしました！

本題に入る前に、読者の皆様に嬉しい？お知らせです。

「DX365LIFE」が音声でもお楽しみいただけるようになりました！

―なりました！―と言っていますが、実は10個のエピソードを公開しています。

4月5日が誕生日だったのですが、残念なことに予定も何もなくて、だったら自分自身でお祝いしようと思って、Spotifyはじめちゃいましたw

このBlogを書き終わる頃には、11個目として1つ追加されていることになるでしょう。

Spotifyで配信中のポッドキャスト版「DX365LIFE」は、Dynamics 365（CRM/ERP）やPower Platformなどの製品、オートモティブ業界のトピック、

そして、AIと人間の関係をテーマに、現場で“実際に起きていること”を言葉にして残していく番組です。

このブログをベースに、AIが要約した音声コンテンツで、そのままお届けしています。

いろいろなAIツールを使ってテストしている段階なのですが、

AIを使うと、「えっ？そーまとめちゃうの？」というメリットとデメリットがありますね。まぁ、AIですから、当たり前ですけどね。

「いやぁ、そうじゃないよぉ。」とネガティブに感じる時、「そんな具体例を持ち出すんだ。斬新！」と、ポジティブに感じる時があります。

どうしても納得いかない内容に、AIがつくりあげてしまった時は、音声データを再作成していますが、

AI時代に生きているので、ある程度妥協し、スピード感を優先しています。

気になる方は、Spotifyからリンクをたどって、このBlogまでお戻りいただけますと嬉しいです。

いずれにしても、単なる成功事例や新機能紹介にとどまらず、プロジェクトの裏側で交わされた会話、迷い、そして責任を引き受ける瞬間に焦点を当てているのが特徴です。

Dynamics 365の根底にある設計思想を解説するエピソードや、現場の葛藤をフィクションで描いた「ある製造業の物語」など、

プロジェクトに関わるすべての方に役立つコンテンツを配信中です。

これからプロジェクトを始める方の予習にも、渦中にいる方の伴走にもなる番組ですので、ぜひSpotifyでフォローして、移動時間などにお聴きください！

【お知らせ2】Power Apps Weekly Newsにゲスト出演しました！

限られた時間ではありましたが、以下のような内容について、4月10日（金）に、お話させていただきました。

YouTubeにも映像が残っているので、ご興味がある方はご覧くださいませ！

山田晃央（Yamada Teruchika）氏と、表田陽（Hyoda Akira）氏に、大変お世話になりました。

【お知らせ3】Power BI Weekly Newsにゲスト出演します！

3月末に描いた架空のストーリー【ある製造業の物語】でも大活躍してくれたPower BIを、多くの皆さまに使ってほしいと思っています。

先日、Power BI王子こと、清水優吾氏に相談して、4月26日夜にお話をさせていただくお時間をいただきましたので、

「何故室長がこのストーリーを描いたのか？」も含めて解説させていただきたいと思います。

Power BI Weekly Newsに出るのは、1年ぶりかな？

私の敬愛する知人・友人がかなり出てきます。勿論、清水さんは、物語の中で、Power BI王子らしい仕事をしてもらいました（笑）

せっかくのお時間なので、“業務システム構築あるある”なネタや、このストーリーを通じて、登場人物がどのように成長していくのか？

各自の行動や発言を見つめながら、【ある製造業の物語】を、解説していきたいと思いますので、是非ご期待くださいませ！

ということで、そろそろ、本編に入っていこうと思います。

何故、このネタを書こうかと思ったかというと、3月にあるコンサルティングファームの方、そして以前私がプロジェクトをご一緒した方から、

最近の新しい内容を含めたDynamics 365 Business Centralのアーキテクト資料が欲しいという声が立て続けにあったんですよね。

4月の頭に海外の数名のMicrosoft MVPと話す機会があり、“日本人が必要な情報にたどり着けていないなら、それは室長が悪い”という話になったので、

「じゃぁ、やってやろうじゃないか！」ということで….以下、海外のMVPの知人たちから教えてもらった内容も含め、纏めておきます。

AIがPoCから「現場の同僚」になる時代

Business Central 2026 wave 1が示す「設計」と「責任」の変化

さて、ここからいよいよ本題です。

AIは本当に「現場の同僚」になれるのか？

2026年を迎え、Dynamics 365 Business Central (以下 BC) の開発や運用環境は、さらに強力に進化しています。

ただし今回の変化は、「新機能が増えた」という話だけではありません。

現場の肌感覚としては、前提そのものが静かに書き換わり始めています。

AIが PoC (概念実証) の「試せる便利ツール」から、本番環境で動く「プロダクションの同僚」へ移行し始めた。

この変化は、設計と運用の問いを確実に変えます。

どう作るか、の前に考えるべきことがあります。

どう壊れないように使うのか。

どう暴走させないのか。

誰が止めるのか。

そして、その責任はどこに置くのか。

今回のブログでは、現在のBC環境で特に注目すべき 3 つのトピックを扱います。

• 外部AIエージェントとの連携 (MCP)
• エンタープライズ規模でのCopilot運用 (負荷分散)
• ALからのネイティブSFTP対応 (v28)

そして記事の後半で、Business Central Launch Editionとして公開された 37 本のYouTubeセッションの中から、本記事のテーマに直結するものを厳選して紹介します。

1. 2026年はエージェントの年|Python 版プロキシによる外部 AI 連携

AIに「判断と実行」を任せるとき、どこまでを許し、どこからを人が持つべきか？

「2026 年はエージェントの年」という言葉が、流行語に聞こえるのも分かります。

けれど、BC 2026 wave 1の情報を追っていると、これは “気分” ではなく “設計の前提” が変わり始めたサインに見えます。

Microsoft LearnのUpdate 28.0の更新点にも、CopilotとAgentsの投資としてMCP強化が含まれています。

従来の Copilotは、文脈から情報を探して答える存在として理解されがちでした。

一方でエージェントは「答える」だけではなく、「ツールを選び、実行し、結果を見て、必要ならやり直す」存在です。

つまり、行動する。行動する以上、統制点と責任分担が設計の中心になります。

ここを誤解したままPoCを進めると、本番直前に同じ会話が起きます。

「AIが勝手に動いた」

「誰が止めるのか」

「責任はどこに置くのか」

この瞬間、議論は技術の話ではなく、運用と統制の話に変わります。

MCP (Model Context Protocol) は「接続」ではなく「許可と責任」の設計

外部のAIクライアントからBCに接続し、BCのAPIを “ツール” として扱うための枠組みが、BCのMCP Serverです。

Microsoft Learnの説明では、MCP Serverを構成するとAIクライアントが環境に接続でき、レコードの参照だけでなく、

構成と権限次第で更新・作成・削除に加え、伝票の計上やステータス変更といったレコードに紐づいた操作（bound actions）まで扱える、とされています。

ここで重要なのは、既定のふるまいが “何でもできる” ではないことです。

Microsoft Learnでは、既定では read-onlyで、作成 / 更新 / 削除などは構成で明示的に許可する必要がある、と説明されています。

つまり、MCPは「便利な接続手段」ではなく、「何を許すか」を設計として固定し、責任の境界を明確化するための枠組みに近い。

Python版プロキシが効くのは「技術」より「試行速度」

MCPの話を現場に落とすとき、意外と詰まるのが “つなぐ側” の現実です。

初期に公開されたBcMCPProxyはMicrosoftのサンプルとしてGitHubにあり、実験用途である旨も明記されています。

そしてPython版のbc-mcp-proxyはPyPI（パイピーアイ｜Python Package Index）に公開されており、こちらも実験用途である旨を含めて、

CursorやVS Code、Claude DesktopなどMCP対応クライアントとBC MCP ServerをつなぐためのPython実装だと説明されています。

現場的にここが効く理由はシンプルです。

PoCの初期は「環境差の調整」で時間が溶けやすい。

その間に、議論の焦点が「設計」ではなく「手元で動かすための調整」へ逸れてしまう。

この逸れ方をすると、プロジェクトは一気に疲れます。

だから “つなぐ” の敷居を下げて、試行錯誤の速度を落とさないこと自体が、導入初期の品質になります。

2. エンタープライズ環境でのCopilot運用|Azure API Managementによる負荷分散

PoCでは動いたAIは、本番の同時利用に本当に耐えられるのか？

BC内でAI機能を作り込むこと自体は、情報が整理されてきました。

Microsoft Learnにも、ALでCopilot Capabilityを追加するためのガイドが用意されています。

ただし、ここでの落とし穴は「作れること」と「使い続けられること」が別物だという点です。

本番展開でユーザーが増えた瞬間に出るのが、推論基盤側の制限です。

レート制限、クオータ、429、部分的な失敗。現場の評価は容赦がありません。

「AIは不安定だよね」

この一言が出た瞬間、PoCの成果は “なかったこと” になります。

APIMで「入口を 1 つ」にするのは、運用と信頼のため

この問題に対して現実的な解として語られるのが、Azure API Management (APIM) を “入口” に置く構成です。

APIMを使って複数のAzure OpenAIを負荷分散する構成例は、実装サンプルとしてGitHubにも存在し、複数インスタンスを単一のAPIMエンドポイントの背後に置くことで、

アプリ側の複雑性を減らしつつリトライやルーティングをポリシーで扱える、と説明されています。

また、APIMのポリシーで負荷分散構成を作る具体例も公開されています。

ここで大事なのは、負荷分散が “性能の話” だけではないことです。

現場にとっての負荷分散は、「AIが止まらない」という信頼の設計です。

そして信頼は、使い続けてもらうための最重要要件です。

3. ALからのネイティブSFTP通信|v28.0の新機能とセキュリティ

「つながる」ことと「安全に運用できる」ことは、本当に同じだろうか？

最後は、地味ですが現場では確実に効くアップデートです。

BCの周辺連携で “ファイル連携” は消えません。

そして現場が欲しいのは「動いた」ではなく、「安全に運用できる」ことです。

Business Central 2026 release wave 1 (v28.0) では、System ApplicationにSFTP Clientが追加され、ALから直接SFTPを扱うためのAPIが提供されると紹介されています。

さらに、BCAppsのREADMEでもSFTP ClientがSSH.NETを用いてSFTPサーバーに接続することが明記されています。

これまで外部システムとのファイル連携にはAzure Functions、Logic Appsなどを介する工夫が必要なケースもありましたが、

AL言語で直接SFTPを扱えるようになることで、開発コストの削減と安定性の向上が期待できます♪（ちなみに室長はAzureも好きですw）

セキュリティの核心はfingerprintの事前検証

SFTPは暗号化されている。だから安全。

現場では、この誤解が事故を呼びます。

重要なのは「正しい相手と通信している」ことを確認すること。つまりfingerprintの検証です。

この点は、SFTPをALから使う “native way” の解説でも強調されています。

実装より運用: “接続の後始末” までが仕様

SFTP Clientは、接続して終わりではありません。

通信がステートフルである以上、運用では “接続のライフサイクル” がそのまま障害率に反映されます。

提供されるAPIと注意点についても、解説記事やREADMEが公開されています。

全体像のおさらい:3つの話は一本の線でつながっている

これらは別々の機能なのか？ それとも一つの「設計セット」なのか？

ここまで、エージェント連携、負荷分散、SFTPという3つの話をしました。

一見バラバラに見えますが、実は一本の線でつながっています。

それは「AIが業務に入ってくる」という現実に対して、BCがどう進化しているか、という線です。

• 外部エージェントとつながる (MCP)
• 内部Copilotを本番で回す (運用設計)
• 周辺連携を標準で安全に扱う (SFTP)

どれも “本番の業務” の話です。だから2026 Wave 1は現場にとって意味があります。

関連YouTubeセッションのご紹介 | 全37セッションから厳選

以下、Business Central Launch Editionとして公開された 37 本の公式セッションの中から、

本記事で扱った「エージェント」「本番運用」「開発者視点」に直結するものだけを抜粋しています。

1) What’s new: Enhanced MCP Server

第1のトピック「AIエージェント連携」の中核となるMCP Serverの強化点に直結します。

Update 28.0の “Copilot and Agents” の更新でもMCP強化が触れられており、位置づけを掴むのに有効です。

2) What’s new: Admin Center MCP Server

MCPを “運用” で扱う視点に寄せるなら、Admin Center側の話は外せません。設計だけでなく、管理・統制の観点で見る導線になります。

3) What’s new: Business Central Integration with Microsoft Copilot Studio

外部エージェント連携の “標準ルート” を把握する上で有効です。

MCPをどう業務側へ落としていくかの勘所が掴めます。

4) What’s new: AI development toolkit

第 2 のトピックで触れた “BC 内でAIを作る” という話に直結します。

実装と運用のギャップを埋める材料として押さえておく価値があります。

5) What’s new: AL Language

第 3のトピック「ネイティブ SFTP」を含むAL側の進化をまとめて俯瞰する入口として最適です。

YouTube の37本セッション一覧自体は、プレイリストとして確認できます。また、37本の内訳やタイムコード付きの整理も公開されています。

マイクロソフトのBC開発チームは凄いですよ。一般公開に合わせて、これらを公開しますからね。

熱い、熱いですよ。ハートが籠ってる。だからマーケットが広がるし、パートナーも頑張れるんですよ。敬礼です！

まとめ|最新のBCは “便利” より “運用可能性” が価値になる

今回の要点を最後にまとめます。

• Python版プロキシを含む周辺整備により、外部 AI エージェント連携が現実味を帯びてきた。

MCP Serverは接続ではなく “許可範囲の設計” を前に出す枠組みであり、既定がread-onlyである点も含めて、統制の発想が中心に来る。

• 本番でCopilotを回すなら、負荷分散と冗長性は前提になり、APIMのように入口で制御する発想が現場の信頼を守る。
• ネイティブSFTPは周辺連携の標準化を前に進めるが、fingerprint検証など “安全に運用できる設計要件” を外すと逆に危険になる。

つまり、BC 2026 wave 1は「AIを足した」ではなく、「AIが業務に入ってくる前提で、運用の論点を揃えに来た」リリースに見えますね。

現場メモ｜AIとBusiness Centralを本番（現場）で使うということ

PoC は「できた」で評価されるが、本番は「続いた」で評価される。

AIほど、この差が残酷に出る。設計の主語は、最初から運用に寄せた方がいい。

AIエージェントは便利なツールではなく「業務参加者」になる。

参加者なら、任せる範囲と止める仕組みが必要になる。

MCPは接続の話に見えるが、実際は統制の話。ここを曖昧にすると、後で必ず燃える。

AIは賢くなるほど、止まったときの失望が大きい。

可用性は性能要件ではなく「信頼要件」。

Azure API Managementは技術要素というより、現場の信用を守る装置だと考えた方が分かりやすい。

ファイル連携は簡単に見えて、障害はだいたいここから始まる。

標準化は嬉しいが、油断すると危ない。

SFTPは特に「相手確認」を外すと、一気に事故になる。

AI導入で一番の敵は「局所最適の成功体験」。

部分で勝って全体で壊れる。

最初に全体像を一枚にして合意すると、議論は驚くほど前に進む。

AIは「導入した」では評価されない。

「事故らず、現場が使い続けた」で初めて勝ちになる。

最後に残るのは、技術ではなく、設計と責任の置き方。

AI時代でも、それだけは変わらない。

この備忘録が、何処かの、誰かの、役に立てば幸いです。

あ、Spotify側も出来上がったので、置いておきますね♪

以上、室長でした。