結婚相談所のカウンセラーが入会面談の記録から会員のプロフィール文の下書きを Azure OpenAI で作り、禁止している表現と個人が特定できる記載を拾う

処理の起点を決める

カウンセラーが会員管理の仕組みで「下書きを作る」を押したときに動かします。 面談の記録を保存した瞬間に自動で動かす形にはしません。面談の直後は記録が途中のことが多く、書き足す前に下書きができてしまうからです。

書き直しのときは、同じボタンで「前のプロフィール文」も一緒に渡します。前の文の良いところを残し、新しい面談で出た話を足す指示に切り替えます。押すたびに1件ずつ動かし、同じ会員について前の下書きがあれば版を分けて残します。

入力データを集める

質を決めるのは、3つ目の「公開してよい項目の印」です。 入会のときに、職業や居住地をどこまでの粒度で載せるか、面談で話した事情のうち載せたいものがあるかを本人に聞いて書面に残し、会員管理の仕組みに印として写します。 印が無ければ、下書きは毎回いちばん粗い粒度で書かせます。

年収・学歴・身長などの数値の項目は渡しません。 これらは連盟の仕組みに提出書類で確かめた値を載せる欄があり、文章の中で数値を言い直すと、確かめた値と食い違うことがあるからです。

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

会員管理の仕組みから、会員番号を鍵に4つの項目を取り出します。 面談の記録は行ごとに番号を振って渡します。この行番号が、下書きの文ごとの根拠になります。

行番号は面談の記録とアンケートで頭文字を分けます。 面談の記録は M12、アンケートは Q3 のように振ります。カウンセラーが確認するとき、どちらの言葉を元にしたかが一目で分かります。

アンケートは本人の文章なので、誤字もそのまま渡します。 前処理で直すと、自己PRの言葉づかいを本人に寄せる材料が減ります。直すのは下書きの段階で、カウンセラーが本人に見せる前です。

会員管理の仕組みに外から読む口が無いときは、記録を書き出したファイルを決まった場所に置き、Azure Functions がそれを読む形にします。 その場合も、書き出すのは対象の会員1人分だけにします。

AIへ渡す前に整形する

1. 伏せ字 … 氏名、電話番号、住所、メールアドレス、SNSのアカウント名を、正規表現と会員の登録情報で照合して ［氏名］ のように置き換えます
2. 特定につながる語の印 … 一覧にある駅名・病院名・学校名・会社名に印を付けます。伏せずに印だけ付けるのは、2回目の呼び出しで「この語が文に残っていないか」を見せるためです
3. 行番号 … 面談の記録とアンケートを行に分け、番号を振ります
4. 公開の粒度の指示 … 印から「職業は業種まで」「居住地は都道府県まで」のような指示文を組み立てます
5. 長さの確認 … 面談の記録が長すぎるときは、書き直しなら直近の面談の分だけに絞ります
6. 数値の除外 … 年収・身長・体重などの数値の行を、渡す前に外します

1番目を生成AIにさせないのは、伏せ字の漏れを仕組みで防ぐためです。 氏名と連絡先は、プロフィール文には一度も要りません。要らないものは、最初から渡しません。

2番目の一覧は、店舗のある地域に合わせて作ります。 全国の駅名を入れると「本町」「中央」のような一般的な語まで当たります。一覧は会員が増えた地域から足し、半年に1回は当たった回数を見て、一度も当たらない語と当たりすぎる語を整理します。

5番目の書き直しの絞り込みには、理由がもう1つあります。 入会のときの記録と3か月後の記録では、本人の希望が変わっていることがあります。 古い記録を全部渡すと、もう望んでいない条件が下書きに戻ってきます。

AIに処理させる

させることは2つです。1つ目は下書きを作ること、2つ目は下書きの中の気になる記載を拾うことです。 呼び出しを分けるのは、書いた本人に点検させると、自分の文を甘く読むからです。

