既存業務のワークフローを置き換えずにAIエージェントを組み込む方法（エージェント用スキルファイルあり）

AIエージェントを実際の業務フローに組み込もうとすると、よく同じ問題に直面します。

AIに自由に判断させるとリスクがある一方で、ルールで細かく縛りすぎると、今度は想定外のケースにまったく対応できなくなります。

この板挟みは、説明責任が強く求められる現場ほど深刻な悩みです。

しかし、この二つを両立させる考え方も存在します。しかも稼働中のシステムを置き換えずに。

今後、現場の運用はどのように変わるのでしょうか。

※文末に、手法を手軽に試すための、AIエージェント向けスキルファイルを掲載しています。

AIエージェントを業務に組み込むと必ずぶつかる壁

従来の業務システムは、決められた手順を正確に繰り返すことを得意としています。しかし、想定外の状況には弱いという限界があります。規制が変わった、過去に例のない申請が届いた、外部システムが異常な応答を返した。こうした、設計時に想定されていなかった事態に対しては、エラーにするか、人間に引き継ぐかしかないのが実情です。

実際の業務では、頻繁に発生する定型パターンは自動化されている一方で、まれに起きる例外は自動フローの外で人手によって処理されています。少数のよくあるパターンが処理件数の大半を占め、その外側に多種多様な例外が長く広がっている。このようなロングテール型の分布は、業務プロセスではよく見られます。定型部分は自動化できても、裾野にある例外はなかなか人手から離れません。

では、すべてをAIに任せればよいのかというと、話はそう単純ではありません。業務の構成図をLLMに読ませ、実行計画を立てさせる方式は柔軟です。しかし、その計画が必ず手順どおりに実行されるとは限りません。監査要件を満たす保証も、コンプライアンス上のルールを守る保証もありません。同じ入力であっても、実行のたびに違う筋道をたどる可能性があります。規制の厳しい業務では、これは受け入れにくい問題です。

IBMの研究チームであるFabiana Fournier氏とLior Limonad氏が2026年6月に公開した論文では、この板挟みを「柔軟さと統制のどちらかを選ぶ問題」ではなく、「両立させる設計の問題」として捉え直しています。

まず既存システムに残す役割を決める

AIエージェントを業務に入れるとき、既存のワークフローエンジンをすぐに置き換える必要はありません。むしろ、監査対象の業務では、置き換えない前提で考えたほうが安全です。

業務の手順を保持し、実際の実行を進める役割は、これまでどおりワークフローエンジンに残します。そのうえで、AIはタスク、分岐点、流れの要所に関わり、判断を補助します。つまり、業務の骨格は既存システムが守り、AIはその外側で不足している判断力を補う位置づけにします。

この考え方の利点は、導入範囲を段階的に調整できることです。最初からプロセス全体をAIに任せるのではなく、一部の作業だけをAIに手伝わせる。効果と安全性を確かめながら、必要に応じて範囲を広げる。問題があれば元に戻す。このような導入経路を取れるかどうかは、既存資産を抱える組織にとって重要です。

ここで大事なのは、「AIを使うかどうか」ではなく、「既存システムに何を残すか」を先に決めることです。手順の実行までAIに渡してしまうと、柔軟にはなりますが、監査しにくくなります。まずは、実行基盤を残したまま、どの判断だけをAIに補わせるのかを切り分ける必要があります。

AIに任せる範囲は一気に広げない

AIに任せる範囲は、大きく3段階に分けて考えられます。重要なのは、これらを一気に有効にしないことです。まずは小さな単位で使い、必要な場所だけ段階的に広げるほうが、監査対象の業務には向いています。

段階①まずはタスク単位でAIを使う

最初の段階は、個々のタスクの中身をAIに担わせることです。あらかじめ書かれた固定スクリプトでは、構造化されていない入力や、答えが一つに決まらない問いに対応しにくい場合があります。

たとえば、申請内容の説明文を読み取り、必要な情報を整理する。顧客から送られた自由記述を分類する。こうした作業では、LLMの判断力を使える余地があります。

ただし、この段階でもAIを自由に動かすわけではありません。何をしてよいか、何をしてはいけないかをルールとして定め、その範囲内でタスクを実行させます。プロセス全体の形は変えずに、各タスクの対応力だけを引き上げる段階です。

段階②次に分岐判断の一部だけをAIに任せる

次の段階は、分岐点でどちらの経路に進むかの判断にAIを使うことです。ただし、すべての分岐をLLMへ任せる必要はありません。むしろ、まずは機械的に判定できる条件を先に評価すべきです。

