audit

stardust:audit

URLを1つ入力するだけで、スコアと根拠に基づく監査レポートを1つ出力します。

audit は既存のウェブサイトを3つの観点から確認します。デザイン（ブランドの緊張関係と具体的な改善機会）、SEO／技術面、LLM／AI検索での可視性です。Core Web Vitalsを測定し、すべての結果を7つのディメンションからなるスコアカードと、優先順位付きの指摘事項台帳にまとめ、ビジネス成果の向上に向けてオーナーが改善すべき点を示します。また、このレポートはリデザインの出発点としても自然に活用できます。指摘事項は、stardust の uplift スキルの改善リストと、stardust の direct スキルのフェーズ2.5に反映されます。さらに、uplift を活用したリデザインの方向性で締めくくるため、次のステップとして「$stardust uplift を実行する」ことが明確になります。

基本方針

• デフォルトで複数ページを対象 — --single または --pages で上書きしない限り、$stardust extract <url> --cap 8（ホームページ＋主要な IA の柱となる7ページ）を使用します。
• 非対話型 — 監査中に質問することはありません。想定した内容はすべて audit.json#assumptions に記録し、レポートのエグゼクティブサマリーにも明記します。
• 根拠に基づく — すべての主張に、測定値、T-* の緊張関係 ID、チェック結果、またはスクリーンショットの観察結果を引用します。引用のない主張はレポートに含めません。
• データを捏造しない — 測定できなかった項目は、推定値を黙って示すのではなく、not measured (<reason>) と報告します。根拠に基づく推定を行う場合は、推定であることとその根拠を明記します。
• 失敗ではなく、段階的に機能を縮退 — refero、marketing-skills、modern-web-guidance、PageSpeed Insights などの任意機能は一度だけ確認し、利用できない場合も致命的なエラーとはせず、その状況を記録します。「縮退の段階」を参照してください。

入力

• <url> — 必須。監査対象のサイトです。パスを指定すると、そのサブツリーにクロール対象を絞ります（extract の仕様に従います）。
• --pages <n> — 任意。デフォルトの8ページという抽出上限を上書きします（--cap <n> として渡されます）。
• --single — 任意。指定した URL のみを対象とする1ページ監査を実行します。この場合、ページ間の重複タイトル、サイトマップの網羅性、ページ間の CTA の分散といったチェックは、1ページのみを対象として実行され、その旨が示されます。
• --deploy — 任意。レポートのレンダリング後、DA トランスポートを介して report.html を自己完結型の単一ページとして公開し（../deploy/da-deploy-protocol.md：ソース PUT → プレビュー → 公開）、公開 URL を出力します。トランスポートのみが対象です。自己完結型ファイルが分解されてしまうため、レポートを deploy のセクションからブロックへの変換に通すことはありません。
• --benchmark — 任意。フェーズ5のリファレンスベンチマークを強制します。先行する機能確認に時間がかかった場合や、結果が曖昧だった場合でも、refero MCP を確認します。このフラグを指定しない場合、フェーズ5は機能確認がすぐに成功した場合にのみ実行されます。

その他のフラグはありません。それ以外はすべて、取得したサイトの情報から導き出すか、基盤となるスキルの仕様に従います。

Phase 0 — セットアップ

