ゲスト寄稿者

Docker MCP Toolkit、VS Code、GitHub CopilotでArm移行を自動化する方法

投稿日 Jan 23, 2026

アジート・シン・ライナとジョー・ステック

この投稿はDockerとArmのコラボレーションによるもので、Docker MCP ToolkitとArm MCP Serverがどのように連携してアーキテクチャの移行を簡素化するかを示しています。

ワークロードをx86 からArm64 アーキテクチャへ移行する重要性が、ますます高まっています。企業はクラウドコストの削減とパフォーマンスの向上を目指しています。AWS Graviton、Azure Cobalt、Google Cloud Axionの登場により、Arm ベースのコンピューティングは主流となり、多くのワークロードで20-40%のコスト削減とパフォーマンス向上が期待されています。

しかし、ここで課題があります:どうやってアプリケーションをArmに移行し、壊さずに済むのでしょうか?

従来の移住アプローチには以下が必要です:

x86特定の依存関係に対する手動コード解析
複数のツールをまたぐ面倒な互換性チェック
手動パフォーマンス評価

もしArm移行全体のワークフローを単一のインターフェースからオーケストレーションできたらどうでしょうか?Docker MCP Toolkit がこれを可能にします。

専門的なArm移行ツールをGitHub Copilotに直接接続することで、互換性分析、内在変換、パフォーマンス予測をVS Codeでの自然な会話を通じて自動化できます。

実際の流れはこうです。GitHub Copilot に、レガシーな C++ アプリケーションを Arm64へ移行するよう依頼します。Copilot は変更点を指摘するだけではありません。x86 の intrinsics をスキャンし、x86 SIMD intrinsics を Arm SIMD intrinsics に変換し、Dockerfile を更新し、Arm でのパフォーマンス向上を予測し、すべての変更を含むプルリクエストを作成します。これらはすべて、VS Code 上での自然な対話を通じて実行されます。手動での移植作業は不要です。事前にアーキテクチャの専門知識も必要ありません。

プロセスのどのステップでも質問があれば、直接Copilotに問い合わせることができ、Arm MCP Serverナレッジベースツールを呼び出します。ナレッジベースには、learn.arm.com のすべての学習パスから直接取得した情報や、すべてのArmの本質的な知識が含まれており、その情報をまとめてくれるだけでなく、ご自身で閲覧できる具体的なドキュメントへのリンクも提供してくれます。

ここで「Arm64向けに Docker イメージを再ビルドするだけではだめなのか？」と思うかもしれません。確かに、多くのアプリケーションではそれで十分です。しかし、手動で最適化された x86 アセンブリや、AVX2 intrinsics、アーキテクチャ固有のコンパイラフラグを含むレガシーアプリに直面した場合はどうでしょうか。そのような場合に、 Arm MCP Server とともに Docker MCP Toolkit が不可欠になります。

このガイドの最後には、x86 向けに AVX2 intrinsicsで記述された行列積ベンチマークという実在のレガシーアプリケーションを、GitHub Copilot と Docker MCP Toolkit を使って Arm 64へ自動的に移行します。

通常 5〜7 時間かかる手作業は、 25 分から 30 分程度で済みます。

腕の移動チャレンジ

何を解決しているのか、正確にお見せしましょう。元々x86向けに書かれた行列乗算ベンチマークを考えてみてください。64 AVX2 最適化を施したもので、Arm移行を苦痛にするようなコードです。

Gravitonへの移行時に問題を引き起こすDockerファイルはこちらです:

FROM centos:6

# CentOS 6 reached EOL, need to use vault mirrors
RUN sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Base.repo && \
    sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Base.repo

# Install EPEL repository (required for some development tools)
RUN yum install -y epel-release && \
    sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/epel.repo && \
    sed -i 's|^#baseurl=http://download.fedoraproject.org/pub/epel|baseurl=http://archives.fedoraproject.org/pub/archive/epel|g' /etc/yum.repos.d/epel.repo

