私たちギグワークスクロスアイティは、ある専門商社のAIエージェント導入を支援しました。J社では、受発注や問い合わせ対応で迷うと、経験者への確認が必要でした。そこで、社員がエージェントの案を直す際に、修正の理由も伝えるようにしました。エージェントはその説明を学び、次の案件で行う確認や作業に反映します。担当者が替わっても、経験者が培った仕事の進め方を引き継ぐには、どのような準備が必要だったのでしょうか。
【関連記事】「使われないマニュアル」から始める技術継承：ベテランの判断を会社に残すための支援事例
日々の仕事に埋もれていた社員の経験
J社の受発注や問い合わせ対応は、決められた項目を入力するだけでは終わりませんでした。注文書の内容を確かめたり、欠品時の対応を考えたりする場面で、経験者の判断が頼りにされていました。しかし、伝票や回答履歴には、何を調べ、なぜその対応を選んだかまでは残っていません。担当者が替わると、同じことを経験者に尋ねる必要がありました。
処理結果だけでは判断の理由が残らない
J社は、産業用の消耗品や保守部材を扱う、従業員約200人の専門商社です。営業拠点は3か所あり、営業事務12人、購買担当6人、問い合わせ担当6人で、月間約3,000件の受注と約800件の問い合わせを扱っていました。受注や発注、在庫は販売管理システムで管理し、入力の手順も社内でそろえていました。
商品の中には、顧客が箱単位で注文し、J社では個数に換算して登録するものがありました。担当者は注文書の単位と商品の入数を確認し、登録する数量を計算していました。入数は、1箱に入っている個数です。以前の注文と数量や品番が違っていて気になったときも、そのまま登録せず、顧客に確かめていました。経験者は、日々の仕事で身に付けた知識を基に、入力前に確認する箇所を判断していました。
ところが、伝票に残るのは確認を終えた数量や品番です。入力前に何が気になり、どの情報を調べたのかは、伝票を見ても分かりません。欠品時に分納を提案するかどうかも、必要な数量や使用日を聞いたうえで担当者が決めていました。分納したという記録だけでは、なぜその案を選んだのかは伝わりません。似た案件を別の社員が担当したときも、確認の手順や判断の理由が分からず、経験者に相談する必要がありました。
Excelとメールに分かれていた対応の経緯
私たちが業務の流れを確認すると、対応の記録は複数の場所に分かれていました。納期調整表と問い合わせ対応一覧は部門ごとのExcelに、顧客や仕入先に確認した内容はメールに保存されていました。担当者が気付いたことを、自分のメモにだけ残していることもあります。販売管理システムの伝票から、これらの記録をまとめて確認することはできませんでした。
欠品した商品についての問い合わせを引き継ぐときは、受注内容に加えて、顧客の使用予定日や仕入先からの回答が書かれたメールを探す必要がありました。納期調整表に日付があっても、入荷予定日なのか、顧客に伝えた納品日なのかは分かりません。やり取りを読み直して初めて、その日付の意味が分かることもありました。前の担当者が何を確認したかを知るために、複数の記録を開かなければならなかったのです。
新人は、仕事の進め方に加え、どの記録をどこに保存しているかも覚える必要がありました。経験者に教わっても、その説明が記録されなければ、次の担当者はまた同じことを尋ねます。J社は、伝票に入力した結果と併せて、登録前に調べた内容や判断の理由も残したいと考えていました。別の社員が仕事を引き継ぐには、前の担当者が何を調べ、どう考えたかまで分かる記録が必要だったのです。
社員の工夫を学ぶエージェントへの投資
そこでJ社は、受発注や問い合わせへの対応を、AIエージェントを通して行うことにしました。AIエージェントは、必要な情報を調べ、システムを操作して作業を進めます。私たちは、エージェントが作った登録案や回答案を社員が確認する流れを整えました。承認を終えると、エージェントが処理を実行します。その中で社員が案を直したときは、何を変えたかと、その理由を残せるようにしました。
J社は、社員が案を修正した理由をエージェントに学ばせ、作業手順に反映することにしました。作業手順には、先に調べる情報と確認の順序を記載します。判断が分かれる条件や、例外への対応も盛り込みます。こうした手順をまとめたものが、エージェントの「スキル」です。エージェントは案件に合うスキルを読み込み、それに沿って作業を進めます。スキルを更新すると、ほかの社員が担当する案件でも、社員の工夫を反映した手順で作業できるようになります。
私たちは、業務の進め方をJ社と一緒に整理し、共有表やシステムの接続機能を整えました。権限の設定に加え、修正理由を記録する方法や、更新した手順を確かめる方法も決めました。受注登録と問い合わせ対応から始め、6か月かけて発注案の作成や納期調整にも対象を広げています。J社は開発費用だけでなく、社員が判断の理由を説明し、手順を確かめるための時間も確保しました。導入後もエージェントに社員の説明を学ばせ、スキルを更新し続けるためです。
情報の共有と実行権限を見直す
情報を共有するにあたり、誰に何を見せるかも見直しました。納期や対応状況は部門をまたいで確認する必要があります。一方、仕入原価や個別の取引条件は、業務で使う担当者だけが閲覧できます。エージェントにも登録やメール送信を任せるため、どの情報を参照でき、どの操作を実行できるか、誰の承認が必要かを決めました。
サイバー攻撃への備えも欠かせません。IPAの「情報セキュリティ10大脅威 2026」では、ランサム攻撃や委託先を狙う攻撃に加え、AIの利用をめぐるサイバーリスクも挙げられています。J社は、アカウントを不正に使われた場合に被害が広がらないよう、閲覧できる情報と実行できる操作を、仕事に必要なものに絞る方針を取りました。
私たちは、社員の役割ごとに、扱う情報と必要な操作を整理しました。そのうえで、社員とエージェントの両方に権限を設定しました。経験者の工夫をほかの社員に伝えることと、すべての情報を全員に公開することは別です。仕事の進め方は共有し、個別の情報は担当者の権限に応じて使えるようにしました。
業務を遂行しながらスキルを蓄積する
社員がエージェントの案を直したときは、修正内容と理由を案件の記録に残します。エージェントはその理由を基に、作業手順を改善する案を作ります。私たちは、この案を別の案件でも試し、業務責任者が確認してから共通スキルへ登録する仕組みを整えました。以後の案件では、エージェントが更新後のスキルを使います。
一部のExcel運用をスプレッドシートへ
最初に、部門ごとのExcelで管理していた納期調整表と問い合わせ対応一覧を、Googleスプレッドシートへ移しました。表ごとに異なっていた項目を見直し、案件番号、商品コード、対応状況、担当者、次に行う作業をそろえました。販売管理システムは引き続き利用し、同じ案件の受注・在庫情報と共有表の記録を結び付けました。社員が必要な情報を探すときに、同じ案件番号で確認できるようにしたのです。
問い合わせ担当者は、注文内容と納期調整の状況を見ながら、顧客への回答を考えられるようになりました。購買担当者が仕入先からの回答を共有表に記録すると、その内容も確認できます。エージェントも同じ記録を参照するため、最初に届いた注文書だけでなく、その後のやり取りで分かった内容を登録案や回答案に使えます。部門ごとに保存されていた情報を、担当者とエージェントが仕事の途中で使えるようにしました。
私たちは、共有表とエージェントの操作画面をつなぐ機能も実装しました。社員が画面で案を確認し、修正すると、その内容が案件の記録として残ります。販売管理システムの受注情報と、共有表にある対応の記録も一緒に確認できます。エージェントが案の作成に使った情報と、社員が修正した箇所を記録しました。処理結果に加え、途中でどのような確認をしたかも分かります。
社員とエージェントの権限を細かく定める
共有表に移す際には、閲覧できる情報を担当業務ごとに決めました。営業事務は受注、在庫、納期を、問い合わせ担当者は注文、出荷、対応状況を確認します。購買担当者が使う仕入原価や仕入条件は別のファイルに保存し、閲覧者と保存先の共有権限を設定しました。共通スキルには判断の条件と手順を記載し、顧客ごとの情報が必要なときは、閲覧権限のある案件記録を参照するようにしました。
操作の権限も、入力・修正、確定登録、発注、社外へのメール送信に分けました。それぞれについて、実行できる担当者と承認が必要な条件を決めています。エージェントが接続できるシステムと実行できる操作も限定しました。さらに、接続先のシステムで、依頼した社員にその操作の権限があるかを確認します。注文状況を読んで回答案を作る権限があっても、それだけで社外に送信できるわけではありません。送信には別の権限を設け、承認が必要な処理は担当者や責任者の確認を経て実行します。
ファイルを読む・編集する権限と、共有先を変える権限も区別しました。共通スキルを公開する権限も別に定め、日常の処理と、情報の共有範囲を変える作業を分けています。誰が依頼し、誰が承認し、どの情報を参照・更新したかは、実行結果と一緒に記録します。異動や退職、業務の変更があったときは、部門責任者が申請し、情報システム担当が権限を変更・削除します。権限を使う人だけでなく、管理する人の責任も明確にしました。
エージェントを通じて仕事と修正を記録する
受注担当者は、届いた注文書をエージェントに渡します。エージェントは商品情報や取引条件、在庫を調べ、登録案を作ります。購買業務では、不足分の発注案を作り、仕入先に確認する内容を整理します。問い合わせ対応では、注文・出荷状況と過去のやり取りを調べ、回答案を用意します。社員がそれぞれの案を確認・修正し、承認を終えると、エージェントがシステムに接続して登録や送信を行います。
案を修正した社員は、同じ画面で理由も入力します。エージェントが参照した資料、行った処理、社員が直した内容、最終的な対応結果を、案件番号でまとめて確認できるようにしました。修正前後の入力値を見るだけでなく、何を調べた結果、なぜ変更が必要になったかまで分かります。この記録から、どの確認が足りなかったかをエージェントが学び、次の案の作成に生かせるようにしました。
記録のために、別の報告書を書く手間は増やしたくありません。そこで私たちは、社員が選択肢から修正理由を選び、短い説明を添える方法にしました。理由がはっきりしない場合は、エージェントが追加で質問します。結果から理由を推測するのではなく、実際に判断した社員に確かめて記録することで、スキルの改善に必要な情報を集めるようにしました。
修正理由から学び、次の案件へ反映する
ある注文書には「10箱」と書かれていましたが、エージェントは「10個」とする登録案を作りました。担当者は、注文書が箱単位、自社の登録が個数であることを確認し、商品情報の入数を使って数量を換算しました。そのうえで担当者は、注文書の数値と単位を併せて確認する必要があると記録しました。商品ごとの入数で換算する点も、修正理由に書き添えました。
エージェントは記録された修正理由を基に、単位の確認手順を見直す案を作りました。まず顧客の注文単位と自社の登録単位を比べ、異なる場合は商品ごとの入数で換算します。入数が分からないときは登録を止め、担当者に確認する手順も加えました。業務責任者は案を読み、過去の事例で正しく登録できるかを確かめました。さらに、改善案を作る際に使わなかった別の案件でも試し、同じ手順で対応できるかを検証しました。
確認を終えた手順は、使える条件、更新日、版、検証結果とともに共通スキルへ登録しました。以後は、ほかの社員の受注案件でも、エージェントがこのスキルを読み込み、注文単位を確認します。社員によって判断が違う場合は、商品や顧客の条件を調べ、どの条件でどちらの判断を使うかを整理します。社員の修正理由を基にエージェントが改善案を作り、業務責任者が確かめた手順を次の案件で実行するようにしました。
可視化された5つのスキル
社員の修正内容と理由を調べると、注文のどこを確かめ、何を基準に対応を決めていたかが分かりました。私たちはJ社とともに、経験者が何を確認し、どう判断しているかを整理しました。その内容を、エージェントが実行する作業手順にまとめました。その結果、注文の点検から引き継ぎまで、5つのスキルを共有できるようになりました。別の社員の案件でも、その手順で対応できるかを確かめました。
注文の食い違いを見つけ、欠品時の案を考える
一つ目は、注文内容の食い違いを見つけるスキルです。経験者は、注文書に書かれた数値をそのまま入力せず、商品の入数や、顧客と自社で使う単位を確かめていました。品番や数量を過去の購入履歴と比べ、気になる点があれば顧客に確認していました。私たちは、この確認の順序をスキルにまとめました。エージェントは注文内容を調べ、担当者に確認してほしい箇所を示します。顧客の回答を確かめてから注文内容を変更する手順も残しました。
二つ目は、欠品したときに対応案を考えるスキルです。経験者は在庫数を見るだけでなく、顧客がいつ、何個必要なのかを聞いていました。そのうえで、代替品が使えるか、分納できるか、仕入先からどのような回答が来ているかを調べていました。エージェントもこの順番で情報を集め、代替品の提案、分納、入荷待ちの案を作れるようにしました。納期を約束する前に仕入先へ確認する必要がある場面も、手順に含めています。
担当者は、エージェントが調べた在庫数や、顧客が必要とする数量・使用日を見ながら、対応案を検討できます。情報が足りなければ、エージェントが確認の必要な項目を知らせます。受注、購買、問い合わせの各担当者も、同じ案件の情報を見て対応を考えられます。担当者が替わっても、これまで経験者が確かめていた項目を、エージェントが手順に沿って確認するようになりました。
問い合わせの要点と対応の優先順位を見極める
三つ目は、曖昧な問い合わせから、確認することを絞るスキルです。「商品が違う」「まだ届かない」という連絡だけでは、詳しい状況は分かりません。経験者は、まず社内の注文や出荷の記録を調べ、その後に型番や商品が必要な日などを顧客に尋ねていました。この順序をエージェントの作業手順に組み込みました。エージェントは社内の記録を確認し、顧客に追加で尋ねることを担当者に示します。顧客に質問する前に、社内で何を調べるかも明確になりました。
四つ目は、急いで対応する案件を見極めるスキルです。経験者は、受付順や「至急」という言葉だけで順番を決めていたわけではありません。顧客の設備が止まっているのか、商品はいつまでに必要なのか、ほかの方法で対応できるのかも確かめていました。こうした事情が分かると、なぜ急ぐのか、遅れるとどのような影響があるのかを判断できます。私たちはこれらを確認項目に加え、エージェントが対応の順番を提案し、必要な案件を責任者に引き継ぐ手順を整えました。
問い合わせの内容を確かめるときも、対応する順番を決めるときも、経験者は判断に必要な情報を先に集めていました。社内の記録を調べ、分からないことを顧客に尋ねます。「至急」といった言葉の強さだけで判断せず、実際に困っている状況を確かめていたのです。エージェントがこの手順で情報を集めることで、別の担当者も、追加で尋ねることや対応の順番を判断できるようになりました。
判断の経緯を次の担当者へ引き継ぐ
五つ目は、判断の経緯を次の担当者に伝えるスキルです。経験者の引き継ぎ記録を調べ、確認できた事実、まだ分からないこと、顧客に伝えた内容、次に行う作業の四つに整理しました。エージェントは、この項目に沿って案件の記録をまとめます。引き継いだ社員は、対応がどこまで進み、何が残っているかを確認できるようになりました。
納期調整の引き継ぎでは、仕入先から得た回答と、まだ確認できていないことを分けて記録します。次の担当者は、顧客に伝えてある内容も確かめたうえで、残っている確認や連絡を行います。記録には、対応の結果と、その判断に使った情報が残ります。次の担当者は、前の担当者が調べた内容を確認してから、続きの作業を決められるようになりました。
引き継ぐ案件の情報は、担当者の閲覧権限に応じて参照します。情報の分け方と確認の順序は、共通スキルにまとめてほかの社員にも共有します。個別の顧客情報をすべて公開しなくても、仕事の進め方は共有できます。経験者が引き継ぎの際に気を付けていた点を、次の担当者とエージェントが同じように確認できる手順にまとめました。
別の社員の仕事で使えるかを確かめる
J社は、作ったスキルが別の社員の仕事でも使えるかを調べました。運用が落ち着いた後の1か月間に扱った受注案件から、共有スキルが使える類似案件を120件選びました。このうち96件は、手順を追加で直さず、担当者の確認を経て処理を終えています。対象案件での再利用率は80%でした。残る24件では追加の判断や手順の修正が必要になり、社員が対応しました。その理由も、次にスキルを改善するための記録として残しました。
問い合わせ対応では、導入前と運用が落ち着いた後の各1か月間から、内容と難しさが近い引き継ぎ案件を100件ずつ選びました。記録だけでは仕事を続けられず、前の担当者に聞き直した案件は、30件から12件に減りました。割合では30%から12%となり、18ポイントの低下です。同じ案件で何度聞き直しても1件と数え、顧客や仕入先に行った必要な追加確認は、聞き直しとして数えていません。
評価では、社員が案を確認・修正する時間に加え、修正理由の記録やスキルの更新にかかる時間も調べました。これらも含めて、業務全体の負担を見ています。誤登録の有無や、送信後に回答を訂正した内容も確認しました。スキルの数を数えるだけでなく、別の案件で使えたか、引き継いだ社員が記録を読んで仕事を続けられたかも調べています。その結果、ほかの案件にも使えた手順と、追加の確認や修正が必要な手順を見分けられるようになりました。
「社員の経験が生きる」投資へ
J社のエージェントは、経験者が教えた手順で注文内容を確認します。社員が注文単位の間違いを直す際は、正しい数量と併せて、換算に必要な確認手順も記録します。エージェントが別の社員の仕事でもその手順を使うようになり、経験者への聞き直しが減りました。
私たちギグワークスクロスアイティは、社員とエージェントが同じ案件の記録を参照できるよう、一部のExcel運用をスプレッドシートへ移しました。併せて、閲覧、入力、承認などの権限も担当業務に応じて定めました。仕事の進め方を共有しながら、個別の情報や操作は、それぞれの権限の範囲で扱えるようにしています。
社員がエージェントの案を直す場面は、仕事の進め方を教える機会にもなります。修正の理由を学ばせ、見直した手順を別の案件で試してから、共通スキルとして使います。J社は、このための時間も業務の中に確保しました。社員がエージェントに仕事を教え、教えた内容を検証する時間も、経験者への依存を減らすための投資です。
この記事を書いた人
