💬

Amazon Quick Automate で業務効率化を PoC してみた。分析で終わらせず、次アクションにつなげる実務フロー

Ryota Ishii

2026/05/13に公開

 はじめに!この記事は約 15 分で読めます。
こんにちは！ SoftBank でエンジニアをしている石井です。

今回は、Amazon Quick Automate を使って、複数ステップの業務フローをどこまで組めるか を確認する PoC を実施しました。
Amazon Quick には Quick Flows と Quick Automate があり、Quick Flows は反復的な日常タスク向け、Quick Automate は複数システムや部門にまたがる end-to-end の業務プロセス向けです。今回のように、判定、調査、条件分岐、レポート生成までを1本の流れとして扱いたいケースは、Quick Automate の特性と相性が良いと感じました。
今回選んだ題材は、顧客対応・活用支援の準備を自動化するユースケースです。

顧客情報、利用状況、サポートのリクエストをもとに、
どの顧客を優先して確認するとよいか
その顧客は現在どのような課題を抱えている可能性が高いか
次回の定例や商談で何を話すとよいか
どのような支援や提案を準備するとよいか
を整理する処理は、単なる要約では終わりません。優先度判定、業界調査、条件分岐、レポート生成までつなげてはじめて価値が出ます。今回はその流れを、Amazon Quick Automate でどこまで再現できるかを確認しました。
この記事は、Amazon Quick Automate で実務に近いフローをどこまで組めるかを確認した PoC 記録です。

完成済みの本番テンプレートを公開する、というよりは、
どの処理を Code に任せるか
どの処理を UI Agent に任せるか
どの処理を Custom Agent に任せるか
どのような入出力設計にすると扱いやすいか
といった、設計の考え方を共有することを目的にしています。

そのため、この記事では細かいプロンプト全文やパラメータを並べるのではなく、全体像、役割分担、アウトプットを中心に記載します。

 PoCの背景と目的
 今回 PoC したこと今回 PoC した内容を要約すると、以下の通りです。

顧客データを起点に、優先度判定、業界調査、次回定例・商談に向けたアクションプラン作成、必要に応じた個別レポート出力までを自動化すること。

目的としたアウトプットは、主に以下の通りです。
顧客ごとのスコア
顧客タイプ
優先度
推奨アクション
高優先度顧客向けの個別 HTML レポート
全体サマリー
ポイントは、分析して終わりではなく、担当者が次の行動に移せる状態まで出力することです。

 本ユースケースを選定した背景と想定している利用シーン今回「顧客対応・活用支援」を題材にしたのは、Amazon Quick Automate の強みが発揮されやすいためです。

このテーマでは、少なくとも次の処理が必要になります。
顧客データを読み込む
顧客ごとにループ処理する
ルールベースで優先度を判定する
外部の業界情報をブラウザで調べる
結果に応じて条件分岐する
個別レポートと全体サマリーを出す
つまり、1回の推論で終わるタスクではなく、複数ステップをまたぐ業務フローです。こうした構成は、Amazon Quick Automate の「複数システム・複数部門にまたがるビジネスプロセス向け」という位置付けとかなり相性が良いと考えられます。
今回の PoC で想定しているのは、法人向け SaaS 企業の既存顧客対応・活用支援です。

例えば、次のような状況です。
顧客ごとの利用状況や問い合わせ情報が CSV などにまとまっている
顧客要望はテキストで管理されている
担当者が毎回、定例や商談前に情報を見返している
顧客数が増えるにつれて、優先順位付けや提案準備が属人化している
このような場合に、まずは PoC として、

「顧客データを入力すると、どの顧客を優先するとよいかと、次のアクションが出力される」

ところまで作れれば、十分に検証価値があると言えます。

 検証の概要
 全体フローと入力データ今回実装したフローは以下です。

実際の Amazon Quick の画面は以下の通りです。
このフローで意識したのは、役割を明確に分けることです。
Code は分類と優先度判定
UI Agent は外部調査と示唆の整理
Custom Agent は提言とレポート生成
Amazon Quick Automate では、UI Agent は Web のナビゲーションやデータ抽出、Custom Agent は自然言語ベースの複雑な処理、Code は Python によるカスタムロジックに向いています。今回のように役割ごとに分けると、どこを修正すれば結果が向上するかも把握しやすくなります。

