プロビジョニングプロファイルとは｜iOS署名の仕組み・4種類・作成・更新・エラー対処

プロビジョニングプロファイルとは、iOSアプリを実機やApp Storeへ配布してよいことをAppleが証明する「実行許可証」です。開発者を保証する証明書・アプリを識別するApp ID・許可端末のUDIDという3つの情報を1ファイルに束ね、拡張子は.mobileprovisionになります。Xcodeの実機ビルドで最初につまずくのがこの署名まわりで、原因の切り分けには「何がどのファイルに紐づいているか」の理解が欠かせません。この記事では、定義と3要素から、4種類の使い分け・作成手順・自動署名と手動署名の違い・頻発エラーの対処・365日の期限管理・CI/CD運用までを実務目線で整理します。

まとめ：プロビジョニングプロファイルの要点

• 正体：証明書・App ID・デバイスUDIDを束ねた、Apple発行の実行許可証（.mobileprovision）。コード署名（バイナリへの電子署名）とは役割が別。
• 4種類：Development（開発）／Ad Hoc（限定配布）／App Store（審査・TestFlight）／In-House（Enterprise社内配布）。UDID登録の要否とデバイス上限が種類で変わる。
• 作成：CSR→証明書取得→App ID登録→デバイス登録→プロファイル生成→Xcode反映、の順。順序を飛ばすと原因不明のビルドエラーになる。
• 署名方式：個人はXcodeの自動署名で足りるが、3名以上の共有アカウントやCI/CDでは手動署名またはFastlane matchが実務上の正解。
• 期限：プロファイルは生成から365日。証明書とは別管理で、Ad Hoc配布アプリは期限が切れると起動不能になる。

以下、各項目を検索意図の順に掘り下げます。まず定義と3要素から確認します。

プロビジョニングプロファイルとは｜iOS署名を成立させる3つの認証要素

iOSはサンドボックスモデルを採用し、署名とプロビジョニングの両方が揃ったアプリだけをカーネルレベルで実行許可します。シミュレータではこの検証が省略されるため署名なしでも動きますが、実機では起動時に署名チェーンとプロファイルの条件が照合されます。Androidのように未署名APKを自由にサイドロードできないのは、この設計方針が理由です。開発者には手間ですが、審査を経ないアプリの無断インストールを技術的に防ぐ仕組みだと捉えると、プロファイル管理を丁寧に行う意味が見えてきます。

証明書・App ID・デバイスUDIDの3要素と.mobileprovisionの中身

プロビジョニングプロファイルは3つの認証要素を1ファイルにまとめた構造です。第一が証明書（Certificate）で、開発者または組織の身元をAppleが保証します。第二がApp IDで、Bundle Identifierに紐づくアプリの識別子です。第三がデバイスUDIDで、インストールを許可する端末の固有番号を列挙します。

この3つが揃って初めて実機で起動します。証明書が有効でもApp IDが違えば署名は無効になり、端末UDIDがプロファイルに無ければインストール自体が拒否されます。.mobileprovisionの実体は、証明書のハッシュ・App ID文字列・許可UDIDのリストを含むplist（XML）をAppleの署名で包んだものです。中身は次のコマンドで確認できます。

security cms -D -i profile.mobileprovision

出力されるapplication-identifierやProvisionedDevices、ExpirationDateを直接読めば、Portalにログインせずローカルだけで「どのApp IDに紐づき、どの端末が許可され、いつ切れるか」を把握できます。トラブル時に最初に叩くコマンドとして覚えておくと切り分けが速くなります。

コード署名とプロビジョニングの違い（混同で起きるビルド失敗）

現場で多い誤解が、コード署名（Code Signing）とプロビジョニング（Provisioning）を同一視することです。コード署名はアプリのバイナリに開発者の秘密鍵で電子署名を付ける行為で、目的は改ざん検知。プロビジョニングは「そのアプリをどの条件で実行してよいか」という許可範囲の定義で、目的が異なります。

