# Hubble > J-PlatPat の商標CSVから、企業ポートフォリオのブランドイメージ空間分析 （8軸ルーブリックへのLLM採点・重心/分散・時系列ドリフト・ホワイトスペース）を行い、 APOLLO CAPCOM デザインのコンサル品質レポート（PDF）とビジュアルサマリーを生成する。 ユーザーが「商標CSV」「商標分析」「商標ポートフォリオ」「ブランドイメージ」 「イメージ空間」「競合の商標」「出願動向のイメージ面」「ネーミングの傾向」 「リブランディングの兆候」「ホワイトスペース」「J-PlatPatのデータを分析」などに 言及したら、スキル名を明示されなくても必ずこのスキルを参照すること。 区分件数の統計分析のみが目的の場合（TradeMark Evolution の領分）は対象外。 - Skill: `shibayamalicht/hubble` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add shibayamalicht/hubble` - Raw SKILL.md: https://api.skillmd.com/api/skills/shibayamalicht/hubble/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: shibayamalicht (https://skillmd.com/u/shibayamalicht) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shibayamalicht/hubble --- # 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 ` — 正規化・区分展開（標章×区分=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 ` — 決定的特徴量 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 --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//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 [--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 --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 ` — 企業カード（重心・分散・代表/外れ値）・ 3年移動窓の重心系列と変化点候補・区分別マップ座標・5×5 密度と空白セル。 ルーブリック版が混在していると停止する（P3）。 2. `python scripts/plot.py ` — レーダー・軌跡・区分別イメージマップ/密度 （300dpi PNG・日本語フォント）。n [...]` — 母集団重心の 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 ` — 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 と分業。イメージ面に徹する）