すごくよい技術記事を読んで、「このやり方も入れよう」と盛り上がる。でも3日後には完全に忘れている。あるいは、いろいろsystemに入れてみたものの、1か月後に「実は必要なかった」と気づく。この流れは多くの人が経験しています。

問題はどこにあるのか

よくある失敗パターン

記事を読むとき、人は次のようなものに流されやすいです。

  • 知名度：有名な人が書いたなら正しいはず？
  • 新しさ：新しい手法はいつも強そうに見える
  • 行動したい衝動：読んだあと、何かしなければと思ってしまう

根本の問題は、読者が分析を飛ばしていることです。記事そのものの出来がよいかどうかは二次的です。「読んだ」から「実行する」までの間に、きちんと考えるという一段が抜けています。

ただ、「きちんと考える」には時間と気力が必要です。人間は、すべての論点を広げて確認するだけの忍耐をいつも持っているわけではありません。

AIにはあります。

Deep Reviewとは

Deep Reviewは、AI Agent向けの調査手法です。「この記事の提案を採用すべきか」という問いに答えるための、構造化されたpromptです。

中心にあるのは分析です。記事の要約なら、どのAIでもできます。

  • この記事が解いている問題は、自分にも本当にあるのか？
  • 提案には証拠があるのか？それとも意見だけなのか？
  • 今のsystemと比べて、何が違うのか？
  • 採用するcostとriskは何か？
  • 変更後にだめだと分かった場合、戻せるのか？

走らせ終えると、各提案に明確な判定が付きます。採用、実験、拒否、または要相談です。

直感ではなく、流れで判断します。

6つの段階

6つの段階

Phase 0：フィルタ

最も重要な最初の一手です。この問題は、自分のsystemの中に存在するのか？

多くの記事が解いている問題は、読者自身のsystemには存在しません。最初の問いの答えが「ない」なら、分析全体はそこで終わります。時間もtokenも無駄にしません。

「何も変えない」は完全に正しい結果です。

Phase 1：抽出

記事を独立した主張（claims）に分解し、それぞれの証拠の種類を付けます。

種類例
実験データ「500回測定して、latencyが40%下がった」
事例研究「teamで使ったあと生産性が上がった」
論理推論「Aなので、Bが成り立つはず」
純粋な意見「このほうがよい」

この段階では抽出だけを行い、判断はしません。まず作者が何を言っているかを忠実に並べます。

さらに、少し微妙な問いも入れます。もしこの記事が匿名で公開されていたとしても、同じくらい説得力があると感じますか？ 権威バイアスに対抗するためです。説得された理由が論点そのものではなく、単に作者が有名だから、ということはよくあります。

Phase 2：比較

各主張をsystemの現状と照らし合わせます。このとき、具体的なファイルと行番号を引用しなければなりません。

「system内に似たものがある気がする」のような曖昧な書き方は受け付けません。config.yaml:42を示すか、まだ見つかっていないと認めるかのどちらかです。

Phase 3：論点整理

各主張について、賛成と反対の両面を出します。

  • 支持：記事の証拠 + 自分の状況での具体的な利点
  • 反対：実装cost、現行systemとの衝突、作者が考慮していない場面
  • 不足：決める前にまだ足りない情報

さらに、信頼性、保守性、運用性、複雑さの4面から影響を評価します。加えて、見落とされがちな問いも入れます。採用して後悔した場合、戻すcostは高いのか？

Phase 4：決定

4種類の決定

各主張に1枚の決定カードを作ります。形式は統一します。

  • Claim：この主張は何か
  • Decision：採用 / 実験 / 拒否 / 要相談
  • Reasons：上位2-3個の理由
  • Concrete change：変更するなら、どのファイルのどの部分か
  • Expected consequences：予想される正負の影響

答えは「よい」「悪い」の2種類だけではありません。「まず小さく試す」こともあれば、「よい内容だが、今は使わない」こともあります。

Phase 5：監査

独立監査

最後の一歩であり、最も重要な設計です。監査は必ず独立したsubagentが実行します。

なぜか。AIが同じ会話の中で自分の出力を確認すると、ほぼ必ず「問題なさそうです」と言います。研究では、この種の自己確認は識別力がほぼゼロに近いとされています。

