労働組合の事務局が、労働協約・組合規約・共済の手引きを Azure OpenAI に渡して組合員の質問にチャットで答え、個別の相談は役員に回す

処理の起点を決める

組合員がチャット画面で質問を送信したときに動きます。 定時のまとめ処理にはしません。チャットの利点は返事の速さで、まとめて処理するとメールで聞くのと変わらなくなります。

ログインは組合員番号と、組合が発行するパスワードで行います。 会社のアカウント（会社の Microsoft Entra ID）でのサインインにはしません。会社のアカウントでサインインさせると、誰がいつ組合に何を聞いたかの痕跡が会社の管理する仕組みに残ります。 組合のテナントに組合員のアカウントを作るか、組合のポータルの独自の認証にします。

フォームとメールで届く質問も、受付の担当がチャットと同じ入口に貼り付けて流せるようにします。入口が複数あっても、判定と回答の仕組みは1つにします。 経路ごとに判定の基準が違うと、相談の拾い方がばらつきます。

入力データを集める

質を決めるのは、雇用区分と版の日付の2つです。 協約は正社員と嘱託・パートで適用される条文が違うことが多く、雇用区分が無いと正社員の条文で嘱託の組合員に答えてしまいます。 版の日付が無いと、改定前の条文で答えます。

労働協約は、書面に作成し、両当事者が署名し又は記名押印することによって効力を生ずると労働組合法で定められています。 検索の索引に入れるのは、署名・記名押印が済んだ確定版だけにします。交渉中の案や、合意前の会社回答を入れると、まだ効力の無い条件を組合員に伝えることになります。

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

条文は、共有フォルダにある協約・規約・手引きのPDFから、条ごと・別表ごとに1件の文書として検索の索引に入れます。ページで区切ると、1つの条が2つに割れたり、別の条とくっついたりします。

検索の要求には、効力の日付と雇用区分のフィルターを必ず付けます。 Azure AI Search のハイブリッド検索は、フィルターやセマンティック ランク付けといったテキスト側の機能をベクトル検索と一緒に使えます。旧版の条文は索引から消さずに残し、フィルターで外します。 「去年はどうだったか」という質問に答えるときと、後から過去の回答を検証するときに必要になるからです。

別表は条とは別の文書として入れ、条から別表への参照を項目として持たせます。 「特別休暇の日数は別表2による」という条文だけが検索に当たっても、日数は答えられません。条が当たったら、参照先の別表も一緒に取り出します。

AIへ渡す前に整形する

1. 個人の識別情報を分ける … 質問に氏名・社員番号・上司の名前が書かれていれば、回答の呼び出しには渡さず、相談の通知にだけ使います
2. 長さを確かめる … 長すぎる質問は、要点を書き直してもらうよう案内します。相談の可能性が高いので、判定には全文を渡します
3. 会話の文脈を付ける … 「それはパートでも同じですか」のような続きの質問には、直前の質問と回答を添えます
4. 雇用区分と共済の加入区分を付ける … 名簿から引いて、検索のフィルターと回答の条件に使います
5. 検索の語を整える … 「産休」「育休」「年休」のような略語に、条文の正式な語を添えます。略語の一覧は事務局が持ちます
6. 同じ質問の連投をまとめる … 送信の二度押しや、言い換えての再送を1件として扱います

1番目を最初に置くのは、回答に個人を入れる必要が無いからです。 「特別休暇の日数」に答えるのに、誰が聞いたかは要りません。AIに渡す範囲を、答えるのに要る範囲に絞ります。

AIに処理させる

呼び出しは2回に分けます。 1回目は相談か質問かの判定、2回目は条文に基づく回答です。1回で両方をさせると、条文が手元にあるせいで相談にも条文で答えようとします。

判定で consultation とする目安は、次のようなものです。

最後の行は、文書の質問に見えて相談です。 「入院したら見舞金は出ますか」は手引きの条件で答えられますが、「この入院で出ますか」は共済の担当が書類を見て決めることです。一般の条件は答え、個別の可否は回す、と線を引きます。

2行目は特に起きやすい失敗です。 労働組合法には、労働協約に定める労働条件その他の労働者の待遇に関する基準に違反する労働契約の部分は無効とする規定があります。AIは「協約に反するので無効です」と言い切りたがりますが、その人の契約が実際にどうなっているかを、チャットの一文からは判断できません。

指示内容を固定する

①判定の呼び出し

あなたは労働組合の事務局で、組合員から届いた文面を仕分ける担当です。
回答はしません。仕分けだけをしてください。

【仕分けの基準】
- question ....... 協約・規約・共済の手引きの条文を読めば、誰にでも同じ答えが
                   返せる質問（日数、期限、金額の決まり、手続きの方法など）
- consultation ... 本人や職場の具体的な事情が書かれていて、事実の聞き取りや
                   組合としての判断が要るもの

【厳守事項】
- 迷ったときは consultation にしてください。question にしないでください。
- 制度の質問の形をしていても、本人が困っている事情が書かれていれば
  consultation です。
  例：「育休は取れますか。上司に取るなと言われています」は consultation。
- 共済の給付について「自分の場合に出るか」を聞いているものは consultation です。
- consultation のときは category を1つ選び、summary に事情の要点を
  3文以内で書いてください。本人の評価や推測は書かないでください。
- 心身の不調や、自分を傷つける考えが書かれているときは、
  urgent を true にしてください。

【文面】{message}
【直前のやり取り】{history}

②回答の呼び出し

あなたは労働組合の事務局として、組合員の質問に答えます。
下の【条文】に書かれていることだけを根拠にしてください。