今回は PoC なので、入力項目は絞りました。今回は、顧客ごとの状況整理、優先度判定、業界調査、次回定例・商談に向けたアクションプラン作成までつなげられるかを確認します。
今回最終的に使った項目は以下です。

customer_id : 顧客ID

industry : 業界

industry_detail : 詳細業種

contract_plan : プラン

usage_rate : 利用率

open_ticket_count : 未解決チケット数

csat : 顧客満足度

unused_features : 未導入機能

customer_requests : 顧客要望 ※実際の顧客からの声を想定して詳細に記載して検証

 今回の設計でこだわったポイント今回の PoC では、単に「AI に顧客分析をさせる」構成にはしていません。特に意識したのは、次の2点です。

 1. ルールベースの分類と、調査・提言を分ける優先度や顧客タイプまで Agent に任せることもできますが、まず Code で明示的に分類した方がロジックが明確になります。

その上で、業界調査や提言のような曖昧さを含む処理だけを Agent に任せる構成にしました。

 2. 出力は「次に何をするか」が見える形にする今回欲しかったのは、単なる分析結果では無く、次回定例・商談に向けて、担当者が何を準備するとよいかが明確になる状態です。そのため、最終的な出力もスコアや分類だけでなく、個別レポートや全体サマリーまで含める構成にしました。
次章からは、実際のフローをそのまま順番に追うのではなく、重要な処理だけを4つのステップに整理して説明します。本記事内での Step 1〜4 は説明用に再構成したものであり、Amazon Quick Automate 上の実際のステップ名や粒度とは一部異なります。

 実際の実行ステップ
 ステップ1: Codeで対応優先度を分類する最初に、Code で顧客ごとの対応優先度を分類しました。

ここでは、利用率、未解決チケット数、CSAT（顧客満足度）、未導入機能などをもとに、各顧客について以下を判定しています。
スコア
顧客タイプ
優先度
推奨アクション
今回の PoC では、顧客タイプを「サポート課題型」「活用不足型」「提案拡大型」「安定運用型」のように整理し、優先度や推奨アクションも合わせて出力するようにしました。
ここを Code にした理由は、初期の分類ロジックを明示し、ブラックボックス化を防ぐためです。優先度判定の基準をコードで持っておくことで、なぜその顧客が優先対応なのかを説明しやすくなり、後続の UI Agent や Custom Agent にも渡しやすくなりました。
def function(row):
usage_rate = float(row["usage_rate"])
open_ticket_count = int(row["open_ticket_count"])
csat = float(row["csat"])
unused_features = str(row["unused_features"]).strip()

score = 0

if csat < 3.5:
    score = score + 3
elif csat < 4.0:
    score = score + 1

if open_ticket_count >= 15:
    score = score + 3
elif open_ticket_count >= 8:
    score = score + 2

if usage_rate < 40:
    score = score + 2
elif usage_rate < 60:
    score = score + 1

if usage_rate >= 70 and unused_features != "なし":
    score = score + 1

if csat < 3.5 or open_ticket_count >= 10:
    customer_type = "サポート課題型"
    recommended_action = "サポート改善提案"
elif usage_rate < 45:
    customer_type = "活用不足型"
    recommended_action = "活用定着提案"
elif usage_rate >= 70 and unused_features != "なし" and csat >= 4.0:
    customer_type = "提案拡大型"
    recommended_action = "拡張提案"
else:
    customer_type = "安定運用型"
    recommended_action = "継続フォロー"

if (csat < 3.5 and open_ticket_count >= 10) or score >= 6:
    priority = "最優先"
elif score >= 4:
    priority = "優先対応"
elif score >= 2:
    priority = "通常対応"
else:
    priority = "経過観察"

return {
    "score": score,
    "customer_type": customer_type,
    "priority": priority,
    "recommended_action": recommended_action
}
戻り値のイメージは以下の通りです。
{
    "score": 7,
    "customer_type": "サポート課題型",
    "priority": "最優先",
    "recommended_action": "サポート改善提案"
}

 ステップ2: UI Agent で業界情報を踏まえた提案の下準備を行う次に、UI Agent を使って外部の業界情報を調べます。

ここで意図したのは、単に業界トレンドを集めることではなく、Code で判定した顧客タイプと優先度を前提に、なぜこの顧客にその提案が必要なのかを整理することです。

