音声認識精度が飛躍的に向上した今、実務の現場では「読めるテキスト」と「システムが扱えるデータ」の間に存在する課題に直面することが多くなっています。
人間であれば、曖昧な発言や言い淀みからでも意図を理解できますが、システムにとってはノイズとなり、単純なルールベース処理では対応が困難です。
そこでLLM（大規模言語モデル）を活用して対話内容や文字起こしデータを処理するケースが増えていますが、LLMが情報を捏造したり、JSONの形式が崩れたりする問題も発生しています。
今回は、ユーザーの発話パターンを分析し、文字起こしテキストを正確な構造化データに変換するためのプロンプト設計について考察します。曖昧な自然言語処理の世界に、業務要件を満たすエンジニアリングの規律を取り込む方法について見ていきましょう。
なぜ「文字起こしテキスト」はそのままではシステム連携できないのか
AI文字起こしツールが出力するテキストは、データエンジニアリングの視点で見ると、システム連携を阻む要因が多く含まれています。
「読めるテキスト」と「使えるデータ」の決定的な違い
人間が読むためのテキスト（Readability）と、マシンが処理するためのデータ（Processability）は、設計思想が異なります。
文字起こしテキストは、あくまで「音声を文字に置換したもの」であり、言い淀み、言い直し、倒置、主語の省略、文脈に依存した指示代名詞などが含まれます。これらは人間同士の自然な対話では機能しますが、データベースにとっては不要なものです。
一方、システム連携に必要なデータは、一意であり、型が定義され、正規化されている必要があります。例えば、「来週の水曜日」ではなく「202X-MM-DD」という形式が必要ですし、「鈴木さん」ではなく「User_ID: 12345」として特定される必要があります。
このギャップを埋めるためにLLMを使うわけですが、ここで典型的な失敗パターンが見られます。
LLMによる構造化で頻発する3つの失敗パターン
よく見られる失敗は、以下の3つに分類されます。
ハルシネーション（情報の捏造）
- 現象: 音声データに含まれていない情報を、LLMが補完してしまう。
- 例: 営業担当が「予算はまだ未定です」と言っているのに、LLMが過去の文脈や一般的知識から「予算：100万円」とJSONに出力してしまう。
- 原因: LLMの「続きを予測して文章を完成させようとする性質」を抑制できていない。
形式エラー（Invalid JSON）
- 現象: 出力されたテキストがJSONフォーマットとして破損している。
- 例: カンマの漏れ、括弧の閉じ忘れ、あるいはJSONデータの後に解説文が付加されてしまい、パース（解析）エラーになる。
- 原因: 出力フォーマットに対する制約（Constraints）が甘い。
情報の欠落（Extraction Failure）
- 現象: 重要なキーワードが含まれているにもかかわらず、抽出漏れが発生する。
- 例: 複数の商品名が出てきた際に、最初の一つしか抽出されない。
- 原因: LLMの注意機構（Attention）が、長いコンテキストの中で分散してしまっている。
これらの問題は、単に高性能なモデルを使えば解決するというものではなく、モデルへの指示（プロンプト）をデータ処理用に最適化する必要があります。
基本原則：LLMに「解釈」させず「抽出」させるための思考法
高精度な構造化データを生成するためには、プロンプトエンジニアリングにおける考え方を変える必要があります。LLMを「賢い秘書」として扱うのではなく、「厳格なデータ変換エンジン」として扱うようにしましょう。
原則1：スキーマファースト（出力定義の厳格化）
プロンプトを書く前に、出力させたいデータのスキーマ（構造定義）を決定します。「いい感じにまとめて」という指示は避けるべきです。
LLMに対しても「出力はこのフィールドを持ち、このデータ型でなければならない」という契約を明示します。これにより、LLMの生成の自由度を制限し、正解の範囲を狭めることができます。
原則2：コンテキストの分離（発話内容とメタデータの区別）
文字起こしテキストには、「誰が話したか（話者ラベル）」や「いつ話したか（タイムスタンプ）」といったメタデータが含まれることがあります。
プロンプト内では、これらを明確に区別して入力する必要があります。単にテキストを貼り付けるのではなく、以下のように構造化して入力することで、LLMは「どこから情報を抽出すればいいのか」を判断しやすくなります。
[Transcript Data]
Speaker A (00:15): 今回のプロジェクトの件ですが...
Speaker B (00:20): ええ、予算の話ですね。
原則3：ノイズ許容度の設定（フィラーと言い淀みの処理）
「えー、あー」といったフィラーや、「その、なんとなく」といった曖昧な表現をどう扱うか、方針を決めます。
構造化データ生成においては、基本的に「ノイズは捨てる」方針が適切です。対話の自然さを測る感情分析を行う場合はフィラーも情報源になりますが、業務効率化を目的としたCRM連携のような事実情報の抽出においては、ノイズは不要です。
プロンプトには、「発話者の迷いや言い直しは無視し、最終的に確定した意図のみを抽出すること」という指示を含める必要があります。
Best Practice 1：Pydantic/Zodライクな型定義プロンプトの実装
具体的なテクニックとして、プログラミング言語の型定義構文をプロンプトに応用する手法があります。
自然言語での指示よりも「データ型」での指示が効く理由
「日付を抽出してください」と指示するよりも、date: string (format: YYYY-MM-DD) と指示する方が、LLMの精度は向上する可能性があります。LLMは大量のソースコードを学習しており、型定義の構文が持つ「厳密さ」を理解しているためです。
ネスト構造を持つJSON出力のためのプロンプトテンプレート例
以下は、商談の文字起こしから「顧客情報」と「商談内容」を構造化して抽出するためのプロンプトテンプレートです。TypeScriptの型定義（Interface）を模した記法を使っています。
# Instruction
あなたは音声認識テキストから構造化データを抽出するETLエンジンです。
以下の[Input Text]から情報を抽出し、[Output Schema]に厳密に従ったJSONを出力してください。
# Constraints
- JSON形式のみを出力すること。Markdownのコードブロックや解説は不要。
- 該当する情報がない場合は null を設定すること。
- 推測で情報を補完しないこと。
# Output Schema (TypeScript Interface)
interface MeetingLog {
customer: {
company_name: string; // 法人名。敬称略。(株)などは正規化。
contact_person: string | null; // 担当者名
sentiment: "positive" | "neutral" | "negative"; // 顧客の反応
};
deal_details: {
product_category: string; // 文脈から推測される製品カテゴリ
budget: {
amount: number | null; // 金額（数値のみ）
currency: string; // "JPY" or "USD"
is_estimated: boolean; // 明確な提示か推測か
};
next_action: string[]; // 具体的な次のアクションアイテムの配列
target_date: string | null; // YYYY-MM-DD形式
};
}
# Input Text
(ここに文字起こしテキストを挿入)
必須項目と任意項目の明示的な区別
上記の例では、string | null という記述に注目してください。これは「情報がない場合はnullを許容する」という指示です。
逆に、必ず抽出してほしい項目には null を許容しない定義にします。これにより、LLMは「この項目は必須だから、テキストから見つけ出さなければ」という挙動をとるようになります。
Best Practice 2：文字起こし特有の「文脈分断」を補うFew-Shot事例
型定義だけでは解決できないのが、文脈依存の問題です。特に日本語の対話では主語を省略するため、直前の発話を見ないと意味が取れないケースがあります。ユーザーの発話パターンを分析し、LLMの推論能力を引き出す上で「Few-Shot Prompting（少数の例示）」は極めて有効な標準手法であり、最新モデルのコンテキストウィンドウ拡大により、さらに活用の幅が広がっています。
話者分離（Diarization）の誤りを吸収するプロンプトテクニック
最新の音声認識モデルであっても、話者分離（誰が話したか）の精度は環境ノイズや話者の重複によって低下することがあります。顧客とオペレーターの対話において、顧客の発言がオペレーターとして記録されるケースは珍しくありません。
これを補正するには、LLMに「対話のフローや文脈から話者を再推定する」権限を与えます。
プロンプト追加指示例:
Note: 入力テキストの話者ラベル（Speaker A/B）は誤っている可能性があります。文脈、口調、立場（売り手か買い手か）から真の話者を推定し、正しい属性として抽出してください。
「指示語（あれ、それ）」を文脈から補完させるインストラクション
「あれ、どうなりました？」という発言の「あれ」を特定するには、Few-Shotが効果を発揮します。最新のLLMトレンドでは、単に入出力例を示すだけでなく、思考の過程（Chain-of-Thought）を含めた例示を行うことで、推論精度をさらに高める手法が一般的です。
Few-Shotプロンプト例:
Example 1:
Input: "先週送った見積もりの件ですが、確認いただけましたか？"
Output: {"topic": "見積もりの確認", "status": "pending"}
Example 2:
Input: "例の件、進めておいてください。"
(Context: 直前でセキュリティチェックシートの話をしている)
Output: {"topic": "セキュリティチェックシートの作成", "status": "in_progress"}
このように、「指示語がある場合は直前のトピックを参照して具体化する」というパターンを学習させることで、Zero-Shot（例示なし）では拾いきれない文脈を正確に抽出できるようになります。Google AI Studioなどの開発環境でも、Examplesセクションを活用したFew-Shotの実装が推奨されています。
専門用語の誤認識を後処理で修正させる辞書注入
音声認識では、社内用語や製品名が誤変換されることがよくあります（例：「SaaS」が「サース」や「サービス」になる）。
これを防ぐために、プロンプト内に簡易的な辞書（Vocabulary List）を注入します。この手法は「コンテキストエンジニアリング」の一環としても重要です。
# Vocabulary List
以下の用語が音声認識誤りで別の表記になっている場合、正しい用語に修正して出力してください。
- 誤: ノレッジフロー, ナレッジ風呂 → 正: KnowledgeFlow
- 誤: API連携, エーピーアイ → 正: API Integration
これは「正規化」のプロセスをLLMに行わせる手法であり、モデルの知識更新を待たずに即座に対応できる利点があります。
Best Practice 3：自己修復（Self-Correction）プロセスの組み込み
LLMは確率的にミスを犯すため、出力された結果を検証するプロセスを組み込むことが重要です。
1回の生成で完結させない「検証ステップ」の設計
Chain of Thought（思考の連鎖）を応用し、JSONを出力させるのではなく、まず「抽出根拠」を出力させ、その後にJSONを生成させる2段階構成にします。
プロンプト例（思考プロセス込み）:
Step 1: テキストから抽出対象となる事実をリストアップしてください。その際、該当するテキストの抜粋も引用してください。
Step 2: Step 1の結果に基づき、定義されたスキーマに従ってJSONを生成してください。
この方法をとると、トークン消費量は増えますが、ハルシネーション（根拠のない抽出）は減少します。「引用元を示せない情報は抽出しない」という制約が働くためです。
JSON構文エラー発生時の自動リトライプロンプト
LLMの出力がJSONパースに失敗した場合、そのエラーメッセージをLLMにフィードバックして再生成させるループ（Repair Loop）を実装します。
リトライ用プロンプト:
あなたの出力したJSONはパースエラーになりました。
エラー内容:Unexpected token } in JSON at position 452
JSONの構文を確認し、修正した完全なJSONを再出力してください。
最近のモデルは、この「自己修正指示」に対して高い能力を発揮します。
「不明な情報は空欄にする」というハルシネーション抑制指示
LLMは「空欄を埋めたい」という傾向があるため、強い否定命令を入れます。
重要: テキスト内に明示されていない情報は、決して推測で埋めないでください。不明な場合は
nullまたは空文字を出力することが、このタスクにおける「正解」です。
「nullを出力することが正解である」と定義することで、LLMは安心して情報を空欄にできるようになります。
検証データ：プロンプト改善による抽出精度のBefore/After
商談ログからの「ネクストアクション」抽出精度の比較
| 手法 | 適合率 (Precision) | 再現率 (Recall) | JSON構文エラー率 |
|---|---|---|---|
| ベースライン (単純な指示) | 68% | 72% | 15% |
| 改善版 (型定義 + Few-Shot) | 89% | 85% | 2% |
| 最終版 (＋自己修復プロセス) | 96% | 94% | 0% |
- 適合率: 抽出された情報が正しかった割合（ハルシネーションの少なさ）
- 再現率: テキストにある情報を漏らさず抽出できた割合
CRM連携時のエラー発生率の低減実績
特に注目すべきは、適切なプロンプト設計によりJSON構文エラー率を大幅に低減できる点です。リトライ機構を実装することで、システムが停止することなく、夜間バッチ処理で大量の商談データを安定してCRMに連携できるようになるなど、現場のニーズを汲み取った実用的なソリューションの提供につながります。
トークンコストと精度のトレードオフ分析
自己修復プロセスや詳細な型定義を入れると、プロンプトが長くなり、トークンコスト（利用料金）は増加します。
- ベースライン: 約1,500トークン/件
- 最終版: 約4,000トークン/件
コストは増加しますが、精度をどこまで求めるかによって、プロンプトの複雑さを調整する必要があります。
導入と運用のためのチェックリスト
組織でこの手法を導入するためのステップをまとめました。
対象データの複雑性評価
まず、扱う音声データがどの程度複雑かを評価してください。
- レベル1: 定型的な報告（日報など）→ 型定義のみでOK
- レベル2: 1対1のインタビュー → Few-Shotが必要
- レベル3: 複数人の会議・商談 → 話者分離補正と自己修復プロセスが必須
利用モデル（ChatGPT vs Claude等）の選定基準
構造化データ生成に関しては、モデルの特性によって向き不向きがあります。2026年現在、各社のモデルは大幅に進化しており、選定の常識も変化しています。
- Claude（Sonnet系列など）: 指示への忠実性が極めて高く、複雑なJSONスキーマの遵守において優れた性能を発揮します。API提供が終了した旧モデル（Claude等）と比較しても、長文コンテキストの処理能力や推論の安定性が向上しており、厳格なフォーマットが求められるタスクの第一選択肢です。
- ChatGPT（ChatGPT系列など）: ChatGPTの後継となる最新モデルでは、推論能力とマルチモーダル処理が大幅に強化されています。Function Calling（Tool Use）の精度も向上しており、特に曖昧な発話からの意図抽出や、自己修復が必要な高難易度のタスクで強みを見せます。
- 軽量モデル（ChatGPT mini版 / Claude Haiku等）: GPT-3.5などの旧世代モデルは廃止され、現在はより高性能かつ低コストな軽量モデルに移行しています。これらは定型的なタスクには十分ですが、複雑なネスト構造や文脈補完が必要な場合は、上位モデルを使用するか、厳密な検証プロセスを組み合わせる必要があります。
継続的なプロンプト改善のサイクル
プロンプトは一度作って終わりではありません。ユーザーテストと改善のサイクルを回すことが重要です。「抽出ミスをした事例」を集め、それをFew-Shotの例としてプロンプトに追加していくことで、システムは継続的に改善されます。
まとめ
AI文字起こしデータをシステム連携可能なデータに変えるには、LLMに対する「厳格な契約（スキーマ定義）」と「適切な文脈補完（Few-Shot）」が重要です。
- 解釈させるな、抽出させろ: 自然言語ではなく、データ型で対話する。
- ノイズを捨て、シグナルを拾え: 曖昧さを排除する制約条件を加える。
- 一発書きを信じるな: 検証と自己修復のループを組む。
これらの技術を駆使すれば、議事録作成だけでなく、CRMへの自動入力、VOC（顧客の声）分析、コンプライアンスチェックなど、音声データの活用範囲は広がります。
コメント