Post
JA EN

「AIを使う人」と「使われる人」を分けるのは、組織の学習設計——「導入して終わり」が二極化を固定する

Posted
By
49 min read
「AIを使う人」と「使われる人」を分けるのは、組織の学習設計——「導入して終わり」が二極化を固定する
  • 想定読者： AI導入を進める経営・人事・組織開発の担当者、チームの育成を担うテックリード／EM、現場のリーダー
  • 前提知識： 生成AIツール（ChatGPT / Claude / GitHub Copilot 等）を業務で使ったことがある程度。組織の人材育成・研修設計への関心
  • 所要時間： 約18分

概要

同じ生成AIを配っても、半年後には二種類の人が生まれる。AIに下案を出させ、それを批判的に検証し、複数案を束ねて価値に変える「使う人」と、AIの出力をそのまま貼り付け、間違いに気づかないまま下流に流す「使われる人」だ。よくある説明は「個人の地頭やリテラシーの差」だが、それは半分しか当たっていない。

この分水嶺をつくっている最大の変数は、組織の学習設計だ。ツールを配って「あとは各自で」と放置した組織は、放っておくと「使われる人」を量産する。逆に、役割分担を明確にし、検証力と協働体験を業務に組み込んで育てた組織は、同じツール・同じ人材で「使う人」の比率を上げられる。

ただし「研修を増やせばいい」という単純な話ではない。日本の労働者2.2万人を対象にした調査（JILPT, 2025）が示したのは、AI使用者のうち会社から訓練を受けたのはわずか25.3%という現実と、もう一つの重要な事実だ——仕事の質が改善するのは、訓練「だけ」を提供したときではなく、職場のコミュニケーション・学び直し・企業の支援が組み合わさったときだった1。つまり効くのは単発の研修ではなく、学習を支える組織の設計そのものである。

本記事は、この分水嶺を組織の学習設計の問題として扱う。姉妹記事「会社規模で変わるAI時代の役割設計」が示した6つの役割と規模の地図に学習設計の層を重ね——スタートアップは兼任で検証を体に通し、大企業はガバナンス教育を制度化する——若手育成や「予算がない」という反論まで、具体策に降ろしていく。

「個人の差」の前に、「組織が何もしなかった」がある

AI時代のスキル格差は、しばしば個人の問題として語られる。「あの人は地頭がいい」「リテラシーが高い」「もともと優秀」。ただ、現場をよく見ると、その手前に組織側の不作為があることが多い。

まず数字で現実を押さえる。労働政策研究・研修機構（JILPT）が2024年5〜6月に雇用者2.2万人を対象に行った「AIの職場導入による働き方への影響等に関する調査」（2025年5月公表）によれば、AIを使って働く労働者のうち、企業から訓練提供や資金援助を「行ってきた」と答えたのはわずか25.3%にとどまる1。全有効回答者ベースでは3.3%だ。残りの大多数は、ツールだけを渡され、使い方も検証の仕方も「各自で工夫してください」の状態に置かれている。

一方で、学ぶ意欲がないわけではない。同調査では、AI利用者のうち60.6%が「もっと学びたい」に同意している1。意欲はある。だが組織がそれを受け止める設計を持っていない。この「意欲はあるのに支援がない」ギャップこそが、放置されると個人差に見える格差を生む土壌になる。

ここで一つ、誤解しやすい点を先に潰しておく。「では訓練を増やせば解決か」というと、データはそう単純ではないと言う。JILPT が示したのは、仕事の質（パフォーマンスやメンタルヘルス）の改善効果は、訓練という単独施策から自動的に出るのではなく、次の3つが組み合わさったときに高まるという構図だ1。

  1. 新しい技術の職場導入をめぐる、企業と労働者のコミュニケーション
  2. AIを使いながら働くための学び・学び直し
  3. 企業の訓練提供や資金援助

