pfd

知覚優先デザイン（PFD）：v0.7.0

著者： Stefan Kovalik / Aurochs フレームワークのバージョン： 3.6（2026-04-20）。引用約100件、国際的な研究の統合、Methodology Siblings セクション、Cultural Calibration メタルール、L0～L4 にまたがる新しいレイヤールール7件 信頼できる唯一の情報源： framework/PERCEPTION-FIRST-DESIGN.md — フレームワークのレイヤー説明を変更した場合は、それに合わせてこのスキルのレイヤー概要も更新してください。正規版はフレームワークであり、このスキルはそこから派生しています。 ライセンス： CC BY-SA 4.0。PFD™ は Stefan Kovalik の商標です（USPTO シリアル番号 99686343）。実践に関する免除事項：業務で PFD を適用しても、継承ライセンスの義務は発生しません。プラグインのルートにある LICENSE と NOTICE を参照してください。 パスの規則： このドキュメント内のパスはすべてプラグインルートからの相対パスです。スキル内のパス（references/...）はこのスキルのディレクトリを起点とし、リポジトリレベルのパス（framework/...、corpus/...）はプラグインルートを起点とします。

---

PFD とは

人間の知覚が実際にどのように機能するかに基づいた、心理学に裏付けられたデザインフレームワークです。「見栄えをよくする」のではなく、人がどのように知覚し、処理し、判断するかを考慮してデザインします。

主張： ユーザーは、そうさせられるまでは考えません。注意はデフォルトでオフです。デザインに関する問いは「注意を無駄にさせないには」ではなく、「注意を喚起したとき、何を考え、どう感じ、次に何をするか」です。

人に情報を伝えるあらゆるものに適用できます。インターフェース、ランディングページ、メール、広告、コピー、プレゼンテーション、提案書、ピッチ、製品説明、ドキュメントなどが該当します。5つのレイヤーは、分析的な思考が働く前に、見る人の神経系が反応する、言語化以前の覚醒を引き起こすためにあります。

---

3つのモード

モード1：PFD 評価（チェックリスト） 既存のデザインを5つのレイヤーに沿って確認します。各レイヤーで、基準を満たしているか、問題があるかを判定します。手早い監査に適しています。

モード2：PFD 導出（生成的） 5つのレイヤーを下から順に進めます。各レイヤーから厳格な要件が導かれます。解決策は、直感や分野の慣習からではなく、積み重なった制約から生まれます。

モード3：PFD 分析（記述的） 5つのレイヤーを制約としてではなく、予測のための視点として捉えます。連鎖する結果、トレードオフ、統合による相乗効果を出力します。仮定の変更に関する問い（「X を変えるとどうなるか」）、メカニズムに関する問い（「なぜ X は機能するのか」）、行動の観察（「ユーザーは X と言うのに Y をするのはなぜか」）に適しています。推奨事項ではなく、分析結果を示します。認知上の約束は、処方的ではなく記述的です。

モード検出（自動）

明示的なコマンドなしでスキルが起動した場合（例：「これを pfd して」「これに PFD を実行して」）、入力を確認してモードを選びます。

モード 1 — 評価：入力が成果物の場合：

• URL、ウェブリンク、または公開中のページ
• スクリーンショット、モックアップ、画像、または PDF
• HTML、CSS、または DOM のスニペット
• レビュー対象の既存のコピー、メール、スライド資料、またはデザイン
• 「これを監査して」「これをレビューして」「これを採点して」「…の何が問題？」「評価して」といった表現

モード 2 — 導出：入力が課題の場合：

• 設計する目標や成果（「X のオンボーディングを設計する」）
• デザインに関する質問（「モーダルとインライン展開、どちらがよい？」）
• 原因の診断依頼（「チェックアウトでユーザーが離脱しています。なぜですか？」）
• 「〜すべきか」「どうすればよいか」「適切なのはどのような…か」「〜を設計して」「これを解決して」といった表現

モード 3 — 分析：入力が仮説、メカニズム、または観察結果の場合：

• 仮説上の変更（「X を取り除くとどうなるか」）
• メカニズムに関する質問（「なぜこれが機能するのか」「この手法はどのように機能するのか」）
• 説明を求める行動の観察（「ユーザーは X と言うのに、Y をする」）
• 既存システムに関する反実仮想や思考実験
• 「〜するとどうなるか」「X が機能しているのはなぜか」「何が変わるか」「置き換えたと想像してみて」「どのような影響があるか」といった表現

