C# でダンプファイル解析を行う MCP サーバーを作成する

こんにちは、Japan Developer Support Core チームの松井です。今回は、C# を使用して MCP (Model Context Protocol) サーバーを作成する方法について紹介します。公式ドキュメントにもチュートリアルがあるものの、最小限の内容ですので実用性が分かりづらいかもしれません。本記事では、WinDbg などが使用するデバッガーエンジンを扱う MCP サーバーを Visual Studio 2022 + C# で作成し、AI エージェントにクラッシュダンプファイルを解析させるまでの流れを紹介します。

なお、Visual Studio 2022 の MCP サーバー関連の機能は本記事執筆時点ではプレビュー機能となっていますので、将来のバージョンで変更される可能性があります。

MCP サーバーとは

MCP サーバーは、Model Context Protocol (MCP) に準拠した AI エージェント用のサーバーで、AI が外部のツールやデータソースなどのリソースと安全かつ柔軟に連携できるようにするための仕組みです。AI は自然言語で質問に答えることは得意ですが、実際にファイルを操作したり、API を呼び出したり、システムにアクセスしたりすることはできません。そこで MCP サーバーが AI の手足となり、AI が現実の操作を実行するためのインターフェイスを提供します。アーキテクチャの詳細は以下のページをあわせてご覧ください。

MCP 用 C# SDK

MCP サーバーの実装方法

MCP は JSON-RPC 2.0 をベースにしたプロトコルです。一から MCP サーバーを実装するのは大変ですが、様々な言語向けにライブラリが提供されていますので、それらを利用することで比較的簡単に MCP サーバーを構築できます。プレビュー版となりますが、C# 向けには Model Context Protocol C# SDK が提供されており、これを使用することで MCP サーバーを簡単に作成できます。また、Model Context Protocol C# SDK を使用するためのチュートリアルは以下のページにあります。

C# を使用して最小限の MCP サーバーを作成し、NuGet に発行する

MCP サーバーの実装例

前提条件

.NET 8
Visual Studio 2022 version 17.14.12 以降
Visual Studio Code version 1.103.1 以降 (任意)
GitHub Copilot Chat

1. プロジェクトの作成と設定

まずは MCP サーバーのプロジェクトを作成します。今回 MCP サーバーはコンソールアプリケーションとして実装しますが、WPF アプリケーションや ASP.NET Core アプリケーションなど、他のアプリケーションタイプでも MCP サーバーを実装できます。以下の手順ではコンソールアプリケーションを作成します。

Visual Studio 2022 を起動します。
[ファイル] - [新規作成] - [プロジェクト] を選択します。
プロジェクトの種類で C# の [コンソールアプリ] を選択します。[コンソールアプリ (.NET Framework)] は違う種類ですので注意してください。名前は任意で構いませんが、本記事では “McpServerForDbgEng” とします。フレームワークのバージョンは [.NET 8] またはそれ以降のバージョンを指定します。
プロジェクトを作成したら、ソリューションエクスプローラーでプロジェクトを右クリックし、[プロパティ] を選択し、[ターゲット OS] を [Windows]、[サポートされている OS バージョン] を [10.0.17763.0] またはそれ以降のバージョンに変更します。この設定は MCP サーバーを実装するだけであれば不要ですが、デバッガーエンジンのライブラリを参照するために必要になります。

ソリューションエクスプローラーでプロジェクトをダブルクリックし、エディターでプロジェクトファイルを開いて <UseWindowsForms>true</UseWindowsForms> を追加します。これは MCP サーバーの実装に必要な設定ではありませんが、今回はデバッガーエンジンの利用を簡潔に済ませるために利用します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
     <OutputType>Exe</OutputType>
     <TargetFramework>net8.0-windows10.0.17763.0</TargetFramework>
     <ImplicitUsings>enable</ImplicitUsings>
     <Nullable>enable</Nullable>
     <UseWindowsForms>true</UseWindowsForms>
  </PropertyGroup>
</Project>

2. NuGet パッケージの追加

NuGet パッケージマネージャーを使用して、MCP サーバーの実装に必要なパッケージを追加します。

