株式会社城南鉄工様 業務フロー分析・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
  fax["FAX複合機"] -->|"紙"| eigyo["営業部・生産管理課"]
  denwa["電話"] -->|"口頭"| eigyo
  taimen["対面・持ち込みの紙図面"] -->|"紙"| eigyo
  mail["Outlook<br>(引き合い・図面添付・仕様連絡)"] --> eigyo
  edi["EDI(大手1社)"] --> eigyo
  eigyo -->|"手入力"| excel["Excel 見積書・外注手配表<br>(担当者ごとの個人ファイル)"]
  eigyo -->|"手入力"| techs["TECHS-BK<br>(工程進捗)"]
  eigyo -->|"手入力"| kikan["自社開発の基幹システム<br>(旧オフコンから継承)"]
  excel -->|"売上・支払額を手で転記"| bugyo["勘定奉行"]
  kikan -->|"一部の実績を転記"| bugyo
  fs["ファイルサーバ・NAS<br>図面(AutoCAD)・検査記録・過去見積<br>(置き場所とファイル名は担当者ごと)"] -->|"記憶を頼りに探索"| eigyo
  memo["工場長・ベテランの記憶と個人の手控え<br>(単価の勘所、協力先の適性、検査の合否基準、金型の状態)"] -->|"口頭で参照"| eigyo
  genba["第一工場・第二工場の現場<br>(進捗は現物と口頭)"] -->|"聞き取り・週次会議"| eigyo
  teams["Teams<br>(社内連絡)"] --> eigyo
  jobcan["ジョブカン勤怠<br>今回の診断範囲外"]

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

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

一覧を眺めると、人手が支えているのは、個々のシステムの中ではなく、システムとシステムの間、またはシステムと記憶の間です。支え方の型は3つに集約されます。図面と注文が紙・口頭・添付のまま届き、人が読み取って入力していること、判断に使う知識(単価の勘所、協力先の適性、検査の合否基準、単位の換算)が記憶と個人の手控えにあること、システムと現場の間の照合(進捗・在庫・売上)を人がまとめて行っていることです。これは担当の方々の工夫で業務が成立している姿であり、同時に、その方々に負担が集中する構造でもあります。

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

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

3. As-Is: 見積・受注ワークフロー

多品種少量の受託加工のため、引き合いが常時複数並行し、そのうち一部が受注に進む姿と推定します。引き合いの入口はFAX・メール添付・持ち込みの紙図面・電話に分かれ、EDIは大手1社のみです。

3-1. 引き合いから見積提出まで

ヒアリングでは「前の担当の基準がちゃんと引き継がれてないんで、工場長が休むと出せないんですよ。お客さんから問い合わせが来ても答えられない」とのことでした。値決めの工程が1人に集まる構造が、そのまま回答速度に表れていると推定します。

3-2. 見積作成のフロー

flowchart TD
  hikiai["引き合いの受領<br>(FAX・メール添付・持ち込み図面・電話)"] --> zumen["図面の読み取り<br>(材質・寸法・公差・加工内容)"]
  zumen --> ruiji["類似図面・過去見積の探索<br>(ファイルサーバを記憶を頼りに探す)"]
  ruiji -->|"見つかった"| jisseki["過去実績の単価・工数を参照"]
  ruiji -->|"見つからない"| keiken["工場長の経験で見積もる"]
  jisseki --> tanka["工場長が単価を決定"]
  keiken --> tanka
  tanka --> gaichu["自社加工か外注かの振り分け<br>(協力先の手空きを記憶で判断)"]
  gaichu --> noki["負荷状況から納期を回答"]
  noki --> teishutsu["Excelで見積書を作成・提出"]
  zumen -->|"工場長が不在"| taiki["回答待ち<br>(提出が翌営業日以降へ)"]

3-3. 受注登録のフロー

flowchart TD
  chumon["注文の受領<br>(FAX・電話・メール・EDI)"] --> tsugo["見積・図面との突き合わせ<br>(図番・改訂・数量・単位)"]
  tsugo -->|"照合できた"| nyuryoku["Excel手配表・TECHS-BK・<br>基幹システムへそれぞれ入力"]
  nyuryoku --> tehai["材料手配・外注手配"]
  tehai --> zairyo["材料在庫の引当<br>(重量と本数の換算を手計算)"]
  tsugo -->|"図番の改訂が不明<br>数量・単位が読み取れない"| kakunin["工場長・営業担当に口頭確認"]
  kakunin --> nyuryoku

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

