AI活用ノウハウは「配る」のではなく「流通させる」

「自社のAI活用ノウハウは、いま誰の手元に溜まっていますか？」
この問いに、すぐ答えられる企業はまだ少ないのではないかと思います。生成AIの導入そのものはすでに多くの企業で進められており、ライセンスを配り、環境を整え、利用を促す。ここまでも同じように取り組まれているのではないでしょうか。
それでも「使い続けられている」状態にはなかなか届かない、という声をよく聞きます。原因は、ツールの性能ではなく、成果を出している使い方が組織のなかを移動していかないことにあるように思います。うまく使えている人はいる。けれど、その使い方が隣のチームには届かない。届かないまま、その人が異動する。といったことが組織では起こりえます。
そこで当社が取り組んだのが、AI活用のノウハウを「配る」のではなく「流通させる」ための仕組みづくりです。本稿では、社内で立ち上げた社員投稿型の「AI活用ノウハウ（SKILL）を全社で共有する仕組み」を題材に、流通の経路をどう設計し、自由投稿型でありながら統制をどう成立させるのか、検討した内容をご紹介します。

1．なぜ今、AI活用ノウハウの「流通」が課題になるのか？

生成AIの利用が一定規模に達した組織では、二つの問題が同時に立ち上がることが想定されます。

課題① ノウハウの断絶問題

導入は進んでも、成果を生み出したノウハウが組織に広がらない問題です。

• 「こう使えばうまくいく」という知見が、個人・チームに閉じたまま蓄積される
• 他部署が同じ試行錯誤を繰り返し、学習が積み上がらない
• 担当者の異動とともに、ノウハウそのものが失われる

課題② ユースケースの活用問題

模範解答の一律配布では、自分の業務で使えるユースケースとして受け取れない人が出てくる問題です。

• 業務文脈はプロジェクト・役割・業種によって大きく異なる
• 配られた使い方が自分の業務に接続できず、業務で使えるユースケースとして受け取れない
• 研修や事例共有会はその場限りで、ノウハウが他の人の手元に残る仕組みがない

とくに課題①の三つ目は見落とされがちです。個人の工夫として最適化されたノウハウは、その人の頭のなかにしか残っていません。組織としては、同じ取り組みを何度も払い直していることになります。

よくある打ち手と、その限界

ノウハウを広げようとするとき、多くの組織はまず次の三つに手をつけると思います。
それぞれ一定の効果はあるものの、単体では効果になりきりません。

社内Wikiに書き溜める
書く側の負担が大きく、書かれた時点で更新が止まります。読む側も、自分の業務に使えるページがどこにあるかを探せません。情報は増えても、再利用の回数は増えないという状態になりがちです。

ベストプラクティスを配布する
運営が選んだ「良い使い方」を配る形です。品質は担保できますが、選定と更新が運営の作業量に制約されます。加えて、配られた側からすると「自分の業務とは前提が違う」という距離が残ります。

事例共有会を開く
モチベーション向上には効果的です。ただ、共有されるのは「うまくいった話」であって、聞いた人がその場で自分の環境に持ち帰れる形にはなっていません。会が終わると、ノウハウはまた個人に戻ります。

この三つに共通しているのは、ノウハウが「伝える対象」として扱われている点です。伝わったかどうかは受け手次第です。優れた事例を運営から配るだけでは、このギャップは埋まりません。現場が自分の業務文脈に近い使い方へ自力でたどり着き、そのまま自分の環境で動かせる経路を、仕組みとして用意する必要があると考えました。

2．SKILL（agent skill）とは？

本稿で扱う「SKILL」とは、生成AIエージェントに特定の業務を実行させるための手順・ツール呼び出し・設定・補助ファイルを、ひとまとめにした再利用可能な単位です。手順（何をどの順で行わせるか）や判断基準・出力形式等が一つのまとまりになっている点が重要です。ばらばらに共有されていると受け取った側が組み立て直す作業から始めることになります。
プロンプトだけを共有する場合との違いは二点です。第一に、設定と補助ファイルを含むためインストールすればまず動き、動いたうえで自分の業務に合わせて手を入れられます。第二に、リポジトリ上で管理されるため改変の履歴が残り、ある部署の改変が別の部署にとっての改善になります。共有された時点で止まるのではなく、使われながら育つ形です。例えば以下のようなSKILLが考えられます。

口頭やドキュメントで共有された「使い方」は、再現に手間がかかります。SKILLとして言語化されていれば、他の社員が自分の環境にインストールしてすぐ試せます。つまりSKILLは、属人的な工夫をそのまま組織の資産に変換できる単位です。もっとも、他者のSKILLがそのまま自分の業務に当てはまるとは限りません。作者の業務コンテキストは他者と同一ではなく、再利用性を高めるほど本来効率化したかった文脈が薄まる、というトレードオフもあります。そのまま動くことよりも「こういう使い方ができる」というユースケースを受け取れること。ここが、流通を成り立たせるための前提になります。

3．SKILLの共有とは？

SKILLの共有は、運営が模範解答を配るのではなく、現場が現場に向けて供給する社員投稿型（UGC）のリポジトリです。流通は次のサイクルで回ります。

STEP 1 投稿する

社員が「業務で使えること」を基準にSKILLを投稿

STEP 2 審査を通す

ライセンス確認・セキュリティ制御・レビューを実施

STEP 3 公開される

承認後に公開され、全社から参照できる状態になる

STEP 4 再利用される

他の社員が自分の環境で利用し、得た知見が次の投稿として戻る