# Install Developer Toolset 2 for better C++11 support (GCC 4.8)
RUN yum install -y centos-release-scl && \
    sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-SCLo-scl.repo && \
    sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo && \
    sed -i 's|^# baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-SCLo-scl.repo && \
    sed -i 's|^# baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo

# Install build tools
RUN yum install -y \
    devtoolset-2-gcc \
    devtoolset-2-gcc-c++ \
    devtoolset-2-binutils \
    make \
    && yum clean all

WORKDIR /app
COPY *.h *.cpp ./

# AVX2 intrinsics are used in the code
RUN scl enable devtoolset-2 "g++ -O2 -mavx2 -o benchmark \
    main.cpp \
    matrix_operations.cpp \
    -std=c++11"

CMD ["./benchmark"]

なぜこれがArmには効かないのか疑問に思うかもしれません。このDockerfileを見ると、Graviton移行の即時的な障害が2つあります:

ベースイメージはArm64 非対応 – centos:6 イメージはx86 専用にビルドされているため、このコンテナは Arm ハードウェアでは起動しません。
x86固有コンパイラフラグ – -mavx2 フラグは、ARMプロセッサには存在しないAVX2 ベクター命令を使用するようコンパイラに指示します。

経験豊富な開発者でさえ、大規模なコードベースではこれらの問題を見落としがちです。

ソースコードはベクトル化演算にAVX2 内在解析を使用しています:

#include "matrix_operations.h"
#include <iostream>
#include <random>
#include <chrono>
#include <stdexcept>
#include <immintrin.h>  // AVX2 intrinsics

Matrix::Matrix(size_t r, size_t c) : rows(r), cols(c) {
    data.resize(rows, std::vector<double>(cols, 0.0));
}

void Matrix::randomize() {
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_real_distribution<> dis(0.0, 10.0);

    for (size_t i = 0; i < rows; i++) {
        for (size_t j = 0; j < cols; j++) {
            data[i][j] = dis(gen);
        }
    }
}

Matrix Matrix::multiply(const Matrix& other) const {
    if (cols != other.rows) {
        throw std::runtime_error("Invalid matrix dimensions for multiplication");
    }

    Matrix result(rows, other.cols);

    // x86-64 optimized using AVX2 for double-precision
    for (size_t i = 0; i < rows; i++) {
        for (size_t j = 0; j < other.cols; j++) {
            __m256d sum_vec = _mm256_setzero_pd();
            size_t k = 0;

            // Process 4 elements at a time with AVX2
            for (; k + 3 < cols; k += 4) {
                __m256d a_vec = _mm256_loadu_pd(&data[i][k]);
                __m256d b_vec = _mm256_set_pd(
                    other.data[k+3][j],
                    other.data[k+2][j],
                    other.data[k+1][j],
                    other.data[k][j]
                );
                sum_vec = _mm256_add_pd(sum_vec, _mm256_mul_pd(a_vec, b_vec));
            }

            // Horizontal add using AVX
            __m128d sum_high = _mm256_extractf128_pd(sum_vec, 1);
            __m128d sum_low = _mm256_castpd256_pd128(sum_vec);
            __m128d sum_128 = _mm_add_pd(sum_low, sum_high);

            double sum_arr[2];
            _mm_storeu_pd(sum_arr, sum_128);
            double sum = sum_arr[0] + sum_arr[1];

            // Handle remaining elements
            for (; k < cols; k++) {
                sum += data[i][k] * other.data[k][j];
            }

            result.data[i][j] = sum;
        }
    }

    return result;
}

double Matrix::sum() const {
    double total = 0.0;
    for (size_t i = 0; i < rows; i++) {
        for (size_t j = 0; j < cols; j++) {
            total += data[i][j];
        }
    }
    return total;
}

void benchmark_matrix_ops() {
    std::cout << "\n=== Matrix Multiplication Benchmark ===" << std::endl;

    const size_t size = 200;
    Matrix a(size, size);
    Matrix b(size, size);

    a.randomize();
    b.randomize();

    auto start = std::chrono::high_resolution_clock::now();
    Matrix c = a.multiply(b);
    auto end = std::chrono::high_resolution_clock::now();

    auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << "Matrix size: " << size << "x" << size << std::endl;
    std::cout << "Time: " << duration.count() << " ms" << std::endl;
    std::cout << "Result sum: " << c.sum() << std::endl;
}

