批判的思考をClaudeスキルにしてみた｜『思い出さないと効かない原則』を自動発動に

前回の記事で、Addy Osmani の「エージェントが仕事をする時代の批判的思考」を整理した。原則はどれも良い。だが読み終えて、ひとつ引っかかった——これらの原則は、覚えておいて自分で発動する運用だと、忙しい日ほど省略される。それはエッセイ自身が指摘している「既定では何もあなたに考えさせてくれない」そのものだ。そこで、原則を Claude のスキル（SKILL.md）にして、場面で自動発動する手順に変えてみた。この記事は、その作ってみた記録——批判的思考 スキルの作り方・中身・動かし方、そして「スキル自体が儀式化しない」ための注意をまとめる。

AIエージェント基盤の全体像はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証、スキルの作法はAddy Osmani のエージェントスキル論、土台の考え方はエージェント時代の批判的思考にまとめている。今回はその原則を“動く道具”にする話だ。

なぜスキルにするのか：原則は、覚えていないと発動しない

Addy の原則（聞く前に仮説を立てる、緑のチェックが何を証明したか問う、下した決定を列挙させる…）は、実行できれば効く。問題は実行のトリガーだ。人間が「よし、今日は批判的思考モードで」と毎回思い出すのは、まさに彼が指摘する「気持ちよくて警戒を緩める」状況で破綻する。手が速くて、だいたい正しくて、二度見を求めてこない出力の前では、規律は静かに溶ける。

スキルにする利点は、トリガーを人の記憶からシステムに移せることだ。Claude のスキルは、定義された条件に合致したときに自動で読み込まれる。つまり「非自明な提案を承認しようとした瞬間」に、こちらが思い出さなくても割り込める。原則を“覚えておくもの”から“ワークフローに埋め込まれた手順”へ変える、というのが狙いだ。

作り方：descriptionが“いつ出るか”を決める

Claude のスキルは .claude/skills/<名前>/SKILL.md に置く。最重要は冒頭の frontmatter、とくに description だ。Claude はこの description を読んで「いつ自分を呼ぶべきか」を判断する。だから、効かせたい場面とトリガー語を具体的に書く。

---
name: critical-thinking
version: 1.0.0
description: "AIエージェントに作業を任せるときに、批判的思考をユーザー側に残すためのスキル。
  …認知的降伏(cognitive surrender)を防ぐ。ユーザーが『批判的思考』『認知的降伏』『丸投げ』
  『鵜呑み』『検証』『仮説』『レビューして』『これでいい？』『判断して』と言ったときや、
  /critical-thinking と打ったとき、または非自明な提案・コード・要約を承認しようとしている
  ときに発動する。…"
---

ここで意図的に入れたのが、キーワードだけでなく「非自明な提案・コード・要約を承認しようとしているとき」という“場面”の記述だ。一番効かせたいのは、ユーザーが無言で「approve で」と言いかけた瞬間だが、そこにはトリガー語が無い。場面を description に書くことで、黙って承認しかけたときにも出てくれる。

中身：6つのふるまいと出力フォーマット

本文には、エッセイの原則を実行可能なルールに落として並べた。核は6つだ——(1) 仮説を強制する、(2) 検証を透明化する（何を検証し、何を検証していないか）、(3) 下した判断を可視化する、(4) 反対意見を自発的に出す、(5) 説明可能性を確認する、(6) 認知的降伏の兆候を指摘する。たとえば仮説の強制はこう書いている。

### 1. 仮説を強制する
非自明なタスクを受けたら、本回答に入る前にまず確認する。
- 「この件について、あなたはどんな仮説（予想）を持っていますか？ 悪い予想でも構いません。」
- 仮説が無ければ、立てるよう促す。…
- 仮説を聞いてから本回答に入る。良い回答を先に読むと、他の可能性が想像しにくくなるため。

そして、重要な提案やコードを出すときの出力フォーマットを固定した。これが「検証を省いて結果だけ渡す」を物理的に防ぐ。

1. 仮説確認（必要な場合）
2. 提案内容
3. 下した判断・仮定
4. 検証したこと / していないこと
5. 残るリスク・次に確認すべき点

要約を先に出さないこと、完了通知の直後は実行したコマンドとその出力を先に見せることも書き込んだ。「できたように見える」で終わらせないためだ。

