損害保険の損害調査で、現地の立会いで話した内容を音声で記録して文字にし、事故状況・損傷箇所・聞き取りを調査報告書の項目に分けて下書きする

処理の起点を決める

調査担当がアプリで「立会い終了」を押し、音声が送られたことを起点にします。 音声には、アプリで選んだ案件番号と、立会いの間に撮った写真の撮影時刻の一覧を付けます。案件番号を付けて送るので、どの事故の立会いかを音声から推し量る必要がありません。

録音はスマートフォンの中に保存してから送ります。山間部や電波の弱い場所の立会いでも、録音だけは確実に残せるようにするためです。送れなかった音声は、電波の戻った場所で自動で送り直します。

1件の立会いは1つの音声にします。 途中で止めて撮り直すと音声が分かれますが、アプリの側で同じ案件の音声をつなげてから送ります。分かれたまま送ると、事故状況と損傷箇所が別の下書きになります。

入力データを集める

質を決めるのは、2行目と4行目です。 写真の撮影時刻が無ければ、写真と記述を対応させられません。語句の一覧が無ければ、「破風板」「鼻隠し」「棟板金」のような部位名が、別の言葉として文字になります。

受付時の申告の内容も渡します。 ただし下書きに写すためではありません。受付のときの申告と立会いでの話が違っていれば、それを調査担当に知らせるためです。違いがあること自体は誤りではなく、調査担当が確かめる材料です。

データの取得方法を決める

文字起こしは、中継の処理から高速文字起こしの API を呼びます。locales に ja-JP を指定し、話者の区別と phraseList を付けます。 フレーズリストは API バージョン 2025-10-15 以降で使えます。

写真との突き合わせは、時刻だけで行います。 音声の開始時刻に文の offsetMilliseconds を足すと、その文が話された時刻になります。撮影時刻の前後の数十秒に「写真」と読み上げた文があれば、その文の損傷箇所にその写真を当てます。 この突き合わせに生成AIは使いません。

呼び出しが混み合ったときの扱いも決めておきます。 公式の手引きでは、HTTP 429 と 500・502・503・504 を再試行の対象に挙げています。台風の後は同じ時間帯に多くの音声が送られるので、 中継の処理で間隔を空けて再試行し、それでも返らなければ控えの音声を後で処理する列に回します。

AIへ渡す前に整形する

1. 形式と長さの確認 … 5時間未満・500MB未満で、WAV、MP3、OPUS/OGG、AAC、WebM などの形式であることを確かめます
2. モノラルにそろえる … 話者の区別はモノラルの音声で使うため、アプリの録音をモノラルに設定します
3. 語句の一覧を組み立てる … 部位名の一覧（会社で共通）に、所在地の地名と被保険者の氏名、建物の構造の呼び方を足します。2,000語句を超えないようにし、 長いほど品質と待ち時間に影響するとされているので、部位名は建物の種類ごとに絞ります
4. 話者の上限を決める … 受付内容から、立会いに同席する人数（被保険者、家族、管理会社、修理業者）を見て maxSpeakers を決めます
5. 録音の了承の部分を確かめる … 冒頭の数十秒に、了承を得た発話があるかを文字起こしで確かめます

5番目は、下書きを作る前に止める仕組みです。 了承の発話が見つからない音声は、下書きを作らずに調査担当へ戻します。了承が録音に残っていないまま会話を文字にして報告書に使うことはしません。 了承を口頭で得て録音の前に済ませた運用なら、アプリで「了承を得た」を押してから録音を始める作りにします。

AIに処理させる

させるのは、文字起こしの文を報告書の項目に振り分け、項目ごとに区分と根拠の文の番号を付けることだけです。

区分を3つに分けるのが、この構成でいちばん大事な点です。 insured_statement は被保険者が話したこと、adjuster_observed は調査担当が見て確かめたこと、adjuster_opinion は調査担当の意見です。同じ「雨樋が外れている」でも、被保険者が言ったのか、調査担当が見て読み上げたのかで、報告書での重みがまったく違います。

分ける材料は話者の区別と、読み上げの決まり文句です。 調査担当は「写真」「所見」と前置きして話す決まりにし、話者の番号と前置きの両方がそろった文だけを調査担当の確認として扱います。

話者の番号は、立会いごとに振り直されます。 同じ調査担当でも、ある立会いでは speaker 0、別の立会いでは speaker 1 になることがあります。どの番号が調査担当かは、冒頭の了承を求める発話をした話者として処理の側で決め、 プロンプトに渡します。

4行目がいちばん起きやすい失敗です。 被保険者が「屋根の瓦が10枚くらい飛んだ」と言い、調査担当が「はい」と相づちを打つと、相づちを確認と読んで adjuster_observed にすることがあります。 相づちは確認ではありません。

指示内容を固定する

あなたは損害保険の損害調査で、立会いの記録から調査報告書の下書きを作る担当です。
文字起こしの文だけを見て、報告書の項目に振り分けてください。

【話者】
speaker {adjuster_speaker} が調査担当です。それ以外は被保険者または同席者です。

【区分の選び方】
- insured_statement .. 被保険者または同席者が話したこと
- adjuster_observed .. 調査担当が「写真」と前置きして、見た状態を読み上げたこと
- adjuster_opinion ... 調査担当が「所見」と前置きして話したこと
- discrepancy ........ 受付時の申告と、立会いでの話が違う点
迷ったときは insured_statement を選んでください。

