走り書きの業務メモから、業務の流れ図をAIで作れるか試してみた

システムを作る前には、今の業務の流れを図にしておくと、開発会社との話が早く進みます。誰が、何を受け取って、何をして、次に誰へ渡すのか。どこで転記や待ちが起きているのか。図があれば、どこをシステムに任せるかを同じ絵を見ながら決められます。

ただ、図を描くのは手間がかかります。現場の担当者に聞けば、手元のメモやノートに流れが書いてあることはよくあります。けれども、それは箇条書きの走り書きで、順番が前後していたり、主語がなかったりします。

その走り書きを生成AIに渡せば、業務の流れ図の下書きを作ってくれるのではないか。そう考えて、実際に試してみました。

結論から書くと、メモに書いた作業と分かれ道は、9回ともすべて図に入りました。図を描くための書き方（Mermaid）も、9回ともエラーなく絵にできました。足りなかったのは次の3つです。

• ふつうに頼むと、図から「誰が」が抜ける
• 担当ごとに分けるよう頼むと、メモに主語がない作業の担当を、9回のうち3回、確認の印なしで決めてしまう
• 担当ごとに分けた図は、線が担当の枠をまたいで絡み、そのままでは読みにくい

結論：AIは「中身の下書き」と「聞くことの洗い出し」に使い、図は人が描き直す

試した結果からいうと、走り書きのメモから業務の流れの中身を起こすところまでは、AIに任せられます。作業の抜けは今回の条件では出ませんでした。さらに、メモに書いていないこと（課長がいないとき、急ぎの依頼の記録など）を「確認したいこと」として挙げさせると、現場に聞き直す質問の一覧になります。

一方で、AIが作った図をそのまま開発会社に渡すのはおすすめしません。主語のない作業が、もっともらしい担当に置かれていることがあるからです。図の見た目も、担当ごとの帯がきれいに並ぶ形にはなりませんでした。使うときは、次の3か所を人が直します。

1. 担当の置き場所：メモに主語がなかった作業を、どの担当に置いたかを確かめる
2. 「確認したいこと」：AIが挙げた質問を、現場の人に聞いて図に反映する
3. 図の見た目：中身が固まったら、付箋やホワイトボード、作図の道具で描き直す

業務の流れの図そのものの書き方は、業務の流れを図にする：システム化の前に整理することにまとめています。今回の採点も、その記事の「7つの手順」と「書き終えたら確かめる10項目」を物差しにしました。

試したこと

架空の修理会社の、走り書きのメモ

本物のお客さまのメモは使っていません。お客さまの業務をAIに入れることになるうえ、記事に載せられないからです。代わりに、架空の会社のメモを用意しました。

設定は、業務用の機械の修理をしている会社です。お客さまから修理の依頼を受けてから、作業員が訪問して直し、月末に請求するまでの流れを、受付・事務の担当者が自分用に書き留めた、という想定です。メモの全文は次のとおりです。

修理依頼〜請求の流れ（受付・事務のメモ）

・お客様から電話 or メールで依頼 → 受付表(Excel)に入れる。月120件くらい、1件10分
・割当は課長。ホワイトボード見て決めてる（課長しか分からない）
・訪問日決まったらお客様に電話。出ないとかけ直し、多い日で20件
・現地で点検 → その場でOKなら修理して終わり
・部品いる時は事務所に連絡 → メーカーに発注 → 入荷したら訪問日を取り直し
・部品代5万超えるなら先に見積。見積は課長が作る。OK出たら手配
・NGなら出張費だけ請求
・作業報告書（紙）にお客様のサイン。週1でまとめて持ってくる人も
・報告書見て受付表を完了に → 月末に経理が請求書（受付表から会計ソフトに打ち直し）
・急ぎ（機械止まってる等）は課長に直で電話 → 当日行ける人を探す
・型番わからない部品は山本さんに聞く
・課長いない時は？

このメモには、走り書きにありがちなことをわざと入れています。

• 主語がない：「お客様に電話」「メーカーに発注」は、誰がするのか書いていません。
• 書いていない登場人物がいる：現地に行く人は、メモのどこにも「作業員」とは書かれていません。「割当」「現地で点検」「持ってくる人」から読み取るしかありません。
• 順番が前後している：「5万超えるなら先に見積」は、部品の発注の行より後ろに書いてあります。
• 答えのない問い：最後の「課長いない時は？」は、メモを書いた人自身が分かっていないことです。

もう1つ、同じ中身で、行の順番を入れ替え、「客」「直電」「週イチ」のような略語や、「治れば」のような書き間違いを混ぜた、さらに崩したメモも用意しました。

図に入るべきものを、先に決めて固定した

AIに作らせる前に、図に入るべきものと、誤りとして数えるものを決めて固定しました。結果を見てから基準を変えると、採点が甘くなるからです。

