ai tag debugger

英語 | Türkçe

AI Tag Debugger

ウェブサイトの分析タグと広告トラッキングをQAテストする、オープンソースのAIエージェントです。

AIモデルが実際のブラウザーを操作し、実際の訪問者のように主要なユーザージャーニー（商品 → カート → チェックアウト、リードフォーム）をたどります。閲覧中、ai-tag-debugger はすべてのトラッキングヒット（GA4、Google Ads、Meta Pixel、TikTok、その他約12のプラットフォーム）と、すべてのdataLayerへのプッシュを記録します。その後、それらを計測プランとConsent Modeの設定と照らし合わせ、何が壊れていたのか、どう修正すればよいのかを、英語またはトルコ語でわかりやすくレポートします。

次の2つの方法で利用できます。

• ターミナルまたはCIから、Anthropic（Claude）、OpenAI、Google Gemini、またはOpenAI互換API（Kimi、GLM、DeepSeek、OpenRouter、ローカルのOllamaなど）用の独自のAPIキーを使用します。
• AIチャットアプリから（Claude、ChatGPT、Gemini、およびMCPに対応したその他のアプリ）。アプリ自体のモデルが監査を実行するため、別途APIキーを用意する必要はありません。

Analitik İşler が開発しました。MITライセンスです。

▶ checkout (mobile)
  Accept cookies
  Open the first product
  Add to cart
  Open the cart
  Go to checkout
  …
  Place the order
  ✓ All scripted steps completed. · 20 tracking hits captured

2 broken · 1 risk · 1 warning · 4 ok
Report: reports/demo/localhost/runs/2026-10-16_0800/report.html

理由

トラッキングの不具合は気づかれないまま発生します。リニューアルでボタンの名前が変わったり、新しいテンプレートでフィールドが抜けていたり、同意バナーの更新によってピクセルが早すぎるタイミングで発火したりします。誰にもアラートは届きません。不正確なコンバージョンデータをもとに広告プラットフォームが最適化を行った後、数週間たってからようやく気づきます。

手作業でタグをQAすれば不具合を見つけられますが、手間がかかるため、リリースのたびに実施されることはほとんどありません。ai-tag-debugger を使えば、CIで実行できるコマンドになります。

チェック項目

チェック項目	指摘例
イベントの不足	チェックアウトのユーザージャーニーで purchase が一度も発火していない
パラメーターの不足	モバイルで purchase が value と currency なしで送信されている
無効な購入額	purchase が value 0、負の数、または "free" のようなテキストとともに送信されている
無効な購入通貨	purchase が USD や TRY のような3文字の ISO コードではなく、usd や TL の通貨コードとともに送信されている
購入アイテムが空	purchase が空の items リストとともに送信されている
購入データの不一致	同じ注文 ID に対して、GA4 は value 120 を送信し、Meta は 115 を送信している
重複	1回のクリックで add_to_cart が2回送信されている
同意	訪問者が Cookie を承認する前に Meta PageView が発火している、Consent Mode のデフォルト設定がない、または設定が遅すぎる、Consent Mode v2 のシグナル（ad_user_data、ad_personalization）がない、同意前にトラッキング Cookie が設定されている、decline_cookies のユーザージャーニーでバナーを拒否した後もタグや Cookie が有効なままになっている、拒否ボタンを押しても何も起きない
個人データ	メールアドレスが平文で広告プラットフォームに送信されている
計画外のイベント	計測計画にないイベントが発火している
計画の網羅状況	計画した各イベントを、実装済み、欠落、パラメーター不足、値の誤り、未チェックに分類します（計画とサイトの比較を参照）
キャンペーンパラメーター	ランディングページのアドレスにある utm_campaign または gclid がリダイレクトで失われている、またはヒットが報告するページアドレスに含まれていないため、訪問が直接トラフィックとして計上されてしまう
サーバーサイドトラッキング	2つの異なるイベントに同じイベント ID が使われている、または Meta のイベント ID が、サーバーコンテナが Conversions API イベントに変換する GA4 ヒットの event_id と一致していない

対象プラットフォーム：GA4（サーバーサイド GTM エンドポイントと、サイト独自ドメイン上の Google tag gateway パスを含む。サーバーコンテナへのヒットにはサーバーサイドの印が付き、Stape と Elevar のリクエストも認識されます）、Google Ads のコンバージョン、Meta Pixel、TikTok Pixel、基本的な X Pixel イベント、LinkedIn Insight Tag、Microsoft Advertising UET、Criteo OneTag、Pinterest、Snapchat、Klaviyo のイベントです。Adobe Analytics、Matomo、Piwik PRO のイベント（ページビュー、リンク、目標、サイト内検索、eコマース注文）も読み取ります。また、Microsoft Clarity と Hotjar のタグ読み込みでは、プロジェクトまたはサイト ID を特定します。

GA4 ヒットの送信先が別ホスト上のサーバーコンテナである場合、または GA4 のローダーが別ホストから配信されている場合、レポートに情報として指摘が追加されます。転送先の広告プラットフォームに送られるイベントはブラウザーを通らないため、ここでは確認できません。

gtm_container エクスポートを使うと、問題のある各イベントについて、それを送信する GTM タグと発火するトリガーが示されます。または、送信するタグがないことが示されます。各タグについては、そのトリガーがユーザージャーニー中に発火したかどうかが示され、発火しなかった場合はその理由も示されます。理由には、タグが一時停止中である、トリガーのイベントを含む dataLayer push がない、トリガー条件を満たさなかった（GTM の Data Layer Variables と同じ方法で累積 dataLayer から読み取った push の値も表示）、例外トリガーにブロックされた、またはイベント発火時に必要な同意が拒否されていた、などがあります。すべてのトリガーが発火しているにもかかわらずヒットが誤っている場合は、その旨を示し、タグ自体の設定を指摘します。クリック、フォーム、表示、タイマーのトリガーは GTM がページ内で評価するため、gtm.click のようなイベントが dataLayer に到達していない限り、評価不可として報告されます。これらはすべて、AI モデルを使わず、取得した dataLayer に基づいて評価されます。

チェックするプラットフォームを選択する

デフォルトでは、監査で GA4、Google Ads、Meta、TikTok がチェックされ、サイトで使用されていることが判明したその他のプラットフォームもチェックされます。そのプラットフォームは最初のリクエストからチェックされ、設定は不要です。プラットフォームを選択すると、この検出は無効になります。--platforms ga4,meta,x、設定ファイルの "providers"、または MCP の start_audit および run_audit ツールの providers で、固定リストを指定してください。選択できるのは ga4、google_ads、meta、tiktok、x、linkedin、microsoft_ads、pinterest、snapchat、criteo、klaviyo、adobe、matomo、piwik_pro、clarity、hotjar、doubleclick、adsense です。イベントは GA4、Google Ads、Meta、TikTok、X、LinkedIn、Microsoft Ads、Pinterest、Snapchat、Criteo、Klaviyo、Adobe Analytics、Matomo、Piwik PRO について解析されます。Clarity と Hotjar ではタグの読み込みが表示され、その他のプラットフォームではネットワークリクエストが表示されます。--providers は、あと 1 回のマイナーバージョンに限り --platforms の旧名称として引き続き使用でき、注記が表示されます。

選択しなかったプラットフォームへのリクエストもローカルで応答されるため、それらのアカウントにリクエストが届くことはありません。リクエストはタイムライン、CSV、チェックから除外され、件数のみが集計されます。レポートには件数とともに表示されます（例：「Microsoft Clarity、DoubleClick への対象外リクエスト 61 件をスキップしました」）。各ステップにもスキップした件数が表示されます。--platforms を指定しない場合、測定プランに記載された、またはサイトがリクエストを送信するプラットフォームは、いずれもデフォルトのリストに追加されます。除外したプラットフォームの予定イベントは、不足として報告されず、1 件の情報検出項目にまとめて記載されます。タグマネージャーと同意プラットフォームへのリクエストは常に表示されます。

同意シナリオ

各監査では、同意の選択肢ごとに、毎回新しいブラウザーで開始ページも開きます。選択肢は「すべて許可」「すべて拒否」「分析のみ」です。OneTrust、Cookiebot、Usercentrics、Didomi などの同意プラットフォームに独自の API がある場合はその API を通じて選択し、ない場合はバナーのボタンをクリックします。その後、各選択肢の後に各タグが送信したヒット数がレポートに表示されます。「分析のみ」は OneTrust と Cookiebot で利用でき、その他のプラットフォームでは該当する列に「ここではサポートされていません」と表示されます。「すべて拒否」の後に送信するタグには、Cookie を使用しない Consent Mode の ping を除き、フラグが付けられます。「分析のみ」の後に送信する広告タグにも、広告ストレージが拒否された状態で送信された場合を除き、フラグが付けられます。表は Journeys タブの上部と、report.md の検出項目の上に表示されます。ツールが操作できるバナーがページに表示されない場合と、保存済みのサイトを再生する場合は、この処理はスキップされます。AI モデルは呼び出されませんが、開始ページにはさらに 3 回アクセスします。無効にするには、設定ファイルで "consent_scenarios": false を設定してください。

仕組み

