陽光建設工業株式会社様 業務フロー分析・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
  denwa["電話<br>(引き合い・手配・材料依頼)"] -->|"口頭"| genba["現場所長・現場監督"]
  taimen["対面・立ち話<br>(追加工事・変更の相談)"] -->|"口頭"| genba
  fax["FAX複合機<br>(見積依頼書・図面)"] -->|"紙"| sekisan["積算担当"]
  mail["Outlook<br>(見積依頼・発注書・連絡)"] --> sekisan
  teams["Teams / LINE<br>(現場写真・進捗・変更連絡)"] --> genba
  genba -->|"手書き・貼り替え"| wb["ホワイトボード<br>協力会社の割り振り表"]
  genba -->|"貼り直し"| daicho["Excel 工事写真台帳"]
  genba -->|"手入力"| yosanExcel["実行予算Excel<br>(現場監督ごとに様式が異なる)"]
  sekisan -->|"マクロで集計"| genkaExcel["原価集計Excel<br>(積算担当が自作)"]
  yosanExcel --> genkaExcel
  yayoi["弥生会計"] -->|"計上額を手で参照・転記"| genkaExcel
  andpad["ANDPAD<br>(一部の現場のみ)"] --> genba
  fs["ファイルサーバ・NAS<br>図面(AutoCAD・JW-CAD)・写真・過去物件<br>(最新版の判別は担当者の記憶)"]
  memo["個人の手控え・記憶<br>(職人ごとの得手・段取りの順序<br>材料の通称、追加工事の経緯)"]
  kami["紙の出面表<br>(現場の職人の稼働)"]

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

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

一覧を眺めると、人手が支えているのは、個々のシステムの中ではなく、システムとシステムの間、またはシステムと記憶の間です。支え方の型は3つに集約されます。電話・対面・紙で届く仕事を人が読み取ってExcelやホワイトボードに書き写していること、判断に使う知識(職人ごとの段取り、材料の通称、追加工事の経緯)が記憶と手控えにあること、現場ごとに散らばった数字と写真の照合を人がまとめて行っていることです。これは担当の方々の工夫で業務が成立している姿であり、同時に、その方々に負担が集中する構造でもあります。

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

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

3. As-Is: 協力会社の手配・現場段取りワークフロー

同時に動く現場が10〜20件程度あり、そのうち複数の協力会社が入る現場が大半を占めると推定します。手配の起点は電話と対面で、ホワイトボードが全体像の唯一の置き場所になっている前提で描きます。

3-1. 手配・段取りの1週間

3-2. 協力会社手配のフロー

flowchart TD
  hitsuyo["必要人工の見込み<br>(工程表・現場の進捗から判断)"] --> zenpan["全体の空き状況を確認<br>(ホワイトボード+所長の記憶)"]
  zenpan -->|"空きが判断できる"| denwa["協力会社へ電話で打診"]
  denwa -->|"了承"| kinyu["ホワイトボードへ記入"]
  kinyu --> chumon["注文書の作成・送付(メール・FAX)"]
  denwa -->|"断り・条件付き"| betsu["別の協力会社を探す<br>(所長の人脈から)"]
  betsu --> denwa
  zenpan -->|"件数が多く全体が追えない"| kasanari["重複発注または手配の抜け"]
  kasanari --> chosei["現場直前の調整<br>(電話での再手配)"]
  zenpan -->|"所長が不在"| taiki["手配が待ちになる<br>(代わりに判断できる人がいない)"]

ヒアリングでは「いまだにホワイトボードでやってて、現場の件数が増えてくると誰がどこに入ってるか分からなくなる」とのことでした。全体像がひとつの物理的な板に載っており、そこを読み解ける人が限られている構造として捉えています。

3-3. 現場情報の流れ

flowchart LR
  genba["現場(監督・職人)"] -->|"写真・進捗"| teams["Teams / LINE"]
  genba -->|"口頭"| shocho["現場所長"]
  teams -->|"流れて埋もれる"| kioku["経緯は記憶と個人メモに残る"]
  teams -->|"後日まとめて貼り直し"| daicho["Excel 工事写真台帳"]
  shocho -->|"手書き"| wb["ホワイトボード"]
  shocho -->|"随時報告"| honsha["本社(工事部・管理部)"]
  andpad["ANDPAD(一部現場)"] --> honsha

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

• 協力会社ごとの得意工種・稼働可能な人数は、文書として存在しますか。所長の記憶に分かれていますか。
• ホワイトボードの内容を、所長以外の方が読み取って引き継ぐことはできますか。
• 追加工事・変更が「正式に決まった」とみなす条件は、どこかに定められていますか。
• ANDPADを運用している現場と、Teams・紙で運用している現場の切り分けはどのようになっていますか。

4. As-Is: 実行予算・原価管理ワークフロー

