ANTIGRAVITY LABEN
記事一覧/アプリ開発
アプリ開発/2026-05-02上級

Antigravity × Tauri 2 デスクトップアプリ本番デプロイ完全戦略 — 署名・自動アップデート・ライセンス認証まで

Tauri 2 で作ったデスクトップアプリを本番配布する際に必ずぶつかる、コード署名・自動アップデート・ライセンス認証・課金フローを、Antigravity のエージェントを使った実装・運用ノウハウとして体系化します。

antigravity416tauridesktop2code-signingnotarization2monetization15license

プレミアム記事

Antigravity × Tauri 2 デスクトップアプリ本番デプロイ完全戦略

Tauri 2 でアプリを完成させたあと、ほとんどの開発者が次に詰まるのは「コードを書く部分」ではありません。tauri build が通ったあとから本当の戦いが始まります。macOS の Notarization、Windows の SmartScreen 警告、自動アップデート、ライセンス認証、課金フロー — これらは公式チュートリアルがあえて深く触れない領域でありながら、有料アプリとして配布するなら避けて通れない関門でもあります。

私自身、個人で iPhone/Android アプリを長年運用してきましたが、デスクトップアプリは別の生き物です。ストアによる審査と配信に頼れない代わりに、自分でインフラを設計しなければなりません。ここではAntigravity のエージェントを活用しながら、本番運用に耐える Tauri 2 アプリのデプロイパイプラインをまるごと組み立てる方法を、実運用で得た落とし穴も含めて共有していきます。

なぜ Tauri 2 の「本番デプロイ」が独特の難所になるのか

Tauri が Electron に対して優位なのは、バイナリサイズと起動速度だけではありません。配布の自由度こそが本質です。Tauri 2 はネイティブインストーラを直接生成し、アップデート基盤も自由に選べる設計になっています。この自由度は強力ですが、同時に「すべて自分で設計しなければならない」責任を意味します。

Electron 系のフレームワークでは、electron-updaterelectron-builder の組み合わせで多くのことが自動化されます。Tauri 2 でも tauri-plugin-updater が用意されていますが、署名鍵の管理、配信エンドポイントの設計、段階的ロールアウトの仕組みは自前で組み上げる必要があります。Antigravity を使う最大の利点は、この「フレームワーク横断の設計判断」を AI エージェントと対話しながら詰められることです。具体的には、Antigravity の Manager Surface で「Rust バックエンドの署名検証」と「TypeScript フロントエンドのライセンス UI」を別エージェントに同時並行で書かせるパターンが本記事を貫く設計思想になります。

なお Tauri 1.x からの移行を検討している方は、Antigravity × Tauri デスクトップアプリ開発ガイド を先に読んでおくと、本記事の文脈が掴みやすくなります。

macOS の Notarization を Antigravity で自動化する完全フロー

macOS で配布する .dmg や .app は、単にコード署名するだけでは「開発元が未確認のため開けません」と表示されます。Apple のサーバーで Notarization(公証)を通し、その結果をバイナリに staple(貼付)するまでが必須の手順です。

私が運用しているフローでは、以下を 1 つのスクリプトに統合しています。Antigravity に「tauri build の後段で実行する notarize.sh を書いて。失敗時は GitHub Actions のジョブをエラー終了させ、エラーログを Slack 通知する」と指示すると、ほぼこの形のスクリプトが返ってきます。

#!/usr/bin/env bash
# notarize.sh - Tauri 2 macOS 公証パイプライン
# 前提: APPLE_ID / APPLE_TEAM_ID / APPLE_APP_PASSWORD / SIGNING_IDENTITY が環境変数に設定済み
set -euo pipefail
 
APP_PATH="src-tauri/target/release/bundle/macos/MyApp.app"
DMG_PATH="src-tauri/target/release/bundle/dmg/MyApp_1.0.0_universal.dmg"
 
# 1. .app に署名 (--options runtime が必須。これがないと公証で reject される)
codesign --force --deep --options runtime \
  --sign "$SIGNING_IDENTITY" \
  --entitlements src-tauri/entitlements.plist \
  "$APP_PATH"
 
