ソリューション
耐久性とオブザーバビリティを備え、人の統制下にある自動化
私たちは、ワークフローエンジン、ドキュメント処理、AIエージェントを用いて、複数ステップからなる業務プロセスを自動化します。決定論的なルールで足りる箇所にはルールを、非構造化入力に対する判断が必要な箇所にはAIを選びます。
課題の全体像
組織における業務の大半は、システムをまたぐプロセスです。請求書がメールで届き、ERP上の発注書と突き合わされ、マネージャーが承認し、帳簿に計上され、支払われます。プロセスをシステムからシステムへ運んでいるのは人であり、データを再入力し、次に何をすべきかを覚えています。自動化は、この運搬をなくします。それをうまく行うには、自動化されたプロセスが、置き換えられる人と少なくとも同程度に信頼でき、かつ人よりも中身を確認しやすいものでなければなりません。
こうしたプロセスのステップには2種類あります。1つは、完全に仕様化できるステップです。金額がしきい値未満で、取引先が承認済みであれば、支払いに回す、といったものです。これらは決定論的なコードまたはルールエンジンに置くべきで、そこでは高速、低コスト、テスト可能、かつ説明可能になります。もう1つは、非構造化入力や判断を伴うステップです。スキャンされた文書を読む、顧客からのメールを分類する、返信を下書きする、曖昧な参照が複数のレコードのうちどれを指すのかを決める、といったものです。言語モデルが真価を発揮するのはここです。
エンジニアリング上の課題は、統制を失うことなくこの2つを組み合わせることです。ツールを呼び出せるAIエージェントは強力であり、かつ非決定論的です。型付けされた入出力、範囲を限定した権限、検証、そして要所での人による承認を備えた耐久性のあるワークフローの中に置けば、エージェントは実際の業務を任せられるコンポーネントになります。本番システムに対して自由に動かしたままでは、そうはなりません。
なぜ難しいのか
エンジニアリング上の課題
誰にも気づかれずに失敗する自動化
スケジュール実行のスクリプトが3番目のステップでエラーを出して止まります。リトライする仕組みはなく、誰にも通知されず、中途半端な処理は顧客から苦情が来て初めて見つかります。状態の永続化と可視性がなければ、どの自動化も隠れた負債になります。
ルールで足りる箇所へのAIの適用
ロジックが完全に分かっている判断を言語モデルに渡すと、実行のたびにコスト、レイテンシー、わずかな誤答の可能性が加わり、結果の説明も難しくなります。逆の誤りも同じくらいよく見られます。モデルなら容易に扱える自由記述のテキストを、何百もの壊れやすいルールで解析しようとするケースです。
権限を持ちすぎたエージェント
広範なAPI認証情報と範囲の定まらない目標を与えられたエージェントは、誰も意図していないアクションを取ることがあります。読み込んだ文書に注入された命令が含まれている場合は、特にそうです。リスクは、エージェントが持つ権限に比例して大きくなります。権限はタスクごとに範囲を限定し、影響の大きいアクションには関門を設けなければなりません。
ドキュメントのばらつき
請求書、帳票、契約書は、スキャン画像、写真、PDFとして、何百ものレイアウトで届きます。テンプレートベースの抽出は、取引先が書式を変えた時点で機能しなくなります。抽出には、信頼度スコア、既知のデータとの突合による検証、そして不確かなケースを人に回す経路が必要です。
システムをまたぐ部分的な失敗
あるプロセスがCRMを更新した後、ERPの更新に失敗します。最初からリトライすれば1つ目の更新が重複し、そこで止めればシステム間に不整合が残ります。各ステップは冪等である必要があり、プロセスには、完了できないステップに対する補償処理を定義しておく必要があります。
後回しにされる人の承認
メールで処理される承認には、期限も、エスカレーションも、プロセスに紐づく記録もありません。業務は受信トレイの中で止まります。人が行うタスクは、担当者の割り当て、タイムアウト、代理承認、監査証跡を備えた、プロセスの正式なステップでなければなりません。
構築の進め方
アーキテクチャ
プロセスは、すべてのステップを永続化する耐久性のあるワークフローエンジン上で実行します。決定論的なルール、ドキュメント処理、AIエージェントは型付けされたコントラクトを持つアクティビティとして呼び出し、人による判断は明示的なタスクとしてモデル化します。
- 01
耐久性のあるワークフローエンジン
TemporalのようなエンジンやCamundaのようなBPMNプラットフォームが、各プロセスを永続化されたステートマシンとして実行します。ワーカーがクラッシュしても、プロセスは最後に完了したステップから再開します。リトライ、タイムアウト、タイマーはワークフロー定義の中で宣言し、プロセスはリソースを保持することなく、外部イベントを何日でも待つことができます。
- 02
連携コネクター
各外部システムには、認証、レート制限、ページネーション、エラーマッピングを扱うコネクターを通じてアクセスします。コネクターの操作は、自然キーまたは冪等トークンを用いて冪等になるように設計するため、ステップがリトライされても重複レコードは作成されません。システムがAPIを提供していない場合は、最後の手段としてユーザーインターフェース経由のRPA（ロボティック・プロセス・オートメーション）を用い、同じインターフェースの背後に隔離します。
- 03
ルール・意思決定サービス
完全に仕様化できる業務ルールは、それを呼び出すワークフローとは切り離し、バージョン管理されたデシジョンテーブルまたはコードとして意思決定サービスに置きます。これにより、ポリシーの変更を単独でレビューし、テストできます。すべての評価について入力、ルールのバージョン、結果を記録するため、自動化されたどの判断についても直接の説明が可能です。
- 04
ドキュメント処理パイプライン
受信したドキュメントは分類した後、OCR（光学文字認識）とレイアウト解析にかけ、文書種別に適したモデルで項目を抽出します。抽出した値は、ERP上の取引先や発注書との照合など、参照データに対して検証し、信頼度スコアを付与します。信頼度の高い結果は自動的に先へ進み、それ以外は、原本と抽出された項目を並べて表示するレビュー画面に回します。
- 05
AIエージェントランタイム
エージェントは、定義された目標、固定されたツールセット、そしてステップ数、時間、費用の上限とともに、ワークフローのアクティビティとして呼び出します。ツールは型付けされたパラメーターを持つ用途の狭い関数であり、タスクに範囲を限定した認証情報で実行します。エージェントの出力はスキーマに準拠していなければならず、ワークフローがそれに基づいて動作する前に検証を通過します。また、エージェントが読み込むコンテンツは信頼できないデータとして扱います。
- 06
ヒューマンタスクサービス
承認、レビュー、例外対応は、期限、エスカレーション経路、代理承認のルールとともに、ロールまたは個人に割り当てるタスクです。レビュー担当者は、自動化が用いた根拠と提案されたアクションを確認し、承認、修正、または却下できます。その判断はワークフローインスタンスに対して記録され、ワークフローを再開させます。
- 07
プロセスのオブザーバビリティ
すべてのワークフローインスタンスについて、現在のステップ、履歴、入力、出力を確認できます。ダッシュボードは、スループット、サイクルタイム、失敗率、人の介入なしに処理された案件の割合を報告し、AIを用いるステップについては、維持管理している評価セットに対する品質も報告します。失敗したインスタンスは運用キューに表示され、そこで内容の確認、修正、再開ができます。
推論
- 01
トリガー
イベント、スケジュール、ユーザー要求
- 02
計画
目標を範囲の限られたステップに分解
- 03
ツール呼び出し
型付きツールによる読み取り専用の参照
- 04
アクション案
根拠を添えた変更の提案
統制下の実行
- 01
ポリシーチェック
上限、権限、リスク評価
- 02
人による承認
影響の大きいアクションで必須
- 03
実行
対象システムへの冪等な書き込み
- 04
検証
結果を確認し、再試行またはロールバック
- 05
監査
全ステップを記録し、再生可能に
プロジェクトの成果物
- ルールベースのステップと判断ベースのステップを特定するプロセス分析
- 耐久性のあるエンジン上にデプロイされたワークフロー定義
- 関係するシステムへの冪等なコネクター
- 信頼度のしきい値とレビュー画面を備えたドキュメント抽出パイプライン
- AIエージェントのツール、権限スコープ、評価セット
- エスカレーションルールを含む承認と例外処理
- 運用ダッシュボードと、失敗したインスタンスに対するランブック
着手する前に
早い段階で決めておくべきこと
- あるステップにルールを使うか、AIを使うか
- 入力が構造化されており、ロジックを完全に書き下せる場合はルールを使います。ルールのほうが安価で高速であり、監査も可能です。入力が非構造化である場合や、ケースの多様さゆえにルールでは管理しきれない場合はAIを使います。基本形として有効なのは、モデルが抽出と分類を行い、その後にルールが判断する構成です。こうすれば、判断そのものは決定論的なまま保たれます。
- 人による承認をどこに置くか
- 誤りの代償が大きい箇所、あるいは取り返しのつかない箇所に置きます。支払い、社外への連絡、契約の変更、そして顧客の法的な立場に関わるあらゆるものが該当します。信頼度のしきい値を使い、人がすべてのケースではなく不確かなケースをレビューするようにします。しきい値は、実績が蓄積するにつれて見直します。人のステップを外すことは、意図的に行い、記録に残す判断であるべきです。
- ワークフローエンジンか、イベントコレオグラフィか
- プロセスに定まった順序があり、状態を明確に把握する必要があり、補償ロジックを持つ場合は、ワークフローエンジンを使います。独立したシステムが事実に反応し、フロー全体を所有する単一の主体がいない場合は、イベントコレオグラフィを使います。コレオグラフィによる長い連鎖は追跡も変更も難しいため、中核となる業務プロセスには、通常オーケストレーターのほうが適しています。
- 高機能なエージェント1つか、用途の狭いエージェント複数か
- 小さなツールセットと単一の責務を持つ用途の狭いエージェントを、ワークフローで組み合わせる構成を優先します。評価しやすく、実行コストが低く、1つの失敗が及ぼす影響も限定されます。多数のツールを持つ単一の汎用エージェントは、始めるのは簡単ですが、予測、テスト、セキュリティ確保が難しくなります。
FAQ
よくあるご質問
RPA（ロボティック・プロセス・オートメーション）とは何が違いますか。
RPAはユーザーインターフェースを通じてアプリケーションを操作します。APIが存在しない場合には有用ですが、画面が変わると壊れやすい手法です。ここで述べるアプローチでは、可能な限りAPIとイベントを通じて連携し、プロセスの状態をワークフローエンジンに永続化し、非構造化入力にはAIを用います。UIの自動操作は、他に手段のないシステムに限って使います。
AIエージェントは監督なしでアクションを実行できますか。
影響が小さく取り消し可能なアクションであれば、そのタスクに範囲を限定した権限の中で実行できます。影響の大きいアクションは、人による承認ステップを経ます。その境界は、プロセスに責任を負う人とともにプロセスごとに定め、エージェントの判断に委ねるのではなく、ワークフローによって強制します。
ステップが失敗した場合はどうなりますか。
一時的な障害については、エンジンがバックオフ付きでリトライします。障害が解消しない場合、インスタンスは完全な履歴を保持したまま、可視化されたエラー状態で一時停止し、オペレーターがデータを修正してそのステップから再開できます。複数システムにまたがる操作では、補償アクションによって、すでに完了したステップを取り消します。
組織はどこから始めるべきですか。
頻度が高く、内容がよく理解されており、負担の大きいプロセスで、入力と結果を計測できるものから始めます。1つのプロセスを本格的なエンジン上でエンドツーエンドに自動化すれば、コネクター、承認のパターン、監視の仕組みが確立し、後続のプロセスで再利用できます。