はじめに

Claude Code や Codex といったAIエージェントが開発の現場に定着し、コードを書く速度は確かに上がりました。ただ、書くのは速くなったはずなのに、全体としてはむしろしんどい。コードが増えすぎて、自分が何を作ったのか、チームが何を持っているのか、把握しきれなくなっているという方もいるのではないでしょうか。

この記事では、この違和感を、認知心理学の「認知負荷理論(Cognitive Load Theory)」と、組織設計の「Team Topologies」という2つの枠組みで整理してみたいと思います。

認知負荷とは何か

まず前提を確認しておきます。ここはエンジニアリングというより認知心理学の話になります。

ワーキングメモリには容量の限界がある

人間の脳には、短時間だけ情報を保持・処理する領域があり、これをワーキングメモリ(作業記憶)と呼びます。George A. Miller が1956年に発表した論文では、人は一度に7±2個程度の情報しか保持できないとされました。その後 Nelson Cowan(2001)の研究では、より厳密には4チャンク程度ではないかという見方に更新されています。

数字の細かさはさておき、重要なのは容量に上限があるという点です。これを超えるとエラーや判断ミス、学習の失敗が起きやすくなります¹。

Sweller の認知負荷理論(1988)

この容量制限を扱う代表的な理論が、教育心理学者 John Sweller が1988年に提唱した認知負荷理論(CLT)です。CLTでは、ワーキングメモリにかかる負荷を3種類に分けます。

種類	内容	開発での具体例
内在性認知負荷(Intrinsic)	課題そのものに本質的に伴う難しさ	ドメインの複雑さ、アルゴリズムの本質的な難度
外在性認知負荷(Extraneous)	情報の提示方法や環境から生まれる、本来不要な負荷	読みにくいコード、一貫性のない設計、ビルド手順の暗記
学習関連認知負荷(Germane)	知識を「スキーマ」として長期記憶に定着させるために使う負荷	コードを読み、設計意図を理解し、パターンとして蓄積する作業

この3つの合計がワーキングメモリの容量を超えると、認知オーバーロードが起きます。

3種類には非対称性があります。内在性負荷は課題側の問題なので簡単には減らせません。外在性負荷は本来なくてもよい負荷なので、削るべき対象になります。一方で学習関連負荷は削ってはいけない負荷で、ここを削ると長期的にスキーマが育たなくなります。

Sweller ら(1998)の定式では、この3つは加算的に扱われます。外在性負荷が増えれば、その分だけ学習関連負荷に使える容量は減ります。

AIは個人の認知負荷にどう影響したのか

「速く書けている感」と実測値のずれ

2025年にMETRが行ったランダム化比較試験において、興味深い結果があります。

経験豊富なオープンソース開発者16人に、自分がよく知っているリポジトリで246件のタスクを行ってもらい、AI使用の可否をランダムに割り当てた研究で、主にCursor ProとClaude 3.5/3.7 Sonnetが使われました。結果は次のようなものでした。

項目	値
開発者の事前予測	AIで24%速くなる
開発者の事後自己評価	AIのおかげで20%速くなったと感じた
実測	AI使用で所要時間が19%長くなった

速くなったと感じているものの、実際には遅くなっていました。認知と実態のあいだにかなり大きなずれが生じていたことになります。

なぜずれが生じたのか

この現象は、Swellerのフレームに当てはめるとある程度説明がつくと思います。

外在性認知負荷の増加

自分で書いていないコードを読み、妥当性を判定する作業自体が、それなりの外在性負荷になります。命名規則が自分の癖と微妙に違う、同じ処理でも毎回書き方が変わる、ライブラリの選択がそのときどきでぶれる、プロンプトの往復でさっきの文脈をどこまで覚えていたか思い出す必要があるといったことが、AIの出力を受け取るたびに積み重なります。本来なくてよかったはずの負荷が、ワーキングメモリの多くを占めていくのです。

学習関連認知負荷の削減

