AIサービスブループリント作成ガイド2026：Figma AI・Napkin AI・Framerで顧客体験と業務を可視化

最終更新日：2026年7月31日 · カテゴリークラスター：AIデザインツール

顧客体験の問題は、画面だけを直しても解決しないことがあります。 申込フォームを短くしても、本人確認が別部署で止まる。問い合わせ画面を見やすくしても、担当者が契約情報を探せない。予約完了メールを改善しても、店舗には変更内容が届いていない。利用者からは一つのサービスに見えていても、社内では複数の人、システム、規程、委託先に分かれているからです。

そこで役立つのがサービスブループリントです。本稿は、日本企業のUX担当者、サービスデザイナー、プロダクトマネージャー、業務改善担当、カスタマーサポート、店舗運営、行政・公共サービスの担当者に向けて、AIでサービスブループリントを作る方法を実務の流れに落とし込みます。共同設計と正式な図の管理には Figma AI、文章から構造案を出す作業には Napkin AI、検証用ページや簡易プロトタイプには Framer、説明会・研修・共有資料には Canva AIを使い分けます。

findaiverse編集チームの立場は明確です。AIには発言の整理、レーン候補、図の初稿、抜け漏れ質問、共有版の展開を任せても、現行業務の事実と責任分担を推測させないこと。よくできた図に見えても、現場確認のない矢印は仮説です。サービスブループリントの価値は美しい図ではなく、利用者の行動と裏側の業務を同じ時間軸で確認し、どこを誰が変えるか決められる点にあります。

サービスブループリントで何を可視化するのか

サービスブループリントとは、利用者が体験する行動・接点と、それを支える従業員の対応、システム処理、ルール、資源を同じ流れで表す設計図です。一般的なカスタマージャーニーマップが利用者の行動、感情、課題を中心に見るのに対し、サービスブループリントは「その体験が社内でどう作られているか」まで降りていきます。

基本のレーンは五つから始めると扱いやすいです。第一は利用者の行動。第二は画面、電話、メール、店舗、書類など目に見える接点。第三は利用者と直接やり取りするフロント業務。第四は利用者から見えないバック業務。第五はシステム、規程、委託先、データ、設備などの支援基盤です。必要に応じて時間、感情、証拠、指標、リスクのレーンを加えます。

線にも意味があります。利用者と接点の間には相互作用があります。フロントとバックの間には可視性の境界があります。部署やシステムの間には受け渡しがあります。単に箱を横に並べるだけでは、どこで情報が欠け、誰が待ち、どの判断が手作業なのか分かりません。矢印に入力、出力、条件、担当、所要時間を添えると議論しやすくなります。

対象範囲は一つの利用目的に絞ります。「保険サービス全体」「自治体窓口全体」では広すぎます。「住所変更をオンラインで申請し、本人確認後に完了通知を受ける」「予約日時を変更し、店舗と決済に反映される」のように、開始と終了を明確にします。利用者の目的が一つなら、途中で複数部署にまたがっても図の軸を保てます。

現状図と理想図は分けてください。ワークショップでは「本来こうするべき」が現状に混ざりやすくなります。現状図には、実際の手作業、Excel、電話確認、待ち、二重入力、担当者の経験則も書きます。恥ずかしい工程を消すと改善対象も消えます。理想図は現状の証拠を確認した後で作ります。

AIは文章からレーン候補を作るのが得意です。しかし、「申請後に審査担当へ通知される」と書かれていても、通知がメールなのかキューなのか、誰が確認するのか、休日はどうなるのか、権限がない場合にどこへ戻るのかは分かりません。生成された矢印ごとに「根拠は何か」と質問する必要があります。

最初の候補ツールは findaiverseのAIデザインカテゴリで比較できます。ただし、ツールを開く前に対象サービス、利用者、開始、終了、現状・理想のどちらを描くかを一文で決めてください。

AIへ渡す前に事実資料をそろえる

よいサービスブループリントは会議室の想像だけでは作れません。利用者インタビュー、問い合わせ記録、アクセス解析、操作ログ、画面録画、店舗観察、業務マニュアル、担当者ヒアリング、処理時間、エラー記録、申請書、通知文、規程、システム構成、委託範囲を集めます。全部そろうまで待つ必要はありませんが、推測と証拠を区別できる状態にします。

資料には機密度を付けます。利用者名、連絡先、契約情報、健康・金融情報、社員評価、認証情報、未公開仕様を外部AIへそのまま入力してはいけません。発言は匿名化し、識別子を置き換え、必要な意味だけを残します。企業の承認済みアカウントとデータ利用条件も確認します。便利な要約機能があるから投入してよい、とは限りません。

