AIスキルの社内展開が進まない｜配布ではなくforkさせる設計へ

AIスキルを社内に配ったのに使われていない、という話をよく見かけます。この状態を抜けるための一番の近道は、配布をやめてfork（フォーク。元をコピーして自分用に書き換えること）させる設計に切り替えることだと思っています。スキルの実体はMarkdown（見出しや箇条書きを記号で表す、ふつうのテキスト形式）で書かれた文書なので、社員が取れる行動は「インストールする」ではなく「複製して書き換える」です。動詞を入れ替えると、Not Invented Here症候群の回避は説得の問題ではなく設計の問題に変わります。

日本の状況は「まだ配れていない」段階ではありません。IPAのDX動向2025では、生成AIを個人で業務利用している割合が日本62.1%とアメリカの47.6%を上回っているのに、部署の業務プロセスに組み込まれている割合は日本13.1%でアメリカ37.8%の約3分の1でした。個人は使えていて、その使い方が隣の席に渡っていません。

なぜ渡らないのか。ハーバード・ビジネス・スクールのIKEA効果の研究が、その心理を数字で示しています。自分で折った折り紙に0.23ドルの値をつけた人たちは、第三者が専門家の折り紙につけた0.27ドルとほぼ同額の価値を、自分のくしゃくしゃの紙に感じていました。そして重要なのは境界条件のほうです。あと2ステップで完成というところで止められた人の評価額は、完成させた人の4割程度にしかなりませんでした。労力は、成功裏に完了したときだけ価値を生みます。

ここから導かれる設計指針は「カスタマイズさせる」ではなく「カスタマイズを完了させる」です。しかも本人に希望を聞いてはいけません。同じ研究で、事前に選ばせると92%が組み立て済みを選んでいます。IKEA効果は事後的なもので、事前的なものではないからです。

この記事では、書き換えないと使えない構造の作り方、forkの単位を小さく保つ理由、失敗したforkが手をつけなかった場合より悪い結果になる根拠、日本企業3社が独立に到達した共有層と個人層の分け方、そして利用回数ではなく動機で定着を測る指標までを、一次資料の数値つきで整理します。

個人は使っているのに、チームには渡っていない

AIが社内で使われないという話は、たいてい「まだ十分に配れていない」問題として語られます。ところが統計を見ると、詰まっている場所はもっと先にあります。日本の会社員は、個人としてはアメリカ人より生成AIを使っています。それがチームの仕事の流れに入るところで止まっているのです。

個人利用は日本のほうが高い、それでもプロセスには入らない

IPAが公開しているDX動向2025に、日本・アメリカ・ドイツを同じ設問で比べた図があります。生成AIを「個人で業務利用している」と答えた割合は、日本が62.1%、アメリカが47.6%、ドイツが51.1%。日本が一番高いんですね。

ところが同じ調査の同じ図で、「部署の業務プロセスに組み込まれている」を見ると、日本は13.1%しかありません。アメリカは37.8%、ドイツは37.9%ですから、およそ3分の1です。

この2つの数字が同じ調査の中に並んでいるのが大事なところです。回答者が違うわけでも、設問の文脈が違うわけでもありません。同じ人たちが、個人としては使っていると答え、部署の仕事には入っていないと答えているわけです。誰かが見つけた良い使い方が、隣の席に渡っていないということになります。

他の統計も同じ方向を指しています。総務省の令和7年版 情報通信白書では、生成AIの業務利用率が日本55.2%、アメリカ90.6%、ドイツ90.3%、中国95.8%でした。

PwC Japanグループの生成AIに関する実態調査2026春（2026年2月調査、日本の回答者932名）は、さらに踏み込んだ数字を出しています。活用の推進度そのものは日本87%で6か国と遜色ないのに、「期待を大きく上回る効果」が出たと答えた企業は9%で最下位でした。アメリカは38%です。配ってはいますし、動いてもいます。それでも効いていません。

これは日本だけの話でもありません。Gallupが2025年10月から11月にかけて22,368人の被雇用者に聞いた調査では、アメリカでも49%が職場でAIを「まったく使わない」と答えています。個人的に面白かったのはその次の設問で、自分の会社がAIを導入したかどうかについて、38%が「導入済み」、41%が「導入していない」、21%が「わからない」と回答していました。導入したつもりの側と、現場の体感が噛み合っていないわけです。配った記憶はあるのに、配られた記憶がありません。心当たりのある方もいるのではないでしょうか。

「研修が足りない」では説明できないこと

「AIツールが社内で使われない」で検索すると、原因として挙がるものはだいたい3つに収まります。研修が足りない、経営のコミットが弱い、業務に組み込まれていない、の3つです。どれも間違いではないと思いますし、実際に効く場面もあります。

ただ、この説明の仕方には困るところがあります。研修をやったのに使われないケースを、説明できないんですね。使い方を教える機会をきちんと設けて、参加率も悪くなくて、それでも翌月には誰も開いていない、という状況です。これを「研修が足りない」で扱うことはできません。

「業務に組み込まれていない」のほうも、よく読むと原因ではなく結果の言い換えに近いです。さきほどのIPAの13.1%は、「組み込まれていない」ことそのものを測った数字でした。なぜ組み込まれないのかを言わないかぎり、対策にはなりません。

私はここに、もう少し身も蓋もない理由が挟まっていると思っています。人は、他人が作ったものを使いたがらないのです。しかもそれは、怠慢とか、理解不足とか、そういう話ではありません。実験室で何度も測定されている、かなり頑固な性質です。

人は自分で完成させたものを、専門家の作品と同じ値段で見る