【厳守事項】
- 条文に書かれていないことは答えないでください。会社の就業規則や
  慣行、一般的な法律の知識で補わないでください。
- 条文に答えが無いときは status を not_found にしてください。
- 回答に使った条文は、citations に文書名・条番号・原文の引用を入れてください。
  引用は条文からそのまま写し、言い換えないでください。
- 別表を参照している条文は、別表の値まで確かめてから答えてください。
  別表が渡されていなければ not_found です。
- 雇用区分が【組合員の区分】と合わない条文を根拠にしないでください。
- 協約と共済の手引きで似た言葉が出てきても、混ぜないでください。
  どちらの文書の話かを回答の中で明示してください。
- 「無効です」「違反です」「請求できます」のような判断を書かないでください。
- 回答は、組合員が読む文章として丁寧語で、300字以内にしてください。

【組合員の区分】{employment_type}／共済：{mutual_aid_type}
【質問】{question}
【条文】{retrieved_articles}

判定の側に「迷ったら consultation」を明記しないと、question に寄ります。 文面の多くは制度の言葉を含むので、言葉だけを見ると質問に見えるからです。相談を質問と取り違えた損失は、質問を相談と取り違えた損失よりはるかに大きいので、迷いの向きを指示で固定します。

回答の側で「言い換えないで写す」を求めるのは、後段で引用を照合するためです。 引用が原文に無ければ、回答は返さずに確認待ちに回します。

出力形式を固定する

①判定は次の形の JSON で受け取ります。

{
  "route": "question | consultation",
  "category": "harassment | treatment | discipline | wage_error | health | mutual_aid_case | other | none",
  "urgent": false,
  "summary": ""
}

②回答は次の形です。

{
  "status": "answered | not_found | ambiguous",
  "answer": "",
  "citations": [
    { "document": "労働協約 | 組合規約 | 共済の手引き",
      "article": "", "version_from": "", "quote": "" }
  ],
  "needs_staff": false
}

構造化出力を使うのは、後段の処理を機械で分岐させるためです。 Azure OpenAI の構造化出力は、指定した JSON スキーマに従った出力を返す仕組みで、Chat Completions API と Responses API の両方で使えます。route が consultation なら回答の呼び出しをせずに通知へ、status が answered 以外なら確認待ちへ、と文章を読まずに振り分けられます。

スキーマには制約があります。 公式ドキュメントでは、すべての項目を必須にし、オブジェクトには常に additionalProperties: false を設定するとされています。省略したい項目は、null との共用体の型で表します。文字列の長さや配列の要素数の制約（maxLength、minItems、maxItems など）はサポートされていないので、「回答は300字以内」「引用は1件以上」はスキーマでは縛れません。受け取った後に Azure Functions の側で数えて、外れたものは確認待ちに回します。

システムへ連携する

役員への通知に、相談の全文は載せません。 載せるのは種類と3文以内の要点と、事務局の画面で全文を開くためのリンクです。役員のメールが会社のメールである場合、全文を送ると会社のサーバーに相談の内容が残ります。 組合の連絡手段を使うか、リンクだけを送ります。

組合員名簿は読むだけで、書き込みません。 雇用区分が変わっていても、チャットからは直しません。

人が確認する

事務局が見るのは、確認待ちに入ったものと、毎日の抜き取りです。 条文で答えた回答をすべて承認してから返す設計にはしません。

1. 緊急の相談を最初に見る … urgent が付いたものは、担当役員と書記長に同時に通知します。組合員への連絡は人が行います
2. 確認待ちに返信する … not_found は条文に答えが無いもの、照合NGは引用が原文に無いもの。多くは、別表が索引に入っていないか、略語の一覧が足りていません
3. 前日の回答から抜き取る … 1日20件程度を読み、条文と回答が合っているかを見ます。誤りがあれば組合員に訂正を送り、原因を記録します
4. 相談の振り分けを見直す … question と判定されて回答されたもののうち、文面に事情が書かれていたものを探します

4番目を毎週続けてください。 相談を質問と取り違えた件は、組合員の側からは「組合に相談したのに条文を返された」という形でしか表に出ません。事務局が自分から探さないと、見つかりません。

目標は、600件をならして1件4分です。 確認待ちと相談が2割前後という想定で、それより多い月は、協約の改定が索引に反映されていないか、略語の一覧が足りていません。

例外に対処する

1行目が、この構成でいちばん気を付ける例外です。 Azure OpenAI の既定の安全方針（DefaultV2）は、憎悪と公平性・暴力・性的・自傷の4つの区分について、入力と出力の両方で重大度「中」以上をブロックします。 入力が止まるとエラーが返ります。ハラスメントの具体的な言動や、つらい気持ちを書いた相談ほど止まりやすく、エラーを「処理失敗」として捨てると、いちばん急ぐ相談が誰にも届きません。 止まった質問は、判定を待たずに相談として扱います。

記録を残す

• 質問の全文と、受け付けた日時・経路
• 判定の結果（route、category、urgent、summary）
• 検索で取り出した条文の ID と版、回答の JSON の全文
• 引用の照合の結果と、確認待ちに回した理由
• 事務局が訂正した回答と、その理由
• 相談を受けた役員と、組合員へ連絡した日時

記録は組合のサブスクリプションの中に置き、会社の管理者が読めない場所にします。 保存の期間と、退会した組合員の記録の扱いは、執行委員会で決めて組合員に示します。

3つ目で条文の版を残すのは、協約が毎年改定されるためです。 後から「あのときの回答は正しかったか」を確かめるとき、当時有効だった版が分からなければ検証できません。