Claude導入事例の作り方 — 顧客インタビューの文字起こしから許諾確認まで

顧客インタビューの文字起こしから導入事例の記事を作るとき、Claudeに任せやすいのは構成の組み立てと、顧客に確認してもらう項目の洗い出しです。逆に、数字の正しさと掲載してよいかの判断は、顧客と自社の担当者に残ります。この記事では、文字起こしと事例フォーマットをProjectsに置き、記事案と「掲載確認シート」を同時に作る手順を、広報・マーケ担当の目線で示します。

事例記事の遅れは、執筆よりも確認の往復で起きがちです。顧客に「全部見てください」と記事を投げると、どこを見るべきか分からず返事が止まります。Claudeに確認項目を種類ごとに切り分けさせ、顧客が判断する箇所だけを短いシートで渡せば、往復の回数を減らせます。

Claudeに任せる範囲と、人が決める範囲

最初に分担を決めておきます。ここが曖昧だと、読みやすい文章の裏で誤った数字や、言っていない発言が混ざります。

右列の判断は、Claudeが出した文面を読んでも代わりにはなりません。掲載の許諾は顧客の意思表示で、契約や社内規程で条件が決まっていることもあります。

Projectsに何を置くか

事例づくりは、複数回の会話に分かれます。構成案、本文、確認シートを別々のチャットで作るため、共通の材料をProjectsに置くと毎回の貼り直しが要りません。ヘルプセンターでは、プロジェクトに置いた知識はそのプロジェクト内のすべてのチャットで使われ、プロジェクト指示も同様に全チャットへ効くと説明されています。

一方で、チャットの中身は別のチャットへ引き継がれません。プロジェクトの知識に追加した情報だけが共有されるので、会話の途中で決めた方針は、プロジェクト指示かファイルに書き戻しておきます。

置くものは次の4種類です。

• 顧客インタビューの文字起こし(TXTまたはDOCX)
• 自社の事例フォーマット(見出し、文字数、必須項目を書いた雛形)
• 公開済みの事例を1〜2本(文体と構成の見本)
• 表記ルール(社名表記、製品名、禁止表現)

ファイル形式はPDF、DOCX、CSV、TXT、HTML、ODT、RTF、EPUB、JSONなどが使えます。プロジェクトのファイルは1つ30MBまでで、個数に決まった上限はありませんが、内容の合計がコンテキストウィンドウに収まる必要があります。ファイルの扱いは文字の抽出が中心です(マルチモーダル対応のPDFを除く)。文字起こしを画像のPDFで持っているなら、先にテキスト化しておきます。上限の全体はClaudeファイル上限の一覧にあります。

有料プランでは、知識がコンテキストの上限に近づくとRAGのモードに自動で切り替わり、容量が最大10倍に広がります。仕組みと注意点はClaude ProjectsのRAG検索の仕組みにまとめています。事例1本分の文字起こしなら収まることがほとんどですが、複数社の事例を1つのプロジェクトで回すと切り替わる可能性があります。顧客ごとにプロジェクトを分けておくと、他社の発言が混ざる事故も避けられます。

顧客の発言を預ける前に確認すること

文字起こしには、顧客の社名、担当者名、未公開の数字が入っています。Claudeに渡す前に、次の2点を確認します。

1. 取材時に、文字起こしを生成AIで処理することを顧客に伝えているか
2. 自分のプランで、入力の学習利用がどう扱われるか

後者はClaudeを学習させない設定で切り替え手順を、前者の情報の扱い全般はClaudeに機密情報を入力しても安全かで整理しています。取材の同意書にAI利用の記載がなければ、そこを直すのが先です。

固有名詞は、渡す前に「顧客A社」「導入責任者」のような属性へ置き換える進め方があります。ただし、事例の最終稿では実名が必要になるため、置換表は人の手元に残し、元の名前に戻す作業は人が行います。

手順1: プロジェクト指示に事例のルールを書く

プロジェクトを作り、「Set project instructions」から指示を保存します。プロジェクト名と説明はClaudeには渡らないとヘルプセンターに明記されているので、ルールは名前ではなく指示に書きます。

あなたは、BtoBサービスの導入事例を作る編集者です。
材料はこのプロジェクトの知識にあるファイルだけです。
 
