Visual Studio 2022 のオフラインレイアウトを作成すると、「ドキュメントでは x64 だけのはずなのに、ARM64 のフォルダーが大量に入っている…」という状況に出会います。本記事では、この挙動の理由と、現状の仕様の中で ARM64 バイナリを“できるだけ”減らしつつ、レイアウトの容量と運用コストを最小限に抑えるための具体的なテクニックを整理します。
Visual Studio 2022 オフラインレイアウトと ARM64 バイナリの問題
Visual Studio 2022 では、以下のようなコマンドでオフラインレイアウト（ローカルレイアウト）を作成できます。
vs_enterprise.exe --layout C:\VS2022
公式ドキュメント上は、「--arch オプションを指定しない場合は、既定で x64 の製品バイナリのみが取得される」と説明されています。
しかし実際にレイアウトを作成して C:\VS2022\packages をのぞいてみると、例えば次のような ARM64 向けパッケージが多数含まれているケースがあります。
Microsoft.Build.Arm64,version=...
Microsoft.Ancmv2.IIS.Msi,version=...,machinearch=arm64
...
「x64 だけのはずなのに ARM64 も入っている」というギャップが、今回の疑問の出発点です。
結論：ARM64 バイナリを“完全には”スキップできない
2025 年時点での Microsoft Q&A では、「--arch を指定せずにレイアウトを作成しても、一部の ARM64 ファイルは依存関係として必ず含まれる。これらを完全に除外する公式な方法は存在しない」と回答されています。
つまり、次のような結論になります。
--arch x64を明示しても、あるいは省略しても、ARM64 パッケージが 0 個になることはない。- 現行のツールには「ARM64 を一切含めない」ためのスイッチや設定は用意されていない。
- ARM64 版 Visual Studio をサポートするための共通コンポーネントとして、一部 ARM64 パッケージが x64 レイアウトにも混在する。
このため、「ARM64 を完全スキップしたレイアウトを作る」という意味では、残念ながら現状は実現不可能です。以降では、
- なぜこのような挙動になっているのか
- それでも容量をできるだけ抑えるためにはどうすべきか
という観点から、現実的な対策を整理していきます。
ドキュメントと実挙動のギャップを整理する
まずは、ドキュメント上の説明と、実際に観測される挙動を簡単に比較しておきます。
| 項目 | ドキュメントの説明 | 実際によく見られる挙動 |
|---|---|---|
--arch 省略時 | 既定では「x64 のみの製品バイナリ」をレイアウトに含めるとされている。 | MSBuild など一部のコンポーネントについては ARM64 用フォルダーも作成される。 |
--arch all / --arch arm64 | 明示的に ARM64 を含める（または ARM64 のみを取得する）オプションとして説明されている。 | 当然 ARM64 パッケージをさらに多く取得するため、容量はさらに増加する。 |
| Q&A での回答 | – | 「依存関係として必要な ARM64 ファイルは自動的に含まれるため、完全に除外することはできない」と明言されている。 |
ここから分かるのは、ドキュメントの「既定で x64 のみ」という表現はあくまで 製品（メインのインストール対象）が x64 版である ことを指しており、「一切 ARM64 パッケージを含まない」という意味ではない、という点です。
なぜ ARM64 パッケージを完全に消せないのか
Visual Studio 2022 は、バージョン 17.4 以降で Arm64 ネイティブ版を提供しており、単一のインストーラーで x64 / Arm64 を両方扱う設計に変わりました。
この「単一インストーラー」設計には、次のような背景があると考えられます。
- 同じワークロード・コンポーネントを、x64 環境でも Arm64 環境でも出来るだけ同じ ID で扱いたい。
- MSBuild、.NET SDK、C++ ランタイムなどのコンポーネントは、ターゲットアーキテクチャごとにある程度共通の構成を持っている。
- インストーラー側で「どのアーキテクチャが必要か」を柔軟に判断したい。
その結果、パッケージの配布単位として「x64 と Arm64 をまとめた共通パッケージ」や、「内部的には複数アーキテクチャのファイルを含むコンポーネント」が存在しており、
- 文書上は「x64 だけのレイアウト」を指定していても
- パッケージ単位では「Arm64 向けファイルも一緒に入ってしまう」
という状況が発生します。
ここで重要なのは、これらの ARM64 ファイルが「将来的に Arm64 マシンに流用されるため」というだけでなく、
- 一部のツールチェーンはクロスコンパイルやマルチターゲットを前提に設計されており、
- ビルド環境を完全に共通化するために ARM64 バイナリも含めた上でテストされている
といった、品質保証やサポート性の観点からも、完全な分離がされていない可能性が高いという点です。
現実的にできること：容量を抑える 3 つの基本方針
「ARM64 を 0 にする」ことはできないものの、レイアウト全体の容量を減らすことで、結果的に ARM64 ファイルの総量もある程度削減できます。基本的な方針は次の 3 つです。
- 必要なワークロードだけを
--addで絞り込む - 言語パックやオプションコンポーネントを最小限にする
- 古いバージョンや不要なレイアウトをこまめにクリーンアップする
それぞれの方法と注意点を、まずは一覧表で整理します。
| 方法 | 期待できる効果 | 向いている用途 | 注意点 |
|---|---|---|---|
--add で必要ワークロードのみ指定 | ダウンロード総量が大幅に減り、結果として ARM64 パッケージもある程度減少 | 社内で特定の開発分野（例：.NET デスクトップのみ）にレイアウトを配布する場合 | ARM64 パッケージが 0 になるわけではない。必要なコンポーネントの ID を正しく洗い出す必要がある。 |
--lang で言語を絞る | 各コンポーネントのローカライズ済みパッケージが減り、数 GB 単位で削減可能 | 日本語環境で、日本語 UI のみを使うクライアントに配布する場合 | 後から別言語を追加したくなった場合、レイアウトを再作成・更新する必要がある。 |
--includeRecommended / --includeOptional を控えめに | ワークロードが自動で引き込む追加コンポーネントが減り、容量を圧縮 | 使う機能がある程度限定されている現場向け | 「おすすめコンポーネント」を入れないことで、後から必要な機能が欠けている可能性がある。 |
レイアウトを定期的に --clean でクリーンアップ | 古いバージョンのパッケージを削除し、ディスク使用量を抑える | 長期運用している共通レイアウト共有サーバー | 対象となるカタログ指定を誤ると必要なバージョンを消してしまう可能性がある。 |
--add で必要最小限のレイアウトを作る
最も効果が大きいのは、「全部入りレイアウト」をやめて、ワークロード／コンポーネントを明示的に指定することです。公式ドキュメントでは、--add を使用すると、指定したワークロードとその依存関係だけがレイアウトにダウンロードされると説明されています。
代表的なコマンド例
.NET デスクトップと ASP.NET / Web 開発に絞ったレイアウトの例です。
vs_enterprise.exe ^
--layout C:\VS2022 ^
--add Microsoft.VisualStudio.Workload.ManagedDesktop ^
--add Microsoft.VisualStudio.Workload.NetWeb ^
--includeRecommended ^
--lang ja-JP
ポイントは次のとおりです。
--addでワークロード ID を明示することで、使わないワークロードのコンポーネントが落ちてこなくなる。--includeRecommendedを付けるかどうかは現場のポリシー次第。最初は付けて、様子を見ながら削ると安全です。--lang ja-JPを付けることで、日本語以外のローカライズパッケージを除外し、容量を抑えられます。
vsconfig を使って内容を固定する
複数の開発者環境で同じ構成を使いたい場合は、Visual Studio からエクスポートした .vsconfig をレイアウトにそのまま流用するのがおすすめです。
vs_enterprise.exe ^
--layout C:\VS2022 ^
--config C:\config\MyTeam.vsconfig ^
--lang ja-JP
こうしておけば、
- 「誰のマシンでも同じコンポーネント構成」という状態を保ちやすくなる
- 後から構成を変更したくなったときも、
.vsconfigを更新するだけでよい - 結果として、過剰なワークロードや不要な ARM64 コンポーネントが入りにくくなる
というメリットがあります。
言語パック・オプションコンポーネントを削る
オフラインレイアウトのサイズを大きくしている要因の一つが「多言語 UI」と「おすすめコンポーネント」です。ARM64 だけでなく、これらも一緒に削ることで、大きく容量を圧縮できます。
言語パックの絞り込み
日本語環境のみで運用するのであれば、レイアウト作成時に --lang ja-JP のように言語を指定することで、他の言語向けリソースがダウンロードされなくなります。
複数言語が必要な場合でも、実際に使う分だけを明示的に列挙することで、不要な言語パックを省けます。
--lang ja-JP en-US
「将来使うかもしれないから全部入れておく」という考え方はオフラインレイアウトだとありがちですが、
- 容量が膨らみすぎてバックアップや配布がつらくなる
- 更新のたびにダウンロード量が増え、ネットワーク負荷も大きくなる
といった弊害の方が大きいことが多いので、まずは現場で実際に必要な言語に絞る方針をおすすめします。
おすすめコンポーネントを無条件で入れない
ワークロードに --includeRecommended や --includeOptional を付けると、
- 便利ではあるが必須ではないツール群
- 将来的なシナリオのためのテンプレートや SDK
などが大量に追加されます。中には ARM64 向けの補助コンポーネントも含まれるため、容量面だけ見るとかなりの負担になります。
最初の一歩としては、
- 共通レイアウト：
--includeRecommendedだけ付けておき、--includeOptionalは付けない - 個別プロジェクト向けレイアウト：本当に必要なコンポーネントだけを
--addで直接指定する
といった住み分けをするのが現実的です。
レイアウトのクリーンアップで容量を維持する
長期間運用しているレイアウトでは、「昔のバージョンのパッケージがそのまま残っている」ことがよくあります。これも ARM64 を含め全体の容量を押し上げる原因の一つです。
Visual Studio のインストーラーには、オフラインレイアウトに対して --verify や --fix、--clean を実行する機能があります。
--verify：レイアウト内の破損・欠落パッケージを列挙する--fix：破損・欠落したパッケージを再ダウンロードする（オンライン接続が必要）--clean <catalog>：レイアウトから古いバージョンのパッケージを削除する
この仕組みを活用して、
- 毎回新しいレイアウトをゼロから作り直すのではなく
- 既存レイアウトをアップデートしつつ、古いパッケージをクリーンアップする
という運用に切り替えることで、結果的に ARM64 を含む余剰パッケージの蓄積を防ぐことができます。
非公式だがよく話題になる方法：ARM64 フォルダーの手動削除
コミュニティでは、「レイアウトを作った後で、packages 以下の ARM64 関連フォルダーを手動で削除する」という方法も時々話題になります。手っ取り早いものの、これは 完全に自己責任で行うべき非公式な手法 です。
なぜサポート外なのか
レイアウトフォルダー内のファイル群は、インストーラーが保持しているカタログ情報と厳密に紐付いています。ここから任意のフォルダーを削除すると、次のような問題が起こり得ます。
- インストール時に「必要なパッケージが見つからない」と判断され、インストールが失敗する。
--noWebを指定しているのに、足りないパッケージを取りに行こうとして失敗する。--verifyを実行すると毎回「欠落」と判定される。
とくに、どの ARM64 パッケージが実際に必要なのかはエディションやワークロード構成によって変わるため、「このフォルダーだけ消せば安全」と言い切ることはできません。
どうしても試す場合の最低限のガイドライン
それでも「検証用に試したい」というニーズがある場合は、次のような手順にしておくと、被害を最小限に抑えられます。
- まず通常どおりレイアウトを作成する。
- そのレイアウトを別の場所（例：
C:\VS2022_Experiment）にコピーする。 - コピー側に対してのみ、ARM64 を含むフォルダーを削除する。
- テスト用の仮想マシンなどに対して、オフラインインストールを試す。
- 問題がなければ、限定的な用途でのみ利用する。
PowerShell で「パスに \arm64\ を含むフォルダーを再帰的に削除する」例を示します（あくまでサンプルです）。
Set-Location C:\VS2022_Experiment
Get-ChildItem -Path .\packages -Directory -Recurse `
| Where-Object { $_.FullName -match '\\arm64\\' } `
| Remove-Item -Recurse -Force
このような操作を行った場合、
- インストールの成否や動作保証は一切得られない
- 問題が発生しても、Microsoft サポートに問い合わせることはできない（サポート範囲外）
という点をよく理解した上で、実運用環境ではなく検証環境に限定して試すことを強くおすすめします。
オンラインインストールへ切り替えるという割り切り
もしインストール対象マシンがオンライン接続できるのであれば、「オフラインレイアウトではなく、オンラインインストールに切り替える」という割り切りも有効です。
オンラインインストールであれば、インストーラーは基本的に 必要になったパッケージだけを都度ダウンロード します。そのため、
- インストールされる ARM64 パッケージは、選択したワークロードやコンポーネントに必要な範囲にほぼ自動的に限定される
- レイアウトフォルダーの容量を気にする必要がない
というメリットがあります。
一方で、
- インストールのたびにインターネット回線への負荷がかかる
- オフライン環境やセキュアネットワークではそもそも利用できない
という制約もあるため、環境に応じて「どこまでオフラインにこだわるか」を決める必要があります。
シナリオ別：おすすめの考え方
ここまでの内容を踏まえ、代表的なシナリオごとに「どの方針を採るべきか」を簡単にまとめます。
| シナリオ | ネットワーク状況 | おすすめ戦略 |
|---|---|---|
| 完全オフライン（ネットワーク分離環境） | インストール対象マシンがインターネットに一切接続できない | オフラインレイアウトを利用するのは必須 --add と --lang を駆使して必要最小限のレイアウトを作る ARM64 の完全除外は諦め、容量削減に集中する |
| 制限付きオンライン（回線は細いが使える） | VPN 越しに遅い回線でインターネットに接続できる | 基本はオンラインインストール 頻繁に使うワークロードだけオフラインレイアウトを用意する「ハイブリッド方式」も有効 |
| 社内配布用共通イメージ | 共通レイアウトをファイルサーバーに置いて、社内各所から利用 | 毎回フルレイアウトを作り直さず、--layout の更新と --clean で運用 共通の .vsconfig を用意して構成を固定化する |
よくある疑問とその考え方
Q. ARM64 パッケージを削っても、x64 開発には関係ないのでは？
理論上、「純粋に ARM64 ターゲットのためだけに存在するパッケージ」であれば、x64 環境では参照されない可能性もあります。しかし、以下のような理由で「どれが完全に不要か」を判断するのは難しいです。
- インストーラーのカタログレベルで ARM64 パッケージが依存関係に含まれている場合、削除するとインストールエラーにつながる。
- 将来のアップデートや追加ワークロードで、後から ARM64 パッケージが参照される可能性がある。
結果として、「今は動いているから大丈夫そう」に見えても、数か月後の更新で突然こける…というリスクがあります。保守性と再現性を重視するなら、公式にサポートされないファイル削除は避けるのが無難です。
Q. Visual Studio Build Tools のレイアウトなら ARM64 は減る？
Visual Studio 2022 Build Tools 向けのオフラインレイアウトでも、考え方は基本的に同じです。Build Tools 用のブートストラッパーと --layout を組み合わせれば、コンパイラや MSBuild だけを含む軽量なレイアウトを作れますが、
- 一部のビルドツールや SDK が Arm64 をサポートしている場合
- 共通の依存関係パッケージが再利用される場合
には、やはり ARM64 パッケージが一定量含まれる可能性があります。つまり、「通常版よりは減るかもしれないが 0 にはならない」というイメージで捉えておくのが現実的です。
Q. 「ARM64 を含めないレイアウト」を将来サポートしてくれそう？
現時点では、「ARM64 パッケージを完全除外するためのオプションを追加する」というアナウンスは公開されていません。ただし、レイアウト機能自体は継続的に改善されており、オフラインインストールのための手順やパラメーターも頻繁に更新されています。
そのため、
- Visual Studio のリリースノート
- オフラインレイアウト関連のドキュメント
- Developer Community や Q&A の動向
を定期的にチェックしておくと、将来的な追加機能や仕様変更にいち早く気付けます。
Q. レイアウト作成後に ARM64 を追加することはできる？
既存のレイアウトに対して --arch all や --arch arm64 を付けて再度 --layout を実行することで、ARM64 バイナリを追加取得することはできます。これは、
- 最初は x64 だけのつもりだったが、後から Arm64 マシンにも配布したくなった
といったケースで役に立ちます。ただし、逆方向（すでに含まれている ARM64 を後から削る）ことは、正式にはサポートされていません。
まとめ：ARM64 を“完全に消す”のではなく、レイアウトを「痩せさせる」発想へ
本記事のポイントを最後に整理します。
- 現行の Visual Studio 2022 では、ARM64 バイナリを完全にスキップする公式手段は存在しない。
--archの既定値は「x64 製品バイナリを中心にしたレイアウトを作る」ことを意味するが、一部 ARM64 パッケージは依存関係として含まれる。- ARM64 フォルダーの手動削除はサポート外であり、インストール失敗や将来の更新トラブルを招くリスクが高い。
- 実務的には、次のような方針でレイアウト全体を「痩せさせる」ことが最も安全で効果的。
--addと.vsconfigでワークロードを厳選する。--langで言語パックを必要な分だけに絞る。--includeRecommended/--includeOptionalの使い方を慎重に見直す。--verify/--cleanでレイアウトを定期的にメンテナンスする。
「ARM64 を一切含めない」という理想は現状の仕様では叶いませんが、レイアウトの設計と運用を工夫することで、ディスク容量や配布コスト、トラブル時の切り分けを大きく改善できます。これからオフラインレイアウトを整備する場合も、すでに運用中のレイアウトを見直す場合も、本記事の方針をベースに、自身の環境に合った“痩せた”レイアウト設計を検討してみてください。
コメント