hdiutil は macOS 27 で非推奨に。後継はすでに出荷済みです

macOSTahoe ·
hdiutil は macOS 27 で非推奨に。後継はすでに出荷済みです

Apple は macOS 27 で hdiutil を非推奨とし、diskutil image への移行を進めています。この新コマンドはすでに現行 Mac に搭載済みです。ただし、日常的に使っている機能の一部が欠けています

macOS 27 Golden Gate の man ページには、これまで存在しなかった一文が追加されています。

In macOS 27.0, hdiutil is deprecated. Use diskutil image instead for all disk image operations.

hdiutil は Mac OS X 10.0 の時代から、Mac 上でディスクイメージを作成・マウント・変換・検査するための標準手段でした。.dmg を配布したことがある人、インストーラーをスクリプト化した人、Mac アプリをパッケージ化する CI ジョブを組んだ人、あるいはプライバシー保護のために暗号化コンテナを作ったことがある人なら、直接であれ間接であれ、必ずこのコマンドのお世話になっています。

多くの報道が見落としている点があります。**後継コマンドは「これから来る」のではなく、「すでに手元にある」**のです。今すぐ macOS 26 Tahoe のターミナルを開いて diskutil image を実行してみてください。ちゃんと応答が返ってきます。

要点まとめ

  • diskutil image はすでに macOS 26 で動作します。 macOS 26.5.2（ビルド 25F84）で検証済みです。macOS 27 のリリースを待たずに、今日からスクリプトの移行とテストが可能です。
  • 非推奨は削除ではありません。 macOS 27 でも hdiutil は引き続き動作します。導入初日に何かが壊れることはありません。ただし Apple はこの7年間、じわじわとこのツールを削り続けてきており、man ページにはその過程がすべて記録されています。
  • コマンドの守備範囲は大幅に縮小しています。 hdiutil は23個のサブコマンド（verb）を公開していますが、diskutil image はわずか5個です。
  • detach は存在しません。 diskutil image でディスクイメージを attach（マウント）することはできますが、detach（アンマウント）はできません。それは diskutil eject に移動しました。
  • verify、compact、makehybrid など、代替手段が今のところ一切ないものもあります。 ビルドスクリプトでこれらを使っている場合、現時点での移行パスは存在しません。

まず：自分の Mac で確認する

私の言葉を鵜呑みにせず、まずはコマンド一つで確かめてください。

diskutil image

macOS 26.5.2 では、以下のように出力されます。

OVERVIEW: Manipulate disk images (attach, create, etc)

USAGE: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

SUBCOMMANDS:
  attach                  Attach a disk image as a device.
  info                    Print info regarding a disk image.
  create                  Create a disk image. Either blank or from an existing
                          source (disk, disk image or folder).
  resize                  Resize a given image to a specified size if
                          applicable.
  chpass                  Change the passphrase of a given encrypted image.

サブコマンドは5個です。これを、hdiutil 自身の man ページに載っている一覧と比較してみましょう。

Common verbs include attach, detach, verify, create, convert, and compact.

The rest of the verbs are currently: help, info, burn, checksum, chpass,
erasekeys, imageinfo, isencrypted, mountvol, unmount, plugins, udifrez,
udifderez, resize, segment, makehybrid, and pmap.

23個のサブコマンド対5個です。この比率だけを見ると衝撃的に思えますが、単純にサブコマンド数を1対1で比較するのは正しい結論を導きません。というのも、hdiutil の複数のサブコマンドは名前を変えて diskutil image に統合されており、いくつかはすでに何年も前から非推奨だったもので、さらに一つの重要な機能はまったく別のコマンドへと移動しているからです。

どれがどれに該当するのかを整理することこそが実質的な「移行作業」なので、きちんと見ていきましょう。

突然の出来事ではない

移行表を見る前に、この非推奨化がそれほど唐突なものではないと分かる背景を押さえておきましょう。hdiutil の man ページには互換性に関するセクションがあり、これは Apple が7年かけてこのツールの範囲を狭めてきた記録として読めます。これは今すぐあなたの Mac 上で確認できます。man hdiutil を実行し、バージョンの見出しを探してみてください。

