[翻訳] エージェント時代の批判的思考

今回の記事では、Addy Osmani の記事 Critical thinking when agents do the work を翻訳してみたい。

エージェントにコードや文書を任せることが増えたのに、返ってきた結果を本当に読んでいるのか自信がない開発者のための記事だ。委任を減らそうという主張ではない。委任しながらも判断を手放さないために著者が自分に投げかける六つの問い、緑のチェックをそのまま信じない検証の習慣、そして毎週、毎月できる練習を扱う。

Addy Osmani は Google で14年以上働き、Chrome、DevTools、Lighthouse、Core Web Vitals の開発者体験を率いてきたエンジニアで、『Learning JavaScript Design Patterns』の著者でもある。現在は Anthropic で Claude Code を作っている。原文は2026年11月3日に X の記事として公開された。

用語は原語を残した。cognitive surrender のように著者がほかの研究者から借りてきた概念には、初出のときだけ訳語を添えた。原文のリンクは残し、同じ記事を指すリンクは最初の一回だけ張った。本文で引用されている文は、それぞれの出典で文言を確認し直した。ここから下は原文を訳したもので、文中の「私」は著者である。

批判的思考が難しくなった理由

かつて批判的思考はこう教わった。新しい情報に謙虚な好奇心と適度な懐疑心で向き合い、さまざまな見方を聞いたうえで自分の意見を持つこと。今もそのとおりだ。ただ、仕事のかなりの部分がエージェントを経由するようになった今、私の日常には批判的思考を強いるものがだんだんなくなっている。agentic workflow に全面的に乗ったエンジニアやプロダクト担当者(複数のセッションを並行して走らせ、モデルがこれからも良くなると期待している人たち)に、先に言っておきたい。私はこうしたツールが大好きだ。エージェントを使うのを減らそうと言うためにこれを書いているのではない。

私の目標は、何でもエージェントに渡せてしまう世界で、あなたが批判的思考を保てるよう手助けすることだ。

かつては認知的、美的な判断の大部分が、問いと答えのあいだの時間に起きていた。その時間は今や秒単位に縮んだ。agentic workflow を使うほど、これは難しくなる(ただし、人々が予想していた形で難しくなるわけではないと思う)。モデルが良くなるほど、目につく誤りの割合が下がるからだ。多くの(ほとんどの?)出力はよく書かれていて、おおむね正しいだろう。けれども、もう一度見直す気にはさせない。

エージェントをいくつ同時に走らせても、出力を見る目は相変わらず一組しかない。

批判的思考は一日の仕事の中に自分で組み込まなければならない。放っておけば、何もそれを代わりにやってはくれないからだ。これを自分で正しにくい理由の一つは、agentic workflow が心地よいことにある。忙しい一日に、速くて楽で、たいてい正しい答えを受け取るのは爽快だ。そして、まさにそのせいで警戒を緩めやすい。

委任、判断の委ね、降伏

この話を人とするとき、私はこれを一本のスペクトラムとして説明する。

いちばん上には cognitive offloading(認知の委任)がある。作業は AI に任せるが、結果の持ち主としては自分が残る。私は一日中こうして働いている。あなたにもそうしてほしい。真ん中には deferral(判断の委ね)がある。ツールの出力がそのまま次の入力になり、結果はもはや仮説として扱われない。いちばん下には cognitive surrender(認知的降伏) がある。AI の出力が知らないうちに自分の考えになり、確かめる必要すら感じなくなる。

cognitive surrender はウォートン・スクールの Steven Shaw と Gideon Nave が作った言葉だ。私が見てきたものにぴったり当てはまる。信頼が(あるいは怠け心が)大きくなるほど、人はスペクトラムを下へと流れていく。その移動はめったに気づかれない。一歩一歩がなだらかで、もっともらしく見えるからだ。前の答えはしっかり読んだから、今回の答えはざっと目を通す。その次の答えは骨組みだけ見る。そして誰かにある一行について聞かれたとき、エージェントの助けを借りても説明できない。

