TauriでmacOSアプリをビルド・署名・公証する完全ガイド

macOS 向け Tauri ビルド設定とパッケージ生成

macOS で配布する Tauri アプリは、ユニバーサル バイナリ（Intel と Apple Silicon の両方）を生成し、適切に署名・公証して初めて Gatekeeper を通過します。本セクションでは tauri.conf.json の基本設定から、x86_64 と arm64 両ターゲットを同時にビルドする方法までを解説します。

tauri.conf.json の基本設定

tauri.conf.json は macOS アプリのメタ情報を一元管理する重要なファイルです。ここで正しいバンドル ID・アプリアイコン・Entitlements への参照先を指定しておくことで、後続の署名や notarization がスムーズに進みます。

• identifier は逆ドメイン形式でユニークにする（例: com.acme.superapp）。
• icon には macOS 用 .icns を指定し、16 px〜512 px の各サイズが含まれることを確認。

Apple Silicon と Intel 両方を対象にしたビルドコマンド

macOS は Apple Silicon (arm64) が主流ですが、依然として Intel 搭載 Mac も多く存在します。そのため ユニバーサル アプリ を作るか、各アーキテクチャごとにバイナリを生成して配布するかを選択できます。以下は代表的なビルドパターンです。

ポイント
- --targets オプションは Tauri CLI ≥ 1.5 で利用可能です。古いバージョンを使用している場合は、個別にビルドした後に lipo -create でユニバーサル実行ファイルを手作業で結合できます。
- ビルドが完了すると .app, .dmg, .zip が自動生成されるので、次章の コード署名 にすぐ進めます。

Developer ID 証明書取得と安全なコード署名

macOS 配布に必須となる「Developer ID Application」証明書は、Apple の Gatekeeper を通過させるための鍵です。本章では 証明書作成から Keychain へのインポート までを一度だけ実行すれば以降再利用できる手順にまとめました。

証明書の作成・Keychain インポート手順（共通）

以下の手順は GitHub Actions、Azure Pipelines いずれでも流用できます。Acme Corp. と SuperApp は実際の組織名・アプリ名に置き換えてください。

1. Apple Developer ポータルで CSR を作成
   bash
openssl req -new -newkey rsa:2048 -nodes \
-keyout acme_superapp.key -out acme_superapp.csr \
-subj "/CN=Acme Corp./OU=Development/O=Acme Corp./C=JP"
2. ポータルに CSR をアップロードし、Developer ID Application 証明書（.cer）を取得。
3. 証明書とプライベートキーを PKCS#12 形式に変換（CI 用に Base64 エンコードしてシークレット化）
   bash
openssl pkcs12 -export \
-inkey acme_superapp.key \
-in DeveloperID_Application.cer \
-out acme_superapp.p12 -passout pass:YOUR_PASSWORD
base64 < acme_superapp.p12 > acme_superapp.p12.b64
4. CI ランナーでデコードし、Keychain にインポート（GitHub Actions の例は後述）。

重要：証明書ファイルは絶対にリポジトリに平文でコミットしないこと。必ず CI のシークレット機能を利用してください。

codesign と productsign の実践例

codesign は .app ディレクトリ全体、productsign は .pkg インストーラを対象とします。以下は Entitlements ファイル（次章で作成）を使用したサンプルです。

• --options runtime は Hardened Runtime を有効化し、Apple の公式ガイドでも必須とされています。
• 証明書名は Team ID（例: TEAMID）を正確に記載してください。

Entitlements の正しい設定と公式根拠

Hardened Runtime が有効なアプリでは、JIT コンパイルや外部ライブラリのロードに必要な権限（Entitlement）を明示しないと notarization に失敗します。本節では 必須 Entitlement とその公式ドキュメントへのリンクを添えて解説します。

必要最低限の entitlements.plist

• allow‑jit：Apple の Hardened Runtime ガイド（Hardened Runtime Entitlements – allow-jit）で必須と明記。
• disable-library-validation：外部ダイナミックライブラリを使用する場合に必要です（disable‑library‑validation）。

ベストプラクティス：不要な権限は付与しない。Entitlement が増えるほど審査リスクが高まります。

Notarization（公証）プロセスとツール選択

macOS 13 Ventura 以降は高速かつシンプルな xcrun notarytool が推奨されています。従来の altool はレガシー環境向けに残っているだけです。本章では ツール比較 と、notarize → staple のフローを具体的に示します。

notarytool と altool の比較と推奨使用法

結論：新規プロジェクトは必ず notarytool を採用し、レガシー環境が必要な場合にのみ altool にフォールバックしてください。

notarize & staple 実装フロー（共通）

1. 認証情報をキーチェーンプロファイルへ保存（一度だけ実行）
   bash
xcrun notarytool store-credentials "my-notary" \
--apple-id "$APPLE_ID" \
--team-id "$TEAM_ID" \
--password "@keychain:AC_PASSWORD"
2. パッケージ（DMG／ZIP）を送信し、完了まで待機
   bash
xcrun notarytool submit ./SuperApp.dmg \
--keychain-profile "my-notary" \
--wait \
--output-format json > notarize_result.json
3. staple（公証チケットの埋め込み）
   bash
xcrun stapler staple ./SuperApp.dmg
# 検証
xcrun stapler validate ./SuperApp.dmg
4. エラーログ取得（失敗時）
   bash
LOG_URL=$(jq -r .logFileURL notarize_result.json)
curl -O "$LOG_URL"

CI/CD パイプラインでの自動化（GitHub Actions・Azure Pipelines 共通）

手作業で行うと証明書漏洩やステップ抜けが起きやすくなります。ここでは シークレット管理 を中心に、両主要 CI プラットフォーム向けのワークフロー例を示します。

証明書とシークレットの安全な取り扱い

ポイント：CI ランナー上に残る証明書はビルド完了後に必ず削除し、ランナーの再利用時に情報が流出しないようにします。

GitHub Actions ワークフロー例（Apple Silicon 対応）

Azure Pipelines の設定例（共通ロジック）

トラブルシューティングとベストプラクティスチェックリスト

実務で遭遇しやすいエラーをまとめ、原因特定の手順 と 予防策 を提示します。CI に組み込むことで失敗を早期に検出できます。

代表的なエラーパターンと対処法

ベストプラクティスチェックリスト

最終的なポイント：
1. ユニバーサルビルド → --targets で両アーキテクチャ対応。
2. コード署名 は Hardened Runtime と Entitlement の組み合わせが必須。公式ドキュメントを参照し、不要権限は付与しない。
3. 公証 → notarytool + stapler が標準フロー。失敗時はログ URL を取得して原因分析。
4. CI/CD → 証明書・パスワードはシークレット化、ビルド後にキーチェーンを必ず削除。

これらの手順とチェックリストをプロジェクトに組み込めば、macOS 13+ の最新環境でも安全かつスムーズに Tauri アプリを配布できるようになります。