高度なAIワークフロー開発における段階的構築プロセス

カスタムボットを作れる人が増えてきた組織では、次のステップとして本格的なワークフロー構築に進む動きが出てきます。

複数の処理を連携させて、一連の業務をまとめて自動化する段階です。
「ボットが作れるなら、ワークフローも作れるだろう」と考えがちですが、これは別の作業です。

前者は言葉のやり取りを設計する仕事ですが、後者にはシステム的な思考が要ります。
同じ感覚で始めると、原因の分からないエラーで止まります。

今回は、高度なワークフロー開発を最小構成から始めて広げていく手順を書いていきます。
どこまで小さく切るかという業務側の分解はワークフローのAI化を成功に導く最小単位からの構築プロセスで扱っています。

ワークフロー構築で、考えることが一気に増える

カスタムボットの開発は、直感的に作って試すサイクルが回しやすい作業です。
指示を書いて、出力を見て、書き直す。
この繰り返しで精度が上がっていきます。

ただ、それが通用するのはボット作りまでです。

一方、複数の処理を連携させるとなると、代表的な論点が3つ増えます。

まず、工程間のデータの受け渡しです。
前の処理が出した結果を、どういう名前で保持して、次の処理にどう渡すか。
ここが曖昧だと、途中で値が消えたり、意図しないものが渡ったりします。

次が、入力側の整形です。
メール本文、フォームの回答、添付ファイル。
「形式がばらばら」のまま渡すと、処理が安定しません。
AIが読める形に整えてから渡す工程が必要になります。

最後が、出力側の加工です。
AIが返してくるのは自然な文章なので、そのままでは次のシステムが受け取れないことが多いです。
決まった形式で返させて、受け手が扱える形に変換する処理が要ります。

3つの論点のほかに、ボット作りとの大きな違いとして、「試すたびに時間がかかる」ことがあります。
ボットなら数秒で結果が返りますが、連携させた処理は1回の検証に数分かかることもあります。
試行の回数が限られるぶん、一度に変える箇所を絞って進めないと、どの変更が効いたのか分からなくなります。

このあたりを最初から全部組もうとすると、どこで失敗しているのかが分からなくなります。
高度なワークフローほど、最初から全体を作らないのが鉄則です。

コア部分だけの、プロトタイプから始める

作り始めるときに最初にやるのは、工程の分解です。
例えば、メールを受信して内容を分類し、顧客管理システムを照会して回答案を作り、チャットに通知する、という長い流れがあるとします。
これをいきなり全自動にせず、最も価値があって検証が必要な部分を特定します。

中心をどこに見るかは、どう決めればいいでしょうか？
人が時間を使っている工程と、判断が必要な工程のどちらに近いかで考えると分かりやすいです。
単純な転記だけの工程は後回しでよく、内容を読んで判断している部分こそ先に検証したいところです。

この例なら、システムを照会して回答案を作る部分がそれに当たります。
前後のメール受信と通知は、しばらく手動のままで構いません。
コピーして貼り付ける手間は残りますが、まず中心の工程が成立するかを確かめます。

ここでの目的は、完成度ではありません。
この工程をAIに任せれば、期待する出力のベースが出るという手応えを掴むことです。

実用レベルまで作り切ろうと意気込む必要はありません。
この過程で得られるものは大きいです。

工程をもう一段分けるべきか、データを事前に整形しないと精度が出ないか、といった判断材料が実感として溜まります。
作って動かしながら決めるという進め方は完璧な仕様を待たない。「作って動かす」を組織の作法にするにまとめてあります。

広げる前に、縦の精度を固める

プロトタイプが動いたら、次は横に広げたくなります。
ただ、その前に中心の工程の精度を実用レベルまで引き上げるほうが先です。

やることは3つあります。
1つは指示の具体化です。
曖昧な指示は出力のブレを生むので、判断の条件や出力の形式を明示的に書き下します。

具体化の進め方としては、うまくいかなかった出力を10件ほど集めて、外し方のパターンを分類するのが早いです。
長すぎる、判断が甘い、指定した項目が抜けている。
パターンが見えれば、直すべき指示の箇所も自然と絞られてきます。

もう1つが、参照データの整備です。
AIに読ませる資料を、検索しやすい形に加工し直します。
「整形の工程を飛ばして精度が出ない」まま進むケースは多いです。
整理の考え方は膨大なデータを扱う際の中間データ作成と精度向上のアプローチで扱っています。

