現場業務における生成AI活用の始め方

エグゼクティブ・サマリー

• 生成AIの現場活用が止まる最大の原因は、モデルの性能ではなく業務の切り出し方である。「何に使えるか」から入った検討はほぼ止まり、「どの業務のどの工程を、誰の何分に代えるか」から入った検討は動く。
• 現場業務は「文書化」「翻訳・要約」「探索」「判断支援」「対話」の5類型に整理できる。最初に着手すべきは、出力の誤りを人がその場で発見でき、かつ発生頻度が高い業務——つまり文書化と要約である。判断支援と対話は、業務設計と責任分界が固まるまで後回しにする。
• 精度100%を前提にした業務設計は必ず失敗する。生成AIは「間違えることがある部品」であり、間違いを人が検知・修正する工程を業務フローに組み込んだ設計だけが本番稼働に耐える。ゼロから書く作業を「叩き台を直す作業」に変える、という価値の置き方が現実的である。
• 社内文書を読ませる取り組みは、AIの設定ではなく文書側の整備で成否が決まる。版が混在し、どれが最新か人にも分からない文書群を読ませても、答えは当然揺れる。整備の順序を決めずに着手した案件は、ほぼ例外なく「使えない」で終わる。
• 利用ルールは禁止事項の列挙ではなく判断基準で書く。禁止リストは新しい使い方が出るたびに破綻し、結果として現場の私的利用（シャドー利用）を生む。「何を入力してよいか」「出力を誰の責任で使うか」の2軸で書けば、想定外の用途にも判断できる。

生成AIを現場で使いたい、という相談は年々増えている。だが持ち込まれる相談の多くは「生成AIで何ができますか」という形をしている。この問いの立て方そのものが、その後の停滞を予告している。できることを網羅的に調べれば調べるほど選択肢は増え、どれも一長一短に見え、意思決定は先送りになるからだ。

本稿は、技術の解説書ではない。ロボット導入の現場で繰り返し見てきた「PoCで止まる構造」は、生成AIでもそのまま再現されている。だからこそ、導入7工程——①RXビジョン／構想策定 ②要件定義・PoC・選定・組成 ③構築スケジュール／ToBe業務設計 ④システム設計 ⑤開発・導入 ⑥定着化 ⑦運用——という同じ枠組みで扱える。本稿は、この枠組みに生成AIを載せ、最初の90日で何を決め、何を作り、何を測るかを具体的に示す。

1. なぜ「何に使えるか」から入ると止まるのか

生成AIの検討が止まる典型的な経路は、ほぼ一つに収束する。

まず情報収集から始まる。事例集を集め、他社が何をしているかを調べ、社内で勉強会を開く。ここまでは順調に進む。次に「うちでは何に使えるか」を洗い出す。アイデアは大量に出る。議事録作成、マニュアル整備、問い合わせ対応、日報の要約、設計書のチェック、教育資料の作成——20個も30個も並ぶ。

そして止まる。止まる理由は明快で、並んだアイデアを比較する軸がないからである。どれも「効果がありそう」で、どれも「難しそう」に見える。優先順位が付かないので、結局「まず全社で使えるようにして、各部署で試してもらう」という決着になる。アカウントは配られ、最初の1か月は利用率が上がり、3か月後には一部の人だけが使っている状態になる。

この経路の問題は、業務ではなくツールを配ったことにある。ツールを配ると、業務を変える責任が個人に分散する。個人が自分の裁量で変えられる範囲は狭いので、変わるのは個人作業の一部だけになり、組織としての効果は測定できない。

逆に動く検討は、必ず一つの業務から始まる。「この報告書は毎月何人が何時間かけて書いているか」「この問い合わせは月に何件来て、誰が何分で答えているか」——具体的な業務、具体的な人数、具体的な時間。ここが起点になっていれば、効果の測り方も、失敗の判定基準も、自動的に決まる。

2. 現場業務の5類型と、着手順序

現場業務への生成AI適用は、次の5類型に整理すると比較できるようになる。

着手順序の判定基準は「効果の大きさ」ではなく、出力の誤りを人がその場で発見できるかである。議事録の下書きが間違っていれば、会議に出ていた本人がすぐ気づく。だが社内規程の検索結果が間違っていても、探している本人は正解を知らないので気づけない。前者は今日から始められ、後者は文書整備と検証の仕組みを作ってから始めるべきものである。