守ること:
- 文字起こしに無い数字、固有名詞、因果関係を書かない。
  必要なのに材料が無い箇所は [要確認: 何が足りないか] と書く。
- 顧客の発言を引用するときは、文字起こしの原文をそのまま使い、
  発言ID(例: T-0123)を付ける。要約は引用符で囲まない。
- 成果の数字には、必ず根拠になった発言のIDを添える。
- 「大幅に」「劇的に」など、数字の裏付けが無い強い形容を使わない。
- 事例フォーマット(case-format.docx)の見出しと順序に従う。

指示の中核は2つです。材料に無いことは書かせず [要確認] として残すこと、そして数字と引用に出どころのIDを付けさせることです。IDがあると、後で顧客に「この数字はここでの発言が根拠です」と示せます。

発言IDは、文字起こしの各行に先頭から振っておきます。行ごとの採番と、IDによる引用の原文照合はClaudeでインタビュー逐語録を横断分析する手順で、スクリプト付きで書いています。1社の事例でも同じやり方がそのまま使えます。

手順2: 構成案を作り、材料の過不足を見る

本文に入る前に、まず構成案だけを出させます。ここで材料の穴が見つかると、取材の追加が早い段階で決められます。

添付の文字起こしと case-format.docx から、導入事例の構成案を作ってください。
 
出力:
1. 見出しごとに、使う発言のIDを並べる
2. 事例フォーマットの必須項目のうち、文字起こしに材料が無いものを列挙する
3. 数字(件数、金額、期間、割合)が出てきた発言のIDと、その数字の文脈
4. 発言どうしで食い違っている箇所があれば、両方のIDを示す
 
本文はまだ書かないでください。

返ってきた「材料が無い必須項目」は、顧客への追加質問の元になります。導入の時期、対象人数、比較した他の選択肢など、フォーマットが求める項目が文字起こしに無いことは珍しくありません。この段階で見つけておけば、本文が出来上がってから「この数字の出どころが無い」と戻るより、手戻りが小さく済みます。

数字の文脈で、成果の書き方を決める

導入事例の核になるのは成果の数字です。文字起こしの数字は、話し言葉のため文脈が抜けていることがあります。「3割減った」が、作業時間なのか件数なのか、導入前後のどの期間の比較なのかは、前後の発言を読まないと決まりません。

構成案の項目3で出てきた数字のうち、比較の基準(何と何を比べたか)が発言の中で言い切られていないものは、すべて [要確認] に回します。本文に書く表現も、顧客が発言した範囲に合わせます。「約3割減った」と話した数字を「30%削減」と書き換えると、精度が上がったように見えますが、顧客の言っていない主張になります。

手順3: 本文を書かせる

構成案に手を入れたら、本文の下書きを依頼します。1度に全部を書かせず、見出し単位で区切ると修正が楽です。

承認した構成案の「導入の決め手」の節を書いてください。
 
- 地の文は事例フォーマットの文体に合わせる
- 顧客の引用は、文字起こしの原文のまま、発言IDを括弧で添える
- 数字は発言どおりの表現で書き、換算や言い換えをしない
- 材料が足りない箇所は [要確認: …] を本文の中に残す

下書きに [要確認] が残っているのは、うまく動いている印です。逆に1つも残らないときは、材料に無い内容で埋めている可能性があります。引用が原文と一字違わないかは、画面の見た目では判断できません。照合は、IDの行を引いて比べる作業になります。

手順4: 掲載確認シートを作る

本文の下書きができたら、顧客に回す確認シートを作らせます。ここで効くのが、確認項目を種類で分けることです。顧客の担当者が答えるべき質問と、自社の法務や広報が決める事項が混ざっていると、返事が遅れます。

確認項目は、次の4種類に分けると整理しやすくなります。

分類ごとに、本文から該当箇所をClaudeに拾わせます。

本文の下書きを読み、顧客に確認してもらう項目を表にしてください。
 
列: 分類 / 本文の該当箇所 / 根拠の発言ID / 顧客への質問文 / 回答欄
分類は「発言」「数字」「名称」「公開範囲」の4つです。
 
