社員インタビューの録音から、採用広報の記事と募集要項の下書きを作る

処理の起点を決める

指定フォルダに録音ファイルが置かれたことを起点にします。 担当者が録音を SharePoint の「インタビュー録音」フォルダに入れる。それだけです。オンライン会議ならTeams の文字起こしの保存をトリガーにできます。 週に1〜2本で日程も不定なので、時刻では動かしません。

直後に人が入力することが1つあります。相手（氏名・拠点・職種・入社年）と用途（記事だけか、募集要項の更新も含むか）です。 ファイル名の規則は必ず崩れるので、録音と同じフォルダに1件1行の管理表を置きます。

入力データを集める

公表してよい数値の台帳が無いと、数値の扱いが担当者の記憶頼りになります。 「平均勤続年数は公開していたか」を毎回思い出す運用は必ず崩れます。公表済みの値だけを並べた表を1枚作り、そこに無い数値は書かせない、と決めます。

伏せる語の辞書は、介護や医療では特に重要です。 インタビューでは利用者さんの具体的な話が自然に出ます。本人にとって仕事のいちばん大事な部分ですが、そのまま公開できる情報ではありません。 型に入れる「してはいけない表現の一覧」は、（c）を止める土台です。

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

録音： Power Automate で SharePoint のフォルダを監視し、ファイルが置かれたら Azure Blob Storage に写して、バッチ文字起こしのジョブを作ります。

{
  "contentUrls": ["https://<storage>.blob.core.windows.net/<c>/interview-0413.wav?<SAS>"],
  "locale": "ja-JP",
  "displayName": "2026-04-13 訪問介護 Aさん",
  "properties": {
    "diarizationEnabled": true,
    "wordLevelTimestampsEnabled": true,
    "timeToLiveHours": 48,
    "destinationContainerUrl": "https://<storage>.blob.core.windows.net/<r>?<SAS>"
  }
}

destinationContainerUrl を properties の中に書いている点に注意してください。 ルートに置くと無視されます。完了は Webhook（transcriptionSucceeded）で受けます。問い合わせる形でも10分ごとで十分です。

Teams の文字起こしを使う場合： OneDrive / SharePoint への保存をトリガーにします。この場合、Azure AI Speech の工程は不要です。 台帳類は SharePoint リストから読みます。公表してよい数値も伏せる語も運用しながら増えるので、スクリプトの中に書き込まないでください。

AIへ渡す前に整形する

1. 話者の割り当て … 話者の情報を「聞き手」と「本人」に対応づけます。冒頭の数発言で決まるので、1回だけ人が確認します
2. 発言の単位に切る … 話者が変わるところで切り q01 q02 と番号を振ります。タイムスタンプも一緒に持たせます
3. 伏せ字への置換 … 辞書にある語を置き換え、どの発言のどの語だったかを記録に残します
4. 数値の抜き出し … 発言の数値を公表値の台帳と照合し、無い数値に印を付けます
5. 整理と分割 … 相づちを除いた読みやすい版を作り、原文は別に残します（引用は原文から）。40分で1万字前後になるので、質問票の区切りで分けます

4番目を省かないでください。 「うちの拠点、去年は3人辞めました」のような発言は、本人にとっては世間話でも、公開すると未公表の数値になります。

AIに処理させる

AIにさせるのは、そろえた材料を記事の日本語にすることと、その根拠を示すことだけです。 事実を補うことも、数値を計算することも、この人が良い社員かを判断することもさせません。

2行目がこの設計の中心です。 段落ごとに「この段落は q07 と q09 に基づく」と出させます。発言番号を付けられない段落は、書いてはいけない段落です。 ただし話をつなぐ文は必要なので、段落に3つの種類を持たせます。quote は発言をほぼそのまま使う段落、paraphrase は発言にある内容だけを言い換えた段落、bridge はつなぎの文で、bridge には固有名詞と数値と評価語を書かせません。

この縛りが効きます。 つなぎの文に「充実した研修体制のもと」のような評価語が入ると、そこが誇張の入口です。「大変だったこと」の節を必須にする理由も同じで、大変な部分が本人の言葉で書いてある記事のほうが信用されます。

指示内容を固定する

社員インタビューの文字起こしから、採用広報の記事の構成案と本文の下書き、
および募集要項の魅力づけの文面を作ってください。原稿は担当者が確認し、
本人に見せて直してもらってから公開します。本人が読んで
「自分はこう言っていない」と感じる文が1つでもあれば失敗です。

【厳守：言っていないことを書かない】
- 本文の段落はすべて quotes のいずれかに基づいて書き、もとになった発言の
  quote_id を based_on に必ず列挙してください。
- based_on を空にできるのは type が "bridge" の段落だけです。
  "bridge" には固有名詞、数値、評価をあらわす語を書かないでください。
- 渡した発言に無い気持ち、理由、経緯を補わないでください（「〜だったから
  だろう」など）。足りない場合は unsupported_claims に理由を書いてください。
- 数値は quotes か公表値の台帳にある値だけを使い、概算に言い換えないで
  ください。台帳に無い数値は、発言にあっても書かないでください。
- 制度、給与、勤務時間、研修は、渡した募集要項と台帳の記述だけを使い、
  食い違う場合は needs_human_attention に理由を書いてください。

【厳守：盛らない】
- 形容詞と評価をあらわす語は、本人が発言で使った語だけを使い、
  「慣れました」を「安心です」に言い換えないでください。
