Apple notarytool企業CIの構築方法：2026年デプロイガイド

Apple notarytoolを企業CIへ組み込むなら、ビルドと署名、公証の提出、状態確認、票の処理、最終検証を別々の追跡可能な工程にしてください。Xcodeやstaplerを使う工程はMac上で検証し、Notary APIは提出や状態照会の一部を置き換える選択肢として扱います。

対象となるのは、Mac App Store外へmacOSアプリを配布するチームです。
CI基盤と認証情報を管理するIT担当者、リリース成果物を承認するエンジニアにも役立ちます。
今週は、実際の配布形式と署名済み成果物を決め、工程ごとに誰が何を確認するかを書き出してください。

配布経路を先に決め、CIの責任範囲を定義する

ここで扱うmacOS公証は、Mac App Store外で配布するソフトウェアの公証です。AppleはDeveloper IDで署名した配布ソフトウェアの公証方法を案内していますが、公証はApp Reviewと同じ審査ではありません。まず、対象がアプリ、インストーラーパッケージ、ディスクイメージのどれなのかを決め、実際に利用者へ渡す形式を受け入れ対象にします。Appleの公証要件とDeveloper IDの配布案内を基準にしてください。

失敗しやすいのは、CIジョブが緑色になったことを成果物の配布可能性と取り違えることです。署名対象と提出対象が食い違う、認証情報を複数のジョブへ広く渡してしまう、公証の受理後に配布ファイルを作り直して検証しない、といった問題はそれぞれ別の確認点です。ビルド成功、署名検証、公証結果、最終ファイルの検証を個別の証跡として扱います。

比較表でnotarytoolとNotary APIの担当を分ける

notarytoolは、Mac上で構築した配布物をコマンドラインから提出し、状態やログを確認する選択肢です。Notary APIは、Appleの説明する提出・状態確認の操作の一部をAPI経由で扱う経路ですが、XcodeによるビルドやMac固有ツールを必要とする工程まで置き換えるものではありません。公証ワークフローのカスタマイズとNotary APIの提出手順を照合します。

評価は、Mac固有工程との連携、監査記録の残しやすさ、認証情報の取り扱いという観点での運用判断です。Notary APIを選んでも、ビルドや署名が不要になるわけではありません。APIの実装を選ぶ場合は、Notary APIの提出仕様と認証要件を読み、実際のCIで再現できるかを確かめます。

第一段階：署名済み成果物を追跡可能にする

配布用のDeveloper ID署名を行い、対象アプリに適用されるHardened Runtimeなどの署名要件を確認します。Hardened Runtimeの設定は機能要件と関係するため、許可項目を慣例で追加せず、アプリが必要とする理由と動作確認を記録してください。AppleのHardened Runtime説明とDeveloper IDの案内に沿って、開発用ビルドと配布用ビルドを区別します。

CI記録では、コミット、ビルドジョブ、署名に使ったID、出力された配布物をひも付けます。公証へ渡すファイルが、その署名済みビルドと同一であることも確認します。開発版の署名をそのまま配布に使えると決めつけず、配布経路に適したIDとプロビジョニング条件を確認してください。Organizerを使うかスクリプト化するかは、手動確認の必要性、再現性、既存のリリース承認手順で選びます。

第二段階：認証情報の保管先と読み取り権限を絞る

Appleの資料に沿って、チームが使う認証方式を選びます。App Store Connect APIキーを使う場合は、キーの作成と権限をAppleのAPIキー手順で確認し、Appleアカウントを使う経路とは設定を混在させないでください。

秘密値をソースコード、設定ファイル、コマンド履歴へ固定せず、CIのシークレット管理から公証が必要なジョブだけに渡します。署名処理の担当と公証の認証情報を読み取れる担当を分け、ログにキーやパスワードが出力されないことをテストします。保管責任者、失効・更新の手順、異動や退職時の権限撤回も運用記録に含めます。

認証情報をマスクする設定だけでは、スクリプトが秘密値を別の形で出力する事故までは防げません。テスト用ジョブでログと成果物の双方を確認し、必要のない工程には認証情報を渡さない設計にしてください。

第三段階：提出IDから最終配布物まで記録する

対象のアプリやコンテナを選び、notarytoolで提出する場合は、提出結果に含まれるsubmission IDをCI記録へ保存します。Appleのワークフロー資料で示される提出、状態確認、ログ取得の流れに従い、アップロード完了と公証完了を別の状態として扱います。Notary APIを使う場合も、公式の提出手順に合わせて、認証方式と応答の記録を実装します。

公証結果が失敗またはInvalidの場合は、submission IDを使ってAppleが返すログを取得し、問題箇所を署名、ランタイム設定、提出物の構成に分けて調べます。修正した後は、変更後の成果物と再提出記録を関連付け、どの修正で結果が変わったか追えるようにします。原因の特定前にCIの再実行だけを繰り返すと、提出対象とログの対応が曖昧になります。

FAQ：CIへの組み込みで迷いやすい点

Notary APIを使えばMac CIは不要ですか？
不要にはなりません。APIで代替できるのはAppleが示す提出や状態照会の一部であり、Xcodeを使うビルドや、Mac上で実行する必要があるstaplerの工程は別に評価します。実際の流水線でどの処理をMac上に残すかを、成果物の生成から配布まで試して決めてください。

公証の受理後、リリース前に何を確認しますか？
配布形式に応じて票をstapleし、stapler validateなどで最終対象を検証します。Appleの資料に沿った適用条件を確認し、ZIP自体へ直接stapleできるとは扱わないでください。受理後に再圧縮や再パッケージを行った場合は、その最終配布物を改めて点検し、失敗時のログと提出IDも保存します。

放行判定：工程ごとの証跡でMac CIの担当を決める

本番リリース前に、ビルド、署名、提出、状態確認、票の処理、配布ファイルの検証を通した一連の試験を行います。各段階で入力と出力、実行主体、失敗時に参照する記録をそろえ、CI成功の表示だけで放行しない条件を定義します。

• Xcodeによるビルドや署名があるなら、その工程をMac環境で検証します。
• Appleの説明するAPI操作だけを分離したいなら、Notary APIを試し、認証と応答記録を確認します。
• staplerを含む配布処理があるなら、配布形式ごとに実際の最終成果物で検証します。
• 人手の承認を残すなら、誰が公証ログと配布物を照合するかをリリース手順に明記します。

ここで決めるべきなのは「APIかMacか」ではなく、どの工程がMac固有で、どの操作をAPIへ切り出せるかです。CI全体を自社購入Macだけで運用すると、調達や保守、利用終了時の処理を自社で担うことになります。一方、既存のホスト型実行環境だけに寄せると、Xcodeやstaplerを含む実際の配布工程を同じ条件で確認できるか、運用前に検証が必要です。

短期の検証や一時的なMac CI枠が必要なら、VPSMACのMac環境の案内を確認し、必要なMac固有工程を載せられるか、利用条件と責任分界を照合してください。自社管理が必要な長期・継続負荷や物理接続を要する作業では購入機が適する場合もあります。候補を具体化する際は、Macノードの案内と自社の受入試験を突き合わせ、未検証のセキュリティ、性能、コストを前提にせず判断します。