- 引用符で囲んだ文は、すべて「発言」に入れる
- 数字は、単位と比較の基準を質問文に含める
- 社名、部署、肩書き、人名が出た箇所は、すべて「名称」に入れる
- 本文に出てこない項目でも、事例の公開で必要になるもの
  (媒体、写真・ロゴ、掲載期間)は「公開範囲」に入れる
- 質問文は、はい・いいえ、または数字の修正で答えられる形にする

出力のイメージは次のような表です(以下の内容は例示用の架空のものです)。

質問文を「はい・いいえ」か数字の修正で答えられる形にしておくのは、顧客の負担を減らすためです。「内容をご確認ください」だけでは、何を見ればよいのかが伝わりません。

「確認」と「許諾」は別の作業

顧客に聞く内容は、2種類の性質が混ざっています。

• 事実の確認: 数字や発言が実際と合っているか。担当者の社内データや記憶で答えられる
• 掲載の許諾: 社名や人名、写真を、どの媒体で、いつまで載せてよいか。顧客の組織としての判断で、広報や法務の承認が要る場合がある

後者は、担当者が個人の判断で「いいですよ」と答えても、社内の承認が通っていないことがあります。許諾のシートは、顧客側の承認者を確認する欄を設け、回答日と回答者を記録するのが実務的です。

Claudeに法的な判断を任せないでください。契約書に掲載に関する条項があるか、肖像や個人情報の扱いが規程と合っているかは、自社の法務に見てもらう領域です。個人情報の入力全般は、Claudeに個人情報を入力する前に確認する一次資料に一次資料を整理しています。

社内で共有するときの設定

広報とセールス、営業企画の複数人で事例を回すなら、プロジェクトを共有します。ただしこれはTeamまたはEnterpriseプランの機能で、個人プランのプロジェクトは共有できません。

共有の設定で押さえる点は次のとおりです。

• 作成時の公開範囲は、組織全体に公開するか、招待した人だけの非公開かを選びます。顧客の文字起こしを置くなら、非公開が合います
• 権限は「Can view」(閲覧とチャットのみ)と「Can edit」(指示や知識の編集も可)の2段階です
• 組織に公開したプロジェクトでも、プロジェクト内の自分のチャットは、手動で共有しない限り他のメンバーに見えません
• 非公開から公開、公開から非公開への切り替えは、共有ボタンの「General access」からいつでも行えます
• 管理者がプロジェクトの共有をオフにしている組織では、共有できません

事例の公開前の下書きと確認シートは、顧客の発言が詰まった内部資料です。編集権限を持つ人を最小限にし、広報以外には「Can view」にとどめる運用が考えられます。

公開後の片付けと、次の事例への再利用

顧客の承認を受けた最終稿が出来たら、次の2つを行います。

1. 承認済みの事例だけを、次の事例の「見本」としてプロジェクトに追加します。承認前の下書きは見本にしません。顧客の修正前の言い回しが、次の事例に混ざるのを避けるためです
2. 文字起こしを預けたプロジェクトの扱いを決めます。保管期間を契約や社内規程で定めているなら、期間が過ぎた時点で削除します

削除に関する仕様として、ヘルプセンターには、アーカイブしたプロジェクトは削除できず、先にアーカイブを解除する必要があると書かれています。「あとで消すつもりで」アーカイブだけしていると、削除ボタンが出ません。保管の要否は、アーカイブする前に決めておきます。

よくある失敗と見分け方

事例記事で起きやすい誤りは、読みやすさの調整の途中で入り込みます。

導入事例の数字は、そのまま営業資料や広告に転用されることがあります。数字の裏取りを顧客側の担当者に回す工程を、省略しないでください。

まとめ

導入事例づくりでClaudeが役立つのは、文章の清書よりも「どの文に、どの発言の根拠があるか」を一覧にする作業です。IDを付けた材料から本文と確認シートを同時に作れば、顧客は短いシートを見るだけで、事実の確認と掲載の判断を分けて返せます。

Claude自身の導入事例を読み比べたいときは、Claude導入事例まとめが参考になります。事例を材料にした長尺資料へつなぐなら、Claudeでホワイトペーパーの構成を作成する手順が続きの手順です。