Claudeで受注・失注インタビューを分析し、テーマを買い手の発言までたどれるようにする

分析するインタビューを確定する

書き起こしを読む前に、対象一覧を作ります。インタビュー1件を1行にし、ファイル名、インタビューID、案件ID、実施日、受注か失注か、対象に含めた理由を書きます。ファイルがない記録や読めない記録には、その旨を記します。インタビュー件数、買い手の人数、案件数は別の単位です。同じ案件で2人に話を聞いた場合や、同じ買い手に2回聞いた場合は、どの単位で数えるかを決め、所見に毎回書きます。後から追加するインタビューは新しい版として扱い、件数を数え直します。

この一覧が母数の範囲も決めます。「今四半期の失注案件のうち中堅企業向け」も母数になり、対象全体も母数になります。所見でどちらを使ったかを明示すれば、どちらも正当です。

使うのは、利用許可のある書き起こしまたはサーベイの出力で、話者の区別と固定のIDが付いたものです。判断に不要な個人情報は、自社の規程に沿って取り除きます。インタビューがまだない場合は、調査チームがなくても受注・失注分析を始める方法とインタビューガイドの作り方が先です。

繰り返す調査なら、対象一覧、ラベルの定義、確認済みの出力をClaudeのプロジェクトナレッジに置きます。設定の手順はプロジェクトの設定方法にまとめてあります。Anthropicのプロジェクトの管理ページには、プロジェクトナレッジに追加しない限りチャット間で文脈は共有されないとあるため、出力はファイルとして保存してください。一度きりの分析は、利用許可のあるファイルを添付した通常のチャットでも試せます。ただし、対象の規模や網羅性は、対象一覧とインタビューごとの確認で管理します。

テーマを付ける前に、発言を抜き出す

インタビュー1件について、購買判断に関わる買い手の発言を、原文どおりの本文、インタビューID、段落番号やタイムスタンプなどの出典箇所、仮のラベルの4点で返してもらいます。誰の発言か、どんな条件付きの言い方かが残るよう、前後の言葉も残します。引用とClaudeの解釈は別の欄に分け、意味が曖昧な箇所は埋めずに「曖昧」と印を付けてもらいます。

発言に短いラベルを付けるこの作業を、調査の用語ではコーディングと呼びます。Clozdのテーマ管理の指針も、インタビューにテーマを付けるたびに、その気持ちを買い手自身の言葉で表した引用を切り出すよう求めています（Clozdの記事、英語）。引用のないラベルは、その出力の中では裏付けがない状態です。作られたテーマだと決まったわけではありませんが、まだ根拠にはなりません。

残す価値のあるプロンプトは一つで、数える単位を固定し、引用と推論を分けるためのものです。効果を測定したものではないため、出発点の文言として使ってください。

インタビュー[ID]を、[判断に関する問い]の観点で分析してください。関係する買い手の発言を原文のまま、出典箇所と仮のラベルを添えて抜き出してください。条件付きの言い方や、矛盾する発言も残してください。各引用とあなたの解釈は分けて書き、曖昧な箇所は補わずに曖昧と記してください。提供したこのインタビューだけを使ってください。抜き出されなかった箇所を、発言がなかった証拠として扱わないでください。

使う予定の引用は全て原文と照合します。書き起こしの冒頭・中盤・末尾を読むのは初期の抜けを探す確認であり、その間の内容まで処理された証拠にはなりません。インタビューごとの完了記録を対象一覧と突き合わせます。早い段階で引用を3つ確認すると、言い換えが引用として出ている問題に気づけますが、後から使う引用も一つずつ確認します。

判断の意味でまとめ、例外を残す

対象全体に広げる前に、まず少数の対象で基準を合わせます。二つの発言が同じ判断要因を指しているかを判断します。「高すぎる」は、他社と比べた価格、価値が伝わらなかったこと、予算がなくなったことのどれも指し得ます。発言がその区別を支えるときだけ分け、そうでなければ未解決と記します。各ラベルには含める条件と含めない条件を書き、どのラベルにも合わない発言も残します。

この記事では、最初の一巡は発言からラベルを起こす方法を勧めます。一方で、問いが決まっているなら、あらかじめ定義した分類表を使うことも正当です。条件は、改訂できることと、付いたラベルを一件ずつ元の発言と照らすことです。自分が分類を与えたという理由でテーマを退ける必要はなく、発言がラベルを支えていないときに退けます。

Goodpatchのリサーチャーは、リモートワークに関するインタビューをGPT-4で切片化・グルーピング・抽象化した実験を報告しています。リサーチャーの考え方を反映したプロンプトでは、欲求を軸にしたラベルと発話の切片が保たれた出力になり、指定の少ないプロンプトでは単語の共通点による分類と要約になったとしています。結論は次の一文です。「リサーチャーとしては、生成AIの出力結果をそのまま使うのではなく、たたき台として使うのが良さそうだと感じました。」（Goodpatch「生成AIでインタビュー分析」）。別のモデルによる一社の実験報告であり、現在のClaudeの性能を示すものではありません。引き継げるのは、切片を添えたまま出力させ、まとまりを一つずつ確認する姿勢です。