インタビューの発言は「観察」「解釈」「要望」に分けます。「確認メールが届かなかったので電話した」は観察です。「メール配信が壊れている」は解釈です。「アプリ通知にしてほしい」は要望です。AIに全部を同じ事実として要約させると、原因と解決策が早く固定されます。原文IDを残し、要約から元の記録へ戻れるようにします。

業務担当者には、標準手順だけでなく例外を聞きます。入力不足、本人確認失敗、期限切れ、重複申請、担当者不在、システム停止、紙への切替、委託先からの差戻し、取消、返金、苦情のときに何が起きるか。新人と熟練者で処理が違うか。非公式な一覧表や個人メモがないと回らないか。ここに改善の手掛かりがあります。

時間を数字で記録します。利用者が操作する時間、待つ時間、担当者が作業する時間、次の担当へ渡るまでの時間を分けます。五分の入力の後に三営業日待つなら、フォームの一分短縮だけでは体験の中心課題を解決しません。平均だけでなく、よくある範囲と極端に遅いケースも見ます。

証拠台帳を作ると便利です。資料ID、種類、日付、対象、収集方法、担当者、機密度、利用可否、関連するブループリントの段階、確認日を記録します。AIで要約した場合は、使用ツール、入力範囲、出力、修正者も残します。図の各セルに証拠IDを付ければ、後から「なぜこの工程があるのか」を確認できます。

未確認の部分は空白にせず「仮説」と表示します。仮説Aは店舗担当への聞き取り待ち、仮説Bはログ確認待ち、と書けば次の調査になります。もっとも危険なのは、AIが埋めた自然な文章が確認済みの事実に見えることです。

Figma AI・Napkin AI・Framer・Canva AI比較

Figma AIは正式なサービスブループリントの置き場所として使いやすい候補です。レーン、ステップ、課題、機会、証拠、指標、オーナー、仮説のラベルをコンポーネント化できます。色だけで状態を示さず、形と文字でも「確認済み」「仮説」「廃止予定」「障害」を区別します。大きな図ほど検索、番号、目次、凡例が必要です。

Napkin AIの役割は、白紙をなくすことです。ヒアリングの要点を渡し、利用者行動、接点、フロント、バック、システムに分けた候補を作らせると、関係者は反応しやすくなります。ただし、生成されたレーン名をそのまま採用せず、組織の実際の言葉に直します。「オペレーション部門」のような総称ではなく、判断をする担当・チーム・委託先を特定します。

Framerはブループリントそのものを描く道具というより、接点の仮説を試す道具です。たとえば、予約変更時に「店舗確認待ち」の状態を明示する案、本人確認失敗後の再提出案内、申請状況ページを作り、少人数で使ってもらいます。ページだけを改善して裏側が変わらない場合は、その制約をブループリントへ戻します。

Canva AIとGammaは、全体図をそのまま貼るのではなく、対象に合わせて共有する際に便利です。店舗スタッフには変更後の手順、経営層には顧客影響・業務負担・投資判断、開発チームにはシステムと状態、研修参加者にはケース演習を見せます。原本へのリンク、版、更新日、適用開始日を必ず残してください。

調査記録を整理する補助として NotebookLM、長いインタビューの文字起こしには Whisperも候補になります。ただし、録音同意、機密情報、話者識別、誤変換の確認を行い、要約だけで原因を決めないでください。

調査から改善実験までの12段階

1. 対象を一つの利用目的に絞ります。 利用者、開始条件、終了状態、対象チャネル、現状図か理想図かを一文で決めます。
2. 関係者とオーナーを並べます。 利用者、フロント、バック、システム、委託先、規程の担当を特定し、図の責任者を一人置きます。
3. 証拠を収集して匿名化します。 インタビュー、ログ、問い合わせ、処理時間、マニュアル、通知、画面を集め、機密度と利用可否を記録します。
4. 利用者行動を時系列で置きます。 内部組織の都合ではなく、利用者が何を達成しようとするかを軸に段階を作ります。
5. 見える接点を対応させます。 画面、電話、店舗、メール、書類、配送物など、利用者が受け取る証拠を置きます。
6. フロントとバックの業務を追加します。 誰が何を見て、判断し、入力し、次へ渡すかを動詞と成果物で書きます。
7. システム・データ・規程をつなぎます。 API、台帳、権限、バッチ、通知、本人確認、委託、法定要件など支援基盤を示します。
8. 時間と例外を重ねます。 操作・作業・待ちを分け、取消、変更、不足、重複、障害、期限切れ、担当不在を追加します。
9. 現場確認を行います。 担当者に図を説明してもらい、順序、非公式作業、例外、責任、実際の所要時間を修正します。
10. 課題を原因別に分類します。 情報不足、権限、引継ぎ、システム、ルール、能力、負荷、表現、アクセシビリティに分けます。
11. 改善仮説と指標を決めます。 変更内容、期待する利用者・業務の結果、リスク、担当、期限、観察方法を書きます。
12. 小さく試して図を更新します。 一つの接点や受け渡しを試し、実際の結果を現状図・理想図・意思決定ログへ反映します。

