AIコーディング時代、エンジニアの認知負荷はどう変わったか――「書く」から「読む」への重心移動
2026.08.11 / Donut Service
AIに実装を指示して、生成された差分を眺める。手はほとんど動かしていないのに、夕方にはくたくたに疲れている――AIコーディングツールを実運用に組み込んでから、疲労の「質」が変わったと感じているエンジニアは少なくないはずです。
筆者も Claude Code と Cursor を日常的に使っていますが、「書く時間」は確かに減りました。代わりに増えたのが、生成されたコードを読み、疑い、検証する時間です。
本記事では、この「負荷の移動」を認知負荷理論のフレームで整理します。あわせて、AIツールと生産性の実証研究――結論は割れています――と、信頼と検証に関する最新の調査データを見ていきます。
1. 認知負荷理論の三分類――ただし理論は更新されている
認知負荷理論は、ジョン・スウェラーが問題解決研究から提唱した理論で、人間の作業記憶が一度に扱える情報量はごく限られているという前提から出発します（Sweller, 1988, Cognitive Science, 12(2), 257–285）。教育心理学では、学習時の負荷を次の3つに分ける整理が広く使われてきました。
- 内在的負荷：課題そのものの複雑さに由来する負荷
- 外在的負荷：課題の本質とは関係ない、提示や手順のまずさが生む負荷
- 学習関連（germane）負荷：スキーマ構築、つまり学習そのものに向かう負荷
ただし、この三分類は確定した定説ではありません。スウェラー自身が2010年に理論を再構成し、学習関連負荷を独立した負荷源ではなく「内在的負荷の処理に振り向けられる作業記憶資源」と再定義しています（Sweller, 2010, Educational Psychology Review, 22, 123–138）。さらにカリュガは、学習関連負荷は内在的負荷と区別がつかず冗長な概念ではないかと批判し、内在的／外在的の二分で十分だと論じました（Kalyuga, 2011, Educational Psychology Review, 23(1), 1–19）。
そこで本記事では、両論が共通して維持している区別だけを借ります。すなわち「課題そのものに由来する負荷（内在的）」と「やり方に由来する、削れるはずの負荷（外在的）」の2つです。
2. コードは「書く」より「読む」――AI以前からの実測
そもそもエンジニアの仕事は、AI登場以前から「読む」ことが中心でした。78名のプロフェッショナル開発者の作業ログ3,148時間分を実測した研究では、作業時間の平均約58%がプログラム理解（コードを読む・調べる）に費やされていたと報告されています（Xia et al., 2018, IEEE Transactions on Software Engineering, 44, 951–976）。
ここで正直に断っておくと、これは時間の比率であって、負荷の大きさを直接測ったものではありません。「読む負荷は書く負荷より大きい」を直接比較した実証研究は、筆者が調べた範囲では見つけられませんでした。以下は一次体験としての整理です。
自分で書いたコードは、書く過程で頭の中にメンタルモデルができています。一方、生成されたコードを読むときはモデルがゼロの状態から始まる。構造としては他人のコードをレビューする行為と同じです。AIコーディングとは、レビュー対象が毎日大量に届く働き方だとも言えます。
3. AIツールで生産性は上がるのか――実証は割れている
3-1. 「速くなる」側の証拠
GitHub と Microsoft の研究チームによる対照実験では、95名のフリーランス開発者に JavaScript で HTTP サーバーを実装させたところ、GitHub Copilot を使った群は使わなかった群より55.8%速く課題を完了しました（Peng et al., 2023, arXiv:2302.06590）。経験の浅い開発者ほど恩恵が大きかったことも報告されています。
3-2. 「遅くなる」側の証拠
一方、研究機関 METR が2025年に行ったランダム化比較試験では逆の結果が出ました。平均5年携わってきた成熟 OSS プロジェクトで、熟練開発者16名が246タスクに取り組んだところ、AI利用を許可された条件のほうが完了時間が19%長くなったのです（Becker, Rush, Barnes, & Rein, 2025, arXiv:2507.09089）。
この研究で最も示唆的なのは体感との乖離です。参加者は事前に「AIで24%速くなる」と予測し、実際には19%遅くなった後でさえ「20%速くなった」と体感していました。書く負荷の軽さが、検証に費やした時間を覆い隠すのかもしれません。
3-3. どちらが正しいのか
両者は矛盾というより条件の違いです。前者はゼロから書く小さな独立課題、後者は暗黙知の多い成熟コードベースで、ツールの世代も違います。METR の著者ら自身も、特定条件下の結果であり一般化はできないと明記しています。「AIで生産性が◯%上がる」と一言で断定できる段階には、まだありません。
4. 「信頼していないのに、検証しきれない」――調査データ
Stack Overflow の2025年開発者調査では、AIツールを利用中・利用予定の開発者が84%を超えた一方、AIの出力を信頼すると答えたのは29%で、前年の40%から11ポイント下がりました。使うほど信頼が下がるという逆説的な傾向です。
Sonar 社が2026年1月に発表した1,100名超の開発者調査では、96%が「AI生成コードが機能的に正しいとは完全には信頼していない」と答えながら、コミット前に必ず確認すると答えたのは48%にとどまりました。さらに38%は「AI生成コードのレビューは同僚のコードより手間がかかる」と回答しています。
信頼していない。しかし全部は検証しきれない。この隙間が「いつか踏むかもしれない」という慢性的な警戒として、個々のエンジニアの認知負荷にのしかかっていると筆者は見ています。
5. 認知負荷のフレームで整理する――何が減り、何が増えたか
減ったのは外在的負荷の一部です。ボイラープレートの記述、構文の想起、APIの細部を検索する往復。これらは課題の本質ではなかったので、削られたこと自体は歓迎すべき変化です。
増えたのは、内在的負荷の高い「検証」の比率です。生成コードが仕様と一致しているか、エッジケースを踏んでいないかの判断は、コード・仕様・システム全体の文脈を同時に頭に載せる作業で、要素間の関連が濃い分だけ作業記憶を消費します。しかも生成コードの誤りは、人間のタイプミスと違って「もっともらしく読めてしまう」形で紛れ込むため、読み流しが利きません。
なお、この整理は教育研究で育った理論の応用であり、AIコーディングの文脈で実証されたマッピングではありません。それでも「楽になったはずなのに疲れる」の説明として、書く局面の負荷が減り、もともと重かった読む局面に仕事が集中した、という見立ては筆者の実感とよく合います。
6. レビュー中心の働き方を前提に、負荷を設計する
負荷の重心が「読む」に移ったなら、時間設計もそちらに合わせて組み直す必要があります。筆者が実践して効果を感じている運用は次のとおりです。
- 生成の単位を小さく保つ：一度にレビューできる差分の量には限界があります。大きな指示を出すほど、検証不能な塊が届きます
- 機械に先に読ませる：テスト・型検査・静的解析で機械的に落とせる誤りを先に落とし、人間の読みは設計判断と仕様適合に集中させる
- レビューを覚醒のピークに置く：検証は深い集中を要する作業です。52/17ルールの記事で書いた長めの集中ブロックを、生成ではなくレビューに割り当てる
- レビューの多い日は疲労を見込む：手を動かしていなくても認知負荷は蓄積します。脳疲労の可視化について書いた記事のとおり、疲れは自覚より先に精度へ現れます
7. まとめ
- 認知負荷理論の三分類は出発点として有用だが、理論自体が更新途上にある。確かなのは「課題由来の負荷」と「やり方由来の負荷」の区別
- エンジニアの時間は AI 以前から約6割が「読む」ことに使われていた
- AIツールの生産性効果は実証が割れており、タスクと熟練度への条件依存が大きい
- 調査データは「信頼していないのに検証しきれない」ギャップを示す。ここが新しい負荷の正体
- 書く負荷が減った分、読む・検証する負荷を前提にした時間設計へ切り替える
AIは疲労をなくしたのではなく、疲労の置き場所を変えました。変化の正体が見えれば、対策は設計できます。まずは明日の一日、自分の時間が「書く」と「読む」のどちらに流れているかを観察してみてください。
BrainSync Focus Timer のご紹介
レビュー中心の働き方では、集中ブロックの設計がこれまで以上に効きます。私たち Donut Service が開発した BrainSync Focus Timer は、VS Code・Cursor のステータスバーに常駐するタイマーで、25/5（ポモドーロ）と52/17（ロングブロック）を切り替えながら使えます。生成を指示して待つ時間と、腰を据えて読む時間。リズムを分けて設計する道具としてお使いください。
休憩のタイミングを自動で知らせるポモドーロタイマー。無料でインストールできます。
BrainSync Focus Timer をインストールする →Cursor をお使いの場合は Open VSX 版 をご利用ください。
※ 効果には個人差があります。本記事は医療助言ではありません。
BrainSync — ソフトウェアエンジニアの心と脳を、やさしく整える。
ドーナツサービス · 東京
参考文献
- Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285.
- Sweller, J. (2010). Element interactivity and intrinsic, extraneous, and germane cognitive load. Educational Psychology Review, 22, 123–138.
- Kalyuga, S. (2011). Cognitive load theory: How many types of load does it really need? Educational Psychology Review, 23(1), 1–19.
- Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E., & Li, S. (2018). Measuring program comprehension: A large-scale field study with professionals. IEEE Transactions on Software Engineering, 44, 951–976.
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
- Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv:2507.09089.
- Stack Overflow (2025). 2025 Developer Survey.
- Sonar (2026). State of Code Developer Survey.
