派遣元が作る個別契約書と就業条件明示書の記載を、労働者派遣法の記載事項と派遣先との基本契約に照らして確かめ、抜けと食い違いを営業へ返す

処理の起点を決める

SharePoint の「契約点検」ライブラリにファイルが作られたことを起点にします。 Power Automate の SharePoint コネクタには「ファイルの作成時 (プロパティのみ)」のトリガーがあり、ライブラリで項目が作成されたときに動きます。返るのはライブラリの列に入ったプロパティだけなので、続けて「ファイル コンテンツの取得」でファイルの中身を取ります。

フォルダー単位のトリガー（「フォルダーにファイルが作成されたとき」）は使いません。 公式の一覧では非推奨とされ、サブフォルダーにファイルが追加されても起動しないと書かれています。支店ごとにサブフォルダーを切る運用と相性が悪いので、ライブラリ単位のトリガーにして、支店はライブラリの列で分けます。

2つのファイルがそろってから動かします。 個別契約書と明示書は別々に置かれるので、1つ目のファイルで動いたときは、同じ受注番号のもう1つがあるかを確かめ、無ければ待ちの状態にして終えます。 2つ目が置かれたときに、改めて点検を始めます。

営業が直して置き直したときも、同じトリガーで動きます。 版の番号をファイル名ではなくライブラリの列で持ち、前の版の点検結果と並べて、直った指摘と残った指摘を示します。

入力データを集める

質を決めるのは、いちばん下の点検項目の表です。 法の条文をそのまま AI に渡しても、何を1項目として数えるかが決まりません。「業務の内容」「責任の程度」「派遣元責任者」のように、1行1項目に分けた表を契約管理課が作り、その表の行をそのまま判定の単位にします。

抵触日の一覧は、派遣先から受けた通知を値として持ちます。 抵触日をこの構成で計算することはしません。通知された日と、明示書に書かれた日が同じかだけを比べます。

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

Power Automate で2つのファイルの中身を取り、受注番号で派遣管理の書き出しと基本契約の台帳の行を引きます。ファイルのサイズは、SharePoint コネクタが最大100MBまでとされています。 契約書のファイルでこの上限に当たることはまずありませんが、図や画像を貼った明示書は大きくなるので、上限に当たったときは人に回します。

Word からの取り出しは、Python の python-docx で行います。 Document の paragraphs は文書の段落を文書順に、tables は文書の表を文書順に返し、iter_inner_content() は段落と表を文書順に1つずつ返します。契約書は表で項目を並べることが多いので、段落と表を文書順のまま取り出し、表はセルを「見出し：値」の形の行にします。

ここで1つ、公式に書かれている注意があります。 paragraphs には、変更履歴のマーク（<w:ins> や <w:del>）の中の段落は含まれず、tables も変更履歴のマークの中の表を含みません。営業が変更履歴を付けたまま置くと、書き足した記載が取り出しから漏れ、「記載なし」と判定されます。 変更履歴が残っていたら、点検の前に営業へ戻します。

.doc（Word 2003 以前の形式）は開けません。 古いひな形を使っている支店があれば、.docx に作り直してもらいます。

AIへ渡す前に整形する

1. ファイルの組をそろえる … 受注番号と書類の種類（個別契約書／明示書）がライブラリの列に入っているかを確かめます
2. 形式を確かめる … .docx 以外（.doc、PDF）は点検せず、営業へ形式の変更を頼みます
3. 変更履歴とコメントを確かめる … 変更履歴が残っていれば点検を止めて戻します
4. 文字を取り出す … 段落と表を文書順に取り出し、表は「見出し：値」の行にします
5. 値の書き方をそろえる … 時刻（「9時」「9:00」「09:00」）、日付（和暦・西暦）、全角と半角の数字を、照合のための別の欄にそろえて持ちます。AIに渡す文はそろえる前の原文のままです
6. 基本契約の行を引く … 派遣先のコードで台帳の行を引きます。見つからなければ照合の一部を飛ばして needs_review にします
7. スタッフの氏名を外す … 明示書に書かれた氏名・住所は判定に要らないので、AIに渡す前に置き換えます

5番目で、原文と照合用の値を分けて持つのが要です。 AIには原文のまま書き写させ、比べるのは照合用の値で行います。AIに「9時」を「9:00」へ直させると、書き写しと正規化が混ざり、どこで値が変わったかを追えなくなります。

AIに処理させる

させるのは、点検項目の表の1行ごとに、その書類に記載があるかを判定し、書かれている値をそのまま書き写すことだけです。

右端の unclear を missing と分けるのが、この構成の工夫です。 missing は書かれていない、unclear は書かれているが中身が足りないかもしれない、という意味です。前者は営業に機械的に戻せますが、後者は担当者が読んで決めます。

最後の行が、いちばん起きやすい失敗です。 受注票も一緒に渡すと、AIは「受注票によれば9時から」と書いて明示書の空欄を埋めます。そのため、受注票と基本契約はAIに渡さず、照合のプログラムだけが使います。

指示内容を固定する

あなたは派遣元の契約管理課で、書類の記載事項を点検する立場です。
渡された【書類の本文】だけを見て、【点検項目】の1行ごとに判定してください。
推測で埋めないでください。