この違いを押さえていないと、「証明書を更新したのにビルドが通らない」で止まります。証明書だけ新しくしても、プロファイルが旧証明書を参照したままなら整合性が取れません。逆にプロファイルを再生成しても、対応する秘密鍵がキーチェーンに無ければ署名は実行できません。コード署名は暗号処理、プロビジョニングはAppleとの許可契約と切り分けて考えるだけで、エラーの読み違いが減ります。

無料Apple IDと有料Apple Developer Programの分岐条件

実機に入れて動かすだけなら、無料のApple IDでも可能です。Xcode 7以降、無料アカウントには7日間だけ有効な開発用プロファイルが自動生成されます。ただし利用できるCapability（プッシュ通知・App Groups・In-App Purchaseなど）が制限され、テスト端末やApp IDの数にも上限があります。7日ごとに再ビルドが必要になる点も、無料枠で検証する際の前提です。

年額99ドル（日本円は為替で変動、最新額は公式で確認）のApple Developer Programへの登録が必須になるのは、App Storeへの公開・Ad Hoc配布・TestFlight配信・プッシュ通知などの高度なCapabilityを使うときです。チーム開発ではメンバーの権限管理も必要になるため、実務ではプロジェクト開始時点で有料登録を済ませるのが定石です。費用や登録手順の詳細はApple Developer Programとは？年会費・登録方法・ログイン手順まで徹底解説で確認できます。

Development・Ad Hoc・App Store・In-Houseの4種類と選定基準

プロビジョニングプロファイルには用途別に4種類があり、配布範囲・UDID登録の要否・審査の有無が異なります。開発フェーズや配布先に合わない種類を選ぶと、ビルドは通っても配布段階でエラーになります。まず全体像を1枚で押さえます。

表のデバイス上限「種別ごと100台/年」は、iPhone・iPad・Apple Watchなどデバイス種別それぞれに100台という意味です。判断は単純です。App Storeに公開するならApp Store Distribution一択（TestFlightのベータ配信も同じプロファイル）。公開しない場合は配布先で分岐し、社内限定で従業員数が多ければIn-House、少人数テストならAd HocかTestFlightを選びます。日常のデバッグはDevelopmentで進め、配布フェーズで切り替えるのが標準です。

Ad HocとTestFlightの使い分け（100台上限とUDID登録）

Ad HocはApp Storeを経由せずIPAを直接配る方式で、社内QAやクライアントへのプレビュー共有に向きます。DevelopmentもAd Hocも、テスト端末のUDIDを事前登録する必要があり、上限はデバイス種別（iPhone・iPad・Apple Watchなど）ごとに年間100台です。この枠は年度更新時にリセットされますが、年度途中で削除した端末の枠はすぐには再利用できません。

ここで割り切りたいのは、テスターが頻繁に入れ替わるならAd Hocは向かないという点です。端末を1台追加するたびにプロファイル再生成とIPA再ビルドが要り、プロファイル期限が切れると配布済みアプリが起動できなくなります。テスターが10名を超えるなら、UDID登録が不要でメール招待だけで追加できるTestFlightのほうが運用負荷は明確に軽くなります。Ad Hocは「少数の固定端末へ確実に配る」用途に限定するのが実務的です。

In-House（Enterprise）を選ぶ組織規模の目安

Apple Developer Enterprise Program（年額299ドル）で使えるIn-Houseプロファイルは、App Storeを介さず社内の全従業員へ配布でき、UDID登録も台数上限もありません。全社に業務アプリを展開する大企業向けの仕組みです。ただし加入にはDUNS番号の取得や法人審査が必要で、個人や小規模チームは利用できません。

注意すべきは規約です。In-Houseで署名したアプリを社外の第三者へ配ることは明確に禁止されており、違反はアカウント停止につながります。目安として、UDID管理が現実的でない数百名規模ならEnterprise、数十名までならAd HocまたはTestFlightのほうがコストと管理負荷の両面で合理的です。「社内配布だからEnterprise」と短絡せず、配布先の範囲と人数で選ぶべきです。

プロビジョニングプロファイルの作成手順（Portal 5ステップ）

作成はApple Developer Portalでの複数ステップにまたがります。証明書の取得→App IDの登録→デバイスの追加→プロファイル生成→Xcode反映という順序を守らないと、後続のビルドで原因の見えないエラーに悩まされます。