実行予算は現場監督が着工前に作成し、原価は月次で積算担当が集計する前提で推定します。会計は弥生会計で、原価の管理は会計とは別のExcel上で行われている構成として描きます。

4-1. 着工から原価締めまでのタイムライン

4-2. 原価集計のデータフロー

flowchart LR
  yosanA["実行予算Excel<br>(現場A・監督Aの様式)"] --> shusshu["回収・様式の読み替え"]
  yosanB["実行予算Excel<br>(現場B・監督Bの様式)"] --> shusshu
  yosanC["実行予算Excel<br>(現場C・監督Cの様式)"] --> shusshu
  shusshu --> macro["原価集計Excel<br>(積算担当の自作マクロ)"]
  seikyu["協力会社・商社の請求書<br>(紙・メール)"] --> macro
  yayoi["弥生会計"] -->|"計上額を手で参照"| shogo["目視での見比べ"]
  macro --> shogo
  shogo -->|"差異あり"| sakanobori["伝票・注文書・やりとりの遡り調査"]
  macro --> hokoku["現場別原価の報告"]

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

• 実行予算Excelの様式差は、費目の分け方の違いですか、シートの構成の違いですか。共通の骨格はどこまでありますか。
• 原価と会計の突合は、どの粒度(現場別・費目別・伝票別)で行っていますか。
• 積算担当の自作マクロは、どの処理を担っていますか(集計・按分・請求書との照合など)。
• 見積フォーマットの違いは、社内比較のときに具体的にどの項目で困りますか。

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が全社に入っていることとANDPADの導入が始まっていることが、有利な条件です。連絡と写真の入口がすでにデータで届く経路を持っているため、整備の中心は、現場・協力会社・費目のIDの軸を立てることと、記憶にある段取りの知識を辞書化することの2つに絞られます。ANDPADが一部の現場に限られている点は、対象を広げるかどうかも含めて診断セッションで扱います。

7. To-Be: 協力会社の手配・現場段取りワークフロー(AI社員配属後)

配属後の姿は、御社固有の情報(現場と協力会社の対応、材料の通称の読み替え、実行予算の費目の骨格、追加工事の合意条件)を整理したうえに成り立ちます。この章の直前に差し込んだ立体の地図は、その整理の成果物の姿です。下段が情報の置き場所(接続に導入時の確認が要るものは接続候補と表示)、中段が御社の業務で共通に扱う実体とその関係、上段がAI社員に任せる仕事です。上段の仕事を選ぶとその仕事が使う実体・元データ・読み替えが光り、実体を選ぶと判断材料がどこから来てどの仕事につながるかをたどれます。実体をつなぐ線は、システムに記録済みのつながり、導入で整理して作るつながり、合っているかを照合するつながりの3種に分かれます。

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

7-1. 配属案

7-2. 現場調整AIの職務定義

7-3. 配属後の手配フロー

flowchart TD
  kotei["工程表・現場の進捗<br>(ANDPAD・Teams・現場報告)"] --> ai["現場調整AIが必要人工を整理"]
  ai --> daicho["手配台帳と突き合わせ"]
  daicho -->|"空きがある協力会社を提示"| teian["候補と根拠(得意工種・直近の稼働)を提示"]
  teian --> handan["現場所長・工事部が打診を判断"]
  handan -->|"了承を得た"| koshin["台帳を更新し、注文書の下書きを作成"]
  koshin --> shonin["人が確認して発注"]
  daicho -->|"重複または空白を検知"| keikoku["Teamsへ報告<br>(該当現場・日付・協力会社を明示)"]
  keikoku --> handan
  ai -->|"判断材料が足りない<br>(未登録の協力会社・新工種)"| reigai["例外としてTeamsで報告"]
  reigai --> handan2["所長・工事部が判断"]
  handan2 --> tsuiki["判断結果を業務マニュアルと意味辞書に追記<br>(版管理)"]
  tsuiki -.->|"以後、同型の手配はAIが候補を出せる"| ai

手配の打診と決定は人が行い、AIは全体像の保持と検知に徹します。人の関係性に踏み込む判断をAIに移す設計ではなく、所長の頭の中にあった全体像を台帳として社内に置く設計です。ホワイトボードは当面併用し、台帳が実務に耐えることを確認しながら移していきます。

7-4. 追加工事・変更の記録フロー

flowchart TD
  kiten["変更の起点<br>(現場での立ち話・電話・Teams)"] --> kiroku["担当者がTeamsに一言投稿<br>(または通話メモ)"]
  kiroku --> ai["現場調整AIが変更候補として台帳に登録"]
  ai --> jotai["状態を管理<br>相談中 / 見積提示 / 合意 / 見送り"]
  jotai -->|"見積が必要"| mitsumori["原価管理AIへ引き継ぎ(8章)"]
  jotai -->|"合意に進める判断"| shonin["所長・営業が承認して状態を更新"]
  jotai -->|"相談中のまま日数が経過"| taikatsu["未決の一覧としてTeamsへ報告"]
  shonin --> hozon["合意の内容と経緯を現場単位で保存"]

