ChatGPTを法人契約した直後の30日で何をするか。キックオフ・用途カタログ・部門別ハンズオン・週次共有・つまずき回収を時系列で整理し、「契約しただけで使われない」状態を防ぐ立ち上げ運用の設計を情シス/DX担当向けに解説します。
生成AIの法人プランを契約したものの、数か月経ってログを見ると一部の熱心な社員しか使っていない——。情報システム部門やDX推進の担当者から、こうした声を聞く機会が増えていると考えられます。契約という「決定」は済んでいるのに、現場の「行動」がそれに追いついていない状態です。これは担当者の熱意や社員の能力の問題というより、契約と利用のあいだにある「立ち上げ運用」が抜け落ちていることに起因する場合が多いと考えます。
アカウントを発行し、ログイン方法を案内すれば、形式上は「導入」が完了します。しかし、多くの人にとって空白の入力欄を前にして「さて、何を頼もうか」と考えるのは、想像以上にハードルが高いものです。日々の業務は既存のやり方で回っており、わざわざ新しい道具に置き換える動機がなければ、人はいつもの手順に戻ります。ツールが配られただけの状態は、いわば「材料は届いたがレシピも調理の場もない」状態に近く、使われないのはむしろ自然な帰結だと考えられます。
導入したAIツールが社内で使われない背景には、いくつか共通する構造があると考えます。第一に、自分の業務のどこに当てはまるのかという「用途の翻訳」が各人任せになっていること。第二に、うまくいった使い方が個人の中に留まり、組織に共有される経路がないこと。第三に、少し試してうまくいかなかったときに、相談したり軌道修正したりする窓口がないこと。これらはツールの性能ではなく、運用の設計で埋めるべき隙間です。この構造は導入したAIツールが社内で使われない理由でも整理していますが、本記事ではとくに「契約直後の30日」に絞って、その隙間を埋める段取りを時系列で見ていきます。
立ち上げに期限を切るのは、勢いには賞味期限があるためだと考えます。契約直後は「新しいものが入る」という期待や関心が社内に生まれやすく、この関心が最も高い時期に用途の体験を届けられるかどうかが、その後の定着を左右する可能性が高いと考えられます。関心が薄れてから研修を始めても、参加率も熱量も上がりにくくなります。30日という区切りは、短すぎて中身が薄くならず、長すぎて熱が冷めない、ひとつの現実的な目安として置いています。厳密な日数そのものより、「期間を区切って、時系列で段取りを組む」という姿勢が本質だと考えます。
立ち上げの30日は、大きく4つの局面に分けて考えると設計しやすいと考えます。順に、（0）キックオフで方向を合わせる、（1〜2週）用途を配り体験させる、（3週）成果を共有し横に広げる、（4週）つまずきを回収してルールに落とす、という流れです。それぞれの局面には固有の目的があり、前の局面が次の局面の燃料になる構造で組むのが要点だと考えられます。
4つの局面すべてに共通して置くべき問いは、「これはあなたの日々の業務のどこで使えるか」だと考えます。ツールの機能を一通り説明する研修は、聞いた直後は理解できても、翌日には自分の仕事に結びつかず忘れられがちです。逆に、参加者自身が抱えている具体的な業務を題材にすると、体験が記憶に残り、翌日から手が動きやすくなると考えられます。この「業務起点」という軸は、従業員向け生成AI研修の設計とも共通する考え方です。
立ち上げを回すには、少人数でも「推進する人」を明確にしておくことが有効だと考えます。典型的には、全体を統括する情シス/DX担当、各部門で使い方を翻訳する「部門アンバサダー」、そして経営層のスポンサー、という三層です。とくに部門アンバサダーの存在は重要だと考えます。情シスが全部門の業務を理解するのは現実的でなく、各現場の言葉で用途を翻訳できる人がいると、体験の当てはまりが格段に良くなると考えられます。アンバサダーは兼任で構わず、まずは各部門から関心の高い1名を募る形が始めやすいと考えます。
設計の段階で見落としがちなのが、「30日が終わった後、何が組織に残るか」を先に定義しておくことです。残すべきものは主に三つ、（1）活用事例とプロンプトが蓄積される場、（2）使い方を相談できる窓口、（3）継続的に共有する定例、だと考えます。これらは30日のあいだに「動かしながら作る」ものであり、後付けしようとすると熱が冷めて立ち上がりにくくなります。生成AI活用が社内で進まない会社の共通点を扱ったこちらの記事でも触れていますが、単発のイベントで終わらせず「運用」に接続する視点が欠かせないと考えられます。
アカウントを配る前後のタイミングで、まずキックオフを行うと立ち上がりが安定すると考えます。キックオフの目的は操作説明ではなく、「なぜ導入するのか」「どこまで使ってよいのか」という前提を、参加者の頭の中で揃えることです。ここが曖昧なまま体験に進むと、人によって期待値も遠慮の度合いもバラバラになり、後の局面で足並みが乱れやすくなると考えられます。
キックオフでは、「この導入で何を目指すのか」を短く言語化して共有することが有効だと考えます。たとえば「調べ物・文章作成・要約・下書きといった日常業務の一次作業を軽くする」といった、身近で具体的な狙いから入ると、参加者が自分ごととして受け取りやすくなります。逆に「全社的な生産性を飛躍させる」といった抽象的で大きな目標だけを掲げると、現場は距離を感じてしまう可能性が高いと考えられます。目的は大きすぎず、最初の30日で手が届く範囲に絞るのが要点だと考えます。
キックオフで必ず触れておきたいのが、入力してよい情報の範囲です。生成AIへの機密情報や個人情報の扱いは、後回しにすると「なんとなく不安だから使わない」か「無警戒に何でも入れる」かの両極に振れやすく、どちらも望ましくないと考えます。法人プランで学習に使われない設定であっても留意すべき点は残るため、情報区分ごとの線引きを最初に、しかも「違反を責めるため」ではなく「安心して使うため」の枠として示すのが有効だと考えられます。具体的な区分の作り方は法務・セキュリティ部門と確認しながら詰める前提で、キックオフでは「迷ったら止めて相談する」という原則だけでも共有しておくと、萎縮と暴走の両方を避けやすくなると考えます。
キックオフのもう一つの役割は、期待値を現実に寄せることだと考えます。生成AIは事実でないことをもっともらしく述べる場合があり、出力をそのまま鵜呑みにできるものではありません。「間違えることがある前提で、下書きや叩き台として使い、最後は人が確認する」という付き合い方を最初に伝えておくと、後で「間違っていたから使えない」と離脱する人を減らせると考えられます。過度な期待も過度な警戒も、どちらも定着を妨げます。等身大の道具として紹介することが、結果的に長く使われる土台になると考えます。
キックオフで前提が揃ったら、次の二週間は「用途を配り、実際に体験させる」局面に充てると効果的だと考えます。ここが立ち上げの中核です。人は抽象的な可能性の説明では動かず、「自分の業務のこれが、こう楽になった」という具体的な成功体験があってはじめて、自発的に使い始めると考えられます。この二週間の狙いは、各人に最低ひとつの「効いた」体験を持ち帰ってもらうことだと考えます。
空欄を前に何を頼めばいいか分からない、という白紙の不安を解くために、用途カタログを用意することが有効だと考えます。用途カタログとは、「議事録を要約する」「メールの下書きを作る」「長文資料の要点を抜き出す」「表現を丁寧に整える」「アイデアを一緒に発散する」といった、日常業務でよくある使い道を一覧化したものです。使い方の例文（プロンプトのひな形）を添えておくと、参加者はゼロから考えずに「まず真似して試す」ことができます。真似から入って、自分の業務に少しずつ寄せていく——この最初の一歩の敷居を下げることが、カタログの目的だと考えられます。
ハンズオンは、可能な範囲で部門ごとに分けて行うと効果が高いと考えます。営業・経理・人事・製造・品質保証では、日々の業務も抱える悩みも異なり、全社一律の共通例だけでは「自分の仕事には関係ない」と受け取られがちです。営業なら提案文の下書きや商談メモの整理、経理なら定型的な文面作成や規程の要点確認、人事なら求人票や案内文の作成、といった部門固有の題材を持ち込むと、当てはまりが一気に良くなると考えられます。ここで先に募った部門アンバサダーが、自部門の言葉で用途を翻訳する役割を担うと、参加者の納得感が高まると考えます。
ハンズオンは、講師が用意した例題を眺めるだけでなく、参加者が「いま抱えている実際の業務」を題材に手を動かす形式にすると、定着しやすいと考えます。たとえば「明日書く予定のメール」「先週作った資料」を題材に、その場で試してもらう。うまくいけばそのまま明日の仕事で使え、体験が実務に直結します。ここで機密情報の扱いに触れる場面も出てくるため、キックオフで示した線引きを実地で確認する良い機会にもなると考えられます。座学より演習、汎用例より自分の実務——この二点を意識するだけで、二週間後の利用率は変わってくる可能性が高いと考えます。
ハンズオンの最中は、参加者がどこでつまずくかを観察する貴重な機会でもあると考えます。「思った答えが返ってこない」「指示の出し方が分からない」「そもそも何に使えるかピンとこない」——こうした声はすべて、後のカタログ改善やルール整備の材料になります。その場で拾い、記録しておくことが、次の局面（週次共有・つまずき回収）の土台になると考えられます。
体験が各部門に配られたら、次は「良い使い方を組織で共有する」局面に移ると効果的だと考えます。個人が見つけた効く使い方を個人の中に留めず、横に広げる仕組みをこの時期に立ち上げます。ここが弱いと、せっかくの成功体験が点在したまま組織の資産にならず、定着が個人技に依存してしまうと考えられます。
週に一度、15分程度の短い共有の場を設けると、負担が小さいまま横展開が進みやすいと考えます。形式は「今週こう使ったら助かった」を各部門から一つずつ持ち寄る程度で十分です。長く重い会議にすると続かないため、あえて短く、軽く、頻度を保つのが要点だと考えられます。人は他人の具体的な成功例を見ると「自分もそれならできそう」と感じやすく、抽象的な推奨よりも実例の共有のほうが行動を促す力が強いと考えます。
共有の場で出てきた「効いた使い方」は、その場限りにせず、蓄積していくことが重要だと考えます。良かったプロンプトのひな形を集約し、誰でも参照・再利用できる状態にしておくと、生成AIの成果が個人のスキルに依存する状態から、組織で再現できる状態へ近づくと考えられます。蓄積先は、すでに社内で使われている情報共有の仕組みや社内ナレッジ基盤など、既存の導線に載せると定着しやすいと考えます。新しい置き場所を増やすほど参照されなくなる傾向があるため、「いつも見る場所」に置くのが現実的だと考えます。
立ち上げ期に利用状況を把握したくなるのは自然ですが、ログイン数だけを追うと表面的な理解に留まると考えます。むしろ「どの部門で・どんな業務に・どう使われているか」という使われ方の中身に重心を置くほうが、次の打ち手につながると考えられます。使われていない部門があれば、それは責める対象ではなく、用途の翻訳が届いていないサインとして捉える。この視点は、AIエージェントを含む社内導入全体の進め方を扱ったAIエージェント社内導入の全体像とも通じる考え方だと考えます。
30日の最終週は、それまでに拾ったつまずきを回収し、続けていくための形に整える局面だと考えます。ここで立ち上げ期の学びを「その場の熱」で終わらせず、運用の仕組みに変換します。この転換ができるかどうかで、31日目以降に定着が続くか、静かに沈むかが分かれると考えられます。
まず、ハンズオンや週次共有で見えてきた「つまずき」を種類ごとに整理すると手当てしやすいと考えます。たとえば、（1）用途が思いつかない→カタログの拡充や部門別の例追加、（2）指示の出し方が分からない→プロンプトのひな形整備、（3）情報の入れ方に不安がある→線引きルールの明文化、（4）出力が信用できない→確認プロセスの明示、といった具合です。つまずきは一律に「教育不足」で片付けず、原因ごとに違う打ち手を当てるのが要点だと考えられます。
この時期に、入力してよい情報の範囲や確認の手順といったルールを、暫定版として明文化しておくと安定すると考えます。その際、ルールを禁止事項の羅列にすると利用そのものを萎縮させかねないため、「ここまでは安心して使える」という枠として示すのが有効だと考えられます。目的は取り締まりではなく、迷わず使えるようにすることです。ルールは一度で完成させず、運用しながら更新していく前提で置くのが現実的だと考えます。なお情報区分や法的な扱いは、自社の状況に応じて法務・セキュリティ部門と確認することが前提だと考えます。
最終週の締めくくりとして、30日で立ち上げた「共有の定例」「プロンプトの蓄積」「相談の窓口」を、誰が・どの頻度で回し続けるかを決めておくことが重要だと考えます。担当と頻度が決まっていない仕組みは、日常業務に押されて自然消滅しがちです。逆に、軽くても継続する仕掛けが残れば、利用は少しずつ広がり、深まっていく可能性が高いと考えられます。30日はゴールではなく、継続運用へのバトンを渡す地点だと捉えるのが要点だと考えます。
最後に、最初の30日でつまずきやすいポイントを、これまでの整理と重なる部分も含めてまとめておきます。いずれもツールの性能ではなく、運用の設計で避けられる種類のものだと考えます。
最初の30日で目指すのは、あくまで「多くの人が日常業務でひとまず使える」状態だと考えます。その先には、生成AIを個々人の道具から、業務プロセスそのものに組み込んでいく段階が続くと考えられます。ここまで来ると、テーマは「個人が使う」から「業務のどこに、どう埋め込むか」へと移り、社内ナレッジ基盤やデータ集約基盤との連携、さらには一定の手順を任せる社内AIエージェント基盤の活用といった論点が視野に入ってくると考えます。
いきなり全業務を自動化しようとするより、まず1部門・1業務で定着させ、そこで得た知見を横に広げていくほうが、現実的で失敗が少ないと考えられます。30日の立ち上げで生まれた「効いた使い方」の蓄積は、次の段階でどの業務を優先するかを見極める材料にもなります。焦って範囲を広げすぎず、成功の再現性を確かめながら進める姿勢が、結果的に早く広がる道になると考えます。
ここまで述べてきた立ち上げ運用は、あくまで一般的な考え方の整理です。実際の設計は、自社の業務・体制・情報の扱いによって最適な形が変わるため、現場で小さく試し、確かめながら組み立てていくことが前提だと考えます。私たちNsightは、産業用画像検査やVLM/AIの開発に加えて、生成AI研修や社内AIエージェント・業務OSの内製化支援に取り組んでおり、元キーエンス画像処理事業部で現場に向き合ってきた知見をもとに、「机上の理想」ではなく「現場で回る運用」を一緒に確かめていく立場を大切にしています。生成AIの活用が思うように進まない、あるいは導入したツールが使われていない、といった段階でも、実際の業務に即してどこから着手するかを一緒に検討することが可能だと考えます。まずは自社の状況を持ち寄って、現物の業務に照らして確かめてみることをおすすめします。
まずは操作説明の前に、キックオフで「なぜ導入するのか」「どこまで使ってよいのか（入力してよい情報の範囲を含む）」を揃えることをおすすめします。その上で、日常業務の使い道を一覧化した用途カタログを配り、部門別のハンズオンで各自の実務を題材に体験してもらう流れが、立ち上がりやすいと考えられます。機能の網羅説明より、自分の業務にどう当てはまるかを起点にするのが要点だと考えます。
厳密な日数そのものより、「期間を区切って時系列で段取りを組む」姿勢が本質だと考えます。契約直後は社内の関心が最も高く、その熱があるうちに用途の体験を届けられるかが定着を左右すると考えられます。30日は、中身が薄くならず、かつ熱が冷めきらない現実的な目安として置いています。自社の規模や体制に応じて調整して構わないと考えます。
全社一律でも実施は可能ですが、部門ごとに業務も悩みも異なるため、共通例だけでは「自分の仕事には関係ない」と受け取られやすいと考えます。手間を抑える方法として、各部門から関心の高いアンバサダーを1名募り、その人が自部門の言葉で用途を翻訳する形が現実的だと考えられます。全部門を情シスが担うより、負担も当てはまりも改善しやすいと考えます。
ログイン数だけでは表面的な把握に留まると考えます。むしろ「どの部門で・どんな業務に・どう使われているか」という使われ方の中身に重心を置くほうが、次の打ち手につながると考えられます。使われていない部門は責める対象ではなく、用途の翻訳が届いていないサインとして捉え、カタログの拡充や個別のフォローにつなげるのが有効だと考えます。
「迷ったら止めて相談する」という原則はキックオフで最初に共有し、詳細な情報区分ごとの線引きは、立ち上げの中で出てきたつまずきを踏まえて第4週あたりに暫定版として明文化していく流れが現実的だと考えます。ルールは禁止一覧ではなく「安心して使う枠」として示し、運用しながら更新する前提が有効だと考えられます。情報区分や法的な扱いは、自社の状況に応じて法務・セキュリティ部門と確認することが前提だと考えます。
立ち上げ運用の設計、研修、社内での定着支援、業務への組み込みまで、自社の現場に即してどこから着手するかを一緒に検討します。導入したものの使われていない、という段階からのご相談も歓迎です。
AI導入・内製化の相談をする