Claudeで業務フロー図を作成 — ヒアリングメモから抜けを洗う手順

ヒアリングメモを図にすると、聞き漏らしが見える

業務改善の最初の作業は、現状の業務フロー(As-Is)を把握することです。担当者へのヒアリングメモは、話した順に書かれるので、箇条書きのままでは「誰が承認するのか」「却下されたらどこへ戻るのか」といった抜けに気づきにくくなります。

Claudeにメモを渡して図にすると、抜けは「矢印の行き先がない箇所」として見えるようになります。図を描くこと自体が目的ではありません。図にしてはじめて浮かぶ抜けを、次のヒアリングで聞く質問リストに変えるのが、この手順のゴールです。

流れは3段階です。

前提と、貼る前に決めておくこと

Artifactsを使うには、Free・Pro・Maxでは「設定 > 機能(Capabilities)」、Team・Enterpriseでは組織設定の同じ項目で、コード実行とファイル作成をオンにしておく必要があります。Artifactsのヘルプでは、図やフローチャートもArtifactsにできる内容として挙がっています。

Claudeがメモの内容をArtifactsにするかどうかは、15行を超える分量があり、単体で完結していて、あとから編集・参照したくなる内容かで決まります。業務フロー図は、この条件を満たしやすい題材です。

ヒアリングメモには、個人名や取引先名が入りがちです。貼る前に「担当者A」「取引先X」のような仮名に置き換えておく方法があります。図に必要なのは、誰かの名前ではなく役割です。

手順1: メモを貼って、確認済みと未確認を分けた図を依頼する

メモは整形し直さなくて構いません。話した順の箇条書きのまま貼れます。ただし依頼文に、メモに書かれていないことは補わず、「未確認」として図に残すという指示を入れてください。この一文がないと、Claudeが筋の通った流れに仕上げようとして、本来は抜けている箇所を自然に埋めてしまうことがあります。

次のメモは、手順の説明用に作った架空の例です。

備品購入の申請について総務担当Aさんに聞いた内容
- 申請者がフォームで購入申請を出す
- 上長が内容を見て、問題なければ次へ回す
- 金額が5万円以上のときは部長の承認も要る
- 承認が済んだら総務が発注する
- 届いたら申請者が検収して、請求書を経理に回す

このメモを使った依頼文の例です。

添付のヒアリングメモから、備品購入申請の現状の業務フロー図を
Artifactsで作ってください。
 
条件:
- 判断(分岐)は菱形で、始点と終点は丸みのある形で描く
- メモに書かれていない担当者・条件・遷移は補わず、
  黄色い枠の「未確認」ノードとして図に残す
- 担当部署ごとに枠で囲む
- 図とは別に、未確認ノードの一覧を番号付きで出す

「条件」の最初の2行は、Mermaid記法を知らなくても図の形を指定するためのものです。向きや配色を具体的に指定するほど手戻りが減る点は、Claudeでのフローチャート作成手順でも触れています。

手順2: 抜けを5つの観点で点検する

図ができたら、次の5つの観点で矢印の行き先がない箇所を探します。観点は業務の種類を問わず使えます。

先ほどのメモを図にすると、次のような形になります。Mermaid記法の例として、抜けに当たる部分を点線の矢印と「未確認」ノードで示しています。

flowchart TD
    S(["申請者が購入申請を出す"]) --> A["上長が内容を確認"]
    A --> B{"金額は5万円以上か"}
    B -->|はい| C["部長が承認"]
    B -->|いいえ| D["総務が発注"]
    C --> D
    D --> E["申請者が検収"]
    E --> F(["経理に請求書を回す"])
    A -.->|"問題があるとき?"| G["差戻し先は未確認"]:::gap
    C -.->|"部長が不在のとき?"| H["代理承認者は未確認"]:::gap
    classDef gap fill:#fff3cd,stroke:#c77700

点線の矢印は、メモに根拠のない遷移です。この例では、上長が「問題あり」と判断したときの行き先と、部長が不在のときの代理が、メモのどこにも出てきません。もう1つ、金額がちょうど5万円のときの扱いはメモの「5万円以上」から読み取れますが、「以上」と「超える」を聞き違えている可能性は残るため、確認事項の候補になります。

Mermaidの点線矢印は-.->、ノードへのクラス指定は:::、色の定義はclassDefで書きます。判断ノードを菱形にする{}と、始点・終点を丸みのある形にする([ ])は、Mermaidのフローチャートの基本構文です。

手順3: 抜けを質問リストにする

点検で見つけた抜けは、図の中に置いたままでは次のヒアリングに持ち込めません。質問の形に直します。次の依頼文は、そのためのものです。

図の未確認ノードと、点検した5つの観点で見つかった抜けを、
次回のヒアリングで聞く質問リストにしてください。
 
形式:
- 誰に聞くか(役割で。名前は書かない)
- 質問文(はい・いいえで終わらない聞き方にする)
- 答えによって図のどこが変わるか
- 優先度(図の主要ルートに影響するものを上にする)