- 次を使わないでください。アットホーム、風通しがよい、誰でも活躍できる、
  未経験でも安心、やりがいしかない、圧倒的、成長できる環境、家族のような／
  最上級と全称の表現（最も、すべて、誰もが、常に、必ず）／他社との比較
- 構成案に「大変だったこと」にあたる節を必ず1つ入れ、本文でも書いてください。
  本人が語った困難を、克服の話だけで締めないでください。

【厳守：伏せる】
- 次は本文にも引用にも使わず、masked_items に記録してください。
  利用者・顧客・取引先の氏名や個人が特定できる状況の描写／未公表の社内の
  数値（離職率、拠点別の人数、給与額、残業時間）／家族・健康・病歴の話／
  同僚を名指しした評価／未公表の事業計画や拠点の開設

【募集要項】記事に出てきた具体的な言葉で魅力づけの欄の案を作り、jd_phrases
  にも based_on を付けてください。条件面の記述は変えないでください。

{interviewee}｜{quotes}｜{questions}｜{public_figures}｜{current_jd}｜{style_guide}

「発言番号を必ず添えさせる」が、いちばん効く制約です。 根拠を示す義務があると、根拠の無い文を書きにくくなります。何より、担当者の確認が速くなります。

禁止する表現を名指しで並べている点も重要です。 「誇張しないで」では効きません。実際に出てくる言い回しを列挙するほうが確実です。

出力形式を固定する

{
  "interview_id": "", "title_candidates": ["", "", ""],
  "outline": [{ "section_id": "s1", "heading": "", "is_difficulty": false }],
  "quotes": [{ "quote_id": "q01", "speaker": "本人", "timestamp": "00:12:34", "text": "" }],
  "draft": [{ "section_id": "s1", "paragraph_id": "p01", "type": "quote",
              "text": "", "based_on": ["q01", "q03"] }],
  "jd_phrases": [{ "field": "仕事内容", "text": "", "based_on": ["q05"] }],
  "masked_items": [{ "kind": "利用者名", "quote_id": "q07", "replacement": "" }],
  "unsupported_claims": [{ "paragraph_id": "", "text": "", "reason": "" }],
  "needs_human_attention": { "flag": false, "reason": "" }
}

構造化する理由は2つあります。1つ目は、突き合わせを速くするためです。 based_on があると、担当者は下書きの1段落を読みながら quotes の該当番号を開き、タイムスタンプで録音のその場所に飛べます（jd_phrases も同じようにたどれます）。

2つ目は、機械で検査できるようにするためです。 based_on が空で type が bridge でない段落、bridge なのに数値が入る段落、quotes に無い固有名詞が出る段落を、プログラムで検知して担当者に先に見せられます。 プロンプトの制約は必ずすり抜けるので、出力の側でも見ます。

形式を確実に守らせる仕組みも使えます。 OpenAI API の Structured Outputs は、公式の案内で、JSON モードが「妥当な JSON であること」を保証するのに対し、「スキーマに従うこと」まで保証すると説明されています。text の format に type: "json_schema"、スキーマ名、スキーマ本体、strict: true を指定すると、渡したスキーマに厳密に従うことが保証されます。 スキーマ側ではすべてのプロパティを required に挙げ、各オブジェクトに additionalProperties: false を指定し、省略してよい項目は型を配列にして null を許します。拒否されると応答は refusal を含む形になるので、受け取る側で判定が要ります。

システムへ連携する

最後の行を自動化しません。 月6件で自動投入を作り込む意味はなく、未確認の原稿が公開される道を作るほうが危険です。

人が確認する

全件、3段階で人が確認します。確認せずに公開する設計にしません。

第1段階：担当者の突き合わせ。 unsupported_claims と needs_human_attention を先に読み、based_on が空の段落と bridge なのに数値のある段落を検査結果から拾います。masked_items を確認し、気になった段落だけ録音を聞きます。

第2段階：本人確認（掲載前に必ず行う）。 本人に下書きを見せ、「事実として違うところはないか」「自分の言い方と違うところはないか」「実名（または匿名）で公開してよいか」の3つを聞きます。

2つ目を必ず聞いてください。 事実だけを聞くと、本人は「まあ、そういうことです」と流します。「これは自分の言葉ですか」と聞くと、（c）の誇張がここで止まります。 本人が直した箇所は、直す前と後の両方を記録に残します。

第3段階：拠点長と人事部長の確認。 制度の記述が現行と合っているか、公表していない情報が残っていないかを見ます。両者が気づかない誤りは、ここで止めます。

確認の目標は1件70分（下書きの確認25分＋突き合わせ20分＋本人確認の反映25分）です。

例外に対処する

最初の行を軽く見ないでください。 話者が入れ替わった記事は、日本語として自然に読めてしまいます。

記録を残す

• 録音ファイルと削除の記録、文字起こしの原文（発言番号とタイムスタンプ付き）
• 伏せ字に置き換えた箇所の一覧（どの発言の、どの語を、何に置き換えたか）
• AIに渡した材料（台帳・募集要項・一覧の版）と、返ってきた出力と検査結果
• 担当者が直した箇所と、本人が直した箇所（直す前と後の両方）
• 本人確認の記録（いつ、誰に見せ、何を直し、公開に同意したか）
• 公開した版と公開日、募集要項に反映した箇所

本人が直した箇所を集めると、自社の誇張の癖が見えます。 「慣れました」を「安心です」に言い換える直しが続くなら、それは自社の採用広報が長年やってきた言い換えです。一覧に足せば、次からは出なくなります。 本人確認の記録は、同意の証拠にもなります。