.NET AndroidのFragment置換後に前画面がタップできる“ゴーストタッチ”の原因と完全対策（Commit/CommitNow/ExecutePendingTransactionsの違いを徹底解説）
アプリの画面遷移で Fragment を置換した直後、すでに表示されていないはずの前画面（例：pageA）のボタンがタップできてしまう――いわゆる「ゴーストタッチ」に困ったことはないでしょうか。これは .NET Android（Xamarin/Android、.NET for Android）で FragmentTransaction.Replace() と Commit() を用いた際に起こり得る、実務でも頻出の落とし穴です。本記事では再現から原因、最適解、さらにパフォーマンスやBackStack、アニメーションとの兼ね合いまで、現場で使える具体策を幅広くまとめます。MAUIやShell、プラットフォーム固有コードとの住み分けにも触れ、検索で辿り着いた方がこの記事だけで解決できることを目指します。
現象の再現：Replace + Commit 直後に前画面がタップできる
以下のように pageA から pageB へ置換するコードを書いたとします。
var transaction = SupportFragmentManager.BeginTransaction();
transaction.Replace(Resource.Id.fragment_container, new PageBFragment());
transaction.Commit(); // ※非同期
画面上は確かに pageB が表示に切り替わります。しかし、pageB の背景や一部Viewが透明だったり、タッチを消費しない領域があると、下に残存している pageA のViewがタップを受け取ってしまうことがあります。これが「ゴーストタッチ」です。
なぜ起こるのか：Commitは非同期、古いViewは即時には消えない
Commit()は非同期…FragmentTransactionを即時に実行するのではなく、メインスレッドのキューに「やること」を積むだけです。実処理は次フレーム以降に反映されます。- 古いViewは一時的に階層に残る…トランザクションが未反映の瞬間、
fragment_containerにはpageAとpageBのViewが併存している状態になり得ます。 - Inputの配達順序…タッチイベントは 最前面（Z順）のViewから配布されます。
pageBがイベントを消費しない場合、背後のpageAにイベントが回り、ボタンが反応してしまいます。
時間軸で見ると以下のような流れです。
// t0: Replace/Commitを呼ぶ（トランザクションはキューに積まれるだけ）
transaction.Replace(...);
transaction.Commit();
// t1: 同フレーム中にユーザーがタップ → View階層はまだA+Bが混在
// pageBがタップを消費しない箇所だと、背後のpageAにイベントが到達
// t2: 次フレーム以降でトランザクションが適用され、pageAがようやく除去
結論（要点）
ゴーストタッチの根本原因は「置換直後に古いViewが残っている」ことです。従って、解決の方向性は次のいずれか（あるいは組み合わせ）になります。
- 古いViewを確実に除去（Remove/Replaceの適用を即時に完了させる）
- トランザクションを同期的に適用（
CommitNow()、またはExecutePendingTransactions()） - 一時的にタッチをブロック（オーバーレイ・ウィンドウフラグ・親コンテナで吸収）
それぞれの具体策を表で俯瞰し、続いて詳細を解説します。
| 対応策 | 要点 | メリット | 留意点 |
|---|---|---|---|
置換前に pageA を明示的に削除 | Remove(pageA) → Replace(...) → Commit()。古いViewを必ず除去する指示を入れる。 | 古いViewの残存をロジック上防ぐ。 | 実適用は非同期のため、Commit()直後の瞬間は残る可能性。必要に応じて同期化（下段）と併用。 |
CommitNow() を使う | Replace(...).CommitNow() で即時適用。 | 置換がその場で完了し、古いViewは残らない。 | BackStack不可、重い処理でフレーム落ちの恐れ。 アニメーション中の強制反映は不整合の温床。 |
ExecutePendingTransactions() を呼ぶ | Commit() 直後にキュー上のトランザクションを即時実行。 | BackStackと両立しつつ同期化できる。 | 大量/複雑なトランザクションでは一時的にUIが詰まる可能性。 |
| 一時的にタッチを無効化 | 短時間だけウィンドウやコンテナでタッチを吸収。 | UXが安定。レース条件を確実に抑止。 | 多用すると操作感が重くなる。解除忘れに注意。 |
実装テンプレート：安全なFragment置換のベストプラクティス
1) Remove + Replace + 同期化（推奨）
BackStackも使いつつ、確実に古いViewを消す最も実用的なパターンです。
using Android.OS;
using Android.Views;
using AndroidX.Fragment.App;
public void NavigateToPageB()
{
var fm = SupportFragmentManager;
var pageA = fm.FindFragmentByTag("PageA");
var tx = fm.BeginTransaction()
.SetReorderingAllowed(true); // 推奨：遷移の整合性と最適化
if (pageA != null)
{
tx.Remove(pageA);
}
tx.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB")
.AddToBackStack(null) // 戻るでAに戻したい場合
.Commit(); // 非同期
// <重要> 置換をこの場で反映させ、古いViewを残さない
fm.ExecutePendingTransactions();
}
ポイント：
SetReorderingAllowed(true)はAndroidXで推奨される設定。遷移の整合性が上がり、トランザクションの順序最適化が働きます。ExecutePendingTransactions()を併用することで非同期のズレを詰め、ゴーストタッチの窓を閉じます。- 必要なら
.AddToBackStack(null)を付け、戻る操作でpageAを自動復元します。
2) Replace + CommitNow（即時置換）
遷移を完了させてから次行に進むため、確実に古いViewが残りません。BackStackは使えません。
var tx = SupportFragmentManager.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB");
// <注意> CommitNow() と AddToBackStack() は併用不可
tx.CommitNow();
注意：アニメーション中の即時適用は唐突な描画切り替えを生み、視覚的不整合の原因になります。特に複雑なShared Elementや遅延トランジション(postponeEnterTransition)を使うケースでは避けましょう。
3) Commit + ExecutePendingTransactions（BackStackと両立）
BackStackを使いつつ同期的に反映させたいときの王道です。
var fm = SupportFragmentManager;
fm.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB")
.AddToBackStack("PageB")
.Commit();
// 非同期キューをこの場で掃き出して反映
fm.ExecutePendingTransactions();
この呼び出しはメインスレッドをブロックするため、重いフラグメント初期化を伴う大量遷移の直後には使いどころを見極めます。
タッチを物理的にブロックする補助策（安全弁）
置換が完了するまでの短時間だけ、タッチを根こそぎ遮断するテクニックです。遷移の種類や端末負荷に左右されない安全弁として有効です。
ウィンドウ全体を一時的にタップ不可
using Android.Views;
// タップ無効化（超短時間）
Window.SetFlags(WindowManagerFlags.NotTouchable, WindowManagerFlags.NotTouchable);
// 置換を即時適用
SupportFragmentManager.ExecutePendingTransactions();
// 解除
Window.ClearFlags(WindowManagerFlags.NotTouchable);
全画面の操作が止まるためUXはやや硬くなります。適用時間を最短にすること、解除忘れをしないことが重要です。
コンテナでタッチを吸収する（オーバーレイ/リスナー）
using Android.Views;
using Android.Runtime;
class BlockTouchListener : Java.Lang.Object, View.IOnTouchListener
{
public bool OnTouch(View v, MotionEvent e) => true; // すべて消費
}
// 遷移直前に付与し、完了後に外す
var container = FindViewById<View>(Resource.Id.fragment_container);
container.SetOnTouchListener(new BlockTouchListener());
var fm = SupportFragmentManager;
fm.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB")
.Commit();
fm.ExecutePendingTransactions();
// 完了したら解除
container.SetOnTouchListener(null);
細かい制御が効く一方、解除忘れがバグに直結します。テストで確実に担保しましょう。
「Replaceしたのに残る」典型パターンと見分け方
- 透明View/クリック非消費領域…
pageBの背景が透明でクリックリスナーもないと、背後のpageAが反応します。 - Add/Show/Hideの混用…以前に
Add()で追加したフラグメントが Hide されただけで、その後のReplace()と競合し、階層に残り続けることがあります。 - 誤ったFragmentManager…親ではなく
ChildFragmentManagerを使うべき箇所でSupportFragmentManagerを使う（またはその逆）と、意図せぬ重なりが生じます。 - 複数コンテナのID取り違い…似たIDを持つ
FrameLayoutを2つ以上使っていると、想定と異なるコンテナにViewが残りがち。
デバッグTips：
- Layout Inspector で「いまView階層に何が残っているか」を3Dで確認する。
- 開発者オプション「レイアウト境界を表示」で、透明範囲やタップ抜けを視覚化。
View#isShown/View#Visibility（C#ではView.Visibility）をログに出して、表示・非表示・削除の遷移を確認。
BackStackと戻る操作の正しい設計
Replace(...).AddToBackStack(null) を併用すれば、戻るで pageA が復元されます。一方、Remove(pageA) を使ってBackStackに積まない場合、戻るとアプリ終了（または前のActivity）に戻るのが自然です。ユーザー期待に合わせ、以下を使い分けましょう。
| 要件 | 推奨 | 備考 |
|---|---|---|
| 戻るで前画面に戻したい | AddToBackStack | ナビゲーション履歴が積み上がる |
| 新規スタート的に遷移したい | Remove + BackStack未使用 | 戻るでアプリが閉じるのが自然なフロー |
| 即時反映を優先 | CommitNow() | BackStack不可に注意 |
アニメーション・トランジションとの兼ね合い
- カスタムアニメーション（
SetCustomAnimations）やShared Elementを伴う場合、CommitNow()は避け、Commit()+ExecutePendingTransactions()で整合性を保つ方が安全です。 - 遅延トランジション（postponeEnterTransition）を使う場合、フラグメント側でデータや画像の読み込み完了後に startPostponedEnterTransition() を呼ぶ設計にして、ブロッキング時間を短縮します。
SetReorderingAllowed(true)はほぼ常にON推奨。不整合が起きにくく、パフォーマンスにも寄与します。
非同期とメインスレッド：状態喪失（State Loss）の地雷を避ける
遷移をアクティビティの状態保存後（例：回転、バックグラウンド遷移直後）に行うと、IllegalStateException もしくは commit が無視されることがあります。どうしても必要なら CommitAllowingStateLoss() / CommitNowAllowingStateLoss() がありますが、画面復元に失敗する覚悟が必要です。基本は「安全なタイミング（表示中・フォアグラウンド）でコミットする」ことを徹底します。
安全なナビゲーション・ヘルパー（実用クラス）
毎回レシピを書くのは手間なので、置換を確実に即時反映する小さなヘルパーを用意しておくと開発効率が上がります。
using AndroidX.Fragment.App;
public static class FragmentNavigator
{
public static void ReplaceImmediate(FragmentActivity activity, int containerId, Fragment dest, string? tag = null, bool addToBackStack = true)
{
var fm = activity.SupportFragmentManager;
var tx = fm.BeginTransaction().SetReorderingAllowed(true)
.Replace(containerId, dest, tag);
if (addToBackStack) tx.AddToBackStack(tag);
tx.Commit(); // 非同期に依存しない
fm.ExecutePendingTransactions(); // 同期適用
}
}
統一的にこのヘルパーを使えば、チームで置換直後のゴーストタッチを再発させにくくなります。
UI/UXの工夫：操作不能時間を気づかせない
- スクリーン・スクラム（半透明オーバーレイ）で視覚的に遷移中を示す。
- プログレスインジケーターを短時間表示（操作不可を自然に感じさせる）。
- タップ音/波紋を抑制し、誤タップの学習を防ぐ。
以下は簡易オーバーレイ例です（解除までタップを吸収）。
// レイアウトに <FrameLayout android:id="@+id/scrim" ... /> を用意し、初期は GONE
var scrim = FindViewById<View>(Resource.Id.scrim);
void ShowScrim() { scrim.Visibility = ViewStates.Visible; }
void HideScrim() { scrim.Visibility = ViewStates.Gone; }
// 遷移時
ShowScrim();
var fm = SupportFragmentManager;
fm.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB")
.Commit();
fm.ExecutePendingTransactions();
HideScrim();
MAUI/Shellとの住み分け
- .NET MAUI を使う場合、通常のページ遷移は
Shell.GoToAsync()/Navigation.PushAsync()が基本です。 - Android固有の高度な演出やネイティブコンポーネントを扱うためにプラットフォーム固有でFragmentを直接操作するなら、本記事の方針（
ExecutePendingTransactions()など）を適用します。
アンチパターン（避けるべき実装）
- とりあえず
CommitAllowingStateLoss()…クラッシュを隠すだけで、復元不能な状態を生みます。正当な理由がない限り避けましょう。 - Addを重ね、Hide/Showだけでやりくり…View階層が太り、タッチ抜けやメモリ増加を招きます。基本は Replace。
- タッチ問題を根本解決せず、無制限にNotTouchable…UXを損ねます。短時間・確実解除が鉄則。
チェックリスト：これでゴーストタッチとサヨナラ
- Replace後は即時反映できているか？ …
CommitNow()かExecutePendingTransactions()を使う。 - BackStackの意図は明確か？ … 戻るの挙動を設計に合わせる。
- 透明/非消費領域はないか？ …
pageBの背景/クリック処理を確認。 - 正しいFragmentManagerを使っているか？ … 親 or 子のどちらか。
- アニメーション中の同期化に無理はないか？ …
SetReorderingAllowed(true)を付ける。 - 緊急停止策は用意したか？ … オーバーレイやウィンドウフラグで短時間だけブロック。
- Layout Inspector で実機のView残存がないか可視化したか？
サンプル：最小構成の安全なページ遷移
using Android.OS;
using AndroidX.Fragment.App;
[Activity(Label = "MainActivity")]
public class MainActivity : FragmentActivity
{
protected override void OnCreate(Bundle? savedInstanceState)
{
base.OnCreate(savedInstanceState);
SetContentView(Resource.Layout.activity_main);
if (savedInstanceState == null)
{
// 初期表示
SupportFragmentManager.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageAFragment(), "PageA")
.Commit();
SupportFragmentManager.ExecutePendingTransactions();
}
}
public void NavigateToB()
{
var fm = SupportFragmentManager;
fm.BeginTransaction()
.SetReorderingAllowed(true)
.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB")
.AddToBackStack("PageB")
.Commit();
fm.ExecutePendingTransactions(); // ゴーストタッチを防ぐ
}
}
public class PageAFragment : Fragment
{
public override View OnCreateView(LayoutInflater inflater, ViewGroup? container, Bundle? savedInstanceState)
{
var view = inflater.Inflate(Resource.Layout.fragment_a, container, false);
var btn = view.FindViewById<View>(Resource.Id.to_b_button);
btn.Click += (_, __) => (Activity as MainActivity)?.NavigateToB();
return view;
}
}
public class PageBFragment : Fragment
{
public override View OnCreateView(LayoutInflater inflater, ViewGroup? container, Bundle? savedInstanceState)
{
// 透過背景だと下のAが触れる可能性があるので注意
return inflater.Inflate(Resource.Layout.fragment_b, container, false);
}
}
レイアウトの注意：fragment_b は必ず全面を覆う背景（不透明に近い）か、クリックを消費するルートView（Clickable=true）にして、背後のタップ抜けを防ぎます。
QA：よくある質問にまとめて回答
Q. Remove(pageA) すれば確実に消えますか？
A. 論理的には消えますが、Commit() が非同期な限り、直後の瞬間はまだ残ります。CommitNow() または ExecutePendingTransactions() を併用して即時適用するのが確実です。
Q. CommitNow() と ExecutePendingTransactions() はどちらがよい？
A. BackStack不要かつ即時性最優先なら CommitNow()。BackStackを使いたい/遷移が複雑なら Commit() + ExecutePendingTransactions()。多くの業務アプリでは後者が扱いやすいです。
Q. タップを吸うだけの対応で十分？
A. 一時的な安全弁としては有効ですが、根本は「古いViewを残さない」こと。両輪で対処しましょう。
Q. 透明領域が必要なデザインです。どう防ぐ？
A. 透明でも構いませんが、ルートViewをClickableにしてタッチを消費する、または不可視オーバーレイを敷いて遷移完了まで吸収します。
Q. フレーム落ちが怖いです
A. 重い初期化は onViewCreated 以降に遅延させる／骨格描画→差し替え描画の二段構成にする／SetReorderingAllowed(true) を使う、などで緩和します。
Q. MAUIだけ使っています
A. 通常は Shell.GoToAsync() を使い、Fragment直接操作は不要です。Android固有の機能に踏み込むときだけ本記事の知見を適用しましょう。
まとめ：確実に「古いViewを残さない」仕組みを入れる
フラグメント置換後に前画面がタップできる問題は、Commitの非同期性とView残存が本質です。以下のいずれかを満たせば解消します。
- 置換を即時完了…
CommitNow()またはCommit()+ExecutePendingTransactions() - 古いViewを確実に除去…
Remove(pageA)を明示してから置換 - 短時間のタッチ遮断…ウィンドウフラグ/オーバーレイ/親コンテナで吸収
さらに SetReorderingAllowed(true)、BackStack設計、透明領域のタッチ消費、Layout Inspectorでの可視化を組み合わせれば、再発の可能性は限りなくゼロに近づきます。本記事のテンプレートとチェックリストをプロジェクトに取り込み、チーム全体で安全なFragment遷移を標準化してください。
（付録）元の質問に対する要点整理
質問概要（再掲）
.NET Android で pageA から pageB へフラグメント置換時、Replace() → Commit() だと、表示は pageB でも pageA のボタンがタップできてしまう。
原因（再掲）
Commit()は非同期で即時完了しないpageAのViewが一時的に残存し、タッチを受け取る
回答・解決策（再掲＋実務補足）
| 対応策 | 要点 | メリット | 留意点 |
|---|---|---|---|
1. 置換前に pageA を明示的に削除 | var pageA = SupportFragmentManager.FindFragmentByTag("PageA"); var tx = SupportFragmentManager.BeginTransaction(); if (pageA != null) tx.Remove(pageA); tx.Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB"); tx.Commit(); SupportFragmentManager.ExecutePendingTransactions(); // 実務では併用推奨 | pageA のViewを確実に除去 | BackStackに積まないなら戻るで復元不可。 同期適用を併用して窓時間をゼロにするのが現場的。 |
2. CommitNow() を使う | SupportFragmentManager .BeginTransaction() .SetReorderingAllowed(true) .Replace(Resource.Id.fragment_container, new PageBFragment(), "PageB") .CommitNow(); | 同期実行で即時入れ替え | アニメ/BackStackと相性難あり。重い遷移ではフレーム落ちの恐れ。 |
3. ExecutePendingTransactions() を呼ぶ | transaction.Replace(...).Commit(); SupportFragmentManager.ExecutePendingTransactions(); | 非同期処理を即時実行 | 大量のネスト/複雑な遷移ではブロック時間に注意。 |
補足：
- BackStackを使う場合は
.AddToBackStack(null)。
削除（Remove）した場合はBackStackに積まず、戻るとアプリ終了になることが多い点に注意。 - UIの重なり確認はLayout Inspectorが最速。
- MAUI Shell利用時は
Shell.GoToAsync()が一般的。FragmentTransactionはプラットフォーム固有コードで必要なときにのみ直接扱う。
以上で、フラグメント置換後のゴーストタッチ問題を理論と実装の両面から解消できるはずです。プロジェクトの性質（BackStack/アニメーション/負荷）に合わせ、「即時適用」＋「安全弁」の二段構えを標準化しましょう。
コメント