• 過去見積と実績工数は、図番と結び付いた形で残っていますか。担当者ごとのExcelに分かれていますか。
• 図面の改訂(A版・B版など)は、どこを見れば最新と判断できますか。
• 受注内容は、Excel手配表・TECHS-BK・基幹システムのうち、どれを正としていますか。
• 見積の提出までにかかる時間は、案件の種類によってどのくらい差がありますか。

4. As-Is: 手配・工程進捗ワークフロー

受注後は、材料手配と外注手配が並行し、進捗は現場の現物と口頭で把握されている姿と推定します。TECHS-BKは工程進捗の管理に使われており、手配と実績原価の面はExcelが担っている前提で描きます。

4-1. 受注から出荷までのタイムライン

4-2. 進捗把握と手配のデータフロー

flowchart LR
  genba["第一工場・第二工場の現場"] -->|"口頭・現物確認"| seisan["生産管理課"]
  kyoryoku["協力先"] -->|"電話・FAX"| seisan
  seisan -->|"聞き取り結果を手入力"| techs["TECHS-BK<br>(工程進捗)"]
  seisan -->|"手配の控え"| excel["個人のExcel 手配表"]
  techs --> kaigi["週次の進捗会議<br>(状況のすり合わせ)"]
  excel --> kaigi
  kaigi -->|"遅れ・前倒しの判断"| taio["納期調整・応援・外注の追加"]
  excel -->|"売上・支払額を手で転記"| bugyo["勘定奉行"]
  kensa["検査記録<br>(ファイルサーバ)"] -->|"客先要求時に抽出"| seisan

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

• TECHS-BKに入る進捗は、どの工程まで、どの頻度で入力されていますか。
• 協力先の手配実績(単価・納期・品質)は、どこに残っていますか。
• 材料の単位換算は、材質ごとの比重や定尺の一覧が文書としてありますか。
• 検査の目視項目は、限度見本や写真の形で基準が残っているものがありますか。

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

見積と手配、検査を成立させている知識の置き場所を整理します。

ISOの関係で手順書は整備されているものの、ヒアリングでは「見積の勘所とか外注先の選び方は書いてないです」とのことでした。文書になっている範囲と、記憶に残っている範囲の線が、そのまま属人性の輪郭になっています。

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

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が社内の連絡経路として定着していることは、この規模の受託加工業では恵まれた条件です。ヒアリングでは「データにはなってるんですけど、置いてある場所もファイル名もバラバラなんで、結局記憶を頼りに探し回ってます」とのことでした。データが存在することと、探し当てられることの差が、整備の中心になります。整備は、置き場所とファイル名を現場に直していただくのではなく、AI側に図番の台帳を作って現状の置き方をそのまま読めるようにする方向で進めます。

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

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

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

7-1. 配属案

7-2. 見積担当AI・受注担当AIの職務定義

7-3. 配属後の見積フロー

flowchart TD
  hikiai["引き合いの着信<br>(FAX・メール添付・EDI)"] --> ai["見積担当AIが図面と仕様を読み取り"]
  ai --> kensaku["図番台帳から類似図面・過去見積・実績工数を抽出"]
  kensaku --> shitagaki["見積の下書きを作成<br>(根拠となる過去案件を併記)"]
  shitagaki --> handan["工場長・営業が単価と納期を判断"]
  handan --> teishutsu["見積書を発行・提出"]
  handan --> tsuiki["判断の理由を意味辞書・業務マニュアルへ追記<br>(版管理)"]
  tsuiki -.->|"以後、同型の引き合いは根拠付きで提示される"| ai
  ai -->|"図面が読み取れない<br>類似案件が見つからない"| reigai["例外としてTeamsで報告<br>(不足している情報を整理して提示)"]
  reigai --> handan

読み取りに自信が持てない図面や、類似案件が見つからない引き合いは、推測で単価を出さず例外として人に回します。読み取りの精度を約束する方式ではなく、確信の持てないものを人に回す設計で誤った提出を防ぎます。単価の決定そのものは人に残し、AIは決定の材料をそろえる役に留めます。工場長が不在でも、過去実績と根拠が並んだ下書きは出ているため、代理の方が判断できる幅が広がります。

7-4. 配属後の受注登録

