Visual Studioで.NET MAUI iOS発行時に開発用証明書が自動生成され配布（Distribution）証明書を使えない原因と手動プロビジョニング解決法

Visual Studioで.NET MAUIのiOSアプリを発行（配布）しようとすると、配布（Distribution）証明書を持っているのに開発用（Development）が勝手に作られ続け、配布用を選べないことがあります。原因を整理し、Xcode確認＋手動プロビジョニングで確実に解消する手順をまとめます。

起きがちな症状：開発用が増殖して配布用が選べない

このトラブルは、.NET MAUI / iOS の署名設定が「意図せず自動（Automatic）」側に寄っているときに起こりやすいです。見た目の挙動としては、次のような“ループ”になります。

発行（Publish / Archive / Distribution）を実行すると、開発用（Development）の証明書・プロビジョニングプロファイルが勝手に作られる
すでに配布用（Distribution）の証明書があるのに、Visual Studio側で選べない／認識されない
「iOS Distribution を作成」などのボタンがグレーアウトし、作成・選択ができない
Apple Developer側で削除しても、しばらくすると開発用が再作成されて戻ってくる
プロジェクトファイル（.csproj）から CodesignKey / CodesignProvision を削除しても再発する

画面・ログで見えること	よくある意味	最初に疑うべき場所
Development証明書や開発用プロファイルが何度も生成される	自動プロビジョニングがトリガーされ続けている	Visual Studio の iOS バンドル署名（Scheme）
Distribution作成がグレーアウト	権限不足／アカウント状態／チームロールが原因になりやすい	Apple Developer のチーム権限、Visual Studio の Appleアカウント
配布証明書があるのに選択候補に出ない	Mac側キーチェーンに秘密鍵がない、または別Macで作った	Keychain Access（秘密鍵の有無）
プロファイルはあるのに署名に失敗する	Bundle ID / Capability（Entitlements）不一致でプロファイルが無効	App ID / プロファイル再生成（Capabilities変更後）

なぜ起きるのか：Visual Studioの“自動署名”が配布より優先される

.NET MAUI の iOS では、デバイスに入れてテストするための「自動プロビジョニング（Automatic provisioning）」と、証明書・App ID・プロファイルを固定して運用する「手動プロビジョニング（Manual provisioning）」があります。自動プロビジョニングは“開発用の導線”としては便利ですが、条件によっては「必要なら再実行する」挙動を持ちます。

自動プロビジョニングが再実行される典型例は、たとえば次のようなタイミングです。

iOSデバイスをMacに接続した（未登録なら登録して新しいプロファイルを生成）
アプリのBundle ID（バンドル識別子）を変更した（新しいApp ID/プロファイルが必要になる）
Entitlements.plist で対応するCapabilityを有効化した（新しいプロファイルが必要になる）

この“再実行”の文脈で開発用（Development）が生成され続けると、Visual Studio上で「開発用が常に正」として扱われ、配布用が選べない／作れない状態になりがちです。実際、同様の状況で「Xcode側で確認して、手動プロビジョニングに切り替えたら直った」という報告があります。

まず整理：配布（Distribution）で本当に必要なもの

“配布用が選べない”を切り分けるには、先に「配布で必要な部品が揃っているか」を明確にしておくのが近道です。iOSのコード署名は、ざっくり言うと次の3点セットで成立します。

証明書（Certificate）：Apple Distribution（旧 iOS Distribution）など
App ID：Bundle ID と一致する識別子（Capabilitiesの設定元）
プロビジョニングプロファイル（Provisioning Profile）：App ID と証明書などを束ねた許可情報

Appleの説明でも、開発用は端末上での実行や開発中の機能利用、配布用はテスト配布やApp Store Connectへのアップロードに使うもの、と整理されています。また配布用証明書はチーム資産として扱われ、作成できるのはAccount Holder / Adminに限られる点が重要です（ここがグレーアウトの原因になりやすいポイントです）。

目的	主に使う証明書	主に使うプロファイル	よくある落とし穴
開発（実機デバッグ）	Apple Development	Development	自動に任せすぎて、配布に切り替えられない
App Store / TestFlight	Apple Distribution	App Store（Distribution）	プロファイル再生成漏れ（Capability変更後に無効化）
Ad Hoc（端末指定配布）	Apple Distribution	Ad Hoc	端末UDIDの追加→プロファイル更新が必要
社内配布（Enterprise）	Enterprise向け証明書	In-House	Enterprise ProgramとApp Storeは前提が別

結論：Xcodeで証明書・プロファイルを整え、手動プロビジョニングで“固定”する

この問題の最短ルートはシンプルです。

