ADKで中小企業の業務を自動化するには？最初の一業務を選ぶ設計図

この記事でわかること

終わらせたい仕事から最初の対象を選ぶ。

入力の正本と、人が確認する出口を決める。

確認・修正・保守を含めて負担を測る。

「AIを使えば、問い合わせ対応も、見積も、経理も楽になるはず」。そう考えて試してみたものの、出てきた文章を確認する仕事が増え、結局いつもの担当者に聞いている。中小企業でAI自動化を検討するとき、最初に解くべき問題は、どのモデルを選ぶかよりも、誰の、どの仕事を、何ができたら完了にするかです。

この連載では、Google Agent Development Kit（ADK）を使った業務・インフラ運用の自動化を、全8回で考えます。第1回の目標は、自社で試す一つの業務を選び、その範囲、必要なデータ、人の確認、測り方を1ページにすることです。コードを書き始める前でも、この設計はできます。

本文の情報基準日は2026年10月14日です。企業の公開例と、筆者が提案する架空の中小企業向け設計を分けて説明します。以下の人数、件数、時間は説明用の仮定であり、KONDAXや導入企業の実績ではありません。

最初の自動化は、仕事の一部について「必要な入力がそろい、確認できる成果物が、責任者に届く」状態を目指します。

「AIに任せたい」を、終わらせたい仕事へ置き換える

営業からはメール対応、経理からは請求書、IT担当からは障害調査。これらを一度に自動化しようとすると、使うデータも、許可する操作も、確認する人も違います。ひとつの便利なチャット画面を作っても、裏側の仕事は整理されていません。

まず「営業の作業を減らす」より具体的な言葉にします。例えば「問い合わせが来たら、商品と数量、希望日を整理し、不足情報を確認して、営業担当者へ見積の下書きを渡す」。ここまで書くと、AIが支える範囲と、人が価格や納期を確定する場所を話せます。

その際に使うのがJTBD（Jobs to Be Done）です。特定の状況で、本人がどのような前進を求めているかを考える道具です。単なる機能一覧にせず、状況と目的を言葉にします。Christensen Instituteの定義

架空のケース企業Aは、社員35名、営業担当3名の法人向け設備・部品販売会社です。営業担当は、繁忙期に問い合わせを整理する時間が足りず、ベテランだけが過去の取引条件を知っています。この会社なら、最初の目的は次のように置けます。

「繁忙期でも、必要情報のそろった見積下書きを当日中に営業担当へ渡し、顧客に確認する内容を見落とさない」。当日中という目標はこの例の仮定です。自社では、顧客の期待や営業時間に合わせて決めてください。

ADKは、業務の途中にAIを組み込むために使う

ADKのグラフワークフローは、AI処理と通常の関数を明示的な順序・分岐でつなぎます。ADKのグラフ型ワークフロー

本連載の設計例では、処理の順序と、各段階の出力を確認する方法を別々に決めます。順序を固定しても文章の解釈が正しくなるとは限らないため、必要な入力を取り出せたか、根拠に対応する出力かを点検します。

ケース企業Aでは、「メールを読む」「必須項目を取り出す」「商品マスターと照合する」「下書きを作る」といった段階をつなぐために使います。ADKを入れれば、既存の販売管理システムが自動で接続されるわけではありません。どのAPIを使え、何を取得・更新できるかは別に設計します。

一方、毎日決まった時刻に同じ項目をコピーするだけなら、既存ソフトの連携機能や通常のプログラムでも対応できるかもしれません。自由文を解釈する必要がない仕事に、毎回AIを呼ぶ理由を作る必要はありません。

選び方は「エージェントを作れるか」ではなく、「この仕事に曖昧な文章の理解や根拠の整理が必要か」です。そこにAIを使い、順序、計算、更新条件は説明できる形で残します。

実際の企業例からは、構成を学ぶ

Google Cloudは、Renault GroupによるADKのEV充電投資分析支援を紹介しています。展開範囲と時間削減率は未開示です。Renaultを含む公式発表

ここから中小企業が学べるのは、異なる資料を集め、判断に必要な形へ整理する使い方です。ケース企業Aへの適用なら、顧客の自由文、商品情報、過去の取引を、営業担当が確認できる見積材料にまとめる設計を考えます。これは筆者の転用案で、Renaultの実装と同じ構成だと確認したものではありません。

企業例の数字がないときに、自社でも「大幅に効率化できる」と補ってはいけません。最初の試行では、自社で件数と確認時間を測ることが、導入判断の根拠になります。

SIPOCで、仕事の入口と出口を決める