心理学に「IKEA効果」という名前のついた現象があります。よく「自分で作ったものには愛着が湧く」という一行で紹介されますが、原論文を読むと話はもう少し込み入っていて、その込み入ったところにこそ設計のヒントが埋まっています。

出典はハーバード・ビジネス・スクールのMichael Norton、Duke大学のDan Ariely、当時UCSDにいたDaniel MochonによるThe IKEA Effect: When Labor Leads to Love（HBS Working Paper 11-091）です。以下の数字はすべてこの論文から取りました。

最初の実験は単純です。52人の学生を2つのグループに分けて、片方にはIKEAの黒い収納ボックス「Kassett」を説明書つきで組み立ててもらい、もう片方には完成品を渡して眺めてもらいます。そのあと「いくらまでなら買うか」を、実際にお金が動く仕組みで答えてもらいました。組み立てた人の平均額は0.78ドル、渡された人は0.48ドル。好き嫌いを7段階で聞いた評価も、3.81対2.50で差がつきました。

もっとはっきり出たのが次の折り紙の実験です。106人に鶴かカエルを折ってもらい、自分の作品にいくら払うかを聞くと、平均0.23ドルでした。同じ折り紙を、誰が折ったかも知らない別の人に見せていくら払うか聞くと、0.05ドルです。第三者から見れば、それはくしゃくしゃになった紙にすぎません。

研究チームはさらに、折り紙が得意な研究助手にきれいな鶴とカエルを折らせて、また別の人たちに値をつけさせました。0.27ドルです。素人が自分で折ったものに自分でつけた0.23ドルとの間に、統計的な差はありませんでした（t<1, p>.45）。

自分が折ったへたな鶴を、他人が見た上手な鶴と同じくらいの値打ちだと思っているわけです。これがIKEA効果の大きさになります。

効果が出るのは「完成させたとき」だけ

ここからが本題で、この論文の一番おいしいところは境界条件のほうにあります。

3つ目の実験では、118人に10ピースから12ピースのレゴセットを使ってもらいました。条件は、完成品をそのまま受け取る、自分で組み立てる、組み立てたあと自分で分解する、の3通りです。そのうえで、自分のセットと相手のセットの両方に入札してもらいます。

自分の作品への入札額が相手の作品を有意に上回ったのは、組み立てた条件だけでした。組み立ててから壊した条件では、その差が消えています。レゴはもともと分解して組み直せるおもちゃですし、落札すればすぐ組み直せる状態だったにもかかわらず、それでも消えました。

4つ目の実験はもっと意地悪です。39人全員に同じIKEAの箱と説明書を渡すのですが、半分の人だけ最後の2ステップの手前で止めてもらいます。完成させた人の支払意思額は1.46ドル、止められた人は0.59ドルでした。止められた人も部品はすべて手元にあって、買って持ち帰れば残りはすぐ終わる状態です。それでも4割程度にしかなりませんでした。

労力それ自体が価値を生むのではありません。成功裏に完了したときにだけ価値が生まれます。

4つの実験を並べると、そのことがはっきりします。

実験	参加者	比べた条件	支払意思額の結果
1A（IKEA収納ボックス）	52人	自分で組み立てる／完成品を受け取る	0.78ドル 対 0.48ドル
1B（折り紙）	106人	自作品への自己評価／第三者の評価／専門家の作品への第三者評価	0.23ドル 対 0.05ドル 対 0.27ドル
2（レゴ）	118人	完成品を受け取る／組み立てる／組み立てて分解する	差がついたのは組み立て条件のみ。分解すると消失
3（IKEA収納ボックス）	39人	最後まで組み立てる／2ステップ手前で止める	1.46ドル 対 0.59ドル

この違いは実務にそのまま効いてきます。設計の目標が「カスタマイズさせよう」ではなく「カスタマイズを完了させよう」に変わるからです。途中で挫折するカスタマイズは、愛着を生まないどころか、手をつけなかった場合より悪い結果になりえます。

それでも本人は「完成品がほしい」と言う

もう一つ、実務に直結する結果があります。同じ研究チームが別の学生51人にこう質問しました。「組み立て済みの製品と、多少組み立てが必要な製品、どちらに多くお金を払いますか」。92%が組み立て済みと答えています。

自分で完成させたものは高く評価するのに、事前に選ばせると組み立てを避けます。著者たちはこれを、IKEA効果は事後的なものであって事前的なものではない、と表現しています。

ここから出てくる結論はけっこう厳しいものです。社員に「スキルを自分でカスタマイズしたいですか」とアンケートを取ってはいけない、ということになります。聞けば「完成品をください」と返ってきます。それは本音ですし、嘘でもありません。でもその通りに完成品を配ると、今度は使われません。希望を聞いて、その希望どおりにすると失敗する構造になっています。

聞くのをやめて、カスタマイズが自然に発生する経路のほうを設計するしかありません。

「うちは非エンジニアだから」は理由にならない

最後の実験では、参加者に「あなたはどのくらい自分でものを作るタイプですか」を7段階で自己申告してもらっています。回帰分析にかけたところ、完成させたかどうかとDIY志向の交互作用は見られませんでした（β=.09, p>.60）。

自分をものづくり好きだと思っていない人にも、完成させたときの評価の上がり方は同じでした。「うちの現場は非エンジニアだから自分で手を入れたりしない」という説明は、少なくともこの実験の範囲では支持されていません。

誤読しないよう、2つ補足しておきます

一つ目。実験に使われたIKEAの箱もレゴも、カスタマイズの余地がない標準品です。著者はこれを意図的に選んでいます。「自分の好みに合わせて仕立てられたから価値が上がった」という説明を排除するためでした。効いているのは自分好みにしたことではなく、自分で完成させたことのほうです。この区別は、あとで設計を考えるときに効いてきます。