macOS 10.15

  • ULMO フォーマットに lzma 圧縮を導入
  • OS 9 由来のデュアルフォークファイルサポート（hdiutil flatten/unflatten）を非推奨化
  • 非推奨だった hdiutil internet-enable コマンドと IDME の attach フラグを削除

macOS 11.0

  • DiskCopy42、DART、NDIF フォーマットのサポートを削除
  • AppleSingle および MacBinary エンコーディングのサポートを削除
  • OS 9 由来のデュアルフォークファイルサポートを削除
  • 新規イメージのデフォルトファイルシステムを APFS に変更

macOS 12.0

  • UDBZ フォーマット（bzip2 圧縮）を非推奨化
  • セグメント化された UDIF イメージ（hdiutil segment、-segmentSize）を非推奨化
  • hdiutil udifrez/udifderez（リソースの埋め込みと抽出）を非推奨化

macOS 13.0

  • encrypted-encoding-version オプションを削除。新規に作成する暗号化イメージはすべてバージョン2を使用

man ページにはさらに、-passphrase が安全でないこと、セグメント化イメージが非推奨であること、UDBZ が非推奨であることも、それぞれの箇所にインラインで明記されています。

一連の流れとして読むと、macOS 27 での非推奨化は、2019年ごろから続いてきたプロセスの最終段階であり、この夏に突然下された決定ではないことが分かります。これは計画を立てるうえで重要です。Apple はこのツールから機能をゆっくりと取り除いており、その都度まず man ページで告知してきました。macOS 27 の hdiutil は非推奨ですが削除されたわけではなく、削除時期も現時点でアナウンスされていません。

移行対応表

これが実際の対応関係です。以下はすべて macOS 26.5.2 上で検証済みです。

やりたいことhdiutildiskutil image
イメージをマウントhdiutil attach x.dmgdiskutil image attach x.dmg
イメージをアンマウントhdiutil detach /dev/diskNdiskutil image には存在しない — diskutil eject /dev/diskN を使用
空のイメージを作成hdiutil create -size 1g -fs APFS x.dmgdiskutil image create blank --size 1g x.dmg
フォルダからイメージを作成hdiutil create -srcfolder ./dir x.dmgdiskutil image create from ./dir x.dmg
フォーマットを変換hdiutil convert in.dmg -format UDZO -o out.dmgdiskutil image create from in.dmg out.dmg --format UDZO
イメージを検査hdiutil imageinfo x.dmgdiskutil image info x.dmg
暗号化されているか確認hdiutil isencrypted x.dmgdiskutil image info → Is Encrypted:
リサイズhdiutil resize -size 2g x.dmgdiskutil image resize
パスフレーズを変更hdiutil chpass x.dmgdiskutil image chpass x.dmg
チェックサムを検証hdiutil verify x.dmg代替なし
スパースイメージをコンパクト化hdiutil compact x.sparsebundle代替なし
ハイブリッド／ISO イメージを作成hdiutil makehybrid代替なし
ライセンス契約を埋め込むhdiutil udifrez代替なし（macOS 12 で非推奨化済み）
光学メディアに書き込むhdiutil burn代替なし

convert に関する誤解

初期の論評で最もよく見かける誤りは「convert に相当するものがない」というものです。実際にはあります。名前が違うだけです。

OVERVIEW: Create a disk image from an existing source (disk, disk image or
folder).

Source and destination disk image can be the same, which will perform the
conversion in place.

diskutil image create from はディスクイメージをソースとして受け取れるため、これは名前を変えた hdiutil convert に他なりません。しかもインプレース変換（同じファイルをソースかつ出力先にする変換）にも対応しており、これは hdiutil convert にはできなかったことです。ヘルプの本文を読まずにサブコマンドの個数だけを数えると、実際には機能が拡張されているのに、機能が失われたと誤解してしまいます。

detach の欠落は本物

こちらはリネームではありません。diskutil image のどこを探しても detach は存在しないのです。

$ diskutil image detach /dev/disk12
Error: 2 unexpected arguments: 'detach', '/dev/disk12'
Usage: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

代替はトップレベルの diskutil コマンドです。

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

