「AI を入れたいんです」——この相談を受ける回数が、2024 年以降で 3 倍以上に増えています。ただ、相談の入り口で技術選定や PoC の話に進んでしまうと、半年後に「動いてはいるが誰も使っていない」状態に着地する事例が後を絶ちません。
多くの場合、原因は LLM の精度でもインフラでもなく、そもそも AI を当てる業務の選び方 にあります。私たちが AI エージェント・生成 AI 活用の初期相談を受けたとき、技術の話に入る前に必ず通している 5 つの問いがあります。本記事では、その 5 つを公開し、業務側の論点を構造化するための判断軸として整理してみます。
業務選定で 8 割が決まる
AI を入れるべき場所を見極めるためには、業務側に対して 5 つの問いを順番に通すのが有効だと考えています。具体的には、(1) その業務は判断か作業か、(2) 失敗のコストはいくらか、(3) 正解は誰が決められるか、(4) データは構造化されているか、(5) 撤退条件を引けるか、の 5 点です。
この 5 つを通すと、AI を入れて伸びる業務とそうでない業務がほぼ機械的に分かれます。実装段階で躓くプロジェクトの多くは、この 5 つのうちいずれかで「答えが曖昧なまま」走り出しているケースに該当します。逆に言えば、5 問すべてに明快な答えが出る業務であれば、技術選定はその後のフェーズに任せて構いません。モデル選定・基盤選定の議論は、業務選定が終わってから始めるべき だと整理しています。
AI 導入の成否は、モデル選定ではなく業務選定で 8 割が決まる。
問い 1：その業務は「判断」か「作業」か
最初に切り分けるのは、対象業務が 定型作業 なのか 判断業務 なのかという点です。転記・要約・分類・翻訳のような作業系業務は、入力と出力が比較的明確で、AI の導入効果も短期で読みやすい領域に該当します。一方、与信・採用・投資判断・契約解釈のような業務は、結論に至る思考プロセスが複雑で、責任分界とガードレール設計が先に必要になります。
両者を混同したまま PoC を走らせると、判断系のレビュー工数が逆に膨らんで頓挫します。たとえば「契約書のレビューを AI で」という相談を、要約系（作業）と解釈系（判断）に分けないまま進めると、リーガル部門のレビュー負荷が AI 導入前より増えてしまうケースを何度か見てきました。
切り分けの目安として、以下の質問をしてみます。
質問 | 「はい」なら作業系 | 「いいえ」なら判断系 |
|---|---|---|
出力の正誤を 1 分以内に判定できるか | ◯ | × |
同じ入力に対して同じ出力が期待されるか | ◯ | × |
間違った場合、やり直しが容易か | ◯ | × |
3 つすべてが「はい」なら作業系として PoC を進めて問題ありません。1 つでも「いいえ」がある場合は、判断系として責任分界の設計から入ります。
問い 2：失敗のコストはいくらか
次に、AI の出力が間違ったとき 誰がいくら損するか を定量化します。問い合わせの一次返信なら数千円規模、契約書ドラフトなら数百万円規模、医療や法務なら桁が変わります。失敗コストが見積もれない業務に AI を入れると、人間レビューを外せず工数削減効果がほぼ消えてしまいます。
整理のために、失敗コストを 3 段階に分けてみます。
段階 | 想定コスト | レビュー設計の方針 |
|---|---|---|
軽微 | 数千〜数万円 | 抜き取り検査・事後修正で許容 |
中程度 | 数十万〜数百万円 | サンプリング + 重要案件全件レビュー |
重大 | 数千万円〜・人命関連 | 全件人間レビュー必須・AI は補助に留める |
軽微レベルなら、AI 単独で運用に乗せても費用対効果が出やすい領域です。中程度以上では、レビュー工数を含めた トータル ROI で評価し直す必要があります。重大領域で「全部 AI に任せたい」という要望が出てきた場合は、要望そのものの再設計から関わるべきだと考えています。
失敗コストを定量化できない業務は、AI 化を後回しにする判断もあり得ます。コストが読めないまま走らせると、撤退判断もできなくなるためです。
問い 3：正解は誰が決められるか
3 つ目は、AI の出力品質を評価する「正解」を持っている人が 組織内に存在するか という問いです。正解者が不在の業務は、PoC の評価指標が立たず、運用後も改善ループが回りません。
これは見落とされがちな論点で、「AI に任せたい業務」が「社内にエキスパートがいない業務」と重なっていることが少なくありません。エキスパート不在の業務を AI で代替しようとすると、出力の良し悪しを判定できる人がいないため、改善のための学習データも作れず、運用が回らなくなります。
着手の順序としては、社内にエキスパートが 2〜3 名以上いる業務 から入るのが安全です。エキスパートが複数いれば、評価指標の合意形成も可能で、PoC の合否判定が客観化できます。一方、「正解は外部の専門家にしかない」業務は、AI 化を後回しにするか、外部監修を入れる前提で設計します。
合意形成のプロセスとしては、PoC 前にエキスパート 3 名で「良い出力」「悪い出力」のサンプルを各 20 件ずつ作り、それを評価データセットとして固定します。この事前準備を省くと、PoC 中に評価軸がブレて、結果の解釈が割れる事態になりがちです。
問い 4：データは構造化されているか
AI に渡せる業務データが、検索可能・構造化された状態で蓄積されているかを問います。紙・口頭・Excel 散在の業務は、AI 導入の前に データ基盤の整備 が必要で、ここを飛ばすと半年遅延します。
現場で見てきた目安として、以下の状態別に必要工数を整理してみます。
データの状態 | 前処理工数の目安 |
|---|---|
kintone や DB に構造化済み | 1〜2 ヶ月 |
Excel・PDF が共有フォルダに散在 | 3〜4 ヶ月 |
紙・口頭・個人の暗黙知 | 6 ヶ月以上 + 業務プロセスの再設計 |
「AI を入れたい」という相談の半分以上は、実は データ基盤の整備案件 であることが多い印象です。この事実を初期相談の段階で共有できると、プロジェクトのスコープと期待値が大きくズレることを防げます。kintone への業務データ集約を AI 導入の前段として位置づけるパターンもよく取ります。詳しくは kintone カスタマイズで失敗する組織の共通点 も併せて参照ください。
問い 5：撤退条件を引けるか
最後の問いは、AI 導入が想定通りにいかなかったときの 撤退ライン を、開始前に合意できているかという点です。撤退条件のない PoC は「もう少し改善すれば」と引き延ばされ、サンクコストが膨らみます。
撤退条件は、必ず 数値で 設定します。たとえば「3 ヶ月で精度 80% に到達しなければ撤退」「6 ヶ月で工数削減 20% に届かなければ仕様再設計」のように、誰が見ても判定できる形に落とし込みます。曖昧な定性条件（「現場で使いやすければ継続」など）は、撤退判断ができなくなるため避けるべきです。
撤退条件を引く際のポイントは、期間 × 達成指標 × 判定者 の 3 つを開始前に文書化することです。判定者が曖昧だと、撤退タイミングで議論が紛糾します。経営層・現場責任者・プロジェクトオーナーの 3 者で合意するのが最低限のラインだと考えています。
なお、撤退は失敗ではありません。5 つの問いのどこかで誤判定があった ことが見えるだけで、次の業務選定の精度が上がります。
ある金融業の問い合わせ対応 AI 化での適用例
ある金融業界の B 社で、社内問い合わせ対応に AI を導入する相談を受けた際の話です。当初は「全部の問い合わせを AI で自動化したい」という要望でしたが、5 つの問いを通したところ、対象を絞るべきだという結論に至りました。
問い 1 で「判断業務（契約条件の解釈）」と「作業業務（FAQ 回答）」を分離し、まずは FAQ 回答に絞る判断をしました。問い 2 で失敗コストを算定すると、FAQ 誤回答は再質問されるだけで実害が軽微であることが確認できました。問い 3 では、社内の業務エキスパート 3 名が正解判定者として合意し、問い 4 では過去 5 年分の問い合わせログが kintone に蓄積されていることを確認しました。問い 5 で「3 ヶ月で一次回答率 60% に到達しなければ撤退」という条件を合意しました。
結果として、4 ヶ月後に一次回答率 72% に到達し、問い合わせ対応工数を 30% 削減できました。当初想定していた「全業務 AI 化」のスコープのままなら、判断業務のレビュー工数が膨らんで頓挫していた可能性が高いと振り返っています。5 つの問いは、AI を入れる範囲を絞り込むためのフィルターとして機能する というのが、現場での実感です。
5 つの問いを具体業務で壁打ちする
「今、社内で AI 化を検討している業務に、この 5 つの問いを当ててみたい」という段階のご相談を歓迎しています。私たちは AI エージェント・生成 AI 活用の初期相談から、PoC 設計、本番運用、撤退判断までを一貫して支援しています。技術選定の前に業務選定を整える支援は、後工程のやり直しコストを大きく下げる効果があります。
業務側の論点を構造化する壁打ちから始められますので、まずは具体的な業務をひとつ持ち寄っていただく形で構いません。
関連記事：