CSR作成からCertificate取得までの手順

プロファイルの前に、まず開発者証明書（Certificate）を取得します。Mac上で作るCSR（Certificate Signing Request）をAppleに提出し、署名済み証明書を受け取る流れです。

1. 「キーチェーンアクセス」→「証明書アシスタント」→「認証局に証明書を要求」を選ぶ
2. メールアドレスと通称を入力し、「ディスクに保存」でCSRファイルを生成する
3. Portalの「Certificates, Identifiers & Profiles」→「Certificates」から「＋」で新規作成する
4. 種類（Apple Development または Apple Distribution）を選び、CSRをアップロードする
5. 署名済み証明書（.cer）をダウンロードし、ダブルクリックでキーチェーンに登録する

この工程で最重要なのは、CSR生成時にMac内部で作られる秘密鍵です。これがキーチェーンから失われると、証明書が有効でも署名できません。別のMacからもビルドするなら、秘密鍵を含む.p12を書き出して安全に共有しておくのが必須です。ここを軽視して秘密鍵を失い、証明書を取り直す羽目になるのが典型的な事故です。

Explicit App IDとWildcard App IDの判断基準

App IDはプロファイルが対象とするアプリの識別子で、Portalの「Identifiers」で登録します。特定のBundle Identifierを指定するExplicit App IDと、末尾をアスタリスクにして複数アプリへ使い回すWildcard App ID（例：com.example.*）の2種類があります。

結論から言えば、App Store提出やプッシュ通知を予定するなら最初からExplicitで登録すべきです。Wildcardは複数プロトタイプを素早く試すには便利ですが、プッシュ通知・App Groups・In-App Purchase・HealthKitなど多くのCapabilityを有効にできません。後からWildcardをExplicitへ変えるにはプロファイルの再作成が必要で、切り替えコストが余計にかかります。迷ったらExplicitが安全側の選択です。

UDID登録で間違えやすい3点とXcodeへの反映

DevelopmentとAd Hocではテスト端末のUDIDをPortalに登録します。UDIDは端末をMacに接続してFinderのデバイス情報でシリアル番号表示をクリックすると切り替わり、XcodeではWindow→Devices and Simulatorsの「Identifier」で確認できます。登録でつまずくのは次の3点です。

• UDIDとシリアル番号の取り違え（UDIDは英数字の長い識別子で、形式が異なる）
• テスターから受け取ったUDIDにスペースや改行が混入して無効になる
• 端末を追加しただけでプロファイルを再生成し忘れる（追加は自動反映されない）

特に3点目が見落とされがちです。デバイスをPortalに足したら、必ずプロファイルの「Edit」から新端末を含めて再生成してください。生成後の.mobileprovisionは、自動署名ならXcodeが自動で管理し、手動署名ならダブルクリックで~/Library/MobileDevice/Provisioning Profiles/に登録されます。反映後はProduct→Clean Build Folderでキャッシュ由来の不整合を消しておくと確実です。

Xcodeの自動署名と手動署名の違いと切り替え基準

Xcode 8以降、新規プロジェクトでは「Automatically manage signing（自動署名）」が既定で有効です。個人開発では快適ですが、チームやCI/CDでは証明書の意図しない再生成やプロファイル競合を招きます。内部で何が起きているかを理解しておくと、切り替えの判断がぶれません。

自動署名（Automatically manage signing）が内部で行う処理

自動署名を有効にすると、Xcodeはビルド時にPortalへ接続し、証明書の確認と必要に応じた新規発行・App IDの登録更新・UDIDの追加・プロファイルの生成とダウンロードまでを裏側で実行します。「接続した実機にそのままビルド」という体験はこの自動処理の恩恵です。

ただし自動生成されるのは「Xcode Managed Profile」という特殊なプロファイルで、手動作成したものとは管理体系が別です。手動編集や再利用が難しく、再生成のタイミングはXcodeの内部ロジックに依存します。この挙動を知らずにチームで使うと、あるメンバーのビルドで証明書が更新され、別メンバーのプロファイルが無効になる不一致が起きます。個人なら便利、複数人なら火種、という理解が実態に近いです。

手動署名へ切り替えるべき3つの条件とBuild Settings

