見積プロセスでは、AI Agent が引き合い情報を整理し、過去の受注データと照合して見積書のドラフトまで作成していても、一部の例外には対応できないことがあります。このような状況を見た責任者は、プロジェクトを「まだ実用化できない」と判断するかもしれません。担当者も、結局すべての項目を確認しなければならないのであれば、最初から自分で対応したほうが早いと感じるでしょう。しかし、問題は必ずしもモデルの能力不足にあるとは限りません。企業が依然として「一人の人間を完全に代替できるか」を受け入れ基準にしていることが原因かもしれません。
Palantir の CTO である Shyam Sankar も、Stratechery のインタビューで同様の見解を示しています。企業が AI を導入する際は、ナレッジワーカー一人の代替を目標にするのではなく、業務プロセス（workflow）を基本単位として考えるべきだというものです。プロジェクトで AI に人間の完全な代替を求めると、AI が業務の 98％を完了できたとしても、残りの業務が完了していないという理由で、企業はプロジェクト全体を失敗と判断する可能性があります。企業は、AI の現時点の能力に合わせてプロセスを再設計すべきだと Sankar は述べています。それは、工場が電力を使い始めた際、単に一台の機械を交換するのではなく、工場全体の運用方法を再構築したことと同じです。
AI が業務の 98％を完了しても、なぜプロセスは最後まで進まないのか？
営業の見積業務は、その典型的な例です。AI Agent は、顧客ニーズの整理、過去の価格の検索、コストの照合、見積書のドラフト作成まで対応できるかもしれません。しかし、値引きが今回の競争状況に適しているか、特別な支払条件を受け入れられるか、納期が部門横断のコミットメントに関わるかといった事項については、依然として営業、財務、または責任者による判断が必要です。プロジェクトの目標を「AI Agent が見積業務を自動で完了すること」と設定すると、最後の数項目で人の判断が必要なだけで、企業はプロジェクト全体を失敗と見なす可能性があります。一方、目標を資料整理にかかる時間の短縮や漏れの削減に変更し、責任者には例外対応だけを任せるようにすれば、チームは人と AI の協働による成果を実感できるようになります。
Sankar はサプライチェーンアナリストを例に挙げ、個人の業務効率が向上しても、必ずしも投資対効果の向上につながるとは限らないと指摘しています。そのため、企業がサプライチェーンのプロジェクトを評価する際は、アナリスト個人の作業速度だけを見るのではなく、調達、在庫、スケジューリング、承認などの工程が実際に改善されたかどうかも確認する必要があります。現在のプロジェクトを点検する際は、まず「AI Agent が整理したデータは誰に引き渡されるのか。引き継いだ担当者はそのまま利用できるのか、それとも改めて整理し直す必要があるのか」と問いかけてみましょう。次の担当者が依然として最初から確認しなければならないのであれば、モデルの変更を検討する前に、引き継ぐ内容を調整し、責任の所在を明確にする必要があります。
プロセスを実行・判断・承認の3種類の業務に分ける
役割を再分担する際は、まず開始点、終了点、責任者が明確なプロセスを一つ選びます。たとえば、調達の相見積もりであれば、依頼の受領から責任者による調達提案の承認までを対象にできます。次に、プロセス内の各ステップを、AI Agent が明確なルールに従って実行できる業務、担当者が実際の状況に応じて判断する必要がある業務、責任やコミットメントに関わり、人による承認が必要な業務の3種類に分類します。分類のポイントは、3種類の業務量を均等にすることではなく、引き継ぎのたびに入力データ、成果物、責任者を明確にすることです。
AI Agent には、まずデータ収集、形式の整理、ルールとの照合、ドラフト作成などを任せることができます。データ同士に矛盾がある、条件が明確に記載されていない、または現行ルールでは処理できない場合は、担当者の判断に引き継ぎます。金額が部門の上限を超える場合、内容を顧客へ送信する直前、または調達条件が長期的なコミットメントにつながる可能性がある場合には、プロセスをいったん停止し、決裁権限を持つ担当者の確認を待つべきです。また、承認者が確認すべき元データ、差異、提案理由を企業側で明確に規定する必要があります。一見完成度の高い提案だけを責任者に見せ、そのまま承認ボタンを押させてはいけません。
EgentWrX では、タスクをワークフローとして連結し、引き継ぎの前に人による承認を設定できます。AI Agent が前工程の作業を完了すると、プロセスはいったん停止し、担当者による確認と実行許可を待ちます。企業は、最近処理した実際の案件を使ってテストし、どの工程で差し戻し、資料の追加、書き直しが頻繁に発生しているかを確認したうえで、AI Agent と担当者の役割分担を調整できます。導入初期には、条件が曖昧なケース、金額が上限を超えるケース、社外へのコミットメントが生じるケースなど、リスクの高い工程を先に特定し、誰が確認を担当するかを決めましょう。すべての業務を一度にシステムへ移行する必要はありません。
経験豊富な担当者の知見を、審査可能なスキルとして整理する
プロセスを分解した後は、「人による判断が必要な業務」をさらに2種類に分けることができます。一つは、社内にすでに定型的な進め方があるものの、これまで文書化されてこなかった業務です。もう一つが、案件ごとに状況が異なり、実際に専門的な判断を必要とする業務です。たとえば、経験豊富な調達担当者は、サプライヤーが支払条件を変更した場合、過去の履行実績、代替調達先、契約上の制約を決まって確認しているかもしれません。しかし、新任の担当者が目にするのは最終的な承認または差し戻しの結果だけであり、経験豊富な担当者が途中でどの情報を確認したのかまでは把握できないことが少なくありません。
企業は、その業務を実際に担当している社員にヒアリングを行い、よく使われる3～5項目の判断条件、例外、出力形式を整理したうえで、実際の案件を使って一つずつ検証できます。繰り返し利用できる手順は、EgentWrX 上でスキル（AI Skill）として作成し、AI Agent が毎回同じルールに従ってデータを整理できるようにします。担当者が自ら作成したスキルを全社展開する場合は、まずスキルを管理画面の審査キューに送り、審査に合格してから展開する必要があります。一方、契約、価格、顧客へのコミットメントに影響する判断については、引き続き人による承認を残し、経験豊富な担当者の経験則をそのまま自動意思決定に使わないようにする必要があります。
受け入れ評価ではプロセス全体と実際の事業成果を見る
役割を再分担した後は、受け入れ基準もあわせて調整する必要があります。チームは、各業務が開始から完了までに何回引き継がれたか、どの工程で待ち時間が発生したか、差し戻しの理由が資料不足だったのか、それとも判断に異論があったためなのか、最終結果が当初の事業目標に沿っていたかを記録できます。こうした情報は、AI の回答が流暢かどうかよりも、企業が実際に負担しているコストを的確に反映します。また、次の改善サイクルでデータ、ルール、責任分担のどれを調整すべきかを判断するうえでも役立ちます。
Sankar は、人員削減やコスト削減を目標とする顧客よりも、売上拡大や市場競争力の向上を目標とする顧客のほうが成功しやすい傾向にあると述べています。ただし、原文には顧客数、業界分布、定量的な比較が示されていないため、この観察結果をそのまま一般的な結論として扱うことはできません。企業はこれを検討の観点として捉え、削減できる人件費を計算するだけでなく、AI によって営業担当者がこれまで手を回せなかった業務に対応できるか、顧客への回答時間を短縮できるか、重要案件の見落としを減らせるかも評価する必要があります。まず、選定したプロセスについて期待する成果、リスク、責任者を明文化し、実際の案件を使って検証します。プロセスが期待した成果を達成できたことを確認してから、他部門へ導入を拡大しましょう。
よくある質問
どのような業務から AI Agent に任せることができますか？
まずは、ルールが明確で、入力データを取得でき、出力を容易に確認できる業務を選びましょう。たとえば、引き合い情報の整理、既存条件との照合、文書のドラフト作成などです。価格に関するコミットメント、契約上の責任、ルールでは処理できない例外が関わる業務は、担当者の判断に引き継ぎ、さらに決裁権限を持つ担当者が承認すべきです。
人による承認は、どの工程に設けるべきですか？
まずは、金額が部門の上限を超える工程、条件が明記されていない工程、データ同士に矛盾がある工程、内容を社外へ送信する直前の工程に設けることができます。承認者が実質的な判断を下せるよう、元データ、変更前後の差異、提案理由を確認できるようにする必要があります。単に「承認」ボタンだけを表示してはいけません。
AI Agent が業務の 98％を完了できても、より高性能なモデルへの変更を続ける必要がありますか？
必ずしも必要ではありません。まず、残っているエラーが、モデルの能力不足、データの欠落、ルールの不明確さ、引き継ぎ方法の問題のどれに起因するかを確認すべきです。エラーが一部の高リスクな判断に集中している場合は、モデルにすべての業務を任せるよりも、プロセスを再構成して人による承認を残すほうが、プロジェクトの目標に適している可能性があります。
スキルを全社展開できるかどうかは、どのように判断しますか？
まず、実際の案件を使ってルール、例外、出力形式を検証します。異なる担当者が同じ手順に従っても、確認可能な結果を得られることを確認してから、管理画面の審査キューに送りましょう。審査に合格した後で、全社に展開できます。スキルが契約、価格、社外へのコミットメントに影響する場合は、ワークフロー内に引き続き人による承認を残す必要があります。
参考資料
- Palantir CTO Shyam Sankar へのインタビュー：AI をめぐる宗教戦争について — Ben Thompson による Shyam Sankar へのインタビュー。2026年10月29日公開。
