---
title: AIエージェント時代の業務自動化のコツ
tags: 
author: [Daisuke Miyata](https://docswell.com/user/miyatti)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LE3W8Y85E5.jpg?width=480
description: AIエージェント時代の業務自動化のコツ by Daisuke Miyata
published: July 24, 26
canonical: https://docswell.com/s/miyatti/K3JLMY-2026-07-24-185918
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LE3W8Y85E5.jpg)

AIエージェント時代の業務自動化
チームで成果を再現する「収束」ワークフロー
Explaza
NotebookLM

# Page. 2

![Page Image](https://bcdn.docswell.com/page/8EDKM5MY7G.jpg)

THE QUEST
自分の会社の業務プロセスを、最新のAIで自動化するには？その「ベストプラクティス」は何か？
前半（いま）
大まかな方向性と「答え」の前さばき。アーキテクチャの基本概念をインストールする。
後半（ハンズオン）
実際にAIワークフローツールを触って、ワークフローの効果と「どう作るか」を体験。
NotebookLM

# Page. 3

![Page Image](https://bcdn.docswell.com/page/V7PKRGR2J8.jpg)

THE CORE THESIS
生成AIで確実に成果が出るのは、発散（上流）ではなく「収束」＝型化できる定型業務のワークフロー化。業務を可視化して、チームみんなで回る形に、自分たちで作れる時代になった。
NotebookLM

# Page. 4

![Page Image](https://bcdn.docswell.com/page/2JVVR6RXJQ.jpg)

仕事を「発散」と「収束」の地図に置く
【発散】正解がなく、広げて磨く領域
要求整理・要件定義
アイディア・設計
あなたを抱えるその業務は、この地図のどこに配置されますか？
毎回同じ手順の部分は「型」にできる。発散の中から、収束側へ移行していく。
【収束】答えを作る「型」がある領域
仕様確認
ナレッジ参照
回答案作成
チケット化
NotebookLM

# Page. 5

![Page Image](https://bcdn.docswell.com/page/5EGLMNMRJL.jpg)

アプローチの比較：「F1カー」か、「自転車」か
発散 / F1カー
対象：スキルを持った一部の熟練者
AIの役割：個人の判断力と創造性を極限まで加速する
結果：属人的（乗り手によってタイムが激変する）
収束 / 自転車
対象：業務に関わるチーム全員
AIの役割：共通ルールと手順で、仕事の受け渡しを自動化する
結果：再現性（誰が乗っても一定のペースで目的地に着く）
チームで仕事を前へ進める主戦場は、全員が乗れる「自転車（収束側）」の設計にある。
NotebookLM

# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JQYRQRY7P.jpg)

The Architect's Workbench
なぜ「収束」が勝つのか？：ROIとコスト管理の構造
底抜けのバケツ
売上増
時間
不確実な売上増（発散）と、サブスク感覚での無計画なAI利用（従量課金によるコスト事故）。
計量カップ
総計コスト
時間
1000 tokens
500 tokens
200 tokens
100 tokens
計算可能なコストダウン（収束）。毎回同じ手順を「スキル」して型化することで、1回あたりの処理量（トークン）を見積もり、計画的なコスト管理が可能。外注費との比較も容易。
NotebookLM

# Page. 7

![Page Image](https://bcdn.docswell.com/page/K74W8N8ZE1.jpg)

「AIの誘惑」に負けない
優れたPMの発想方法や、社長の思考プロセスそのものをAIで再現したいという誘惑。
STOP
「かっこいいが、一旦優先順位を下げる。」
GO
定型業務の確実な自動化。
できないのではなく、アプローチが全く異なる。今日のテーマは「思考の再現」ではなく「業務自動化」である。
NotebookLM

# Page. 8

![Page Image](https://bcdn.docswell.com/page/LJ1Y252DEG.jpg)

自動化候補を選ぶ「3つの必要条件」
1. マニュアル化できる
2. 判断基準の明文化
3. 入口と出口の固定
業務 業務 業務 業務 業務 業務 業務 業務 業務
担当者の頭の中だけでなく、手順として説明できるか？
REJECTED
何をを見て対応を判断し、どの条件で人間に戻すか？
REJECTED
何をを受け取り、最後に何を返すかが定まっているか？
REJECTED
自動化候補
NotebookLM

# Page. 9

![Page Image](https://bcdn.docswell.com/page/GJWGR5R872.jpg)

The Blueprint：「前さばき」ワークフローの全体設計図
[入口]
[要点抽出]
[参照]
[回答案]
[人が確認 (HITL)]
[出口 / チケット化]
1. 入口：どんな問い合わせを、どんな形式で受け取るか？
2. 参照：回答を作るために、どのナレッジを見に行くか？
3. 人の確認：AIに任せきらず、どこで人間が判断し責任を持つか？
4. 出口：回答やチケットなど、仕事の成果として何を出すか？
この「型」を自社の業務に当てはめることから、チームの自動化が始まる
NotebookLM

# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EZLRNR973.jpg)

組織のボトルネック：「人間が翻訳機になる」悲劇
Aさん（神プロンプト）
Bさん（自己流AI）
人間が翻訳して橋渡し
各々がAIを使っても、結果の解釈と受け渡しで人間が「翻訳係」になってしまう。
うまくいった人のやり方が共有されず、再現性がない（本人が休むと止まる）。
個人の生産性は上がっても、チーム全体では「受け渡し」が新たなボトルネックに。
NotebookLM

# Page. 11

![Page Image](https://bcdn.docswell.com/page/Y76WR8RD7V.jpg)

The Blueprint: 共通ワークフローの全体設計図（複数のワークフローが連鎖する）
前さばき (Initial Triage)
入力
要点抽出・振分け
Next Workflow
対応 (Response/Action)
参照
回答案・アクション
人が確認 (HITL)
実行
記録 (Record/Output)
出力 / チケット化
ログ記録・分析
Complete
1. 前さばき：問い合わせの受付から、内容の自動分類と適切な担当・プロセスへの振分けまで。
2. 対応：ナレッジ参照、回答生成、またはアクション実行。人間による確認を経て、次の工程へ。
3. 記録：最終結果の出力、チケット作成、システムへの記録。業務の連鎖を完了させる。
個人の「最強ツール」ではなく、最初から「チームで使える共通ワークフロー」を繋げていく。
NotebookLM

# Page. 12

![Page Image](https://bcdn.docswell.com/page/G75M898874.jpg)

「グラフエンジニアリング」とは結局なにか？
流行りの魔法の言葉も、結局は「複数のワークフローを繋げて自社の最適解にする」というHow（手段）に過ぎない。
手段に振り回される必要はない。最も重要なのは、気負わずに「自分の業務プロセスを大まかに理解すること」。
業務プロセスの可視化は、相変わらず「人間の力」である。
NotebookLM

# Page. 13

![Page Image](https://bcdn.docswell.com/page/9J29K2KVER.jpg)

AI以前の前提条件：業務プロセスを可視化する
未整理の自社業務
PM / 企画職
整理された業務フロー
Insight
外部ベンダーには要件定義するのに、自社の日常業務は「詳しい人がよしなにやる」ブラックボックスになりがち。AIに「うまくやって」は通じない。
The Architect
ここは非エンジニア（PM・企画職・業務改善）の主戦場。自社の例外や責任分解点を知る人間こそが、設計の中心になる。
NotebookLM

# Page. 14

![Page Image](https://bcdn.docswell.com/page/DEY4NYNQJM.jpg)

ゼロから作らない。サンプルとの「差分」を編集する
白紙からすべての例外を洗い出して設計しようとすると、必ず挫折する。
考え方の入った「動くサンプル」を土台にする。「うちなら参照先はここ」「この判断基準を足す」と、ブロックを組み合わせるように自社の知識を注入する。
NotebookLM

# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJNYXPX278.jpg)

改造はコードではなく、チャットで指示する
Input
Reference Database
うちの会社のプロセスはこうだから、ここの参照先を変えて
Output
ゼロから作ると「そもそも何を作ればいいの？」で手が止まる。
動くサンプルがあれば、差分をチャットで指摘するだけで自社のプロセスに適合できる。自社の業務に合わせる部分こそ、AIに頼る。
NotebookLM

# Page. 16

![Page Image](https://bcdn.docswell.com/page/YE9P838DJ3.jpg)

私たちは狙うのは「中間」の道
完全外注（専用SaaS依存）
自社の特殊なフローに合わず、現場で使われなくなる。
☆サンプルを土台に、自分たちでチャット改造
「型化できる定型業務（自転車）」を、非エンジニアの手で自社専用にフィットさせる。
ゼロから自作（白紙から要件定義）
開発カロリーが高すぎ、例外処理の多さに挫折する。
Action Call
この「中間」のアプローチを、これからの後半セッション（Palmaハンズオン）で実際に体験します。
NotebookLM

# Page. 17

![Page Image](https://bcdn.docswell.com/page/GE8D8M85ED.jpg)

THE CORE THESIS
生成AIで確実に成果が出るのは、発散（上流）ではなく「収束」＝型化できる定型業務のワークフロー化。業務を可視化して、チームみんなで回る形に、自分たちで作れる時代になった。
NotebookLM