残る1つが、想定外の入力への備えです。
空のデータが来たとき、極端に長い本文が来たとき、対象外の内容が来たとき。
そのまま処理して変な答えを返すより、処理を止めて通知するほうが安全な場面は多いです。

ここがぐらついている状態で連携を広げると、システム全体が不安定になります。
どこで失敗しているのかも追いにくくなる。
先に縦を固めるのは、後の手戻りを減らすためです。

つまずいたときは、境目と形式と挙動を見る

作っている途中で動かなくなったとき、どこを見ればいいかの当たりを持っておくと復旧が速くなります。
まず確認するのが、工程の境目で何が渡っているかです。
処理そのものが正しくても、渡ってきた値が空だったり、想定と違う形式だったりすると結果は崩れます。
各工程の出力を一度そのまま記録しておく仕組みを入れておくと、切り分けが一気に楽になります。

次に見るのが、「出力の形式が守られているか」です。
決まった形で返すよう指示していても、入力の内容によっては説明文が付いて返ってくることがあります。
形式が崩れる前提で、受け取る側に余裕を持たせておくのが実務的です。

そして、失敗したときの挙動です。
エラーで止まるのか、空のまま次に進むのかで、影響範囲がまったく変わります。

「途中で止まったら前の工程まで戻せるか」「二重に実行されないか」も、あらかじめ決めておきたいところです。
こうした確認を繰り返していくと、精度が出ない原因の多くは処理の重さではなく、渡しているデータの側にあると分かってきます。
段階を分けて処理する考え方はAIの精度が低いと言われる前に。段階処理を現場の標準手順にするに整理してあります。

精度が安定したら、そのあとで横に広げる

中心の精度が安定したら、手動で残していた前後の工程をつないでいきます。
入力側は、フォームの送信やメールの受信を起点にして、データが自動でAIに渡るようにします。
出力側は、AIが作った結果をチャットや顧客管理システムへ自動で書き込むようにする。
起点の取り方はシステムを起点とした裏側でのAI自動処理の導入に整理してあります。

つないだ直後は、「しばらく人が結果を見る」期間を置くのがおすすめです。
1週間ほど出力を目視で確認して、想定外の入力がどれくらいの頻度で来るかを掴んでおくと、そのあとの運用が落ち着きます。

先に中心を固めてから前後をつなぐ順番で進めると、問題が起きたときの切り分けが楽になります。
中心の処理は既に検証済みなので、「疑うべきは新しくつないだ部分だ」とすぐに分かる。
最初から全部つないでいると、この切り分けができません。

広げる段階では、コストの確認も入れておきます。
「手動なら1日数回だったのに」というくらい、自動化すると想定より多く走ることがあります。
考え方は全社規模のAIワークフロー運用におけるコスト設計と最適化にまとめてあります。

広げる幅も一度に増やさないほうが安全です。
入力側をつないで安定を確認してから出力側に進む、という順番にしておくと、問題が出たときに戻す場所がはっきりします。

つなぐ前に、業務側の手順が固まっているかも確認します。
「例外はどう判断するか」が口頭で回っている段階だと、自動化した瞬間に破綻します。
担当者の頭の中にしかない判断基準を書き下すところまでが、横に広げる前の準備になります。

判断基準を書き下すところから一緒に手を動かすのが、当社のAI伴走支援です。
業務の洗い出しから、AIワークフローの実装までを扱っています。

縦を固めてから横に広げると、迷わない

ワークフロー構築では、工程間のデータ受け渡し、入力の整形、出力の加工という3つが新しく増えます。
ボット作りと同じ感覚で全体を組むと、原因の分からないエラーで止まります。

進め方は、まず工程を分解して、最も価値のある中心部分だけをプロトタイプにすること。
前後は手動のままで構いません。
目的は完成度ではなく、「この工程は任せられる」という手応えを得ることです。

次に、縦の精度を固めます。
指示の具体化、参照データの整備、想定外の入力への備え。
ここが固まる前に横へ広げないことが、手戻りを減らす最大のポイントです。

そのうえで、入力と出力を自動でつないでいきます。
この順番なら、問題が起きたときに疑う場所がはっきりします。
つまずいたときに見るのは、工程の境目で何が渡っているか、出力の形式が崩れていないか、失敗したときにどう振る舞うかの3点です。

各工程の出力を記録しておく仕組みを先に入れておくと、切り分けの時間が大きく変わります。
自動化したい業務を工程に分けたとき、その中心はどこにあるでしょうか。