この順序を無視して、いきなり「社内文書を全部読ませてQ&Aを作る」から始める組織は多い。見栄えがよく、デモが映えるからだ。しかし現場に出すと、間違った規程を根拠にした回答が返り、一度でも起きると信用は戻らない。最初の失敗が、その後2年の停滞を生む。

3. 最初の業務を選ぶ——4つの条件

最初に着手する業務は、次の4条件をすべて満たすものから選ぶ。一つでも欠けるなら、それは2番目以降に回す。

1. 頻度が高い——月に数回ではなく、週に複数回、あるいは毎日発生する。頻度が低い業務は、効果が出るまでに時間がかかりすぎ、途中で関心が失われる。
2. 今の所要時間が測れる、または見積もれる——「だいたい1件30分」で構わない。数字がない業務は、効果も語れない。
3. 出力の誤りをその場で人が検知できる——前節の類型でいえば文書化・翻訳要約に該当する。
4. 担当者が特定できる——「全社の誰か」ではなく、「◯◯課の3名」まで絞れる。絞れない業務は、変更を誰も引き受けない。

条件を満たす業務が複数あれば、次の簡易評価で並べる。

最後の「担当者の意欲」を軽視しないほうがよい。最初の案件は、成功事例そのものよりも、社内に「実際に変わった業務」を一つ作ることが目的である。前向きな担当者がいる業務のほうが、途中の細かな調整が回る。

4. 「精度が100%でない部品」を前提にした業務設計

生成AIを使った業務設計で最も重要な転換は、出力を成果物として扱わないことである。出力は中間物であり、人が確認・修正して初めて成果物になる。

この前提を置くと、業務フローの書き方が変わる。

• 旧：担当者が報告書を作成する（60分）
• 新：担当者が要点を入力する（5分）→ 生成AIが下書きを出す（1分）→ 担当者が確認・修正する（15分）→ 完成

ここで効果は「60分→21分」であって、「60分→1分」ではない。この現実的な数字を最初に置くことが、後で失望しないための条件になる。「AIで9割削減」という期待値のまま始めた案件は、実測で6割減という良好な結果が出ても「思ったほどではない」という評価になる。

確認・修正の工程を設計するときは、次を明示する。

とくに確認観点を絞ることが効果を左右する。「全部読んで確認してください」という運用は、実質的に元の作業時間に戻る。「数値と固有名詞だけ照合し、文章表現は直さない」といった観点の限定が、時間削減を実際に生む。

5. 社内文書を読ませる——整備の順序

「社内の資料を読ませて質問に答えさせたい」は、最も要望の多いテーマであり、最も失敗の多いテーマでもある。失敗の原因はほぼ一つ、文書側が整備されていないことである。

人が読む場合、文書の版が混在していても、経験のある担当者は「これは古い」と判断できる。AIにはその判断材料がない。日付の新しい文書が正しいとは限らず、正式版と作業中の版が同じフォルダに並んでいれば、どちらも同等に扱われる。

整備は次の順序で進める。

1. 範囲を狭く切る——全社文書ではなく、「◯◯業務の手順書だけ」から始める。最初から全社を対象にした案件は、整備が終わらず立ち消えになる。
2. 正・副を決める——同じ内容の文書が複数あるなら、どれが正本かを決め、副本は対象から外す。これは人の仕事であり、後回しにできない。
3. 版と有効期限を書く——各文書に「いつ時点のものか」「いつまで有効か」を明記する。これがあるだけで、回答に日付を添えられるようになる。
4. 答えられない範囲を宣言する——対象文書に書かれていない質問には「対象外」と返す設計にする。何でも答えようとする設計は、それらしい誤答を生む。
5. 検証セットを作る——現場の担当者に、実際に来る質問を30〜50件出してもらい、正解を人が用意する。この検証セットがない取り組みは、良くなったのか悪くなったのかを誰も判定できない。

5番目の検証セットは、PoCの合否判定そのものになる。PoC設計の考え方はPoC（実証実験）の設計と評価で詳しく扱っているが、生成AIの場合も原則は同じで、始める前に合格ラインを紙に書く。「30問中、事実誤りゼロで24問以上に正答」といった形式である。ラインを決めずに始めたPoCは、成果の解釈が立場によって割れ、意思決定に至らない。

