株式会社まつかぜ企画様 業務フロー分析・AI社員配属提案書

サンプル(架空企業)。展示会のAX診断でお聞きした内容(業種・規模・使っているシステム・仕事の入口・困りごと・情報の置き場所・特定の人に頼っている業務・手順の文書化)から、この形式の提案書を作成します。2〜6章の現状の記述は、同業種・同規模・同じシステム構成の企業で最も多い姿の推定です。

目次

1. 企業概要・システム全体像
2. 人手が支えている箇所の一覧
3. As-Is: 会議・決定事項ワークフロー
4. As-Is: 依頼受付・情報探索ワークフロー
5. As-Is: 業務知識の所在と属人性
6. As-Is: AI社員を受け入れる土台の現状
7. To-Be: 会議・決定事項ワークフロー(AI社員配属後)
8. To-Be: 依頼受付・情報探索ワークフロー(AI社員配属後)
9. システム構成(To-Be)
10. 導入ステップ
11. セキュリティ設計
12. 提供体制
13. 御社版の作成にあたって 付録A. 実装項目 付録B. 試用期間(PoC)の検証計画

1. 企業概要・システム全体像

現行システム構成図

情報の置き場所を、システムとシステム外(紙・記憶・個人の手控え)まで含めて描きます。

flowchart TD
  mail["Outlook<br>(顧客からの依頼・資料の添付)"] --> tanto["各部署の担当者"]
  teams["Teams<br>(社内の依頼・DM)"] --> tanto
  denwa["電話<br>(社内・営業所からの依頼)"] -->|"口頭"| tanto
  fax["FAX複合機<br>(営業所からの依頼)"] -->|"紙"| tanto
  tanto -->|"案件の登録・更新"| kintone["kintone<br>(案件管理)"]
  tanto -->|"起票(起票されない宿題もある)"| backlog["Backlog<br>(タスク管理)"]
  soumu["管理部総務1名<br>(議事録の作成)"] -->|"手入力"| notion["Notion<br>(議事録・社内手順書。<br>手順書がある業務は半々)"]
  kaigi["定例・案件打ち合わせ<br>(決定と宿題は口頭で確定)"] --> soumu
  sp["SharePoint<br>(現行資料。最新版の判別は<br>メール添付との見比べ)"] --- tanto
  nas["社内ファイルサーバ<br>(旧資料。過去帳票・古い版)"] --- tanto
  memo["個人の手控え・記憶<br>(決定の経緯、人と取引先の呼び名、<br>過去に返した回答)"] --- tanto
  freee["freee会計<br>(経費・請求)"] --- kanri["管理部(経理)"]
  kot["KING OF TIME<br>(勤怠)"] --- kanri

2. 人手が支えている箇所の一覧

御社の業務は、システムとシステムの間を担当の方々が人手でつなぐことで、毎日回っています。この章では、その人手が支えている箇所を一覧にします。支えている箇所には負担が集中しやすく、担当の方の不在や繁忙期に綻びやすいためです。展示会で伺った内容と、業種×規模×システム構成からの推定を並べ、出所の列で区別します。推定の行は「同じ構成の企業で最も多い姿」であり、御社に当てはまるかの確定は診断セッションで行います。

一覧を眺めると、人手が支えているのは、個々のシステムの中ではなく、システムとシステムの間、またはシステムと記憶の間です。支え方の型は3つに集約されます。紙と口頭で届く依頼や決定を人が読み取って入力していること、判断に使う知識(決定と検討中の線引き、人と取引先の呼び名、過去に返した回答)が記憶と手控えにあること、システム間の照合(SharePointとメール添付、kintoneとBacklogとNotion)を人がまとめて行っていることです。これは担当の方々の工夫で業務が成立している姿であり、同時に、その方々に負担が集中する構造でもあります。

診断セッションで確認する点

• 推定の行は、御社にも当てはまりますか。すでに運用や仕組みでカバーされている行はどれですか。
• この一覧に載っていない箇所で、現場の負担になっているものはありますか。
• この中で、時間または影響が最も大きいのはどれですか。

3. As-Is: 会議・決定事項ワークフロー

部署別の週次定例が3本、加えて案件ごとの打ち合わせがあり、記録の対象となる会議は週あたり10本前後と推定します。議事録は管理部総務1名が中心となって作成し、案件打ち合わせでは参加者の誰かが書く形が混在すると推定します。

ヒアリングでは「書く人によって粒度がぜんぜん違って。決まったことなのか、まだ検討中なのかが読んでて分からない」とのことでした。

3-1. 会議の1サイクル

