AIツールが定着しない対策は、研修ではなく4択の判定を誰が回すか

「AIツールが定着しない」ことへの対策で最初に決めるべきは、研修をもう1本増やすかどうかではない。使われなくなったものを一件ずつ棚卸しして、維持・再設計・保留・撤退のどれかに処遇を振る判定を、誰が回すかである。国内の検索結果はこの問題を「定着しない＝推進が足りない」の一方向で扱っており、処方も研修・ガイドライン策定・アンバサダー育成・チェンジマネジメントと、どれも推進の側を厚くする手当てに集まる。だが海外の元記事を並べると、放棄は推進不足の結果というより、合理的な判断の結果であることが多い。合理的な判断なら、推してもひっくり返らない。本稿はこの一点に絞る。

AIツールが定着しないのは、推進が足りないからなのか

答えを先に置く。足りていないのは推進ではなく、使われなくなったものを読む側である。

数字から入る。Everyで技術コンサルティングを率いるMike Taylorは、何千人にAIのワークショップを教えてきた経験から、ClaudeやChatGPTではなくMicrosoftのCopilotを使う理由として最も多く挙がるのは「使わなければならないから」だと書いている。

“I’ve taught AI workshops to thousands of people, and the most common reason people give me for using Microsoft Copilot over Claude or ChatGPT is ‘because I have to.’”

（私は何千人もの人にAIのワークショップを教えてきたが、ClaudeやChatGPTではなくMicrosoft Copilotを使う理由として最も多く挙がるのは「使わなければならないから」である。出典: Every by Mike Taylor、2026-08-04）

この一文が指しているのは、推進が足りない状態ではない。推進が最大まで効いた状態である。情報システム部門がCopilotを選ぶのは、それが安全な選択肢で、長年供給されてきた他のMicrosoft製品と統合するからだ、とTaylorは書く。配布は完了し、利用は命令で担保されている。彼自身はCopilotのライセンスを買い、導入の難所も越えたが、まだ乗り換えていない。ドロップダウンでOpus 4.8が「実験的」と表示される一方でチームの他のメンバーがFableやSolで野心的なものを作っているという落差が理由で、Copilotへ強制された人が抱く反感、そして自分が最前線から取り残されているのではないかという不安は理解できる、と彼は書いている。

配布の数字そのものは伸び続けている。Copilotは前四半期に有料シートを1,000万追加し、累計3,000万を超える途上にある。配布数が配った先で選ばれているかを語らないことはAI ROIのKPI設計、自己申告の時短を経営会議に出すのをやめるで扱った。本稿が使うのはその先である。命令で担保された利用は、推進の余地をもう残していない。

Taylorは、Microsoftのエージェント構築ツールであるCopilot Studio自体は高く評価している。エージェントが他のエージェントを呼び出せるので各エージェントのスコープを小さく保てる、それが信頼性の源泉だという設計上の利点を挙げ、Microsoftには人が実際に使うAIエージェントを作る最良の道具を生み出す可能性があると書く。にもかかわらずIT部門を持たない側に広がらないのは、購入・初期設定・権限付与を通り抜けるまでが苦行だからである。彼の周囲の大半はCopilotを試そうとすら考えず、試したとしても初期設定を通過できないだろう、と彼は書いている。

ただしTaylorは、この難所がIT部門を持つ企業では障害になっていないとも書いている。Microsoftの世界で日常的に働く情報システム部門の担当者は、アカウントと権限の設定に慣れており、追加される安全性を好み、どの設定が何をするかを知っているのが仕事だからだ。苦行で止まるのは、情報システム部門を通さずに試そうとする個人や小さなチームの側である（Copilot のライセンス配布数は AI 導入の成功指標になるのか — Copilot Studio の実力とユーザー流出の実態で扱った）。

ここで国内の処方と突き合わせてみる。研修は、初期設定の難所を越えさせる手当てではない。ガイドラインは、最前線から取り残される不安を解消しない。アンバサダーは、命令で使われている状態をそれ以上押し上げられない。処方が効いていないのではなく、処方が当たっている先が違うのである。

使われなくなった4つの理由のうち、研修で埋まるのはどれか

先に言い切る。ほぼない。

