Lieflat Charts — 图表品味法典（日本語版）

Lieflat Chartsは、AIエージェント向けデータ可視化スキル（Agent Skills形式）で、Monoグレースケールを基本としつつ、データのセマンティクスや使用シーンに合わせて自動的にカラープリセットを選択します。データを編集可能で読みやすく、完全なページとして構成できるビジュアルコンテンツに変換することに特化しています。このスキルはmoxt.aiで作成され、Lupi（編集物語型）、Glance（クイック判断型）、Basics（基本編集型）、Interactive（インタラクティブ大図）をサポートします。ユーザーからデータとシチュエーションが与えられたら、ビルド不要でダブルクリックで開ける単一HTMLファイルを生成し、データ変更は上部の配列を編集するだけで済みます。純粋なSVGチャートはオフラインで動作しますが、Chart.js、ECharts、またはオンラインフォントを使用するチャートは、依存関係がインライン化されていない場合はインターネット接続が必要です。デフォルトでは、必ずLupi EditorialとLupi Basicsから選択すること。両方に適切なテンプレートがない場合、またはユーザーがGlance / dashboard / 3秒クイックリードを明示的に要求した場合にのみ、Glanceの使用が許可されます。

色はユーザーが明示的にトリガーする必要はありません。セクション6.5に従い、Monoとcolor-presets.jsの3つのビルトインプリセットの間で自動判断します。ユーザーがブランドカラーやカスタムカラー値を明示的に指定した場合は、納品内でcustomカラーパレットを構築できます。同じHTMLまたは同じグループの納品では、1つのカラーシステムのみに固定し、混在させてはいけません。カラースキンのサンプルはtemplates/color/にあります。

チャートのリファレンスコードを確認する方法: catalogでチャートタイプを特定 → 対応するgalleryファイルを開く → カード内のタイトルで<div class="card">ブロックを見つけて構造を確認 → <script>内で同名の// ════コメントブロックを検索してレンダリングコードを取得します。ページ全体をコピーしないでください。galleryは複数カードの合体ページであり、ユーザーに納品するのは常にセクション9のスケルトンに従って組み立てられた単一チャートファイルです。

ターゲットユーザーは非プログラマー（ライター、マーケター、PPT作成者）です。彼らは自然言語で要求します（「今期のコンバージョンをチャートにして、WeChatの公式アカウントに使いたい」など）。チャートタイプ名は言いません。あなたの役割は、その自然言語要求を正しいチャートに翻訳し、すぐに公開できる品質にすることです。

0. テンプレート優先の厳格な制約

以下のルールは提案ではありません。違反した場合はすべてやり直しです。

リポジトリのテンプレートから生成すること。 各完成チャートは、まずcatalog.mdでチャートタイプ番号を特定し、対応するgalleryの実際の実装を開きます。Lupiはtemplates/lupi-gallery.html、ベーシック型はtemplates/basics-gallery.html、Glanceはtemplates/glance-gallery.html、インタラクティブ大図はtemplates/big-*.htmlを使用します。カラーチャートでも、これらのオリジナルテンプレートが構造の正本であり、templates/color/は配色の確認のみに使用します。
選択したテンプレートのコードスケルトンをそのまま使用すること。 カード内のタイトルに対応する<div class="card">と同名の// ════ チャート名 ════コメントブロックから出発し、そのコアとなるSVG/Canvas/ECharts構造、データエンコーディング方法、比率関係、アニメーションリズムを保持します。データ、タイトル、注釈、出典、必要なレイアウトの変更は許可されますが、テンプレートから離れて「似たような」チャートを別途描くこと、複数のテンプレートを結合してハイブリッドチャートを作成すること、チャートライブラリのデフォルトスタイルに戻すことは禁止されています。
デフォルトの選択順序は固定。 まずLupi Editorial（L1–L15）を完全に比較し、次にLupi Basics（F1–F13）を比較します。データを誠実に表現し、ラベルを収容でき、読み取り可能なテンプレートがこれらのいずれかに存在する場合は、必ずこれらのグループから選択しなければなりません。
Glanceはデフォルトのダウングレードオプションであり、並列の第一選択肢ではありません。 Lupi EditorialとLupi Basicsの両方が適切でない場合、またはユーザーがGlance、dashboard、モニタリング、週報、3秒クイックリードを明示的に要求した場合にのみ、Glanceを使用します。ダウングレードする前に、Lupi/Basicsが不適切である具体的な理由を明記しなければなりません。
ライブラリ外での新規作成は最後の手段。 Lupi、Basics、Glance、およびインタラクティブテンプレートのいずれも対応できない場合にのみ、セクション6の翻訳プロセスを進めることができます。新しいチャートは、最も近いgalleryテンプレートのビジュアル文法とコード構造を継承しなければなりません。