研修だけを増発しても、現場との対話がなく、日常業務に学びが接続されていなければ、効果は出にくい。逆に言えば、「使う人」を増やす鍵は単発の研修イベントではなく、対話・学習・支援が噛み合った組織の学習設計にある。これが本記事の出発点だ。

分水嶺の正体——「検証力」と「協働体験」

では、組織の学習設計は具体的に何を育てればいいのか。「使う人／使われる人」を分ける能力を2つに絞る。

検証力——AIの「ほぼ正しい」を見抜く軸

AIは「ほぼ正しいが完全ではない」出力を大量に生む。Stack Overflow の2025年開発者調査では、84%がAIを使う／使う予定である一方、46%が出力の正確性を信頼しておらず、66%が「ほぼ正しいが完全ではない」AI出力を最大の不満に挙げていた2。この「ほぼ正しい」を見抜けるかどうかが、「使う人」と「使われる人」を最初に分ける。

検証力とは、AIの出力を鵜呑みにせず、「これは本当に妥当か」を自分の専門の軸で判定する力だ。元記事で論じたとおり、AI時代に役割の重心は「コードを書く」から「AIに書かせ、見極め、束ねる」へ移る3。その中核が検証力であり、これは座学では身につかない。自分が責任を負う成果物で、AIの出力を実際に検証し、間違いを踏み、直す経験を通じてしか育たない。

誰が「使われる側」に滑るのかを示す実証もある。Microsoft Research とカーネギーメロン大学が知識労働者319名・実例936件を分析した研究（Lee et al., 2025）は、AIへの信頼が高い人ほど批判的思考の関与が下がり、逆に自分の判断力への自信が高い人ほど批判的思考が深まるという関係を報告した4。AIを信じて自分を信じない人ほど、出力をそのまま受け入れてしまう。検証力とは、この「自分の軸で問い直す」関与そのものであり、AIへの過信と表裏の関係にある。同研究は、批判的思考の中身が「自分で答えを出す」から「情報の検証・統合・タスクの統括」へシフトすると整理しており、これは本記事の言う検証力の定義とほぼ重なる。鍵になるのは、組織が「AIを反対者(challenger)として扱い、自分の判断で検証する」習慣を育てられるかだ4。

協働体験——「依存の破綻点」と「拡張の伸びしろ」を体で知る

もう一つが協働体験だ。AIと一緒に仕事をして、「どこまで任せると破綻するか」「どう使えば自分の出力が跳ね上がるか」の両方を体感していること。

人材育成会社ファーストキャリアは、若手がAIに「思考を依存する」側と「思考を拡張する」側に二極化しつつあり、その差を決めるのは育成設計だと指摘する5。同社が有効としているのは、配属前の研修に「協働体験」を組み込む設計だ——「AIに依存した場合、どこで破綻するのか」「AIを拡張的に使った場合、どれだけアウトプットが良くなるのか」を、実際に手を動かして体験させる。

ここが座学との決定的な違いだ。「AIを過信するな」と講義で聞くのと、自分が任せすぎてプロジェクトが破綻するのを体験するのとでは、定着がまるで違う。協働体験は、検証力を「知識」から「身体感覚」へ変える装置になる。

graph TB
    A[ツールを配布] --> B{組織は学習を設計したか}
    B -->|導入して終わり| C[各自で工夫してください]
    B -->|検証力と協働体験を育てる| D[責任ある成果物で<br>検証を反復し破綻点を体感]
    C --> E[出力を鵜呑みにし<br>間違いを下流へ]
    D --> F[ほぼ正しいを見抜き<br>強みを増幅して使う]
    E --> G[使われる人]
    F --> H[使う人]

成功する組織と失敗する組織は、何が違うのか

「使う人」を育てる組織と「使われる人」を量産する組織の違いを、施策レベルで並べる。

