こんにちは。グッドパッチのサービスデザイナーのぬまです。
過去にもいろいろな記事を出していますが、グッドパッチでは生成AIを活用した新たなデザインプロセスを日々検討しています。中でもホットな領域が、ユーザーインタビューのいわゆる「後工程」です。
今回はインタビューを実施したあと、文字起こしの整形から、要約・示唆の抽出、振り返り用のHTMLレポート作成、Slackへの通知までをAIワークフローで丸ごと自動化してみました。一緒にインタビューを進めているメンバーと「これはいい！」とかなり盛り上がり、記事を書くことにしました。
インタビューが終わると、20〜30分ほどで「整形された議事録・要約・示唆・分析の種」の4ファイルと、それらをまとめたHTMLの図解レポートが自動で生成され、Slackに通知が届きます。
目次
インタビュー後の工程を自動化したい
生成AIによって今は誰でも、早くプロトタイプを作れるようになりました。そのため、プロダクトの開発サイクルがとても速くなっているのは皆さんもご存じのところでしょう。
だからこそ、そもそも「なぜそれを作るのか」「何を作るべきなのか」を考えるプロセスに時間を割き、ユーザーの悩みや背景のような一次情報をインタビューで確かめることの方が重要だと感じています。
一方で、インタビューによって仮説を検証したいけれども、分析作業に時間をかけたくない自分もいます。重要なインタビューに全集中した上で分析工程を高速化し、解決アイディアをプロトタイプに早く落とし込んで前に進めたい。そのような思いで、ひとまず粗いものでもいいから、インタビュー後の工程をAIで自動化するワークフローを組んでみることにしました。
インタビューのワークフローをAIエージェントでつないでいく
仕組みを作る前に、まず社内のデザイナーに話を聞いてみることにしました。直近ではAIを使ったリサーチにあまり携われていなかったので、周りの人がどのようにAIを使ってインタビューを実施しているか聞いてみることに。
結果、社内のリサーチに詳しいメンバーから、次のようなコメントをいただきました。
- 文字起こしはMeetやZoomで音源を取り、NotebookLMで整形すると使いやすい
- 語尾や発言のニュアンスはそのまま残す
- 分析は2種類に分けて考える。要約・抽出のような「ロジカルに絞り込む」作業はAIでかなり出せる。一方、ユーザーの背景からインサイトを立ち上げる作業はAIにヒントをもらいつつ、単位化や分析は人がやる
- 課題抽出も「インタビューで明示的に言われたもの」ならAIで出せる
加えて、NotebookLM用にどのようなプロンプトを使っているか共有してもらいました。話者の分離、フィラーの削除、口調やニュアンスの維持、テーマ見出しの付与などを指示しているようです。これらのエッセンスは、のちのAIワークフローの構築の際に取り入れています。
Claudeには、GitHubのイベント等をトリガーにAIエージェントを起動できる「Routines（ルーティン）」という機能があります。
ちょうど別のプロジェクトでこの機能を利用していたことがあるので、うまくいきそうなイメージはありました。Meetの文字起こしをGitHubに上がれば、整形も、要約も、示唆出しも、図解レポートの生成も、Slackへの通知までまとめてRoutinesに任せられるはずだと、ワークフローのイメージが湧いたのです。
そこで当日のインタビューの3時間前くらいに、駆け込みでサクッと組んでみることにしました。
インタビューが終わると、7つのフローが自動で回ってHTMLのレポートが出てくる
そして組み上げたのは、インタビューが終わると後工程が勝手に進むワークフローです。全体は7つのステップでつなげています。
- Google Meetが議事録（文字起こし）を自動生成する
- GASで議事録を検知するようにして、GitHubにPull Request（PR）を自動作成する
- PRのオープンをトリガーに、ClaudeのRoutinesが起動する
- Routinesが文字起こしと既存の検討資料を読み込む
- 整形された議事録・要約・示唆・分析の種のMarkdown 4ファイルを生成する
- 4ファイルを入力に、HTMLの図解レポートを生成する
- Slackに要約・示唆・アイデアの種を通知する
図にするとやや複雑に見えますが、これらはすべてGASと、Routinesだけで構成しています。各ステップの内容を順に見ていきましょう。
GASで、Docが入ったら自動でGitHubにPRを立てる
最初のステップはGAS（Google Apps Script）の出番です。専用のDriveフォルダに、決めておいたキーワードを件名に含むドキュメントが入ると、GASがそれを検知するようにし、本文をMarkdownに変換して、GitHubにPRを自動で立てます。
つまり、インタビューの文字起こしをそのフォルダに入れさえすれば、あとは勝手にPRになるという仕組みです。GitHub側では、インタビュー結果のPRが順に並んでいきます。
PRが開いたら、ClaudeのRoutinesがあとは全部やってくれる
ふたつ目は、ClaudeのRoutinesです。設定はシンプルで、トリガーを「PRのオープン」に、通知先をSlackにして、処理内容のプロンプトを指示欄に貼るだけです。
GASが立てたPRが開くとRoutinesが起動し、文字起こしと案件の文脈資料を読み込んで、次の4つのMarkdownファイルを生成します。
- 整形された議事録：話者を分け、言い淀みを削って、読める形に整えた発話録
- 要約：インタビューの要点を短くまとめたもの
- 示唆：インタビューで明示的に語られた、ユーザーの価値観や課題についての気付き（推測は混ぜず、事実ベースで）
- 分析の種：既存の仮説とどう接続するか、次に深掘りすべき問いや、施策アイデアの種
4ファイルを書き出したあと、それらを入力にHTMLの図解レポートを生成します。ペルソナ・レポート・発話録を1ページにまとめた、振り返り用のレポートです。
何をインプットに、どう考えさせているか
AIにインタビュー内容の分析をさせるためのインプットは2種類に分けました。 1つは、PRに入ってきた生の文字起こし。もう1つは、リポジトリに溜めてあるプロジェクトの文脈資料です。具体的には、案件の前提やQ&Aをまとめた中心ドキュメント、ビジネスモデルとグロースサイクルの戦略資料、ユーザーセグメントの差別化切り口、市場分析資料。これらを毎回読み込ませてから、生成に入らせています。
ポイントは、すべてのデータを丸ごと読ませないことです。 手元の資料をそのまま全部渡すのではなく、必要な情報だけに絞り込み、文脈として読ませるようにしました。情報を盛りすぎると、かえってインタビューの解釈がぶれてしまいます。あくまで「自分たちが今立てている仮説」に関連する範囲にとどめる、という考え方です。
発話録では、「語尾や発言はそのまま残す」というルールにしました（社内で聞いた話の通りです）。整形の段階で発言のニュアンスが消えてしまうと、その後の示唆や分析がすべて信用できなくなってしまうからです。
示唆と分析の種は、AIに任せる範囲を変えています。 示唆は「インタビューで明示的に語られたこと」だけに絞り、推測と事実を分けて書かせます。分析の種はあくまで「アイデアの種」レベルのものを出してもらう程度にとどめています。
最後にHTMLレポートは、専用のスキルを作って型を固定しました。 毎回そのスキルを適用することで、見た目とフォーマットをすべてそろえています。デザインは固定したまま、中身だけが対象者のデータに差し替わるようにしています。
ユーザーインタビューの振り返りが、楽しくなった
約3時間と突貫で作った割には、活用した初日からインタビューの振り返りがとても楽になりました。インタビューが終わると20〜30分後に、要約5行・主な示唆5点・施策アイデアの種5点、そしてHTMLの図解レポートがそろいます。本来この後に手作業でやるはずだったことが、丸ごとなくなったのです。
「終わればレポートがすぐ上がってくる」と思えるようになってから、振り返りそのものが楽しくなりました。
一緒に進めているメンバーとの振り返りも、その場の2人の記憶だけに頼らなくなりました。振り返りのラップアップをしている最中に、裏でRoutinesが動き始めるので、話している途中に生成結果がインプットできます。
自分たちが振り返っている内容に加えて、AIが事実に基づいてまとめた結果を見ると、「こういう発言も、確かにしていたよね」と思い出せます。もう「一人」、AIが幅広く情報を補ってくれるため、振り返りの解像度が上がりました。
ここからさらに先に進めることもできそうです。インタビュー内容からユーザーの潜在ニーズを推測し、どんな施策が考えられるかを出して、そのアイデアをプロトタイプのイメージに起こすところまで、Routinesで自動化できると思います。
ただ、自動化をしすぎると逆効果だとも感じています。出てきたアイデアに引っ張られて、「そもそもユーザーはどんな人だったのか」「本当はこういうところも気にしていたのでは」という問いを持たないまま、それっぽく良いアイデアだけが並んでしまいます。そうなると、肝心のユーザー理解の解像度を高めることに、かえって時間をかけられなくなる気がしました。だからAIワークフローは”ほどよく”組む必要があるとは感じています。
さらにこの仕組みを完成させてから、社内勉強会でシェアしました。実際に生成されたHTMLレポートを見てもらいながら、「ここから先の分析はどう進めているか」「どこを自動化して、どこに人が介入すべきか」という問いを、参加者のみなさんと一緒に考えました。
例えば、「チーム全員でインタビュー結果を読み合わせるデブリーフィングの時間を意識的に設けることが大事」という話も出ました。自動生成されたレポートも含めると、人間にとっては情報量はやや多めです。
だからこそ、チームで一緒に眺めながら「この人はこういうタイプだね」「この発言が引っかかる」と話し合う時間が、ユーザー理解をチームで揃えていくうえで大きな意味を持ちます。
すぐ作れる時代だからこそ、一次情報を取りにいく
冒頭でお話ししたように、今は生成AIのおかげで、誰でも何でも、すぐに作れるようになりました。
ただ、生成AIが出してくるものはどうしても平均的なアウトプットになりがちです。最近では「AI Slop（AIによる質の低いコンテンツ）」とも呼ばれます。AIは、何となくそれらしいものを、すぐに出してしまうからです。
よって「誰のために、どんな問題を解決するのか」という問いが、これまで以上に大事になってきます。何を作るのか、そしてなぜ作るのか。その問いに、既存のリサーチ結果だけで答えようとすると、やはりAIがまとめた平均的な情報に終始してしまいます。
だからこそ、一次情報を取りにいくことが非常に大事になってきていると思っています。なぜなら、AIがまだ学習できていない情報が含まれているから。ユーザーの解像度を高めるために不可欠な、今のところ人間にしかできない価値の出し方でしょう。
解像度が高まると同時に、「この人の課題を解決したい」と、その人自身に好奇心を持つことができ、熱量が生まれてきます。だからこそ、人が介入するポイントをどこに設けるか、という「Human in the Loop」の設計が、このAIワークフローにおいても欠かせない、と改めて実感できました。この熱量もまた、AIには生み出せない価値なのだと信じています。
ここまで読んでいただき、ありがとうございました。
AI時代に、自分の領域を積極的に広げていきたい方。そして、AI時代のデザイナーの価値を一緒に考えていきたい方。私はそんな人たちと一緒に働きたいと思っています。少しでも興味を持ってくれた方、よければお気軽にカジュアル面談からいかがでしょうか。お待ちしています。