1. ワークフロー（毎回のリクエストでこの6ステップを実行）

データ形状を判断する。 ユーザーに「どんなチャートが欲しいか」を尋ねるのではなく、データがどのような形をしているかを確認します。いくつかのカテゴリの比較？時間系列？構成比？正負を含む？多対一の帰属？ネットワーク？個別レコードの分布？形状がチャート選択の主キーです。
まずLupiとBasicsを監査する。 データ形状に基づいて、それに対応できるすべてのLupi Editorial（L1–L15）とLupi Basics（F1–F13）の候補をスキャンします。少なくとも3つの候補を比較します。3つ未満の場合は、すべての候補をリストアップします。セマンティックの適合性、単位の誠実さ、ラベルの収容力、読み取り速度、ナラティブの緊張感、およびこのバッチでの重複を比較します。
必要な場合にのみGlanceをチェックする。 LupiとBasicsの候補がすべて失敗した場合、またはユーザーがGlance/dashboard/モニタリング/週報/3秒クイックリードを明示的に要求した場合にのみ、Glance（G1–G18）をスキャンします。Glanceを選択する際は、LupiとBasicsが対応できなかった理由を記録し、「Glanceの方が直感的」というだけの記述は避けます。
実際のテンプレートを特定し、ページ全体を構成する。 各チャートについて、システム、チャートタイプ番号、galleryファイル、カード内タイトルを記録し、そのカードの実際の構造とレンダリングコードをスケルトンとして使用します。「このページでは6つのことを伝えたい」と先に考えてからチャートを即興で発明することは禁止されています。ページ全体のナラティブは、テンプレートが特定された後にのみ構成できます。
チャート数ルールに従ってバッチを構成する。 1つのチャートは1つの独立した結論のみを担当します。重複する結論を削除した後、セクション1.1のデフォルト範囲に従って数量を決定します。テンプレートはグローバルに割り当てる必要があります。重複なし、同じ輪郭の積み重ねなし、数を増やすためだけに無理にチャートを追加しない。
テンプレートに従ってレンダリングし、自己チェックを実行する（セクション0、2、3、8）。完成品が選択したgalleryの実装に対応しているかどうかを項目ごとに確認します。データを変更したからといって、テンプレートのコアジオメトリ、エンコーディング、またはエフェクトを変更してはいけません。セクション6.5に従い、納品全体にMonoまたは1つのカラープリセットを選択します。ライブラリ外のチャートタイプは翻訳プロセス（セクション6）を経ます。

1.1 チャート数ルール

チャートの数は独立した結論の数によって決まり、「データ列がいくつあるか」や「5枚か6枚固定」ではありません。

リクエストタイプ	デフォルト完成数	ルール
単一の質問/単一のテーブル/単一の指標	1	最も強力な1枚のみを納品。テンプレートを披露するために拡張しない
2〜3の明確な結論	2–3	各チャートが異なる結論を担当。同一データソースを共有可能
記事、論文、または完全なケーススタディ	4–6	概要、構成、比較、関係、変化など、異なるデータ形状をカバー
ユーザーが数量を明示的に要求	ユーザー要求通り	それでも重複チャートは削除。十分でない場合は説明して削減

デフォルトの1ページあたりの上限は6枚。6枚を超える場合は複数ページに分割するか、セクションごとに納品します。
候補案、Glance/Lupiの比較原稿は最終チャート数にカウントしません。これらは選択プロセスであり、完成品バッチではありません。
1ページに複数チャートがある場合、少なくとも1つの概要結論を保持し、残りのチャートは新しい比較次元、関係、時間変化、または詳細な証拠を提供しなければなりません。
2つのチャートが同じ結論を表現している場合は、読み取りシチュエーションにより適し、データ契約がより誠実なもののみを保持します。

2. Monoシンタックス・ハードルール（違反はやり直し）

デフォルトでmono-tokens.jsを参照します（オープンソース配布時は内容をHTMLにインライン化します）。トークンと競合する値は、常にトークンを優先します。カラーを使用する場合も、カラートークンのみを置き換え、フォント、角丸、レイアウト、アニメーションはmono-tokens.jsに従います。

カラー

デフォルトはペーパーグレー#F0EFEBとチャコールブラック#1C1C1Aの2極、中間に7段階のグレースケールラダー。カラーの例外はセクション6.5に従いプリセットから開始。
明度＝データ: 最も重要＝最も暗い（ダークカード上では反転して最も明るい）。複数系列は重要度に沿ってラダーに割り当て、順番に適当に取らない。
一律ベタ塗り: 不透明な素材、発光なし、グラデーションフィルターなし、シャドウなし。質感は明度のコントラストと形状のみで表現。唯一の例外：オーバーレイタイプのチャート（Radial Patchwork）では、透明度自体が密度をエンコードする。これはデータであり、装飾ではない。
ダークカード（.card.dark）は2種類のチャートのみに使用：暗い背景を必要とする形状（花びら、発光感のある糸/ネットワーク）。デフォルトはライトカード。1画面（4カード）あたり最大1枚のダークカード。