最初の題材には、頻度が高く、関係部署が二つか三つあり、利用者の困り事が確認できる流れを選びます。住所変更、予約変更、請求書再発行、返品受付、アカウント権限申請などです。全社横断の大改革を最初に選ぶと、図の範囲が広がりすぎて確認が進みません。

ワークショップでは、AIが作った図を正解として投影しないでください。「この初稿のどこが違うか」を問い、参加者に修正してもらいます。発言者の役職で事実が決まらないよう、ログや実物の帳票と照合します。会議後に編集担当が決定・仮説・未確認を分け、関係者へ確認版を戻します。

試験用の例外セットも用意します。本人確認が一度失敗する、担当者が休み、通知が届かない、二重申請、変更期限を一日過ぎる、連携システムが停止する、利用者が電話とWebをまたぐ、代理人が手続きする、といったケースです。通常系だけでは見えない手作業と判断が現れます。

日本の組織で合意形成できる図にする

関係部署が多いサービスでは、同じ言葉が違う意味で使われます。「受付」は利用者が送信した時点か、担当者が開いた時点か。「完了」は社内処理が終わった時点か、利用者へ通知された時点か。「顧客」は契約者、利用者、支払者、代理人のどれか。最初に用語集を作り、図のセルでは曖昧な名詞を避けます。

部署名だけで責任を書かないようにします。「営業が確認」では、誰が、何を根拠に、どの権限で、いつまでに、どこへ記録するか分かりません。「担当営業がCRMの契約条件と申請内容を照合し、不一致理由を審査キューへ記録」のように、役割、入力、判断、出力を示します。

決裁と作業を分けることも大切です。申請を入力する人、内容を確認する人、例外を承認する人、システム権限を変更する人、利用者へ通知する人が異なる場合があります。一つの箱に「社内処理」と書くと、待ち時間と責任が消えます。承認が必要な理由と、基準を満たした通常処理まで同じ承認を通していないかを確認します。

会議では全体図を一度にレビューしないほうが効率的です。まず利用者行動と接点、次に現場業務、次にシステム・規程、最後に例外と改善案という順で分けます。参加者ごとに確認範囲を明確にし、全員の承認が必要な項目と、担当オーナーの確認で進められる項目を分けます。

図の密度にも注意します。A0用紙で読める図がオンライン会議やノートPCで読めるとは限りません。全体索引、段階ごとの詳細図、課題一覧、意思決定ログを分けます。セルには一つの行動を置き、長い説明は注釈へ移します。各ステップに番号を付けると、「左から三番目の青い箱」ではなく「S4-B2」と会話できます。

公共・行政サービスや幅広い利用者を対象にする場合、デジタル庁の デザインシステムの考え方も参考になります。組織にそのまま適用するのではなく、再利用可能な部品、分かりやすい情報、アクセシビリティ、継続的な改善という観点を自社のサービス設計へ置き換えてください。

外部委託先を「外部」とまとめないでください。コールセンター、配送、決済、本人確認、保守、店舗運営などは、入力・出力・サービス水準・障害連絡が異なります。利用者から見れば自社サービスの一部です。契約上の責任と実際の運用が違う場合は、課題として明示します。

最後に、改善案を組織図の変更だけにしないこと。フォームの説明を変える、確認通知へ期限を書く、担当者画面に根拠を表示する、二重入力をなくす、例外判断の基準を共有する、状態を利用者へ見せるなど、小さな変更で大きな待ちや問い合わせが減る場合があります。ブループリントは大規模システム刷新の理由付けだけに使う道具ではありません。

アクセシビリティ・個人情報・例外処理を組み込む