「答えによって図のどこが変わるか」を書かせるのが要点です。質問と図の接続がわかると、ヒアリングの相手に「この答えで、この矢印が決まります」と説明でき、答えも具体的になりやすくなります。

質問リストの1行は、次のような形になります。以下は、上の例の抜けから起こした、形式を示すための例です。

点検がうまくいかないとき

最初の図が思いどおりにならないことは普通にあります。よくある原因と、その直し方です。

メモに書いていないことを補われる。依頼文に「補わない」と書いても、細かい接続は補われることがあります。図ができたら、メモの各行と図のノードを照らし合わせ、メモに根拠のないノードに印を付けさせます。「各ノードについて、元になったメモの行を一覧にして」と頼むと、根拠のない箇所が見つかります。

図がエラーになる。Artifacts内でエラーが出たときは、エラーメッセージの近くにある「Try fixing with Claude」を押します。エラー内容が新しいメッセージにコピーされるので、そのままClaudeに送って直させます。ヘルプには、直る保証はなく、追加の切り分けが必要な場合もあると書かれています。

Mermaidが描画されない。Artifactsのヘルプには、Mermaid記法の描画に対応するという記載がありません。描画されない場合は、依頼文で「Mermaid記法ではなく、Artifacts上の図として描いて」と指定するか、Mermaidのコードをチャットのコードブロックで受け取り、Mermaid対応のエディタで表示する方法があります。コードをテキストとして残しておくと、修正の履歴をGitやWikiで追いやすくなります。

Mermaidのコードが壊れる。Mermaidのフローチャートのドキュメントには、ノード内で小文字のendを使うと図が壊れるという警告があります。EndやENDのように一部を大文字にします。接続先ノードの先頭がoまたはxのときも、矢印の記号と読み違えられます。前にスペースを入れるか、大文字にするよう案内されています。「Order確認」「xxx承認」のような英字始まりの工程名では、ここで引っかかります。日本語のノード名は、ドキュメントのUnicodeテキストの案内に合わせて、引用符で囲んでおくと安全です。

担当別に枠で囲むと、担当不明の作業が目立つ

手順1の依頼文で「担当部署ごとに枠で囲む」と指定したのは、担当が決まっていない作業を見つけるためです。Mermaidのフローチャートでは、subgraphで枠を作れます。どの枠にも入らないノードは、担当が聞けていない作業の候補として、そのまま点検の対象になります。

枠を使う場合、サブグラフ内のノードが外部のノードと矢印でつながっていると、サブグラフ内の向きの指定(direction)は無視され、外側の向きが使われます。部署をまたぐ業務フローでは、ほとんどのノードが外部とつながるので、枠ごとに向きを変える使い方は想定しない方が確実です。

図を次のヒアリングに持ち込む

質問リストと図は、ヒアリングの場に一緒に持ち込みます。9月16日以降にチャットで作ったArtifactsは、サイドバーの「Artifacts」タブに保存され、最初は自分だけが見られる状態です。他の人に見せる場合は共有の範囲を選ぶことになります。組織の管理者が外部への共有を制御している場合は、Claude Artifactsの管理者が組織外共有を制御する設定手順で、どこまで共有できるかを確かめてください。

ヒアリングの回答が出たら、同じチャットで続けます。回答メモを貼り、「回答に基づいて未確認ノードを確定し、図を更新して。まだ確認が取れていない箇所は未確認のまま残して」と頼みます。何回かのヒアリングにわたる案件は、元のメモ・図の方針・過去の回答をProjectの知識に保存しておくと、会話をまたいで同じ前提で作業できます。使い方はClaude Projects完全ガイドにまとめています。

打ち合わせの録音や文字起こしからヒアリングメモを起こす段階は、Claude議事録の実践プロンプトが参考になります。

図の種類で目的が変わる

同じ「図にする」でも、作る図によって目的が違います。業務フロー図は、現状の手順と判断の分岐をたどる図です。顧客がどう動くかを時系列で追う図は、カスタマージャーニーマップの領分です。件数や割合を帯の太さで見せる図が必要なら、フローチャート作成手順の記事にあるSankey形式が向いています。

業務フロー図で見るのは「手順がつながっているか」です。件数や所要時間を載せたくなったら、メモにその数字があるかを先に確認してください。数字がないまま図に載せると、根拠のない値が図の説得力だけを強めることになります。

作った図は仮説として扱う

ここで作る図は、ヒアリングメモから起こした仮説です。実際の業務が図どおりに動いているかは、現場の担当者に見せて確かめるまで分かりません。未確認のノードが残っている図は、不完全なのではなく、まだ聞いていないことが見える状態の図です。

抜けを質問に変える作業は、ヒアリングの回数が増えるほど効きます。1回目のヒアリング直後に図にして質問を整えると、2回目で聞く内容が具体的になり、同じ相手に何度も時間をもらう負担を減らせます。