二つ目。この論文の考察部で、著者たち自身がIKEA効果を組織の2つの落とし穴に接続しています。サンクコスト効果と、Not Invented Here症候群です。

the “not invented here” syndrome, in which managers refuse to use perfectly good ideas developed elsewhere in favor of their – sometimes inferior – internally-developed ideas

管理職が、よそで生まれた申し分のないアイデアを使うことを拒み、自分たちが内部で作った、ときには劣っているアイデアのほうを選んでしまう。それがNot Invented Here症候群だ、と説明しています。

そして論文はこう締めくくられます。IKEA効果はどんな介入にも抵抗するかもしれず、NIH症候群はこの先も残り続けることを示唆している、と。

私が持ち込んだ強引なアナロジーではなく、原論文が自分で書いている接続です。ただ公平を期すために書いておくと、この段落でNortonらはNIHに関する先行研究を一つも引用していませんし、実験でNIHそのものを検証したわけでもありません。考察部の示唆にとどまります。実証のほうは別の研究者たちが積み上げていて、そこには実務家にとって少し意外な発見が含まれています。

いちばん拒まれるのは、隣のチームが作ったスキル

Not Invented Here症候群、略してNIH症候群と呼ばれるものがあります。外から来た良いアイデアを退けて、自分たちが中で作ったものを選んでしまう傾向のことです。実証研究をたどっていくと、この傾向には強く出る条件と、ほとんど出ない条件があることがわかります。そして強く出るほうの条件が、社内展開の設計にとって都合の悪いものでした。

よく引かれる原典は、別のことを測っている

NIHの話をするとき、ほぼ必ず引かれる論文があります。Ralph KatzとThomas Allenが1982年に*R&D Management*誌に出した、50のR&Dプロジェクトグループを調べた研究です。ある企業の研究開発拠点で、専門職345名を対象に、チームの平均在籍年数とパフォーマンスの関係を調べたもので、在籍が長くなるほど成績が落ちていく逆U字のグラフが有名になりました。

ただ、この論文を根拠として引くのは少し危ういです。東京大学の高橋伸夫氏と稲水伸行氏が2012年に*Annals of Business Administrative Science*で発表したMysteries of NIH Syndromeという論文が、正面から方法論を批判しています。散布図そのものには傾向が見えないのに平滑化の手法で曲線を作り出している点、有名な図の切片が本文の数式から導けない点などが指摘されていて、そのうえで批判の核心はこうです。

Katz & Allenが言う「NIH症候群」は、現代的な意味での自前主義ではありません。彼らはこの語を「メンバーの在籍が長くなることによる成績低下」そのものを指すのに使っています。だから自前主義の文脈でこの論文を引くと、読んでいないことを自分で明かしてしまう、と高橋氏らは書いています。

原論文を読むと確かにそうで、6つ測ったコミュニケーション指標のうち在籍年数と有意な相関が出たのは2つだけでした。しかも「内輪で固まって内部の会話が増える」という当初の予想は外れていて、長期チームはメンバー同士でも話さなくなっていたと書かれています。

こういう論文の読み直しは、それ自体が面白いだけでなく実務的な意味もあります。40年前の一本に寄りかからなくても、NIHにはもっと新しくて条件のはっきりした実証があるからです。

抵抗が起きるのは「自分たちに似た相手」からの知識のとき

Katharina HussingerとAnnelies Wastynが2016年に*R&D Management*で発表した研究は、ドイツの製造業905社のデータを使って、外部知識に対する社内の抵抗がどこで起きるかを調べました。

結果は、抵抗が起きるかどうかは知識の中身ではなく、その知識がどこから来たかで決まる、というものでした。競合他社から取り込んだ知識には社内の抵抗が起きやすく、サプライヤー、顧客、大学から来た知識では起きにくくなっていました。著者たちは社会的アイデンティティ理論、つまり自分たちと似た相手ほど比較対象になりやすいという枠組みでこれを説明しています。

この結果を会社の中に翻訳すると、どうやらなかなか厳しい絵が出てきそうです。抵抗が強く出るのは、自分たちと立場や職種が近い相手からの知識ということになります。社内で言えば、隣の部署や似た業務をしている別チームがそれにあたります。

外部ベンダーが売っているAIツールより、隣の課が作ったプロンプト集のほうが拒まれやすくなります。感覚的にはあべこべに聞こえますが、ベンダーは競争相手ではないので受け入れても自分の立場が脅かされないのに対し、隣の課は評価軸を共有している相手だからです。「あそこができるなら、うちも当然できるはずだ」という視線が、そのまま「あれを使うのは、うちが劣っていると認めることだ」に裏返ります。

社内展開でよく取られる手が「他部署の成功事例を横展開する」ですが、この知見に照らすと、それは一番抵抗の強い経路を選んでいることになります。うまくいかないのは、事例の見せ方が下手だからではないのかもしれません。

説得ではなく、設計の問題にする

ではどうするか。ここでもう一本、Jan Hannenらが2019年に*Research Policy*で発表した研究が参考になります。世界565件のR&Dプロジェクトを定量調査し、あわせて32件のインタビューと3回のフォーカスグループを実施したものです。

この研究が面白いのは、現場で実際に取られている対策の大半が「直接的な」ものだった、と報告している点です。外部知識を使えと指示する、使わない理由を説明させる、といった直球の働きかけですね。そのうえで著者たちが有効性を確認したのは、perspective taking、つまり相手の視点に立たせるという間接的な手法のほうでした。

正面から「これを使え」と言うのではなく、拒みたくなる気持ちが発動しない状況を先に作っておきます。この方向転換が、この記事の残り半分のテーマになります。

