チームの業務フローをAI前提で再設計する型

個人の自動化がチームに広がらない理由

S2（個人の雑務自動化）が進んだとき、次の問題が必ず起きる。「Aさんはメール下書きにAIを使っているけど、Bさんは全然使っていない」という個人差だ。

これは意識や努力の問題ではない。フローに組み込まれていないからだ。

Fujitsuの事例では、AIエージェントを提案書作成フローに組み込むことで工数を67%削減した¹。これは「誰かがAIを使った」ではなく、「提案書作成というフロー自体をAI前提で再設計した」結果だ。

業務フロー再設計の4ステップ

ステップ1: 現状フローの可視化（「正直に書く」が肝）

現状フローを図にする最大のポイントは「本当にやっていること」を書くことだ。理想ではなく、実態を。

黄色のステップ（考える・下書き）がAIに移せる最有力候補だ。

ステップ2: AIに移せるステップの特定

以下の基準で各ステップを判定する。

基準	AI向き	人向き
判断の種類	定型・ルールベース	例外・関係性・倫理
インプット	テキスト・構造化データ	非言語・複雑な文脈
アウトプット	文章・分類・要約	最終意思決定・責任
変動頻度	低い（毎回同じ）	高い（毎回状況が違う）

全てのステップをAIに渡そうとしなくていい。「考える・下書き」の2ステップをAIに渡すだけで、全体の所要時間は大幅に短縮できる。

ステップ3: 30/50/20チェックポイント設計

新フローを設計するときは「AIが失敗したら人がキャッチできるか」を必ず設計に含める。

この設計の重要なポイントは「C（品質確認）」を設けること。ここで人が確認することで、AIの出力品質を監視しながら、徐々に自動化範囲を広げられる。

ステップ4: ドキュメント化とフロー所有権

最も重要で最も省略されるステップ。フローをドキュメントに残さないと、担当者が変わった瞬間に全てが消える。

最低限ドキュメント化すること:

1. フロー図: どの順番で何をするか
2. プロンプト集: どのツールにどう頼むか（実際に使っているプロンプトをそのまま）
3. 例外パターン: どういう場合に人が判断するか
4. 品質基準: どの状態を「OK」とするか

フロー所有権はラインマネージャーに置く。特定の「AI詳しい人」に依存すると、その人が異動したとき全てが止まる。

実例: 営業日報の自動整形フロー

実装難易度: ノーコード（ZapierとClaude APIで2〜3時間）

効果:

• Before: 営業日報を書くのに15〜20分、マネージャーが確認するのに10分
• After: 営業は3分でフォーム入力、マネージャーは整形済みを1〜2分で確認

注意: プロンプトで「KPI（商談数・パイプライン金額・フォローアップ予定）を必ず抽出して」と指定することで、必要情報の抜け漏れが防げる。

よくある失敗: 属人化した自動化

「Aさんが作ったAI活用フローがBさんには使いこなせない」という問題が頻発する。これは設計の問題だ。

失敗パターン:

• プロンプトがAさんのPC上のメモに書かれている
• フローの設計をAさんしか知らない
• Aさんが詳細を覚えていることが前提になっている

解決策:

• プロンプトはNotionなどのチーム共有ツールに保存
• 「誰でも再現できるか」を設計基準にする
• 月1回、フローを別の人がそのまま実行してみる（再現性テスト）

Shopify・Fujitsuが示す「フロー全体」の発想

個人タスクの自動化に留まらず、ビジネスプロセス全体をAI前提で設計した事例を見ると、効果の桁が違う。

• Shopify RFP対応エージェント: 提案書の初稿生成から送付まで。自動生成した文書の50%が人手修正なしで使用された²
• Fujitsuの提案書作成: フロー全体をエージェント化した結果、工数を67%削減¹

共通点は「個人の使用量を増やした」のではなく「フローそのものをAI前提で再設計した」こと。

まとめ: フローとして残すことが目標

チームのプロセスAI化の成功基準は「フローとして残っているか」だ。

• 担当者が変わっても動き続けるか
• 新しく入った人がドキュメントを読めば再現できるか
• 品質確認のステップが設計に含まれているか

この3点を満たせば、そのフローは「誰かの工夫」ではなく「チームの仕組み」になった。

出典・参考

1. Fujitsu: AIエージェント導入で提案書作成工数67%削減（2024）
2. Shopify: RFPエージェントで生成文書の50%が無修正採用（2025）
3. BCG: AI変革のROI配分 — 技術10%・プロセス20%・人と組織70%