曖昧な場合：一度だけ質問します。

「次の 3 つから選んでください。既存のものを評価する（URL／スクリーンショット）、デザイン上の課題を解決する（目標／質問）、またはメカニズムや仮説を分析する（何が起きるか／なぜ）。どれですか？」

境界ケース：

• URL と仮説の両方がある場合（「このページで、ナビゲーションを削除するとどうなりますか？」）は分析に振り分けます。作業の中心は仮説であり、URL は背景情報にすぎません。
• 課題に仮説的な表現が含まれる場合（「X を削除しようと考えています。どうなるでしょうか？」）は分析に振り分けます。仮説的な表現を優先します。
• 質問がなく URL のみの場合は、デフォルトで評価に振り分けます。
• 質問形式が成果物に基づく振り分けより優先されます。

コマンドによる強制指定：

• /perception-first-design:solve — 常にモード 2（解決策を導出）
• /perception-first-design:evaluate — 常にモード 1（成果物を監査）
• /perception-first-design:analyze — 常にモード 3（記述的なカスケード）
• /perception-first-design:all — 複合モード。同じ入力に対して 3 つすべてのモードを実行

---

5 層の依存スタック

下層から順に修正します。上流の失敗は、下流のすべてを妨げます。

認知負荷（L0）

「処理能力がなければ、何も認識できません。」

• ワーキングメモリ：約 3～5 チャンク（Cowan、2001、2010 — Miller の「7±2」ではありません）
• ワーキングメモリは無意識の処理にも使われます（Hassin et al.、2009）：視覚的なノイズは、注意を向けていない場合でも処理能力を消費します
• 内在的負荷（タスク）のために処理能力を確保できるよう、外在的負荷（不適切なデザイン）を取り除く必要があります
• 処理量が容量を超えると、脳は離脱を選びます
• 制約の種類： 同時処理における容量の上限

実践例： 選択肢を減らします。段階的開示を使います。適切なデフォルトを設定します。不要なフィールドを削除します。ユーザーが意識的に気づくことのない背景ノイズ（不統一な余白、システムに沿わない色）を取り除きます。ユーザーのワーキングメモリは、いずれにせよその負担を負います。
失敗の兆候： フォームの放棄、選択肢の多いページでの高い直帰率、「どこをクリックすればいいの？」という声

レイヤー 1：第一印象のアーキテクチャ

「サイトに与えられる時間は50ミリ秒です。」

• 視覚的な魅力の判断は50msで形成されます（Lindgaard et al., 2006）
• 美的ユーザビリティ効果：美しいものほど、より機能的だと認識されます（Kurosu & Kashimura, 1995）
• 5段階のサブルーチン（Leder et al., 2004）：知覚 → 暗黙的統合 → 明示的分類 → 認知的習熟 → 評価。それぞれの段階が独立して失敗する可能性があります。
• 言語化される前の覚醒には、L1で2つの極性があります（Mori, 1970; Pessiglione et al., 2007）：不気味の谷への反応は分析前にL1を失敗させ、サブリミナルな報酬の手がかりは、意識される前にL1を通過します。
• 第一印象こそが活性化ポイントです。注意をOFFからONに切り替えます。
• **制約の種類：**時間的ゲート — ここで失敗すると、それ以降は何も評価されません。

**実践方法：**ヒーロー／冒頭部分は、主張を示すものです。ビジュアルの品質は価格帯に見合う必要があります。不気味の谷を引き起こす要素（不自然なAI写真、不気味なアニメーションのタイミング、非対称な顔）を監査します。 **失敗の兆候：**直帰率が高く、ページ滞在時間が短い。「怪しく見える」。より劣る製品を持つ競合に負けている。

レイヤー 2：処理の流暢さ

「処理しやすいものは、真実だと感じられます。」

• 読みやすいフォントは、より真実だと判断されます（Reber & Schwarz, 1999）
• この効果は、真実性、自信、好意、信頼にも及びます（Alter & Oppenheimer, 2009）
• 客観的に測定できる流暢さではなく、主観的に感じられる流暢さ（Forster, Leder & Ansorge, 2013）：Lighthouse のスコアと実際に感じられる流暢さには相関がありますが、同じものではありません。L2はその差にあります。
• 感覚をまたいだ一貫性：すべての要素が同じストーリーを伝えます（Spence, 2011）
• 創造性より一貫性。一貫性の欠如は、信頼の低下を積み重ねます。
• **制約の種類：**シグナル品質 — 一貫性の欠如は、真実性／信頼のシグナルを劣化させます。