1. マスタースキルのセットアップ（../stardust/SKILL.md § Setup）を実行します。ただし、監査固有の例外があります。**impeccable が利用できない場合、ここではハードストップではなく劣化として扱います。**依存関係チェックに失敗した場合は、audit.json#degradations に impeccable: unavailable を記録して続行します。Phase 2 は critique/audit のアームなしで実行されます（VISION パスとアクセシビリティの統合は引き続き実行されます）。Phase 6 ではレポートのレンダリングがスキップされます。実行は、audit.json の書き込み後に停止条件（b）に達します。
2. 抽出データの鮮度チェック。stardust/current/ に同じオリジンの抽出データがあり、抽出から7日未満の場合は、それを再利用して site.extraction.reused: true を記録します。オリジンは stardust/state.json（サイトレコードの抽出スタンプ）から取得し、鮮度は最新の pages/<slug>.json#_provenance.fetchedAt から取得します。それ以外の場合は、$stardust extract <url> --cap 8（入力に応じて --single / --pages <n>）を呼び出します。クロール、スクリーンショット、_brand-extraction.json、pages/<slug>.json、PRODUCT.md / DESIGN.md、および Tensions セクションを含む brand-review.html は Extract が管理します。
3. オプション機能を一度だけ確認し、それぞれの結果を劣化レコード（audit.json#degradations）に記録します。
   • marketing-skills プラグイン（seo-audit、ai-seo スキルが存在するか）
   • modern-web-guidance（npx -y modern-web-guidance@latest search "<query>" が応答するか）
   • refero MCP（mcp__refero__refero_search_styles を試行します。ツールが見つからない場合やタイムアウトした場合は、利用不可として扱います）
   • PageSpeed Insights API（キーなしでネットワークに接続できるか）
   • rollout プロジェクト（stardust/rollout/rollout.json が存在するか）

extract が完全に失敗した場合（サイトに到達できない、または headed-Chrome フォールバック後もボット管理によるブロックが続く場合）は、処理を停止し、extract のエラーをそのまま提示します。監査対象がないためです。これが統合前の唯一のハードストップです。§ Stop conditions を参照してください。

Procedure

Phase 1 — ブランド表現と緊張点の分析

stardust/current/_brand-extraction.json と stardust/current/brand-review.html の § Tensions surfaced を読みます（ルールカタログは ../extract/reference/brand-review-template.md の § Tensions にあります）。検出されたすべての T-* 緊張点は所見の候補となる証拠です。ID を引き継ぎ、検出を再導出しないでください。

レポートに必要な4つのブランド表現指標を算出します。それぞれを reference/report-format.md に従って status と method とともに audit.json#measurements に記録します。