条件が明確に決まる典型的なケースでは、その時点で進む経路を確定します。値が欠けている、例外的な閾値が関係する、単純な条件だけでは判断しにくい。こうした場合にだけLLMを呼び出します。

毎回AIを動かすと、コストや遅延が増えます。さらに、判断のばらつきも入り込みます。明らかなケースは従来のルールで処理し、固定ルールでは捌きにくいケースだけをAIに任せる。分岐判断にAIを使うなら、この切り分けが必要です。

段階③最後に流れの組み替えを検討する

最も自律性が高い段階では、AIが業務フローの要所を見て、必要に応じて手順そのものの組み替えを提案します。次の工程を飛ばす、別の工程へ迂回させる、処理を中断する、工程を差し込む、工程を取り除く。こうした介入が考えられます。

なかでも、まだ残っている任意の工程へ一気に飛ばす操作は強力です。フローの途中から最終工程へ進めたり、複数の中間工程をまとめて省略したりできます。

ただし、この段階は便利さとリスクが同時に増えます。業務フローそのものに影響するため、どの操作を許すのか、どの条件で許すのか、どの記録を残すのかを明確にしなければなりません。実務で使うなら、最初からここを目指すのではなく、タスク単位、分岐単位の制御ができてから検討するのが現実的です。

実行権限と判断権限を分ける

監査対象の業務にAIを入れるとき、最も重要なのは、AIに何を判断させるかではなく、その判断がどのように実行へ反映されるかです。判断と実行が同じ場所にあると、AIの出力がそのまま業務上の操作になってしまいます。これは監査や統制の面で扱いにくくなります。

手順そのものはワークフローエンジンが実行する

この設計で中心になるのは、プロセスの手順そのものをワークフローエンジンに残すことです。どの工程が次に動くのか、どの順番で処理が進むのかは、エンジンが管理します。

そのため、AIが判断に関わっていても、手順を大きく逸脱した実行は起こりにくくなります。構造の遵守はエンジンが担う。AIは、その構造の内側で必要な判断を補助する。この切り分けが、監査対象の業務では前提になります。

AIは実行せず、指示や提案にとどめる

AIはあくまで「指示」や「提案」までを担当し、実行そのものは行いません。AIが提案した介入を、実際にプロセスへ反映するかどうかはエンジン側が扱います。

この分離により、AIの柔軟さを使いながら、業務フロー全体の統制を維持しやすくなります。AIに直接実行させるのではなく、AIの判断をいったん別レイヤーで受け止め、許可された操作だけを実行に移す。ここを分けておかないと、AIの判断ミスがそのまま業務上の誤操作につながります。

許可された操作だけが反映される

統制は二重に設計する必要があります。一つ目は、LLMが何について考え、何を結論づけてよいかを定めるポリシーの層です。二つ目は、その結論のうち、実際にどの操作までを起こしてよいかをプロセスごとに列挙する許可の層です。

たとえLLMが禁止された操作を結論として出したとしても、その操作が許可されていなければ実行されません。許可の層で止められ、安全な既定動作に差し替えられます。たとえば、特別な介入は行わず、そのまま次の工程に進むといった挙動です。

この仕組みは、AIを信用しないためのものではありません。AIを業務で使うために、AIの出力がそのまま実行にならないようにするためのものです。

判断の記録をあとから検証できる形にする

この分離が特に必要になるのは、監査と説明責任が求められる現場です。どの工程が動いたのか、分岐がどのように判断されたのか、流れにどのような介入が入ったのか。これらはすべて、プロセス上の具体的な要素に紐づけて記録される必要があります。

一つひとつのAIの判断を、あとからルール文書と照らし合わせて検証できることが重要です。LLMにプロセス全体の計画を丸ごと委ねる方式では、この検証が難しくなります。規制業務でAIエージェントを使うなら、判断の自由度だけでなく、あとから説明できる粒度で記録が残るかを確認しなければなりません。

例外ルールはコードではなく管理可能な文書にする

業務でAIを使うとき、例外対応をどこに書くかも重要です。すべてをコードやワークフロー図に埋め込むと、規制や業務ルールが変わるたびにシステム改修が必要になります。一方で、文章で管理すればよいというだけでもありません。その文章が、誰に読めて、どう承認され、どの範囲に反映されるのかまで決める必要があります。

従来のワークフローは想定済みの例外しか扱えない