タイポグラフィ

Interフォントファミリー。タイトル700 / チャート内数値800 / 軸ラベル600。カード構造は4点セット固定：結論型タイトル（h2）+ サブタイトル（凡例と時間範囲をここに記述、·で区切る）+ チャート + 出典行（すべて大文字、字間広め）。
タイトルは結論を書き、チャートタイプ名は書かない：「Revenue by plan」は可、「棒グラフ」は不可。さらに良いのは判断を含むもの：「Where we gained, where we bled」。
SVG最小フォントサイズ：半幅カード6.5px、全幅5.5px。収まらない情報はホバーで表示に変更し、フォントサイズを縮小して無理に詰め込まない。

形状

カードの角丸24px、境界線なし、シャドウなし、余白でカードを区切る。棒の端はカプセル型の角丸（縦棒は上端、横棒は外側の端）。
棒グラフで軸を切ってはいけない。 棒の契約は長さ∝数値であり、軸を切ると契約が破綻する。極端な値の正しい対処法：①極端値を天井まで伸ばす（最も誠実）②メインチャート＋拡大鏡サブチャート ③棒を切っても軸は切らない（描ききれないことを明記）。
花びらスキン（太い黒い縫い目＋角丸扇形）は、等分割またはほぼ等分割のラジアルチャートにのみ適用。幅の大きく異なる扇形は互いに遮蔽し、可読性を低下させる。

アニメーション

登場アニメーションはデフォルトでオン。quarticOutで速く入り速く止まる、バウンドなし（波形登場はelasticOut可）。ドットのstagger 8–15ms/個、バー 80–130ms/本。
統一されたリビールメカニズム：スクロールで視界に入ったら再生 + クリックで再再生（tokenのobsRevealを使用、timer付きでクリーンアップ）。
prefers-reduced-motionのダウングレードを必ず含める（tokenのCSSに既に含まれている）。
アニメーションは構造より優先されてはならない：新しいレイアウトを発明しなければ配置できないエフェクトは、存在する価値がない（effectScatterの教訓）。

データ

デモデータはtokenのrnd(i,k)決定論的疑似乱数を使用し、Math.random()は禁止。リロード時に同じ見た目になること。
数値とビジュアルは厳密に比例する。面積エンコーディングはMath.sqrt(v)で半径に換算し、数値をそのまま半径にしてはいけない。

3. 2つのスタイル系の役割分担

同じmonoカラーパレットの下に2つの世界観があります。どちらを選ぶかはシチュエーションと読者が費やせる秒数によります。

	Glance系（18枚）	Lupi系（精読、15枚）
基本単位	形状（太い棒、大きな弧、色ブロック）	レコード（1点 = 1データ）
線	2px以上、堂々と	0.5–0.7px ヘアライン
集約	事前に集約済み、結論を提示	集約を拒否、原材料を開示
読み方	一目で（<10秒）	近づいて読む（30秒以上）
シチュエーション	週報、ダッシュボード、ちょっとした貼り付け	年報、対外向けストーリーページ、ポスター
エンジン	Chart.js / ECharts	手書きSVG

デフォルト戦略：Lupi Editorial → Lupi Basics → Glance。 明確なシチュエーションがない場合、デフォルトでGlanceを選択してはいけません。年報、WeChat公式アカウントの長文、ポスター、オープンソースREADME、ポートフォリオの場合は、まずLupi Editorialを選択。データが少ないか、よく知られたチャートタイプが適している場合は、次にLupi Basicsを選択。最初の2つのグループに適切なテンプレートがない場合、またはユーザーがダッシュボード、モニタリング、週報、3秒クイックリードを明示的に要求した場合にのみ、Glanceの候補プールに入ります。

全量候補監査は「すべてのチャートを一度に作る」ことではありません。 まずデータ形状で同じデータ本体をエンコードできる候補を絞り込み、次に候補を以下のカテゴリに分類します。

セマンティックに適切: 各点、線、面、ビーズの背後に現実の単位または明確な集約基準がある。
ビジュアルに適切: ラベルが収まり、密度が十分で、読者が想定された時間で読み終えられる。
ナラティブに適切: 図形自体がこのデータが伝えようとしている判断を支えられる。単に数字を並べるだけではない。

最終的な選択はこれら3つの共通部分であり、「どのテンプレートファイルが最もコピーしやすいか」ではありません。デフォルトの監査はまずLupi EditorialとLupi Basics内で完了します。両方のグループが失敗した場合にのみ、Glanceに拡張します。同じバッチで複数のチャートを作成する場合は、候補に対してグローバルな割り当てを再度行います。テンプレートの重複なし、形状のローテーション、最大1枚のダークカード、ページ全体が6枚の似たようなリングまたは横棒にならないようにします。