観点「使われる人」を量産する組織「使う人」を育てる組織
導入の終わり方ツール配布と利用ガイドで完了配布後に役割・検証手順・評価を再設計
学びの場所単発の集合研修（座学中心）日常業務に検証と振り返りを埋め込む
AIとの関わり方「効率化のために使え」とだけ伝える依存の破綻点と拡張の伸びしろを体験させる
検証の責任暗黙に下流（レビュアー）任せ検証を誰の仕事か明示し、評価対象にする
対話現場の戸惑いを吸い上げない導入の影響を現場と継続的に対話する
失敗の扱いAI起因のミスを個人の責任に帰す「仕様が曖昧だった」と構造から学ぶ

この表の右側は、JILPT が示した3要素（コミュニケーション・学び直し・支援）の組み合わせ1と、検証力・協働体験という育てるべき2能力を、施策に翻訳したものだ。注意したいのは、左から右への移行は予算規模より設計の有無に依存する点だ。集合研修を年に何度やったかではなく、検証が日常業務に組み込まれ、評価され、失敗から学べる構造があるか。ここが分かれ目になる。

ただし留保を一つ。JILPT のデータは「3要素が揃うと効果が高まる可能性が示唆された」という相関の観察であり、「この設計にすれば必ず使う人が増える」という因果の証明ではない1。組織の学習設計が分水嶺になるというのは、現時点で合理的な見立てであって、対照実験で確立した法則ではない。自社で試すときは、効果を測りながら調整する前提で進めるのが正攻法だ。

規模別の学習設計——6つの役割に「育て方」を重ねる

ここからが本記事の中核だ。姉妹記事「会社規模で変わるAI時代の役割設計」は、AI時代に「実装する人」が6つの役割——プロダクト／FDE型・実装指揮・技術領域検証・エージェント基盤・ガバナンス・データ／ML——に分化し、その6つを何人で分けるかが会社規模で決まることを示した3。スタートアップは1人が全部かぶり、大企業は1役割＝1専任に分かれる。

役割の地図ができたなら、次の問いは「その役割を担える人をどう育てるか」だ。役割設計と育成設計は別物で、前者だけあって後者がないと、役割名だけが宙に浮く。規模ごとに、学習設計の具体策を置く。

スタートアップ（〜数十人）——兼任で検証を体に通す

スタートアップでは、そもそも研修部門も育成プログラムもない。6役割を1人が兼任する以上、学習は業務そのものをOJTにするしかない。ただ、これは弱点ではなく強みになりうる。

兼任は「協働体験」を自動的に生む。フロントもバックもインフラもAIに書かせて自分で検証する人は、否応なく各領域でAIの破綻点に出くわす。全領域で検証を反復する経験は、専任では得にくい横断的な検証力を育てる。

意図的に設計すべきは1点だけ——検証を飛ばさない仕組みだ。速度優先のスタートアップでは、AI出力をそのままマージする誘惑が強い。最低限、「マージ前に1人が必ず意図との乖離を確認する」「AI起因の事故を週次で1件振り返る」程度の軽量な習慣を回す。研修予算ゼロでも、これは設計できる。

中堅（数十〜数百人）——機能別の検証研修と「役割の上乗せ」

中堅になると機能別の分担が戻り、6役割の専任化が上の行から進む。学習設計も機能別になる。

具体策は「専任採用」より先に「役割の上乗せ」だ。既存のフロント／バック／インフラ担当に、いきなりAI専任職を外から採るのではなく、「あなたの領域でAI生成物の落とし穴を見抜く検証役」という役割を上乗せする。そのうえで、機能別に検証研修を設計する——フロントなら体感品質とアクセシビリティの検証、バックならデータ整合性と境界設計の検証、というように、領域固有の「AIが間違えやすいポイント」を教材にする。

ここで効くのが、JILPT の言う現場との対話だ1。中堅は導入の戸惑いが最も可視化される規模でもある。「AIに任せたら品質が落ちた」「何を検証すればいいか分からない」という現場の声を吸い上げ、それを研修内容に反映するループを回せるかが、学びが定着するかどうかを分ける。