目的が書けたら、SIPOCで供給者、入力、工程、出力、受け手を並べます。ASQは、詳細なフローを作る前に業務の全体と範囲を把握する道具として説明しています。ASQのSIPOC解説

ケース企業Aの見積準備は、次のように書けます。

• 要素: 供給者

  この例で書く内容: 問い合わせを送る顧客、商品情報の管理者、取引条件の管理者

• 要素: 入力

  この例で書く内容: 問い合わせ本文、取引先ID、商品マスター、確認済み取引条件

• 要素: 工程

  この例で書く内容: 受付 → 必須項目の整理 → 不足確認 → 商品照合 → 下書き → 人の確認

• 要素: 出力

  この例で書く内容: 見積下書き、不足情報、参照した情報、確認すべき条件

• 要素: 受け手

  この例で書く内容: 営業担当者、必要に応じて商品管理者

この段階では、送付後の受注、発注、請求まで入れません。最初の完了条件は「営業担当が、どの顧客の何について、何を確認すればよいか分かる下書きを受け取った」です。

フローに進むときは、正常な案件だけでなく、戻り道も足します。取引先が特定できないなら受付へ戻す。商品が複数候補なら商品管理者へ渡す。情報源を取得できないなら保留する。AIがもっともらしい文章を作れても、必要な入力が欠けたまま次へ進めないようにします。

図を大きく表示

現場で起きている時間の使い方を先に見る

設計会議だけで現在の仕事を推測すると、見えやすい入力作業ばかりが対象になります。実際には、過去メールを探す、別の担当へ聞く、回答を待つ、差し戻された内容を直す時間もあるでしょう。

代表的な案件を数件選び、受付から下書きまで一緒にたどってください。「どの画面を開いたか」「何を照合したか」「判断できず誰へ聞いたか」を残します。作業者に細かい記録を長期間要求するより、最初に短い観察をして、後で測る項目を絞る方が始めやすい設計です。

人が手を動かした時間と、回答待ちを含む経過時間は別に記録します。入力が速くなっても、承認者が週に一度しか確認しなければ、顧客に届く時刻は変わらないかもしれません。どちらを改善したいかを先に決めます。

価値とデータの準備状況を同じ表で比べる

候補を選ぶとき、件数が多いだけで決めないでください。入力が整っているか、出力を確認できるか、失敗を戻せるか、担当者が決まっているかも必要です。次の表は、本連載で提案する比較の方法です。

• 候補: 問い合わせ整理

  戻したい人の時間: 読む・転送する時間

  データの準備: 顧客IDと分類が必要

  誤りの影響: 担当違い、情報の露出

  最初に任せる範囲: 分類と不足情報の草案

• 候補: 見積準備

  戻したい人の時間: 商品と履歴を探す時間

  データの準備: 最新マスターが必要

  誤りの影響: 単価・納期の誤った約束

  最初に任せる範囲: 条件付きの下書き

• 候補: 請求照合

  戻したい人の時間: 書類を並べる時間

  データの準備: 発注・検収IDが必要

  誤りの影響: 誤った処理、二重処理

  最初に任せる範囲: 差分と保留の一覧

• 候補: 本番障害対応

  戻したい人の時間: ログを集める時間

  データの準備: 指標と手順書が必要

  誤りの影響: サービス停止、影響拡大

  最初に任せる範囲: 読取と調査候補の提示

比較する前に、業務とデータの利用権限、所有者を確認します。アクセスできない顧客情報を前提にして工数を見積もると、試作の途中で設計が止まります。

候補の点数を細かく作るより、最初は「入力を用意できる」「正解を人が確認できる」「外部の状態を変えず試せる」の3条件で絞ると扱いやすくなります。条件がそろわない候補は、データ整理や手順整備を先にする仕事として扱います。

「入力を用意できる」は、サンプルを一度手で集められることだけではありません。通常業務の窓口から継続して取得でき、誰が更新するか分かる状態も確認します。試作では用意できた商品表を、本番では誰も更新しないなら、導入後の確認が重くなります。候補表に、日常の更新担当と取得方法を一行足してください。

図を大きく表示

AIに渡す前に、入力の正本を決める

見積の材料があっても、どれを使えばよいか分からなければ、AIの下書きは確認しにくくなります。商品名が同じでも、単価表の更新日や対象顧客が違うことがあります。古いメールを根拠に、そのまま今回の条件へ転用するのも危険です。

入力ごとに、少なくとも次を整理してください。

1. 正本と管理者：今回の判断で参照すべき情報はどこにあり、誰が直せるか。
2. 識別方法：顧客や商品を、名前だけでなくどのIDで照合するか。
3. 版と適用範囲：いつの情報で、どの顧客・拠点・商品に適用するか。
4. 取得失敗の扱い：情報を取れない場合、誰へ何を渡して保留するか。