[ソリューションエクスプローラー] でプロジェクトを右クリックし、[NuGet パッケージの管理] を選択します。
[参照] タブで [ModelContextProtocol] を検索し、[ModelContextProtocol] パッケージをインストールします。検索で表示されない場合は、[NuGet.org] ソースが選択されていること、および[プレリリースを含める] のオプションが有効になっていることを確認してください。
同様に、[Microsoft.Debugging.Platform.DbgX] を検索し、[Microsoft.Debugging.Platform.DbgX] パッケージをインストールします。今回はバージョン [20250225.2.0] を選択します。(20250415.1.0 や 20250612.2.0 は、本記事執筆事前では依存関係のパッケージが公開されていないため、プロジェクトがビルドできない可能性があります。)
最後に、[Microsoft.Extensions.Hosting] を検索して [Microsoft.Extensions.Hosting] パッケージをインストールします。こちらのバージョンは最新の安定版で構いません。

ここまで完了したら、プロジェクトは下図のようになっているはずです。
プロジェクトの状態

3. コーディング

次に、MCP サーバーの実装を行います。以下のコードを Program.cs ファイルに追加します。Microsoft.Debugging.Platform.DbgX パッケージの詳細については詳しく言及しませんが、端的に言えば WinDbg などが使用するデバッガーエンジンを C# から利用するためのライブラリです。本記事ではダンプファイルを開いてデバッガーコマンドを実行するために使用していますが、実行中のプロセスにアタッチすることも可能です。

using DbgX;
using DbgX.Interfaces.Services;
using DbgX.Interfaces.Services.Internal;
using DbgX.Requests;
using DbgX.Requests.Initialization;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;
using System.Collections.Concurrent;
using System.ComponentModel;
using System.Diagnostics;
using System.Text;

// MCP server tools in this example return results in the form of a record.
// Explicitly specify IncludeFields = true so that the fields of the tuple are serialized.
var options = new System.Text.Json.JsonSerializerOptions { IncludeFields = true };
options.MakeReadOnly(true);

var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace);
builder.Services
    .AddLogging()
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithTools<DbgEngTools>(options);
_ = builder.Build().RunAsync().ContinueWith(t => DbgEngTools.Shutdown());

Application.Run(DbgEngTools.CreateContext());

class DbgEngTools(ILogger<DbgEngTools> _logger)
{
    // Invoker control to run debugger engine in the main thread.
    // This is necessary because MCP server tools methods run in thread pool threads.
    private static readonly Control _invoker = new();

    public static ApplicationContext CreateContext()
    {
        _invoker.CreateControl();
        return new ApplicationContext();              
    }

    public static void Shutdown() => _invoker.Invoke(() => Application.Exit());

    // Dictionary to hold active debug sessions
    private static readonly ConcurrentDictionary<string, (DebugEngine engine, StringBuilder buffer)> _sessions = new();

    public record StartDebugSessionResponse(string Result, string CommandOutput = "", string SessionId = "");

    [McpServerTool]
    [Description("Start debug session from a specified dump file.")]
    public async Task<StartDebugSessionResponse> StartDebugSessionFromDumpFile(
        [Description("Full path to a dump file.")] string dumpFilePath
    )
    {
        return await _invoker.Invoke(async () =>
        {
            try
            {
                DebugEngine engine = new();
                StringBuilder buffer = new();
                engine.DmlOutput += (sender, e) => buffer.AppendLine(e.Output);

                await engine.SendRequestAsync(new OpenDumpFileRequest(dumpFilePath, new EngineOptions()));
                await engine.SendRequestAsync(new ExecuteRequest(".prefer_dml 1"));
                var sessionId = Guid.NewGuid().ToString();
                _sessions[sessionId] = (engine, buffer);
                return new StartDebugSessionResponse($"Debug session has been started from '{dumpFilePath}'.", buffer.ToString(), sessionId);
            }
            catch (Exception ex)
            {
                _logger.LogError("{Message}", ex);
                return new StartDebugSessionResponse($"Failed to open '{dumpFilePath}': {ex.Message}");
            }
        });
    }

    public record ExecuteCommandResponse(string Result, string CommandOutput = "");