従来のワークフローでは、想定される逸脱をすべて、設計時に例外経路として図に書き込んでおく必要があります。書かれていないことは起こりえない、いわば「閉じた世界」です。

そのため、新しい例外を一つ追加するだけでも、ワークフロー図の改修やリリース作業が必要になります。業務のルールが頻繁に変わる現場では、この硬さが運用上の負担になります。

文章化されたルールから判断できる範囲を広げる

AIを使うことで、あらかじめ図に描かれた例外経路だけでなく、文章として与えられたルールから判断できるケースも扱えるようになります。対応できる事態の範囲は、ルール文書によって推論できる範囲に広がります。

ただし、これはAIが何でも自由に処理できるという意味ではありません。AIが判断できる範囲は、あくまで事前に与えられたルール文書の中に限られます。枠の外でLLMを自由に呼び出すのではなく、ルール文書の範囲内で判断させることが前提です。

ルール文書は独立して更新できるようにする

ここで扱われるルールは、マークダウン形式の文章として書かれます。人間が読めて、バージョン管理でき、プロセス本体やコードとは独立に更新できます。

タスク向け、分岐向け、流れの介入向けのルールを束ねた全体は、この設計案では「FRAME」と呼ばれています。ただし、実務上重要なのは名称ではありません。重要なのは、AI判断の根拠になるルールを、コードとは別の管理対象として扱うことです。

このようにしておくと、規制が変わったときに、ワークフロー全体を改修せず、ルール文書の更新で対応できる可能性があります。変更は、稼働中のインスタンスに対しても、その後の判断から反映される設計になっています。

文書で管理するからこそ統制が必要になる

ルールを文章で管理できることは、運用の柔軟性につながります。一方で、その文章が増えれば、文書そのものをどう統制するかが問題になります。

誰がこのルールを書くのか。誰が承認するのか。タスク向けのルールと分岐向けのルールが矛盾していないか。規制対応のために追加したルールが、既存の与信ロジックを壊していないか。こうした点を確認できなければ、文章で管理していることが新しいリスクになります。

したがって、ルール文書は単なるプロンプトではなく、業務上の統制対象として扱う必要があります。AIに渡す文章だからといって、現場ごとに自由に書き換えられるメモのように扱うべきではありません。

通常判断と規制例外は同じ場所に混ぜない

AIを使った業務フローで混乱が起きやすいのは、通常の判断ロジックと、規制や例外対応のルールが同じ場所に混ざるときです。これらを一つのルールに押し込めると、何を変えたときに何が影響を受けるのかが見えにくくなります。

この点は、与信審査の例で考えるとわかりやすくなります。

審査タスクには承認可否を判断させない

この例では、審査タスクが申請者の財務情報から正規化された信用スコアを算出します。ここで重要なのは、このタスクが承認や否決そのものを判断することを明示的に禁じられている点です。

承認可否を決めるのは、分岐点の役割です。たとえスコアを算出しているタスクであっても、その一線を越えることはできません。タスクの役割はスコアを出すことまでであり、そのスコアに基づいて経路を決めるのは別の場所に分けられています。

この分離により、スコア算出のロジックと、承認可否の判断を別々に監査できます。AIに任せる作業を細かく区切ることには、このような意味があります。

分岐点ではスコアに基づいて経路を決める

分岐点では、信用スコアを閾値と照らし合わせて経路を決めます。たとえば、スコアが0.6を超えていれば承認側へ進み、それ以下なら否決側へ進みます。ただし、融資額が大きい場合は、より厳しい0.75という閾値が使われます。

ここで扱っているのは、通常の与信判断です。財務情報から算出されたスコアに基づいて、承認側か否決側かを決めます。判断基準はスコアと閾値であり、規制上の個別例外とは分けて考えます。

規制例外は別のルールとして上書きする

さらにこの例では、規制由来の上書きルールが別に用意されています。特定の申請者、たとえばID 4321の申請者は、規制上の制約対象とされます。その場合、信用スコアにかかわらず、否決側へ迂回させるというルールです。

注目すべきなのは、信用スコアに基づく通常の判断と、申請者IDという別の基準に基づく例外の上書きが、別々のルール文書で管理されていることです。

実際、スコア0.82の申請者は、分岐の論理だけを見れば承認側へ振り分けられます。しかし、その後に規制フックが働き、否決側へ上書きされます。このとき、分岐側のルールには手を触れません。

ルールを分けると変更の影響範囲を追いやすくなる