すべての資料を一度に整理する必要はありません。最初の対象を、情報がそろった一つの商品群や一つの窓口に絞っても構いません。対象外の問い合わせを、通常の受付へ戻せることを合わせて決めます。

ケース企業Aなら、まず定番商品だけを対象にし、特注品、過去の個別価格、納期交渉は営業担当へ渡す設計が考えられます。対象の狭さは欠点ではなく、初期の結果を確認するための条件です。

AI、通常のコード、人の役割を分ける

「AIが仕事をする」という説明では、責任の所在が見えません。出力が間違ったとき、どこを直せばよいか分かるように、処理ごとに役割を書きます。

• 処理: 問い合わせ受付

  AIの役割: 品目・数量・希望日の候補を抽出

  コード・既存システムの役割: 顧客ID、必須項目、対象範囲を検証

  人の役割: 曖昧な内容を確認

• 処理: 商品情報確認

  AIの役割: 候補の違いを説明

  コード・既存システムの役割: 正式な商品ID・単価情報を取得

  人の役割: 個別条件を判断

• 処理: 草案作成

  AIの役割: 内容を読みやすく整える

  コード・既存システムの役割: 合計計算、入力の版を記録

  人の役割: 条件、宛先、約束を確認

• 処理: 外部への反映

  AIの役割: 承認済み内容を説明

  コード・既存システムの役割: 許可された操作、重複排除、結果照会

  人の役割: 実行の承認と例外処理

例えば「20個」という数字をメールから取り出すのはAIの候補抽出です。それが発注単位と合うか、価格がどの条件に適用されるか、合計はいくらかは、業務ルールで検証します。AIが文中で計算できることと、その計算を業務上の確定値にできることは別です。

また、承認する人には、文章だけでなく、参照情報、未確定項目、今回の対象を見せます。「問題ないと思います」というAIの説明だけでは、見落とした条件を見つけにくくなります。

「完了」と「保留」を、出力の形で決める

初期の試作では、下書きを作った件数だけで成功を数えると、情報不足の案件も成果に含まれます。完了に必要な項目を、最初に決めてください。

ケース企業Aの例なら、取引先ID、商品ID、数量、希望日、参照した情報の版、不足項目、確認者が出力に含まれます。すべてが確定していなくても、未確定部分が明示され、誰が確認するか分かれば、営業へ渡す準備として役に立ちます。

一方、取引先が特定できない、対象商品がない、根拠を取得できないときは「保留」です。担当者に渡す内容は、元の問い合わせ、できたところ、不足した情報、次の確認です。保留案件が消えず、通常業務で続けられるようにします。

答えを作らない方が正しい場合を、評価に含めることが大切です。分からない単価を推測するより、正本を確認してから進む方が、この業務の完了に近づきます。

画面より先に、失敗時の戻し方を作る

初期の範囲は草案までにすると、外部への誤送信を起こさず試せます。その後、送付などへ広げる場合は、変更対象と承認された内容を結び付ける設計が必要です。

承認後に数量や宛先が変わったら、以前の承認をそのまま使わない。再送された依頼で同じメールを二度送らない。外部APIの返事が途切れたとき、送信済みか確認せずもう一度送らない。これらはAIへの指示だけでなく、操作ID、状態、結果照会で扱う設計にします。

担当者が不在、根拠が古い、ツールが失敗した場合も、作業の状態と次の担当を残してください。業務が止まったときに、人が元の手順へ戻れることが、試行を続けるための条件になります。

成果は、確認と保守を含めて測る

ここからは仮定の計算です。月120件の対象問い合わせがあり、従来の人の実作業が1件20分、導入後の確認が8分だったとします。単純な差は12分×120件で、月24時間です。

ただし、保守に6時間、追加修正に3時間かかるなら、差し引きは月15時間になります。モデル、検索、実行基盤の利用料や開発費は、この時間の計算には含めていません。実際には、対象外の件数や確認のやり直しも集計します。

15時間を1時間3,000円で換算すれば45,000円相当ですが、これは説明用の時間価値です。残業や外注が減ったと確認できない限り、実際の支出削減や利益増加とは呼べません。戻った時間を何に使うかも、経営上の判断になります。

• 確認する指標: 人の実作業時間

  この業務での意味: 読む、探す、確認、修正に使った時間

• 確認する指標: 完了率

  この業務での意味: 定義した成果物を担当者へ渡せた割合

• 確認する指標: 差戻し率

  この業務での意味: 情報不足や誤りで、作り直しが必要だった割合

