fbc-guard

fbc-guard

Meta のクリック ID を保存するランディングページのコードを静的にチェックします。

ドキュメントと背景情報：adsandcode.com/en/open-source/fbc-guard

fbc-guard は、fbclid URL パラメーターを _fbc Cookie（自分で記述する場合は _fbp Cookie も）に変換する HTML と JavaScript を読み込み、コードの変更やクリック ID の喪失につながる既知のパターンを検出します。

MCP サーバーとして動作するため、AI アシスタントはページの作成中やレビュー中にトラッキングコードをチェックできます。また、CI 用のコマンドラインツールとしても使用できます。

対処する問題

Meta 広告をクリックすると、ランディングページの URL に fbclid パラメーターが含まれます。ページまたは Meta Pixel は、この値を fb.<subdomainIndex>.<creationTime>.<fbclid> の形式でファーストパーティの _fbc Cookie に保存し、後続のイベントではその値を fbc パラメーターで Meta に送信します。

手書きのコードでは、次のような特定の問題が起こりがちです。

• 再訪問したユーザーが別の広告からアクセスしても古いクリック ID を保持するため、コンバージョンが以前の広告に関連付けられます。
• クリック ID を処理中に変更します。再度デコードしたり、大文字と小文字を変えたり、途中で切り詰めたりします。
• creationTime をミリ秒ではなく秒で記述したり、subdomainIndex をハードコードしたりします。

広告主からは、Events Manager で fbc パラメーター内の fbclid が変更されたという診断が表示されるとの報告があります。Meta のドキュメントには、原因は記載されていません。上記の最初の 2 つの問題は、URL からイベントまでの間にクリック ID を変更または置き換えるため、この診断が表示されたときは原因から除外しておく価値があります。

fbc-guard は、コードの公開前にソースコード内のこうしたパターンを検出します。コードは実行せず、Meta に何も送信しません。

インストール

MCP サーバー

MCP クライアントの設定に次の内容を追加します（Claude Desktop、Cursor、および mcpServers ブロックを読み込むその他のクライアント）。

{
  "mcpServers": {
    "fbc-guard": {
      "command": "npx",
      "args": ["-y", "mcp-server-fbc-guard"]
    }
  }
}

Claude Code：

claude mcp add fbc-guard -- npx -y mcp-server-fbc-guard

Node.js 18 以降が必要です。

コマンドライン

npx -y -p mcp-server-fbc-guard fbc-guard https://your-landing-page.example/
# or install it
npm install -g mcp-server-fbc-guard
fbc-guard ./dist/index.html ./dist/js/tracking.js

ライブラリとして使用

import { checkCode } from "mcp-server-fbc-guard";

const result = checkCode(htmlOrJs); // { status, failed, unknown, warnings, rules }

パッケージのエントリーポイントはルールモジュールのみです。インポートしても MCP サーバーは起動せず、ファイルの読み込みやネットワークへのアクセスも行いません。

MCP ツール

ツール	入力	内容
check_fbc_code	code：HTML または JavaScript。任意の kind：auto（デフォルト）、html、または js	渡されたソースに対してすべてのルールを実行します。ネットワークにはアクセスしません。
check_fbc_url	url：http または https の URL	ページと、ページが読み込む同一オリジンのすべての <script src> を取得し、その全体に対してすべてのルールを実行します。サーバーが FBC_GUARD_ALLOW_PRIVATE=1 で実行されている場合を除き、公開ホストのみが対象です（ネットワークの安全性を参照）。final_url、scanned_scripts、skipped_scripts も返します。

どちらも JSON を返します。

{
  "status": "fail",
  "failed": ["FBC-01"],
  "unknown": [],
  "warnings": ["FBC-06"],
  "rules": [
    {
      "id": "FBC-01",
      "title": "A new fbclid must overwrite an older _fbc cookie",
      "status": "fail",
      "evidence": "indexOf('_fbc=')<0",
      "protects": "If the cookie is only written when it is missing, ...",
      "basis": "official",
      "severity": "error",
      "reference": "https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc"
    }
  ]
}

各ルールの status は pass、fail、unknown、または warn です。warn は警告レベルのルール（FBC-06）からのみ返され、warnings に記載されます。全体のステータスや終了コードは変更しません。

全体の status は pass、fail、unknown、または not_applicable です。

