CheckMate を運営しているのは誰で、どんな原則に基づいているか

誰が開発し責任を負っているのか、分析結果をどこまで信頼できるのか、そして何を根拠にコンテンツを修正しているのか。

最終更新: 2026年7月16日

運営者

名前: Imagine (이매진)
形態: 個人が開発・運営する無料サービス
連絡先: dlaudwls1203@gmail.com
ソースコード: https://github.com/thingineeer
公開開始: 2026年3月

現時点で有料商品がないため、事業者登録の詳細は公開していません。決済を伴う機能が追加された場合は、必要な通信販売事業者の届出とあわせて、事業者情報をここに掲載します。

なぜ作ったのか

Instagram のフォロー解除チェックアプリの多くは、アカウントのパスワードやアカウントへの常時接続を必要とし、私はそれを避けたいと考えました。そこで、Instagram があなた自身のリクエストに応じて提供するデータエクスポートファイルを、ブラウザ内で直接読み込む方式を選びました。

企画、TypeScript の分析エンジン、インターフェース、デプロイ、サポートの返信はすべて運営者1人が担当しています。実際のエクスポート構造が変わった場合は、サンプルを再確認し、パーサーと説明文を一緒に更新します。

分析はどのように動くのか

Instagram に JSON 形式のデータエクスポートをご自身でリクエストします。
CheckMate はブラウザのメモリ上で ZIP または JSON を展開し、つながり（connections）のファイルを探します。
フォロワーとフォロー中を比較して、相互フォロー、フォローし返していないアカウント、ファンを算出します。
ユーザーネームの不一致は、新形式に安定した ID が含まれる場合にのみ照合し、それ以外はすべて可能性として表示します。

ファイルがたどる正確な経路は次のとおりです。アップロードボタンを押すと、ブラウザが ZIP をメモリに読み込み、JSZip を使って connections/followers_and_following/ 配下の JSON ファイルだけを取り出します。パース関数（src/lib/igFormat.ts）が旧形式と新形式の両方を同じ形に正規化し、分析関数（src/lib/analyzer.ts）が2つのリストを突き合わせます。この過程でネットワークリクエストは一切発生しません。結果画面の4つの数字（フォロー中、フォロワー、相互フォロー、フォロバなし）とリストはすべてそのメモリから生成され、タブを閉じると消えます。サーバーに送られるのはページビューなどの一般的なサイト分析だけで、それもアップロードした内容と結合されることはありません。コードは公開リポジトリの同じパスで確認できます。

エクスポートの範囲は、アカウントやリクエストした時期によって異なることがあります。CheckMate は一律の365日制限を前提とせず、ファイル内で実際に観測された期間を使用します。

精度と解釈の限界

ユーザーネームの変更に影響されない照合は、最新のエクスポートに安定したアカウント ID が含まれる場合にのみ可能です。
旧形式の URL はユーザーネームに基づいており、タイムスタンプの一致はユーザーネーム変更の可能性を推定する二次的な手がかりにすぎません。
停止、削除、ブロックされたアカウントとエクスポートの欠落は、ファイルだけでは完全には区別できません。
結果はつながりを整理するための参考情報であり、Instagram によるアカウント状態の公式な判定ではありません。

上記の限界は抽象的な免責事項ではなく、実際のファイルで確認した事実に基づいています。運営者自身のアカウントの 2026-08-18 のエクスポートを開いたところ、固有のアカウント ID がなかったのは followers_1.json と following.json の2ファイルだけで、同じ ZIP 内の残り8ファイルにはすべて含まれていました。そのため、この2ファイルだけからユーザーネームを変更したアカウントを確定する方法はなく、CheckMate は「ユーザーネーム変更の可能性」を示すにとどめています。詳しい数値は全10ファイルの内訳にあります。逆に、「フォロワーは直近1年分しか含まれない」というよくある主張は、同じファイルでは成り立ちませんでした。543件のうち86.4%が1年より古く、最も古いものは2018年まで遡ります。とはいえ、サンプルは1アカウントのみなので、これがすべてのアカウントに当てはまるとは結論づけていません。結果と再現方法は365日制限の実測記事にまとめています。

執筆時に守っている基準

このサイトの技術記事は、3つの情報源のみに依拠しています。1つ目は Meta が公開しているドキュメントとヘルプページ。2つ目は運営者自身のアカウントから直接取得したエクスポートファイルの観察。3つ目は公開されているパーサーのコードが実際に行っていること。この3つで確認できないことは推定として明記し、観察がどこで終わり解釈がどこから始まるかを文単位で区別しています。

これにより、何を書かないかも明確になります。ユーザーのファイルから集計した統計は存在しないため、決して引用しません。サービス開始の2026年3月より前に運営者が何かを観察したかのようには書きません。製品が画面に表示していない機能を、あたかも存在するかのように説明しません。この3つのルールはリポジトリ内で文のパターンを検査するテストによって強制され、違反するとビルドが失敗します。

実測記事のサンプルは1アカウントです。別のアカウントや別のリクエスト日で同じ結果になることは保証せず、読者が同じ手順で自分のファイルを確認できるよう、各記事に再現用スクリプトを添えて公開しています。反例が報告された場合は検証して記事を更新し、改訂履歴を残します。

これらの基準は実際に適用されています。2026年8月19日にブログ全体を再点検し、サービス開始前の自社データを出典であるかのように引用していた文、およびユーザーの集計データと読める表現をすべて修正し、製品にない機能を説明していた記事や根拠を復元できなかった記事4本は修正ではなく削除しました。残した記事では、出典のない数値を表の横で推定と明記するか、定性的な記述に書き換えました。同日、サイトガイド内の「興味関心分析」など画面にない機能に関する文言も削除しました。それ以降に公開した実測記事は、上記の3つの情報源と単一サンプルの原則に従っています。

プライバシーとコンテンツの点検

元の ZIP、ユーザーネームの一覧、DM の内容、相手のアカウント名がサーバーに送信されることはありません。再読み込みするかタブを閉じると、分析用メモリから消えます。一般的なサイト分析は、アップロード結果の収集とは切り離して管理し、プライバシーポリシーで開示しています。

技術記事は、検証済みの JSON キーと実際のファイルの観察に基づいて書いています。検証していないサンプル、運営期間、アルゴリズムの数値、成功率を事実であるかのように公開することはありません。

運営者への連絡

バグの再現、プライバシーに関するお問い合わせ、コンテンツの修正依頼は dlaudwls1203@gmail.com までメールでお送りください。公開している開発履歴は GitHub プロフィールで確認できます。