通常の与信判断と、規制による例外対応が分離されていれば、それぞれを単独で監査できます。片方を変更しても、もう片方にどの程度影響するかを確認しやすくなります。

規制ルールだけを差し替えても、与信ロジックそのものは残る。逆に、与信スコアの閾値を見直しても、規制上の個別制約は別に維持できる。この独立性が、ルールを分けることによって得られます。

実務で見るべきなのは、AIが正しい判断をしているかだけではありません。通常判断と例外上書きが混ざっていないか。あとから変更したときに、どのルールがどの挙動を変えたのかを追えるか。この点が、監査対象の業務では重要になります。

実装前に残る制約を確認する

ここまでの設計は、監査対象業務にAIを入れるうえで参考になります。ただし、そのまま導入できる完成品として扱うべきではありません。示されているのは概念の枠組みと、小規模な実例による検証です。大規模なベンチマークによって効果が測定された段階ではないことは、まず押さえておく必要があります。

実装を検討する場合は、少なくとも次の制約を確認する必要があります。

LLM呼び出しの回数が遅延につながる

ルールを仕掛けた流れを通るたびにLLMが呼ばれるため、フックの数が増えるほど遅延も積み上がります。業務フローの各所にAI判断を置けば、それだけ応答時間や処理コストに影響します。

対策としては、状態をキーにして推論結果をキャッシュする方法や、明らかに条件を満たすケース、満たさないケースを軽量な分類器で事前に振り分け、LLM呼び出しを省く方法が示されています。いずれにしても、どの判断でLLMを呼び、どの判断では呼ばないかを設計時に決める必要があります。

ルール文書同士の矛盾を検査する仕組みが必要になる

タスク、分岐、フックの各文書にまたがって矛盾があると、一貫性のない振る舞いが生まれます。たとえば、ある文書では承認側へ進める条件を書き、別の文書では同じ条件で否決側へ迂回させるような指示があれば、AIの判断は不安定になります。

こうした矛盾を自動で検査する手立ては、未解決の課題とされています。実務で使うなら、ルール文書のレビュー、変更履歴の管理、承認フロー、テストケースの整備が必要になります。

AIが本当にルールを守るかは別途検証が必要になる

この枠組みでは、各AIに判断の文脈とルールを渡します。しかし、複雑で曖昧な入力のもとで、AIの内部推論が本当にルールどおりに振る舞うかどうかは、この仕組みだけでは完全には保証できません。

したがって、ルールを書いたから安全だとは言えません。実際の入力に近いケースで検証し、判断のばらつきや誤った解釈が起きないかを確認する必要があります。形式的な保証をどう与えるかは、今後の発展余地として残されています。

手順の組み替えには適用範囲がある

工程の差し込みや削除といった構造変更は、まだ実行されていない工程にしか適用できません。すでに実行済みの工程を巻き戻して組み替えるような操作は、この範囲には含まれていません。

実務では、どの時点までなら介入できるのか、どの工程は絶対に飛ばしてはいけないのか、どの操作には人間の承認が必要なのかを決めておく必要があります。AIによる流れの変更を許すなら、その境界を先に設計しなければなりません。

まとめ

監査対象の業務にAIエージェントを入れるとき、重要なのはAIにどれだけ自由を与えるかではありません。実行、判断、許可、記録をどこで分けるかです。

業務の手順そのものは、決定的に動くエンジンに残す。AIには判断を補助させる。ただし、その判断が実際に反映される範囲は、別のルールで制限する。そして、どの判断がどのルールに基づいて行われたのかを、あとから検証できる形で残す。

この分離ができていなければ、AIエージェントは柔軟であっても監査に耐えません。一方で、すべてを固定ルールに閉じ込めれば、想定外のケースに対応できません。実務で見るべきなのは、特定の方法論を採用するかどうかではなく、自社の業務フローの中で「AIに判断させる場所」と「AIに実行させてはいけない場所」を切り分けられているかです。

ただし、こうした設計にも課題は残ります。ルール文書同士の矛盾をどう防ぐか、LLMが複雑な入力でも本当にルールを守るか、LLM呼び出しによる遅延をどう抑えるかは、実装時に必ず検討が必要です。

したがって、この考え方は、そのまま導入する完成品ではありません。監査対象業務にAIを入れる際の設計チェックリストとして扱うのが現実的です。見るべきポイントは明確です。AIをどこに置くかではなく、AIの判断がどこで止まり、どこから先を既存システムや人間の統制に任せるかです。

スキル

本記事の関連研究