定義が固まったら、残りのインタビューにも同じ定義を1件ずつ適用し、完了記録を付けます。長いインタビューを分割しても1件は1件です。定義を変えたら済んだ行に戻って見直し、原文の引用、要約、解釈は別の列に保ちます。

テーマごとに、インタビューの件数を数える

テーマごとに、対象の各インタビューに「支持」「反対」「混在」「言及なし」「不明」のいずれかを、根拠となる発言と一緒に付けます。「言及なし」は、そのインタビューを確認したうえで話題が出なかったことを指します。取得結果に出てこなかったことから推測してはいけません。「記録にない」と「確認していない」は別です。そのうえで、値ごとに固有のIDを数えます。

架空の例です。価格に関する判断について、5件のインタビューがあるとします。

所見はこう書きます。「今回の対象5件のうち、価格テーマを支持するのは2件、反対が1件、混在が1件、言及なしが1件」。I04を黙って支持に数えてはいけません。別に「導入の手間」というテーマがあり、I01とI04が入るなら、二つのテーマの件数を足すと同じインタビューを二重に数えることになります。テーマは重なるので、テーマ別の合計が対象の件数と一致する必要はありません。別の懸念を挙げた買い手が、このテーマを否定したことにもなりません。

少ない件数では、割合が誤解を招きます。9件なら1件で100÷9、つまり約11.11ポイント動くため、「買い手の44%」は対象にない精度を足しています。件数、母数、例外を一つの文に入れて、テーマが単独で歩き出さないようにします。Dovetailの受注・失注分析ガイドは、各インタビューのテーマを同じ形式で記録し、対象全体でパターンを確かめるよう勧めています（Dovetailの記事、英語）。母数と精度の扱いは、この記事で提案する方法です。

共有する前に、根拠を確認する

• 引用した発言は全て、シートに書いた出典箇所で原文を確認し、言い換えは引用符を付けずに解釈の欄に置いてあります。
• 対象一覧の全てのインタビューに完了の記録があり、各書き起こしの冒頭・中盤・末尾は出力から推測せず自分で確認しています。
• 各テーマのラベルはその下の発言に合っており、発言から起こしたラベルでも定義済みの分類表のラベルでも同じ確認をし、分類表の版を記録しています。
• 各所見は対象の範囲と母数を明示し、宣言した単位（インタビュー、買い手、案件のいずれか）の固有の数で、支持・反対・混在・言及なし・不明の件数を示しています。
• 未解決の曖昧さは、近いテーマに入れずに未解決の問いとして一覧にしています。

対象一覧、版番号を付けた分類表、確認済みの引用シート、未解決の事項を保存し、次の調査では分類表を作り直さずに改訂します。

記録から分からないこと

書き起こしにあるのは、買い手が述べたことです。述べられていない動機は分かりませんし、Claudeが筋の通った説明を返しても、それが事実になるわけではありません。Cotionの失注分析の記事は、AIの出力を「事実・傾向・仮説」の3層に分けるよう勧めています（Cotion「失注分析にAIを使う方法」）。仮説の層は、買い手が確認するまで仮説のまま扱います。丁寧な言い回しから隠れた本音を推測するのも、記録が支えない解釈です。意味が定まらなければ、不明と記します。

対象の外にある出現率も分かりません。所見は「今回のインタビューでは」で始まります。件数を増やしても偏った選び方は直らず、コンテキストウィンドウが大きくても同じです。1件だけでも重大な失敗を語るテーマは、次に確かめる問いとして一覧に残します。頻出するテーマは訴求を見直す材料になり、その先は受注・失注の結果を訴求に反映する記事が扱いますが、頻度だけで重要度は決まりません。CRMの失注理由と買い手の説明が食い違うときは、どちらも書き換えずに同じ案件で並べて比べます。

次の仕事が、構造化したサーベイの収集であるとき

テーマ一覧を1回作ることより、買い手の回答を期ごとに集め続けることの方が難しい場合があります。自力で続けるなら、再利用できるインタビューガイド、固定の記録項目、自社で管理する分類表、1件ごとの確認、明示した実施周期が対策になります。

Steve Win/Lossが担うのは、この分析手順より狭い仕事です。買い手がAIチャットで質問に答え、チャットは追加の質問もします。集まった回答に対して、担当者が必要なときに、テーマ、失注の要因、競合に関する洞察をまとめた要約を生成できます。要約はGenerate Summaryをクリックした時点で利用できる回答から作られるため、どの回答を承認済みか確認してください。サーベイの記録として扱い、書き起こしの原文引用とは見なさないでください。ここで説明したWin/Lossのサーベイとレポートの流れは、既存の書き起こし一式を取り込んで分析するものではありません。解釈、引用の確認、対象の選び方は、この記事のとおり自社の作業として残ります。買い手側の回答を集め続ける部分を続けられないなら、SteveのWin/Lossを確認してください。