組織内における自作AIツールの共有構造と管理手法

現場でAIツールを自作できる人が増えてくると、組織のあちこちで業務用のボットが立ち上がり始めます。

推進としては良い兆候ですが、このフェーズに入った組織は必ず同じ問題にぶつかります。
ツールが乱立して、「結局どれを使えばいいんですか」と聞かれる状態です。
顧客分析用のボットを10人がそれぞれ作ってしまい、ほぼ同じ用途のものが社内に10個ある、といった状況が起きます。

個別にカスタマイズしたい事情があるのは分かりますが、組織で見ると開発とメンテナンスの手間が膨らみます。
さらに、チャットで共有の報告が飛び交うぶん、大事なツールほどログに埋もれていきます。
結果として、せっかく作ったものが個人利用のままで止まります。
今回は、この重複作成と探す手間を解消する共有インフラの作り方を書いていきます。

まずは表計算の台帳から始める

共有構造を作るのに、いきなり高価なシステムが要るのでしょうか？
現実的で効果の早い第一歩は、表計算ソフトや社内Wikiを使った台帳管理です。

ポイントは、チャットにURLを流すだけで終わらせないことです。
いつの情報で誰向けに作られたものかが分からないと、使う側が判断できません。
「開いてみたら違った」という経験が数回続くと、人は台帳そのものを見なくなります。

台帳に持たせる項目は、最低限これくらいです。
何ができるか分かる「ツール名」、アクセス先の「URL」、営業向け・経理向けといった「おすすめ職種」、誰が管理しているかを示す「作成者」「責任者」、そして「作成日」「最終メンテナンス日」です。
日付の欄は必須で、ここがないと情報の鮮度が判断できません。

運用を始めるときは、既存のツールを全部埋めようとしないほうが進みます。
社内で実際に動いているものを5つか10ほど拾って先に並べ、残りは見つかり次第足していきます。
空欄の多い完璧な台帳より、少なくても中身が埋まっている台帳のほうが使われます。

そのうえで、ここを見れば使えるツールが分かる場所を、全社で1つに決めます。
「議事録ツールならこのリストにあるものを使えばいい」と全員が認識できる状態になると、それだけで無駄な重複作成が減ります。
台帳の整え方は共有したのに使われない。社内AI資産をカタログ化するで詳しく扱っています。

台帳をAIに読ませて案内役を置く

台帳ができたら、次の壁は何でしょうか？
そこにたどり着くまでの手間です。
項目が増えてくると、一覧から自分に合うものを探すこと自体が負担になります。
有効なのが、台帳そのものをAIに読み込ませて、案内役のボットを置くやり方です。

台帳をCSVやPDFで出力してナレッジとして連携し、ユーザーの困りごとに合わせて最適なツールとURLを案内するよう指示を書いておきます。
「議事録を要約したい」と入力すると、該当するツールの名前とリンク、どの職種向けかまでを返してくれます。
探す側は一覧を眺める必要がなくなり、アクセスのハードルが一段下がります。

案内役に持たせる情報は、ツール名とURLだけでは足りません。
「議事録の要約には使えるが、契約書のチェックには向かない」というところまで台帳に書いておくと、返答の精度が一段変わります。
向かない用途を書いておくのは地味ですが、期待値のずれによる離脱を防ぐうえでかなり効きます。

ただ、案内役が参照する台帳を更新し忘れると、古いツールを案内し続けます。
ナレッジの鮮度を保つ運用の考え方は古い情報で答えるAIを作らない。社内ナレッジの更新体制のつくり方に整理してあります。

推進チームのレビューで公開のハードルを下げる

公開をためらう人が多いのは、なぜでしょうか？
共有の器が整ってくると、今度は別のブレーキが出てきます。
現場の作り手が、自分の作ったものを全社に公開することをためらう心理的なハードルです。
実際、公開をためらう理由の多くは技術的な完成度ではありません。

自分の名前が出た状態で全社に配ることへの気後れがあり、「まだ作りかけなので」と言って手元に置いたまま数ヶ月が過ぎる、というのがよくある流れです。
「プロンプトに穴があったらどうしよう」「変な出力で業務に迷惑をかけたら、責任を問われるのではないか」といった懸念が理由になります。
作った本人ほど、その不安が具体的に見えています。

ここで効くのが、AI推進チームによるレビューとお墨付きの仕組みです。
公開の前に推進メンバーが一度テストして、機密情報の扱いやプロンプトの指示が適切かを確認し、問題がなければ承認します。
推進チームの安全チェックを通ったという事実は、作り手にとって想像以上に大きな後押しになります。