• brandColorShare — キャプチャしたホーム画面のスクリーンショットにおける、ブランドカラーのピクセル比率です。推奨手法は Playwright によるピクセルサンプリング（method: "pixel-sample"）です。スクリーンショットを読み込み、グリッド状（例：8ピクセルごと）にサンプリングし、許容範囲内で各サンプルを最も近いパレット項目に分類して、ブランド色相のサンプル数を、描画済み（白または白に近い色以外の）サンプル数で割ります。セッション中にサンプリングが実行できない場合は、キャプチャした画面に基づく根拠のある推定を認めますが、根拠を添えて method: "surface-estimate" として記録する必要があります。測定値として提示してはいけません。
• ctaFragmentation — pages/*.json#ctas[].label から集計した、同等性バケットごとの個別 CTA ラベル数です（T-cta-vocab の判定に使用するバケットと同じものです）。
• typeScale — _brand-extraction.json#type.scaleAudit から取得した、見出しサイズの種類とスケールの種類／比率です。
• radiusSprawl — _brand-extraction.json#motifs.borderRadius から取得した、異なる角丸値とその出現回数です。

フェーズ 2 — デザインとエクスペリエンスの批評

キャプチャしたホームページ（スクリーンショット＋ライブ URL）を 3 回に分けて確認し、 1 つのデザイン所見にまとめます。

1. impeccable による批評＋監査。 委任の仕組みを使い、ハーネスの スキル呼び出しツールから impeccable を呼び出します。 ../prototype/SKILL.md § impeccable の呼び出し方法を参照してください （Claude Code 形式： Skill { skill: "impeccable:impeccable", args: "critique <target>" } を実行し、続いてアクセシビリティ／レスポンシブ／パフォーマンスの確認として "audit <target>" を実行します）。 その所見を監査の所見形式に正規化します。
2. VISION パス。 キャプチャしたスクリーンショット （stardust/current/assets/screenshots/<slug>.png）を直接確認し、デザインディレクターの視点で指摘します。 業界ではすでに使われなくなった古いパターン、階層構造の問題、キャプチャされた画面が活かせていない機会などです。 主張には厳密な根拠が必要です。すべての所見に測定値、緊張関係 ID、またはスクリーンショット上の領域を示してください （例：「home.png、ヒーロー：同じ強さの 3 つの CTA が競合」）。 根拠のない形容詞は所見として扱いません。
3. アクセシビリティの統合。 実際に使われている役割におけるキャプチャ済み配色ペアのコントラストを計算します（WCAG 比率）。 pages/*.json#media.images から alt 属性の網羅状況を確認し、 pages/*.json#landmarks からランドマークの有無と見出しの順序を確認します。 内容のないリンクラベルがある場合は T-link-content-free を再利用します。

フェーズ 3 — SEO と技術面

marketing-skills プラグインがインストールされている場合は、 marketing-skills:seo-audit の手法に従い、issue／impact／evidence／fix の各項目を所見に正規化します。 インストールされていない場合は、チェックを直接実行します。いずれも curl／Playwright で確認できます。

area	checks	method
クロール可能性	robots.txt が存在し、適切であること。サイトマップが宣言され、有効な XML であること	curl
インデックス登録	canonical が存在し、自身を参照していること。meta robots が誤って noindex になっていないこと。http→https のリダイレクトが 1 回であること。リダイレクトチェーンがないこと	curl -I
セマンティクス	main／nav／footer ランドマーク。<h1> が 1 つだけであること。階層を飛ばさない見出し構造	pages/*.json + Playwright
メタデータ	ページごとの title／description の有無と品質。ページ間の重複。Open Graph の網羅性	pages/*.json#metadata
構造化データ	JSON-LD の有無、解析可能性、ページ種別に合ったエンティティタイプ	Playwright / curl

失敗が rollout:baseline のチェック ID （../rollout/reference/checks.md：single-h1、title-missing、 meta-description、canonical、sitemap、jsonld、img-alt、 landmark-main、duplicate-title）に該当する場合は、その ID を 所見の evidence.ref（check:<id>）として再利用してください。既知の ID で記録された所見は、 ロールアウト台帳に登録されると AEM の自動修正レジストリで自動的に認識されます。

Core Web Vitals。 Playwright のパフォーマンス API を使って、LCP／CLS／TBT を測定します （largest-contentful-paint と layout-shift に対する PerformanceObserver、TBT には longtask エントリーを使用）。 測定対象は 2 つのビューポートです。モバイル（375×667、セッションで対応している場合は CPU をスロットル）と、デスクトップ（1440×900）です。 PageSpeed Insights API にキーなしでネットワーク経由でアクセスできる場合は、そちらを優先して method: "psi-api" と記録してください（フィールド INP も取得できます）。それ以外の場合は、 method: "playwright-lab" と記録し、測定メモでラボの TBT が INP の代替指標であることを明記してください。 各指標を reference/scoring.md § パフォーマンスに記載された Google のしきい値表に照らして分類します。

修正の指針。 modern-web-guidance がインストールされている場合は、 失敗の種類ごとに npx -y modern-web-guidance@latest search "<specific failure>" を実行し、 返されたガイド ID を所見の guides[] に記載してください。インストールされていない場合は、 一般的な修正方法を記述し、guides: [] のままにしてください。

Phase 4 — LLM の可視性

marketing-skills:ai-seo がインストールされている場合は、その方法論に従います。 インストールされていない場合は、以下を直接評価します。

• llms.txt — オリジンのルートに存在しますか？
• 回答可能性 — 監査対象の各ページは、ユーザーがそのページに対して抱く質問（「これはいくらですか」「これは何ですか」）に、抽出しやすく、適切に構成された文章で回答していますか？ また、その回答はページのどの位置にありますか？
• schema.org のカバレッジ — JSON-LD エンティティは、組織に加えて、回答エンジンがエンティティを理解するために必要なページタイプのエンティティを網羅していますか？
• 質問形式の見出しのカバレッジ — h2／h3 のうち、スローガンではなく、質問として尋ねられる内容や一覧で確認できるトピックに対応しているものの割合はどれくらいですか？
• コンテンツの深さ — 主要ページの抽出可能な文章の単語数、および具体的で引用可能な主張と、情報の乏しいマーケティングコピーの比較。
• クロール可能なテキストに含まれる重要情報 — 価格、製品の説明、対象ユーザーはクロール可能なテキストに記載されていますか？ それとも画像や JavaScript で描画されるウィジェット内に閉じ込められていますか？
• 測定された引用の読みやすさ — skills/deploy/scripts/ai-readability.mjs --origin <site> <sampled paths> を実行し、ページごとの厳密なスコアと、レンダリング後にのみ存在する単語を増やしている上位ブロックを報告します。このスコアは、Adobe の AI Content Visibility Checker と同一の計算式です（deploy/reference/ai-readability.md）。

Phase 4 の指摘では、「コンテンツを改善する」のようなカテゴリではなく、具体的な修正内容を示します（「価格表に3つの価格をテキストで記載してください。現在はプランカードの画像内にのみ表示されています」）。

Phase 5 — 参考サイトとのベンチマーク（任意）

refero MCP ツールに到達できる場合に実行します。Phase 0 のプローブでは mcp__refero__refero_search_styles を試しています。--benchmark を指定すると再プローブを強制します。利用できない場合は、問題なくスキップします（benchmarks: { status: "skipped", reason: … }）。

利用できる場合は、同じ業種の参考スタイルを2～3件取得し、監査対象サイトのブランド表現（Phase 1 の測定結果）を、そのカテゴリの最高水準のサイトと比較します。関連するデザイン上の指摘と audit.json#benchmarks.references で各参考サイトを引用し、タイトル、URL、および優れている点を1行で記載します。

フェーズ 6 — 統合とレポート

1. スコアカード。 reference/scoring.md に従って7つの評価軸を採点します。アンカーを先に適用し、エビデンスの最低基準を適用したうえで、未測定の評価軸を null にして重みを再正規化します。加重総合スコアを算出します。

2. 調査結果。 フェーズ 1〜5 の内容を、優先順位付きの台帳にまとめます。P1（積極的にビジネス機会を逃している、またはユーザーを排除している）／P2（重大な阻害要因）／P3（仕上げ）。各調査結果には、dimension、evidence（測定値／緊張関係／スクリーンショット／チェック／ベンチマークの引用）、businessImpact（一文）、具体的な fix、guides[] を記載します。

3. 改善の方向性。 ../uplift/SKILL.md § The three-variant role contract にある uplift のバリアント役割の規約と完全に同じ形式で、2〜3個の再設計の方向性を示して締めくくります。A 忠実さを保ちながら修正（解消する調査結果を明記）、B 把握された特性のうち、活用が不十分なものを1つ増幅、C シネマティック（動きをアイデンティティとして扱い、レジスターは ../prototype/reference/motion-registers.md § Selection heuristic に従って提案）。把握した表層が差別化された中間案を支えられない場合は B を省略します。弱い案を3つ出すより、強い案を2つ出すほうが効果的です。

4. stardust/audit/<domain-slug>/audit.json を書き込みます。 スキーマ、スラッグ規則、測定ルールについては reference/report-format.md Part 1 に従います。_provenance を最初のキーにします。

5. stardust/audit/<domain-slug>/report.html をレンダリングします。 reference/report-format.md Part 2 の概要を使って $impeccable craft に委譲します。prototype と同じスキル呼び出しの仕組みを使い、レポートを手動でテンプレート化しないという同じルールを守ります。レンダリング後の検証チェックリストを実行し、失敗した場合は具体的な違反を示して craft を再実行します。open stardust/audit/<domain-slug>/report.html で結果を開きます。

6. 台帳への記録（rollout プロジェクトのみ）。 stardust/rollout/rollout.json が存在する場合は、node skills/rollout/scripts/findings.mjs record を使って、名前空間 audit: のソースから各調査結果をデリバリー台帳に記録します。--source audit:<dimension> を指定し、以下の対応表に従って --layer を設定します。重大度はそのまま引き継ぎ、--fixability は ../rollout/reference/audit-sources.md § Recording an external finding に従って正規化します。返された各 ID を該当する調査結果の ledgerId に書き込みます。

   audit dimension	ledger layer
   brand-expression	brand-tensions
   visual-hierarchy-craft	design-ux
   conversion-focus	content-conversion
   accessibility	accessibility
   technical-seo	seo（サイト全体の場合：cross-page）
   content-llm-visibility	ai-search
   performance	seo

7. --deploy。 指定された場合は、../deploy/da-deploy-protocol.md に従って DA トランスポート経由で report.html を公開します。ファイルを単一ソースとして PUT し、プレビューを POST し、公開版を POST して、配信 URL が 200 を返すことを確認し、配信 URL を出力します。トランスポートのみを行い、レポートに deploy の section→block 変換を実行しないでください。

8. チャットでの要約。 短くまとめます。成果物はディスクにあり、開くことができます。

   audit complete — <url>
   
   Site health: <overall>/100
     <dimension>: <score>   × 7 (not-measured dimensions listed with reasons)
   
   Findings: <n> P1 · <n> P2 · <n> P3
   Top lever: <the single highest-impact P1, one line>
   
   Report: stardust/audit/<domain-slug>/report.html
   Data:   stardust/audit/<domain-slug>/audit.json
   
   Next: run `$stardust uplift <url>` — the report's closing directions
   are its variant briefs.
   

機能低下時の対応

フェーズ 0 で一度プローブし、機能低下はすべて audit.json#degradations に記録して、レポートの方法論付録に反映します。これらのいずれも監査を停止する理由にはなりません。

利用できない機能	動作
refero MCP	フェーズ 5 を省略します。理由を添えて benchmarks.status: "skipped" とします
marketing-skills	フェーズ 3／フェーズ 4 のチェックを直接実行します（上記の表を参照）
modern-web-guidance	一般的な修正テキストを使用し、guides: [] とします
PageSpeed Insights	Playwright のみでラボ指標を測定します。測定の注記で、ラボの TBT は INP の代替指標であることを示します
Playwright のピクセルサンプリングが実行不可能	brandColorShare は根拠を添えて method: "surface-estimate" として提供します
rollout プロジェクト	台帳への記録は行わず、各調査結果の ledgerId を null にします

厳格な制約

• データを捏造しません。 測定できなかった項目は、両方の成果物で not measured (<reason>) とします。推定値には、方法と根拠を明記します。これは、 合成に対して extract が課す規律（../extract/SKILL.md § Failure modes）と同じです。 捏造した監査数値は、実行に移せそうに見えて誤っているため、欠落している数値よりも 深刻です。
• 証拠に基づいて記述します。 すべての所見には、測定キー、T-* の緊張 ID、 スクリーンショット上の領域、チェック ID、ベンチマーク URL のいずれかを示し、 観察可能な証拠を引用します。引用のない主張は、合成時に削除します。
• レポートは craft でレンダリングします。 report.html は、 reference/report-format.md のブリーフに基づき $impeccable craft で作成し、 その後に検証します。手作業でテンプレート化したり、手作業でパッチを当てたりしてはいけません。
• 両方の成果物で来歴を必須とします。 ../stardust/reference/artifact-map.md § Provenance shapes に従います。
• 非対話型です。 通常のフローでは質問せず、前提はレポートに記載します。停止するのは以下の 2 つの場合のみです。
• 監査では修正しません。 修正は、uplift（ページの再設計）、direct Phase 2.5（改善リスト）、および rollout の最適化ループ（プラットフォームの自動修正）が担当します。監査は修正内容を示しますが、サイトは編集しません。

停止条件

次の場合に限り、停止してその内容のみを報告します。

(a) Extract が完全に失敗した場合 — サイトにアクセスできない、構造を解析できない、または headed-Chrome フォールバックを経てもボット管理によるブロックが解消しない場合です。extract のエラーをそのまま報告します。監査対象はありません。 (b) impeccable を利用できない場合 — Phase 2 の批評／監査アームと Phase 6 のレポートレンダリングで必要です。Phase 0 の例外に従い、縮退モードで実行を続けます（VISION パス、SEO／技術、LLM の可視性、ベンチマークはすべて実行します）。audit.json を書き込んだ後、デザイン済みレポートには impeccable プラグインが必要だとユーザーに伝えて停止します。データを提供し、手作業でテンプレート化した代替物は作成しません。

それ以外のすべては段階的に縮退させます。通常のフローで、監査が確認を求めて停止することはありません。

出力

stardust/
├── current/                             ← from extract (reused when <7 days old)
│   ├── _brand-extraction.json
│   ├── brand-review.html                ← Tensions section = Phase 1 input
│   ├── pages/<slug>.json
│   └── assets/screenshots/<slug>.png    ← VISION-pass + report evidence figures
└── audit/
    └── <domain-slug>/                   ← hostname, www-stripped, dots → dashes
        ├── audit.json                   ← scorecard, measurements, findings[], provenance
        └── report.html                  ← craft-rendered, self-contained

stardust/rollout/optimize/findings.json  ← appended via findings.mjs (rollout projects only)

監査では state.json にエントリーを書き込みません。抽出の状態は extract が管理し、監査独自の成果物は来歴情報によって自己記述されます。新しい抽出結果に対して監査を再実行すると、stardust/audit/<domain-slug>/ を上書きします。台帳への記録は、台帳独自の ID ハッシュによって重複を排除します。

対象範囲

• 監査と改善策の提示を行います。サイトや、その再設計成果物は変更しません。
• 1 回の実行につき 1 つのオリジンを対象とします。競合サイト群を監査する場合は N 回実行します。
• 自然な後続作業は、$stardust uplift <url>（締めくくりの指示はそのバリアントブリーフになります）、stardust の direct スキル（所見は Phase 2.5 の改善リストに反映されます）、rollout の最適化ループ（既知のチェック ID を持つ台帳の所見は AEM 上で自動修正されます）です。

参照資料

• reference/scoring.md — 7 つの評価軸、重み、40／70／90 点の観察可能な基準、採点手順。
• reference/report-format.md — audit.json のスキーマ（パート 1）、および report.html の作成概要とレンダリング後の検証（パート 2）。
• ../extract/SKILL.md — クロール、キャプチャ、ブランド要素の抽出。統合を避ける規律については「失敗モード」を参照してください。
• ../extract/reference/brand-review-template.md § Tensions — フェーズ 1 で引き継ぐ T-* 検出器カタログ。
• ../prototype/SKILL.md § Invoking impeccable — 批評（フェーズ 2）とレポートのレンダリング（フェーズ 6）で再利用するスキル呼び出しの委任メカニズム。
• ../rollout/reference/audit-sources.md — フェーズ 6 で適用する検出事項台帳の正規化ルール（深刻度、修正可能性）。
• ../rollout/reference/checks.md — AEM の自動修正が検出事項を取り込めるよう、再利用するベースラインのチェック ID。
• ../rollout/scripts/findings.mjs — 台帳の書き込み処理（record）。
• ../uplift/SKILL.md § The three-variant role contract — 最後に提示する改善案の枠組み。
• ../prototype/reference/motion-registers.md § Selection heuristic — 方向性 C のレジスター提案。
• ../direct/SKILL.md § Phase 2.5 — 以降の再設計で改善点リストを取り込む監査結果。
• ../deploy/da-deploy-protocol.md — --deploy の背後にある DA 転送（ソース PUT → プレビュー → 公開。ブロック変換なし）。
• ../stardust/SKILL.md § Setup — フェーズ 0 で実行するマスタースキルのセットアップ。
• ../stardust/reference/artifact-map.md — プロベナンスの形式。