Claude Code法人導入、最初の30日で「誰も使わない」を回避する。NEC・ギブリー・デジライズ別オンボーディング設計図

「導入、決まりました。あとはよろしく」

5/3に書いたClaude Code法人導入の市場化記事を読んだ実務者から、ここ数日で立て続けに同じ相談が来ました。3社の中からどれを選ぶかは決まった。問題は次です。

決まった翌日から、何をやればいいのか。

僕の経験で言うと、ここで止まる会社が一番危ないです。導入を決めた瞬間が一番熱量が高くて、その熱が冷める前に最初の30日を設計しないと、3ヶ月後には「あの予算、何に使ったの？」が役員会で出てきます。

この記事は、5/3の続編にあたります。NECモデル、ギブリーモデル、デジライズモデルのどれを選んだ会社にも当てはまる「最初の30日プレイブック」をまとめました。読み終わったときには、明日の朝礼で何を宣言するかが決まっているはずです。

「導入決定」の翌日から始まる、見えにくい競争

導入が決まった翌日、現場で何が起きるか。たいていの会社で、同じ展開になります。

役員会で「Claude Code法人導入」が承認されました。担当部署はIT部門か人事部門のどちらか。担当者は契約書の押印に動き、社内告知メールの草案を作る。ここまでが2〜3日の仕事です。

そして、4日目から動かなくなります。

理由は単純で、「次に何をすべきか」が誰にも書かれていないからです。契約は結んだ。アカウントは配れる。ライセンスもある。でも「現場の誰が、何を、どのタイミングで動かすか」のスケジュールが空白のままです。

ここで多くの会社が、便利な逃げ道を選びます。「とりあえず使ってみてください」メールを全社に流す。それで完了したことにしてしまう。

僕がこの2週間で受けた相談の中で、最も切実だったのがこのパターンでした。「役員から導入の指示が来たので、ベンダーは決めて契約したんですが、現場が誰も触っていないんです。来月の会議で進捗を聞かれます。どうすればいいですか」。

僕の答えはいつも同じです。「ツール導入」で終わらせない。「業務改革プロジェクト」として動かす。この発想の差が、最初の30日で見えにくく、しかし決定的に効いてきます。

5/3の記事では、3社の規模感と狙いから「自社モデル」を選び分ける話を書きました。今日はその続きです。選んだ後の30日をどう使うか。これを設計しないと、せっかく選んだベンダーのリソースを最大限使えません。

3モデル共通の落とし穴3つ

NECモデル、ギブリーモデル、デジライズモデル。サービス内容は違いますが、どのモデルを選んでも同じ場所で詰まる。実際に法人AI導入の現場を見ていると、共通する落とし穴が3つあります。

落とし穴①: 現場の声を聞かずに展開計画を作る

最も多いのがこれです。導入決定をしたIT部門と人事部門だけで「全社展開ロードマップ」を作ってしまう。現場の業務実態を踏まえずに計画を出すので、配られた現場が「これ、私の仕事の何に使うの」となります。

僕が見てきた中では、導入後の利用率が低い会社の多くがこのパターンでした。逆に利用率が高い会社は、導入決定の翌週には現場ヒアリングを入れています。「あなたの部署で、今いちばん時間を取られている作業は何ですか」を聞きに行く。

聞いた結果を全社展開計画に反映するから、配られた人が「あの会議で出した話、ちゃんと反映されている」と感じます。これが最初の心理的ハードルを越える一番の近道です。

落とし穴②: 最初の成功事例を作らずに広げる

2番目の落とし穴は、パイロット部門を作らずに全社一斉展開してしまうことです。

全社一斉が悪いわけではありません。NECのように3万人規模で展開する場合は、初日から全部署にライセンスを配る判断もありえます。問題は「最初に成功する部門」を意図的に設計していないことです。

組織が大きく動くときには、必ず最初に勝った部門が必要です。社内の他部署が「あそこがやれているなら、うちもやれる」と思えるリファレンス部門。これが30日以内に作れていないと、3ヶ月目に「他社の方が進んでいる」報道を見て役員会が動揺します。