何かあったときに一人で抱えなくていいと分かるだけで、公開に踏み切れる人が増えます。
このレビュー体制が、現場発のアイデアを組織に波及させる鍵になります。

レビューの基準は、最初から細かく決めなくても構いません。
「機密情報を扱っていないか」「出力をそのまま社外に出す使い方になっていないか」「動かなくなったときに誰が直すのか」。
この3点を見るだけでも、公開して大丈夫かどうかの判断はだいたいつきます。

権限設計をどう組むかという実務は現場が作ったAIツールを埋もれさせない。社内配布と権限の設計、作る側の育て方は社内AIツールの内製化。現場が自分で作れる組織にするまでが参考になります。

使われているかが見えないと台帳は形骸化する

リスト共有が進むと、次は何が起きるでしょうか？
どれが良いツールなのか、選ぶ側にも分からなくなる問題です。
台帳に何十個も並んでいる状態だと、選ぶ側が疲れてしまいます。
厄介なのが、表計算での管理だと実際の利用回数や利用部署までは取れないことです。

どれが使われていてどれが放置されているのかが、管理者ですら分からなくなっていきます。
そのため、作成者と推進担当が定期的に台帳を見ながらメンテナンスする運用が必要になります。

とはいえ、この手動更新を続けるのはなかなか大変です。
現実的な落としどころは、四半期に一度、使われていないツールを一覧から下げるルールを決めておくことです。
そのうえで、利用状況が動的に見える仕組みへ移行できるのが理想です。

社内ポータルやダッシュボードを用意して、誰がどのツールをどれくらい使っているかが分かる状態になると、メンテナンスの優先順位が数字で決まります。
下げる判断には、作成者への確認を一度挟むのがおすすめです。
使われていないように見えても、「うちの部署は月末だけ使っています」というケースがあります。
数字だけで機械的に切ると、静かに困る人が出ます。

どれが使われているかが作った人に返らないことも、社内でAIツールの共有が進まない理由の1つです。

作るツールの粒度そのものを見直すのも効きます。
ひとつのボットに機能を詰め込むより、部品として分けておくほうが管理しやすくなります。
この考え方は万能AIボットを作らない。社内AIツールを部品化して組み合わせるに書いています。

公開した後も、面倒を見る人を決めておく

公開した後、誰が面倒を見るのでしょうか？
共有したツールは、公開した時点が完成ではありません。
使われ始めると、エラーの報告が来たり、「こんな機能がほしい」という要望が出たりします。
そのため、共有の条件として責任者を明確にしておくことが大切です。

守りの面では、エラー対応などのメンテナンスが欠かせません。
「動きません」という報告を放置すると、そのツールはあっという間に使われなくなります。
責任者が異動したときの扱いも、あらかじめ決めておくと安心です。

引き継ぎ先が決まらないツールは台帳から下げると決めておけば、誰も面倒を見ていないものが残り続ける事態を避けられます。
攻めの面では、機能改善のサイクルを回します。
台帳に要望のコメント欄を設けて、ユーザーが自由に書き込めるようにしておきます。
作成者はそこからニーズに気づいて、プロンプトや処理を直してバージョンを上げていきます。

このサイクルが回り始めると、ツールは使われるほど洗練されていきます。
改善を組織の資産として扱う仕組みは社内AIボットを共通資産にする。作成・共有・改善のサイクルにまとめてあります。

直した内容と理由を、担当が替わっても追える形で残すシートの列は、プロンプト管理の方法。社内AIボットを引き継げる管理シートの6列で書いています。

当社の組織のAIポータル「AI Portalize」では、社内で作ったAIツールを登録すると全社に公開され、「いいね」の数や使われた回数が作った人に返ってきます。

置き場所を作っただけで、共有は完結しない

自作ツールが増えたときに起きるのは、乱立と埋没です。
同じ用途のものが並行して作られ、大事なものがチャットのログに沈みます。
対策は4段階です。

まず表計算の台帳で置き場所を1つに決めます。
名称・URL・職種タグ・責任者・最終更新日を必須項目にします。

次に、台帳をAIに読ませて案内役を置き、探す手間を削ります。
また、推進チームのレビューで公開のハードルを下げます。
安全チェックを通ったという後ろ盾があると、現場は共有に踏み切れます。

最後に、利用状況を見える状態にして、使われていないものを定期的に下げます。
共有とは、置き場所を作ることではなく、みんなでツールを育てる土壌を作ることです。

まずは台帳のシートを1枚作って、社内で動いているボットを5つ書き出してみるところから始めるのが良いのではないかと思います。
ここを起点にすると、どの業務に偏っているか、誰が作り手として突出しているかも同時に見えてきます。