flowchart TD
  chakusin["注文の着信<br>(FAX・メール・EDI)"] --> ai["受注担当AIが読み取り"]
  ai --> tsugo["見積・図番・改訂・数量の突き合わせ"]
  tsugo -->|"一致"| kihyo["正のシステムへ起票し<br>他系統へ展開"]
  kihyo --> hikiate["材料在庫の引当照会<br>(単位換算は辞書で解決)"]
  tsugo -->|"単価が見積と不一致<br>改訂が最新でない<br>数量・単位が読み取れない"| hokoku["例外としてTeamsで報告"]
  hokoku --> hito["営業部・生産管理課が判断"]
  hito --> tsuiki["判断結果を業務マニュアルと意味辞書に追記"]
  tsuiki -.->|"以後、同型の注文はAIが処理"| ai

電話と持ち込みの紙図面は当面人が受け、入力と図面の取り込みだけをAIへの依頼に置き換えるところから始めます。

8. To-Be: 手配・工程進捗ワークフロー(AI社員配属後)

8-1. 生産管理担当AIの職務定義

8-2. 配属後の1週間・1か月

8-3. 変化の姿(推定)

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

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

flowchart TD
  fs["ファイルサーバ・NAS<br>(図面・検査記録・過去見積)"] --> madoguchi
  techs["TECHS-BK"] --> madoguchi
  kikan["自社開発の基幹システム"] --> madoguchi
  bugyo["勘定奉行"] --> madoguchi
  excel["Excel 見積・外注手配表"] --> madoguchi
  faxin["FAX受信 / Outlook / EDI"] --> madoguchi
  madoguchi["各システムとAIの間の窓口(システムごとに設置)<br>・アクセスできる範囲の制御(権限)<br>・全操作の記録(監査ログ)<br>・意味辞書(図番と改訂、類似の手がかり、単価の勘所、協力先の適性、材料の単位換算、正となる数字の定義)"]
  madoguchi --> mitsumoriAI["見積担当AI"]
  madoguchi --> juchuAI["受注担当AI"]
  madoguchi --> seisanAI["生産管理担当AI"]
  mitsumoriAI -->|"報告・例外照会"| teams["Teams"]
  juchuAI -->|"報告・例外照会"| teams
  seisanAI -->|"報告・例外照会"| teams
  teams <-->|"判断・承認"| hito["営業部・生産管理課・品質保証課・管理部"]

• 既存システムの入れ替えは行いません。TECHS-BK・自社開発の基幹システム・勘定奉行・ファイルサーバは現行のまま、AI専用の窓口を追加します。
• 図面の置き場所とファイル名の付け方も現行のままとし、図番台帳の側で対応を持ちます。
• AIがシステムに触れる経路は窓口だけに限定され、窓口を通らないアクセスはできません。

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

10. 導入ステップ

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

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

1. 業務マニュアル。例外対応の追記を含む、版管理された手順書
2. 意味辞書。図番と改訂の台帳、単価の勘所、協力先の適性、材料の単位換算といったデータの読み方の登録集
3. 監査ログ。AIがいつ何を参照しどの操作をしたかの全記録

利用をやめた場合も、この3点は読める形式のファイルとして手元に残ります。ISOの手順書との関係では、業務マニュアルは既存の手順書に載っていない範囲(見積の勘所、外注先の選び方、目視項目の判断基準)を補う位置づけになります。

他の手段との比較

導入後も続く運用

業務は変わり続けます。新しい客先、協力先の入れ替え、図面の改訂の増加、使用システムの更新。月額利用の中では、例外判断のマニュアル・辞書への反映、接続先の変化への追従、任せる業務の拡張が続きます。AI社員の仕事の範囲は、配属時の定義から運用の中で広がっていきます。金型の記録や目視検査の扱いも、記録の持ち方が定まったところから順に範囲に入ります。

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

11. セキュリティ設計

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

• システム操作の実行は、依頼した本人・その場に同席する全員・AI社員自身の3者すべてに権限がある場合に限られ、未登録の操作・身元不明の参加者は拒否が既定値です。
• 見積の提出、外注の発注、検査の合否判定、仕訳の確定には人の承認が必ず挟まり、許可・拒否を問わずすべての実行が監査ログに残ります。
• 客先から預かった図面は、案件と権限の範囲を単位として参照範囲を区切ります。
• 提供環境は1社ごとに独立し、他社とデータベースを共有しません。

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

12. 提供体制

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

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

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

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

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

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