落とし穴③: KPIを設計する前にツールが配られる

3番目は、評価軸の設計が後回しになることです。

「Claude Code法人導入のKPIって何ですか」と僕が聞き返すと、多くの担当者が固まります。利用率、と答える人が多い。ただ、利用率だけだと「とりあえずログインだけする」運用が起きるのです。

評価軸は3階層で設計するのが定石です。第1層はツール利用の量で、ログイン率と月間アクティブユーザー数を測ります。第2層は業務改善の質で、具体的な時間短縮事例と新規アウトプット数を数える。第3層は組織変容の深さで、社員のAIリテラシー診断スコアと現場発の活用提案数を見るのが基本です。この3階層をDay 1から決めておかないと、3ヶ月後に何を報告すればいいか担当者が困ります。

この3つの落とし穴は、3社のどのサービスを選んでも自分たちで対処する必要があるのです。ベンダーが30日プログラムを提供してくれるからといって、社内の意思決定は社内でしかできません。

NECモデルを選んだら、大企業の30日オンボーディング設計

NECモデルを選んだ会社は、規模も意思決定の重さも他の2モデルと違います。NEC自身がグループ約3万人にClaudeとClaude Codeを展開し、Center of Excellenceを設置して運営する構造です（出典: NEC公式プレスリリース）。同様の規模感で動く会社の30日設計を書きます。

Week 1: 経営アジェンダ化とCoE立ち上げ

最初の1週間は、AI推進を経営アジェンダに正式に組み込む作業です。

具体的には、CIOまたはCDOクラスを責任者にした「AI推進室」または「Center of Excellence」を社内に立ち上げます。NECがそうしているように、この組織は単なるIT部署の延長ではなく、全社のAI戦略を統合する司令塔。役員会の議題に「月次AI進捗報告」を追加してもらうのも、この週のうちに済ませておきます。

ここで重要なのが、外部の手を借りる体制です。NECはAnthropicから直接の技術支援を受けて動いている。同規模の会社が同じことをやるなら、Claude Coworkを使った業界別ソリューション開発のためのパートナー選定を、Week 1のうちに動かしておきます。

Week 2-3: パイロット部門の選定と「最初の勝ち」を作る

2〜3週目で、社内3〜5部門を選んでパイロット運用に入ります。

選び方は、業務インパクトが大きく、かつ現場のモチベーションが高い部門です。NECは金融・製造・自治体の3領域から先行で着手すると公式に明言しました。同じ発想で、自社の中で「効果が見えやすく」「現場が前向き」な3〜5部門を選ぶのが原則です。

パイロット部門には、社内のAI推進担当が直接張り付きます。Week 2にヒアリング、Week 3に最初のユースケース実装。この2週で「うちの部署で時間が3割減った」が言える事例を1つ作ることが目標です。

Week 4: KPI再確認と全社展開ロードマップ

最終週は、パイロット部門の成果をベースに、全社展開ロードマップの点検です。

Day 1で決めた3階層KPIを、Week 4の段階で実測値に置き換えます。利用率は何%か。業務改善事例は何件出たか。社員のリテラシー診断は何点上がったか。実測値を入れることで、役員会への次月報告の素地ができます。

NECモデルの強みは、Anthropicとの直接連携で技術的な裏付けが厚いことです。だからこそ、社内の運用設計に集中できる体制を作ることが、ベンダーリソースを最大限使う近道になります。

ギブリーモデルを選んだら、人材育成型の30日設計

ギブリーの「Claude Cowork 活用支援」を選んだ会社は、対象が「ビジネス職からエンジニアまで」と明示されているのが特徴です（出典: ギブリーPR TIMES）。エンジニアだけでなく、非エンジニアも巻き込む前提で30日を設計します。

Week 1: 共通言語会議の設置

ギブリーモデルで最初に起きやすい誤解は、「研修プログラムの中身を全部ベンダー任せにする」ことです。

研修内容は確かにベンダーが組んでくれます。問題は、研修を受けた後に「現場で何に使うか」が社内で決まっていないこと。ここを埋めるために、Week 1でビジネス職とエンジニアの共通言語会議を設置するのが先決です。