情シスやDX推進の側から見ると、これは仕事の性質が変わるということでもあります。ツールを選定して配って研修するところまでを仕事の範囲だと考えていると、一番効く部分が守備範囲の外に落ちてしまいます。この論点はAI活用が進む会社と進まない会社の分岐点でも扱いましたが、あちらが導入の手前で止まる話だったのに対して、こちらは配ったあとに起きることの話です。

そして幸いなことに、AIスキルという対象は、この設計変更をやりやすい性質を持っています。

「配る」と「forkする」は別の動詞

ここまでの話を設計に落とすとき、最初にやることは言葉を変えることだと思っています。AIスキルを「導入して配布するもの」として扱っているかぎり、打てる手は研修と通達しかありません。でもスキルは、そもそも配布するタイプの物体ではないんですね。

Claude Skillsも、Copilot向けのカスタムエージェントも、GPTsの指示文も、実体はテキストです。Agent Skillsの公式仕様を見ると、スキルとはSKILL.mdという1枚のMarkdownファイルを含むディレクトリだと定義されています。

skill-name/
├── SKILL.md      # 必須。YAML形式のメタ情報 + Markdownの本文
├── scripts/      # 任意。実行できるコード
├── references/   # 任意。必要になったときだけ読み込む詳細資料
└── assets/       # 任意。テンプレートや画像

SKILL.mdの冒頭にはYAML（ヤムル。「項目名: 値」の形で設定を書く記法）形式のメタ情報を置きます。必須なのはname（64文字以内、小文字の英数字とハイフンのみ、親ディレクトリ名と一致させる）とdescription（1024文字以内）の2つだけです。あとは全部Markdownの散文で、「こういうときに、こういう手順でやってください」と日本語で書けます。

つまり社員に渡っているものは、ソフトウェアではなくテキストファイルです。テキストファイルに対して人間が取れる行動は、インストールではなく、複製して書き換えることです。ソフトウェア工学の言葉を借りれば、これがforkにあたります。この動詞に切り替えると、NIHの回避は「どう説得するか」ではなく「どう書き換えやすくするか」という設計の問題に変わります。

書き換えなければ使えない形にしておく

fork を促す一番強い方法は、書き換えないと使えない状態にしておくことです。

わかりやすい実例が、Anthropicが公開しているskillsリポジトリのbrand-guidelinesというスキルです。中を開くと、Anthropic自社のブランドカラーが直に書いてあります。ダークが#141413、アクセントのオレンジが#d97757、見出しのフォントはPoppins、本文はLora。

これは他社にとって、そのままでは使い物になりません。使いたければ自社の色とフォントに書き換えるしかありません。そして書き換えるという行為は、Markdownの十数行を自社の値に置換するだけで終わります。5分もかかりません。

私はこの構造がよくできていると思っています。パラメータを設定画面に隠したり、環境変数で外から差し込む形にしたりせず、本文にべた書きしてあります。おかげで「書き換える」以外の選択肢がなく、しかも書き換えは確実に完了します。前の節で見た境界条件を思い出すと、これは意味のある性質です。完了しないカスタマイズは価値を生みませんでした。

自社でスキルを整備するときも、同じ発想が使えます。チームごとに変わる値、たとえば対象の製品名、レビュー観点、確認すべき社内ルール、想定読者といったものを、本文の目立つ位置にまとめて置いておく。共通の手順部分と、チーム固有の値の部分を、視覚的に分けておくということです。

分量が増えてきたらreferences/に逃がします。公式仕様でも、この置き場の例としてfinance.mdやlegal.mdのようなドメインごとのファイルが挙げられていて、必要になったときだけ読み込まれる設計になっています。本体のSKILL.mdは500行以内に収めることが推奨されているので、共通部分を本体に、書き換える部分を参照ファイルに、と分けると構造としても素直です。この層の分け方については、メダリオンアーキテクチャとClaudeスキルで扱った考え方がそのまま応用できます。

最初のforkは、小さくしておく

もう一つの原則は、最初に書き換えてもらう単位を小さくすることです。

これは根拠のある話で、IKEA効果の論文自身が、労力を引き出した成功例としてLinuxの立ち上げに触れています。参加を呼びかけるとき、貢献を小さく扱いやすい単位に切り分けて、全体として必要になる労力の威圧感を前に出さなかった、という説明です。

オープンソースの世界には、この話を裏側から支える数字があります。Shurui Zhouらが2020年のICSEで発表したfork研究によると、GitHub上の4,700万件のforkのうち、star（お気に入り登録のようなもので、多少なりとも他人の目に触れた証拠になります）が3つ以上ついたものは0.2%でした。さらに、活動中の元リポジトリを持つforkのうち、元との同期やマージを一度でも行ったものは16.18%にとどまります。コピーはされたけれど、誰にも使われず、元に返りもしないまま放置されているということです。

forkを作るコストはボタン1つまで下がりました。書き換えて返すコストは、下がっていません。だから「forkできるようにしました」だけでは、ほぼ何も起きないと考えておいたほうがいいです。

失敗したforkは、forkさせなかったより悪い

ここが、この記事で一番強調したいところです。

Igor Steinmacherらが2018年のICSEで発表したquasi-contributorの研究があります。quasi-contributorというのは、プルリクエスト（自分が書き換えた内容を元のプロジェクトに取り込んでほしいと申請する手続き）を出したのに、受け入れられなかった人たちのことです。人気21プロジェクトを調べたところ、この「あと一歩だった人」は10,099名いて、実際の貢献者のおよそ70%にあたる規模でした。

そのうち84.68%は、一度きりで終わっています。追加のアンケートでは、およそ30%が「意欲を削がれて次のプルリクエストを出さなくなった」と答えました。