それが認知的降伏だ。cognitive debt(認知負債)はこうして積み上がる。たいていは、システムについてのメンタルモデルを使おうとしたその瞬間に、そんなモデルがないと気づくことで表に出る。Margaret-Anne Storey は、これがチームの中では、システムについて共に築いた理論(shared system theory)が削られていく形で現れると書いた。私はコードの側の同じ現象を comprehension debt(理解負債、Jeremy Twei による言葉)という名前で書いたことがある。その瞬間にはまったく見えない。コードベースはきれいに見え、テストも通る。システムに手を入れなければならなくなって初めて、もう誰もそれを理解していないという事実が明らかになる。戦略文書や仕様書の目次だけ読んで承認したときも同じだ。

はっきりさせておくと、不可能なことを求めたいわけではない。大きな現代のコードベースのメンタルモデルを丸ごと頭に入れておくのは不可能だ。Claude Code チームは、理解を必要なときに組み立て直していると 公に語っている。ある部分を知る必要があるとき、全体のモデルを頭に入れておく代わりに、Claude にその一切れだけ説明してもらうのだ。以前書いたように、この種の負債はたいていのエンジニアが思うより回復しやすい。必要なときにその部分だけ組み立て直せるなら、全体のモデルを保つ必要はない。ただ、自分が何を持っていないかは知っておく必要がある。

間違っても失うものが少ない仕事なら、安心して丸ごと任せてよい。エージェントを通しても、その答えを説明できないなら、持ち主の座を明け渡したということだ。それがいつも問題だというわけでもない。少し前、講座を収録するときに、評価が同じくらいのホテル三つから撮影場所を一つ選ばなければならなかった。レビューを一つ一つ読む時間がなかったので、決定を AI に任せた。結果は問題なく、同じ状況ならまたそうするだろう。けれども、うちのお金をどこに投資するか、子どもたちに進路をどう助言するか、あるいは職場で何を作るか、どの変更がどのユーザーに届くか、リリースして安全か、を決めるときはそうしない。間違っても代償が小さいことは手渡し、その結果を他の人が引き受けることになるものでは、推論を自分の手に握っておくこと。

私が自分に投げかける問い

自分が何を考えているのか自分でもわからないとき、私はたいていこんな基本的な問いのリストに戻っていた。自分が正しい問題に取り組んでいると、どうしてわかるのか。正しいやり方で解いていると、どうしてわかるのか。自分の結論を裏づける証拠はあるか。終わったと、どうしてわかるのか。ほとんどは 誰が、何を、どこで、なぜ、いつ、どのように だ。書き出してみるとおかしいほど子どもっぽく見えるが、普段なら素通りしていた範疇まで考えさせてくれる。最近は、これをすべて飛ばしてエージェントに自分は何をすべきかと聞くのがあまりに簡単だ。今、私が自分に投げかけている新しい版の問いはこうだ。

聞く前に仮説を立てたか？些細ではない仕事にエージェントを走らせる前に、頭の中でだけでも答えが何になりそうかを書き留めておく。でたらめな推測でもかまわない。新しい情報を見て考えを変えるのはいつでも歓迎だ。けれども、よく書かれた答えを一度読んでしまうと、ほかの可能性を思い浮かべるのが難しくなる。何の手がかりもないなら、Thariq Shihipar が blind spot pass(死角チェック)と呼ぶものを頼むといい。自分が知っていることをモデルに渡し、自分が知らないことすら知らないものを見つけさせるのだ。

考えるのを手伝わせているのか、考えることを肩代わりさせているのか？どちらでもかまわない。今どちらをしているのかさえわかっていればいい。

何が事実なら、これは間違いになるのか？そして、それを自分で確かめに行くこと。モデルが自分でつけた確信度は、実際に走らせることのできるテスト一つよりはるかに価値が低い。だから、モデルにテストを一つ渡すこと。

反対の論理を別の角度から聞いてみたか？正解がはっきり決まっていない類の問題で自分が強い立場を取ったときは、二つ以上のモデルに反対側を論じさせ、その結果を読んでから自分の意見を固める。時間はかかるが、そのテーマについてずっと多くを知ることになる。

これを保守する人の前でも、これが正しいと賭けられるか？コードにも、自分が世に出すほかのあらゆるものにも当てはまる。私はこれが、自分の仕事について説明責任を果たせるかどうかの基準線だと考えている。

私はもう何を練習していないか？日常的なデバッグの一部かもしれない。その一部は手放してもかまわない。ただ、それが意図したものであってほしい。

習慣としての検証

最近、私は検証についてたくさん書いている。ボトルネックが、コードを書くことから自分が正しいと確信することへ移った と信じているからだ。エージェントに自分の作業を検証する手段を与えれば(end-to-end テストでも、property テストでも、実際にアプリを操作してみることでも)、エージェントは私が何も見ないうちに変更を加え、検証を走らせ、出力を読み、もう一度試すことができる。Boris Cherny が 「Claude に自分の作業を検証する方法を与えよ」 と呼んでいるのがこれで、私はこれが良い結果を得るうえで最も重要な要素の一つだと考えている。すべての行を読む代わりに、こうしたループを作り、その証拠をレビューすることになる。

検証でも降伏は起こりうる。「自分の結論を裏づける証拠はあるか」が「チェックは緑になったか」に置き換わる。エージェントのおかげでテストを作るコストがとても安くなったので、緑をたくさん見ることになるだろう。だが、壊れた機能を捕まえられないテストが通っているかもしれない。テストと機能に同じ間違いが入っていれば、テストは通る。そして緑のチェック一つが教えてくれるのは、一つの性質だけだ。それなのに、それがすべてを覆っていると思い込むのはあまりに簡単だ。

チェックが緑になったら、それが何を証明したのかを問うこと。そして何を証明しなかったのかを問うこと。「検証済み」の定義は前もって決めておくこと。結果が出てから決めると、どんな結果でも正当化してしまう。

エージェントの作業のゴールラインは、手に取れるものであるべきだ。通ったテスト、スクリーンショット、ログや trace といったものだ。そうすれば、終わったという基準が事実になり、「もうできていそうだ」といった解釈(そして降伏)に委ねられずに済む。エージェントから完了通知を受け取ったら、要約を見る前に、実行されたコマンドのコードとその出力から確認すること。

Claude Code は、新しいコンテキストで立ち上げた subagent に自分の作業を批判的に見直させ、基本的なチェックをすることもできる。これをループの中に組み込み、自分が思い出したときだけでなく毎回走るようにしておく価値がある。私は最後に今でも「何か見落としていないか」と聞く。ばかげて見えるかもしれないが、frontier モデルで複雑な機能の作業を終え、自分で見てレビューしたあとに「何か見落としていないか」と聞くと、本当によく二つ三つ追加で返ってくる。だから私はいつも聞く。

もちろん、このすべてを毎回やる必要はない。いつ深く入るべきかを知るのも技術だ。Claude Code チームがコードレビューをどう行っているかをまとめた私たちの記事の中で、私がいちばん好きな経験則はこれだ。「チェックが何を見逃すかを言えないなら、手早い承認ではなく、ちゃんとしたレビューを頼むこと」。

これはコードの外にも当てはまる。エージェントが顧客との通話50件や競合分析をまとめてくれたなら、元の文書を二つ三つ自分で開いて、要約が正確か確かめること。自分の提言の根拠になる数字を一つ選んで、正しく計算されているか確かめること。エージェントのおかげで検証を用意するのは安くなった。難しいのは、良い検証がどんな姿をしているかを知ることだ。

生成されたものを実際に見る

エージェントが600行の PR を出してきたとしよう。構造をざっと眺める。すべての行は読まない。変数名ももっともらしく、テストも通っているので承認する。ところが、その真ん中あたりのどこかで、トランザクション境界の順序が微妙に変わっていたり、一度も考えたことのない edge case のデフォルト値がひっくり返っていたりする。レビューはしたことになる。ただ、もともと見つかるとわかっていたものしか見ていなかっただけだ。

コードを書くこととレビューすることは別の技術で、レビューが rubber stamping(形だけの承認)に変わる地点がある。だから diff は AI が書いたのではないつもりで読み、そのうえで diff の向こうでエージェントが何を決めたのかを見ること。長いセッションのあいだ、エージェントは小さな決定をたくさん代わりに下している。デフォルト値を何にするか、何を範囲外にするか、二つの要件がぶつかったときにどちらを解釈し直すか、といったことだ。

「すべてうまくいきました」という要約には、そのどれも見えない。だから、エージェントに自分が下した決定と前提を列挙させること。そのうえで自分にクイズを出すこと。適当な行をいくつか選び、「この行は?」「あの行は?」と聞いてみるのだ。文書なら閉じてから、核となる論旨を記憶だけで書いてみること。長いセッションで一部の人が使っている習慣で、私が気に入っているものがある。Claude に変更のレポートを書かせ、いちばん下にクイズを出させたうえで、「クイズに満点で合格したときだけマージする」というルールを置くのだ。リリースするものを弁護できるくらいには理解しておくこと。いつか誰かに聞かれるかもしれないのだから。

エージェントは注意力を守るのにも使える。たとえば私がメンテナンスしているオープンソースプロジェクトには PR がたくさん来る。エージェントの助けを借りて、何が来ているのか、何がガイドラインに反しているのか、どこに私の注意が必要そうかを見分ける。その判断をエージェントに単独で下させることはめったにないが、私が集中すべき場所を絞り込んでもらうことはできる。そうすれば私は、その変更が正しい問題を正しいやり方で解いているかを実際に考えられる。

そして量の問題がある。これは自分に正直でなければならない。私はこれを orchestration tax(調整コスト)と呼んだ。エージェントが生み出す量と、自分の名前を出しても平気だと感じられる量とのあいだの差だ。終わった作業が自分の消化できる速さより速く積み上がっているなら、それを直すまではセッションをもう一つ開いても役に立たない。チェックを締めて自分が見るべき量を減らすか、ペースを落とすこと。自分が責任を持てるより多くを生み出しているなら、それはもうレビューではない。運任せだ。

良い入力、良い出力

人間のメンタルモデルは今も関わっている。ただ、その位置が真ん中ではなく前と後ろになった。エネルギーを前段のタスク説明とコンテキストに、そして後段の出力レビューに注ぐことになる。だから良い入力が出力の品質にそれほど重要なのであり、私は良いプロンプトを書くことを批判的思考の技術だと見ている。

以前は曖昧な頼み事をすると誰かがそれを問い返し、そうするうちに「あ、自分はこれを実はまだ整理できていなかった」と気づいたものだ。エージェントはそこで止めてくれないことが多い。抜けている部分を勝手に埋め、根っこの考えはぼやけたままなのに、出来上がったように見える結果を差し出す。私はこれを intent debt(意図負債)という名前で書いたことがある。自分が書いていない成果物の中に潜んでいるかもしれない、暗黙の目標、制約、根拠のことだ。ほかの負債と違って、これは誰も代わりに返してくれない。意図は自分から出てこなければならない。

プロンプトは、問題をどれだけ理解しているかを映す。それをはっきり言えないなら、自分の頭の中でもはっきりしていないのかもしれない。助けを求める前に、依頼の概要を自分の言葉で書くこと。対象の読者、範囲外のもの、完了の定義を書く。二回目の修正依頼でも望むところにたどり着けなかったら、少しずつ直すのをやめてプロンプトを書き直すこと。

これにもエージェントの助けを借りられる。私は Andy Clark が AI システムに委任することと、協働することを区別したやり方が好きだ。協働では、互いを高め合う好循環に入る。プロンプトが出力を磨き、その出力が次のプロンプトを磨き、問題についてのメンタルモデルまで磨く。整理できていないなら、エージェントが理解できていないことについて、エージェントに自分をインタビューさせること。セッションを閉じるとき自分のメンタルモデルが磨かれていれば、うまくいったしるしだ。

入力にも気をつけること。エージェントが前のエージェントの要約だけを自分のコンテキストとして受け取ってしまいがちだ。そうしているうちに、三番目のエージェントは元の文書を一度も読んでいない状態になる。

出力についての自分なりの基準も必要だ。私はさまざまな創作の媒体で AI をあれこれ試してきたが、そのほとんどは自分の基準に届かなかったので誰にも見せていない。すべてがきれいな書式と自信のある口調で出てくるので、なめらかさはもう役に立つシグナルではない。AI のおかげで作る速さは上がったのかもしれない。それでも、その成果物を自分の名前で出すのが落ち着かないなら、出さない。

基準に届かないものがあれば、その理由を共有設定や hook、テストに書き残し、二度と起きないようにすること。センスはそうやって積み上がる。そして、何がなぜ落ちたのかを書くこと自体が良い練習になる。

「それでもモデルのほうが私よりうまくなるだろう」

この分野の未来を私の周りの多くの人と同じくらい楽観しているなら、ここまでのいくつかの節を読みながらこう思ったことだろう。1、2年もすれば、私が見つけられるものはモデルも見つけられるようになる。それなのに、なぜわざわざその技術を保たなければならないのか。

その検出のかなりの部分については、あなたが正しいのかもしれない。私自身、検出をますますエージェントに任せようと主張してきた。それでもこれが今なお重要だと考える理由はこうだ。結局、リリースされるものには誰かが責任を負う。AI がどれだけ手伝ったとしても、人間が責任を負わなければならない。

ある仕事でエージェントをどこまで信頼するかは、それ自体が判断の問題だ。その判断の目盛りを合わせておくことの一部が、作業をレビューすることだ。モデルが間違える場所は変わり続けるからだ。Anthropic が自社のエンジニアと研究者を対象に行った研究も、この落とし穴を指摘しながら paradox of supervision(監督のパラドックス)と呼んでいる。「Claude を監督するにはまさにそのコーディング技術が必要なのに、その技術は AI を使いすぎると衰えるかもしれない」。

私にとって最も大切で、より良いモデルが解決してはくれないものがある。何を作るのか、なぜ作る価値があるのか、誰に影響するのか、何を進んで手放すのか。どれもあなたが答えなければならない問いだ。エージェントはその答えを探るのに役立つことがあるし、私もそうであってほしいと思う。けれども結局、その問いは今もあなたのものだ。仕事は手渡せるし、チェックのかなりの部分も手渡せる。しかし責任は手渡せない。

日々の練習

このすべてを厳格にやる必要はない。自分の働き方に合うものだけ組み込めばいい。

週に一度は、エージェントなしで少しコードを書くか、やり方を忘れたら困る実際の仕事を一つ自分でやってみること(私はこれを calibration exercise(目盛り合わせの練習)と呼んだが、説教をしたいわけではない)。月に一度は、自分がやめたことを書き出し、そのうちどれをやらなくても大丈夫かを決めること。以前のブログ記事の問いの一つは、今もそのまま有効だ。AI がなかったら、私はどれだけ途方に暮れるだろうか。

理解できないものがあれば、学びに行くこと。文章を書いていて初めて見る表現に出会ったら、Google で一行の説明を探して入れることもできる。私はもう少し調べてきちんと理解するほうを選ぶ。そうすれば、それがどこに収まるのかが見える。

機械がやったことをきちんと確かめるのは、本物の仕事だ。そうではないふりをすると、チームは結局それをやらなくなる。タダではないので、スケジュールに一つの項目として入れておくこと。そうすれば実際にやることになる。

使わない技術は消えていく。おそらく思ったより早く。手放したくない技術は使い続けること。

持ち帰るもの

• 意図的に設定する: エージェントはクイズを出し、インタビューし、証拠を見せることができる。ただし、そう設定したときだけだ。だから設定すること。
• スペクトラム上の自分の位置に正直である: エージェントの助けを借りても答えを説明できないなら、その答えに降伏したということだ。
• 仮説を立てる: でたらめでもいいので、聞く前に一つ立てる。
• 緑のチェックが意味するのは一つだけ: 何を確かめたのか。何を確かめていないのか。
• 証拠を探す: 要約を読む前に、何を実行し何が返ってきたのかを読む。
• どんな決定を下したのかを読む: エージェントは私の代わりに何を決めたのか。
• プロンプトを磨く: プロンプトをどう書くかが、問題をどれだけ理解したかを示す。
• 基準を決めて守る: 自分の名前を出せないなら、外に出さない。

大事な技術は自分で使いながら手放さないこと。試してみる価値のあることを一つ勧めたい。聞く前に何が起きるかを書き、エージェントが終わったあとには、エージェントが確かめなかったことを一つ書くこと。それで出力の読み方が変わるかどうか教えてほしい。自分の頭で考えること。より良い問いを立てること。結果に責任を持つこと。

筆者の考え

AI が重要なのは明らかだ。それでも今、筆者が先に選びたいのは技術スタックを広げることではなく、考える力と判断の基準を作ることだ。

著者が警戒する cognitive surrender は、判断をエージェントに明け渡してしまうことだ。筆者も AI と自動化ツールを積極的に使うが、思考そのものを任せるより、思考の生産性を上げる方向で使いたい。この優先順位をなぜそう決めたのかは、考えを証明するプロセスに別途書いた。