AIエージェント時代に批判的思考をどう保つか｜滑落の見分け方・検証OSS・作り方まで

AIエージェントに仕事の多くを通すようになった今、ひとつ見落とされがちな問いがある——「批判的思考は、いつ・どこで起きているのか？」。元 Google Chrome のエンジニアリングリーダーで、現在は Anthropic の Member of Technical Staff である Addy Osmani のエッセイ「Critical thinking when agents do the work（エージェントが仕事をするときの批判的思考）」は、そこを突いて話題になった。AIは答えを速くした。問題は、速くなったぶんだけ「考えない時間」も速くなったことだ。主張の芯はシンプルだ——仕事の多くがエージェントを通るようになった今、既定では何もあなたに批判的思考を強いてこない。だから自分で日々に組み込むしかない。この記事は、その内容を咀嚼し、AIエージェント 批判的思考の“保存版”として、滑落の見分け方・検証の習慣・聞く前の自問・現場で使えるOSS・そして「批判的思考を組み込んだエージェントの作り方」までを、図解多めで整理する。

AIエージェント基盤の全体像はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめている。関連して、スキルの作法はAddy Osmani のエージェントスキル論、そして本記事の原則を実際に“自動発動するスキル”へ落とした記録は批判的思考をClaudeスキルにしてみたで扱った。今回はその土台にある「人間の思考をどこに残すか」の話だ。

なぜ今、AIエージェント時代に批判的思考は「自動では起きない」のか

かつて、認知と美的判断の多くは質問と答えのあいだの空間で起きていた。その空間が、いまは秒で測られる。Addy が指摘する難しさは、多くの人の予想とは逆向きだ。モデルが良くなるほど、明らかな誤りの割合は下がる。出力の多く（ほとんど？）は、よく書けていて、だいたい正しく、二度見を求めてこない。だから警戒を緩めやすい。しかも何体ものエージェントを並列で走らせても、出力を見る目は結局ひと組しかない。

ここで彼はスペクトラムを示す（冒頭の図）。上が認知のオフロード（タスクは任せるが結果の所有権は自分が持つ＝彼も一日中やる、推奨される使い方）。中がディファーラル（ツールの出力がそのまま自分の次の入力になり、結果が“仮説”であることをやめる）。下が認知のサーレンダー（AI の出力が静かに自分のものになり、確認の必要を感じなくなる）。滑り落ちるのは気づかれにくい。各ステップが少しずつで妥当に見えるからだ。よく読んだから次は斜め読み、その次は骨組みだけ——そして、ある行について問われて、エージェントの助けを借りても説明できなくなる。これが理解の負債として積み上がり、コードベースは一見きれいでテストも通るのに、いざ変更しようとして「もう誰も分からない」と気づく。

彼は「無理を説いているのではない」とも言う。巨大な現代のコードベースの全体像を頭に保ち続けるのは不可能だ。必要なときにその一部をモデルに説明させて理解をオンデマンドで再構築するやり方で十分——全体を保つ必要はないが、“自分が何を持っていないか”は知っておく必要がある、という線引きだ。つまり目標は「全部を覚える」ことではなく、「どこを手放したかを把握しておく」ことにある。言い換えれば、覚えるべきは地図ではなく、“地図の空白”の位置だ。

この記事に出てくる言葉（ひとことの定義）

良い議論は、たいてい良い名付けから始まる。本記事と出典のエッセイで鍵になる言葉を、まずひとことで押さえておく——ここを握れば、以降の話は速い。

あなたは今どこ？批判的思考の“滑落”セルフチェック

スペクトラムは概念だが、日々の実感に落とすと「サイン」として現れる。下の図は、降伏のサイン（こう感じたら危ない）と、所有権を取り戻す一手（こう戻す）を左右で対にしたものだ。右の列は、どれも数十秒でできる。

ポイントは「自分がスペクトラムのどこにいるか、正直になる」ことだ。基準は一つ——説明できるか。ある変更・ある結論を、エージェントの助けを借りても自分の言葉で説明できないなら、あなたはもう降伏の側にいる。逆に言えば、サインに気づいた瞬間に右の一手を一つ打てば、オフロード（＝推奨される使い方）に戻れる。完璧である必要はない。気づいて、戻す。これを習慣にするのがこの記事全体の狙いだ。

検証を習慣にする：緑のチェックは一つのことしか示さない

Addy は近ごろ「検証（verification）」について多く書いている。ボトルネックがコーディングから『自分が正しいと確かめること』へ移ったからだ。

エージェントに検証手段（e2e テスト、プロパティテスト、実際のアプリ操作）を与えれば、変更→検証→出力を読む→再挑戦を、あなたが何かを見る前に回せる。Boris Cherny の言う「Claude に自分の作業を検証する手段を与える」で、Addy はこれを最良の結果を得る最重要要素の一つだとする。一行ずつ読む代わりに、このループを組み、証拠をレビューするのだ。