アクセシビリティは画面の最終チェックではなく、サービス全体のレーンです。視覚、聴覚、身体、認知、言語、年齢、通信環境、端末、支援者の有無によって接点が変わります。オンライン手続きが難しい場合の代替経路、その経路で同じ結果を得られるか、追加負担や遅延がないかを図に入れます。

Web接点では WCAG 2.2のような検証可能な基準を参照し、組織に必要な適合目標を決めます。ただし、ブループリントに「アクセシブル」と書くだけでは検証になりません。キーボード、見出し、ラベル、エラー、フォーカス、コントラスト、拡大、時間制限、認証、通知を誰がどの段階で確認するかを割り当てます。

電話や店舗も代替手段として自動的に使いやすいわけではありません。営業時間、待ち時間、本人確認、通訳、筆談、車いす動線、代理手続き、必要書類を確認します。Webから電話へ移った利用者が最初から説明し直すなら、チャネルはつながっていません。引継ぎ可能な情報と、プライバシー上引き継げない情報を分けます。

個人情報は収集、表示、転送、保管、削除の全段階を追います。誰が何の目的で見られるか、委託先へ何が渡るか、ログに残るか、誤送信時の連絡はどうなるか。AIで記録を要約する場合も入力範囲、保存、学習利用、権限、削除を確認します。サービスブループリント自体に実名や識別可能なケースを貼らないようにします。

例外処理には復旧の主体を書きます。「エラー表示」で終わらせず、利用者が再試行できるのか、データが保存されるのか、担当者へ通知されるのか、重複処理を防げるのか、何時間後に誰が追跡するのかを示します。障害時の紙・電話・手動入力への切替があるなら、通常復旧後の再入力と照合も必要です。

通知も一つのサービスです。送信成功と到達は違います。メール、SMS、アプリ通知、郵送のどれを使い、失敗を検知できるか、利用者が連絡先を変更した場合はどうするか、重要な期限を一度だけ知らせて終わらないかを確認します。通知文は Claude AIや ChatGPTで初稿を比較しても、制度・日時・問い合わせ先は原本から差し込み、人が確認します。

品質指標は利用者と業務の両側に置きます。完了率、再入力、問い合わせ、待ち、離脱、誤案内、差戻し、手作業、担当者の探索時間、例外処理時間を見ます。一つの画面のクリック率が上がっても、バック業務が増えたり利用者の誤解が増えたりするなら改善とは言えません。

一度きりのワークショップで終わらせない運用

サービスブループリントが古くなる理由は、更新責任がないからです。図ごとにオーナー、対象範囲、版、最終確認日、次回確認日、関連するプロダクト・業務・規程を記載します。変更案件の完了条件にブループリント更新を含めると、実態との差が広がりにくくなります。

正式な原本を一つ決めます。Figmaを原本にするなら、CanvaやGammaの説明資料は派生版と表示し、原本リンクと版を入れます。PDFをメールで配布すると、古い手順が残ります。適用終了日や「最新版はこのURL」という案内を付け、現場で参照する短い手順書も原本の変更と連動させます。

変更ログには、何を、なぜ、誰が、いつ変え、どの指標を確認するかを書きます。新しい画面が加わっただけでなく、バック業務、権限、通知、研修、委託先、問い合わせ対応がどう変わるか確認します。デザイン変更だけが先に公開されると、利用者の期待と現場の処理がずれます。

課題には種類と優先度を付けます。安全・権利、利用不能、誤案内、重大な待ち、繰返し作業、情報不足、表現、見た目の順に一律で並べる必要はありませんが、影響と頻度と修正可能性を共通基準で評価します。声の大きい要望だけで優先しないよう、証拠IDを結びます。

月次または四半期の短いレビューでは、全図を描き直しません。指標が悪化した段階、問い合わせが増えた段階、規程やシステムが変わった段階、仮説のまま残ったセルを確認します。担当者の異動時には、非公式作業が消えていないか聞きます。属人的な回避策は引継ぎで失われやすいからです。

AIは更新差分の整理に使えます。変更前後の手順書から候補差分を出す、会議記録から決定事項を抽出する、課題一覧を分類する、といった補助です。ただし、差分の正しさと適用範囲は担当者が確認します。規程文の削除をAIが「簡略化」と解釈し、重要な条件まで落とす可能性があります。

改善実験が終わったら、採用・不採用・追加検証を記録します。不採用案も理由を残すと、半年後に同じ議論を繰り返しません。実験の結果が想定と違った場合は、失敗を隠さずブループリントの仮説を更新します。図は完成品ではなく、サービスに関する共有理解の現在地です。

