Google Play内部テストの設定方法（2026年版）

内部テストは、Play Consoleのトラックのなかで唯一、開発者がソフトウェアに期待するとおりに動いてくれるトラックです。ビルドをアップロードすれば表示され、あとはインストールしてもらうだけ。そう、うまくいかなくなるまでは。気づけばリンクを開いても「このアプリはお使いのアカウントではご利用いただけません」とだけ表示されるPlay Storeのページを前に、エラーコードもなければ診断情報もなく、3つのテストトラックが数百行にわたって混ざり合ったヘルプ記事を読まされることになります。この記事では、内部テストを残り2つのトラックから切り離し、Play Consoleの操作経路とテスターリストのルールを実際に必要になる順番で示したうえで、サポートスレッドを埋め尽くしている失敗のパターンにしっかり時間を割きます。Google自身のページどうしが食い違っている箇所（タイミングの記述は明らかに食い違っています）は、都合のよいほうだけでなく両方の読み方を並べて示します。内容はすべて2026年8月12日時点のものです。

内部テストはどう設定しますか？

始める前に

アプリ、ビルド、テスターのアカウント、そして自分のPlay Consoleのアクセス権を用意します。必要ないものにも注目してください。完成したストアの掲載情報、スクリーンショット、コンテンツのレーティング、データセーフティの入力は不要です。Googleは、アプリの設定が完了する前に内部テストを実施することを明確に認めています。確認済み

• 01
  Play Consoleに存在しているアプリ 作成されていればよく、中身が埋まっている必要はありません。最初にアップロードしたアーティファクトがそのアプリのパッケージ名を確定させ、あとから変更できなくなるので、applicationIdがこの先も使い続けるものかどうかを確かめてください。
• 02
  有効なアプリバンドル Googleの表現では「有効なアプリバンドル」です。早い段階の内部ビルドをテスターの手元に届けるうえで、アーティファクトに求められる条件はこれだけです。
• 03
  テスターのメールアドレス Googleアカウントが必要です。現行のヘルプは、Gmailを使うGoogleアカウント、またはGoogle Workspaceのアカウントを指定しています。各自が実際にログインするアドレスを正確に集めてください。トラック全体がそのアカウントを鍵にしているからです。
• 04
  実行できるだけのPlay Consoleのアクセス権 オーナーと管理者はすでに持っています。権限を委任されたユーザーには、テストトラックへアプリをリリースする権限が必要で、トラックとそのテスターリストの管理には、テストトラックを管理しテスターリストを編集する別の権限が必要になることがあります。リリースのボタンが見当たらない、あるいはグレーアウトしているのは、ビルドの問題ではなくアクセス権の問題です。
• 05
  Playアプリ署名（初回リリースのみ） アプリの初回リリースでは、Play ConsoleがPlayアプリ署名（Play App Signing）の設定手順を案内します。事前に準備しておくものではなく、アップロードの途中で通る一度きりの工程ですが、始める前にこれが待っていると知っておく価値はあります。

手順1：内部テストトラックを開く

アプリを選び、テストと公開 › テスト › 内部テストと進みます。Googleはこの経路を2通りに記載しています。テストの設定を解説するPlay Consoleヘルプの記事ではテスト › 内部テストと省略され、別の現行ヘルプページでは親メニューまで含めて示されています。どちらも同じ場所を指しているので、お使いのConsoleのメニューがここに書いたものより短くても、間違った場所にいるわけではありません。

手順2：内部テスター用のリストを作成する

内部テストトラックの「テスター」タブを開き、「メーリングリストを作成」を選びます。リストに名前を付け、アドレスを追加し、変更を保存してから、リストを作成します。アドレスはカンマ区切りで画面に直接入力することも、CSVでアップロードすることもできます。リストが静かに壊れるのはCSV経由のときで、一度しか書かれず二度と繰り返されないルールが3つあるからです。

テスターリストのチェックツール

手順3：リストとフィードバックの連絡先を設定する

「テスター」タブに戻り、このトラックで使うユーザーリストを選んだうえで、フィードバック用のURLまたはメールアドレスをGoogleに登録します。この連絡先はオプトインページでテスターに表示され、不具合を伝えてもらうための唯一の標準ルートになります。