データが少ない（数パーセントしかない）場合でも、Glanceだけが選択肢ではありません。 Lupi化の正しい道は単位分解です。集約された数値を可算単位に分解します（1点 = 1人 / 1パーセントポイント）。密度はレコード数ではなく単位から生まれます。単位の意味はサブタイトルに記述し、誠実な単位のみを分解します（割合の合計が100 → 100個の点）。存在しない個別レコードをでっち上げてはいけません。四捨五入して合計が100に満たない場合（例：49.0+27.4+13.9+5.0+3.2 → 98）、脚注に「さらにN人が四捨五入により失われました」と記述し、偽の単位を作成しない。

少数データにおけるLupiへのパスの優先順位（複数ケースで検証済み）：

まず全量スキャンし、次にコードスケルトンを選択する—ベーシック型グループF1–F13（templates/basics-gallery.html）は疎データのためのLupi語彙：棒/折れ線/面積/ドーナツ/横棒/グループ化/積み上げ/散布/滝/ヒートマップ/進捗/ダンベル/矩形木。編集型L1–L15は、レコードごと、単位分解、関係性、注釈のシンタックスを提供します。basics-gallery.htmlに既製のコードがあるからといって、直接Fチャートを選択しない。
最もデータ本体に近いテンプレートから始める—複数選択肢のパーセンテージはL15、F5、L2を優先比較。100%構成はL14、L5、F4、G4を優先比較。ファネルはL13、F1/F5のダウングレード表現を優先比較。選択の根拠はデータエンコーディング方式であり、ファイルの順番ではない。
ライブラリに本当に対応する形状がない場合のみ新規作成、かつ新規作成はgalleryの既存シンタックス（ヘアラインチック、決定論的rndジッター、paint-orderグロー、全大文字注記）から拡張すること。ライブラリ外の参照を持ち込まない — 「Lupi風」とはgalleryのチャート群のビジュアル文法であり、Giorgia Lupi本人の手書きスタイルではない。
新規作成の少数データチャートには、環境構造レイヤーを十分に追加すること。galleryの見た目の良さは、半分はデータのないファニチャー（帳簿用紙の横線、破線ガイドレール、リム目盛り、10単位ごとの立柱グリッド、注釈引き出し線）によるものです。データレイヤーは誠実に疎にし、密度予算はファニチャーに費やします。データ＋基準線のみの少数データチャートは必然的に貧相になります。

同じバッチの成果物（1ページ複数チャート）ではテンプレートを重複させない。 15枚のLupi系でローテーションは十分可能。同じデータを複数のテンプレートで表現できる場合は、このバッチでまだ使用していないものを選択します。

4. チャート意思決定ツリー（データ形状 → 候補）

番号はcatalog.mdに対応します。これらは候補検索テーブルに過ぎず、矢印と記述順序は優先順位を表しません。実際の選択は以下を遵守しなければなりません。まずすべてのLupi EditorialとLupi Basicsの候補をチェックし、適切なテンプレートがないことが確認された場合にのみ、Glance候補の採用が許可されます。

