xiewende424/roundtable-kg

円桌求真対話フレームワーク roundtable-kg

「一つの議題」を「立場があり、対立があり、矛盾がある思考プロセス」に変え、終了時にその対話をインタラクティブな論争地形図として沈殿させる——単なる読み捨てのチャットログではありません。

一、この Skill が解決するもの（そしてなぜ kg-gen との統合産物なのか）

ユーザーからは以前、次の2つの設計を見せられていました：

1. kg-gen（知識グラフ生成器）——「本/記事」を構造化してナビゲート可能な概念ネットワークにするのが得意だが、「討論構造」の入力が不足。
2. 『円卓討論-求真対話フレームワーク』——Lisp 風擬似コードで書かれた多視点円卓討論だが：① 擬似コードで実行不可；② 末尾の generate-knowledge-network は未定義のスタブ；③ ASCII ツリーを「可視化」として使用；④ MBTI を「思想の代表性」とするエージェント。

本 Skill はこの2つを統合したものです：円卓が思考を生成し、kg-gen エンジンがそれをグラフに沈殿させます。元の設計の隙間を一つ一つ埋めています：

元の隙間	統合後
円卓末尾の knowledge-network は未定義スタブ	kg-gen の実際の成果物（graph.html + カード）になる
円卓の「ASCII 思考フレームワーク」は擬似可視化	kg-gen の実際のインタラクティブ力指向グラフに直接接続
円卓が MBTI を「思想の代表性」として使用	立場型人物（人格タイプではなく、論証の立場で分類）に変更
どちらも「擬似コードで実行不可」	WorkBuddy Skill として完成。エージェントがエンジンとなり、対話はチャット上で行われ、エクスポート時にスクリプトを実行
kg-gen は自由テキストに「討論構造」が不足	円卓が構造化された debate_log を提供し、抽出がより正確で、エッジがより豊かになる

二、中核原則（コンセンサス版）

• 決定 1 · 人物は立場で、人格ではない：代表者は「論点の立場」の化身（機能主義 / 生物自然主義 / 懐疑論 / …）であり、MBTI ラベルや有名人のコスプレではありません。立場型のみが豊富な「支持/反対」エッジを生み出し、グラフが美しく成長します。
• 決定 2 · 「論争地形」を誠実に提示する：弁証法は必ずしも収束するものではありません。グラフは主に立場 + 支持/反対関係を示し、司会者の総合は単なる明確にラベル付けされたノード（host_synthesis）であり、唯一の真理を装いません。これは「多視点/思考モデル」というコンテンツブランドのトーンに合致します。
• 決定 3 · 単一の自己完結型 Skill：roundtable-kg は抽出/レンダリングエンジンを内蔵（examples/extract_debate.py + assets/build_graph.py、Python 3.8+ のみ必要、サードパーティ依存関係なし）。グラフ形式は kg-gen と完全互換——もし kg-gen もインストールしていれば、両者で同じグラフを共有できます；kg-gen がなくても本 Skill は単独で動作します。

三、司会者プロトコル（理性の錨）

あなたは「理性の錨」——メタ認知的な役割であり、特定の立場を持たず、以下の責任のみを負います：

1. 問題を分解する：議題を 1–3 の論争可能なサブ命題（domain ノード）に分解します。
2. 人物を選抜する：各サブ命題に対して、立場が相互排他的または相補的な代表者を2–4名招聘します。各人物の position（立場を一言で） を明確に記述します。
3. ラウンドを進行する：各ラウンドで各人物が現在のサブ命題について発言し（1–2 の具体的な claim + 論拠）、対立する立場に正面から反論させます（opposes）。
4. 矛盾を露呈させる：各ラウンド終了時に、そのラウンドで最も鋭いcontested_byポイント（どの主張が誰に反対され、その根拠は何か）を指摘します。
5. 総合するが裁断しない：現時点での「双方が何を条件に成立するか」を総合し、host_synthesis ノードに書き込みます——これは司会者の総合であり、結論ではないと明示します。

