世界を動かす技術を、日本語で。

考えることを真剣にするのが恋しい

概要

  • 思考力 の重要性と希少性についての自省
  • BuilderThinker という二重性の自己分析
  • AI 時代における葛藤と成長実感の希薄化
  • 実用主義 と創造的思考の間でのジレンマ
  • 今後の 自己探求 と未解決感

本当に「考える」ことについての問い

  • 「最後に本気で 考え抜いた のはいつか?」という自己問答
  • 単なる作業や表面的な思考ではなく、 数日間悩み抜く 体験の希少性
  • 常に考えている人、全く考えない人、その中間層という分類
  • 筆者自身は 中間 に属する自覚
  • 本投稿は 回答や提案 ではなく、単なる心情の吐露

BuilderとThinkerという二重性

  • 筆者は Builder (作り手)と Thinker (思索者)の二面性を自認
  • Builder :実用性やスピード重視、アイデアを現実化する喜び
  • Thinker :深い問題に長時間取り組むことへの渇望
  • 大学時代の 物理学の難問 で顕在化したThinker気質
  • 問題解決アプローチの違いによる学生の分類
    • 大多数:すぐに 諦めて助けを求める
    • リサーチ型: 文献調査 で類似解法を発見
    • Thinker型: 徹底的に自力で考え抜く 希少な存在
  • Thinker型であることへの 誇りと満足感

AI時代と成長実感の希薄化

  • ソフトウェアエンジニア としての成長実感は「難問解決」と「創造」にあった
  • 近年は AIの進化 で深く考える時間が激減
  • 生産性は向上したが、 思考の飢餓感 が増大
  • 「Vibe coding」=Builderとしての即時的な満足感
  • しかし 創造的な問題解決 の機会が激減
  • Builder気質だけの人には最適な時代
  • Thinker気質には 物足りなさ と喪失感

実用主義の罠とジレンマ

  • 「AIで解ける問題はそもそも 難しくない」という意見への反論
  • AIの出す 70%解答 で十分な場合が多く、非効率な手法に戻れない現実
  • Builder としての合理性と Thinker としての満足感の間での葛藤
  • AI時代において 両者を同時に満たす ことの困難
  • より難しい課題を求めてみても、 創造的思考 の出番が減少傾向

思索の出口なき模索

  • コーディング以外で 知的成長 を模索
  • 物理学の再学習なども試みたが 満足感を得られず
  • Builder側が 非生産的な思索 を許さず、Thinker側が 浅い作業 に飢えるジレンマ
  • かつてのように 両者を満たす時代 は戻るのか不透明
  • 未解決感 とともに自己探求の継続

哲学的引用

  • Philipp Mainländerの「神の死」による 統一性の喪失 の引用
  • 創造と思索 の統合が過去のものとなったという象徴
  • 自己の二重性 と現代における「満たされなさ」の比喩

Hackerたちの意見

コードの設計について、細かいところまで考える時間を持つのは結構役立つって感じてる。エージェントにやらせる前にね。そうすれば、頭を使った気になれるし、挑戦にもなる。自分の考えた解決策が、エージェントの書いたプランよりも問題をうまく解決できたかどうかを考えるんだ。エージェントの解決策が良かったら、それを認めて次回に向けて頭を使う材料になるし、自分の解決策が良かったら、頭が喜んでより良いコードが書けるってわけ。

LLMを使ってコーディングしてるけど、まだまだ真剣に考えてるよ。間違ってるわけじゃない。デザインの選択肢、リスク、制約、技術的負債、代替案、可能性について考えてる。今まで以上に真剣に考えてる感じ。

この意見に共感する。個人プロジェクトの実験として、Claude Codeに100%コードを書かせてるけど、真剣に考える必要性はすごく感じてる。実際、ボイラープレートや繰り返しのテストみたいな低い思考のタスクをやらなくていいから、逆に考える割合が普段より高くなってる気がする。

Claude Codeをよく使ってるけど、考えるのをやめた瞬間を教えてくれるんだ。そうすると、全く意味不明なものを作り始めるから。ゴミを入れればゴミが出るってやつだね…。

LLMをこういうツールとして使うのは十分可能だと思う。ただ、多くの人はそうしてない気がする。個人的にもプロとしても、問題を与えて、設計と実装を期待して、それをゴールドスタンダードとして扱う人をよく見る。少なくとも自分にとってのベストな使い方は、自分が何も学ばないようなワークフローの小さな部分だと思う。 - 捨てるために作る:ステークホルダーのフィードバックを得るためのクイックプロトタイプをくれる - シンプルなヘルパー関数:デザインとパラメータは決まってるから、レビューできる実装が欲しい - タブ補完のコード生成 - 何かを調べるための手がかりが欲しいとき(ライブラリやツール)で、Googleで調べてもダメなとき。