具体的には、顧客データとシステム判定結果を基に、
顧客が現在その状態にある背景
業界全体で共通して起きやすい課題
顧客要望に近い改善テーマ
未導入機能を今提案するとよいかどうか
次回定例・商談でどんな順番で話すとよいか
を整理する役割にしました。

このステップで行っているのは、単なる業界調査というよりも、顧客の状態、業界文脈、提案の方向性をつなぐための下準備 です。

今回の UI Agent の出力は、次のような内容にしました。

customer_status : 顧客の状態評価（システム判定を踏まえた深掘り）

proposal_rationale : 提案の根拠（なぜ提案するのか / Why）

proposed_solution : 提案内容（何を提案するのか / What）

action_plan : 次回商談のアクションプラン（どんな順番で提案するか / 商談ステップ1, 2, 3...）

search_evidence : 検索エビデンス（トレンド情報源・キーワード）

 ステップ3: 条件分岐して、高優先度顧客だけ戦略的なHTMLレポートを生成するCode で優先度をつけ、UI Agent で提案の下準備ができたら、次に条件分岐を行います。

ここでは、優先度が高い顧客だけを対象に、Custom Agent で個別の HTML レポートを生成するようにしました。
このステップで作成を意図したのは、単なる分析メモではなく、次回の定例や商談準備にそのまま使える戦略的なレポートです。

レポートには、以下のような内容を含めています。
顧客 ID と優先度
顧客タイプと現状評価
課題の背景と提案の根拠
何を提案するとよいか
次回商談でどんな順番で話すとよいか
業界動向や外部エビデンス
ここで作成しているのは完成済みの提案書そのものではなく、担当者が次回商談に向けて整理された状態で持ち込めるたたき台を想定しています。


 ステップ4: 結果を CSV に書き戻し、全体サマリーを作る各顧客の処理が終わったら、結果を CSV に書き戻します。ここでは、顧客ごとのスコア、顧客タイプ、優先度、推奨アクションなどを追記し、一覧で状態を確認できるようにしました。
さらに、優先度が高い顧客に対して生成した個別 HTML レポート全体をもとに、最後に全体サマリーも作成します。単なる件数集計ではなく、個別レポートに含まれる課題や提案内容まで含めて、全体としてどこに注力するとよいかを整理する点がポイントです。
このように、個別顧客の結果は CSV に、チーム全体としての示唆は全体サマリーに分けて出力することで、現場担当者にも管理者にも使いやすい形にしました。

 出力結果とPoCの検証結果
 出力結果今回の PoC で得られたアウトプットは、大きく 3 つです。

 1. 高優先度顧客向けの個別 HTML レポート優先度が高い顧客に対しては、次回定例・商談準備に使えるレポートを生成します。今回作成したレポートでは、以下のような内容が出力されました。








 2. 更新後の CSV各顧客に対して、分析結果を CSV に書き戻せるようにしました。

顧客ごとの結果を一覧で確認したい場合は、この CSV を参照する想定です。特に priority のカラムを見ることで、どの顧客から優先して対応するとよいかを把握しやすくしています。以下はその一例です。


項目
値


customer_id
C002

priority
最優先

recommended_action
サポート改善提案

customer_status
【システム判定：サポート課題型・最優先対応】利用率40%（業界平均60-70%を大幅下回る）、オープンチケット15件・CSAT3.1という数値は明確な課題状況を示している。根本原因は①利用が一部担当者に偏り現場浸透不足、②同じ質問の反復発生によるサポート負荷増大、③セルフサービス体制の未整備。これらは典型的な「導入後の定着課題」であり、新機能活用以前の基盤整備が急務の状態。

proposal_rationale
【課題背景】B2B SaaS業界では利用定着率がチャーン率に直結するため、現在の40%使用率は事業継続リスクが高い。業界標準では、①オンボーディング強化によるユーザー拡大、②ナレッジベース整備によるセルフサービス化、③段階的機能展開が成功パターンとされている。顧客の「運用負荷削減」「自己解決環境構築」要望は、まさにこの標準アプローチと合致しており、API連携・AI機能は基盤整備完了後の次段階として位置づけるべき。

proposed_solution
【段階的アプローチ】第1段階：既存機能の利用定着強化（現場メンバーへのオンボーディング研修、FAQ・ナレッジベース整備、利用促進施策）、第2段階：セルフサービス体制構築（チャットボット導入検討、ユーザーコミュニティ活用、段階的サポート自動化）、第3段階：未使用機能の段階的展開（API連携による他システム統合、AI機能活用による業務自動化）。重要なのは第1段階での基盤固めを優先し、顧客の運用負荷削減を実現してから機能拡張に進むこと。