Everyのライター、Katie Parrottは、自分が放棄したAIワークフローの事後検証を書いている。発端は、同社CEOのDan Shipperがメール・Slack・会議メモ・社内の更新を1か所に集めて処理する「Tend」という自作の仕組みを見せてくれたことだった。通話が終わった瞬間、彼女はその記録をCodexに渡して自分用の版を作らせた。Codexはそれを「Attention Desk」と名付けた。彼女はそれを使う人物像を思い描けた。1日の大半を深い作業に沈め、何度か浮上して誰が何を必要としているかを見て、また消える、以前より10倍生産的な自分である。

執筆時点で、Attention Deskはピン留めされたチャットの中に放置されている。

彼女が自分の数字を数えたところ、受け取るSlackは1日平均6〜8件だった。Tendが解いているのは、多方向に引っ張られるCEOの通信を集約するという問題であり、彼女にはその問題がなかった。さらに彼女は1日に40〜50回Slackを確認する。それは執筆の不快感からの逃避であり、確認するたびに安堵か新しい情報の刺激という即座の報酬がある。Attention Deskが差し出す「心の平穏」は、その報酬と競争にならなかった。

対照にあるのが、定着した方のワークフローだ。彼女が使い続けている執筆支援の一式（compound writing plugin）は、失敗例を基準にすれば不利な条件が揃っていた。他人から借りたもので（メールアシスタントCoraのゼネラルマネージャーKieran Klaassenの仕組みを模している）、手間がかかり、Slack確認の習慣とも競合する。それでも定着した。理由は、うまく動くようになる前から効果の兆しを返してきたことだという。押し返す相手になる段落をくれ、議論の詰まりを解く問いをくれ、書くことに内在する孤独という実在の問題を解いた。放棄された方との差は、努力の量ではなく、解いていた問題と、効果が返ってくるまでの時間だった。

“A workflow may go unused for a boatload of reasons: The problem is too infrequent, the trigger doesn’t go off, or the output creates more work than it saves.”

（ワークフローが使われなくなる理由は山ほどある。問題の発生頻度が低すぎる、トリガーが発動しない、アウトプットが節約分より多くの仕事を生む。出典: Every by Katie Parrott、2026-07-20）

彼女は最後に、自分のAIの仕組みを監査するAIの仕組みを足した。Codexの中に置いた「Agent Ops」というプラグインで、作ったり採り入れたりしたワークフローを棚卸しし、それぞれの目的・利用状況・結果を1問ずつ尋ねてから処遇を勧める。これを設定する過程で彼女が見つけた放棄の理由は、4つに分かれた。存在を忘れていた / 動かなかった / 出力の維持に手間がかかりすぎた / 繰り返し起きる問題を解いていなかった（導入した AI ツールはなぜ使われなくなるのか——Keep/Redesign/Revisit/Retire で判定する棚卸しの枠組み）。

この4つを国内の処方に当ててみる。1つ目は通知と導線の設計の問題である。2つ目は実装の問題だ。3つ目は出力品質か後処理の設計の問題で、価値が維持コストを下回っている。4つ目はそもそも需要がない。研修が届くのは、強いて言えば1つ目の「存在を知らせる」部分だけで、それも研修よりは導線を直したほうが早い。ガイドラインとアンバサダーも同じで、4つのどれにも正面からは当たらない。

Parrottはこの4分類を、判定が起動する条件として数字に落としている。新しい自動化は手動で3回動かしてから定期実行に載せる。出力はレビュー5分未満で使える状態でなければならない。未使用の実行が4回あったら、変更か撤退の判定を起動する。

この3本をそのまま借りるべきだという話ではない。一人の書き手が自分の仕事のために置いた暫定の数字であって、業界の標準ではないし、彼女自身「暫定のルール」と書いている。移植できるのは数字ではなく形のほうだ。判定が起動する条件を、事前に数字で決めてあるという形である。国内の「定着しない」記事が持っていないのはここで、原因と対策の一覧は提示されても、何が起きたら誰が判定を始めるのかが書かれていない。

全社共通のマニュアルを配っても定着しないのはなぜか

先に言い切る。マニュアルに書ける部分が、定着を決める部分ではないからだ。

