湘南物流サービス株式会社様 業務フロー分析・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["電話(受注の最多経路)"] -->|"口頭"| note["受注ノート(紙)"]
  fax["FAX複合機"] -->|"紙"| note
  mail["メール"] --> haisha["配車課"]
  note --> haisha
  haisha -->|"手書き・手入力"| wb["ホワイトボード<br>(当日の配車。随時書き換え)"]
  haisha -->|"手入力"| ex["個人のExcel<br>(配車表・運行実績の控え)"]
  haisha -->|"受注の登録"| kikan["自社開発の基幹システム<br>(受注管理)"]
  driver["ドライバー約50名"] -->|"紙で提出"| nippo["運転日報(紙)"]
  nippo -->|"事務所で打ち直し"| ex
  ex -->|"転記"| seikyu["請求書(Excel)"]
  ex -->|"手計算"| kyuyo["歩合給・残業代の計算(Excel)"]
  kyuyo -->|"金額を手で転記"| yayoi["弥生会計"]
  seikyu -->|"売上を手で転記"| yayoi
  jobcan["ジョブカン勤怠<br>(出退勤の打刻)"] -->|"目視参照"| kyuyo
  digitaco["デジタコ(矢崎)<br>運行データ"] -.->|"参照は限定的"| haisha
  trabox["トラボックス<br>(空車探し)"] -.->|"画面を見て電話"| yousha["傭車先への電話"]
  fs["ファイルサーバ・NAS<br>伝票・帳票・点呼記録・日報綴り"]
  memo["担当者の頭の中<br>(荷主ごとの納品条件、ドライバーの状態、<br>傭車先の付き合い、歩合の例外)"]
  haisha --- memo

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

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

一覧を眺めると、人手が支えているのは個々のシステムの中ではなく、システムとシステムの間、またはシステムと記憶の間です。支え方の型は3つに集約されます。電話とFAXと紙の日報で届く仕事を人が読み取って入力していること、配車と給与の判断に使う知識(荷主の納品条件、ドライバーの状態、傭車先の当て、歩合の例外)が記憶と手控えにあること、日報・デジタコ・基幹システム・弥生会計の間の照合を人がまとめて行っていることです。これは担当の方々の工夫で業務が成立している姿であり、同時に、その方々に負担が集中する構造でもあります。

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

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

3. As-Is: 受注・配車ワークフロー

区域配送を主とし、荷主からの当日・翌日の依頼が電話とFAXでまとまって届く前提で推定します。営業所3か所ぶんの車両とドライバーを、配車課が横断して割り付けている姿を想定します。

3-1. 受注・配車の1日

3-2. 受注から配車確定までのフロー

flowchart TD
  juchu["注文の受領<br>(電話・FAX・メール)"] --> note["受注ノートへ書き取り"]
  note --> joken["荷主ごとの条件の確認<br>(納品時間・積み下ろし・車格)"]
  joken -->|"条件が分かる"| wari["車両・ドライバーの割り付け<br>(得意エリア・当日の状態を踏まえる)"]
  joken -->|"条件が分からない"| eigyo["営業担当に電話で確認"]
  eigyo --> wari
  wari -->|"自社車両で足りる"| wb["ホワイトボードへ記入・指示連絡"]
  wari -->|"車両が足りない"| trabox["トラボックスで空車を確認"]
  trabox --> tel["付き合いのある傭車先へ順に電話"]
  tel -->|"確保"| wb
  tel -->|"確保できない"| chosei["荷主と納期・便の調整"]
  chosei --> wb
  wb --> henko["当日の追加便・欠勤・遅延"]
  henko -->|"書き直し"| wb
  wb --> jisseki["実績は紙の日報として翌日以降に集約"]

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

• 荷主ごとの納品条件(時間指定・積み下ろし・車格・付帯作業)は、文書として存在しますか。営業の方それぞれの手控えに分かれていますか。
• 当日の配車変更は、ホワイトボード以外のどこかに記録が残りますか(Excelの控え、LINE WORKSの指示履歴など)。
• 傭車先の一覧と取り決め単価は、どこにありますか。声をかける順序の考え方は共有されていますか。
• 基幹システムには、受注のどこまで(荷主・便・車両・実績)が登録されていますか。

4. As-Is: 日報・請求・給与ワークフロー

月末締めの荷主を主とし、ドライバーの給与が固定給に歩合と残業代を加えた構成である前提で推定します。

4-1. 締めから支払までのタイムライン