Xcode（＋Keychain）側で「配布用証明書が秘密鍵付きで正しく存在する」状態にする
Apple Developer側で「配布用プロビジョニングプロファイルが正しく作られている」状態にする
Visual Studio側を「手動プロビジョニング」に切り替え、使う証明書／プロファイルを固定する

ここからは、再発しない形で進めるための具体手順を、チェックポイント込みで説明します。

Apple Developer側の権限を確認する（グレーアウト対策）

「iOS Distribution を作成」がグレーアウトする場合、まず疑うべきは権限です。配布用証明書はチームに紐づく資産で、作成できるロールが制限されます。組織アカウントでは特に、開発メンバーがAdmin権限を持っていないケースが多いです。

Apple Developer Program に加入済みか（サブスクリプションが有効か）
自分のApple Accountがチームの Account Holder もしくは Admin か
App Store Connect / Apple Developer の最新同意事項が未承諾になっていないか

ここがクリアできないと、Visual Studioから配布用を作ろうとしても、そもそも作成操作が許可されません。

MacのKeychainで「配布証明書＋秘密鍵」を確認する（最重要）

配布用証明書が“あるのに使えない”原因として非常に多いのが、秘密鍵（Private Key）がMac側に存在しないケースです。証明書だけをダウンロードして入れても、署名に必要な秘密鍵がなければコード署名はできません。

確認は次の観点で行います。

Macで「キーチェーンアクセス」を開き、ログインキーチェーン（login）を対象にする
「マイ証明書」カテゴリで Apple Distribution（または iOS Distribution）を探す
証明書を展開でき、秘密鍵がぶら下がっている状態か（鍵アイコンが見えるか）

もし Xcode の「Manage Certificates」画面などで Missing Private Key と表示される場合、基本的には次のどちらかです。

その証明書を作成したメンバーが別にいて、あなたのMacには秘密鍵がない（→作成者から秘密鍵付きで共有してもらう）
秘密鍵を失っている（→新しい配布用証明書を作り直して運用を切り替える）

なお、Appleのガイドでも、Missing Private Key の場合に作成者へ依頼（Email Creator）する／新規作成する、といった対応が示されています。ここが直らない限り、Visual Studio側で何を選んでも配布署名は成立しません。

配布用プロビジョニングプロファイルを“配布目的に合わせて”作成・更新する

プロビジョニングプロファイルは、App ID と署名（配布）証明書を含む形でアプリの配布を許可するものです。配布の種類（App Store / Ad Hoc / In-House）に合っていないプロファイルを選ぶと、署名が通りません。

さらに重要なのが、Capabilities を変更したらプロファイルを再生成する必要があるという点です。App ID の能力（Capabilities）を変更すると、既存プロファイルが無効になり、再生成が必要になることが明示されています。

チェックの観点は次の通りです。

チェック項目	見る場所	OKの基準
Bundle ID一致	プロジェクトの Application ID / Info.plist	Apple DeveloperのApp IDと完全一致
プロファイル種別	Apple DeveloperのProfiles	App Store配布ならApp Store用を選ぶ
含まれる証明書	Profilesの詳細	対象の配布証明書が含まれている
Capabilities整合	App ID（Identifiers）＋ Entitlements.plist	両方で同じ機能が有効になっている

Xcodeでプロファイルを同期し、署名素材を“Macに揃える”

Visual Studio（Windows）で開発している場合でも、iOSの実体の署名は最終的にMac側（ビルドホスト）で行われます。したがって「MacのKeychainに証明書（秘密鍵付き）がある」「Macにプロファイルが入っている」状態を作るのが安全です。

Microsoft Learn の手動プロビジョニング手順でも、Xcode のアカウント設定から手動でプロファイルをダウンロードする流れが案内されています（この“Xcodeで状態を確かめる”のが効きます）。

やること（概念）は次の通りです。

Xcodeを開き、Settings（またはPreferences）→ Accounts で該当のApple AccountとTeamを選ぶ
手動プロファイルのダウンロード（手動同期）を実行し、Mac側にプロファイルを入れる
Keychain Accessで配布証明書が秘密鍵付きで存在することを再確認する

Visual Studioを「手動プロビジョニング」に切り替えて固定する

いよいよ本丸です。Visual Studio 側で “自動生成ループ” を止めるには、iOS バンドル署名の Scheme を手動プロビジョニングに切り替えるのが効果的です。

Microsoft Learn では、プロジェクトのプロパティから iOS バンドル署名 タブを開き、Scheme のドロップダウンで手動プロビジョニングを選ぶ手順が示されています。

