「空洞化した精神」から考える、IT技術者のためのAIとの付き合い方
生成AIが開発現場に入り込んでから、仕事の進め方はかなり変わりました。エラーの原因調査、設計のたたき台、SQLや正規表現の作成、コードレビュー観点の洗い出し、ドキュメント要約、未知の技術のキャッチアップ——以前なら数十分から数時間かかっていたことが、今では数分で前に進むことも珍しくありません。Microsoft・Accenture・フォーチュン100企業で4,867人の開発者を対象としたフィールド実験では、AIコーディングアシスタントの利用でタスク完了数が約26%増加したという結果が報告されています（Microsoft Research, 2024）。
この変化はたしかに大きい。そして多くの技術者が、すでにこう感じているはずです。「分からないことは、まずAIに聞く」。このスタイルは、もはや一時的な流行ではなく、日常の標準動作になりつつあります。
ただ、その便利さの裏で、少し気になる感覚はありませんか。以前より自分で粘って考える時間が減った。答えは出せるのに、なぜそうなるのかを深く説明しにくい。AIがない状態で、同じ品質のアウトプットを出せる気がしない。書けるコードは増えたのに、理解の密度はむしろ薄くなっている気がする——。
この違和感を説明する、とても示唆的な概念があります。2025年に発表された Klein らの論文では、AI時代の学びや認知のリスクを説明する枠組みとして、「空洞化した精神（Hollowed Mind）」 という考え方が提案されました（Frontiers in Artificial Intelligence, 2025）。これは、AIによって成果物は立派に見えても、その中身となる知識構造や判断力が本人の中に育ちにくくなる状態を指します。
教育の話に見えるかもしれません。でも、これはむしろIT技術者こそ真正面から考えるべきテーマだと思います。なぜなら、技術職はもともと「分かる」ことと「できる」ことと「説明できる」ことの3つがズレやすい仕事だからです。そこにAIが入ることで、このズレが一気に拡大する可能性があるからです。では、なぜAIはそうした「空洞化」を招きやすいのか。まず、AIが従来のツールとどこで違うかから見ていきましょう。
AIは「調べ物の補助」ではなく、推論の中核まで代行し始めた
昔のツールは、主に手間を減らすものでした。電卓は計算を速くし、IDEは補完やリファクタを助け、検索エンジンは情報探索を速くし、Stack Overflowは類似事例への到達を速くしました。これらはどれも強力でしたが、基本的には人間が考えること自体は残っていました。
一方、生成AIは少し違います。いまのAIは、単なる検索結果の提示ではなく、情報を選び、文脈をまとめ、論点を整理し、仮説を立て、手順に分解し、もっともらしい説明や結論の形にまで仕上げるところまでやってきます。つまり、単なる補助ではなく、統合的な推論の一部を肩代わりする存在になっているのです。
ここが本質です。AIは「作業を楽にする道具」であるだけでなく、本来なら自分の頭の中で起きるはずだった試行錯誤や統合のプロセスそのものを、外部で先回りして完成させてしまう。このとき技術者に起きることは、アウトプットは速くなる一方で、理解が育つ前に答えが届くということです。そして、その流れをさらに加速させてしまう要因が、技術者自身の性質にあります。
技術者はもともと「認知的ケチ」になりやすい
人間には、なるべく楽に考えたいという性質があります。認知心理学では、こうした傾向を認知的ケチ（cognitive miser） と呼びます（Fiske & Taylor, 1984の社会認知研究に由来する概念で、Cognitive miser - Wikipedia に概要があります）。そして技術者は、この性質と相性が悪いようでいて、実はかなり相性が良いです。
なぜなら、技術者の仕事は本質的に、面倒な処理を自動化したい、再利用可能にしたい、冗長さを減らしたい、認知コストを下げたい、一度解いた問題を二度解きたくない、という発想に支えられているからです。これはエンジニアリングとしては正しく、むしろ強みです。でも、その強みがAI時代には落とし穴にもなります。AIは、技術者の「省力化したい」という本能に、極端に強く刺さるからです。考えるより聞いた方が速い。書くより生成させた方が速い。調べるより要約させた方が速い。比較するより推薦させた方が速い——。この流れが加速すると、だんだん「自分で考えなくても、それなりに前へ進める」状態になります。そして怖いのは、これが短期的にはかなりうまく機能してしまうことです。うまくいっているように見えるからこそ、もう一つのリスクに気づきにくくなります。それは、AIの答えの「質」ではなく「見え方」に関する問題です。
一番危ないのは「答えがそれっぽい」こと
AIの問題は、間違えることそのものではありません。もっと厄介なのは、間違えていても自然に見えることです。OpenAIの解説では、ハルシネーションを「もっともらしく聞こえるが正しくない発言を自信を持って生成する」現象と定義しており、多くの評価が「推測を報酬づける」設計になっているため、不確実な場合でも断定しがちになることが指摘されています（言語モデルでハルシネーションがおきる理由 | OpenAI）。
技術者が本来持っているはずの重要な力に、違和感を検知する力があります。このAPI設計は何か気持ち悪い。このクラス分割は責務が曖昧だ。このSQLはたぶん遅くなる。この説明は言ってることは通るけど前提が怪しい。このリファクタは見た目は綺麗でも保守性が落ちる——。こうした感覚は、知識が増えるほど育つもので、言語化しにくいけれど現場では非常に重要です。しかしAIの回答は、表面がなめらかです。自然な文章で、筋も通って見える。コードも一見もっともらしい。そのため、立ち止まって疑うきっかけそのものが減る可能性があります。
元の論文では、こうした状態を、思考の手間を飛ばしてしまう認知的バイパスとして捉え、AIの賢さの前で自分の判断権を手放してしまうことを認知的主権の喪失として問題にしています。IT技術者の文脈で言い換えるなら、AIを使うこと自体が問題なのではなく、AIの出力を自分の理解を経由せずに採用してしまうことが問題なのです。そして、このリスクは誰にでも同じようにあるわけではありません。知識量によって、AIの効き方——そして落とし穴の深さ——が変わってきます。
初心者ほどAIで“できてしまう”。でも、そこに罠がある
この論点で特に重要なのが、知識量によってAIの効き方が変わるという点です。元論文では、これを専門性の二面性（Expertise Duality） として整理しています。興味深いのは、先のMicrosoft等のフィールド実験でも「経験の浅い開発者の方がAIの採用率が高く、生産性向上の効果も大きかった」という結果が出ていることです（同上、Microsoft Research）。一見すると初心者に有利に見えますが、Kleinらが指摘するように、成果物の量や速さと長期的な理解や判断力の育ち方は別問題です。
初心者にとってのAI
初心者にとってAIは、非常に強力な平準化装置になります。それっぽいコードが書ける。それっぽい設計説明ができる。それっぽいドキュメントが作れる。それっぽい比較表や提案書が出せる——つまり、知識の不足を外部から埋めることができ、短期的にはとても有効です。ただし問題は、その成果が本人の中で構造化された理解を伴っていない可能性があることです。たとえば、コードは書けたがなぜその実装なのか説明できない。エラーは直せたが根本原因を抽象化できない。設計案は出せたがトレードオフを語れない。ライブラリは使えたが制約や失敗条件を理解していない。この状態は、かなり危険です。なぜなら、現場で本当に価値を持つのは「前と同じ問題を解けること」ではなく、「少し違う問題でも原理から応用できること」 だからです。AIが毎回答えをくれる環境では、一見成長しているように見えます。でも実際には、毎回その場しのぎで借り物の足場に乗っているだけかもしれない。これは、学習の問題であると同時に、技術者育成の問題でもあります。
専門家にとってのAI
一方で、十分な知識を持つ人にとって、AIはかなり違う働きをします。専門家は頭の中に、すでに多くのスキーマ（知識の整理棚のようなもの）を持っています。たとえばバックエンド経験者なら、その処理は同期にすべきか非同期にすべきか、DBで持つべきかキャッシュで逃がすべきか、ドメイン層に寄せるべきかアプリケーション層で持つべきか、障害時にどこがボトルネックになるか、といった観点が頭の中にあります。そのためAIの出力を見たときも、「ここは正しい」「ここは浅い」「この前提は危ない」「この説明は一般論すぎる」「このコードは通るが本番ではつらい」という形で照合・修正・問い直しができます。このときAIは、思考を奪う存在ではなく、自分の知識を高速に拡張する増幅器になります。
ここで重要なのは、AIを使う前に知識が必要なのではなく、AIを本当に使いこなすためには、やはり知識が必要ということです。少し皮肉な話ですが、「AIがあるから勉強しなくていい」のではなく、むしろ 「AI時代ほど、土台の知識の有無が効いてくる」 わけです。こうした「空洞化」が、現場ではどんな形で表れやすいか。具体例に落としてみましょう。
IT技術者に起きやすい「空洞化」の具体例
この話を抽象論で終わらせないために、現場で起きやすい例に落としておきます。
コードは生成できるが、デバッグ力が育たない
AIにコードを書かせること自体は便利です。でも、エラー時にどこから疑うか、何を切り分けるか、何が再現条件か、なぜこの不具合が起きたかを自分で整理しないまま直していると、障害対応力が育ちません。
設計の言葉を話せるが、設計判断ができない
AIは設計原則をそれっぽく説明できます。SOLID、疎結合、拡張性、責務分離、DDD、クリーンアーキテクチャ。でも、本当に重要なのは用語を知っていることではなく、この規模ならどこまで分けるべきか、将来変更をどこで受けるべきか、複雑さと柔軟性をどう交換するかを判断できることです。
新技術のキャッチアップが速いが、定着しない
AIに聞けば、どんな技術も数分で概要はつかめます。でも、概要を読んだだけでは使える知識にはなりません。実際に手を動かし、失敗し、設定で詰まり、ログを読み、制約を体感して初めて、自分の知識になります。
レビューコメントは書けるが、品質観が育たない
AIはレビュー観点を大量に出せます。しかし、本当に大事なのは「この変更のどこが本質的に危ないか」を見抜く品質観です。表面的な指摘の数が増えても、重要な欠陥を見抜けなければ意味がありません。では、こうした空洞化を防ぐために、何を軸にすればよいのか。そこで鍵になるのが、先ほど触れた「認知的主権」という考え方です。
技術者が守るべきなのは「認知的主権」
元論文で特に重要だと思うのは、認知的主権という考え方です。少し難しく聞こえますが、要するにこういうことです。最終的に、何を根拠に、どの判断を採用するかを、自分で持ち続けること。
AI時代の技術者に必要なのは、何でも自力でやることではありません。それは非現実的です。そうではなく、どこをAIに任せるか、どこは自分で考えるか、どこで疑うか、どこで検証するか、最後に何を自分の判断として引き受けるか——この境界線を失わないことです。AIに全部聞くことは問題ではありません。でも、AIに全部決めさせるようになると、技術者としての中核が痩せていきます。認知的主権を守るとは、言い換えれば「AIの使い方そのものを設計する」ということです。では、日々の仕事のなかで、どんな工夫が有効でしょうか。
では、IT技術者はAIをどう使えばいいのか
ここが一番大事です。AIをやめるべき、という話ではありません。むしろ逆で、よりうまく使うための使い方の再設計が必要です。
いきなり完成答えをもらわない
最初から完成コードや完成設計を出させると、思考工程が消えやすいです。代わりに、論点だけ列挙させる、方針候補を3つ出させる、比較観点だけ出させる、バグの可能性を仮説として並べさせる、まず質問だけ返させる——といった、答えをもらう前に、考えるための足場をもらう使い方が有効な場面が多いです。
必ず「なぜそうなるか」を自分の言葉で言い直す
AIの説明を読んで終わりにしない。自分で、なぜこの設計になるのか、なぜこのクエリになるのか、なぜこのエラーが起きるのか、なぜこの修正で直るのかを言い直す。この一手間で、理解の質はかなり変わります。
AIの出力をそのまま採用せず、比較対象を持つ
1つの回答だけで決めると、思考停止しやすいです。自分案を先に作る。AI案と比較する。別モデルでも聞く。公式ドキュメントに当たる。小さく実行して確かめる——こうすると、AIは答えそのものではなく、対照実験の相手になります。
学習時はあえて負荷を残す
学ぶ場面では、摩擦が必要です。学習科学では、一定の負荷をかける 望ましい困難（desirable difficulty） が、長期の保持や転移を高めることが知られています（Bjork, 1994。Desirable difficulty - Wikipedia に概要があります）。まず自力で10分考える。実装してからAIにレビューさせる。エラー文だけ見て原因を先に推測する。要約の前に原文を一度読む。チュートリアルを読む前に触ってみる。AI時代でも、いやAI時代だからこそ、理解のための苦労は消さない方がいいです。
若手育成では「AI込みで何を残すか」を設計する
育成では特に重要です。AI利用を禁止するか解禁するかの二択ではありません。重要なのは、どの工程はAI可か、どの工程は自力でやるか、どこまで説明できれば合格か、何をレビューで確認するかを明確にすることです。たとえば「AIで実装してよいが、設計理由を口頭で説明できること」「AIで調査してよいが、一次情報に当たって根拠を示すこと」のように、成果物ではなく理解責任を問う設計が必要になります。こうした使い方の再設計は、言ってみれば「速さ」への偏りにブレーキをかけることでもあります。最後に、なぜそこにこだわるべきかを、もう一度整理しておきましょう。
AI時代の技術者に必要なのは、速さだけではない
いまの現場では、AIで速く作れる人が目立ちやすいです。それ自体は悪いことではありません。ただ、長期的に価値を持つのは、速く作れる人だけではなく、なぜそれでよいのかを理解し、壊れたときに立て直せる人です。
AIは、平均的な出力を速く作る力にはかなり強い。一方で、GitHubの調査ではCopilot利用によるコードの機能性・可読性・承認率の向上が報告される一方、別の実証分析では「サイクルタイムは短縮するがバグ率が増加する」といったトレードオフも指摘されています（GitHub Blog - コード品質とデータ 等）。あいまいな要件を整理する、本質的な失敗要因を見抜く、トレードオフを引き受ける、責任ある設計判断をする、障害時に仮説を組み立てる、チームに知識を定着させる——こうした仕事は、まだ人間の理解の厚みに強く依存しています。だからこそ、AI時代の技術者に必要なのは「AIを使わない根性」ではありません。必要なのは、AIを使っても自分の頭を空洞化させない使い方です。ここまで述べてきた「空洞化」「認知的ケチ」「それっぽさの危険」「初心者と専門家の差」「具体例」「認知的主権」「使い方の工夫」——それらをひとつにまとめると、次のように言い換えられます。
まとめ——守るべきは「認知的主権」
生成AIは、IT技術者にとって間違いなく強力な武器です。でも、その武器は便利すぎるがゆえに、私たちから考える過程そのものを静かに奪うことがあります。成果物が出ることと理解が育つことは同じではない。書けることと説明できることも同じではない。一時的に解けることと、次も解けることも同じではありません。
もし最近、AIがないと不安になる、自分で考える前に聞いてしまう、分かった気はするが腹落ちしていない、出力は速いのに実力が増えた感覚が薄い、という感覚があるなら、それは単なる気のせいではないかもしれません。AI時代に守るべきなのは、知識量そのもの以上に、自分で理解し、自分で疑い、自分で判断する主導権です。AIを使うことは問題ではありません。問題なのは、思考まで委託してしまうことです。便利さを受け取りながら、認知的主権は手放さない——これが、これからのIT技術者にとって、かなり重要な作法になるのではないでしょうか。
参考
- Christian R. Klein et al., The extended hollowed mind: why foundational knowledge is indispensable in the age of AI, Frontiers in Artificial Intelligence, 2025.
https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1719019/full - Microsoft Research, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, 2024.
https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/?lang=ja - OpenAI, 「言語モデルでハルシネーションがおきる理由」, 2025.
https://openai.com/ja-JP/index/why-language-models-hallucinate/ - GitHub Blog, 「GitHub Copilotはコード品質を向上させるか？データが語る真実」, 2024.
https://github.blog/jp/2024-12-03-does-github-copilot-improve-code-quality-heres-what-the-data-says/ - Cognitive miser（認知的ケチ）: Fiske & Taylor (1984) に由来。
https://en.wikipedia.org/wiki/Cognitive_miser - Desirable difficulty（望ましい困難）: Bjork (1994) に由来。
https://en.wikipedia.org/wiki/Desirable_difficulty
作成日：2026年3月2日