議論の構築

仮説から推論を経て具体的な証拠に至るまでの厳密な議論を構築する。すべての説得力のある技術的主張は同じトライアドに従う: 明確な仮説が何を信じるかを述べ、議論がなぜそれが成立するかを説明し、例がそれが成立することを証明する。このスキルは、コードレビュー、設計決定、研究執筆、および主張が正当化を必要とするあらゆるコンテキストにその構造を適用する方法を教える。

使用タイミング

• 技術的な変更を提案するPRの説明を書く/レビューする場合
• ADR（アーキテクチャ決定記録）で設計決定を正当化する場合
• 「これが好きではない」を超えたコードレビューでフィードバックを構築する場合
• 研究論証や技術提案を書く場合
• 技術的な議論でアプローチに異議を唱えるまたは擁護する場合

入力

• 必須: 正当化が必要な主張または立場
• 必須: コンテキスト（コードレビュー、設計決定、研究、文書化）
• 任意: 聴衆（同僚の開発者、レビュワー、ステークホルダー、研究者）
• 任意: 対処する反論または代替的な立場
• 任意: 主張を支持するために利用可能な証拠またはデータ

手順

ステップ1: 仮説を定式化する

主張を明確で反証可能な仮説として述べる。仮説は意見や好みではない — 証拠に対してテストできる特定の主張だ。

1. 主張を一文で書く
2. 反証可能性テストを適用する: 誰かが証拠でこれを間違いと証明できるか?
3. 具体的にスコープを絞る: 特定のコンテキスト、コードベース、またはドメインに制限する
4. テスト可能な基準を確認することで意見と区別する

反証可能 vs 反証不可能:

反証不可能（意見）	反証可能（仮説）
「このコードは悪い」	「この関数はO(n)が達成可能なところO(n^2)の複雑さを持つ」
「TypeScriptを使うべき」	「TypeScriptの型システムは過去6回の本番インシデントのうち4回を引き起こしたnull参照バグのクラスをキャッチする」
「APIデザインがクリーン」	「5つのエンドポイントバリアントを単一のパラメータ化されたエンドポイントに置き換えることでパブリックAPI表面を60%削減する」
「この研究アプローチが優れている」	「方法Aは95%信頼水準でデータセットXにおいて方法Bより高い精度を達成する」

期待結果： 具体的で、スコープが絞られ、反証可能な一文の仮説。それを読む人は、何の証拠がそれを確認または反論するかをすぐに想像できる。

失敗時： 仮説が曖昧に感じられる場合、「これをどうやって反証するか?」テストを適用する。反証の証拠を想像できない場合、その主張は仮説ではなく意見だ。測定可能な基準を追加するかスコープを絞る。

ステップ2: 議論タイプを特定する

仮説を最もよく支持する論理的構造を選択する。異なる主張は異なる推論戦略を必要とする。

1. 4つの議論タイプを確認する:

タイプ	構造	最適な用途
演繹的	AならばB; Aは真; したがってB	形式的証明、型安全性の主張
帰納的	N件にわたって観察されたパターン; したがって一般的に成立する可能性が高い	パフォーマンスデータ、テスト結果
類比的	XはYと関連する方法で類似; YはPを持つ; したがってXもPを持つ可能性がある	設計決定、技術選択
証拠的	証拠EはH1の下でH2より起こりやすい; したがってH1が支持される	研究の発見、A/Bテスト結果

2. 仮説を最も強い議論タイプに一致させる:

   • 何かが必ず真であると主張する? 演繹的を使用
   • 何かが観察に基づいて傾向として真であると主張する? 帰納的を使用
   • 何かが類似した過去の事例に基づいて機能する可能性が高いと主張する? 類比的を使用
   • 一つの説明が代替よりもデータに合うと主張する? 証拠的を使用

3. より強い議論のためにタイプを組み合わせることを検討する（例: 帰納的証拠に裏付けられた類比的推論）

期待結果： 仮説に合う理由の明確な根拠を持つ選ばれた議論タイプ（または組み合わせ）。

失敗時： 単一のタイプが明確に合わない場合、仮説をサブ主張に分割する必要がある場合がある。それぞれが自然な議論構造を持つ部分に分解する。

ステップ3: 議論を構築する

仮説をその正当化に結びつける論理チェーンを構築する。

1. 前提（出発点となる事実または仮定）を述べる
2. 論理的な接続を示す（前提がどのように結論につながるか）
3. 最も強い反論を鋼人化する: 論駁する前に最も良い反対のケースを述べる
4. 証拠または推論で反論に直接対処する

動作例 — コードレビュー（演繹的 + 帰納的）:

仮説: 「バリデーションロジックを共有モジュールに抽出することで、3つのAPIハンドラー間のバグの重複が減少する。」

前提:

• 3つのハンドラー（

  createUser

  、

  updateUser

  、

  deleteUser

  ）はそれぞれ同じ入力バリデーションをわずかな変形で実装している（

  src/handlers/

  で観察）
• 過去6ヶ月で、5つのバリデーションバグのうち3つが1つのハンドラーで修正されたが他に伝播しなかった（issue #42、#57、#61を参照）
• 共有モジュールはロジックの単一の真実のソースを強制する（演繹的: 一つの実装なら修正は一箇所）

論理チェーン: 3つのハンドラーが同じバリデーションを重複しているため（前提1）、1つで修正されたバグが他で見逃される（前提2、3/5件から帰納的）。共有モジュールは修正がすべての呼び出し元に一度で適用されることを意味する（共有モジュールのセマンティクスから演繹的）。したがって、抽出によりバグの重複が減少する。

反論（鋼人化）: 「共有モジュールは結合を導入する — あるハンドラーのバリデーション変更が他を壊す可能性がある。」

反論への返答: ハンドラーはすでに同一のバリデーション意図を共有している; 結合は暗黙的で保守が難しい。パラメータ化されたオプション（例:

validate(input, { requireEmail: true })

）を持つ共有モジュールを介して明示的にすることで、結合が見えテスト可能になる。現在の暗黙の重複は依存関係を隠しているため、よりリスクが高い。

動作例 — 研究（証拠的）:

仮説: 「バイオメディカルNERでは、ドメイン固有のコーパスでの事前学習が、一般的なコーパスサイズの増加よりもダウンストリームタスクのパフォーマンスを向上させる。」

期待結果： 前提、論理的接続、鋼人化された反論、反論への返答を持つ完全な議論チェーン。読者はステップバイステップで推論をたどれる。

失敗時： 議論が弱く感じられる場合、前提を確認する。弱い議論は通常、欠陥のある論理ではなくサポートされていない前提から生じる。各前提の証拠を見つけるか、仮定として認める。反論が反駁より強い場合、仮説を修正する必要がある。

ステップ4: 具体的な例を提供する

独立して検証可能な証拠で議論を支持する。例は説明ではない — 議論をテスト可能にする経験的基盤だ。

1. 仮説を確認する少なくとも1つのポジティブな例を提供する
2. 限界をテストする少なくとも1つのエッジケースまたは境界例を提供する
3. 各例が独立して検証可能であることを確認する: 他の人があなたの解釈に依存せずにそれを再現または確認できる
4. コードの主張については、特定のファイル、行番号、またはコミットを参照する
5. 研究の主張については、特定の論文、データセット、または実験結果を引用する

期待結果： 読者が独立して確認できる具体的な例。少なくとも1つのポジティブと1つのエッジケース。それぞれが特定のアーティファクト（ファイル、行、issue、論文、データセット）を参照している。

失敗時： 例が見つけにくい場合、仮説が広すぎるか観察可能な現実に根付いていない可能性がある。実際に指し示せるものにスコープを絞る。例の不在はシグナルであり、曖昧な参照で埋めるギャップではない。

ステップ5: 完全な議論を組み立てる

仮説、議論、例をコンテキストに適した形式に組み合わせる。

1. コードレビューの場合 — コメントをこのように構造化する:

   [S] <suggestion の一行要約>
   
   **Hypothesis**: <何を変えるべきで、なぜか>
   
   **Argument**: <論理的なケース、前提を含む>
   
   **Evidence**: <特定のファイル、行、issue、またはメトリクス>
   
   **Suggestion**: <具体的なコード変更またはアプローチ>
   

2. PRの説明の場合 — 本文をこのように構造化する:

   ## Why
   
   <仮説: これが解決する問題と具体的な改善の主張>
   
   ## Approach
   
   <議論: このアプローチが代替案より選ばれた理由>
   
   ## Evidence
   
   <例: ベンチマーク、バグの参照、before/afterの比較>
   

3. **ADR（アーキテクチャ決定記録）**の場合 — トライアドをContext（仮説）、Decision（議論）、Consequences（期待される結果の例/証拠）にマップして標準ADR形式を使用する