    [McpServerTool]
    [Description("Execute a debugger command in the specified session and return the output of the executed command.")]
    public async Task<ExecuteCommandResponse> ExecuteCommand(
        [Description("Debug session ID")] string sessionId,
        [Description("Debugger command to execute")] string commandInput
    )
    {
        return await _invoker.Invoke(async () =>
        {
            try
            {
                var (engine, buffer) = _sessions[sessionId];
                buffer.Clear();
                await engine.SendRequestAsync(new ExecuteRequest(commandInput));
                return new ExecuteCommandResponse($"Command '{commandInput}' has been executed.", buffer.ToString());
            }
            catch (Exception ex)
            {
                _logger.LogError("{Message}", ex);
                return new ExecuteCommandResponse($"Failed to execute command '{commandInput}': {ex.Message}");
            }
        });
    }

    [McpServerTool]
    [Description("End the specified session.")]
    public async Task<string> ExitDebugSession(
        [Description("Debug session ID")] string sessionId
    )
    {
        return await _invoker.Invoke(async () =>
        {
            try
            {
                _sessions.TryRemove(sessionId, out var session);
                if (session.engine is not null)
                    await session.engine.ShutdownAsync();
                return "Debug session has been ended.";
            }
            catch (Exception ex)
            {
                _logger.LogError("{Message}", ex);
                return $"Failed to end debug session: {ex.Message}";
            }
        });
    }
}

ソースコードは 100 行以上になりますが、概ね以下のような構成になっています。

20-27L: MCP サーバーの構成と起動処理
29L: デバッガーエンジンの同期のためのメッセージループの開始
48-76L: MCP サーバーのツールの実装 (デバッグセッションの開始)
78-102L: MCP サーバーのツールの実装 (デバッグコマンドの実行)
104-126L: MCP サーバーのツールの実装 (デバッグセッションの終了)

なお、今回はサンプルとして細かなエラー処理やログ出力などを省略していますが、実際の実装では適切なエラー処理やログ出力を行うことをお勧めします。また、セキュリティの観点から入力の検証やサニタイズも行う必要があります。例えば、デバッガーエンジンは外部プログラムの実行や拡張機能の読み込みなど非常に多くのタスクを実行することができるため、利用できるコマンドを制限するなどの十分なセキュリティ対策が必要です。

4. テスト

事前準備

ビルドしたら、MCP サーバーを実行してみましょう。MCP サーバーの動作を確認する方法は様々ありますが、本記事では Visual Studio と Visual Studio Code の GitHub Copilot Chat から MCP サーバーに接続して動作確認してみます。Visual Studio や Visual Studio Code は、いくつかのファイルパスに MCP サーバーの構成ファイルを探しに行きます。今回は、プロジェクトファイルと同じ階層に “.vscode” フォルダーを作成し、その配下に以下のような内容の mcp.json ファイルを作成します。”command” プロパティはビルドした実行可能ファイルの完全パスに置き換えてください。定義済みの変数を使用することもできますが、使用するツールによって解釈が異なりますのでここでは完全パスを指定しています。今回 “inputs” プロパティは使用しませんが、”inputs” プロパティを省略した場合 Visual Studio 2022 のバージョンによっては MCP サーバーを検出できなくなるため注意してください。

{
  "inputs": [],
  "servers": {
    "DbgEng": {
      "type": "stdio",
      "command": "C:\\source\\repos\\McpServerForDbgEng\\McpServerForDbgEng\\bin\\Debug\\net8.0-windows10.0.17763.0\\McpServerForDbgEng.exe"
    }
  }
}

次に、テストに使用するダンプファイルを生成するための設定を行います。今回は Windows Error Reporting (WER) を使用してクラッシュダンプファイルを取得します。以下のテキストをコピーして localdumps.reg のファイル名で保存し、インポートしてください。これにより、クラッシュダンプファイルが C:\Logs フォルダーに保存されるようになります。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
“DumpType”=dword:00000002
“DumpFolder”=hex(2):43,00,3a,00,5c,00,4c,00,6f,00,67,00,73,00,00,00
“DumpCount”=dword:0000000a