# 2. ZIP に固める(公証は ZIP/DMG/PKG のみ受付)
ditto -c -k --keepParent "$APP_PATH" "MyApp.zip"
 
# 3. Apple サーバーへ公証リクエスト(同期待機)
xcrun notarytool submit "MyApp.zip" \
  --apple-id "$APPLE_ID" \
  --team-id "$APPLE_TEAM_ID" \
  --password "$APPLE_APP_PASSWORD" \
  --wait \
  --output-format json > notarize_result.json || {
    SUBMISSION_ID=$(jq -r '.id' notarize_result.json 2>/dev/null || echo "unknown")
    echo "❌ 公証失敗: $SUBMISSION_ID"
    # 失敗ログを取得して終了
    xcrun notarytool log "$SUBMISSION_ID" \
      --apple-id "$APPLE_ID" \
      --team-id "$APPLE_TEAM_ID" \
      --password "$APPLE_APP_PASSWORD" || true
    exit 1
  }
 
# 4. .app と DMG の両方に staple
xcrun stapler staple "$APP_PATH"
xcrun stapler staple "$DMG_PATH"
 
# 5. 検証(gatekeeper が受け入れるか最終確認)
spctl --assess --type execute --verbose=4 "$APP_PATH"
echo "✅ 公証完了: $DMG_PATH"

このスクリプトの肝は --options runtime と staple の二段階です。前者を忘れると Apple が「Hardened Runtime が有効でない」と reject し、後者を忘れるとオフライン環境のユーザーが「公証情報を確認できません」と弾かれます。両方とも一見わかりにくいエラーで返ってくるので、Antigravity の Sub-Agent に「notarize の結果 JSON を解析してエラーカテゴリを分類するスクリプト」を書かせておくと、運用がぐっと楽になります。

期待される出力は accepted のステータスと、staple 後に spctlsource=Notarized Developer ID を返すことです。これが Unnotarized Developer ID のままなら staple が失敗しています。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
Tauri 2 アプリを App Store 外で配布するときに必ず詰まる macOS Notarization と Windows EV 署名の壁を、Antigravity で再利用可能なスクリプトに落とし込んで突破できます
Cloudflare Workers と R2 で構築する自前の自動アップデート基盤を、ロールバック・段階的配信付きで本番運用レベルに仕上げる設計判断を習得できます
Stripe Checkout とオフライン検証可能なライセンスキー方式を組み合わせた収益化フローを、海賊版対策とユーザー体験の両立という観点から自分のプロダクトに応用できます
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

アプリ開発2026-06-30
Antigravity に任せた App Open 広告が、課金画面やリワード動画から戻るたびに出てしまう
Antigravity のエージェントに App Open 広告を実装させると、自前のリワード動画や Google Play の課金シートから戻った瞬間にも広告が出ます。AdMob のポリシー違反にも触れるこの挙動を、前面復帰の理由を記録するフォアグラウンド調停役で抑える設計を、動く Kotlin と検証手順つきで解説します。
アプリ開発2026-06-25
「広告を見たら壁紙を解放」をエージェントがクライアント側だけで付与していた — リワード報酬をSSVで検証し直した記録
リワード広告を見たら壁紙を解放する機能を Antigravity のエージェントに頼んだら、解放フラグをクライアント側だけで書き込む実装が返ってきました。なぜそれでは足りないのか、AdMob のサーバーサイド検証(SSV)で報酬付与を検証し直し、二重付与まで止めた設計を記録します。
アプリ開発2026-06-19
ATT を取る前に広告SDKを初期化していた — 初回起動だけ eCPM が下がる順序の罠
iOS の AdMob メディエーションを4本のアプリへ広げたとき、初回セッションだけ広告収益が落ちる現象に気づきました。原因は ATT 許諾と MobileAds 初期化の順序です。順序が効く理由と、Antigravity にその順序を監査させた実装記録をまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →