🎉
Copilot Claudeのレビューが雑なのでOpusに相談して解決した

2026/02/04に公開
!GitHub copilot claude sonnetの問題をclaude opusに相談して解決した件
AIには知識がある。しかし、それを使えない。この問題をAI自身に相談して解決した記録と、そこから見えた人間-AI協働のパターンについて記す。

 問題コードレビューをAIにやらせたい。素直なアプローチは「これをチェックせよ」とリストを渡すこと。だがこれはホワイトリスト方式だ。リストにないものは見逃す。
「リストに書いていないことも検出してほしい」
これをどう実現するか、AI自身に相談してみた。

 対話の記録私: AIは知識があるのに活かせない。これを何とかしたい。
AI: いくつかパターンがある。知識があっても適用タイミングがわからない、優先順位がつけられない、複数の知識を統合できない...
私: コードレビューで事前にチェック対象を示すとできる。でもこれはホワイトリスト方式で、新しいものに対応できない。
AI: アプローチとしては、原則からの逸脱を検出する、多角的検討を強制する、AIに自己チェックリストを生成させる...
どれも妥当だが、結局ホワイトリストの変形だ。もっと具体的に攻めることにした。
私: 何も作用しない属性値をチェックする方法は？
AI: 難しい。「作用しない」の判定には「作用する条件の全体像」が必要。具体的にどの領域？
私: C# APIでJSON属性。Newtonsoft.Jsonの属性を使っている。
AI: ああ、典型的な罠：
// プロジェクトは System.Text.Json を使用
// しかしモデルには...
[JsonProperty("user_name")]  // ← Newtonsoft.Json（効かない）
public string UserName { get; set; }

// 本来は
[JsonPropertyName("user_name")]  // ← System.Text.Json
コンパイルは通る、実行もできる、ただ静かに無視される。Roslyn Analyzerで検出できるかも...
私: Roslynでは無理。
AI: 確かに。DI構成を追って、実行時にどのシリアライザーが使われるか判定する必要がある。静的解析の限界だ。残る手段は設計決定を宣言すること。「このプロジェクトはSystem.Text.Jsonを使う、Newtonsoft属性は禁止」と。
私: 最初から誤ってコードに入っている。誰も気づいていない。設計規約はまだない。
AI: なるほど、整合性のチェックか。両方のパッケージがあるか、どの属性が使われているか、どのシリアライザーが登録されているか確認して...
私: 整合性チェックをしたら「問題なし」と判定された。統一的に間違っている。
AI: 「綺麗に間違っている」状態。整合性チェックは通る。これは本当に難しい。AIが自発的に逆引きしないといけない。「この属性が機能するには何が必要か？その条件は満たされているか？」と。
私: これを網羅的に確認させたい。
AI: 汎用プロセスにする。すべての属性について：
この属性はどのライブラリ由来か
機能するための前提条件は何か
その前提条件はプロジェクト内で満たされているか
満たされていなければ報告
私: 検出できた。

 対話の構造振り返ると、3つの要素が機能していた。
!ゴール共有: 何を達成したいか
「これを網羅的に検出したい」。共有されたゴールがなければ、「Roslynは無理」と押し返したとき、会話は終わっていたかもしれない。ゴールが共有されていたから、別の方向を探し続けた。
!絞り込み:   問題空間を狭める
問題を扱える大きさにした

具体例がなければAIの知識は活性化しなかった。
人間: AIは知識を活かせない
     （広すぎて手が出ない）
         ↓
人間: コードレビューで
     （領域を限定）
         ↓
人間: 属性値の空振り
     （具体的な現象）
         ↓
人間: System.Text.JsonでJsonProperty
     （再現可能な事例）
!押し返し:   解決空間を狭める
押し返しが行き止まりを排除した：
「Roslynは無理」
「整合性チェックでは問題なしと出た」
「統一的に間違っている」
押し返すたびに、ゴールがまだ達成されていないため、AIはより深く探索せざるを得なかった。
ゴール共有: 「解決」の定義を与える
絞り込み:   問題空間が収縮
押し返し:   解決空間が収縮
                ↓
        交差点に解が存在する
これが協業だ。どちらも単独では到達できなかった。人間は現実からの制約を提供し、AIは知識からの候補を提供する。共有されたゴールが、両者を交差点へ向かわせ続ける。

 なぜ機能したかAIには知識がある。欠けているのは起動条件だ。
従来: [JsonProperty]を見る → （知識は眠ったまま）

今回: [JsonProperty]を見る
      → 「前提条件は？」（強制的な問い）
      → 知識が起動
      → 「Newtonsoft.Jsonが必要」
      → 確認しに行く
      → 不一致を報告
対話を通じて到達したのは、個別のチェック項目ではなく、メタルールだった。
ホワイトリスト方式：

[JsonProperty] → Newtonsoft.Jsonを確認

[JsonPropertyName] → System.Text.Jsonを確認
（無限に続く）
メタルール方式：
任意の属性 → その前提条件を確認
ルールは1つ。カバレッジは網羅的。メタルールは知識を追加しない。既存の知識へのトリガーを追加する。
今回の事例が特殊だったのは、属性の空振りが「沈黙の失敗」だからだ。コンパイラ警告なし、実行時例外なし、テスト失敗なし。実行しても検出できないエラーには、知識ベースの検出が必要になる。

 AIの問題をAIに相談するAIのことはAIに聞く。 AIの限界を解決する最短経路だ。
AIは自分の知識を知っている。属性について、シリアライザーについて、前提条件について、何を知っているか知っている。知らないのはいつその知識を適用すべきかだ。だが直接聞けば—「これをチェックするには何が必要？」—答えられる。
人間はすべての属性の前提条件を列挙できない。AIはできるが、自発的にはやらない。

解決策：人間が問い、AIが答え、人間が現実と照合する。

 わかったこと「AIは知識があるのに使わない」という問題は、固定された限界ではない。起動の問題だ。知識は存在する。検索メカニズムにトリガーが必要なだけだ。
これが人間-AI協働の実践だ。プロンプトで答えを求めるのではなく、AIが既に持っている知識を適用するための構造を共に探る。
問題

対話の記録

対話の構造

なぜ機能したか

AIの問題をAIに相談する

わかったこと

Discussion