この結果は、前の節で見たIKEA効果の実験4とほとんど同じことを言っています。あと2ステップで完成する状態で止められた人の評価額は、完成させた人の4割程度でした。分野もデータの取り方もまったく違う2つの研究が、労力は完了しないと価値を生まないどころか、マイナスに振れることを示しています。

社内展開に置き換えると、次のような場面が該当します。スキルを配って「自由にカスタマイズしてください」と伝えたところ、実際に手を出した人が書き換え方がわからずに詰まってしまう。あるいは書き換えたものを共有しようとして、レビューで差し戻される。そういう場面です。この人は、最初から完成品を渡された人より確実にAIから遠ざかります。しかもその人は、たいてい社内で一番前向きだった人です。過去に社内ツールを推進したとき、最初に手を挙げてくれた人が途中から静かになった経験はないでしょうか。

なので、カスタマイズを促すセットには最低限これだけは要る、というものがあります。書き換える箇所が指定されていること。書き換えの単位が小さいこと。書き換えた結果が動いたかどうかを本人が確認できること。そして戻すのが簡単であること。この4つのうちどれかが欠けると、完了しないカスタマイズが発生します。

ドキュメントについて、都合の悪い話も書いておきます

「使い方のドキュメントを整えれば貢献が増える」という説を、私は当然のものとして書こうとしていました。調べてみると、それを支持する強い実証が見つかりませんでした。

まず整備率のほうから。Felipe Fronchettiらが2023年のESEC/FSEで発表した研究によると、GitHubの上位9,514リポジトリのうちCONTRIBUTINGファイルを持っていたのは36.4%です。さらに、新規参加者が実際にぶつかる6種類の障壁をすべてカバーしていたのは、分析対象2,274件のうち65件、率にして6%でした。特に欠けやすいのが「どのタスクから手をつけるか」と「コミュニティとどう対話するか」で、どちらも75%以上のプロジェクトで書かれていません。

問題は因果の向きです。Karan Aggarwalらが2014年のMSRで発表した分析では、「人気が出る、その結果ドキュメントが更新される」という向きは支持されたのに、逆向きはうまく支持されませんでした。2025年のCHASEで発表された別の研究も、CONTRIBUTINGは貢献が流れ込んできた後で追加される事後的な文書だと報告しています。

というわけで、ドキュメントを整えれば人が来るという話ではなさそうです。ただ、書かない理由にはなりません。位置づけを変えればいいだけで、ドキュメントは集客の道具ではなく、すでに手を出してくれた人を取りこぼさないための道具です。そして取りこぼしがそのまま離脱につながることは、さきほどのquasi-contributorの数字が示していました。

なおスキル1本をどう書き起こすかについては、Claudeでフィードバックスキルを作るで10ペアの実例から組み立てる手順を書いています。個人が最初の1本を作るところは、そちらのほうが具体的です。

共有する層と個人の層を分け、動機で測る

ここからは実装の話です。日本の会社がすでに公開している実例が3つあって、面白いことに、書いた人たちはおそらくお互いの記事を読んでいないのに、同じ構造にたどり着いています。共有する層と個人の層を分けること、改善を集める場所を1つに決めて配布を自動化すること、そして完成品を配らず使われながら改善する前提で設計することの3点です。最後に、その状態になれたかどうかを利用回数以外の指標で測る方法まで見ていきます。

日本企業3社が独立に到達した同じ形

マネーフォワードは2026年3月に、社内スキル共有基盤をつくった話を公開しています。エンジニアが1,000人近い組織で、ai-agent-toolsという名前のGitHubリポジトリをClaude CodeやCursorのマーケットプレイスとして提供する、という作りです。

この記事で私が一番大事だと思ったのは、置き場所のルールが明示されている点でした。個人専用のものや特定のリポジトリに閉じたものは、共有基盤には置かずローカルや各リポジトリに置く、と切り分けてあります。何でも共有基盤に集めると、他人のものだらけになって誰のものでもなくなります。個人の層を残すことが、共有の層を機能させる条件になっているわけですね。

登録されたプラグインは2月初旬の11個から、記事を書いた時点で28個に増えています。中身はデザインシステムのコンポーネント対応表、GoとKotlinのバックエンド標準、API設計、DBスキーマ設計、インフラや社内ツールの運用など、いずれも「その会社でしか意味を持たない知識」です。そして著者はこう書いています。重要なのは、誰か一人が完成形を作ることではなく、各自が必要なスキルを持ち寄り、使われる中で改善していくことだ、と。別のチームの知見を「そのまま、あるいは少し調整しながら」使えるようになる、という言い方もされていて、調整の余地が前提に組み込まれています。

CARTA HOLDINGSは2026年5月に、Claude Codeのスキルをチームで共有して、全員で育てる仕組みを公開しました。共通スキル置き場としての社内リポジトリ、Microsoftが開発しているapmというAIエージェント向けのパッケージマネージャ、そしてGitHub Actionsによる自動更新の3点セットです。

自動更新の部分が実務的で、毎朝9時にパッケージの取得を走らせて、共通置き場に更新があれば各リポジトリに自動でプルリクエストが立ちます。誰も手を動かさなくても最新版が回ってきます。この記事も「誰か一人が育てるのではなく、全員が日々の気づきを置き場に還流させる運用にすること」がポイントだと書いていますし、始め方についても、まずリポジトリを1つ用意して小さなスキルをひとつ置くところから、と勧めています。前の節で見た「最初のforkは小さく」がここでも出てきます。