あわせて、メモに書いていないことを7つ決めました。課長がいないときの対応、部品を発注するのは誰か、見積を誰がお客様に出して返事を受けるか、急ぎの依頼も受付表に入れるか、月末までに報告書が戻らない分の請求、5万円以下なら見積なしで発注してよいか、請求書の送り方と入金の確認、の7つです。図に入れずに「確認したいこと」として挙げたら○とします。

誤りとして数えるのは、次の3つです。

• 付け足し：メモにない作業や判断を、確認の印なしで図に入れる
• 主語なしを断定：メモに主語がない作業を、ある担当に置いたうえで、確認にも挙げない
• 開いた問いを黙って決める：「課長いない時は？」に、メモにない答えを入れる

頼み方とメモを変えて、9回作らせた

使ったのは、Anthropic社の生成AI「Claude」（Opus 5.5）です。2026年11月2日に試しました。AIには過去のやり取りやほかの資料を一切読ませず、頼み方の文章とメモだけを渡しています。同じ条件でも答えが毎回変わるので、1つの条件で3回ずつ作らせました。

ふつうの頼み方は、「次の業務メモから、業務の流れ図を Mermaid で作ってください。」の1文だけです。Mermaid は、文字で書いた決まった形の文章から図を描く仕組みで、担当ごとの枠（subgraph）も書けます（Mermaid の流れ図の書き方）。書き方の決まりは、業務の流れを図にする記事の記号と手順を8行にしたものです。文章は記事の後半に載せています。

1回にかかった時間は46〜92秒でした。

結果①：作業と分かれ道は、9回とも全部入った

メモに書いた12の作業と3つの分かれ道は、9回とも図に入りました。例外の流れも、①の1回で「かけ直し」が戻りの線ではなく作業の横の注記になっていたほかは、すべて線で描かれています。

順番が前後していた「5万超えるなら先に見積」も、9回とも「部品が要ると分かったあと、発注の前」に置き直されていました。崩したメモの「治れば」も、正しく「直れば」と読まれています。月120件・1件10分、多い日20件、5万円といった数字も、決まりを渡した②と③では6回とも作業の横に書き添えられました。

Mermaid の文章は、9回とも図を描く道具（mermaid-cli）でエラーなく絵になりました。手で直さずに図が出てくるのは、下書きとしては十分な速さです。

結果②：ふつうに頼むと、「誰が」が図から抜ける

違いが大きく出たのは、担当の扱いです。

ふつうの頼み方の①では、3回とも、担当ごとの枠のない、縦1列の図になりました。1回は作業の箱に「【課長】」「【受付・事務】」と注記を付けていましたが、もう2回は、「課長が見積作成」のように一部の作業の文中に出てくるだけです。流れの順番は追えますが、どこで人から人へ渡っているのかが見えません。

業務の流れを図にするいちばんの目的は、渡すところで起きる転記や待ちを見つけることです。「誰が」がない図では、その目的が果たせません。

決まりを渡した②と③では、6回とも担当ごとの枠が描かれました。お客様、受付・事務、課長、作業員、経理の5つに、山本さんとメーカーを足した7つです。メモに「作業員」と書いていない現地の担当も、6回とも枠になっていました。ただ、呼び名は「作業担当」「作業員（現場）」「訪問する担当者」「現場担当」とばらばらでした。メモにない名前なので当然ですが、図を社内で使うなら、呼び名は人がそろえる必要があります。

困りごとの印（★）も、②と③では6回とも、転記・待ち・確認の往復・属人の4種類すべてに付いていました。①でも、頼んでいないのに課長に集中する作業や手作業を色分けする回がありました。

結果③：主語のない作業を、3回は黙って決めた

メモには「メーカーに発注」とだけあり、誰が発注するかは書いていません。担当ごとに枠を分ける以上、AIはこの作業をどこかの枠に置くしかありません。問題は、置いたあとに「ここは仮に置いた」と伝えるかどうかです。

部品の発注を誰がするかは、9回のうち5回が「図では受付・事務に置いています」のように確認事項に挙げていました。一方で3回は、部品の発注を、確認に挙げないまま受付・事務の枠に置いていました（①の1回と③の2回）。そのうち1回は、同じく主語のない「訪問日の電話」も、確認に挙げずに受付・事務に置いています。残りの1回は、担当の枠のない図で、発注の担当を書いていませんでした。

図だけを見ると、どちらも同じに見えます。けれども、確認の印のない図を開発会社に渡すと、「部品の発注は受付・事務がしている」という前提で話が進みます。実際には課長が発注していた、ということが後から分かれば、権限の設計や画面の作り直しにつながります。

このほか、次のような点もありました。