以下のコードを見ると、Intel/AMD x86 プロセッサ向けに大幅に最適化されており、Armでは動作しないことがわかるかもしれません。

x86-excluclynヘッダー – #include <immintrin.h>xの86 システムにのみ存在します。腕の用途 <arm_neon.h>その代わりに。
AVX2 全体に内在機能 – すべての _mm256_* 機能はIntel固有の機能です:

_mm256_setzero_pd() – 256-ビットのゼロベクトルを作成します(Arm NEONは 128-ビットです)
_mm256_loadu_pd() – 一度に 4 重を積み込む(NEONが 2を装填)
_mm256_set_pd() – セット 4 ダブル(NEONに直接相当するものはない)
_mm256_add_pd() / _mm256_mul_pd() – 256ビット演算(NEONは 128ビットを使用)
_mm256_extractf128_pd() – 高 128 ビットを抽出(NEONでは不要)

ベクトル幅の不一致 – AVX2 は1回の操作で 4 倍を処理しますが、Arm NEONは 2処理します。ループ全体の構造を調整しなければなりません。(新しいArmコア(Neoverse V1/V2、Graviton 3/4)のSVE/SVE2は、256ビットまたはより広いベクトル長非依存(VLA)レジスタを提供し、AVX2レジスタと同等またはそれを超える。)
水平還元ロジック – _mm256_extractf128_pd と _mm256_castpd256_pd128 を用いた水平増しパターンはx86特有であり、Arm SIMD用に完全に書き直す必要があります。

手動変換には 30+行の内在コードの書き直し、ループのストライド調整、数値精度のテストが必要です。まさにここで自動化された移行ツールが不可欠になります。

これらの問題はそれぞれ異なる形でアームの移行を妨げています。手動移行は、単に内部機器の変換だけでなく、ビルドインフラ全体の近代化、Armの同等物の発見、性能の検証も必要です。大規模なコードベースでは、これは非常に高コストになります。

GitHub CopilotがARM MCPなしでできることとできないこと

Arm MCP ServerをDocker MCP Toolkitに追加した際の変更点を明確にしましょう。

アームなしMCP

GitHub CopilotにC++アプリケーションをx86 からArm64へ移行するよう依頼します。Copilotは一般的なアドバイスを返します:「AVX2 の内在データをNEONに変換する」「DockerファイルをARM64 ベースイメージを使うように Dockerfile を更新する」「コンパイラフラグを変更する」などです。その後、NEON の同等実装を自分で調査し、数百行に及ぶ intrinsic コードを書き直し、Dockerfile を自分で更新し、変換が正しいことを祈りながら、コンパイルエラーのデバッグに何時間も費やすことになります。

はい、Copilotはコードを書くことができます。しかし、専門的なツールがなければ、具体的な知識ベースのドキュメントや専用ツールを使って実際のアプリケーションアーキテクチャを分析するのではなく、トレーニングデータに基づく推測に過ぎません。

Arm MCP + Docker MCP Toolkit を使った

GitHub Copilotにも同じことを聞いてみてください。数分のうちに、それは:

check_imageツールを使って、ベース画像がARM対応かどうかを検証64
実際のコードベース上でmigrate_ease_scan動いて、特定のコードを探し86
knowledge_base_searchを使って、各xの本質的変数に対して正しいArm SIMDの等価物を見つける86
アーキテクチャ固有の精度でコードを変換します
DockerファイルをArm互換のベースイメージで更新します
すべての変更を含むプルリクエストを作成します。

本物のコードはスキャンされます。本物の本質的なものが変換されます。実際のプルリクエストはリポジトリに表示されます。VS Codeを閉じて明日戻ってきて、移行はテストの準備ができており、すべての変更を説明するドキュメントも完備されています。

違いは?Docker MCP Toolkitは、GitHub CopilotにArmアーキテクチャの一般的な知識だけでなく、実際のArm移行ツールへのアクセスを提供します。