3つ目は、Zennに公開されているClaude CodeのSkillsやHooksを社内で共有する方法です。プロジェクトごとの共有、組織共通リポジトリ、その中間のハイブリッド構成という3通りを比べたうえで、ハイブリッドを推奨しています。設定の読み込みには優先順位があって、より具体的なスコープが優先されるので、組織共通の設定をグローバルに、プロジェクト固有の設定をローカルに置くと自然に上書きが効きます。

3社に共通しているのは、次の3点です。共有する層と個人の層を明確に分けていること。改善を集約する場所を1つに決めて、そこから配る経路を自動化していること。そして、完成品を配るのではなく、使われながら改善される前提で設計していること。

Microsoftの公式ガイドは「例を自分たちのものに置き換えろ」と書いている

同じ発想は、ベンダー側の公式ドキュメントにも出てきます。

Microsoftが公開しているCopilot Champion Playbookは、社内の推進役に何をさせるかを具体的に指定しているのですが、技術訓練ではなく業務ゴールから始めるよう設計されています。手順は、チームがすでに気にしている目標を特定する、影響の大きいユースケースを3つから5つ選ぶ、実際に仕事をしている場所にCopilotを持ち込む、成功指標を決めて測る、の4段階です。

その中に、こういう指示があります。例をローカライズせよ。「RFP向けの営業エージェント」という汎用の例を、「うちの更新サイクル向けの営業エージェント」に差し替えろ、と。あわせて、自分のチームのプロセスに特化したプロンプトを5個から10個集めたスターターパックを作れとも書かれています。

これはforkの指示そのものです。公式が用意した完成品をそのまま使わせるのではなく、推進役の手で自分たちの業務語彙に置き換えさせています。しかも置き換える対象は、プロンプト5個から10個という完了可能な単位に区切られています。

推進役の選び方についても、公式は具体的です。手を挙げてもらう方式より、活動を観測して個別に非公開で声をかける方式のほうが一般的だとしていて、社内のExcelやSharePointの相談役になっている人をそのまま転用せよ、とも書かれています。

人数の目安について公式な基準はありません。ただしMicrosoft自身は、33万人を超える従業員と契約社員にCopilotを展開したうえで、1万人近い推進役を抱えていると書いています。そのうえで、推進役はプロの講師ではないので素材とコーチングをセットで渡す必要がある、と総括されていました。

もう一つ引いておきたいのが、Microsoftが2026年に整備したエージェント向けCenter of Excellenceのガイダンスです。Center of Excellence、略してCoEというのは、社内の取り組みをまとめて推進する中核チームのことだと考えてください。

ここには推進組織の失敗パターンが3つ、名指しで挙げられています。すべてをレビューして何も実現させず、結果として現場に迂回されて管理外のエージェントを生んでしまう「門番」型。華々しく発足したものの、運営リズムも決定権限もなく紙の上だけの存在になる「幽霊」型。そしてガバナンスが完成するまで誰にも出荷させない「完璧主義者」型の3つです。

役割の定義もうまい言い方をしています。CoEが所有すべきなのは、どのエージェントが作られるかではなく、どう普及するかのほうだ、と書かれています。安全な道を、いちばん楽な道にするのが良いCoEだ、とも述べられていました。

「どれだけ使われたか」ではなく「なぜ使ったか」を測る

最後に測り方です。ここを間違えると、これまでの設計が全部台無しになります。

利用率やアクティブユーザー数だけを追うのは、この文脈では特に危険です。DORA（DevOps Research and Assessment。開発組織の生産性を10年以上にわたって調査してきた研究チームで、現在はGoogle傘下にあります）は2026年6月に、AIのトークン消費量をリーダーボードにする風潮を虚栄の指標だと名指しで批判しました。指標が目標になった瞬間に良い指標ではなくなるというGoodhartの法則の典型で、全社集計には意味がなく個人スコアは有害だ、とまで書いています。

副作用として報告されているのが、自分に効くプロンプトや使い方を同僚に共有しなくなるという囲い込みです。共有基盤を作ろうとしている側からすると本末転倒で、測り方ひとつで設計の意図が裏返ってしまいます。

では何を測るか。私が一番しっくりきたのは、CNCF（Kubernetesなどを運営する、クラウド技術の標準づくりを担う非営利団体）が公開しているプラットフォームエンジニアリング成熟度モデルの「採用」の軸でした。社内基盤がどれだけ根づいたかを段階で表すもので、どれだけ使われているかだけでなく、なぜ使うのかを段階にしているところが、この記事の主題とそのまま重なります。

4つの段階は次のように定義されています。

段階	定義されている状態	社内スキルに置き換えると
1. 散発的	採用がばらばらで、社外のツールのほうが優れているという発想が支配的	各自が勝手に外部のプロンプト集を拾って使っている
2. 外からの押し込み	社内の指令やインセンティブで使わせている。指示されないと存在にすら気づかない	通達を出したので一応は使われている
3. 内側からの引き寄せ	認知の負荷が下がるという明確な価値があるから自分で選んでいる	自分で作る選択肢も外部から買う選択肢も持ったうえで、社内のスキルを選んでいる
4. 参加	使う側がエコシステムに参加し、改善や新機能を持ち込んで貢献し返している	現場が書き換えたスキルが共有置き場に戻ってくる

第3段階の定義文が秀逸です。自分たちで作るという選択肢も、外部から調達するという選択肢も持ったうえで、社内の実装を選んでいるか、と書かれています。これはNIHを回避できたかどうかの操作的な定義そのものです。使わせたかどうかではなく、他の選択肢がある状態で選ばれたかどうかを見ています。

第4段階が、この記事で言うforkの還流にあたります。