action_plan
【商談ステップ】1. 現状課題の共有と優先順位確認（利用率・サポート負荷の数値的確認、課題の根本原因分析結果共有）、2. 第1段階提案：利用定着強化策（現場メンバー向けオンボーディングプログラム提案、FAQ・ナレッジベース整備計画、利用促進のためのKPI設定）、3. 中長期ロードマップ提示（第2段階：セルフサービス化、第3段階：API連携・AI機能活用の段階的展開計画）、4. 次回までのアクション合意（オンボーディング実施スケジュール、効果測定指標の設定、定期レビュー体制の確立）

search_evidence
【業界標準情報】B2B SaaS業界におけるカスタマーサクセス標準指標：利用率60-70%、CSAT4.0以上が健全水準。【ベストプラクティス】段階的機能展開アプローチ：基盤定着→セルフサービス化→高度機能活用の順序が成功パターン。【市場動向】API連携需要増加、AI機能活用による自動化推進が業界トレンド。【検索キーワード】B2B SaaS カスタマーサクセス、利用定着率改善、セルフサービス化、API連携トレンド、サポート自動化


 3. 全体サマリー最後に、全顧客の結果を基に全体サマリーも作成します。出力した全体サマリーは以下の通りです。







 PoCを通じて確認できたこと今回の検証を通じて、Amazon Quick Automate が特に適していると確認できたのは、次のような処理です。

 1. 複数ステップをまたぐ業務フロー単発の要約や単純な転記ではなく、
データ取得
ループ
分類
外部調査
条件分岐
レポート出力
のように、複数の処理をひとつにつなぐケースです。Amazon Quick Automate 自体が、複数システム・複数部門にまたがるビジネスプロセス向けとして位置付けられています。

 2. Code と Agent を組み合わせたい処理「分類はルールベースで固めたい」「文章化や外部調査は Agent に任せたい」といった、ルールと推論を分けたいケースです。

Code アクションで Python を使えるので、スコアリングや変換はコードに寄せて、UI Agent / Custom Agent はそれぞれの得意領域に寄せる、という分担がしやすいです。

 3. ブラウザ調査を業務フローに組み込みたい処理UI Agent が Web を巡回して情報を収集し、その結果を構造化して次のステップに渡せるのは、非常に有用です。

単に「検索できる」だけではなく、検索結果を後段の自動化で扱いやすい形に変換できるのが強みと言えます。

 4. 将来的にレビュー工程を入れたい処理今回は Human-in-the-loop（人間による介入・確認工程）までは使っていませんが、Amazon Quick Automate にはケース管理や Human-in-the-loop の仕組みがあります。将来的に「自動生成した内容を人が確認して確定する」運用に広げやすいのも優れた点であると考えられます。

 PoCの検証結果今回の PoC では、少なくとも以下のレベルの出力を達成しました。
顧客ごとの優先度の分類
顧客タイプの整理
推奨アクションの提示
業界情報を踏まえたアクションプランのたたき台
高優先度顧客向けの個別 HTML レポート
全体サマリー
特に良かったのは、「誰を優先して確認し、次に何を話すか」 がかなり整理しやすくなったことです。PoC としては、Amazon Quick Automate で実務に近い顧客対応準備フローを十分に組める感触がありました。

 まとめ今回は、Amazon Quick Automate を使って、顧客対応・活用支援の準備を自動化する PoC を実施しました。

実施内容をまとめると、次の通りです。
顧客データを Amazon S3 から取得する
顧客ごとにループ処理する
Code で優先度を分類する
UI Agent で業界情報を踏まえた提案の下準備を行う
条件分岐して高優先度顧客だけ個別レポートを作る
最後に分析結果の CSV と全体サマリーを出力する
今回改めて確認できたのは、Amazon Quick Automate は、
複数ステップをまたぐ業務フロー
Code と Agent の役割分担が必要な処理
ブラウザ調査を組み込みたい処理
条件分岐やレポート出力までつなげたい処理
に向いている、ということです。