Everyで業務統括を務めるArielle Shipperと、コンサルティング統括のNatalia Quinteroが、互いのCodexの構成を見せ合った。結果は対照的だった。Quintero自身の構成は詳細な計画立案・コンテキストの整理・出力の監督で成り立っている。Shipperの構成は、リマインダーとメッセージを置いて、本人が追いかけたり注意を払ったりしなくてもその項目が片付くようにする形だった（Shipperの構成をこう性格づけているのはQuinteroである）。人がAIをどう使い、プロジェクトやファイルの体系をどう組むかは、その人の考え方の鏡だ、とQuinteroは言う。

Parrottは同じ回で、構成が人ごとに分かれる理由を4つの決め事に整理している。エージェントにどのコンテキストを渡すか、どこまで自力でやらせるか、どの作業に常設の手順を与えるか、どこで許可を求めさせるか。この4つの答えは、その人の仕事量や考え方、生活で変わる。だから他人の設定から借りられるのはアイデアまでで、その人の仕事量・頭脳・人生は借りられない、と記事は書く（全社共通の AI 活用マニュアルはなぜ機能しないのか — 個人最適ワークフローの設計と横展開）。

Parrott自身の代替案は、マニュアルではなく面談の型だった。彼女はCodexに、自分の仕事・必要なもの・システムに支えてほしい判断について面談させ、その答えをデスクトップの構成とピン留めするスレッドの提案に変えさせた。そうして自分に合うCodexの構成を手にしてから、この手順を同僚のライターLaura Entisに渡している。

彼女が「やり直すならこれを使う」として公開しているプロンプトは、その手順をもう一段細かくしている。1問ずつ面談させ、繰り返し発生する業務や正となる情報の置き場など、本人しか答えられない項目を押さえる。構成と常設の指示、手作業のまま残す範囲まで提案させたうえで、そこでは何も作らせずに待たせる。締めは読者への指示になっている。実際にやっている仕事に照らして提案を点検し、理解できた部分だけを承認してから作らせること。

横展開されたのは設定ではなく手順である。ここが「マニュアル配布のあと研修」との分かれ目だ。マニュアルは4つの決め事の答えを一つに固定して配るが、答えは人によって違う。手順は、答えを本人に出させる。

同じ構図を、経営層の側から見た整理もある。Every Consultingの2人（Natalia QuinteroとMike Taylor）が2026年6月2日のライブセッションで経営層の33の質問に答えた回で、2人が業界を問わない落とし穴として挙げたのは4つだった。誰が業務プロセスを持つのかが不明確なこと、経営層自身のAI習熟が弱いこと、ツールが散在していること、ワークフローを作り直していないこと。彼らの言い方では、人々は自分の仕事にそれをどう組み込むかを知る前に、ツールへのアクセスを手にしている。

そして彼らが避けよと言うのは、1,000人が1,000個の私的なプロンプトのフォルダを抱える状態である。処方は、繰り返す業務のうち良いものを再利用できるスキルに変え、それを可視化し、編集可能にし、誰かの所有物にし、全員が使えるようにすること。本稿はこの「所有」を、ライセンス管理ではなく、改訂する義務を負う人が決まっているかという意味で読む（AI 全社導入の次に経営層は何を決めるべきか ― 33の質問への回答に見る人材育成・ガバナンス・組織設計）。

所有者のいないスキルは、誰も撤退を判定しない。だから使われないまま残る。放棄が検知されない組織では、放棄は「定着しなかった」という漠然とした印象として溜まり、次の予算サイクルで「もっと研修を」という結論になりやすい。

処遇の判定を誰にどの頻度で持たせるか

決め事は一つに絞れる。判定を回すのは業務の事業所有者であり、回すきっかけは暦ではなく起動条件である。これを今期の運用に書き込むことだ。

実務は3手で足りる。

第一に、判定を回す主体を業務の事業所有者に置く。 Every Consultingの助言は、業務ごとに事業の所有者・技術の所有者・リスクの所有者・人間の承認者を定義するほうが、先に組織図を描き直そうとするより明確だというものだった。処遇を出すのは、この4役のうち事業の所有者である。情報システム部門でもAI推進の専任組織でもない。元記事の助言でも、ワークフローと成功の定義を持つのは事業チームで、アクセス制御・システム構成・セキュリティレビューを持つのが情報システム部門である。推進する側が撤退の判定まで持つと、自分が配ったものを自分で引き下げる構造になり、判定そのものが出てこなくなる。この配置を決めると、判定の単位もツールではなく業務に移る。ツール単位で問うと「Copilotは定着したか」という、答えの出ない問いになる。母集団が全社員で、用途が無数にあるからだ。業務単位なら「請求書の処理は何分になり、手直しは何回起きているか」になる。前者は配布数しか答えを持たないが、後者は処遇を出せる。