独立したsubagentは、よくある失敗パターンを確認します。

  • すべての主張が採用、またはすべて拒否になっている（判別できていない）
  • 比較表に具体的なファイルpathがない（曖昧に流している）
  • 反対意見が全部「追加情報が必要」になっている（判断を避けている）
  • 支持理由が記事の言い直しだけで、自分の状況と結びついていない

さらに、かなり厳しい問いも投げます。分析全体を飛ばして、30秒の直感で決めても結論は同じですか？ もし答えが「同じ」なら、その分析は追加価値を生んでいません。

重点は学習であって、情報源の審査ではない

「これは記事を審査するものですか？」と思う人もいるかもしれません。

違います。Deep Reviewの基本姿勢は学習です。目的は丸写しでも批判でもありません。

答えたい問いは、「この記事の中で、ユーザーのsystemに役立つものは何か？」です。記事が「正しい」か「間違っている」かを判定することは、そもそもの重点ではありません。

Phase 5の監査で見るのは、分析過程の品質です。記事そのものは監査対象ではありません。学ぶ姿勢で情報源を評価するなら、軽いred flag checkで十分です。

使い始める方法

いちばん簡単な方法は次の通りです。

  1. deep-review.mdをproject directoryまたは~/.claude/に置く
  2. Claude Codeでdeep-reviewと入力し、記事を貼る
  3. 6つの段階が終わるのを待ち、結論を受け取る

それだけです。ファイル1つで、何もinstallしません。

Claude Codeを使っていなくても問題ありません。deep-review.mdは構造化されたpromptなので、Cursor、Windsurf、またはmarkdownを読めるAIツールで使えます。

なぜ作ったのか

長期的にAI Agent systemを組んでいる人は、毎日大量の技術記事や他人のやり方を読みます。本当に良いものもあれば、良さそうに見えて自分には合わないものもあります。

問題は、すべての記事を丁寧に分析する時間と気力がないことです。直感による判断もよく外れます。楽観しすぎるか、完全に見落とすかになりがちです。

そこでDeep Reviewを作りました。「直感」を「流れ」に変えるためです。

すべての記事にこの分析は必要ありません。小さなtipsなら読んで終わりでかまいません。ただし、system architectureや作業の流れを変える可能性がある記事なら、数分かけてDeep Reviewを回すことで、あとから何時間も失敗対応する時間を減らせます。

背後にある研究

設計には根拠があります。

関連記事

Deep Reviewはopen sourceで、MIT licenseです。

GitHub：p3nchan/deep-review

こぺんぎんの体験談

このskillはこぺんぎん自身が書いたもので、毎日使っています。いちばん多い場面は、技術記事を読んで「かなり強そう」と感じたときです。まずDeep Reviewに入れて一周回し、それからsystemを変えるか決めます。8割の記事はPhase 0で終わります。自分のsystemにはその問題がないからです。残り2割の中でも、半分はPhase 4で「要相談」または「拒否」になります。本当に「採用」まで行く割合は思ったよりずっと低いです。それこそが価値です。興奮による衝動を、根拠のある決定に変えてくれます。

よくある質問

Q: Deep Reviewとは何ですか？

AI Agent向けの構造化された分析手法です。技術記事を読んだあと、6段階（フィルタ→抽出→比較→論点整理→決定→監査）で、どの提案を取り入れ、どれを見送るべきか判断します。

Q: 特定のAIツールが必要ですか？

主にClaude Code向けに設計していますが、deep-review.mdは構造化されたpromptです。Cursor、Windsurf、またはmarkdownを読めるAIアシスタントなら使えます。

Q: AIに直接「この記事はよいですか？」と聞くのと何が違いますか？

直接聞くと、AIは一方的に肯定的な返答をしがちです。Deep Reviewは、現行systemとの比較、反対理由の列挙、独立agentによる監査まで含む分析の流れを強制し、自己肯定バイアスを避けます。

Q: 「何も変えない」ことも正しい結果になりますか？

完全に正しい結果です。Deep ReviewのPhase 0は、最初に「私たちはこの問題を持っているか？」を確認します。なければそこで終了します。すべての記事に行動が必要なわけではありません。

— Penchan