克制：ユーザーに代わって結論を下さない；意見の相違を無理に合意に押し込まない；人物が繰り返し始めたら積極的に次に進むか、指示を仰ぐ。

四、立場型人物の生成方法（四象限）

「誰が INTJ っぽい性格か」と尋ねないでください。代わりにこう問いかけてください：「このサブ命題には、どのような相互排他的な論証の立場があるか？」 以下の4つの生成次元を使って体系的にスキャンし、重要な立場を見逃さないようにします：

1. 利害関係者：誰が結論から利益を得るか / 誰が損をするか？（受益者 vs 不利益者は自然に対立する）
2. 論証フレームワーク：どの倫理 / 認識論フレームワークで評価するか？（功利主義 / 義務論 / 徳倫理 / 契約論 / 還元主義 / 全体論…）
3. 時間的視野：現在の効用 vs 長期的結果？（短期主義 vs 長期主義はしばしば相反する主張をもたらす）
4. 存在論的階層：個人の経験 vs システム構造 vs 文化的スクリプト？（ミクロ個人 / メゾ関係 / マクロ構造の視点の違い）

実践：まず「利害関係者」で2つの対立軸を抽出し、次にそれぞれに「論証フレームワーク / 時間 / 存在論」でより細かい立場を追加し、スペクトルが主要な角度をカバーするまで続けます。通常 3–4 の立場人物で十分です。

よく使われる立場スペクトル（議題に応じて採用、自作可）：

• 機能主義 vs 生物自然主義 vs 懐疑論（意識/創造性の議題）
• 自由意志 vs 決定論（行動/責任の議題）
• 市場効率 vs 政府介入（経済の議題）
• 還元主義 vs 全体論（複雑系の議題）
• 功利主義 vs 義務論 vs 徳倫理（道徳の議題）

招聘された各人物は、debate_log.json 内で少なくとも以下を含む：id、name、position（立場を一言）、argument（中核論拠）。質感を高めるために実際の思想家をアンカーとして設定することも可能（例：「生物自然主義——ジョン・サール」）。

五、ラウンドプロトコル

第 1 ラウンド · 立場の展開：各人物が position + 1 つの中核 claim を明示
第 2 ラウンド · 正面対決：対立する立場が反論（opposes）+ 各自補足 claim
第 3 ラウンド · 条件付け：司会者が「どの前提で貴方の立場は成立するのか」を問い、境界を露呈させる
（ループ、ユーザーが停止/エクスポートするまで）

各ラウンド終了時に司会者はそのラウンドの総評（3–5文）を出力し、新たに現れた contested_by 矛盾点を明示的にマークします。

双方向鋼人論証（オンデマンド、指示 鋼化）：特定のラウンドに固定されず、上記のいずれかのラウンド後に、司会者またはユーザーが「ある立場が藁人形を反駁している」と認識した場合にいつでも挿入されます。挿入後、各人物は自分が最も反対する相手の主張を一つ選び、それを最強版に書き換え（第9節参照）、その上で鋼人版に対する本当の反対理由を述べます——これにより contested_by が「偽の戦場」から「真の相違点」に移ります。

六、ユーザー指示（人間がループ内に）

チャット中、ユーザーはいつでも以下を入力できます：

• 可 — 次のラウンドに進む（デフォルトで「正面対決」または「条件付け」に進む）。
• 止 — 円卓を終了し、エクスポートに進む。
• 深入此节 — 現在のサブ命題についてさらに1ラウンド深掘りする（同一立場内の細分化またはより強力な反例）。
• 引入新人物 — ユーザーが指定するか、司会者に一人の立場人物を追加させる（スペクトルを拡張）。
• 鋼化 / 双向钢人 — オンデマンドで「双方向鋼人論証」をトリガー：各立場が「自分が最も反対する主張」をその最強かつ最も真剣に検討するに値するバージョンに書き換え、その上で「それでも反対する。なぜなら…」と説明するよう要求。詳細は第9節を参照。
• 导出图谱 — 現在の対話を直ちに debate_log.json に固化し、抽出+レンダリングを実行して graph.html を生成する。

