※この記事は「エムティーアイ Blog Summer 2026」の 6/3(水) 分の記事です。
スマートコンテンツ事業部で保守・開発を行っている 兒玉 です。
今回は、かつて自分が関わっていた社内チャットアプリの話を供養しつつ、Microsoft Foundry を使うと当時のコードがどれだけ消えるかを Before/After で紹介します。
はじめに（AI 活用について） 本記事の構成・初稿の作成には Claude Code を一部利用しています。最終的な文章・公開判断は執筆者が行っています。記事のテーマと相性が良いため、こうした取り組みの実例として活用方法も含めて紹介します。
はじめに
ChatGPT が世間に広まり始めた頃、チームで「社内にも AI を使える環境を作ろう」という話になりました。エンジニアは触れ始めていたものの、企画や非エンジニアの人たちにも AI を身近に感じてもらいたい。そのための入口として、シンプルな社内チャットアプリを作りはじめたのが発端です。当時のモデルは GPT-3 系、サービスは Azure AI Studio（現 Microsoft Foundry の前身）でした。
作っていくうちに、やりたいことがどんどん増えました。会話の流れを前のターンから引き継がせたい、モデルを切り替えられるようにしたい、社内のドキュメントを参照させたい（RAG）、Web から情報を取ってきて回答に反映させたい……。これらを全部、1 から自前で実装していく必要がありました。Claude Code のような開発支援ツールもない時代で、「AI にコードを書かせる」こと自体がまだぎこちなかった頃の話です。
そのアプリは今、役目を終えてサービスを停止しています。
最近、新規事業の PoC で久しぶりに Microsoft Foundry（Azure AI Studio の後継）を触ったときに、ちょっと驚きました。会話履歴、認証、モデル切替、RAG のための接続。当時あんなに手を動かして実装したものが、軒並みプラットフォームの組み込み機能として提供されていました。
どれくらい変わったのか気になったので、当時の社内デモアプリを Microsoft Foundry + Python で作り直してみました。結果、マルチユーザー対応・会話履歴・モデル切替・人格切替まで含めて、UI を除いたバックエンドのコードが 1,085 行から 224 行まで減りました。約 8 割減です。
この記事では、当時と今を Before/After で比べながら「Microsoft Foundry が今どれだけ便利になったか」を紹介します。これから AI 機能を組み込もうとしている方や、過去に同じような実装と格闘した経験のある方に、何か伝わればと思っています。
昔と今、何が変わったか
まず全体を早見表で比べてみます。
Before/After 早見表
| 旧社内デモアプリ（自前で実装） | Microsoft Foundry（組み込み機能） | |
|---|---|---|
| 会話履歴 | localStorage / Blob Storage に自前永続化、データ整合性問題と戦う | conversations.create() 1 行 |
| 認証 | ユーザー認証は Entra ID。AI 呼び出しにはバックエンド API の API キーを別途管理 | DefaultAzureCredential() のみ（AI 呼び出しもキーレスに統一） |
| API プロキシ | Azure Functions で実装、ロール分岐ロジック | 不要（SDK が直接 Microsoft Foundry へ） |
| モデル切替 | Azure Functions 内で api_type 分岐、専用テーブル |
model="gpt-5.4-mini" の引数 1 つ |
| 監査ログ | Application Insights を自前で繋ぐ | Microsoft Foundry が組み込みで保持 |
| 本筋のコード行数 | 約 1,085 行（UI 除くバックエンド） | 約 224 行（同・作り直し実測） |
アーキテクチャの変遷
当時チームで議論しながら一つひとつ実装したものです。localStorage の整合性問題に向き合い、Blob Storage で端末間同期を実現し、Azure Functions でモデルを切り替えていた。それぞれの選択が、当時の制約の中では合理的でした。今でもそう思っています。
図: 旧構成。色がついている箱は、当時の要件を満たすために必要だった構成要素
Microsoft Foundry を使うと、これが次のようになります。
図: 新構成。旧構成で色がついていた箱の大部分が Microsoft Foundry の組み込み機能に統合された
コードで見ると、ここまで変わった
実際のコードで 4 つのテーマを比べます。
テーマ1：会話履歴の永続化
旧アプリで一番手がかかっていたのがここでした。localStorage と Blob Storage の二箇所に書いて、どちらかが失敗すると不整合が起きる。タイトル保存のタイミングを誤るとデータが飛ぶ。「また会話履歴バグか」というやりとりをした記憶が何度かあります。
図【Before】: 会話履歴の保存と送信。クライアントが「履歴を作る人」「送る人」「保存する人」を全部兼ねる
図【After】: 同じ機能が約 8 行に。整合性問題は構造上発生しなくなった
ただし、作り直してみて分かったことがひとつあります。Microsoft Foundry が保持してくれるのは「会話の中身（メッセージ本体）」で、「どのユーザーがどの会話を持っているか」の一覧だけはアプリ側で持つ必要がありました。Microsoft Foundry には特定ユーザーの全会話を一覧する API が無いためです。とはいえ、持つのは会話 ID とタイトルだけで、メッセージ本体は Microsoft Foundry にあります。旧アプリが全メッセージを Blob に書いていたのと比べると、保持するデータは桁違いに軽くなりました。
テーマ2：認証
ユーザーが誰かを識別する仕組みは、当時も今も Entra ID（Azure AD）です。違うのは AI を呼ぶ側で、旧アプリは AI を呼ぶバックエンド API への通信に API キーをヘッダで付ける必要があり、その鍵を .env で管理していました。Microsoft Foundry では DefaultAzureCredential() ひとつで済みます。
ここで「社内に展開したら、誰のトークンで AI を呼ぶの？」という疑問が出ると思います。実際に作り直したときに確認したのですが、DefaultAzureCredential() は実行環境を自動で判別してくれます。ローカルで開発しているときは az login した自分のトークン、サーバーにデプロイしたときはそのアプリに割り当てたマネージド ID を使う。つまり 40 人が使う本番アプリでも、AI を呼ぶのは利用者個人ではなく「アプリ自身」で、利用者一人ひとりがログインを意識する必要はありません。コードは DefaultAzureCredential() のまま、デプロイ先が変わるだけです。
図【Before】: AI 呼び出しに API キーが必要だった。当時広く使われた実装パターン
図【After】: AI 呼び出しもキーレス。ローカルは az login、本番はマネージド ID を自動で使い分ける
テーマ3：モデル切替
新しいモデルを試したいとき、旧アプリはクライアントと Azure Functions の両方を直す必要がありました。「どのモデルを呼ぶか」という情報をフロントから投げて、Azure Functions がそれを見て分岐する構造だったので、モデルが増えるたびに if 文と認証情報が増えていきました。
図【Before】: クライアント + Azure Functions の二箇所改修。新モデル追加のたびに分岐とキーが増える
図【After】: 切替は引数だけ。新モデルもポータルでデプロイすれば即使える
テーマ4：AI 人格管理
ユーザーごとの「AI キャラクター設定」を JSON で Blob に保存して、リクエストのたびに読み込んで system メッセージとして展開していました。端末をまたぐと設定が同期されなかったり、JSON の構造が変わると読み込みが壊れたりと、地味に大変だった部分です。
図【Before】: 人格を Blob に保存し、毎回読み込んで system メッセージに展開
図【After】: 人格は Microsoft Foundryの Agent として登録。クライアントは名前を渡すだけ
結局、何が消えたか
冒頭にも書きましたが、実際に作り直して行数を数えてみました。UI を除いたバックエンドのコードで、旧アプリが 約 1,085 行、Microsoft Foundry 版が 約 224 行（どちらもコメントを除いた実コード）。約 8 割減です。
特に効いたのが、会話履歴の永続化（旧 Conversation.ts 140 行）、AI 人格のロード（旧 AIPersonalityLoader.ts 303 行）、Blob 連携や認証トークン管理といった一連のコードで、これらは Microsoft Foundry が肩代わりしてくれるので丸ごと消えました。この部分だけ見れば 9 割以上が不要になっています。
数えながら、「あのとき自分たちはこれを全部実装していたのか」と少し呆然としました。。。
図: 自前実装の大半が Microsoft Foundry の組み込みに置き換わった。残ったのは UI・ビジネスロジックと、会話 ID の索引くらい
おわりに
当時一緒に作ったコードの 8 割が消えたと書きましたが、「要らなかった」という話ではないです。あの実装をやりきった経験があるから、Microsoft Foundry が何を肩代わりしているかが具体的に分かる。それは今の仕事にも生きています。
この記事が、これから AI 機能を組み込もうとしている方や、昔似たような実装と格闘した経験のある方の参考になれば幸いです。Microsoft Foundry はまだ仕様が動いていますし、半年後にこのコードが動かなくなる可能性もゼロじゃないですが、「自前で書く前に一度確認する」くせは付いたので、それが今回の収穫です。
本記事で紹介している Conversations API・Agent API 等は 2026 年 6 月時点の仕様を含みます。最新情報は Microsoft Foundry 公式ドキュメントをご参照ください。
