LaunchRepo申請が審査待ちなのは、ディレクトリが受け取ったものの、まだ判断していないときです。公開中なのは、無関係の第三者が掲載を開けて、そこに「審査待ち」を示す表示が何もないときです。予約済みは、プラットフォームがローンチ日を確定したことを意味します。提出済みは、それだけでは、あなたがボタンを押したことしか意味しません。この4つの言葉は4つの異なる瞬間を表しており、それらを1つの「完了」列にまとめて保存するトラッカーは、誰も説明できない合計を報告することになります。この記事では、それぞれの状態と、何が証拠になるか、そして検証に耐える数字でディレクトリのローンチを報告する方法を説明します。総称としての用語の短い定義は掲載ステータスの解説を、日々の運用については二重カウントせずにディレクトリ申請を追跡するガイドをご覧ください。
1つの列に、5つの問い
ディレクトリにプロダクトを申請したとき、結果を気にする人たちが知りたいことはそれぞれ違います。
- 自分の側の作業は終わったか？ すべて入力して、ボタンを押したか。
- プラットフォームは受け取ったか？ お礼のページ、メール、アカウント内の項目。
- 何かを待っているか？ モデレーション、キューの枠、承認、日付。
- 一般の人に見えるか？ ログインしていない人でも開けて、「審査待ち」の表示がないURL。
- 自分が何かをする必要があるか？ CAPTCHA、2要素認証の確認、自分のウェブサイトへのバッジの設置、有料ルートについての判断。
「完了」は最初の問いに答えながら、黙って4つ目の問いにも答えたことにしてしまいます。こうして、40と書かれたスプレッドシートが実は6を意味する、ということが起きます。最初の2つの問いの違いには専用の解説があります：下書きと提出済み。
審査待ちと公開中、予約済みと提出済みの違い
最も混同されやすい組み合わせです。各行は、状態を変える前に確認すべき問いです。
| 組み合わせ | 違い | 次の状態に進めるための証拠 |
|---|---|---|
| 提出済みと審査待ち | 提出済みはあなたの行動。審査待ちは、モデレーションが始まったことをプラットフォームが認めた状態 | プラットフォームからの受領の証拠：完了ページ、メール、ダッシュボードの項目 |
| 審査待ちと公開中 | 審査待ちは判断を待っている状態。公開中は公開されていて、ラベルが付いていない状態 | ログアウトした状態で公開URLが開け、「審査待ち」の表示がない |
| 予約済みと公開中 | 予約済みには確定した日付がある。公開中には公開ページがある | その日付以降にページを開く |
| キュー待ちと予約済み | キュー待ちには順番がある。予約済みには日付がある | プラットフォームが日付を明示する |
| 公開中と既存の掲載 | 公開中は今回の申請によるもの。既存の掲載は作業を始める前から存在していたもの | 最初に既存の掲載がないかを確認する |
最後の行は見た目以上に重要です。ディレクトリにすでにあなたのプロダクトが掲載されている場合、もう一度申請すると重複が生まれ、プラットフォームがそれを却下したり削除したりすることがあります。だからトラッカーには、そのための専用の状態があります。
11の状態を、答える問いごとに分類する
LaunchRepoのトラッカー（submissions.json に書き込む record.py と、ローカルダッシュボードにある同じルール）は、11の状態を使います。どの状態にも、記録する前に必要な最低限の観察があります。ダッシュボードは各プラットフォームを必ず1つのグループに分類するので、グループの合計は常に、試したプラットフォームの数と一致します。
| 問い | 状態 | ダッシュボードのグループ | 次の行動 |
|---|---|---|---|
| 自分の側の作業 | draft |
draft |
仕上げて申請するか、破棄する |
| 自分の側の作業 | prepared_needs_human |
needs_you |
指定された手順を行う：CAPTCHA、2FA、バッジ、判断 |
| 受け取り済み | submitted_pending_review |
pending |
示された審査期間の後に再確認する |
| 受け取り済み | queued |
queued |
キューを待つ。再確認はしても、再申請はしない |
| 受け取り済み | scheduled |
scheduled |
確定した日付に掲載を開く |
| 公開 | live |
live |
何もしない。URLを保管する |
| 公開 | already_listed |
already_listed |
何もしない。再申請しない |
| 停止 | blocked |
problem |
利用資格やアカウントの上限を解消するか、見送る |
| 停止 | unavailable |
problem |
ルートが使えるようになったら再試行する |
| 停止 | deferred_paid |
parked |
あなたの判断：実行の外で支払うか、見送る |
| 停止 | not_a_fit |
parked |
なし |
11と聞くと多く感じるかもしれません。しかし実際には、どの状態も、隣の状態とまとめてしまったせいで少なくとも一度は誤ったレポートが生まれたからこそ存在しています。各状態の具体的なコマンドは結果の記録ガイドで紹介しています。
例1：SaaSHub、公開されているが審査待ち
公開しているSaaSHubの実践ガイドに記録したとおり、SaaSHubへの申請では、リンクを知っていれば誰でも開けるプロダクトページができました。そのページには、目に見えるラベルも付いていました：Pending approval（承認待ち）。
1列だけのトラッカーは、ページが開けるというだけで、これを完了、あるいは公開中とさえ記録してしまいます。LaunchRepoのルールはその逆です：公開アクセスできることだけでは、承認された証拠になりません。 ページに審査待ちと書かれている間、掲載は submitted_pending_review のままです。live に移るのは、誰かがもう一度ページを開き、審査待ちの表示がないことを確かめ、明示的な確認フラグを付けてURLを記録したときだけです。申請した日に公開中の数は増えませんでした。代わりに、その行には再確認する日付が付きました。
例2：TinyLaunch、予約済みだが承認はまだ
TinyLaunchの実践ガイドに記録したとおり、TinyLaunchは無料のStandardルートで、将来の週のローンチ枠を提示しました。日付が確定した後、ダッシュボードにはその横に Waiting for approval（承認待ち）と表示されていました。
これを記録する誤った方法は2つあります。カレンダーに日付があるからと live にすること、あるいは承認がまだだからと submitted_pending_review にすることです。トラッカーは確定した日付とともに scheduled を記録し、承認がまだであることはメモに残します。日付が存在すること、そしてそれが守られないかもしれないこと、両方の事実が残ります。トラッカーはまた、プロダクトの最短公開日より前の scheduled の日付を拒否するので、来週月曜日の無料枠が、ローンチページの準備ができる前に公開されてしまうことはありません。この状態は予約掲載の解説で、1段落で説明しています。
トラッカーが拒否すること
ページに書かれたルールは、簡単に読み飛ばされます。以下のルールはスクリプトが強制します。これは2026年9月30日に、新しいワークスペースで例のプロダクトを使って実際に実行したものです。公開している実践ガイドに対応する6件の結果を記録した後、SaaSHubを公開中に昇格させようとしています。buckets.py はこの記事のために書いた4行のヘルパーで、ダッシュボード自身のグループ分けの関数が返す内容を表示します。
$ python3 scripts/record.py --project projects/my-product saashub submitted_pending_review --note 'Public page labelled Pending approval' --next-action 'Recheck the label after the review window'
Recorded saashub: submitted_pending_review
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 2, "scheduled": 2, "problem": 2}
$ python3 scripts/record.py --project projects/my-product saashub live --note 'Page loads' --next-action None
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product saashub live --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Tracker rejected input: Platform exists: inspect the record and use --replace intentionally
$ python3 scripts/record.py --project projects/my-product saashub live --replace --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Recorded saashub: live
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 1, "scheduled": 2, "live": 1, "problem": 2}ここでは3つのことが起きています。「ページが開ける」だけでは live には足りません。トラッカーは確認済みの公開URLと確認フラグを求めます。既存の行が黙って上書きされることは決してなく、変更するには意図的な --replace が必要です。そしてSaaSHubを昇格させると、1つのプラットフォームが審査待ちから公開中に移りますが、提出済みは4のままです。状態の変更は新しい申請ではないからです。公開中の掲載が記録されると、その行には誰でも確認できるURLが付きます。
1つの合計ではなく、3つの数
良いレポートは、決して1つの数字だけを示しません。3つの数字を示し、それぞれが別の問いに答えます。
- 提出済み： プロダクトを受け取ったプラットフォームの数。ダッシュボードでは
pending+queued+scheduled+liveです。 - 公開中： 今日リンクできる公開掲載の数。
- 要対応： 人の対応を待っている行の数。
同じルールで、実行の目標に何が数えられるかも決まります。ツールキットのランブックは、プラットフォームが初めて submitted_pending_review、queued、scheduled、live のいずれかに達したときに1回だけ数えます。下書き、引き継ぎ、有料ルート、却下された候補、already_listed は目標を進めず、同じプラットフォームへの後からの更新も二度は数えません。本当に申請したものが後でモデレーションで却下された場合は、提出済みとして数えたままにします。訂正するのは誤って記録された受領だけで、それには --invalidate-run-confirmation を使います。
私たち自身のパイロットが、この区別が大事な理由を示しています。創業者のページで公開しているSeoMapの2026年9月14日のログには、211件の申請の試行があり、公開中が20件、審査待ちが97件、予約済みが24件でした。残りの70件は、この3つのどの状態にも達していませんでした。「211件完了」は、ある意味では正しくても、役に立つ意味ではすべて間違いだったでしょう。
エージェントにとって、あなた以上にこれが必要な理由
5つのディレクトリに手作業で申請するなら、どれが審査待ちで、どれにカレンダーが表示されたかを覚えていられます。AIエージェントはそうはいきません。セッションを実行して終了し、翌日に、しかも別のマシン上の別のエージェントとして再開することもあるからです。まずトラッカーを読み、状態から判断します。
prepared_needs_humanの行と、確認の時期が来たscheduledのローンチが最優先です。- 示された審査期間を過ぎた
submitted_pending_reviewの行は再確認します。対象は既存の記録であり、順番を飛ばすための新しい申請は決して行いません。 liveの行はそのままにします。
状態が間違っていれば、これらの判断はすべて間違いになります。初日にSaaSHubを公開中と記録していたら、承認されたかどうかを誰も確認しなかったでしょう。TinyLaunchを単に提出済みと記録していたら、ローンチ日にページを確認する人はいなかったでしょう。状態はエージェントの記憶であり、それを読む場所がローカルダッシュボードです。
自分の実行を準備しているなら、LaunchRepoの仕組みでトラッカーがワークフローのどこにあるかがわかります。SaaS創業者向けのページでは、実際のローンチカレンダーがあるプロダクトについて説明しています。トラッカー、ダッシュボード、そして299件のアクティブなプレイブック（2026年9月24日時点）は、一回払いのライセンスに含まれています。
よくある質問
審査待ちと公開中の違いは何ですか？
審査待ちは、ディレクトリが申請を受け取り、審査がまだ終わっていない状態です。公開中は、掲載が公開されていて、審査待ちの表示がない状態です。開けるページでもまだ審査待ちのことがあるので、URLだけでなく表示を確認してください。
予約済みの掲載はもう公開されていますか？
いいえ。予約済みは、プラットフォームがローンチ日を確定したという意味です。掲載はその日に公開され、承認がまだ終わっていないこともあります。公開中と記録する前に、その日以降にページを開いてください。
お礼のページが出たら、申請は承認されたということですか？
いいえ。お礼のページは、フォームが送信されたことを示すだけです。証明できるのはせいぜい受領までなので、プラットフォームが掲載を公開するまで、状態は審査待ちです。
申請はどれくらい審査待ちのままですか？
プラットフォームの審査にかかるだけの期間です。無料ルートは遅いことが多く、このサイトのある実践ガイドには、30日を超える見込みが記録されています。プラットフォームが示す期間に従い、示されていなければフォローアップの日付を決めておきましょう。
掲載が審査待ちのままなら、再申請すべきですか？
いいえ。審査期間の後に既存の申請を再確認し、プラットフォームのルールが許すなら問い合わせてください。再申請は重複を生むおそれがあり、キューの順番も上がりません。
出典：LaunchRepoツールキット1.9.0の RUNBOOK.md（状態の表、数え方と訂正のルール）、scripts/record.py、scripts/dashboard_status.py、2026年9月30日の実際のトラッカーの実行、公開しているSaaSHubとTinyLaunchの実践ガイド（2026年9月13日に観察）、創業者のページにあるSeoMapの2026年9月14日のログ。