1. 閲覧： AI モデルは平易な言葉で目標（「任意の商品をカートに追加し、テスト決済でチェックアウトを完了する」）と、ページのテキスト表示を受け取ります。Playwright を使い、browser_action（goto、click、fill、select、scroll、wait）と finish の2つのツールを通じて、一度に1ステップずつ操作します。
2. 記録： トラッキングエンドポイントへのすべてのリクエストを解析して正規化されたヒットに変換し、その原因となったステップをタグ付けします。すべての dataLayer の push は、gtag('consent', ...) コマンドも含め、init スクリプトを通じて記録されます。デフォルトでは、ツールが解析できるすべてのプラットフォーム（GA4、Google Ads、Meta、TikTok、X、LinkedIn、Microsoft Ads、Pinterest、Snapchat、Criteo、Klaviyo、Adobe Analytics、Matomo、Piwik PRO）の収集リクエストに加え、Google のコンバージョン、リマーケティング、同意の ping にローカルで応答するため、テストトラフィックが実際のアカウントに届くことはありません。タグの読み込みや、ホスト名からのみツールが認識するベンダー（Clarity や Hotjar など）へのリクエストは引き続き送信されます。タイムラインのネットワーク部分には、各呼び出しと、それにローカルで応答したかどうかが表示されます。
3. 確認： 決定論的なルールで、ヒットと計測プランを比較します。この処理では API 呼び出しを行わないため、結果は再現可能です。
4. 説明： モデルは検出結果、ステップごとのヒット、そして（任意で）GTM コンテナのエクスポートを読み取ります。各問題について、関連するタグとトリガーを示しながら、考えられる原因と修正方法を記述します。

AI プロバイダー

ご自身の API キーをご用意ください。ai-tag-debugger は、各プロバイダーの公式 SDK を使用します。

プロバイダー	API キーの変数	デフォルトモデル
Anthropic (Claude)	ANTHROPIC_API_KEY	claude-opus-5-5
OpenAI	OPENAI_API_KEY	gpt-5.5
Google Gemini	GEMINI_API_KEY	gemini-pro-latest
Cloudflare Workers AI	CLOUDFLARE_API_TOKEN と CLOUDFLARE_ACCOUNT_ID	@cf/meta/llama-3.3-70b-instruct-fp8-fast

--provider を指定しない場合は、次の順に最初に見つかった設定が使用されます：OPENAI_COMPATIBLE_BASE_URL、Vercel AI Gateway（AI_GATEWAY_API_KEY）、Cloudflare Workers AI、Anthropic、OpenAI、Gemini。--provider anthropic|openai|gemini|vercel|cloudflare または設定の "provider" で明示的に選択し、別のモデルを使う場合は --model を指定してください。--model cheap を指定すると、CI での通常の実行に適した、各プロバイダーの小型で低価格なモデルが選ばれます：Vercel では claude-haiku-5-5、gpt-5.5-mini、gemini-flash-latest、または anthropic/claude-haiku-5.5 です。Cloudflare のモデルリストにはモデルが1つしかないため、cheap とデフォルトは同じです。ナビゲーションでは実行コストを抑えるために低い推論負荷が指定され、説明では高い負荷と構造化 JSON 出力が指定されます。

OpenAI 互換 API：Kimi、GLM、DeepSeek、OpenRouter、Ollama など

多くのプロバイダーが、OpenAI と同様に動作する API を提供しています。接続先アドレスとモデル ID を指定して、ai-tag-debugger の接続先に設定してください：

export OPENAI_COMPATIBLE_API_KEY=...        # leave unset for a local Ollama
ai-tag-debugger run --site https://yourshop.com --journey add_to_cart \
  --provider openai-compatible --base-url <API address> --model <model id>

プロバイダー	--base-url
Moonshot (Kimi)	https://api.moonshot.ai/v1
Z.ai (GLM)	https://api.z.ai/api/paas/v4
DeepSeek	https://api.deepseek.com
Mistral	https://api.mistral.ai/v1
Groq	https://api.groq.com/openai/v1
OpenRouter（数百種類のモデル）	https://openrouter.ai/api/v1
お使いのコンピューター上の Ollama	http://localhost:11434/v1

プロバイダーのドキュメントに記載されているモデル ID を使用してください。フラグの代わりに OPENAI_COMPATIBLE_BASE_URL と OPENAI_COMPATIBLE_MODEL を設定することもできます。また、設定で "provider"、"base_url"、"model" を指定することもできます。API が厳密な JSON スキーマを返せない場合、説明はプレーン JSON モードに切り替わります。

Vercel AI Gateway

1つのキーで多数のモデルを利用できます。Vercel ダッシュボードから AI_GATEWAY_API_KEY を設定し、<provider>/<model> 形式でモデルを選択してください：

export AI_GATEWAY_API_KEY=...
aitd run --site https://yourshop.com --journey purchase --model google/gemini-3.6-flash

--model を指定しない場合は anthropic/claude-opus-5.5 が使用されます。使用状況と費用は Vercel の AI Gateway ダッシュボードに表示され、料金は Vercel から請求されます。実行時に使われる AI を確認するには、aitd を実行してください。最後の行に、たとえば AI: vercel (anthropic/claude-opus-5.5) · also set: anthropic (pick with --provider) と表示されます。

Cloudflare AI Gateway

すべての AI 呼び出しのログ、コスト、レート制限を確認するには、Cloudflare AI Gateway 経由で送信します。プロバイダーキーはそのままです：

export AI_GATEWAY_URL=https://gateway.ai.cloudflare.com/v1/<account id>/default
export AI_GATEWAY_TOKEN=...   # only if the gateway has authentication on

これは anthropic、openai、gemini で動作します。各実行でライブサイトを確認できるよう、ゲートウェイのキャッシュはオフにしてください。Cloudflare 上でモデルを実行するには、Cloudflare Workers AI をご覧ください。

モデル選択について。 AI はツールを呼び出して、一度に 1 ステップずつ、5〜30 ステップでサイトを閲覧します。モデルによって、この処理の信頼性には大きな差があります。小型モデルやローカルモデルは、誤った項目をクリックしたり、ループしたり、途中で停止したりすることがあります。チェックは、モデルの動作にかかわらず取得されたヒットに基づいているため正確ですが、完了しなかったユーザージャーニーでは、その後のイベントを確認できません。モデルの動作が不安定な場合は、より大きなモデル、目標が短い既成のユーザージャーニー、または --max-steps をお試しください。Anthropic、OpenAI、Gemini のデフォルトはテスト済みです。

Cloudflare Workers AI

Cloudflare のネットワーク上にあるオープンモデルを、Cloudflare に使用量に応じて課金される形で利用できます。Workers AI の権限を持つ API トークンを作成し、Cloudflare ダッシュボードでアカウント ID を確認してください：

export CLOUDFLARE_API_TOKEN=...
export CLOUDFLARE_ACCOUNT_ID=...
aitd run --site https://yourshop.com --journey purchase

--model を指定しない場合は、@cf/meta/llama-3.3-70b-instruct-fp8-fast が使用されます。両方の変数が設定されている場合、Cloudflare が Anthropic、OpenAI、Gemini より優先されます。そのいずれかを使うには、--provider を指定してください。

ネイティブプロバイダーを追加するには、src/providers.js に 2 つの関数を実装します。ツール呼び出しを行う会話処理と、構造化 JSON 呼び出しです。

クイックスタート

Node 20 以降が必要です。

npm install -g @analitikisler/ai-tag-debugger
npx -y [email protected] install chromium   # the browser version this release uses
export ANTHROPIC_API_KEY=...                # or OPENAI_API_KEY, or GEMINI_API_KEY

ai-tag-debugger run --site https://staging.yourshop.com --journey add_to_cart --headed

グローバルインストールでは、短縮エイリアスの aitd も追加されます。aitd run --site … --journey add_to_cart は同じ処理を行います。

または、インストールせずに実行します：npx -y @analitikisler/ai-tag-debugger run --site … --journey add_to_cart。

aitd --help を実行するとコマンドを確認できます。各コマンドのオプションは、aitd run --help（または plan、replay、mcp）で確認できます。正常に動作しない場合は、aitd doctor で Node、Chromium、AI キー、データフォルダーをチェックし、修正方法を確認できます。

デモショップを試す（ソースから）

このリポジトリには、意図的に 3 つのトラッキングバグを含めたデモショップがあります：

