プロダクトマネージャー（PM）やUXリサーチャー（UXR）は、数十件のデプスインタビューを実施した後、5万〜30万字に及ぶ非構造化テキストの整理に直面します。手作業によるタグ付けやKJ法・親和図法（Affinity Mapping）を用いた分類は数日から数週間を要します。一方で、従来の短コンテキストAIモデルで文字起こしを細切れに投入したり、検索拡張生成（RAG）に頼ったりすると、回答者間の横断的な関係性が分断され、ペインポイントの発生頻度の歪みや全体像の喪失を招きがちでした。
Moonshot AI（月之暗面）が提供する「Kimi」は、この課題を根本から解消します。フラッグシップモデル「Kimi K3」の最大100万トークン、および「Kimi K2.6」「Kimi K2.7 Code」の256Kトークンという超長コンテキストウィンドウにより、調査サイクル全体の文字起こしデータを1つのアクティブセッションに一括投入できます。本稿では、テキストの前処理、3段階の構造化プロンプト設計、Context Caching（コンテキストキャッシング）によるコスト削減、そして定性分析特有の落とし穴を防ぐ実践手法を詳しく解説します。
なぜKimiは大量インタビュー分析に適しているのか
定性ユーザーリサーチの本質は「クロス比較」にあります。ある参加者の何気ない不満発言も、類似するユーザーセグメントの行動障壁と照合して初めて、組織として対応すべき共通課題として浮かび上がります。従来のAIアプローチには次の3つの大きな壁が存在していました。
- 断片的な検索による全体視野の喪失： 従来のRAGは文脈の類似度に基づいてテキスト断片を抽出するため、「請求エラーに言及した人はいるか」という質問には答えられますが、「25名全員の中で最も頻出する業務上のボトルネック上位5件を抽出し、管理者と一般ユーザーの違いを比較せよ」といった全体集計には対応できません。
- 個別要約による情報の劣化： 1ファイルずつ個別に要約させてから人間がそれらを突き合わせる方法は、手間がかかるだけでなく、要約の過程で重要な文脈が抜け落ち、人間の主観的バイアスが再混入します。
- 抽象的すぎる「定型要約」の罠： 制約をかけずに要約させると「ユーザーはより使いやすいUIを求めている」といった抽象的な表現に終始し、エンジニアやデザイナーが仕様策定に必要とする具体的な障害ステップや生の声（Verbatim）が失われます。
Kimiの長文処理能力は、45分間のインタビュー数十本分に相当する文字起こしを一括で読み込めます（1ファイルあたり最大100 MiB、txt、md、docx、pdf等に対応）。テキスト全体に均一にアテンションを効かせることで、全参加者を横断した出現頻度の正確な算出やペルソナ間の矛盾点の発見が可能になります。
実践4ステップ：書き起こしからプロダクト意思決定へ
厳密なリサーチ精度を保ちながら、機械的なコーディング作業を80%削減するための4つの手順です。
ステップ1：文字起こしデータの匿名化とメタデータ標準化
Kimiにデータを投入する前に、プライバシー保護（PIIスクラビング）とフォーマットの標準化を行います。
- 個人特定情報（PII）のマスク： 氏名、社名、パスワード、具体的な財務数値を一括置換し、
P01_中規模_デザイナー、P02_エンタープライズ_情シス管理者のような識別子を付与します。 - ヘッダーメタデータの統一： 各文字起こしファイルの冒頭に以下のメタデータを記載します。
- 回答者ID：P01
- ペルソナ・役職：シニアオペレーションマネージャー
- 企業規模：500〜1,000名
- 主な職務目的：月次在庫照合と自動レポート出力
- ファイル形式の整理： テキスト（
.txt）、Markdown（.md）、Word（.docx）に統一します。KimiのWebインターフェースではドラッグ＆ドロップで一括アップロードでき、API利用時は統一テキストブロックとしてプロンプトに組み込みます。
ステップ2：コンテキストアンカーの設定と役割定義
ファイルを読み込ませた最初のターンでは、いきなり「要約して」と指示してはいけません。分析エンジンとしての役割、事実準拠の制約、参照ルールを定義します。
あなたは経験豊富なUXリサーチリードおよびシニアプロダクトマネージャーです。
最近実施したレポート機能に関する20名分のユーザーインタビュー書き起こし（匿名化済み）を読み込ませました。
あなたの役割は定性分析エンジンです。以下の規則を厳守してください。
1. すべての分析結果は提供されたテキストの記述のみに基づき、推測や事実の捏造を一切行わないこと。
2. 引用や根拠を示す際は、必ず回答者ID（P01〜P20）を明記すること。
3. ユーザーの「表面的な機能要望」（例：「CSV出力ボタンがほしい」）と、「本質的な課題」（例：「1万行超のデータ同期時に画面がタイムアウトする」）を明確に区別すること。
20名分の書き起こしをすべて認識したことを確認し、認識した回答者IDと役職の一覧を返答した上で、次の具体的な指示を待ってください。
痛点抽出：3段階の構造化プロンプトフレームワーク
表層的な不満から製品要件へと昇華させるための3段階のアプローチです。
第1段階：網羅的なペインポイントと生の声の抽出
全ファイルを走査し、具体的な業務摩擦と感情の起伏を逃さずリスト化させます。
20名全員のインタビュー書き起こしから、ユーザーが困惑、苛立ち、作業中断、不満を感じた具体的なシーンを網羅的に抽出してください。
以下の形式のMarkdownテーブルで出力してください。
- 課題ID（PP01, PP02…）
- 発生した体験フェーズ（例：オンボーディング、データ連携、カスタム検索設定、レポート定期出力）
- 具体的な課題内容（どのような状況でどのような障害が発生したか）
- 深刻度（高：作業が完全に中断・遂行不能；中：複雑な回避策が必要；低：軽微なストレス）
- 該当する回答者ID（言及したすべての参加者ID、例：P02, P06, P14）
- 象徴的な生の引用句（課題の切実さが伝わるユーザーの発言を1つ、回答者ID付きで抜粋）
第2段階：共通パターンのクラスタリングとセグメント間比較
個別事象から共通テーマを導き出し、ペルソナ別の傾向差を分析します。
抽出されたペインポイントのうち、3名以上の回答者が言及した共通課題をテーマごとにグループ化し、言及人数の多い順に並べ替えてください。
各テーマについて以下を分析してください。
1. テーマ名と課題ステートメント
2. 出現頻度：影響を受けているユニーク回答者数と全体比率（例：14/20名、70%）
3. セグメント比較：企業管理者と一般担当者で、この課題の現れ方にどのような違いがあるか
4. 根本原因の推定：システム性能の限界、情報設計の不備、メンタルモデルの乖離のいずれに起因するか
5. 現状の回避行動：ユーザーは現在どのように業務を回しているか（例：Excelでの手動再計算、自作マクロ、紙での二重チェック）
第3段階：JTBD（Jobs-to-be-Done）による機会領域への変換
抽出された課題を、開発バックログやPRD（製品要求仕様書）に直結するフォーマットへ変換します。
上位5件の主要ペインポイントを、以下のJobs-to-be-Done（JTBD）形式に落とし込んでください。
「【特定の業務状況やトリガー】において、ユーザーは【期待するビジネス成果】を得るために【行動や目的】を達成したいが、現在は【Kimiが特定した根本課題】によって阻まれている。」
各JTBDステートメントに対して：
- プロダクトチームが検証可能な仮説の方向性を2点提示してください。
- ユーザー間の要望の衝突（例：パワーユーザーが求める高度な設定項目が、初心者にとって過度な認知的負荷になる等）があれば明記してください。
技術的な最適化：Context Cachingで反復分析のコストを抑制
API経由（kimi-k3 や kimi-k2.6 等）で数十万字のインタビューデータを繰り返し分析する場合、毎回フルテキストを送信するとトークン消費とレスポンス遅延が課題となります。
Moonshot AIの Context Caching（コンテキストキャッシング） を活用することで、この問題を防げます。
- 仕組み： プロンプトの先頭（
systemメッセージ等）にインタビュー全文を配置し、キャッシュ設定（prompt_cache_optionsやcache_control）を宣言すると、Kimiがその入力をキャッシュに書き込みます。 - TTL（有効期限）の選定： 自動スクリプトには「5分（
5m）」、リサーチャーが対話形式で深掘りする作業には「1時間（1h）」が適しています。キャッシュがヒットするたびに有効期限は自動で無料延長されます。 - コストと遅延の削減： キャッシュヒット時の入力トークン料金は、通常の未ヒット時の約10分の1です（例：
kimi-k3の場合、通常 ¥20/1M tokens に対し、ヒット時は ¥2/1M tokens）。同一データに対して30通りの深掘りクエリを実行しても、極めて低いコストと高速なレスポンス（TTFT短縮）で処理可能です。
from openai import OpenAI
client = OpenAI(
api_key="YOUR_MOONSHOT_API_KEY",
base_url="https://api.moonshot.cn/v1",
)
# インタビュー全文をプレフィックスに配置し、1時間のキャッシュを適用
completion = client.chat.completions.create(
model="kimi-k3",
messages=[
{
"role": "system",
"content": f"あなたはUXリサーチアシスタントです。インタビューデータ:\n\n{bulk_transcripts_text}",
},
{
"role": "user",
"content": "大企業管理者とスタートアップ担当者で、エクスポート処理への不満表現を比較してください。",
},
],
prompt_cache_options={"mode": "implicit", "ttl": "1h"},
)
print(completion.choices[0].message.content)
調査の信頼性を守るベストプラクティス
AIによる定性データ分析を安全かつ効果的に運用するためのポイントです。
| 観点 | 陥りがちな失敗 | 推奨される対策 |
|---|---|---|
| 発言引用の真正性 | AIが言い換えた文章を顧客の生の言葉と誤認する | 必ず参加者ID付きの直接引用を出力させ、元テキスト内を検索して実在を確認する |
| 頻度集計のバイアス | 1人の声の大きな不満を全体の共通課題と勘違いする | 「言及したユニーク回答者数」を数えさせ、1人が10回不満を述べていても1票として処理する |
| 機密保持・コンプライアンス | 顧客の実名や社内システム情報をそのまま投入する | 投入前にスクリプト等で完全に匿名化し、社内規程および同意書に適合させる |
| ハルシネーションの防止 | 記述がない事項についてのAIの推測を事実と信じる | プロンプトに「書き起こしに明記されていない場合は『該当なし』と明記すること」と指示する |
まとめ
Kimiの100万トークンに及ぶ長文処理能力と3段階の構造化プロンプトを組み合わせることで、従来数日を要していたインタビューの分類作業を数時間に圧縮できます。断片的なテキスト検索による文脈の見落としを防ぎ、全参加者を俯瞰した正確な頻度集計と生の声に裏打ちされたペインポイントマップを手に入れることができます。