AI 活用ユースケース例 — 5 類型で読む実企業の型
30 社超の導入事例（アムジェン・ウェルズ・ファーゴ・EY・ダウ・ABN アムロ・BOQ ほか）を、共通する5 つの類型に整理しました。各類型で As-Is → To-Be、人 → AI に移った業務、Microsoft Copilot / Claude での実装手筋までを 1 ページで俯瞰できます。
社内ナレッジ検索型
「探す・照合する・要約する」を AI に、「判断・助言」を人に
| 観点 | As-Is | To-Be |
|---|---|---|
| 情報の探し方 | 複数 DB・共有フォルダ・Outlook・Teams を人が個別に検索、詳しい同僚に聞く | エージェントに自然言語で質問 → 数秒で根拠リンク付き回答 |
| 知識の所在 | 個人の頭の中・部門サイロ | 全社ナレッジを 1 つの窓口に統合 |
| 新人の立ち上がり | 先輩に都度質問（先輩の時間を消費） | エージェントが一次回答、人は例外対応のみ |
「探す・照合する・要約する」の部分。判断・助言そのものは人に残す。EY は『回答＋原典への直リンク』で人が検証できる形にしたのがポイント。
「同僚・ヘルプデスクへの質問」→「エージェントへの質問」。ウェルズ・ファーゴは検索の 75% をエージェント経由に置き換え、応答 10 分 → 30 秒。
再現の工夫
- いきなり全社ではなく「1 業務領域 × 厳選された正のドキュメント群」から始める（クレスターファンズは既存文書のみで 1 週間で構築）
- 回答に必ず出典リンクを付け、人が検証できる設計にする（信頼獲得の鍵）
- 「誰がその経験を持つか」という人材検索も対象にすると価値が跳ねる（アムジェン）
- M365 Copilot ＋ Graph 接続（SharePoint / Outlook / Teams を自動横断）が最短。追加開発ほぼ不要
- 部門特化は Copilot Studio でエージェント作成 → SharePoint サイトや Dataverse をナレッジソース指定 → Teams に配置
- 小規模：Claude.ai の Projects に基準文書をアップロードし、チームで共有ナレッジベース化
- 中規模以上：MCP コネクタで SharePoint / Google Drive / Slack / 社内 DB に接続し、Claude が横断検索
- 本格構築：Claude API で RAG 構成（社内文書をベクトル DB 化＋引用付き回答）を構築し、Teams / Slack ボットとして配置
文書生成・要約型
「書く人」から「編集者・検証者」へ役割シフト
| 観点 | As-Is | To-Be |
|---|---|---|
| 初稿作成 | 人がゼロから執筆（提案書 100 ページ超、ブリーフに 3 時間） | AI が過去の成功事例・社内資料から初稿生成、人はレビューと磨き込み |
| 事前リサーチ | 営業 1 人あたり最大 4 時間（ルーメン） | AI が要約・示唆出しで 15 分に |
| 定型チェック | 書式・用語統一・校正・コンプラ確認を人が実施 | AI が自動チェック（KT） |
初稿（0→60%）とリサーチ。人の役割は「書く人」から「編集者・検証者」へシフト。クリフォード・チャンスの実験が示す通り、短縮された 40% の時間を「洞察と分析の深掘り」に再投資するのが本質。
ボーダフォンは「営業→提案書作成部門への依頼」を「営業→エージェントへの指示」に変え、RFP 対応数 2〜3 倍を見込む。カンパリは「社内→外部代理店」の伝達を AI 生成ブリーフで標準化し、誤解による手戻りを削減。
再現の工夫
- 過去の勝ちパターン（受注提案書・承認済みコピー）を教材化するのが最重要。汎用生成ではなく「自社の型」を学ばせる
- 承認フローは人に残す。「AI が初稿 → 人が承認」の線引きを明文化
- ブランドガイドライン・トーン文書を参照ファイルとして固定する（カンパリ方式）
- Word / PowerPoint 内の Copilot で社内ファイルを参照指定して生成
- RFP 対応は Copilot Studio ＋ SharePoint 上の過去提案・製品仕様・コンプラ文書をナレッジ指定（ボーダフォン方式）
- Projects に「勝ち提案書・ブランドガイド・トーン規定」を登録し、その文脈で生成
- Claude for Word / Claude for PowerPoint で文書・スライド内で直接編集・生成
- 大量一括処理（数千ページのインタビュー記録要約など）は Claude API のバッチ処理が向く。長文コンテキストを活かし議事録 → テーマ抽出を一括実行（フィナストラ型）
業務プロセス自動化型（バックオフィス）
「AI が検知 → 人が判断」の分業でエラー×頻度の高い業務から
| 観点 | As-Is | To-Be |
|---|---|---|
| 請求書チェック | 数千件/日を人が目視、エラー見逃し多発 | AI が PDF → 構造化 → 異常検知、人は例外レビューのみ（ダウ） |
| 社内サポート | 500 人チームが 150 万チケットを手動処理、回答まで最大 1 週間 | 統括エージェント → 専門エージェント → 必要時のみ人へ（HCLTech） |
| SOP 作成 | 手入力で 1 時間超/件 | テンプレート＋自動文書化で 10 分（イートン） |
| IT 修復 | 人が対応 | bot がキャッシュクリア等を自動実行（CommBank） |
「読む・分類する・突合する・一次対応する」。人に残ったのは「例外判断・エスカレーション対応・最終承認」。重要なのは全自動化ではなく「AI が検知 → 人が判断」の分業（ダウの 3 万ドル過剰請求発見はこの型）。
「従業員 → サポート窓口の人」を「従業員 → エージェント（自然言語）」に変更。回答不能時のみ人へシームレスに引き継ぐ設計が定着率を左右。
再現の工夫
- エラー検知系は「誤りのコスト × 発生頻度が高い業務」（請求・発注・照合）から着手すると ROI が見えやすい
- HCLTech 型のマルチエージェント（受付役が専門役に振り分け）は、単一巨大エージェントより保守しやすい
- 「回答するだけ」から「アクションを実行する」（CommBank の自動修復）への段階的拡張を計画に入れる
- Copilot Studio ＋ Power Automate でトリガー型フロー（請求書着信 → AI 解析 → 異常フラグ → Teams 通知）
- AI Builder で PDF 抽出、Dataverse で状態管理、既存チケットシステム（ServiceNow 等）とはコネクタ接続
- Claude API のツール使用（tool use）で「PDF 読解 → 構造化 JSON 出力 → 社内システム API 呼び出し」のパイプラインを構築。PDF ネイティブ対応のため請求書処理と相性が良い
- Agent SDK でマルチエージェント構成（受付 → 専門 → 人へエスカレーション）を実装
- 定型業務の対話的な自動化には Claude Cowork（ファイル・複数ツールをまたぐ多段タスクの委任）も選択肢
顧客対応エージェント型
3 種の顧客接点（コール／Web／店員）を「会話型 AI」に置換
| 観点 | As-Is | To-Be |
|---|---|---|
| 一次対応 | コールセンターの人が全件対応 | エージェントが年 200 万件超を処理、対話の 50% 以上を自動化（ABN アムロ） |
| 店頭営業 | 会話を中断してシステム・Web を行き来 | 接客中にエージェントへ自然言語で照会、比較表も自動生成（T-Mobile） |
| 相談・提案 | 営業時間内・担当者次第 | 24 時間の会話型コンシェルジュが予約前〜搭乗後まで伴走（ホーランド・アメリカ） |
定型照会・手続き案内・比較情報の提供・時間外対応。人に残ったのは複雑案件・感情的ケア・クロージング。ヴァージン・マネーの「必要に応じて人がシームレスに介入」設計が満足度の鍵。
これが最も特徴的な類型。①顧客 → コールセンター ②顧客 → Web の静的 FAQ ③店員 → 社内システム、の 3 種の接点を「会話型 AI」に置換。ホーランド・アメリカは「チェックボックス UI → 対話」への転換自体を顧客体験価値として訴求。
再現の工夫
- 「ブロック解除」「限度額変更」など件数が多く手順が明確なトップ 10 手続きから自動化する（ABN アムロは PoC 1 日半）
- 顧客向けの前に従業員向け（店員支援）から始めるとリスクが低い（T-Mobile 方式）
- 人への引き継ぎ（ハンドオフ）を最初から設計。AI で完結させようとしない
- Copilot Studio で対話フロー＋生成 AI 回答を構築し、Web / アプリ / 電話（Dynamics 365 Contact Center 連携）へ配置
- 基幹システム連携は Power Platform コネクタまたはカスタム API
- Claude API を既存チャネル（Web、アプリ、LINE 等）に組み込み。システムプロンプトで対応範囲・トーン・エスカレーション条件を定義
- ツール使用で予約システム・在庫・料金 API を呼び出し「調べて答える」だけでなく「実行する」対応へ
- 外部情報が必要な比較系（T-Mobile 型）は API 経由の Web 検索ツールを併用
分析・意思決定支援型
「AI に分析させる」から「AI と一緒に分析ツールを作る」へ
| 観点 | As-Is | To-Be |
|---|---|---|
| リスク分析 | アナリストが手動で根本原因を診断 | ガイド付きプロンプトで 50% 以上高速化（BOQ） |
| インサイト統合 | ブランド・地域ごとに散在、調査が重複 | 全社インサイトを 1 エージェントに集約、数秒で回答（ELC） |
| 災害時の状況把握 | メール往復で数時間、避難時は不可能 | AI と共同開発したスクリプトが座標 × 公開 API で数分算出（メットライフ） |
データ収集・統合・一次分析。意思決定そのものは人。ELC の「消費者を中心に据えた判断を人が速く下せるようにする」という位置づけが典型。
「分析依頼 → 専門チーム → 数日待ち」を「担当者 → エージェント → 即時」に。メットライフは「AI に分析させる」のではなく「AI と一緒に分析ツールを作る」という第 3 の型（Copilot ＋ GitHub Copilot でスクリプト開発）を示した点が示唆的。
再現の工夫
- 分析の「型」（BOQ のカスタマイズ可能プロンプト）を組織で共有資産化する。個人任せにしない
- 既存レポート・調査資料の「再利用」から始める（ELC：新調査ではなく蓄積の活用）
- 非エンジニア部門でも「AI とツールを作る」選択肢を持つ（メットライフ型）
- Excel 内 Copilot でのデータ分析、Copilot Studio ＋インサイト DB 接続、開発が絡む場合は GitHub Copilot 併用
- Claude for Excel でスプレッドシート上の分析・数式構築・データクリーニング
- Claude.ai の分析ツール（コード実行）で CSV を直接分析・可視化
- メットライフ型のツール内製は Claude Code で（Python スクリプト開発を対話的に実施）
- インサイト統合基盤は Claude API ＋ RAG で構築
プラットフォーム対応の全体マップ
M365 にデータと業務が集中している組織は Copilot 系の初期構築コストが圧倒的に低い（Graph 連携が標準）。 一方、① M365 外システムが多い、② 回答品質・長文処理・カスタム制御を重視、③ 自社プロダクトへの組み込みが目的 の場合は Claude API / Agent SDK での構築が向きます。実務では「全社標準は Copilot、高度な分析・開発・組み込みは Claude」の併用が現実的。
| やりたいこと | Microsoft 側 | Claude 側 |
|---|---|---|
| M365 内の文書・メール横断検索 | M365 Copilot（標準機能） | MCP コネクタ or API＋RAG 構築 |
| ノーコードでエージェント構築 | Copilot Studio | Claude.ai Projects（簡易）／Agent SDK（本格） |
| 文書・スライド内での生成 | Word/PPT 内 Copilot | Claude for Word / PowerPoint |
| 表計算・データ分析 | Excel 内 Copilot | Claude for Excel／分析ツール |
| ワークフロー自動化 | Power Automate 連携 | API tool use＋自社実装／Claude Cowork |
| コード・ツール内製 | GitHub Copilot | Claude Code |
| 顧客チャネル組み込み | Copilot Studio＋各チャネル | Claude API 組み込み |
横断的に効く「自社で変えられるポイント」5 つ
初稿・一次対応・一次分析を AI へ、承認・例外・関係構築を人へ。全事例に共通する線引き。
「同僚への質問」「サポート窓口」「外部委託先への依頼」のどれかをエージェント化するだけで効果測定が明確になる。
勝ち提案書・承認済み文書・厳選ナレッジ。AI の精度は投入するデータの選別で決まる。
PoC 1 日半（ABN アムロ）、構築 1 週間（クレスターファンズ）、数日（ペット・アット・ホーム）が相場観。数か月かける計画はまず疑う。
時間削減（週◯時間）、処理速度（10 分 → 30 秒）、件数（対応数 2 倍）など、事例企業はすべて数値で語れる形にしている。