手順4：リリースを作成して公開する

「新しいリリースを作成」を選び、アプリバンドルを追加し、内容を確認して、現在のConsoleの操作にしたがって公開します。Play Consoleは版によってボタンの文言が十分に異なるため、これ以上細かいクリック手順を丸暗記することは、助けではなく足かせになります。この説明がGoogleの現行ドキュメントと同じところで止まっているのはそのためです。

手順5：オプトインリンクをコピーして共有する

共有用のテスターリンクをコピーして配布します。この工程は少なくとも2018年から開発者を混乱させてきましたが、その混乱にはまったく理由があります。インターネット上のほかの招待システムはどれもメールを送るのに、Googleが示している流れでは、配布用のリンクが渡されるだけだからです。Play Consoleが代わりにテスターを招待してくれるとは考えないでください。

そのリンクがそもそも存在するかどうかは、2つの条件で決まります。オプトインリンクが表示されるのは、アプリのステータスが公開済みのときだけです。アプリがDraftやPending publicationのあいだはコピーできるものが何もなく、「テスター」タブを何度読み直してもリンクは現れません。確認済み

手順6：各テスターがオプトインしてインストールする

最後の工程はテスターのもので、自分が代わりに行うことはできません。各自が、追加したアカウントに正確にログインした状態でリンクを開き、そのページでオプトインを完了し、Play Storeのリンクをたどってインストールします。それまでは対象ではあっても参加していない状態で、対象なだけのテスターには何も届きません。リンクを送るときは、招待したアカウント名も一緒に書き添えてください。違うアカウントでオプトインしてしまうのは、この流れで最も報告の多い失敗のひとつであり、見た目はリンクの故障とまったく区別がつきません。

誰が何をするか

一連の流れを1つの表に

表を横にスクロールすると全列を確認できます

テスターがインストールできるまでどれくらいかかりますか？

内部テスト中は5つの時計が別々に動いていて、時間についての不満はたいてい、比べる相手を間違えたところから生まれます。ビルドがGoogleの配信システムに届くのが1つ目。テスターに見えるオプトインリンクが有効になるのが2つ目。公開した変更が、すでに参加している人に届くのが3つ目。インストール済みのアプリが自動更新されるのが4つ目。そして仮のストア掲載情報が本来のアプリ名に置き換わるのが5つ目で、問題なく動いている内部ビルドが数日間だけ未完成に見えるのはこのためです。

この待ち時間は普通ですか？

この質問が意味を持つのは、何を待っているのかを含めたときだけです。段階によって答えが数百倍違うからです。下のツールは両方を尋ね、その段階についてGoogleが実際に公開している表現を引用したうえで、数値のしきい値は本記事の読み方であってGoogleのものではないと明示します。

反映タイマー

すべての時計を並べて見る

表を横にスクロールすると全列を確認できます

持ち帰るべき編集上のポイントはこうです。数秒、数分、数時間、最大48時間はすべて同時に正しく、それぞれ同じパイプラインの違う部分を説明しています。これらを1つの数字に押しつぶした記事は、読者が正確さを最も必要としているまさにその瞬間に、誰かを誤らせます。確認済み

内部リリースはGoogleの審査を待ちますか？

ここは言葉づかいが重要です。Googleの2つの情報源が、同じ言い回しをしていないからです。内部テストの製品ページでは、アプリの審査を待たずにビルドを配信する方法として宣伝されています。Play Consoleのヘルプセンターはより控えめで、内部テストは通常のPlayのポリシー審査やセキュリティ審査の対象とならない場合があるとしています。

したがって正確な言い方は、内部テストでは通常、標準のアプリ審査の流れを待たずに配信できる、というものです。不正確な言い方は、内部リリースは決して審査されない、というものです。Googleはあらゆる審査からの全面的な免除を約束してはいませんし、約束したかのように書くことが、誰かの内部リリースが保留された瞬間に記事を誤りに変えます。確認済み、ただし表現に注意

内部テストはテスター12人の要件にカウントされますか？

これはこのテーマ全体で最も重大な誤解であり、しかも今も広められています。広く読まれている2026年の記事のうち少なくとも1本は、この必須要件を内部テストトラックで満たせるものとして説明しています。Google自身の要件ページは、解釈の余地のない言葉でそれを否定しています。