Visual Studio のソリューションエクスプローラーで .NET MAUI プロジェクトを右クリック →「プロパティ」
「iOS バンドル署名」タブへ移動
「スキーム（Scheme）」を 手動プロビジョニング に変更
「署名 ID」「プロビジョニングプロファイル」を 配布用 に合わせて選択（または、手動スキームのまま自動選択を使う場合は“配布（自動）”を選ぶ）

ここでのポイントは、“手動プロビジョニング”という運用モードに切り替えて、Visual Studioの勝手な再生成を止めることです。配布のときだけでもこの固定にしておくと、発行時に開発用へ戻される事故が減ります。

csprojで明示指定して、さらに事故率を下げる（チーム運用向け）

GUIで選んでも、環境差やキャッシュで意図せず切り替わることがあります。チーム運用やCI/CDを見据えるなら、.csproj に CodesignKey と CodesignProvision を明示して「この証明書・このプロファイルを使う」と固定するのが堅実です。

&lt;PropertyGroup&gt;
  &lt;CodesignKey&gt;Apple Distribution: Your Company (TEAMID)&lt;/CodesignKey&gt;
  &lt;CodesignProvision&gt;Your App Store Provisioning Profile Name&lt;/CodesignProvision&gt;
&lt;/PropertyGroup&gt;

証明書名はKeychain Accessに表示される“完全一致の名前”、プロファイル名はApple Developerで作成時に付けた“完全一致の名前”を指定します。Microsoft Learn でも、キー名の確認方法（Keychain Accessでの確認）が案内されています。

発行（Publish）時に「Release構成」になっているかも確認する

“配布用にしたつもりなのに開発用になる”の原因が、単純に構成（Configuration）の取り違えであることもあります。Visual Studio の発行フローでも、配布時は Release 構成に切り替える手順が明記されています。

ツールバーのソリューション構成が Release になっているか
iOS バンドル署名が Release 側で配布用に設定されているか（Debugだけ見ていないか）

「iOS Distribution を作成」がグレーアウトする代表原因と対処

配布証明書を“作成できない／選べない”のは、だいたい原因が絞れます。現場で多い順にまとめます。

原因	見分け方	対処
チームロールがAdmin/Account Holderではない	作成ボタンが無効／権限に関する説明が出る	権限付与を依頼（または作成自体を権限者にやってもらう）
Apple Developer Program未加入・期限切れ	証明書の要求や利用ができない	サブスクリプション状態を確認し更新
配布証明書はあるが秘密鍵がない（別Macで作った）	XcodeでMissing Private Key、またはVSでKeychain未検出	秘密鍵付きでエクスポート（.p12）して取り込む／新規作成
Capabilities変更でプロファイルが無効化	署名自体はできそうでもインストールや検証で失敗	App IDの設定を見直し、プロファイルを再生成

Apple側の資料でも、配布証明書はAccount Holder / Adminのみが要求できること、また証明書の要求・ダウンロード・利用にはDeveloper Programのメンバーシップが必要であることが明記されています。ここが満たされないと、Visual Studioのボタンは実質的に詰みます。

それでも直らないときの追加チェック（再発防止まで含めて）

自動プロビジョニングの“再実行トリガー”を潰し切れているか

「手動に切り替えたつもりなのに戻る」場合は、手動へ切り替えたのが Debug 側だけ、あるいは別のターゲット/構成が自動のまま、というケースが目立ちます。Visual Studio は条件により自動プロビジョニングを再実行し得るため、“戻る原因”が残っていると再発します。

プロファイルのダウンロードと同期が古い（Visual Studioの一覧が更新されない）

配布プロファイルをApple Developerで作った直後は、Visual Studio側の一覧が更新されていないことがあります。Microsoft Learnでも「場合によって再起動が必要」「すべてのプロファイルのダウンロード」といった手順が案内されています。

Bundle ID（アプリケーションID）がほんの少し違う

iOS署名の不一致は、ほとんどがBundle IDの齟齬です。特に、次のパターンで事故が起きます。

開発用と配布用で、Bundle IDの末尾だけを変えている（例：com.example.app と com.example.app.dev）
CI用に別のBundle IDを使っている
iOS側だけ別の識別子になっている（設定の更新漏れ）

Microsoft Learnでは、Visual Studioの「MAUI 共有 > 全般」タブの Application ID がBundle IDに相当し、Info.plistへ反映される点が説明されています。ここを起点に整合を取るのが安全です。

Capabilities / Entitlements の整合（Push、Associated Domains、App Groupsなど）