git clone https://github.com/analitikisler/ai-tag-debugger.git
cd ai-tag-debugger
npm install
npx playwright install chromium   # run again after upgrading, so the browser matches Playwright
npm run demo:serve                # in one terminal: http://localhost:4321
node src/cli.js run --config examples/demo.config.json --data-dir reports/demo
open reports/demo/localhost/runs/*/report.html

API キーがまだありませんか？AI モデルを使わずに、修正済みの手順を再生できます：

node src/cli.js run --config examples/demo.config.json --scripted --no-ai --data-dir reports/demo

そのまま質問する

最初にオプションを覚える必要はありません。引用符で囲んだ普通の文章を入力すると、aitd が対応するコマンドに変換し、そのコマンドを表示してから、実行前に Run this? (Y/n) と確認します：

aitd "check my google analytics tags"
# aitd run --platforms ga4
# Run this? (Y/n)

入力する内容	aitd が実行する内容
"Check my google analytics tags"	aitd run --platforms ga4
"What changed on my site since the last run"	aitd run（各実行で変更点はすでに報告されます）
"Compare my site against the plan"	aitd run --against latest
"What custom events does my site need"	aitd plan --topic custom-events
"Is my Meta pixel firing on checkout?"	aitd run --platforms meta --goal "reach checkout"
"Test signing up for the newsletter"	aitd run --goal "sign up for the newsletter"
"Does my purchase event send the right revenue?"	aitd run --journey purchase
"Make a tracking plan for example.com"	aitd plan --site https://example.com
"What ecommerce events should an online shop track?"	aitd plan --topic ecommerce
"Check TikTok and Google Ads on the contact form"	aitd run --platforms google_ads,tiktok --goal "submit the contact form"

質問を省略するには、-y を追加します：aitd -y "check my google analytics tags"。

文章に情報が足りない場合、aitd は推測せず、計画か実行か、どのサイトか、何をテストするかを短く質問します。文章によるレポートの絞り込みには、まだ対応していません（"Show me only the errors from the last report" と入力すると、その旨が表示されます）。AI キーがない場合は、一般的なフレーズを小さなキーワードマッチャーで処理します。キーがある場合は、AI がどのような言い回しも読み取りますが、存在するオプションしか選べないため、存在しないフラグを作り出すことはありません。

計画を立ててから監査する

実行では、サイトが送信する内容をプラン、つまり想定されるイベント、パラメーター、ユーザープロパティと照合します。手順は3つです。

# 1. Draft a plan. The AI explores the site and proposes what should be tracked.
aitd plan --site https://yoursite.com

# 2. Optional: edit it in a spreadsheet, then save the edited copy as a new plan.
aitd plan export latest --site https://yoursite.com     # writes plan.xlsx next to the plan
aitd plan import plan.xlsx --site https://yoursite.com  # saves a new plan; the old one is untouched

# 3. Audit the site against the plan.
aitd run --site https://yoursite.com --against latest

プランの作成にトラッキングコードは必要ありません。AI は各タイプのページを1つずつ確認します。対象はホームページ、カテゴリー、商品、カート、チェックアウトの最初のステップ、検索、登録フォームや問い合わせフォームです。支払いを行ったり、個人情報を使ってフォームを送信したりすることはありません。--provider、--model、--max-steps（デフォルトは25で、AI のステップ数の上限です）は、runと同様に機能します。出力には「見つかったページタイプ」と「このサイトに存在しないもの」が表示されるため、AI がどのページタイプにたどり着いたかを確認できます。2ページしかない小規模なサイトでも問題ありません。

1種類のイベントだけのプランを作成するには、--topicを追加します。指定できる値はcustom-events、ecommerce、forms、consentです。この場合、プランにはそのイベントだけが含まれ、その他の形式は変わりません。

aitd plan --site https://yoursite.com --topic ecommerce

プランは新しいフォルダーaitd/<domain>/plans/<id>/に、measurement-plan.jsonと、閲覧しやすいplan.htmlとして保存されます。各イベントには次の情報が記載されます。

• nameとplatform。サイズガイドや店舗検索など、サイト固有のイベントにはcustom: trueが付けられます。
• descriptionとtrigger：ページタイプと、イベントを発生させる要素に表示されるラベルです。
• parameters：各パラメーターの説明と値の例です。カスタムパラメーターにはその旨が付記されます。必須のパラメーターはrequired_paramsに記載されます。
• user_properties：customer_typeなどの候補と、それぞれの説明および値の例です。

サイトがすでに送信しているイベントには"seen": trueが付けられます。

プランは使用前に確認してください。例や候補は AI が確認したページに基づいているため、各イベントがビジネスに適しているか確認してください。追加フィールドはチェックでは無視されます。

スプレッドシートのインポートとエクスポート。 aitd plan export <plan> --site <url>を実行すると、プランと同じ場所にplan.xlsxが作成されます。eventsタブにはイベントパラメーターごとに1行（event, platform, parameter, required, example, trigger, description）、user_propertiesタブにはユーザープロパティごとに1行が記載されます。代わりにevents.csvとuser_properties.csvを出力するには、--format csvを追加します。CSVには追加パッケージは不要です。.xlsxでは小規模なライブラリfflateを使用します。このライブラリはオプションの依存関係としてツールとともにインストールされます。aitd plan import <file> --site <url>を実行すると、スプレッドシートを読み込み（Google Sheets の場合は、［ファイル］>［ダウンロード］>［Microsoft Excel（.xlsx）］を選択するか、各タブを CSV としてダウンロードしてください。Shop plan - events.csvは、同じ場所にあるShop plan - user_properties.csvと一緒にインポートされ、チェックボックスのセルは yes/no として扱われます）、新しいプランフォルダーに保存されます。インポートによって既存のプランが編集されることはありません。不明な列は警告とともに無視されます。エラーにはタブ名、行番号、修正方法が示されます。たとえば、events, row 7: "required" must be yes or no (found "maybe").のように表示されます。

measurement-plan.jsonの形式は次のとおりです。

{
  "consent_mode": true,
  "events": [
    { "platform": "ga4", "name": "add_to_cart", "required_params": ["currency", "value", "items"] },
    { "platform": "ga4", "name": "purchase", "journeys": ["checkout"], "required_params": ["transaction_id", "currency", "value", "items"] },
    { "platform": "meta", "name": "Purchase", "journeys": ["checkout"], "required_params": ["value", "currency"] }
  ]
}

platformはga4、google_ads、meta、tiktokのいずれかです。journeysを設定すると、イベントが想定される場所を限定できます（デフォルトではすべてのジャーニーが対象です）。アクションごとに複数回発生しても問題のないイベントには、allow_multiple: trueを設定します。

イベント名は柔軟に照合されます。そのため、Elevar のdl_add_to_cart、addToCart、Add To Cartはadd_to_cartとして、transactionとorder_completedはpurchaseとして扱われます。計画したイベントに"aliases": ["my_event"]を追加すると、独自の別名を設定できます。必須パラメーターも、一般的な別名で見つけることができます。たとえば、itemsにはproducts、valueにはrevenue、transaction_idにはorder_idが該当します。 プランとの照合。 run --against <plan> には、latest（または last）、first、プラン ID、またはプランファイルやそのフォルダーへのパスを指定できます。--site を指定しない場合、サイトはプランから取得されます。実行にジャーニーも指定すると、そのフローだけをたどり、そこで想定されるプランのイベントだけを確認します。プランの残りは未確認として報告され、欠落として扱われることはありません。--against 単独で使用すると、プランから最大 6 つのジャーニーが導出されます。計画されたイベントを発生するページごとにグループ化し、ページごとに 1 つのジャーニーを作成します（最大 6 つ。最小のグループは最後のジャーニーにまとめられます）。追加の AI 呼び出しはありません。選択されたジャーニーは、ブラウザーの起動前に表示されます。各レポートのヘッダーには、Checked against plan <id> と表示されます。

run にはテスト対象が必要です。--against、--journey、--goal、または設定ファイル内のジャーニーのいずれかを指定してください。指定がない場合、ブラウザーを開く前に停止し、Nothing to test. Add --against latest, --journey <id> or --goal "<text>". と表示されます。そのため、目的なく操作して API 利用量を消費することはありません。サイトにまだプランがない場合、run --against は No plan yet for example.com. Draft one with: aitd plan --site https://example.com と表示します。

aitd plan list --site <url> は、そのサイトのプラン ID を古い順に一覧表示します。

最初の実行からプランを学習する。 サイトに保存済みのプランがなく、--against も --out も指定せずに実行すると、そのサイトがすでに送信しているイベントを一覧表示し、それらをプランとして保存するかどうかを尋ねます。

No plan yet for this site. It already sends 3 events: ga4:page_view, ga4:purchase, meta:PageView
Save them as the site's plan? (Y/n)

「はい」と答えると、次回以降の実行で --against latest を使って照合できます。イベントが発生するたびに必ず含まれるパラメーターは、そのイベントの必須パラメーターになります。値はコピーされないため、訪問者が入力した内容がプランに含まれることはありません。スクリプトや CI ジョブでは、--yes を追加しない限り何も保存されません。--yes を指定した場合、実行時に、より詳細なプランを作成するための aitd plan --site コマンドが表示されます。

プランとサイトの比較

実行で --against を使用すると、レポートに プランとサイトの比較 セクションが表示されます。report.md では先頭に、report.html ではカバレッジセクションに表示されます。計画された各イベントは、次のいずれかに分類されます。

分類	意味
実装済み	プランにあり、発生し、すべての必須パラメーターが存在し、値に問題がない
欠落	実行でたどったジャーニーで計画されていたが、一度も発生しなかった
パラメーター不足	発生したが、必須パラメーターがない
値の誤り	値に問題がある状態で発生した。購入値、通貨、商品と同じチェックによる
未計画	発生したが、プランにない
未確認	計画されていたが、そのジャーニーまたはプラットフォームは今回の実行に含まれていない

カバレッジスコアは、実装済みイベント数を確認可能な計画済みイベント数（未確認以外）で割ったもので、全体とプラットフォームごとに表示されます。例：Coverage 7 of 11 (64%), 2 events not checked。同じ項目が plan-check.json にも記録され、計画済みの各イベントに分類が 1 つずつ付与されます。終了コードは変わりません。--fail-on は引き続き検出事項の重大度を判定します。--against を指定しない場合、レポートは従来どおりです。

プランがそのサイトの初版でない場合、ヘッダーでは、直前に保存されたバージョンとの比較結果が表示されます。例：Plan changed since 2026-10-01_0900: 1 added, 0 removed, 2 changed、または Plan unchanged since 2026-10-01_0900。続いて report.html と report.md のヘッダーに、変更内容が一覧表示されます。追加イベントには +、削除イベントには −、変更イベントには ~ が付され、その後に変更内容（必須パラメーター、パラメーター、またはジャーニー）が示されます。初版は比較対象がありません。capture.json には、同じ比較結果が planChanges に保持されます。

タグの一覧

すべてのレポートには タグの一覧 も含まれます。サイトがリクエストを送信した各ベンダーが表示され、そのリクエストがサイト独自のドメインに送られた場合はファーストパーティ、ベンダーに送られた場合はサードパーティ、両方の場合は両方として示されます。ベンダーが確認されたページ数と、関連付けられた Cookie も表示されます。どのベンダーにも属さない Cookie は、ファーストパーティまたはサードパーティとして別に一覧表示されます。記録されるのは Cookie 名のみで、値は記録されません。これは report.html の インベントリ セクションと、report.md の表に表示されます。

フォルダー構成とプラン ID

プランと実行結果は、ツールを実行したフォルダー内の aitd/ に保存されます。

aitd/
  example.com/                      the site's host, without www.
    plans/2026-10-16_0900/          measurement-plan.json, plan.html, plan.xlsx (after an export)
    runs/2026-10-16_0912/           report.html, report.md, timeline.csv, capture.json, steps.json,
                                    junit.xml, summary.json and plan-check.json (with --against)
    history.json                    a small summary of every saved run, for the trend (see below)

ID はローカル時刻の YYYY-MM-DD_HHMM です。その分がすでに使われている場合は、秒が追加されます（_HHMMSS）。上書きされることはありません。各ドラフト、インポート、実行結果には新しいフォルダーが作成されます。--data-dir <dir> を使うと、aitd/ フォルダーを別の場所に保存できます。replay と --save-site のフォルダーには影響しません。

各レポートには「前回の実行からの変更」セクションがあり、実行結果とサイトの runs/ にある前回の実行結果を比較します。たとえば「2 件のイベントを修正、1 件の新しい問題」のように、修正された内容（修正前の状態も含む）、新たに発生した問題、未解決の問題をそれぞれ一覧表示します。両方の実行で --against を使用している場合は、プランのカバレッジを比較します（Missing から Implemented に変わったイベントは修正として扱われます）。そうでない場合は、ヘルスに関する指摘事項を比較します。サイトでの初回実行では、まだ比較対象がないことが示されます。設定用のフラグはありません。この比較結果は capture.json の changes にも保存されます。

実行結果の推移

2 回目以降の保存された実行では、ツールはサイトの直近 30 回分の実行結果もまとめて確認します。件数の後に、CLI は判定行と最大 3 行の推移を表示します。

2 broken · 1 risk · 1 warning · 0 info · 4 ok
Verdict: Fail · purchase tracking is broken on mobile · score 25/100
Trend over 5 runs (2026-10-01 → 2026-10-07): improving. Now 0 broken · 1 risk · 2 warning; 3 runs ago 2 broken · 1 risk · 0 warning.
Open longest: Meta PageView before_consent in 4 places since 2026-10-01 (5 runs); GA4 add_to_cart duplicate in 4 places since 2026-10-03 (3 runs).
Journeys that do not finish every time: checkout (mobile) 80%.

同じ行が、実行結果を表すテキストのスパークライン（各実行を 1 文字で表示し、ジャーニーがすべて完了しなかった実行は ·）とともに、report.md と report.html の Trend セクションに表示されます。最後にジャーニーを完了した実行で問題がまだ確認されている場合、その問題は 未解決 として扱われます。ジャーニーが途中で停止した実行からは何も判断できないため、問題を修正したとも、再発させたともみなしません。変動する 問題（発生、解消、再発）は、タイミングや AI が選んだプロダクトに左右され、修正とは関係ないことが多いため、名前を挙げて表示します。傾向の方向は、直近の数回の完了した実行と、それ以前の実行を比較して判断します。

aitd history --site <url> は、推移を単独で表示します。各実行の件数とスコア（3·broken + 2·risk + warning。低いほど良好）、スパークライン、上記の各行が 1 行ずつ表示されます。--limit <n> を指定すると、新しい方から n 件の実行結果のみを読み込みます（デフォルトは 30）。--lang tr を指定すると各行がトルコ語になり、--json を指定すると推移の時系列、指摘事項ごとのタイムライン（初回確認、最終確認、未解決開始、修正された実行、変動の有無）、スクリプトのジャーニー完了率が出力されます。

概要は aitd/<domain>/history.json に保存されます。サイズは実行 1 回あたり約 2 KB で、保存された実行ごとに capture.json の書き込み後に更新されます。このファイルはキャッシュです。ファイルに含まれていない実行フォルダーは、その capture.json から読み込まれます。削除されたフォルダーは次回の更新時に除外され、ファイルを削除しても問題ありません。--out に送られた実行結果とリプレイは、履歴には含まれません。

テスト対象を選ぶ

始める際に設定ファイルは必要ありません。すぐに使えるジャーニーを選ぶ、自分の言葉でジャーニーを説明する、プランと照らし合わせる、または確認対象を必要なイベントに絞ることができます。

# Check the site against its latest saved plan.
aitd run --site https://staging.yourshop.com --against latest

# Ready-made journeys come with a goal and the GA4 and Meta events to expect.
ai-tag-debugger run --site https://staging.yourshop.com --journey purchase --journey sign_up

# Describe a journey in your own words. The events you name are expected on it.
ai-tag-debugger run --site https://yoursite.com --goal "Subscribe to the newsletter in the footer" --events newsletter_signup

# Only check some events.
ai-tag-debugger run --config ai-tag-debugger.config.json --events purchase,add_to_cart

すぐに使えるジャーニー	AI が行うこと	想定されるイベント
purchase（または checkout）	プロダクト → カート → チェックアウト → テスト用の支払いオプションで注文	GA4 view_item、add_to_cart、begin_checkout、purchase；Meta AddToCart、InitiateCheckout、Purchase
add_to_cart（または cart）	プロダクトを開き、カートに追加	GA4 view_item、add_to_cart；Meta AddToCart
sign_up（または signup、register）	テストデータでアカウントを作成	GA4 sign_up；Meta CompleteRegistration
lead（または contact、form）	問い合わせ、見積もり、デモのフォームに入力して送信	GA4 generate_lead；Meta Lead
search	サイトを検索して、検索結果を開く	search_term を含む GA4 search；Meta Search

--journey では、設定ファイル内の ID を指定してジャーニーを選ぶこともできます。設定ファイルがある場合、すぐに使えるジャーニーのイベントがプランに追加されます。

何をテストすればよいかわからない場合は、aitd plan --site https://yoursite.com で計測プランを作成し、--against latest でサイトをプランと照らし合わせて確認できます。

API 使用量を抑える

各ブラウジングステップでモデルを1回呼び出すため、使用量は ジャーニー数 × ビューポート数 × ステップ数 に応じて増えます。さらに、最後に調査結果を説明するための呼び出しが1回あります。チェック自体ではモデルを呼び出しません。

• 必要なジャーニーだけを実行します。 これが最も大きな節約になります。purchase ジャーニー全体ではなく --journey add_to_cart を指定すれば、10ステップ以上ではなく、数ステップで済みます。
• ビューポートを1つだけ実行します。 --viewport mobile を指定すると、デスクトップとモバイルの両方を実行する場合と比べて呼び出し回数が半分になります。
• ステップ数に上限を設けます。 --max-steps 15 を指定すると、ジャーニーが道に迷った場合に停止します。
• ページが大きいほどコストが増えることを想定してください。 各ステップではページビュー（最大250要素、テキスト3,000文字）をモデルに送信するため、情報量の多いページでは、シンプルなページよりも1ステップあたりのトークン数が増えます。
• 繰り返し実行すると、前回のルートから始まります。 サイトでジャーニーを完了すると、次回の実行では、そのジャーニーで通過したページが順番にAIに渡されるため、探索せずに目的地へ直行します。ルートが再利用されるのは、同じ目標の場合、0.14.0以降で実行された場合、かつAI実行の場合に限られます。--out または replay では使用されません。サイトが変更されてルートが合わなくなった場合、AIは別の経路をたどります。
• --events を使って レポートの内容を絞り込みます。ブラウジングが短くなるわけではないため、使用量への影響はわずかです。
• AIを使わずにリプレイします。 完了した実行では、実行したステップが実行フォルダー内の steps.json に保存されます。また、--scripted --no-ai を指定すると、独自の固定ステップがないジャーニーについて、最後に完了した実行のステップを繰り返します。まずAIを使ってジャーニーを1回実行し、その後はデプロイのたびにリプレイしてください。ステップを保存してAIを使わずにリプレイするを参照してください。
• チャットアプリを使います。 MCP経由では、チャットアプリ独自のモデルがブラウジングを行うため、APIキーは一切使われません。
• 一時的な障害では実行回数を消費しません。 モデルAPIからのレート制限、応答の過負荷、接続切断（429、529、5xxなど）は、待機時間を段階的に延ばしながら最大3回再試行し、retry-after に従います。ネットワークによって中断されたページ読み込みやタイムアウトしたページ読み込みも、2秒後に1回再試行します。キーの誤りやページへのアクセス拒否など、その他のエラーは直ちに失敗します。

実行時間はまた別の問題です。--concurrency 3 を指定すると、それぞれ専用のブラウザーで最大3つのジャーニーを同時に実行するため、複数のジャーニーとビューポートを実行する場合、完了までの時間を大幅に短縮できます。モデルの呼び出し回数は変わらず、呼び出し間隔が短くなるだけなので、プロバイダーによってレート制限される場合は 1 または 2 にしてください。

保存したサイトで新しいバージョンを確認する

--save-site <dir> を指定すると、サイトからのすべての応答と、実行したステップも保存されます。replay を実行すると、ネットワークもAIモデルも使わずに、オフラインで同じページを再度監査できます。そのため、費用はかかりません。保存済みの実行と比較して、新たに検出された問題や解消した問題が一覧表示されます。

npx @analitikisler/ai-tag-debugger run --site https://www.yourshop.com --journey purchase --save-site saved/yourshop
npx @analitikisler/ai-tag-debugger replay saved/*
✗ https://www.yourshop.com (saved/yourshop): 0 new, 1 gone
    - warning duplicate purchase desktop ga4 page_view

最初の実行で検出された問題が、期待される問題になります。変更が適切な場合、たとえば誤検知が修正された場合は、replay --update を実行して、新たに検出された問題を期待される問題として設定します。この機能を使うと、既知のサイトでツールの新しいバージョンを確認したり、最後の正常な実行結果と比較してサイトの変更を確認したりできます。保存したサイトのサイズは通常数MBです。トラッキングリクエスト、画像と動画、HttpOnly CookieとログインCookie、ブラウザーが送信したCookie、認証ヘッダー、フォームデータ、メールアドレスなどのユーザーデータがURLに含まれるリクエストは保存されません。ただし、サイトのページとスクリプトは含まれるため、自分が所有していないサイトは公開リポジトリに保存しないでください。

AI を使わずに手順を保存して再生する

完了した実行では、各ジャーニーで行った手順が実行フォルダー aitd/<domain>/runs/<id>/steps.json に毎回保存されます。その後の --scripted --no-ai 実行では、独自の steps がないすべてのジャーニーについて、手順を繰り返します。ジャーニーが完了したサイトの最新の実行を使用し、同じビューポートの実行があればそれを、なければ別のビューポートの実行を使用します。また、ジャーニーの ▶ 行の下に、再生している実行を表示します。つまり、AI が必要なのはジャーニーごとに一度だけで、それ以降の実行には費用がかかりません。

ai-tag-debugger run --site https://www.yourshop.com --journey purchase
ai-tag-debugger run --site https://www.yourshop.com --journey purchase --scripted --no-ai

サイトが変更され、保存された手順で要素が見つからなくなると、そのジャーニーは未完了として終了し、その実行の手順が合わなくなったことを示すメモが表示されます。AI を使ってもう一度実行すると、次の再生では新しい手順が使用されます。サイトで一度も完了したことのないジャーニーがある場合は、ブラウザーの起動前に実行が停止します。再生元となるのは aitd/ に保存された実行だけです。--out を使って別の場所に出力した実行や、MCP 経由で行った実行でも steps.json は書き込まれますが、次の実行ではその場所は参照されません。手順は実行時の状態で保存され、入力した値も含まれます（再生時に再び入力する必要があるため、フォームに入力したメールアドレスも steps.json にそのまま保存されます）。そのため、ジャーニーではテストデータを使用し、実行フォルダーをバージョン管理の対象外にしてください。

代わりに手順をリポジトリに保存するには、--save-steps <file> を使うと、設定ファイルの journeys[].steps に書き込まれます。ファイルが存在しない場合は作成され、設定に実行計画がない場合は、その実行の計画も保存されます。同じ設定ファイルを使えば、AI モデルも API キーも使わずにジャーニーを再実行できます。

ai-tag-debugger run --site https://www.yourshop.com --journey purchase --save-steps ai-tag-debugger.config.json
ai-tag-debugger run --config ai-tag-debugger.config.json --scripted --no-ai

ジャーニーが両方のビューポートで実行された場合、最初のビューポートの手順だけが保存されます。2 つ目のコマンドをデプロイのたびに実行すると、モデル呼び出しなしで同じジャーニーを確認できます。

既知の検出結果を許容する

--fail-on は、指定したレベルの検出結果があるとビルドを失敗させます。ベンダーのピクセルが同意前に発火する場合など、既知の検出結果をすぐに修正しないときは、ベースラインを使うと、その後の実行で新しい検出結果だけを対象に失敗させられます。まず --update-baseline を指定して一度実行し、現在の検出結果をすべてファイルに書き出して内容を確認し、コミットします。

ai-tag-debugger run --config ai-tag-debugger.config.json --scripted --no-ai --baseline baseline.json --update-baseline
ai-tag-debugger run --config ai-tag-debugger.config.json --scripted --no-ai --baseline baseline.json --fail-on warning

このファイルには検出結果ごとに 1 つのエントリーが含まれます。各エントリーの key は、実行時に照合する項目（チェック、プラットフォーム、イベント、ジャーニー、ビューポート、およびパラメーターが不足している場合はそのパラメーター）を示し、残りの項目には読み手向けの情報が含まれます。エントリーを削除すると、その検出結果に対して再び失敗するようになります。許容する理由を示す "note" を追加すると、そのメモは次の --update-baseline の後も保持されます。許容された検出結果は「Accepted」ラベル付きでレポートに残りますが、件数と AI による説明からは除外され、--fail-on の対象にもなりません。件数の後に、許容された検出結果の数と、古くなった（つまり、現在は検出されない）ベースラインエントリーの数が表示されるため、ファイルを整理できます。一部のビューポートまたはジャーニーでのみ許容された問題は、部分的に許容されたものとして報告され、引き続き件数に含まれます。また、別のサイト向けに作成されたベースラインには警告が表示されます。設定ファイルで "baseline": "baseline.json" を指定すると、設定ファイルからの相対パスでベースラインが保存され、オプションを毎回渡す必要がなくなります。MCP の run_audit ツールでも baseline を指定できます。

サイトを設定する

ai-tag-debugger.config.json：

{
  "site": "https://staging.yourshop.com",
  "plan": "measurement-plan.json",
  "gtm_container": "GTM-XXXX_workspace.json",
  "viewports": ["desktop", "mobile"],
  "journeys": [
    {
      "id": "checkout",
      "goal": "Accept cookies, add any product to the cart and complete checkout using the test payment method."
    }
  ]
}

フィールド	意味
site	ベース URL です。可能であればステージング環境を使用してください。
plan	計測プランです。ファイルパスまたはインラインオブジェクト（下記）を指定します。既製のジャーニーを使用する場合は省略できます。--against を指定して実行すると、そのプランが使用されます。
gtm_container	GTM コンテナのエクスポート（Admin → Export container）を任意で指定します。問題のある各イベントについて、送信するタグと発火するトリガー（または送信するタグがないこと）が示されます。また、キャプチャした dataLayer を AI モデルなしで評価し、そのトリガーがジャーニー中に発火したかどうか、および発火しなかった理由（タグの一時停止、イベントを含む push がない、確認された値で条件が不成立、ブロッキングトリガー、同意の拒否）も示されます。
viewports	desktop および／または mobile です。
concurrency	デフォルトは 1 です。同時に実行するジャーニー（および同意シナリオ）の数です。各ジャーニーは個別のブラウザーで実行され、最大 8 まで指定できます。--concurrency と同じです。
journeys	--journey で既製のジャーニーを選択する場合、--goal でジャーニーを説明する場合、または --against でプランとの照合を行う場合は省略できます。
journeys[].goal	AI に実行させる内容を、平易な言葉で指定します。
journeys[].start	開始パスを任意で指定します（デフォルトは /）。
journeys[].steps	--scripted 実行用の固定ステップを任意で指定します：{ "action": "click", "selector": "#add-to-cart" }。指定しない場合、--scripted はそのサイトでジャーニーの最後に完了した実行のステップを繰り返します。
allowed_hosts	ジャーニーが訪問できるその他のホストです。たとえば、ホスト型チェックアウトの場合は ["checkout.payments-provider.com"] を指定します。それ以外の場合、ブラウザーは site のホストとそのサブドメインにとどまります。--allow-host と同じです。
providers	確認するトラッキングプラットフォームです。たとえば ["ga4", "meta"] を指定します。デフォルトは ["ga4", "google_ads", "meta", "tiktok"] です。未設定の場合、サイトがデータを送信するその他のプラットフォームも対象になります。--platforms と同じです。
campaign_checks	デフォルトは true です。各実行では、最初のページを広告クリックのように開き（UTM パラメーター、gclid、fbclid、または開始アドレスにすでに含まれているものを使用）、それらがリダイレクト後も保持され、ヒットに含まれるかを確認します。false にすると、通常のアドレスを開きます。
block_hits	デフォルトは true です。false にすると、ヒットが実際のエンドポイントに到達するようになります。
consent_scenarios	デフォルトは true です。false にすると、同意の選択肢ごとに開始ページを1回ずつ訪問する同意シナリオを省略します。
baseline	受け入れ済みの検出結果を記録したベースラインのパスを任意で指定します。設定ファイルからの相対パスです。--baseline と同じです。既知の検出結果を受け入れるを参照してください。
language	レポートの言語です。en（デフォルト）または tr を指定します。--lang と同じです。
keep_bodies	デフォルトは false です。true にすると、ユーザーデータをマスキングせずに、送信された状態のトラッキングリクエストを保存します。--keep-bodies と同じです。
branding	デフォルトは true です。false にすると、レポートに Analitik İşler のロゴと「Generated by AI Tag Debugger · analitikisler.com」の行を表示しません。--no-branding、または MCP の finish_audit および run_audit ツールでの branding: false と同じです。
report	任意のホワイトラベル設定です：{ "name": "Acme", "logo": "logo.png", "color": "#0a7d5a", "pdf": true }。logo（PNG、JPG、WebP、GIF、SVG に対応。最大 512 KB。設定ファイルからの相対パス）と name は、HTML レポートの Analitik İşler のブランディングを置き換えます（小さな「by AI Tag Debugger」ロゴとクレジットは残ります）。color はアクセントカラーを設定します。pdf: true にすると、report.html と同じ場所に report.pdf も出力されます。
provider	任意で、anthropic、openai、gemini、vercel、cloudflare、または openai-compatible を指定します。--provider と同じです。
base_url、model	API アドレスとモデル ID を任意で指定します。たとえば openai-compatible の場合に使用します。--base-url および --model と同じです。
notify	保存した各実行の後に送るアラートを任意で指定します。slack（Webhook URL、または SLACK_WEBHOOK_URL を読み込む場合は true）と email（メールアドレスまたはアドレスのリスト）を指定します。アラートを参照してください。
設定とプランは読み込まれるとすぐに、ブラウザーの起動前に検証されます。エラーにはフィールド名と、選択肢が決まっている場合は許可される値が表示されます。たとえば、viewports[1]: must be one of desktop, mobile (got "tablet") や journeys[0].steps[2].action: must be one of goto, click, fill, select, scroll, wait のようになります。ツールが認識しないキーは、最も近い候補を示す警告とともに無視されます（Unknown key "viewport" ... Did you mean "viewports"?）。そのため、ファイルに余分なメモがあっても実行は止まりません。aitd plan で保存したプランも、スプレッドシートからインポートしたプランも同じように検証されます。

アラート

実行結果を保存するたびに、notify が「前回実行以降の変更」差分をチームに送信するため、レポートを開かなくてもサイトの変更を確認できます。

"notify": {
  "slack": "https://hooks.slack.com/services/...",
  "email": ["[email protected]"]
}

• Slack には Webhook URL を指定します。"slack": true にすると、代わりに SLACK_WEBHOOK_URL 環境変数から URL を読み込むため、URL をファイルに記載せずに済みます。
• メール には 1 件のアドレスまたはアドレスのリストを指定します。メールは SMTP_URL のサーバー経由で送信されます。たとえば、smtps://user:[email protected]:465 のように指定します。SMTP_FROM で送信者を設定します（デフォルト：最初の宛先）。接続開始時から暗号化される smtps:// を使用してください。通常の smtp:// URL ではログイン情報とメールが暗号化されずに送信され、STARTTLS もサポートされません。

アラートは、保存された実行（--out に送信した実行は対象外）で、比較対象となる過去の実行があり、それ以降に変更があった場合にのみ送信されます。件名には、最初に判定結果、続いて件数と概要が記載されます。shop.example: Fail · 2 new problems · purchase tracking is broken on mobile のようになります。本文では判定結果の行を繰り返した後、修正された項目（以前の状態も併記）と新しい項目を一覧にし、新しい項目にはそれぞれ重要度と担当者を記載します。続いて、スパークライン付きの傾向、再発を繰り返している問題、問題が未解決のまま 5、10、20 回（以降は 10 回ごと）の実行に達した場合の「Still open after N runs」を記載し、同じ未解決項目の一覧が毎回のメッセージに繰り返されないようにします。

shop.example
Verdict: Fail · purchase tracking is broken on mobile · score 25/100
1 problem fixed, 1 new problem. Compared with run 2026-10-15_1000, by health findings (2026-10-16_1000).
- Fixed: GA4 page_view (was: Sent before consent)
- New: Meta Purchase · Broken · "Purchase" was sent without "value". · Developer
Trend over 5 runs (2026-10-12 → 2026-10-16): worsening. Now 2 broken · 1 risk · 0 warning; 3 runs ago 0 broken · 1 risk · 0 warning. `▃▃·▅█`

傾向だけでアラートが発生することはありません。チャネルでエラーが発生した場合、実行は理由を表示して続行します。終了コードは引き続き --fail-on に従います。

CLI

aitd "<sentence>" [-y]
aitd plan --site <url> [--topic <name>] [--headed] [--provider <name>] [--model <id>] [--max-steps <n>] [--data-dir <dir>]
aitd plan list --site <url> [--data-dir <dir>]
aitd plan import <file> --site <url> [--data-dir <dir>]
aitd plan export <plan> --site <url> [--format xlsx|csv] [--data-dir <dir>]
aitd run --site <url> (--against <plan> | --journey <id> | --goal "<text>") [--config <file>] [--events <names>]
         [--max-steps <n>] [--viewport desktop|mobile] [--concurrency <n>] [--platforms <list>] [--data-dir <dir>]
         [--provider anthropic|openai|gemini|openai-compatible] [--model <id>] [--lang en|tr] [--headed]
         [--fail-on broken|risk|warning|never] [--baseline <file>] [--update-baseline]
         [--scripted] [--no-ai] [--save-site <dir>] [--save-steps <file>]
aitd replay <dir>... [--update] [--out <dir>]
aitd mcp [--http] [--port <n>] [--host <addr>] [--token <secret>] [--public-url <https url>] [--reports <dir>]
         [--allow-private-network]
aitd doctor [--site <url>] [--data-dir <dir>]
aitd history --site <url> [--limit <n>] [--json] [--lang en|tr] [--data-dir <dir>]

aitd は ai-tag-debugger の短縮エイリアスで、同じコマンドとオプションを使用できます。各コマンドで使用できる主要なオプションを確認するには、aitd <command> --help を実行してください。

すべてのオプション

オプション	コマンド	意味
--site <url>	plan, run, doctor, history	サイト。plan と history では必須です。run では、--against が指定されている場合、または設定ファイルに指定されている場合を除き、必要です。doctor では、アドレスが http(s) であり、ホスト名を解決できることだけを確認します。
--against <plan>	run	プランと照合します。latest（または last）、first、プラン ID、プランファイルまたはフォルダーへのパスを指定します。
--journey <id>	run	既成のジャーニー（複数回指定できます）。
--goal "<text>"	run	平易な言葉で指定するジャーニー（複数回指定できます）。
--config <file>	run	設定ファイルからサイト、ジャーニー、プランを読み込みます。
--events <names>	run	指定したイベントのみを確認します。例：purchase,add_to_cart。
--viewport <name>	run	desktop または mobile（複数回指定できます）。
--concurrency <n>	run	同時に実行するジャーニーの数です。各ジャーニーは専用のブラウザーで実行されます。1（デフォルト）から 8 まで指定できます。並行実行時、各ジャーニーのログ行は [journey/viewport] で始まり、--headed を指定すると、その数のブラウザーウィンドウが開きます。設定ファイルの concurrency と同じです。
--platforms <list>	run	確認するプラットフォームです。例：ga4,meta。--providers に代わるオプションで、--providers はあと1つのマイナーバージョンまで引き続き使用できます。
--max-steps <n>	plan, run	ジャーニーあたりの AI ステップの上限です（plan のデフォルトは 25）。
--lang <code>	run, history	レポートの言語です。en または tr を指定します。history ではトレンドラインの言語を指定します。
--fail-on <level>	run	このレベルで終了コード 1 を返します。broken（デフォルト）、risk、warning、never を指定します。
--baseline <file>	run	承認済みの検出結果を記録したファイルです。検出結果は引き続き報告されますが、--fail-on の判定には含まれません。既知の検出結果を承認するを参照してください。
--update-baseline	run	実行後、この実行でのすべての検出結果をベースラインファイルに書き込みます。ファイルがない場合は作成します。
--headed	plan, run	ブラウザーウィンドウを表示します。
--provider <name>, --model <id>	plan, run	AI プロバイダーとモデルです。デフォルトでは、設定されている API キーに応じて選択されます。
--scripted	run	AI によるナビゲーションなしで、各ジャーニーの固定ステップを再生します。ステップのないジャーニーでは、そのサイトで最後に完了した実行のステップを繰り返します。
--no-ai	run	AI モデルを一切使用しません。--scripted も有効になります。
--save-site <dir>	run	サイトの応答を保存して、replay で使用できるようにします。
--save-steps <file>	run	各ジャーニーで実行したステップを設定ファイルに書き込みます。
--data-dir <dir>	plan, run, doctor, history	aitd/（プランと実行結果）の保存先です。デフォルトは ./aitd です。run --out に代わるオプションです。
--limit <n>	history	トレンドの読み取り対象とする、サイトの最新の実行結果の数です。デフォルトは 30 です。
--json	history	トレンド系列、検出結果のタイムライン、ジャーニーの安定性をテキストではなく JSON で出力します。
--format xlsx|csv	plan export	スプレッドシートの形式です。デフォルトは xlsx です。
--update	replay	この再生での検出結果を、期待される検出結果として設定します。
--out <dir>	replay	再生レポートの出力先です。run では、--out はあと1つのマイナーバージョンまで非表示のエイリアスとして引き続き使用でき、注記が表示されます。--data-dir を使用してください。
--base-url <url>	run	OpenAI 互換プロバイダーの API アドレスです。
--allow-host <host>	run	ジャーニーのアクセスを許可する追加のホスト（複数回指定できます）。allowed_hosts と同じです。
--keep-bodies	run	ユーザーデータをマスキングせず、トラッキングリクエストを送信時のまま保存します。
--no-branding	plan, run	レポートと plan.html からロゴとクレジット表記を除外します。
--http, --port, --host, --token, --public-url, --reports, --allow-private-network	mcp	詳細は以下の MCP セクションを参照してください。

0.10.0 で削除：plan --from、plan --out、plan --force。プランの下書きは常に新しいフォルダーに保存されます。削除されたフラグを指定すると、代わりに実行するコマンドが表示されます。 検出結果が--fail-on（既定値はbroken）に達すると終了コードが1になるため、デプロイのゲートとして使用できます。ベースラインで承認された検出結果はカウントされません。デプロイのたびに実行する方法については、examples/github-actions/ai-tag-debugger.ymlを参照してください。

CIでのテスト結果。 実行のたびにjunit.xmlも書き出されます。各ジャーニーがテストスイート、各検出結果がテストケースとなり、--fail-onに達すると失敗として扱われるため、GitHub Actions、GitLab、Jenkinsでは検出結果がテスト失敗として表示されます。GitHub Actionsでは、これをアップロードしてJUnitレポーターアクションに渡します。

      - run: aitd run --config ai-tag-debugger.config.json --data-dir tracking-report
      - uses: actions/upload-artifact@v6
        if: always()
        with:
          name: junit
          path: tracking-report/**/junit.xml
      # Optional: any JUnit reporter action turns the file into annotations on the run.
      - uses: dorny/test-reporter@v2
        if: always()
        with:
          name: tracking
          path: tracking-report/**/junit.xml
          reporter: java-junit