これ自体は問題なく動作しますが、スクリプトへの影響には注意が必要です。hdiutil attach / hdiutil detach というきれいな対称性は、diskutil image attach / diskutil eject という、同じバイナリの異なる階層のサブコマンドに置き換わります。attach と detach をペアで扱うラッパー関数があるなら、単純な文字列置換ではなく、構造そのものの見直しが必要になります。

ディスクイメージ用スクリプトの移行

diskutil image が優れている点

これを純粋な劣化として片付けるのは公平ではありません。明確に改善されている点が3つあります。

hdiutil ではまったく作れない ASIF

diskutil image は Apple Sparse Image Format（ASIF）に対応しています。hdiutil は対応していません。ASIF が欲しい場合——APFS 上の仮想マシンディスク用として、Apple が明らかに推し進めている方向のフォーマットです——diskutil image だけがこれを生成できます。

対応フォーマットの一覧は知っておく価値があります。

create blank --format : RAW, ASIF, UDSB          (default RAW)
create from  --format : ASIF, RAW, UDRO, UDSB,
                        UDZO, ULFO, ULMO         (default ULFO)

HTTP 経由での attach と、RAM ディスクの直接作成

attach のヘルプから抜粋します。

Supports 'ram://<size>', file paths, http[s].

Mac で RAM ディスクを作る作業は、伝統的に hdiutil attach -nomount ram://<sectors> を実行してから newfs_hfs または diskutil eraseVolume を続けるという、扱いにくい2段階の手順でした。それが、ドキュメント化された一つのフラグへの引数だけで済むようになっています。

大幅な高速化

Lapcat Software の Jeff Johnson は、2026年8月上旬にこの非推奨化を調査する中で両者をベンチマークし、diskutil image は作成処理を40〜45秒で完了させたのに対し、hdiutil は110〜115秒かかり、しかも生成されたイメージのサイズも diskutil image の方が小さかったと計測しています。これは誤差の範囲ではありません。コミットのたびにディスクイメージをビルドする CI ジョブにとっては、無視できない差です。

スクリプトで実際に壊れるもの

非推奨警告そのものはビルドを壊しません。壊すのは以下のような要素です。

1. -puppetstrings に代替がない

hdiutil の -puppetstrings フラグは、機械可読な進捗出力を出すもので、まさにビルドシステムが求める機能です。Johnson もこの欠落を注目すべき点として挙げています。diskutil image には構造化された結果を出す --plist がありますが、進捗自体は次のような人間向けのテキストとして出力されます。

[5% completed] [79% completed] [98% completed] [100% completed]
test.dmg created

hdiutil の PERCENT: 行をパースするツールを持っている場合、そのパーサーには読み取る対象がなくなってしまいます。

2. create の複数のオプションが単純に消えている

Johnson のまとめによると、-[no]crossdev、-[no]scrub、-[no]anyowners、-skipunreadable、-[no]atomic、-copyuid には対応するものがありません。フォルダから厳密な条件でイメージを作っている場合——インストーラー、フォレンジック用のキャプチャ、所有権や含めるファイルを正確に制御しなければならないケース全般——このリストは注意して読んでください。特に -skipunreadable と -copyuid は、一部のパッケージングスクリプトにとって不可欠な機能です。

3. スクラブ動作が静かに変化している

Johnson の報告によると、diskutil image はゴミ箱フォルダなどの一時ファイルを自動的に除外し、常に -scrub が有効な状態であるかのように振る舞います。hdiutil は明示的に指定した場合のみスクラブを行っていました。イメージの中身がソースディレクトリとバイト単位で一致している必要がある場合、これは何の警告もなく異なる中身のイメージを生成してしまいます。

4. パーミッション処理が静かに失敗する

これは真っ先にテストすべき項目です。Johnson の検証によると、hdiutil は root 所有のファイルに当たると認証プロンプトを表示するのに対し、diskutil image はプロンプトを出さず、そのまま失敗します。以前は認証情報の入力待ちで一時停止していたスクリプトが、今では不完全なイメージを生成し、エラーハンドリング次第では成功したかのように報告してしまう可能性があります。

自分が所有していないファイルを含むディレクトリからイメージを作る場合は、終了コードを信用せず、出力内容そのものを検証してください。

5. ログが薄い