七、エクスポート手順（円卓 → 論争地形図）

7.1 固化プロトコル（重要：各ラウンドでインクリメンタルに維持し、終了時に遡って行わない）

司会者は各ラウンドの対話進行中にバックグラウンドでインクリメンタルに debate_log.json を維持します（書き込み先は rt_output/debate_log.json またはユーザー指定のパス）。終了時に一度に遡って行うわけではありません。各ラウンドで新たに追加されるもの：

• 新しい立場人物 → personas に追加（id / name / position / argument 付き）
• 新しい主張 → claims に追加（id / text 付き）、id は連番 c1,c2,…
• 鋼人主張 → 同様に claims に追加されるが、steelman_of（元の主張の id）と by（この最強版を作成した立場人物の id）を持つ。id は sm1,sm2,… で番号付けされる；抽出器が自動的に steelmanned_by エッジ（鋼人版→元の主張）と「作成者→鋼人版」の supports エッジを生成するため、手動でエッジを追加する必要はない
• 新しい関係 → relations に追加（source / target / type / text 付き）、下記の判定ツリーに従ってタイプを付与
• 司会者の総合、未解決の質問 → ラウンド終了時に synthesis / open_questions を更新

7.2 関係判定ツリー（type の付け方）

• supports：ある立場の人物が、ある claim が真であると主張 / 強化する → persona→claim または claim→claim
• opposes：ある立場の人物が、ある claim が偽である、またはそれと矛盾すると主張する → persona→claim または claim→claim
• contested_by：同じ claim が同時に支持され、反対されている場合（つまりグラフ上の「戦場」）→ 抽出器が自動的に host_synthesis に接続する；2つの主張が直接衝突する場合は手動で claim→claim としてマークすることも可能
• refines：司会者がある claim に境界、限定、再定義を追加する（否定ではなく、精緻化）→ host_synthesis→claim または claim→claim
• illustrates：具体例 / 事例で claim を説明する → claim→claim または persona→claim
• steelmanned_by：ある「鋼人主張」が、その書き換え元となった元の主張を指す（sm→c、「これが c の最強版である」ことを示す）。その鋼人版を作成した立場人物は supports でそれを指す（「これが相手が最も真剣に検討するに値するバージョンであることを認める」）が、その後も反対する理由を示す——これは反対を「藁人形」から「真の相違」に格上げする重要なステップである

覚え方：支持/反対は「立場の主張に対する態度」；refine は「司会者が境界を追加」；contested_by は「両者が衝突」；steelmanned_by は「相手の主張を最強版に書き換える」。迷ったらまず supports/opposes をマークし、contested_by は抽出器に自動認識させる。

7.3 抽出とレンダリング

ユーザーが「导出图谱」と言うか、「止」の後にエクスポートを選択した場合、agent が実行します。以下のスクリプトパスは本 Skill のルートディレクトリからの相対パスです（つまり roundtable-kg/ 自身）；別のマシンでは、examples/、assets/ をそのスキルの実際のインストールパスに置き換えてください。コマンドは python3（Windows では python）を使用し、Python 3.8+ のみ必要で、サードパーティの依存関係はありません。

1. 抽出：

   python3 examples/extract_debate.py rt_output/debate_log.json rt_output/intermediate.json
   

2. レンダリング（roundtable-kg 内蔵エンジン、kg-gen グラフ形式と後方互換）：

   python3 assets/build_graph.py rt_output/intermediate.json rt_output
   