自動署名から手動署名へ移すべき条件は明確です。第一に、3名以上が同一のApple Developerアカウントを共有して開発する場合。自動署名だと各自のMacで証明書が発行され、発行上限に達したり既存証明書が無効化されたりします。第二に、CI/CDでビルドとアーカイブを自動化する場合。CIサーバーにApple IDの認証情報を持たせるのはセキュリティ上の負債になる。証明書とプロファイルをファイルとして持てる手動署名のほうが、CIへは安全に組み込める。第三に、アプリ本体・拡張機能・ウィジェットなど複数ターゲットを持つ場合。ターゲットごとに別プロファイルが必要で、自動署名は意図しない組み合わせを生みやすい。

手動署名ではBuild Settingsの値を正しく指定します。中核はCODE_SIGN_IDENTITYで、Debugは「Apple Development」、Releaseは「Apple Distribution」が標準です。Xcode 11以降はこの2つに統合されているため、古いプロジェクトに残る「iPhone Developer」「iPhone Distribution」はエラーの原因になります。あわせてPROVISIONING_PROFILE_SPECIFIERにプロファイル名、DEVELOPMENT_TEAMにチームIDを設定します。これらは.pbxprojにも反映されるので、Gitの差分に意図しない変更が混ざっていないか確認する習慣が安定運用につながります。

頻発するプロビジョニングプロファイルエラー5種と対処

プロビジョニング関連のエラーはiOS開発で最も遭遇頻度が高く、メッセージが似ているため切り分けが難しいのが厄介です。代表的な5種を、原因と即効の対処に絞って整理します。

No matching provisioning profile foundの3原因

「No matching provisioning profile found」は、ビルド設定に合うプロファイルが見つからないときに出ます。原因は3つに絞れます。ひとつはBundle IdentifierとApp IDの不一致（タイプミス、または生成時に別App IDを選んだ）。ふたつめはプロファイルの期限切れやRevoke（Portalでステータスが「Active」以外）。みっつめはXcodeのプロファイルキャッシュが古いこと。Xcode→Settings→Accountsでチームを選び「Download Manual Profiles」を実行すると最新へ同期されます。この3点を順にチェックし、解消後はクリーンビルドを忘れないことです。

証明書の期限切れ・キーチェーン不整合の切り分け

「A valid signing identity matching this profile could not be found in your keychain」や「Certificate is not valid」が出たら、まずキーチェーンアクセスで証明書の有効期限を見ます。Apple Development証明書の有効期間はおおむね1年で、切れていればPortalで新規発行が必要です。期限が有効なのにエラーが出る場合は、証明書に対応する秘密鍵が無いケースを疑います。「自分の証明書」カテゴリで該当証明書の左に三角マークが出て秘密鍵を展開できるか確認し、無ければ生成元のMacから.p12を書き出してインポートし直します。「期限確認→秘密鍵の存在確認→プロファイルとの紐づけ確認」の順が最短です。

Bundle ID不一致をsecurity cmsで30秒特定

Bundle IDの不一致は頻度が高く、しかも見落としやすい原因です。プロジェクト名の変更やターゲット追加で、Bundle Identifierが意図せず変わっていることがあります。Portalにログインせず、ローカルだけで素早く突き合わせる方法があります。

security cms -D -i profile.mobileprovision | plutil -extract Entitlements xml1 -o - -

出力のapplication-identifierに入っているBundle IDと、Xcodeの「Signing & Capabilities」に表示されるBundle Identifierを完全一致で比べるだけで、不一致を即座に検出できます。プロジェクト名変更の直後にこれを一度回す習慣をつけると、デバッグ時間を大きく削れます。

キャッシュ破損時のクリーン手順とデバイス未登録

プロファイルを入れているのにXcodeが認識しないときは、キャッシュ破損を疑います。Xcodeのアップデート直後やmacOSのバージョンアップ後に起きやすい症状です。Xcodeを完全終了し、~/Library/MobileDevice/Provisioning Profiles/内のファイルを削除、次にDerivedDataを消し、Xcodeを再起動して「Download Manual Profiles」で入れ直します。

rm -rf ~/Library/Developer/Xcode/DerivedData

