回答するAIから、業務を動かすAIへ。導入前の比較も変わる
Zendeskは2026年9月28日の国内向け発表で、業務に特化したAIエージェントと、日本国内でのMCPクライアントの一般提供を案内しました。MCPは、AIが利用する外部システムの機能をつなぐ仕組みです。同発表では、小売向けエージェントは早期アクセス開始予定、カスタムエージェントは早期アクセス中とされ、日本語の正式サポートも一般提供時の予定です。すべてが今すぐ同じ条件で使えるわけではありません。
企業が比較したいのは、返信の自然さに加えて、注文の変更や確認がどこまで終わったと分かるかです。「回答できた件数」だけを見ると、後ろで担当者が照合や連絡を続けている仕事を見落とします。
ここからは、問い合わせ対応と受注業務をつなぐSHINJIDAIの設計案です。図・依頼番号・業務例は架空で、紹介製品の標準機能や当社の導入実績ではありません。実装できる範囲は、利用製品・契約・接続先の条件を確認して決めます。
「返信済み」の中に、まだ終わっていない仕事が隠れる
架空の法人向け資材通販会社で、顧客から配送先変更の依頼が届きました。AIチャットは「受け付けました」と返答。しかし、受注システムの住所は元のままです。窓口担当は、倉庫へ確認する必要があることに気付いていません。
この例では、依頼CS-041に注文OD-218をひも付け、回答・受付・処理完了・顧客への通知を分けます。回答は質問への案内、受付は依頼を記録した状態。処理完了は接続先の変更結果を確認した状態で、顧客へその結果を連絡できたかは別に残します。
「受付」までは進んでも、出荷状況が未確認なら変更完了とは伝えません。顧客には「変更可否を確認中」と、会社が対応できる次の連絡予定を案内します。返信だけを理由に依頼全体を完了へ移さない設計です。
処理結果が未確認なら、完了と案内しない。通知の送信失敗も別に追う。
同じ注文でも、出荷が進めば変更できる条件は変わる
CS-041では、依頼者がその注文を変更できる人か、どの配送先への変更を希望しているかを先に確認します。会話に注文番号が書かれているだけで、変更権限があるとは扱いません。本人・権限の確認方法は、現在の会員認証や社内ルールとそろえます。
次に、受注だけでなく実際に出荷を管理するシステムの状態を確かめます。注文画面が未出荷でも、倉庫では送り状作成や引渡しが進んでいることがあります。どの記録を変更可否の根拠にするか、確認から実行までの間に状態が変わったら止められるかを、運用担当と接続先の担当者で決めます。
価格変更、返金、例外対応まで一度に任せる必要はありません。AIが参照できる情報と実行できる操作を分け、まず配送先変更の受付までに限定する方法もあります。顧客からの指示が、社内の承認条件や操作権限を広げる理由にはなりません。
確認済みの範囲で進める
- 許可された注文状態を参照する
- 希望内容と対象注文を記録する
- 条件がそろった操作だけ実行する
処理を保留して人へ戻す
- 本人・変更権限が確認できない
- 出荷記録が食い違う・状態が変わった
- 契約外の対応や金額の例外がある
結果が分からないときは、再実行より先に照合する
CS-041の変更要求を送った後に、接続が切れたとします。画面に成功と表示されないことだけでは、受注側で変更されなかったとは分かりません。この状態は「失敗」や「完了」に決め付けず、「結果確認待ち」として扱います。
元の依頼番号と操作の記録から、接続先で実行された内容を確認します。再送が必要な場合は、同じ依頼による同じ操作を接続先が重複処理しない仕組みを使えるか確かめます。使えない場合は、照合してから人が再実行を判断するなど、代わりの手順が必要です。番号を付けるだけで重複が防げるわけではありません。
顧客がチャットを送り直したときも、同じ注文への依頼が進行中か確認します。一方、変更先が別の住所へ変わったなら、前の依頼の単なる再送とは区別します。元の処理がどこまで進んだかを確認し、追加変更を判断する担当へ戻します。
- 01
結果確認待ちにする
自動再実行と、変更完了の案内を止める
- 02
接続先の記録を照合
依頼・注文・操作内容が一致するか確認
- 03
確認結果で分ける
完了済みは再実行しない。不明は担当判断を待つ
- 04
残る対応を引き継ぐ
未実行と確認できた場合だけ、合意した方法で再実行
人へ転送した後、誰が引き受けたかまで追う
時間外に倉庫確認が必要になったCS-041を、共用メールへ送るだけでは、翌朝の担当が決まらない場合があります。「人へ転送済み」と「担当者が受領済み」を分け、担当部署・引取担当・次の連絡期限を残します。期限を超えた場合の責任者と代わりの窓口も決めます。
担当者に渡すのは会話全文だけではありません。顧客の希望、注文番号、確認できた出荷状態と確認時刻、実行した操作、まだ分からないことをまとめます。顧客情報は、その対応に必要な担当だけが閲覧できる範囲にします。
顧客が依頼を取り消した場合も、画面から消して終わりにしません。まだ実行前か、既に変更したかを確認し、元に戻す必要と可否を人が判断します。処理を止めたことと、変更前の状態へ戻ったことを分けて連絡します。
転送しただけ
受領と次の仕事を残す
運用で直せるか、既存設定か、連携・追加開発かを比べる
担当が決まっていないことが原因なら、AI製品の追加より先に、受付と受領のルールを整えます。既存の問い合わせ管理で担当割当・期限・状態を設定できるなら、その機能を使って試します。
一方、受注や倉庫の画面を見に行くたびに転記が必要なら、まず状態を参照する連携から検討できます。変更操作まで広げるのは、権限、結果の照合、二重実行の防止、人へ戻す方法を確かめてからです。独自の承認や複数拠点の例外が既存機能に収まらない場合に、追加開発を比較します。
経営者は、返信にかかった時間だけでなく、未解決の滞留、再問い合わせ、担当者の照合負担、誤った完了案内の有無も見ます。機能の数ではなく、顧客に返す結果と、人が負担する仕事がどう変わるかで投資の範囲を決めます。
運用を整える
担当・受領・期限が曖昧。既存窓口で責任と引継ぎをそろえる
既存設定を使う
状態・担当割当・時間外案内を設定し、未処理を見つけられるか試す
必要な情報を連携する
受注・出荷状態と処理結果をつなぎ、手作業の照合を減らす範囲を決める
不足する部分を開発する
固有の承認・例外・複数システムの結果確認が、既存機能で扱えない場合に比較
発注前に、正常時だけでなく「止まる依頼」を一緒に試す
比較する会社や製品には、同じ依頼を使って確かめてもらいます。正常に住所が変わる場面だけでなく、出荷済み、担当不在、接続切れ、顧客の再送、途中の希望変更を含めます。結果が分からない状態を完了にしないか、担当が引き取り、残る仕事から再開できるかを確認します。
最初は配送先変更の受付だけなど、一種類の依頼・限られた範囲で始めます。切替中は現在のメールや電話の窓口を続け、同じ注文への依頼を一つにまとめてから処理する担当を決めます。AI側と既存窓口の両方で、同じ変更を別々に実行しない運用も試します。
株式会社SHINJIDAIは、業務課題の相談・解決策の提案から、設計・開発・導入まで伴走しています。このテーマでは、実際に止まっている依頼の流れを確認し、AIへ任せる段階と人の判断、接続先の条件を整理します。既存設定で足りる部分と、連携・追加開発が必要な部分を比較して提案します。
合意した範囲では、依頼と注文の対応付け、処理結果の照合、担当への受渡しなどを実装し、担当者と例外ケースを確かめます。製品ごとの接続可否、AIの精度、夜間対応や運用支援の体制は個別に確認します。特定製品の機能や処理成功を無条件に保証するものではありません。
費用を左右するのは、接続先の数、参照だけか変更操作まで含むか、例外の種類、過去の対応履歴をどこまで移すかです。継続するAI・製品の利用条件と、導入後の保守・改善の範囲も分けて確認し、初期実装だけで比較しないようにします。
- どの状態で、顧客に「完了」と案内してよいか
- 結果不明・二重依頼を、誰がどの記録で照合するか
- 担当不在時に誰が引き取り、いつ連絡するか
- 製品や接続先の更新後に、誰が同じ例外ケースを試すか
- 出荷可否・例外の承認・顧客への連絡期限は、社内の誰が判断するか。支援側が実装する接続・状態・記録と、双方で試す範囲を合意する
- 運用中の設定・権限・接続先の更新を誰が担い、変更後に誰が再検証するか。自社・製品提供者・支援先の分担を合意する
業務の課題整理から、設計・開発・導入まで
問い合わせの回答と、受注側の処理をつなぐなら、
SHINJIDAIにご相談ください。
- AIは返信済みでも、注文変更の処理が追えない
- 人へ転送した依頼が、担当待ちのまま残る
- 今の窓口と受注システムを活かし、任せる範囲を決めたい
課題の整理から伴走止まっている依頼の一件から、受付・実行・結果確認・顧客への連絡を整理します。既存設定と運用、連携・追加開発を比較し、合意した範囲を実装。結果不明・再送・担当不在まで試し、人が残る仕事から再開できるかを確かめます。
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
特定製品の契約・接続可否、夜間対応、運用支援の範囲は個別に確認します。
ID・パスワードや顧客データは、フォームに記載しないでください。
業務自動化の支援を見る出典
確認日：2026年9月30日。国内発表日、海外での発表・提供日、一般提供と早期アクセスを区別しています。提供条件は変更される場合があるため、実際の契約・環境で確認してください。
Zendeskの国内向け発表は9月28日。英語版の特化型エージェント発表は9月14日、MCPクライアントの一般提供に関する英語ヘルプは8月10日です。本記事では9月28日を世界初の発表・提供日とは扱っていません。
外部ツールの選択、出力の扱い、接続失効とタイムアウトは公式ヘルプを参照。4つの状態、CS-041の例、担当・通知・再実行の判断、方法の比較はSHINJIDAIの設計案であり、製品機能の再現や効果の実測ではありません。
よくある質問
回答が正確なAIチャットなら、注文変更も任せられますか？
回答の正確さと、注文を変更できることは別に確認します。本人や依頼権限、最新の出荷状況、操作できる範囲、実行結果を確かめる方法が必要です。まず案内だけ、受付まで、人の確認後に実行など、任せる段階を分けて試します。
人への転送機能があれば、引き継ぎは十分ですか？
転送先へ届いたことと、担当者が引き受けたことを分けて確認します。会話の要点、注文番号、依頼内容、実行済みの操作、未確認事項、次に返答する期限をそろえます。担当不在や時間外に誰が引き取るかも決めます。
接続がタイムアウトしたら、AIにもう一度実行させればよいですか？
接続先では処理が済んでいる場合もあるため、すぐに再実行しません。元の依頼と処理記録を照合し、結果が分からなければ確認待ちにします。同じ操作の重複を防ぐ仕組みと、照合できない場合に人が判断する手順を、接続先の仕様に合わせて設計します。
既存の問い合わせ管理や受注システムは入れ替える必要がありますか？
まず現在の機能で、依頼番号、担当、引取確認、処理結果、顧客への連絡を追えるか確認します。設定と運用で足りる部分は残し、照合や転記に負担が残る部分だけ連携を検討します。固有の権限や例外が既存機能で扱えない場合に、追加開発を比較します。
SHINJIDAIへ相談する前に、AI製品を選ぶ必要がありますか？
製品が決まる前から相談できます。止まっている問い合わせの例、現在の窓口と受注システム、担当の分担をもとに、AIへ任せる範囲と人の確認を整理します。機密情報や顧客の会話全文を最初から送る必要はありません。製品の契約条件・接続可否を確認したうえで支援範囲を決めます。