今はもっと考えてると思う、もしくは少なくとも早く考えてる。雑用に時間を無駄にしてないから、大きな絵に集中できるんだ。

このコメントや似たようなコメントを読むと、やっぱり人によって違いがあるよね。個人的には、ブログ記事にすごく共感するし、自分のプログラムのデザインは自然に出てくることが多い。通常、難しい問題は技術的な問題で、その後、プログラムを制御するために必要なことに基づいてデザインが決まる。デザインについてそんなに考えたことはなかったな。

確かに、考え方が違うよね。以前はコーディングでストレスを感じてたんだ。問題を解決するのにハックを導入したり、大規模なリファクタリングに繋がったりして、イライラしてた。でも今は、どんなクールな新機能を作るかを考えるのに時間を使って、あまりストレスを感じてないよ。

OPの投稿は、この議論の段階を超えようとしてると思う。正直、古い話だしね。彼らが言いたいのは、AIツールを使うことで、深く考えるための規律を保つのが難しくなるってこと。これはみんなに当てはまるかどうかは分からないけど。

でも、考え方は確かに違うよね。

そうだね、LLMを使って考えるのは違う。記事にはこう書いてある: 「“真剣に考える”とは、特定の難しい問題に直面し、それを克服するために数日間じっくり考えることを意味する。LLMを使っての“真剣に考える”は、管理的な思考に近い。混沌としていて、会話や文脈の切り替えが多い。確かに疲れるけど、1つのアイデアを数日間考え続けるわけじゃない。1つの問題について数日間考えるのは、科学者や数学者の思考に近い。夜寝るときもその問題について考えてるし、シャワーを浴びてるときも考えてる。小さな突破口や挫折があって、最終的に解決するか諦める。全然違うんだ。」

使い方次第だよね…シンプソンズのエピソードを思い出す。ホーマーが銃のライセンスを取る話。最初は全く使わなかったのに、ちょっと使うようになって、気にせずに使いまくるようになる。思考するのは疲れるし、人生は複雑だから、ツールを使うと悪い習慣に陥りやすい。悪い習慣は認識してもなかなか抜け出せないし。多くの人は忙しかったり、怠けてたり、自分を客観視できなかったりして、自分の行動を評価する余裕がないんだよね。

考えることを減らしてないよ!今日、AIにバグをデバッグさせたんだけど、明らかに正しい解決策を出してきた。でも、なぜそのコードがその状態になっているのかは説明してくれなかった。AIがただ修正したがってたから、なぜそうなったのかを探るように促したら、すごくクールな方法でgitやgithubの問題を掘り下げてくれた。最終的に、意味のあるものを引き出してくれたんだ。それは、どこか別の問題を修正するために導入された防御的プログラミングで、結局その問題も修正されたから無駄だった。そこでアイデアが浮かんで、コードベースの中でその変更に関連する似たようなパターンを探してみたら、3つ見つけた。1つはバグじゃなくて、2つは潜在的なバグだった。修正を出して、まだ発見されていないバグのための2つの修正も出したよ。

「私は考えることを減らしていない!」あなたは実際に考えることを減らした例を詳しく説明しましたね。人に何をやるべきかを指示するマネージャーは、問題について考えていない。

2025年3月のアラル・バルカンの投稿が印象に残ってる。 「コーディングは、粘土の塊を手で少しずつ形にしていくようなものだよ。このプロセスや、作っている素材との親密さが、何を作っているのか、どんな特性や限界があるのかを教えてくれるんだ。実際に作り始める直前が一番何も知らない瞬間で、その時は自分が作りたいものが分かっていると思っている。プロセスは反復的なもので、最初は気づいていなくても、実際に作りたいものを理解する手助けをしてくれる。デザインは単に問題を解決することじゃなくて、正しい問題を見つけてそれを解決することなんだ。問題をうまく解決できなかったから失敗するのではなく、間違った問題を解決してしまうことが多い。創造のプロセスを飛ばすと、学ぶことができたはずのものを、思い描いていたものの模造品と交換してしまう。焼き上げられ、釉薬がかけられたアートファクトを手にすると、発見や学びという人間らしい要素が失われてしまう。粘土の塊から形を作り上げたことを知っているのに、自動販売機から1セントで受け取ったものについては何も知らないんだ。」

うん、たぶん僕は直接コーディングに飛びつくのが好きなんだ。GUIを描くためにCanvaを使うのはあまり深く関わってないから、何を描けばいいのか分からないし…みたいな。

エージェンティックツールでプログラミングする時は、アイデアが最も明白で平均的なバージョンに戻らないように積極的に押し進める必要がある。‘ノルム’から逸脱するアイデアを推進するために必要な努力は、手で何かを書くのにかかる努力と同じくらいのものだよ。全く異なる2種類の努力なんだ。でも、この努力には良い面もある。エージェンティックプログラミングツールからの継続的な反発があるから、アイデアが何であるか、何でないかを明確にする必要がある。押し返すのをやめた瞬間、LLMが君のプロジェクトを覆い、最初に君のものをユニークにしていたものを壊してしまう可能性が高いんだ。

うーん、1万個の粘土の壺を作ったら、結果をすぐに見たい気持ちもわかる。10,001個目の壺でそんなに学ぶことはないし。最初から最終的にどうしたいかのアイデアを考えることができると思う。普段の自分なら考えないようなことにも手を伸ばせるようになった。これって、ユーザー向けじゃないけど、コードのメンテナンスやスケーラビリティ、テストやテスト可能性を改善するものだったりする。

魅力的で感動的で、カメラが登場したときにみんなが言ってたこととほぼ同じだね。

わからないな。僕は同じくらい真剣に考えてるけど、タイプする量は少ない。正確に指定して、見直してる。変わったのは、より高いレベルで作業しているだけだと思う。製品は同じだよ。でも、みんなは「わあ、今フェラーリを手に入れた、道を飛び出すのを見て!」みたいに混乱してる。そう、ツールがアップグレードされたんだ。速くて、パワフルになった。道を走らせるか、運転を諦めるかだよ!キーワードの自動補完から、シンボルの自動補完、文の自動補完、段落の自動補完、機能全体の自動補完に進化した。こんなに早く進んだから、毎週プログラミングの名前を変えたくなるんだ。今は「バイブコーダー」だとか「エージェンティックコーダー」だとか、ただのプログラマーだとか。なんでかって?僕はCで書いて、マシンコードを得るけど、マシンコードは自分で書いてない!全部抽象化されてるんだ!でも「それは違う」と言うけど、聞くたびに変わるんだ。そう、今はまだ不安定で、ところどころガタガタだけど、ただの踏み台なんだ。リラックスして、プログラミングだよ。ツールがさらに良くなっただけ。3日で砂漠をキャメルで渡ることもできるし、ヘリコプターを借りて数時間で飛び越えることもできる。選ぶのは君次第。旅行じゃないって言わせないで。今、私たちはみんなリーナス・トーバルズだよ。レビューして、マージして、送り返す。もし以前に何をしていたか分からなかったら、今日も何をしているか分からないよ。ただ、今は以前よりもタイプミスが少なくなっただけなんだ。

でも、実際には期待通りに機能しなくて、逆に悪化するだけなんだよね。

今やみんなリーナス・トーバルズだね。で、君のOSとSCMはどこ?ウェアの重要性はわかるけど、LLMがある今、リーナス・トーバルズのレベルに達してる人がそんなにいるとは思えないな。

著者が言いたいことはわかる気がする。小さな詳細について「しっかり考える」ことを忘れちゃってるんだよね。もしかしたら「しっかり」が適切な形容詞じゃないかもしれないけど、コーディングのプロセスはただタイプするだけじゃないってみんな知ってる。打ってるコードや新しいコードと既存のものとの相互作用、潜在的なバグや問題についてずっと考えてる。(これが「しんどい」かどうかは別として。) そして、こういう考え方は、リーナスが他のメンテナーからの大きなパッチをレビューするときに考えなきゃいけないこととは全然違う。リーナスの仕事は多分「もっと大変」だけど、考え方が違うんだよね。ツールが進化してるのはその通り。コンパイラが改善されたとき、多くの人は喜んだけど、アセンブリを手作りするのが好きな人は趣味で続けてた。だけど99%以上のケースでは、アセンブリを手作りするのはプロジェクトにとってマイナスだし、楽しいとしても。だから、アセンブリを書くのが好きなら、仕事がないか、仕方なくJavaを書くことを受け入れなきゃいけない。こういう状況を嘆くのも仕方ないと思う。

今日は以前よりもタイプミスが少ないだけだよ。私のタイプミスは大体許容範囲だし。

もっと適切なアナロジーは、フェラーリのような速い車じゃなくて、運転が好きな人が自動運転車を監視しながら運転する感じだと思う。フェラーリと比べるのは間違ってる。運転手が持つエージェンシーのレベルは似たようなものだから。

簡単だよ。あなたの比喩を続けると、3日でキャメルに乗って行きたい場所に行くか、数時間でヘリコプターで砂漠の向こう側のランダムな場所に行くかの選択がある。合理的な人間として、私も著者と同じようにヘリコプターを選ぶ。それが全て、これが問題の全貌だ。

正直、著者の言いたいことがよくわからない。もし彼がエージェント的なコーディングやAIが思考に悪影響を与えると思っているなら、単に使うのをやめればいいじゃん。使わなければ影響もないのに、なんでツールを責めるの?私の場合、何かを作り始める前に考えすぎることが多かったけど、バイブコーディングがそのサイクルから救ってくれた。数日前、openclawを使ってテレグラムチャットで完全なプロダクトを作って立ち上げた。今は、アイデアを記録するだけじゃなくて、すぐに行動できる。私にとって、それは進化だと思う。AI技術の進歩とこの新しい時代に本当に感謝してる。結局、使うか使わないかは自分の選択であって、もっと考えるのを妨げるものじゃないよ。

個人的には、問題はチームメイトにあると思う。批判的に考えたり、コードベースにある既存のツールを調査する能力や意欲が消えてしまってる気がする。最近は、既存のインフラを使った単一の関数呼び出しで解決できるところを、新しい実装を使って修正したPRを送り返さなきゃならないことが多すぎる。

数十年プログラミングをやってきた者として(つまり、年寄りです)、今のAIツールはすごく自由に感じる。業界全体で、何がうまくいくかを確かめるために小さな実験をたくさんやることの利点をずっと言ってきたけど、AIが出る前は、こういうアイデアは実行に移されることが少なかった。時間がかかりすぎて、明確な利益がなかったからね。面白いアイデアを考えるのに何時間もかけても、試す時間がなかったりして。今は、思いついたちょっとしたアイデアを試すためにすぐにコーディングエージェントを立ち上げられる。やるのにかかるコストはすごく低いから、以前よりもずっと多くて変わったアプローチを試せる。もしそのアイデアがうまくいかなくても、まあいいやって感じ。左フィールドのアイデアでも成功率が十分に高いから、以前よりもずっと正当化しやすい。あと、一人プロジェクトを遊び感覚でやるのもすごく実用的になった。パートナーや子供がいると、自由な時間は貴重で、計画できない小さな時間にしか来ないことが多いから。例えば、昨夜はドライブスルーの列で10分待ってたんだけど、その間に次の一人プロジェクトの開発をスマホで始めて、結果を見て、次の開発を始めることができた。去年なら、ただイライラしながら待ってたと思う。AIコーディングに関して「アウトソーシングレゴ」的な考え方を持っている人もいるけど、クールなレゴキットを買って、他の人に組み立ててもらうみたいなもので、楽しみの99%を奪われるっていうのは分かる。でも、私はそれを、使える時間で何倍も多くのことを達成できるっていう観点で考えたい。追加コストはほぼゼロに近いし。

この議論で気づいたのは、「真剣に考える」っていうのは単一の思考モードじゃないかもしれないってこと。大学院の時、私はクラシックなバージョンを経験した。2トーラスを裏返すというトポロジーの問題に一晩中考えていた。普通のR^3ではトーラスを裏返すことはできないと知っていたから、頭の中でトーラスとその周囲の空間を動かしたり伸ばしたりして、障害がどこにあるのかを理解しようとしていた。日の出の頃、無限を通過する動きを許すと(つまり、実質的にS^3)、私が頼りにしていた内外の区別が崩れ、視覚化していた障害が消えることに気づいた。鳥がさえずり、寝ていないのに、何も有用な結果は出なかったけど、空間の内部モデルが永久にアップグレードされた感じがした。これが「真剣に考える」ってことだと思う。でも、別のモードも経験したことがあって、それは関連はあるけど違う。難しいコードゴルフの問題を持ち歩くことがあるけど、ずっと考えているわけじゃなくて、問題はバックグラウンドに残っている。で、突然、シャワー中や散歩中に圧縮トリックや別の表現がひらめく。それは瞬間的には「難しい」とは感じない。むしろ、問題を記憶に留めておくことで、正しい構造が浮かび上がる感じ。集中して疲れるのと、拡散してじっくり燃えるのは違う現象だけど、どちらも深く関与している形で、簡単にかき消される。

同僚のエンジニアたちが、私たちを市場で価値ある存在にしてくれた唯一のものを売り渡して、ソフトウェアエンジニアリングをキャリアとして壊そうとしていることには、絶対に腹が立つ。要するに「クロードコードがバrrrrrr」って感じで。私たちは生産手段を持っていて、ほぼ集団的に「まあ、ブルジョアに任せてもいいか」と決めたみたいなもんだ。

まだ数日間考え続けることはある。もしやりたいことが新しくないなら、これらのツールから同じ満足感は得られないと思う。明確な解決策がない可能性の領域を探っているなら、しっかり考えなきゃ。もっと野心的なプロジェクトに挑戦して、できないと思うことをやってみる。そして、それを実現するために取り組む。