Visual Studioでビルドした.NET MAUI（Android）のApp Bundle（AAB）をGoogle Play Consoleの内部テストにアップロードした際、「There is no deobfuscation file associated with this App Bundle」という警告が出て戸惑うことがあります。ここでは警告の意味、よくある原因、Visual Studio側でまず見直すべき配布手順、難読化（R8/Proguard）を使っている場合の対処まで、実務目線で整理します。
結論：Visual Studioの配布フローで「署名→Save As（書き出し）」まで完了したAABをアップロードする
この警告に対して、いきなりAndroidプロジェクト設定（難読化のON/OFFなど）を変更する前に、まずは「Google Play向けに正しく署名されたAABを、配布（Distribute）で最終書き出ししているか」を確認してください。
実際に解消したポイントはシンプルで、Distribute（配布）でSigning Identity（署名）を選んだあとに、必ずSave Asで最終成果物（AAB）を書き出し、そのファイルをアップロードすることです。Save Asを押さずに、途中生成物（あるいは別経路のAAB）をアップロードしていた場合、Google Play Console側で想定外の警告が出ることがあります。
| まず最初にやること | 狙い | 期待する変化 |
|---|---|---|
| 公式の公開手順どおりに、署名付きAABを“最終書き出し”する | アップロード対象のAABが「配布用の完成品」かを担保する | 警告が消える／または原因の切り分けが一気に進む |
| DistributeでSigning Identity選択後、Save AsでAABを保存してからアップロード | 途中成果物や未署名・別構成のAABの混入を防ぐ | 「deobfuscation fileがない」系の指摘が出にくくなる |
警告「There is no deobfuscation file associated with this App Bundle」の意味
Google Play Consoleの警告「There is no deobfuscation file associated with this App Bundle」は、アプリが壊れているというエラーではなく、“難読化（obfuscation）をしているなら、難読化解除ファイル（deobfuscation file）を関連付けるとクラッシュ/ANR解析がしやすい”という趣旨の案内です。
deobfuscation file（難読化解除ファイル）とは
一般的なAndroidの文脈では、次のようなファイルを指します。
- R8 / Proguard の mapping ファイル（mapping.txt）
難読化によって短縮されたクラス名・メソッド名を、元の名前に復元（リトレース）するための対応表です。 - （補足）ネイティブデバッグシンボル
NDKを使うアプリでは、ネイティブクラッシュ解析のために別種のシンボルをアップロードするケースもあります。今回の警告の主役は多くの場合「mapping」です。
この警告が出たら、致命的にまずいのか？
多くのケースで、公開や内部テストの継続自体は可能です。ただし、難読化を有効にしている状態で放置すると、将来クラッシュが起きた際にレポートが読みにくくなり、原因究明が遅れがちです。
| あなたの状況 | 警告の実害 | おすすめ対応 |
|---|---|---|
| R8/Proguardの難読化を使っていない | 基本的に実害は小さい（解析性向上の案内に近い） | まずは配布手順（署名付きAABの書き出し）を見直す |
| 難読化を有効にしている（縮小・難読化） | クラッシュ/ANRのスタックトレースが読みにくくなる | 該当バージョンのmappingファイルをPlay Consoleへアップロード |
| 難読化の有無が不明 | 原因切り分けが難しい | ビルドログ・生成物・設定を確認して判断する |
.NET MAUI（Android）でこの警告が出やすい“実務的な理由”
.NET MAUIのAndroid配布では、Visual Studio側の操作によって「同じReleaseでも、アップロードしているAABが実は別物」になりやすいタイミングがあります。特に、次のようなパターンがハマりどころです。
よくある原因
| 原因 | 起きやすいこと | 見分け方 | 対策 |
|---|---|---|---|
| Distributeのフローを途中で止め、Save Asせずに別ファイルをアップロード | 意図しない中間成果物や別構成のAABを提出してしまう | アップロードしたAABの生成経路を説明できない／保存場所が曖昧 | 署名選択後にSave AsでAABを書き出し、そのファイルのみをアップロード |
| bin/Release配下のAABを“それっぽいから”使ってしまう | 署名状態や構成差分で挙動が変わる | 配布ウィザードの成果物ではない | 基本はDistributeで作った成果物を使う（運用を固定） |
| 難読化を有効にしているのにmappingをアップロードしていない | Playが「関連付けがない」と警告する | ビルド出力にR8/Proguardの処理ログ、mapping生成が見える | Play Consoleでバージョンごとにmappingをアップロード |
今回のケースでは、「Save Asを押さずに途中成果物をアップロードしていた」可能性が高く、Save Asで最終AABを書き出してからアップロードしたところ警告が出なくなった、という流れが最も筋が通ります。
解決手順：Visual Studioで署名付きAABを正しく書き出してアップロードする
ここからは、警告を潰すために“まず再現性の高い形”に手順を揃えるやり方です。Visual StudioのUIはバージョンや拡張機能で若干表記が異なるため、言葉は近いものを探してください（重要なのは流れです）。
手順の全体像（やることは「最後まで書き出す」）
- 構成をReleaseに切り替える
Debugのまま配布物を作ると、最適化や署名の扱いが揺れやすくなります。 - アーカイブ（Archive）を作成する
配布ウィザードに乗せるための“スナップショット”を作ります。 - Distribute（配布）を開始する
- Signing Identity（署名）を選択する
Google Playに出すAABは署名が前提です。 - Save AsでAABを保存する
ここが最重要です。この手順で保存されたAABのみをGoogle Playへアップロードします。 - Google Play Console（内部テスト）にアップロードして確認する
“Save Asを押す”が重要な理由
Distribute（配布）フローの途中段階では、Visual Studio内部に「アーカイブ情報」や「一時出力」が存在していても、Google Playに提出すべき“完成品としてのAAB”が確定していないことがあります。Save Asで明示的に保存することで、
- どの署名（keystore）を使ったか
- どの構成（Releaseなど）で作ったか
- どのファイルが“提出物”か
が一本化され、アップロード時の混乱や差分が減ります。結果として、Play Console側の解析も想定どおりになり、警告が消える（あるいは次のアクションが明確になる）ことが多いです。
それでも警告が残る場合：難読化（R8/Proguard）の有無で次の一手が変わる
配布フローを揃えても警告が残る場合は、ここからが本題です。次の分岐で対応を決めると、無駄に設定をいじらずに済みます。
分岐早見表
| 確認したいこと | 確認方法（例） | YESなら | NOなら |
|---|---|---|---|
| R8/Proguard（縮小/難読化）を有効にしているか | プロジェクト設定（Android）／ビルド出力ログにR8/Proguardの記述があるか | mappingファイルをPlay Consoleへアップロードする運用にする | 警告は基本“解析性の案内”なので、まずは無視しても致命傷になりにくい |
| アップロードしたAABはDistributeのSave Asで出力したものか | 保存場所と生成手順を言語化できるか | 次の確認（mapping運用）へ | 手順をやり直してAABを作り直す |
難読化を使っている場合：mappingファイルをアップロードしてクラッシュ解析性を上げる
もしR8/Proguard（コード縮小・難読化）を有効にしているなら、警告は実質「mappingファイルをアップロードしませんか？」という提案です。ここを整備しておくと、公開後の火消し速度が変わります。
mappingファイル運用のポイント
- mappingは“バージョンごと”に管理します。別バージョンのmappingを当てると復元が崩れます。
- 内部テストでも本番でも同様に、クラッシュ解析の品質に関わります。早めに運用を固めるほど後が楽です。
- .NET MAUIアプリでも、Android側（Java/Dex、依存ライブラリ、生成コード）に難読化がかかると、Play Consoleの表示は読みにくくなります。
mappingファイルが生成されているかの確認方法（Visual Studio側）
環境や設定により場所は多少変わりますが、次の考え方で探すと見つけやすいです。
- ビルド出力（Output）で「r8」「proguard」「mapping」という文字列を検索する
- プロジェクトの出力ディレクトリ（特にobj配下）に「mapping.txt」相当のファイルができていないか確認する
見つかったら、そのファイルが対象バージョンのものか（ビルドした構成・バージョンコードと一致するか）を確認して保管します。
Google Play Consoleへdeobfuscation fileをアップロードする手順（概略）
Play ConsoleのUIは更新されることがあるため、ここでは“迷わないための見方”として説明します。
- Play Consoleで対象アプリを開く
- 対象のリリース（内部テストや本番）で、アップロードしたAAB（バージョンコード）を特定する
- 該当バージョンの詳細画面でDeobfuscation files（難読化解除ファイル）の項目を探す
- mappingファイルをアップロードし、関連付けを完了する
アップロード後、同じ画面で「紐づけ済み」になっているか、また警告が改善するかを確認します。
Visual Studio側の設定は変更すべき？判断の基準
質問として多いのが「Visual Studio側のAndroidプロジェクト設定を変えるべきか？」です。ここは、警告を消すこと自体が目的になってしまうと遠回りになります。判断基準は次のとおりです。
設定変更を急がなくてよいケース
- 難読化（R8/Proguard）を使っていない、または意図して使っていない
- クラッシュ解析の運用（どこでログを見るか、誰が見るか）がまだ固まっていない
- まずは内部テストの配布を前に進めたい（警告はブロックではない）
この場合は、配布手順（署名付きAABの最終書き出し）を正して、警告が残っても「必要になったらmapping運用を始める」で問題になりにくいです。
設定と運用を見直すべきケース
- 難読化を有効にしている（アプリサイズ削減や難読化が目的）
- リリース後にクラッシュ/ANRをPlay Console中心で追う予定がある
- 不具合解析を短時間で回したい（復旧速度を重視する）
この場合は、警告を放置せず、mappingをバージョンごとに保管してアップロードする運用を作ることをおすすめします。設定そのものを変えるというより、成果物と解析ファイルをセットで管理する発想が重要です。
実務で効くチェックリスト：内部テストに出す前に見る項目
最後に、同種の警告や差分を減らすためのチェックリストをまとめます。チーム内で手順を固定するだけでも、再発率が下がります。
| チェック項目 | 見るポイント | ありがちな落とし穴 |
|---|---|---|
| AABの生成経路 | Distribute→署名選択→Save Asで保存したAABか | bin/ReleaseのAABを“提出物”にしてしまう |
| 署名 | 想定のkeystore/Signing Identityで署名されているか | 別の証明書で署名してしまい、後で更新できない |
| Release構成 | Releaseでビルドしているか（Debug混入防止） | Debugで内部テストへ出して挙動が変わる |
| 難読化の有無 | R8/Proguardを意図して使っているか | ON/OFFが曖昧でmapping運用も曖昧になる |
| mapping運用 | 難読化を使うなら、バージョンごとにmappingを保存しているか | 後から探しても見つからず、解析が詰む |
まとめ：まずは「完成品AAB」を固定し、必要ならmapping運用を追加する
- Google Playの「このApp Bundleに紐づく難読化解除ファイルがありません」警告は、多くの場合致命的エラーではなく解析性向上の案内です。
- 最初にやるべきは、設定変更よりも公式手順どおりの配布フローに揃えることです。
- 特に、Visual StudioのDistributeでSigning Identityを選んだあとにSave AsでAABを書き出し、そのファイルをアップロードするのが重要です。
- 難読化（R8/Proguard）を使っているなら、将来の調査効率のためにmappingファイルをPlay Consoleへアップロードする運用を整えるのがおすすめです。
コメント