ただし検証も“降伏”できてしまう。「結論を支える証拠はあるか」が「チェックは緑になったか」にすり替わる。エージェントはテスト作成を安価にするので、緑はいくらでも出る。だが機能とテストに同じ誤りが入っていれば、そのテストは通る。緑は一つの性質しか伝えないのに、全部を覆っていると錯覚しやすい。緑は「動いた」を証明する。「正しい」は証明しない。だから——緑が出たら、それが何を証明し、何を証明しないのかを問う。「検証済み」の定義は“事前”に決める（後からだと、どんな結果も正当化してしまう）。完了の基準は、テスト通過・スクリーンショット・ログ/トレースといった具体物にして、「できたように見える」で終えない。そして完了通知が来たら、要約を読む前に実行したコマンドとその出力を先に見る。

生成物に注意を向ける：レビューがゴム印に変わる地点

600 行の PR が来たとする。構造をざっと見て、変数名は妥当でテストも通るから承認する。でも真ん中あたりに、トランザクション境界の微妙な順序変更や、考えたこともないエッジケースでの既定値の反転が潜んでいる。あなたは確かにレビューした——ただし、自分が見つけると分かっていたものだけを。書くことと読む（レビューする）ことは別のスキルで、レビューがゴム印に変わる地点がある。

対策は具体的だ。diff を、AI が書いていないものとして読む。そして diff の先、エージェントが何を“決めた”かを見る。長いセッションで、既定値・何を対象外にしたか・要求が衝突したときどちらを再解釈したか——エージェントは小さな決定を山ほど下している。「すべて順調」という要約にはそれが出てこないので、下した決定と置いた前提を列挙させる。そして自分を小テストする。数行を無作為に選び、「この行は？」と問う。文書なら、閉じて要点を記憶から書き出す。Addy が好む運用は、「変更のレポートを書かせ、末尾に小テストを付けさせる。満点で合格するまでマージしない」というものだ。

量の問題にも正直になる、と彼は言う。生成される量と、自分の名前で出せる量の差——彼はこれをオーケストレーション税と呼ぶ。片づかない成果物が溜まっているなら、もう一つセッションを足しても解決しない。チェックを締めて自分の手を減らすか、速度を落とすかだ。レビューが祈りに変わるのは、読む速さより、出てくる速さが上回った瞬間だ。自分が立てる以上に生産しているなら、それはもうレビューではなく“祈り”だ。

聞く前に自分に問い、良い入力を作る

Addy は、昔の「正しい問題か」「正しい解き方か」「結論を支える証拠は」「終わったとどう分かるか」という素朴な問いを、エージェント時代版に置き換えた。聞く前に仮説を立てたか（予想を書く。悪くてよい）。助けさせているのか、肩代わりさせているのか（どちらも可、ただし自覚する）。これが間違いなら何が真でなければならないか（そして確かめに行く。モデルの自己申告の確信度より、回せるテストの方が価値がある）。反対の論を別角度で聞いたか（別のモデルに逆の立場を述べさせ、自分の意見を作る）。維持する人の前でこれに賭けられるか（answerability の基準）。自分は何を練習しなくなったか（手放すなら、意図的に）。

そして入力の質だ。彼はプロンプトを批判的思考のスキルとみなす。昔は曖昧な依頼を誰かが突っ込んで、「あ、自分は分かっていなかった」と気づけた。エージェントはそこで止めてくれず、欠けを埋めて“できあがったもの”を返す。背後のアイデアがぼんやりしたままでも。これを彼は意図の負債（intent debt）と呼ぶ——他人には直せない、意図は自分から出すしかない負債だ。だから、助けを求める前に、自分の言葉で依頼ブリーフを書く。読者・対象外の項目・完了の定義を書く。2 巡目の修正でも届かないなら、いじるのをやめてプロンプトを書き直す。これは「委譲」ではなく「協働」で、良いプロンプトが出力を鋭くし、次のプロンプトと問題の心的モデルを鋭くする好循環になる。プロンプトは、あなたの問題理解の映し鏡だ。

現場で使えるOSS：検証・評価・可観測性で批判的思考を支える

原則を「気合い」で続けるのは難しい。幸い、検証・評価・可観測性を仕組みにするOSSが育っている。どれも「緑のチェックを増やす」だけに使えば降伏の入口になるが、“何を検証したか/していないか”を構造として残す使い方をすれば、批判的思考の足場になる。テーマに直結する代表例を、一次情報（公式リポジトリ）で確認して並べる。

使い分けの目安はこうだ。出力の良し悪しを自動で採点したいなら promptfoo / DeepEval / Ragas（Ragas は RAG に強い）。攻撃に耐えるか（注入・脱獄）を見たいなら promptfoo / Giskard のレッドチーム。本番でエージェントが実際に何をしたか追いたいなら Langfuse のトレース。いずれも「評価データセットを事前に定義し、結果を後から正当化しない」という、この記事の原則そのものを運用に落とす道具だ。なお star・ライセンスは変わりうるので、採用時は各リポジトリの LICENSE と README を自分で確認してほしい（READMEの公称値をそのまま信じない、は批判的思考の実践でもある）。