動かすとこうなる（サンプル）

たとえば「この決済リファクタの PR（600行）、問題なければ approve で」と投げると、スキルはこう返す。まず仮説を一つ聞く（「トランザクション境界は変えていないはず、で合ってますか？」）。そのうえで diff を“AI が書いていないもの”として読み、下した判断・仮定（リトライ既定を 3→5 に変更／エッジケース X はスコープ外と判断）、検証した/していない（ユニットは緑。ただし L312 の順序変更と L418 の既定値反転はテストが触れていない）、残るリスクと次の一手（L312 は二重課金を生みうる。確かめるなら統合テストを1本）を並べる。最後に 「L312 の変更を、自分の言葉で説明できますか？」 と確認して、所有権をこちらに残したまま終える。/critical-thinking と打って明示的に呼ぶこともできる。

効くのはコードだけではない。Addy も強調しているが、原則は成果物全般に効く。たとえば「50件の顧客通話をまとめて」と頼んだ要約や、競合分析、ある数字に依存した提案でも、スキルは同じ型で返す——どの元資料を確認し、どれを未確認のままにしたか、要約が元の数件と食い違っていないか、推奨が依存する数値は正しく計算されているか。文書なら「閉じて、要点を記憶から書き出せますか？」と促す。コードレビューと同じく、“読んだつもり”と“本当に読んだ”の差を、出力フォーマットで可視化するわけだ。

どこに置き、どう呼ぶか

スキルは .claude/skills/<名前>/SKILL.md に置くだけで、Claude が description を見て必要な場面に自動で読み込む。明示的に使いたいときは /critical-thinking と打てばよい。リポジトリに入れておけば、そのプロジェクトで作業するときに効く。個人の全作業に効かせたいなら、ユーザー設定側のスキル置き場に入れる手もある。いわゆる MCP クライアントをまたいで“同じ手順”を持ち運べるのも、プロンプトを頭の中に抱えるのとの違いだ。中身はただの Markdown なので、自分のワークフローに合わせて何度でも書き換えられる。これが「固定された機能」ではなく「編集できる手順」である利点だ。

作ってみて分かったこと

一番の学びは、トリガーは“語”より“場面”が効くことだ。キーワードだけだと、一番危ない「無言の承認」で発動しない。description に「承認しようとしているとき」という場面を書くことで、そこに届く。逆に、場面を広げすぎると出過ぎて邪魔になる。実際、最初は「どんな質問にも仮説を聞く」書き方にしたら、些末なやり取りにまで割り込んできた。そこで「非自明なタスク」「重要な判断」と条件を効かせ、低リスクの用途では黙って任せる、という線を description と本文の両方に入れた。Addy の言う「掛け金が低いところは丸ごと委譲してよい」を、スキル側でも尊重した形だ。

トーンの調整もいる。厳しすぎると監査官のようで使う気が失せ、甘すぎると素通りする。今回は「責めるためでなく、気づかせるため」と本文に明記し、指摘は兆候ベース（仮説なしで丸投げ／検証を見ずに承認しようとしている等）に限った。

もう一つは、冒頭の FAQ でも触れた皮肉だ。批判的思考のスキルすら、出力を読まずに流せばそれ自体が儀式になる。「仮説は？と聞かれたので適当に埋めた」「検証した/していない欄を読み飛ばした」では、降伏は防げない。だからスキルは「問いを必ず出す」ところまでしか担保できず、答えて・読んで・判断するのは人間の仕事、という線引きをスキル本文にも書いた。スキルは足場であって、思考の代替ではない。成功条件に「ユーザーの問題理解が前より鋭くなっている」を入れたのは、そのためだ。

参照ソース

• Addy Osmani『Critical thinking when agents do the work』（原典のエッセイ。ユーザー提供の本文を一次とした）
• Addy Osmani のブログ（comprehension debt・intent debt・orchestration tax などの関連エッセイ）
• Claude Code のエージェントスキル（公式ドキュメント）（SKILL.md の name/description と配置の作法）
• 当サイト関連：エージェント時代の批判的思考（本スキルの土台になった原則）／作成物 .claude/skills/critical-thinking/SKILL.md（リポジトリに追加した実物）