**実践方法：**フォントは最大2種類。色は3〜4色。余白を一貫させます。声の調子とトーンを一貫させます。指標をクリアするためではなく、流暢さが感じられるように設計します。 **失敗の兆候：**タッチポイントごとにブランディングが一貫していない。ビジュアル／文章の品質が価格帯に見合っていない。

レイヤー 3：知覚バイアスの最適化

「あなたのためではありません。ユーザーのためです。」

• ユーザーは自動操縦で判断し、後から合理化します（Nisbett & Wilson, 1977; Kahneman, 2011）
• アンケート ＝ システム2による合理化。分析データ ＝ システム1の行動。その差に問題が潜んでいます。
• 予測処理：脳は予測を生成し、予測が一致すれば自動操縦となり、予測に反すれば注意が向けられます（Clark, 2013）
• 信頼は議論の結果ではなく、知覚の結果です（Seckler et al., 2015）：ビジュアルの一貫性は信頼を直接高めます。ビジュアルが弱ければ、ユーザーはすべての主張を品質の低い事前情報に照らして判断します。
• **制約の種類：**情報の非対称性 — ユーザーが言うこと ≠ ユーザーが反応すること

**実践方法：**アンケートの回答ではなく、分析データが示す内容に基づいて設計します。明示された好みではなく、感情的な反応をテストします。信頼に関するデータが悪い場合は、文章を書き直す前にビジュアルの一貫性を修正します。 失敗の兆候：「ユーザーはXを望むと言うのに、Yをする」。社内チームの好み ≠ ユーザーの行動。

レイヤー 4：意思決定のアーキテクチャ

「道筋を築く。」

• 適切な選択が最も簡単な選択となるよう、環境を構成します
• 倫理的な説得：整合性（ユーザーの目標＝ビジネスの目標）、誠実さ（提示するもの＝提供するもの）、黄金律（自分がこれを体験しても問題ないか？）
• 説明するのではなく、実演する（Hertwig & Erev、2009）：説明に基づく意思決定では、まれな事象が過小評価されます。インタラクティブなプレビュー、試用版、サンプルによって、意思決定を説明から体験へと移します。
• コミットメントまでの距離に合わせて言語表現のレジスターを調整する（Trope & Liberman、2010）：近い将来の行動には具体的な表現（「今すぐ購入」）を使い、抽象的なコミットメントには抽象度の高い表現（「パートナーシップ」）を使います。不一致があると、取引的、あるいは大げさに感じられます。
• PFDは、本質的な価値を認識するうえでの障壁を取り除きます。価値が存在しないところに価値の認識を生み出すものではありません。
• 制約の種類： 行動構造 — 環境が意思決定を形作ります

「選択肢を減らす」ことの適切さは、状況によって異なります。 選択肢を減らすと、購入ページ、一度限りのコミットメント、なじみのない選択肢など、意思決定の場面での迷いは軽減されます。ただし、専門家向けのツールパレット、閲覧・参照インターフェース、生産性を損なうような選択肢の削減が起きるワークスペースには当てはまりません。原則は、環境全体ではなく、意思決定の場面をシンプルにすることです。

実践例： CTAを体験の自然な着地点として設けます。段階的に信頼を築きます。ダークパターンは使いません。選択肢の密度は状況に合わせます。コンバージョンの場面では少なく、専門家向けのワークスペースでは豊富にします。リスク、価格、不確実性については、説明ではなくインタラクションを通じて実演します。 失敗の兆候： ユーザーはタスクを完了しても、操作されたと感じます。コンバージョン率は高いものの、継続率が低い状態です。専門家が、ツールを隠されたり減らされたりすることに不満を感じます。

---

導出プロトコル

ルール 0： 5つのレイヤーすべてを分析し、要件を積み上げるまでは、解決策を提案してはいけません。

ステップ 1 — 設計上の問題を述べる

ユーザーは何をしようとしているのか。何がそれを妨げているのか。ユーザーは何を体験しているのか。 問題を、機能の不足や他のツールとの比較として説明してはいけません。

ステップ 2 — 各レイヤーを下から順に検討する

