FDEによるAI導入は、最初に1つの業務を選び、現状を測り、小さく試し、現場が使えるか確認する順で進めます。本記事では、中小企業が支援会社と会話するための90日間の進め方、役割分担、受入テスト、引き継ぎのチェックシートを紹介します。
執筆：86研究所｜2026年9月29日。以下は当社が整理した進行例です。90日での完成や成果を保証するものではありません。86研究所のFDE伴走支援は基本6ヶ月契約で、この例は前半の検討・実装を具体化するためのものです。
最初に決めるのは「AIツール」より「対象業務と担当者」
「社内でAIを活用する」だけでは、何ができれば成功か判断できません。「問い合わせ内容を台帳へ転記し、担当者へ知らせる」「領収書から入力候補を作り、人が確認する」といった作業単位まで分けます。
FDEは現場の課題整理と実装をつなぐ役割です。経営者は優先順位と予算、現場担当者は業務ルールと確認、FDEは実装方法と改善の提案を担う、と分担しておくと進めやすくなります。詳しい定義はFDEとは？仕事内容と他の支援との違いをご覧ください。
30日・60日・90日で確認するもの
| 期間の目安 | 取り組むこと | 残すもの | 次に進む条件 |
|---|---|---|---|
| 1〜30日 | 業務を観察し、件数・時間・例外を計測。データと権限を確認 | 業務フロー、対象範囲、現状値、役割表 | 誰が何を確認するか合意できている |
| 31〜60日 | 限定したデータで試作。正しい入力と例外の両方をテスト | 試作品、テスト結果、修正履歴、費用の見込み | 合意した品質・費用条件を満たし、停止方法がある |
| 61〜90日 | 少人数で実運用。確認時間・修正率・利用状況を計測 | 運用手順、実測値、改善リスト、引き継ぎ計画 | 継続・範囲変更・停止を実測値で判断できる |
データが整理されていない場合や、外部システムとの連携に時間がかかる場合は、期間を延ばすか対象を小さくします。日付に合わせて自動化を広げるよりも、判断条件を満たしてから進む設計です。
1〜30日：業務棚卸しで失敗しにくい対象を選ぶ
候補ごとに「月の件数」「1件の時間」「入力元」「出力先」「例外」「最終確認者」を書き出します。最初の対象には、件数があり、入力形式が比較的そろい、間違いを人が確認できる業務を選びます。
- 始めやすい候補：議事録の下書き、問い合わせの分類候補、社内文書の検索、入力内容の照合補助。
- 先に設計が必要な候補：顧客への自動送信、請求金額の確定、データ削除など、誤処理の影響が大きい工程。
- 急がないほうがよい候補：処理件数が少ない、現行ルールが担当者ごとに違う、正解を判断できる人がいない業務。
たとえば、問い合わせ台帳を作る前に、担当部署が未定の依頼や同じ顧客からの重複連絡をどう扱うか決めます。「例外は後から考える」と、現場の確認負担が増えがちです。
31〜60日：実装前に受入テストを作る
試作品が動いたことと、業務で使えることは別です。いつもの入力に加え、欠損・重複・権限不足・通信失敗を試します。下表は、問い合わせを台帳に記録する仕組みのテスト例です。
| 入力・状況 | 期待する動作 | 確認方法 |
|---|---|---|
| 必要項目がそろう | 正しい行・列へ1件記録し、担当者へ通知 | 原文と台帳の項目を照合 |
| 電話番号などが欠ける | 推測で埋めず、要確認として扱う | 空欄と確認フラグを確認 |
| 同じ依頼が2回来る | 二重登録を防ぐか、重複候補として表示 | 再実行して件数を照合 |
| 閲覧権限がない | 権限を越えて内容を表示しない | 権限の異なるテスト利用者で確認 |
| 外部ツールが停止する | 失敗を記録し、担当者が再処理できる | エラー表示・通知・再処理結果を確認 |
| AIの分類が誤る | 人が修正でき、修正結果を追跡できる | 変更前後と更新者を記録 |
合格条件は業務に合わせて決めます。まず試す件数、許容する誤り、必ず人が確認する項目、停止する条件を文書化してください。少数のテストで問題がなくても、すべての入力で安全に動くことの証明にはなりません。
61〜90日：利用率と確認時間まで測る
現場への展開は少人数から始め、操作方法だけでなく「いつ使わないか」「困ったら誰へ連絡するか」も共有します。次の4つを定例会で確認すると、改善の優先順位を決めやすくなります。
- 利用率：対象件数のうち実際に仕組みを使った件数。使われない理由も聞く。
- 正味の作業時間：AI処理後の確認・修正・例外対応を含めて比較する。
- 品質：入力漏れ、誤分類、二重登録、再作業の件数を記録する。
- 費用：AI利用料と運用担当時間が当初の想定を超えていないか確認する。
「生成が速い」というツールの性能と、「仕事が早く終わる」という業務効果を分けて評価します。費用面の計算はFDEの費用と費用対効果の記入シートを利用できます。
86研究所の公開例：レシートから経費シートへ
86研究所では、DriveやSlackに送ったレシート画像から情報を読み取り、月別のスプレッドシートへ記録する仕組みを公開しています。見どころは、AIに読み取らせる部分だけでなく、合計行との位置関係や、読み取れない画像を「要確認」に回す処理です。
これはレシート入力の自動化を紹介した当社の公開記事に基づく実装例です。本記事では顧客案件数や削減率としては扱いません。会計処理の確定や税区分の判断をAI任せにせず、担当者が確認する運用を設計してください。
支援会社と共有できる1ページの依頼シート
目的：何のために改善するか 対象：どの作業からどの作業までか 対象外：今回行わないこと 入力：形式・保存場所・利用権限 出力：記録先・通知先・人の承認 現状：月の件数・時間・ミス件数 合格条件：正確さ・費用・処理時間 例外：欠損・重複・失敗時の扱い 担当：意思決定者・現場確認者・実装者 運用：問い合わせ先・停止方法・復旧方法 成果物：設定・ソース・手順書・テスト結果 判断日：継続・変更・停止を決める日
最初から完璧に埋める必要はありません。空欄を支援会社と一緒に確認し、合意できたところから進めるためのシートです。
引き継ぎで残しておきたい5点
- 構成図：どのデータがどのサービスを通るか。
- 権限と契約：アカウントの管理者、利用料の負担者、更新日。
- 操作と例外：通常手順、要確認時の対応、停止・復旧手順。
- 変更履歴：何を直し、どのテストを行ったか。
- 改善指標：導入前の数字と、導入後に継続計測する数字。
特定の人しか動かせない状態を減らすため、利用者と管理者の両方が手順を試す時間を設けます。外部支援を継続する場合も、責任範囲を曖昧にしないことが重要です。
よくある質問
社内にエンジニアがいなくても始められますか？
技術担当がいなくても相談できます。ただし、業務ルールを判断する現場担当者と、優先順位を決める責任者は必要です。外部のFDEと社内担当者が役割を分けて進めます。
90日で全部門に導入できますか？
本記事は1つの対象業務から始める例です。部門数、データの状態、連携先によって期間は変わります。全社展開は小さな運用の結果を見て判断します。
検証で効果が小さかったら失敗ですか？
効果が小さいとわかった時点で対象や方式を変えることも、検証の役割です。続けるためだけの評価をせず、停止も含めた判断条件を最初に決めます。
FDEに任せる業務を一緒に整理する
86研究所では、業務整理・実装・現場定着までを支援します。SNSやWebから入る問い合わせと、その後の社内対応もまとめて検討できます。
本記事の進行表・受入チェック・依頼シートは86研究所が整理した検討用の例です。一般的なFDEの背景は、AWSによるForward Deployed Engineeringの解説も参照できます。