diskutil image の verbose 出力は hdiutil に比べて詳細さに欠けます。深夜3時にビルドが失敗したとき、それを痛感することになるでしょう。

macOS 26 のサポートを崩さずに移行する方法

多くの人はしばらくの間、両方をサポートし続けなければなりません。良いニュースは——そしてこの記事全体で実務的に一番重要な点は——OS バージョンで分岐させる必要がないということです。なぜなら diskutil image は macOS 26 にもすでに存在するからです。

バージョンではなく、機能の有無を検出しましょう。

#!/bin/bash
# Prefer diskutil image; fall back to hdiutil where unavailable.

if diskutil image --help >/dev/null 2>&1; then
  USE_DISKUTIL=1
else
  USE_DISKUTIL=0
fi

make_image_from_folder() {
  local src="$1" dst="$2"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image create from "$src" "$dst" --format UDZO
  else
    hdiutil create -srcfolder "$src" -format UDZO "$dst"
  fi
}

attach_image() {
  local img="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image attach "$img" --nobrowse
  else
    hdiutil attach "$img" -nobrowse
  fi
}

detach_device() {
  # Note the asymmetry: detach is NOT under `diskutil image`.
  local dev="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil eject "$dev"
  else
    hdiutil detach "$dev"
  fi
}

そのうえで出力内容を検証してください。静かな差異が潜んでいるのはまさにここだからです。

# Compare what actually landed in the image against the source.
diskutil image attach build.dmg --nobrowse --mountPoint /tmp/verify_mnt
diff -rq ./src /tmp/verify_mnt/src
diskutil eject /tmp/verify_mnt

この diff -rq は省略すべきではないステップです。常時有効なスクラブ処理と、静かに失敗するパーミッション処理の両方を踏まえると、「ビルドが成功したイメージ」と「意図した中身がそのまま入っているイメージ」は同じものではありません。

Mac の開発環境をゼロから構築する場合は、Apple silicon 開発環境構築ガイドで周辺ツールについて、ターミナル活用ガイドでこれらのスクリプトが前提とするシェルの基礎について解説しています。

ディスクイメージの中身を検証する

実例：最初から最後まで

再現ではなく実際の出力を見てもらうため、macOS 26.5.2 上で実行した一連の流れをそのまま示します。

フォルダからイメージを作成する：

$ mkdir -p src && echo "hello" > src/file.txt
$ diskutil image create from src --format UDZO test.dmg
[5% completed] [79% completed] [98% completed] [99% completed] [100% completed]
test.dmg created

検査する：

$ diskutil image info test.dmg
Image Format: UDZO
Format Description: UDIF read-only compressed image (zlib)

	Identity Info:
		UUID: 061189CB-7502-4EA6-BFE3-424442C16D10

	Size Info:
		Empty Bytes: 3437056
		Total Bytes: 4233216

	Compression Info:
		Compressed Bytes: 4124
		Compression Type: zlib

	Encryption Info:
		Is Encrypted: 0

	Master Checksum Info:
		Checksum Type: crc32
		Checksum Value: c4 e3 90 4b

info が、かつて hdiutil imageinfo、isencrypted、そして checksum の一部が別々に提供していた情報をまとめてカバーしていることが分かります。ただし、これは保存されているチェックサムを「報告」しているだけで、「検証」はしていません。これが hdiutil verify の欠けている部分です。

マウントする：

$ diskutil image attach test.dmg
/dev/disk12  	GUID_partition_scheme
/dev/disk13s1	Apple_APFS_Volume    	/Volumes/src

アンマウントする——別のコマンドを使って：

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

暗号化イメージ

ディスクイメージを暗号化コンテナとして使っている場合、仕組み自体はシンプルですが、選べるオプションは以前より少なくなっています。

# Create an encrypted blank image
diskutil image create blank --encrypt --size 10g --volumeName Vault vault.dmg

# Provide the passphrase on stdin rather than interactively
printf '%s' "$PASSPHRASE" | diskutil image create blank --encrypt --stdinpassphrase \
  --size 10g --volumeName Vault vault.dmg

# Change the passphrase later
diskutil image chpass vault.dmg

--encrypt は AES-256 として文書化されており、アルゴリズムを選択する余地はありません。これは機能の喪失というより単純化です——Apple は古い暗号化エンコーディングバージョンを、すでに macOS 13 の時点で削除しています。