少数カテゴリの比較（≤8） → G3 Chunky Bars ⇄ 縦並びF1 Rung Bars / 横並びF5 Tick Rows ⇄ L2 Dot Cascade（⚠️ cascadeはカテゴリ名が縦書き。カテゴリ名が4文字以下または短い略語の場合のみ使用可能。中国語の長いカテゴリ名はF5/L5/L12に変更）
複数選択肢のパーセンテージ（各項目独立0–100、合計が100を超える可能性あり） → G3 Chunky Bars ⇄ L15 Ballot Tally
多カテゴリ分布（30–60本） → G12 Stagger Wave
正負を含むカテゴリ数値 → G10 Diverging Bar
構成比 / 100%構成 → G4 Dot Waffle ⇄ L14 Hundred Field ⇄ F4 Tick Donut（円グラフのデフォルト代替）。ほぼ等分割で見栄えが必要 → G2 Petal Rose。構成比×強度の二重エンコーディング → G13 Big Slice。カテゴリ別積み上げ → F7 Stacked Rungs
2時点の比較（前後 / 過去と現在） → カテゴリレベル（≤6カテゴリ）→ F12 Dumbbell Queue（横向き、ビーズ = 実際の単位）⇄ F6 Paired Rungs（並列二段梯子）。2–4系列のみでトレンドラインが必要 → Glance chunky slope（太い線、大きな数字、結論をタイトルに）。交差が多い傾きチャートは可読性を著しく低下させるため、Lupi化のために装飾構造を追加しない。
日次系列（≤30日、区間あり） → G1 Range Capsules ⇄ 日次読み取りF2 Hairline Line ⇄（90日レベル、テクスチャが必要）L3 Barcode Lollipop。30–60日で形状を確認 → F3 Hairline Area
累積成長 → G18 Draw-in + Counter
二系列因果（投入 vs 産出） → G8 Rainfall
リアルタイムデータ → G17 Dynamic Stream
時間によるランキング変化 → G16 Bar Race
曜日×時間×量 → G14 Single Axis ⇄ F10 Dot Heat
滝 / 増減分解（≤6レベル） → F9 Rung Waterfall
単一値進捗（0–100%） → F11 Tick Gauge ⇄ G18 Draw-in + Counter
2次元散布（≤20点） → F8 Plumb Scatter。数百点の分布 → G15 Jitter Strip
グループ化分布、個別レコード → G15 Jitter Strip
カテゴリ×カテゴリ+量（行列） → 軽量（≤100セル）L4 Arc Matrix ⇄ 重量級（大スパン、注釈が必要）L9 Bubble Almanac
多対一の帰属 → 形状重視L5 Radial Convergence ⇄ 名前付きリストL12 Type Colonnade
ファネル / 段階的減少 → L13 Hourglass Stream
階層構造 → G7 Tree LR
階層 + シェア / 重み（2層、値は正の数） → F13 Nested Treemap。誰が誰に属するかだけを見て、大きさを比較しない → G7 Tree LR
イベント系列のライフヒストリー → L11 Trend Lineage
複数エンティティの誕生時間と現状 → L1 Launch Fan
イベントごとの時間分布（1日以内） → L10 Radial Patchwork
二極評価尺度（両端が妥当） → L7 Brand Spectrum。単極スコアリング（レーダーチャート）と区別すること。単極はEChartsネイティブレーダーチャートを使用
ネットワーク → ≤15ノード G6/G11 小図。>15または数字を確認する必要がある場合 → B1 リング / B2 フォース指向。複数セグメントパスのフロー → B3 Threads
複数グループ×グリッド（装飾感が必要） → L8 Dotty Matrix。数値を読み取りたい場合 → 平坦化してG14を使用
同一エンティティセットの多次元カルーセル（デモ） → G9 Scatter Morph

F13 Nested Treemap ハードルール

階層データと非負の重みのみを受け付ける。親の値は子の合計から計算され、親子の合計が矛盾してはいけない。面積は直接ECharts treemapレイアウトに委ね、値に対して平方根を取らない。
デフォルトで2層（親グループ＋リーフ）を表示。2層を超え、読者がレイヤーごとに照会する必要がある場合のみ、ドリルダウンを有効にする。通常の静的納品ではnodeClick:falseを維持し、誤ったクリックでビューが変わらないようにする。
Monoのグレースケールは階層のみを表現し、各リーフにランダムな濃淡を割り当てない。親グループは見出し、グループ間の余白、境界線で区別する。色を削除してもグループ分けが明確であること。
porcelainは単色相の明度を使用して、順序付けられた親グループのシェアまたは階層を表現。palmは色相を使用して、最大4つのトップレベルカテゴリに対応。wireはグレースケールを維持し、明確な主役1つだけにHEROを使用することを許可。
面積がすでに数値を表現している場合、色は無説明で同じ数値を再度表現してはならない。サブタイトルにはarea = ...を明記し、カラーを使用する場合はさらにcolor = ...を明記する。
リーフが30個を超え、ラベルが広範囲に省略されるか、最小矩形が安定したホットゾーンを形成できないほど小さい場合は、まずロングテールをOtherに統合するか、複数に分割するか、G7 / L12 / B系の関係図に変更する。
ツールチップは少なくとも完全な階層パス、元の値、総量に対する割合を表示する。カード内のラベルが収まらない場合は非表示にし、最小フォントサイズ以下に縮小しない。

5. インタラクションの3つの質問（静的 vs インタラクティブを決定）

順番に質問する：

この線/点の背後に実際のレコードはあるか？ ない（純粋なテクスチャ装飾、例：Cluster Fieldのスポーク、Hourglassの流線）→ インタラクションの追加を禁止。コンテンツのない要素にホバーを追加するのは欺瞞。
レコードがある → クリックしなくても読み取れるか？ 要素が50未満で両端にラベルがある（例：Colonnade）→ 静的で十分。ホバーはオプションの追加。
要素が50以上または複数セグメントのパス（例：Threads）→ ホバー/ピン必須。そうでなければ雰囲気図に過ぎない。インタラクションの実装はtemplates/big-threads.htmlを参照：可視線の下に9pxの透明な双子線をホットゾーンとして配置。ホバーで単線をハイライトしパス全体を強調、ラベルホバーで束全体をハイライト、クリックでピン留め。