こちらのほうが深刻かもしれません。AIが完成したコードを提示してくれると、自分の中にスキーマを構築するプロセスをそのまま省略できてしまいます。最初から動くコードが出てくるので、なぜそう書くのかを考えなくなります。動かないときだけピンポイントで直しますが、全体の理解は深まりません。結果として、次に似た問題に当たったときにも、またAIに頼るしかなくなります。短期的には楽ですが、長期的にはスキーマが育たず、依存から抜けにくくなります。

内在性認知負荷は変わらない

ドメイン自体の複雑さは、AIが書こうと自分が書こうと変わりません。AIは計算してくれますが、このビジネス要件をどう分解するかという内在的な難しさまで引き受けてもらうことは現時点（2026年7月時点）では難しいと思います。

つまりAIは、外在性負荷を増やし、学習関連負荷を削り、内在性負荷はそのままにしてしまう可能性があります。「速く書けているのに疲れる」という感覚には、こうした構造的な理由がありそうです。

AIはチームの認知負荷にどう影響したのか

個人だけの話ではなく、チームレベルではさらに気になる現象が観測されています。

生成量の急増(Faros AI、2025年)

Faros AIが2025年に公開したレポートは、1,255チーム、1万人超の開発者のテレメトリを分析したものです。

AI導入率の高いチームでは、平均PRサイズが154%増え、1日あたりのPR数が47%増え、開発者あたりのバグが9%増えるという変化が観測されています。個人がさばくタスク数は増えていますが、その分がレビューやテスト、デバッグにそのまま流れ込んでいる構造がうかがえます。

負債の蓄積(GitClear)

GitClearが数億行のコードを分析した結果では、AI普及期(2021〜2024年)にかけて、コード重複率が8.3%から12.3%に上がり、変更行に占めるリファクタリングの割合は25%から10%未満に下がっています。書く量は増え、直す量は減る。典型的な技術的負債の蓄積パターンです。

セキュリティリスクの増大(Apiiro)

同じ時期のApiiroの調査では、AI生成コードで権限昇格の経路が322%増え、設計上の欠陥が153%増え、AI関連コミットは通常より4倍速く本番にマージされている、つまりレビューが追いついていないという結果が出ています。SonarSourceの2025年8月の分析でも、主要なLLMはどれも一定割合で高深刻度の脆弱性を生成するという結果が出ています。

Team Topologiesで言う「チーム認知容量の超過」

Matthew SkeltonとManuel Paisは2019年の著書『Team Topologies』で、チームにも認知容量の上限があり、それを超えると出荷速度が落ちるという原則を示しました。

この本では、Swellerの認知負荷理論をチームレベルに拡張し、チームサイズはおおよそ8人程度が上限であること(Dunbar数がベース)、責任領域の数と複雑さがチームの認知負荷を決めること、負荷が容量を超えると品質低下・デリバリー遅延・燃え尽きが起きることが整理されています。

AIによって1人あたりの生成量が増えた結果、チームが抱えるコードベースやPR数、依存関係の総量が、8人分の認知容量を超え始めています。いま起きているのは、おおむねそういうことだと考えられます。

認知負荷が溢れると何が起きるか

個人には、書いているのに達成感が薄い、常にAI出力を検品している感覚が続くといったバーンアウトの兆候や、スキーマが育たずAIなしでは同じタスクに時間がかかるようになるスキルの退化、ワーキングメモリが外在性負荷で埋まることによる設計判断の雑さ、AIとの往復で中断が増えることによる集中力の低下が起きやすくなります。

チームには、PRサイズと数の増加にレビュアが追いつかなくなる滞留、AIが書き、各メンバーがその出力をさばくだけで設計の全体像を持つ人がいなくなる状態、新メンバーが把握すべき量の増加によるオンボーディングの困難化、重複や不整合、セキュリティリスクの蓄積が起きやすくなります。

個人でできること――Swellerのフレームで負荷を整理する

外在性認知負荷を削る

