「導入して数ヶ月経つと、Claude Codeを使う人がだんだん減っていく」という相談を受けることがある。ライセンスは配った、キックオフの説明会もやった、それでも数ヶ月後には一部の人しか使っていない——珍しい話ではない。
MITのNANDA研究チームが2025年に発表した調査「The GenAI Divide: State of AI in Business 2025」は、企業の生成AI導入全般を対象に、経営層150人へのインタビュー・従業員350人の調査・公開された導入事例300件の分析から、投じられた300億〜400億ドルの投資に対して95%の企業が測定可能な事業成果を得られていないと報告している。この調査が原因として挙げているのは、モデルの性能ではない。パイロットが「本番運用に移行する」という明確な合意なしに始まり、導入後の意思決定を誰が担うかが決まらないまま優先順位が別の案件に移り、静かに使われなくなっていく——という構造だ。
このパターンは、Claude Codeの企業導入にもそのまま当てはまる。
公式ベストプラクティスは「担当者がいる」ことが前提
Anthropic自身の企業向けデプロイのドキュメントは、組織展開時のベストプラクティスとして6つの項目を挙げている。クラウドプロバイダー経由でモデルバージョンを固定するという技術的な1点を除くと、残り5つは次のように整理できる。
| 推奨事項 | ドキュメントの記述 |
|---|---|
| ドキュメントとメモリへの投資 | CLAUDE.mdファイルを組織の複数階層に配置し、コードベースの理解を助ける |
| デプロイの簡素化 | 独自の開発環境がある場合、「ワンクリックで導入できる仕組み」が組織内での普及の鍵になる |
| 段階的な利用から始める | 新規ユーザーにはまずコードベースへの質問や小さな修正から試させ、様子を見ながら徐々に自律的な使い方に慣らす |
| セキュリティポリシーの設定 | 何を許可・禁止するかをmanaged permissionsで固める |
| MCPの一元管理 | 一つの中央チームがMCPサーバーを設定し、.mcp.jsonをコードベースにチェックインして全員に行き渡らせる |
読み返すと、5つのうち4つが「誰か(部署)がこれを継続的に担当する」ことを前提にしている。組織単位のCLAUDE.mdは書いて終わりではなく更新し続ける必要があるし、セキュリティポリシーもMCPの一元管理も、継続的にメンテナンスする担当がいて初めて機能する。ドキュメント自体は「何をすべきか」を詳しく書いているが、「それを誰が担当するか」までは書かれていない。ここが、MITの調査でいう「オーナー不在」の入り込む余地になる。
「配れば広がる」という前提が崩れる場所
以前の記事で扱った管理者主導型・現場主導型のどちらを選んでも、最初の号令をかけることはできる。だが号令をかけた後、次の3つを誰が担当するかが決まっていないと、号令の効果は数ヶ月で消える。
- CLAUDE.mdや権限設定を、単発の初期設定でなく継続的に更新する担当
- 利用状況とコストを定点観測する担当(効果測定の考え方は別記事で整理した)
- 現場からの「うまくいかない」「もっとこう使いたい」というフィードバックを拾い上げ、設定に反映する担当
これらは特別な専任チームである必要はない。中小企業の規模であれば、情シス・DX推進の担当者が兼務で十分に回せる範囲だ。実際、このLP自体の運用がその一例になっている。記事の公開パイプライン一つとっても、「助成金を主題にした記事は自動マージせず人間の確認を通す」という基準をCLAUDE.mdに明文化し、各記事の事実確認結果と判断根拠を引き継ぎ用のドキュメントに記録し続けている。専任の担当者がいるわけではなく、運用ルールを文書に落として更新し続けているだけだが、それだけで「誰が何を決めたか分からなくなる」状態は避けられている。
自社で確認すべきこと
新しく展開を始める前に、次の3つに答えが出るか確認するとよい。
- 導入から30日後・90日後に、利用状況とコストを見る人は決まっているか
- CLAUDE.mdや権限設定に変更が必要になったとき、誰が判断して誰が反映するかが決まっているか
- 「使われなくなってきた」というシグナルが出たとき、それを拾い上げる場所があるか
3つとも即答できないなら、ツールを配る前に整えるべきはトレーニング資料でも展開計画でもなく、この3つに答えられる担当を1人決めることだ。
自社の体制でこの担当をどう置くべきか整理したい場合は、パイロット・構築のフェーズで一緒に検討できる。まずは30分の無料診断から相談してほしい。