3-2. 決定事項と宿題の流れ

flowchart TD
  kaigi["会議での議論"] --> kettei["決定・宿題の口頭合意"]
  kettei --> memo["メモの作成<br>(総務または参加者の一人)"]
  memo -->|"書き起こす"| notion["Notionの議事録"]
  memo -->|"書き起こされない回"| kioku["記憶と個人の手控えに残る"]
  notion --> yomite["読み手が参照"]
  yomite -->|"決定か検討中か判別できない"| toiawase["書き手へ口頭で確認"]
  toiawase --> soumu["総務が経緯を説明<br>(不在時は保留)"]
  kettei --> shukudai["宿題(担当・期限)"]
  shukudai -->|"起票された分"| backlog["Backlogの課題"]
  shukudai -->|"起票されない分"| omoidashi["期限直前に思い出して着手"]
  kioku --> jikai["次回会議で再確認"]
  omoidashi --> jikai

3-3. 診断セッションで確認する点

• 議事録の書式(決定・検討中・宿題の欄立て)は、決まった型として存在しますか。書き手ごとの裁量ですか。
• 会議の音声や自動文字起こしを取得している会議はありますか。取得の可否について社内の合意はどこまで進んでいますか。
• 宿題をBacklogに起票する担当は、発言者本人ですか、主催者ですか、総務ですか。

4. As-Is: 依頼受付・情報探索ワークフロー

依頼は顧客からのメール、社内のTeamsダイレクトメッセージ、電話、営業所からのFAXの4経路で届きます。経路ごとに窓口が分かれておらず、受けた方がそのまま抱える形が多いと推定します。

4-1. 依頼が届いてから着手までの流れ

4-2. 情報探索のデータフロー

flowchart LR
  irai["依頼の受領<br>(メール・DM・電話・FAX)"] --> tokutei["誰の・どの案件の話かの特定"]
  tokutei -->|"名前の突き合わせ"| namae["メール表示名 / Teams名 /<br>社内の呼び名 / 取引先の部署名"]
  tokutei --> kensaku["過去の類似回答の探索"]
  kensaku --> notion["Notion<br>(議事録・手順書)"]
  kensaku --> outlook["Outlookのメール履歴"]
  kensaku --> sp["SharePoint"]
  kensaku --> nas["社内ファイルサーバ(旧資料)"]
  notion --> handan["最新版・正しい回答の判断"]
  outlook --> handan
  sp --> handan
  nas --> handan
  handan -->|"見つかる"| ryuyo["流用して回答"]
  handan -->|"見つからない"| shinki["一から作成"]
  ryuyo --> kihyo["Backlogへ起票して着手"]
  shinki --> kihyo

4-3. 診断セッションで確認する点

• 4経路のうち、件数と緊急度が高いのはどの経路ですか。窓口を寄せられる余地はどこにありますか。
• SharePointと社内ファイルサーバの使い分けの基準は決まっていますか。旧資料の移行は検討されていますか。
• 過去の回答を再利用する場面(顧客への回答、社内への説明、見積の前提など)のうち、頻度が高いのはどれですか。

5. As-Is: 業務知識の所在と属人性

会議の運営と依頼の処理を成立させている知識の置き場所を整理します。

属人性は、担当者が抜けたときに何が止まるかを並べると、そのまま見えてきます。止まるものの一覧は、文書に起こすべき知識の目次でもあります。

6. As-Is: AI社員を受け入れる土台の現状

2〜5章は業務の流れと知識の姿でした。この章は、AI社員を配属するために必要な土台が現時点でどこまで揃っているか、いわばAI ready度を整理します。まず全体を一覧で示し、システム別の接続の詳細と、◯に変わるまでの道のりを続けます。判定はシステム構成からの推定で、確定は診断セッションで行います。判定の根拠を埋める作業は、付録Aの実装項目に対応づけています。

判定は4値です。◯ 足りている / △ 一部足りている・版による / ✕ これから整える / ? 診断セッションで確認。

✕と△が並びますが、いずれも第一・第二工程で埋まる種類のもので、どの工程で◯に変わるかは6-2に対応表があります。

6-1. 接続手段

接続のしやすさの列は、当社カタログの一般情報(◎ 公式APIが充実 / ○ APIあり / △ 版・契約による / ✕ 手作業前提)で、確定は導入時に版・契約を確認して行います。

6-2. AI readyまでの道のり

冒頭の一覧で✕と△が付いた観点は、10章の導入ステップの中で次の順に◯へ変わります。

6-3. この章の読み方