スクリプトで使うべきは --stdinpassphrase フラグです。hdiutil 自身の man ページも -passphrase は安全でないと警告しています。理由は単純で、コマンドラインに直接書かれたパスフレーズは、そのマシンを使う全ユーザーからプロセステーブル経由で見えてしまうからです。

利便性ではなくプライバシー保護のためにディスクイメージを利用しているなら、暗号化イメージが FileVault とどう位置づけが異なるのかについて、Mac のセキュリティとプライバシーガイドを読んでおく価値があります。両者は異なる問題を解決するものであり、暗号化された .dmg はマウントされている間は何も保護してくれません。

ディスクイメージがまだ使われている理由

ここまでの話が重要な理由を考える価値はあります。「ディスクイメージ」は遺物のように聞こえますが、周辺のツール群はいくつもの場面で静かに欠かせない役割を果たしています。

アプリの配布。 .dmg は、App Store 以外で Mac アプリを配布する際の標準的な手段であり続けています。アプリバンドルと /Applications へのシンボリックリンクを含む、圧縮された読み取り専用イメージは、ユーザーにおなじみの「ドラッグしてインストール」の作法です。そのすべては、ディスクイメージ用ツールを呼び出すスクリプトによって作られています。

暗号化コンテナ。 暗号化された .dmg は、ボリュームとしてマウントでき、特別なソフトウェアなしでどの Mac でも動作する、持ち運び可能な自己完結型ボルトです。ディスク全体を静止時に保護する FileVault とは異なり、暗号化イメージは特定のファイル群だけを保護し、USB メモリやクラウドストレージ、同僚への受け渡しなど、自由に移動させることができます。

仮想マシンのディスク。 ここが ASIF の重要性が発揮される場面であり、Apple の方向性が最もはっきり見える部分です。

ネットワークバックアップ用のスパースバンドル。 Time Machine がネットワーク先にバックアップする際、バックアップはスパースバンドル——変更されたバンドだけを同期すれば済むよう、多数の小さなバンドファイルに分割されたディスクイメージ——の中に保存されます。この運用経験がある人なら誰でも、削除されたバンドから空き容量を取り戻すために hdiutil compact を実行したことがあるはずです。

フォレンジックとアーカイブ。 チェックサム付きのボリュームのブロックレベルイメージは、ディスクの正確な状態を保存する手段です。そして hdiutil verify は、後からそれを確認する手段です。

このリストを移行対応表と照らし合わせると、欠落している機能はランダムではなく、特定のコミュニティに沿って並んでいることが分かります。アプリ開発者はライセンス契約の仕組みと -puppetstrings を失います。バックアップやスパースバンドルの利用者は compact を失います。アーカイブやフォレンジックの利用者は verify を失います。日常的な作成・変換・マウントといった作業だけを行っている人には、特に問題はありません。

ASIF：新しいツールだけが作れるフォーマット

Apple Sparse Image Format（ASIF）は、Apple がなぜ人々を hdiutil から遠ざけたいのかを最もはっきり示すものです。なぜなら hdiutil はこのフォーマットをまったく生成できないからです。

スパースイメージは、実際にデータが入っているブロックの分だけディスク容量を消費します。10GB のファイルを含む100GBのスパースイメージは、ディスク上では約10GBしか占有せず、データを追加するにつれて大きくなっていきます。従来の UDSP スパースイメージや UDSB スパースバンドルフォーマットも同じことをしていましたが、既知の問題を抱えていました。スパースバンドルは数千ものバンドファイルに断片化しやすく、両フォーマットとも歴史的に空き容量の回収が苦手で、これこそが hdiutil compact が存在しなければならなかった理由です。

ASIF は APFS の上に後付けされたものではなく、APFS を前提として設計されているため、イメージフォーマット側がスパースファイルの動作をエミュレートするのではなく、ファイルシステム自身が持つスパースファイルサポートに処理を任せることができます。実際のところ、この恩恵が最も現れるのは仮想化の場面です。VM の仮想ディスクは、ほとんど空でありながら絶えず変化する大きなファイルであり、これはまさに従来のフォーマットが最も苦しんできたケースです。