大企業（1000人以上）——ガバナンス教育を制度化する

大企業では、検証力の個人育成に加えて、ガバナンスを「教育」として制度化する層が立ち上がる。AI利用の統制・監査・コンプライアンスは、元記事では専任の役割だったが3、学習設計の視点では「全員が最低限のガバナンス感覚を持つための教育」が別途要る。

具体的には、AI生成コードのセキュリティリスク、データの取り扱い境界、エージェント権限の設計といった「やってはいけないこと」を、専任者だけでなく現場の全エンジニアに浸透させる教育プログラムだ。規模が大きいほど、1人の不注意が全社リスクになる。ここは座学とケーススタディの併用が現実的で、人事・法務・セキュリティが連携して設計する。

人事の主導性は、この規模で最も重要になる。組織開発の専門家は、生成AI活用の鍵は技術導入ではなく「人」と「組織」のアップデートにあり、人事がAIを使う前提で組織をデザインし、スキル育成と文化醸成を主導すべきだと提言する6。大企業ほど、育成を現場の心がけに任せず、人事が制度として設計する責任が重くなる。

規模学習の形重点的に育てる能力設計の主体
スタートアップ業務そのものをOJT化（兼任）横断的な検証力現場リーダー
中堅機能別の検証研修＋役割の上乗せ領域固有の検証力テックリード＋人事
大企業ガバナンス教育の制度化＋検証研修検証力＋全社的なガバナンス感覚人事主導（法務・セキュリティ連携）

若手育成は「努力目標」として、組織の学習文化で支える

ここまでは全体の設計だ。最後に、若手育成を切り出して扱う。なぜ切り出すかというと、若手は「使う人／使われる人」の分岐が最も鋭く出る層だからだ。経験の浅い段階でAIに思考を丸投げする習慣がつくと、検証の軸そのものが育たない。逆に、早い段階で協働体験を積めば、「使う人」への立ち上がりが速い。

この「若手で分岐が鋭い」という見立てには、実証の裏付けがある。666名を対象にした研究（Gerlich, 2025）は、AI利用頻度と批判的思考スコアの負の相関を「認知オフロード」——考えることをAIに外注すること——が媒介すると報告し、とりわけ若年層（17〜25歳）でAI利用と認知オフロードが多く、批判的思考スコアが低い傾向を示した7。著者は「デジタルネイティブはむしろ認知オフロードに陥りやすいかもしれない」とまで述べている。

ただし、ここには2つの留保が要る。第一に、これは相関の観察であり因果は確定していない。著者自身、「AIが思考力を奪うのか、それとももともと批判的思考が弱い人がAIに頼りやすいだけなのか区別できない」と明記している7。第二に——そしてこちらが育成設計にとって重要だ——同じ研究で教育水準は保護的で、AI利用頻度に関わらず高学歴層は批判的思考を維持していた7。つまりこの傾向は年齢で固定されたものではなく、学習設計で動かせる。若手で目立つが、訓練で変えられる。だからこそ若手育成は「あきらめる対象」ではなく「努力目標」になる。

ただし、ここで一般化を避けたい。「若手をこう育てれば必ず使う人になる」という確立した方法論は、まだない。だから本記事では若手育成を、断定的な処方箋ではなく努力目標として位置づける。組織が個々の若手に成果を約束させるのではなく、組織の学習文化が若手の挑戦を支える、という方向だ。

努力目標として現実的なのは、次のような設計だ。

  • 新人研修に協働体験を組み込む：コードを書かせる前に、AIとの協働で「依存の破綻点」と「拡張の伸びしろ」を体験させる5。失敗を安全に経験できる場として設計する。
  • 「答え」ではなく「判断」を書かせる：AIに答えを出させたうえで、「なぜこの出力が妥当か／妥当でないか」を言語化させる。検証の軸を、知識ではなく実践で作る。
  • 概念が固まる前は、あえてAIを切る工程を残す：基礎が形成される前に全工程をAIに投げると、検証の軸が育たない。新人期の前半は「自力で再構成する」課題を意図的に残す。