最後に以下のような C++ コードをコンパイルして実行し、クラッシュダンプファイルを生成します。このコードは意図的にヒープのバッファオーバーフローを引き起こすものです。今回は x64|Debug の構成でビルドします。このとき、exe ファイルと一緒に出力されるシンボルファイル (*.pdb ファイル) はデバッグで必要となりますので、削除しないでください。シンボルファイルがないと、ダンプファイルの解析時にソースコードの行番号などの情報が得られません。(参考情報: シンボルファイルと Visual Studio のシンボル設定を理解する)

#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <string.h>

__declspec(noinline)
void foo(char* buffer)
{
    strcpy(buffer, "This is a long long long long long long long long long long long text.");
}

int main()
{
    char* buffer = new char[8];
    foo(buffer);
    delete[] buffer;
}

実行したらアプリケーションがクラッシュし、C:\Logs フォルダーにクラッシュダンプファイルが生成されているはずです。

Visual Studio を使用して MCP サーバーに接続する

Visual Studio 2022 を起動して、MCP サーバーのプロジェクトを開きます。
GitHub Copilot Chat を開きます。
チャットモードで [エージェント] を選択し、ツールに DbgEng が含まれていることを確認してチェックを入れます。

もしツールが見つからない場合は、MCP サーバーのプロジェクトファイルと同じ階層にある “.vscode” フォルダーに mcp.json ファイルが正しく配置されているか確認してください。また、[出力] ウィンドウで出力元を [GitHub Copilot] に変更し、MCP サーバーの読み込みに失敗していないか確認してください。

チャット欄に以下のように入力して、MCP サーバーに接続します。

1	C:\logs\xxxxxxxx.dmp を開いて解析し、原因と対処方法について教えてください。

AI からの応答を確認してみてください。AI の判断によっては MCP サーバーを使用しない可能性があるため、”DbgEng の MCP サーバーを使用して” など具体的に指示してみてください。MCP サーバーの実行を試行する場合は実行してよいか確認が求められれますので、正しいツールとコマンドを実行しようとしていることを確認してから許可してください。

私の手元で実行した結果は以下のようになりました。

Visual Studio での解析結果

ダンプファイルの解析結果をまとめます。

### 解析内容
- ダンプファイル：`C:\logs\ConsoleApplication1.exe.8052.dmp`
- 例外コード：`c0000374`（STATUS_HEAP_CORRUPTION、ヒープ破損）
- スタックトレースの最上位は `ntdll!RtlpMuiRegCreateRegistryInfo` で、ヒープ操作（`RtlAllocateHeap` など）や `operator delete`、`operator delete[]` が見られます。
- アプリケーションの `main` 関数付近でクラッシュしています。

### 原因
- ヒープ破損（メモリ破壊）が発生しています。  
  これは二重解放、バッファオーバーフロー、解放済みメモリへのアクセスなどが原因で発生します。

### 対処方法
1. **メモリ操作の見直し**  
   - `delete` や `delete[]` の重複呼び出しがないか確認してください。
   - 解放済みメモリへのアクセスや、バッファサイズを超えた書き込みがないか確認してください。
2. **デバッグビルドで実行**  
   - Visual Studio等でデバッグビルドし、ヒープチェック機能（CRTのデバッグヒープなど）を有効にして再現させると、問題箇所が特定しやすくなります。
3. **静的解析ツールの利用**  
   - C++の場合、AddressSanitizerやVisual Studioの静的解析を利用してください。

### 備考
- `!analyze -v` コマンドは利用できませんでした（拡張DLLがロードされていないため）。
- 詳細な原因特定には、ソースコードの該当箇所（`main`やメモリ操作部分）の確認が有効です。

ご不明点や追加で実行したいコマンドがあればご指示ください。

今回、!analyze -v コマンドが利用できなかったことが記載されていますが、これは Microsoft.Debugging.Platform.DbgX パッケージに !analyze 拡張機能を実装した exts.dll などが含まれていないことに起因しています。Debugging Tools for Windows がインストールされている場合は、C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 配下のファイルをビルド出力先の amd64 フォルダーに、C:\source\repos\McpServerForDbgEng\McpServerForDbgEng\bin\Debug\net8.0-windows10.0.17763.0\x86 配下のファイルをビルド出力先の x86 フォルダーにそれぞれコピーすることで、!analyze コマンドを使用できるようになります。拡張機能の利用は必須ではありませんが解析する手段の選択肢が多くなりますので、興味がある方は公式ドキュメントをご確認いただき入手してください。