足りない項目が並びますが、いずれも第一工程(10章)の中で当社が主導して埋める種類の作業で、御社の業務を止めるものはありません。埋める作業の中身と順序は、業務の実物を拝見しないと確定できないため、診断セッションの議題とします。

主要なシステムがMicrosoft 365・kintone・SharePoint・freee会計と、いずれも公式APIの整ったもので揃っていることは、この規模の会社では恵まれた条件です。整備の中心は、口頭と紙で届く仕事のデータ化、決定と最新版の正の明文化、そして人と案件の名寄せの3つに絞られます。

7. To-Be: 会議・決定事項ワークフロー(AI社員配属後)

配属後の姿は、御社固有の情報(人と取引先の呼び名の対応、案件と議事録と課題の紐付け、決定と検討中の線引き、資料の正の版)を整理したうえに成り立ちます。この章の直前に差し込んだ立体の地図は、その整理の成果物の姿です。下段が情報の置き場所(接続に導入時の確認が要るものは接続候補と表示)、中段が御社の業務で共通に扱う実体とその関係、上段がAI社員に任せる仕事です。上段の仕事を選ぶとその仕事が使う実体・元データ・読み替えが光り、実体を選ぶと判断材料がどこから来てどの仕事につながるかをたどれます。実体をつなぐ線は、システムに記録済みのつながり、導入で整理して作るつながり、合っているかを照合するつながりの3種に分かれます。

そのうえで、2章で挙げた人手の支えを、それぞれどこでAI社員が引き継ぐかを対応づけます。

7-1. 配属案

7-2. 会議記録担当AIの職務定義

7-3. 配属後の会議記録フロー

flowchart TD
  mae["会議の前日"] --> junbi["会議記録担当AIが前回の決定・<br>未了の宿題・関連資料をまとめる"]
  junbi --> teams1["Teamsに提示"]
  kaigi["会議"] --> motozuki["メモ・文字起こしを取得"]
  motozuki --> ai["会議記録担当AIが下書きを作成"]
  ai --> wake["決定 / 検討中 / 宿題に切り分け"]
  wake -->|"基準で判定できる"| soan["議事録の下書き+宿題の起票案"]
  soan --> kakunin["主催者・総務が確認"]
  kakunin --> notion["Notionへ確定・版を記録"]
  kakunin --> backlog["Backlogへ起票(担当・期限つき)"]
  wake -->|"判定できない<br>(決定か保留か曖昧・担当未定・期限未定)"| reigai["例外としてTeamsで照会<br>(論点を整理して提示)"]
  reigai --> handan["主催者が判断"]
  handan --> tsuiki["判断結果を業務マニュアルと<br>判定基準に追記(版管理)"]
  tsuiki -.->|"以後、同型の議題はAIが切り分け"| ai

決定か検討中かの判断に確信が持てない項目は、決定として書き切らず例外として人に回します。切り分けの精度を約束する方式ではなく、確信の持てないものを人に回す設計で、記録の誤りを防ぎます。会議の音声を取得していない会議は、当面は参加者のメモを入力として受け取る形から始めます。

7-4. 配属後の会議の1サイクル

例外の比率は導入初期が最も高く、判断のたびに判定基準とマニュアルへ追記されるため、運用とともに下がる構造です。

8. To-Be: 依頼受付・情報探索ワークフロー(AI社員配属後)

8-1. 依頼受付担当AIの職務定義

8-2. 配属後の1日

電話での依頼は当面は人が受け、内容のメモをAIへの依頼に置き換えるところから始めます。営業所からのFAXは、複合機のPDF転送を設定した時点で一覧に載ります。

8-3. 変化の見立て(推定)

実数の測定は、試用期間中に御社の会議と依頼の実物で行います(付録B)。

9. システム構成(To-Be)

flowchart TD
  m365["Microsoft 365<br>(Teams・Outlook)"] --> madoguchi
  kintone["kintone"] --> madoguchi
  backlog["Backlog"] --> madoguchi
  notion["Notion"] --> madoguchi
  sp["SharePoint"] --> madoguchi
  nas["社内ファイルサーバ"] --> madoguchi
  faxin["FAX受信(PDF)"] --> madoguchi
  freee["freee会計 / KING OF TIME<br>(第三工程)"] --> madoguchi
  madoguchi["各システムとAIの間の窓口(システムごとに設置)<br>・アクセスできる範囲の制御(権限)<br>・全操作の記録(監査ログ)<br>・意味辞書(人と取引先の名寄せ、案件の紐付け、<br>決定と検討中の判定基準、正となる資料の定義)"]
  madoguchi --> kaigiAI["会議記録担当AI"]
  madoguchi --> ukeAI["依頼受付担当AI"]
  kaigiAI -->|"報告・例外照会・承認依頼"| teams["Teams"]
  ukeAI -->|"報告・例外照会・承認依頼"| teams
  teams <-->|"判断・承認"| hito["各部署の担当者・管理部総務"]