判断基準は一行で

信頼できる相手との素早い非公開QAには内部テストを、必須の製品版前テストが必要なときはクローズドテストを使う。ルールはこれだけで、この記事が比較についてこれ以上書かないのも意図的です。3つのトラックの詳しい比較は、そのために作った内部・クローズド・オープンテストの違いにあります。

表を横にスクロールすると全列を確認できます

この要件が実際に適用される対象

この要件には適用範囲があり、混乱のほとんどはそこで生まれています。Googleのページは、2023年11月13日以降に作成された対象の個人用デベロッパーアカウントについて記載しています。Googleがこのポリシーを発表したのは2023年11月9日で、開始日として両方の日付が引用されるのはそのためです。

組織用アカウントについては、言い方に注意してください。Googleの要件ページはこのルールを個人用アカウントに限定して記載しており、組織用アカウントが免除されると述べた文はありません。より正確な言い方は、この要件は対象となる個人用デベロッパーアカウントについて記載されており、引用したページは組織用アカウントにそれを課してはいない、というものです。適用範囲は推定

14日間オプトインしていることと、14日間使っていることは違います

数値のしきい値は、テスターが連続してオプトインしていることとして書かれていて、毎日の利用状況としては書かれていません。測定できるのはこちらです。それとは別に、Googleは製品版へのアクセスを申請したときにテストについて申告した内容を評価し、テスター数や関与が不十分であれば追加のテストを求めることがあります。競合ページの多くは、この2つをひとまとめにして、1日あたりの利用時間についての存在しないルールを作り出しています。

まとめると、しきい値はオプトインの継続であり、関与はその代わりではなく、その上に重ねて評価されます。実際に進行中のテストで何を意味するかは14日間連続のルールとテスター12人の要件を解説で扱っています。確認済み

内部テストのリンクが動かないのはなぜですか？

内部テストのコミュニティスレッドを埋め尽くしているのがこの失敗で、しかも最も文書化されていないものです。開発者は、Play Consoleに言われたことをすべてやり終えた状態でここにたどり着きます。だからこそ混乱するのです。エラーコードもなければ診断情報もなく、ページは、まるでアカウントのほうが問題であるかのように、「このアプリはお使いのアカウントではご利用いただけません」と平然と表示します。報告は2018年のStack Overflowの質問から2026年7月のGoogle Developer Communityのスレッドまで、英語でもポルトガル語でも、同じ数種類の原因を語っています。

役に立つのは、壊れたリンクとして考えるのをやめて、回路として考えることです。Googleの配信ルールは一連の条件であり、接点が1つ開いているだけでその先はすべて止まります。報告のなかで繰り返し出てくる原因は、4つの状態でカバーできます。テスターリストに入っていない、リストには入っているがオプトインしていない、オプトインしたが別のGoogleアカウントを使っている、そして設定は正しく、まだ反映中です。最後の1つはそもそも不具合ではありません。だからこそ、ここに膨大な時間が費やされます。

開いているゲートを見つける

以下のスイッチは、思い込みではなく実際に確認できたことに合わせて設定してください。ゲートは確認コストの低い順に並んでいるので、最初に開いたままのものが、次に直す価値のあるものです。

アクセスゲートシミュレーター

“このアプリはお使いのアカウントではご利用いただけません”

テスターのアクセス権は、端末やリンクではなくアカウントに紐づいています。Googleが求めているのは、そのアカウントが管理対象のテスター設定に含まれていること、かつそのテストプログラムにオプトインしていることです。どちらかが欠けていれば、Play StoreにはそのテスターとURLをたまたま見つけた他人とを区別する手段がありません。

これが実際に頻発する理由は、ごく平凡なものです。スマートフォンもブラウザも日常的に複数のGoogleアカウントにログインしていて、リンクを開くアカウントが招待したアカウントとはかぎりません。2026年3月のGoogle Developer Communityのスレッドには、アカウント選択画面が想定と違う挙動をするために、意図したアカウントへまったく切り替えられないというテスターの報告があります。2025年半ばのポルトガル語のスレッドでも同じパターンが報告されており、そこでの回答はGoogle Playで選択されているアカウントを一致させることを直接指しています。コミュニティ報告

