― AI 研修だけでは業務は変わらない。中小企業が四半期で「業務に埋め込まれた AI」に到達するための 30/60/90 日フレームと、3 つの典型的な失敗パターン。
§ 01 / なぜ「90 日」か
中小企業の AI 導入を見ていると、ある共通パターンに気づく。経営判断の単位は 四半期 であり、それを越える時間軸の投資は議題に乗りにくい。「半年後の効果」「1 年後のロードマップ」は、実務的には意思決定されない。
逆に 90 日以内に何らかの実利が見える プロジェクトは、経営層が継続判断しやすい。30 日で討議、60 日で検証、90 日で社内発表 ─ この時間軸は、四半期決算と組織内の動員リズムに乗る。
本記事は、関西の食品メーカー C 社 (従業員 180 名) を疑似ケースとして、業務 AI 化の最初の 90 日に何を組み立てるべきかを、フェーズ別に示す。
§ 02 / 2026 年時点の「業務 AI 化」の現在地
3 年前まで、業務 AI 化は「機械学習エンジニアを採用してモデルを作る」ことを意味していた。2026 年現在、その前提は完全に崩れている。
理由は 3 つある:
- 基盤モデル (Claude / GPT / Gemini) の汎用性が、独自モデル開発の必要性を消した。多くの業務 (文書要約・分類・草案作成・コード補助) は API で即座に解決する。
- Tool Use / MCP (Model Context Protocol) の成熟で、AI が業務システムを直接操作できるようになった。Slack・Notion・スプレッドシート・社内 DB との連携が、コード 100 行で書ける。
- コストが急速に下がった。Claude Haiku 4.5 の 1M トークン処理が約 ¥150。月 1,000 業務をこなしても月額数千円〜数万円のオーダーで動く。
つまり、業務 AI 化は 「技術の問題」から「設計の問題」 に移行した。何を AI に任せ、何を人に残し、どんな運用で品質を保つか ─ これが経営判断の本筋になる。
§ 03 / Day 0-30 ─ Discovery (業務棚卸 + 適用領域抽出)
最初の 30 日は 「業務を AI に置き換える」ことを禁止 する。やるのは、業務の棚卸しと適用領域の抽出だけである。
C 社の場合、以下の手順で進めた:
Week 1: 主要業務のリスト化 ─ 部門長 4 名へのヒアリングで、業務カテゴリを 38 項目抽出。「見積もり作成」「顧客問い合わせ対応」「製造ログのレポート化」「在庫発注計算」など。
Week 2: 各業務の作業時間 / 頻度 / 担当者数を計測 ─ 業務カードを作り、月間時間消費を見える化。最も時間がかかっていたのは「見積もり作成 ─ 月 130 時間 (担当者 1 人 6 時間/日 × 22 日)」だった。
Week 3: AI 適用可能性のスクリーニング ─ 当社が独自に持つ 6 つの判定軸で評価:
- 入出力がテキスト/構造化データ中心か (vs 物理作業)
- 判断基準が言語化できるか (vs 暗黙知)
- 失敗時のリカバリが容易か (vs 不可逆)
- 業務量が一定以上か (月 10 時間以上)
- 機密性・規制要件をクリアできるか
- 業務オーナーが存在するか (推進力)
38 業務のうち 9 業務が「90 日以内に PoC 可能」 と判定された。
Week 4: 経営層への中間報告 + 1 つに絞り込み ─ 9 業務のうち、最もインパクトが大きく失敗時の影響が小さい「見積もり作成業務」を最初の PoC として選定した。
この段階の重要なポイント: 30 日かけても 動くものは何もできない。経営層は不安になる。しかし、この棚卸し作業を飛ばして「とりあえず ChatGPT を導入」とすると、必ず Day 60 で停滞する。「AI 適用は業務の選定が 90% を決める」 ─ これが経験則である。
§ 04 / Day 31-60 ─ PoC (1 業務に絞って検証)
61 日目までに 1 つの業務だけ を、本番に近い形で動かす。これも経験則: 同時に複数の PoC を回すと、どれも中途半端で終わる。
C 社の「見積もり作成」PoC の構成:
システム構成:
- LLM: Claude Sonnet 4.6 (品質と速度のバランス、複雑な見積もり計算に十分)
- 入力: 顧客からの問い合わせメール (テキスト) + 社内の商品マスタ (CSV)
- 出力: 見積もり Excel + 顧客向けメール文面
- 連携: 営業担当の Gmail と Notion (Tool Use 経由)
運用フロー:
- 顧客メール受信 → AI が見積もり草案を生成 (3 分以内)
- 営業担当がレビュー → 必要に応じて修正 (平均 5 分)
- 承認 → 顧客に送信
- すべてのやり取りを Notion にログ
最初の 14 日: AI 出力の精度が 65% (修正なしでそのまま送れる確率)。失敗パターンを 1 件ずつ分析し、プロンプトを改善。
Day 45 時点: 精度 88%。平均処理時間は 6 時間/日 → 30 分/日 に短縮。
Day 60 時点: 精度 94%。営業担当からは「以前は午前中ずっと見積もりに取られていたが、午後を顧客対応に使えるようになった」とのフィードバック。
経営層への報告書のキーポイント:
- 再現性のある節約時間 (月 110 時間 = 担当者の業務時間の 65% 解放)
- 品質はむしろ向上 (テンプレ品質のばらつきが消えた)
- AI 利用コスト: 月額約 ¥18,000 (Claude API 利用料 + 連携ツール)
- 削減した人件費換算: 月 33 万円
ROI が見えれば、Day 60 で経営層は「次の業務に拡張する」を合意できる。
§ 05 / Day 61-90 ─ Scaling + Handover (定着 + 内製化)
最後の 30 日は 「AI を社員のものにする」 フェーズ。当社がフェードアウトする準備期間でもある。
C 社の場合、以下の 3 つを並行で進めた:
(1) 横展開: 見積もり業務で構築したプロンプトと運用パターンを、隣接業務 (顧客問い合わせ対応 / 製造ログのレポート化) に拡張。1 業務目に 30 日かかったが、2 業務目は 8 日、3 業務目は 4 日 で本番化した。これが「業務 AI 化が指数的に加速する」と言われる構造である。
(2) 内製化研修: 社内エンジニア 2 名 + 業務担当 3 名に 2 週間の集中講座 を実施。内容は:
- プロンプト設計の実務 (業務別パターン 12 種)
- API / SDK の使い方 (Claude API + Tool Use + MCP)
- 評価指標の設計 (出力品質をどう測るか)
- 運用ドキュメントの書き方
(3) 運用 Runbook 化: トラブル発生時の対応手順、コスト監視、モデル切り替えの判断基準を文書化。社内 Notion に置き、当社が抜けても継続できる体制に。
Day 90 時点の到達状態:
- 業務 3 つが AI 化済み、運用安定
- 社内エンジニア 2 名が新規業務の AI 化を自走できる
- 月額の AI 利用コスト: ¥45,000、削減人件費換算 月 95 万円
- 経営層が四半期会議で「次の 90 日」を決められる材料が揃う
§ 06 / 3 つの典型的失敗パターン
業務 AI 化の現場で繰り返し観察される失敗を、3 つに分類する。
(1) 全社員一斉に ChatGPT を配る
「とりあえず全員にライセンスを配って、各自で使い方を見つけてもらおう」 ─ これが最も多い失敗である。3 ヶ月後の社員アンケートで「実務で使っている」と答える比率は、ほぼ例外なく 15% 以下。活用しない 85% を見て経営層は「効果が薄い」と判断し、契約を解約する。
根本原因: AI は 「個人の生産性向上ツール」と「業務システムへの埋め込み」 で求められる設計が全く違う。前者は個人スキル次第で当たり外れが大きい。後者は組織として運用設計しないと立ち上がらない。多くの企業は前者を導入して、後者の効果を期待している。
対策: 全社一斉配布よりも、1 業務に絞った PoC から始める。
(2) AI に「業務全体」を任せようとする
「営業活動を AI に任せて、人間は戦略に集中する」 ─ こうした目標設定は美しいが、現実には失敗する。AI は 業務の中の特定タスク には強いが、業務全体の判断と責任 はまだ人間の領域である。
根本原因: 業務は「タスクの集合」ではなく、「判断・関係性・責任」を含む生態系である。AI でタスク単位を効率化しても、全体を引き受けることはできない (少なくとも 2026 年現在は)。
対策: 業務を 「AI が下書きする」+「人がレビュー・確定する」 の役割分担に分解する。当社の社内標準もこの設計である。
(3) 研修だけで終わる
「AI 研修を実施しました。それで終わり」 ─ 研修後に業務適用がされない、最も静かな失敗パターン。研修参加者にアンケートを取ると満足度は高いが、3 ヶ月後の社内利用状況は研修前と変わらない。
根本原因: 研修は「知識のインプット」、業務適用は「組織の運用設計」、別の問題である。研修と運用設計を別ベンダーに頼むと、両者の間で必ず落ちる。
対策: 研修と内製化伴走を 同じチームで一気通貫 で実施する。これが当社の AI 事業の中心的な設計思想でもある。
§ 07 / Tool Selection ─ Claude / GPT / Gemini の使い分け
2026 年現在、業務 AI 化で主に使われる 3 つの基盤モデルを、当社の運用経験から比較する。
| モデル | 強み | 弱み | 主な用途 |
|---|---|---|---|
| Claude (Anthropic) | 長文の精読・整合性のある推論・指示遵守 | 画像入力の細部認識 | 文書要約、見積もり、契約書草案、コード補助 |
| GPT (OpenAI) | 汎用性・速度・周辺エコシステム | 長文での一貫性が崩れることがある | 短文タスク、画像生成、音声処理 |
| Gemini (Google) | Google Workspace 連携、画像認識 | 日本語の細かいニュアンス | Google 環境の業務、画像理解タスク |
当社の標準スタックは Claude Sonnet 4.6 を主力 に、画像理解タスクで Gemini、軽量タスクで Haiku を組み合わせる構成。月コストの 70% は Claude API、残りで他モデルを使い分け。
学び: モデル選定は「最高性能」より 「業務との相性」 で決める。1 つの基盤モデルに固定せず、業務単位で最適なモデルを当てる設計が、コストと品質の両立に効く。
§ 08 / Closing ─ AI は思考のレバー、業務の代替ではない
最後にひとつ、誤解を解いておきたい。
業務 AI 化は 「人を減らすため」 ではない。「人の思考の時間を、価値の高い判断に集中させるため」 である。
C 社の見積もり業務で AI 化した結果、営業担当 1 人の業務時間 6 時間が解放された。その時間は人員削減ではなく、「顧客との対話」「新規提案」「業界動向の把握」 に再配分された。3 ヶ月後の新規受注数は 22% 増えていた。
AI は、業務を奪う技術ではない。業務の中の「機械でもできる作業」を機械に戻し、人を人の仕事に戻す 技術である。
90 日のロードマップは、その第一歩を踏み出すための時間枠に過ぎない。次の 90 日、そのまた次の 90 日 ─ 業務 AI 化は一過性のプロジェクトではなく、継続的な再設計の連続である。経営者にとって、それを始めるか否かの判断が、今期のどこかで必要になる。
本記事の数値は実在の運用案件を匿名化・抽象化した集約値で、複数案件の傾向を代表する例示として記述しています。個別案件の数値は背景条件 (業界・地域・既存業務基盤) によって変動します。
関連サービス: AI 事業 (研修・内製化) / IT 受託開発