もうひとつ多いのが、Ad Hoc配布での「The device is not included in the provisioning profile」です。対象端末のUDIDがプロファイルに無いのが原因で、テスターの端末変更や新メンバー参加のたびに再発します。新端末追加のたびにUDID登録とプロファイル再生成をセットで行い、再生成後は必ず新プロファイルでIPAを作り直す運用ルールにしておくと、再発を大幅に減らせます。テスターが増えてきたら、この手戻りごとTestFlightへ移すのが根本策です。

有効期限と更新管理（365日ルール）

プロビジョニングプロファイルには有効期限があり、期限切れではビルドが通りません。さらにAd HocやIn-Houseで署名したアプリは、期限が切れた時点で起動不能になり、運用中のアプリに直接影響します。期限管理は「後で」では間に合わないため、仕組みで回す前提が要ります。

プロファイル365日・証明書1年の別管理と更新時期

プロファイルの有効期間は種類を問わず生成日から365日です。切れるとステータスが「Expired」になり、そのプロファイルを指定したビルドは実行できません。Developmentならビルドが通らないだけですが、Ad Hocは配布済みアプリまで起動できなくなる点が決定的な差です。App Store配布分はApple側で再署名されるため公開中のアプリに影響はありませんが、次回アップデート提出時には有効なプロファイルが要ります。

見落としやすいのは、プロファイルと証明書が独立して期限管理される点です。両者の発行日が違えば切れるタイミングもずれます。プロファイルを更新したのに紐づく証明書が先に切れていてビルドが通らない、というのが典型的な失敗です。逆に証明書を新規発行した後、プロファイルの再生成を忘れて旧証明書を参照し続ける事故もあります。どちらか一方を更新したら、必ずもう一方の紐づけも確認するルールを決めておくべきです。

期限切れによるアプリ起動不能を防ぐ再配布タイミング

更新は期限の30日前に着手するのが現実的です。Portalの「Profiles」で対象を選び、「Edit」で証明書やデバイスを最新化して「Generate」し、Xcodeに反映してビルドが通ることまで確認して完了です。Ad Hoc配布中のアプリがある場合は、新プロファイルで再署名したIPAを期限切れの2週間前までにテスターへ再配布しておかないと、期限到来と同時にアプリが開けなくなります。

手作業の一覧管理なら、最低限「プロファイル名／種類／App ID／紐づく証明書名／プロファイル有効期限／証明書有効期限／最終更新日／更新担当者」を持たせます。

この一覧に、期限30日前のカレンダー通知やSlackリマインダーを組み合わせれば見落としは減ります。複数アプリを運用するなら、アプリごとにシートを分けるより1枚に集約してフィルタで絞るほうが横断チェックに向きます。手作業に限界を感じ始めたら、次に触れるFastlane matchで自動化する段階です。

CI/CDとチーム開発でのプロビジョニングプロファイル運用

チーム規模が大きくなりCI/CDを導入すると、プロファイルの手作業管理は破綻します。CIサーバー上で安定してビルドするには、証明書とプロファイルを安全に配置し、全員が同じ署名環境を再現できる仕組みが要ります。

GitHub Actions/Bitriseでプロファイルを安全に配置する

CIでiOSをビルドするには、mac_osランナー上に証明書とプロファイルを配置する処理をワークフローに組み込みます。GitHub Actionsでは、証明書（.p12）とプロファイル（.mobileprovision）をBase64にエンコードしてSecretsに格納し、実行時にデコードしてファイルへ書き出すのが定石です。

echo "$PROFILE_BASE64" | base64 --decode > profile.mobileprovision

書き出したプロファイルを~/Library/MobileDevice/Provisioning Profiles/へ置き、証明書はsecurity importでキーチェーンに登録します。Bitriseなら「Certificate and profile installer」ステップが用意されており、管理画面にアップロードしたファイルが自動配置されるので記述量を減らせます。いずれの場合も、Secretsの値がログに出ないようにし、ビルド後にキーチェーンから証明書を削除するクリーンアップを必ず入れることがセキュリティ上の前提です。

Fastlane matchによる証明書・プロファイルの一元管理