6. 利用ルールは「禁止リスト」ではなく「判断基準」で書く

多くの組織が最初に作るのは禁止リストである。「個人情報を入力しない」「機密情報を入力しない」「出力をそのまま使わない」。方向は正しいが、この形式には二つの弱点がある。

一つは、新しい使い方が出るたびに破綻すること。リストに書かれていない用途が出れば、現場は「書いていないから良い」と判断するか、「怖いから使わない」と判断する。どちらも望ましくない。

もう一つは、現場の私的利用を生むこと。会社の環境が使いにくければ、個人の端末で個人のアカウントを使う人が出る。これは禁止しても止まらず、可視化もできない。

ルールは次の2軸で書くと、想定外の用途にも現場が判断できるようになる。

この2軸で、たとえば「取引先情報を含む文書の要約を、社外提出資料に使う」は最も慎重な扱いになり、「公開情報の要約を、本人の下書きに使う」は自由に使ってよい、という判断が現場で自動的にできる。表を配るだけで、個別の問い合わせが大幅に減る。

加えて、使ってよい環境を明示する。どのサービスを、どのアカウントで使うのか。ここが曖昧なままルールだけを配ると、現場は判断できず、結局は使わないか、勝手に使うかに分かれる。

7. 効果を金額で語る——測定の設計

生成AIの効果は「便利になった」で終わりやすい。継続投資を得るには金額に変換する必要があるが、ここでよく起きるのが時間削減を単純に人件費に換算して過大な数字を出すという誤りである。「1日30分削減×100人×250日×時給3,000円＝年間3,750万円」という計算は、経営層に一度は響くが、二度目には通用しない。削減された30分が実際に何に使われたかを説明できないからである。

効果は3階層に分けて語る。

多くの現場で最も正直に語れるのは増員回避である。「業務量が2割増えたが、人を増やさずに回せた」は、削減額として説明可能で、経営層にも通る。逆に、人が減っていないのに人件費削減として計上すると、次年度に必ず追及される。

測定で決定的に重要なのは、導入前に現状値を取ることである。1件あたり何分かかっているか、月に何件あるか。この2つを、開始前の2〜4週間で記録する。ここを飛ばした案件は、以後どれだけ丁寧に測っても「導入前と比べてどうか」を証明できない。KPIの階層設計とベースラインの取り方はロボット導入のKPI設計と効果測定と同じ構造なので、あわせて参照されたい。

8. 最初の90日——何を決め、何を作るか

最後に、着手から90日の進め方を示す。長い計画は途中で状況が変わるため、90日を一区切りにする。

11〜13週に撤退判断を明示的に置くことが、この計画の要点である。うまくいかなかった業務を惰性で続ける組織は、次の業務に着手できない。「この業務では効果が出なかった。理由はこれ。次はこの業務でやる」と言えることが、組織としての学習になる。

横展開を含めた進め方についてはコンソーシアム型導入のプロジェクトマネジメント、現場に受け入れられるための進め方については定着化・運用設計で扱っている。生成AIもロボットも、技術が違うだけで、現場の仕事が変わることを人が受け入れるかどうかという最大の関門は同じである。

まとめ

生成AIの現場活用は、技術の問題ではなく業務設計の問題である。本稿の要点を再掲する。

• 「何に使えるか」ではなく「どの業務の、誰の、何分か」から始める
• 業務を5類型に分け、誤りをその場で検知できる文書化・要約から着手する
• 出力は成果物ではなく中間物。確認工程を組み込んだフローだけが本番に耐える
• 社内文書の活用は、AIの設定ではなく文書の整備順序で成否が決まる
• ルールは禁止リストではなく、入力情報と責任範囲の2軸で書く
• 効果は作業時間・業務成果・財務の3階層で語り、ベースラインは開始前に取る

RobiZyは、ロボットもソフトウェアも販売しないNPO法人である。特定のベンダーや製品に紐づかない立場から、ユーザー企業の側に立って、業務の切り出し、要件の整理、検証設計、そして事業者選定の伴走を行っている。「何に使えるか」の段階で止まっている——その構想段階こそ、外部の中立的な視点が最も効く時期である。

まだ何も決まっていない状態でのご相談を歓迎する。無料の相談窓口を用意しているので、まずは現在の状況をお聞かせいただきたい。