補助線として2つ足しておきます。1つはDORAのAI Capabilities Modelです。ここではAIの採用度を利用回数ではなく、依存度と信頼と反射的な使用という3つの変数の合成として定義しています。何回使ったかではなく、迷ったときに手が伸びるかどうかを測る発想ですね。

もう1つは参加率の現実的な目標です。Jakob Nielsenが提唱した90対9対1の法則は、9割が見るだけ、9%が時々貢献、1%がほとんどの貢献を生むという分布を指します。Nielsen自身が「解消はできない、変えられるのは曲線の角度だけ」と書いていて、現実的な改善目標として挙げているのが80対16対4です。全員に貢献させようとしないほうがいいですし、逆に貢献者の比率が1%から4%に動いたなら、それは十分な成果になります。

指標を1つに絞らないことも大事です。開発の生産性を満足度・成果・活動量・協働・効率の5側面から捉えるSPACEフレームワークの原論文は、最低3つの次元から測ること、そのうち1つはアンケートのような主観指標を含めることを推奨しています。

活動量の指標だけを単独で使って評価や報酬に結びつけてはいけない、とも明記されています。トークン数を数える前に読んでおくと安全です。運用コストの側から見た測り方については、Return on Tokenで見直すClaude運用で別の角度から書いています。

月曜日から試せる形にすると

長くなったので、実際に手をつける順番だけまとめておきます。

1. 共有置き場にするリポジトリを1つ決めて、小さなスキルを1本だけ置きます
2. そのスキルに、チームごとに書き換える箇所を目立つ位置で作り、書き換えの単位は5分で終わる大きさに切ります
3. 書き換えた結果が動いたかどうかを本人がその場で確認できるようにして、元に戻す手順もあわせて書いておきます
4. 推進役は手を挙げさせるのではなく、すでに詳しい人に個別へ声をかけます
5. 測るのは利用回数ではなく、自分で作る選択肢を持ちながら社内のものを選んだ人がどれだけいるか、にします

うまくいっている会社の記事を読むと、どこも「これが正解というわけでもないし、一つのお試しである」といった断りから始まっています。完成させてから配る前提を捨てるところが、たぶん出発点なのだと思います。判断の基準そのものをスキルに落とし込む具体例としては、AI Skillsでコピーライターの判断ルールを抽出した事例も参考になるはずです。

私たちDeskrexが開発しているSnorbeは、ナレッジグラフ型のリサーチAIエージェントで、この記事の設計を調査という業務で実現しようとしたものです。自然な日本語で問いを投げるだけで、JPO・EPO・Google Patents・arXiv・PubMed・Semantic Scholarといった専門データベース群を横断して調べにいきますが、効いてくるのはその後です。調査の観点と経路が完全記憶型のナレッジグラフとして残るので、次の人はそれを自分の問いに合わせて書き換えて走らせられます。レポートを配るのではなく、調べ方のほうをforkできる形で持てるということですね。社内のリサーチを任せる先を探しているなら、新しい選択肢として試してみてください。

よくある質問

Q1. AIスキルが社内で使われないのは、研修不足が原因ですか

研修は必要ですが、それだけでは説明がつきません。研修を実施して参加率も悪くないのに翌月には誰も開いていない、という現象が起きるからです。IPAのDX動向2025では、日本の個人での業務利用は62.1%とアメリカの47.6%を上回っており、使い方を知らないわけではないことがわかります。詰まっているのは、個人が見つけた使い方がチームのプロセスに入る手前です。他人が作ったものを使いたがらない心理が働いている可能性を、先に検討したほうがいいと思います。

Q2. Not Invented Here症候群とは何ですか

外部から来た良いアイデアを退けて、自分たちが内部で作ったものを選んでしまう傾向のことです。実証研究をたどると、無条件に起きるわけではないことがわかります。ドイツの製造業905社を調べたHussinger & Wastyn（2016年、R&D Management）は、抵抗が起きやすいのは競合他社のような自分たちと似た組織から来た知識のときで、サプライヤーや顧客、大学から来た知識では起きにくいと報告しています。社内に置き換えると、外部ベンダーのツールより隣の部署が作ったスキルのほうが拒まれやすいということになります。

Q3. IKEA効果をAIツールの話に当てはめるのは強引ではありませんか

その接続は、IKEA効果の原論文自身が行っています。Norton、Mochon、Arielyによる論文の考察部で、IKEA効果が組織にもたらす落とし穴としてサンクコスト効果とNot Invented Here症候群の2つが挙げられ、論文はNIH症候群はこの先も残り続けるだろうという一文で締めくくられています。ただし公平に書いておくと、その段落で著者たちはNIHの先行研究を引用しておらず、実験でNIHそのものを検証したわけでもありません。考察部の示唆にとどまります。

Q4. 社員に「スキルをカスタマイズしたいか」とアンケートを取ればいいのでは

聞くと失敗します。同じ研究チームが51人に「組み立て済みの製品と、多少組み立てが必要な製品、どちらに多く払うか」と質問したところ、92%が組み立て済みと答えました。自分で完成させたものは高く評価するのに、事前に選ばせると組み立てを避けます。著者たちはこれを、IKEA効果は事後的なものであって事前的なものではない、と表現しています。希望を聞いてその通りに完成品を配ると、今度は使われないという構造です。カスタマイズが自然に発生する経路のほうを設計してください。

Q5. 非エンジニアの部署でも、スキルを書き換えてもらえるものでしょうか

実験の範囲では、ものづくり志向の有無は結果に影響していませんでした。IKEA効果の4つ目の実験では参加者に自分がどのくらいDIY型かを7段階で自己申告してもらっていますが、完成させたかどうかとDIY志向の交互作用は見られていません（β=.09, p>.60）。自分をものづくり好きだと思っていない人にも、完成させたときの評価の上がり方は同じでした。実務面でも、SKILL.mdの中身は日本語の散文なので、書き換える作業自体はテキストの置換です。

