社内から届く押印と契約書の締結の申請を、書類の種類・金額・相手方で分類し、法務の審査が要るものとそのまま押印できるものに仕分ける

処理の起点を決める

押印の申請フォームの送信を起点にします。 Form Trigger で作るフォームに、書類のファイル（PDFまたはWord）、稟議の番号、相手方の名前、押す印（代表者印・社印・部署の印）、希望の期日を入れてもらいます。

フォームの「Respond When」は「Form Is Submitted」にします。 申請者には受け付けたことだけを返し、仕分けの結果は通知で知らせます。書類の読み取りに時間がかかっても、申請者を画面の前で待たせません。

稟議の番号は必須にします。 押印に回ってくる書類のほとんどは、先に稟議で決裁されています。稟議の番号が無い申請は、ワークフローの最初で差し戻します。 番号の無いものを読んで分類しても、照らす先がありません。

ファイルは1件の申請に1つにします。 契約書と別紙を別のファイルで付けたくなりますが、押すのは1つの書類で、ハッシュ値で照らすのも1つの版です。 別紙はPDFにまとめてから出してもらいます。

入力データを集める

質を決めるのは、押印の基準の表です。 規程の別表は文章で書かれていることが多く、そのままでは照らせません。 「書類の種類」「金額の下限」「自社のひな形か」「注意すべき条項があれば審査」の列にそろえます。

審査の記録のハッシュ値の列は、法務課が審査を終えるたびに埋めます。 審査した最終の版のファイルをフォームに入れると、ハッシュ値を返す小さなワークフローを用意しておけば、法務課の手間は1件数十秒です。

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

ハッシュ値の照合は、ファイルが1バイトでも違えば一致しません。 中身が同じでも、PDFに書き出し直すと値が変わることがあります。一致しなかったときは「審査済みの版ではない」ではなく「版が確かめられない」として扱い、法務課に版の確認を頼みます。 誤って「審査が要る」に倒れても、審査済みのものを押してしまうよりは安全です。

PDFは Extract From File で文字にします。 ページをつなげる、読むページの上限、パスワードを指定できます。スキャンした画像のPDFからは文字が取れないので、例外処理で扱います。Word は PDF にしてから出してもらうか、変換の段を前に置きます。

AIへ渡す前に整形する

1. 稟議の番号の確認 … 番号が無い、または稟議の仕組みに無い番号なら、読む前に差し戻します
2. ファイルの形式の確認 … PDF以外は、PDFにしてから出してもらいます
3. ハッシュ値の計算 … 申請されたファイルそのものから計算します。文字の取り出しの後の値ではありません
4. 文字の取り出し … 取れた文字が数十字しかなければ、画像のPDFとして扱います
5. 長さの確認 … 約款の付いた注文請書など、長い書類は本文と約款を分けて渡します
6. 相手方の名前の正規化 … 「株式会社」の前後、全角と半角をそろえ、取引先マスタと照らせる形にします

5番目は、条項の見落としを防ぐためです。 長い書類を一度に渡すと、最後の方にある約款の条項の取り出しが粗くなります。 本文と約款を分け、注意すべき条項はそれぞれから取り出します。

AIに処理させる

させるのは2つです。書類の種類を区分のどれかに分けることと、相手方・金額・期間・注意すべき条項を取り出すことです。

Text Classifier で種類を分け、Information Extractor で項目を取り出します。 Text Classifier は、カテゴリーに名前と説明を付けて入力を分けるノードで、どれにも当たらないときに捨てるか「Other」の出口に出すかを選べます。既定は捨てる方なので、必ず「Other」に変えます。 Information Extractor は、属性の説明やJSONの例で形を決めて、文章から項目を取り出すノードです。

注意すべき条項は、「ある」と「見当たらない」の2つで返させ、「ない」とは言わせません。 AIが見当たらないと返しても、書類のどこかにある可能性は残ります。「見当たらない」は、法務の審査が要らないことの証明ではありません。

押印そのものについて、内閣府・法務省・経済産業省の「押印についてのＱ＆Ａ」は、私法上、契約は当事者の意思の合致により成立し、書面の作成やその書面への押印は、特段の定めがある場合を除き必要な要件とはされていない、としています。 押印の有無で契約の効力が変わらないからこそ、押す前の確認の質が、社内の統制として意味を持ちます。

指示内容を固定する

Text Classifier の System Prompt Template には、次の文を入れます。 {categories} はノードが置き換える部分です。

あなたは押印の窓口の補助として、申請された書類の種類を1つに分けます。
分ける先は次のとおりです。
{categories}

【厳守事項】
- 書類の題名だけで決めないでください。本文の内容で決めてください。
  題名が「覚書」でも、新しい取引の条件を一から定めているものは
  「取引基本契約」または「業務委託・請負」に分けてください。
- 注文請書の裏面などに約款が付いている場合は、約款を含めて
  「業務委託・請負」に分けてください。
- どれにも当たらない、または判断できないときは、その他にしてください。

Information Extractor の各項目の説明には、次の制約を書きます。