Visual Studio Code を使用して MCP サーバーに接続する

Visual Studio Code を起動します。
メニューから [ファイル] - [フォルダーを開く] を選択して MCP サーバーのプロジェクトファイルがあるフォルダーを開きます。
“.vscode\mcp.json” を開くと MCP サーバーの操作のラベルが表示されますので、[起動] をクリックします。[その他] - [出力の表示] を選択すると MCP サーバーの出力が表示されますので、あわせて確認しておくとよいでしょう。
GitHub Copilot Chat を開き、チャットモードで [エージェント] を選択してツールに DbgEng が含まれていることを確認します。

チャット欄に以下のように入力して、MCP サーバーに接続します。

1	#DbgEng C:\logs\xxxxxxxx.dmp を開いて解析し、原因と対処方法について教えてください。

AI からの応答を確認してみてください。MCP サーバーの実行を試行する場合は実行してよいか確認が求められれますので、正しいツールとコマンドを実行しようとしていることを確認してから許可してください。

私の手元で実行した結果は以下のようになりました。なお、選択している AI モデルにも依存する点や、処理の都度 AI が異なる応答を返す可能性がある点に注意してください。期待した応答が得られない場合は、追加のコンテキストや指示を与えることで良い結果が得られる可能性があります。また、Visual Studio Code の場合は入力や出力も確認することができますので、実際にどのようなデバッガーコマンドが実行されたのかを確認することもできます。

kemats: #DbgEng C:\logs\ConsoleApplication1.exe.8052.dmp を開いて解析し、原因と対処方法について教えてください。

GitHub Copilot: ダンプファイルを解析して問題の原因を特定しましょう。まず、指定されたダンプファイルでデバッグセッションを開始します。 ダンプファイルが正常に読み込まれました。例外コード `c0000374` が発生していることがわかります。これは一般的にヒープ破損（Heap Corruption）を示すエラーです。詳細な解析を実行してみましょう。 解析結果から、ヒープ破損（HEAP_CORRUPTION）が発生していることが確認できました。次に、スタックトレースと例外コンテキストをより詳しく確認してみましょう。 優れたスタックトレースが取得できました！問題の根本原因が特定できます。

フレーム42（0x2a）で、`ConsoleApplication1!main+0x59` からの `delete[]` 操作でヒープ破損が発生しています。ソースコードの詳細を確認してみましょう。 main関数のアドレスを直接確認してみましょう。 問題の発生地点が特定できました。フレーム42でmain+0x59、つまり `00007ff6\u00609ab31979` で `delete[]` が呼ばれています。ソースコードの行番号も確認できています（15行目）。

ヒープ検証を有効にして、さらに詳細な情報を取得してみましょう。 バッファの詳細を確認してみましょう。 プログラムのメモリマップとソースコードに関する追加情報を取得してみましょう。 ここでデバッグセッションを終了して、解析結果をまとめます。 ## ダンプファイル解析結果

### 🔍 **問題の原因**

ダンプファイルの解析により、**ヒープ破損（Heap Corruption）**が発生していることが判明しました。

**具体的な詳細：**
- **例外コード**: `c0000374` (STATUS_HEAP_CORRUPTION)
- **発生場所**: `ConsoleApplication1.cpp` の15行目
- **実行コンテキスト**: `main()` 関数内で `delete[]` 操作実行中
- **バッファ内容**: `"This is a long long long long long long long long long long long text."`

### 📍 **ソースコードレベルでの問題特定**

スタックトレースから、以下の呼び出しシーケンスでエラーが発生：

main() (15行目)
  ↓
operator delete[]
  ↓  
ucrtbased!free_dbg
  ↓
ntdll!RtlAllocateHeap (ヒープ破損検出)
  ↓
ntdll!RtlReportFatalFailure (致命的エラー報告)

### 🔧 **推定される根本原因**

1. **バッファオーバーラン**: 配列の境界を超えた書き込み
2. **二重解放**: 同じメモリブロックを複数回 `delete[]` で解放
3. **メモリ破損**: 無効なポインタに対するメモリ操作
4. **不適切なメモリ管理**: `new[]` で確保したメモリを `delete` で解放（`delete[]` ではなく）

