--- title: "社内のAI推進担当は何から始める？最初の30日の進め方" description: "社内のAI推進担当を任された非エンジニア向けに、最初の30日の進め方を解説。業務の棚卸し、Claude Codeでの試作、確認・修正込みの効果測定、同僚への引き継ぎまで、依頼文と架空データで具体化します。" url: "https://shiftb.dev/articles/internal-ai-champion-first-30-days" publishedAt: "2026-09-22" updatedAt: "2026-09-22" author: "立川修平（ぶべ）" category: "ai-development" tags: ["AI活用", "AI推進", "業務改善", "非エンジニア", "Claude Code"] --- # 社内のAI推進担当は何から始める？最初の30日の進め方 「来月の会議でAI活用の成果を見せて」と頼まれた。普段の仕事は減らず、比較するツールのタブだけが増えていく。僕が開発・運営するVibelyも、最初はShiftBの社内ツールで、教材管理、受講生のブログ投稿、進捗管理から始めました。身近な仕事を形にしてから、外部向けのサービスへ広げています。 社内のAI推進も、対象業務と確かめ方を決め、動くものを小さく作るところから始められます。この記事では、開発チームを持たない営業・企画・事務の担当者向けに、業務の棚卸しから試作、効果測定、同僚への引き継ぎまでを30日の計画例にします。日数は成果の保証ではなく、相談と作業を区切る目安です。 ## 手順1：最初に上司とAI推進の範囲を決める ### 1〜3日目：月末に見せる成果物を具体化する 「AI活用を推進する」だけでは、調査を続けるのか、研修を開くのか、業務を変えるのかが定まりません。最初の打ち合わせでは「申請一覧から未対応だけを抜き出す試作品と、導入前後の作業記録を見せる」のように、対象と成果物を決めます。担当者が実演できて、続けるかやめるかを上司が判断できる状態が、今回の到達点です。 全社のルール作りや全員への展開まで一度に引き受けると、兼務の担当者は作る時間を確保できません。自分が試作する範囲、上司が決める予算と作業時間、情報システム担当へ確認するデータの扱いを分けて書きます。社内に専門担当がいなければ、利用を承認する責任者に相談窓口を決めてもらいます。 上司には「通常業務のどれを調整して、この試作に時間を使うか」も確認してください。空いた時間で進めるという合意では、締め切りだけが残ります。承認に時間がかかる場合は、月末の報告を架空データによる実演までにするなど、成果物の範囲を先に調整します。 ### 使う道具より先に、使えるデータと責任者を決める 試作に使うサービス、入力してよい情報、出力の確認者、困ったときの停止・相談先を短いメモにします。例えば「会社で承認されたアカウントを使う。初回は架空データのみ。結果は業務担当者が確認し、実際の申請台帳には書き戻さない」という範囲です。担当になったことと、社内情報を外部サービスへ渡す権限を得たことは別です。 Claude Codeの[公式のデータ利用説明](https://code.claude.com/docs/en/data-usage)では、個人向けと商用契約でモデル改善へのデータ利用条件が分かれています。商用契約でも、データ提供を選ぶ仕組みがあります。「有料だから何を入れてもよい」と判断せず、会社の契約・設定・利用規程を確認します。手元で動くツールにも外部通信があるため、ローカル作業だけを理由に機密情報を渡さないでください。 ![社内AI推進の30日計画例。1〜7日目は業務を選ぶ、8〜14日目は架空データで試作、15〜21日目は確認と修正を含めて測定、22〜30日目は同僚へ引き継ぐ。承認と検証が済むまで次へ進めない](https://shiftb.dev/images/articles/internal-ai-champion-first-30-days-flow.png) ## 手順2：自分で正解を確かめられる1業務を選ぶ ### 4〜7日目：業務名ではなく、繰り返す操作を書く 棚卸しでは「営業」「総務」のような大きな単位を避け、「一覧を開く→未対応を探す→担当者別に並べる→確認して共有する」と、普段の操作を順に書きます。各操作に、入力元、判断条件、完成品、やり直しが起きる理由を添えます。担当者本人が迷うルールは、AIへ渡す前に決める対象です。 「申請管理を全部自動化したい」なら、まず未対応の抽出だけに絞ります。申請の承認、催促メール、台帳更新は外します。見た目を整えるだけでは痛みが残るので、今いちばん繰り返している操作を残してください。僕がよく伝える「ビタミン剤よりも鎮痛剤を作れ」は、社内向けにも当てはまる考え方です。 選ぶ基準は、自分が正解を説明できること、同じ処理が繰り返されること、失敗しても元の手順へ戻せることです。採用の合否や契約の可否など、判断の責任が重い業務は最初の題材から外します。顧客ごとに例外が多く、担当者も理由を説明できない業務は、試作の前にルールを整理する必要があります。 ### 作る前の時間と、残す作業を記録する 元のやり方で作業し、準備、抽出、確認、修正にどれだけ時間を使ったかを記録します。件数やデータの状態も残してください。少ない件数の新しい方法と、大量の件数を扱った従来の方法を比べても、何が改善したのかは分かりません。比較用の同じ入力と、手作業で確認した正解を保存します。 最初のつまずきは、日常業務と試作の範囲がずれることです。担当者への共有までを普段の仕事として測るなら、試作でも確認と共有にかかる時間を含めます。AIが一覧を出すまでだけを測って「速くなった」と結論づけないよう、測定の開始点と終了点をメモに書いておきます。 ここまでに必要なのは、入力、抽出条件、正解の例、確認者、元へ戻す方法です。これを書こうとして手が止まるなら、道具の知識より、仕事をどこで区切るかが課題です。AIシフトコースの無料相談会では、自分の仕事を題材に「何を作るところから学ぶか」を整理する入口にできます。 ## 手順3：架空データで動くものを1つ作る ### 8〜14日目：まず完成条件を日本語で渡す Claude Codeは、会話に沿ってファイルを読み、編集し、コマンドを実行できる開発ツールです（[公式の概要](https://code.claude.com/docs/en/overview)）。会社で利用が認められている場合は、業務用の原本と分けた空のフォルダで始めます。導入の操作は[Claude Codeの使い方](https://shiftb.dev/articles/how-to-use-claude-code)にまとめています。 悪い依頼は「申請管理をAIで便利にして」です。何を承認し、誰へ送るのかまでAIが補ってしまいます。良い依頼は、入力、出力、除外する操作、成功条件を指定します。公式の[ベストプラクティス](https://code.claude.com/docs/en/best-practices)でも、具体的な文脈と検証方法を渡すことが勧められています。次は架空の練習用データだけで試す依頼例です。 ``` 架空の申請一覧から、未対応の行を抜き出す試作品を作りたいです。 まず実装せず、入力と完成条件を確認して計画を説明してください。 入力：申請ID、担当、状態の3列を持つCSV（表を文字で保存する形式）。 状態は「未対応」「対応済み」のみ。未対応の行を担当ごとに並べて表示。 件数も表示する。同じ申請IDがある、必須欄が空、未知の状態がある場合は、 成功扱いにせず理由を表示する。元のデータは上書きしない。 実データ、外部送信、ログイン、台帳への書き戻しは今回の対象外。 入力画面、結果画面、エラーの確認方法を提案してください。 ``` ### 正しい一覧と、止まるべき入力を先に用意する 練習用の申請は5件にします。A01は担当甲・未対応、A02は担当乙・対応済み、A03は担当甲・未対応、A04は担当乙・未対応、A05は担当甲・対応済み。抽出されるIDはA01・A03・A04で、未対応は計3件、担当甲が2件、担当乙が1件です。これは説明用に作った架空データで、実際の社内記録ではありません。 別の練習ファイルではA01を重複させ、さらに別のファイルでは状態を空欄にします。どちらも正常な一覧を出す代わりに、理由が表示されることを確かめます。該当なしと処理失敗が同じ「0件」になると、利用者は見落とします。未対応がない正常な入力では「未対応なし」と表示する、と区別して伝えます。列名が「状態」から「対応状況」に変わった場合も、黙って読み飛ばすのではなく入力の違いを知らせる設計にします。使う人が修正できる案内まで含めて完成です。 AIに修正を頼むときは「動かない」ではなく「A02が結果に入った。対応済みなので除外してほしい」と、入力と期待結果の差を示します。画面だけを直して判定が変わっていないこともあるので、変更後は同じ練習データで確かめ直します。題材の選び方から制作を追いたい場合は、[業務アプリを作る手順](https://shiftb.dev/articles/claude-code-business-app-non-engineer)も使えます。 ### 「送信しない」という依頼と、実際の制限を分ける 依頼文に禁止事項を書くだけでは、アクセス権は制限されません。Claude Codeの[権限の公式説明](https://code.claude.com/docs/en/permissions)は、プロンプトの指示とツールの許可設定を区別しています。会社で許可された範囲に設定を合わせ、読めるフォルダや外部接続を確認します。今回の依頼は、AIとの会話自体を外部通信なしにする指定ではありません。 最初の試作では、元の業務システムにつなぐための鍵や、顧客情報を置かずに進めます。ファイルがどこへ保存されるか、画面を閉じると何が消えるかもAIに説明させます。「ローカルで動く」という説明だけで判断せず、実データを使う前には社内の確認担当へ構成を見てもらってください。 ## 手順4：確認・修正まで含めて効果を測る ### 15〜21日目：速さと正しさを別々に確認する 架空データで正解が出たら、社内で承認された範囲のデータで試行します。まだ承認されていなければ、架空データでの検証を続けます。元の業務手順も残し、同じ入力に対する結果を照合してください。数字が違う場合は機能を増やさず、抽出条件、重複、空欄の扱いまで戻って確認します。 効果測定では、処理時間だけでなく確認と修正も足します。以下は計算方法を示す架空の記録で、ShiftBや受講生の実績ではありません。同じ入力を扱い、作業を始めてから結果を確認し終えるまでを比べる想定です。 | 時間の内訳 | 従来の手順 | 試作を使う手順 | | --- | --- | --- | | 準備・抽出 | 40分 | 15分 | | 結果の確認 | 10分 | 12分 | | 修正・やり直し | 5分 | 3分 | | 合計 | 55分 | 30分 | この例の差は25分ですが、初回の制作・設定に使った時間は含めていません。制作時間と、継続してかかる利用料・保守作業は別に記録します。速くても見落としがあれば採用できず、正しくても確認の負担が増えるなら、入力を簡単にするなどの見直しが必要です。 ### 採用・修正・停止の条件を成果報告に添える 動画や画面を見せるだけでなく、「何を入力し、何が出て、人は何を確かめるか」を説明します。正常な例と、エラーで止まる例を並べて見せれば、使える範囲が伝わります。例外が出たときに担当者が毎回コードを修正する必要があるなら、その負担も成果報告に含めます。 判断を急がないため、入力条件を満たすのに誤った結果が出る、無断の外部送信が見つかる、復旧方法を説明できない場合は利用を止める、と先に決めます。単に使われなかった場合も、操作が難しいのか、そもそも困っていないのかを確認します。使う人数だけを増やして解決したことにしないでください。 上司への報告は「対象業務／変更した操作／正解との照合結果／確認込みの時間／残った問題／次に判断してほしいこと」を短くまとめます。改善しなかった場合にも、どの条件で使えなかったかが残れば次の題材を選べます。承認が未完了なら、検証済みの範囲と実運用の範囲を分けて報告します。 ## 手順5：同僚が使える手順にして引き継ぐ ### 22〜30日目：同僚に操作してもらい、説明が足りない箇所を直す 展開前に、同じ業務を知る同僚に手順書と練習データを渡します。作った本人が横から操作を代わらず、どこで迷うかを見ます。開き方、入力ファイルの選び方、結果の見方、エラー時の戻り方を補い、担当者が休んでも困らない状態に近づけます。アカウントは共有せず、会社で認められた方法で利用権限を用意してください。 AIへ伝える業務ルールと、人向けの操作手順は分けて残します。Claude Codeでは、プロジェクトの指示を`CLAUDE.md`というファイルに書いて継続して参照させられます（[公式のメモリ説明](https://code.claude.com/docs/en/memory)）。そこには入力の条件や確認方法を書き、人向けの手順書には保存場所と連絡先を記載します。ルールを変えたときは、正解の見本も更新します。 自分では使えても、同僚に「この結果が正しい理由」を説明できない。そこで必要になるのが、データの扱い、条件による分岐、エラーの読み方といった基礎です。作ったものを仕事で使い続けたい段階では、自分の題材を動かしながら中身を理解する学び方が、次の一歩になります。 ### 次の月は、同じ仕組みを維持できる範囲で広げる 月末には、試作品、使える入力の条件、正解の見本、作業記録、操作手順をまとめます。次の業務へ広げる前に、現在の仕組みを直す担当者と更新の判断者を決めてください。人が変わる、列が増えるなどの変更でも、以前の正解を使って確かめられるように残します。30日で全社へ展開できなくても、この単位が引き継げれば次の判断ができます。 Excelの集計が題材なら[Excel作業のAI自動化](https://shiftb.dev/articles/excel-automation-claude-code)へ進めます。開発チームの導入を扱う場合は、[AI駆動開発をチームに導入する方法](https://shiftb.dev/articles/ai-driven-development-team-adoption)で、開発者のレビューや組織の運用を確認してください。最初に取りかかるのは、今週繰り返した作業をひとつ書き出し、完成品と確認者を決めることです。