これらが機能する前提は、心理的に安全なフィードバック文化だ。若手がAI出力の検証で間違えたとき、それを責めるのではなく「仕様が曖昧だったね」と構造から学べる場でないと、若手は萎縮して「AIの出力をそのまま出す」安全策に逃げる——つまり「使われる人」化する。検証は失敗を含む試行錯誤なので、失敗を罰する文化の下では検証力は育たない。

この点で、「若手はデジタルネイティブだから自然にAIを使いこなす」という前提で検証教育を省くと、操作の速さがそのまま未検証の出力を量産する速さに化ける。育成設計上の含意は単純だ——ツール習熟度の高さを、検証力の代理指標にしない。操作に慣れていることと出力を批判的に検証できることは別の能力で、後者は意図して育てない限り身につかない。

「効果が出ない」「予算がない」にどう応えるか

組織の学習設計を提案すると、決まって返ってくる反論がある。正面から扱う。

「教育投資しても効果が出ない」——これは多くの場合、「導入して終わり」か「単発研修だけ」の経験から来る。JILPT のデータが示すのはまさにその逆で、効果が出にくいのは訓練を単独施策として打ったときであり、現場との対話・日常への学びの接続・支援が組み合わさると効果が高まる可能性が示唆されている1。「効果が出ない」のは投資が無駄なのではなく、投資の設計が単発に閉じていることが多い。研修を一度やって終わりにせず、業務に検証を組み込む設計に変えることが先決だ。

「予算がない、特に中小企業では無理だ」——大規模な研修予算は確かに中小には重い。だが本記事で挙げた中核施策——マージ前の検証習慣、AI起因の事故の週次振り返り、判断を言語化させる課題——は、いずれも予算ではなく設計の問題だ。むしろ兼任が常態の中小は、業務そのものが協働体験になりやすく、検証を日常に埋め込みやすい。高価な研修プログラムがなくても、日常の検証習慣で「使う人」化は進められる。

「個人の責任で十分、組織で一律に教育する必要はない」——意欲のある個人は確かに自走する。しかし先に見たとおり、AI使用者の60.6%が「もっと学びたい」と答えているのに訓練提供は25.3%にとどまる1。意欲はあるのに受け皿がない。この差を埋めるのが組織設計の役割だ。個人責任に委ねた結果が、いまの二極化である。組織が学習を設計することは、自走できる個人を縛るためではなく、意欲はあるが支援を欠く多数派を「使う人」側に引き上げるためのものだ。

まとめ

「AIを使う人」と「使われる人」の分水嶺は、個人の地頭やリテラシーだけでは説明できない。その手前に、組織が学習をどう設計したか（あるいは、しなかったか）がある。

  • 「導入して終わり」が二極化を固定する：AI使用者のうち訓練を受けたのは25.3%、学びたい人は60.6%。意欲と支援のギャップが、放置されると個人差に見える格差を生む。
  • 効くのは単発研修ではなく組み合わせ：仕事の質改善は、現場との対話・学び直し・企業支援が噛み合ったときに高まる。育てるべき中核は「検証力」と「協働体験」。
  • 役割設計に学習設計を重ねる：スタートアップは兼任で検証を体に通し、中堅は機能別の検証研修と役割の上乗せ、大企業はガバナンス教育を制度化する。規模ごとに育て方が変わる。
  • 若手育成は努力目標として文化で支える：協働体験・判断の言語化・心理的に安全なフィードバックで検証の試行錯誤を支える。若年層に見える傾向は年齢で固定されず、訓練で動かせる。
  • 「効果が出ない／予算がない」の多くは設計の問題：投資が単発に閉じていないか、検証を日常業務に埋め込めているか。中小でも予算ゼロで設計できる施策はある。