### 💡 **対処方法**

#### **即座の対策:**
1. **コードレビュー**: `ConsoleApplication1.cpp` の15行目周辺のメモリ管理を確認
2. **デバッグビルド**: Application Verifierやページヒープを有効にして詳細な診断を実行
3. **静的解析**: コードに対してPREfast/Code Analysisを実行

#### **ソースコードでの修正ポイント:**

// 問題のあるパターン例:
char* buffer = new char[size];
// ... バッファ操作 ...
delete buffer;  // ❌ 間違い: delete[] を使うべき

// 正しい修正:
char* buffer = new char[size];
// ... バッファ操作 ...
delete[] buffer;  // ✅ 正しい

// さらに安全な方法:
std::vector<char> buffer(size);  // 自動的に適切に管理される
// または
std::string buffer;  // 文字列の場合

#### **長期的な対策:**
1. **RAII原則の適用**: `std::vector`, `std::string`, スマートポインタの使用
2. **メモリリーク/破損検査ツール**: 
   - Visual StudioのDiagnostic Tools
   - Application Verifier
   - CRT Debug Heap
3. **単体テスト**: メモリ管理を含む十分なテストケース作成

### 🚨 **緊急度**

このエラーは**高優先度**で対処が必要です。ヒープ破損はアプリケーションクラッシュだけでなく、セキュリティ脆弱性の原因となる可能性があります。

15行目のメモリ管理コードを直ちに確認し、適切な `new[]`/`delete[]` のペアリングと境界チェックを実装してください。

5. デバッグ

MCP サーバーを直接実行してデバッグしてもよいのですが、AI エージェントから呼び出されたときの振る舞いを確認したい場合もあると思います。MCP サーバーの方式によってデバッグ方法は異なりますが、ローカル実行の場合に使用されることが多い stdio の場合、Visual Stuio や Visual Studio Code からサーバープロセスが起動された後は実行中のまま標準入力を待ち受ける状態になっています。そのため、実行中のサーバープロセスにアタッチすることでデバッグすることが可能です。ここでは、Visual Studio Code から起動された MCP サーバーにアタッチしてデバッグする手順を紹介します。

Visual Studio Code から MCP サーバーを起動します。
Visual Studio 2022 を起動し、MCP サーバーのプロジェクトを開きます。
メニューから [デバッグ] - [プロセスにアタッチ] を選択します。
プロセスの一覧から、mcp.json で指定した MCP サーバーのプロセスを選択して [アタッチ] ボタンを押下します。今回は “McpServerForDbgEng.exe” という名前になっているはずですが、dotnet.exe など別のホストプロセスが起動している場合は、ホストプロセスを選択する必要がありますので注意してください。
McpServerTool 属性を指定してツールとして公開しているメソッドにブレークポイントを設定します。今回は StartDebugSessionFromDumpFile メソッドにブレークポイントを設定します。
Visual Studio Code から GitHub Copilot Chat を使用してツールを呼び出します。今回は以下のように指示してみます。
1
#DbgEng C:\Logs\xxxxxxxx.dmp を開いてください。
Visual Studio 2022 でブレークポイントがヒットすることを確認します。この後は、呼び出し履歴や変数を確認したり、ステップ実行するなどの通常のデバッグ操作を行うことができます。

まとめ

今回は、C# を使用して MCP サーバーを作成し、AI エージェントにクラッシュダンプファイルを解析させる方法について紹介しました。MCP サーバーは AI エージェントが外部のリソースと連携するための重要な仕組みであり、C# での実装も比較的簡単に行うことができます。アプリケーションが MCP サーバーを提供することで、AI エージェントがアプリケーションの機能やリソースにアクセスしてタスクを実行できるようになります。本記事が開発者の皆様の MCP サーバーの利用や実装の参考になれば幸いです。

本ブログの内容は弊社の公式見解として保証されるものではなく、開発・運用時の参考情報としてご活用いただくことを目的としています。もし公式な見解が必要な場合は、弊社ドキュメント (https://learn.microsoft.com や https://support.microsoft.com) をご参照いただくか、もしくは私共サポートまでお問い合わせください。