配布先は、App Store、ストア外、研究室内テストの3つに分けて考えます。AppleはApp Storeへのビルド提出と、ストア外配布向けの公証を別の手順として案内しています。Mac研究用ソフトウェアを配るときは、最初に配布先を決め、その経路に合わせて署名と公証を進めてください。App Store Connectへのビルド提出手順とmacOSソフトウェアの公証準備で、それぞれの流れを確認できます。
判断： App Storeで公開するならApp Store Connect経由、ストア外で配布するなら通常はDeveloper ID署名と公証を検討します。研究室内テストでは、テスト対象や配布方法に応じて開発用署名と配布用署名を選びます。公証に通っても、研究作業の受け入れ確認が完了したことにはなりません。
高校・大学の研究者や開発者で、自作のmacOS解析ツールを指導教員、共同研究者、テスト担当者へ渡す方に向けています。
研究室の技術管理者が、内部テスト用アプリ、プラグイン、インストーラーの配布手順を整理する場合にも役立ちます。
手元にMacがない環境で、遠隔macOS環境を構築や受け入れ確認に利用できるか判断したい方も対象です。
配布先を決めて署名経路を選ぶ
「開発者のMacで動いた」だけでは、別のMacへ配布して実行できるとは限りません。誰が、どこから取得し、どの環境で使うのかを先に決めてください。
- App Storeで公開する場合： App Store Connectの提出・審査経路を使います。ストア外配布のDeveloper ID公証を、App Store提出の代わりに使うことはできません。ビルドのアップロード手順に沿って、提出対象とプロジェクト設定を確認します。
- ストア外で公開する場合： 通常はDeveloper IDで配布用コードに署名し、Appleの公証に提出します。Developer ID証明書の説明で、証明書の用途と作成条件を確かめてください。
- 研究室内でテストする場合： テスト担当者、対象のMac、配布方法から署名経路を判断します。チームの権限は一律ではないため、Apple Developerアカウントの役割と権限を確認し、所属チームの管理者にも必要な操作ができるか照会してください。
配布先を決めずに署名すると、公開直前に証明書やビルド設定を見直すことになりかねません。受け取り手と配布方法を短く記録し、関係者間で認識をそろえてから作業を始めると、手戻りを防ぎやすくなります。
ビルド前にアカウントとプロジェクトを整える
ストア外配布では、Developer ID証明書を利用できるアカウントか、チームで必要な操作を行えるか、プロジェクトの署名設定が配布先に合っているかを確認します。証明書の名称だけで判断せず、用途と署名対象を照合してください。
公証に向けては、署名状態に加えてhardened runtimeや必要なentitlementを点検します。アプリが使う機能に合わせて設定し、必要性を確認せずに権限を追加しないでください。AppleのMac向け配布コード署名ガイドとコード署名サービスの資料を参照し、プロジェクトの設定と配布対象を照合します。
- [ ] 配布先がApp Store、ストア外、研究室内テストのどれか決まっている
- [ ] チームアカウントで証明書の管理に必要な権限を確認した
- [ ] アプリの識別子と署名設定が配布先に合っている
- [ ] hardened runtimeとentitlementを、アプリが使う機能に合わせて確認した
- [ ] 署名のタイムスタンプ設定を確認し、使用するツールの手順を把握した
- [ ] アプリ本体のほか、同梱するフレームワーク、ヘルパー、プラグインを洗い出した
- [ ] 配布する最終ファイルの形式と、公証の提出方法を決めた
署名から公証結果の確認まで進める
ストア外配布では、署名、提出、公証結果の確認、配布物の検証を順に行います。Xcode Organizerとコマンドラインのどちらを使うかは、プロジェクトの構成や自動化要件に応じて選んでください。Appleの公証ワークフローのカスタマイズ方法を参照し、使う方法が対象の納品物に合うか確認します。
処理状況は、次のように区別して記録します。
- アップロードの受け付け： 提出データが処理に渡った状態です。公証を通過したことを意味しません。
- 公証の処理結果： 返された結果とログを確認し、指摘事項や警告がないか調べます。公証に関する一般的な問題の対処資料を使い、ログの内容に応じて修正してください。
- チケットの反映： 公証結果が実際に配布するファイルに結び付いているか確かめます。
- 利用者側の動作： 配布経路からインストールし、起動、ファイル入出力、必要なプラグインの読み込みを試します。
アプリ本体に署名があっても、同梱コンポーネントに署名漏れがあれば問題が残ることがあります。公証に失敗した場合は、ログで対象と指摘内容を特定し、署名対象、entitlement、梱包方法を見直してから再提出してください。「送信できた」と「公証を通過した」を同じ状態として扱わないことが重要です。
アプリ以外の納品物も最終形で検査する
研究用ソフトウェアは、アプリだけでなく、コマンドラインツール、プラグイン、インストーラー、ディスクイメージとして配布されることがあります。形式によって検査すべき対象が異なるため、通常のアプリ向け手順を機械的に当てはめないでください。Macソフトウェアのパッケージ作成資料で、実際の梱包方式に対応する手順を確認します。
コマンドラインツールは、利用者が実行するファイルと同梱の実行ファイルを確認します。プラグインはホストアプリとの互換性や配置先も検査対象です。インストーラーやディスクイメージの場合は、内部のアプリだけでなく、利用者へ渡す最終ファイルまで含めて確認してください。
研究室内テストでは、開発者の環境だけで動く状態を合格にしないことが大切です。担当者が実際に受け取る経路からファイルを取得し、対象のMacでインストールと起動を試します。その後、研究で使う入力データ、出力形式、解析手順を確認し、公証の結果とは別に受け入れ判定を記録します。
よくある疑問
ストア外配布ではどの署名と公証の手順を使いますか
不特定の利用者へストア外で配布する場合は、通常、Developer IDによる配布用署名と公証を検討します。アプリ本体だけでなく、同梱コンポーネントやインストーラーなど、最終的な納品物に含まれる対象を確認してください。提出方法はアプリの構成に合わせ、Appleの公証要件と梱包形式の資料に照らして決めます。
Developer IDと開発用署名はどう使い分けますか
開発用署名は開発中やテストで使い、Developer IDはMac App Storeを通さない配布で使うのが基本です。研究室内テストでも、対象者や配布方法によって選ぶ経路が異なります。アカウントの役割、テスト端末、配布範囲を確認し、開発用の設定を公開配布へそのまま流用しないでください。
公証後もログ確認とインストール試験が必要なのはなぜですか
提出が受け付けられただけでは、公証の処理が完了したことや、利用者のMacでアプリが動くことは確認できません。処理結果とログを読み、チケットが最終配布物に反映されているかを確かめたうえで、実際の配布経路からインストールと起動を試します。研究データを使う受け入れ確認も別に行います。
手元にMacがなくても構築と配布前確認を進められますか
遠隔のmacOS環境を使えば、Mac上で必要なビルド、署名、初回起動の確認を進められる場合があります。ただし、遠隔接続や公証の通過だけで、研究室のデータや解析手順が正しいと確認できるわけではありません。ビルド情報、署名状態、公証ログ、クリーンな環境でのインストール結果をそれぞれ記録してください。
リリース記録に構築と受け入れの結果を残す
手元にMacがない場合、WindowsやLinuxの端末、研究室のHPC環境だけでは、macOS上のビルド、署名、初回起動を同じ条件で確認できません。遠隔macOS環境はその工程を補える場合がありますが、接続できること、公証に通ること、研究の作業手順が完了することは別々の確認事項です。
GPUMiniでは、データセンターのMacへVNC、SSH、ウェブコンソールから接続でき、root権限で操作できます。利用期間は週、月、四半期単位から選べます。環境の詳細はGPUMiniのサービス説明で確認し、所属機関のデータ管理規定に合うか、利用前に判断してください。
リリース前には、次の項目を記録します。
- [ ] ビルドを識別するバージョン情報と作成条件
- [ ] 署名対象と署名状態、利用した証明書の種類
- [ ] 公証の提出結果とログ。受け付けと通過は分けて記載
- [ ] 最終配布ファイルのインストールと初回起動の結果
- [ ] 研究室で使うデータ、プラグイン、解析手順の確認結果
- [ ] 確認に使ったmacOS環境と再現に必要な条件
接続方法や利用上の確認事項を事前に整理する場合は、GPUMiniのヘルプセンターも参照できます。機密データを扱うときは、所属機関の規定と利用環境の条件を先に確認してください。公証は配布に関する確認であり、データ管理の適合性や研究結果の正しさを証明するものではありません。
手元のMacを購入する方法は、継続的に使える一方で初期費用がかかり、共用機だけに頼る方法は必要な時期に利用できないことがあります。WindowsやLinuxの環境は既存の解析基盤として有効ですが、macOS専用アプリのビルドや初回起動の確認までは代替できません。短期のビルドやリリース前検証が目的なら、必要な接続方法と利用期間を確認したうえでGPUMiniの遠隔Macを比較してください。継続的な高負荷処理や物理ポートを使う検証では、遠隔環境が適さない場合もあります。
よくある質問
MacアプリをWebサイトなどから配布する場合、どの署名経路を選べばよいですか？
不特定の利用者へストア外で配布する場合は、通常、Developer IDで配布用に署名し、Appleの公証に提出する流れを検討します。実行ファイルだけでなく、同梱するフレームワークやヘルパーなども確認してください。アプリの形式や梱包方法によって必要な確認が異なるため、提出前にAppleの公証要件と配布形式の資料を照合します。
Apple Developer IDと開発用の署名は、どのように使い分けますか？
開発用の署名は、開発中のアプリをチーム内や登録済みのテスト環境で扱う目的に使われます。一方、Developer IDは、Mac App Storeを通さずに利用者へ配布するための署名経路です。どちらを使うかは、受け取り手が誰か、どこからアプリを入手するかを基準に決めます。アカウントの役割と証明書の利用条件も事前に確認してください。
公証の提出が受け付けられたのに、ログやインストール確認が必要なのはなぜですか？
提出データの受け付けは、公証の審査が完了したことや、利用者のMacで正しく起動することを示しません。処理結果を確認し、ログに示された問題がないか調べたうえで、最終的な配布物に公証の結果が反映されているかを確かめます。さらに、利用者に近い環境でインストールと起動を試し、科研ワークフローで必要な入力や出力も確認します。
手元にMacがなくても、研究用アプリの構築から配布前確認まで進められますか？
Macが必要なビルド、署名、初回起動の確認は、利用可能な遠隔macOS環境を使って進められる場合があります。ただし、接続できることや公証に通ることだけでは、研究室の実験手順や解析結果まで検証したことにはなりません。ビルド識別情報、署名状態、公証結果、実データを使った受け入れ確認を別々に記録してください。
署名と公証の検証に、専用のクラウドMacを
GPUMiniなら、専用物理Mac miniで署名から公証、配布前の確認まで一連の工程を試せます。