各レイヤー（L0 → L1 → L2 → L3 → L4）について： a. 制約を述べます（生物学的・心理学的なハードリミット） b. 違反の内容を述べます（現在の設計がこの制約にどう反しているか） c. 要件を導き出します（設計が実行しなければならないこと。「すべき」ではありません） d. R[n] とラベルを付けます e. **Citations:** の行を含め、フレームワークの研究基盤から最も有力な裏付けとなる研究を1〜2件列挙します。形式は Author (Year) for [reason] とし、複数ある場合はセミコロンで区切ります。

ステップ 3 — 要件を積み上げる

R1〜R5を列挙します。すべて譲れない要件です。解決策はすべてを同時に満たす必要があります。 競合がある場合は、下位レイヤーの要件を優先します。

ステップ 4 — 解決策を導き出す

R1 AND R2 AND R3 AND R4 AND R5を満たすものは何ですか？ 単一の介入策で5つすべてを満たせない場合、どの最小限の組み合わせで満たせますか？

ステップ 5 — 提案を検証する（提案がある場合）

既存の提案を、要件全体に照らして確認します。満たせない要件を記録します。

ステップ 6 — ギャップを特定する

どの提案も満たしていない要件が、当たり前ではない解決策の見つかる場所です。

出力の締めくくり

出力は、次のイタリック体の1行で締めくくります。

初期所見です。要件をラルフループで反復する、根拠をさらに引用する、「分析」／「評価」に切り替える、または追加質問をしてさらに掘り下げることができます。

必須です。イタリック体の1行のみとし、箇条書きのメニューにはしません。

---

分析プロトコル

ルール 0： 5つのレイヤーを制約ではなく、記述的な視点として検討します。推奨事項ではなく、分析結果を示します。解決策の検討に移行してはいけません。

ステップ 1 — 問いを言い換える

分析対象となる変更、メカニズム、または反実仮想を述べます。具体的な内容に基づいて説明します。解決すべき問題として言い換えることは避けます。

Step 2 — 各レイヤーを下位から順に、記述的なレンズとして検討する

各レイヤー（認知負荷 → 第一印象 → 処理流暢性 → 知覚バイアス → 意思決定アーキテクチャ）について、以下を行います。 a. そのレイヤーにおける心理的な現実（制約）を述べます。 b. 変更がそのレイヤーで知覚や認知にどのような影響を与えるかをたどります。 c. 次の4つの観点で、その影響をストレステストします（それぞれの影響には、少なくとも2つの観点、できれば4つすべてから得られた知見を反映させます）。 - ユーザー層による違い（初心者、パワーユーザー、アクセシビリティ、デバイス、人口統計） - 隣接するインフラ（拡張機能、API、自動化、依存する製品、統合、規制対象のサーフェス） - 先行事例（同様の変更はほかで試みられたことがあるか。その結果はどうだったか） - 時間構造（即時／短期／長期：数秒〜数分、数日〜数週間、数か月〜数年） d. 出力：メカニズムの説明と、ストレステストの知見を盛り込んだ「何が起きるか：」という予測行。

レイヤーごとに1つの影響を出してください。5つのレイヤー連鎖による影響は必須です。

Step 3 — トレードオフを確認する

変更はレイヤーを一方向にだけ動かすのか、それとも両方向に動かすのか。レイヤーが両方向に動く場合は、そのトレードオフを別の影響としてではなく、サブ所見として影響に組み込みます。

例：「URLバーを削除する」分析におけるフィッシングリスクは双方向です。発生件数は減る一方で、1件あたりの深刻度は増します。どちらが優勢かによって全体の影響が決まります。トレードオフがあるのに、一方向の影響だと断定しないでください。

Step 4 — 複合的な影響を確認する

複数のレイヤーにわたる影響が積み重なると何が起きるでしょうか。まずは次の3つのパターンを確認します。

• 社会的な集約（個人の経験が集団的な反応へと集約されること：反発、拡散する議論、規制措置）。消費者向けの場合は必ず確認します。連鎖が複数段階にわたる場合は、時間に沿った波として示します。
• ロックインの非対称性（代替行動は定着が速い一方、それを元に戻す導入では変化が戻りにくいこと）。行動変容が関わる場合は必ず確認します。元に戻る過程は、混乱が生じる過程と対称になることはほとんどありません。
• エコシステムへの波及（下流の製品、派生製品、統合先が変更を引き継ぐこと）。成果物がプラットフォームレベルの場合は必ず確認します。

