SourceTrace
SourceTrace は、AI が生成した知識ツリーを、その元となったソース画像と照合し、すべての問題を追跡可能な証拠とともに説明します。ユーザーは指摘を鵜のみにする必要はありません。各指摘は、なぜ問題なのか、ソースのどこにあるのか（ページと引用）、何に基づいているのか（証拠ID）を明示します。
通常のモデルでもエラーを見つけることはできます。SourceTrace が追加する価値は、結果が検証可能であることです。すべてのノードとエッジに判定が下され、各判定は証拠を引用し、カテゴリとリスクレベルは固定され、出力は毎回同じ構造になります。
入力
- ソース画像: PNG/JPG、1ページにつき1枚の画像（例：スライドを画像としてエクスポートしたもの）。これらが唯一の真実のソースです。ユーザーがPPTやPDFを持っている場合は、最初に画像にエクスポートするよう依頼してください。
- 知識ツリー:
schemas/knowledge-tree.schema.jsonに従った JSON（id、label、definition、kindを持つノード、id、source、target、relationを持つエッジ）。ツリーが別の形式や他のリレーション名を使用している場合は、最初に変換し、何をマッピングしたかをユーザーに伝えてください。
以下の scripts/…、schemas/…、references/… などのパスは、このスキルのフォルダを基準としています。
出力
すべてのファイルを1つの出力フォルダ（デフォルトでは知識ツリーの隣にある sourcetrace-output/）に書き込みます。
| ファイル | 段階 | 内容 |
|---|---|---|
evidence-index.json | 2 | 画像から抽出されたすべての証拠（あなたが作成） |
audit.json | 4–6 | すべてのノードとエッジの判定、および欠落（あなたが判断を記述、スクリプトが完成させる） |
report.md | 6 | 人間が読めるレポート（scripts/build_report.py により生成、自分で作成しないこと） |
ユーザーの知識ツリーを決して変更しないでください。SourceTrace は報告と推奨を行います。決定するのはユーザーです。
ワークフロー
6つの段階を順番に実行します。証拠インデックスが存在する前にツリーの判断に進まないでください。スライドの印象ではなくインデックスに対して監査することが、発見事項を追跡可能にするのです。
1. ソースの取り込み
python scripts/validate_input.py --tree <knowledge-tree.json> --images <image folder or files> --json
- エラー（
"valid": false）：停止し、エラーを平易な言葉でユーザーに表示し、入力を修正するよう依頼してください。無効なツリーを監査しないでください。 - 警告（例：
DISCONNECTED_TREE、ISOLATED_NODE、DUPLICATE_EDGE）：続行します。build_report.pyがレポートの「構造」セクションにそれらを配置します。 summary.imagesは各画像にsource_idとpageを提供します。段階2ではこれらを正確に使用してください。
次に、すべての画像を確認し、タイトル、テキスト、表、図を記録します。
2. 証拠の抽出
references/evidence-extraction.md に従って evidence-index.json を作成します。抽出前にそのファイルを読んでください。要約は次のとおりです。
- スライドのタイトル、箇条書き、表の行、図の関係ごとに1項目。
- テキストを元の言語でそのまま引用します。小さな言い回しの変更こそが、監査で見つけなければならないものです。
- 宿題や読書ノートも含め、すべてを抽出します。
certaintyは正直に設定します。lowの証拠だけではツリーの項目を却下できません。
次に検証し、続行する前にすべてのエラーを修正します。
python scripts/validate_evidence.py --index <output>/evidence-index.json
3. 知識マッピング
ツリーを検証すべき主張の集合として扱い、決して事実として扱わないでください。次のように分割します。
- ノード: ラベルと定義は正しいか？
- エッジ: 2つのノード間の関係は正しいか？エッジは
source relation targetとして読みます。
これらを個別に監査します。ノードが正しくても、それを使用するエッジが間違っている場合があり（またその逆もあり）、それぞれが独自の判定を受けます。
各ノードとエッジについて、それに関連する証拠項目をリストアップします。予想されるページだけでなく、インデックス全体を検索してください。ある主張は、2つのページを組み合わせることで初めて確認または反証される場合があります。
4. 双方向監査
- ツリー→ソース: すべてのノードとエッジについて、証拠がそれを支持するかどうかを判断します。正しいものも含め、すべてのノードとエッジに判定を下します。正しいものを確認することも結果の一部です。
- ソース→ツリー: 証拠インデックスを調べ、どのノードやエッジもカバーしていない重要なコンテンツを見つけます。
判定、重要とみなす基準、およびエッジケースについては references/audit-rules.md に従ってください。
5. 競合検出
すべての問題を正確に1つのカテゴリに分類し、リスクレベルを割り当てます。references/audit-rules.md の決定順序を使用してください。その質問を順番にたどり、最初の「はい」で停止します。発見事項の印象でカテゴリを選ばないでください。その順序が2回の実行で一貫性を保証します。
| カテゴリ | 意味 |
|---|---|
conceptual-error | ノードの定義がソースと矛盾する。 |
incorrect-relationship | エッジがソースと矛盾する（両方のノードが正しくても）。 |
unsupported-expansion | ソースにないコンテンツ（一般的に真実でも）。 |
overgeneralization | サポートされているコンテンツがソースの記述を超えて拡張されている。 |
ambiguous | 確認または却下するには曖昧すぎる、または確実性が低すぎる。 |
omission | ソースの重要なコンテンツがツリーから欠落している。 |
6. 監査レポート
あなたの判断を audit.json に書き込み、スクリプトにチェックとレポート生成を任せます。あなたが判断し、スクリプトがカウント、番号付け、並べ替え、フォーマットを行います。この分割により、2回の実行で同じレポートが生成されます。
audit.json（v0.1、スキーマ schemas/audit.schema.json）は次のように記述します。
{
"schema_version": "0.1",
"items": [
{ "target": "N001", "verdict": "supported", "evidence": ["EV-002"] },
{ "target": "N002", "verdict": "finding", "evidence": ["EV-008"],
"category": "conceptual-error", "risk": "high",
"reason": "...", "recommendation": "..." }
],
"omissions": [
{ "category": "omission", "tier": "core", "risk": "medium", "evidence": ["EV-016"],
"reason": "...", "recommendation": "..." },
{ "category": "omission", "tier": "core", "risk": "high", "risk_reason": "講義の中心的概念",
"evidence": ["EV-003"], "reason": "...", "recommendation": "..." }
]
}
items: ツリーのノードとエッジごとに、正確に1つのエントリ。reason: 1～2文で問題の理由を記述し、異なる正確な単語を引用します。recommendation: ツリースキーマの範囲内に収まる具体的な修正案（許可されたkindとrelationの値のみ）。tier（欠落のみ）:coreまたはsupporting。references/audit-rules.mdで定義されています。risk_reason: リスクがデフォルトと異なる場合のみ。summary、structure_warnings、finding_idは省略します。スクリプトが計算します。
次に実行します。
python scripts/build_report.py --tree <knowledge-tree.json> --index <output>/evidence-index.json --audit <output>/audit.json
- エラー: 何も書き込まれません。
audit.jsonを修正し、成功するまで再実行してください。チェックを回避しないでください。 - 成功: スクリプトは
audit.jsonをsummary、structure_warnings、finding_id（F-001、F-002、… レポート順）で書き換え、その隣にreport.mdを書き込みます。レポート言語はスライドに従います。ユーザーが他の言語を希望する場合は--lang zhまたは--lang enを渡してください。
最後に、ユーザーにレポートの場所、サマリーの件数、および上位の問題を数行で伝えます。レポート全体を貼り付けないでください。
入力が特殊な場合
- 画像が読めない場合: 読める範囲を
lowの確実性で抽出し、影響を受ける発見事項のreasonにページ番号を記載し、ユーザーに伝えてください。内容をでっち上げないでください。 - ツリーが画像にない内容をカバーしている場合（例：一部のスライドのみが提供された）：該当する項目を
unsupported-expansionとして報告し、欠落しているページが原因である可能性があることをユーザーに伝えてください。 - 非常に大きなデッキやツリーの場合: 段階2ではページごと、段階4ではノードごとに作業し、すべてを記憶するのではなく、結果をファイルに逐次書き込んでください。