【書類の種類】{doc_type}   ※ individual_contract か employment_terms

【status の選び方】
- present ... その項目の値が書かれている
- missing ... 書かれていない。見出しや欄だけがあって値が空の場合も missing
- unclear ... 書かれているが、中身が足りない・幅がありすぎる・複数に読める
迷ったときに present を選ばないでください。

【厳守事項】
- value には、書類に書かれている文字列をそのまま写してください。
  時刻や日付の書き方を直さないでください。
- 書類に無い値を書かないでください。他の書類や一般的な契約の内容から補わないでください。
- 見出しや欄の名前があることを、値があることとして扱わないでください。
- 同じ項目が複数の箇所に書かれていて値が違うときは、両方を values に並べ、
  status を unclear にしてください。
- location には、根拠にした段落または表の番号を入れてください。
- 派遣してよい業務か、法令に合っているか、待遇が適切かは書かないでください。
- 抵触日を計算しないでください。書かれている日付を写すだけにしてください。
- 個人の氏名や住所は書き写さないでください（[氏名] のように置き換え済みです）。

【点検項目】{check_items}
【書類の本文】{document_text}

「他の書類から補わない」を書いても、他の書類を渡せば補います。 指示で禁じるだけでなく、渡すものを1つの書類だけにするのが、この題材のいちばん効く対策です。個別契約書と明示書も、別々の呼び出しで判定します。

「見出しがあることを値として扱わない」も明記します。 ひな形には全項目の見出しが印刷されているので、何も言わなければ見出しの存在を根拠に present を選びます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力では、すべての項目を必須にし、オブジェクトに additionalProperties: false を付けます。省略してよい値は、公式の例のとおり null との共用体型で表します。

{
  "order_no": "",
  "doc_type": "individual_contract | employment_terms",
  "checks": [
    {
      "item_id": "work_hours",
      "status": "present | missing | unclear",
      "values": [""],
      "location": "",
      "note": null
    }
  ]
}

AIが返すのはここまでです。 照合のプログラムが、2つの書類の checks と受注票・基本契約の値を並べて、次の結果を足します。

1つ目の理由は、AIの書き写しと機械の比較を別の層に置けることです。 食い違いと出たときに、AIの写し間違いか、書類そのものの食い違いかを values と location から確かめられます。

2つ目は、判定を規則で決められることです。 missing か食い違いが1つでもあれば needs_fix、unclear か台帳に無しがあれば needs_review、どちらも無ければ pass とします。どの項目を必須にするかが変わっても、直すのは規則の表だけです。

3つ目は、組み合わせの数を数えられることです。 施行規則第21条第1項は、業務の内容などの組合せが2つ以上あるときは、その組合せごとの内容と人数を定めるとしています。values が複数ある項目の数から、組合せごとの人数が書かれているかを照合で確かめられます。

システムへ連携する

派遣管理の仕組みと書類そのものには書き込みません。 指摘を受けて書類を直すのは営業です。AIの判定から書類が自動で書き換わる経路を作ると、誰がその記載を決めたのかが分からなくなります。

営業への通知には、項目名と根拠の場所だけを書きます。 「就業条件明示書の就業時間が個別契約書と違います（明示書 表3、個別契約書 表2）」のような形です。書類の本文やスタッフの情報を Teams のメッセージに貼りません。

人が確認する

契約管理課の担当は、needs_fix と needs_review の組を開きます。 pass の組は一覧で件数と派遣先を流し見るだけにします。

1. needs_review を先に見る … unclear の項目と、台帳に無い派遣先です。読んで、戻すか通すかを担当者が決めます
2. needs_fix の根拠を確かめる … values と location から書類の該当箇所を開き、本当に書かれていないか、本当に値が違うかを目で確かめます
3. 営業へ戻す文を決める … 自動で作った指摘の一覧を、担当者が直してから戻します
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目を省かないでください。 取り出しの漏れ（変更履歴の中の記載、図の中の文字）で missing と出ることがあります。根拠の場所を見れば、書類の抜けか取り出しの漏れかはすぐに分かります。

派遣してよい業務かどうか、抵触日の計算が正しいかは、この点検の対象外です。 指摘の一覧の末尾に、「業務の適否と抵触日の計算は別の手順で確認済みか」の確認欄を置き、担当者が印を付けます。

例外に対処する

上から3行目は、実際に多く起きると考えています。 派遣先との調整を変更履歴で残す営業は多く、そのまま置かれた書類は、書き足した記載だけが点検から抜けます。 点検の前に止めるのが、もっとも確実です。

記録を残す

• 点検した書類の版と、置かれた日時・置いた営業
• 取り出した文字（段落と表の番号付き）
• Azure OpenAI に渡した点検項目の表の版と、返ってきた checks
• 照合の結果と、そのとき参照した受注票・基本契約の台帳の行
• 担当者が判定を覆した記録（項目、変更前、変更後、理由）
• 営業へ戻した指摘と、直った版の点検結果

4つ目で「そのときの台帳の行」を残すのは、基本契約が更新されるためです。 時間外の上限を派遣先と見直したあとで、過去の点検が通った理由を説明できるようにします。

判定を覆した記録は、点検項目の表を直す材料になります。 同じ項目で覆す回数が多ければ、項目の切り方か、unclear の基準が実態に合っていません。