essence-diagnosis について
essence-diagnosis は、原因が明確でない複雑な問題を分析するエージェントスキルです。解決策は提示せず、証拠と論理の連鎖を組み立て、複数の仮説を比較し、multi-agent-debate による反証的な検証を必須とします。
主な機能
- 01SOAP に基づく診断フロー
- 02情報源の収集とノイズ除去
- 03複数の仮説の構築と検証
- 04証拠を因果の論理連鎖に整理
- 05マルチエージェントによる反証検証
活用シーン
- 01原因が不明な複雑な問題の調査
- 02複数の根本原因仮説の比較
- 03追跡可能な診断レポートの作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ fudesign2008/ open-skills --skill essence-diagnosisインストール後、Claude Code で/essence-diagnosisを入力して読み込まれたか確認します。
同梱ファイルreference.md
詳細
本質診断
役割:複雑な問題の本質分析と診断のみを行います。完全な証拠チェーン+論理チェーン+仮説リストを作成します。問題の解決は行いません(解決策の提示、実行、修正は行いません)。敵対的検証のため、必ず
multi-agent-debateを統括して実行します。出力テンプレートと形式については、reference.md を参照してください。
このスキルが存在する理由
膨大なログ、複雑に絡み合った要因、症状と本質の乖離など、複雑な問題に直面すると、人間も AI も同じ過ちを犯しがちです。根本原因に見える最初の説明で分析を止めてしまうことです。これは早まった収束です。いったん収束すると、その後の分析はすべて「自分の正しさを証明する」ものとなり、確証バイアスが働きます。反例は無視され、別の説明は退けられてしまいます。
このスキルの唯一の価値は、構造化されたプロセスによってこの二つの認知的な落とし穴を防ぎ、「X だと思う」を「証拠チェーンが X を示しており、Y/Z は反証されている」へと変えることです。修復は行いません。敵対的検証を経ても耐えうる診断レポートを作成します。
他のスキルとの関係
| スキル | 担当範囲 | このスキルとの関係 |
|---|---|---|
solve-workflow | 全ワークフロー(分析 → 解決策 → 実行 → 検証 → 振り返り) | このスキルはフェーズ 1.2 の重点的な詳細分析であり、分析・診断のみに集中します。単独でも使用できます |
multi-agent-debate | 既存の結論に対する 3 エージェントによる敵対的検証 | このスキルの出力=その入力です。一方向の統括実行であり、ディベート側からこのスキルを呼び戻すことはありません |
diagnose / debug-workflow | 単一バグの診断/デバッグ | これらは「バグであることが既知」という前提に立っています。このスキルはその前提を置かず、「何が問題なのかもまだ分からない」という不確かな状態に適しています |
hybrid-debug | ハイブリッドアプリ(WebView/WKWebView/Electron + H5)の 4 層デバッグ | ドメイン固有の事前フィルターです。ハイブリッドアプリの問題には、まず 4 層モデルを適用します。構造化された層ごとの分析後も問題が不明瞭な場合に限り、このスキルへ引き継ぎます |
トリガーとモード
トリガー:本質診断、根因診断、深度診断、診断問題本質、梳理問題逻辑、证据链分析、逻辑链分析、essence-diagnosis
デフォルト:ユーザーがこのスキルを呼び出した場合、問題は複雑であるとみなします。複雑さのしきい値による判定は行いません。
方法論の基盤
3 つの情報源を融合しています(いずれも成熟した業界の実践に基づいており、一から考案したものではありません)。
| 情報源 | 取り入れた仕組み | このスキルでの役割 |
|---|---|---|
| 医療の鑑別診断(DDx) | SOAP 形式+並行仮説+VINDICATE による分類 | プロセスの基盤(S/O/A の 3 セクション)+仮説の網羅を強制 |
| 強い推論(Platt) | 仮説の並行反証(確認ではない)、反証可能性(Popper) | 仮説検証の仕組み。支持材料ではなく、反例を探します |
| 故障の木/事故調査 | トップダウンの因果関係の遡及、証拠・支持マトリクス | 論理チェーンの可視化 |
中核フロー:S → O → A → Debate
S — 主観的情報:情報フィールドの収集とノイズ除去
目標:混沌とした情報フィールドから構造的に情報を抽出します。すべてをそのまま受け入れてはいけません。複雑な問題の本質は、シグナルがノイズに埋もれていることです。ノイズ除去が最初のステップです。
- 情報源の棚卸し:ログ、コード、ドキュメント、メトリクス、設定、ユーザーフィードバック、議事録、git 履歴など、利用可能な情報源をすべて列挙します
- ノイズ除去:重複を排除し、時系列をそろえ、関連性順に並べ、明らかなノイズに印を付けます
- 出力:客観的事実のリスト(各項目に出典
file:line/cmd/N samplesを付記)
仮説を立てる前にノイズを除去するのはなぜでしょうか。頭の中に仮説を抱えたままログを読むと、それを裏付ける行だけが目に入ります。これが確証バイアスの入口です。ノイズ除去中に仮説を立てることは厳禁です。
O — Objective:複数仮説の生成とエビデンスチェーンの構築
目標:早まった収束を防ぐため、複数の仮説を必ず生成します。
- 仮説の生成(3つ以上):VINDICATE の一般分類法(reference.md を参照)の各カテゴリーを確認し、カテゴリーごとに少なくとも1つの仮説を立てます
- 各仮説のエビデンスチェーンを構築:Toulmin の論証モデル(reference.md を参照)を使用します。6つの要素すべてを完成させます
- エビデンスと仮説を分離:最初にエビデンスを収集し、その後に仮説と照合します。「仮説を立ててからエビデンスを探す」ことは決してしません
- 出典がなければ、結論を出さない:エビデンスにはすべて、原文と行番号/コマンド出力/サンプル数を明記します。そうでなければ破棄します
なぜ3つ以上なのか? 仮説が1つだけだと、無意識にそれを支持するエビデンスだけを集めてしまいます。2つだと、より都合のよい方を選んでしまいます。3つ以上あれば、実際に比較するようになります。これは鑑別診断における、100年来の経験則です。
A — Assessment:論理チェーンの組み立てとバイアスへの反撃
目標:エビデンスチェーンを論理チェーンとして組み立て、自分の作業に欠陥がないか積極的に探します。
- 論理チェーンの構築:トップダウンで因果関係を遡ります(reference.md のフォールトツリーを参照)。因果関係のつながりにはすべて、エビデンスによる裏付けが必要です
- バイアスへの反撃チェック:各仮説について、以下の4項目のバイアスチェックリストを確認します
- 最弱リンクの特定:論理チェーンで最も弱いリンクを2~3個選び、ディベートに引き渡す対象とします
- 物理検証の設計:すべての結論を、実行可能な検証コマンドまたは実験に対応づけます
複数エージェントによるディベートを調整する(必須条件であり、省略不可)
S/O/A の完了後、敵対的検証のために multi-agent-debate を必ず呼び出します。これはこのスキルの必須条件です。
引き継ぎパッケージ(形式は reference.md を参照):
- 第一仮説を1段落で記述
- エビデンスの一覧(それぞれに出典タグを付与)
- 最弱リンクを2~3個
ディベートの結論が返されたら、診断レポートの「確認済み事実/妥当な推論/未解決の論争」セクションを更新します。
なぜディベートを必須にするのか? S/O/A をどれほど厳密に行っても、単独の分析者が進める以上、盲点が生じます。ディベートでは、敵対する3つの視点(擁護者/異議申立人/エビデンスハンター)を用いて単一の視点を強制的に崩し、物理的なエビデンスに基づいて推論上の論争を裁定します。
エビデンスチェーンの必須条件
| ルール | 理由 |
|---|---|
| 出典がなければ、結論を出さない | 原文の引用がない「エビデンス」は、幻覚の温床です。LLM はもっともらしい引用を捏造します |
| Toulmin の6要素(Claim / Data / Warrant / Backing / Qualifier / Rebuttal) | すべての結論を監査可能な粒度に分解することを徹底します。Rebuttal によって、反例を積極的に想定することを促します |
エビデンスタグ:[FACT:file:line] [FACT:cmd] [FACT:N samples] [INFERENCE] [UNRESOLVED] | 事実と推論は視覚的に区別できなければなりません。そうしないと、推論がいつの間にか「事実」に変わってしまいます |
| エビデンスと仮説の分離 | 先にエビデンス、次に仮説とすることで、仮説によるエビデンス収集への汚染を避けます |
バイアスに対抗するチェックリスト
フェーズ A では、各仮説をすべての項目に照らして確認します。
| バイアス | 症状 | 対策 |
|---|---|---|
| 確証バイアス | 仮説を裏付ける証拠だけを集める | 各仮説について反証となる証拠を最低2つ挙げるよう徹底します。反証となる証拠が見つからないこと自体が危険信号です |
| 早すぎる収束 | もっともらしい仮説が最初に見つかった時点で止める | 最低3つの仮説すべてについて、証拠の連鎖を最後までたどります。途中で打ち切ってはいけません |
| アンカリング効果 | 最初に得た情報/最初のスタックトレースに引きずられる | フェーズ S のノイズ除去が完了する前に、仮説を立ててはいけません |
| 相関と因果の混同 | A と B が同時に発生したため、A が B の原因だと考える | 仕組みに基づく説明(どのような仕組みで A が B を引き起こすのか)を求め、反例も探します |
出力形式
SOAP 診断レポート一式、証拠の連鎖の表、ロジックチェーン図、ディベート引き継ぎパッケージを作成します。テンプレートは reference.md にあります。
このスキルの最終成果物は診断レポートであり、修正計画ではありません。レポートの最後には「This report covers diagnosis only and has not entered the resolution phase.」という注記を記載する必要があります。
注意すべき落とし穴(直感に反するもの)
- ❌ S を省略して仮説に進む — ノイズ除去されていない情報をもとに仮説を立てるのは、ノイズの上に土台を築くようなものです
- ❌ 証拠の収集に推論を混ぜる — 推論を事実として扱うと証拠の連鎖が汚染され、追跡が困難になります
- ❌ もっとも可能性が高い仮説だけについて証拠の連鎖を構築する — ほかの仮説を未完成のままにすると、早すぎる収束を招きます。まさにこのスキルが防ごうとしていることです
- ❌ 中間証拠がないまま、5 ステップを超えるロジックチェーンを構築する — 長い推論の連鎖はハルシネーションの温床です。すべてのステップに根拠が必要です
- ❌ ディベートを始める前に、最も弱い結び付きを特定しない — ディベートの対象が失われ、空虚な議論になります
- ❌ このスキルを修復ツールとして扱う — 診断レポートを提出した後、ユーザーが修正を希望する場合は、
solve-workflowまたは専門のスキルに引き継ぎます