なぜこれが手動移行と異なるのか

手動でArmの移行ツールを使うこともできます。ローカルでユーティリティをインストールし、チェックをし、内部情報を調査し、コードを更新する。そのプロセスは以下の通りです:

手作業のプロセス:

Armマイグレーションツールをインストールする(415 分)
互換性スキャンを実行してください(5 分)
各x個を調べてみてください86 内在的相当物(1つあたり30 分)
手動でコードを書き直す(2〜3 時間)
Update Dockerfile(15 分)
コンパイルエラーの修正(1-2 時間)
文書の変更(30 分)

合計:1回の応募で 5〜7 時間

Docker MCP Toolkit + Arm MCPでは:

GitHub Copilotに移行を依頼する(20 4分)
変更の確認と承認(10-20 分)
マージプルリクエスト

合計:1回の申請で 30〜40 分

Docker MCP ToolkitでVisual Studio Codeを設定する

前提条件

開始する前に、次のものがあることを確認してください。

最低 8 GBのRAM(推奨16GB)のマシン
最新のDocker Desktopリリース
GitHub Copilot拡張機能を使ったVS Code
個人アクセストークン付きのGitHubアカウント

ステップ 1。Docker MCP Toolkitを有効にする

Dockerデスクトップを開き、設定からMCP Toolkitを有効にしてください。

以下を可能にする方法:

Docker Desktop を開く
ベータ機能→設定へ
Toggle Docker MCP Toolkit ON
「応募」をクリックします

キャプション:Docker Desktop 下のDocker MCP Toolkitを有効にする

カタログから必要なMCPサーバーを追加する
以下のリンクをたどるか、Docker Desktop MCPツールキットの「カタログ」を選択してArm、Sequential Thinking、GitHub Officialを追加してください:

Arm MCP Server – Arm 移行ツールとアーキテクチャの専門知識
GitHub MCP Server – リポジトリ操作およびプルリクエスト管理
シーケンシャルシンキングMCPサーバー – 複雑な問題の分解と計画

キャプション:Docker MCPカタログでArm MCPサーバーを検索

ステップ 2。サーバーの設定

Arm MCPサーバーの設定

移行イージースキャンおよびMCAツールでローカルコードにアクセスするには、Arm MCPサーバーがローカルコードを指すディレクトリを設定する必要があります。

キャプション:Arm MCPサーバーの設定

「保存」をクリックすると、Arm MCPサーバーがコードの探し場所を把握してくれます。将来的に別のディレクトリへのアクセスを許可したい場合は、このパスを変更する必要があります。

利用可能なアーム移行ツール

ツールをクリックすると、Arm MCP Serverで利用可能な6つのMCPツールすべてが表示されます。

キャプション:Arm MCPサーバーが提供するMCPツール一覧

knowledge_base_search – Arm学習リソース、内在文書、ソフトウェア互換性の意味検索
migrate_ease_scan – C++、Python、Go、JavaScript、Javaに対応したコードスキャナー(Arm互換性解析)
check_image – Dockerイメージアーキテクチャ検証(イメージがArm64をサポートしているか確認)
skopeo – ダウンロード不要の遠隔コンテナ画像検査
mca – アセンブリ性能分析およびIPC予測のためのマシンコードアナライザ
sysreport_instructions – システムアーキテクチャ情報収集

GitHub MCPサーバーの設定

GitHub MCP Serverは、GitHub Copilotがプルリクエストの作成、課題の管理、変更のコミットを可能にします。

キャプション:GitHub公式MCPサーバーの設定手順

認証の設定:

GitHub officialを選択してください
希望する認証方法を選びましょう
Personal Access Tokenについては、GitHubの設定>開発者設定>取得する必要があります

GitHub MCP ServerでのPersonal Access Tokenの設定

キャプション:GitHub MCPサーバーでのパーソナルアクセストークンの設定

Sequential Thinking MCP サーバーの設定

「シーケンシャルシンキング」をクリックしてください
設定は不要です