「迷ったら拾う」を2か所に書いているのは、拾いすぎの損より見落としの損が大きいからです。 拾いすぎた記載はカウンセラーが数秒で外せますが、見落として掲載された記載は、他の相談所の会員にも読まれます。

2行目がいちばん起きやすい失敗です。 「料理が得意」と記録に無いのに、「家庭的な方です」と書きたくなるのが生成AIの癖です。書かれた長所が事実と違えば、お見合いの席で本人が困ります。

同意の要る記載の範囲は、個人情報保護委員会のガイドラインを目安にします。 ガイドライン（通則編）は、要配慮個人情報として人種、信条、社会的身分、病歴、犯罪の経歴、犯罪により害を被った事実、心身の機能の障害があることなどを挙げ、その取得には原則としてあらかじめ本人の同意が必要としています。相談所では、これらに加えて家族の介護や離婚の事情も「本人に確かめる」に入れます。

指示内容を固定する

1回目（下書き）のシステムの指示：

あなたは結婚相談所のカウンセラーを手伝う立場です。
面談の記録（M で始まる行）とアンケート（Q で始まる行）だけを材料に、
お見合いの仕組みに載せる自己PRと推薦文の下書きを作ってください。

【書き方】
- 自己PR：本人の一人称。アンケートの言葉づかいに寄せる。{pr_limit}字以内
- 推薦文：カウンセラーの視点。面談で見えた人柄を、具体的な出来事で書く。{rec_limit}字以内
- 1文ごとに、元にした行番号を source に入れる

【厳守事項】
- 行に書かれていないことを書かないでください。長所を足さないでください。
- 根拠の行が無い文は、書かずに missing_topics に話題の名前を挙げてください。
- 年収・学歴・身長・体重などの数値を書かないでください。
- 職業は「{job_level}」、居住地は「{area_level}」の粒度で書いてください。
  勤務先の名前、駅名、学校名、病院名を書かないでください。
- 病気、障害、信仰、家族の事情は、公開の印にあるものだけ書いてください。
  印に無ければ書かないでください。
- 相手の条件を断る書き方、他の人と比べる書き方をしないでください。
- 成婚の見込みや「理想の結婚相手」などの評価を書かないでください。

【公開の印】{consent_flags}
【面談の記録】{interview_lines}
【アンケート】{survey_lines}

2回目（拾う）のシステムの指示（要点）： 「下書きの文と、元の行を照らしてください。①文の組み合わせで本人が分かる記載、②病歴・障害・信仰・家族の事情で公開の印に無いもの、③元の行に書かれていない内容、④一覧で印を付けた語が残っているもの、を拾い、種類・該当の文・理由を書いてください。直し方の提案は書いてよいが、消すか残すかは決めないでください。迷ったら拾ってください」。

「行に書かれていないことを書かない」だけでは足りません。 生成AIは根拠の行番号を付けながら、その行を膨らませて書くことがあります。2回目の呼び出しで、行と文を突き合わせ直すのはそのためです。

出力形式を固定する

1回目は次の形のJSONで受け取ります。

{
  "self_pr": [
    { "text": "休日は友人とキャンプに出かけます。", "source": ["Q2", "M18"] }
  ],
  "recommendation": [
    { "text": "面談では、職場の後輩の相談に…", "source": ["M24"] }
  ],
  "missing_topics": ["結婚後の住まいの希望"]
}

2回目は次の形で受け取ります。

{
  "flags": [
    { "type": "identifiable | sensitive | unsupported | listed_term",
      "sentence": "",
      "reason": "",
      "suggestion": "" }
  ]
}

1つ目の理由は、文ごとに根拠を持たせられることです。 カウンセラーの画面では、下書きの文にマウスを重ねると元の行が出ます。根拠を確かめる時間が、記録を読み返す時間より短くなります。