Q6. AIスキルの定着はどの指標で測ればいいですか

利用回数やアクティブユーザー数だけを追うのは避けてください。開発組織の生産性を長年調査してきた研究チームのDORAは2026年6月に、AIのトークン消費量をリーダーボードにする動きを虚栄の指標だと批判し、全社集計には意味がなく個人スコアは有害だと書いています。副作用として、効くプロンプトを同僚に共有しなくなる囲い込みが報告されています。代わりに使えるのが、クラウド技術の非営利団体CNCFが公開しているプラットフォームエンジニアリング成熟度モデルの採用軸で、社内の指令で使っている段階と、自分で作るという選択肢を持ちながら社内の実装を選んでいる段階、さらに使う側が改善を持ち込んでいる段階を区別します。この3段階目の定義が、NIHを回避できたかどうかの操作的な定義になります。

この記事で参照した一次情報

本文の数値・定義・引用は、次の資料を実際に開いて確認したうえで書いています。2026年7月時点の内容です。

• Norton, Mochon & Ariely「The IKEA Effect: When Labor Leads to Love」HBS Working Paper 11-091（4つの実験の設計と効果量、NIHへの接続）: https://www.hbs.edu/ris/Publication%20Files/11-091.pdf
• IPA「DX動向2025」（個人利用62.1%と部署プロセス組込13.1%の対比、図表2-11）: https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf
• 総務省「令和7年版 情報通信白書」（生成AIの業務利用率の4か国比較）: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html
• PwC Japanグループ「生成AIに関する実態調査2026春 6カ国比較」（推進度87%に対し期待超えの効果9%）: https://www.pwc.com/jp/ja/knowledge/thoughtleadership/generative-ai-survey2026.html
• Gallup「Frequent AI Use at Work Continues to Rise」2025年Q4, N=22,368（職場でAIを使わない49%）: https://www.gallup.com/workplace/701195/frequent-workplace-continued-rise.aspx
• Katz, R. & Allen, T. J. (1982)「Investigating the Not Invented Here (NIH) syndrome」R&D Management 12(1): https://doi.org/10.1111/j.1467-9310.1982.tb00478.x
• Takahashi, N. & Inamizu, N. (2012)「Mysteries of NIH Syndrome」Annals of Business Administrative Science 11（原典への方法論批判）: https://www.jstage.jst.go.jp/browse/abas
• Hussinger, K. & Wastyn, A. (2016)「In search for the not-invented-here syndrome」R&D Management 46(S3)（ドイツ製造業905社、競合由来の知識のみ抵抗）: https://doi.org/10.1111/radm.12136
• Hannen, J. et al. (2019)「Containing the Not-Invented-Here Syndrome」Research Policy 48(9)（565プロジェクト、perspective taking）: https://doi.org/10.1016/j.respol.2019.103822
• Zhou, Vasilescu & Kästner (2020)「How Has Forking Changed in the Last 20 Years?」ICSE ’20（fork の 0.2%、同期16.18%）: https://doi.org/10.1145/3377811.3380412
• Steinmacher, I. et al. (2018)「Almost There: A Study on Quasi-Contributors」ICSE ’18（10,099名、84.68%が一度きり）: https://doi.org/10.1145/3180155.3180208
• Fronchetti, F. et al. (2023)「Do CONTRIBUTING Files Provide Information about OSS Newcomers’ Onboarding Barriers?」ESEC/FSE ’23: https://doi.org/10.1145/3611643.3616288
• Agent Skills 公式仕様（SKILL.md の構造、frontmatter、progressive disclosure）: https://agentskills.io/specification
• anthropics/skills リポジトリ（brand-guidelines のハードコード例、template/SKILL.md）: https://github.com/anthropics/skills
• マネーフォワード「そのAI活用、チームで再現できますか？」（ai-agent-tools、プラグイン11個から28個へ）: https://moneyforward-dev.jp/entry/2026/03/13/how-we-built-an-internal-skill-sharing-platform
• CARTA HOLDINGS「Claude Code のスキルをチームで共有して、全員で育てる仕組みを作った」（skilltree + apm + skill-updater）: https://techblog.cartaholdings.co.jp/entry/team-skilltree-apm
• Zenn / Katsuhisa Kitano「Claude Code の Skills や Hooks を社内で共有する方法」（設定の優先順位、ハイブリッド構成）: https://zenn.dev/katsuhisa_/articles/claude-code-internal-marketplace
• Microsoft「Copilot Champion Playbook / Adopt」（例のローカライズ、スターターパック）: https://adoption.microsoft.com/en-us/copilot/essential-guide/adopt
• Microsoft Learn「Center of Excellence」（門番・幽霊・完璧主義者の3つの失敗パターン）: https://learn.microsoft.com/en-us/agents/center-of-excellence
• CNCF TAG App Delivery「Platform Engineering Maturity Model」（採用の4段階）: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
• DORA「Finding Balance in the Era of Tokenmaxxing」（虚栄の指標、囲い込みの副作用）: https://dora.dev/insights/finding-balance-in-the-era-of-tokenmaxxing
• DORA「AI Capabilities Model」（依存度・信頼・反射的な使用の合成因子）: https://dora.dev/ai/capabilities-model/questions/
• Forsgren, N. et al.「The SPACE of Developer Productivity」ACM Queue 19(1): https://queue.acm.org/detail.cfm?id=3454124
• Nielsen, J.「The 90-9-1 Rule for Participation Inequality」NN/g（80対16対4の目標）: https://www.nngroup.com/articles/participation-inequality/