.NET MAUI iOSアプリをiPadにインストールできない（MT1006/0xe8008015）原因と解決策｜プロビジョニングプロファイルとEntitlements整合

.NET MAUI（iOS）アプリをVisual Studio（Windows）からiPad実機へデバッグ配信しようとして、インストール工程だけが失敗する。しかも証明書やプロビジョニングプロファイルは選べている――この状況で出やすいのが、MT1006と0xe8008015（有効なプロビジョニングプロファイルが見つからない）です。本記事では、原因の考え方と、最短で通すための具体策を整理します。

現象：MT1006 / 0xe8008015（有効なプロビジョニングプロファイルが見つからない）とは

Visual StudioからiOSプロジェクトをiPadへデプロイする際、ビルドは通るのに「端末へのインストール」で失敗するケースがあります。表面上はMT1006として出ますが、実体はMac側でdevicectl（Appleのデバイス操作コマンド）経由のインストールが失敗し、署名検証で弾かれているパターンです。

ログには次のようなニュアンスが含まれます（文言は環境により多少変わります）。

MT1006: Could not install the application ...
... devicectl ...
0xe8008015: A valid provisioning profile for this executable was not found.
Signing verification failed

重要なのはここで、「プロファイルが存在しない」のではなく、「アプリが要求している署名条件（Bundle ID / Capabilities / Entitlements / 証明書 / 端末登録など）と、実際に埋め込まれたプロビジョニングプロファイルが一致していない」ために、端末側のインストール検証で落ちることが多い点です。

結論：コード署名の“整合性”が崩れているとインストール時に落ちる

Visual Studio側でAppleアカウントを追加し、Apple Development証明書とDevelopmentプロビジョニングプロファイルを選んだとしても、次のいずれかが噛み合っていないと、端末インストール時の検証で0xe8008015になりがちです。

噛み合わないポイント	よくある具体例	起きること
Bundle ID（アプリ識別子）	プロファイルはcom.example.appなのに、ビルド対象がcom.example.app.dev	署名はできたように見えても、端末検証で不一致
Capabilities / Entitlements	Push通知、Associated Domains、KeychainなどのEntitlementsがプロファイル側と不整合	「署名検証に失敗」→0xe8008015
端末登録（UDID）	Developmentプロファイルに、そのiPadが含まれていない	開発用プロファイルとして無効扱い
証明書（Signing identity）	プロファイルはA証明書で作成、ビルドはB証明書で署名	端末側で“このプロファイルの署名ではない”と判断
プロファイルの鮮度	Capabilitiesを後からONにしたのに、プロファイルを作り直していない	プロファイルが古く、要求するEntitlementsを満たせない

最短で切り分ける：チェックリスト（上から順に潰す）

原因は複数あるように見えて、ほとんどが「整合性の崩れ」です。迷ったら、次の順番で確認すると復旧が速いです。

手順	確認すること	OKの目安	NGならやること
1	手動プロビジョニングでプロファイルを明示指定	目的のDevelopmentプロファイルを“確実に”選べる	自動から手動へ切替、選択をやり直す
2	Bundle IDがApp IDと完全一致	Identifierが同一（大文字小文字、接尾辞含む）	Bundle IDを合わせる／App IDを作り直す
3	EntitlementsとCapabilitiesの整合	有効化した機能がApp ID側でON、かつ新しいプロファイル	Apple Developerで機能ON→プロファイル再生成
4	プロファイルのDevicesにiPadが含まれる	該当iPad（UDID）が登録済み	端末登録→プロファイル更新（再DL）
5	クリーン＆ツール更新	bin/obj削除後に再ビルドで同じ挙動が再現しない	VS/.NET workload/Xcode更新、キャッシュ掃除

対処1：手動（Manual）プロビジョニングに切り替えて“本当に一致するプロファイル”を選ぶ

まず多いのが、Visual Studioの自動プロビジョニングが「選べているように見えて、内部的には違うプロファイルを掴んでいる」パターンです。特に、似た名前のプロファイルが複数ある場合や、Capabilities変更後に古いプロファイルが残っている場合に起きやすいです。

やること

• iOSプロジェクトの署名設定を自動ではなく手動に切り替える
• Signing identity（Apple Development）を明示
• Provisioning profileを明示（目的のDevelopmentプロファイル）

ポイントは「候補に出てくる中から選ぶ」だけで満足せず、次の“整合”までセットで確認することです。

• 選んだプロファイルのApp IDが、アプリのBundle IDと一致している
• そのプロファイルがDevelopment（開発用）である
• 含まれている証明書が、現在使うApple Development証明書と同じ

手動で正しいプロファイルを選べない場合、そもそもApple Developer側のプロファイルが期待通りに作られていない（または更新されていない）可能性が高いです。次の対処2へ進みます。

対処2：Entitlements（権限設定）とApp ID / Capabilitiesの整合性を取る

0xe8008015でいちばん見落とされやすいのがここです。アプリ側（Entitlements.plist）に要求が書かれているのに、Apple Developer側のApp IDでその機能が有効化されていない、または有効化はしたがプロファイルを作り直していない――このズレがあると、ビルド自体は通っても端末インストールの署名検証で落ちます。