4. 研究執筆の場合 — 標準構造にマップする: イントロダクションが仮説を述べ、Methods/Resultsが議論と例を提供し、Discussionが反論に対処する

5. 組み立てられた議論を確認する:

   • 論理的なギャップ（結論は前提から実際に従うか?）
   • 欠けている証拠（サポートされていない前提はあるか?）
   • 対処されていない反論（最も強い異議に答えられているか?）
   • スコープのクリープ（議論は仮説の範囲内に収まっているか?）

期待結果： コンテキストに適した完全にフォーマットされた議論。読者は仮説を評価し、推論をたどり、証拠を確認し、反論を検討できる — すべて一つの一貫した構造で。

失敗時： 組み立てられた議論がバラバラに感じられる場合、仮説が広すぎる可能性がある。焦点を絞ったサブ議論に分割し、それぞれが独自の仮説-議論-例のトライアドを持つ。2つの緊密な議論は1つの広がりのあるものより強い。

Composition: Argumentation + Advocatus Diaboli

For high-stakes decisions, compose this skill with the

advocatus-diaboli

agent to form a pre-decision review loop. The pattern:

1. Structure via argumentation -- build the hypothesis-argument-example triad
2. Stress-test via advocatus-diaboli -- steelman the proposal, then challenge each assumption with specific questions. Flag severity: Critical (redesign or abandon), Medium (adjust), Low (note and proceed)
3. Revise based on findings -- critical findings trigger redesign; medium findings trigger adjustment; low findings are noted

When to compose vs. use alone:

• Use argumentation alone when constructing a proposal, PR description, or design justification
• Use advocatus-diaboli alone when reviewing someone else's existing argument
• Compose both when you are both the proposer and need adversarial self-review before committing

バリデーション

• 仮説が反証可能（誰かが証拠でそれを反論できる）
• 仮説が普遍的な主張ではなく特定のコンテキストにスコープが絞られている
• 議論タイプが特定され、主張に適切
• 前提が共有知識として仮定されずに明示的に述べられている
• 論理チェーンがギャップなしに前提から結論に接続する
• 最も強い反論が鋼人化され対処されている
• 少なくとも1つのポジティブな例が仮説を支持する
• 少なくとも1つのエッジケースまたは制限が認識されている
• すべての例が独立して検証可能（参照が提供されている）
• 出力形式がコンテキストに一致する（コードレビュー、PR、ADR、研究）
• 論理的な誤謬がない（権威への訴え、偽の二分法、ストローマン）

よくある落とし穴

• 仮説として意見を述べる: 「このコードが雑然としている」は好みであり仮説ではない。テスト可能な主張に書き直す: 「このモジュールは3つの無関係なドメインにまたがる6つのパブリックメソッドで証明されるように、単一責任原則に従って分離すべき4つの責任を持つ。」
• 反論をスキップする: 対処されない異議は読者がそれを声に出さなくても議論を弱める。常に鋼人化する — 最も強い反対のケースを最良の形で述べてから反論する。
• 曖昧な例: 「このパターンは以前も見た」は証拠ではない。具体的なissue、コミット、行、論文、またはデータセットを指す。具体的な例が見つからない場合、仮説が根拠のない可能性がある。
• 権威への論証: 「シニアエンジニアがそう言った」や「Googleはそうしている」は論理的な議論ではない。権威は調査を動機づける可能性があるが、議論は独自の証拠と推論で成り立つ必要がある。
• 結論のスコープクリープ: 証拠がサポートするものより広い結論を引き出す。例が3つのAPIハンドラーをカバーしている場合、コードベース全体について結論を出さない。証拠のスコープに結論のスコープを一致させる。
• 議論タイプの混同: 演繹的な主張（「必ず」）に帰納的な言語（「傾向として」）を使用するか、その逆。結論の強さについて正確にする — 演繹的議論は確実性を与え、帰納的議論は確率を与える。

関連スキル

• review-pull-request

  -- 構造化されたコードレビューフィードバックへの論証の適用

• review-research

  -- 研究コンテキストでの証拠に基づく議論の構築

• review-software-architecture

  -- 仮説-議論-例のトライアドによるアーキテクチャ決定の正当化

• create-skill

  -- スキル自体がタスクを達成する方法についての構造化された議論だ

• write-claude-md

  -- 明確な正当化から利益を得る規約と決定の文書化