システムを起点とした裏側でのAI自動処理の導入

AIツールを導入したものの、使われる回数が伸びない。
この課題の対策として、研修を増やしたり事例を共有したりする打ち手がよく取られます。

どれも有効ではあるのですが、人が使うという前提そのものを一度外すと、別の道が見えてきます。
組織のAI活用には、大きく2つのアプローチがあります。

ひとつは、人がトリガーになってAIを起動する「表側」の活用です。
もうひとつが、いつもの業務をこなしているだけで「裏側」でAIが動いている状態を作るアプローチです。

今回は、後者にあたるシステム起点のAI処理について書いていきます。
自動化の手段全体の見取り図はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

表側のAIは個人のやる気に依存する

導入初期は、変化を実感しやすい表側の活用に意識が向きがちです。
自分で使って便利さを体感してもらう段階なので、これ自体は正しい順番です。

ただ、人が都度立ち上げて使うスタイルだけだと、利用頻度を伸ばすのにどうしても限界がきます。
理由はシンプルで、AIを使うかどうかの判断が、その人のやる気とリテラシーに委ねられているからです。
「今日は忙しいから」「急ぎだから使い慣れた手でやろう」と感じて手が伸びません。

研修で得た熱量も、日常の業務に戻って数週間もすれば静かに薄れていきます。
つまり、表側の活用だけで組織全体の底上げを狙うと、常に働きかけ続ける必要が出てきます。

研修のあとに使う業務を決め、4週間かけて仕事に組み込む流れは、研修後のフォローの進め方で扱っています。

また、表側の活用には成果が個人に閉じるという弱点もあります。
「この使い方、便利だった」と見つけた人が異動すると、その工夫ごと業務から消えます。
裏側に作り込んだ処理なら、担当が変わっても同じ形で回り続けるので、組織に残る資産としての性格が強くなります。

ここで効いてくるのが、裏側で勝手に動く仕組みです。
個人の意識と無関係に処理が走るので、利用の波がなくなります。

情報のバケツリレーを人がやっている

情報は、誰がメールとAIのあいだを運んでいるのでしょうか？
構造の違いを、営業の事前調査を例に見てみます。
人がトリガーになる場合、問い合わせのメールが届いたら、担当者が会社名やURLをコピーしてAIツールに貼り付けます。
出てきた分析結果を読んで、必要な部分を顧客管理システムに転記します。

この流れで起きているのは、人間がメールとAIのあいだで情報を運んでいることです。
AIが分析している時間より、人が貼り付けたり転記したりしている時間のほうが長い、ということも珍しくありません。
しかも、人が動かない限りAIも動きません。

効果を考えるときは、1件あたりの短縮時間だけでなく、発生の頻度も合わせて見ます。
1件5分の作業でも、月に200件あれば無視できない量になります。
逆に、1件30分かかっていても月に2件なら、作り込む価値は薄いという判断になります。

裏側に回すというのは、この運搬を人の手から外すことです。
フォームからデータが届いた時点を起点にして、AIが対象サイトを読み、自社のサービス資料と照らして提案の切り口を生成します。
結果がチャットや顧客管理システムに自動で追記されます。

このプロセスに人は一切介在していません。
担当者が画面を開いたときには、すでに分析と提案の切り口が用意されている状態になります。

システム上のイベントをトリガーにする

裏側の仕組みは、何をきっかけに動かせばいいのでしょうか？
起点になるのが、システム上で発生するイベントです。
何かが起きたことを合図にして処理を走らせます。
起点を選ぶときのコツは、業務の始まりに近いところを取ることです。

担当者が着手する直前ではなく、データが社内に入ってきた瞬間を起点にすると、人が待つ時間そのものがなくなります。
フォームに回答が入った、特定のフォルダにファイルが置かれた、表計算シートに行が追加された、チャットの特定チャンネルに投稿された、日付が変わった。
どれも人が意識せずに発生している出来事です。

このとき、データの置き場所が整理されているかどうかが効いてきます。
表計算シートを起点にする構成は取り回しがよく、最初の一歩としては組みやすいです。
考え方はスプレッドシートを社内DBとして扱う。AI自動化の土台設計で扱っています。

どのツールで組むかについては、処理の内容と運用する人によって答えが変わります。
判断の軸は業務自動化はどのツールで作る？Gem・GAS・Canvasの判断基準に整理してあります。

