ワークフローのAI化を成功に導く最小単位からの構築プロセス

複数ツールを連携させたワークフローのAI化について、相談を受ける機会が増えています。

ただ、いざ作り始めると、最初から欲張ってしまうケースが多くあります。
一気に全体をつなごうとしてエラーが頻発し、そのまま止まってしまう光景をよく見かけます。
ここで効いてくるのが、どこまで小さく切り出すかという判断です。
開発の技術的な段取りは高度なAIワークフロー開発における段階的構築プロセスにまとめてあるので、今回は「業務のどこをどう分けて、どこから着手するか」を書いていきます。

業務プロセスは細かく分けて、役割まで決めて安定する

最初にやるべきなのは、対象の業務プロセスを細かく分解することです。
そのうえで、AIに任せる部分と人が確認する部分を、極限まで切り分けます。
この工程を飛ばすと、あとから複雑なエラーに対処できなくなります。
「どこまでがAIの担当で、どこから人の判断か」が曖昧なままだと、問題が起きたときに何が原因か分からなくなるからです。

分解する業務そのものを決めかねているときは、業務の洗い出しからAI化の優先順位までの手順が先になります。

例えば、問い合わせ対応から顧客管理ツールへの登録、社内チャットへの通知までの流れがあるとします。
最初から全部つながず、それぞれのタスクを独立したブロックとして捉えるところから始めます。

内容を読んで分類する、顧客情報を照会する、登録する形式に整える、システムに書き込む、担当者に知らせる。
並べてみると、性質の違う作業が混ざっていることが分かります。
判断が必要なもの、単純な転記、外部システムとのやり取り。
「これはどっちに当たるか」を意識するだけで、着手する順番も自然に決まってきます。

切り分けのとき、人が確認する場所は最初から多めに残しておくほうが安全です。

あとから確認を減らすのは簡単ですが、一度なくした確認を戻すのは、事故が起きてからになりがちだからです。
とくに社外に出ていく内容や、金額に関わる処理は、しばらく人の目を通す前提で設計しておきます。

分解のときに一緒に見ておきたいのが、「その工程が1日に何回発生しているか」という数字です。
判断が必要でも月に2回しか起きない工程は、自動化しても効果が見えにくいものです。
逆に、単純な転記でも1日に何十回も起きている工程なら、そこを外すだけで体感が変わります。
頻度と難易度の両方を並べておくと、着手する順番の議論が早く終わります。

業務を洗い出すところから始める場合はAI化する業務が見つからない。全社一斉の業務棚卸しの設計が参考になります。
フロー自体が揃っていない場合は複雑な自動化の前に取り組むべき「業務の標準化」と再設計を先に見ておくとつながります。

最小単位まで切ると、成否が一言で判定できる

分解できたら、次はもっと小さい単位で着手します。
最初から複数の処理を連携させたり、複雑な条件分岐を組んだりするのは避けます。
やるのは、最小単位のタスクをひとつだけAI化して試すことです。
先ほどの例でいえば、問い合わせの本文から「顧客名だけを抽出する」という単一の処理を作ります。

これだけなら、うまくいかなかったときに原因がはっきりします。
抽出そのものができていないのか、抽出はできているが形式が揃わないのか、そもそも本文に情報が含まれていないのか、切り分けの候補が数えられる状態になるからです。
確実に動く単体のモジュールを持っていることが、安定したワークフローの土台になります。

小さく作ると、検証にかかる時間も短くて済みます。
1回の実行が数秒で終わるので、指示を書き換えて試すサイクルを何十回も回せるからです。
この回転数の差が、そのまま完成までの期間の差になってきます。

切り方の目安は、「その処理の成否を一言で判定できるか」どうかです。
顧客名が取れたかどうかは、見れば分かります。
一方で、適切に対応できたかどうかは判定できません。
判定できない単位で作ると、直すべき場所も見えなくなります。

実データで動かすと、想定外の入力が必ず来る

作った最小単位の仕組みは、必ず実際のデータで動かします。
ここを飛ばして次に進むと、あとでまとめて破綻するからです。
想定外の入力は必ず来ます。
名前が入っていない問い合わせ、複数社の名前が混ざっている本文、署名だけで本文が空のメール。

机上で考えていても出てこないパターンが、実運用では普通に発生します。
テスト用のデータは、きれいなものを選ばないのがコツです。
整った事例だけで検証すると、本番で崩れます。

むしろ、過去に担当者が処理に困った案件を10件ほど集めて、それで通るかを見るほうが実態に近い検証になります。
手を動かして試行を繰り返すことでしか、精度は上がりません。
このとき、外れたケースを記録に残しておくと改善が速く進みます。