7-5. 配属後の1日

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

8. To-Be: 実行予算・原価管理ワークフロー(AI社員配属後)

8-1. 原価管理AIの職務定義

8-2. 配属後の月次タイムライン

8-3. 実行予算の骨格の扱い

flowchart LR
  yosanA["実行予算Excel<br>(現場A)"] --> yomikae["原価管理AIが<br>共通骨格へ読み替え<br>(意味辞書の費目対応)"]
  yosanB["実行予算Excel<br>(現場B)"] --> yomikae
  yosanC["実行予算Excel<br>(現場C)"] --> yomikae
  yomikae --> shukei["現場別・費目別の原価集計"]
  chumon["注文書・出来高・請求書"] --> shukei
  yayoi["弥生会計(計上額)"] --> shogo["日次照合"]
  shukei --> shogo
  shogo -->|"差異あり"| ichiran["差異一覧+根拠を提示"]
  shukei --> saishin["最新の現場別原価を随時参照"]
  yomikae -->|"未登録の費目・様式の変更"| reigai["例外として報告"]
  reigai --> tsuiki["費目対応を辞書に追記"]

現場監督ごとの様式をすぐに統一する前提には立ちません。共通の骨格を定めて、既存の様式は辞書の費目対応で読み替えます。様式を揃えるかどうかは、読み替えの実績が見えてから判断できます。積算担当の自作マクロが担っている処理は、内容を伺ったうえで業務マニュアルに起こし、AIが実行する手順として社内に残します。

8-4. 時間の変化(推定)

実数の測定は、試用期間中に御社の現場と帳票で行います(付録B)。

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

flowchart TD
  m365["Microsoft 365<br>(Teams・Outlook)"] --> madoguchi
  andpad["ANDPAD"] --> madoguchi
  fs["ファイルサーバ・NAS<br>(図面・写真・過去物件)"] --> madoguchi
  yayoi["弥生会計"] --> madoguchi
  excel["実行予算・原価・見積Excel"] --> madoguchi
  faxin["FAX受信(PDF)"] --> madoguchi
  madoguchi["各システムとAIの間の窓口(システムごとに設置)<br>・アクセスできる範囲の制御(権限)<br>・全操作の記録(監査ログ)<br>・意味辞書(材料の通称、費目の対応、協力会社の情報、正となる数字の定義)"]
  madoguchi --> genbaAI["現場調整AI"]
  madoguchi --> genkaAI["原価管理AI"]
  genbaAI -->|"報告・例外照会"| teams["Teams"]
  genkaAI -->|"報告・例外照会"| teams
  teams <-->|"判断・承認"| hito["現場所長・工事部・積算担当・管理部"]

• 既存システムの入れ替えは行いません。弥生会計・ANDPAD・ファイルサーバ・CADは現行のまま、AI専用の窓口を追加します。
• 現場のExcelも作り替えを前提としません。共通の骨格を定めて読み替える形から始めます。
• AIがシステムに触れる経路は窓口だけに限定され、窓口を通らないアクセスはできません。

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

10. 導入ステップ

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

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

1. 業務マニュアル。現場の段取りの順序、手配の進め方、原価締めの手順を含む、版管理された手順書
2. 意味辞書。材料の通称、費目の対応、協力会社の得意工種をはじめとする、データの読み方の登録集
3. 監査ログ。AIがいつ何を参照しどの操作をしたかの全記録

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

他の手段との比較

導入後も続く運用

業務は変わり続けます。新しい協力会社、工種の追加、発注者ごとの様式の変更、ANDPADの適用現場の拡大。月額利用の中では、例外判断のマニュアル・辞書への反映、接続先の変化への追従、任せる業務の拡張が続きます。AI社員の仕事の範囲は、配属時の定義から運用の中で広がっていきます。

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

11. セキュリティ設計

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

• システム操作の実行は、依頼した本人・その場に同席する全員・AI社員自身の3者すべてに権限がある場合に限られ、未登録の操作・身元不明の参加者は拒否が既定値です。
• 協力会社への発注連絡、材料の発注、原価の締めの確定などの重要操作には人の承認が必ず挟まり、許可・拒否を問わずすべての実行が監査ログに残ります。
• 現場に出ている方が携帯から使う場面を想定し、参照できる範囲は現場単位・役割単位で区切ります。
• 提供環境は1社ごとに独立し、他社とデータベースを共有しません。

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

12. 提供体制

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

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

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

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

1. 2章の一覧を御社の実際に合わせて確定した、人手が支えている箇所の一覧表
2. お使いのシステムの版に応じた、接続方式と可否の回答(弥生会計・ANDPAD・AutoCAD・JW-CADを含む)
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. 検証項目と指標

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