• unknown は、ルールに失敗したものはないものの、少なくとも 1 つのルールで判定できなかったことを意味します。現在、これを返すのは FBC-01 のみです。URL の fbclid を保持している変数を特定できない場合に返されます。ルールの evidence に、解決できなかった内容が記載されます。
• not_applicable は、スキャン対象のどこにも _fbc という文字列がないため、ルールが評価されなかったことを意味します。コードがスキャンで検出できない場所にある可能性があります。

どちらも合格を意味するものではありません。

check_fbc_code で kind: "auto" を指定すると、入力が < で始まる場合は HTML として読み込み、インラインの <script> 本文を解析します。それ以外は JavaScript として読み込みます。

サーバーは起動時に独自のネガティブテストを実行し、いずれかのルールが検出対象のコードで失敗しなくなった場合は起動を拒否します。

コマンドライン

fbc-guard <url|file> [<url|file> ...]   check pages (http/https) or local files
fbc-guard --json <url|file> [...]       print JSON instead of text
fbc-guard --allow-private <url> [...]   also allow localhost and private-network URLs
fbc-guard --selftest                    run only the negative tests
fbc-guard --help | --version

各ターゲットは個別に判定されます。URLは、同一オリジンのスクリプトと一緒に取得されます。ローカルファイルはそのままスキャンされ、<script src> の参照先は追跡されないため、JavaScriptファイルもリストに含めてください。ローカルファイルは、拡張子が .js、.mjs、.cjs、.jsx、.ts、.mts、.cts または .tsx の場合はJavaScriptとして、.html、.htm、.xhtml、.shtml または .php の場合はHTMLとして、それ以外の場合は check_fbc_code と同様に先頭の文字に基づいて読み込まれます。

ターゲットを判定する前に、CLIはサーバーと同じ否定テストを実行します。テストに失敗すると、失敗したテストを表示し、判定結果を出さずにコード2で終了します。

終了コード	意味
0	どのターゲットでもエラーレベルのルールに違反していません。警告のみのターゲット（FBC-06）、unknown（ルールで判定できなかった場合）、not_applicable（_fbc コードがない場合）も含まれます。出力ではこの3つすべてが示されます
1	少なくとも1つのターゲットで、少なくとも1つのルールに違反しています
2	否定テストが失敗した、引数が無効だった（--selftest とほかの引数を併用した場合を含む）、またはターゲットを読み込めなかったか取得できなかった場合

CIでの実行：

npx -y -p mcp-server-fbc-guard fbc-guard ./public/index.html ./public/js/tracking.js

ルール

各ルールでは、Metaのリファレンスページ ClickID and the fbp and fbc Parameters を参照します（以前のURL /docs/marketing-api/conversions-api/parameters/fbp-and-fbc/ はこのページにリダイレクトされます）。根拠列には、そのページがルールをどの程度直接裏付けているかを示します。

• 公式：ページに要件が記載されています。
• 導出：ページに一般的な要件が記載されており、それをこの特定のコードパターンに適用したものが本ルールです。
• 実務上の観察：Metaの記載にはありません。実際の実装で見られた誤りです。

