「Claude Code、ライセンスは全員に配ったのに、ふたを開けたら結局あの2人しか使ってない」。受託開発のリーダーや部長層からよく聞く悩みです。
導入時は社内で盛り上がり、勉強会も開いたはずなのに、3か月もすると一部の若手と熱心なエンジニアが個人プレーで使い続け、ほかのメンバーは元のやり方に戻っている。月次のレポートを見れば利用ログは右肩下がり。経営からは「あれ、効果どうなったの」と聞かれて言葉に詰まる。こうした状況は珍しくありません。
問題は Claude Code そのものではなく、「使う動機」と「使う場所」が組織として設計されていないことにあります。この記事では、Claude Code が社内で使われなくなる3つの原因と、それを解消するための「最初の成功体験 → 共有可能なテンプレ → 業務工程への組み込み」という3段階フレームを解説します。導入推進担当やマネジメント層が、利用率の低迷から脱却するためのヒントとして読んでいただける内容です。
よくある光景｜Claude Code が「使われていない」とはどういう状態か
まず、現場でよくある「使われていない」状態を具体的に見ていきましょう。
ありがちなのは次のような状態です。
- ライセンスは20人分配ったが、月次のアクティブ利用者は4〜5人で固定化している
- 使っている人は「便利ですよ」とは言うが、何にどう使っているか他のメンバーは知らない
- 一部のリーダーが Claude Code で書いたコードをレビューに回しても、レビュアー側が読めずに突き返される
- 案件のキックオフや進捗会議では、相変わらず「人が手で書く前提」で工数見積もりが組まれている
- 半年後、契約更新の判断材料がなく「とりあえず継続」になる
これは「ツールが使われていない」のではなく、個人の生産性向上で止まっていて、組織の仕事のやり方に変化が起きていない状態です。経営から見れば投資効果が見えず、現場から見れば「自分が使う理由」が見つかりません。
原因1：個人の試行錯誤に依存している
最初のつまずきは、導入直後の「最初の1週間」で生まれます。
Claude Code は、与えるコンテキストやプロンプトの作り方で出力の質が大きく変わります。慣れている人は、リポジトリの構造を読み込ませ、コーディング規約を伝え、テストの書き方を指示してから依頼します。一方、慣れていない人は、いきなり「このバグを直して」と書き、期待した結果が返ってこないと「やっぱり使えない」と判断します。
ここで起きているのは、Claude Code を使えるかどうかが個人の試行錯誤量に依存しているという構造です。導入研修を1回やっただけでは、この差は埋まりません。
受託開発の現場では、案件ごとに技術スタックも顧客のレビュー観点も違います。汎用的な「プロンプト集」を配っても、自分の案件にどう当てはめればいいか分からず、結局「使ってみたけどピンと来なかった」で終わります。最初のつまずきを乗り越えられないメンバーは、二度目を試そうとしません。
原因2：成功事例が共有されず属人化している
次の原因は、使えている人の知見が組織に流れない構造です。
うまく使っているメンバーに「どう使ってます？」と聞くと、たいてい答えは具体的です。「設計レビュー前に、自分の設計書を Claude に読み込ませて、抜け漏れを聞いてる」「お客さま向けの状況報告メールは、案件サマリと前回の議事録を渡して下書きしてもらう」など、自分の業務に組み込んだ使い方を持っています。
ところが、これらは Slack の DM や個人のメモに留まり、チームに共有されません。理由は単純で、「こんな雑な使い方を共有していいのか分からない」「自分のプロンプトは未完成」という心理的なブレーキがあるからです。共有の場とフォーマットが用意されていないと、知見は属人化したまま蓄積されていきます。
属人化が続くと、別の問題も起きます。使えている人が異動・退職すると、その案件のAI活用ノウハウが丸ごと消えます。組織として再現できないため、新しいメンバーはまたゼロから試行錯誤することになります。
原因3：業務工程のどこに組み込むか設計されていない
3つ目が、もっとも見落とされがちな原因です。
Claude Code が「使う/使わない」の意思決定が、メンバー一人ひとりに委ねられている状態だと、忙しい日ほど使われなくなります。人間は普段の手順から逸脱することにコストを感じるため、「いつもの手順 + AIに聞く」という追加作業は、納期が迫ると真っ先に省かれます。
定着している組織の特徴は、業務工程の中に Claude Code を使う場所が明示的に組み込まれていることです。たとえば、
- 設計レビュー前に「Claude による抜け漏れチェック」をチェックリストに入れる
- プルリクのテンプレートに「AIレビューでの指摘事項と対応」欄を設ける
- 週次の進捗報告書は「Claude による要約案 → PMが事実確認」という手順を標準化する
このように、「いつ・どの工程で・誰が・何のために使うか」が手順書レベルで決まっていると、忙しいときでも自然に使われます。逆に、これが決まっていないと「便利だけど自分の仕事には不要」と判断され、利用は止まります。
定着させる3段階フレーム
ここまで挙げた3つの原因は、それぞれが連動しています。個人の試行錯誤頼みになるから成功事例が出にくく、出ても共有されないから工程にも組み込めない。逆に言えば、この順序を意識して整えれば定着は進みます。
具体的には、次の3つの段階で進めていきます。
段階1．最初の成功体験を、特定のメンバーで作る
全員一斉ではなく、まずは2〜3人の小さなチームで、1つの業務に絞って成功体験を作ります。たとえば「結合試験の不具合票から、原因仮説を整理する」「お客さま向けの週次報告メールを下書きする」など、頻度が高く、品質のバラつきが許容される業務から選びます。
この段階の目的は、ツールを社内で広めることではありません。「Claude Code を使えば確かにこの作業は楽になる」という実例を、自社の文脈で1つ作ることです。汎用的なデモではなく、自分たちの案件・自分たちの顧客名・自分たちの技術スタックで動く実例があると、次の段階に進みやすくなります。
ここで重要なのは、選ぶ業務を絞るという点です。「全社で生成AI活用」のような広い目標は、最初の段階ではかえって足を引っ張ります。1つの業務、1つのチームで「これは間違いなく使える」と言える状態を作るのが優先です。
段階2．成功体験を、共有可能なテンプレに変える
成功体験ができたら、それを他の人がコピペで再現できる形に整えます。具体的には、
- 何の業務に使うのか（例：結合試験の不具合票の原因仮説整理）
- どのタイミングで使うのか（例：不具合票が10件以上溜まった時点）
- どんなコンテキストを渡すのか（例：システム概要、不具合票一覧、過去の類似不具合）
- どんな出力を期待するのか（例：原因の仮説3つと、それぞれの確認方法）
- どこに注意するのか（例：顧客固有名詞は伏せる、最終判断は人が行う）
この5点をセットで「テンプレ」として残します。プロンプト本体だけを共有しても再現できません。業務の文脈と出力の使い方まで含めてテンプレ化することで、初めて他の人が使えるようになります。
ここで参考になるのが、テックエイドの過去記事「PM必見。AIをベテランPMに変える思考加速プロンプト術」で扱っているような、業務シーンに紐づけたプロンプトの設計の考え方です。プロンプト単体ではなく、業務手順とセットで設計する発想が、テンプレ化のコツになります。
段階3．テンプレを業務工程に組み込む
最後の段階は、できあがったテンプレを標準業務に組み込むことです。具体的には、
- チェックリスト・手順書・テンプレートの中に「ここで Claude Code を使う」というステップを書く
- レビュー時の確認項目に「AIによる事前チェックを通したか」を入れる
- 進捗会議のフォーマットに「AI下書きを使った成果物・所感」の欄を設ける
ここまでやって初めて、「使う/使わない」の判断がメンバー個人ではなく、組織の標準業務の側に移ります。忙しい人ほど標準手順に沿って動くので、ここに組み込まれていれば自然に利用されます。
PM業務の特定シーンにAIを組み込む発想については、「PMの会議膠着を打破するAI式ファシリテーションプロンプト術」のように、業務シーンに紐づけて使い方を設計する記事も参考になります。
よくある失敗｜定着フェーズで起きること
3段階フレームを進めるときに、よく見かけるつまずきを3つ挙げます。
まず挙げられるのが、「全社展開を急ぎすぎる」失敗です。経営層から「投資効果を見せろ」と言われると、まだ段階1の検証が終わらないうちに全社研修を企画してしまいがちです。テンプレも工程組み込みもない状態で広げると、メンバーは「使ってみたけどよく分からなかった」で終わり、その記憶が次の取り組みの足かせになります。
次に、「ツール導入＝定着」と捉えてしまうのも、よくあるつまずきです。ライセンス数や利用ログだけを KPI に据えると、組織の業務が変わったかどうかが見えなくなります。指標としては、利用回数より「どの工程で、何件、AI活用に伴うアウトプットが出ているか」を追うほうが実態に近づきます。
そして三つ目が、「成功事例の共有を担当者任せにする」という落とし穴です。共有の場とフォーマットを用意しないと、忙しいメンバーは絶対にまとめません。月1回でいいので、成功事例をテンプレ形式で集める時間を業務として確保することが必要です。
まとめ｜定着は「個人の試行錯誤」から「組織の標準手順」へ
この記事で見てきたように、Claude Codeが社内で使われない原因は主に3つです。
- 個人の試行錯誤に依存している
- 成功事例が共有されず属人化している
- 業務工程のどこに組み込むか設計されていない
そして、その解決策として紹介したのが次の3段階です。
- 最初の成功体験を、特定のメンバー・特定の業務で作る
- 成功体験を、業務文脈ごと共有可能なテンプレにする
- テンプレを業務工程に組み込み、標準手順にする
という流れです。重要なのは、この順序を飛ばさないという点です。テンプレ化なしに工程組み込みはできず、最初の成功体験なしに共有可能なテンプレは作れません。
導入推進担当がまず着手すべきは、全社展開でも研修プログラム作成でもなく、「自社の文脈で確実に効く業務シーンを1つ選ぶ」ことです。そこから始めれば、3段階は自然につながります。
次の一歩へ｜体系的に学ぶ
ここまで整理した3段階は、現場メンバー一人ひとりが Claude Code をはじめとした生成AIを業務に組み込む力を持っていて初めて回ります。導入推進担当が組織設計を整える一方で、現場メンバー側にも「業務文書にAIを使い分ける力」や「PM業務の管理運用にAIを組み込む力」が必要です。
テックエイドでは、この2つの実務テーマを体系的に学べる Udemy 講座を提供しています。
-
【生成AI実践】仕様書・報告書・議事録を半分の時間で仕上げる技術（AIX-101） — 文書タイプ別のプロンプト設計、AI下書き→人間レビューのワークフロー、テンプレート化と再利用までを扱います。本記事の段階2「テンプレ化」の具体的なやり方を、現場メンバー本人が学ぶのに適した内容です。
-
【生成AI実践】進捗・課題・リスク管理をAIで加速する運用設計（AIX-102） — 進捗報告の自動要約、課題管理台帳の分類、リスク対応案の生成、定例会議の準備自動化を扱います。段階3「業務工程への組み込み」を、PM業務の文脈で具体化したい方向けです。
導入推進担当が組織側の3段階を整えながら、現場メンバーには上記のような体系的な学びを並走させることで、Claude Code をはじめとした生成AI活用は、属人化から組織の標準手順へと移っていきます。