findaiverseの比較メモ

findaiverseでデザインAIを比較していると、図を生成できる製品は多くても、業務の事実を維持する仕組みは別問題だと分かります。文章から流れを作る速さ、共同編集、コンポーネント、説明資料、プロトタイプはそれぞれ価値があります。しかし、同じサービスの最新版を指していなければ、ツールが増えるほど混乱します。

私たちがサービス設計用途で見る最初の項目は、出力の美しさではなく修正可能性です。セルを移動できるか、レーンを追加できるか、証拠へリンクできるか、仮説と確認済みを区別できるか、コメントを決定へ変えられるか、版を追えるか。フラットな画像だけが残ると、現場の訂正を反映しにくくなります。

次に見るのは要約の損失です。AIは長い発言から滑らかな共通点を作りますが、少数の重大な例外を消すことがあります。「ほとんどの利用者は問題なく完了した」という要約の裏に、支援が必要な人だけ完了できない状況が隠れていないか。原文IDと例外一覧を残し、平均的な流れとは別に確認します。

三つ目は、図と実験の距離です。ブループリントで課題を発見しても、改善案が大きすぎると進みません。Framerで案内ページを試す、通知文を変える、担当者画面に状態を一つ追加する、受け渡しの必須項目を決めるなど、二週間以内に観察できる実験へ落とせるかを見ます。

四つ目は共有相手です。経営層、現場、開発、デザイン、法務、委託先、研修参加者が必要とする詳細は違います。原本を分割した派生資料は有効ですが、独立した別事実にしないこと。CanvaやGammaの資料には原本の版を付け、正式な変更はFigmaや指定リポジトリへ戻します。

初回は、利用者インタビュー二件、担当者ヒアリング二件、問い合わせ十件程度でも構いません。証拠の限界を表示し、一つの流れを描き、例外を三つ追加し、改善仮説を一つ試します。候補ツールは AIデザインツールのハブ、他カテゴリを含む一覧は findaiverseのAIツール一覧で確認できます。

注記：findaiverseは無料・有料のAI製品を掲載しています。本稿は独立した制作・運用ガイドであり、広告順位ではありません。機能、料金、保存、学習利用、共有権限、出力形式は変わる可能性があります。機密性の高い調査や公共サービスで使う前に、各サービスの最新規約と組織のセキュリティ・法務・アクセシビリティ基準を確認してください。

よくある質問

サービスブループリントとは何ですか？

サービスブループリントは、利用者の行動と接点、それを支えるフロント業務、バック業務、システム、データ、規程、委託先を同じ時間軸で可視化する設計図です。画面だけでなく、待ち、受け渡し、責任、例外を確認し、体験と業務を一緒に改善するために使います。

AIだけでサービスブループリントを作れますか？

文章からレーンや流れの初稿を作ることはできますが、AIだけでは現行業務の事実を保証できません。インタビュー、ログ、マニュアル、担当者確認が必要です。AI出力は仮説として表示し、順序、権限、時間、例外、責任を証拠と現場で確認してください。

カスタマージャーニーマップとの違いは何ですか？

カスタマージャーニーマップは利用者の行動、接点、感情、課題を中心に理解します。サービスブループリントは、その体験を支える社内外の業務、システム、ルールまでつなぎます。両方を使う場合、ジャーニーで課題を見つけ、ブループリントで発生構造と改善責任を確認できます。

FigmaとNapkin AIはどちらを使うべきですか？

Napkin AIは文章から構造候補を早く作り、議論を始める用途に向きます。Figmaはレーン、部品、証拠、コメント、版を含む正式な原本を共同管理する用途に向きます。Napkin AIで初稿を出し、確認した内容をFigmaで運用可能な図へ直す組合せが現実的です。

まとめ

AIでサービスブループリントを作るとき、速くなるべきなのは事実を飛ばす工程ではありません。発言を整理し、初稿を見える形にし、関係者が違いを指摘し、改善案を共有するまでの時間です。現行業務の確認、個人情報の保護、例外処理、責任の決定は人が引き受けます。

まず一つの手続きについて、開始と終了を決め、証拠を集め、Napkin AIで構造案を出し、Figmaで確認済み・仮説・未確認を分けてください。例外を三つ加え、改善案を一つFramerなどで試し、結果を図へ戻します。説明版はCanvaやGammaで作っても、原本へのリンクを残します。ツール選びは findaiverseのデザインカテゴリから始め、実際のサービス資料で小さく検証してください。