コピーできるオプトインリンクがない

何よりも先にアプリのステータスを確認してください。Googleがオプトインリンクを表示するのは、アプリのステータスが公開済みのときだけです。DraftやPending publicationの状態では、リンクが隠れているのでも遅れているのでもなく、まだ存在していません。条件が二択で、しかも自分のConsoleから目視できるため、トラブルシューティング全体のなかで最もきれいに片づく原因です。確認済み

公開されているのに、Play検索で誰も見つけられない

それは不具合ではなく、想定どおりの動作です。Googleは、オープンテストや製品版より前の内部テスト・クローズドテストはPlay Storeの検索では見つけられないとしています。「Playでアプリを検索して」と言われたテスターは、設定がどれだけ正しくても毎回失敗し、当然のようにアプリが存在しないと報告してきます。

直接リンクを送ってください。そのメッセージのなかで、検索では見つからないことをはっきり書き添えます。誰もがまず検索を試すからです。確認済み

一部のテスターが古いバージョンのままになっている

3つの原因を順番に確認します。1つ目は反映です。追加で公開した変更がテスターに届くまで数時間かかることがあるため、直近の更新が単にまだ届いていないだけかもしれません。2つ目はバージョンコードです。ユーザーは、自分が対象となっているトラックのうち最も高い互換バージョンコードを受け取ります。すべてのユーザーが製品版の対象であるため、テスト版の低いバージョンではなく製品版の高いバージョンコードが配信されることがあり、最新の内部ビルドは実在していて正しいのに、テスターの手元にはそれが届かないという分かりにくい状況が生まれます。3つ目はトラックの対象条件です。内部テストにオプトインしているアカウントはクローズドやオープンのビルドを受け取る対象にならないため、作業を別のトラックへ移していれば、そのアカウントは違うトラックを見ていることになります。確認済み

すべて問題ないのに、それでも失敗する

ここで初めて、コミュニティで知られている対処を試す価値が出てきます。端末を再起動する、Play Storeを再起動する、Play Storeのキャッシュやデータを削除する、まっさらなブラウザプロファイルでリンクを開く、といったものです。これらはGoogleのポリシーではなくGoogle Developer Communityのスレッド由来で、記載された動作というより「誰かの環境では効いた」という報告です。これらを最初に試してしまうせいで、開発者は何日も失います。設定の問題は直せませんし、反映の遅れを成功だと勘違いさせてしまうからです。コミュニティ報告

本当の境界事例もあります。2026年2月のコミュニティスレッドには、内部テストのリンクが最初から一度も機能しなかったという報告があり、2026年5月のスレッドではオプトインページがHTTP 500を返したと報告されています。どちらも一般的な根本原因は特定されておらず、技術的な説明をでっち上げるくらいなら、分からないと認めるほうがましです。設定が検証可能な形で正しく、反映の時間枠も過ぎていて、失敗が継続する、あるいはサーバーエラーが返るのであれば、設定をいじり続けるよりPlay Consoleのサポートへエスカレーションするのが妥当な段階です。原因未確認

症状から対処へ、根拠の確度つき

表を横にスクロールすると全列を確認できます

間違えられやすい上限とルール

表を横にスクロールすると全列を確認できます

内部テストと内部アプリ共有

この2つは名前が紛らわしいだけの別機能で、選び間違えると午後がまるごと消えます。内部テストはこの記事全体で扱っている正式なトラックで、リリースがあり、最大100人のテスターリストを管理し、オプトインがあり、更新はGoogle Play経由で配信されます。内部アプリ共有は、アップロードしたAPKやアプリバンドルからダウンロードリンクを作って渡すだけの簡易共有ツールです。こちらにも独自のアクセス制御はあり、内容が違うだけです。Googleの解説ページによれば、ダウンロードをメーリングリストに限定することも、送った相手なら誰でも開けるようにすることもできますが、いずれの場合もテスターは先に自分のPlay Storeアプリで内部アプリ共有をオンにする必要があります。