• 小さな付け足し：②の2回で、お客様の枠に「請求書を受け取る」「見積の内容を確かめる」が足されていました。②の1回は、受付・事務の枠に「部品の入荷を待って受け取る」も足しています。メモにはありませんが、流れを変えるものではありません。
• 決まりを守らなかった1回：③の1回は、「課長は在席しているか？」という分かれ道と「対応が決まっていない」という箱を図の中に入れていました。決まりでは、メモにないことは図に入れず確認事項にするよう頼んでいます。ただ、この回も確認事項には挙げており、答えを勝手に決めたわけではありません。
• 開いた問いを黙って決めた回は、0回：「課長いない時は？」に、メモにない答え（「部長が代わりに」など）を入れた回はありませんでした。

結果④：「確認したいこと」は、決まりを渡すと増えた

メモに書いていない7つのことを、確認事項として挙げた数は次のとおりです。

確認事項の数そのものも、①は1回5〜6個、②と③は14〜21個でした。

「課長いない時は？」と、急ぎの依頼の扱いは9回とも挙げています。急ぎの依頼については、9回とも受付表を通らない線で描いたうえで、「受付表に入れるかどうか分からない」と書いていました。図をそう描いた理由を自分で説明できている、ということです。

いちばん挙がらなかったのは、「月末までに報告書が戻らない分」です。報告書が週1でまとめて戻ること自体には、6回とも★（待ち）を付けていました。けれども、その待ちが月末の請求にどう響くかまで踏み込んだのは1回だけでした。困りごとに印を付けることと、その困りごとが次の工程で何を起こすかを考えることは、別の作業だということです。ここは人が図を見て考える所として残ります。

反対に、こちらが用意した7つにはない、妥当な指摘もありました。

• 訪問日は誰が決めているか（②③の5回）：メモは「訪問日決まったら」としか書いていません。正解表を作ったときに、こちらが見落としていた点です。
• 当日行ける人が見つからないとき（4回）
• 電話に何度も出ないときの上限や、ほかの連絡手段（6回）
• 取り消しや、報告書の差し戻し（取り消し5回、差し戻し4回）
• 山本さんが不在のとき（4回）

業務の流れの記事でも書いたとおり、システムを作るときに費用と手間が大きく変わるのは、たいてい例外の扱いです。メモに書かれていない例外の候補を、現場に聞く前に並べてくれる点は、AIを使う大きな利点だと感じました。

もう1つ、メモの「その場でOKなら修理して終わり」という書き方について、9回とも、「終わり」で止めずに報告書と請求の流れにつなげていました。そのうち5回は、「その場で直ったときも報告書と請求は同じ流れでよいか」を確認事項に挙げています。①の3回は、黙ってつなげていました。

結果⑤：担当ごとの図は、線が絡んで読みにくい

中身とは別に、図の見た目にも課題がありました。

①の図は、縦1列の長い図になります。担当は見えませんが、上から下へ順に読めます。

②と③の図には担当ごとの枠がありますが、枠は横に並んだ帯になりません。担当ごとの箱がばらばらの位置に置かれ、矢印が何本も枠をまたいで交差します。大きく描き直しても、どの矢印がどこへ向かっているかを目で追うのは大変でした。今回の6回の図では、担当ごとの枠は、業務の流れ図でよく見る横並びの帯にはなりませんでした。

つまり、AIが作るのは図の中身の下書きで、そのまま会議で見せる図ではありません。中身が固まったら、付箋やホワイトボード、作図の道具で、担当ごとの帯を並べて描き直すのがおすすめです。業務の流れの記事の7つの手順でいえば、AIが助けてくれるのは「2. 作業を書く」「3. 並べてつなぐ」「4. 分かれ道と例外を書く」「5. 困りごとの印を付ける」の下書きまでです。「1. レーンを引く」の見た目と、「7. 実際の1件でなぞって、現場の人に確かめてもらう」は、人の仕事として残ります。

崩したメモでも、結果はほとんど変わらなかった

③の崩したメモは、行の順番を入れ替え、略語と書き間違いを混ぜたものです。それでも、作業・分かれ道・例外は3回ともすべて図に入り、困りごとの印も4種類そろいました。行の順番がばらばらでも、「依頼 → 受付表 → 割当 → 訪問日の電話 → 点検」という順に並べ直されています。

差が出たのは、主語のない作業の扱いです。主語なしを断定した3回のうち2回が③でした。崩したメモほど、AIが補う部分が増えます。補った部分を確認事項に書いたかどうかを見るのが、いっそう大事になります。

使うときに、人が直す3か所

試した結果をもとに、AIが作った業務の流れ図を使うときの手順をまとめます。

1. 担当の置き場所を、メモと見比べる

図の作業を1つずつ見て、メモに主語が書いてあったかを確かめます。主語がなかった作業は、AIが置いた担当に印を付けて、現場の人に聞きます。決まりの中で「主語がない作業は、置いた担当に『仮』と書く」と頼んでおくのも一つの手です。ただし、この1行で黙った断定がなくなるかは、今回は試していません。

