この判断、結局だれのやり方が正解なんでしたっけ
月曜朝の会議室で、営業企画部の山岡さん(仮名)がそう漏らしました。筆者がAIエージェント導入の相談を受ける現場では、この一言に近い声を何度も耳にします。AIを入れたい。問い合わせ対応を効率化したい。定型業務を自動化したい。そうした期待の奥に、実は「そもそも人間同士でも判断がそろっていない」という問題が横たわっていることがあります。
これは、社内問い合わせ対応にAIエージェントを導入しようとしていた、あるBtoB企業の業務設計チームの話です。人事、情報システム、現場リーダーが集まって検証を進めたものの、半年前は担当者ごとに業務マニュアルの解釈が異なり、標準業務手順も例外処理の分岐も曖昧なままでした。その結果、AIエージェントは通常ケースには答えられても、契約条件が特殊な相談や承認者不在の依頼では止まり、Slackには「これは人に戻した方がよさそうです」という投稿が並んでいました。
その後、対象となる12業務について、直近3週間分・82件の問い合わせログを棚卸しし、SOP、エスカレーション条件、フォールバック文面を整理しました。ここでいうSOPとは、Standard Operating Procedureの略で、誰が対応しても一定の判断に近づけるための標準業務手順を指します。弊社が提供するKanataのように、AIチャット、AI要約、eラーニングなどをプロジェクト単位で扱える業務支援プラットフォームを使う場合は、標準化した手順を学習データや研修コンテンツに接続しやすい点が利点になります。ただし、ツールはあくまで選択肢のひとつです。重要なのは、自社の業務ルールをAIが参照できる粒度まで整えることです。
この記事では、業務標準化 AI活用を進めたい担当者に向けて、AIエージェントが迷わず動ける業務AI設計、例外処理 AIの考え方、想定外シナリオへのガードレールを整理します。目指すのは、誰が担当しても判断基準がぶれず、AIと人が同じルールで業務を回せる状態です。ただし、標準業務手順を作るだけで万能に解決するわけではありません。継続的な見直し、現場教育、責任者によるレビューがあって初めて、安定した運用に近づきます。
AIエージェント導入で最初につまずくのは「業務の曖昧さ」
AIエージェントの導入を検討するとき、多くの企業は「どのAIを使うか」「どこまで自動化できるか」「人の作業時間をどれくらい減らせるか」を考えます。
もちろん、AIの性能や外部システムとの連携機能は重要です。筆者も、AI導入やプロダクト開発の支援では、モデル選定、セキュリティ要件、データ連携、運用体制を確認します。しかし、実際の導入現場で最初に問題になるのは、AIそのものよりも、業務側の曖昧さであることが少なくありません。
たとえば、社内問い合わせ対応をAIエージェントに任せようとしたとします。経費精算、契約確認、営業資料の申請、社内規程の確認など、業務マニュアル自体は存在しているかもしれません。ところが、現場に入ってみると、次のような状態になっていることがあります。
- AさんはSlackで確認してから承認する。
- Bさんは過去のメールを見て判断する。
- Cさんは上長に聞く前に一度差し戻す。
- Dさんは「急ぎなら例外的に進めてよい」と考えている。
人間同士であれば、この曖昧さを会話で補えます。「前もこうしていたから」「この人の依頼なら急ぎだろう」「いったん通して後で確認しよう」といった暗黙知で業務が進むからです。筆者も、こうした現場の柔軟さ自体を否定するつもりはありません。多くの企業は、その柔軟さによって日々の業務を回しています。
ただし、AIエージェントは暗黙知を前提に安定動作するわけではありません。どの情報を見て、どの条件なら回答し、どこから人に渡すのかが決まっていなければ、業務AI設計は不安定になります。
つまり、AIエージェント活用の前提は、業務標準化です。
業務標準化 AI活用とは、単に業務マニュアルをPDF化したり、既存資料をAIに読み込ませたりすることではありません。AIが判断できる単位まで、業務の流れ、判断条件、例外処理、エスカレーション先を整理することです。
筆者は、AI導入の相談を受けたとき、最初から「何を自動化しましょうか」とは聞かないようにしています。むしろ、「その業務は、いま人によって判断が変わっていませんか」と確認します。ここを避けてAIだけを導入すると、現場は便利になるどころか、確認作業に追われる可能性があります。
「業務マニュアル」だけではAIエージェントは動けない
多くの企業では、すでに何らかの業務マニュアルが存在しています。社内Wiki、スプレッドシート、PDF、Notion、Teamsの固定投稿など、形式はさまざまです。
しかし、AIエージェントにとって重要なのは、マニュアルの有無ではなく、そこに判断可能な情報が書かれているかです。
たとえば、次のような業務マニュアルがあるとします。
申請内容を確認し、必要に応じて上長に確認する
人間には何となく通じます。けれども、AIエージェントから見ると、判断に必要な情報が足りません。
- 「申請内容」とは何を確認するのか。
- 「必要に応じて」とは、どの条件なのか。
- 「上長」とは、申請者の直属上長なのか、業務主管部門の責任者なのか。
- 確認後は、承認するのか、差し戻すのか、保留にするのか。
このように、業務マニュアル AI活用で問題になるのは、文章が存在していても、AIが使える粒度に分解されていないことです。
筆者は、業務改善の支援に入ると、既存マニュアルをそのままAIに入れる前に、まず「判断が発生する箇所」に印をつけます。すると、多くの場合、マニュアルの中に「適宜」「必要に応じて」「原則として」「状況に応じて」といった言葉が並んでいます。これらの言葉は、人間の経験を前提にした便利な表現です。一方で、AIエージェントにとっては判断不能な曖昧語でもあります。
AIエージェントに渡す標準業務手順では、少なくとも次の情報を整理する必要があります。
| 項目 | 整理すべき内容 |
|---|---|
| 入力 | AIが受け取る依頼内容、ファイル、フォーム、チャット文面 |
| 参照情報 | 規程、FAQ、過去対応、商品情報、顧客情報など |
| 判断条件 | 承認、回答、差し戻し、保留、確認依頼の条件 |
| 出力 | AIが返す回答文、登録内容、通知文、次アクション |
| 例外処理 | AIで処理しないケース、人に渡すケース |
| 責任者 | 最終確認者、エスカレーション先、運用管理者 |
標準業務手順とは、作業の順番を書いたものではありません。誰が見ても同じ判断に近づけるための、業務の共通言語です。
この共通言語がないままAIエージェントを導入すると、AIは現場の曖昧さをそのまま映し出します。逆に、共通言語が整っていれば、AIは業務を支える実務的な補助者になりやすくなります。
AIエージェント向けSOPは「通常処理」と「例外処理」を分ける
AIエージェント活用におけるSOPでは、通常処理と例外処理を分けて設計することが重要です。
通常処理とは、AIエージェントが一定のルールに沿って処理してよい業務です。たとえば、社内規程に明記されている内容への回答、定型フォーマットに沿った要約、既存FAQに基づく問い合わせ対応などが該当します。
一方、例外処理とは、AIだけで完結させない業務です。契約条件が特殊な場合、顧客への影響が大きい場合、法務や人事の確認が必要な場合、情報が不足している場合などが該当します。
ここを曖昧にしたままAIエージェントを動かすと、2つの問題が起きます。
- AIが答えてはいけないことまで答えてしまう。
- AIが必要以上に人へ確認を戻してしまい、結局業務が進まない。
筆者が支援した現場でも、初期検証の段階ではこの両方が起きていました。ある問い合わせにはAIが踏み込みすぎた回答をし、別の問い合わせでは本来答えられるはずの内容まで「担当者に確認してください」と返してしまう。現場から見ると、「便利だけれど、まだ任せるのは怖い」という状態です。
そのため、例外処理 AI設計では、次のように分岐を明確にします。
| 分岐 | AIの対応 | 例 |
|---|---|---|
| 明確に回答できる | AIが回答する | 規程に明記された申請期限を案内する |
| 情報が不足している | 追加質問をする | 対象期間、金額、申請区分を確認する |
| 判断権限が必要 | 人にエスカレーションする | 承認者不在、例外承認、契約変更 |
| リスクが高い | 回答せず担当部門へ誘導する | 法務判断、個人情報、未公開情報 |
| 根拠がない | 「確認が必要」と返す | 規程やFAQに該当記載がない |
重要なのは、AIに「できる限り答えさせる」ことではありません。答えてよい範囲と、答えてはいけない範囲を明確にすることです。
日本のAI事業者向けガイドラインでも、AIに関わる事業者がライフサイクル全体でリスクを認識し、必要な対策を講じる考え方が示されています。AIエージェントの自律運用でも、この発想は重要です。自律化とは、人の確認をなくすことではなく、人が確認すべきポイントを明確にすることです。
例外処理とは「想定外との向き合い方を決める」こと
AIエージェント導入でよくある誤解に、「想定外シナリオをすべて洗い出せば安定する」というものがあります。
しかし、現実の業務では、すべての例外を事前に洗い出すことはできません。部署ごとの慣習、顧客ごとの契約条件、急ぎの依頼、組織変更、担当者不在など、例外は常に発生します。
筆者自身、プロダクト開発や業務改革の現場で、何度も「これは想定していませんでした」という場面に立ち会ってきました。仕様書には書かれていないが、現場では起きる。業務フローには載っていないが、顧客対応では必要になる。こうした余白こそ、現場のリアルです。
そのため、例外処理の目的は、想定外をゼロにすることではありません。想定外が起きたときに、AIエージェントが暴走せず、適切に止まり、人へ渡せる状態を作ることです。
ここで重要になるのが、ガードレールとフォールバックです。
- ガードレール
- AIが越えてはいけない境界線です。たとえば、「契約条件の変更判断はしない」「個人情報を含む依頼には回答しない」「規程にない内容は推測しない」といったルールです。
- フォールバック
- AIが自律処理できないときの戻り先です。たとえば、「担当部門へ確認してください」とだけ返すのではなく、どの部門に、どの情報を添えて、どのように確認すればよいかまで示します。
悪いフォールバック例は、次のようなものです。
この件は担当者に確認してください
一見問題なさそうですが、依頼者は次に何をすればよいか分かりません。結果として、Slackで別の人に聞く、過去の担当者にDMする、会議で口頭確認するなど、属人化した運用に戻ってしまいます。
より実務的なフォールバックは、次のような形です。
この申請は通常ルールに該当しないため、AIでは判断できません。以下の3点を添えて、営業企画部の承認担当者に確認してください。
- 申請対象の顧客名
- 通常条件と異なる点
- 希望する対応期限
このように、フォールバックは「止める」ためだけの文面ではありません。人に渡した後も業務が前に進むようにする設計です。
筆者は、例外処理を設計するとき、よく「AIが困ったときの作法を決めましょう」と伝えます。AIが完璧に答えることよりも、分からないときに正しく立ち止まれることの方が、実務では重要な場面が多いからです。
業務AI設計では「AIに任せない業務」を先に決める
AIエージェント導入の議論では、「何をAIに任せるか」が中心になりがちです。しかし、安定運用の観点では、最初に決めるべきなのは「何をAIに任せないか」です。
任せない業務が曖昧なままだと、現場はAIの回答をどこまで信じてよいか分からなくなります。AIが出した回答を人が毎回疑うようになれば、かえって確認工数が増えます。逆に、AIの回答を過信すれば、誤った判断が業務に入り込むリスクがあります。
AIに任せない業務の例としては、次のようなものがあります。
- 最終的な契約判断
- 法務・労務・税務など専門判断が必要な回答
- 顧客への条件変更の確約
- 人事評価や懲戒に関する判断
- 個人情報や機微情報を含む処理
- 会社としての公式見解を伴う発信
- 未公開情報や経営判断に関わる内容
これらは、AIが一切関与できないという意味ではありません。論点整理、下書き、比較表の作成、確認項目の抽出など、補助的に使える場面はあります。
ただし、最終判断は人が行う。この線引きを標準業務手順の中に書いておくことが重要です。
OECDのAI原則では、信頼できるAIの開発・利用に向けた考え方が示されており、各国のAIリスクフレームワーク形成にも使われています。企業内の業務AI設計でも、こうした「信頼性」「説明可能性」「責任の所在」を意識した運用設計が必要です。
筆者はAI導入を支援するとき、「AIに任せる領域」を広げることよりも、「AIが踏み越えてはいけない境界」を先に合意することを重視します。この境界があるからこそ、現場は安心してAIを使えます。境界がないAI活用は、便利に見えても運用で止まりやすいのです。
標準業務手順は、現場のログから作る
標準業務手順を作るとき、いきなり理想の業務フローを描こうとすると失敗しやすくなります。なぜなら、現場で実際に起きている例外や迷いが反映されないからです。
おすすめは、過去の問い合わせログ、Slackのやり取り、メール、チケット、会議メモなどをもとに、実際の業務を棚卸しする方法です。
筆者が現場に入るときも、最初から美しい業務フロー図を作ることはあまりありません。まずは、現場で起きたやり取りを見ます。どこで止まったのか。誰に確認しているのか。どの言葉に迷いが出ているのか。どの問い合わせが何度も繰り返されているのか。そこに、AIエージェント導入前に整えるべき論点が出ています。
たとえば、3週間分の問い合わせ82件を確認すると、次のような分類ができます。
| 分類 | 内容 | AI対応の方向性 |
|---|---|---|
| 定型回答 | FAQや規程に答えがある | AIが回答 |
| 情報不足 | 必要項目が足りない | AIが追加質問 |
| 承認判断 | 上長・責任者の判断が必要 | エスカレーション |
| 例外相談 | 通常ルールに当てはまらない | 人に渡す |
| マニュアル未整備 | 回答根拠が存在しない | ナレッジ整備対象 |
このように分類すると、AIに任せるべき業務と、先に標準化すべき業務が見えてきます。
特に重要なのは、AIがうまく答えられなかったケースです。そこには、業務マニュアルの不足、判断基準の曖昧さ、組織内の責任分界の不明確さが隠れています。
AIエージェント導入は、単なる自動化プロジェクトではありません。業務の曖昧さを可視化し、標準業務手順として整えるプロジェクトでもあります。
筆者は、この作業を「現場の迷いを資産化する工程」と捉えています。迷いが記録され、分類され、手順に反映されることで、次に同じケースが起きたときの対応が少しずつ安定していきます。
ツールを使う場合は、業務標準化と研修をつなげて設計/h2>
AIエージェントを安定して運用するには、システム設定だけでなく、現場の使い方をそろえる研修も必要です。
このとき、AIチャット、AI要約、eラーニング、ナレッジ管理、ワークフロー管理などのツールをどのように組み合わせるかが重要になります。選択肢は複数あります。既存のグループウェアや社内Wikiを活用する方法もあれば、AI機能を備えた業務支援プラットフォームを使う方法もあります。
Kanataを使う場合は、AIチャット、AI要約、eラーニングなどの機能をプロジェクト単位で整理できるため、業務標準化で作ったSOPや例外処理ルールを、学習データ、プロンプト、研修コンテンツとして接続しやすくなります。Kanataでは、AIチャット・AI要約・eラーニングをアプリ単位で追加でき、プロジェクトライブラリにAI設定、プロンプト、学習データを整理する設計になっています。
たとえば、次のような運用が考えられます。
- 業務ログから標準業務手順を作る
- SOPを学習データとして登録する
- よく使う判断フローをプロンプト化する
- 現場向けに研修コンテンツを作る
- AIチャットで日常業務の問い合わせに対応する
- AIが答えられなかったケースを月次で見直す
- SOP・プロンプト・研修内容を更新する
この流れを作ると、業務標準化が一度きりのドキュメント作成で終わらなくなります。
筆者は、AI導入の成否は「初期設定」よりも「運用に戻れる仕組み」で決まると考えています。どれだけ立派な業務マニュアルを作っても、現場が見なければ意味がありません。どれだけ丁寧な研修をしても、日常業務の中で使い方が更新されなければ定着しません。
AIエージェント活用研修・高度リスキリングで重要なのは、操作方法を教えることだけではありません。どの業務ならAIに任せてよいのか、どのケースなら人に戻すのか、どの出力をどう確認するのかを、現場が判断できるようにすることです。
AIエージェント運用では、ログを見てルールを育てる
AIエージェントは、一度設定すれば終わりではありません。業務内容、組織体制、顧客条件、社内規程は変わります。最初に作った標準業務手順も、時間が経てば現場とずれていきます。
そのため、AIエージェント運用では、ログを見てルールを育て続ける仕組みが欠かせません。
見直すべきログは、主に次の4つです。
| ログ | 見るべきポイント |
|---|---|
| AIが回答したログ | 誤回答、過度な断定、根拠不足がないか |
| AIが人に渡したログ | エスカレーションが多すぎないか |
| 現場が修正したログ | SOPやプロンプトに不足がないか |
| 未解決ログ | 新しい例外パターンが発生していないか |
この見直しは、導入初期は週次、その後は月次など、業務量とリスクに応じて頻度を決めると現実的です。ただし、法務・労務・金融・医療・安全管理など、誤回答の影響が大きい領域では、より短いサイクルで確認する必要があります。
ここで注意したいのは、AIの回答精度だけを評価しないことです。AIが間違えた原因が、プロンプトにあるのか、学習データにあるのか、業務ルールにあるのかを分けて考える必要があります。
筆者がよく見る失敗は、すべてを「AIの精度が低い」という言葉で片づけてしまうケースです。もちろん、AIの出力品質に改善余地がある場合もあります。しかし、実際には、参照データが古い、業務ルールが決まっていない、承認権限が曖昧、担当部門が決まっていない、といった原因もあります。
業務ルールが曖昧なままでは、どれだけAIを調整しても安定しません。逆に、業務標準化が進むほど、AIエージェントが対応できる範囲も明確になります。
AIエージェントを育てるとは、AIだけを改善することではありません。業務そのものを見直し、人の判断とAIの処理を少しずつ噛み合わせていくことです。
共通して押さえるべき論点
AIエージェント活用に必要な業務標準化・例外処理の考え方は、特定の部門だけの話ではありません。
経営者にとっては、AIエージェントをどの業務領域まで任せるかという投資判断・リスク判断の問題です。情報技術責任者にとっては、システム連携、権限管理、ログ監査、セキュリティ設計の問題です。マーケティング・セールス責任者にとっては、顧客対応、商談支援、ナレッジ共有、提案品質の標準化の問題です。
立場によって見るべき論点は異なりますが、共通する土台は同じです。
- AIに任せる業務と任せない業務を分ける
- 標準業務手順を判断可能な粒度で整える
- 例外処理とエスカレーション条件を決める
- ガードレールとフォールバックを設計する
- 現場ログをもとに継続的に見直す
- 操作研修だけでなく、業務設計の研修も行う
筆者は、AIエージェントを「業務を勝手に片づけてくれる存在」として語ることには慎重です。そうした期待は、短期的には導入を後押しするかもしれません。しかし、現場で使われ続けるAIを作るには、もう少し地味で、実務的な設計が必要です。
AIエージェントは、業務を自動で魔法のように整えてくれる存在ではありません。むしろ、業務の曖昧さを映し出す存在です。
だからこそ、AIエージェント導入は、業務標準化の好機でもあります。これまで人の経験や勘で回していた判断を言語化し、誰が担当しても同じ品質に近づける。その土台があって初めて、AIエージェントは安定して業務を支えられるようになります。
まとめ:AIエージェントは、標準化された業務の上で力を発揮する
AIエージェント活用に必要なのは、高度な技術だけではありません。むしろ、最初に必要なのは、現場の業務を丁寧に分解し、標準業務手順と例外処理を整えることです。
業務が属人化したままでは、AIエージェントは安定して動けません。マニュアルがあっても、判断条件が曖昧であれば、AIは推測するか、人に戻すしかありません。
一方で、SOP、分岐、エスカレーション、ガードレール、フォールバックが整理されていれば、AIが対応できる範囲と、人が判断すべき範囲が明確になります。
重要なのは、最初からすべての業務を自律化しようとしないことです。まずは問い合わせ対応、議事録作成、社内FAQ、申請前チェックなど、判断条件を整理しやすい業務から始める。そこで得られたログをもとに、SOPと例外処理を更新する。この積み重ねが、AIエージェントの安定運用につながります。
筆者は、AI導入の現場で「思ったより地味ですね」と言われることがあります。たしかに、業務ログを読み、例外を分類し、フォールバック文面を整える作業は、派手ではありません。けれども、その地味な設計こそが、現場で使われ続けるAIを支えます。
業務標準化 AI活用は、AI導入の前工程ではなく、AIを業務に根づかせるための中心工程です。
AIエージェントが迷わず動き、人が本来判断すべき仕事に集中できる状態をつくる。その第一歩は、自社の業務を「AIが理解できる粒度」で言語化することから始まります。
Q&A
業務標準化 AI活用では、最初に何から始めるべきですか?
最初に行うべきことは、対象業務のログを集めることです。問い合わせ履歴、Slackのやり取り、メール、チケット、会議メモなどを確認し、どこで判断が分かれているかを見ます。いきなり理想のフローを作るより、現場で実際に起きている迷いや例外からSOPを作る方が、実態に合いやすくなります。
業務マニュアルがあれば、AIエージェントはすぐに使えますか?
必ずしもそうではありません。業務マニュアルに「必要に応じて」「適宜」「原則として」といった曖昧な表現が多い場合、AIエージェントは判断に迷います。AIに使わせるには、入力、参照情報、判断条件、出力、例外処理、責任者を明確にする必要があります。
例外処理 AI設計で最も重要なことは何ですか?
AIが答えてよい範囲と、答えてはいけない範囲を分けることです。特に、法務判断、個人情報、契約条件、未公開情報、顧客への確約などは、AIだけで完結させない設計が必要です。分からないときに無理に答えさせるのではなく、適切に止まり、人に渡せるフォールバックを用意します。
AIエージェントのログは、どのくらいの頻度で見直すべきですか?
導入初期は週次、その後は月次で見直す運用が現実的です。ただし、誤回答の影響が大きい業務では、より短いサイクルで確認します。見るべきポイントは、AIの誤回答だけではありません。エスカレーションが多すぎないか、現場がどこを修正しているか、未解決の例外が増えていないかも確認します。
Kanataは、どのような場面で検討しやすいですか?
AIチャット、AI要約、eラーニング、プロジェクトライブラリを組み合わせ、業務標準化と現場研修を一体で進めたい場合に検討しやすい選択肢です。たとえば、SOPを学習データとして整理し、よく使う判断フローをプロンプト化し、現場向けの研修コンテンツに展開するような運用と相性があります。一方で、既存の社内Wikiやワークフローシステムで十分な場合もあるため、自社の情報管理、権限設計、利用部門の範囲に合わせて比較検討することが重要です。