連鎖を通じて、ほかの複合的な影響が明らかになることもあります。それらを探してください。[Cross-layer + Social Aggregation]、[Cross-layer]、または適切なほかの横断的なラベルを付けます。番号付きのレイヤー連鎖と区別するため、文字（A、B、C）でラベル付けします。

Step 5 — 出力形式

• タイトル： 問い
• サブタイトル： 「X layer-cascade consequences, Y integrative compounds.」。具体的な件数を示します。

各影響（番号または文字でラベル付け）には、次の4つの構成要素を含めます。

1. 見出し： 抽象的な分析タイトルと、角括弧で囲んだレイヤータグ（## N. [Title] [Layer] または ## N. [Title] [Layer A × Layer B]）
2. イタリック体の具体的なサブタイトル： 見出しの直下に配置します。影響を平易な言葉で要約し、フレームワークの専門用語は使いません。この1行だけで、PFDの文脈を知らない読者にも影響が伝わるようにします。
3. 本文： メカニズムの説明と「何が起きるか：」という予測を含めます。
4. 引用： 本文の末尾に記載します。書式は **Citations:** Author (Year) for [reason]; Author (Year) for [reason]. とします。フレームワークの調査基盤から、裏付けとなる最も有力な文献を1〜3件選びます。直接の引用がない応用予測の場合は、「Applied prediction; no direct framework citation. Closest adjacent: [related citation].」と記載します。

サブタイトルと引用はどちらも必須です。

• レイヤー連鎖： 連鎖の順序に沿って、上記の4要素を備えた影響を5件、番号付きで記載します。
• 複合的な影響： 独立したセクションに、文字でラベル付け（A、B、C、…）して記載します。見出しには[Cross-layer ...]タグを付け、同じ4要素を含めます。
• 締めくくりの案内： 出力の最後に、次の1行をイタリック体で記載します。

  初期所見です。影響を1つ選んでさらに検討する、追加の引用を加える、「solve」／「evaluate」に切り替える、または詳細を掘り下げるために追加の質問をすることができます。

独立した1行で、必ずイタリック体にします。選択肢を追加しないでください。

---

アンチパターン

アンチパターン	失敗する理由
解決策から始める（「サイドバーが必要」）	要件の範囲を汚染します
競合製品を模倣する（「MiroはXをしている」）	知覚ではなく、ドメイン主導になります
エンジニアリングから始める（「何が最速か」）	知覚ではなく、作業量を最適化します
チェックリスト方式（事後評価）	改善はしますが、生成はしません
レイヤーを飛ばす	依存関係の階層に違反します
曖昧な要件（「すべき」であって「必須」ではない）	欠落があっても解決策が通ってしまいます
分析中に解決モードへ移行する	問いが結果を求めているのに提案を生み出します。記述的な契約に違反します
トレードオフがあるのに一方向の影響だけを見る	レイヤー間の双方向の挙動を見落とします。「フィッシングは一様な上昇として現れる」という例があります
分析でレイヤーを個別に扱う	統合的な複合効果（反発、ロックインの非対称性、エコシステムの連鎖）を見落とします
分析における結果ごとの掘り下げが浅い	単文では正しくても凡庸に見えます。十分な掘り下げとは、複数段落にわたるストレステスト済みの知見です
具体的な副題を斜体で付けずに見出しだけにする	抽象的なタイトルは一覧性に欠けます。フレームワークの背景知識がない読者には、分析を理解するための平易な表現の一文が必要です
結果や要件ごとの「引用」行を省略する	根拠に基づくべき出力が意見のように見えます。フレームワークの信頼性は、研究の蓄積に支えられています
締めの一言を箇条書きのメニューに広げる	出力を最も疲弊している瞬間に作業記憶（WM）を使わせます。アンケート主導で形式が肥大化する原因にもなります。締めの一言は斜体の一行であり、リストにはしません

---

PFD 適用後

インサイトログ（必須 — 分析ごと）

PFD の導出または評価の後は、必ず references/insights-log.md にエントリーを追記してください。

### YYYY-MM-DD — [Brief description of what was analyzed]
**Type:** url | text | image | html | css | copy | directory
**Domain:** [e.g., SaaS landing, ecommerce PDP, email, portfolio, dashboard]
**Key finding:** [The non-obvious thing PFD surfaced — one sentence]
**Layer(s):** [L0/L1/L2/L3/L4]
**Promote?:** yes | maybe | no
**Notes:** [Cross-references, patterns, connections to prior findings]