AIエージェント 批判的思考の作り方：最小ループに組み込む

最後に「作り方」だ。フレームワーク（比較記事で LangGraph・CrewAI・AutoGen 等を検証した）は何を使ってもいいが、批判的思考を“後付けの心がけ”でなく、ループの構造に埋めるのが肝になる。下の図は、その最小ループだ。

各ステップを“構造”として持たせる。つまり、エージェントのプロンプトや出力スキーマに、次の4つを必ず出す欄として作り込む——(1) 仮説（着手前）、(2) 検証したこと/していないこと、(3) 下した判断・置いた前提・スコープ外、(4) 残るリスクと「人が確認すべき点」。擬似コードで書くと、ループはこうなる（フレームワーク非依存の骨組み。実際には各 llm() 呼び出しをお使いの基盤に差し替える）。

# 骨組み（擬似コード）: 批判的思考を“欄”として強制するエージェントループ
def run(task):
    hypothesis = llm(f"着手前に、答えの予想を1行で。悪い予想でよい: {task}")
    plan   = llm(f"仮説 {hypothesis} を踏まえた実行計画を箇条書きで")
    result = execute(plan)                 # ツール/MCPで実行
    checks = verify(result)                # e2e・プロパティテスト・実アプリ操作

    # 完了通知より先に「実行と出力」を人へ見せる
    report = {
        "did": checks.ran_commands,        # 実行したコマンドと出力
        "verified": checks.passed,         # 何が緑になったか
        "NOT_verified": checks.untested,   # 何を検証していないか（空にしない）
        "decisions": result.decisions,     # 下した判断・前提・スコープ外
        "risks": result.open_risks,        # 残るリスク
    }
    return require_human_signoff(report)   # 説明責任は人間に残す

ここで大事なのは NOT_verified（検証していないこと）を空にしないことと、最後の require_human_signoff を省略しないことだ。緑だけを返すエージェントは“祈り”を量産する。検証欄と判断欄を強制し、人の承認で閉じる——これだけでループの性質が変わる。評価は前節のOSS（promptfoo / DeepEval 等）を verify() に差し込めばよい。トレースを Langfuse に流せば、「このエージェントが実際に何を決めたか」が後から追える。

そして、この一連の“手順”そのものを持ち運びたくなったら、プロンプトに毎回書く代わりにスキルとして外出しできる。実際に本記事の原則を Claude のスキル（SKILL.md）にして、承認しかけた場面で自動発動させた記録が批判的思考をClaudeスキルにしてみただ。エージェントの“記憶”をどう持たせるかはdeja-vuでも扱っている。道具立ては揃いつつある——足りないのは、ループの最後に人を置き続ける設計だ。

モデルが上手くなっても、責任は移せない

「1〜2年でモデルが自分の検出能力を超えるなら、スキルを保つ意味は？」——Addy はこの反論を正面から受ける。検出をエージェントに寄せること自体には彼も賛成だ。だが、最終的に出荷物の責任は人間が負う。

どのタスクをどこまで信頼するかの判断自体が人間の仕事で、モデルが間違える箇所は変わり続けるから、較正のためにレビューを続ける必要がある。彼は Anthropic 自身の研究が呼ぶ監督のパラドックスを引く——「Claude を監督するには、AI の使いすぎで衰えかねないコーディング能力そのものが要る」。何を作るのか、なぜ価値があるのか、誰に影響するのか、何を犠牲にするのか。これらはより良いモデルが解いてくれない、あなたの問いだ。作業と監査の多くは手放せても、説明責任は手放せない。

実践は重くなくていい。週に一度、エージェントなしでコードを少し書く（忘れたら困ることを一つ手でやる＝較正の運動）。月に一度、やめたことを書き出し、手放してよいものを決める。古い問い「もし AI が無かったら、自分はどれだけ途方に暮れるか？」は今も有効だ。そして「機械をちゃんと点検するのは本物の仕事」であって、無料ではない——だから予定に“項目として”入れる。使わなくなったスキルは、思うより速く失われる。手放したくないものは、やり続ける。モデルは答えを肩代わりできる。だが、その答えに名前を貸すのは、最後まであなただ。

参照ソース

• Addy Osmani『Critical thinking when agents do the work』（本記事の出典。原文のエッセイ。ユーザー提供のスクリーンショットと本文を一次とした）
• Addy Osmani のブログ（comprehension debt・intent debt・orchestration tax などの関連エッセイ）
• promptfoo（公式リポジトリ） ／ Langfuse ／ DeepEval ／ Ragas ／ Giskard（star・ライセンスは2026-11-04時点で各リポジトリのトップページを確認）
• 用語の出どころ（Addy が引用）：認知のサーレンダー＝Wharton の Steven Shaw・Gideon Nave／監督のパラドックス＝Anthropic のエンジニア・研究者に関する研究