CLOVE管理サイトと公式システムを結ぶ証拠：9つの論点、原本、検証手順
見慣れない管理URLなら「模倣サイト」と言えるかもしれない。スクリーンショットなら切り取りを疑える。しかし、会社発表、公式プログラム、Googleの設定応答、過去の第三者アーカイブがつながるとき、説明すべき対象はもっと具体的になる。
本記事では資料を公開する。鸚鵡の判断に同意しなくても、原本を開き、関係をたどり、証拠がどこまで届くかを自分で確かめられる。
確認基準日：2026年9月5日。以下の9項目は想定される説明の検討であり、CLOVEが実際に述べた回答ではない。
疑うなら、原本を開こう。3ステップの画像ガイド
本鸚鵡の言葉を先に信じる必要はない。URLを開き、名前を検索欄に貼り付ければ、原文を自分で読める。 以下は実際のChrome画面。画像を押すと拡大できる。
ステップ1：管理ログインの入口とGoogleの一覧を確認する
管理サイトの入口を開くと、ログイン画面に移動する。この画像で入口を確認し、次の資料でCLOVE公式システムとのつながりを確かめよう。
公式サイトと管理ログインページのコードは、同じプロジェクト設定を使っている。そのプロジェクトについてGoogleが返した一覧にも、clove.jp、oripa.clove.jp、clv-admn-next.vercel.app が並ぶ。保存したGoogle応答の原本を開くと比較できる。これはプロジェクト設定上の技術的な関連を示す資料であり、会社の所有権証明書ではない。
ステップ2：公開フロントエンドの2つのファイルを開く
アカウントもログインも不要。次のリンクを直接開く。
- 操作定義：2902-1b4cb7dff6c6ef54.js——操作の正式名と入力引数を見る。
- 日本向け管理ページ：list-0f33ebdda397cc72.js——オリパIDの送信と結果の読み取りを見る。
文字が詰まっているのは正常だ。サイトがブラウザーに配信するコードなので、変更せずに検索する。
ステップ3：Ctrl＋Fで、この名前をそのまま検索する
Windows／Linuxでは Ctrl＋F、Macでは ⌘＋F。余分な空白を付けず、次の名前をすべて貼り付けてEnterを押す。
scheduleAssignGuaranteedWinOripaUsers操作定義ファイルで2か所、日本向け管理ページで3か所見つかる。 2026年9月5日に読み取った版での件数だ。サイトがファイルを更新した場合は、下の原本パッケージにある保存版と比較できる。
この名前は原文に存在し、管理ページもその返り値を処理している。 ここまでは誰でも直接確認できる。サーバー側の選定方法や、どの有料取引で実行したかを調べるには、実行・取引記録が必要だ。
画像とコードの確認日：2026-09-05。画像・出典・ファイルのハッシュ。この画像ガイドは追加資料であり、既存ZIPはそれぞれの保存版と署名を維持している。
店、奥の部屋、住所録で考える
確認するのは5つだ。
- 店の紹介を読む。 会社自身が、そのブランドを自社サービスとして紹介しているか。
- 部署番号を比べる。 売り場と奥の部屋の書類に、同じ番号が書かれているか。
- 登録住所録を見る。 システムを提供するGoogleも、両方の住所を一緒に掲載しているか。
- 古い副本を開く。 第三者が以前保存した資料と、今調べる資料が一致するか。
- 作業記録を見る。 手引きに作業があっても、いつ行ったかは記録で確かめる。
最初の4つには、実際に開ける資料がある。5つ目には実行と取引の記録が必要だ。店と奥の部屋がつながっても、誰がどの景品を受け取ったかまで見えたわけではない。
これはたとえ話である。「住所録」に当たるのは許可された移動先の一覧で、所有権の証書や従業員名簿ではない。以下に実際の資料を残した。
原資料と詳しい照合を開く
会社とClove製品の関係
TrustHub公式サイトはクローブオリパを自社サービスとして掲載し、oripa.clove.jpへリンクしている。AppleのClove掲載ページには販売元としてTRUST HUB, K.K.が記載され、会社発表とSMBCの2024年10月15日発表も会社と製品の関係を示す。
ここでつながるのは会社と製品だ。管理サイトとの技術的な関係は、次の資料で確かめる。
公式サイトと管理ログイン画面が同じプロジェクトを参照
clove.jpの公式JSと管理ログイン画面のJSには、共通のFirebase公開識別情報がある。
| 項目 | 共通の値 |
|---|---|
| プロジェクトID | clove-v2-prd |
| App ID | 1:385949280493:web:224ed7999dd0740cfdc4e4 |
| 認証ドメイン | clove-v2-prd.firebaseapp.com |
公開設定キーのハッシュも一致する。詳細は証拠パックのidentity-chain-sources.jsonにある。Firebaseの説明にあるとおり、この種のキーはプロジェクト識別用であり、管理画面にログインする権限そのものではない。
公開コードはコピーできる。設定が同じというだけで終わらず、次にGoogle側の応答を確認した。
Googleの応答にも管理ドメインが含まれる
2026年9月5日03:56 UTC頃、両プログラムの公開設定識別情報を使い、Googleの公開プロジェクト設定エンドポイントからHTTP 200の応答を取得した。2つの本文はバイト単位で一致し、プロジェクト番号は385949280493だった。
authorizedDomainsには、clove.jp、oripa.clove.jp、clv-admn-next.vercel.appが同時に含まれている。
関係は、Googleから返された設定にも及んでいる。 管理サイトが公式システムと完全に無関係だと説明するなら、なぜ同じプロジェクトの許可ドメインに含まれるかも説明する必要がある。
Googleのフィールド定義では、これはウィジェットのリダイレクトを許可するドメインの一覧だ。設定上の技術的な関係を示す一方、法人所有者、Vercelアカウント所有者、操作担当者の名簿ではない。誰がいつ設定したかは、IAM、設定変更履歴、デプロイ記録で確認する対象になる。
2つのGoogle原本JSONはpublic-captures/にあり、共通のSHA-256は次のとおり。
7a574650bdfa74f1460bb31500d691ff8d6a386660b56cfe21239675e936228b過去の第三者アーカイブと照合する
2026年8月23日02:14:55 UTCのWayback公式JS保存版は、9月5日に保存した公式JSとバイト単位で一致した。このコードは今回の収集以前から存在していたことになる。
SHA-256：
df59333f5c2ff7ff223e7b321575fd86c6d6aaaa86622f84fa9946ecf70204fa9月5日の管理ログインJS保存版も原本と一致する。SMBCと会社発表にも閲覧可能な副本がある。Appleの副本は閲覧できるが、今回の取得ファイルとバイト列が異なり、完全一致とは扱わない。
8月のJS保存版から、9月のGoogle設定が以前も同じだったとは言えない。資料ごとの日時を混同しないことが必要だ。
ここまでの連鎖は、会社 → Clove製品 → 公式・管理プログラムの共通プロジェクト → Google設定に含まれる管理ドメインとなる。異論があるなら、どの資料や推論に問題があるかを具体的に示せる。
そのうえで、割り当て機能の用途を問う
日本、v2、香港、米国向けの2つの在庫管理版には、ユーザー割り当て予約の実装がある。日本版listコードには商品選択、入力確認、予約送信、結果処理があり、共通操作定義にはscheduleAssignGuaranteedWinOripaUsersがある。各地域の原本リンクは調査本文に掲載している。
同時に、周辺には「アド確定オリパ」の表示がある。この呼び出しで送るoripaIdsは商品・オリパのIDであり、この操作には任意の当選者ユーザーIDを入力する項目はない。参加資格の割り当てという説明は、具体的に検証すべきものだ。
システムの関係と、実際に行った処理は別の段階である。 次の段階には実行記録が必要になる。
想定される9つの説明と、確認すべき記録
実際の回答を得た場合は、以下の仮説と混ぜず、原文・日付・出典を別途掲載する。
1.「模倣サイトで、当社と無関係」
「当社の部屋ではない」なら、同じ番号と住所録の記載も合わせて説明する必要がある。
原資料と詳しい照合を開く
ブランドのコピーだけでは全資料を説明できない。公式JSと管理JSの共通設定、Googleの許可ドメインを含めた説明が必要だ。Vercelプロジェクト・チームの管理記録、ドメイン変更履歴、会社と開発会社のデプロイ関係を示せば、管理権限をさらに確かめられる。
2.「外注、旧版、テスト環境にすぎない」
古い外注先の部屋なら、いつ、誰の仕事に使ったかを記録で示せる。
原資料と詳しい照合を開く
管理共通コードは複数のapi.prd.*.clove.jpを参照し、公式側とプロジェクト設定を共有する。環境の役割は検証できる。prdという名前だけでは本番稼働の証明にならず、リリース対応表、デプロイ日時、ルーティング、通信記録が判断材料になる。
3.「スクリーンショットやコードを改変した」
紙を差し替えたと言うなら、原本と他所に残る副本を並べて比べる。
原資料と詳しい照合を開く
どのファイルのどの箇所かを示してほしい。原本、SHA-256、記録したURL、第三者保存版を比較できる。一致するアーカイブは独立した照合点となり、タイムスタンプは特定のハッシュを固定する。ただし、ハッシュは一致を確認するものであり、記事の解釈まで証明するものではない。
4.「使っていないコード」
手引きにあっても未実施はあり得る。作業記録で確かめる。
原資料と詳しい照合を開く
候補商品取得、入力確認、操作呼び出し、結果処理が連なった実装であることは確認できる。実際の使用にはresolverの版、ジョブ作成・完了履歴、DB記録が必要だ。画面への組み込みと実行済み処理を、別々の証拠で確かめる。
5.「通常のアド確商品の参加資格を割り当てるだけ」
特典の参加券だけなら、事前に説明した条件と、配った相手を照合する。
原資料と詳しい照合を開く
この説明には文脈上の根拠がある。選定ルール、資格条件、対象商品ID、購入制限、支払前の説明、割り当て結果、通常オリパとの境界を示してほしい。公開済みの特典資格だけを割り当てた記録があれば、その事実に沿って判断する。開示を超える用途があれば、そこが争点になる。
6.「当選者指定も、有料利用者への影響もない」
特定のお客さんの領収書と結果をつなぐ必要がある。その完全な対照はまだない。
原資料と詳しい照合を開く
現時点の公開資料には、これを直接反証する完全な取引対照はない。商品ID、ジョブID、実行時刻、割り当て、決済、抽選結果を、購入時の説明と照合する必要がある。公開資料は匿名化し、完全な記録は権限のある独立検証者に提示できる。関数名だけで全利用者の損失を証明することはできない。
7.「複数アカウントへの措置で、証拠隠滅ではない」
退出を求めることと領収書を燃やすことは違う。理由と記録の有無を確認する。
原資料と詳しい照合を開く
公式規約には複数アカウントなどを理由とする措置がある。停止だけで報復や記録破棄を証明することはできない。個別事例では日時、理由、不服申立て対応、保存期限、バックアップ、記録提供方法を確認する。ログイン不能と全記録の消去を混同しない。
8.「AIの分析が間違っている」
分析者の名前より原本を見る。誤りは直し、残りも検証する。
原資料と詳しい照合を開く
分析文は原本の代わりにならない。ここでは公開コード、設定応答、保存版を提供し、誤読の指摘を受け付ける。以前の日本版listファイルにadminSoftDeleteがあるという引用は撤回した。当該ファイルとデコード済み過去版にその文字列を確認できなかったためだ。他の証拠も同じ基準で検証する。
9.「もうシステムを変更した」
新しい手引きは古い内容を書き換えない。日付ごとに比べる。
原資料と詳しい照合を開く
新版は現在の動作を変えられるが、過去に公開したファイルの内容までは変えられない。変更日、版、変更範囲、デプロイ記録で比較すべきだ。変更や削除それ自体を、自認、報復、抽選操作の証拠とは扱わない。
原本・公開分析・タイムスタンプ
このサイトで配布するZIPは公開用の再編集版である。取得した応答本文とコードは元のバイト列を維持し、内部編集メモは公開説明に置き換えた。DISTRIBUTION.jsonに維持・編集・除外項目を記載し、SHA256SUMS.txtで新版の各ファイルを照合できる。
- 公開ソースパック：HTTP本文、JS、WARC、保存サービスの記録
- 関係資料パック：Google設定、会社資料、コード文脈、補完4ファイル
- 5言語の公開分析と検証ツール
- サイズ、SHA-256、署名情報の一覧
新版ZIPにはそれぞれRFC 3161タイムスタンプがある。ZIP名に.tsrを加えると応答、.tsqを加えると要求ファイルになる。prior-seals/の旧署名は旧ZIPのハッシュを対象とし、新版ZIPの検証には使えない。ソースパックには、当初の証拠一覧自体を対象とする署名も残してある。
保存記録には閲覧可能なWayback副本24件と、Archive.todayの旧記事1件がある。旧記事の訂正は現行本文を参照してほしい。Arquivo.ptの20記録は公開統合の確認待ち、Google設定のWayback保存は未完了、Perma.ccは完了受領記録がないため、成功件数には含めない。
自分で検証する手順
1. ダウンロードを確認する
ZIPのサイズとSHA-256をrelease.jsonと比較する。Windows PowerShell：
Get-FileHash -Algorithm SHA256 -LiteralPath .\clove-identity-public-20260905.zip解凍したパックの直下でpython verify_files.pyを実行すると、SHA256SUMS.txtの各項目を照合する。ローカルファイルだけを読み、ネットワーク通信や保存JSの実行は行わない。
2. 出典をたどる
ソースパックのcapture-manifest.json、関係資料パックのadditional-public-manifest.jsonとidentity-chain-sources.jsonから、URLとファイルを対応させる。Apple、会社発表、SMBCの一部補完資料はHTTPヘッダーを保存できておらず、一覧に明記している。
テキストエディタで2つのJSを開き、プロジェクトID、App ID、認証ドメインを検索する。次にpublic-captures/admin-firebase-public-config.jsonのprojectIdとauthorizedDomainsを、Googleのフィールド定義と照合する。
3. 操作の前後を読む
日本版listでscheduleAssignGuaranteedWinOripaUsers、oripaIds、アド確定オリパ、ユーザーの自動割り当て予約を検索する。引数、対象商品、結果処理を読み、共通chunkの操作定義へ進む。英語の関数名だけでは重要な文脈が抜け落ちる。
recovered-missing-entries/の4ファイルは旧一覧のハッシュに一致するが、回収日は9月5日である。元のZIPに当初から入っていたとは扱わない。
4. 保存日時と署名を検証する
Waybackの14桁の日時はUTCである。実際のreplayと最終URLを確認し、保存したバイト列を比較する。ジョブの送信成功は閲覧可能な保存版の完成とは異なり、動的HTMLの差だけで偽造とは判断できない。
ZIPと同名の.tsr、FreeTSAのCA証明書、署名証明書を同じフォルダに保存し、実行する：
openssl ts -verify -data clove-identity-public-20260905.zip -in clove-identity-public-20260905.zip.tsr -CAfile cacert.pem -untrusted tsa.crt成功時はVerification: OKと表示される。FreeTSA公式手順から証明書を独立に取得してもよい。信頼の基礎は当該認証局と証明書チェーンであり、Bitcoinへの記録は主張していない。タイムスタンプは署名対象のハッシュが発行時点に存在したことを示すが、サイトの著作者、抽選結果、疑惑の成立を証明するものではない。
次につなぐべきものは、利用者の取引記録
システム間の関係は、誰でも順に検証できる形になった。利用者への影響を判断するには、同じ商品のルール、割り当て、決済、結果、アカウント措置を照合する必要がある。
記録で説明できるなら、その説明を示してほしい。矛盾があるなら、その箇所を示してほしい。 この調査も同じ検証を受ける。
鸚鵡によるCARDZ.GAMEの推薦と紹介コードの開示は調査本文の末尾にある。推薦はCLOVEに関する証拠の強さを変えず、推薦先も同じ基準で検証する。