具体的には、各部署の代表（ビジネス職1名、エンジニア1名）を集めた週次定例を立てます。最初の議題は「うちの部署で、AIエージェントに任せたい仕事は何か」。この問いに、ビジネス職とエンジニアが同じテーブルで答える設計が肝です。

Week 2: 研修ファーストで「使える」を共有する

2週目は、ベンダーの研修プログラムを集中的に走らせます。

ギブリーの強みは、ビジネス職もエンジニアも同じ研修を受けられる設計です。これを最大限活かすために、部署横断の研修バッチを組みます。営業1名、開発1名、企画1名、人事1名のような4〜5名のチームで研修を受け、研修中から自部署のユースケースを議論する。

研修だけで終わらせると効果が薄くなります。研修後に「自部署で何に使うか」を持ち帰る宿題を出すのが、ギブリーモデルを使い切るコツです。

Week 3-4: 現場プロジェクト立ち上げと振り返り

3〜4週目は、研修で身についたスキルを現場プロジェクトに落とす番です。

Week 3で各部署のエース級が、自部署で「Claude Coworkで業務を組み替えるパイロットプロジェクト」を1本立ち上げます。Week 4は実装の振り返りと、横展開の方針決め。

ギブリーモデルで僕が見てきて成功率が高いのは、非エンジニアの管理職が最初のチャンピオンになるパターンです。エンジニア発の改革は社内で警戒されやすいですが、人事や経営企画の管理職が「これで会議が半減した」と言うと、組織全体の温度が一気に変わります。

デジライズモデルを選んだら、現場自走型の30日設計

デジライズの「Claude Code法人導入支援」は、動画60本×ハンズオン×伴走の3本柱で、先着10社限定です（出典: デジライズPR TIMES）。中小規模で「自走できるチーム」を作りたい会社向けの設計を書きます。

Week 1: 動画60本の見方戦略

最初の1週間は、動画60本のカリキュラムを「全員が全部見る」のではなく、役割別の必修パスに切り分けます。

僕がここで強調したいのは、動画は順番通りに全部見ても効果は出ないことです。経営層が見るべき動画、エンジニアが見るべき動画、現場リーダーが見るべき動画は違う。Week 1で各メンバーの「最初の10本」を決めて、配布します。

カリキュラム全体を網羅するのは、Week 4以降の業務時間外学習に回すのが現実的です。30日の中では「業務に直結する10本」に集中するほうが、自走の手応えが早く出ます。

Week 2-3: ハンズオンと伴走支援を最大限使う

2〜3週目は、ハンズオンセッションと伴走支援が中心になります。

ここでの落とし穴は、「ベンダーに丸投げにしない」ことです。先着10社という限定数が示しているように、デジライズは1社あたりに濃く時間を取ってくれる設計になっている。だからこそ、自社側が「今うちで詰まっている業務はこれ」と具体的に持ち込む準備をしておかないと、伴走時間をもったいなく使うことになるのです。

Week 2の頭で、社内で「Claude Codeで動かしたい業務リスト」を10本作ります。Week 2〜3のハンズオンで、この10本を1つずつ実装していく流れが、現場自走型の本来の使い方です。

Week 4: 自走チェックと撤退判断

最終週は、自走できる体制が整ったかをチェックする時間です。

具体的には、ベンダーの伴走がない週を1週間だけ意図的に作ります。社内のチームだけで、Week 2〜3で実装したフローを動かしてみる。回ればOK、止まればどこで止まったかを記録する。

この自走テストを30日以内にやることが、デジライズモデルを選んだ価値を最大化します。先着10社の枠を取った以上、契約期間が終わった後に自社で動かせる状態を作るのが本来の目的です。

KPIと撤退基準。3モデル共通の評価軸

3モデルどれを選んでも、Day 30の評価軸を事前に決めておくことが、最初の30日を「進捗報告できる30日」にする最低条件です。

Day 30の3階層KPI実測値

落とし穴③で書いた3階層KPIを、Day 30時点で実測します。

