Apple siliconのMacに入れ替えた後も、以前から使っている業務ツールが問題なく動いているなら、それがIntel向けに作られたものかどうかを意識する機会はあまりありません。Rosettaという変換の仕組みが、利用者に見えないところで動かしているためです。
この前提が変わります。Appleは2026年9月1日の開発者向けの告知で、Rosettaの汎用の提供をmacOS 27で終えると案内しました。
macOS 27: Final release to support Rosetta — Intel-only apps will no longer run on Mac computers with Apple silicon after this update.
この記事では、Appleの告知と開発者向けのドキュメントをもとに、社内のMacを管理する担当者と、Macのアプリやツールを開発・配布しているチームが、今のうちに確かめておくことを整理します。
何が、いつ変わるか
告知とドキュメントの内容をまとめると、次のとおりです。
- macOS 26.4以降：Rosettaに頼るアプリを起動すると、Apple silicon向けの版に更新するよう促す通知が出ることがある
- macOS 27：Rosettaを汎用に使える最後の版。この後の版（Appleのサポート記事ではmacOS 28）では、Intel専用のアプリはApple siliconのMacで動かなくなる
- 例外：Intel向けの仕組みに依存する、保守されていない古いゲームのための一部の機能は残す
Rosettaのドキュメントも、Rosettaは「macOS 27まで」移行を助ける汎用の道具として提供し、その後はゲーム向けの一部の機能だけを残すと書いています。業務で使うツールは、この例外には当たらないと考えておくのが安全です。利用者向けのサポート記事「Appleシリコン搭載のMacでIntelベースのアプリを使用する」も、Rosettaを使えるのはmacOS 27以前で、次のmacOS 28からはメンテナンスされていない古いゲームに限って提供すると案内しています。
「アプリ」だけを見ると漏れる
Appleのドキュメント「Building a universal macOS binary」は、Intel（x86_64）とApple silicon（arm64）の両方で動くユニバーサルバイナリにすべきものとして、アプリだけでなく、次のようなものを挙げています。
- アプリの拡張機能、プラグイン
- 独自のフレームワーク、静的・動的ライブラリ
- ビルドツール、コマンドラインツール
- デーモン、ログイン時に動くエージェント（launch agents）
- DriverKitの拡張機能、カーネル拡張
特に気をつけたいのがプラグインです。Rosettaのドキュメントによると、1つのプロセスの中でarm64とx86_64のコードを混ぜることはできません。アプリ本体がユニバーサルでも、Intel専用のプラグインを読み込むために、Finderの「情報を見る」でRosettaを使って開く設定にしている場合があります（Appleのサポート記事によると、この「Rosettaを使用して開く」の設定は、アプリの開発者が用意した場合に表示されます）。Rosettaがなくなれば、この使い方はできなくなります。
また、Rosettaはもともと、カーネル拡張と、x86_64のPCを丸ごと再現する仮想マシンのアプリは変換できません。AVX512の命令も実行できないとされています。
Intel専用のファイルを見つける
まず、Macの標準の機能で確かめる方法があります。Appleのサポート記事によると、Finderでアプリを選んで「情報を見る」を開くと、「種類」の欄に「アプリケーション (Intel)」「アプリケーション (ユニバーサル)」「アプリケーション (Appleシリコン)」のいずれかが表示されます。macOS 27では、「システム設定」の「一般」にある「情報」で、「Intelベースのアプリケーション」の横の「詳細」ボタンから、Intelベースのアプリの一覧も開けます。ただし、この一覧に出るのは、最近使ったアプリと、一般的な場所に入っているアプリです。編集部ではこれらの画面を確かめていません。
プラグインやコマンドラインツールまで含めて調べるには、ファイルの中身を見る方法が向いています。Macのアプリやツールの実行ファイル（Mach-O形式）は、ファイルの先頭に、どのCPU向けのコードを含むかが書かれています。編集部では、指定したフォルダの下を調べて、x86_64だけを含むファイルを一覧にする小さなスクリプトを作りました。Python 3の標準の機能だけで動きます。
#!/usr/bin/env python3
"""指定したフォルダの下のMach-Oファイルを調べ、x86_64だけを含むもの（Intel専用）を一覧にする。"""
import os, struct, sys
CPU = {0x01000007: "x86_64", 0x0100000C: "arm64", 7: "i386"}
THIN = {0xFEEDFACF: ">", 0xCFFAEDFE: "<"} # 64ビットのMach-O（ビッグ／リトルエンディアン）
FAT = {0xCAFEBABE: 20, 0xCAFEBABF: 32} # ユニバーサル（fat）。値は1件分のバイト数
def archs(path):
with open(path, "rb") as f:
head = f.read(8)
if len(head) < 8:
return None
magic = struct.unpack(">I", head[:4])[0]
if magic in THIN:
cpu = struct.unpack(THIN[magic] + "I", head[4:8])[0]
return [CPU.get(cpu, hex(cpu))]
if magic in FAT:
n = struct.unpack(">I", head[4:8])[0]
if n > 20: # Javaのclassファイルも同じ先頭の値のため除外
return None
out = []
for _ in range(n):
cpu = struct.unpack(">I", f.read(FAT[magic])[:4])[0]
out.append(CPU.get(cpu, hex(cpu)))
return out
return None
for top in sys.argv[1:]:
for d, _, files in os.walk(top):
for name in files:
p = os.path.join(d, name)
if os.path.islink(p):
continue
try:
a = archs(p)
except OSError as e: # 読み取れないファイルは飛ばして知らせる
print(f"読めない\t-\t{p}（{e.strerror}）")
continue
if a:
mark = "Intel専用" if "arm64" not in a else "対応済み"
print(f"{mark}\t{','.join(a)}\t{p}")動作を確かめるため、npmで公開されている3つのファイルを使いました。esbuildのIntel Mac向けとApple silicon向けの実行ファイル（0.25.0）と、fseventsの拡張モジュール（2.3.3）です。あわせて、読み取りの権限がないファイル（locked/tool）を1つ置き、一般の利用者の権限で実行しました。結果は次のとおりで、3つのファイルの判定はLinuxの file コマンドの結果とも一致しました。
Intel専用 x86_64 darwin-x64/package/bin/esbuild
対応済み arm64 darwin-arm64/package/bin/esbuild
対応済み x86_64,arm64 fsevents/package/fsevents.node
読めない - locked/tool（Permission denied）社内のMacで使う場合は、/Applications や、業務ツールを入れているフォルダ、/Library/LaunchAgents などに置かれたプログラムの場所を引数に渡します。ただし、この記事を書いた環境はLinuxのため、編集部ではMacの上での実行は試していません。権限のないファイルは「読めない」として一覧に出ますが、中を開けないフォルダは何も表示されずに飛ばされます（Pythonの os.walk の既定の動き）。漏れを防ぐには、管理者の権限で実行し直すことも検討します。
見つかった後の進め方（編集部の提案）
ここからは編集部の整理です。
自社で開発・配布しているものは、ユニバーサルバイナリで作り直します。Appleのドキュメントによると、Xcode 12.2以降では、標準の設定（Standard Architectures）のままならリリース用のビルドは自動でユニバーサルになります。アーキテクチャの設定を個別に変えていたら、標準に戻すよう案内しています。Xcodeを使わず独自のスクリプトでビルドしている場合は、arm64向けにもビルドし、lipo で1つにまとめます。CIで作っている場合は、ビルドの設定と、成果物の確認（上のようなスクリプトでarm64を含むか調べる）を手順に入れておくと、Intel専用のものが混ざるのを防げます。
他社製のツールは、提供元にApple silicon向けの版があるかを確認します。更新が止まっているツールや、プラグインだけが古いものは、代わりを探す時間が必要です。
利用者への案内も必要です。告知は、Apple silicon向けの版をすでに出している開発者に対しても、利用者に最新の版を入れてもらうよう直接働きかけることを勧めています。社内では、通知が出たときに誰に連絡すればよいかを決めておくと、問い合わせが散らばりません。
Macの開発環境の準備の考え方はAIにiOS開発を任せる前のMac環境の準備で、開発用のMacの点検の例はeMudhraの中間CAの侵害を受けた開発端末の点検で扱っています。
確認した範囲
2026年10月27日に、Apple Developerのニュース「Upcoming changes to Rosetta support for Intel-based macOS apps」（2026年9月1日）と、ドキュメント「About the Rosetta translation environment」「Building a universal macOS binary」、利用者向けのサポート記事「Appleシリコン搭載のMacでIntelベースのアプリを使用する」（日本語版の公開日は2026年9月26日）を確認しました（資料調査）。上のスクリプトは、編集部の検証環境（Linux、Python 3）でnpmの3つのファイルに対して実行し、
fileコマンドの結果と照合しました（実機検証）。Macでのスクリプトの実行、Finderやシステム設定での表示、macOS 26.4の通知、macOS 27での動作は確認していません。
社内のMac向けツールの作り直しや、配布の仕組みの見直しは、開発・AI・自動化のご相談からお問い合わせください。
