商談の文字起こしから営業日報を自動作成する方法

処理の起点を決める

Teams会議の終了、より正確には文字起こしファイルが生成されたことを起点にします。

会議終了と文字起こしの生成には時間差があるため、「会議終了」を直接のトリガーにすると、まだ存在しないデータを取りに行って失敗します。実装では次のどちらかを取ります。

• 会議終了の15分後にワークフローを開始する（遅延を入れる）
• 文字起こしを保存する専用のSharePointフォルダを監視し、Power Automateの「ファイルが作成されたとき」トリガーで開始する

後者のほうが確実です。SharePointコネクタの「ファイルが作成されたとき」は標準のトリガーとして提供されています。

入力データを集める

AIへ渡すのは次の3つです。

文字起こしだけを渡すと、AIは「株式会社◯◯さん」という発言から顧客名を推測しようとします。CRM側にある確定情報を一緒に渡すことで、推測させる余地を減らします。

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

文字起こし： Microsoft Graph の GET /users/{userId}/onlineMeetings/{meetingId}/transcripts で会議の文字起こし一覧を取得し、GET /users/{userId}/onlineMeetings/{meetingId}/transcripts/{transcriptId}/content で本文を取得します（v1.0で提供）。

ここには2つの制約があります。

• カレンダーに予定として存在する会議のみが対象です。その場で立ち上げたアドホック会議の文字起こしはGraphから取れません
• テナント管理者がGraph経由の文字起こしアクセスを止めている場合、403が返ります。この場合、依頼側で解除してもらう以外の回避策はありません

自社環境でこの2点を先に確認してください。取得できない環境では、Teamsの文字起こしを手動でSharePointへ保存する運用に切り替え、フォルダ監視をトリガーにします。

案件情報： Salesforce REST API の sObject エンドポイントで、会議の参加者メールアドレスまたは会議件名に含まれる案件番号から該当レコードを引きます。会議と案件を確実に紐づけるには、会議の件名に案件番号を入れる運用ルールを先に作るのが早道です。ここを自動判定に頼ると、同名顧客の別案件を取り違えます。

AIへ渡す前に整形する

そのまま渡すと精度が落ちるため、3つの処理を入れます。

1. 不要部分の除去 … 冒頭の挨拶、接続確認（「聞こえますか」）、雑談を削る。単純に先頭2分・末尾1分を落とすだけでも効きます
2. 長い商談の分割 … 60分の商談は文字起こしで2万字を超えます。入力上限に収まる場合でも、長すぎると後半の情報が抜けやすくなります。20分ごとに分けて抽出し、最後に統合する構成にします
3. 固有名詞の補正 … 自社の製品名、競合名、業界用語の誤変換を、置換辞書で直します。「デボノ」が「デ・ボーノ」になるといった誤りは、辞書を用意すれば潰せます

AIに処理させる

「要約して」ではなく、抽出する項目を指定します。

指示内容を固定する

あなたは法人営業の商談記録を整理する担当者です。
以下の商談の文字起こしから、指定された7項目を抽出してください。

【厳守事項】
- 文字起こしに明記されていない内容は推測しないでください。
  該当する発言がない項目は "不明" と記入してください。
- 金額、日付、社名、役職は、発言にあった通りに記載してください。
  言い換えや概算への変換をしないでください。
- 顧客の発言と自社担当者の発言を区別してください。
  「顧客課題」「要望」「予算」には、顧客側の発言のみを反映してください。
- 推測が混ざった箇所には、末尾に「（要確認）」を付けてください。

【案件情報】
案件ID: {opportunity_id}
顧客名: {account_name}
現在フェーズ: {stage}

【文字起こし】
{transcript}

「明記がなければ不明とする」という制約が、この構成でもっとも重要な1行です。 これを書かないと、AIは「予算の話は出ていないが、規模から見て500万円程度と思われる」といった内容を、事実のように書きます。CRMに入ってしまえば、後から見た人は本人が聞いた情報だと受け取ります。

出力形式を固定する

自由文ではなく、項目が固定されたJSONで返させます。CRMの入力欄は決まった数・決まった名前で存在するため、自由文で返されると、後段で「どこからどこまでが顧客課題か」を切り出す処理が必要になり、そこが壊れやすくなるからです。

{
  "customer_issue": "",
  "customer_request": "",
  "budget": "",
  "decision_maker": "",
  "competitor": "",
  "action_items_ours": "",
  "next_action": "",
  "next_action_due": "",
  "confidence_note": ""
}

Claude API には Structured Outputs（JSON Schemaを指定すると、その形式に沿った出力だけが生成されるよう制約をかける仕組み）が提供されています。スキーマを渡す方式と、ツール定義を使う方式の2通りがあります。同種の機能は他社のLLM APIにもあります。これを使うと、項目名の揺れや、JSONとして壊れた出力による処理落ちがなくなります。

confidence_note は、AIが判断に迷った箇所を書かせる欄です。確認する人が、どこを重点的に見ればよいか分かります。

システムへ連携する

承認後、JSONの各項目をCRMの対応する入力欄へ書き込みます。

HubSpotの場合は PATCH /crm/v3/objects/{objectType}/{recordId} に properties を渡します。自社で決めた一意のIDで更新したい場合は、hasUniqueValue を立てたプロパティを作り、クエリパラメータ idProperty にその名前を指定すると、HubSpotの内部IDを知らなくても更新できます。

CRM側の項目を先に作っておく必要があります。 既存の「備考」欄に全部流し込む構成にすると、検索も集計もできず、日報を書く手間が減っただけで終わります。この構成の価値は、7項目が別々の欄に構造化されて入ることにあります。

人が確認する

初期運用では全件を人が確認します。生成結果をTeamsのチャネルへ投稿し、営業担当が承認ボタンを押した内容だけがCRMへ入る形にします。

3か月ほど運用して誤抽出率を測ったうえで、段階的に自動化を進めます。

金額と決裁者は自動化しないことを推奨します。 この2項目は誤りが商談の判断そのものを狂わせるうえ、誤っていても後から気づきにくいためです。

例外に対処する

記録を残す

次の3つを残します。営業活動の記録は、後から「なぜこの判断をしたか」を確認する対象になるためです。

• 入力した文字起こし（またはその保存先へのリンク）
• AIの出力JSON（承認前の生の状態）
• 承認者、承認日時、修正された箇所

修正箇所のログは、プロンプト改善の材料にもなります。「予算だけ毎回直されている」と分かれば、その項目の指示文を見直せます。