【厳守事項】
- 話されていないことを書かないでください。推測で補わないでください。
- 寸法・枚数・日時は、話された言葉どおりに写してください。
  「くらい」「たぶん」などの言葉も省かないでください。
- 調査担当の「はい」「なるほど」などの相づちを、確認として扱わないでください。
- 損害の原因、保険の対象になるか、損害の額は書かないでください。
- 信頼度が 0.6 未満の文を使った項目は low_confidence を true にしてください。
- すべての項目に、根拠にした文の番号を evidence_phrase_ids に入れてください。
- 受付時の申告は、違いを見つけるためだけに使ってください。下書きに写さないでください。

【受付時の申告】{intake_summary}
【文字起こし（番号・話者・時刻・信頼度・文）】{phrases}

「迷ったら insured_statement」にしているのは、誤ったときの害の大きさが違うからです。 被保険者の申告を調査担当の確認と誤ると、確かめていないことが確認済みとして査定に回ります。逆に確認を申告と誤っても、調査担当が直すだけで済みます。 迷ったときは害の小さいほうに倒します。

「くらい」「たぶん」を省かないのも同じ理由です。 「10枚くらい」が「10枚」になると、申告の確かさが下書きの中で上がってしまいます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 スキーマのすべての項目を必須にし、additionalProperties: false を付けます。値の無い項目は null を許す型にします。

{
  "claim_no": "",
  "incident": [
    { "text": "", "category": "insured_statement",
      "evidence_phrase_ids": [], "low_confidence": false }
  ],
  "damages": [
    { "part": "", "condition": "", "extent": "",
      "category": "adjuster_observed", "photo_nos": [],
      "evidence_phrase_ids": [], "low_confidence": false }
  ],
  "interview": [
    { "topic": "previous_repair | previous_damage | repair_quote | other",
      "text": "", "category": "insured_statement",
      "evidence_phrase_ids": [], "low_confidence": false }
  ],
  "opinions": [],
  "discrepancies": []
}

photo_nos はAIが埋めず、処理が写真の撮影時刻から埋めます。下書きの画面では、たとえば次のように出します。

1つ目の理由は、区分が画面の色分けにそのまま使えることです。 調査担当は、申告と確認が混ざっていないかを色で見ます。自由文で受け取ると、区分を読み取る作業がもう一度人に戻ります。

2つ目は、根拠の文に戻れることです。 evidence_phrase_ids から文字起こしの文と、その時刻の音声に飛べるので、下書きの1行が本当にそう話されたかを、録音を聞き直して確かめられます。

システムへ連携する

案件管理の仕組みへの書き込みは、調査担当が確定した後の1回だけにします。 下書きの段階では書き込みません。AIの出力が確定前に査定の担当の目に触れると、下書きが報告書として読まれてしまいます。

人が確認する

調査担当は、下書きの全項目を確かめます。 第5章で書いたとおり、確かめなくてよい項目はありません。確かめる順番を決めておくと、時間が短く済みます。

1. discrepancy を先に見る … 受付時との違いは、所見に関わることが多いからです
2. adjuster_observed の項目と写真を見比べる … 写真の番号が合っているか、寸法が読み上げたとおりかを見ます
3. insured_statement が確認として書かれていないかを見る … 色分けで、申告の項目が確認の色になっていないかを見ます
4. low_confidence の項目は録音を聞き直す … 根拠の文の時刻から再生します
5. 所見を書き足して確定する … 下書きの所見は前置きした部分だけなので、調査担当が判断を書き足します

3番目を省かないでください。 区分の誤りは、読み流すと気づきません。報告書を受け取った査定の担当は、区分を信じて読みます。

下書きを直すのは、調査担当本人に限ります。 立会いに行っていない人が下書きを直すと、録音を聞き直しても現地の状態は分かりません。休みなどで本人が確かめられないときは、確定を待つ運用にします。

目標は、240件をならして1件15分です。 立会いの直後か当日のうちに下書きを開けるので、記憶が新しいうちに確かめられることが、時間の短さにつながります。

例外に対処する

2行目の運用を、最初から用意しておきます。 録音を断る被保険者は一定の割合でいます。断られたら構成が使えない、では運用に乗りません。 立会いの後に車の中で調査担当が要点を読み上げれば、会話の記録は残りませんが、損傷箇所と写真の対応は同じ仕組みで作れます。

記録を残す

• 立会いの音声と、案件番号・録音の日時・了承の記録
• 高速文字起こしが返したJSONの全文（話者・時刻・信頼度）
• 生成AIが返した下書きのJSONと、写真との突き合わせの結果
• 調査担当が直した項目と、直す前と後の値
• 確定した報告書と、確定した日時・確定した人
• 語句の一覧の版と、maxSpeakers の値

4つ目は、区分の誤りの傾向を見るために残します。 調査担当が insured_statement を adjuster_observed に直した、またはその逆が多い場合、読み上げの決まり文句が守られていないか、プロンプトの区分の説明が足りていません。

音声の保存期間は、報告書と同じにするとは限りません。 報告書が確定した後に音声をどれだけ残すかは、社内の規程と被保険者に伝えた扱いに合わせて決めます。