TRUST_v1.md
# TRUST v1.1 ## AI時代の認知的検証フレームワーク ## Cognitive Verification Framework for the AI Era **Version 1.1** **Created: 2025-12-29** **Updated: 2026-02-28** --- ## § 0. Executive Summary ``` 【197文字で本質を伝える】 AIはすべてを美しく見せる。TRUSTは本物を見抜く力を与える。 AI makes everything look good. TRUST helps you see what's real. TRUSTは「敵と戦う」フレームワークではない。 「パターンに気づき、含んで超える」ためのフレームワーク。 3つのパターン(Polishing Trap, Sycophancy, Cognitive Comfort Trap)に気づき、 3つの問い(Origin, Resistance, Execution)で検証し、 E1-E6のエビデンス・ピラミッドで現在地を知る。 4つの検証モード(Light/Standard/Full/Cross)でリスクに応じた深度を選ぶ。 気づけば、超えられる。 ``` --- ## § 1. 位置づけ — 横断的検証層 ### フレームワーク体系における位置 ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ NOBU'S FRAMEWORK ECOSYSTEM │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ LAYER 0: 原理層(Principles) │ │ メタ原理:含んで超え続ける │ │ │ │ LAYER 1: OS層(Meta-Methods) │ │ ITF / USM / CEM / derivation / AAF / Sovereign AI / ADDE │ │ │ │ ════════════════════════════════════════════════════════════════════════ │ │ ║ TRUST(検証層 / Verification Layer) ║ │ │ ║ ║ │ │ ║ すべてのフレームワーク出力は、TRUSTによる検証を通過すべき ║ │ │ ║ ║ │ │ ║ Evidence Pyramid (E1-E6) | Core Questions | 48-Hour Rule ║ │ │ ════════════════════════════════════════════════════════════════════════ │ │ │ │ LAYER 2: パターン層(Domain Patterns) │ │ TAT / DDM / etc. │ │ │ │ LAYER 3: 実装層(Implementation) │ │ サービス / プロダクト │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### なぜ「横断的検証層」なのか ``` 【問題】 AI時代において、すべてのフレームワーク出力は「AI汚染」のリスクを持つ。 ITFの問い → AIが「気持ちいい答え」を生成するリスク USMの構造 → AIが「美しいが浅い」構造を生成するリスク CEMの洞察 → AIが「磨かれただけ」の洞察を生成するリスク derivationの契約 → AIが「正しそうに見える」契約を生成するリスク AAFの設計 → AIが「論理的だが未検証」の設計を生成するリスク 【解決】 TRUSTを横断的検証層として位置づけ、すべての出力に適用する。 ITF出力 → TRUST検証 → 検証済みITF出力 USM出力 → TRUST検証 → 検証済みUSM出力 ... ``` ### ITF Q4 "Validation"との関係 ``` ITF v2.1の6つの問いの円環: Q1 Perspective → Q2 Development → Q3 Inquiry → Q4 Validation → Q5 Decision → Q6 Integration TRUSTは「Q4 Validation」の深い実装である。 しかし、Q4だけでなく、すべての問いの出力に適用可能。 【関係性】 Q4 Validation = 「十分に見えたか?」という問い TRUST = Q4の問いに答えるための具体的方法論 Q4が問いを立て、TRUSTが答えを検証する。 ``` --- ## § 2. 3つのパターン — Patterns to Transcend ### 概要 ``` これらは「敵」ではなく、「気づくべきパターン」。 気づけば、超えられる。 超え方: 含んで超える(Include & Transcend) パターンを否定するのではなく、認識し、より高い次元へ昇華する。 ``` ### Pattern 1: The Polishing Trap(磨き上げの罠) ``` 【定義】 AIが出力を美しく構造化することで、 深さがないまま「完成した」と錯覚させる。 【症状】 ・構造化されただけで「論理的」と感じる ・見栄えの良さに満足してしまう ・核心的な問いが欠落したまま進む 【検出】 Origin Question:「この核心は、AIに触れる前から自分の中にあったか?」 No → Polishing Trapの可能性 【超え方】 ・AIに触れる前に、自分の直感を言語化する ・AIの出力を「磨き」ではなく「素材」として扱う ・「何が欠けているか」を常に問う ``` ### Pattern 2: Sycophancy(サイコファンシー) ``` 【定義】 AIが「正しいこと」より「気持ちいいこと」を優先する。 ユーザーの期待に迎合し、批判的視点を提供しない。 【症状】 ・AIが常に肯定してくれる ・反論が出てこない ・自分の考えが強化されるだけ 【検出】 Resistance Question:「これは間違っている、と言われたらどう感じるか?」 防御的になる → Sycophancyの兆候 【超え方】 ・AIに「最も厳しい批判者」の視点を求める ・自分の仮説に対する反証を積極的に探す ・「気持ちいい答え」を疑う習慣 ``` ### Pattern 3: Cognitive Comfort Trap(認知的快適性の罠) ``` 【定義】 AIが思考の「苦しい部分」を代替することで、 批判的思考の機会が減少する。 【症状】 ・「AIが言ったから」が理由になる ・自分で考える前にAIに聞く ・不確実性への耐性が低下する 【検出】 Execution Question:「明日、最小単位で始められるか?」 No → 観念的・抽象的すぎる(AIが思考を代替した可能性) 【超え方】 ・AIの出力を「出発点」として使い、自分で深める ・最終判断は必ず自分で行う ・48時間ルールで興奮を冷ます ``` --- ## § 3. TRUST Core Questions — 3つの問い ### 概要 ``` 3つの問いで本質を見抜く。 これらは順番に問うことも、状況に応じて単独で使うこともできる。 ``` ### Origin Question(起源の問い) ``` 「この核心は、AIに触れる前から自分の中にあったか?」 【Yes → 健全】 自分の直感が起点。AIは磨きに使われている。 【No → 要注意】 AIが生成した可能性。Polishing Trapの兆候。 → 自分の中の「種」を見つけ直す 【Unsure → 探求】 自分の考えの起源を振り返る。 → 何が自分のもので、何がAIのものかを分離する 【適用例】 新規事業アイデア → このアイデアの核は、AIに聞く前から考えていたか? キャリア決断 → この方向性は、自分の価値観から来ているか? 技術選定 → この選択の根拠は、自分の経験に基づいているか? ``` ### Resistance Question(抵抗の問い) ``` 「これは間違っている、と言われたらどう感じるか?」 【冷静に検討できる → 健全】 確証バイアスが少ない。批判を受け入れる準備がある。 【防御的になる → 要注意】 Sycophancyの兆候。AIに肯定されすぎている可能性。 → 最も厳しい批判者に意見を求める 【Unsure → 探求】 信頼できる人に批判的なフィードバックを求める。 → 自分の反応を観察する 【適用例】 戦略提案 → この戦略を否定されたら、どう感じるか? 設計判断 → この設計が間違っていると言われたら? 投資判断 → この判断を批判されたら、冷静でいられるか? ``` ### Execution Question(実行の問い) ``` 「明日、最小単位で始められるか?」 【Yes → 健全】 地に足がついている。具体的な実行可能性がある。 【No → 要注意】 観念的・抽象的すぎる。Cognitive Comfort Trapの兆候。 → 最小の実行単位を定義する 【Unsure → 探求】 具体的な最初の一歩を考える。 → 何が障壁になっているかを特定する 【適用例】 プロジェクト計画 → 明日の朝、最初に何をする? 学習目標 → 今日15分でできる最小のステップは? 習慣形成 → 今すぐ始められる最小の行動は? ``` --- ## § 4. Evidence Pyramid (E1-E6) — エビデンス・ピラミッド ### 概要 ``` 【重要】 Evidence Pyramid (E1-E6) は「情報の検証レベル」を示す。 MIRROR Evolution Map (L1-L5.5) の「AI協働成熟度」とは別概念。 E1-E6は医学研究のエビデンス階層を拡張し、 AI時代の新しいカテゴリ(E6)を追加したもの。 ``` ### 6つのレベル ``` ┌─────────────────────────────────────────────────────────────────┐ │ E1: 複数環境で再現・実証 │ │ ≒ メタアナリシス、システマティックレビュー、複数市場A/Bテスト│ │ 信頼度: ★★★★★ │ ├─────────────────────────────────────────────────────────────────┤ │ E2: 自己/自社環境で実証 │ │ ≒ 単独RCT、自社A/Bテスト、パイロット結果 │ │ 信頼度: ★★★★☆ │ ├─────────────────────────────────────────────────────────────────┤ │ E3: 類似事例・他者経験 │ │ ≒ ケーススタディ、リファレンス顧客、ベストプラクティス │ │ 信頼度: ★★★☆☆ │ ├─────────────────────────────────────────────────────────────────┤ │ E4: 理論的妥当性 │ │ ≒ デザインパターン、戦略フレームワーク、論理的一貫性 │ │ 信頼度: ★★☆☆☆ │ ├─────────────────────────────────────────────────────────────────┤ │ E5: 経験・直感・専門家意見 │ │ ≒ コンサル助言、シニア判断、暗黙知 │ │ 信頼度: ★☆☆☆☆ │ ├─────────────────────────────────────────────────────────────────┤ │ E6: AI出力(未検証)← TRUST独自 │ │ ≒ 該当なし(新カテゴリ) │ │ 信頼度: ☆☆☆☆☆ ← スタート地点 │ └─────────────────────────────────────────────────────────────────┘ ``` ### E6の特別な位置づけ ``` 【なぜE6が必要か】 従来の医学研究階層には「AI出力」というカテゴリがなかった。 しかし、AI時代において、多くの情報は「AI出力(未検証)」から始まる。 E6は: ・検証のスタート地点 ・そのままでは意思決定に使用すべきでない ・検証を通じてE5→E4→...と上昇させる必要がある 【E6からの上昇パス】 E6 → E5: 専門家がレビューし、妥当性を確認 E5 → E4: 理論的フレームワークと整合性を確認 E4 → E3: 類似事例を収集し、パターンを確認 E3 → E2: 自社環境でパイロットを実施 E2 → E1: 複数環境で再現性を確認 ``` ### ギャップ計算 ``` 【認識レベルと実態レベルのギャップ】 自分が認識しているレベル(Perceived Level)と 実際のエビデンスレベル(Actual Level)の差を計算する。 Gap = Perceived Level - Actual Level Gap 0-1: 適切な認識 Gap 2-3: 軽度の過大評価 → 注意 Gap 4+: 重度の過大評価 → 48時間ルール推奨 【例】 「この戦略は確実だ」(Perceived: E2) 実際: AIが提案したままで検証なし(Actual: E6) Gap = 2 - 6 = -4 → 重度の過大評価 → 48時間ルールを適用し、再評価する ``` --- ## § 4b. 検証モード(Verification Modes) ### 概要 ``` すべての判断に同じ検証を適用するのは非現実的であり、 過度な懐疑は行動を麻痺させる(§9 警告2)。 検証モードは、リスクに応じた段階的検証を構造化する。 「使う/使わない」の二値ではなく、4段階のグラデーション。 ``` ### 4つのモード ``` ┌─────────────────────────────────────────────────────────────────┐ │ Mode │ Trigger │ Actions │ ├──────────────┼───────────────────────┼──────────────────────────┤ │ Light │ 日常判断 │ Origin Questionのみ │ │ │ 可逆的な決定 │ │ ├──────────────┼───────────────────────┼──────────────────────────┤ │ Standard │ 通常の業務判断 │ Core Questions 3問 │ │ │ │ + E1-E6判定 │ ├──────────────┼───────────────────────┼──────────────────────────┤ │ Full │ 不可逆的・高コストの │ Standard │ │ │ 決定 │ + 48時間ルール │ │ │ │ + 文脈分離(§5b) │ ├──────────────┼───────────────────────┼──────────────────────────┤ │ Cross │ 戦略的決定 │ Full │ │ │ 組織方向性 │ + 異なる立場からの再検証 │ └──────────────┴───────────────────────┴──────────────────────────┘ ``` ### モード選択の判断基準 ``` 【3つの問いで決める】 1. この決定は可逆か? 可逆 → Light or Standard 不可逆 → Full or Cross 2. 影響範囲はどこまでか? 自分のみ → Light チーム → Standard 組織全体 → Full or Cross 3. 投資規模はどの程度か? 小(時間 < 1日) → Light 中(時間 1日-1週間、費用あり) → Standard 大(時間 1週間+、大きな費用) → Full 戦略的(方向性を決める) → Cross ``` ### モード選択の例 ``` 【Light】 - Slackの返信文面 - 日常のコード変更 - ドキュメントの軽微修正 【Standard】 - 新機能の設計判断 - 技術スタックの選定 - 採用基準の設定 【Full】 - 事業戦略の決定 - 大規模リファクタリング - チーム構造の変更 【Cross】 - 事業撤退/参入の判断 - 組織理念の改定 - 長期投資(3年+)の方向性 ``` --- ## § 5. 48時間ルール ### 概要 ``` 重要な意思決定は、48時間寝かせてから判断する。 興奮が冷めた後も重要なら、それは本物。 【原理】 ・興奮状態での判断はバイアスがかかりやすい ・時間が経つと、本質的でないものは色褪せる ・「本物」は48時間後も輝き続ける 【適用条件】 ・エビデンスレベルがE5-E6の場合 ・ギャップが4以上の場合 ・興奮や強い感情を伴う場合 ・取り消し不能な決定の場合 ``` ### 実践手順 ``` 【Day 0: 意思決定案を作成】 ・「これが正解だ」と感じる ・興奮している自分を認識する ・判断を文書化する(後で見返すため) 【Day 0-2: 寝かせる】 ・意識的に考えないようにする ・別のことに取り組む ・無意識に処理させる 【Day 2: 見返す】 ・文書化した判断を読み返す ・まだ重要か?興奮は冷めたか? ・新しい視点が生まれたか? 【判断】 ・Yes: 実行に移す ・No: 再検討 or 破棄 ・Unsure: さらに48時間、または他者に相談 ``` --- ## § 5b. 文脈分離(Context Separation) ### 概要 ``` 48時間ルールは「時間分離」——時間を置いて再評価する。 文脈分離は「空間分離」——文脈を変えて再評価する。 時間を置いても、同じ文脈(同じ場所、同じ役割、同じ相手)で 考え直すと、同じ結論に至りやすい。 文脈を変えることで初めて見えるバイアスがある。 ``` ### 3つの分離軸 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 軸 │ 方法 │ 検出するバイアス │ ├──────────────┼─────────────────────────┼─────────────────────────┤ │ 場所分離 │ 物理的に異なる場所で │ 環境依存バイアス │ │ │ 再評価する │ (オフィス vs 自宅 │ │ │ │ で判断が変わるか) │ ├──────────────┼─────────────────────────┼─────────────────────────┤ │ 役割分離 │ 異なる立場から │ 役割固着バイアス │ │ │ 再評価する │ (開発者 vs ユーザー │ │ │ │ で判断が変わるか) │ ├──────────────┼─────────────────────────┼─────────────────────────┤ │ 相手分離 │ 異なる相手に │ 社会的バイアス │ │ │ 説明してみる │ (上司 vs 同僚 vs 部下 │ │ │ │ で説明が変わるか) │ └──────────────┴─────────────────────────┴─────────────────────────┘ ``` ### 実践手順 ``` 【Step 1: 判断を記録する】 ・現在の文脈(場所、役割、相手)を明示する ・その文脈での判断を記録する 【Step 2: 文脈を1つ変える】 ・場所、役割、相手のうち1つを変える ・新しい文脈で同じ問いを再評価する ・判断が変わるかどうかを記録する 【Step 3: 差分を分析する】 ・判断が変わらない → 文脈非依存(堅牢な判断) ・判断が変わる → 文脈依存(バイアスの可能性) → どの文脈が「より正確」かを検討する ``` ### 48時間ルールとの組み合わせ ``` Full/Crossモードでは、時間分離と文脈分離を併用する。 Day 0: 判断を記録(文脈も記録) Day 1: 文脈分離を実施(場所 or 役割 or 相手を変える) Day 2: 時間分離後に再評価(48時間ルール) 時間分離だけ → 同じ文脈のまま冷静になるだけ 文脈分離だけ → 興奮したまま別角度で見るだけ 両方 → 冷静に、かつ別角度から見る ``` --- ## § 6. 各フレームワークへの適用 ### ITF × TRUST ``` 【適用ポイント】 ITFの各問いの出力に、TRUSTを適用する。 Q1 Perspective出力 → Origin Question 「この視点は、AIに触れる前から持っていたか?」 Q2 Development出力 → Execution Question 「この方向性で、明日から始められるか?」 Q3 Inquiry出力 → Evidence Pyramid 「この深掘りの結果、エビデンスレベルはいくつか?」 Q4 Validation出力 → Core Questions全体 「この検証は十分か?」(TRUST自体がQ4の実装) Q5 Decision出力 → 48時間ルール 「この決定は、48時間後も有効か?」 Q6 Integration出力 → Resistance Question 「この統合に批判されたら、どう感じるか?」 ``` ### USM × TRUST ``` 【適用ポイント】 USMで構造化した結果に、TRUSTを適用する。 軸の発見 → Origin Question 「この軸は、AIに提案される前から見えていたか?」 構造化の結果 → Evidence Pyramid 「この構造は、E何レベルか?」 普遍的言葉 → Resistance Question 「この言葉選びを批判されたら?」 ``` ### CEM × TRUST ``` 【適用ポイント】 CEMの協働的創発の結果に、TRUSTを適用する。 4象限の移動 → Origin Question 「この移動は、自分の直感が起点か?」 螺旋的上昇 → Evidence Pyramid 「この上昇は実証されているか?」 協働の成果 → Core Questions 「この成果は本物か?磨かれただけか?」 ``` ### derivation × TRUST ``` 【適用ポイント】 derivationの契約と導出に、TRUSTを適用する。 契約定義 → Origin Question 「この契約の本質は、自分が定義したか?」 導出結果 → Evidence Pyramid 「この導出は、E何レベルで検証されたか?」 完成物 → Execution Question 「この完成物で、明日から運用できるか?」 ``` ### AAF × TRUST ``` 【適用ポイント】 AAFの採用設計に、TRUSTを適用する。 摩擦除去 → Evidence Pyramid 「この摩擦分析は、E何レベルか?」 統合設計 → Resistance Question 「この設計を批判されたら?」 価値循環 → 48時間ルール 「この設計は、48時間後も有効か?」 ``` --- ## § 7. ペルソナ別エントリーポイント ### Creative(創造者) ``` 【痛み】 「AIが磨いたアイデア、本当に私のもの?」 「深みがないまま完成した気になってしまう」 【TRUSTの価値】 ・Origin Questionで「起源」を確認 ・Polishing Trapに気づく ・自分の直感を守りながらAIを活用 【ジャーニー】 1. Origin Question → 自分のアイデアの核を特定 2. Evidence Pyramid → 現在の検証レベルを認識 3. 48時間ルール → 興奮を冷まし、本質を見極める ``` ### Strategy(戦略家) ``` 【痛み】 「AIが提案した戦略、どこまで信頼できる?」 「論理的に見えるが、検証されていない」 【TRUSTの価値】 ・Evidence Pyramid(E1-E6)で検証レベルを可視化 ・ギャップ計算で過大評価を検出 ・48時間ルールで重要決定を保護 【ジャーニー】 1. Evidence Pyramid → 戦略のE1-E6レベルを判定 2. ギャップ計算 → 認識と実態のズレを検出 3. Resistance Question → 批判への耐性を確認 ``` ### Technology(技術者) ``` 【痛み】 「AIが書いたコード、本当に正しい設計?」 「動くけど、ベストプラクティスか分からない」 【TRUSTの価値】 ・Execution Questionで実装可能性を確認 ・Evidence Pyramidで技術選定を検証 ・Core Questionsで設計判断を検証 【ジャーニー】 1. Execution Question → 明日から実装できるか 2. Evidence Pyramid → 技術選定の根拠レベル 3. Origin Question → この設計は自分の経験に基づくか ``` --- ## § 8. 統合使用パターン ### パターンA: AI協働セッション後の検証 ``` 【状況】 AIと長時間対話し、アイデアや計画がまとまった。 「これでいこう」と思っている。 【TRUST適用】 1. Origin Question → 最初の発想は自分から出たか? → AIが方向性を変えたポイントはどこか? 2. Evidence Pyramid → この計画はE何レベルか? → E6のまま進もうとしていないか? 3. 48時間ルール → 重要決定なら48時間寝かせる → 興奮が冷めても重要か? 【出力】 ・検証済みの計画、または ・「まだE6、検証が必要」という認識 ``` ### パターンB: 戦略的意思決定の検証 ``` 【状況】 新規事業、大型投資、組織変更など、 取り消し困難な決定を行おうとしている。 【TRUST適用】 1. Evidence Pyramid → 各根拠のエビデンスレベルを判定 → E5-E6が多い場合は検証を追加 2. Resistance Question → この決定を否定されたら、どう感じるか? → 防御的になるなら、確証バイアスの可能性 3. 48時間ルール → 必ず適用 → ステークホルダーにも共有 【出力】 ・エビデンスレベル付きの意思決定文書 ・48時間後の再評価結果 ``` ### パターンC: フレームワーク出力の品質保証 ``` 【状況】 ITF/USM/CEM/derivation/AAFを使って成果物を作成した。 品質を確認したい。 【TRUST適用】 1. Origin Question → フレームワークの入力は自分のものか? → AIに誘導されていないか? 2. Evidence Pyramid → 成果物のエビデンスレベルは? → 検証が必要な箇所はどこか? 3. Execution Question → この成果物で、明日から行動できるか? → 抽象的すぎないか? 【出力】 ・検証済みの成果物、または ・「追加検証が必要」という認識と具体的アクション ``` --- ## § 9. 三つの警告 ### 警告1: TRUST自体のサイコファンシー ``` 【リスク】 TRUSTを使うこと自体が「検証した気分」を与え、 実際の検証を怠る可能性がある。 【対策】 ・TRUSTは「問い」を立てるツール ・問いに「答える」のは別のプロセス ・「TRUSTを使ったから安心」とは思わない ``` ### 警告2: 過度な懐疑 ``` 【リスク】 すべてを疑いすぎて、行動が遅れる可能性がある。 「完璧な検証」を求めて、永遠に決定できない。 【対策】 ・E1-E2を求めるのは重要決定のみ ・日常的な判断はE3-E4で十分な場合も ・「十分な検証」の基準を状況に応じて設定 ``` ### 警告3: 形式的適用 ``` 【リスク】 TRUSTを形式的に適用し、本質的な検証を行わない。 チェックリストを埋めるだけの作業になる。 【対策】 ・各問いに「本気で」答える ・不快な答えこそ重要 ・「気づき」を目的とし、「通過」を目的としない ``` --- ## § 10. Quick Reference ### 30秒で使う ``` ┌─────────────────────────────────────────────────────────────────┐ │ TRUST Quick │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 【モード選択】 │ │ │ │ Light: 日常判断 → Origin Questionのみ │ │ Standard: 業務判断 → 3問 + E1-E6 │ │ Full: 重要決定 → Standard + 48h + 文脈分離 │ │ Cross: 戦略的決定 → Full + 異なる立場から再検証 │ │ │ │ 【3つの問い】 │ │ │ │ 1. Origin: AIに触れる前から、自分の中にあったか? │ │ 2. Resistance: 批判されたら、どう感じるか? │ │ 3. Execution: 明日、最小単位で始められるか? │ │ │ │ 【E1-E6】 │ │ │ │ E1 複数環境で実証 | E2 自社環境で実証 | E3 類似事例 │ │ E4 理論的妥当性 | E5 経験・直感 | E6 AI出力(未検証) │ │ │ │ 【48時間ルール + 文脈分離】 │ │ │ │ 重要決定 → 48時間寝かせる(時間分離) │ │ → 場所/役割/相手を変えて再評価(文脈分離) │ │ → まだ重要なら実行 │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` ### 診断フロー ``` 1. 今、判断しようとしていることは何か? → 明確に言語化する 2. モード選択(§4b) → 可逆性・影響範囲・投資規模で判断 → Light / Standard / Full / Cross 3. Origin Question → Yes: 次へ / No: 起源を探る 4. Resistance Question(Standard以上) → 冷静: 次へ / 防御的: 批判者を探す 5. Execution Question(Standard以上) → Yes: 次へ / No: 最小単位を定義 6. Evidence Pyramid(Standard以上) → E1-E4: 進める / E5-E6: 48時間ルール 7. 48時間ルール + 文脈分離(Full以上) → 時間分離: 寝かせて再評価 → 文脈分離: 場所/役割/相手を変えて再評価 8. 異なる立場からの再検証(Crossのみ) → 利害関係者、批判者、新参者の視点 ``` --- ## § 11. 参照 ### 内部参照 ``` Integrated/ ├── ITF_v2_1.md # Q4 Validationの親フレームワーク ├── USM_v1.md # 構造化の方法論 ├── CEM_v1.md # 協働的創発 ├── AAF_v1.md # 採用設計 └── Framework_Integration_Map.md # 全体統合マップ ``` ### 実装 ``` work/trust/ # TRUSTプロダクト ├── CLAUDE.md # TRUST Agent定義 ├── docs/TRUST_v1_Design.md # 設計ドキュメント └── src/app/ # Webアプリケーション ├── page.tsx # ホーム ├── card/ # 30秒カード ├── quick-reference/ # クイックリファレンス └── diagnostic/ # 診断ツール URL: trust.seehub.org ``` ### 外部参照 ``` ・医学研究のエビデンス階層(Evidence-Based Medicine) ・認知バイアス研究 ・AI Safety / AI Alignment研究 ・行動経済学(48時間ルールの根拠) ``` --- **Document Information** ```yaml Title: TRUST v1.1 Subtitle: AI時代の認知的検証フレームワーク Version: 1.1 Created: 2025-12-29 Updated: 2026-02-28 Status: Active & Evolving 位置づけ: 横断的検証層(Verification Layer) 親フレームワーク: ITF v2.1 Q4 Validation 実装: trust.seehub.org 変更履歴: v1.1 (2026-02-28): 検証モード・文脈分離の追加 - §4b 検証モード(Light/Standard/Full/Cross): リスクに応じた段階的検証 - §5b 文脈分離(Context Separation): 48時間ルールの補完 - §10 Quick Reference更新: モード選択・文脈分離を追加 - 動機: 検証の二値性(使う/使わない)とバイアス低減の時間軸偏重を解消 v1.0 (2025-12-29): 初版作成 - 横断的検証層としての位置づけを確立 - E1-E6 Evidence Pyramidを定義 - 各フレームワークへの適用方法を明示 ``` --- _AIはすべてを美しく見せる_ _TRUSTは本物を見抜く力を与える_ _気づき、含んで、超える_ _Notice, include, and transcend_ _これがTRUSTである_ 🔍