現場が作ったAIツールを埋もれさせない。社内配布と権限の設計

現場でAIツールを作れる人が増えてくると、しばらくして必ずこの状態にぶつかります。
作ったのは本人だけで、使っているのも本人だけ、社内AIツールの共有がどこにも設計されていない状態です。
推進担当から見ると、同じ業務をやっている人が他にもいるのに、そのまま使えるはずのものが個人の手元に留まったままという、かなりもったいない状況です。
作った側も、共有したくないわけではなく、「共有の手順を知らない」「共有していいのか分からない」、それだけのことです。

ここでは、社内配布と権限の設計を整理します。
作る側の全体像は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

埋もれる原因は3つあり、「完成していなくても配ってよい」が一番効きます

なぜ、作ったAIツールは個人の手元で止まるのでしょうか？
原因は、だいたい次の3つに絞られます。

まず、共有の手順そのものを知らないことです。
作る操作は覚えても、人に渡す操作までは試しておらず、教えている人もいません。

次に、そもそも共有していいのか分からない遠慮で、自分が作ったものを勝手に配ってよいのか、中途半端なもので迷惑にならないかが、いちばん大きな要因です。
もうひとつが置き場が決まっていないことで、共有しようと思ってもどこに載せればいいか分からず、個人のチャットで送るだけになって後から探せなくなります。
3つとも、手順を教える・配ってよいと明言する・置き場を決めるだけで、推進側が用意しさえすれば解決する話です。

探せる置き場をどう作るかはツールに限らず社内の資料全般に共通する話で、社内ナレッジをAIで活用する方法。ツール導入・RAG・手持ちのAIの選び方でも一つの節を割いています。

なかでも効果が大きいのは、共有していいのか分からないという遠慮を外すことです。
現場の作り手は自分のツールが荒いことを知っているので、「まだ人に見せる段階ではない」と判断してしまいます。
ところが受け取る側からすると、荒くても手元にないものより価値があります。

だからこそ推進側から、「完成していなくても配ってください、使ってもらって直すほうが速いです」と明示します。
あわせて、荒いものを配る心理的な障壁を下げる工夫も入れておきます。
カタログの項目に「試作」という区分を作っておくと、完成度の議論をしないまま置けるようになります。

また、最初に推進担当自身が自分の荒いツールを載せておくと、かなり効きます。
整ったものだけが並ぶ場所には、現場は自分のものを載せてくれないからです。

配布はチーム内→部門→全社カタログへと、3フェーズで広げます

配布は、どこまで一気に広げればいいのでしょうか？
ここも段階を踏むのが安全です。

最初はチーム内、5〜10人程度の範囲で行い、この段階でやることは共有の操作を1回やってみることと、使った人の反応を聞くことの2つです。
反応を聞くところが重要で、「入力の項目が分かりにくい」「出力の形をこうしてほしい」といった、作った本人が想定していなかった使い方がこの段階で見えてきます。
チーム内なら口頭で使い方を伝えられて説明書を書く必要がなく、この手軽さが最初の一歩を軽くします。

チーム内で使われるようになったら、次は部門に広げます。
ここから必要になるものが増えてきます。
まずは、何ができるかを1行で書くことです。
口頭で伝わる範囲を越えるので文字にしておく必要があり、例えば「議事録の文字起こしから、決定事項と宿題を抽出します」といった一文になります。

次に、使い方の例を1つ添えます。
何を入れれば何が出るかという具体例がないと、そもそも試してもらえません。
質問先も、作った本人の名前でよいので書いておきます。
詰まったときに聞けないものを業務に使うのはリスクなので、問い合わせ先が書かれていないツールは使われません。

最後に、想定する職種を「営業向け」「経理向け」と書いて、自分に関係あるかを判断できるようにしておきます。
この4項目が、部門共有の最低ラインです。

部門を越えて使われる段階になると、運用の設計が必要になります。
まず、載せる基準を決めます。
全部を載せると探せなくなるので、「2人以上が継続して使っている」程度の基準で足ります。

作った本人しか使っていないものは、まだ部門段階に置いておきます。
カタログそのものの作り方は共有したのに使われない。社内AI資産をカタログ化するにまとめてあります。

次に、更新オーナーをはっきり決めます。
部門を越えて使われると要望が増えるので、誰が直すのかを先に決めておく必要があります。
作った本人が持つのが基本で、異動する場合は引き継ぎ先まで決めておきます。
担当交代そのものの設計は担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計で扱っています。

3つ目が、職種でたどれるようにすることです。
用途別のリストより職種別のほうが使われるのは、「自分と同じ職種の人が何を使っているか」が見えると人は試すからです。

最後に、サポート窓口を1本にします。
全社に広がると作った本人への問い合わせが増えて負担になるので、一次対応の窓口を推進チーム側に置き、答えられないものだけ作者に回します。
ここを設計しないと、作り手のほうが共有を嫌がるようになります。

