マイクロソフトが.NETのメモリダンプ自動化やAIエージェントの「永続メモリ」機能を発表

何が発表されたのか

マイクロソフトは、開発者向け情報番組「The Upload」において、ソフトウェア開発およびAIアプリケーション構築を支援する複数の技術アップデートを公開しました。今回の発表は、研究段階の基礎技術から、すでにプレビュー版や一般提供（GA）が開始されている実践的な開発パターンまで多岐にわたります。

具体的には、生産環境でのアプリケーション停止を防ぐための「C#によるクロスプラットフォームなメモリダンプ自動生成手法」、異種データベース間の移行を円滑にする「PostgreSQLからSQL Serverへの日時セマンティクス移行ガイド」、そして自律型AIエージェントのセキュリティとデータ永続性を担保する「Microsoft Foundryホスト型エージェントの隔離制御」および「LangChain向けAzure Blob Storage耐久性ワークスペース」の4点です。これらのアップデートは、開発者が直面する運用上の課題や、次世代AIアプリ開発におけるセキュリティ要件に直接応える内容となっています。

発表された機能・アップデートの全容

C#によるクロスプラットフォームなメモリダンプ自動生成手法

アプリケーションが生産環境でハングアップ（無応答状態）に陥った際、原因究明にはメモリダンプの解析が不可欠です。しかし、手動でのダンプ取得はタイミングが難しく、運用の大きな負担となっていました。マイクロソフトはこの課題に対し、スレッドプールの飽和（Thread Pool Saturation）を検知して自動的にプロセスダンプを出力する、C#のクロスプラットフォームな実装パターンを公開しました。

公開されたサンプルコードでは、「ThreadFlowWatcher」と呼ばれる監視用スレッドを常駐させます。このスレッドが、あらかじめ設定された閾値を超える処理遅延を検知すると、自動的にダンプ生成処理をトリガーします。プラットフォームごとの差異は抽象化されており、OSに応じて適切なAPIやユーティリティが呼び出される仕組みです。

Windows環境においては、dbghelp.dllに組み込まれているWindows APIであるMiniDumpWriteDumpをP/Invoke経由で呼び出します。これにより、インプロセスで詳細なミニダンプを直接生成することが可能です。一方、Linux環境においては、.NETランタイムに同梱されているシステムユーティリティであるcreatedumpを起動するプロセスを生成します。Linux特有のセキュリティ制約である「PTrace」の制限も考慮された設計となっており、管理者権限の有無やコンテナ環境の仕様に応じた適切な設定方法が提示されています。

この自動生成パターンを導入することで、開発者はプロセスが完全に停止する直前の、スレッドの状態、ハンドラ、読み込まれているモジュール、メモリ上のオブジェクトの実態を正確に記録できます。これにより、再現性の低いデッドロックやリソース枯渇問題の解決が容易になります。

PostgreSQLからSQL Serverへの移行における日時セマンティクスのマッピング

オンプレミスや他社クラウドからAzure（SQL Server / Azure SQL Database）へデータベースを移行する際、最も不具合が発生しやすい領域の一つが「日付と時間（Date & Time）」のデータ型変換です。マイクロソフトは、PostgreSQLからSQL Serverへの移行時における、データ型の厳密なマッピング指針と注意点を詳細にまとめました。

PostgreSQLの代表的な日時型であるtimestamp（タイムゾーンなし）とtimestamptz（タイムゾーンあり）は、SQL Serverの対応する型とセマンティクスが微妙に異なります。指針では、以下のマッピングを推奨しています。

• PostgreSQLのtimestamp：SQL Serverのdatetime2型へマッピングします。
• PostgreSQLのtimestamptz：SQL Serverのdatetimeoffset型へマッピングします。

特に注意が必要なのが、タイムゾーンの扱いとストレージサイズの違いです。PostgreSQLのtimestamptzは、内部的には値をUTC（協定世界時）に変換して保存しますが、SQL Serverのdatetimeoffsetは、元の値に加えて入力時のタイムゾーンオフセット情報もそのまま保持します。この違いを理解せずに移行すると、アプリケーション側での時刻計算や表示にズレが生じる原因となります。

