ソフトバンクのAIエージェント事例から学ぶ 申請・問い合わせ業務の設計と効果測定

要約
ソフトバンクが公開したCopilot StudioとPower Automateの事例をもとに、申請判断や社内問い合わせへAIエージェントを組み込む業務設計を整理します。人へ戻す条件、後続処理、削減時間と品質の測り方まで、自社で小さく検証する手順を紹介します。
生成AIを社内で使い始めても、回答画面だけで業務が完了するとは限りません。申請内容を確認し、条件に応じて後続処理へ渡す部分まで設計して、初めて業務の流れに組み込めます。
ソフトバンクが公開した事例では、Copilot StudioとPower Automateを使い、申請受付の事前判断や社内問い合わせへの対応を扱っています。海外でもAIエージェントを業務へ組み込む議論が広がるなか、BinxAIが現場で見てきたのは、回答精度だけでなく任せる範囲の設計が成否を分ける場面です。
自社で試す際は、全社の業務を一度に変えるのではなく、判断手順と結果を確認しやすい業務から切り出します。申請や問い合わせを題材に、次の処理、人へ戻す条件、測定方法を先に決める進め方です。
この記事の対象読者
次のような課題を持つ企業や組織を対象にしています。
- 社内申請や承認業務を効率化したい企業や組織
- Microsoft 365を活用している企業や組織
- 問い合わせ対応のナレッジ活用を進めたい企業や組織
- AIエージェントを業務プロセスに組み込みたい企業や組織
- 業務自動化の効果を数値で確認したい企業や組織
回答だけでは止まる申請業務

社内申請では、受付後に内容を確認し、条件に応じて差し戻しや承認、別システムへの登録が発生します。AIが申請文を要約するだけでは、担当者が次の処理を判断する負担は残るでしょう。
ソフトバンクの事例では、申請受付の事前判断を自動化し、確認にかかる工数を約40%削減したと紹介されています。この数字は申請業務全体の削減率ではなく、事前判断における確認工数を測ったものです。
社内問い合わせも同じ構造です。規程や手順書を検索して回答するだけでなく、回答の根拠を示し、判断できない問い合わせを担当者へ渡す流れまで決める必要があります。
AIエージェントの対象は、質問や申請の文章ではなく、業務プロセスの一部として切り出します。

Copilot Studioで切り出す業務単位

ソフトバンクは2026年10月8日、Microsoft Copilot StudioとPower Automateを活用した社内AIエージェントの実践事例を公開しました。自社へ応用する場合は、製品名から始めず、既存業務の判断と後続処理を分けて確認するところから始まります。
- 受付情報、AIが判断に使える項目は何か
- 判断基準、承認や差し戻しを分ける条件は何か
- 例外処理、情報不足や規定外の場合に誰へ戻すか
- 後続処理、通知や登録など次に起こる処理は何か
- 記録方法、判断結果と人の修正をどこへ残すか
たとえば申請業務なら、申請種別、金額、対象部門、添付資料の有無などを入力項目として整理します。条件が不足している場合は自動判定を止め、追加情報の依頼や担当者への引き継ぎへ分岐させましょう。
社内ナレッジを使う問い合わせ対応では、文書を集めるだけでは足りません。適用条件、更新日、対象部門、回答できない範囲を整理し、古い情報や複数の規程がある場合の扱いも決めておくべきでしょう。
判断基準と例外処理を業務単位で定義すると、AIに任せる範囲と人が担う範囲を同じ設計図で確認できます。
約40%削減の裏側で測る品質

ソフトバンクの申請業務の事例では、事前判断の確認工数を約40%削減したとされています。導入前後で同じ対象の確認時間を比べた結果として見るべきで、全工程の作業時間が同じ割合で減ると解釈できる数字ではありません。
| 測定する対象 | 確認する内容 | 結果の見方 |
|---|---|---|
| 確認工数 | 申請受付の事前判断にかかった時間 | 削減時間と削減率 |
| 判定品質 | 人の判断との一致や修正の発生 | 誤判定と再確認の件数 |
| 例外対応 | 情報不足や規定外の申請の処理 | 有人対応への引き継ぎ状況 |
| 後続処理 | 通知や登録までの完了状況 | 処理停止や再実行の発生 |
削減時間だけを見ると、確認を省略した結果として数字がよく見える場合があります。判定の修正件数、差し戻しの適切さ、問い合わせの再発生などを並べて、業務品質の変化を確認しましょう。
問い合わせ対応では、回答の正しさだけでなく、根拠となる文書を参照できたかも記録します。回答できない質問を無理に処理せず、担当者へ戻せたかどうかも品質の一部です。
- 導入前の業務時間と確認件数を記録する
- AIの判定と担当者の最終判断を比較する
- 例外として人へ戻った件数と理由を残す
- 後続処理の完了率と停止理由を確認する
- 利用者からの再問い合わせや修正依頼を集計する
数値を取る期間や対象範囲が曖昧なままだと、導入前後の比較が難しくなります。まず1つの申請種別や問い合わせカテゴリに絞り、同じ条件で記録を続ける方法が現実的でしょう。
自社検証で詰まりやすい設計箇所

