Hubble trademark analysis

HUBBLE — 商標イメージ空間分析スキル

Holistic Understanding of Brand-image By LLM-based Evaluation（旧仮称 shohyo-image）

J-PlatPat 出力 CSV → イメージ軸採点（LLM）→ 決定的集計 → コンサル品質レポート、を 発注者のゲート承認だけで完結させる。仕様の正本は DESIGN.md（design v1.0）。 設計原則 P1〜P6（LLMは判断だけ・状態はファイル／ルーブリックが空間定義／同一版内比較／ 初見の消費者視点／人の承認なしに軸・水準・アンカーを変えない／所見は mark_id 参照付き） からの逸脱は禁止。 迷ったら補完せず発注者に質問する。

全体パイプライン（フェーズと発注者ゲート）

0. ワークスペース生成・列マッピング     【G0: 列マッピング承認】
1. 取込・特徴量・名寄せ                【G1: 抜粋承認 + 名寄せ確定】
2. ルーブリック（凍結済み v1.0 を使用。変更時のみ G2 で版上げ）
3. 採点ループ（サブエージェント委譲・バッチ検証・HALT 監視）
4. 集計・図版
5. レポート（Web調査 → 執筆 → PDF/別冊）  【成果物提示】

各段階の詳細な読み物: 採点＝references/scoring_guide.md、レポート＝ references/report_guide.md、業界軸の追加＝references/industry_axis_howto.md。 該当段階に入る前に必ず該当ファイルを読む。

0. ワークスペース生成と列マッピング（G0）

1. python scripts/make_workspace.py <案件名> → workspaces/workspace_<案件名>/
2. 発注者から J-PlatPat CSV を受領し data/raw/ に置く（原本・変更禁止）。
3. 実物の列を確認してから config/columns.yaml を確定する（列名を推測で書かない）。 称呼列が無い場合は「音特徴は欠測扱い」を明示。指定商品列が無い場合は同梱の 区分ラベル表（assets/class_labels.yaml）で goods_summary を代替する。
4. config/settings.yaml の population（検索式・検索日）を発注者から聞いて記入する （未記入だとレポート生成が止まる）。
5. 🛑 G0: 列マッピング表（設計フィールド × 実列 × 変換規則）を提示し承認を得る。

1. 取込・特徴量・名寄せ（G1）

1. python scripts/ingest.py <workspace> — 正規化・区分展開（標章×区分=1行）・ mark_id 付与・mark_type 判定（v1 の採点対象は「文字」のみ）。
2. 名寄せ: 出力される data/normalized/applicant_review.md の候補を発注者に提示。 自動確定は禁止 — 発注者が config/applicant_map.yaml を確定したら ingest を再実行。 検索式の部分一致による偽陽性出願人は settings.yaml の exclude_applicants へ （発注者判断。marks.csv には残し、採点・集計から除外）。
3. python scripts/features.py <workspace> — 決定的特徴量 L1（文字種構成比・モーラ・ 母音構成比・濁/長/促/拗音率）。
4. 🛑 G1: marks.csv / features.csv のサンプル 10 件抜粋を表で提示し承認を得る。

2. ルーブリックとアンカー基準レジストリ

• 共通 8 軸は references/axes_v1.yaml（凍結。status: frozen）。アンカー定義（12 件の 架空標章）は references/anchors_v1.csv。発注者の承認なしに軸・水準・アンカー・ 閾値を変更しない。
• アンカー基準はモデル別: references/baselines/v<版>/<モデルID>.csv のレジストリで 管理する（例: baselines/v1.0/claude-opus-4-8.csv）。モデル ID は正確な ID （エイリアス opus 等は不可 — 指す実体が入れ替わり較正の対応が壊れる）。
• 新モデルの較正（案件ごとではなくモデル ID ごとに 1 回）。較正は使用量がかかるため、 実施前に必ず発注者へコストを提示して承認を得る（勝手に較正しない）:
  1. python scripts/calibrate.py prepare <モデルID> → run1〜3 の採点入力を生成
  2. 各 run を独立サブエージェントに委譲（scoring_guide.md と当該 runN.json のみ・ モデルは当該 ID を指定）→ runN.out.jsonl
  3. python scripts/calibrate.py finalize <モデルID> → 中央値基準を登録＋較正レポート （run 間ばらつき・既存モデル基準との差分表）
  4. python scripts/repro_test.py <ws> --make --label <モデルID> → 2 回独立採点 → --analyze --model <モデルID> --label <モデルID>（目安: 隣接一致率 90% 以上）
  5. 較正レポートと再現性試験報告を発注者に提示し、採用の確認を得てから運用する