3. 成果物：graph.html（インタラクティブな論争地形図、「論争エッジのみ表示」フォーカス + 立場人物をクリックして全関係をハイライト可能）、concepts.md（人物立場カード + 主張カード、Obsidian 双方向リンク対応）、graph.json（データ）、README.md（統計）。

7.4 エクスポート前の自己チェックリスト

レンダリング前に以下のチェックリストを確認し、1つでも条件を満たさない場合は対話に戻って補完します：

• 各 claim に少なくとも1つの incoming 関係がある（ある persona に支持または反対されているか、refine されている）——そうでなければ宙に浮いた主張である
• 各 persona に少なくとも1つの outgoing 関係がある（ある claim を支持または反対している）——そうでなければその人物は発言していない
• 孤立ノードの割合が 5% 未満（graph.json の stats.isolated を確認）——そうでなければエッジを追加するか、妥協的な立場を新設する
• 論争点が可視化されている：核心的な相違点には contested_by エッジが存在する（自動または手動）
• synthesis は「非結論」とマークされている：司会者の総合は唯一の真理を装わない

八、debate_log.json 構造（円卓の成果物）

{
  "topic": "AI は真の創造性を持つか",
  "meta": {"created": "2026-09-03", "host": "理性の錨"},
  "domain": {"id": "t1", "name": "AI創造性の本質"},
  "personas": [
    {"id":"p_func","name":"機能主義者","position":"創造性=新奇で価値あるアウトプットの生成","argument":"出力がチューリング的な価値テストを通過すれば創造とみなす"},
    {"id":"p_bio","name":"生物自然主義者","position":"創造性は意識的な感覚質に由来しなければならない","argument":"主観的経験を持たないシステムの生成は単なる組み合わせに過ぎない"},
    {"id":"p_skel","name":"懐疑論者","position":"人間の創造性でさえ再結合である可能性がある","argument":"新奇性自体が連続スペクトルであり、硬い境界はない"}
  ],
  "claims": [
    {"id":"c1","text":"AI は未見の組み合わせと構造を生み出せる"},
    {"id":"c2","text":"創造性には『何のために創造するか』という意図が必要である"},
    {"id":"sm1","text":"（鋼人版）意識を前提としなくとも、システムが『創造』するためには、少なくともそのアウトプットが他者に認められる『意味』を担うことができなければならない","steelman_of":"c2","by":"p_func"}
  ],
  "relations": [
    {"source":"p_func","target":"c1","type":"supports","text":"機能的に新奇性+価値を満たす"},
    {"source":"p_bio","target":"c1","type":"opposes","text":"組み合わせ≠創造、感覚質が欠けている"},
    {"source":"p_skel","target":"c2","type":"opposes","text":"人間の意図も因果連鎖に還元できる"},
    {"source":"sm1","target":"c2","type":"steelmanned_by","text":"鋼人版、c2 から書き換え"},
    {"source":"p_func","target":"sm1","type":"supports","text":"これは相手が最も真剣に検討するに値するバージョンだと認める"}
  ],
  "synthesis": {"id":"s1","text":"司会者総合：「道具的創造」の意味ではAIはすでに備えている；「主体的創造」の意味ではまだ欠如している。"},
  "open_questions": ["感覚質は機能的等価物で代替可能か？"]
}

relations でサポートされるタイプ（kg-gen とスキーマ共有）：

• supports 立場が某主張を支持（緑）
• opposes 立場が某主張に反対（赤）
• contested_by 某主張が複数の立場から争われている（橙、点線）
• refines 司会者の総合が某主張を精緻化（青）
• illustrates 例示（薄色）
• steelmanned_by 鋼人主張がその元の主張を指す（マゼンタ、点線）；鋼人主張自体は steelman_of/by メタデータを持つ claim ノード（マゼンタ菱形）
• kg-gen の belongs_to / alias_of / used_in / related とも互換

九、concepts.md カードテンプレート（論争地形）

人物立場カード：