権限は扱う情報の種類で決まり、共有した人には見返りが要ります

配布の範囲と権限は、何で線引きすればいいのでしょうか？
基準になるのは、そのツールが扱う情報です。

手元のデータだけを処理するツールは、誰がどう使ってもデータが外に出ないので、全社に公開して構いません。
社内データを読むツールは、人事のデータのように全社公開してしまうと権限管理を迂回する経路になるため、そのデータ自体の閲覧範囲と一致させます。
社内データに書き込むツールは、書き込み先を壊す可能性があるので、業務として書き込む立場の人だけに使える人を限定します。

また、使えるけれど中身は変えられない状態にしておけば意図しない改変を防げるという理由で、編集権限と利用権限は分けておきます。
カタログに載せるときは、利用権限のほうで配るのが基本です。

共有が一度で終わるか続くかは、共有した人が報われるかどうかで決まる、ここが継続の条件です。
では、何をもって「報われた」と感じてもらえるのでしょうか？

まず、利用回数と利用者数を作り手に見せます。
「30人が使っている」と分かればその人はまた次を作りますが、分からないままだと共有した労力が報われた感覚が残りません。
次に、四半期に一度、作成者ごとの実績を部門長に共有すると、作った数と累計の利用回数を一覧にするだけで上司の評価コメントに載るようになります。

もうひとつが、月1回10分の共有の場を作ることです。
作った人が何を作ったかを話す場で「それ欲しい」という声が出れば、次を作る動機になります。
資産として回していく全体像は社内AIボットを共通資産にする。作成・共有・改善のサイクルで扱っています。

利用回数が作り手に届かない状態は、AIツールの社内共有が止まる原因の4つ目として、対策と並べて扱っています。

3つとも、称賛と要望が届く経路を作るという同じ目的のものです。
善意だけで回る期間は、そう長くありません。

失敗は、だいたい同じ5つに集約されます

配布と権限を整えても、つまずく組織には共通点があります。
何が失敗の分かれ目になるのでしょうか？
よくある失敗を5つ、まとめて見ていきます。

まず、共有の手順を教えないことです。
作る操作だけを教えて渡す操作を教えていない状態で、ここは配布物1枚あれば解決します。

配布物の元にするなら、Gemの共有の手順はGemの共有方法と、共有されたGemの探し方。スキルへの移行の前に決めること、Gemini Notebook（旧NotebookLM）はGemini Notebook（旧NotebookLM）の共有方法。社内で使える状態にするまでにまとめています。

次に、荒いものを配ってよいと言わない限り何も出てこないのに、完成度を求めすぎることです。
超最小単位で回す考え方は内製開発は超最小単位で回す。作りすぎて失敗しないためににまとめてあります。

また、置き場を決める前に共有を促すことも失敗のもとです。
個人のチャットで送られて、後から探せなくなります。

サポートを作った本人に全部負わせることも起こりがちで、負担が大きいと次から共有されなくなるので、一次窓口は推進側に置いておきます。
最後に、利用実績を作り手に見せないことです。
それでは、共有が一度きりで終わります。

カタログ化と利用回数の可視化が、作り手の燃料になる

ここまで見てきたとおり、手順や権限は整えれば済むのに対して、配布の設計で最も重要な「作り手が報われる経路」だけは仕組みがないと成立しません。
では、仕組み化すべきものは何でしょうか？
必要なのは「誰に、どれだけ使われたか」という一点だけです。

これが作り手に見えていれば次を作りますが、見えていなければ共有はそこで一度きりで終わります。
あわせて、部門を越えた利用が起きず使われないものからは実績も出てこないという理由で、職種でたどれる一覧も必要です。

私たちの組織のAIポータル「AI Portalize」では、社内で作ったAIツールを登録すると全社に公開され、「いいね」の数・使われた回数・使った人数が作った人に返ってきます。
作られてはいるが共有が続かない、という状態で止まっているなら、考え方の参考になるかもしれません。

埋もれさせないコツは、手順・段階・見返りをセットで用意することです

ここまでの内容を、実務の順番で並べ直しておきます。
どこから手をつければいいのでしょうか？

ツールが埋もれる原因は、「共有の手順を知らない」「配っていいのか分からない」「置き場が決まっていない」の3つで、どれも推進側が用意すれば解決します。
最も効くのは、「完成していなくても配ってください」と明言することです。
あわせて「試作」の区分を作り、推進担当が自分の荒いツールを最初に載せます。

配布は3フェーズです。
チーム内で反応を聞き、部門で4項目（何ができるか・使い方の例・質問先・想定職種）を添え、全社カタログに載せて更新オーナーとサポート窓口を決めます。
権限はそのツールが扱う情報によって決め、編集権限と利用権限は分けたうえで、最後に利用回数を作り手に見せる仕組みを作ります。

自部門で作られているツールを集めて、共有の操作を1つやってみると、次にすべきことが見えてきます。