Entitlements（権限）系の機能を追加すると、開発用は自動で回り始めるのに、配布用プロファイルは更新されない、という“ねじれ”がよく起こります。CapabilitiesをApp IDで変更した場合、関連するプロファイルは無効になるため、再生成が必要です。

とくに次の機能はトラブルを起こしやすいので、追加したタイミングで「配布プロファイルの再生成」までセットで行うのがおすすめです。

Push Notifications
Sign in with Apple
Associated Domains
App Groups
iCloud / CloudKit

「証明書はある」けど“秘密鍵がない”問題（Macを変えた/増やした）

Macを買い替えた、ビルドホストを変えた、複数人で署名する、といった局面で一気に増えるのがこれです。自動プロビジョニングのトラブルシューティングでも「証明書は作成したマシンにしか秘密鍵がない」ため、別マシンではインポートが必要、という趣旨の説明があります。

対処としては次のいずれかになります。

秘密鍵付きでエクスポート（一般的に .p12）して、Macビルドホストへインポート
作成者から秘密鍵付きで共有してもらう（Xcodeヘルプでも作成者へ依頼の導線が示されています）
秘密鍵が失われている場合は新規に配布証明書を作り直し、関連プロファイルを再生成

プロビジョニングプロファイルの“掃除”は最後にやる（やるなら手動固定後）

「開発用が勝手に復活する」状態でプロファイルを削除しても、また自動で作られてしまいます。まず手動プロビジョニングに固定し、そのうえで不要なプロファイルを整理するのが安全です。

整理の目安（例）：

期限切れのプロファイル
“Valid signing identity not found” 相当の状態で使えないプロファイル
同じ目的なのに似た名前が大量にあるプロファイル（自動生成の残骸）

運用のコツ：配布だけは“手動固定”にしておくと安定する

現場で安定する運用は、次の形です。

実機デバッグ（開発中）は自動でも良い（チームが小さいなら特に）
発行（配布）だけは手動プロビジョニングに切り替えて固定する
Capabilitiesを増やしたら、配布プロファイルを再生成する（“作業手順に組み込む”）
配布証明書はチーム資産なので、管理者が責任を持って保全（秘密鍵の所在を明確化）

また、プロファイル命名を雑にすると、Visual Studioの選択候補がカオス化しやすいです。おすすめは「アプリ名＋用途＋年」など、意図が一目でわかる命名です（例：MyApp AppStore 2025、MyApp AdHoc QA）。

よくある質問

配布証明書はあるのに、Visual Studioが認識してくれません

まずMac側のKeychainで「配布証明書に秘密鍵が付いているか」を確認してください。秘密鍵がない場合、署名に使えないため、Visual Studioの候補に出ない／選んでも失敗しやすくなります。Missing Private Key のときは、作成者から秘密鍵付きで共有してもらうか、新規作成→プロファイル再生成が必要です。

「iOS Distribution を作成」がグレーアウトです

Apple側の権限（Account Holder / Admin）不足が最有力です。配布証明書はチーム資産で、要求できるロールが制限されます。組織アカウントの場合は、管理者に作成を依頼し、秘密鍵付きで安全に共有する運用に切り替えるのが現実的です。

Capabilitiesを追加したら、急に配布で失敗し始めました

App ID のCapabilitiesを変更すると、既存のプロビジョニングプロファイルが無効になり、再生成が必要になります。Entitlements.plist側の設定だけ進めて、Apple Developer側のプロファイル更新を忘れると、開発は通るのに配布で落ちる、という状況になりやすいです。

結局、この問題は何をすれば最短で直りますか？

最短は「Xcode（＋Keychain）で配布証明書とプロファイルを正しく揃える → Visual Studioを手動プロビジョニングへ切り替え、配布用の証明書／プロファイルを固定する」です。同様の症状で、手動プロビジョニングへ切り替えることで解決した事例も報告されています。

まとめ：自動生成ループは“固定”で止める

開発用が勝手に作られるのは、自動プロビジョニングの再実行トリガーが働いている可能性が高い
配布用が選べないときは、まず権限（Account Holder/Admin）と、Mac側の秘密鍵（Private Key）を疑う
Xcodeで証明書・プロファイルを確認し、Visual Studioは手動プロビジョニングへ切り替えて固定する
Capabilities変更後はプロファイル再生成が必要。配布前チェックに組み込むと再発しにくい

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Visual Studioで.NET MAUI iOS発行時に開発用証明書が自動生成され配布（Distribution）証明書を使えない原因と手動プロビジョニング解決法

起きがちな症状：開発用が増殖して配布用が選べない

なぜ起きるのか：Visual Studioの“自動署名”が配布より優先される

まず整理：配布（Distribution）で本当に必要なもの