第二に、判定が起動する条件を数字で先に置く。 Parrottの3本（手動3回・レビュー5分未満・未使用4回）は、そのまま使うものではなく形を借りるものである。Every Consultingが自動化の候補の条件として挙げるものも、同じ形をしている。毎週起きて、出力の形が決まっていて、人間が短時間でレビューできる作業は、良い候補だ、と。この条件から外れていた業務は、定着しなかったのではなく、最初から候補ではなかった。起動条件を先に置くことの効果は、この区別が後から付けられるようになる点にある。そして頻度の答えもここで出る。判定は定期の棚卸し会ではなく、条件に触れたときに起動させる。 固定の頻度が要るのは、起動条件をまだ持たない業務を洗い出す作業だけだ。四半期の棚卸し会だけを置くと、条件に触れた業務が次の会まで放置され、その間に「使われていない」という印象だけが溜まる。

第三に、判定の出力を4択に固定する。 維持・再設計・保留・撤退である。Parrottの監査プロンプトが明示している2つの制約が、この4択を機能させている。頻繁に使われていることを価値の証拠と見なさないこと、そして放棄されたことを失敗の証拠と見なさないことだ。

“Do not assume that frequent use equals value or that abandonment equals failure.”

（頻繁に使われていることが価値と等しいとは考えず、放棄されたことが失敗と等しいとも考えるな。出典: Every by Katie Parrott、2026-07-20）

彼女自身の監査では、Attention Deskは「あとで再検討」に振られた。撤退ではない。仕事の性質が変われば——メールが大幅に増えるか、無害な気晴らしへの興味を失うか——必要になるからである。4択のうち「保留」が効いているのはこの型で、撤退と再設計の2択しかない組織では、需要が来ていないだけのものまで捨てることになる。

もう一つ付け加える。この判定を品質ゲートにしないことだ。PMへのAI研修を3万人以上に行ってきたColin Matthewsは、AIの使い方を3つの「はしご」と各段階で整理したうえで、すべての作業・業務・会社が最上段を目指す必要はないと書いている。それぞれのはしごの正しい段は、目の前の仕事にとって最適な使い方で決まる、と（PMのAI活用レベルをどう測るか ― トップPMに学ぶ3つの「はしご」フレームワーク）。定着率そのものを上げることを目標に置くと、最上段へ押し上げる圧力になり、第二の条件から外れた業務にまで自動化が載る。判定は、業務を上に押し上げるためではなく、処遇を決めるために回す。

では何を測るのか。Every Consultingの整理では単一の指標はなく、業務ごとのサイクルタイム・出力の品質・エラーの数・手戻りの回数・利用者の満足度・従来の費用便益に加えて、再利用を追う。共有されたスキルを何人が使い、どれだけ改訂され、チームの通常の手順になったか、である。経営会議に出す指標そのものの設計はAI ROIのKPI設計、自己申告の時短を経営会議に出すのをやめるで扱った。本稿が扱ったのは、その指標に載せる前段——使われていないものの処遇をどう決めるかである。エージェントを業務に乗せたあとで何が壊れるかはAIエージェント導入、成功事例だけでは決められない ― 失敗パターンと組織実装のリアルと合わせて読める。

まとめ: 研修を足す前に、放棄を読む仕組みを決める

AIツールが定着しない対策の議論は、推進の厚みの話に寄りすぎている。だが、ある書き手が自分の放棄したワークフローを棚卸しして得た4つの理由に当ててみると、研修・ガイドライン・アンバサダーが当たるものはほとんどない。存在を忘れられたものは導線の問題、動かなかったものは実装の問題、維持に手間がかかりすぎたものは価値がコストを下回った問題、繰り返し起きる問題を解いていなかったものは需要そのものがない問題である。配布側で起きていることも同じ向きを指す。Copilotは前四半期に1,000万シートを足したが、使う理由として最も多く挙がるのは「使わなければならないから」だった。配布数は、配った先で選ばれているかを語らない。経営が今期決めるべきは、研修をもう1本増やすかではなく、使われていないものを一件ずつ4択に振る判定を、業務の事業所有者に持たせ、起動条件に触れたときに回させること、その一点だ。