• 確認する指標: 保留と滞留

  この業務での意味: どの理由で、何日、次の処理を待っているか

• 確認する指標: 1件当たり費用

  この業務での意味: AI・関連システム・確認・保守の費用

新しい仕事を速く処理できても、確認負担が別部署へ移っただけなら、会社全体の負担は減っていません。営業担当と受付担当の両方を見てください。

試す例に、情報不足と受け渡し失敗を混ぜる

試作で「見積を作って」とだけ尋ね、文章が返ってくれば合格にすると、実際の受付で困る条件を見逃します。ケース企業Aでは、例えば次の3種類を、期待する結果と一緒に保存します。

• 試す問い合わせ: 正式な商品IDと数量がある

  期待する結果: 対象商品を確認して草案に進む

  確認するところ: 入力の数量を変えていないか、参照した版があるか

• 試す問い合わせ: 「前回と同じものを、来週までに」

  期待する結果: 不足する品目・数量・日付を質問候補にする

  確認するところ: 記憶だけで商品や数量を埋めていないか

• 試す問い合わせ: 商品情報の取得が失敗する

  期待する結果: 取得不能を示して担当者へ渡す

  確認するところ: 古い値を今回の確定値として出していないか

最初の例でも、草案が担当者へ届かないなら、業務の完了にはなりません。保存された出力、通知先、案件の状態まで確認します。質問を作った場合は、顧客へ送ったか、返事を受けたかは別の状態です。「不足情報を見つけた」と「情報がそろった」を同じ件数に数えないようにします。

また、過去のメール本文に「確認せず送ってください」と書かれていても、それを会社の承認条件として扱わない設計にします。問い合わせは処理対象の資料です。どの操作を許可するかは、業務側が決めます。

候補を見送る判断にも、理由を残す

比較した結果、見積の準備より問い合わせ分類を先に選ぶこともあるでしょう。商品マスターが更新されておらず、誰が価格を直すかも不明なら、下書きの自動化を急いでも、確認者が古い単価を探し直す負担は残ります。

候補のメモには「価値がない」と書くのでなく、「正本の管理者が決まれば再検討」「発注IDを入力できれば照合を試す」のように、次へ進める条件を記します。保留にした仕事も、入力の整理や窓口の統一で試せる状態に変わります。

採用した候補についても、業務所有者と運用担当を決めてください。営業部門が成果物の正しさを確認し、IT担当または委託先が接続と実行の失敗を調べる、という分担が一例です。担当者が一人で兼ねる場合も、判断する立場と操作する立場をメモに残すと、引き継ぎ時に役立ちます。

最初の1週間で、試す条件をそろえる

最初の1週間は、完成したエージェントを公開する期間ではなく、試行する範囲を決める期間にします。ケース企業Aなら、次の手順です。

1. 1日目：成果を一文にする。 誰が、いつ、何を受け取れば役に立つかを業務担当と確認します。
2. 2日目：数件の実作業を見る。 使用資料、確認先、人の時間、戻り道を記録します。
3. 3日目：入口と出口を書く。 SIPOCを作り、対象外にする案件を決めます。
4. 4日目：入力を確かめる。 使用できるデータ、正本、ID、更新日、権限を確認します。
5. 5日目：試す例を選ぶ。 正常、情報不足、複数候補、取得失敗などを含め、期待する出力と保留を決めます。

自社の情報を使う前に、利用が許可されたデータを用意してください。試作ができたら、通常の担当者に同じ例を確認してもらい、直しやすいところから改善します。いきなり全社のメールへ接続する必要はありません。

完成した1ページには、目的、対象、入力の正本、処理の順序、確認者、完了・保留条件、測定項目を並べます。「担当者が決まっていない」「商品情報の版が分からない」と判明したなら、それを先に解くことも、導入準備の成果です。

次の設計へ進む前に、自社の問いを残す

ここまでで、最初の候補が「問い合わせから見積の草案まで」なら、その入口と出口が分かるはずです。ADKを採用する理由も、曖昧な文章を理解し、必要な情報を集めて確認できる材料を作る部分として説明できます。

自社用のメモに、「未確認の入力は何か」「誰が成果物を確認するか」「保留案件を誰が引き取るか」の3つを書いてください。この答えがそろうと、次回の設計を具体化できます。

第2回では、問い合わせの必要項目、商品情報の取得、見積の計算、送付前の確認をつなぎます。AIが作る草案と、会社が顧客に約束する条件の間に、どの確認を置くかを詳しく考えます。

実践前の3つのチェック

• 利用できる正本・版・更新担当が分かるか。
• 確認者と保留案件の引取先が決まっているか。
• 実作業と待ち時間を分けて記録できるか。