Claude Codeには「スキル」という仕組みがある。SKILL.mdというMarkdownファイルを置くと、Claudeがタスクに応じて自動で読み込んで使ってくれる、エージェントの拡張機能みたいなものだ。
noteのCDO・宇野雄さんが、その仕組みを使った「円卓会議スキル」を公開していた。複数の専門家ペルソナを持ったAIエージェントが、一つのテーマについて独立して意見を出し合い、Devil's Advocateが楽観的な合意を阻止しながら、最終レポートをまとめる——という構造化議論のスキルだ。
デルファイ法・Groupthink研究・MAD（Multi-Agent Debate）研究の知見がきちんと組み込まれていて、設計はとてもよく考えられている。ただ、惜しかった。
何が惜しかったのか
リポジトリを読んでみて、気になった点は3つあった。
- JIT原則の不徹底: SKILL.md本体が「動作原理の解説書」と「実行手順書」を兼ねていて、エージェントが実行時に読む文書として冗長だった
- 能書きノイズ: 「研究で効果なし〜逆効果」「MAD研究では」といった学術的な注釈が手順の中に散在していて、これは設計ドキュメント側にあるべきもの
-
ハーネス固有の漏出:
Claude Code: Agent tool で run_in_background: true で並列起動のような環境固有の記述が本体に直書きされていた
特に最後のが致命的で、設計思想はハーネス非依存であるべきなのに、別の環境（Cursor、Agent Teamsなど）に持ち出した瞬間に動かなくなる構造になっていた。設計と実装が矛盾していた。
全ファイル書き直した
改善の方針は「SKILL.md本体はオーケストレーターが迷わず実行できる最小手順書にする。それ以外は全部外に出す」というシンプルなもの。
具体的にやったことは：
ファイル構成の再設計
skills/roundtable/
├── SKILL.md # 本体。手順のみ、能書きなし
├── README.md # ★新設。設計思想・参考文献はここ
└── references/
├── expert-selection.md # 専門家選定の原理＋アーキタイプ統合
├── deliberation-rules.md # 実行時ルールのみに縮小
├── output-format.md # Phase番号を新体系に合わせて更新
└── harness-adapters.md # ★新設。環境別実装をここに隔離
SKILL.md 本体の主な変更
- Phase を 0〜4（責務混在）から 1〜7（単一責務）に分割
- Intake / Calibrate / Assemble / Analyze / Deliberate / Synthesize / Report
- 深度別の分岐記述（Quick/Standard/Deep）を各Phaseから抜いて、冒頭の1つのマトリクスに集約
- 学術引用・「研究で〜」系の能書きを全削除（README.mdへ移設）
- ハーネス固有名詞をゼロに（全て harness-adapters.md へ）
- frontmatterの
argument-hintを削除（Agent Skills仕様外のClaude Code拡張だったため）
Phase構成を並べるとこう変わった。
Before（元の5 Phase構成）
Phase 0: 議題分析・専門家選定
├── 0-1. 議題の構造化
├── 0-2. パネルサイズと議論深度の判定
├── 0-3. 専門家の動的選定
├── 0-4. 専門家ペルソナの定義
└── 0-5. メタ判断の出力
Phase 1: 独立分析
Phase 2: 構造化議論（Standard / Deep のみ）
├── Round 1: 対立点への反論
└── Round 2: 深掘り（対立が残る場合のみ）
Phase 3: 統合・評決
├── 3-1. 合意事項のまとめ
├── 3-2. 対立の解決
├── 3-3. 少数意見チェック
└── 3-4. セカンドチャンス（Deep のみ）
Phase 4: ユーザーへの報告
Phase 0 だけで5つのサブステップを持っていて、議題分析・深度判定・専門家選定・ペルソナ定義・承認提示という、性質の異なる責務が一つのPhaseに詰め込まれていた。Phase 3も統合と再問い合わせ（セカンドチャンス）が混在している。
After（1〜7の単一責務構成）
Phase 1: Intake — 議題と対象物を受け取る
Phase 2: Calibrate — 深度とパネルサイズを決める
Phase 3: Assemble — 専門家を選定・ペルソナ定義・承認
Phase 4: Analyze — 独立分析（並列）
Phase 5: Deliberate — 構造化議論（Standard / Deep のみ）
Phase 6: Synthesize — 統合・少数意見チェック・評決
Phase 7: Report — レポート生成・提示
各Phaseが1つの責務だけを持つようになった。オーケストレーターが実行時に迷わない構造を優先した結果で、「今どのPhaseで何をすべきか」が名前を見ただけで決まる。
改善前後の比較：
| 指標 | Before | After |
|---|---|---|
| SKILL.md 内のハーネス固有名詞 | 多数 | 0 |
| SKILL.md 内の学術引用・能書き | 多数 | 0 |
| Phase 構成 | 0〜4（責務混在） | 1〜7（単一責務） |
| 深度分岐の記述 | 各Phaseに散在 | 冒頭マトリクスに集約 |
改良版を実際に回してみた
せっかく整理したので試してみた。
設定
- 議題: 「AIコーディングアシスタントは開発者のスキルを長期的に向上させるか、退化させるか」
- 深度: Standard（最大2ラウンドの議論あり）
- パネル: 認知科学者、プログラミング教育研究者、シニアSWE/テックリード、労働経済学者、HCI研究者、Devil's Advocate（計6名＋DA）
- モデル: Claude Sonnet 4.6（全エージェント同一モデル）
出てきたレポートはこちら。
# 円卓会議レポート: AIコーディングアシスタントは開発者のスキルを長期的に向上させるか、退化させるか
## エグゼクティブサマリ
現実の使用環境では、AIコーディングアシスタントは特に初学者・ジュニア開発者のスキルを静かに・痛みなく劣化させるデフォルト経路をたどる。スキル向上は不可能ではないが、
それには「足場を外す設計」「意図的な非AI実践」「メタ認知の訓練」が必要であり、その条件を自然に満たせる個人・組織は少数派である。技術そのものではなく、適切な使用設計
の不在がリスクの主体だ。問いへの回答を一言で言えば：「退化がデフォルト、向上は設計次第」。最優先の行動は、AIなしでの意図的実践を個人・組織の制度として今すぐ設計する
ことである。
---
## 専門家パネル
| 専門家 | 役割 | 総合評価 |
| ------------------------ | ------------------------------ | -------- |
| 認知科学者 | 道具使用・分散認知・スキル形成 | ★★☆☆☆ |
| プログラミング教育研究者 | CS教育・学習科学・発達段階 | ★★★☆☆ |
| シニアSWE/テックリード | 実務現場・コードレビュー観察 | ★★☆☆☆ |
| 労働経済学者 | 技術変化と職業スキル・市場構造 | ★★☆☆☆ |
| HCI研究者 | 人間とAIの協調・ツール設計 | ★★★☆☆ |
| Devil's Advocate | 問いの構造的批判 | — |
---
## 合意事項
- 上級者への補完効果: 既にスキルを内面化した上級者・シニアエンジニアに対して、AIは認知的拡張ツールとして有効に機能する。意図的練習理論（Ericsson 1993）によれば、内面化済みのスキルは外部ツール依存で簡単には失われない。
- 初学者・ジュニアへのリスク集中: スキル形成段階においてAIに依存すると、「望ましい困難（Desirable Difficulties）」が系統的に除去され、チャンキング形成・手続き的記憶・デバッグの因果モデルが構築されない。
- 劣化の不可視性: スキルの空洞化は遅く・痛みなく進行し、3〜5年後に「AIが使えない場面」で初めて顕在化する（認知科学者・教育研究者・SWEが一致）。
- 「設計の不在」がデフォルト: 適切な足場除去のタイミング・意図的練習・メタ認知訓練を自然に実現できる個人・組織は少数派であり、劣化経路がデフォルトに近い（Round 1 の収束結論）。
---
## 主要な議論と結論
### 論点1: 「条件次第で大丈夫」か「構造的に問題」か
- 結論: 「条件があれば向上も可能だが、その条件が現実に実現されるのは少数派。設計の不在がリスクの主体」
- 教育研究者・HCI研究者の根拠: 発達段階（ZPD理論）・SRL能力・ツール設計の差異によって影響が180度異なる。中級者へのスキャフォールディング効果は認知科学的に整合する（Vygotsky 1978）
- 認知科学者・SWEの根拠: Bainbridge (1983)の「自動化の皮肉」——ツールが快適に機能するほど人間は能動的モニタリングを放棄する。足場を外すタイミングを判断する設計が現在のAIツールには存在しない。「使い方次第という楽観論」を維持するインセンティブ構造が存在しない
- 判断理由: 認知科学者・SWEの反論が「条件の理想的実現を妨げるメカニズム（Bainbridge効果・インセンティブ構造）」という具体的根拠を持つため重視。教育研究者も Round 1 で「サイレントスキルホロウイングはデフォルト経路に近い」と修正した
### 論点2: どのスキルが最も先に・深く劣化するか
- 結論: 優先順に「デバッグ・因果推論能力」「AI生成コードの検証能力」「アーキテクチャ設計能力」の順で劣化リスクが高い
- 認知科学者: デバッグは因果モデルを構築する最重要な学習機会。AIによるエラー解決の即時化がこれを奪う（Kapur 2016の生産的失敗理論）
- HCI研究者: AI生成コードの検証能力は従来とは異なる認知プロセスを必要とするが訓練機会がない。Automation Bias（「AIが書いたなら正しいはず」）がバグ見逃しを構造化する（Parasuraman & Riley 1997）
- SWE現場観察: アーキテクチャ設計は「なぜKafkaか」「べき等性の実装」などの設計文脈をAIが提供しないため、ジュニアの設計力が成長しない
- 判断理由: HCI研究者の「検証能力劣化」は他の専門家が明示的に言及していないが、Automation Bias の研究根拠が強固であり、少数意見として採用（後述）
### 論点3: 市場・業界レベルの構造変化
- 結論: 個人・組織レベルの介入だけでは不十分であり、業界・政策レベルの集合行為問題として捉える視点が必要と考えられる
- 労働経済学者の根拠: ATMパラドックスとの違い（AIはスケールコストがほぼゼロのため窓口係増加と同じ補完構造が起きない）。ジュニア層がスキル形成機会を失った世代がシニアになる10〜15年後、業界全体の深い技術能力の基盤が空洞化するリスク。製造業での数値制御機械導入後の「職人技の断絶」（Hirschhorn 1984）との類比
- 判断理由: 他の専門家は個人・組織解決策に留まっているが、「集合行為問題として個々の企業・個人が合理的インセンティブでAIを使い続ける結果、業界全体が劣化する」というメカニズムは、個人レベルの推奨では解決できない次元の問題を指摘している。採用。
---
## 少数意見（見逃してはいけない指摘）
### 指摘1: 検証能力（Verification）の劣化が最も危険
- 指摘者: HCI研究者
- 内容: AI生成コードを「正しいか確認する」検証能力は、従来の「自分で書いてデバッグする」経験では自動的に鍛えられていたが、AI主流環境ではその訓練機会が消滅する。しかも Automation Bias（「AIが書いたなら大丈夫」）がバグ見逃しを構造化するため、劣化は自覚が最も遅い
- 根拠: Bainbridge 1983 (Ironies of Automation)、Parasuraman & Riley 1997の自動化依存理論、Vasconcelos et al. 2023
- 対応: 採用 — 根拠が強固であり、本番障害・セキュリティバグという影響大の領域に直結する。他の専門家がデバッグ力を挙げたのと部分的に重なるが、「検証という異なる認知プロセスの欠落」という観点は独自であり保護すべき
### 指摘2: 集合行為問題——市場メカニズムだけでは解決できない
- 指摘者: 労働経済学者
- 内容: 個々の企業・個人はAIを使う合理的インセンティブを持つが、その合理的選択の集積が業界全体のスキル基盤を10〜15年後に空洞化させる。これは典型的な集合行為問題であり、推奨アクションとして業界基準の「基礎スキル認定制度」や「メンタリング義務付け」等の制度的補完が必要になる可能性がある
- 根拠: Hirschhorn 1984の製造業職人技断絶研究、Acemoglu & Restrepo 2022のタスク置換フレームワーク、Tinbergen 1975の競争的スキルプレミアムモデル
- 対応: 採用 — 他の専門家が個人・組織レベルに終始したのに対して、「個人レベルでは解決できない構造」を指摘した唯一の声。影響大。
### 指摘3: 「向上/退化」という問いの設定が粗すぎた
- 指摘者: Devil's Advocate（最終的に「不必要に迂回的」へ軽量化）
- 内容: 「スキルは向上するか退化するか」という問いは、実際には「どのスキルが、誰の、どの段階で、どの設計の下で」という条件束によってしか答えられない。他の専門家もそれを分析の中で示した（教育研究者「条件依存性こそ最大の知見」）
- 根拠: 測定論的批判、選択バイアス問題、AIの進化速度による研究対象の同一性問題
- 対応: 採用（但し「問いが無意味」ではなく「問いが粗すぎた。正確な問いは：どのスキルが、誰の、どの条件下で変容するか」として採用）
---
## 推奨アクション
1. [最優先] 「AIなし実践」を個人・チームの制度として今すぐ設計する — 週次の「AI禁止デバッグセッション」、スプリントごとのAIフリー課題、新技術習得の最初の2週間はAI補完オフ。根拠：足場は意図的に除去されなければスキャフォールディングにならない（Vygotsky ZPD; 認知科学者・教育研究者・SWE・労働経済学者が共通して推奨）
2. [高] コードレビューで「説明義務」を制度化する — AI支援で書いたコードでも「なぜこの実装か」を説明できなければ採用しない規範を組織として設計する。説明できない場合はレビューで差し戻す。根拠：説明義務が精緻化リハーサルを誘発し、表面的コピーから概念的理解に転化させる（Craik & Lockhart 1972; SWE・教育研究者の推奨）
3. [高] 「AIを使う前に問題を定義する」プロトコルを習慣化する — コメントで意図を先に書いてからAIを呼び出す。「コードを書かせる」より「私の実装方針の問題点を指摘させる」対話型の使い方を標準化する。根拠：意図の言語化が問題分解を促進し、補完による思考の短絡を防ぐ（Hutchins 1995の外化認知理論; HCI研究者・SWE推奨）
4. [中] 発達段階別のAI使用プロトコルを策定する — 初学者（0〜2年）：エラー解説以外のコード生成を控える。中級者（2〜5年）：設計段階の丸投げは禁止。上級者（5年+）：積極活用しつつ月次のスキル維持テストを実施。根拠：ZPD理論（Vygotsky）とSRL能力の発達段階的差異（教育研究者の推奨；SWEの現場観察と整合）
5. [中] AI生成コードの「検証ルーティン」を意図的に設計する — コードを読んで「なぜ動くか」を自分の言葉で説明できるか確認する、エッジケースを自分でリストアップする、週1回特定モジュールをAIなしで書き直す。根拠：Automation Biasへの対抗策として、意図的な検証プロセスの習慣化が不可欠（HCI研究者、Bainbridge 1983）
6. [長期] 業界・政策レベルの制度的介入を今から議論する — 「基礎スキル認定制度」「メンタリング義務付け」等、市場メカニズムだけでは維持できないスキル形成基盤を制度的に補完する仕組みの設計を業界団体・政府レベルで開始する。根拠：集合行為問題は個人・組織レベルの解決で補いきれない（労働経済学者の少数意見；製造業職人技断絶の歴史的類比）
---
## 議論の限界
- 測定問題: 「スキル向上/退化」の定量的測定は現時点では困難。「AIなし評価」と「AIあり評価」の乖離自体が新しい測定課題であり、既存の技術面接・コーディングテストはAI以前の前提で設計されている（DAの批判、教育研究者の指摘）
- AIの進化速度: 本分析はGitHub Copilot・ClaudeCode等2024〜2026年時点のAIを前提としている。エージェント型AI・コード自動生成の本格化によって、この分析の前提が変わる可能性がある（DAの指摘）
- 個人差・組織差の大きさ: 「SRL能力」「ツール設計」「組織文化」によって影響が逆転するため、一般化には限界がある。本レポートは「現実の平均的な使用環境」に基づく議論
- モデル構成: 本分析は単一のLLMモデル（Claude）によるペルソナベースの議論であり、モデル固有の盲点は検出できない可能性がある
- カバーできなかった観点: 地域・文化的差異（日本・米国・インド等で開発文化が異なる）、オープンソース vs 企業内開発での差異、ノーコード/ローコードへの影響波及
---
## 議論プロセス
- 深度: Standard — 業界全体に広く影響するが、ユーザーによる「徹底的に」の指定なし
- 実行方式: 並列独立（Phase 4: 6名同時起動、Phase 5: Round 1のみ実施）
- モデル構成: 単一モデル（Claude Sonnet 4.6）によるペルソナベース議論
- Phase 5 参加者の選定理由: 対立A（楽観/悲観）には認知科学者と教育研究者を選定（Phase 4で最も直接的に対立した2者）。対立B（問いの妥当性）にはDAを選定（批判の当事者）
- 収束判定: Round 1 完了後、対立AはBoth parties が「デフォルトは劣化」で収束を確認。新規具体的証拠が出尽くしたと判断しRound 2 不実施
読んで気づいたこと
少数意見の保護、ちゃんと機能する
単独のLLMに同じ質問を投げると「使い方次第で向上も退化もあり得ます」という無難な回答に落ち着きがちだ。円卓だとそうならない。
面白かったのは2つ。HCI研究者が「AI生成コードの検証能力の劣化」を持ち出した。デバッグ力が落ちるとはよく言われるが、「AI生成コードが正しいか判断する能力」はそもそも従来の開発経験では自動的には育たない、という切り口は他の誰も明示的に触れていなかった。
労働経済学者の「集合行為問題」も鋭かった。個々の企業・個人がAIを使う合理的なインセンティブを持つとしても、その合理的選択の集積が業界全体のスキル基盤を10〜15年後に空洞化させる——というシナリオ。「個人レベルの推奨では解決できない次元の問題」として切り出したのは、他には誰もいなかった視点だ。
いずれも、単独のLLMではまず出てこない粒度。
ネガティブに寄るのは設計通り——フィーチャーとして割り切る
結論は「退化がデフォルト、向上は設計次第」と明確にネガティブ寄りだった。Devil's Advocateが常駐して楽観的な合意の流れを遮断し、少数意見が保護される設計なので必然的にそうなる。人間のチームは楽観に流れるバイアスがあるので、円卓がネガティブ側を補完してくれるのはむしろちょうどいいバランスだと思う。
同一モデルバイアスの限界は正直に言う
全パネリストが同じClaudeなので、「Claudeがその専門家ならこう考えるはず」の範囲内でしか意見が出ない。これは単に「呼ばれていない分野がある」という話ではなく、もっと根が深い。
たとえば物理学者の中にも弦理論派とループ量子重力派がいるように、同じ肩書きの専門家でも立場が分かれるテーマでは、単一モデルは「その専門家の多数派的見解」に収束しがちで、内部の立場の分岐を再現できない。今回の議題でも、「労働経済学者」と一括りにしたがAI楽観派・悲観派の両方が実在するはずで、パネル内に両方を据えても出力が似通った可能性が高い。
結果として、結論も「スキルの陳腐化≠退化」(CADで製図スキルは消えたが設計能力は別の形で発展した、というような歴史的・技術史家的類推)のような視点が弱くなり、ネガティブ側に寄った。AIへの指示設計・生成物の品質判断・エージェントのオーケストレーションなど、今後重要になるスキルへの言及もほぼなかった。
この問題は「技術史家を追加する」程度では解決しない。専門家を増やしても、同じモデルが演じる限り立場の広がりには上限がある。本質的には異なるモデルを混ぜるしかない。
ただしこれはスキル側の問題というより、実行環境(ハーネス)側の問題だと思っている。スキル自体はハーネス非依存に設計できても、「どのモデルに問い合わせられるか」はハーネスの提供機能に依存する。Claude Code に ask gemini や ask codex のようなツールがあれば、このスキルをそのまま使いつつ専門家ごとに別モデルを割り当てられて、同一モデルバイアスはかなり緩和できる。後述の askbudi/roundtable はMCP経由でそれを実現しているが、本質的に必要なのは「モデル横断の問い合わせ機能」であって、特定のスキル実装ではない。
意外だった使い方：議論の「ドレスリハーサル」
一番の発見はここだった。
レポートの結論そのものより、「どこで対立が起きるか」「どの視点が足りないか」が、本番前にわかるのが便利だった。
今回なら「技術史家がいなかったからネガティブに寄った」というのが事後にわかった。これが実際の社内レビューや提案の前にわかっていれば、呼ぶべき人・補うべき視点が変わる。
人間の専門家6人を集めて2時間議論するとコストも調整工数も相当かかる。円卓スキルなら数分とAPIコストで何度でも試せる。パネル構成を変えながら「一番生産的な対立軸が出る組み合わせ」を探索してから本番に臨める。
「チェックリスト生成器として使う」くらいの距離感が現実的で一番しっくりくる。
類似スキルの状況（2026年4月時点）
調べてみたら円卓系のスキルがほかにもいくつかあった。
| スキル | 言語 | 特徴 |
|---|---|---|
| 宇野雄さんの円卓会議スキル（元ネタ） | 日本語 | 学術的設計、独立意見生成＋DA＋少数意見保護 |
| yyufoyy02/roundtable-skill | 中国語 | 歴史上の人物を召集、廷議フォーマットあり。エンタメ寄り |
| lijigang/ljg-skill-roundtable | 中国語 | 哲学的議論に特化、デネット・サルトル等を呼んで弁論 |
| askbudi/roundtable | 英語 | 専門家ペルソナではなく異なるAIモデル（Claude/Gemini/Codex）をMCP経由で協調させるアプローチ |
まとめ
宇野雄さんのスキルの設計思想——独立意見生成、DA常駐、少数意見保護、ラウンド数のキャップ——はどれも学術的な根拠があり、実際に回してその効果を体感できた。単独のLLMとのやりとりとは明確に違う粒度の指摘が出てくる。
一方で同一モデルの限界もはっきりしている。高リスクな意思決定にそのまま使うのは過信で、「シミュレーターとして使ってから本番に臨む」くらいの使い方がちょうどいいと思っている。
改良版のスキルはGitHubに公開しているので、興味があればどうぞ。