4-2. 実績データの流れ

flowchart LR
  nippo["運転日報(紙)"] -->|"打ち直し"| ex["Excel(実績)"]
  wb["ホワイトボード<br>(書き換えで消える)"] -.->|"記憶と控えで補う"| ex
  digitaco["デジタコ<br>運行データ"] -.->|"必要時に個別確認"| ex
  ex --> seikyu["請求書(Excel)"]
  ex --> kyuyo["歩合・残業代の計算(Excel)"]
  jobcan["ジョブカン勤怠"] -->|"目視参照"| kyuyo
  yousha["傭車先の請求書(紙・FAX)"] --> shogo["取り決め単価との照合"]
  shogo --> shiharai["支払処理"]
  seikyu -->|"手で転記"| yayoi["弥生会計"]
  kyuyo -->|"手で転記"| yayoi
  shiharai -->|"手で転記"| yayoi

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

• 請求単価の体系は、荷主ごとに何種類ありますか(距離制・時間制・個建て・付帯作業の加算など)。
• 待機時間・高速代・付帯作業の請求根拠は、日報とデジタコのどちらを正としていますか。
• 歩合給の例外(区域ごとの単価、欠勤時の扱い、傭車に出た日の扱いなど)は、いくつくらいの型に整理できそうですか。
• ジョブカン勤怠の打刻と日報の運行時間に差が出た場合、どちらを正として扱っていますか。

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章)の中で当社が主導して埋める種類の作業で、御社の業務を止めるものはありません。埋める作業の中身と順序は、業務の実物を拝見しないと確定できないため、診断セッションの議題とします。

この規模の運送業では、点呼記録と運転日報の様式が法令に沿って整っていることが、進めやすさにつながります。記入する項目が決まっているため、紙のまま届く情報でも、読み取ってデータにする際の受け皿を作りやすいのです。デジタコに運行の実データが日々蓄積されていることも同様で、事務所側から取り出せる形にできれば、請求と給与の裏取りの材料になります。整備の中心は、電話とFAXと紙の日報という入口のデータ化と、配車と給与の判断知識の辞書化の2つに絞られます。

7. To-Be: 受注・配車ワークフロー(AI社員配属後)

配属後の姿は、御社固有の情報(荷主と納品条件の対応、車両・ドライバーと資格・車格の対応、傭車先と取り決め単価、請求単価の体系、歩合の例外)を整理したうえに成り立ちます。この章の直前に差し込んだ立体の地図は、その整理の成果物の姿です。下段が情報の置き場所(接続に導入時の確認が要るものは接続候補と表示)、中段が御社の業務で共通に扱う実体とその関係、上段がAI社員に任せる仕事です。上段の仕事を選ぶとその仕事が使う実体・元データ・読み替えが光り、実体を選ぶと判断材料がどこから来てどの仕事につながるかをたどれます。実体をつなぐ線は、システムに記録済みのつながり、導入で整理して作るつながり、合っているかを照合するつながりの3種に分かれます。

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

7-1. 配属案

7-2. 配車担当AIの職務定義

7-3. 配属後の受注・配車フロー

flowchart TD
  chakusin["注文の着信<br>(FAX・メール)"] --> ai["配車担当AIが読み取り"]
  denwa["電話注文"] --> memo["人が受付メモの様式で受ける"]
  memo --> ai
  ai --> kaiketsu["荷主条件の解決<br>(納品時間・積み下ろし・車格)"]
  kaiketsu -->|"辞書で解決"| kihyo["基幹システムへ受注を起票"]
  kihyo --> an["割り付け案の作成<br>(車格・資格・稼働状況を照合)"]
  an -->|"自社車両で組める"| kakutei["配車課が確定・指示配信"]
  an -->|"車両が不足"| yousha["傭車候補を台帳から順位づけ<br>依頼文の下書きを提示"]
  yousha --> handan2["配車課が依頼先を決定・交渉"]
  handan2 --> kakutei
  kakutei --> henko["当日の追加便・欠勤・遅延"]
  henko --> kiroku["AIが配車記録を更新し変更履歴を残す"]
  kiroku --> renraku["荷主への連絡文の下書きを提示"]
  kaiketsu -->|"解決できない<br>(未登録の荷主条件・記載不備・新規荷主)"| hokoku["例外としてLINE WORKSで報告<br>(論点を整理して提示)"]
  hokoku --> handan["配車課・営業が判断"]
  handan --> tsuiki["判断結果を業務マニュアルと辞書に追記<br>(版管理)"]
  tsuiki -.->|"以後、同型の依頼はAIが処理"| ai