ここで工夫したのが責任分界の設計です。審査の観点は「含めてはいけないものが入っていないか」に限定し、SKILL自体の動作品質は問いません（検証は利用者責任）。品質保証まで運営が背負う設計にすると、審査が滞留して流通そのものが止まってしまうと考えたためです。
「良いものだけを載せる」のではなく、「載せてはいけないものを載せない」に絞る。この線引きが、投稿数と安全性を両立させる分岐点になっていると感じています。

4．自由投稿型の基盤をどう成立させるのか？

自由投稿型には、品質・ライセンス・セキュリティのリスクが必然的に伴います。これらは運用ルールの周知では防ぎきれません。「気をつける」で守れる範囲には限りがあるためです。当社は、情報漏洩と法務・知財の二つに対して投稿者が迂回できない制御を置き、そのうえで、制御を通っていないものがそのまま配布されないためのガードを重ねています。

実装している制御

CIによる外部送信制限

投稿物そのものが守るべき情報資産であるため、CIジョブが漏洩の踏み台にならないような制御を行っています。投稿者がCIパイプラインの定義を書き換えられない権限構造とし、漏洩経路そのものを閉じる方式を選びました。あわせて、投稿者の自己チェックとレビューでも確認しています。

レビューを通らないものが配布されない仕組み

レビューを通っていないSKILLが、そのまま全社に配布されることのないようにしています。
上記の制御をくぐっていないものを流通させないためのガードです。

ライセンス・知財は人の目でレビュー

OSSを組み込む場合は当該のライセンスに違反していないか、他者の知財を不適切に組み込んでいないかを、投稿時のセルフチェック宣誓と人の目によるレビューで確認しています。宣誓だけでは抜けが出るため、二段構えにしています。

運用開始後の実績（本コラム公開時点）

SKILLを参照・利用できる範囲

全社員（うち投稿に向けたユーザ登録 91名）

公開前に検知・排除したNG案件

2件

数字はまだ小さいものですが、速さと統制を両立させるうえでは、事後のチェック体制よりも、投稿時点で迂回できない構造を持てているかどうかが重要だと感じています。NG案件を2件検知できたことは、ゲートが実際に機能していることの確認にもなりました。なお、完成度より「業務で使えること」を投稿基準とし、動作品質の検証は利用者責任とする線引きは、投稿者にも利用者にも明示しています。

5．流通を定着させるために何が必要か？

仕組みを用意しても、投稿と再利用が自然に起きるわけではありません。定着を左右するのは、認知と心理的ハードルです。
例えば以下のような施策が効果的です。

相談できる場を用意する

問いを立ち消えにさせないことが、再利用の起点になります。

• 個別の問い合わせ窓口ではなく、オープンなコミュニティへ集約する
• 同じ疑問を持つ他の社員にも回答が共有される
• 結果として、運営側の対応負荷も同時に下がる

投稿のハードルを下げる

優れたSKILLばかりが並ぶと、かえって出しにくくなります。

• 完成度ではなく「業務で使えること」を投稿基準として明示する
• 率先して投稿する協力者を確保する
• 少人数の発表機会を継続的に設ける

当社では、投稿されたSKILLについて、実際に使った感想を投稿する取り組みも行っています。
投稿者へのリスペクトと「同じ立場の人が投稿している」事実を共有することができています。

どんなSKILLがあるかを把握しやすくすることも重要です、当社ではコンテンツの充実と可視化を継続的に進めています。もう一つは、再利用性と業務文脈のトレードオフです。他者のSKILLをそのまま使えるようにすること自体を、必ずしも目的にはしていません。目指しているのは、流通基盤でユースケースを獲得し、そこから各人が自分の業務文脈に合うSKILLを構成していける状態です。

6．システム開発生産性向上に向けた取り組み

また当社は2025年10月に、2029年度までにシステム開発の生産性を50%向上させる全社目標^（※）を掲げています。SKILLの共有についての取り組みも、この目標達成に向けた取り組みの一つとなりますのでご紹介します。本取り組みが開発生産性向上に貢献するため、二段階に分けて設計しています。

※詳細については発行済のプレスリリースをご参照ください。
https://www.tisi.jp/news/2025/tis_news/20251031_1.html

STEP 1 コーディングエージェントの全社展開

ライセンスと環境の整備だけでは「使い続ける」状態に至りません。業務文脈に合うユースケースを届ける経路として、定着を支えます。

STEP 2 内製AIエージェントの全社展開

現場がノウハウをSKILLとして言語化・形式化する習慣が根付くことが、次段階への足がかりになります。

肝心なのは、STEP 1の「定着」です。ツールを配る施策ではなく、現場で生まれた業務で使えるユースケースを組織内で循環させる施策として設計しています。同時に、ノウハウをSKILLとして言語化する習慣づけを通じて、STEP 2にも間接的に貢献します。

7．まとめ ― ノウハウ基盤の成熟度が、AI活用の実装力を左右する

課題はツールよりも「経路」

成果を生み出したノウハウが個人に閉じたままでは、担当者の異動とともに失われてしまいます。

自由投稿型は「構造」で支える

外部送信制限に加え、ライセンス・知財は人の目でレビューし、動作品質は利用者責任という線引きを明示。

定着を左右するのは、認知と心理的ハードル

相談できる場と、完成度を求めすぎない投稿基準が、流通量を左右します。

目指すのは、自ら構成できる力

他者のSKILLをそのまま使えるかどうかではなく、ユースケースを起点に自分の業務文脈でSKILLを組み立てられる状態を目標にしています。

生成AIを個人が使えることと、活用ノウハウを組織として蓄積・再利用できることは、別の能力です。後者は、仕組みとして運用できているかどうかに表れるのだと思います。これは、基盤の設計・ガバナンス・定着施策の面など、同じ課題に向き合う企業の皆さまとも共有できるものではないかと思っています。