• 既存システムの入れ替えは行いません。Microsoft 365・kintone・Backlog・Notion・SharePoint・社内ファイルサーバは現行のまま、AI専用の窓口を追加します。
• AIがシステムに触れる経路は窓口だけに限定され、窓口を通らないアクセスはできません。

意味辞書に登録する内容の一覧は、付録A-2にまとめています。

10. 導入ステップ

第一工程の内容は、6章で足りないとした項目にそのまま対応します。

導入後に社内に残るものは次の3点で、いずれもファイルの形を持ちます。

1. 業務マニュアル。議事録の型、決定と検討中の判定基準、例外対応の追記を含む、版管理された手順書
2. 意味辞書。人と取引先の名寄せ、案件の紐付け、正となる資料の定義といった、データの読み方の登録集
3. 監査ログ。AIがいつ何を参照しどの操作をしたかの全記録

利用をやめた場合も、この3点は読める形式のファイルとして手元に残ります。

他の手段との比較

導入後も続く運用

業務は変わり続けます。新しい取引先、会議体の組み替え、使用システムの入れ替え。月額利用の中では、例外判断のマニュアル・辞書への反映、接続先の変化への追従、任せる業務の拡張が続きます。AI社員の仕事の範囲は、配属時の定義から運用の中で広がっていきます。

実装項目の一覧は付録A、試用期間の検証計画は付録Bにまとめています。

11. セキュリティ設計

11-1. データの経路と実行の条件

• システム操作の実行は、依頼した本人・その場に同席する全員・AI社員自身の3者すべてに権限がある場合に限られ、未登録の操作・身元不明の参加者は拒否が既定値です。
• 議事録の確定、Backlogへの起票、社外に出る文面の送信といった操作には人の承認が必ず挟まり、許可・拒否を問わずすべての実行が監査ログに残ります。
• 非公開の会議や役員会議など、AIの参照対象から外す会議体は導入時に指定できます。
• 提供環境は1社ごとに独立し、他社とデータベースを共有しません。

11-2. 導入時によく確認される事項

12. 提供体制

導入から運用まで、技術担当と導入支援担当が付きます。問い合わせは担当窓口に一本化します。

13. 御社版の作成にあたって

本書は架空企業のサンプルです。2〜6章のAs-Isはシステム構成からの推定であり、御社の実際の業務・会議体・例外ルールを反映していません。

御社版の作成は、短時間の診断セッションから始めます。セッションでは次の3点を持ち帰っていただけます。

1. 2章の一覧を御社の実際に合わせて確定した、人手が支えている箇所の一覧表
2. お使いのシステム(Microsoft 365・kintone・Notion・Backlog・SharePoint・freee会計・KING OF TIME)のプランと契約に応じた、接続方式と可否の回答
3. どの会議体・どの依頼経路から、どんな体制で始められるかの初期見立て

セッションは技術担当が同席し、ご希望に応じてNDA締結後に実施します。議題は事前にお送りする内容に固定します。お申し込みは、ブースの担当者にお声がけください。

(セッションを予約されない場合、こちらからの営業連絡は行いません。)

付録A. 実装項目

実装の中心は、各システムとAIの間の窓口(標準規格MCPによる接続)の構築と、業務ナレッジ(意味辞書・業務マニュアル)の整備の2つです。項目をID付きで整理します。

A-1. 窓口の接続

すべての窓口に、アクセス範囲の制御と全操作の記録が標準で備わります。既製の接続部品がある接続先はそれを使い、ない接続先は個別に開発して納品します。

A-2. 意味辞書の整備

A-3. 業務マニュアルの整備

A-4. AI社員の設定

A-5. 開始前に一緒に確認する事項

いずれも第一工程の中で当社が主導して進めます。御社に単独でお願いする作業はありません。

A-6. 非機能要件

環境の独立と監査ログの扱いは11章のとおりです(保持期間は導入時に取り決めます)。

付録B. 試用期間(PoC)の検証計画

導入は試用期間として小さく始め、開始前に合意した水準で本番化を判定します。

B-1. 試用期間の範囲

B-2. 検証項目と指標

本番化の水準は試用期間の開始前に合意し、文書に残します。表の水準は例です。