今すぐ作成できます。

# A 100GB ASIF image that occupies only what it uses
diskutil image create blank --format ASIF --size 100g \
  --volumeName VMDisk vmdisk.asif

# Convert an existing image to ASIF
diskutil image create from old.dmg new.asif --format ASIF

フォーマットは拡張子から自動的に推測される点に注意してください——create blank は「イメージパスが .asif または .sparsebundle 拡張子でない限り」デフォルトで RAW になります。ファイル名を正しく付けるだけで十分ですが、念のため --format も併せて指定しておくのが安全です。

トレードオフは可搬性です。ASIF は新しいフォーマットであり、古い macOS や Mac 以外の環境では開けません。VM のディスクやローカルの作業用ボリュームであれば、これは特に問題になりません。ただし他人に渡すファイルの場合は UDZO を使い、互換性を保ってください。

配布パイプラインにおける位置づけ

App Store 以外で Mac アプリを配布している場合、ディスクイメージ作成のステップは一連の工程の中間に位置しており、今回の変更がどこに影響するのかを見ておく価値があります。

#!/bin/bash
set -euo pipefail

APP="build/MyApp.app"
DMG="dist/MyApp.dmg"
STAGE="$(mktemp -d)"

# 1. Sign the app bundle (unchanged by any of this)
codesign --force --options runtime --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$APP"

# 2. Stage the contents the user will see
cp -R "$APP" "$STAGE/"
ln -s /Applications "$STAGE/Applications"

# 3. Build the image — the step this article is about
diskutil image create from "$STAGE" "$DMG" --format UDZO

# 4. Sign the image itself
codesign --force --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$DMG"

# 5. Notarize and staple
xcrun notarytool submit "$DMG" --keychain-profile "AC_NOTARY" --wait
xcrun stapler staple "$DMG"

rm -rf "$STAGE"

変更が入るのはステップ3だけです。署名、公証、ステープルは影響を受けません。これらは完成したイメージに対して動作するもので、どのツールがそれを作ったかは関知しないからです。

実際のパイプラインで注意すべき点が2つあります。まず、前述の静かなスクラブ処理とパーミッション動作があるため、ステージングした中身が正しく反映されているかを検証してください。$STAGE とマウント結果の間で diff -rq を取っておくのは安価な保険です。次に、現在のスクリプトが hdiutil udifrez でライセンス契約を埋め込んでいる場合、そのステップには代替手段がなく、しかも macOS 12 の時点ですでに非推奨とされています。それが存在するうちは hdiutil を残しておき、代替案を計画してください。

よくあるトラブルシューティング

「diskutil image: command not found」、またはサブコマンドが認識されない

問題：image サブコマンドが存在しない、macOS 26 より古いバージョンで実行している。

解決策：思い込みで判断せず、前述の機能チェックを使ってください。diskutil image --help >/dev/null 2>&1 は、その機能がないシステムでは非ゼロを返すため、信頼できる分岐条件になります。sw_vers でバージョンを判定するのはやめましょう。実際に気にすべきなのは、そのサブコマンドの有無そのものだからです。

イメージはビルドできるがファイルが欠けている

問題：考えられる原因は2つ。一つは diskutil image が自分のユーザーで読み取れなかったファイルをスキップし、かつ認証を求めなかった場合。もう一つは、常時有効なスクラブ処理によって hdiutil なら含んでいたはずの項目が除外された場合です。

解決策：作成結果をマウントし、ソースディレクトリに対して diff -rq を実行してください。所有権が原因でファイルが欠けている場合は、プロンプトを期待するのではなく、必要な権限でビルドを実行してください。終了コードだけを信用しないでください。

CI で進捗のパース処理が壊れた

問題：-puppetstrings に相当する diskutil image の機能がないため、hdiutil の機械可読な進捗出力をパースしていたスクリプトには、読み取る対象がなくなります。

解決策：構造化された結果には --plist を使い、進捗については取得できないものとして扱ってください。CI で進捗そのものが必要な場合は、そのステップだけ hdiutil を使い続けるのは妥当な判断です。非推奨であって削除されたわけではなく、削除時期もアナウンスされていません。

detach できない——「resource busy」

