はじめに｜開発者が、実験への参加を断り始めた
9月も半ばです。3月期決算の企業なら、下半期の始まりまで半月ほど。前回（第20回）で整理した5つの接続点は、そろそろ「誰が、いつまでに」の段まで降りてきている頃でしょうか。
その作業と並行して、開発・技術部門を見ていて引っかかっていることはないでしょうか。コード生成AIの導入は進んだ。開発者からの変更申請（プルリクエスト）の本数も増えた。ところがレビューで「なぜこの設計にしたのか」と尋ねると、返事が返ってこない。テストは通っている。動いてもいる。でも、書いた本人が中身を説明できない。
その違和感を、思いがけない形で裏づけた出来事があります。AI評価を行う非営利研究機関METRが、2026年2月24日、開発者の生産性を測る実験の設計を変更すると公表しました(*1)。理由は、結果が悪かったからではありません。実験そのものが成立しなくなったからです。
AIなしで仕事の半分をこなすのは嫌だ——そう言って参加を断る開発者が増えた。時給50ドルを払ってもです。参加した人でも、30〜50%が「AIなしではやりたくない」という理由で一部の課題を提出していませんでした。普段Uberに乗っている人間が、急に街を歩いて横断しろと言われるようなものだ、と表現した参加者もいます。
依存は、使用量には表れません。「なしでやること」を避ける度合いに表れます。今回は、その均衡をどう設計するかを扱います。
体感と実測は、驚くほど簡単にずれる
METRが最初にこの実験を行ったのは2025年の前半でした。大規模なOSSリポジトリ（オープンソースの共有プログラム群）に何年も関わってきた熟練開発者16人に、自分のプロジェクトの実課題246件を出してもらい、1件ずつランダムに「AI使用可」「使用不可」を割り当てる。結果は、AIを使えるときのほうが19%長くかかったというものでした(*2)。
驚くのはその先です。開発者たちは事前に「24%速くなる」と見込み、実験を終えたあとも「20%速くなった」と感じていました。実際には遅くなっていたのに、です。
ここで誤解のないように申し添えます。METR自身がこの結果に「もう古い」と注記を付けています(*2)。2026年2月の続報では、後継実験の生データはむしろ速度向上を示唆しており、現在の開発者は当時より加速している可能性が高い、と同機関は述べています(*1)。「AIを使うと遅くなる」という話をしたいのではありません。
押さえるべきは、体感と実測がおよそ40ポイントずれたという一点です。しかも、ずれていたのは素人ではなく熟練者でした。
補助線がもう一つあります。同機関が2026年5月に公表した技術職349人への調査では、AIによる仕事の価値向上を最も控えめに答えた層が、METR自身の職員でした。過去の「体感と実測のズレ」を知っているからではないか——同機関はそう推測しています(*3)。断定はできない、と自ら断ったうえでの推測ですが、示唆的ではあります。
あなたの部門のAI活用は、体感で報告されているでしょうか。それとも、第17回で測った成果創出率のように、数字で報告できているでしょうか。
依存が削るのは、速度ではなく判断
では、依存が進むと何が起きるのか。ここに正面から答えた研究があります。
Microsoft ResearchとCarnegie Mellon大学の共同研究(*4)は、週1回以上業務で生成AIを使う知識労働者319人に、実際の利用事例936件を挙げてもらいました。1件ずつ「このタスクで批判的に考えたか」を尋ねたところ、「考えた」は936件中555件、約6割。裏を返せば4割は、本人の自覚としても、批判的には考えていません。
分かれ目は、意外な場所にありました。そのタスクをAIがこなせるという自信が高いほど、批判的思考は減る。一方、そのタスクを自分でもできるという自信、そしてAIの出力を評価できるという自信が高いほど、批判的思考は増える。
面白いのは、AI全般への信頼度では差が出なかったことです。効いていたのは「AI観」ではなく、目の前の一件について、自分とAIのどちらをどれだけ信用するかという、その場の見積もりでした。なお同論文は、これは相関であって因果を示すものではない、と明確に断っています。
批判的思考を妨げる要因は、気づき・動機・能力の3つに整理されています。このうち能力について、同論文はこう書きます。知識労働者はしばしば、AIの出力を検査し、改善し、誘導するスキルを持たないために、批判的に考えることを控える、と。設計を評価できない人に、設計の良しあしを問う習慣は生まれません。
同論文は、40年以上前の古典も引いています。定型作業を機械に任せ、例外処理だけを人間に残すと、判断力を鍛える日常の機会が失われ、いざ例外が来たときには備えがない——1983年に指摘された「自動化の皮肉」です。低リスクの場面で練習しないまま、高リスクの場面だけが唯一の実践機会になる。これはリスク管理として明らかに危うい。
Google CloudのDORA（研究組織）も、2026年3月10日の分析で同じ場所を指しています。Googleのソフトウエアエンジニア1,110件の自由回答を分析した結果、入り口の障壁を下げることは、深い専門性に必要な「productive struggle（生産的な苦闘）」を飛ばしてしまう——同分析はこれを「専門性のパラドックス」と呼びました(*5)。突破的な生産性を生む使い方が、同時にスキル形成をふさいでしまう、と。
「設計力が落ちた気がする」は、精神論ではありません。構造の話です。
これは、現場の自制心の問題ではない
とはいえ、ここで「若手の心構えが」と結論づけるのは早計です。日本の数字を見ると、話の重心は別のところにあります。
総務省が2026年7月に公表した令和8年版情報通信白書(*6)によれば、自社の何らかの業務で生成AIを利用している日本企業は86.4%。2024年度調査の55.2%から大幅に上昇し、米国90.9%、ドイツ91.6%、中国98.1%との差はかなり縮まりました。使ってはいる。ここは、もう問題ではありません。
問題はその隣の欄です。生成AIによる業務変革について尋ねると、「組織的な取り組みはない」と答えた日本企業は27.0%。米国1.4%、ドイツ4.9%、中国2.6%と比べて突出しています。
環境整備の状況も、同じ方向を向いています。日本の回答企業326社のうち、「業務プロセスの見直しや生成AI活用検討に必要なスキルやノウハウを学ぶ環境がある」と答えたのは39.9%。米国62.7%、ドイツ60.4%、中国71.7%です。「特に実施している施策はない・把握していない」は日本19.9%で、米国の0.7%とは桁が違います。
つまり、こういうことです。個人は使っている。組織は、使い方を学ぶ場所を用意していない。 その空白が、そのまま個人の自己管理責任として現場に押し戻されている。
DORAの表現を借りれば、AIは増幅器です(*5)。内部プラットフォームの質が高く、ワークフローが明確で、テストが整っている組織では、AIは強力な協働者になる。逆に、ツールが分断され、データが分断され、基盤がもろい組織では、技術的負債を速く作る手助けをするだけになる。第8回で扱った技術・組織・心理の3つの壁は、AIによって消えるのではなく、増幅されるのです。
あなたの会社で、エンジニアが「AIとの付き合い方」を学ぶ場は、業務時間の中に置かれているでしょうか。
均衡を設計する——4つの装置
抽象論はここまでにします。下半期の初日から動かせる装置を4つ挙げます。
▶︎ 装置1：測る——3指標シートに、1列足す
第17回の3指標シート（実務適用率・行動変容率・成果創出率）に、開発・技術部門だけの列を1つ追加してください。「代表業務1つについて、AIなしで着手できる人の割合」です。
測り方は難しくありません。四半期に一度、対象業務を1つ選び、AIを使わずに着手だけしてもらう。完成させる必要はありません。方針が立つかどうかを見るだけです。
DORAは、生成行数のような出力量ベースの指標を「実際の生産性の物差し」として使うのはやめるべきだと書いています(*5)。ツールの浸透度を見る指標としてはなお有効だが、AIは出力量をいくらでも膨らませられるからです。測るなら、量ではなく影響を測る。この原則は、依存度の測定にもそのまま当てはまります。
▶︎ 装置2：残す——手で書く領域を、明示的に決める
DORAが「深い専門性を守る」ために挙げた具体策は、驚くほど地味です(*5)。複雑なシステム部品については手でコードを書くことを推奨する。AIが生成したアーキテクチャ上の判断を、若手とベテランがペアでレビューする。それだけです。
UC Berkeleyの学生を8カ月にわたって調べた別の調査(*7)では、学生自身が自分でガードレールを作っていました。先に自分で解いてからAIに聞く。1行ずつ検証する。支援ありと支援なしを意図的に交互にする。AIは着手のためだけに使い、完成には使わない——。指示されたわけではなく、自分の学びを守るために編み出された作法です。
部門として決めるべきは、「どこまでAIを使うか」ではなく「どこは自分で書くか」です。認証、課金、データ整合性——事故ったときに事業が止まる領域を、まず1つ指定してください。
▶︎ 装置3：組み替える——検証税を、書き手側に戻す
DORAは、AI導入に伴う隠れたコストを「検証税」と名づけました(*5)。書く時間が減った分が、そのまま監査の時間に振り替わる。しかもその負担は、書いた本人ではなくレビュアーに移ります。書き手はAIで巨大な変更を一気に生成できるのに、レビュアーは1行ずつ手で確かめるしかない。
処方箋は3つ示されています。AIによる指摘は、レビュアーではなく書き手に、書いている最中に返す。小さなバッチで出す。組織の基準はレビュー前に自動で当てる。
第18回で「伸ばす・譲る・深める」を扱いましたが、下半期の開発部門で最初に手を入れるべきは、レビュー工程です。ここが詰まったまま生成速度だけ上げると、DORAが観測したとおり、スループットと不安定性が同時に増えます(*5)。
▶︎ 装置4：確かめる——外部の物差しに、原理を当てる
社内だけで「原理を理解しているか」を測るのは、実務的にかなり難しい。ここは外の物差しを借りるのが早道です。
IPAの情報処理技術者試験は、2026年度から応用情報技術者試験・高度試験・情報処理安全確保支援士試験のすべてがCBT方式となり、前期・後期の年2回実施に変わりました(*8)。方式は変わりましたが、問う知識・技能の範囲、出題形式、配点、合格基準に変更はありません(*8)。
日程が、ちょうど下半期の立ち上がりに重なります。
| 手続き | 期間 |
| バウチャーチケット購入申込 | 2026年9月25日10時〜10月13日17時 |
| 受験申込受付開始 | 2026年10月6日10時（高度・SCは10月24日17時まで、APは11月7日17時まで） |
| 高度試験 科目A-1・A-2 | 2026年10月17日〜10月27日 |
| 応用情報 科目A | 2026年10月28日〜11月10日 |
前期試験の高度区分には、システムアーキテクト試験とネットワークスペシャリスト試験が含まれます(*8)。設計と基盤——まさに、いま社内で怪しくなっている領域です。受験手数料は7,500円。バウチャーチケットを使えば、企業が従業員の分を一括して支払えます(*9)。
150分間、AIなしで問題を解く。 その体験を年に1回、業務として用意する。第6回のカークパトリック5段階でいえば、L2（学習）の測定にあたります。
ここで第16回の3ステップを思い出してください。夏季賞与で試験導入し、9〜10月に検証し、11月から制度化する——いまは、ちょうど検証の段です。あのとき挙げた4指標のうち④学習継続は、資格や研修受講歴を評価に織り込む設計でした。外部試験の日程は、その空欄にそのまま入ります。
購入申込の開始は9月25日10時です。部門の対象者を洗い出すには、今週がちょうどいいタイミングではないでしょうか。
維持するのは、昔のやり方ではない
最後に、誤解を1つつぶしておきます。
均衡を保つとは、AIを使わない時間を作ることではありません。Microsoft／CMUの研究は、生成AIによって知識労働の中身が3つの方向にずれたと整理しています(*4)。情報収集から検証へ。問題解決から、出力を自分の文脈に統合することへ。作業の実行から、AIを統括すること（スチュワードシップ）へ。
育てるべきは、この3つです。そして同論文が最後に付け加えたのが、情報収集と問題解決という土台の能力を維持しておくことが、過度な依存を避ける助けになるという一文でした。土台と新スキルは、二者択一ではありません。土台があるから、統括ができる。
予算の話をすれば、装置1から3に新規の費目はほとんど要りません。既存のレビュー工程と研修枠の中身を組み替えるだけです。実費が出るのは装置4だけ。第19回で書いたとおり、大事なのは金額の多寡ではなく、同じ金額を何に使うかを変えることです。そして第20回で最後まで空欄が残りやすかったリスク管理の行に書き込むべき中身は、まさにこれです。
下半期の初日にやることは、たった1つで構いません。開発・技術部門の代表業務を1つ選び、「AIなしで着手できるか」を測る欄を、3指標シートに足す。数字が出たら、装置2から4のどれを先に回すかは、おのずと決まります。
10年後も設計を語れるチームを持っているかどうか。その分かれ目は、意外なほど地味な場所にあります。
＜ 参考文献・出典 ＞
*1 METR「We are Changing our Developer Productivity Experiment Design」2026年2月24日
https://metr.org/blog/2026-02-24-uplift-update/
*2 METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」2025年7月10日（2026年2月に結果の更新注記あり）
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
*3 METR「Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity」2026年5月11日
https://metr.org/blog/2026-05-11-ai-usage-survey/
*4 Hao-Ping (Hank) Lee, Advait Sarkar, Lev Tankelevitch, Ian Drosos, Sean Rintel, Richard Banks, Nicholas Wilson「The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers」CHI ’25（2025年）、Carnegie Mellon University／Microsoft Research
https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf
*5 DORA（Google Cloud）「Balancing AI tensions: Moving from AI adoption to effective SDLC use」2026年3月10日
https://dora.dev/insights/balancing-ai-tensions/
*6 総務省「令和8年版 情報通信白書（概要）」2026年7月
https://www.soumu.go.jp/main_content/001082851.pdf
白書本体掲載ページ
https://www.soumu.go.jp/johotsusintokei/whitepaper/index.html
*7 DORA（Google Cloud）「Managing AI dependency: How students are establishing guardrails with AI」2026年2月17日
https://dora.dev/insights/managing-ai-dependency/
*8 独立行政法人情報処理推進機構（IPA）「令和8年度 応用情報技術者試験、高度試験及び情報処理安全確保支援士試験の申込受付期間及び試験実施期間について」2026年7月6日公開／2026年8月26日最終更新
https://www.ipa.go.jp/shiken/2026/ap_koudo_sc_kikan.html
*9 独立行政法人情報処理推進機構（IPA）「令和8年度前期試験におけるバウチャーチケットの購入申込みについて」2026年8月26日
https://www.ipa.go.jp/shiken/2026/r08zen_voucher.html
＜前回までの記事はこちら＞
AIの現在地から考える人材開発〜生成AI幻滅期に考えるリスキリングとアップスキリング〜
