生成AIで業務資料作成業務を代替する
はじめに
「調査して結果をまとめ、PowerPointとExcelを作り、上司に連携する」という業務は、多くの職種で共通する型です。ここでは そのフローを題材に、自動化の候補を整理するうえで、どこにRPA（ルールベースの定型操作自動化）を入れ、どこに生成AI（要約・下書き・分類など）を使うか を、As-Is / To-Be の対比で示します。
本記事でいう 成果物 は次を想定しています。
| 成果物 | よくある中身 | 上司が見るポイント |
|---|---|---|
| Excel | 比較表、試算、一覧、根拠数値、前提条件 | 再計算可能性、一次データへのトレース、例外の扱い |
| PowerPoint | 結論、論点、根拠、リスク、次アクション | メッセージの一貫性、一枚目の結論、図表の読みやすさ |
| 連携 | メール本文、Teams投稿、共有リンク、版管理 | いつ・誰向け・何を決めてほしいかが明確か |
前提として、次のような役割分担が現実的です。
| 観点 | RPAに向く | 生成AIに向く |
|---|---|---|
| 入力 | 画面操作・ファイル操作が繰り返される | 文章・表・ログなど非構造〜半構造データが多い |
| ルール | 手順が固定で例外が少ない | 表現が多様で「意味」の判断が必要 |
| リスク | 画面変更で壊れやすい（メンテ前提） | 事実誤り・ハルシネーション（人の確認前提） |
| 成功の鍵 | 例外処理・ログ・再実行の設計 | プロンプト設計・根拠資料の添付・人による検証ゲート |
以下の図では、人が最終責任を持つ承認・ファクトチェック を To-Be に明示しています。生成AIは「下書き装置」、RPAは「手を動かす装置」という位置づけです。
対象フローのAs-Is（現状）
典型的なAs-Isでは、調査・資料化・連携が 人手とコピペ でつながり、同じ作業が案件ごとに繰り返されます。
対象フローのAs-Is（情報収集 → 整理・資料化 → 連携）
As-Isで起きがちな「隠れコスト」
同じ型でも、負荷は 調査対象の不確実性 と 資料の再利用性 で大きく変わります。検討会でよく出る論点を列挙します。
- 探索コスト：何を調べれば十分かが最初から決まっていないと、検索・問い合わせ・試行錯誤が膨らむ（この部分はRPA単体では解けにくい）。
- 転記コスト：同じ一覧を「画面→Excel」「Excel→スライド」と何度も載せ替えるほど、ミスと版ズレが増える。
- 合意形成コスト：上司向けの「一言」「結論の言い切り」に時間がかかるが、案件ごとにゼロから書き直している。
- 連携コスト：正しいファイルを正しい場所に、正しい権限で渡す作業が手作業だと、後から「どれが最新？」が起きやすい。
As-Isの時間配分イメージ（例）
数字はあくまで 説明用の目安 です。実際は業界・案件で変わりますが、改善議論では「どのブロックが支配的か」を切るのに便利です。
| ブロック | 時間の目安 | 主な中身 |
|---|---|---|
| 収集 | 35〜55% | 画面操作、ダウンロード、問い合わせ待ち、読み込み |
| 整理（Excel） | 20〜35% | 表作成、関数、グラフ、前提の注記 |
| 資料化（PPT） | 15〜25% | ストーリー化、図表、テンプレ合わせ |
| 連携 | 5〜15% | 命名規則、格納、送付文、版の確定 |
この配分が「収集偏重」なら 収集の定型化（RPA） が効きやすく、「資料化偏重」なら テンプレとたたき台（RPA＋生成AI） が効きやすい、といった読み方ができます。
As-Isのつまずきポイント（例）
- 調査ソースが分散し、同じ検索・同じ画面遷移 を毎回やり直す。
- Excel・PowerPointへの転記で 転記ミス・版ズレ が起きる。
- 「上司向けに一言添える」文面作りに 時間はかかるが再利用しにくい。
- 出典管理 が弱く、後から根拠を説明できない（上司質問で詰まる）。
ここでは RPA＝定型UI/ファイル操作、生成AI＝文章化・要約・構成案 に分けて検討するのがわかりやすいです。
To-Be（改善後）：RPAと生成AIの入れどころ
To-Beでは、データ取得とファイル生成の繰り返しをRPA に寄せ、調査結果の要約・スライドのたたき台・表の下書きを生成AI に寄せます。そのうえで 人が数値・固有名詞・引用元を確認 してから上司へ渡します。
To-BeにおけるRPA・生成AI・人の役割分担
To-Beのシーケンス（誰が何をするか）
「ツールを入れた結果、工程がどう並ぶか」を整理すると、次のような流れになりやすいです（※環境により前後します）。
RPA・生成AI・担当者・上司のシーケンス例
配置の考え方（具体例）
| ステップ | As-Isでの負荷 | To-Beでの打ち手 | RPA / 生成AI |
|---|---|---|---|
| 社内システムから同じ条件で一覧を取得 | 毎回クリック連打 | スケジュールまたはボタン1つで取得 | RPA |
| 外部サイトの公開情報を定点観測 | 巡回とコピペ | 取得はRPA、変化の「意味づけ」は人＋AI | RPA＋生成AI（補助） |
| 調査ログを読みやすくする | 手作業で要約 | たたき台を生成AI、事実は人が修正 | 生成AI |
| Excelの定型レイアウトに値を入れる | 手入力 | テンプレにRPAで流し込み | RPA |
| PowerPointの体裁・社内テンプレ適用 | 手作業 | マスタにRPAで流し込み、文言はAI下書き | RPA＋生成AI |
| 上司への説明文・要点メール | 毎回ゼロから執筆 | 構成と初稿を生成AI、トーンは人が調整 | 生成AI |
| 版管理・格納ルール | ばらつき | 命名・フォルダ・権限操作をRPA化 | RPA |
ExcelとPowerPointで「効く場所」が違う
Excel は「構造が決まっているほどRPAが強い」一方、意味づけの注釈（前提、例外、読み替えルール）は生成AIの補助が効きます。
| 内容 | 向く手段 | コメント |
|---|---|---|
| 一覧の取り込み・整形・差分更新 | RPA / スクリプト | 列固定・フォーマット固定が前提 |
| ピボットやグラフの更新 | 人 / マクロ | 分析の意図が変わると設計が変わる |
| 「この表を第三者が読んだときの注意書き」 | 生成AI（下書き） | ただし数値・定義は人が確定 |
| 監査に耐える出典列・根拠URL | 人（責任） | AIに丸投げしない |
PowerPoint は「型」が強いほど自動化の効果が出ます。典型パターンは次の二つです。
- テンプレ固定＋差し替え：結論・根拠・次アクションの枠が決まっている（RPAでテキストボックス更新やファイル結合がしやすい）。
- ストーリーが毎回変わる：構成案は生成AI、最終メッセージは人が作る（AIは「候補を複数」出させると安全）。
生成AIを使うときの「最低限の型」（プロンプト設計の芯）
ハルシネーション対策は「禁止ではなく 工程で封じる」が現実的です。たとえば次をプロンプトに毎回含めると、下書き品質が安定しやすいです。
- 目的：上司に何を決めてほしいか（判断依頼／情報共有／期限）
- 読者：上司の関心（コスト、リスク、スピード、コンプライアンス等）
- 入力の扱い：貼り付けたメモ以外の知識を使わない／推測は推測と明記する
- 出力形式：章立て、箇条書き、1枚あたりの文字量、禁止表現
- 検証依頼：出典が不明な主張は「要確認」として列挙させる
「調査メモそのもの」を社外クラウドに出せない場合は、社内LLM・マスキング・要約のみ投入 など、情報区分（Public/Internal/Confidential）に合わせた使い分けが必要です（次節）。
RPAだけ・生成AIだけに寄せない方がよい典型
| 状況 | 片方だけに寄せると起きること | 望ましい組み合わせ |
|---|---|---|
| 画面が頻繁に変わる | RPAが壊れ続ける | 取得方法をAPI/エクスポートに寄せる、範囲を狭める |
| 数値の正確さが最優先 | 生成AIが誤る | AIは「文章」だけ、数値はソースオブトゥルースへ |
| 監査ログが必要 | 人手が残らない | RPAの実行ログ、ファイルのハッシュ、承認履歴を設計 |
セキュリティ・ガバナンス（導入前に並べるチェック）
「便利さ」と「情報漏えいリスク」はトレードオフになりやすいので、To-Be設計では先に並べます。
| 区分 | 例 | 生成AI | RPA |
|---|---|---|---|
| 公開情報のみ | プレス、官報、公開統計 | 外部サービス利用も検討しやすい | 画面取得でもリスク低め |
| 社内限定 | 未公開数値、顧客名、社員情報 | 社内ゲートウェイ／オンプレ／マスキング必須 | 実行アカウント権限の最小化、ログ保管 |
| 個人情報・機密 | 契約書、ID情報 | 原則NGまたは匿名化後のみ | 画面キャプチャの保存先を厳格化 |
加えて、生成AIの出力をそのまま上司提出 しない、RPAの実行結果をサンプル検証 する、といった 人のゲート をTo-Beに書き込むのがポイントです。
導入の進め方（As-Is計測 → パイロット → 横展開）
いきなり全工程を自動化せず、次の順で進めると失敗しにくいです。
- As-Isの事実収集：1案件を追い、画面録画・作業ログ・所要時間を取る（どこが支配的かを確定）。
- 自動化の候補を2系統に分ける：①RPA向き（定型操作）②生成AI向き（文章・構成）。混ざる場合は分割する。
- パイロット：週次・月次など「頻度が高い」案件を1つ選び、例外処理の扱い（失敗時の通知先、再実行）まで含める。
- 運用設計：担当交代、テンプレ更新、画面改修時の保守責任、セキュリティレビューのタイミング。
- 横展開：テンプレとプロンプトを資産化し、案件間で再利用する。
導入の進め方（As-Is計測から横展開まで）
KPIの置き方（Before / After）
「何が改善したか」を上司やステークホルダーに示すために、次のような指標が扱いやすいです。
| 指標カテゴリ | 例 | メモ |
|---|---|---|
| 時間 | リードタイム（着手〜送付）、工程別分位（中央値） | 短縮だけでなく、品質（手戻り）も見る |
| 品質 | 転記ミス件数、上司からの差し戻し回数 | To-Beの真の価値が出やすい |
| 再現性 | テンプレ準拠率、命名規則違反 | RPAの効果が表に出る |
| リスク | インシデント件数、越権アクセス未遂 | セキュリティとセット |
失敗パターンと対策（よある落とし穴）
| 失敗パターン | 症状 | 対策の方向性 |
|---|---|---|
| AIに丸投げ | 数値・法令・固有名詞が誤る | ファクトチェック専用のチェックリストを工程化 |
| RPAの密結合 | 画面改修のたびに修理が必要 | オブジェクトセレクタ見直し、安定UIへの誘導、範囲縮小 |
| 責任境界が曖昧 | 障害時に誰が直すか不明 | 運用オーナー、保守SLA、ログの見方を文書化 |
| テンプレなき自動化 | 生成物のばらつきが増える | 先にテンプレと「禁止事項」を固める |
| 機密データの誤投入 | コンプラ事故 | データ分類、マスキング、社内LLM、入力前の確認 |
As-Is / To-Be を1枚に畳んだ比較図
As-IsとTo-Beの対比（1枚図）
RACIの例（責任の置き方）
自動化しても 責任は人に残る ので、最低限のRACIを例示します（組織に合わせて調整してください）。
| 活動 | 担当者 | RPA/AI運用 | 上司 |
|---|---|---|---|
| 調査範囲・前提の確定 | A/R | C | I |
| 収集の実行（自動含む） | R | A | I |
| 要約・資料たたき台 | R | C | I |
| ファクトチェック・最終編集 | A/R | I | I |
| 提出・説明 | R | I | A |
R:実行 A:説明責任 C:相談 I:報告
まとめ
- RPA は「同じ手順で、同じ画面・ファイル操作を何度もする」部分に効きやすい。調査結果の 取得・フォルダ格納・テンプレへの流し込み・連携操作 が代表例です。
- 生成AI は 要約・構成・スライド／説明文のたたき台 に効きやすい一方、正確性の最終責任は人 に置くのが安全です。
- To-Beでは 「RPAで手を減らし、生成AIで頭のスタートを早くし、人で信用を担保する」 という三段が、上司連携のレポート業務ではバランスが取りやすいです。
- Excelは構造化・差分更新、PowerPointは型固定の差し替え にRPAを寄せ、ストーリーと文章 は生成AIの下書き＋人の校正、という切り分けが実務的です。
- セキュリティ区分・ログ・運用オーナー・KPI をセットで決めないと、ツール導入が「個人の工夫」で止まりやすいです。
業務の実態（対象システム、セキュリティポリシー、既存のテンプレ有無）によって最適解は変わるため、本記事は 検討のたたき台 として利用し、パイロット範囲と人の確認ゲートをセットで設計することをおすすめします。