実務上の使い分けはこうです。10分以内に同僚へビルドを渡したいときは内部アプリ共有、バージョン履歴とテスターリストが欲しく、あとから昇格できるビルドが必要なときは内部テストトラック。引っかかりやすいのは60日の期限で、2か月前のバグ報告に貼られたリンクは、設定が壊れているのではなく単に死んでいます。どちらの機能も、テスター12人のクローズドテストにはカウントされません。確認済み

アプリ内購入の落とし穴

内部テスト中はすべて無料、というよくある説明を真に受けないでください。Googleのルールは、アプリ本体と、その中で売られているものを分けています。有料アプリ本体は、内部テスターが無料でインストールできます。アプリ内購入は、そのテスターのアカウントがライセンステスターとしても設定されていないかぎり、通常どおり課金されます。

サブスクリプションを含むテストでは、この違いが実際の金額に直結します。しかも、現在上位に表示されている比較記事の少なくとも1本は、真逆のことを書いています。テスターに購入フローを試してもらう予定があるなら、先にライセンステストを設定するか、実際に課金されることを覚悟してください。確認済み

あなたの落ち度ではない2つのこと

ネット上にある一般的な内部テストのアドバイスの多くは、原因になりえないものを直せと言っています。時間を浪費させ、ときには正常な設定まで壊してしまいます。

検証した主張と、その判定

以下の各行は、内部テストについて実際に流通している主張です。判定の列は、もっともらしく聞こえるかではなく、一次情報が裏づけている内容です。

• 誤り
  “内部テストがテスター12人のテストとしてカウントされる” Googleの要件ページはクローズドテストを明示的に求めています。14日間をまるごと失わせるという意味で、このテーマで最も損害の大きい誤りです。
• 情報が古い
  “テスターは今も20人必要” 2024年12月11日以降は過去の話です。現在の最低人数は12人です。
• 誤り
  “内部テスターは購入もすべて無料になる” 無料なのは有料アプリ本体だけです。アプリ内購入は、ライセンステストを設定していないかぎり課金されます。
• 誤り
  “テスターが海外にいるなら、その国を追加する” Googleは内部テストを、その配信上の制限から明示的に除外しています。
• 誤解を招く
  “すぐに動かないリンクは壊れている” Google自身が、最初のリンクには数時間、その後の変更にも数時間を見込んでいます。
• 誤解を招く
  “テスターにはオプトインリンクが自動でメール送信される” Googleが示している流れでは、デベロッパーが共有用リンクをコピーして配布します。Play Consoleが代わりにテスターを招待してくれる前提で計画しないでください。
• 一部正しい
  “内部テストでGoogleグループを使える” 現行のConsoleヘルプは、内部テストにはメーリングリスト、クローズドテストにはGoogleグループを記載しています。Publishing APIのtestersリソースはグループをより広く扱えますが、それが2026年のConsoleのこのトラックでの動作を裏づけるわけではありません。記載されているメーリングリストの方法を使い、グループを前提に計画しないでください。
• 一部正しい
  “Googleが認めている内部トラックはちょうど1つ” Publishing APIは標準の内部トラックを1つのwell-knownトラックとして公開しており、ヘルプは名前付きのクローズドトラックを追加できることを記載していますが、内部トラックの数は明示していません。厳密な上限があると断定せず、「標準の内部テストトラック」と呼ぶのが正確です。
• 正しい
  “ストアの掲載情報が未完成でも内部テストを実施できる” Googleは、有効なアプリバンドルさえあれば、アプリの設定が完了する前でも内部配信できるとしています。
• 正しい
  “テストで受け取ったフィードバックは公開評価に影響しない” Googleは、テストユーザーからのフィードバックはアプリの公開評価に影響しないと明記しています。

内部テストを終了する

トラックを一時停止します。テスターはすでにインストール済みのアプリをそのまま保持しますが、そのトラック経由でのテスト更新は受け取らなくなります。トラックを一時停止すれば誰かの端末からアプリが消えると思い込む前に、知っておく価値があります。実際には消えません。確認済み

ビルドをクローズドテストへ移すにはどうしますか？

内部テストがうまくいったあと、多くの人が次にたどり着くのがこの段階で、製品版アクセスの時計が実際に動き出すのもここです。以下の説明であえてボタン単位の手順書にしていないのは、Play Consoleの版によって表示が異なり、丸暗記したクリック経路が真っ先に通用しなくなるからです。

