生成AI活用が「あの人頼み」になったときの解き方2026｜属人化を防ぐ5つの手順

生成AIを導入した組織でよく起きる状態があります。使いこなしている人が数人いて、その人たちに依頼が集まる状態です。一見すると成功に見えます。実際に成果も出ています。しかし、この構造は脆いままです。

その数人が異動したり退職したりすると、活用は元の水準まで戻ります。ツールも契約も残っているのに、使える人がいなくなるからです。本記事では、この属人化を診断し、解いていく手順を整理します。なお、アカウントやデータの引き継ぎ手続きは別の論点です。ここで扱うのは、手続きでは移らない「使い方の勘所」の方です。

属人化は「成功しているように見える」から見つけにくい

属人化が厄介なのは、問題として認識されにくい点にあります。依頼が集まるパワーユーザーは実際に成果を出しています。周囲も助かっています。数字の上では活用が進んでいるように見えます。

しかし、そこで測れているのは「組織が使えているか」ではありません。「その人が使えているか」です。この二つは別物です。前者は再現しますが、後者は本人が抜けた瞬間に消えます。

依存しているかどうかの簡易チェック

次の問いに答えてみます。判断材料は感覚ではなく、直近の実例で確認します。

• 特定の一人が明日から一か月不在になったとき、止まる業務はいくつありますか
• その人が使っているプロンプトを、別の人が見られる場所に置いていますか
• 「なぜその指示文にしたのか」を説明できる人は本人以外にいますか
• 直近の生成AI関連の相談は、何人に分散していますか
• その人が使っているツールの契約者・管理者は誰になっていますか

止まる業務が挙がり、相談先が一人に集中しているなら、依存は既に発生しています。ここで重要なのは、本人を責める話にしないことです。属人化は個人の抱え込みではなく、共有する仕組みを用意しなかった組織側の設計の結果です。

手順1：止まると困る業務から順に並べる

すべてを一度に共有しようとすると、量が多すぎて頓挫します。まず、その人が抜けたときに実際に困る業務だけを取り出します。

並べる基準は二つです。頻度と、代替の効きにくさです。毎日発生していても他の人がすぐ肩代わりできる作業は後回しで構いません。逆に、月に一度でも締切が固定されていて、やり方を知っているのが一人だけという作業は最優先です。

この作業は本人一人にやらせない方がうまくいきます。周囲から見て「あの人に頼んでいること」を挙げてもらう方が、本人が自覚していない依頼まで拾えるためです。

手順2：プロンプトではなく「判断」を書き出す

共有というと、プロンプトの文面を集めることだと考えられがちです。しかし文面だけを渡しても、たいてい再現しません。同じ指示文を使っても、別の人が使うと結果が違うからです。

差を生んでいるのは、文面の外側にある判断です。具体的には次のような部分です。

• どういう場面ではAIを使わず自分で書くと決めているのか
• 出てきた出力のどこを見て「これは使えない」と判断しているのか
• やり直すとき、指示のどこを変えているのか
• 参考として渡している資料は何で、なぜそれを選んでいるのか
• 最終的にどこまで自分で直してから提出しているのか

この四つ目と五つ目が、特に抜け落ちます。パワーユーザーは無意識に手直ししているため、本人の申告では「AIが出してくれた」で終わってしまいます。実際の作業を横で見るか、直前の出力と提出版を並べて差分を確認すると、言語化されていない工程が見えてきます。

書き出す形式は凝らなくてよい

整った手順書を目指すと着手が遅れます。最初は箇条書きで構いません。目的・使う場面・使わない場面・確認する点・よくある失敗、この五項目が埋まっていれば十分に機能します。形式を整えるのは、二人目が実際に使ってみた後です。

手順3：二人目を「担当」ではなく「一緒にやる人」として置く

引き継ぎを任命の形で進めると、多くの場合うまくいきません。手順書を渡して「これで頼む」と伝えても、判断の部分は文書に載りきらないためです。

有効なのは、一定期間だけ二人で同じ作業をやる形です。最初は二人目が手を動かし、パワーユーザーが横で見て指摘します。次に、二人目が一人でやったものをパワーユーザーが確認します。最後に確認を外します。三段階を踏むと、文書化されていない判断が会話の形で移っていきます。

この期間は一時的に工数が増えます。そこを許容できるかどうかが分かれ目です。増える分を「引き継ぎのコスト」として事前に見込んでおくと、現場が後ろめたさを感じずに進められます。

手順4：置き場所と更新の担当を決める

書き出したものが個人のメモ帳に残っていると、共有していないのと同じです。誰でも見られる場所に置きます。そのうえで、更新の担当を決めます。

更新されない手順書は、時間が経つと有害になります。ツールの仕様が変わったり、業務そのものが変わったりすると、書いてある通りにやっても再現しなくなるためです。そして「書いてあるのに動かない」経験を一度すると、次からは誰も読まなくなります。

更新の頻度は業務の変化に合わせます。仕様変更が多い領域なら短い周期で、安定している領域なら長い周期で構いません。重要なのは、次にいつ見直すかを決めておくことです。期日がないものは見直されません。

手順5：一人に集まる構造そのものを変える

手順1から4は、既に発生した依存を解く作業です。同時に、再発を防ぐ側も見ておきます。依頼が一人に集まるのには理由があります。

多いのは、他の人にとって最初の一歩の負荷が高い状態です。アカウントの申請に時間がかかる、どのツールを使えばいいか分からない、失敗したときに怒られるかもしれない、といった障壁があると、詳しい人に頼む方が早くなります。そして頼むほど、頼まれる側だけが上達します。

この循環を切るには、頼む以外の選択肢を軽くします。使い始めるまでの手続きを短くする、用途ごとに推奨ツールを決めておく、試して失敗した記録を共有しても不利にならないと明示する、といった対応です。パワーユーザーの負担を減らす取り組みでもあります。

役割を評価の中に置く

共有や引き継ぎは、本人の業務時間を使います。それが評価に反映されないと、続きません。教える側の貢献をどう扱うかを決めておくと、協力を個人の善意に頼らずに済みます。

まとめ：仕組みが残るまでは成功と呼ばない

生成AIの活用は、使える人が現れた時点では途中経過です。その人が抜けても回る状態になって、はじめて組織の能力になります。

取り組む順番は、止まると困る業務の洗い出し、判断の言語化、二人目との並走、置き場所と更新担当の決定、そして依頼が集中する構造の是正です。すべてを一度にやる必要はありません。まず、いま一人しかできない業務を一つ選び、二人目を並走させるところから始めます。一件でも型ができれば、以降は同じ進め方を使い回せます。

本記事は組織運営上の一般的な整理です。人事評価や労務の取り扱いは各社の制度によって前提が異なります。実際の運用は自社の規程と担当部門の確認を経てご判断ください。