定型的な分析でも必ず実施してください。PFD が苦労した点、曖昧だったレイヤー、またはプロトコルでうまく扱えなかった点に、インサイトがある場合もあります。

蓄積された学び — シャーディングされたコーパス（v0.5 以降）

学びは references/learnings/ の下に、主要レイヤーごとに整理された個別ファイルとして保存されます。軽量なインデックスから必要に応じて個別ファイルを読み込み、巨大な単一ファイルを最初から読み込むことはしません。

検索手順：

1. references/learnings/_index.md を読みます。各学びが1行にまとまった軽量なインデックスです（1000件以上に対応します）
2. 現在のタスクに関連する個別ファイルをインデックスから探し、パスを控えます
3. Read を使って必要な個別ファイルだけを読み込みます
4. プログラムによる絞り込み（例：「流暢さのタグが付いた L2 の学びをすべて検索」）には、Markdown のインデックスではなく references/learnings/_search.json を読みます

コストの低い方法から： インデックスを検索 → 対象の個別ファイルを読む → 従来の単一ファイルにフォールバック。

accumulated-learnings.md を最初から読み込まないでください — この単一ファイルは、L1〜L19 のみを対象とした移行前のフォールバックです。インデックスが移行前の内容を指している場合、または幅広いコンテキストが必要な場合の最終手段として読みます。フェーズ 2 の一括移行後は完全に廃止されます。

新しい学びを追加する（insights-log で Promote?: yes の場合）：

1. YAML のフロントマターを含む個別ファイル references/learnings/{layer}/l<NNN>-<slug>.md を作成します（必須項目：id、title、layer、date、contributor、source。任意項目：secondary_layers、updated、related、tags）
2. インデックスを再生成します：python scripts/gen-pfd-index.py（リポジトリのルートから実行）
3. 個別ファイル、再生成した _index.md、および _search.json をまとめてコミットします
4. 学びによってスコアリングの挙動が変わる場合は、.claude-plugin/plugin.json のパッチバージョンを上げます

---

参考ファイル

関連する場合に読み込んでください。

• references/learnings/ — 分割された蓄積済みの知見（L0/L1/L2/L3/L4/cross/metaにまたがる29個のアトム）。_index.md（人間向け）または_search.json（機械向け）から検索します。必要に応じて読み込みます。
• references/accumulated-learnings.md — 後方互換性のために保持されている、分割前のモノリシックなファイルです。最初に読み込まず、上記の分割ファイル読み込み方法を使用してください。
• references/citation-standards.md — PFDを一般公開する場合、またはクライアントに提示する場合に必要です。厳密な科学的知見と実践者による統合を区別します。
• references/mvs-psychology-reference.md — 各レイヤーの心理学に関する資料と、一次研究の引用をまとめています。PFDへの違反はすべて、ここにある引用にたどれます。
• references/pfd-spatial-extension.md — PFDをキャンバスツール、空間インターフェース、レイアウトシステム（Figma、Miro、Notion、Cognograph）に適用する場合に読み込みます。
• references/practitioner-corrections.md — 実践者による修正レイヤーです。デフォルトでは空で、評価精度をLLMベースラインから実践者レベルに引き上げるため、監査による修正を追加します。

フレームワーク全体：framework/PERCEPTION-FIRST-DESIGN.md（約870行、約100件の引用）。

---

コーパスに基づく評価（v1）

モード1の評価を行う場合は、より深く分析するためにコーパスを読み込みます。モード2（解決）では、制約設定のためにデザインシステムプロファイルと実践者による修正を任意で読み込みます。モード3（分析）は自然言語入力を対象とし、コーパスの読み込みは不要です。

モード1の評価の場合：

1. corpus/core/tier2-prompt-template.mdを読み、評価プロトコルを確認します
2. テンプレートに記載された読み込み順序（ルーブリック -> 制約 -> 修正 -> デザインシステムプロファイル -> ヒューリスティックルール -> 実例）に従います
3. テンプレートの評価指示を適用します
4. 評価後、以下のインサイトログプロトコルに従って所見を記録します

コーパスには以下が含まれます。