1. 01
   移動先のトラックを開く テストと公開 › テスト › クローズドテストに進み、使いたいクローズドトラックを管理します。
2. 02
   そのトラックでリリースを作成する クローズドのリリースは、すでにテスト済みのアーティファクトを載せる場合でも、それ自体が独立したリリースです。
3. 03
   「ライブラリから追加」でテスト済みのアーティファクトを再利用する アプリバンドルをもう一度アップロードするのではなく、内部テストのときにアップロードしたバージョンを選びます。この部分はGoogleの現行のリリース関連ヘルプ（回答 9859348）に記載があります。確認済み
4. 04
   クローズドテストのテスターを設定する クローズドトラック側のテスター設定を使います。クローズドテストでは、現行のヘルプがメーリングリストまたはGoogleグループのどちらにも対応しており、ここが内部トラックとの実際の違いです。
5. 05
   内容を確認して公開する そのあとは、内部テストのときと同じようにクローズドテストのオプトインリンクを共有します。条件も同じ2つです。リストに載っていること、そしてオプトインしていること。

同じテスターをそのまま使えますか？

人としては使えますが、同時にオプトインした状態にはできません。この段階では、この違いが何よりも多くのクローズドテストを壊しています。

内部テストにオプトインしているアカウントは、オープンテストやクローズドテストのビルドを受け取る対象になりません。Googleの指示は、テスターがまず内部テストをオプトアウトし、それからクローズドテストにオプトインする、というものです。つまり、丁寧に集めた内部QAのメンバーをそのままクローズドテストのメンバーにすることは十分できますが、全員が自分で内部トラックを抜けないかぎり、クローズド側では何も見えません。

表を横にスクロールすると全列を確認できます

ここから先の仕組みは、まったく別の話になります。14日間連続でオプトインし続けてくれる人を集めること、その人数を正しくカウントさせること、そして製品版アクセスの質問票を乗り切ることです。これらはクローズドテストへのテスター招待方法、Play Consoleでオプトイン済みが0人と表示される理由、製品版アクセス質問票で扱っています。

PrimeTestLabが担う範囲

この引き継ぎ地点は正確に押さえておく価値があります。2つのトラックは、まったく違う理由で失敗するからです。内部テストが失敗する原因は設定です。まだ存在していなかったリンク、オプトインしていないアカウント、待ちきれなかった反映時間。どれも丁寧に読めば解決できるもので、この記事の前半3分の2はそのためにあります。

クローズドテストが失敗する原因は人です。Googleが公表している数値条件は、直近14日間にわたってクローズドテストに連続でオプトインしているテスター12人以上というもので、実際には、参加してくれて2週目にもまだ残っている12人の人間を意味します。この人数とは別に、テスターにはビルドをインストールして意味のある形で使ってもらう必要があります。製品版アクセスの申請を審査する際、Googleは関与度、機能の利用状況、フィードバックについて質問するからです。どちらもドキュメントの問題ではなく、Consoleにいくら詳しくても解決しません。多くの開発者がこれに気づくのは、内部テストを終えて、要件がまったく動いていないと分かった瞬間です。

クローズドテストを自分で行うか、任せるか

表を横にスクロールすると全列を確認できます

はい、いまはテスター25人のほうがテスター20人より安くなっています。これは誤記ではなくキャンペーンです。現在はEnterpriseに3プランのうち最も大きな割引を適用しているため、テスター1人あたりの単価も最も低く、Professionalの$1.50に対しておよそ$1.12になります。どちらのプランも同じクローズドテストを実施します。順番が逆転しているのはキャンペーンのためだけで、この記事の執筆後に金額が変わっている可能性もあるので、最新の数字は料金ページをご確認ください。

120+か国7,400+件のアプリで、クローズドテスト要件について99.9%の成功率を維持しています。一方で、承認を保証するとは申し上げません。Googleは製品版アクセスの申請を独自の基準で審査し、追加のテストを求めることもあります。特定の結果を約束する人は、自分では制御できないものについて語っています。私たちがお約束するのは、制御できる部分です。テストが通らなかった場合は、無料の再テストまたは全額返金をお選びいただけます。

内部テストのよくある質問

まとめ