6. ライブラリ外チャートタイプ・翻訳プロセス

ユーザーが求めるチャートが49枚にない場合（またはリファレンス画像を送ってきた場合）、できないわけではない、その場で文法を作るというプロセスです。4ステップで、最初のステップは省略してはいけません。

まず本体を答える：このチャートタイプは何をエンコードしているか？各ビジュアルチャネル（位置/長さ/角度/面積/明度/密度）は、それぞれどのデータ次元に対応するか？答えられない場合は、ユーザーにデータ構造を尋ねる。形をコピーして魂をコピーしない＝無駄な作業（pictorial barが「記号のカウント」を誤って「木の成長」として表現し、やり直しになった）。
最も近い親戚を見つける：catalogの中でデータ形状が最も似ているチャートを起点として見つけ、そのレイアウトスケルトンとアニメーションリズムを継承する。
トークンを使って文を作る：カラーパレット、フォント、角丸、アニメーションパラメータはすべてmono-tokens.jsから取得し、新しい色やフォントサイズを発明してはいけない。成果物はライブラリ内のチャートと「一目で同じファミリー」と見なせなければならない。カラーを使用する場合は、色をcolor-presets.jsの単一プリセットから変更し、他のトークンはmono-tokens.jsに従う。
セクション2のハードルールとセクション8の自己チェックを通過する。ライブラリ内チャートと同じ基準。

リファレンス画像翻訳の追加ルール：リファレンス画像がどの流派に属するか（Glanceか編集部か）を識別する。編集部スタイルの密度、注釈、手書き感（blob）は本体の一部であり、収束させてはいけない。almanacが「思い切って詰められなかった」ためにやり直しになった例あり。

6.5 カラー（シチュエーションに応じて自動選択、単一カラーシステム）

Monoはフォールバック案であり、カラーがトリガーされなかった場合の強制的な答えではありません。 ユーザーが色について言及していない場合でも、データのセマンティクス、カテゴリ数、読み取りシチュエーション、コンテンツの雰囲気に基づいて、カラーが適切かどうかを評価する必要があります。適合関係が明確でない場合、または色が実際の情報価値をもたらさない場合は、Monoに戻ります。

カラーの初稿は、3つのプリセットから1つを選択します。色値はcolor-presets.jsに、サンプルはtemplates/color/にあります。プリセットは、安定した統一された初版を迅速に得るためのものであり、固定されたカラーパレットではありません。ユーザーが「この青をもう少し濃く」と要求した場合は、現在のカラーシステム内で調整を続けます。ユーザーがブランドカラー、色値、または完全なカラーパレットを明示的に指定した場合は、以下のルールに従ってcustomカラーパレットを構築します。調整後は、コントラスト、ビジュアルの優先順位、データセマンティクスを再確認する必要があります。

同じHTMLまたは同じグループの納品では、まずグローバルなカラーシステム（Mono、porcelain、palm、wire、またはcustom）を1つに固定する必要があります。 すべてのチャートがその選択を共有します。選択したシステムをサポートしないチャートが1枚でもある場合、個別に色を変更してはいけません。グローバルに互換性のあるシステムを選び直すか、グループ全体をMonoに戻します。

構造の正本は常にオリジナルギャラリーです。 レンダリングコードはtemplates/ルートのgalleryを参照し、templates/color/は配色の確認のみに使用します。まずセクション0に従って構造を選択し、次にスキン変更を行うかどうかを決定します。

カラーを使うかどうか

以下の優先順位に従って判断します。

ユーザーが明示的に指定。 ユーザーが特定の色、雰囲気、またはプリセットを要求した場合、それを優先して従うが、容量、コントラスト、データセマンティクスのチェックは依然として必要。
エージェントによる自動選択。 ユーザーが色について言及していなくても、データ形状とシチュエーションが特定のプリセットと明確な対応関係にある場合は、自動的に使用可能。順序付けられた単一系列はporcelainに適している。少数の順序付けられていないカテゴリはpalmに適している。制御された視線の着地点が必要な場合はwireに適している。
関係が不明確な場合はMonoを使用。 カテゴリが多すぎる、高密度レコード、色に安定した意味がない、またはチャートグループ全体が同じプリセットを共有できない場合は、Monoを使用。

カラーはアップグレード版ではなく、エージェントが能動的に選択できるセマンティックツールです。納品時には、選択したカラーシステムと、それが担うデータの意味を1文で説明します。

カスタムカラーパレット（ユーザーが明示的に要求した場合のみ有効）

エージェントは、独自に5番目のデフォルト美的感覚を発明してはいけません。ユーザーが明確な色値、ブランドカラー、ブランドガイドライン、または「このリファレンス画像の配色に従って」を指定した場合のみ、customカラーパレットを構築します。「もう少し良く見えるように」というだけの場合は、3つのビルトインプリセットから選択します。