自社で試す場合、Copilot StudioやPower Automateの設定より先に、業務側の曖昧さが表面化することがあります。特に次の箇所は、担当者への確認なしに決めにくい部分です。
- 同じ申請でも部門ごとに異なる判断基準がある
- 規程に書かれていない例外を担当者の経験で処理している
- 社内ナレッジの更新日や正しい版が分からない
- AIの判定後に誰が承認し、どこへ記録するか決まっていない
外部の支援を使う場合は、ツール設定だけを依頼するのではなく、現行業務の確認から範囲に含めるかを見ます。判断基準、例外時の分岐、測定指標を一緒に整理できると、試行後の手戻りを抑えやすくなるでしょう。
BinxAI株式会社 | みっちゃくん
BinxAI株式会社のみっちゃくんでは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。一式の見積ではなく、要件を整理したうえで詳細を示す方針です。契約後に要件が動いた場合も、決めた範囲で優先順位を入れ替えて進めます。
企画や課題整理、要件整理から開発までを同じ担当が一気通貫で受け持ちます。本番展開後は、運用の引き継ぎや内製化、担当者向けの研修まで含めて、自社で使い続ける状態を整えます。
- 課題の整理と現状の診断
- 要件定義と設計
- 開発と本番環境への展開
- 運用の引き継ぎと内製化の支援
- 担当者向けの研修

よくある質問
AIエージェントとFAQの違いは?
FAQは質問への回答が中心です。AIエージェントは、情報の確認や条件分岐、通知や登録など、回答後の業務処理までつなげる設計を含みます。
最初に選ぶ業務は申請と問い合わせのどちらですか?
判断基準と成果指標を定義しやすい方を選びます。申請なら受付条件や後続処理、問い合わせなら参照文書と有人対応への切り替え条件を先に整理しましょう。
人へ戻す条件はどう決めますか?
必要情報が不足している場合、規程外の内容が含まれる場合、複数の判断が競合する場合を候補にします。候補ごとに、戻す担当者と引き継ぐ情報を決めて検証します。
約40%の削減効果を自社でも期待できますか?
ソフトバンクの約40%は、申請受付の事前判断における確認工数の事例です。業務量や判断基準が異なるため、自社では導入前の時間と件数を記録してから比較するのが現実的です。
品質はどの指標で測ればよいですか?
確認時間だけでなく、人による修正件数、例外処理の引き継ぎ状況、後続処理の停止、再問い合わせを組み合わせます。削減と品質を同じ期間で確認すると、効果の偏りを見つけやすくなるでしょう。
本記事のソフトバンクに関する情報は、2026年10月8日に公開された事例をもとに、2026年10月15日時点で整理しています。導入条件や機能、成果は業務環境によって異なるため、契約や導入の前に各社へ確認してください。記事内の事例と同等の成果を保証するものではありません。
ソフトバンクの事例から学べるのは、AIエージェントを回答ツールとして置くのではなく、申請や問い合わせの一部を業務単位で切り出す考え方です。判断基準、例外時の有人対応、後続処理、削減時間と品質の測定を一つの流れとして設計し、小さな範囲で自社の結果を確かめてください。
この記事の分類
同じ分類の記事をまとめて読めます。
次に読む記事

単発回答から継続実行へAgentforce長期タスクの本番化設計
Salesforce Agentforceが長期実行やマルチエージェント連携へ広がりました。単発回答で終わらせず、完了条件や途中承認、引き継ぎ、成果KPIまで設計して本番運用へ進める考え方を解説します。

Geminiの業務エージェント化で企業の設計はどう変わるか
Google Cloudが発表した企業向けGeminiエージェントを起点に、複数モデルへのタスク振り分けやHoneywellの予知保全事例を整理します。既存システムとの接続、承認、実行ログ、成果指標をどう設計し、業務自動化をどこから始めるかを解説します。

Microsoft 365企業がCopilot更新で確認すべき5項目
MicrosoftがCopilotを情報収集やコード作成から自律的な業務実行まで広げました。Microsoft 365企業が更新前に確認したい権限、利用上限、監査ログ、費用、段階導入の5項目を整理します。