もうひとつ注意したいのが、裏側の処理は業務フローが固まっていないと作れないことです。
人がやっている段階なら、その場の判断で例外を処理できますが、自動化するとその判断は書き下しておく必要があります。
手前の整理については複雑な自動化の前に取り組むべき「業務の標準化」と再設計にまとめています。

裏側に向く業務、表側が要る業務

裏側に回していい業務と、人が握っておくべき業務は、どう見分ければいいのでしょうか？
表側を否定したいわけではありません。
意識的に使うAIと、無意識に動くAIでは、そもそも役割が違います。
判断の目安として、その作業をマニュアルに書き下せるかどうかを考えてみると分かりやすいです。

手順として書けるなら裏側に回せますし、その都度考えて決めていると答えるなら、まだ人が握っておくべき工程だという整理になります。
裏側に向いているのは、発生のタイミングが決まっていて、やることが毎回同じ業務です。
問い合わせが来たら調べる、日次で集計する、ファイルが届いたら形式を変換する。
ここは人が判断する余地が少ないので、自動化すると効果がまっすぐ出ます。

逆に、表側が向いているのは、何を作るかを人が考える必要がある業務です。
「提案の方向性を練る」「資料の構成を決める」「文章の表現を選ぶ」。
ここを自動化すると、出てきたものを人が直す手間のほうが大きくなります。

実際には、ひとつの業務のなかで両方が混ざっていることが多いです。
調べて整理するところまでは裏側に任せて、そこから提案の方向性を決める部分は人がやる。
工程を分けて考えると、全部を自動化しようとして詰まる事態を避けられます。

大事なのは、最初からこの2つの選択肢を持っておくことです。
この業務は人が考えてAIに指示すべきか、それともデータが来た時点で処理できるものか。
この見極めが先にできると、実装の手戻りがなくなります。
業務の切り出し方は業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順が参考になります。

動かなくなったときのことを先に決めておく

処理が止まったとき、誰が気づくのでしょうか？
裏側の処理には、表側にはない注意点があります。
誰も見ていないところで動いているので、止まっても気づかれにくいことです。
人が起動する仕組みであれば、動かなかった時点で本人が気づいて誰かに聞きに行きます。

一方で自動処理は静かに失敗するので、半月ほど経ってから、「そういえば、あの追記が最近来ていない」と誰かが気づく、という発覚の仕方になりがちです。
そのため、作る段階で最低限のことを決めておきます。
「誰へ通知が飛ぶのか」「通知を受けた人は何をどこまでやるのか」「誰がこの仕組みの責任者なのか」。
この3点が決まっていない自動処理は、壊れた時点で放置される可能性がかなり高いです。

通知の飛ばし先は、個人ではなくチャンネルにしておくのがおすすめです。
個人宛にすると、その人が休んでいる日や異動したあとに通知が宙に浮きます。
チームの目に入る場所へ流しておけば、誰かが気づける状態を保てます。

もうひとつ、出力の中身が劣化していないかを見る仕組みも要ります。
エラーは出ていないけれど、参照している資料が古くなって内容がずれている、というのは気づきにくい壊れ方です。
月に一度、直近の出力をいくつか目視で確認する運用を入れておくと安心です。

私たちのAI伴走支援では、こうした裏側で動くAIワークフローの実装も、現場の担当者と一緒に手を動かしながら進めています。

起点を人からイベントに移すと、AIは動き続ける

表側のAIだけで利用回数を伸ばそうとすると、個人のやる気とリテラシーに依存し続けることになります。
裏側の活用は、システム上のイベントを起点にして、人を介さずに処理を走らせるアプローチです。
起点にできるのは、フォームへの回答やファイルの追加、行の追加、決まった時刻など、人が意識せずに発生している出来事です。
業務の始まりに近いところを取ると、担当者が着手を待つ時間そのものを消せます。

向いているのは、発生のタイミングが決まっていて毎回同じことをする業務です。
向いていないのは、何を作るかを人が考える必要がある業務です。
この2つを最初から使い分けられると、手戻りが減ります。

裏側の処理は止まっても気づかれません。
失敗時の通知先と責任者、出力を定期的に見る運用を、作る段階で決めておきます。
作る順番としては、いきなり全工程をつなげず、通知だけを自動化してみるのも良い入り方です。
データが届いたことをチャットに流すところまでを先に作ると、起点が正しく取れているかを安全に確かめられます。

まずは自部署の業務のうち、何かが届いたら毎回同じことをしている作業を3つ、洗い出してみてください。