2. 「確認したいこと」を、現場に聞く質問にする

AIが挙げる確認事項は、決まりを渡した②と③では1回で14〜21個ありました（①は5〜6個）。全部を一度に聞くと、現場の負担が大きくなります。作る範囲や費用を左右するもの（課長がいないとき、急ぎの扱い、見積の受け渡し）を先にして、件数や日数のような数字は、あとで書いてもらう依頼にまわします。

3. 図は、人が描き直す

中身が固まったら、担当ごとの帯を横に並べて描き直します。このとき、呼び名をそろえ（「作業員」か「現場担当」か）、AIが足した小さな作業（「請求書を受け取る」など）が要るかを決めます。描き直した図を、ふだんその業務をしている人に見てもらい、実際の1件でなぞってもらえば完成です。

自社で試す手順

自社のメモで試すときは、次の順で進めます。

1. メモを集める：担当者の手元の箇条書きや、引き継ぎのメモで構いません。きれいに書き直す必要はありません。
2. 名前を役割に置き換える：人の名前や取引先の名前を、「担当A」「取引先」のように置き換えます。今回のメモの「山本さん」も、本物のメモなら置き換える所です。
3. 書き方の決まりを付けて頼む：下の文章に、メモを続けて貼ります。
4. 担当の置き場所を確かめる：上の「人が直す3か所」の1です。
5. 確認事項を絞って、現場に聞く：同じく2です。
6. 人が描き直して、現場で確かめる：同じく3です。

今回使った、書き方の決まりを渡す頼み方は次のとおりです。

次の業務メモから、業務の流れ図を Mermaid で作ってください。次の決まりで書いてください。
1. 担当ごとにレーン（subgraph）を分ける。お客様や取引先もレーンにする
2. 記号は5つだけ：始まりと終わりは角の丸い四角、作業は四角、分かれ道はひし形、矢印、困りごとは★の印
3. 作業は「何を、どうする」の形で書く
4. 分かれ道は、はい・いいえで答えられる問いにする
5. 差し戻し・急ぎ・取り消しなど、いつもと違う流れも書く
6. 困りごと（転記・待ち・確認の往復・特定の人しか分からないこと）に★を付ける
7. メモに書いてある件数・時間・金額は、作業の横に書き添える
8. メモに書いていないことは図に足さず、図のあとに「確認したいこと」として箇条書きにする

Mermaid の文章は、そのままでは図になりません。Mermaid に対応したメモアプリや、Mermaid の公式サイトで案内されている編集画面に貼ると、図として表示できます。

本物の業務メモには、取引先の名前や金額が書いてあることがあります。生成AIに入れる前に確かめることは、打ち合わせの文字起こしを試した記事の「録音や文字起こしをAIに入れる前に確かめること」にまとめています。業務メモでも考え方は同じです。

この試しの限界

今回の結果は、次の条件のもとでのものです。

• メモは架空で、短い：12行のメモで、作業も12個です。実際の業務は、1つの流れに数十の作業があることも珍しくありません。長くなると、抜けや誤りが出る可能性があります。
• 作った側が、答えを知っている：メモも正解表も、同じ側が作っています。作業の名前や順番がメモから読み取りやすくなっている可能性があります。実際、正解表を作ったこちらも「訪問日は誰が決めるか」を見落としていました。
• AIは1つ、回数は少ない：使ったのは1つのAIで、条件ごとに3回です。別のAIや、別の時期のモデルでは結果が変わる可能性があります。
• 図の読みやすさは、Mermaid での結果：担当ごとの図が読みにくかったのは、Mermaid の描き方によるところが大きいです。ほかの作図の道具や書き方を頼めば、見た目は変わる可能性があります。
• 紙の手書きは試していない：今回は、打ち込んだメモを渡しています。紙に手で書いたメモを写真で読ませる場合は、文字の読み取りの段階で誤りが出る可能性があり、今回の結果には含まれていません。

おわりに

走り書きの業務メモをAIに渡すと、今回の条件では、作業・分かれ道・例外が9回とも図に入りました。メモに書いていない例外の候補を並べてくれる点も、現場に聞き直す準備として役に立ちます。業務の流れを図にする最初の一歩、白紙から書き始める手間は、かなり減らせると感じました。

ただ、AIが作るのは中身の下書きです。主語のない作業の担当を黙って決めることがあり、担当ごとの図はそのままでは読みにくいままでした。担当の置き場所を確かめ、確認事項を現場に聞き、図は人が描き直す。この3つを人が受け持てば、業務の流れの図は、短い時間で、現場の実態に近いものになります。

図ができたあとは、その図をもとに、どこをシステムに任せるかを決めていきます。進め方は、要件定義とは：開発会社に頼む前に、社内でまとめておくことにまとめています。