GitLabでは、artifacts: reports: junit:に同じパスを指定します。その隣にあるsummary.jsonには、件数、判定（status：fail、attention、passのいずれか、およびfail_brokenなどのheadlineキー）、データ品質のscore（0～100）、保存済みの実行間の傾向を示すdirection、ジャーニー、すべての検出結果（チェック、重大度、プラットフォーム、イベント、ジャーニー、ビューポート、タイトル、メッセージ）、実行フォルダー名を示すrun、そのフォルダーからの相対パスで他のファイル名を示すfilesが含まれます。そのため、スクリプトはcapture.jsonを解析せずに結果を読み取ることができ、実行したマシンに依存する情報は含まれません。

jq '.counts.broken' aitd/example.com/runs/*/summary.json
jq -r '.verdict.status + " " + (.score | tostring)' aitd/example.com/runs/*/summary.json

定期実行。 デプロイのたびではなく、タイマーに基づいて監査するには、examples/github-actions/scheduled-run.ymlを使用します（既定では毎週実行され、cron行は変更できます）。実行間の履歴はキャッシュに保存されるため、新しいランナーでも「前回の実行からの変更」が引き続き機能します。独自のサーバーでは、examples/cron/に同じ処理を行うスクリプトとcrontab行があります。

出力：

• report.html：1つのファイルで、画面は一度に1つ表示します。左側の折りたたみ可能なナビゲーションには7つのセクションが並びます。すべてのセクション、フィルター、カードにはそれぞれブックマークや共有ができる独自のURLがあり、あるセクションから別のセクションへのリンクを開くと、該当するカードが表示されます（所見の「Where」チップを開くと、そのステップで発生したヒットが表示されます）。
  • Summary：リング形式のデータ品質スコア。50未満は赤、89まではアンバー、90以上は緑で表示されます。判定とその見出し、ポイントを失った理由を説明する最大3行のテキスト（満点の場合は表示されません）、重大度別にフィルターされた所見を開くステータスチップ、実行に関する6つのカード（確認したベンダー、各プラットフォームが確認されたジャーニー、確認したイベント、同意、AI プロバイダー、実行そのもの）が表示されます。
  • Findings：3つのグループ（失敗、未検証、合格）に対するフィルターバー（重大度、担当者、プラットフォーム、ジャーニー、ビューポート、検索）。各行は折りたたまれた状態で表示され、開くと Evidence、Fix、Where、Verify のタブが表示されます。影響、考えられる原因、不足しているパラメーターが示された証拠、番号付きの修正手順、発生したステップ、Tag Assistant、GA4 DebugView、Meta Test Events、TikTok Pixel Helper など、修正を確認するためのツールが表示されます。サイトに以前の実行がある場合は、グループの上に Changed since last run が表示されます。
  • Journeys：一度に1つのジャーニーとビューポートを表示します。左側には、ページ名（「Open Home」「Add to cart」など）を付けてページごとにグループ化されたステップと、各ステップで発生したヒットが表示されます。右側には、選択したステップの Hits、Data Layer、Requests タブが表示されます。各ヒットにはイベント、主要なパラメーター、同意の状態が表示され、開くとデコードされたパラメーター、アイテムカード、生のリクエストが表示されます。バッチ化された GA4 リクエストには、そのリクエストに含まれる各イベントが表示されます。問題のある最初のステップを開いた状態で表示されます。
  • Consent：プラットフォームごとに1行で、選択前、同意後、拒否後に受信した内容、Consent Mode のデフォルト値と更新、およびそのタイミング、同意シナリオの表が表示されます。
  • Coverage：各ジャーニーで計画された各イベントが送信されたかどうか、不足しているパラメーター、コンバージョンの整合性が表示されます。--against を指定すると、計画とサイトの比較の分類も表示されます。
  • Inventory：タグインベントリがプラットフォームごとに1行で表示され、開くとホスト、ページ、Cookie が表示されます。
  • Run：実行の詳細（サイト、バージョン、AI プロバイダーとモデル、計画、ジャーニー、ビューポート、プラットフォーム、所要時間、ファイル）が表示されます。サイトに以前の実行がある場合は、Trend も表示されます。 サマリーを除き、各カードは折りたたまれた状態で表示されます。各セクションには「すべて展開」と「すべて折りたたむ」があります。このページには、レール、フィルター、タブ、ディープリンクを動作させる小さなスクリプトが1つ含まれており、ページの Content Security Policy でそのハッシュが許可されています。JavaScript が無効でも、セクションは1つのドキュメントに縦に並び、印刷用レイアウトとしても使えます。キーボード操作：[ でレールを折りたたみ、1～7 でセクションに移動します。ロゴは埋め込まれているため、インターネットから何も読み込まれません。--no-branding を指定すると、Analitik İşler のロゴとクレジット行が省かれます。
• timeline.csv：同じタイムラインを、ヒット、dataLayer push、ネットワーク呼び出しごとに1行で記録したもので、Excel または Google Sheets ですぐに使えます。
• report.md：プルリクエストのコメント、Slack メッセージ、メールに使える Markdown 形式のレポートです。4つのジャーニーを実行した場合、約100行、8 KB 未満です。タイトルは判定結果（# shop.example: purchase tracking is broken on mobile）で、その後にメタ情報を1行、データ品質スコアを含むステータス、件数が続きます。次に、この順で表示されます：前回の実行からの変更点と傾向（サイトに過去の実行結果がある場合）、計画とサイトの比較（--against を指定した場合）、優先事項（担当者別のToDoリスト：Developer、Tag Manager、Marketing）、検出事項（場所、影響、原因、証拠、問題のないケース、担当者、修正方法、確認方法、report.html 内の該当箇所へのリンクを含む詳細ブロックを最大5件。残りはその他の下に各1行で表示）、同意（Consent Mode のタイミングに関する説明と、すべてのセルに理由を記載したシナリオ表）、問題のなかった項目、ジャーニー（実行ごとに1行、その後に問題があったステップのみ）、未確認項目（実行で判定できなかった内容と、それを有効にする設定キー）、およびタグ一覧。ヒットごとのタイムラインはこのファイルには含まれません。timeline.csv に記録されています。
• capture.json：独自の分析用にキャプチャしたすべての情報です。ツールの version、ai プロバイダー、計算された metrics（判定結果、スコア、計画の網羅率、ファネル、プラットフォーム間の同等性、同意への準拠、コンバージョンの整合性、タイミング、優先事項）が含まれます。
• plan-check.json：--against を指定した場合に、計画されたイベントごとにバケットを記録します。
• junit.xml：検出事項を JUnit のテスト結果として出力します。ジャーニーとビューポートごとに1つのテストスイートが作成され、CI システムでテスト失敗として表示できます（上記を参照）。
• summary.json：実行の件数、判定結果、スコア、傾向の方向、ジャーニー、検出事項、ファイル名を1つの小さなファイルにまとめたもので、スクリプトで利用できます。
• plan.html（計画のフォルダー内）：計画されたイベント、パラメーター、ユーザープロパティを読みやすく表示するページです。

レポートの末尾には、「Generated by AI Tag Debugger · analitikisler.com」というクレジット行が付きます。ドメインは通常のリンクです（画像やトラッキングはなく、リファラーも送信されないため、レポートの URL が漏れることはありません）。--no-branding を指定すると、ロゴとともにこの行も削除されます。

トルコ語のレポートを作成するには、--lang tr を指定してください。検出事項のテキスト、見出し、モデルによる説明と修正方法はすべてトルコ語で記述され、エージェントも手順をトルコ語で説明します。

AI チャットアプリから使用する（MCP）

aitd mcp は Model Context Protocol サーバーを起動します。チャットアプリのモデルが監査を実行します。「staging.myshop.com のチェックアウトでのトラッキングを確認して」と尋ねると、ブラウザーを開いて操作し、結果をチャットで説明します。アプリ独自のモデルが処理するため、API キーは必要ありません。

サーバーが提供するツール：

ツール	機能
make_plan	サイトのトラッキング計画（何をトラッキングするか）を作成します。aitd plan --site と同じです。topic（custom-events、ecommerce、forms、consent）を指定すると、イベントの種類を 1 つに絞れます。計画は保存され、その ID を against として finish_audit に渡せます。サーバーを実行しているコンピューターに設定されている AI プロバイダーを使用し、数分かかります。
what_changed	サイトの「前回の実行以降」の差分のみを返します。最新の保存済み実行（aitd run）で修正された問題と新たに発生した問題を、直前の実行と比較します。ブラウザーも AI も使用しません。トルコ語で回答する場合は language を指定します。
start_audit	URL で新しいブラウザーを開き、すべてのトラッキングの記録を開始します。用意されたジャーニー（purchase、sign_up、…）を渡すと、その目標と想定イベントが設定されます。また、確認するプラットフォームを選ぶには providers を渡します。アシスタントが最初に確認するプラットフォームを尋ねます。
browser_action	クリック、入力、選択、移動、スクロール、待機のいずれかを 1 つ実行します。ページと、その操作で送信されたトラッキングヒットを返します。
get_page	現在のページを表示します。
finish_audit	すべての内容を測定計画（JSON）、against として指定した保存済み計画（latest、first、計画 ID、またはローカルサーバー上のパス）、あるいは用意されたジャーニーのイベントと照合します。必要に応じて、指定した events のみを対象にできます。タイムライン付きの完全な HTML レポートを書き出します。サイトは監査の情報から取得します。
run_audit	設定ファイルを最初から最後まで実行します。against を指定すると、実行内容を保存済み計画と照合します。また、設定にジャーニーがない場合は、その計画から導出したジャーニーを実行します。concurrency は同時に実行するジャーニーの数を指定し、それぞれが独自のブラウザーで実行されます（既定値は 1）。baseline は --update-baseline で書き込まれた、受け入れ済みの検出結果を記録するファイルを指定します（既定値：設定ファイルの baseline。詳細は既知の検出結果を受け入れるを参照してください）。ファイルパスを使えるのはローカルの場合のみです。

against には、CLI の --against と同じ値を指定します。HTTP 経由の場合は latest、first、または計画 ID のみを指定でき、パスは指定できません。計画とは、aitd plan --site <url> または make_plan で保存されたものです。何をトラッキングすべきか知りたい場合は計画を、サイトが何を送信しているか知りたい場合は監査を依頼してください。

ブラウザーはサーバーが動作しているコンピューター上で実行されるため、ステージング環境や localhost のサイトにアクセスできます。トラッキングリクエストは通常どおりローカルで処理されます。

ローカルサーバーを起動するアプリ：Claude Desktop、Gemini CLI、Cursor、VS Code、Claude Code

アプリの MCP 設定にサーバーを追加します。Claude Desktop の場合は、「Settings」→「Developer」→「Edit Config」（claude_desktop_config.json）を開きます。

{
  "mcpServers": {
    "ai-tag-debugger": {
      "command": "npx",
      "args": ["-y", "@analitikisler/ai-tag-debugger", "mcp"]
    }
  }
}

ブラウザー（Chromium）は、監査を初めて実行したときに自動でダウンロードされます。所要時間は約1分で、必要なのは初回のみです。事前にダウンロードするには、npx -y [email protected] install chromium を実行します。

ワンクリックまたは1行で設定できます。

• Claude Code： claude mcp add ai-tag-debugger -- npx -y @analitikisler/ai-tag-debugger mcp
• Cursor： Cursor に追加
• VS Code： VS Code にインストール、または code --add-mcp '{"name":"ai-tag-debugger","command":"npx","args":["-y","@analitikisler/ai-tag-debugger","mcp"]}'
• Claude Desktop、Gemini CLI など： 上記の JSON ブロックを使用します。Gemini CLI では、同じ mcpServers ブロックを ~/.gemini/settings.json に設定します。

アプリを再起動すると、ai-tag-debugger のツールが表示されます。アプリが npx を見つけられない場合は、フルパスを指定します（たとえば、Homebrew を使っている Mac では which npx を実行すると /opt/homebrew/bin/npx が表示されます）。レポートは ~/ai-tag-debugger-reports に保存されます。

クローンしたリポジトリから実行する場合は、"command": "node" と "args": ["/path/to/ai-tag-debugger/src/cli.js", "mcp"] を使用します。

URL に接続するアプリ：ChatGPT、Gemini

これらのアプリは HTTPS 経由で MCP サーバーに接続します（ChatGPT では、プランに応じて開発者モードのコネクターを使用します）。サーバーを HTTP モードで起動し、トンネルを使って公開します。

cloudflared tunnel --url http://localhost:8787     # or: ngrok http 8787; note the https address it prints
npx -y @analitikisler/ai-tag-debugger mcp --http --port 8787 --public-url https://<your-tunnel-address>

サーバーは、https://<your-tunnel-address>/mcp/<secret> のような、ランダムなシークレットパスを含む URL を表示します。その URL をアプリのコネクターとして追加します。URL を知っている人は誰でも、お使いのマシンのブラウザーを利用できるため、URL は非公開にし、使用後はサーバーを停止してください。独自のシークレット（--token）は16文字以上である必要があります。

HTTP モードでは、サーバーはローカル実行時よりも厳しく制限されています。

• ディスク上の測定プランや設定は読み込みません（プランをチャットに JSON テキストとして渡すか、against: latest、first、またはその ID を指定して保存済みのプランを使用してください）。また、run_audit は提供されません。サーバー自身が作成したレポートのみを提供します。
• ブラウザーは http と https のページのみを開き、localhost やプライベートネットワークアドレス（192.168.x.x や 169.254.169.254 など）へのアクセスを拒否するため、この URL を使ってネットワーク内を調べることはできません。WebSocket を含むすべてのブラウザートラフィックは、小規模な組み込みプロキシを経由します。このプロキシは各ホストを一度だけ名前解決し、確認済みのアドレスにのみ接続するため、監査中に DNS の応答が変化してもチェックを回避できません。それでもローカルのステージングサイトを監査するには、サーバーを --allow-private-network を付けて起動します。
• 15分間開いたままの監査は終了され、リクエストボディーのサイズは1 MBに制限されます。

トンネルが不要なホスト型サーバーは、Analitik İşler Cloud バージョンに含まれています。

安全性

• エージェントには、明らかなテストデータを使い、実際の支払い情報は絶対に入力しないよう指示されています。実際の支払いやアカウントが必要なユーザージャーニーでは、そこで停止してその旨を報告します。
• 仕組みに記載されているプラットフォームへのトラッキングリクエストには、デフォルトでローカルから応答するため、分析や広告のアカウントにテストコンバージョンが送信されることはありません。
• ブラウザーのアクセス先は、監査対象のサイトとそのサブドメイン、および allowed_hosts に限定されます。開くのは http と https のページのみです。
• モデルには、ページの内容はデータであり、指示ではないと伝えています。プロンプトのルールでモデルが誤解することを完全に防ぐことはできないため、上記のナビゲーション制限によって、誤解したモデルができることを制限しています。
• ブラウザーは、API キーなどのシークレットを環境に含めずに実行されます。
• 広告のマッチングに送信されるユーザーデータは、capture.json に保存したりレポートに表示したりする前に秘匿化されます。対象は、GA4 と Google Ads の拡張コンバージョン（em、ph、uid、…）、Meta の詳細マッチング（ud[*]、udff[*]）、TikTok の context.user、および拡張コンバージョン用にサイトが dataLayer に送る user_data に含まれるメールアドレス、電話番号、氏名、住所、ユーザー ID です。メールアドレスのように見える値は、フィールド名にかかわらず秘匿化されます。ただし、mailto: リンクやリンクフィールド（link_url、link_text、gtm.elementUrl、…）にある、監査対象サイト自体のアドレスは除きます。たとえば、GTM のクリックイベントに含まれる問い合わせリンクは訪問者のデータではありません。各値は [redacted: 64 chars, looks hashed] のようなマーカーに置き換えられ、ハッシュ化されていない値は個人データのリスクとして報告されます。--keep-bodies（"keep_bodies": true）を指定すると、デバッグ用にリクエストが送信時のまま保存されます。
• 保存されるリクエスト本文は、1 リクエストあたり 32 KB、1 ユーザージャーニーあたり 2 MB に制限されます。上限を超えた場合、本文が保存されなかったことがレポートに記載されます。
• 自分が所有するサイト、またはテストの許可を得たサイトのみを対象に実行してください。
• 他の人向けに HTTP サーバーをホスティングしていますか？多層防御として、ネットワークレベル（送信ファイアウォールまたは隔離されたネットワーク）でも、プライベートアドレスとクラウドメタデータのアドレス範囲をブロックしてください。

ロードマップ

• Consent Check：GDPR/KVKK に照らして、Cookie バナーと Consent Mode v2 をさらに詳しく監査します。
• Measurement Plan：URL からプランと dataLayer 仕様を作成します。
• analitikisler.com で、スケジュール実行、デプロイ用 Webhook、ホスト型 MCP サーバー、代理店向けマルチサイトダッシュボードを備えたホスト型バージョンを提供します。

開発

npm run setup   # checks Node, installs the dependencies and Chromium, says whether an AI provider key is set
npm test        # parsers, checks, each AI provider and the MCP server, end to end against the demo shop
npm run test:unit   # only the tests that need no browser, in about ten seconds
npm run lint    # ESLint, the recommended rules only: undefined names, unused imports and the like

リポジトリには開発コンテナー（.devcontainer/devcontainer.json）もあります。Dev Containers 拡張機能を使って VS Code で開くか、GitHub Codespaces で開くと、Chromium のシステムライブラリも含めて npm run setup が実行されます。そこで AI モデルを使うには、キーを Codespaces のシークレットとして追加するか、コンテナーのターミナルでエクスポートしてください。

エンドツーエンドテストでは偽のモデルクライアントを使用するため、API キーなしで実行できます。

ホスト型バージョン

ホスト型実行、スケジュール設定、代理店向けダッシュボードについては、analitikisler.com をご覧ください。

ライセンス

MIT © Analitik İşler