また、ストレージの消費量も無視できません。datetimeoffsetは、小数点以下の秒の精度に応じて8〜10バイトを消費します。これに対し、datetime2は6〜8バイトで済みます。大量のデータを扱う大規模システムにおいては、この2バイトの差が全体のストレージ容量やメモリ消費量、ひいてはI/Oパフォーマンスに大きな影響を及ぼします。移行時には、単に名前が似ている型を選ぶのではなく、データの用途と精度要件に基づいた適切なデータ型の設計が求められます。

Foundryホスト型エージェントにおける2つの独立した分離制御

生成AIを用いたエンタープライズ向けアプリケーション開発において、自律的に動作するAIエージェントの安全な実行環境の確保は極めて重要です。マイクロソフトは、AIエージェントフレームワーク「Microsoft Foundry」において、ホスト型エージェントの安全性を高める2つの独立した分離制御（Isolation Controls）を発表しました。

1つ目は「ユーザー分離（User isolation）」です。これは、エージェントがアクセスできるデータやリソースを、リクエストを送信したユーザーのアイデンティティに基づいて厳密に制限する制御です。エージェントがユーザーに代わってアクションを実行する際、権限のないデータへのアクセスや操作を防ぎます。実装においては、信頼されたミドルウェア層を介してユーザーの認証情報をエージェントに安全に伝搬させる仕組みが提供されます。

2つ目は「ホスト型セッション分離（Hosted sessions isolation）」です。これは、エージェントが動作する実行環境そのものを、軽量な仮想マシン（VM）サンドボックスによって隔離する技術です。万が一、エージェントが不正なコードを実行したり、外部からの攻撃を受けたりした場合でも、影響が他のセッションやホストシステム全体に波及するのを防ぎます。このサンドボックス環境内では、コードの実行、ファイルの生成、実行状態の管理が完全に閉じられた領域で行われます。

これらの制御は、.NET（C#）およびPythonの双方のSDKからシンプルなコードで設定可能です。開発者は、セキュリティ要件やユースケースに応じて、これらの分離レベルを柔軟に組み合わせて構成できます。

LangChainエージェント向けAzure Blob Storageを用いた耐久性ファイルシステム

複雑なタスクを実行するAIエージェント（Deep Agents）は、処理の過程で中間ファイルを生成したり、外部のドキュメントを参照したり、実行状態を保存したりする必要があります。マイクロソフトは、AIアプリ開発の人気フレームワーク「LangChain」との統合機能として、Azure Blob Storageを仮想ファイルシステムとして使用できる「耐久性ワークスペース（Durable Workspace）」のパブリックプレビューを開始しました。

この機能により、クラウド上で動作するAIエージェントは、まるでローカルのファイルシステムを操作するかのように、Azure Blob Storageに対して以下の操作を実行できます。

• list（ファイル一覧の取得）
• read（ファイルの読み込み）
• write（ファイルの書き込み）
• delete（ファイルの削除）
• glob（パターンマッチングによるファイル検索）

最大のメリットは、エージェントのライフサイクルを超えてデータが永続化される点です。エージェントが一時的に停止したり、別のインスタンスに処理が引き継がれたりした場合でも、Blob Storage上のワークスペースを介して、以前の状態や生成されたファイルをシームレスに再利用できます。また、このワークスペースは複数のエージェント間で共有することも可能なため、複数の専門エージェントが協調して1つのタスクを遂行する「マルチエージェントシステム」の開発が容易になります。

セキュリティ面においても、Azureのロールベースアクセス制御（RBAC）やライフサイクル管理ルールがそのまま適用されます。不要になった一時ファイルを一定期間後に自動削除する設定なども、Azureインフラ側で一元管理できるため、安全かつ効率的な運用が可能です。