「どんな入力で外れたか」の一覧があれば、指示をどう直せばいいかが見えてきます。
確認を担当する人も決めておきます。
作った本人が見続けると、期待どおりに動いているように見えてしまうことがあるからです。
その業務を実際にやっている担当者に見てもらうと、出力の細かいずれに気づいてもらえます。

期間の目安は、2週間ほど人が結果を確認しながら運用してみることです。
そのあいだに出てきた例外を潰してから次に進むと、広げたあとの手戻りがかなり減ります。
作りながら直していく進め方は完璧な仕様を待たない。「作って動かす」を組織の作法にするにまとめてあります。

幅と深さは、似た業務の数で使い分ける

単体のタスクが安定して動くようになったら、そこから広げていきます。
広げ方には、幅と深さという2つの方向があります。
ここで、自分の業務は幅と深さのどちらに向いているでしょうか？

幅の拡張は、安定した仕組みを別の似たワークフローに横展開することです。
問い合わせから顧客名を抽出する処理ができたなら、同じ形を採用サイトからの応募や資料請求の処理にも当てはめられます。
作り直す部分が少ないので、費用対効果は高くなります。

深さの拡張は、次の工程とつなげていくことです。
抽出したデータを顧客管理ツールに自動入力し、その結果をチャットに通知すれば、一連の流れとして完成に近づきます。

判断材料は、「同じ形の業務が社内にいくつあるか」です。
似た処理が3つ以上あるなら、幅に広げたほうが早く効きます。
ひとつしかないなら、深さに進んでその業務を仕上げるほうが価値になります。

どちらを先にやるかは、目的によって変わります。
効果を早く広げたいなら幅、その業務を完全に自動化したいなら深さです。
両方を同時に進めると、どちらも中途半端になりやすいので、まずどちらかに絞ります。
事例を別部署へ広げるときの考え方は特定部署のAI成功事例を全社へ展開する抽象化アプローチで扱っています。

小さく作る進め方は、失敗の共有とセットで定着する

ここまで書いてきた進め方を、推進チームだけが知っている状態にしておくのはもったいないです。
現場でツールを作る人が増えてくると、同じつまずき方をする人が次々に出てくるからです。

そのため、最小単位から作るという進め方自体を、社内の標準として配るのが有効です。
いきなり全体を組まない、まず1つの処理だけ作る、実データで2週間試す、それから広げる。
この4つを手順として渡しておくだけでも、挫折する人はかなり減ります。

配るときは、うまくいった事例と一緒に渡すと効果的です。
手順だけを渡すと守られませんが、「この進め方でこの業務がこうなった」という結果が添えてあると、やってみようという気持ちにつながります。

推進チーム側も、自分たちが詰まった話を先に出しておくと場の空気が変わります。
うまくいっている人だけが発信する状態になると、相談のハードルだけが上がっていくからです。
あわせて、うまくいかなかった事例も共有できる場を作っておきます。
成功事例だけが並ぶと、失敗している人が相談しにくくなります。

もちろん、うまくいった話のほうが集めやすいのは確かです。
ただ、「この入力で外れた」という情報のほうが、次の人には役に立ちます。
内製を組織として支える体制については社内AIツールの内製化。現場が自分で作れる組織にするまでに整理してあります。

こうした進め方を社内で回し始めるところは、当社のAI伴走支援でも、業務の洗い出しからAIワークフローの実装まで、現場の担当者と一緒に手を動かして進めています。

小さく作って直してから、広げる

ワークフローのAI化で失敗する最大の原因は、最初から全体をつなごうとすることです。
進め方は4段階です。
まず業務プロセスを分解して、AIに任せる部分と人が確認する部分を切り分けます。

次に、これ以上小さくできない単位をひとつだけAI化します。
「判定できる単位で切る」のがポイントです。
そして、実データで2週間ほど動かして、外れたケースを記録しながら直します。

想定外の入力は必ず来るので、ここを飛ばせません。
広げる前には、いま動いているものを誰が面倒を見るのかも決めておきます。
作った本人が次の開発に進んでしまうと、最初に作った処理の面倒を見る人がいなくなるからです。
数が増えるほど、この管理の設計が効いてきます。

安定したら、幅か深さのどちらかに広げます。
効果を早く広げたいなら幅、その業務を完全に自動化したいなら深さです。
自動化したい作業のなかで、どこが一番小さく切り出せるかを見極めることが、最初の一歩になります。