キャプション:シーケンシャルMCPサーバーは設定不要

このサーバーはGitHub Copilotが複雑なArm移行の決定を論理的なステップに分解するのに役立ちます。

ステップ 3。VSコードにサーバーを追加する

Docker MCP Toolkitを使えば、VS Codeのようなクライアント向けにMCPサーバーを非常に簡単に設定できます。

設定するには、「クライアント」をクリックして下にスクロールしてVisual Studio Codeへ行ってください。「接続」ボタンをクリックしてください:

キャプション:Visual Studio CodeをMCPクライアントとして設定する

次にVS Codeを開き、左のツールバーにある「拡張機能」アイコンをクリックしてください:

キャプション:VS Code拡張機能でのMCP_DOCKER設定

MCP_DOCKERのギアをクリックし、「サーバー開始」をクリックしてください:

キャプション:VS CodeでMCPサーバーを起動

これでアームの移行を行う準備ができました!

ステップ 4。接続確認

GitHub Copilot ChatをVS Codeで開いて質問してください:

What Arm migration tools do you have access to?

3つのサーバーすべてのツールがリストに記載されているはずです。彼らを見かけたら、接続は正常です。コードを移行しましょう。

キャプション:GitHub Co-Pilotで遊ぶ

実世界でのデモ:レガシーx86 アプリケーションの移行

GitHub CopilotをDocker MCP Toolkitに接続したところで、先ほど見た行列乗算ベンチマークを移行しましょう。

移行までの時間: 20 分
インフラ:$0 (すべてDockerコンテナで動作)
前提条件:この投稿の前半で示したコード

ワークフロー

Docker MCP Toolkitは、リクエストを専門ツールにルーティングする安全なMCPゲートウェイを通じて移行をオーケストレーションします。Arm MCP Serverはコードをスキャンし、内在的な変換を行い、GitHub MCP Serverはプルリクエストを作成し、Sequential Thinkingは多段階の移行を計画します。各ツールは独立したDockerコンテナ上で動作し、安全で再現可能、そしてあなたの管理下にあります。

ステップ 1。リポジトリのクローン

git clone https://github.com/JoeStech/docker-blog-arm-migration

GitHub Copilotの移行指示を出す

VS Codeでプロジェクトを開きます。GitHub Copilot Chatで、このプロンプトを貼り付けてください:

Your goal is to migrate this codebase from x86 to Arm64. Use the Arm MCP Server tools to help you with this migration.

Steps to follow:
1. Check all Dockerfiles - use check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary
2. Scan the codebase - run migrate_ease_scan with the appropriate language scanner and apply the suggested changes
3. Use knowledge_base_search when you need Arm architecture guidance or intrinsic equivalents
4. Update compiler flags and dependencies for Arm64 compatibility
5. **Create a pull request with all changes using GitHub MCP Server**

Important notes:
- Your current working directory is mapped to /workspace on the MCP server
- NEON lane indices must be compile-time constants, not variables
- If you're unsure about Arm equivalents, use knowledge_base_search to find documentation
- Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.


**After completing the migration:**
- Create a pull request with a detailed description of changes
- Include performance predictions and cost savings in the PR description
- List all tools used and validation steps needed

ステップ 2。Watch Docker MCP Toolkit Execute

GitHub CopilotはDocker MCP Toolkitを使って移行をオーケストレーションします。こういうことが起こる:

フェーズ 1:画像解析

GitHub CopilotはまずArm MCP Serverの skopeo ツールを使ってDockerfileのベースイメージを解析します。

GitHub CopilotはArm MCPサーバーのskopeoツールを使ってcentos:6 ベース画像を解析しています

キャプション:GitHub CopilotはArm MCPサーバーのskopeoツールを使ってcentos:6 ベースイメージを解析しています。ツールはこの画像にビルドのARM64 がないと報告しています。これが最初に特定されたブロッカーで、コンテナはArmハードウェアでは起動すらできません。

これにより、CentOS 6 にArm64 ビルドが存在せず、置き換えが必要であることを即座に特定できます。

フェーズ 2:コード解析

