📋 この記事でわかること
株式会社エム・ジー・ケイ（M.G.K.）が、自社で Claude を業務に組み込んでいく過程を「AI導入日記」として公開しています。この記事は、その公開済み7本を時系列の一連のストーリーとして並べ直した総集編です。初日に引いた90日ロードマップを準備期（0〜30日）・整備期（31〜60日）・展開期（61〜90日）の3フェーズに分け、各段階で「何を決めたか」「どこでつまずいたか」を、日記に実際に書いた内容だけで再構成しました。初日の実作業3時間・会議0回、CLAUDE.md を書くきっかけになった1週間で二十数行の言い直しメモ、研修90分の内訳、見積書9項目・請求書8項目のチェックリストまで、社員数名の会社が実際に踏んだ順番が分かります。削減率などの効果指標は日記でも出していないため、この記事にも載せていません。
📖 この記事は約13分で読めます。
「AI導入の事例を見せてください」というご相談をよくいただきます。ただ、世の中に出ている導入事例の多くは大企業のもので、社員数名の会社が読んでも「うちとは前提が違う」と感じてしまうことが少なくありません。
そこで弊社は、自分たちが Claude を業務に組み込んでいく過程をそのまま「AI導入日記」として公開してきました。この記事は、その公開済み7本を1本の流れとして読めるようにまとめた総集編です。他社の事例ではなく、社員数名の自社で実際にやった記録です。
1. この記事の位置づけ──社員数名の自社でやった記録の総集編
まず、素材にしている日記7本を一覧にしておきます。各回の詳細は、それぞれの記事で読めます。
| 回 | 公開日 | テーマ | 対応するフェーズ |
|---|---|---|---|
| #1 | 2026年7月27日 | 法人導入の初日にやったこと | 準備期 |
| #2 | 2026年7月28日 | プラン選び（個人契約と法人契約） | 準備期 |
| #3 | 2026年7月29日 | 情シスがいない会社のセキュリティ確認 | 準備期 |
| #4 | 2026年7月30日 | CLAUDE.md に社内ルールを書いた | 整備期 |
| #5 | 2026年7月31日 | コーポレートサイトの更新を内製化 | 整備期 |
| #6 | 2026年8月1日 | 非エンジニア社員の研修初日 | 展開期 |
| #7 | 2026年8月2日 | 見積書・請求書のチェック | 展開期 |
※各回の日付は公開日です。出来事が起きた時期とは一致しません。
※「90日」は、初日に自分たちで引いたロードマップの区切りです。この総集編は、そのロードマップの各段階に公開済みの日記を対応させて並べ直したものであり、「90日でここまで到達できます」という成果の保証ではありません。日記の連載は継続中です。
1-1. この記事に書いていないこと
先にお断りしておきます。この記事には、作業時間が何％削減された、といった効果指標を載せていません。日記の第7回でも同じ方針を書いています。「導入初期の数字は条件次第でいくらでも大きく見せられます。社内でそれをやると、後で辻褄が合わなくなったときに信用を失います」という理由からです。初日の記録でも「稟議で盛った数字を出すと、後で説明に困ることになります」と書きました。
ですので、ここに出てくる数字は「実際に何時間かけたか」「何項目のチェックリストを作ったか」といった、事実として数えられるものだけです。
2. フェーズ1：準備期（0〜30日）──使う前に決めたこと
初日に引いたロードマップでは、最初の30日は「推進役が毎日使う／失敗を記録する」期間としました。この段階でやったのは、実は使うことよりも「決めること」のほうが多かったというのが正直なところです。
2-1. 初日は実作業3時間・会議0回（日記#1）
初日にかけた時間は、合計で3時間ほど。会議は1回もしていません。何かを導入するとき、最初に会議で方針を固めたくなりますが、触る前に議論しても決めようがないというのが実感でした。
最初の対象業務には自社コーポレートサイトの更新を選びました。選定の基準として書いたのは3つです。
- 毎週必ず発生する
- 失敗しても取り返しがつく
- 自分が正しさを判断できる
この3つが揃っている業務は、探してみると社内に見つかることが多いはずです。逆に、この3つのどれかが欠けている業務から始めると、成果が測れないか、事故が起きたときに戻せません。
初日につまずいたのは次の3か所でした。①指示が短すぎた（「トップページを直しておいて」のように、文脈の補完を相手任せにしていた）②一度に5つの修正を頼んで、3つは意図どおり・2つは方向がずれた ③毎回同じ前提（会社名の表記、文体、色使い）を説明していた。この③が、のちに CLAUDE.md を書く直接のきっかけになります。
そのうえで決めたルールが3つです。
- 入れてはいけない情報を、使う前に決める……顧客個人情報の一覧、NDA対象資料、パスワード・APIキー、未公開の見積金額や原価は入力しない。
- AIの出力はたたき台。責任は人が持つ……数字と固有名詞は原典で確認する。
- やったこと・失敗したことを全部書き残す……日付／やったこと／うまくいったこと／つまずいたこと／次にやること、の5項目を毎日5行だけ書く。
体制は、推進役1人（毎日使い、記録を残す）と決裁者を別に立てる形にしました。推進役が決裁も兼ねると、うまくいっていない状態を認めにくくなるためです。
2-2. 個人契約のままでは会社の資産にならない（日記#2）
導入の初期は個人アカウントで会社の業務を進めていました。その状態で気づいたのが、支払いも設定も履歴も個人に紐づいたままで、会社の資産になっていないということです。
プランを検討するとき、機能の比較表よりも先に、次の3つを自分に問いました。
- この契約は、担当者が辞めても会社に残るか
- 支払いと請求書は、経理が処理できる形になるか
- 使う人と使わない人を、あとから増減できるか
使い方は2つに分けて考えました。ブラウザ上のチャット利用（相談・作文・要約）と、ファイル・コマンドを操作する作業用途です。前者は翌日から使えますが、後者は端末の準備が必要で、対象者も限られます。ここを分けずに「全員に配る」と考えると、話が進まなくなります。
実際、つまずいたのは次の3点でした。①全員分を一度に契約しようとしたこと ②研修だけ安いプランで代用しようとしたこと（環境が違うと学習効果が落ちる）③契約前に、やめるときの手順を確認しなかったこと。とくに③は、決裁者にとって「やめられる」ことが分かるほうが承認しやすい、という意味でも重要でした。
初期配布は「明日から実務で使う人」「用途を説明できる人」に絞りました。稟議に書いたのは3行だけです。「現在は個人契約で業務を行っており、担当者の退職時に業務が止まるリスクがある」「法人契約により、停止・引き継ぎが可能になる」「初月は実務利用者分のみ、利用状況に応じて増減」。
もうひとつ決めたのが、料金とプラン名は社内資料に書き写さず、公式ページのリンクだけを貼るという運用です。プランの改定が速いため、書き写した瞬間から資料が古くなります。プランごとの違いを整理したものはClaude 法人プランの料金比較にまとめていますので、金額の検討はそちらをご覧ください。
2-3. 情シスがいないなりのセキュリティ確認（日記#3）
「セキュリティは大丈夫なのか」と聞かれたとき、答えられる担当者が社内にいない。中小企業ではよくある状態で、弊社もそうでした。そこで、この漠然とした問いを3つに分解しました。
- 入れた情報はどこへ行くのか……提供元の公式ドキュメントで、学習への使用の有無・保存期間・管理者の閲覧範囲を確認する。
- 誰が使えるのか……自社でアカウントを棚卸しする。
- 後から何が起きたか分かるのか……ログをどう扱うか運用を決める。
現場で使える形にするために、入力してよい情報を信号機で分類しました。赤＝個人情報・機密情報は入力しない。黄＝固有名詞や数字を置き換えてから入力する。青＝公開済みの資料やルールの草案はそのまま入力してよい。3色なら覚えられます。
アカウントは、入社時・異動時・退職時の3タイミングに加えて、四半期に一度の突き合わせを行うことにしました。社内規程はA4一枚にまとめ、6項目だけ書いています（使用範囲／入力情報の分類／使用アカウント／出力の扱い／報告先と責めない方針／見直し時期）。
目標も置き換えました。事故をゼロにすることを目的にすると、禁止事項が増え続け、最終的に「使わない」という結論に着地しがちです。掲げたのは「気づける状態・範囲を特定できる状態・止められる状態」を保つことです。ファイル操作を伴う使い方については、「読み取りは自由、書き換えと実行は都度確認」から始め、慣れた作業だけ自動実行に移す段階的な設計にしました。
3. フェーズ2：整備期（31〜60日）──指示を型にする
ロードマップの31〜60日は「指示の定型化／ルール化／少人数で共有」としていました。準備期で分かった課題が、そのままこのフェーズの宿題になります。
3-1. 同じ説明を毎回している、に気づく（日記#4）
導入から数日で、同じ依頼をしても出力にばらつきが出ることが気になり始めました。毎回付け足していたのは「箇条書きで」「敬体で」「会社名は正式名称で」「決まっていない件は決まっていないと書く」といった指示です。入力履歴を見返すと、ほぼ同じ前置きを毎回ゼロから書いていました。
つまり問題は出力側ではなく、社内の暗黙のルールが言語化されていないことでした。そこで、その前置きをファイルに書き出すことにしました。それが CLAUDE.md です。書いたのは4種類の項目です。
- 表記と文体のルール……社名、日付の形式、文体の統一。手戻りの大半はここで消えました。
- やってはいけないことのリスト……推測した数値を書かない、事例を創作しない、未確定の情報を断定形で書かない。
- 成果物の型……議事録なら「日時／参加者／決定事項／未決事項／次アクションと期限」の順で固定。
- 迷ったときの行動指針……判断が止まったら二択・三択で質問する。
書き方のコツは、抽象語を具体に置き換えることでした。「読みやすく」では伝わらないので「一文は60字以内。3文ごとに改行を入れる」と書きます。「必ず確認してから」も「削除・公開・送信の前は確認する。表記修正は不要」と範囲を切ります。
作り方は3ステップです。まず1週間、自分が言い直した内容をメモする（弊社は二十数行たまりました）。次に抽象語を具体化する。最後に1週間運用して、効かなかった行を削る。分量はA4で1枚、多くても2枚程度に収めるのがおすすめです。更新のトリガーも決めました。同じ指摘を2回した時点で、1行足す。これだけです。
なお、パスワード・接続情報・鍵の値・顧客の個人情報は CLAUDE.md に書きません。ルールを書くファイルであって、秘密を置く場所ではないためです。
3-2. コーポレートサイトの更新を内製に戻す（日記#5）
弊社のコーポレートサイトは WordPress で動いています。以前は「サービスページの1行修正」のような小さな変更でも、依頼を書く・相手の手が空くのを待つ・確認する、という往復が挟まり、数日かかっていました。
これを Claude Code で内製に戻しました。手順は6ステップに固定しています。
- 依頼を1行で書く（目的と対象を明確にする）
- 現状のページを読ませる
- 変更案を先に出させる
- 差分を確認する
- 反映を指示する
- 実際の画面で見る
簡単な文言修正なら数分、というのが当社の体感です。ただし速さより大事なのは、本番に出す前の3つのゲートを通すことでした。「差分を人が読んだか」「戻せる状態か」「確認する人が決まっているか」。この3つが欠けると、速さがそのまま事故の速さになります。
失敗も4件記録しています。①お手本になるHTMLを渡さずにレイアウトが崩れた ②構造まで意図せず変更された（「構造は変えないでください」と明示すべきだった）③タイムゾーンを書かずに公開日時がずれた（JSTと明記する）④誰も差分を確認していない状態が生まれた。いずれも指示の書き方と運用で防げるものでした。
これから始める会社向けに、2週間のならし方も書いています。1週目は読ませるだけにして、バックアップ体制の確認と「触らせない範囲」の決定に充てる。2週目に影響の小さい1ページを実際に更新する。この順番を飛ばすと、最初の失敗が本番で起きます。
4. フェーズ3：展開期（61〜90日）──人と業務を増やす
ロードマップの61〜90日は「対象業務の追加／研修の実施／費用対効果の整理」としていました。推進役1人が使える状態から、他の社員と他の業務へ広げる段階です。
4-1. 非エンジニア社員の研修初日（日記#6）
対象は営業・制作・事務の担当者で、コマンド操作の経験はありません。研修時間は90分。内訳は説明20分、演習60分、ふりかえり10分です。
当日の朝、用意していた30枚ほどの研修資料を捨てました。設計の重心を「何を教えるか」から「何を教えないか」に移したためです。初日のゴールは1つだけにしました。「自分の仕事に関係する成果物をひとつ作り、それを自分の言葉で説明できる状態で帰る」。
演習は3つです。①自分が過去に書いた提案書や報告書を読み込ませて要約する ②お詫びの一文を3通りに書き分ける ③自分の作業手順を口述して手順書にまとめる。いずれも「自分の仕事の材料」を使う点が共通しています。他人のサンプルで練習すると、翌日から使う動機が生まれません。
初日によく出るつまずきは7つに整理しています（詰まる場所は、何回まわしてもほぼ同じでした）。多かったのは指示が短すぎるケースで、対処はシンプルです。「誰に向けて」「何文字くらいで」「どんな形式で」の3つを足す。入力してはいけない情報については、A4一枚の資料を事前に配りました。
講師ひとりで見られるのは6〜8人が目安でした。それ以上だと、つまずいた人を拾えません。翌営業日に15分のフォローを入れ、第2回は1週間後に設定しています。研修は1回で終わらせず、間隔を空けて2回目を置くほうが定着します。
4-2. 見積書・請求書のチェック（日記#7）
バックオフィスに広げるきっかけは、社外に出した書類の宛名を間違えたことでした。株式会社が前か後ろか、中黒があるかないか。人が気をつけるだけでは再発が止まらない種類のミスです。
この業務を選んだ理由は、自動化に向く3条件を満たしていたからです。定型であること、反復があること、判断基準を言葉にできること。
ここでも3つつまずきました。①PDFをそのまま渡し、何を確認してほしいかを書かなかったため、体裁の一般論が返ってきた ②毎回違う箇所を指摘されて安定しなかった ③合計金額の検算で誤った判定が返ってきた。
対処はそれぞれ、①テキスト化して渡す前処理を定型にする ②「気づき」ではなく「網羅」を求める形に変え、観点を固定して全項目の結果を返させる ③計算は表計算側で機械的に行い、AIには計算結果と書類の記載が一致しているかの比較だけを頼む、という分離でした。
チェック観点の言語化は4ステップで進めました。過去に差し戻した書類を集める → 「正式名称と一致しているか」のような確認文に変換する → OK／NGの判定基準を書く → 過去の書類で試す。初版は半日ほどで作れています。できあがったのは見積書9項目・請求書8項目のチェックリストです。
そして、任せる範囲を3段階で線引きしました。
| 区分 | 対象 | 考え方 |
|---|---|---|
| 任せる | 記載漏れ・体裁のチェック、見積・発注との突合 | 判断基準が固定でき、結果を人が検証できる |
| 半分任せる | 金額の検算（表計算と記載確認に分離）、宛名・敬称、振込先、制度要件の形式確認 | 工程を分け、間違えやすい部分は機械側に寄せる |
| 任せない | 値引き・特別条件の判断、与信や取引可否、最終承認と社外送付の操作 | 責任の所在が人にある行為は人が行う |
※日記#7に記載した線引きを整理したものです。区分の考え方は業種・取引条件によって変わります。
運用では、一次チェックの指示テンプレートに「判定不能」という選択肢を用意しました。無理に判定させると、それらしい誤答が混ざります。人が見るのは「要確認」と「判定不能」だけです。情報の扱いについては、法人向けの契約形態で、入力が学習に使用されない設定であることを2026年7月時点で確認しています。秘密保持の特約がある案件の情報は伏せる運用です。
想定していなかった副産物もありました。チェック観点を言語化した結果、人間同士の引き継ぎまで楽になったことです。新人への説明や、確認の往復が短くなりました。
5. 90日を通して出たつまずきの一覧
ここまでの7本で記録したつまずきを、一枚にまとめておきます。これから始める会社が最初に踏みやすい場所は、だいたいこの中にあります。
| フェーズ | つまずき | やったこと |
|---|---|---|
| 準備期 | 一度に5つ頼んで2つが方向ずれ | 依頼を分ける。目的と対象を1行で書く |
| 準備期 | 全員分を一度に契約しかけた | 用途を説明できる人から配る。30日後に見直す |
| 準備期 | やめるときの手順を確認していなかった | 契約前に解約手順まで確認してから決裁に出す |
| 整備期 | 毎回同じ前提を説明していた | CLAUDE.md に書き出す。同じ指摘2回で1行追加 |
| 整備期 | レイアウト崩れ・構造の意図しない変更 | お手本HTMLを渡す。「構造は変えない」と明示 |
| 整備期 | 確認が形骸化し、誰も差分を見ていない | 確認者を決める。3つのゲートを通す |
| 展開期 | 研修で指示が短すぎて成果物にならない | 「誰に・何文字で・どんな形式で」を足す |
| 展開期 | 金額の検算で誤った判定が返る | 計算は表計算、AIは記載の一致確認だけに分離 |
6. 同じことを社員数名の会社でやるなら
最後に、7本を振り返って「順番として効いた」と感じている点を整理します。
6-1. 順番を変えないほうがよい3点
① 入れてはいけない情報を、使う前に決める。 初日にやったのはこれでした。あとから決めると、すでに入力してしまった情報の扱いを判断できません。A4一枚で足ります。
② 推進役1人が毎日使う期間を先に置く。 全員に配ってから考えると、使わない人のアカウントが増えるだけで、成功例も失敗例も溜まりません。研修（#6）が成立したのは、先に推進役が自分でつまずく場所を経験していたからです。
③ 型（CLAUDE.md）を作ってから人を増やす。 表記や文体の指摘は、人が増えるほど回数が増えます。増える前に型にしておくほうが、結果的に早く進みます。
6-2. 効果を数値で語らない代わりに残しているもの
削減率を出さない代わりに残しているのが、初日に決めた毎日5行の記録です。日付／やったこと／うまくいったこと／つまずいたこと／次にやること。これが溜まると、社内で説明するときに「印象」ではなく「経緯」で話せます。日記7本も、元はこの5行の積み重ねです。
費用対効果の整理はロードマップの61〜90日に置いていますが、弊社が次にやろうとしているのは「チェック結果の記録を月次でまとめ、どの観点で引っかかりやすいかを可視化する」ことです。ミスが出にくい書式に変えるほうが、任せる範囲を広げるより効くと考えているためです。
6-3. 費用と補助金の扱いについて
費用面については、プランごとの違いをClaude 法人プランの料金比較に、補助金・助成金の考え方をClaude導入で使える補助金・助成金にまとめています。制度の要件や採択の可否は個別事情によりますので、詳細は各制度の公募要領と、必要に応じて専門家にご確認ください。
導入の手順そのものを段取りとして知りたい方はClaude 法人導入の手順を、支援会社を比較検討している段階の方はClaude 導入支援会社の選び方をあわせてご覧ください。
よくある質問（FAQ）
社員数名の会社でも、90日で同じところまで進められますか？
90日という区切りは、弊社が初日に自分たちで引いたロードマップの単位です。同じ期間で同じ状態になることをお約束するものではありません。進み方は、対象業務の性質、推進役が使える時間、既存の書式が整理されているかによって変わります。この記事は「こう進めた」という記録としてお読みください。
最初に着手する業務は、どう選べばよいですか？
弊社が日記#1で書いた基準は3つです。毎週必ず発生する、失敗しても取り返しがつく、自分が正しさを判断できる。この3つを満たす業務から始めると、成果も失敗も測れます。バックオフィス業務を選ぶ場合は、日記#7の「定型であること・反復があること・判断基準を言葉にできること」も参考にしてください。
情報システムの担当者がいなくても、セキュリティ確認はできますか？
弊社も専任者がいない状態から始めました。日記#3では、「入れた情報はどこへ行くのか」「誰が使えるのか」「後から何が起きたか分かるのか」の3つに分解し、公式ドキュメントの確認・アカウントの棚卸し・ログの扱いの決定に対応させています。社内向けにはA4一枚・6項目の約束ごとにまとめました。自社の業種や取引条件によって必要な要件は変わるため、契約前に公式情報をご確認ください。
研修は何人まで一度にできますか？
日記#6の記録では、講師ひとりで見られるのは6〜8人が目安でした。演習中につまずいた人を拾えるかどうかが基準です。研修は90分（説明20分・演習60分・ふりかえり10分）で構成し、翌営業日に15分のフォロー、1週間後に第2回を置いています。
導入効果を数値で示していないのはなぜですか？
日記#7に書いたとおり、導入初期の数字は条件次第で大きく見せられてしまい、社内で辻褄が合わなくなると信用を失うためです。代わりに、実作業にかけた時間やチェック項目数など、事実として数えられるものだけを記録しています。稟議の資料をお作りになる際も、盛った数字より経緯のほうが後から説明しやすいと考えています。
✏️ 山崎 将史より
この日記を書き始めたのは、AI導入の事例として世に出ているものが、どうしても自分たちの規模とかけ離れて見えたからです。数百人規模の会社が専任チームを組んで進めた話は参考にはなりますが、社員数名の会社にとっては「その体制がない」という一点で使えません。それなら、自分たちの記録をそのまま出したほうが役に立つのではないかと考えました。
書いてみて分かったのは、うまくいった話よりつまずいた話のほうが読まれるということです。初日に一度に5つ頼んで2つ外した話や、金額の検算で誤った判定が返ってきた話は、規模の近い会社なら同じように起きるつまずきだと思います。導入がうまくいかない理由は、たいてい特殊な事情ではなく、順番の問題です。
順番として効いたのは、入れてはいけない情報を先に決めたこと、推進役1人が毎日使う期間を先に置いたこと、型を作ってから人を増やしたこと。この3つでした。逆に、うまくいかなかったのは全部「先に広げようとした」ときです。全員分を一度に契約しかけたときも、研修を安く済ませようとしたときも、根っこは同じでした。
弊社では初回のご相談を無料・オンラインで承っています（全国対応・所要60分）。「うちの業務なら何から始めるか」「社内にどう説明するか」といった具体的なご相談で構いません。この日記に書いた失敗も、包み隠さずお話しします。まずは現状をお聞かせください。