まずカラーロジックを決定し、次に色値を割り当てる。 順序データには単色相の明度グラデーション。順序なしカテゴリにはカテゴリカルカラー。フォーカスが必要な場合にはニュートラルカラー＋1つのアクセントカラー。まず5色を取得し、その後すべての要素に均等に散布することを禁止。
完全なロールを確立し、単にhexをばらまかない。 customは少なくともBG、TXT、MUT、GRID、DATAを定義する。ハイライトが必要な場合はさらにHEROを定義。順序データにはRAMP、カテゴリカルデータにはCATを定義。完成品にはCUSTOMオブジェクトをインライン化し、すべてのチャートはロールから色を取得する。
入力された数量に基づいて解釈する。 1色の場合、同色相の明度グラデーションを生成。2色の場合、デフォルトでメインデータ色＋アクセント色として分割し、自動的に2つの等しいカテゴリと見なさない。3–6色の場合、データに対応するカテゴリが実際にある場合のみCATに入れる。6色を超える場合は、まずカテゴリを統合するか、位置/ラベルを使用するか、Monoに戻す。
派生した明暗は許可するが、新しい色相を密輸入することは禁止。 明るい色はユーザー色とBGを混合。暗い色はユーザー色とTXTを混合。porcelain、palm、wireの色値を借用してcustomを補完してはいけない。
コントラストはハードルール。 本文と小さなラベルは背景に対して少なくとも4.5:1。大きなテキストは少なくとも3:1。重要な境界線、データ形状、インタラクション状態は隣接色に対して少なくとも3:1。基準を満たさない場合は、まず明度を調整し、ユーザーが指定した主色相を勝手に変更しない。
色が唯一の手がかりになってはいけない。 カテゴリには依然としてラベルを付け、序数は位置/長さ/面積を保持し、強調はタイトルまたは注釈で説明する。色覚異常のユーザーが色を除去しても、チャートの構造は読み取れる必要がある。
1回につきこのcustomのみをロックする。 customはビルトインプリセットと混在させない。複数チャートの納品は同じCUSTOMを共有する。ユーザーがブランドカラーをプロジェクトレベルのプリセットとして固定することを明示的に要求しない限り、customは現在の完成品にのみインライン化され、color-presets.jsに書き戻さない。

ユーザーが後から「もう少し濃く」、「背景をもう少し暖かく」、または特定の色値を置き換えるように要求した場合は、該当するロールを修正し、セット全体のコントラストとセマンティックマッピングを再チェックする。指摘された1つの要素だけを変更してはいけない。

どのプリセットを選ぶか：まずデータ形状、次に雰囲気

データ形状	許可	理由
順序 / 単一系列（進捗、ヒートマップ、時系列、単一指標、ランキング）	porcelain、wire	明度＝データの契約が依然として成立
順序なしカテゴリ ≤4	palm	色相がカテゴリに対応
順序なしカテゴリ 5–6	palm（ぎりぎり）	明度と彩度で区別を補助
カテゴリ >6	Monoグレースケール	カラープリセットの容量不足
抑制が必要だが1つの視線着地点が必要	wire	グレースケールがデータを担い、オレンジは主役のみマーク

ユーザーが言う言葉	プリセット	雰囲気
青、クール、学術的、理性的、シリアス、テクノロジー感	porcelain	単色相ブルー階調
緑、暖かみ、ナチュラル、優しい、ビンテージ、モランディ	palm	緑黄の低彩度、アンバーでアクセント
白黒、抑制的、雑誌感、編集部	wire	黒灰に少し蛍光オレンジ

カラーハードルール

同じ納品では1つのカラーシステムのみを使用。 1枚のチャート、同じHTML、または同じグループの姉妹チャートは、Mono、color-presets.jsの1つのプリセット、またはユーザーが明示的に要求した1つのcustomのみを使用できる。プリセット同士の混在、およびcustomがビルトインプリセットから色を借用して補完することは禁止。
線幅 ×1.8、透明度下限 .85。 グレースケール下のヘアラインは淡色で見えにくくなる。dot heatは除く。
各チャートは少なくとも3つの色階または色相を持つ。 1–2色しか使用しない場合は、グレースケールに戻す。
色は実際の次元に接続されなければならない。 序数グラデーションは数値に、区分色は月またはセグメントに、カテゴリカル色はカテゴリに接続。脚注には色が何をエンコードしているかを明記。
強調色は1つの主役のみに与える。 2番目の主役は強調を無効化する。
ダークカードのデータ色はカード背景より明るくなければならない。 ダーク背景の大図はプリセットのDARKブロックを使用。big-circular / big-force / big-threadsはporcelainとpalmのみ。wireはオリジナルのMono大図を使用。
palmではDATAとHEROは異なる色でなければならない。 アンバーとオリーブは明度が近いため、両方を同等のカテゴリ色として扱ってはいけない。