2つ目は、type で確認の仕方を分けられることです。 identifiable と listed_term はカウンセラーが直し、sensitive は本人に確かめ、unsupported は面談で聞き直すか消します。

文字数はスキーマで縛れません。 公式のページでは、文字列の minLength・maxLength・pattern・format はサポートされないキーワードとされています。Azure Functions が文字数を数え、上限を超えたら「あと何字短く」と付けて1回だけ作り直します。 スキーマには最大100個のオブジェクトのプロパティ、入れ子は5段までという上限もあるので、文の配列は1段の深さに収めます。

システムへ連携する

会員管理の仕組みへの書き戻しは、下書きの欄だけにします。 掲載中のプロフィール文の欄には書きません。掲載している文と下書きを別の欄に置けば、確認の途中の文が掲載用の欄に入ることがありません。

デプロイの種類は、処理の場所で選びます。 Microsoft のデータとプライバシーのページでは、Global や DataZone の種類でなければ、プロンプトと応答は顧客が指定した地域（geography）の中で処理されるとされています。Global の種類は、そのモデルが展開されているどの地域でも処理されうるとされています。会員の面談の記録を扱うので、Global の種類は使わず、日本の地域の中で処理される種類にします。

人が確認する

カウンセラーは、拾われた記載を先に見てから下書きを読みます。

1. sensitive を見る … 公開の印に無い病歴や家族の事情。消さずに、本人に確かめる一覧に入れる
2. identifiable と listed_term を直す … 「市内の総合病院の救急外来」→「医療の仕事」のように粒度を上げる
3. unsupported を確かめる … 元の行に無い長所や出来事。面談で確かめていなければ消す
4. 下書きを読み、書きぶりを直す … 本人らしさが出ているか。ここはカウンセラーの腕の見せどころです
5. 会員本人に送る … sensitive の記載は「載せてよいか」を一緒に聞く

1番目を消さずに本人に回すのが、この運用の約束です。 持病を知ったうえで出会いたい、と書きたい会員もいます。決めるのは本人で、カウンセラーは確かめる役です。

本人の了承をもらうまで、掲載しません。 書き直しのときも同じで、前の文を了承していても、新しい文は改めて見せます。

4番目の書きぶりの手直しを省かないでください。 下書きは記録に沿っていても、どの会員の推薦文も同じ組み立てになりやすいからです。最初の1か月は、経験の長いカウンセラーが新しいカウンセラーの手直しを週に1回まとめて読み、どこを直すとその人らしさが出るのかを共有します。この共有が、属人化していた書き方を相談所の中に広げる場になります。

例外に対処する

3行目は、相談所の業務では避けられません。 既定の安全方針は、ヘイトと公平性・性的・暴力・自傷の4つについて、プロンプトと出力の両方で重大度が中以上を止めるとされています。家族や恋愛の関係に触れるだけなら安全の範囲とされていますが、過去の被害の経緯が詳しく書かれた記録は止まりうるので、その行は最初からプロフィール文の材料に入れない運用にします。

記録を残す

• 下書きを作った日時、カウンセラー、会員番号、版
• 生成AIへ渡した入力（伏せ字にした後のもの）と、2回の呼び出しの出力
• 拾われた記載と、カウンセラーが「直した」「消した」「本人に確かめた」のどれにしたか
• 会員本人が了承した文と、了承した日時
• 掲載した日と、掲載した文が了承した文と同じであること

4つ目が、いちばん大事な記録です。 掲載した文について後から会員から問い合わせがあったとき、本人が了承した文がどれだったかを示せることが、相談所の信用を守ります。

拾われた記載の種類ごとの件数も、月ごとに数えます。 unsupported が多いカウンセラーは面談の記録が短く、identifiable が多い地域は一覧が足りていません。直す先が、指示ではなく記録の書き方や一覧だと分かります。

伏せ字の前の入力は、ログに残しません。 面談の記録そのものは会員管理の仕組みにあるので、ログに同じものを二重に持つ理由がありません。