便利そう、で終わるAI
最新機能を紹介すると喜ばれるのに、翌月には誰も使っていないことがありました。「こんなことまでできるんですね」と言われたデモと、実際に変わった仕事の間には、思っていた以上に距離がありました。
私たちは三人の小さなAI支援会社です。開発が必要なら外部のエンジニアとも組みます。当時は、できることを多く見せるほど価値が伝わると考え、打ち合わせのたびに新しい使い方を持っていきました。
ところが、導入先の担当者は、どれから始めればよいか分からないままでした。便利なのは分かる。でも、今の仕事を止めて覚える時間がない。失敗したときに誰が確認するかも決まっていない。私たちは技術の説明を重ねながら、使い始める人の不安と段取りを飛ばしていたのです。
雑談に出てきた毎週の苦痛
相談の入口が変わったのは、SNS運用者との雑談でした。彼女は毎週、顧客へ送る報告文の下書きに時間がかかると話しました。数値を見ることではなく、それを相手の仕事に沿った文章へ直すところで手が止まるそうです。
「AIを入れたい」という相談ではありませんでした。「毎週、同じところで金曜の夕方がなくなる」。その言い方の方が、私には具体的でした。何の機能を提案するかより、どんな手順で書いているのかを聞きたくなりました。
画面を見せてもらうと、資料を探し、前週の表現を確認し、説明を組み立て、読み直す工程がありました。文章の生成だけを速くしても、全部は終わりません。それでも、毎週必ずある一作業なら、変化を確かめられる。私たちは大きな導入提案を作る前に、その下書きだけを試すことにしました。
担当者がいちばん嫌がっていたのは、文章を書くこと自体ではありませんでした。書き出しで迷っている間に、考えたかった改善案を忘れてしまうことでした。その話を聞いて、私は短縮時間だけでなく、残したい仕事も一緒に聞こうと思いました。
一つの下書きだけ試す
まず三つの定型業務を、それぞれ二週間ずつ計測しました。報告文の下書きは一件平均四十七分。長すぎるのか短いのかを評価するより、どこで時間を使っているかを同じ区切りで残しました。
試行には、公開可能な情報と、検証用に用意した文章だけを使いました。顧客の資料をとりあえず入れてみる、という始め方はしません。担当者が毎回入力してよい情報を判断する負担も考え、最初は対象を狭くしました。
下書きの時間は平均十八分になりました。一方で、確認する時間は以前より七分増えました。差し引けば、この工程での短縮は二十二分です。四十七分が十八分になった部分だけを見せれば、成果は大きく見えます。でも、そのまま広げる判断はできません。誤りを見つけた箇所と、確認に迷った理由も一緒に記録しました。
速さより先に決めること
文章が早く出ると、読む側もつい安心してしまいます。実際、意味は通っているのに、前週と今週の比較が逆になった下書きがありました。数値が合っているかだけでは、見落とす種類の誤りでした。
そこで、下書きの担当と最終確認の担当を決めました。数字の対応、比較の向き、元資料にない理由を言い切っていないか。確認する点を短く整理し、迷った文は送信しない流れにしました。例外が出たら、その場で個人の工夫に任せず、どこを見直したか残します。
業務担当、情報管理に詳しい人、開発者にも、それぞれ確認を依頼しました。入力できない情報、利用サービスの条件、権限や記録の扱いは、案件ごとに整理します。全員がすべてを決めるのではなく、確認する論点を分けることで、現場が相談する相手も明確になりました。
確認で迷った文章は、そのまま下書きの例として残しました。良い出力だけを集めると、使う人は失敗の見分け方を学べません。どの箇所を元の情報へ戻って確かめたかが分かる方が、担当者には使いやすい資料でした。
開発しないという判断
試行が進むと、報告の作成から送信まで自動化できないかという話が出ました。技術的な案はいくつかありましたが、私たちはすぐに開発の見積りを出しませんでした。
報告の形式は顧客ごとに少し違い、元の情報を確認する場所も一定ではありません。下書きより、その前の資料整理をそろえた方が楽になる可能性がありました。まず書式をそろえ、対象を絞ったまま使ってみる。それで十分なら、専用の開発をしない選択もあります。
外部のエンジニアには、その判断に必要な部分だけを見てもらいました。「作れるか」ではなく、「作った後、誰が直すのか」。その問いが入ると、開発しないことも立派な提案になります。機能を増やすほど頼られると思っていた私たちには、少し勇気のいる判断でした。
作らずに残した予算を、使い方の確認へ回せることもありました。
デモではなく現場を聞く
次の相談では、デモの前に現場の手順を聞きました。「AIで何がしたいですか」ではなく、「毎週、後回しになる仕事はありますか」。すると、提案書には載っていなかった困りごとが出てきます。
ただ、似て見える作業でも、同じ方法が通用するとは限りません。誰が確認するか、情報を外へ出せるか、作業の頻度はどれくらいか。別の会社では、AIより、入力する表の項目を減らす方が先でした。最初の成功を、そのまま別の現場へ持ち込まないようにしました。
私たちの料金も、ツールの設定だけでなく、作業の棚卸し、試行、振り返りの範囲が分かる形へ変えました。準備と連絡にかかった時間を数え、支援する側も続けられるかを確認します。便利なものを見せる仕事から、使うまでの条件を一緒に整える仕事へ変わっていきました。
浮いた時間を何に使うか
試行の後、SNS運用者が、浮いた時間で顧客への提案を一件増やせたと話してくれました。報告の下書きを終えるだけで精いっぱいだった日に、投稿の改善案まで考えられたそうです。
その一件が売上にどれだけ効いたかまでは分かりません。私たちが確認したのは、仕事を急いで済ませるためではなく、本人がやりたかった仕事へ時間を戻せたことでした。短縮した分をすべて新しい受注で埋める必要もありません。余裕を残すことが、確認の質を守る場合もあります。
運用者からは、使いにくかった表現や例外の報告が戻ってきます。私たちはそれを次の手順へ反映し、開発者には必要な部分だけ相談する。互いの仕事が少しずつ分かることで、初回のデモでは出てこなかった改善案が生まれるようになりました。
次の打ち合わせで見せてもらったのは、AIの画面ではなく、顧客へ送った提案のメモでした。速くなった作業の外側に、使いたかった時間がありました。私たちが導入したかった道具の話から、担当者がしたかった仕事の話へ、ようやく会話が移りました。
小さな実装から始める
四十七分という数字は、誰の会社にもある標準時間ではありません。この試行で、一つの作業を測って分かった数字です。それでも、私たちには大きな意味がありました。「AIを活用したい」という広い話を、来週もう一度確かめられる仕事に変えてくれたからです。
今でも、新しい技術を見つけると使い道を考えたくなります。ただ、提案する前に、誰の何を軽くするのかへ戻ります。速くなっても確認が追いつかないなら、まだ現場で使える形ではありません。導入したことと、定着したことは分けて見るようになりました。
今はツール導入より、使い続けられる業務設計と社内ルールづくりを支援しています。大きな開発を決める前に、毎週繰り返している一作業から検証しています。何を変えられるか分からない段階でも、普段の手順を聞くところから始められます。
明日、自分の仕事に持ち帰るなら
顧客理解：AIで何ができるかではなく、誰のどの作業を、どこまで安全に軽くするのか。
小さな実証：公開可能な情報だけで報告文の下書きを作り、人が確認する小さな試行から始めました。
仕事の境界：最終判断は人が行い、機密情報を入れず、ログ・権限・利用サービスの条件を案件ごとに確認します。