• ヒューリスティックルール（corpus/heuristics/） — 心理学の引用に基づく具体的な検出基準
• デザインシステムプロファイル（corpus/design-systems/） — フレームワーク固有の検出方法と修正案
• 実例（corpus/worked-examples/） — 各スコア範囲の例を示す、評価基準の基準点

（実践者による修正はreferences/practitioner-corrections.mdで追跡します。これが唯一の信頼できる情報源です。）

コーパス評価と簡易評価の使い分け：

• PFDの簡易スキャン（URLなしで、デザインを見るだけ）：スキルの5レイヤースタックをそのまま使用します（コーパスは不要）
• PFDの完全な監査（URLが提供され、詳細な分析が求められる場合）：テンプレートに従ってコーパスを読み込みます
• PFDの導出（デザインの生成）：制約設定のためにreferences/practitioner-corrections.mdとデザインシステムプロファイルを読み込みます

---

バージョン履歴

• v0.7.0 (2026-04-28): モード 3（分析）を追加しました。新しいコマンド /perception-first-design:analyze（仮定の状況、メカニズムに関する質問、行動の観察に対する記述的なカスケード）と /perception-first-design:all（3 モードを統合した実行コマンド）を追加しました。分析プロトコルを正式化しました。5 層カスケードの影響について、それぞれ 4 つの観点（ユーザー層による違い、隣接するインフラ、先例、時間構造）でストレステストを行い、さらに統合的な複合要素（社会的集約、ロックインの非対称性、エコシステムのカスケード）と、統合されたトレードオフを扱います。モード検出を拡張し、スキルを単独で有効化した場合、「X が起きたらどうなるか」「X はなぜ機能しているのか」といった表現をモード 3 に振り分けるようにしました。SKILL.md の「2 つのモード」セクションを「3 つのモード」に改名しました。分析固有の失敗モードを扱う 4 つのアンチパターンを追加しました（解決モードへの逸脱、トレードオフがある場合の一方向の影響、分析における各層のサイロ化、影響ごとの掘り下げ不足）。v2.1 時代に専門家から「すごい」という反応を引き出した URL バー／Chrome の思考実験に照らして仕様を調整しました。v0.6.0 の解決モードではその問いを結論に圧縮していましたが、v0.7.0 の分析モードでは、その問いにふさわしい記述的なカスケードを提示します。
• v0.6.0 (2026-04-27): マーケットプレイス掲載への対応を整えました。.claude-plugin/plugin.json（リポジトリのルート）にプラグインマニフェストを配置し、仕様で規定されたコンポーネント構成（ルート直下の skills/、commands/、scripts/。ネストした skill/ サブディレクトリは使用しません）を採用しました。.claude-plugin/marketplace.json にマーケットプレイスカタログを追加し、Anthropic への公式申請と並行してセルフホスト配布を可能にしました。コマンド名を変更しました。/perception-first-design: 名前空間の下で、pfd → solve（モード 2 の導出）、pfd-audit → evaluate（コーパスに基づくモード 1 の監査）としました。モード検出ルールを追加し、スキルを単独で有効化した場合、入力の形式に基づいて solve と evaluate を自動で振り分けます。調整キャンペーンから新しいアトムを 9 件（l021～l029）追加し、_index.md を再生成してアトム数を 29 件にしました。スキルからすばやく参照できるよう、mvs-psychology-reference.md をスキルのリファレンスに追加しました。ライセンスを、実践に対する免除条項付きの CC BY-SA 4.0 のみへ簡素化しました（従来は MIT と CC BY-SA のデュアルライセンスでした）。商標条項と、許可・禁止される使用例を記載した NOTICE ファイルをリポジトリのルートに追加しました。OS 関連の不要ファイルと非公開の作業ファイルを対象に .gitignore を追加しました。パスの規約を明確化しました。修正内容は references/practitioner-corrections.md に集約しました（信頼できる唯一の情報源）。
• v0.5.0 (2026-04-21): 学習内容を分割して管理するアーキテクチャを導入しました。蓄積された学習内容 20 件を、単一の accumulated-learnings.md から、主要レイヤー（L0/L1/L2/L3/L4/meta/cross）ごとに整理した references/learnings/ 配下のアトムファイルへ移行しました。アトムの YAML フロントマターから scripts/gen-pfd-index.py を使って _index.md（人間が読みやすい形式）と _search.json（機械可読形式）を生成します。SKILL.md のローダーを遅延読み込みに対応させ、まずインデックスをスキャンし、必要に応じてアトムを読み込むようにしました。有効化のたびにコストが増大することなく、1000 件以上の学習内容に拡張できます。単一ファイルは、外部リンクとの互換性を保つためのポインターとして残しています。Framework v3.6 に変更はありません。
• v0.4.0 (2026-04-20): Framework v3.6：国際的な引用を拡充しました。6 つの研究潮流（DE/AT/CH、JP、CN、FR、NL/IL/Scandinavia）から 17 件の引用を追加しました。方法論上の関連分野のセクション（感性工学／長町、ゲシュタルト／Wertheimer＋Metzger、神経美学／Skov＋Nadal＋Leder）を新設しました。文化的キャリブレーションのメタルールを追加しました。アーキテクチャは普遍的ですが、キャリブレーションは文化に応じて異なります。地域をまたいで展開する前に、対象市場のユーザーに対して L1 と L3 を検証してください。7 つの新しいレイヤールールを脚注ではなく、L0～L4 に有効なフレームワークルールとして組み込みました。言語化以前の覚醒反応に関する実証的基盤を強化しました（Hassin 2013、Pessiglione 2007、Mori 1970）。学習 #20「国際的な引用の拡充」を追加しました。マスター文書の行数：817 → 872 行。
• v0.3.9 (2026-04-16): 学習 #19（複数アーティファクトのエンゲージメントフィールドとリレーユーザーモード）を追加しました。欧州のエンタープライズ見込み顧客とのエンゲージメントで 2 回実施した、互いに収束する PFD Ralph Loop により、同じ構造的なギャップが明らかになりました。PFD の 5 層スタックは、1 つのアーティファクトと、目の前にいる購入者を前提としています。しかし、B2B のエンゲージメントは、リレーユーザーが評価する複数のアーティファクトで構成されるフィールドです。あと 2～3 件のエンゲージメントで検証した後、v0.4 で L5 として正式化する候補です。関連する候補の観察事項（暦・タイミングの層）はインサイトログに登録しましたが、まだ昇格していません。
• v0.3.8 (2026-04-02): 「PFD とは」に、統一された目的の記述を追加しました。5 層スタックの明示的な目標として、言語化以前の覚醒反応を掲げています。
• v0.3.7 (2026-03-16): レイヤー番号を正規化しました。Foundation（L0）→ L1 → L2 → L3 → L4。1 つずれていた番号（L2～L5）を修正しました。フレームワークの内容は変更していません。番号の整合のみです。
• v0.3.6 (2026-02-26): 学習 #16（僅差での色の非対称性）を追加しました。Framework v3.3：Bujack et al. 2022 と Brainard 2022 を追加しました（引用 55 件）。L2 の色に関する限定条件（知覚空間と物理空間、OKLCH）を追加しました。デザイントークンのリンティングにおいて、僅差での見落としに対する重大度の重み付けを追加しました。「シュレーディンガーの完成」をうたう見出しを批判的に分析しました。「完成」という枠組みではなく、非加法性に関する知見を引用してください。
• v0.3.4 (2026-02-25): Framework v3.2 の学術監査に合わせて同期しました。引用 53 件（新規 5 件）。Tractinsky 2006 の誤った説明、Miller 1956 の本文、Zak 2015 の留保表現を修正しました。Cowan 2010 に基づいて WM を 3～4 から 3～5 に変更しました。Citation-standards.md を更新し、監査ログをすべて記載しました。
• v0.3.0 (2026-02-24): プラグインを適切なディレクトリ構成に再編成しました。スキルの説明を拡充し、デザイン、マーケティング、コピーライティング、執筆、コミュニケーションを対象に含めました。段階的に開示できるよう、学習内容、引用、PFD-S を references/ に移動しました。/pfd コマンドを追加しました。
• v0.2.0 (2026-02-19): 9 人の専門家による PFD ブレインストーミングの統合を行いました。学習 #9～12 として、時間・セッションの継続性、制約を分布として捉えること、視覚チャネルの監査、知識を経路と調査に分けることを追加しました。
• v0.1.1 (2026-02-19): プロダクトレベルの導出から得た学習 #6～8 を追加しました。
• v0.1 (2026-02-19): 最初のプロトタイプです。導出プロトコル、5 層、PFD-S、蓄積された学習 5 件を含みます。