元記事は「役割分担は個人の頑張りではなく組織設計の質の問題だ」と締めた3。本記事はそこに一層を加える——役割を担える人を育てる学習設計もまた、個人の心がけではなく組織設計の質の問題だ。誰を「使う人」にするかは、才能の問題である前に、組織が学習をどう設計するかの問題である。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

  1. 調査シリーズNo.256「AIの職場導入による働き方への影響等に関する調査（労働者Webアンケート）結果」 - 労働政策研究・研修機構（JILPT）(2025年5月23日). 雇用者2.2万人を対象（実査2024年5〜6月）。AI使用者の訓練提供率25.3%（全有効回答者ベース3.3%）、学習欲求60.6%、仕事の質改善効果はコミュニケーション・学び直し・企業支援の組み合わせで高まる可能性、の出典。【信頼性: 高】（公的機関による大規模調査。ただし因果でなく相関の観察） ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6 ↩︎7 ↩︎8 ↩︎9

  2. 2025 Stack Overflow Developer Survey: AI section - Stack Overflow (2025). 84%がAIを使用／使用予定、46%が出力の正確性を信頼していない、66%が「ほぼ正しいが完全ではない」AI出力を最大の不満として挙げた、の出典。【信頼性: 中〜高】 ↩︎

  3. 「何でも屋」になるべきか、分担を守るべきか——会社規模で変わるAI時代の役割設計 - 当ブログ (2026年5月20日). AI時代に「実装する人」が6役割へ分化し、規模が「何人で分けるか」を決めるという議論、役割の重心が「書く」から「検証・統制」へ移ること、組織設計の質の問題であることの出典。【信頼性: 中】（自ブログの先行記事。一次ソースは記事内に明記） ↩︎ ↩︎2 ↩︎3 ↩︎4

  4. The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers - Lee, H.-P. ら, Microsoft Research ＆ Carnegie Mellon University. Proceedings of CHI 2025. 知識労働者319名・実例936件。AIへの信頼が高いほど批判的思考の関与が下がり、自己の判断力への自信が高いほど高まること、批判的思考が「検証・統合・統括」へシフトすることの出典。査読済み（CHI）だが自己申告調査・相関。【信頼性: 中〜高】 ↩︎ ↩︎2

  5. 「AIと協働して成果を出す若手」をどう増やす？これからの若手育成施策設計のポイントとは - 株式会社ファーストキャリア (2025年12月16日). 若手が「思考を依存する」側と「思考を拡張する」側に二極化し、その差を育成設計が決めること、新人研修への協働体験（依存の破綻点・拡張の伸びしろの体感）の組み込みを提言。【信頼性: 中】（人材育成会社による実務的見解） ↩︎ ↩︎2

  6. 企業の生成AI活用には「人」が鍵。人事が導くこれからの組織デザイン - 小澤健祐（AICX協会代表理事）, UNITE powered by Unipos (2025年5月15日). 生成AI活用の鍵は「人」と「組織」のアップデートにあり、人事がAI活用を前提に組織をデザインし、スキル育成・文化醸成を主導すべきとする提言。【信頼性: 中】（専門家による実務的提言） ↩︎

  7. AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking - Michael Gerlich, Societies 15(1):6 (2025). N=666＋インタビュー50名。AI利用頻度と批判的思考の負の相関を認知オフロードが媒介し、若年層（17〜25歳）で顕著、教育水準は保護的であることの出典。著者は因果は未確定（弱い批判的思考の人がAIに頼る逆方向も否定できない）と明記。相関研究・自己申告と客観評価の併用・Correction あり。【信頼性: 中】 ↩︎ ↩︎2 ↩︎3

キャリア・働き方
AI時代のキャリア 組織設計 人材育成 リスキリング 検証力 学習文化 若手育成
This post is licensed under CC BY 4.0 by the author.