ツール利用の量は、ログイン率と月間アクティブユーザー数で測ります。ベンチマークとしては、配布アカウントの60%以上が週1回以上ログインしていれば合格ラインです。50%を切ると、現場が止まっているサインです。Week 4でのテコ入れを検討してください。

業務改善の質は、具体的な時間短縮事例の件数で測ります。Day 30時点で部署あたり1件、全社で5件以上の事例が出ていればOK。事例の中身は、「会議資料作成が2時間から30分に減った」「営業メールの初稿生成が10分から3分に減った」のような数値ベースが理想になります。

組織変容の深さは、社員のリテラシー診断スコアと、現場発の活用提案数です。スコアは導入前後で測定して比較します。提案数は、社内の「AIで改善したい業務」フォームに月10件以上集まればOKです。

続けるか撤退するかの判断ライン

Day 30で3階層KPIを実測し、続けるか撤退かを判断するのが最後の仕事です。

僕が経験的に使っている基準があります。利用率50%以下、改善事例3件以下、提案数5件以下のうち2つ以上が当てはまったら、Day 60までに体制を作り直すべきです。これは「撤退」ではなく「再設計」として捉えてください。多くの場合、運用設計の見直しで持ち直します。

3つ全部が当てはまったら、ベンダー選定からやり直す覚悟が必要です。これはまれなケースですが、ありえないわけではありません。

失敗を成果に変える運用

評価軸が低かったとしても、Day 30で正直に出すことが次の30日を救います。

役員会で「順調です」と報告して、Day 60で破綻するパターンが一番怖いです。Day 30の段階で「想定より下振れています、原因はXとYです、Day 60までにこう立て直します」と出すほうが、長期的には信頼を損なわない動き方になります。

まとめ。今週やる3つのこと

1つ目は、自社が選んだモデルの「Week 1タスク」を担当者の予定表に入れることです。NECモデルならCoE立ち上げ、ギブリーモデルなら共通言語会議、デジライズモデルなら役割別動画パス設計。今週の朝のうちに、誰が何を動かすかが見えていない状態を脱します。

2つ目は、3階層KPIをDay 1で決めること。利用率、改善事例、提案数の3層で、自社の合格ラインを今週中に書き出します。あとから決めるとバイアスがかかるので、ツールが配られる前に決めるのがコツです。

3つ目は、最初の勝つ部門を決めること。全社展開でも、まず勝つ部門を3〜5個指定する。この部門への支援を厚くして、Day 30で「あそこがやれているなら、うちも」と他部署が言える事例を1つ作ります。

5/3の記事で書いたように、Claude Code法人導入は選んで終わりではなく、選んだ後の運用が10倍重要な設計です。3社のサービスがどれも優秀だからこそ、社内側の準備で差がつきます。

過去にAI導入が頓挫した経験がある会社ほど、Day 1から30の動きを丁寧に設計してください。決めた瞬間が一番熱い。その熱が冷める前に、最初の30日を埋めましょう。

僕もまだ、こうした導入の現場で毎週新しいパターンに出会います。一緒にやっていきましょう。

---

参考記事

• Claude Code法人導入が「市場化」した10日間。NEC・ギブリー・デジライズ、3社のサービスから自社モデルを選ぶ最短ルート（5/3公開・本記事の前編）
• 前回300席が早期完売。Claude Codeセミナーに「非エンジニア」が殺到した理由と、彼らが最初にやったこと（4/18公開・非エンジニアの取り組み方）
• 日本のIT企業が全エンジニア・全コンサルにClaude Codeを配った。ARアドバンストテクノロジの決断から逆算する「自社導入の判断基準」（4/19公開・全社展開事例）

出典

• NEC「NECとAnthropic、戦略的協業を発表」: https://jpn.nec.com/press/202604/20260423_01.html
• ギブリー「Claude Cowork 活用支援サービスの提供開始」: https://prtimes.jp/main/html/rd/p/000000382.000002454.html
• デジライズ「Claude Code法人導入支援サービス開始」: https://prtimes.jp/main/html/rd/p/000000077.000126540.html