「どのモデルが一番賢いか」「エージェントで何％自動化できるか」「人件費をどれだけ削れるか」——生成AIの議論は、いまもこのあたりに引力が強いです。PoCの数字がきれいに見えるほど、経営会議の資料もそちらに寄りがちです。
けれど、MITの経済学者ダロン・アセモグルの議論を経済学の外から読むと、争点はもう一段深いところにある、と気づきます。彼はAIによるGDP押し上げを今後10年でおおむね1.1〜1.6%、生産性の年率上昇も0.05%程度と見積もり、業界が語るほど短期で経済全体をひっくり返すとは限らない、と慎重な立場を取っています（What do we know about the economics of AI?（MIT Economics）、論文本体は The Simple Macroeconomics of AI（Economic Policy, 2024））。これは「AIは大したことがない」という話ではなく、どの方向に設計し、誰の判断を強め、誰の判断を弱めるかが本丸だ、という警告に近いです。
IT技術者にとって、この問いは他人事ではありません。私たちはAIを使う側であると同時に、業務システム、ワークフロー、データ基盤、エージェント環境、権限、監査ログ、UI/UXを通じてAIの使われ方そのものを設計する側でもあるからです。本記事では、アセモグルが提起する知識崩壊（Knowledge Collapse）を、教育論ではなくシステム設計・ナレッジマネジメント・ガバナンスの問題として読み解きます。思考の空洞化や認知的主権の話は 便利すぎるAIは、なぜ技術者の思考を弱くするのか に譲り、ここでは組織の知識がどう痩せていくかと、それを防ぐ設計の地図に焦点を当てます。
ROIの数字の向こう——「自動化率」だけでは測れない影響
現場でよく聞く問いは、だいたい次の形です。「この業務の何％をAIで自動化できるか」「問い合わせを何件減らせるか」「レポート作成を何分短縮できるか」「人間のレビューをどこまで減らせるか」。ROIを語るうえで、時間とコストの指標は避けられません。
ただ、アセモグルの視点を借りると、この問いの立て方は少し狭い、と言えます。AIの影響は作業時間が短くなるかどうかだけでなく、人間の判断能力、学習行動、組織内の知識蓄積のしかたまで変えるからです。コード生成AIを開発現場に入れたとします。短期的には実装は速くなる。ボイラープレート、テストの雛形、ドキュメントの初稿——どれも助かります。
ここから先が設計の本番です。チーム全体がAIの出力を深く読まず、設計意図やエラー処理、境界条件を理解しないままマージするようになったら、表面的な生産性は上がっていても、内部には別の負債がたまります。それは読みにくいコードやテスト不足といった技術的負債だけではありません。認知的負債です。「なぜこの設計か説明できない」「AIが書いたので理解者がいない」「障害時にログを読んでも原因を推定できない」「レビューは通ったが、レビュアーも深く読んでいない」——こうした症状は、エージェント型AIが普及するほど現実的になります。AIは成果物を速く出せますが、理解する経験までは人間に与えてくれません。使い方を誤ると、試行錯誤や比較、失敗から学ぶ時間まで短縮してしまうのです。
「知識崩壊」とは何か——一般知識と現場知識の補完関係
2026年のNBERワーキングペーパー 「AI, Human Cognition and Knowledge Collapse」（NBER Working Paper 34910、MIT Stone Center の解説）では、生成AI、とくにエージェント型AIが、人間の学習インセンティブと社会の情報エコシステムにどう効くかが分析されています。論文が整理するのは、意思決定には共有された一般知識と、個人や現場に固有の文脈知識の両方が必要で、それらは補完関係にある、という点です。
AIは一般知識には強い。それでも、現場の制約、例外、過去の経緯、暗黙知を完全に置き換えるわけではありません。ところが人間がAIに依存しすぎると、現場固有の知識を自分で獲得する動機が弱まる。短期的には意思決定は速くなる。長期的には、組織全体の知識基盤が痩せていく——これが知識崩壊です。エージェントの推薦精度が一定のしきい値を超えると、一般知識が社会から消えうる「知識崩壊の定常状態」に入りうる、という動学モデルも示されています。福祉はAIの精度に単調増加しない、という含意は、「精度を上げれば上げるほど安全」ではない設計判断につながります。
IT現場に翻訳すると、こういう絵になります。社内の障害対応ナレッジは、Wikiの一般手順と、当該サービスだけの依存関係や過去のインシデントの文脈がセットです。RAGで要約を引くだけにすると、前者は取り出せても後者が育たない。エージェントが自動でロールバックまで進めると、MTTRは下がるかもしれないが、チームのトラブルシューティング能力は弱くなるかもしれない。速さと学習はトレードオフになりうる、と設計表に書いておくべき項目です。
エージェントは「便利な部下」ではなく、権限を持つプロセス
AI活用は、チャットボットからエージェント型AIへ移りつつあります。従来は人間が入力し、人間が出力を読み、人間が次の操作をしていました。エージェント型では、AIがタスクを分解し、ツールを呼び、APIを叩き、ファイルを作り、ワークフローを実行します。アーキテクチャ上、AIは自然言語インターフェースではなく、業務プロセスを実行する主体に近づいています。
そうなると、モデル精度だけでは足りません。どの権限を与えるか、どのデータに触らせるか、どの操作に人間承認を要するか、どのログを残すか、どの判断を委譲してはいけないか、誤作動時に誰が追跡できるか——セキュリティ、ガバナンス、監査、SRE、業務設計、UXが交差します。エージェントを「便利な部下」と見ると設計を誤ります。権限を持った自動実行プロセスとして、Cron、CI/CD、RPA、ワークフローエンジン、IAM、監査ログ、ゼロトラストと同じ文脈で扱う必要があります。権限・検証・観測・状態の四つ組は 賢いモデルを探す競争は終わった——次世代AIで勝つ「権限・検証・観測・状態」の設計と運用 で整理しています。エージェント統制の実務は エージェンティックAI時代のセキュリティは防御から統制へ——「動くAI」を止めずに制御する設計へ とも接続できます。任せ方の実測データは AIエージェントを使うとき、どこまで任せてどこで止める？——Anthropicの実測研究が教えてくれたこと を参照してください。
三つの方向——置き換え、強化、そして新しいタスク
アセモグルの議論で外せないのは、AIの影響を単純な「自動化」に畳まないことです。おおまかに三方向があります。人間の作業を置き換えるAIは、既存業務の一部を自動化し、人間の関与を減らします。人間の判断を支援するAIは、検索、要約、比較、異常検知、仮説生成で、人間がより良い判断をする手がかりを出します。新しいタスクを可能にするAIは、これまで難しかった分析、設計、個別化、モニタリングを可能にします。
この三つを混同すると、導入効果の測り方も設計もずれます。障害対応でAIがログを要約し「おそらく原因はこのサービス」と示すのは、調査を助ける強化です。一方、原因を断定して設定を自動変更し、担当者が中身を理解しないまま承認するのは、置き換えに近く、長期ではチームの能力を蝕みます。導入後に必ず問うべきは、「処理時間は短くなったか」だけではありません。このAIは人間の理解を増やしているか。それとも、理解しないまま進められる範囲を広げているだけか。 この差は、四半期単位では見えにくく、数年で効いてきます。
スキルの空洞化——学習を飛ばす道具にもなる
IT業界では、すでにスキルの空洞化が起きやすい領域があります。コード生成AIのおかげで、初学者でも一見それらしいSQLやTerraform、Kubernetes manifestが書ける。学習支援として使えば非常に強力です。出力を理解せずに使えば、学習を飛ばす道具にもなります。
エラーが出るとまずAIに貼る。なぜ出たかは読まない。修正版が動いたら終わり。差分の意味を説明できない。同種のエラーに再び出会っても自力で対処できない——このループでは、問題は解決しているように見えて、人間側の内部モデルは育ちません。プログラミングでもインフラでもセキュリティでも、本当に効くのは「なぜそうなるか」を理解することです。AIが答えを出せる時代だからこそ、出力を検証する力、設計意図を読む力、抽象化する力が以前にも増して求められます。AIはジュニアの成長を加速しうる。同時に、試行錯誤の機会を奪いうる。分岐はツールの性能だけでは決まらず、チームの使い方、レビュー文化、学習設計で決まります。個人の認知の話は前述の 便利すぎるAI を、ボトルネックとして残る仕事の話は 「詰まる人」が評価される——AIが速くなるほど、技術者に残る仕事の正体 をあわせて読むと、個と組織の両面がつながります。
レビューの再設計——「動く」から「説明できる」へ
AIを本格導入する開発組織では、コードレビューや設計レビューの意味も変わります。従来は人間が書いた成果物を人間が確認していました。AI生成物が混ざると、レビュー対象はコードそのものだけではなくなります。この変更を誰が理解しているか。生成に使った前提は正しいか。AIが存在しない仕様を補完していないか。依存ライブラリやAPI仕様は現行か。例外処理は運用条件に合っているか。将来の保守担当者が読めるか。生成者本人が説明できるか。
AI時代のレビューで重要なのは、モデル内部の完全な説明（explainability）というより、人間側が設計意図・リスク・制約・変更影響を説明できる状態を保つことです。レビューは品質保証であると同時に、チームの知識を維持する仕組みでもあります。生成が速いほど、基本のエンジニアリング——仕様、テスト、権限、観測——が支配的になる、というQCon London 2026周辺の議論とも響き合います（AIが速いほど怖い——「基本のエンジニアリング」が支配的になる理由を読み解く）。
「直して」と「考え方を出して」——委譲と補助の分岐
日々の使い方にも、はっきりした分岐があります。AIを委譲先として使うのか、思考の補助線として使うのかです。
「この仕様を満たすコードを書いて」と「この仕様を満たす実装方針を3案出し、トレードオフを説明して」は、似ていてまったく違います。前者は実装の委譲、後者は設計判断の支援です。「このエラーを直して」と「原因候補を優先順位つきで出し、確認すべきログと仮説検証手順を示して」も同様です。前者は修正作業の自動化、後者はトラブルシューティング能力を高める使い方です。AI活用の成熟度は、プロンプトの巧みさだけでは測れません。答えを出させるのではなく、人間の判断を鍛える形で使えるか——ここが分かれ目です。
RAGと社内ナレッジ——検索性が上がると、読む力が下がる
企業内AIでは、RAGや社内ナレッジ検索が定番です。議事録、仕様書、FAQ、障害報告、チケットをベクトル化してLLMに参照させる。非常に有効です。落とし穴もあります。検索性が上がると、人間は原文を読まなくなる。要約が便利になると、更新日や例外条件を見落とす。AIが「それらしく」答えると、古い前提が一気に広がる。
従来の検索では、複数文書を見比べ、更新日を確認し、書き手や文脈を読み取っていました。AI回答では、それらが一つの自然文に圧縮されます。便利ですが危険でもあります。根拠文書、更新日、信頼度、未確認事項が見えない回答は、社内ナレッジのインターフェースとして不十分です。エンタープライズAIを設計する技術者は、回答を自然にするだけでなく、根拠の明示、原文への導線、矛盾時の警告、答えられないときの正直な停止、重要判断での人間確認をUXに埋め込む必要があります。PoCから本番への持ち上げでは、評価と観測まで含めて初めて信頼の形になる、という話は デモで終わらせない——RAGとCopilotが本番で踏む地雷と、PoCからの持ち上げ方 で触れています。
判断インフラのロックイン——AIは次第に業務OSになる
アセモグルが懸念するもう一つの論点は、AIの力の集中です。IT現場では技術スタックの依存として具体化します。大規模モデル、GPU、クラウド、データ、API、開発者エコシステムは一部の大企業に寄りやすい。その結果、特定ベンダーのAPIに業務フローが結合し、プロンプトやエージェント設計が特定モデル前提になり、評価基準もその出力特性に最適化され、乗り換えコストが上がる。
これは単なる vendor lock-in ではなく、判断インフラの lock-in です。業務判断、顧客対応、開発支援、採用、教育、監査の一部がAIに依存すると、プラットフォームの仕様変更、料金、利用規約、性能、セーフティポリシーの変更が業務そのものに効きます。AI導入を「便利なSaaSを1つ入れる」感覚で扱う余地は、どんどんなくなっています。抽象化レイヤー、監査ログ、モデル切替可能性、データ持ち出し制御、評価基盤、フェイルセーフ——業務OSの一部として設計する意識が要ります。規制と標準の地図は パワーと規制のあいだで——ISO/IEC 42001（AIMS）がIT技術者に効く理由 が参考になります。
設計者が持つべき五つの観点
アセモグルの問題提起をITシステム設計に落とすなら、次の五つが実務のチェックリストになります。
Augmentationを先に決める
AIを「人間を減らす仕組み」にするのか、「人間の判断を強くする仕組み」にするのかを、要件の段階で明文化します。専門業務では、最終判断の代替より、判断材料の整理、選択肢の比較、リスク提示のほうが安全なことが多いです。
Human-in-the-loopを形骸化させない
「最後に人間が承認するから安全」は、しばしば形だけになります。人間が理解できない速度と量でAIが出力し、承認ボタンを押すだけなら、実質的には自動化です。判断できる情報量、表示形式、比較材料、根拠、反証可能性をUIとワークフローに設計します。
出力に根拠と履歴を結ぶ
参照元、生成時刻、使用モデル、プロンプト、参照データ、実行ツール、操作ログを、回答や変更とセットで残します。障害対応、品質改善、教育、ナレッジ継承のすべてに効きます。
学習機会を奪わないUXにする
すべてを完成形で渡すUIは便利ですが、学習を奪います。オンボーディングや開発支援では、考え方、確認手順、代替案、失敗例を示す設計を選びます。AIを使うほど人間が賢くなる配置を目標にします。
モデル依存を前提に層を分ける
モデルもAPIも価格も性能も変わります。業務ロジックを特定モデルに密結合させない。プロンプト管理、評価基盤、モデルルーティング、ログ、権限、RAG、UIを分離し、必要に応じてベンダーやモデルを切り替えられるようにします。
まとめ——モデル選定の先にあるアーキテクトの仕事
AI導入の初期には、どのLLMが高性能か、どのAPIが安いか、どのエージェントフレームワークが便利か、に注目が集まります。もちろん重要です。けれど、アセモグルから学べるのは、本当の影響がもっと深い層で起きる、ということです。AIは業務プロセスを変え、組織の知識の流れを変え、人間の学習行動を変え、判断の所在を変え、権限と利益の集中構造を変えます。導入は単なるツール導入ではなく、人間とシステムの境界の再設計です。
IT技術者にとってAIは強力な武器です。コード、ログ、仕様、テスト、分析、問い合わせ、ドキュメント、業務フロー——できることは増え続けています。ここで問うべきは「どこまで任せられるか」だけではありません。AIを使うことで、人間はより良く判断できるか。チームの知識は増えているか。障害時に強くなっているか。若手は成長しているか。属人性は減っているか、ブラックボックスは増えていないか。組織は自律性を高めているか、外部プラットフォームへの依存を深めているか。
第一に——知識を残す設計を要件に入れる
効率化だけをKPIにしない。説明可能性、レビュー、ナレッジの原文への導線を、最初からスコープに含めます。
第二に——エージェントをプロセスとして統制する
権限、承認、ログ、ロールバックを、CronやCI/CDと同列の設計対象にします。
第三に——AugmentationかReplacementかを毎回言語化する
導入提案のたびに、「人間の理解は増えるか」を一行で書く習慣をつけます。
AI導入で本当に怖いのは、仕事がなくなることだけではありません。仕事は残っているのに、人間がその意味を理解できなくなることです。人間の知識を残す設計。人間の判断を強くする設計。人間が説明できる設計。組織が学び続ける設計——その視点を持てるかどうかが、これからのAI活用の質を決めます。フロンティアモデルの公開前評価という国家レベルの動きは フロンティアAIは「出す前に評価される」——米国のTRAINSと、IT技術者が描くべき設計地図 で別角度から整理しています。モデルの外側と内側、両方の地図を持つことが、これからの技術者には求められると思います。
作成日：2026年5月17日