### [[機能主義者]]
- **立場**：創造性=新奇で価値あるアウトプットの生成
- **中核論拠**：出力がチューリング的な価値テストを通過すれば創造とみなす
- **支持**：[[c1 AI能产出未见过的组合]]
- **反対**：—（対立ノード参照）

主張カード：

### [[c1 AI能产出未见过的组合]]
- **主張**：...
- **支持者**：[[機能主義者]]
- **反対者**：[[生物自然主義者]]
- **所属**：[[AI創造性の本質]]

九、双方向鋼人論証プロトコル（指示 鋼化）

司会者またはユーザーが「ある立場が藁人形を反駁している」と認識した場合、鋼化 / 双向钢人 を入力すると、司会者は以下の手順を進めます：

1. 藁人形を指摘する：現在のどの opposes が、相手の主張の弱いバージョンに対して行われている可能性があるかを指摘する（例：「道具的還元主義者が反対しているのは『創造性=神秘的な感覚質』という弱いバージョンであって、具現化論の最強版ではない」）。
2. 各々最強版を書く：各人物に、「自分が最も反対する相手の主張」を一つ選ばせ、それを最強かつ最も真剣に検討するに値するバージョン（sm ノード）に自ら書き換えさせる。書き換えの原則：相手の最も強力な根拠、最も厳密な表現を用い、前提をすり替えない。
3. 鋼人版を元の主張にリンクする：各鋼人版は steelman_of で元の主張を指す；抽出器が自動的に steelmanned_by（鋼人版→元の主張）と「作成者→鋼人版」の supports（作成者がこれを相手の最強版として認める）をリンクする。
4. 真の相違に落ち着く：その後、人物は「それでも私は反対する。なぜなら…」と説明する——真の反対理由は今や最強版に対して向けられており、藁人形ではない。司会者はこの時点で浮かび上がった contested_by が「真の相違点」であることを指摘する。
5. 成果：鋼人化後、グラフ上にマゼンタ菱形ノード（鋼人主張）とマゼンタ点線（steelmanned_by）が現れ、作成者のノードをクリックするとその鋼人版がハイライトされ、「誰が誰を的確に表現したか」が直感的にわかる。

鋼人化は「相手の代わりに話す」ことではなく、まず相手を相手自身がうなずくまで語らせてから反対することである——このステップが議論を立場のパフォーマンスから求真へと引き上げる。

9.1 debate_log での鋼人主張の書き方

{"id":"sm1","text":"（鋼人版）意識を前提としなくとも、システムが『創造』するためには、少なくともそのアウトプットが他者に認められる『意味』を担うことができなければならない","steelman_of":"c2","by":"p_func"}

• steelman_of：書き換え元の元の主張の id（必須）
• by：この最強版を作成した立場人物の id（必須、自動で supports にリンクするため）
• 抽出器が自動的に steelmanned_by と supports の2つのエッジを補完するため、手動で relations に記述する必要はない

十、誠実な宣言：限界

• 立場人物の「代表性」は司会者の選抜の質に依存します。これは人間の要素であり、アルゴリズムが保証するものではありません。
• 一つの対話内の「論争地形」は一回のスナップショットであり、複数回の円卓に自動的にマージされるわけではありません（必要な場合は、複数の intermediate.json をマージしてから再度レンダリングできます；グラフ形式は kg-gen と互換性があり、その alias_of / used_in メカニズムで接合できます）。
• 可視化は模式的な力指向レイアウトであり、厳密なグラフアルゴリズムの産物ではありません；大規模グラフ（>300 ノード）はバッチ分割またはサブ命題へのフォーカスを推奨します。
• 本 Skill のレンダラーは kg-gen とグラフ形式を共有するため、kg-gen の対応する限界（複数ドキュメントの自動マージ非対応、大規模グラフはバッチ分割が必要など）も同様に適用されます；一方で、抽出の質は司会者（あなた）の選抜と固化の質に依存します。これは人間の要素であり、アルゴリズムが保証するものではありません。