そして PoC の結果としても、顧客ごとの優先度、推奨アクション、アクションプラン、個別レポートまで一貫して出力できたため、「顧客情報やサポートリクエストをもとに、次回定例・商談に向けた準備を自動化する」 というユースケースとの相性は非常によいと評価できます。
要約で終わらず、次の行動に直結する出力を得られる点が、本ツールの大きな利点です。業務を効率化するだけでなく、判断から次アクションまでをつなぎ、ビジネスの意思決定を加速させる基盤になり得ると言えます。

項目	値
customer_id	C002
priority	最優先
recommended_action	サポート改善提案
customer_status	【システム判定：サポート課題型・最優先対応】利用率40%（業界平均60-70%を大幅下回る）、オープンチケット15件・CSAT3.1という数値は明確な課題状況を示している。根本原因は①利用が一部担当者に偏り現場浸透不足、②同じ質問の反復発生によるサポート負荷増大、③セルフサービス体制の未整備。これらは典型的な「導入後の定着課題」であり、新機能活用以前の基盤整備が急務の状態。
proposal_rationale	【課題背景】B2B SaaS業界では利用定着率がチャーン率に直結するため、現在の40%使用率は事業継続リスクが高い。業界標準では、①オンボーディング強化によるユーザー拡大、②ナレッジベース整備によるセルフサービス化、③段階的機能展開が成功パターンとされている。顧客の「運用負荷削減」「自己解決環境構築」要望は、まさにこの標準アプローチと合致しており、API連携・AI機能は基盤整備完了後の次段階として位置づけるべき。
proposed_solution	【段階的アプローチ】第1段階：既存機能の利用定着強化（現場メンバーへのオンボーディング研修、FAQ・ナレッジベース整備、利用促進施策）、第2段階：セルフサービス体制構築（チャットボット導入検討、ユーザーコミュニティ活用、段階的サポート自動化）、第3段階：未使用機能の段階的展開（API連携による他システム統合、AI機能活用による業務自動化）。重要なのは第1段階での基盤固めを優先し、顧客の運用負荷削減を実現してから機能拡張に進むこと。
action_plan	【商談ステップ】1. 現状課題の共有と優先順位確認（利用率・サポート負荷の数値的確認、課題の根本原因分析結果共有）、2. 第1段階提案：利用定着強化策（現場メンバー向けオンボーディングプログラム提案、FAQ・ナレッジベース整備計画、利用促進のためのKPI設定）、3. 中長期ロードマップ提示（第2段階：セルフサービス化、第3段階：API連携・AI機能活用の段階的展開計画）、4. 次回までのアクション合意（オンボーディング実施スケジュール、効果測定指標の設定、定期レビュー体制の確立）
search_evidence	【業界標準情報】B2B SaaS業界におけるカスタマーサクセス標準指標：利用率60-70%、CSAT4.0以上が健全水準。【ベストプラクティス】段階的機能展開アプローチ：基盤定着→セルフサービス化→高度機能活用の順序が成功パターン。【市場動向】API連携需要増加、AI機能活用による自動化推進が業界トレンド。【検索キーワード】B2B SaaS カスタマーサクセス、利用定着率改善、セルフサービス化、API連携トレンド、サポート自動化

ソフトバンクテックブログ

ソフトバンクのエンジニアが、ソフトバンクの業務・サービスを支える技術をテーマに、現場の知見や取り組みを発信する技術ブログです。 2026年３月以前のブログ softbank.jp/biz/blog/cloud-technology/

はじめに

PoCの背景と目的

今回 PoC したこと

本ユースケースを選定した背景と想定している利用シーン

検証の概要

全体フローと入力データ

今回の設計でこだわったポイント

1. ルールベースの分類と、調査・提言を分ける

2. 出力は「次に何をするか」が見える形にする

実際の実行ステップ

ステップ1: Codeで対応優先度を分類する

ステップ2: UI Agent で業界情報を踏まえた提案の下準備を行う

ステップ3: 条件分岐して、高優先度顧客だけ戦略的なHTMLレポートを生成する

ステップ4: 結果を CSV に書き戻し、全体サマリーを作る

出力結果とPoCの検証結果

出力結果

1. 高優先度顧客向けの個別 HTML レポート

2. 更新後の CSV

3. 全体サマリー

PoCを通じて確認できたこと

1. 複数ステップをまたぐ業務フロー

2. Code と Agent を組み合わせたい処理

3. ブラウザ調査を業務フローに組み込みたい処理

4. 将来的にレビュー工程を入れたい処理

PoCの検証結果

まとめ

Discussion