EntitlementsとCapabilitiesがズレる典型例

• Push通知（APNs）を追加した
• Associated Domains（Universal Links等）を追加した
• Keychain Sharingを追加した
• Sign in with Apple / App Groupsなどを追加した

これらは「アプリが要求する権限（Entitlements）」が、Apple Developerポータル上のApp ID設定に反映され、さらにその結果を含んだプロビジョニングプロファイルで署名されて初めて成立します。

CapabilitiesとEntitlementsの対応（目安）

機能（Capabilities）	Entitlementsのキー例	ズレたときの症状
Push Notifications	aps-environment	インストール時に署名検証失敗になりやすい
Associated Domains	com.apple.developer.associated-domains	同上（特に追加直後）
Keychain Sharing	keychain-access-groups	同上（グループ不一致）
App Groups	com.apple.security.application-groups	同上（グループID不一致）

やること（Apple Developer側）

• Identifiers（App ID）で、該当Bundle IDのCapabilitiesがONになっているか確認
• Capabilitiesを変更したなら、Provisioning Profilesを必ず再生成（更新）
• 再生成したプロファイルをMac側に取り込み、Visual Studio側の候補も更新させる

「App IDの機能をONにしただけ」で止まっているケースが非常に多いです。Capabilitiesの変更は、プロファイルを作り直して初めて“署名可能な条件”として反映されます。

対処3：プロビジョニングプロファイルに“そのiPad端末”が含まれているか確認

Developmentプロファイル（開発用）で実機デバッグする場合、基本的に端末登録（UDID登録）が必要です。iPadがプロファイルのDevicesに入っていないと、端末側で「この実行ファイルに対する有効なプロビジョニングプロファイルが見つからない」と判断されます。

UDID確認の実用ルート

• MacのXcode：Devices and Simulatorsから該当iPadを選び、Identifier（UDID）を確認
• Windows環境でも、iTunes相当の仕組みやデバイス情報表示で確認できる場合があります（ただしXcode経由が確実）

やること

• Apple DeveloperポータルでDevicesにiPadを登録
• 該当のDevelopmentプロファイルを編集し、DevicesにそのiPadを含める
• プロファイルを再生成（更新）して取り込み直す

ここでの注意点は、端末登録だけして「プロファイルを再生成していない」パターンです。Devicesに追加したら、必ずプロファイルを更新して反映させます。

対処4：端末の再認証（信頼関係のリセット）でインストール経路を正す

署名不一致が本丸であることが多い一方、USB接続や端末側の信頼関係が壊れていて、インストール手順が不安定になるケースもあります。特に、同じiPadを複数のMac/PCに接続している場合や、OS更新直後に発生することがあります。

試すこと

• iPadをPC/Macから外し、iPadを再起動
• 再接続して「このコンピュータを信頼しますか？」が出たら信頼する
• 必要ならiPad側で「位置情報とプライバシーをリセット」（信頼関係の再生成を促す）

この手順は“単体での決定打”になることは少ないですが、署名設定を直したのに挙動が変わらない時のノイズ要因を潰すのに有効です。

対処5：VS / Xcode を最新化し、bin/obj削除→クリーンビルドでキャッシュ不整合を排除

.NET MAUIのiOSデバッグは、Windows側のVisual StudioとMac側のXcodeツールチェーンが組み合わさって動きます。どちらかが古い、もしくは中間生成物が古い署名条件を保持していると、設定を直しても反映されず“同じエラー”に見えることがあります。

やること

• Visual Studioと.NETワークロード（MAUI/iOS関連）を更新
• Mac側のXcodeを更新し、Command Line Toolsも整合させる
• プロジェクトのbin/objを削除してクリーンビルド
• Visual Studioのビルド出力詳細度を上げ、どのプロファイル/証明書で署名されたか追える状態にする

署名問題は「正しい設定に直したのに古い成果物が残っている」だけで詰まることがあります。特にiOS側の署名は、生成物の差し替えが発生しやすい領域です。

補足：今回の“決定打”になりやすい原因—aps-environmentがproductionになっている

ここからが最重要ポイントです。Push通知（APNs）を扱うためにEntitlementsを追加している場合、aps-environmentの値が開発用プロファイルと一致していないと、端末インストール時の検証で落ちることがあります。

よくある落とし穴

デバッグ用途なのにEntitlementsが次のようになっているパターンです。

<key>aps-environment</key>
<string>production</string>

開発用（Development）のプロビジョニングプロファイルでデバッグする場合、通常は次が期待値になります。

<key>aps-environment</key>
<string>development</string>

このズレがあると、「署名はできた」ように見えても、端末側が“このプロファイルでは許可されないEntitlementsを要求している”と判定し、0xe8008015につながります。

ベストプラクティス：DebugとReleaseでEntitlementsを分ける