- 金額：書類に「契約金額」「委託料」「代金」などとして書かれた額を、
  書かれたとおりに写す（税込・税抜の別も写す）。
  書かれていなければ空にする。単価と数量から計算しない。
- 注意すべき条項：次の7つについて、書類のどこかに該当する定めがあれば
  found、無ければ not_found とし、found のときは条番号と該当の文を写す。
  ① 損害賠償の上限が無い、または相手方にだけ上限がある
  ② 成果物の知的財産権を相手方に帰属させる
  ③ 自社の競業を禁じる  ④ 独占の定め  ⑤ 準拠法または管轄が国外
  ⑥ 相手方だけが理由なく解除できる  ⑦ 保証・連帯保証
  条項が妥当かどうかは書かない。
- 書式の出所：「当社書式 Ver.」などの自社のひな形の版の表示があれば
  その表示を写す。無ければ空にする。

「条番号と該当の文を写す」を入れているのは、確認の速さのためです。 総務の担当者は、写された文と条番号を見て書類の該当の箇所を開けます。根拠の文が無い found は、確認できないので信用しません。

出力形式を固定する

ワークフローの最後に、申請1件につき次の形で一覧に載せます。

{
  "request_id": "",
  "ringi_no": "",
  "file_sha256": "",
  "doc_type": "master | nda | outsourcing | amendment | pledge | filing | other",
  "counterparty": "",
  "amount_text": "",
  "term": { "start": "", "end": "", "auto_renewal": "" },
  "template_mark": "",
  "clauses": [
    { "code": "liability_cap", "status": "found | not_found", "article": "", "quote": "" }
  ],
  "checks": {
    "ringi_approved": true,
    "amount_matches_ringi": "match | mismatch | unknown",
    "counterparty_registered": true,
    "reviewed_version": "match | no_record | hash_mismatch"
  },
  "stamp_duty_check": false,
  "route": "legal_review | stamp_ok | return",
  "route_reason": ""
}

1つ目の理由は、AIの取り出しと規則の照合を別の層に置けることです。 doc_type から clauses まではAIが埋め、checks と route はワークフローが表に照らして決めます。route_reason には、表のどの行に当たったかを書きます。 「業務委託・請負、金額300万円以上」のように、決まった理由がそのまま読めます。

2つ目は、reviewed_version を3つの値で持てることです。 match は審査した版と同じ、no_record は審査の記録が無い、hash_mismatch は同じ相手方・同じ種類の審査の記録はあるが版が違う。3つ目が、第3章の（b）で見逃していた差し替えです。 法務の審査が要るものとして回します。

3つ目は、amount_text を文字列で持つことです。 「月額50万円（税別）」のように、AIは書かれたとおりに写します。決裁の金額との照合は、数字に直せたものだけをワークフローが行い、直せないものは unknown にします。

システムへ連携する

稟議の仕組みとの接続は、使っている仕組みによって変わります。 APIで決裁の状態を引ける仕組みもあれば、一覧を書き出すことしかできない仕組みもあります。 後者なら、毎朝の書き出しを読む形にします。この部分は利用環境に応じた個別の実装になります。

どこにも書き込みません。 押印簿への記録は、押した後に総務の担当者が行います。

人が確認する

総務の担当者は、「そのまま押印できる」の件について、根拠を見てから押します。

1. route_reason を読む … どの表の行で「押印できる」になったかを見ます
2. reviewed_version を見る … match なら審査済みの版です。no_record で押印できるとされたものは、審査が要らない種類と金額であることを確かめます
3. clauses の found を見る … found があれば、表の上は押印できるとされていても押す前に法務課に一言確かめます
4. 押して、押印簿に記録する

法務課は、「法務の審査が要る」の件を受けて審査します。 clauses の条番号と該当の文が添えられているので、どこから読むかが最初から分かります。 審査が終わったら、最終の版のハッシュ値を審査の記録に残します。

差し戻しの件は、申請者が直して出し直します。 差し戻しの理由は、稟議の番号が無い、決裁が終わっていない、決裁の金額と書類の金額が合わない、ファイルが読めない、のいずれかです。

例外に対処する

判断できないものは、すべて法務に倒します。 「その他」、文字の取れないPDF、ハッシュ値の不一致は、どれも押してしまう方に倒さない作りにしています。法務課に回る件数は増えますが、その件数が多い月は、押印の基準の表か、申請のしかたを見直す合図です。

記録を残す

• 申請の情報、ファイルのハッシュ値、ファイルそのもの
• AIの分類と取り出しの結果（doc_type、clauses の条番号と該当の文）
• 照合の結果（checks）と、そのとき当てはめた押印の基準の表の版
• route と route_reason
• 総務や法務課が仕分けを変えた記録 … どれからどれへ、その理由
• 押印した日時、押した印、押した人

3つ目で「基準の表の版」を残すのは、表が後から変わるためです。 表を変えると過去の仕分けの意味が変わり、当時の表が残っていないと、なぜ押してよいとされたかをたどれません。

ファイルそのものを残すのは、押した版を後から確かめるためです。 相手方と取り交わした書類と、押印に回った書類が同じかを、ハッシュ値で後から照らせます。