7. 断る時

断る勇気は、何でも受けることよりも信頼性を高めます。以下の場合は作成せず、代替案を提示します。

軸を切った棒グラフ → 拒否。3つの誠実な代替案を提示（天井まで伸ばす/拡大鏡/棒を切っても軸は切らない）。
発光 / グラスモーフィズム / 3D → 拒否。既存のビジュアル文法を維持。カスタム色値はcustomルールに従ってマッピング。異なるカラーシステムの混在は拒否。
多色相で単一系列を描画 → 拒否。porcelain、wire、またはMonoに戻す。
カテゴリ >6 でカラーを要求 → 拒否。Monoグレースケールに戻す。
地図タイプ（コロプレス、トラジェクトリ）→ ライブラリに地理パイプラインがない。正直にできないと伝え、無理に描かない。
純粋な装飾要素にインタラクションを追加（セクション5の質問1）→ 拒否し、説明。
レーダーチャートの再構築 → 再構築しない。EChartsネイティブレーダーチャート＋Monoトークンスキンを使用（テスト済み：表示シチュエーションでは「認識可能なチャートタイプ」に価値がある）。
データが少なすぎて選択したチャートタイプを支えられない（例：3ノードでフォース指向を要求）→ よりシンプルなチャートにダウングレードし、説明。

8. 納品前の自己チェックリスト

数値とビジュアルは比例しているか？（面積にsqrtを使用？棒の軸を切っていない？）
カラーパレットは制御されているか？HTML全体または同じグループの納品は、Mono、単一ビルトインプリセット、または単一customのみを使用しているか？Monoにラダー外の色が出現したら即やり直し。ビルトインカラーに別のプリセットの色が出現したら即やり直し。customはCUSTOMロールからのみ色を取得し、コントラストチェックを通過しているか？
ラベルは重なっていないか？（barcodeの教訓：近接するピークのラベルは最小間隔を強制）
最小フォントサイズを下回っていないか？（半幅6.5 / 全幅5.5）
デモデータはrndで決定論的か？2回リロードして同じ見た目になるか？
リビールは正常か？（スクロール再生、クリック再再生、timerが重複しない、reduced-motionダウングレードが存在する）
node --checkでシンタックスチェック済みか（<script>の内容を抽出してチェック）。
カードの4点セットは揃っているか？タイトルは結論であり、チャートタイプ名ではないか？
サブタイトルで凡例を明確に説明しているか？（読者がコードを見なくても、この行だけで理解できるか）
全量候補監査は完了したか？少なくとも3つの候補と不採用理由を記述し、「どのテンプレートを採用したか」だけを記録しない。
1ページ複数チャートの場合、テンプレートはグローバルに割り当てられたか？類似した輪郭の繰り返し、ダークカードの過剰、すべてのチャートが同じラジアルチャートになっていないか？
各チャートについて、チャートタイプ番号、galleryファイル、カード内タイトルを記録したか？完成品のコア構造は実際にそのテンプレートからのものであり、再発明ではないか？
Glanceを使用する場合、Lupi EditorialとLupi Basicsがなぜ不適切かを明記したか？そうでなければ、Lupi/Basicsに戻ってやり直し。
最後の質問：このチャートを選択したgalleryの対応するカードの隣に置いたとき、同じテンプレートファミリーに見えるか？単に「スタイルが似ている」だけではないか？

9. 単一ファイルテンプレートスケルトン

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {チャート名}</title>
<!-- EChartsが必要な場合： -->
<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.min.js"></script>
<!-- Chart.jsが必要な場合（G1 / G3）： -->
<!-- <script src="https://cdn.jsdelivr.net/npm/chart.js@4/dist/chart.umd.min.js"></script> -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="{MONO.FONT.link}" rel="stylesheet">
<style>/* MONO.CARD_CSS をインライン化 */</style>
</head>
<body>
<div class="grid2">
  <div class="card"><!-- または card dark / card wide -->
    <h2>{結論型タイトル}</h2>
    <div class="sub">{説明} · {凡例} · {時間範囲}</div>
    <!-- チャートコンテナはエンジンに応じて3択： -->
    <div class="ch" id="ch"></div><!-- ECharts -->
    <!-- 手書きSVG： <svg id="ch" viewBox="0 0 400 320"></svg> -->
    <!-- Chart.js（G1/G3）： <div class="wrap"><canvas id="ch"></canvas></div>、.wrap{position:relative;height:320px} を設定 -->
    <!-- ⚠️ Chart.js 必須... -->
  </div>
</div>
</body>
</html>

Lieflat Charts — 图表品味法典