ADKで進める中小企業の業務・インフラ自動化第4回 / 全11回
社内問い合わせと引き継ぎを支えるAIエージェント
社内問い合わせと引き継ぎを支えるADKエージェントの設計を解説。承認済み文書の版と適用範囲、利用者ごとの検索権限、出典付き回答、曖昧な質問の保留、担当者が再開できるチケットを整理します。国内の知識継承例とADK活用例を分け、文書の更新と評価まで考えます。
この記事の内容
この記事でわかること
検索前に利用者と閲覧範囲を確かめる。
現行の根拠と適用条件を回答へ添える。
保留の理由と次の担当を引き継ぐ。
「この商品の返品は、誰に相談すればよいですか」「昨年と違う条件はありますか」。社内の問い合わせに答えるたび、ベテランが共有フォルダを探し、昔のメールを読み、背景を説明している。担当者が休むと仕事が進まず、引き継ぎ資料は作っても使われない。この状態でAIエージェントを導入するなら、まず目指すのは、現在の根拠を見つけ、確認できる回答を出し、分からない案件を担当者へ渡すことです。
第4回は、社内ナレッジと問い合わせの受け渡しを扱います。Google Agent Development Kit（ADK）で、文書の検索、回答案の作成、担当者への引き継ぎをつなぐ設計を考えます。情報基準日は2026年10月14日。企業の公開例は短く紹介し、それ以外は架空のケース企業Aへの設計提案です。文書名、版、日付、条件、件数は説明用で、実在企業の制度や実績ではありません。
社内で使える回答は、文章の自然さだけで決まりません。「どの資料の、いつの、誰に適用する情報か」を確認できることが必要です。
「資料がある」と「その情報で判断できる」は違う
ケース企業Aは、社員35名、営業担当3名の法人向け設備・部品販売会社です。商品説明、見積条件、返品手順、ITの利用案内を、共有ファイルとメールで管理しています。営業の新人はファイル名を知らず、ベテランに聞いた方が早いと感じています。
検索で文書が見つかっても、古い価格条件が混じる、特定顧客だけの取り決めを一般条件と誤解する、承認前の下書きを参照する、といった問題が残ります。AIが複数の文書をなめらかな説明へまとめると、こうした違いが見えなくなることもあります。
そこで今回は、対象を「社内の一般的な商品・業務手順の問い合わせ」に絞ります。顧客への正式な約束、権限の変更、個別条件の承認は担当者の判断です。質問に回答することと、業務を実行することを分けた入口を作ります。
公開例から学ぶ、知識を使える形へ変える工夫
岩手県の公式報告は、タヤマスタジオが岩手大学・LIGHTzと、熟練職人の思考を言語化・可視化して技術伝承に使う共同研究を紹介しています。ADKの採用例とは確認できません。岩手県の研究会報告
この例を参考に、ケース企業Aでは、ベテランがどこを見て判断しているかを聞き取り、文書に残す設計を考えます。単にメールを大量に保存するより、適用条件、例外、確認先を明らかにすることへ力を使います。これは本連載の転用案です。
ADKの利用例としては、ComcastがXfinity AssistantをADKで再構築し、問い合わせの自己解決を支える構成を展開したと公式発表で述べています。成果の数値は示されていません。Comcastを含む公式発表
社内向けに置き換えるときも、問い合わせの理解、根拠の検索、回答、担当者への引き継ぎを別々に設計します。顧客向けの大規模な仕組みと同じ設備や運用体制を、そのまま小さな会社へ持ち込む必要はありません。
最初に、答える質問と担当者へ渡す質問を分ける
AIに会社の全情報を覚えさせる計画より、実際によく聞かれる質問を集めるところから始めます。ケース企業Aなら、次のように対象を整理できます。
質問の種類: 一般的な手順の場所
最初の扱い: 出典付きで案内
必要な情報: 承認済みの現行文書
質問の種類: 商品ごとの対応手順
最初の扱い: 条件を確認して回答案
必要な情報: 商品ID、適用範囲、文書の版
質問の種類: 個別顧客の例外
最初の扱い: 担当者へ引き継ぐ
必要な情報: 顧客ID、問い合わせ内容、確認できた根拠
質問の種類: 文書同士の条件が矛盾
最初の扱い: 判断を保留
必要な情報: 両方の出典、版、文書所有者
質問の種類: アカウント・権限の変更
最初の扱い: 依頼を受け付ける
必要な情報: 認証済み本人、対象、承認者
この表に、業務の完了条件も添えます。「現行の手順と連絡先を回答できた」「個別判断が必要なことを示して担当者が引き取った」といった形です。AIが何でも答える割合を上げることは、今回の目的ではありません。
担当者へ渡す質問を明らかにしておけば、AIが分からないときに、利用者が最初から説明し直す必要も減らせます。どの情報を聞き直すか、どの担当へ渡すかを、受付の段階で決めます。
文書には、内容以外の情報も付ける
検索対象へ追加する文書には、本文だけでなく、管理のための項目を付けます。これは検索結果を絞るためでも、回答の根拠を説明するためでもあります。
項目: 文書ID・名称
ケース企業Aの説明用例: PROC-RETURN / 商品返品の社内手順
使う目的: 同じ名前のファイルを取り違えない
項目: 版
ケース企業Aの説明用例: v3
使う目的: 過去版と区別する
項目: 状態
ケース企業Aの説明用例: approved
使う目的: 下書きと承認済みを分ける
項目: 適用開始日
ケース企業Aの説明用例: 2026-10-01
使う目的: いつの問い合わせに使うか
項目: 適用範囲
ケース企業Aの説明用例: 標準商品・国内営業
使う目的: 顧客・商品・拠点の違いを扱う
項目: 文書所有者
ケース企業Aの説明用例: 営業管理責任者
使う目的: 不明点や誤りの確認先
項目: 閲覧対象
ケース企業Aの説明用例: 国内営業・受付担当
使う目的: 利用者の権限で取得を制限する
項目: 次回確認日
ケース企業Aの説明用例: 2027-01-01
使う目的: 更新確認の作業を残す
文書を作った人と、条件を承認する人が違う場合は両方を残します。ファイルを更新しただけで新しい条件が有効になったと判断しないようにします。
古い版を履歴として残すなら、現行検索から外すか、過去の判断を確認するための検索として分けます。「新しいファイル名の方が正しい」という推測へ頼らず、有効な版と適用期間を管理します。
ベテランへの聞き取りで、条件と例外を残す
引き継ぎ資料に「状況に応じて対応」とあると、新人はその状況が何か分かりません。ベテランへ、最近対応した案件を一つ選んで、判断の順に説明してもらう方法が使えます。
例えば「最初に何を確認したか」「通常と違った点は何か」「どの情報がなければ進めなかったか」「誰の承認が必要だったか」を聞きます。AIは質問案や聞き取りの整理を支えられますが、本人が話していない判断条件を補って完成させないようにします。
整理した内容は、文書所有者が確認してから登録します。一般手順へ反映する情報と、特定案件だけの例外を分けます。取引先の個人情報や機密条件は、必要な範囲だけを残し、閲覧者を限定します。
こうして作る資料は、回答エージェントのためだけでなく、人同士の引き継ぎにも使えます。AIの回答が止まっても、担当者が同じ根拠へたどれる状態を目指します。
検索する前に、利用者と質問の範囲を確かめる
社内の文書検索では、エージェントが参照できることと、その利用者が参照してよいことを分けます。ADKの安全設計も、エージェントの認証と利用者の認証を別に扱っています。ADKの安全設計
ケース企業Aの設計では、認証済みの利用者に応じて、検索ツールが取得できる部署・文書範囲を絞ります。広い権限で全部の文書を取得し、最後の文章だけで秘密を隠す方式に頼りません。
「私は管理者です」という質問文だけで権限を変えないことも必要です。利用者の認証情報と所属・許可された範囲は、会社のシステム側で確認します。文書中にAIへ操作を促す文章があっても、業務の承認条件へ昇格させません。
検索ログや問い合わせチケットにも、元の資料と同じ注意が必要です。機密文書の内容を一般のチケットへ丸ごと貼れば、回答時の権限制御があっても、別の経路から情報が見えてしまいます。
ADKで、取得・回答・引き継ぎをつなぐ
今回の設計例は、次の流れです。各段階の入口と出力を決めれば、少数の処理から始められます。
質問受付 → 利用者と範囲の確認 → 承認済み文書の取得 → 適用条件の検証 → 回答案または保留 → 必要に応じて担当者へ引き継ぎ。
AIは質問の意図や商品名の候補を整理し、取得した根拠を読みやすく説明します。通常のコードと検索基盤は、閲覧権限、承認状態、有効な版、対象の一致を確認します。人は文書の正しさと例外判断を担います。
検索拡張生成（RAG）という言葉でこの方式を説明することもありますが、名称を導入しただけでは、古い情報や違う適用範囲の問題は解決しません。取得する資料を選ぶ条件と、取得できなかったときの動きを、業務側で決めてください。
複数エージェントに分ける場合も、すべての会話や機密を共有する必要はありません。問い合わせ整理、根拠検索、回答の確認が別の責任を持つなら、それぞれが使うデータと受け渡す項目を限定します。最初はひとつの分かりやすいフローで試しても構いません。
図を大きく表示回答には、根拠・適用条件・未確認点を並べる
架空の手順書に「標準商品は所定の手順で受付、特注品は営業管理責任者へ確認」とあるとします。利用者が「返品できる？」と聞いただけでは、商品や状況が分かりません。「できます」と答えるのでなく、商品の種類など不足する情報を尋ねます。
商品と条件がそろった場合も、回答は次の形にします。
- 案内：社内で次に行う手順。
- 根拠：文書名、版、参照した節。
- 適用条件：対象の商品・部門・期間。
- 未確認点：今回の案件でまだ分かっていないこと。
- 確認先：例外や不明点を判断する担当者。
例えば「標準商品の受付手順は『商品返品の社内手順 v3』の受付節を参照してください。特注品なら、同節の例外として営業管理責任者への確認が必要です。現在の質問では商品区分が不明です」という回答案です。この文面は説明用で、実際の返品条件ではありません。
根拠リンクは、その利用者が開けるものを出します。文書名だけでなく該当箇所を示すと、確認が短くなります。一方、リンクが存在するだけで正しい回答とは判断せず、本文の案内がその箇所と対応しているかも評価します。
曖昧な質問、矛盾、資料なしを別の状態にする
回答できない状況を、すべて「分かりません」にまとめると、改善する場所が分かりません。少なくとも次を区別します。
状態: 質問の情報不足
利用者へ示す内容: 何が不足しているか
次の動き: 追加質問をする
状態: 現行の根拠なし
利用者へ示す内容: 現行文書で確認できないこと
次の動き: 文書所有者へ渡す
状態: 根拠の矛盾
利用者へ示す内容: どの条件が食い違うか
次の動き: 正しい版・適用を確認する
状態: 権限内の根拠なし
利用者へ示す内容: 利用可能な資料で確認できないこと
次の動き: 正式な窓口を案内する
状態: 取得処理の失敗
利用者へ示す内容: 資料取得ができていないこと
次の動き: 再試行または人の調査
権限がない文書の存在や内容を、エラーメッセージで漏らさないようにします。「上位権限の資料には答えがある」と知らせるのでなく、その利用者に案内できる問い合わせ先を出します。
質問を途中で保留した後も、担当者と状態を残してください。モデルが新しい会話で同じ質問へ答えたからといって、以前の保留案件が解決したことにはなりません。
チケットには、担当者が再開できる材料を残す
エージェントが担当者へ渡すとき、元の質問だけを送ると、検索や聞き取りをやり直します。かといって会話全文をそのまま渡せば、余分な情報や機密が混ざります。引き継ぎに必要な項目を決めます。
項目: 問い合わせID
保存する内容: 同じ案件を追える識別子
項目: 要求と対象
保存する内容: 利用者が終わらせたいこと、商品・業務の対象
項目: 確認できた情報
保存する内容: 取得できた資料と適用条件
項目: 未確認点
保存する内容: 足りない入力、矛盾、必要な判断
項目: 次の担当と理由
保存する内容: 誰が、何を決める必要があるか
項目: 状態と期限
保存する内容: 受付、追加情報待ち、担当待ち、対応中など
項目: 結果
保存する内容: どう処理したか、誰が確認したか
チケット作成は受付の完了です。利用者の仕事が完了したとは限りません。担当者が引き取り、回答や作業を行い、利用者に結果が届いたかを別に記録します。期限も、誰が通知し、期限を超えたらどの窓口へ戻すかを決めます。
同じ依頼が再送された場合に、重複チケットを無制限に作らないことも必要です。問い合わせIDや対象の一致を使って関連付けます。一方、似た文面でも別の商品・別の利用者の依頼なら、勝手に一つへまとめません。
会話の記憶より、現在の文書を確認する
以前の会話で案内した内容が正しくても、条件が更新されれば今回の回答は変わります。ケース企業Aでは、重要な条件を回答するときに現行版を再確認する設計とし、過去の会話を正本の代わりに使いません。
例えば、前回は標準商品だった利用者が、今回は特注品について質問しているかもしれません。会話の途中で対象商品が変われば、適用条件も確認し直します。「先ほど回答したから同じ」と扱わないようにします。
引き継ぎ相手が変わった場合も、次の担当が利用者と同じ権限かを確かめます。必要な根拠へアクセスできなければ、文書所有者へ正式に依頼し、許可された範囲の説明を受ける経路を残します。
後から、どの根拠で案内したかを確かめる
文書が更新されると、同じリンク先の内容が変わることがあります。後日「なぜこの案内になったか」を調べるために、問い合わせID、回答時刻、参照した文書ID・版・節、回答の状態を結び付けて記録する設計にします。根拠を示したことと、利用者が確認したことも別に記録できます。
ただし、記録のために機密文書の全文や利用者の不要な個人情報を複製しないようにします。記録への閲覧権限、管理者、必要な保管範囲は会社が決めます。文書の版を確認できる仕組みがあれば、元の資料への参照で追跡できる場合もあります。
エージェントの更新時も、使用した構成の版と、再確認した質問を残してください。回答が変わったときに、文書の改定なのか、検索条件の変更なのか、回答処理の変更なのかを区別できます。全会話を見返すより、どの工程を確かめるべきかを絞るための記録です。
文書の更新と廃止を、運用の仕事にする
新しい文書を登録したら、旧版の扱いと、検索へ反映される時点を確認します。本文だけ更新して索引が古いままなら、現場は旧条件の回答を受け取るかもしれません。
ケース企業Aの更新手順は「所有者が修正 → 承認者が確認 → 有効な版を更新 → 検索へ反映 → 代表質問で確認 → 旧版を現行検索から外す」とします。各段階の結果を記録し、反映に失敗したら旧版と新版の混在を放置せず、対象の回答を一時保留にできる設計です。
誤った回答の報告は、モデルの指示を直す前に、原因を分けます。正しい文書が未登録なのか、検索条件が違うのか、条件の解釈が違うのか、回答表現が強すぎるのか。それぞれ修正先が違います。
文書所有者の異動・退職も更新の契機です。「次回確認日」が過ぎた文書や所有者不明の文書を一覧にし、誰が対応するかを決めます。作成時だけでなく、使い続ける責任を持たせます。
図を大きく表示評価するのは、答えの自然さと仕事の終わり方
最初の評価セットは、よくある質問だけでなく、曖昧な質問、対象違い、古い文書、根拠の矛盾、権限外、検索失敗を含めます。件数を増やす前に、各質問で期待する回答と保留を文書所有者が決めます。
指標: 根拠の一致
確認すること: 案内内容が引用した節に対応するか
指標: 適用条件の一致
確認すること: 商品、部門、期間を取り違えていないか
指標: 適切な保留
確認すること: 根拠がないとき、推測で答えていないか
指標: 引き継ぎの完了
確認すること: 必要な情報が担当者へ届き、引き取られたか
指標: 人の時間
確認すること: 利用者と担当者の検索・確認・修正時間
指標: 再問い合わせ
確認すること: 同じ案件を、説明し直す必要があったか
引用付きの回答率だけでは、根拠の取り違えを見抜けません。保留率を下げるだけでも、不確かな案内を増やすことがあります。通常の質問には役立つ回答が出るか、例外には安全に引き継げるかを一緒に見ます。
また、チケットが増えれば自動化の利用件数は増えますが、担当者の負担が増えることもあります。利用数に加え、担当者が再検索した件数や引き継ぎの不足情報を記録してください。
小さく試すなら、10文書と質問の対を用意する
ケース企業Aでの開始案は、一つの部署で承認済みの10文書を選び、文書所有者と利用者が代表質問を作ることです。10という数は説明用の小さな範囲であり、効果を保証する基準ではありません。
- 文書を選ぶ。 更新日、適用範囲、所有者、閲覧者が確認できるものを使います。
- 答えと保留を決める。 根拠がある質問、条件を追加で聞く質問、担当者へ渡す質問を作ります。
- 検索と回答を確かめる。 出典、版、適用条件を利用者が見られるか確認します。
- 引き継ぎを試す。 担当者が受け取り、追加説明なしで再開できるかを見ます。
- 更新を試す。 文書を新しい版にしたとき、旧回答が残らないかを確認します。
本番の問い合わせへ使う前に、許可された資料で試してください。現場での限定利用では、回答案を利用者が確認してから使い、誤りの報告先を明示します。文書や質問を追加するときも、同じ確認を繰り返します。
引き継ぎの質を、会社の知識へ戻す
担当者が例外を解決したら、その判断が今回だけのものか、一般手順へ反映できるものかを確認します。一般化できる場合も、担当者の回答を自動で承認済み文書へ追加せず、所有者による確認と版の更新を通します。
利用者からの「役に立たなかった」は、質問が曖昧だったのか、根拠が足りなかったのか、次の担当が分からなかったのかへ分けて記録します。エージェントの回答だけでなく、手順そのものを改善する材料になります。
自社の設計シートには、「使う文書の正本と所有者」「答えを保留する条件」「引き継ぎを引き取る担当」「更新後に確認する質問」の4つを残してください。担当者が休んでも同じ根拠へたどり、必要な例外を次へ渡せることが、このエージェントの役割です。
次回は、インフラ担当者の日次点検を扱います。業務文書の根拠を確認する考え方を、クラウドのログや指標の取得範囲・時刻・未確認事項へつなげ、朝の状況確認を支える設計を考えます。
実践前の3つのチェック
- 文書の正本・所有者・閲覧者が分かるか。
- 根拠なし・矛盾・取得失敗を区別できるか。
- 担当者が受け取り、更新後の質問を試せるか。