Fastlane matchは、チーム全体の証明書とプロファイルをプライベートリポジトリ（GitやGoogle Cloud Storage）で一元管理するツールです。導入すると各自がPortalで個別に証明書を発行する必要がなくなり、全員が同一の証明書・プロファイルセットでビルドできます。基本の流れは次のとおりです。

1. fastlane match initで設定ファイルを生成する
2. 証明書とプロファイルを保管するプライベートGitリポジトリのURLを設定する
3. fastlane match developmentでDevelopment用を生成・保管する
4. fastlane match appstoreでApp Store Distribution用を生成する
5. 各開発者のMacでfastlane match development --readonlyを実行してインストールする

注意点は、matchが初回実行時に既存証明書をRevokeするオプションを持つことです。稼働中の証明書がある環境では--readonlyで運用するか、既存証明書をmatchのリポジトリへインポートしてください。リポジトリ内はパスフレーズで暗号化され、CIでは環境変数MATCH_PASSWORDにパスフレーズを渡して自動化します。matchやリリース自動化そのものの導入手順はfastlaneとは？iOSアプリのビルド・配信を自動化する使い方を解説、App Storeへの配信自動化は【Swift】fastlaneを使用したリリースの自動化の基本概要が参考になります。

秘密鍵共有のセキュリティ3原則と命名規則

署名に使う秘密鍵をチームで共有するときは、次の3原則を守ります。共有経路は必ず暗号化する（.p12を平文でチャット送信しない）。アクセス権限は最小化する（Distribution証明書はリリース担当とCIのみ、一般メンバーにはDevelopmentだけ）。そして定期的にローテーションする（メンバー離脱時は証明書をRevokeして再発行し、プロファイルも再生成する）。この3点目を怠ると、退職者が持つ秘密鍵で不正署名される余地が残ります。

複数アプリを運用するとプロファイルは容易に数十個へ膨らむため、命名規則も先に決めておくべきです。「アプリ名_ターゲット名_種類_環境」の形式（例：MyApp_MainTarget_AppStore_Production）にしておくと、一覧でどのアプリのどのターゲット用かが即座に判別できます。不要になったプロファイルはPortalで定期的に削除し、有効なものだけを残すことで、選択ミスやキャッシュ混乱を防げます。

よくある質問

プロビジョニングプロファイルとは何ですか？

iOSアプリを実機やApp Storeへ配布してよいことをAppleが証明する実行許可証です。開発者を保証する証明書・アプリを識別するApp ID・許可端末のUDIDを1ファイル（.mobileprovision）に束ねたもので、実機ではこの条件と実行環境が一致して初めてアプリが起動します。

プロビジョニングファイルとプロビジョニングプロファイルは同じですか？

実務上は同じものを指します。正式名称はProvisioning Profile（プロビジョニングプロファイル）で、拡張子が.mobileprovisionであることから「プロビジョニングファイル」と呼ばれることがあります。証明書（Certificate）は別物なので、区別して扱ってください。

プロビジョニングプロファイルの保存場所（パス）はどこですか？

手動署名で登録したプロファイルは~/Library/MobileDevice/Provisioning Profiles/に格納されます。Finderから直接開けるほか、認識不良の際はこのフォルダ内を空にしてから「Download Manual Profiles」で入れ直すと復旧できます。

プロビジョニングプロファイルの有効期限はどのくらいですか？

生成日から365日です。証明書の有効期限とは別に管理されるため、両方の期限を突き合わせて管理する必要があります。Ad Hoc配布のアプリは期限切れで起動できなくなるので、期限の2週間前までに再署名したIPAを配り直してください。

無料のApple IDでも実機テストはできますか？

できます。ただし自動生成される開発用プロファイルは7日間だけ有効で、プッシュ通知などのCapabilityやテスト端末数に制限があります。App Store公開・Ad Hoc配布・TestFlight配信を行うには、有料のApple Developer Programへの登録が必要です。

関連記事

• Apple Developer Programとは？年会費・登録方法・ログイン手順まで徹底解説
• fastlaneとは？iOSアプリのビルド・配信を自動化する使い方を解説
• 【Swift】fastlaneを使用したリリースの自動化の基本概要