次に、Copilotはコードベース上でC++スキャナーを使って migrate_ease_scan ツールを実行します。

キャプション:migrate_ease_scanツールはC++のソースコードを分析し、AVX2 イントニシクス、-mavx2 コンパイラフラグ、x86固有ヘッダーを検出します。この自動スキャンは、変換が必要なアーキテクチャ依存のコードをすべて特定します。手動で見つけるのに数時間かかる作業も含めてです。

スキャン結果は、ARM互換性のために何を変えるべきかを正確に示しています。検出された各問題には、ファイルの場所、行番号、修正が必要な特定のコードが含まれています。この正確さにより、推測を排除し、見落としがありません。

フェーズ 3:アーム最適化とベストプラクティス

フェーズ2で見つかる内在通貨86、必要に応じてCopilotはArm MCPサーバーの知識ベースにArm対応のものを問い合わせます。必要に応じて交換を行います。

GitHub Copilotはknowledge_base_searchツールを使って各AVX2 本質的なARM NEON対応モデルを見つけます

キャプション:GitHub Copilotはknowledge_base_searchツールを使って、各AVX2 本質的なArm NEON対応モデルを探しています。

ツールは公式のArmドキュメントを返します。変換内容を示す _mm256_loadu_pd() が vld1q_f64()、 _mm256_add_pd() が vaddq_f64()に、という具合です。この知識は learn.arm.com 学習経路や本質的なドキュメントから得られます。

ナレッジベースは変換マッピングだけでなく、アーキテクチャ的な文脈も提供します。AVX2の 256ビットベクトルとNEONの 128ビットベクトルを区別するため、ループ調整が必要です。Copilotはこの情報をもとに行列の乗算符号を正しく書き換えます。

フェーズ 4:GitHubのPRを作成し、まとめる

移行完了後、CopilotはGitHubでPRを作成し、変更内容をまとめます。

変更点は大きくなっています:

Centos:6 → Ubuntu :22を置き換えました。04、マルチアーチビルド用のTARGETARCH追加
Arm64 検出と -march=armv8-a+simd コンパイラフラグを追加
AVXをNEONに変換2 →アーキテクチャガード付き

ビルドはよりシンプルでモダン、そしてARM対応になっています。

フェーズ 5:プルリクエストのチェック

プルリクエストの確認は https://github.com/JoeStech/docker-blog-arm-migration/pull/1 /

性能を検証するには、ベンチマークを作成して実行できます:

docker buildx build --platform linux/arm64 -t benchmark:arm64 . --load

docker run --rm benchmark:arm64

出力は以下の通りです:

SIMD Matrix Operations Benchmark
================================
Running on Arm64 architecture with NEON optimizations
=== Matrix Multiplication Benchmark ===
Matrix size: 200x200
Time: 17 ms
Result sum: 1.98888e+08

注意事項

非常に重要な点は、すべてのモデルが同じ結果をもたらすわけではなく、Arm MCP Serverは決定論的なコンテキストを提供しますが、モデル自体は確率的であるということです。最良の結果を得るためには常にフラッグシップの最新世代モデルを使用し、モデルがパフォーマンス向上に関して予測するものは検証してください。

Docker MCP Toolkitが開発に与える変化

Docker MCP Toolkitは、開発者が専門知識や能力とどのように関わるかを変えます。新しいツールを学んだり、依存関係をインストールしたり、認証情報を管理する代わりに、開発者はAIアシスタントを一度接続すれば、すぐにコンテナ化された専門知識にアクセスできます。

その利点はArm移行にとどまらず、

一貫性 – すべての開発者で同じツール、同じ結果を得られる
セキュリティ – コンテナ化された隔離により工具の干渉が防げます
バージョン管理 – アプリケーションコードで追跡されるMCPサーバーのバージョン
再現性 – 移行は環境を越えて同じように振る舞う
発見可能性 – Docker MCP Catalog は適切なサーバーの見つけを簡単にします

最も重要なのは、開発者が既存のワークフローを維持していることです。VS Code。GitHub Copilot。行け。外部ツールやダッシュボードにコンテキスト切り替えもありません。