問題：何かがまだそのボリュームを開いたままにしています。これは以前から変わらない挙動です。

解決策：lsof +D /Volumes/YourVolume で使用元を特定し、diskutil eject を実行してください。Spotlight のインデックス作成やウイルス対策ソフトが原因であることが多く、--nobrowse オプション付きでマウントすることで、ボリュームを Finder から隠し、一部の問題を回避できます。

ライセンス契約付きの .dmg がビルドできなくなった

問題：ライセンス契約の仕組みは hdiutil udifrez に依存していますが、これは Apple により macOS 12 の時点で非推奨化されており、diskutil image にも対応するものがありません。

解決策：現時点で代替パスは存在しません。それが存在するうちは該当ステップで hdiutil を使い続け、埋め込み契約に依存しない配布方法を計画してください。この件はすでに4年前から予告されていたものであり、今初めて知ったという人にとっては覚えておく価値があります。

FAQ

macOS 27 でも hdiutil は動作しますか？

はい。非推奨ではありますが、削除はされていません。非推奨化とは Apple が意図を示し、時計の針を進め始めることであって、機能面での変更を意味するものではありません。今日動いているものが、macOS 27 をインストールした瞬間に動かなくなることはありません。

hdiutil はいつ実際に削除されますか？

Apple は明言していません。man ページ自体の履歴を見る限り、Apple のこのツールに対するパターンは、あるリリースで機能を非推奨化し、その1メジャーバージョン以上あとに削除する、というものです。internet-enable と OS 9 のデュアルフォークサポートも、それぞれ少なくとも1サイクルはかかっています。具体的な削除バージョンを断言する人がいたら、それは推測にすぎません。

macOS 26 Tahoe で diskutil image は使えますか？

はい。これがこの記事で最も実用的な事実です。macOS 26.5.2（ビルド 25F84）で検証済みです。macOS 27 を待たずに、今使っている OS 上でスクリプトを移行・テストできます。

diskutil image は hdiutil の完全な代替になりますか？

今のところ、いいえ。verify、compact、makehybrid、burn には代替がなく、含めるファイルを厳密に制御するための create オプションもいくつか欠けています。作成・変換・マウント・検査・リサイズ・暗号化という、よくある用途については十分完結しています。

なぜ Apple はこれをやったのですか？

Apple は理由を公表していません。観察できる事実としては、diskutil image はベンチマークで高速であり、より小さいイメージを生成し、hdiutil が作れない新しい ASIF フォーマットに対応しており、コマンド体系もはるかにシンプルだという点です。ディスクイメージの処理をストレージ管理全般とともに diskutil に統合していくのは、一貫した方向性と言えます。ただしこれは証拠からの推測であり、Apple の公式見解ではありません。

hdiutil を呼び出しているアプリは壊れますか？

macOS 27 では壊れません。とはいえ移行は計画しておくべきです。機能チェックを使えば1つのコードパスで両方をカバーできますが、これが見た目より簡単なのは、新しいコマンドがすでに macOS 26 に存在しているからに他なりません。

まとめ

「25年続いたターミナルコマンドが引退する」という見出しは事実ですが、両方向に誤解を招きます。verify、compact、makehybrid、あるいは細かい create オプションをビルドスクリプトで使っている人にとっては、現時点で先に進む道がないという意味で、この見出しは事態を過小評価しています。一方で、それ以外のすべての人にとっては、hdiutil は macOS 27 でも動作し続け、Apple は削除時期を一切アナウンスしておらず、今回の非推奨化は macOS 10.15 以来、そのツール自身の man ページに記録され続けてきた縮小過程の最終段階にすぎないという意味で、過大評価にもなっています。

本当に知っておく価値があるのは、後継コマンドが未来の話ではないということです。diskutil image は今すぐあなたの Mac 上に、macOS 26 の時点ですでに存在しており、create、attach、info、resize、chpass が動作します。今使っている OS のまま、火曜日の午後にでもこの移行作業を済ませ、diff -rq で検証し、それ以上悩む必要はなくなります。

ただし、detach が思っている場所にはないことだけは忘れないでください。

関連記事：Mac のターミナル活用術、Apple silicon 開発環境の構築、macOS 28 で暗号化 HFS+ ボリュームが廃止される件