署名コマンドは通ったのに、公証結果や配布物が本当に有効か判断できない。
最短の対処は、Claude Codeにはコマンド実行を補助させ、署名・公証・最終パッケージをmacOSのツール出力で個別に検証し、責任者が公開を承認することです。
無常設のMacで公開準備を進めたい独立開発者向けです。
Claude Codeを含むビルド工程を監査可能にしたいリリース担当者にも役立ちます。
署名資格情報とクラウドMacの実行環境を管理するプラットフォーム担当者も対象です。
最初の判断:配布経路を分ける
まず、Mac App Storeで配布するのか、Apple Developer IDで署名して直接配布するのかを決めます。同じアプリでも、提出先と必要な確認が異なるため、片方の手順をもう片方に流用しないでください。
| 選択肢 | 主な目的 | 確認するもの | 公開ゲート |
|---|---|---|---|
| Mac App Store | App Store Connect経由で配布 | 配布用署名、アップロードしたビルド、審査に必要な情報 | アップロード結果と審査・公開状態 |
| Developer IDによる直接配布 | App Store外でMacアプリを配布 | Developer ID署名、公証の結果、チケットの添付、配布パッケージ | 署名・公証・最終パッケージの検証 |
Mac App Store向けは、ビルドをApp Store ConnectへアップロードするAppleの手順に沿って管理します。App Store外へ配る場合は、Mac向け配布署名の要件とAppleのmacOS公証ガイドを基準にします。
Claude Codeだけで署名から公開まで任せられますか?
コマンドの提案や実行補助はできますが、選ぶ署名ID、秘密情報を使わせる範囲、最終公開の承認まで委ねてよいことにはなりません。Claude CodeのCLI権限オプションを確認し、操作ごとに必要な権限を絞ってください。
ビルド工程:再現できる成果物を残す
Claude Codeが「ビルド成功」と説明しただけでは、リリース候補の証拠になりません。使用するXcodeまたは外部ビルドシステム、依存関係、対象アーキテクチャ、バージョン識別子を記録し、実際のコマンド出力と生成物を保存します。
作業前に、次の項目をプロジェクトの設定と照合してください。
- ビルド方法と使用するツールチェーン
- 依存パッケージの取得元と固定方法
arm64、x86_64など、配布対象となるアーキテクチャ- アプリのバージョン識別子と出力先
- 生成したアプリ、アーカイブ、ログを保管する場所
Xcodeを使うプロジェクトでは、たとえば次のようにアーカイブを作り、出力先とログを追跡します。スキーム名や保存先は実際のプロジェクトに置き換えてください。
xcodebuild archive \
-scheme "YourScheme" \
-destination "generic/platform=macOS" \
-archivePath "$PWD/build/YourApp.xcarchive"
これはコマンド例であり、成功を保証するものではありません。終了コード、生成されたアーカイブの存在、アプリの識別情報を確認し、必要に応じて配布用パッケージを作ります。Macソフトウェアのパッケージ作成に関するAppleの説明と照合し、プロジェクト固有の手順を決めてください。
資格情報の保護:実行環境を使い捨て前提で設計する
クラウドMac上で署名資格情報をどう扱えば安全ですか?
証明書や公証用の秘密情報を、リポジトリ、プロンプト、通常の作業ファイル、長期間残るログへ書き込まないでください。利用できる安全な資格情報管理手段から、担当者が管理する方法を選び、Claude Codeに見せる範囲と実行ユーザーを必要最小限にします。
公証では、Appleのカスタムワークフローにあるnotarytoolとキーチェーンプロファイルを使う構成が選択肢になります。資格情報を保存する場合も、実行環境の権限や存続期間を確認し、タスク終了後に削除または失効できる運用にしてください。Appleの公証ワークフローを参照し、秘密情報そのものは作業ログに出さない設計にします。
注意:共有ワークスペースに資格情報を残すと、後続タスクや別の利用者が読み取れる可能性があります。環境の引き渡し条件を決められない場合は、実際の署名鍵を使わずに手順を検証してください。
Developer ID配布:署名、公証、パッケージを別々に検収する
署名・公証・最終パッケージの順番はどう組み立てますか?
直接配布では、対象物を確定して署名し、その署名済みのアプリまたは配布物を公証サービスへ提出します。公証結果を取得した後、アプリや対応する配布パッケージにチケットを添付できる形式なら添付し、最後に配布予定の完成物を検証します。パッケージ形式により手順が異なるため、使用する形式に合わせてAppleの資料を確認してください。
Hardened Runtimeは公証に関わる要件です。対象アプリと実行ファイルの署名設定を確認し、例外を追加する場合は理由を記録します。Hardened RuntimeのApple公式説明を見ながら、署名オプションをプロジェクトの要件と照合してください。
次のコマンドは検証例です。アプリ名やキーチェーンプロファイルは、実環境の値に置き換えて実行し、出力をログとして保存します。
security find-identity -v -p codesigning
codesign --verify --deep --strict --verbose=2 "YourApp.app"
xcrun notarytool submit "YourApp.zip" \
--keychain-profile "notary-profile" \
--wait
xcrun stapler staple "YourApp.app"
xcrun stapler validate "YourApp.app"
codesign --verifyは署名の検証に使います。ここでの--deepは検証時の例であり、署名作成時に無条件で同じ指定を使うという意味ではありません。公証についても、提出処理が完了したという表示だけで配布可能と判定せず、結果、ログ、チケットの添付状態、最終成果物の検証を別々に確認します。
公証が成功した後、何を確認すればよいですか?
公証サービスの結果に加え、ログで問題の有無を確認し、添付対象ではstapler validateの出力を記録します。さらに、署名済みアプリを含む最終配布物を開けること、配布するファイルが検証済みのものと一致することを確かめてください。失敗時はエラー表示だけでなく、公証ログと実行コマンドを残し、原因を追える状態にします。
公開判定:証拠がそろうまで保留する
リリース担当者が確認するのは、Claude Codeの説明ではなく、実行記録と成果物です。次の検収項目をすべて満たした場合にのみ、公開を承認します。
- ビルドコマンド、ツールチェーン、対象アーキテクチャ、バージョンが記録されている
- 使用した署名IDと署名検証の出力を照合できる
- 公証結果と必要な公証ログを確認できる
- チケットの添付が必要な成果物では、その検証記録がある
- 公開物が検証済みのアプリ・パッケージと一致している
- 資格情報を削除または失効させ、承認者と承認記録を残している
一項目でも証拠が欠けたら公開を止めます。資格情報の削除を確認できない環境や、承認者を特定できない自動処理は、公開工程から切り離してください。
クラウドMacを選ぶ場面:環境と責任範囲を比べる
手元のMacは物理的な確認や長期の常時稼働に向きますが、担当者の端末に依存し、作業環境やログの引き継ぎが難しくなることがあります。汎用のCI環境ではmacOS固有の署名・公証ツールやキーチェーンを扱えるかを別途確認する必要があり、Linuxだけの実行環境ではmacOSアプリをそのまま署名できません。
クラウドMacは、作業用のmacOS環境を分離してチームで引き継ぎたい場合に候補になります。ただし、実際に必要なツールが使えるか、資格情報を安全に管理できるか、タスク終了時に環境を清掃できるかは契約前に確認してください。たとえば、日本向けMac miniレンタル環境を検討する場合も、必要な開発ツールと運用条件が合うかを先に照合します。長期の高負荷を常時かける用途や、物理ポートへの直接接続が必須なら、レンタルが適さない場合もあります。
すでにクラウドMacがあるなら、実際の秘密鍵を使う前に、秘密情報を含めない検証用プロジェクトでビルドから公証結果の確認までを通してください。これから環境を用意するなら、KvmkitのMac環境案内を確認し、署名資格情報の管理と作業後の清掃を運用条件に含められる場合に限って選ぶのが安全です。クラウドMac上でClaude Codeを使う場合も、公開の最終判断は人が保持し、署名・公証・検収の証拠がそろってから配布へ進めてください。
M4 Mac mini で CI/CD を回すのが一番ラク
Xcode, Fastlane, CocoaPods, and SPM are first-class on macOS. Mac mini M4 unified memory keeps signing and archiving smooth; ~4W standby power suits 24/7 build nodes.