生成AIの検証が動いたのに本番に進まない、という相談をよく受けます。デモは成立していて、担当者も手応えを感じている。それでも半年経って業務は変わっていない。
止まっている理由を聞くと「精度がもう少し」と言われることが多いのですが、掘っていくと別のところで詰まっていることの方が多い。作ったものに、業務フローの中の置き場所がないという状態です。
置き場所がない、とはどういうことか
たとえば問い合わせメールを分類して要約するものを作ったとします。精度は十分。デモでも良い結果が出る。
ここで本番に持っていこうとすると、質問が出ます。要約はどこに出るのか。担当者はいまメールソフトを開いて処理している。要約を見るために別の画面を開くのか。開くとして、それは処理時間を短くするのか、増やすのか。
この問いに答えがないまま作られたものは、使われません。精度が99%でも使われない。既存の作業導線から外れているものは、忙しいときに真っ先に飛ばされます。
もう1つよくあるのが、出力の信頼度をどう扱うかが決まっていないケースです。AIが「この問い合わせは緊急度が高い」と言ったとして、担当者はそれをそのまま信じていいのか、確認するのか。確認するなら結局全部読むことになり、時間は減りません。
どこで止まるかの内訳
これまで見てきた止まり方を、多い順に並べます。
1. 出力の置き場所が決まっていない
いちばん多い。既に使っているツール（メール、チャット、業務システム）の中に結果が出てくる形にしないと、定着しません。新しい画面を1つ増やすことのコストは、想像より大きい。
2. 誰が使うかが決まっていない
「全社的に使える」と説明されるものは、たいてい誰も使いません。特定の部署の特定の作業に絞ったものの方が本番に行きます。使う人が1人でも、その人の作業が変われば成功です。
3. 本番データで動いていない
サンプルデータや、きれいに整理されたテストケースで作ったものは、本番データの汚れ方を通ると壊れます。表記の揺れ、欠損、想定外の長さ、コピペで混入した制御文字。検証の段階で本番データを触っていないと、この工程がまるごと本番の後ろに残ります。
4. 間違えたときの扱いが決まっていない
AIは間違えます。問題は間違えることではなく、間違えたときに誰がどう気づいて、どうリカバリするかが決まっていないことです。ここが空白だと、責任の所在が曖昧なまま本番に出せません。
5. 合格条件が後出しになる
「精度がもう少し」と言われるとき、何%あれば合格かが最初に決まっていないことがほとんどです。基準がないので、いつまでも「もう少し」が続きます。
順番を変える
Nue が案件で最初にやるのは、モデルの選定でも技術検証でもなく、業務の分解です。
現場の方に実際の作業を見せてもらいます。資料だけでは分かりません。「この判断はどうやっていますか」を繰り返し聞いて、暗黙のルールを言語化していきます。判断のうち何が定型で、何が例外か。例外は月に何件あるのか。
この工程で、AIを入れない方がいい業務も出てきます。
- 件数が少なすぎて、手でやった方が早いもの
- 間違えたときの損害が大きすぎて、人の確認が外せないもの
- 業務フローを整理すれば、そもそも消える作業
3つめが意外と多い。二重入力や、使われていない帳票の作成が、慣習で残っている。ここにAIを載せると、やめられる作業を高速化することになります。そういうものは、そう伝えます。
合格条件を先に決める
検証に入る前に、何ができたら本番に進めるかを文章で書きます。書くのは4つです。
- 対象。どの部署の、どの作業か。1つに絞る
- 成功の定義。作業時間が何割減るか、処理できる件数が何件増えるか。着手前に現状を測っておく
- 合格ライン。何%正しければ運用に乗せるか。100%を求めると永遠に終わりません
- 間違えたときの手順。誰が気づいて、どう戻すか
「作業時間が何割減るか」は、着手前に測っておかないと後から言えません。終わってから「たぶん3割くらい」と言うことになり、それは翌年の予算で真っ先に削られます。
本番データで作る
プロトタイプの段階から本番の業務データで動かします。契約や社内規程の制約があるなら、そこを先に整理します。マスキングして使うのか、学習に使われない契約形態のAPIを使うのか、社内ネットワーク内で処理するのか。
この整理を後回しにすると、動くものができてから「そのデータは外に出せません」と言われて振り出しに戻ります。技術検証より先に、データの扱いを決める。
現場に渡すときに渡すもの
操作マニュアルではなく、判断の基準を渡します。
「AIの出力をそのまま使っていい場合」と「必ず人が確認する場合」の線引きを、現場の言葉で書いたものです。これがないと、使う人は毎回全部を確認することになり、時間が減りません。逆に何も確認しなくなると、事故が起きたときに止められません。
渡したあとに出てくる要望は、ほとんどが精度の話ではありません。出力の形式、結果が出てくる場所、通知のタイミング。その要望を自分たちで直せる状態にして渡すところまでを範囲にしています。プロンプトやモデルの切り替えを、こちらに頼まずに社内でできるようにする。
本番に行ったものは何が違ったか
自社の例で書きます。Nue が運営しているサービスで、ブログ記事の企画から執筆、公開までをAIに任せる仕組みを作りました。これは本番運用まで行って、日次で回り続けています。
本番に行った理由は、たぶん3つです。
出力の置き場所が最初から決まっていた。 生成された記事は、リポジトリの中にファイルとして保存され、push すると自動でデプロイされます。人が「どこかにコピーする」工程がありません。既存の公開フローの中に結果が落ちる形にしたので、運用者が別の画面を開く必要がない。
間違えたときの扱いが決まっていた。 生成された記事は、公開前に機械的な検査を通ります。禁止表現が入っていないか、内部リンクの飛び先が実在するか、既存記事とタイトルが重複していないか。落ちたら公開されません。人が全文を読まなくても、一定の水準は担保されます。
「やらない」判断を許した。 書く価値のある企画が無い日は、書かずに見送ってよいことにしました。毎日必ず1本出す設計にすると、無理に本数を合わせにいって質が落ちます。
それでも間違えた
ただ、この仕組みは数か月のあいだ、誰も検索していないキーワードを狙った記事を量産していました。
企画の段階で「この語には検索需要があるか」を確認する工程が無かったからです。生成の速度が上がったぶん、間違った方向にも速く進みました。実データで判明したのは数か月後です。
直し方は、記事を書く前に需要を検証する工程を挟んで、需要のない語を狙った企画は生成側が自分で飛ばす、という形にしました。別の記事でも書きましたが、出力の量を見ていると結果を見なくなります。
ここから引ける教訓は、PoC の話に戻ります。本番に行くかどうかと、行った先で成果が出るかどうかは別の問題です。 置き場所と間違えたときの手順が決まっていれば本番には行く。ただし、正しいことをやっているかを確かめる工程が無ければ、本番で間違い続けることになります。
費用と期間はどう決まるか
金額は範囲を決めてから出しますが、何で変わるかは先に言えます。
対象業務の広さ。 1つの業務に絞った検証と実装なら数週間、全社の活用方針づくりを含むなら数か月です。ここがいちばん効きます。
つなぐ先の数と、その API の素直さ。 Slack や Notion のようにドキュメントが整っているものは読めますが、社内システムや古い業務パッケージは調査に時間がかかります。見積もりが一番ぶれるのがここです。
データの扱いにどれだけ制約があるか。 個人情報や機微な情報を含む場合、送信前のマスキング、処理場所の制限、監査ログの設計が必要になります。技術的な難易度より、確認と合意にかかる時間の方が大きい。
誰が運用を引き取るか。 社内に引き取る人がいるなら、引き継ぎのための資料と説明の時間を見込みます。いないなら保守として継続します。どちらが安いかは体制次第です。
まず何から聞くか
相談を受けるとき、最初に聞くのはこれです。
- いま、どの作業にいちばん時間を取られているか
- その作業は月に何件あるか
- その判断のうち、迷うのはどれくらいの割合か
- 間違えたら何が起きるか
「生成AIで何かやりたいが決まっていない」という段階でも構いません。むしろその段階の方が、筋の悪いテーマに投資する前に方向を変えられます。生成AI導入支援のページに進め方を書いています。