ID	検出内容	重大度	根拠
FBC-01	_fbc Cookieは存在しない場合にのみ書き込まれる、またはURL内のクリックIDがリテラル以外の値と比較されることがない	error	公式
FBC-02	decodeURIComponent(fbclid)	error	導出
FBC-03	fbclid.toLowerCase() / fbclid.toUpperCase()	error	公式
FBC-04	fbclid.slice(、.substring(、.substr(	error	導出
FBC-05	_fbc=fb. 値を構築する文で、秒単位のタイムスタンプが使われている	error	公式
FBC-06	_fbc Cookie値の subdomainIndex にリテラルの数字が使われている	warning	実務上の観察
FBP-01	_fbp=fb. に対するFBC-05と同じルール	error	公式

エラーレベルのルールに該当すると、チェックは失敗し（終了コード1）、警告レベルのルールに該当すると、ステータス warn として報告されますが、結果や終了コードは変わりません。

ルールでは、JavaScriptパーサーではなく、小規模なスキャナーを使ってソースを読み取ります。JavaScriptコメント内の内容は判定対象にならず、HTMLコメント内のマークアップも同様です。

• FBC-02、FBC-03、FBC-04はJavaScript（インラインの <script> 本文と取得したスクリプトファイル）のみを読み取り、文字列の内容も無視します。そのため、'do not call decodeURIComponent(fbclid)' のようなメッセージは検出されません。
• FBC-06とFBC-01の「存在しない場合のみ書き込む」チェックでは、文字列リテラル内のテキストを探すため、コメントを取り除き、文字列の内容を残した文書全体を読み取ります。
• FBC-01、FBC-05、FBP-01では、スキャナーを使って文の開始位置と終了位置も特定します。

FBC-01: 新しい fbclid は古い _fbc Cookie を上書きする必要があります

「Cookie がなければ設定する」というコードでは、最初のクリック ID がいつまでも残ります。別の広告経由で再訪した訪問者にも古い ID が保持され、コンバージョンが以前の広告に計上されます。Meta のページでは、Cookie を設定すべきケースとして、URL の fbclid が「_fbc Cookie の値に対応する値と等しくない」場合を挙げています。

このルールの判定方法：

1. URL からクリック ID を保持する変数を探します。具体的には、.get('fbclid')、['fbclid']、.fbclid から代入された変数、fbclid= を含むテキストに対する match、split、exec などの呼び出しから代入された変数、またはそれらのいずれかからコピーされた変数（var f = fbclid || ''）です。変数名またはパラメーター名が文字どおり fbclid の場合も対象です。
2. これらの変数のいずれかと、リテラルではない値との間にある !==、!=、===、== の比較を探します。id !== f と if (stored === clickId) return; は対象ですが、f !== '' と f != null は対象外です。
3. 比較があればルールに合格します。「Cookie がない、または値が異なる場合に設定する」ケースも含まれます。たとえば、indexOf('_fbc=') < 0 || id !== f のような記述です。
4. 比較がなく、indexOf('_fbc=') < 0 という「Cookie がない場合のみ書き込む」パターンが見つかった場合、またはクリック ID の変数が見つかった場合、ルールに不合格となります。
5. クリック ID の変数もこのパターンも見つからない場合、説明を添えてステータスを unknown とします。終了コードは 0 です。

FBC-02: fbclid を二重に URL デコードしないでください

URLSearchParams.get() はすでにデコード済みの値を返します。再度デコードしても値が変わらない場合もありますが、変わる場合もあります。また、単独の % に対して decodeURIComponent を呼び出すと例外が発生し、スクリプトの残りの処理が停止します。Meta のページには、クリック ID を「使用する前に変更を加えないでください」と記載されています。デコードについての明記はありませんが、二重デコードを変更にあたるものとして扱うのがこのルールの解釈です。

FBC-03: fbclid の大文字・小文字を変更しないでください

Meta のページには「ClickID の値は大文字と小文字を区別します」とあり、避けるべき変更として小文字化と大文字化が挙げられています。

FBC-04: fbclid を切り詰めないでください

短縮されたクリック ID は変更されたクリック ID です。Meta のページには、クリック ID を「使用する前に変更を加えないでください」と記載されていますが、切り詰めについての明記はありません。

FBC-05: _fbc の creationTime はミリ秒で指定する必要があります

Meta のページでは、creationTime を「UNIX エポックからの経過時間（ミリ秒）」と定義しています。Date.now() はすでにミリ秒を返すため、1000 で割ると秒単位で書き込まれます。

このルールは、_fbc=fb. という文字列またはテンプレートリテラルを含む各ステートメントを調べ、ミリ秒単位の時計を 1000 で割っている場合に不合格とします。

• 時計：Date.now()、new Date()、(new Date)、new Date().getTime()、(new Date).getTime()、new Date().valueOf()、+new Date、および変数に対する d.getTime()／d.valueOf()（引数から作られた new Date(...) は特定の時点を表し、時計ではないため対象外です）。
• 除数：スペースの有無を問わない /1000 または /1e3。Math.floor、Math.round、Math.trunc、parseInt、|0、~~ など、どのようなものに囲まれていても対象です。
• 連結またはテンプレートリテラルに直接記述されている場合、または先に変数へ格納してから連結される場合が対象です。変数の場合は、ステートメントより前にある最後の代入が判定対象です。

Date.now() のみの場合、別のステートメントにある /1000（ファイル内の別の場所にあるカウントダウンタイマーなど）、コメントアウトされた行、または (end - Date.now()) / 1000 のような時刻の差分には適用されません。後者はタイムスタンプではなく、max-age のような時間間隔を表すためです。

FBC-06（警告）：_fbc Cookie のハードコードされた subdomainIndex を確認する

Meta のページには、「subdomainIndex は Cookie が定義されるドメインを示す」とあり、 com は 0、example.com は 1、www.example.com は 2 とされています。リテラルの数字が 正しいのは、Cookie が常にその階層のドメインに設定される場合に限られます。また、Cookie を 保存せずにサーバーで値を生成する場合は 1 を使うよう記載されており、独自の例でも fb.1. が使われています。不一致の値が拒否されるとは記載されていません。そのため、リテラルの 値自体が間違いというわけではなく、このルールは失敗ではなく警告です。Cookie が実際に設定される ドメインと照らし合わせて確認する価値のある値を指摘しています。

FBP-01：_fbp の creationTime はミリ秒単位である必要があります

同じページの fbp セクションにも、同じ定義が記載されています。 「creationTime はエポックからの UNIX 時刻をミリ秒で表したものです」。これは、自分のコードで _fbp を書き込む場合にのみ関係します。通常は Meta Pixel が書き込みます。 検出方法は FBC-05 と同じで、_fbp=fb. を含むステートメントを対象とします。

すべてのルールに合格するコード

これは、セルフテストですべてのルールに照らして実行される正確なスニペットです。また、 これと異なる README の公開を、公開チェックで拒否します。

<script>
(function () {
  // URLSearchParams.get() already returns the decoded value. Use it as is.
  var fbclid = new URLSearchParams(location.search).get('fbclid');
  if (!fbclid) return;

  // The click ID in an existing _fbc cookie is its fourth field:
  // fb.<subdomainIndex>.<creationTime>.<fbclid>
  var current = (document.cookie.match(/(?:^|;\s*)_fbc=([^;]*)/) || [])[1] || '';
  var storedId = current ? current.split('.')[3] : '';

  // A different click replaces the stored one. The same click keeps it.
  if (storedId !== fbclid) {
    // Use the widest domain the browser accepts for a cookie, and derive
    // subdomainIndex from it: example.com is 1, www.example.com is 2.
    var host = location.hostname, parts = host.split('.');
    var domain = host, domainAttr = '';
    for (var i = parts.length - 2; i >= 0; i--) {
      var candidate = parts.slice(i).join('.');
      document.cookie = 'cookie_domain_probe=1;path=/;domain=' + candidate;
      if (document.cookie.indexOf('cookie_domain_probe=1') >= 0) {
        document.cookie = 'cookie_domain_probe=;path=/;domain=' + candidate + ';max-age=0';
        domain = candidate;
        domainAttr = ';domain=' + candidate;
        break;
      }
    }
    var subdomainIndex = domain.split('.').length - 1;

    // creationTime is Date.now(): milliseconds, not seconds. 90 days = 7776000 s.
    document.cookie = '_fbc=fb.' + subdomainIndex + '.' + Date.now() + '.' + fbclid +
      ';path=/' + domainAttr + ';max-age=7776000;SameSite=Lax';
  }
})();
</script>

この例に関する注記：

• Cookie のどの部分がクリック ID なのか。 この例では、ドットで区切られた 4 番目の セグメントを使用しています。一方、Meta の fbc ページでは、Cookie 値の最後のドット以降の部分が クリック ID であるとされています。この 2 つは、Meta の Parameter Builder library が Cookie を書き込んだ場合に異なります。ドキュメントに記載されている形式は fb.${subdomain_index}.${creation_time}.${fbclid}.${appendix} であるため、最後のドット以降の 部分はクリック ID ではなく appendix です。どちらの形式でも、4 番目のセグメントがクリック ID です。
• ブラウザーは com や com.tw などのパブリックサフィックスに Cookie を設定しないため、 ループは登録可能なドメイン（example.com、example.com.tw）に落ち着きます。
• サーバーで設定する Cookie を優先してください。 Meta の fbc ページでは、fbclid を含む リクエストが届いた際に、応答ヘッダーで _fbc を 90 日間有効な HTTP Cookie として設定することを 推奨しています。この例では document.cookie を使って書き込みます。静的ページから実行できるのは この方法であり、ブラウザーには制限があります。WebKit の Intelligent Tracking Prevention 2.2 には、クロスサイトトラッカーとして分類されたドメインが訪問者を誘導し、ランディング URL に クエリ文字列またはフラグメントがある場合、「document.cookie を通じて設定された永続 Cookie の 保存期間は 1 日に制限される」と記載されています。広告のクリックには必ずクエリ文字列に fbclid が含まれるため、ITP が参照元サイトをそのように分類している場合、このスクリプトで 設定される 90 日間は Safari では 1 日になります。サーバーを管理している場合は、そこで Cookie を 設定してください。
• Meta Pixel がインストールされている場合は、_fbc と _fbp を Meta Pixel 自身が管理します。 このようなコードは、たとえば Conversions API 経由で転送するために、Pixel を使わずにクリック ID を 取得するページ向けです。

元のルールセットからの変更点

このパッケージは、同じルール ID を使う社内スクリプトとして始まりました。公開リリースにあたり、実際のミスを見逃したり、正しいコードを誤検知したりしていたいくつかのルールを見直しました。

• FBC-05 と FBP-01 は以前、_fbc=fb. / _fbp=fb. と同じ文字列またはテンプレートリテラル内にある場合に限り、Date.now()/1000 を検出していました。よくある連結形式である '_fbc=fb.' + i + '.' + Math.floor(Date.now()/1000) は検出されませんでした。現在は上記の説明のとおり、文全体と、変数に格納された秒数をチェックし、コメントは無視します。
• FBC-01 は以前、fbclid という名前の変数の隣にある !== または != だけを受け付けていたため、if (id !== f) や if (stored === fbclid) return; のような正しいコードが失敗していました。現在は、クリック ID を保持している変数を特定し、4 種類の比較演算子をすべて受け付けます。また、変数を特定できない場合は失敗ではなく unknown を報告します。
• FBC-06 は以前、失敗として扱われていました。Meta 自身が例やサーバー生成値に fb.1. を使用しているため、現在は終了コードを変更しない警告になっています。
• FBC-02、FBC-03、FBC-04、FBC-06 は以前、コメントを含め、テキスト内のどこにあっても一致していました。そのため、ミスを避けるよう注意を促すコメントでもルールが発動していました。現在はコメントをスキップし、FBC-02 から FBC-04 では文字列の内容もスキップします。

元のテスト用フィクスチャでは、FBC-06 が以前の fail ではなく warn を報告する点を除き、すべてのルールが以前と同じ結果になります。

制限事項

これはソーステキストの静的解析であり、コードの実行ではありません。合格は「このツールが認識する形式では、既知のミスが見つからなかった」という意味であり、「このコードは正しい」という意味ではありません。

• 偽陰性。 圧縮、バンドル、難読化されたコードや、実行時に組み立てられるコードでは、ミスが隠れることがあります。FBC-02、FBC-03、FBC-04 は fbclid という名前の変数だけを調べるため、f.toLowerCase() は検出されません。FBC-05 と FBP-01 では、_fbc=fb. / _fbp=fb. のテキストが 1 つの文字列またはテンプレートリテラル内にある必要があります。'_fbc=' + value や join('.') で値を組み立てている場合はチェックされず、ヘルパー関数から返される秒数も追跡されません。変数の追跡はテキストベースです。文の前にある最後の代入を採用し、スコープや分岐は追跡しません。
• 偽陽性。 FBC-01 は、クリック ID とリテラル以外の値との比較をすべて受け付けるため、もう一方が実際に保存済みの Cookie 値かどうかを判別できません。そのため、偽陰性よりも誤って合格する可能性が高くなります。分岐内で再代入される秒数の変数は、誤った代入に基づいて判定されることがあります。
• HTML または JavaScript。 インラインイベントハンドラー属性（onclick="..."）は、FBC-01 から FBC-05 または FBP-01 では解析されません。< で始まる JavaScript ファイルは、kind: "js" を渡すか .js 拡張子を付けない限り、HTML として読み込まれます。
• 該当なしは合格ではありません。 スキャン対象に _fbc が現れなければ、何も判定されません。タグマネージャーコンテナ、クロスオリジンスクリプト、サーバーサイドの統合にあるトラッキングコードは、このスキャンでは検出できません。
• URL スキャンの制限。 取得されるのは同一オリジンのスクリプトのみで、最大 20 個、展開後のサイズは各 2 MB まで、リクエストごとのタイムアウトは 30 秒、リダイレクトは最大 5 回で、モバイル Safari のユーザーエージェントが使用されます。クロスオリジンスクリプトは取得されず、skipped_scripts に一覧表示されます。別のオリジンへリダイレクトする同一オリジンのスクリプトは、その先を追跡しません。JavaScript の実行後にのみ配信されるマークアップは検出されません。プロキシ環境変数は使用されません。
• 実行時チェックはありません。 静的解析では、実際にどの値が送信されるかはわかりません。確認するには、古い _fbc Cookie を設定した状態で、現実的な fbclid を URL に含めてブラウザーでページを読み込み、コードが送信する値と URL の値を文字単位で比較してください。テスト中は Meta へのリクエストをブロックし、テスト用クリック ID が実際のイベントとして報告されないようにしてください。

ネットワークの安全性

check_fbc_url と CLI の URL モードは、指定された URL を取得します。URL を選ぶのは AI エージェントかもしれません。これをクラウドメタデータエンドポイント、ローカルホストのサービス、またはプライベートネットワークへ侵入する手段にしないため、取得先はデフォルトでパブリックホストに制限されています。

• http と https の URL のみ受け付けます。
• ホストがループバック、プライベート（10/8、172.16/12、192.168/16、fc00::/7）、リンクローカル（169.254/16、fe80::/10）、キャリアグレード NAT（100.64/10）、0.0.0.0/8、マルチキャスト、予約済み、または未指定のアドレスである場合、あるいはそれらに解決される場合、接続は拒否されます。IPv6 内に記述されたアドレス（::ffff:127.0.0.1、NAT64、6to4）も対象です。名前の解決先に拒否対象のアドレスがひとつでも含まれる場合、その名前は拒否されます。
• リダイレクトは最大 5 回まで手動でたどり、すべての遷移先を同じ方法で検査します。同一オリジンのスクリプトもすべて同様に検査します。
• 拒否されたアドレス、DNS の失敗、拒否またはリセットされた接続、TLS エラー、タイムアウトは、すべて同じエラーテキストを返します。そのため、このツールのメッセージから、開いているポートと閉じているポートを判別することはできません。

自分のマシンまたはイントラネット上のページを検査するには、オプトインしてください。コマンドラインでは --allow-private を指定するか、MCP サーバーの環境変数に FBC_GUARD_ALLOW_PRIVATE=1 を設定します。

{
  "mcpServers": {
    "fbc-guard": {
      "command": "npx",
      "args": ["-y", "mcp-server-fbc-guard"],
      "env": { "FBC_GUARD_ALLOW_PRIVATE": "1" }
    }
  }
}

オプトインすると、アドレスは拒否されません。

残存するリスク：

• DNS リバインディング。 ホスト名が検査時にはパブリックアドレスに解決され、接続時にはプライベートアドレスに解決される可能性があります。アドレス検査は接続自体の DNS ルックアップ内で、ソケットが使用しようとしているアドレスに対して実行されます。また、リダイレクト先とスクリプトはすべて、再度解決して検査されるため、応答が変化しても検査と接続の間をすり抜けることはできません。これは、Node.js がホスト名の接続ごとにそのルックアップを呼び出すことを前提としており、実際に呼び出します。IP リテラルは接続前に検査されます。これは緩和策であり、保証ではありません。
• タイミング。 拒否対象のアドレスはすぐに失敗しますが、到達できないパブリックホストでは 30 秒のタイムアウトまでかかる場合があります。そのため、メッセージでは分からなくても、タイミングから情報が分かる可能性があります。
• 内部へアクセスするパブリックホスト。 オープンプロキシなど、リクエスト元に代わって内部リソースを取得するパブリック URL は、アドレス検査では検出できません。

開発

npm ci
npm run build
npm run selftest                     # negative tests: every rule must fail on its own fixture
node scripts/smoke.mjs               # talks to the built server over stdio, including a local HTTP check
node scripts/check-publish-ready.mjs # package and MCP Registry metadata checks

ライセンス

MIT。詳細は LICENSE をご覧ください。

メンテナー

Ads & Code が開発・メンテナンスしています。