まとめ

Docker MCP Toolkit、Arm MCP Server、GitHub Copilotを使ってArm64 への移行を自動化できました。これまでアーキテクチャの専門知識や手動での intrinsic 変換、何時間ものデバッグを必要としていた作業が、今では自然な対話を通じて、Docker コンテナ内で安全に実行されます。

試してみる準備はできていますか?Docker Desktopを開き、MCPカタログを探索してください。まずはArm MCP Serverから始め、GitHubを追加し、シーケンシャルシンキングを試してみてください。各サーバーは新たな機能をアンロックします。

移行の未来はすべてのアプリケーションを手動で移植することではありません。AIアシスタントが、あなたのスタック全体を安全かつ再現可能に、そして思考の速さで実行できるのです。

詳細情報

Docker は初めてですか? Docker Desktop をダウンロードする
MCPカタログを探る: コンテナ化されたセキュリティ強化されたMCPサーバーを発見
MCP Toolkitの始め方: 公式文書

著者について

アジート・シン・ライナ

開発者アドボケイト、Docker

Docker の開発者アドボケイトである Ajeet Singh Raina は、コンテナ、Docker Compose と AI について執筆および講演し、開発者が自信を持って構築できるよう支援しています。

Joe Stech

スタッフソリューションアーキテクト、Arm

Docker MCP Toolkit、VS Code、GitHub CopilotでArm移行を自動化する方法

腕の移動チャレンジ

GitHub CopilotがARM MCPなしでできることとできないこと

アームなしMCP

Arm MCP + Docker MCP Toolkit を使った

なぜこれが手動移行と異なるのか

Docker MCP ToolkitでVisual Studio Codeを設定する

前提条件

ステップ 1。Docker MCP Toolkitを有効にする

ステップ 2。サーバーの設定

ステップ 3。VSコードにサーバーを追加する

ステップ 4。接続確認

実世界でのデモ:レガシーx86 アプリケーションの移行

ワークフロー

ステップ 1。リポジトリのクローン

ステップ 2。Watch Docker MCP Toolkit Execute

フェーズ 1:画像解析

フェーズ 2:コード解析

フェーズ 3:アーム最適化とベストプラクティス

フェーズ 4:GitHubのPRを作成し、まとめる

フェーズ 5:プルリクエストのチェック

注意事項

Docker MCP Toolkitが開発に与える変化

まとめ

詳細情報

著者について

関連記事

Docker Hardened System Packagesの発表

Docker Model RunnerがApple Siliconを搭載したmacOSにvLLMを導入

Open WebUI + Docker Model Runner:セルフホストモデル、ゼロ設定

製品

特徴

開発者

料金プラン

会社

言語

Docker MCP Toolkit、VS Code、GitHub CopilotでArm移行を自動化する方法

腕の移動チャレンジ

GitHub CopilotがARM MCPなしでできることとできないこと

アームなしMCP

Arm MCP + Docker MCP Toolkit を使った

なぜこれが手動移行と異なるのか

Docker MCP ToolkitでVisual Studio Codeを設定する

前提 条件

ステップ 1。Docker MCP Toolkitを有効にする

ステップ 2。サーバーの設定

ステップ 3。VSコードにサーバーを追加する

ステップ 4。接続確認

実世界でのデモ:レガシーx86 アプリケーションの移行

ワークフロー

ステップ 1。リポジトリのクローン

ステップ 2。Watch Docker MCP Toolkit Execute

フェーズ 1:画像解析

フェーズ 2:コード解析

フェーズ 3:アーム最適化とベストプラクティス

フェーズ 4:GitHubのPRを作成し、まとめる

フェーズ 5:プルリクエストのチェック

注意事項

Docker MCP Toolkitが開発に与える変化

まとめ

詳細情報

著者について

関連記事

Docker Hardened System Packagesの発表

Docker Model RunnerがApple Siliconを搭載したmacOSにvLLMを導入

Open WebUI + Docker Model Runner:セルフホストモデル、ゼロ設定

前提条件