Push通知を使うアプリでは、Debug（開発）とRelease（本番配布）で要求するAPNs環境が変わることがあります。運用で事故を起こしにくいのは、Entitlementsファイルを分離してビルド構成で切り替える方法です。

例として、次のように2つのEntitlementsを用意します。

• Entitlements.Debug.plist：aps-environment = development
• Entitlements.Release.plist：aps-environment = production

そして、プロジェクトの設定（またはcsproj）で構成ごとに使うEntitlementsを切り替えます。csprojで管理する例は次のイメージです（実際のパスはプロジェクトに合わせてください）。

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <CodesignEntitlements>Platforms/iOS/Entitlements.Debug.plist</CodesignEntitlements>
</PropertyGroup>


Platforms/iOS/Entitlements.Release.plist

この切り替えを入れておくと、「デバッグしたいだけなのに本番Entitlementsが混ざってインストール不可になる」といったトラブルを根本から減らせます。

より確実に原因を特定する：プロファイルとEntitlementsを“中身で照合”する

「合っているはず」をやめて、アプリに埋め込まれた情報とプロファイルの中身を比較すると、原因は一気に絞れます。Mac側で確認できる代表的な方法を紹介します。

アプリに実際に付与されたEntitlementsを確認する

ビルドされた.appに対して、署名に含まれるEntitlementsを表示します（.appのパスは環境により異なります）。

codesign -d --entitlements :- /path/to/YourApp.app

ここに出てくるaps-environmentやapplication-identifier、各種グループIDが、想定と一致しているか見ます。

プロビジョニングプロファイル（.mobileprovision）の中身を確認する

プロファイルは中身がXML（plist）なので、展開して確認できます。

security cms -D -i /path/to/Profile.mobileprovision

確認観点は次の通りです。

• Entitlements：アプリが要求するものと矛盾しないか（特にaps-environment）
• ApplicationIdentifierPrefixとapplication-identifier：Bundle IDと一致しているか
• ProvisionedDevices：対象iPadのUDIDが含まれているか（Developmentの場合）
• DeveloperCertificates：使っている証明書と一致しているか

この2つ（アプリのEntitlements、プロファイルのEntitlements）が一致しない限り、端末インストールで弾かれる可能性が残ります。

“直したのに直らない”ときの落とし穴集

最後に、復旧を遅らせがちな落とし穴をまとめます。該当しそうなものから潰すと、無駄な試行錯誤が減ります。

似た名前のプロファイルが複数存在する

• 過去に作ったプロファイルが残っていて、自動選択がズレる
• 同名に近いプロファイルを手動で選び間違える

対策：不要なプロファイルを整理し、命名規則（例：AppName Dev iPad）を固定すると事故が減ります。

Capabilitiesをいじったのにプロファイルを作り直していない

• App IDでPush通知をONにしたが、プロファイルが旧状態のまま

対策：Capabilitiesを変更したら、必ずプロファイルを再生成→再ダウンロード→取り込み直しまでセットで実施します。

証明書を更新したのに古い証明書で作ったプロファイルを使っている

• Apple Development証明書を作り直した／期限切れで更新した
• プロファイルが古い証明書を参照している

対策：証明書更新時はプロファイルも作り直すのが安全です。

Debug/Releaseの取り違え（Entitlements・プロファイル・構成）

• Debugでビルドしているのに、Release用（配布用）の設定を参照している
• 逆にReleaseなのに開発用Entitlementsが混ざっている

対策：構成ごとにEntitlementsとプロファイルを固定し、切替を明示します（前述の分離運用が効きます）。

再発防止：署名トラブルを“仕組みで起こしにくくする”

この問題は、個別に直しても、次に機能追加（Capabilities追加）や証明書更新があると再発しがちです。次の運用を入れておくと、将来的な詰まりが大幅に減ります。

再発防止策	狙い	具体例
EntitlementsをDebug/Releaseで分離	環境不一致（特にAPNs）を防ぐ	Debugはdevelopment、Releaseはproduction
Capabilities変更＝プロファイル再生成をルール化	古いプロファイルの混入を防ぐ	変更のたびに再DL＆取り込み
プロファイル命名規則を固定	選択ミスを防ぐ	App名/環境/対象端末を名前に含める
ビルド出力を診断レベルで確認できる状態に	原因特定の時間短縮	VSの出力詳細度を上げて署名情報を追う

まとめ：MT1006 / 0xe8008015は“プロファイル不在”ではなく“整合性の崩れ”で起きる

MT1006や0xe8008015（有効なプロビジョニングプロファイルが見つからない）は、Visual Studio側で証明書とプロファイルを選べていても、端末が求める署名条件と一致していないと発生します。とくにEntitlementsとCapabilitiesのズレは、ビルドでは表面化しにくく、インストール工程で初めて落ちるため厄介です。

手動プロビジョニングで“本当に一致するプロファイル”を選び、Bundle ID・端末登録・証明書・Entitlements（特にaps-environment）の整合を取る。これが最短ルートです。Push通知を扱うなら、Debug/ReleaseでEntitlementsを分離して運用すると、今後の機能追加でも詰まりにくくなります。