AI導入は開発から考えない|最安・最短で課題を解く4段階アプローチ

この記事でわかること
- 検討順序を「既存ツールの未使用機能→汎用AIの運用→ノーコード連携→カスタム開発」の4段階に固定し、段階を飛ばさずに進めます
- 各段階に完了条件(ここで解決した)と打ち切り条件(ここでは解決できない)を先に決め、誰が何を確認したら次へ進むかを明文化します
- 段階の比較は、月額ライセンス・初期構築・教育定着工数・セキュリティ審査・保守改修の5費目を足し合わせた年間総額で行います
- 安価な段階を見送るときは、データ量・セキュリティ要件・業務の属人性・運用担当の有無・更新頻度の5観点で理由を残します
- 形式的な第1段階、運用担当が不在のノーコード、PoC止まりの3つが、この進め方が崩れる典型的な形です
目次
「この業務をAIで何とかしたい」と対象が決まった時点で、開発会社へ見積もりを依頼するのは早すぎます。すでに毎月払っているライセンスに使われていない機能が眠っていたり、汎用AIの使い方を変えるだけで片づいたりする課題が、実際に混ざっているからです。
結論
AI導入の解決策は、手元にある手段から順に検討します。既存ツールの未使用機能 → 汎用AIの運用 → ノーコード連携 → カスタム開発の4段階を固定し、前の段階を「ここでは解決できない」と条件付きで打ち切ったときだけ次へ進みます。
この順序にする根拠は、段階が後になるほど初期構築費と保守負担が増え、いったん進むと前へ戻りにくくなる点にあります。当社が提案時に用いている原則では、開発投資の対象は、前の3段階を打ち切り条件付きで通過した課題に限ります。安価な段階を見送った経緯が検討記録として残るため、経営層にも現場にも根拠を示したうえで投資判断へ進めます。
なぜ開発から考えないのか
この進め方は、課題が1業務単位まで特定されていることを前提にします。「営業を効率化したい」という粒度では、どの段階でも解決できたかどうかを判定できません。「毎週金曜に3時間かけている案件報告書の作成」まで絞られていれば、第1段階から判定を始められます。
開発から入ると、費用・期間・運用の3方向で負担が同時に立ち上がります。
最初に効くのは費用です。要件定義から実装までの初期構築費が発生し、その課題1件に年間の投資枠の多くを充てることになります。中小企業庁「2025年版 中小企業白書」は、設備投資額に占めるソフトウェア投資比率が中小企業では大企業と比べて低い水準で推移していると整理しています(2025年版 中小企業白書 第4節 労働生産性・設備投資)。枠が限られていれば、1件目に充てた金額がそのまま2件目以降の余地を削ります。
期間の負担は、待ち時間として現れます。要件を固めて開発の完了を待つあいだ、現場は元の手作業を続けます。既存ツールの設定変更で工程の一部が片づく課題なら、その分の効果を待ち時間のぶんだけ取り逃がします。
運用の負担が見えるのは稼働後です。作ったものには保守と改修の責任が付き、業務ルールが変わるたびに費用と工数が発生します。既存のSaaSに同等機能が含まれていた場合は、機能が重複したまま両方の料金を払い続ける状態も残ります。
導入前の懸念がどこにあるかも、順序の判断材料になります。総務省「令和7年版 情報通信白書」は、日本企業が生成AI導入で挙げる懸念事項として「効果的な活用方法がわからない」が最も多く、次いで社内情報の漏えい等のセキュリティリスク、ランニングコスト、初期コストが続くと整理しています(令和7年版 情報通信白書 企業におけるAI利用の現状)。活用方法が定まらないうちに初期コストの大きい段階から着手すると、効果を確かめる作業と、すでに確定した支出の回収が同時に走ります。先に安い段階で確かめておけば、支出が確定するのは効果の見通しが立ったあとです。
4段階アプローチの全体像
4つの段階は、投じるコストと後戻りのしにくさが小さい順に並んでいます。2つの軸が同じ向きに増えるため、安い順に試すことが、やり直しの効く順に試すことと一致します。各段階には「この段階で解決した」と言える完了条件と、「この段階では解決できない」と言える打ち切り条件を対で置きます。
| 段階 | 検討する手段 | 解決できる課題の性質 | 完了条件(止まる) | 主に増える費目 |
|---|---|---|---|---|
| 第1段階 | 契約済みSaaS・Office/Google環境の未使用機能 | 機能はあるが知られていない、設定されていない | 現場が実業務で1回通して使え、追加契約が不要 | 教育・定着工数のみ |
| 第2段階 | 汎用AIを業務手順に組み込む運用 | 判断や文章生成が絡み、入力材料が都度そろう | 担当者が手順書どおりに再現でき、品質が承認者の基準を満たす | 月額ライセンス、教育・定着工数 |
| 第3段階 | ノーコードによるツール間連携・自動化 | 発生タイミングとデータの形が定型で、繰り返し回数が多い | 連携が本番データで1か月安定稼働し、運用担当が決まっている | 月額ライセンス、初期構築、保守 |
| 第4段階 | カスタム開発 | 業務固有のロジックが深く、扱うデータ量や権限要件が既製品の範囲を超える | 要件が凍結でき、保守予算と受け入れ担当が確保できている | 初期構築、セキュリティ審査、保守・改修 |
第1段階:契約済みツールの未使用機能を洗い出す
すでに払っている料金に含まれる機能から確認します。追加費用が発生せず、見込みが外れても損失が確認と教育の工数に収まるためです。確認は次の5手順で進めます。
- 経理の支払データから、直近12か月に支払ったSaaS・グループウェア・業務システムの契約一覧を作ります。手を動かすのはDX推進担当、確認先は経理です。
- 各サービスの管理画面とプラン比較表で、契約中プランに含まれる機能を一覧化します。上位プランで追加される機能も、金額とあわせて併記します。
- 対象業務の担当者に、実際に使っている機能と、手作業やExcelで代替している箇所を聞き取ります。契約上使える機能と現場の利用実態の差が、この段階で探す範囲です。
- 特定済みの課題と、2で洗い出した未使用機能を突き合わせます。完全一致でなくても、工程の一部を置き換えられるものは候補に残します。
- 候補の機能を、現場担当者が実データで1回通して試します。所要は30分程度を目安にし、詰まった箇所をメモに残します。
Microsoft 365やGoogle Workspaceのように、契約中のプランへAI機能や自動化機能が含まれている場合は、この段階で片づく課題が出てきます。含まれる範囲はプランと契約時期で変わります。自社の管理画面で実際の状態を確認してください。
完了条件は、現場担当者が実業務で1回通して使えたことを、その業務の承認者が確認できた状態です。追加契約も新しい運用ルールも要らないため、ここで止まればコストは教育工数だけで済みます。
次のいずれかをDX推進担当が根拠つきで確認できたときに、打ち切り条件を満たします。
- 契約中プランにも上位プランにも、該当する機能が存在しない
- 機能はあるが、必要なデータ形式や権限設定に対応しておらず、業務要件を満たせない
- 使えるが、手作業より工程が増える、または現場が実データで再現できない
第2段階:汎用AIの運用で解決できるか試す
ChatGPT・Claude・Geminiなどの汎用AIを、新しいシステムとしてではなく既存の業務手順の一工程として組み込みます。この段階で作るのはシステムではなく、入力材料と出力の判定基準を書いた手順書です。
進め方は3つの作業に分かれます。対象業務の入力材料(元データ、参照する社内資料、前提条件)を洗い出すこと、出力の合格基準を承認者と決めること、担当者2〜3名が同じ手順で1〜2週間試すことです。担当者ごとに品質がばらつくときは、手順書のどこが曖昧かを示す手がかりとして扱います。
この段階の完了条件は、担当者が手順書どおりに操作して、承認者の合格基準を満たす出力を繰り返し得られる状態です。誰か1人だけができる状態は含めません。属人化したまま次へ進むと、その担当者が抜けた時点で運用が止まるためです。
打ち切り条件は4つあります。
- 手作業でのコピー&ペーストや転記が多く、AIを使う工程より前後の作業時間のほうが長い
- 発生頻度が高く、毎回人が起動する運用では回数に追いつかない
- 入力するデータに、社内ルール上その汎用AIへ投入できない情報が含まれる
- 出力の合格率が上がらず、手順書を2回改訂しても承認者の基準に届かない
第3段階:ノーコード連携で自動化する
第2段階の打ち切り理由が「人が毎回起動する運用では回数に追いつかない」「前後の転記作業が長い」であれば、ノーコードツールでツール間をつなぐ検討に移ります。この段階が向くのは、発生タイミングが決まっていて、扱うデータの形が毎回同じ課題です。
逆に苦手なのは、例外処理が多い業務や、担当者が状況に応じて判断を変えている業務です。分岐の設定が増え続け、作った本人以外に読めない状態になりがちです。属人的な判断が残っている課題は、判断基準を先に言語化してから戻ってくるほうが、設定のやり直しが減ります。
採否を決めるとき、機能の可否より先に確認するのが運用担当の有無です。ノーコードで作った連携は、つないだ先のサービスの仕様変更で止まることがあります。止まったときに復旧できる人を社内で決めていないと、その連携は動かない設定として残ります。
完了条件は2つあります。本番データで1か月間、担当者の手直しなしに稼働していること、そして運用担当者が氏名レベルで決まっていることです。両方そろって初めて、第3段階で止めたと判断します。
打ち切り条件として扱うのは、次の4つです。
- 対象業務の例外パターンが多く、分岐条件が十数個を超えて設計が読めなくなる
- 連携したいシステムがAPIや外部連携に対応しておらず、接続手段がない
- 運用担当を置ける人員がなく、止まったときに復旧する体制を作れない
- 扱うデータが外部サービスを経由することになり、社内のセキュリティ要件を満たせない
新しいノーコードツールを契約する場合は、契約前にデータの保存先、権限管理、監査ログを確認します。ここで使う確認項目は生成AIツールの選定基準と重なるため、一度整理しておけば第4段階のセキュリティ審査でもそのまま使えます。
第4段階:カスタム開発に進む条件
カスタム開発の対象になるのは、前の3段階すべてを打ち切り条件付きで通過した課題です。3つの打ち切り理由が書けていなければ、まだ判定が終わっていません。
開発が正当化されるのは、打ち切り理由が次のような構造的な制約に由来する場合です。
- 業務固有性:処理ロジックが自社の商習慣や積算ルールに強く依存し、既製品の設定範囲では表現できない
- データ量と処理頻度:件数が多く、汎用AIやノーコードの実行回数・処理上限では業務量をさばけない
- セキュリティ要件:扱う情報を外部サービスへ渡せず、自社が管理する環境で処理する必要がある
- 更新頻度の低さ:業務ルールが安定していて、作ったものを数年使い続けられる見込みがある
4つ目の更新頻度は、要件の議論では後回しになりがちです。業務ルールが毎四半期変わる領域で作り込むと、改修費が継続的に発生し、初期投資を回収する前に作り直しの検討が始まります。ルールが動いている業務なら、第3段階までの手段で回しながら仕様が落ち着くのを待つ判断もあります。
着手前に固めるのは、要件の凍結範囲、保守予算の年額、社内で受け入れ確認をする担当者の3点です。この3つが決まらないうちに見積もりを取ると、比較の前提がそろわないまま金額だけを見ることになります。
段階別の総コストを比較する観点
段階の比較は、月額料金だけでは成立しません。同じ課題に対する年間の総額を、次の式でそろえます。
段階の総コスト(年額) = 月額ライセンス × 12 + 初期構築費 + 教育・定着工数 × 人件費単価 + セキュリティ審査工数 × 人件費単価 + 年間の保守・改修費
同じ式を4つの段階へ当てはめると、費目の比重が教育・定着工数から初期構築と保守へ移っていきます。
| 費目 | 第1段階 | 第2段階 | 第3段階 | 第4段階 |
|---|---|---|---|---|
| 月額ライセンス | 追加なし | 利用人数分が発生 | 連携ツール分が上乗せ | 稼働環境の費用が発生 |
| 初期構築 | なし | 手順書作成の工数のみ | 連携設計・テストの工数 | 要件定義から実装までが中心費目 |
| 教育・定着工数 | 主な費目 | 主な費目 | 運用担当への引き継ぎが加わる | 受け入れ確認と操作教育 |
| セキュリティ審査 | 既存契約の範囲内 | 利用ルールの確認 | 新規サービスの審査が発生 | 環境・権限設計まで審査対象 |
| 保守・改修 | なし | 手順書の更新 | 連携停止時の復旧対応 | 継続的に発生し、年額で計上が必要 |
第1段階と第2段階は教育・定着工数がほぼすべてを占めるため、見込みが外れても損失は工数に収まります。第3段階から先は事情が変わります。止まったときに復旧する費用が、毎年の固定費として乗ってくるからです。
安価な選択肢を見送る理由の説明方法
汎用AIやノーコードで解決できそうに見える課題を見送るとき、説明が「難しいので」で止まると、受け取られ方が二方向に割れます。経営層からは過剰投資を疑われ、現場からは安い方法を試さずに決めたと見られます。観点ごとに判定材料と説明の言い方を分けて用意しておけば、この食い違いは避けられます。
| 観点 | 見送りの判定材料 | 経営層への説明 | 現場への説明 |
|---|---|---|---|
| データ量 | 月間の処理件数、実行回数の上限 | 件数が上限を超え、超過分の追加料金が開発費を上回る見込み | 繁忙期に処理が止まり、結局手作業に戻る |
| セキュリティ要件 | 扱う情報の区分、外部送信の可否 | 社内規程で外部サービスへ渡せない情報が含まれ、規程改定は別の判断になる | この資料は今の方法では入力できない決まりになっている |
| 業務の属人性 | 判断の分岐数、例外パターンの件数 | 判断ルールが未文書化で、設定に落とすと例外が想定より多い | いまの判断基準を先に文章にしないと自動化しても外れる |
| 運用担当の有無 | 復旧担当者の氏名、代替要員 | 止まったときに直す担当を置けず、放置される資産になる | 動かなくなったとき誰も直せない状態は避けたい |
| 更新頻度 | 業務ルールの改定間隔 | ルール改定のたびに設定変更が必要で、年間の維持工数が積み上がる | 制度が変わるたびに設定し直す作業が増える |
この進め方で失敗しやすい点と防止策
第1段階を形式的に済ませて開発へ飛ぶ
兆候は2つあります。契約一覧が「たぶん使っていない」という記憶ベースで作られていること、現場担当者に一度も聞かないまま第2段階へ進んでいることです。開発の検討が打ち合わせや見積もりという目に見える動きを伴うのに対し、契約済み機能の確認は進捗が外から見えにくく、後回しにされやすいことが背景にあります。
防止策は、第1段階の打ち切り理由を文章で残すことを、次段階の着手条件にする運用です。「該当機能なし」ではなく「契約中プランおよび上位プランの機能一覧を確認し、対象工程に当たる機能がないことを◯月◯日に確認」まで書ければ、確認が実際に行われたかを後から検証できます。
ノーコードの運用担当が不在のまま導入する
導入を主導した1名だけが設定内容を把握していて、設定変更の手順がどこにも記録されていない状態が兆候です。連携先の仕様変更で止まったとき、設定を読める人がいないため復旧に着手できません。
防ぐには、運用担当者の氏名と代替要員を決めることを、第3段階の完了条件に含めます。あわせて、連携の設定内容と復旧手順を1枚に残し、担当者以外が読める場所へ置きます。
PoCで止まり本番運用へ移らない
試行の結果が「おおむね良好」といった定性的な言葉で報告されるのが兆候です。合格基準が事前に決まっていないため、良し悪しを言葉でしか書けません。基準がなければ、続けるか止めるかの判断を誰も下せず、試行だけが延長されます。
対策は、試行の開始前に合格基準と判定日、判定する人を決めておくことです。判定日に基準を満たしていなければ、その段階を打ち切って次へ進むか、課題そのものを取り下げます。判定日が先に置かれていれば、続けるか止めるかの判断は担当者個人の裁量から離れます。
法人AI研修で支援できること
当社の法人AI研修は、Claude・ChatGPT・Geminiなどの生成AIを自社の業務課題に合わせて学び、部門別演習からAI成果物の実装、研修後の定着支援まで伴走するサービスです。4段階の検討順序と、扱う内容は次のように対応します。
- 第1段階に対応するもの:Microsoft Copilotコース(Excel・Word・FormsなどMicrosoft 365でのAI活用)、Google Geminiコース(Google環境でのAI活用、NotebookLMや画像生成)。契約済み環境に含まれる機能から扱います。
- 第2段階に対応するもの:生成AI業務プロセス適用研修。自部門の実業務を棚卸しし、生成AIを組み込んだワークフローを設計して、研修内で動く成果物まで作ります。
- 第3段階に対応するもの:Zapierコース(GoogleとMicrosoftを横断する定型業務の自動化)、Power Automateコース(Microsoft環境での自動化)、n8nコース(自社サーバーで動かす自動化)、Difyコース(チャットボット構築の基本)。
- 段階の見極めに対応するもの:AIコンサルコース。複数AIツールの比較、導入設計、社内推進の考え方を扱います。
研修の形式は2種類です。標準カリキュラムをベースに進めるパッケージ研修と、現状課題・部門・業務フローをヒアリングして実務テーマと成果物まで設計するパーソナライズ研修から選べます。研修後アンケートでは、80%以上の受講者が業務でAIを活用していると回答しています。対象人数・レベル・題材によって設計が変わるため、料金は個別のお見積りとし、初回のヒアリングは無料で承っています。
4段階の検討には全体でどのくらいの期間を見込めばよいですか?
段階ごとに期限を切る形をおすすめします。第1段階は契約一覧の作成と現場確認で1〜2週間、第2段階は担当者が手順を反復する期間として1〜2週間、第3段階は本番データでの安定稼働を見る1か月が目安になります。期限内に完了条件も打ち切り条件も判定できなかった場合は、判定材料が足りていない状態です。期間を延ばすより、確認項目を絞り込んでください。
コンサルタントに依頼せず、自社だけで4段階を回せますか?
第1段階と第2段階は社内で回せる範囲です。必要になるのは契約情報へのアクセスと現場への聞き取りで、専門知識よりも、契約と業務の両方を横断して確認できる立場が要ります。第3段階以降は、ノーコードツールの選定基準やセキュリティ審査の観点が絡むため、社内に経験者がいなければ外部の知見を入れると判断材料がそろいやすくなります。判断そのものを外部に委ねるのではなく、判定条件を一緒に作る使い方が向いています。
第1段階や第2段階で解決した課題は、あとから再検討すべきですか?
処理件数が増えたときと、業務ルールが変わったときに見直します。第2段階で回していた業務の件数が倍になれば、人が毎回起動する運用では追いつかなくなり、第3段階の打ち切り条件に該当する状態へ変わります。半年ごとに対象業務の件数と所要時間を確認する運用にしておくと、段階を上げるタイミングを逃しません。
すでにカスタム開発の見積もりを取ってしまった場合、どうすればよいですか?
見積もりを取り下げる必要はありません。見積書に書かれた機能要件を工程単位に分解し、それぞれが第1〜第3段階で解決できるかを判定してください。全工程がそのまま開発対象として残るとは限らず、一部の工程が既存ツールや汎用AIで片づけば、開発範囲が縮んで金額も下がります。段階判定の結果を持って、開発範囲の再提示を依頼する形が現実的です。
AI導入の費用は、選んだ手段と同じくらい、どの順番で検討したかで変わります。既存ツールの未使用機能から順に当て、各段階の打ち切り理由を記録に残していけば、開発へ進む段になったときには、その投資が必要な理由がすでに文章になっています。社内の合意が早く取れるのは、選択肢が減るからではなく、見送った理由を示せるからです。

この記事の監修者

主任講師 / AI活用コンサルタント
小柴 鷹介
業務で動くところまで、一緒に考える講師です。
京都大学大学院修了後、株式会社リクルートに入社。国内最大級の不動産プラットフォーム「SUUMO」のプロダクトマネージャーとして、データ分析・AI活用を取り入れたプロダクト改善を主導。その後、複数のAI・SaaSプロダクトの企画・開発をゼロから立ち上げ、「AIを業務で本当に使える形にする」ことを一貫して追求。現在は法人向けにAI活用戦略の立案から研修設計・実施まで手掛け、非エンジニアでも現場でAIを活用し始められる実践型プログラムを提供している。