• ルーブリック改訂時: 改訂案 → 発注者承認 → 版上げ（axes_v2…）→ 使用する全モデルの 再較正 → 再現性試験 → 凍結。版をまたぐスコアの混在集計は禁止（aggregate.py が停止）。
• モデル間のスコア補正・読み替えはしない（P1）。モデルをまたいで案件を比較する際は、 較正レポートの差分表を注記として引用する。
• 業界軸を足す場合は references/industry_axis_howto.md に従う（人の承認必須）。

3. 採点ワークフロー（L2・パイプライン運転）

親セッション（このスキルの実行者）は進行管理のみを行い、標章を自分で採点しない。

0. 採点モデルの選択 — 必ず発注者に尋ねる（勝手に選ばない・勝手に較正しない）。 採点 GO を求める際、次を 1 回の確認にまとめて提示する:
   • 認定済みモデルの一覧と使い分け: references/baselines/v<版>/*.csv を列挙し、 各モデルの特性（再現性・速度・系統差）を references/calibration/<ID>/report.md から要約して示す（ハードコードされた一覧に頼らない — 新モデルが随時増えるため）
   • 件数・トークン・時間のモデル別見積り
   • 未較正モデルという選択肢: 発注者が一覧に無いモデル（例: 発売直後の新モデル）を 希望できることを添える。希望された場合は、較正＋再現性試験のコスト （約 40〜50 万トークン・1〜2 時間、モデル ID ごとに 1 回だけ）を提示して 実施可否を尋ね、承認後に §2 の較正手順 → 認定 → 採点開始の順で進める
   • レポートの 4 点確認（§5-1。往復削減。承認後は第 1 段 Web 調査を採点と並行開始） 確定したモデルの正確な ID を settings.yaml の scoring_model に記入する （エイリアス不可。基準の無いモデルは batch.py / validate.py が機械的に止まる）。
1. バッチ生成: python scripts/batch.py <workspace> [--count N]
   • 未採点の文字商標 25 件＋アンカー 3 件を、匿名ID（X001…）に置換しシャッフルして data/scores/batches/b###.json へ（盲検化: 実出願番号・アンカーの正体を見せない）。
   • 実IDとアンカーフラグは b###.key.json。採点者には渡さない。
   • 再開制御あり: 採点済みは自動スキップ。未取込バッチ内の標章は「予約済み」として 除外されるので、validate 完了を待たずにいつでも補充生成できる（波同期は不要）。
2. 採点の委譲: バッチごとにサブエージェント 1 体を起動し、次の 2 ファイルだけを 読ませる: references/scoring_guide.md と当該 b###.json。出力は b###.out.jsonl（JSONLのみ）。他のバッチ・scores.jsonl・marks.csv・key は読ませない。 モデルは scoring_model の ID を指定する。
   • 並列度は 12〜16 を既定とする。レート制限（429 / overloaded）を検知したら 並列度を半分に落として続行し、収まったら戻す。
3. 検証と取込: python scripts/validate.py <workspace> <batch_id> --model "<モデルID>"
   • --model は settings の scoring_model と同一文字列（モデルロック。案件内の モデル混在は機械的に拒否される）。検証・取込は番号順。
   • G1 形式 / G2 較正（アンカー逸脱・バッチ横断移動平均）/ G3 縮退。合格行のみ scores.jsonl へ追記（meta: model/date/rubric_version/batch_id/anchor）。
   • 失格 → 出力は .rejected に退避。同じバッチファイルで再委譲。
   • data/scores/HALT.md が生成されたら全作業を停止し発注者に報告。人が確認して 削除するまで batch.py / validate.py は動かない。
4. 連続運転で全件完了までループ: 完了したバッチから番号順に validate し、空いた 並列枠に補充生成→委譲を繰り返す（全バッチの完了を待つ「波」運転はしない）。 500 件超は日またぎ分割も可（再開制御があるため安全）。 サブエージェントが出力ファイルを作らず終了することが稀にある — 再委譲すればよい。

4. 集計・図版（L3・LLM不使用）

1. python scripts/aggregate.py <workspace> — 企業カード（重心・分散・代表/外れ値）・ 3年移動窓の重心系列と変化点候補・区分別マップ座標・5×5 密度と空白セル。 ルーブリック版が混在していると停止する（P3）。
2. python scripts/plot.py <workspace> — レーダー・軌跡・区分別イメージマップ/密度 （300dpi PNG・日本語フォント）。n<map_min_marks の区分はスキップとして manifest に記録。 初回はサンプル図で日本語の豆腐化がないことを確認する。
3. 複数母集団の比較（要望時）: 比較対象すべてで aggregate 済みを確認し、 python scripts/compare.py <wsA> <wsB> [...] — 母集団重心の 8 軸比較・ 業界共通空白と一社固有空白の仕分け・「片方は空白だが他方は埋めている」セルの検出・ 母集団を色分けした重ね合わせマップを comparisons/ に出力する。 ルーブリック版とマップ軸の不一致は機械的に停止（P3）。採点モデルが異なる比較は可 だが、基準レジストリから軸別差分が自動で注記される（スコアの補正・読み替えはしない）。

5. レポート（Web調査 → 執筆 → 組版 → 別冊）

references/report_guide.md を読了してから着手（CAPCOM レポートデザイン準拠）。

1. 4 点確認は採点 GO と同時に前倒しで行う: タイトル案／重点／Web 調査テーマ一覧／ 別冊（ビジュアルサマリー）の要否（1 回の往復にまとめる。未確認のままここへ来た 場合のみ、ここで確認する）。
2. Web 調査（必須・2 段構え）:
   • 第 1 段（採点と並行）: スコアに依存しないテーマ — 対象企業の中期戦略・IR・ 商品化/ライセンス実績・グループ構造イベント — は採点ループが回っている間に 調査し、出所（サイト名・URL・取得日）を台帳化しておく（実時間の短縮）。
   • 第 2 段（集計後）: 検出されたドリフト・新顔標章・ホワイトスペースに対応する 発表の有無を追い調査する。
   • 商標出願日と公開イベントのリードタイム表と、対応が取れない出願の **未発表ウォッチリスト（★）**を作る。
3. output/report.md を執筆（テンプレート: assets/report_template.md。章立て・記法・ 所見の mark_id 必須・ACH 簡易表・ミラーイメージング定型文は report_guide §1-3）。
4. 組版（第一候補: Typst）: python scripts/render_typst.py <workspace> — APOLLO CAPCOM と同一のスタイル（assets/report_style.typ・HUBBLE 銘板）で report.pdf を 生成（機械検査つき。紺表紙・目次・KPI ダッシュボード・要点/まとめ/総括ボックス・ 数値強調・Hiragino 系フォント）。typst CLI が無い環境のみ python scripts/render_pdf.py（reportlab 版・同一検査）に退避する。
5. 別冊 ON の場合: summary.html（KPIタイル・キーカード・主要図版・リードタイム表・ ウォッチリスト）を作成し、headless Chrome で summary.pdf に変換。
6. 成果物一式（report.md/pdf・summary.html/pdf・figures/）を発注者に提示する。

発注者にしか決められないこと（勝手に進めない）

列マッピングの承認（G0）／名寄せと除外の確定（G1）／ルーブリックの変更・版上げ／ 採点モデルの選択（毎案件、認定済み一覧を提示して尋ねる）／新モデルの較正実施 （コスト提示のうえ）／大量採点の実行 GO（使用量がかかる）／HALT 発生時の対処方針／ レポートのタイトル・重点・Web調査テーマ・別冊要否／コールサイン（名称）変更。

使用量・時間の目安

• 採点: 1 バッチ（28件）≒ 6〜10 万トークン・8〜15 分（Opus。Sonnet はおおむね半分の 時間）。1,600 件 ≒ 65 バッチ ≒ 400〜600 万トークン。パイプライン運転＋12〜16 並列で 実時間はおよそ 1 時間（Opus）／30〜40 分（Sonnet）。
• 較正（アンカー12件×3回 ≒ 5〜10 万）+ 再現性試験（50件×2回 ≒ 25〜40 万） ≒ 計 40〜50 万トークン。モデル ID ごとに 1 回だけ（案件ごとには不要）。
• 集計・図版・PDF はローカル実行で数分。レポート執筆・Web調査はメインコンテキストで 行う（第 1 段の Web 調査は採点と並行）。

禁止事項

• 採点のための API 直接呼び出し（v1 の採点は Claude Code セッション内のみ）
• 実在ブランド名のアンカー使用（P4）／ルーブリック版をまたぐ比較・混在集計（P3）
• 発注者の承認なしの軸追加・水準変更・閾値変更（P5）／名寄せの自動確定
• 区分×出願人の統計分析への越境（TradeMark Evolution と分業。イメージ面に徹する）