読み取りに自信が持てない注文は、誤って起票せず例外として人に回します。読み取りの精度を約束する方式ではなく、確信の持てないものを人に回す設計で誤入力を防ぎます。配車の確定判断は人に残します。AIが担うのは、条件と可否の照合という手間のかかる部分と、割り付け案の下書き、そして変更が記録として残ることです。電話注文は当面人が受け、書き取りから起票までをAIへの依頼に置き換えるところから始めます。

7-4. 配属後の1日

例外の比率は導入初期が最も高く、判断のたびにマニュアルと辞書へ追記されるため、運用とともに下がる構造です。配車ベテランの方の頭の中にある条件は、この追記の積み重ねで辞書に移っていきます。

8. To-Be: 日報・請求・給与ワークフロー(AI社員配属後)

8-1. 日報担当AIの職務定義

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

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

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

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

flowchart TD
  kikan["自社開発の基幹システム"] --> madoguchi
  yayoi["弥生会計"] --> madoguchi
  jobcan["ジョブカン勤怠"] --> madoguchi
  digitaco["デジタコ<br>(書き出しファイル)"] --> madoguchi
  fs["ファイルサーバ・NAS"] --> madoguchi
  faxin["FAX受信 / メール"] --> madoguchi
  scan["日報のスキャン"] --> madoguchi
  madoguchi["各システムとAIの間の窓口(システムごとに設置)<br>・アクセスできる範囲の制御(権限)<br>・全操作の記録(監査ログ)<br>・意味辞書(荷主条件、車格と資格の可否、傭車先台帳、請求単価、歩合の例外)"]
  madoguchi --> haishaAI["配車担当AI"]
  madoguchi --> nippoAI["日報担当AI"]
  haishaAI -->|"報告・例外照会・指示配信"| lw["LINE WORKS"]
  nippoAI -->|"報告・例外照会"| lw
  lw <-->|"判断・承認"| hito["配車課・運行管理・経理"]
  lw <-->|"指示・報告"| driver["ドライバー"]

• 既存システムの入れ替えは行いません。基幹システム・弥生会計・ジョブカン勤怠・デジタコ・NASは現行のまま、AI専用の窓口を追加します。
• 配車の実績と当日変更の履歴は、これまでホワイトボードで消えていた情報です。窓口の側に記録の置き場所を用意し、AIが更新します。
• AIがシステムに触れる経路は窓口だけに限定され、窓口を通らないアクセスはできません。

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

10. 導入ステップ

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

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

1. 業務マニュアル。例外対応の追記を含む、版管理された手順書。配車の組み方と給与計算の考え方が、初めて書いたものになります
2. 意味辞書。荷主条件・車格と資格の可否・傭車先台帳・歩合の例外といった、データの読み方の登録集
3. 監査ログ。AIがいつ何を参照しどの操作をしたかの全記録

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

他の手段との比較

導入後も続く運用

業務は変わり続けます。新しい荷主、車両とドライバーの入れ替え、傭車先の変化、単価改定、法令の改正。月額利用の中では、例外判断のマニュアル・辞書への反映、接続先の変化への追従、任せる業務の拡張が続きます。AI社員の仕事の範囲は、配属時の定義から運用の中で広がっていきます。

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

11. セキュリティ設計

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

• システム操作の実行は、依頼した本人・その場に同席する全員・AI社員自身の3者すべてに権限がある場合に限られ、未登録の操作・身元不明の参加者は拒否が既定値です。
• 配車の確定・請求発行・給与額の確定などの重要操作には人の承認が必ず挟まり、許可・拒否を問わずすべての実行が監査ログに残ります。
• 運行記録や点呼記録は法定の保存義務がある帳票です。AIが読み取ったデータと原本の対応が追える形で保管します。
• 提供環境は1社ごとに独立し、他社とデータベースを共有しません。

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

12. 提供体制

導入から運用まで、技術担当と導入支援担当が付きます。問い合わせは担当窓口に一本化します。営業所が3か所に分かれている点は、配属の順序と承認の経路の設計に反映します。

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

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

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

1. 2章の一覧を御社の実際に合わせて確定した、人手が支えている箇所の一覧表
2. お使いのシステムの版と作りに応じた、接続方式と可否の回答(自社開発の基幹システムとデジタコの出力形式を含む)
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. 検証項目と指標

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