本来考えなくていいことは、道具に任せます。ESLintや型、Formatterで一貫性を自動化する。AIへのコーディングルールをCLAUDE.mdや.cursor/rulesに構造化して書き、毎回違う書き方をされるのを防ぐ。AIが毎回違うスタイルで書いてくる問題は、lintルールで静的に縛るのが早いです。

命名やスタイル、構造を自動で揃えることで、コードを読むときの「違和感の処理」に使うワーキングメモリを解放できます。

学習関連認知負荷を守る

ここが一番大事なところだと思います。AIに任せすぎると、自分の中にスキーマが育ちません。新しい領域に入るときは最初の実装を自分で書いてみる、AIの出力をそのままマージせずなぜそうなっているかを自分の言葉で説明できる状態を目指す、1人でAIを使うより人間同士の対話を交えたペアプロ・モブプロでAIを使う、といったことが有効だと思います。

短期の速度と長期のスキルは、意識的にバランスを取らないと前者に吸い取られてしまいます。

内在性認知負荷を下げる

課題そのものの複雑さは減らせませんが、一度に向き合う量は制御できます。1PRで扱う概念の数を減らす、AIに投げるタスクも大きな塊ではなく意味のある単位に分ける、「なぜこの設計にしたか簡潔に説明しながらコードを書いて」のように理解しながら書くことを促すプロンプトを使う、といった工夫が考えられます。

チームでできること――Team Topologiesで認知容量を守る

チームレベルの問題は、個人の努力だけでは追いつきません。設計の問題として扱う必要があります。

Stream-aligned teamの認知容量を守る

Team Topologiesの中核は、顧客価値をエンドツーエンドで届けるStream-aligned teamにフォーカスを集中させ、それ以外の負荷は他のチームに逃がすという構造です。AIによってドメインあたりのコード量が膨らんでいる以上、このチームが持っていい責任範囲はどこまでかを、あらためて引き直す必要があります。チームが抱えるドメインの数と複雑さを定期的に棚卸しし、1チームで扱う複雑ドメインは原則1つ、低複雑度のものでも最大2〜3個までに抑えます。AI導入後は生成量が増えているぶん、導入前より責任範囲を狭めるという発想も必要になってきます。

3種類の補助チームを使い分ける

Team Topologiesでは、Stream-aligned teamを支える3種類のチームが定義されています。
Platform teamは他チームが使う基盤をas-a-Serviceで提供するチームです。AI時代にはAIエージェント用の共通ルールやCI/CDのガードレール、共通lintプリセットの提供がこれにあたります。
Enabling teamは他チームのスキル獲得を一時的に支援するチームで、AIコーディングのベストプラクティスを広め、各チームが自走できるようにする役割を担います。
Complicated Subsystem teamは高度な専門性が要る領域を担当するチームで、独自のAIエージェント基盤や機密性の高いセキュリティレイヤなどが該当します。

ここで重要なのは、Platform teamの一番の目的がStream-aligned teamの認知負荷を下げることにある点です。単なるコスト削減や標準化のためではありません。

AI時代に必要なガードレール

チームレベルで具体的に仕込んでおきたいものとしては、AIが触っていい領域と触ってはいけない領域をADRや設計ドキュメントに明示すること、Farosの調査にあった154%増という傾向を前提にPRサイズの上限を機械的に設定してレビュアを守ること、コードは増えるが「なぜ」まではAIが書いてくれないので設計意図をドキュメント化すること、GitClearが示したリファクタ比率の低下を踏まえて定期的なリファクタ枠を確保すること、あたりが挙げられます。

AIが書く量ではなく、チームが理解し維持できる量を上限にする。そういう発想の転換が必要になっています。

まとめ

この記事では、AI時代のソフトウェア開発を認知負荷理論とTeam Topologiesの視点から整理しました。AIを前提とした開発では、コードを書く速度だけでなく、人間が理解・保守できる認知容量を意識した設計や運用が重要になります。個人・チームの双方で認知負荷を適切にコントロールすることが、持続的な開発につながると思います。

参考

Sweller, J., van Merriënboer, J. J. G., & Paas, F. G. W. C. (1998). Cognitive Architecture and Instructional Design. ↩