秘密保持契約ごとに、実際に開示した資料と返却・破棄の状況を台帳にする

処理の起点を決める

毎日決まった時刻に動かし、拾うのは前日分に限ります。 当日分を追いかけると、送信直後のメールと後から追加された共有リンクが別の日にまたがり、同じ開示を2回拾います。

時刻主導トリガーは毎分から月1回までの頻度を取れますが、返却・破棄の依頼は契約の終了日を起点に動くもので、分単位の速さには意味がありません。日次で十分です。

function createDailyTrigger() {
  ScriptApp.newTrigger("collectDisclosures")
    .timeBased().atHour(3).everyDays(1).create();
}

指定した時刻ちょうどには動きません。 時刻はわずかにランダム化されるので、午前3時を指定すれば3時から4時の間のどこかで動きます。深夜を選ぶのは、その日の送信メールが出そろっているからです。

スクリプトの実行やAPIリクエストでは、トリガーは発火しません。 動作を確かめるときは対象の関数を直接実行します。失敗したときは自動でメールが通知され、調整できるのは通知の頻度だけです。 気づく手段が通知しかないので、宛先を法務の共有アドレスにしてください。

入力データを集める

この構成の質を決めるのは、契約台帳に「相手先ドメイン」の列があることです。 社名だけでは引けず、表記ゆれ、英語表記、グループ会社の混在が、そのまま取りこぼしになります。契約番号の列も同じくらい重要です。 同じ取引先と複数の契約を結んでいる場合はドメインだけでは区別できないので、件名の先頭に契約番号を書く運用を併せて始めてください。

添付ファイルは、名前と拡張子だけを取ります。中身は開きません。 「A部品_試作評価_v3.xlsx」というファイル名から分かることまでが、この構成の範囲です。理由は第13章に書きます。

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

すべて Apps Script の中で完結し、外部にデータを持ち出す経路は生成AIへの呼び出し1本だけです。

②はドメインごとに検索を分けてください。 まとめて引くと、どのメールがどの契約に属するのかを後から付け直すことになります。

③は②より取りこぼしやすい経路です。共有リンクは、発行しただけでは相手にメールが飛ばないことがあります。 チャットでリンクを送った場合、Gmail には何も残りません。ドライブ側の共有設定を直接読むのは、この経路を拾うためです。

④は重複を防ぐためです。同じメールを翌日も拾うと、台帳に同じ開示が2行並びます。

AIへ渡す前に整形する

1. 有効な契約の絞り込み … 終了日が過ぎていても、返還義務が残る契約は含めます
2. ドメインの正規化 … サブドメインを吸収し、フリーメールは除外します
3. 社内メールの除外 … 自社ドメイン宛てと、自動送信の通知を落とします
4. 署名と引用履歴の除去 … 返信の引用部分を落とします
5. 添付情報の取り出し … 名前、拡張子、サイズだけを取ります。中身は読みません
6. 公開範囲の判定 … 「リンクを知っている全員」か「指定したユーザーのみ」かを見ます
7. 記録済み分の除外 … すでに台帳にある開示を落とします
8. 件数の上限 … 1回の呼び出しに載せる開示を10件程度に区切ります

4番目が効きます。 秘密保持契約の相手とのやり取りは、同じスレッドが伸びていきます。引用を残したまま渡すと、最初の1通で渡した図面の名前が、その後の20通すべてで「開示があった」と読まれます。

8番目はスキーマの制限と関係しています。 構造化出力では大きく深くネストされたスキーマが拒否されることがあり、 1件ごとに8項目、各項目が3つの値を持つ以上、配列はすぐ大きくなります。

AIに処理させる

させるのは、メールと共有リンクの情報から次の8項目を取り出すことだけです。

各項目に value、evidence、confidence の3つを持たせます。 evidence は本文からの引用、confidence は explicit（本文にそう書いてある）、inferred（前後から読み取った）、not_stated（書かれていない）です。

inferred と not_stated は必ず人が読みます。 この区別が無いと、機械の推測が本文の事実と同じ重さで台帳に並びます。台帳は後から根拠に使われるものなので、推測と事実が混ざると、無いよりたちが悪くなります。

1行目がこの章の要です。 「目的の範囲外の疑い」は out_of_scope_suspected というフラグにして、根拠になる引用を必ず付けさせます。法務が読むべき行に印を付けるためのもので、判定結果ではありません。 「A部品の共同検討」の契約でB製品の資料が渡っていても、交渉の過程で対象が広がっていたなら範囲内で、その経緯は本文に書かれていません。

指示内容を固定する

あなたは、秘密保持契約にもとづく開示の記録を作る担当者です。
渡された送信メールと共有リンクの情報から、開示の事実を項目ごとに取り出してください。

【判断の基準】
- 「開示があった」とするのは、添付が付いているか、共有リンクを発行したかの
  いずれかがある場合だけです。「来週お送りします」だけの文面は開示ではなく、
  disclosure_occurred を false にしてください。
- 資料の名称は、添付ファイル名か本文にある呼び方をそのまま写してください。

【記載がない項目の扱い】
- 本文に書かれていない項目は value を空文字にし、
  confidence を not_stated にしてください。推測で埋めないでください。
- 前後の文脈から読み取った場合は confidence を inferred にし、
  evidence にその根拠になった一文を引用してください。
- 本文にそのまま書かれている場合だけ confidence を explicit にしてください。
- 受領者が特定できないときは「不明」とし、
  宛先のアドレスから会社名や役職を推測しないでください。

【契約の目的との整合】
- 範囲外だと断定しないでください。判断するのは法務です。
- 疑いがある場合は out_of_scope_suspected を true にし、reason に
  「契約の目的は〜だが、渡した資料は〜である」の形で理由を書いてください。
- 判断がつかない場合も true にしてください。

【厳守事項】
- 日付は YYYY-MM-DD の形式で書き、本文に日付が無い場合は
  メールの送信日を使って confidence を inferred にしてください。
- evidence は本文からそのまま引用し、要約しないでください。
- 渡された情報に無い資料名・相手先名・日付を書かないでください。
- 添付ファイルの中身について書かないでください。

【契約の情報】{contract}
【送信メール】{mail}
【共有リンク】{drive_links}

「記載がない項目の扱い」を3つに分けているのは、空欄を嫌う性質があるためです。 何も言わないと、宛先のアドレスから会社名を組み立て、本文に無い資料の種類を書き、送信日を開示日として断定します。どれももっともらしく、後から間違いだと気づけません。

「範囲外だと断定しない」と「判断がつかない場合も true」は対で書きます。 断定を禁じただけだと、疑わしい行に印が付かなくなります。多めに付けさせて人が外すほうが、絞って見落とすより安全です。

出力形式を固定する

レスポンス形式に MIME タイプ application/json と、次のJSONスキーマを指定します。

{
  "type": "object",
  "properties": {
    "contract_no": { "type": "string" },
    "mail_id": { "type": "string" },
    "disclosure_occurred": { "type": "boolean" },
    "disclosure_date": { "type": "string", "format": "date" },
    "recipient_company": {
      "type": "object",
      "properties": {
        "value": { "type": "string" },
        "evidence": { "type": "string" },
        "confidence": { "type": "string", "enum": ["explicit", "inferred", "not_stated"] }
      },
      "required": ["value", "evidence", "confidence"]
    },
    "documents": {
      "type": "array", "minItems": 0, "maxItems": 20,
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "doc_type": { "type": "string", "enum": ["図面", "仕様書", "見積", "評価データ", "その他"] },
          "medium": { "type": "string", "enum": ["添付", "共有リンク", "持ち出し", "不明"] },
          "link_visibility": { "type": ["string", "null"] },
          "evidence": { "type": "string" },
          "confidence": { "type": "string", "enum": ["explicit", "inferred", "not_stated"] }
        },
        "required": ["name", "doc_type", "medium", "evidence", "confidence"],
        "additionalProperties": false
      }
    },
    "out_of_scope_suspected": { "type": "boolean" },
    "out_of_scope_reason": { "type": "string" }
  },
  "required": ["contract_no", "mail_id", "disclosure_occurred",
               "documents", "out_of_scope_suspected"],
  "additionalProperties": false
}

受領者と開示の目的も、recipient_company と同じ形で並べます。

構造化する理由の1つ目は、日付をそのまま計算に使えることです。 disclosure_date に format の date を指定するので、返ってくるのは日付として解釈できる文字列です。開示日と契約の終了日の差を取れば、返却・破棄を求めるべき先の一覧が機械で作れます。 自由文だと「9月中旬」を解釈する処理が要ります。

2つ目は、confidence を enum で固定できることです。 構造化出力は文字列に対して enum で取りうる値を列挙でき、分類を行わせる用途に使えます。3つの値しか返らないと決まっていれば、「確からしい」「たぶん」といった表記ゆれを後段で受けずに済みます。

3つ目は、additionalProperties を false にすると、スキーマに無い項目が増えないことです。 「範囲外である」と断定する欄を作らなければ、そこに断定は書かれません。

link_visibility は、添付だけの開示では値がありません。型の配列に null を含めて {"type": ["string", "null"]} と書きます。 空文字で代用すると、「公開範囲が取れなかった」のか「共有リンクではない」のかが区別できません。

なお、すべてのJSONスキーマの機能が使えるわけではなく、大きく深くネストされたスキーマは拒否されることがあります。

システムへ連携する

書き込みは下2つだけで、契約台帳・Gmail・ドライブへの書き戻しはありません。元のデータを壊す経路が無いことが、難易度を下げています。

人が確認する

全件、人が確認します。確認せずに台帳へ記録する設計にしません。

1. 開示の事実を確かめる … evidence の引用を読み、実際に資料が渡ったかを見ます。confidence が inferred または not_stated の項目は必ず開きます
2. 目的の範囲外の疑いを判断する … out_of_scope_suspected が true の行について範囲内か範囲外かを決め、結果と理由を台帳に残します
3. 拾えなかった開示を補う … 印刷物や対面で渡したものは拾えません。「人が足した分」として区別できる形で記入します

2番目が、この構成の中心の作業です。 機械は印を多めに付け、人が外します。外すときの根拠は契約書の文言と交渉の経緯で、どちらもメール本文には書かれていません。

確認の目標は1件5分、補足の記入が3分です。 それ以上かかるなら evidence が長すぎるか、印の付き方が粗すぎます。

例外に対処する

最後の行を軽く見ないでください。 記録が無いことと開示が無かったことは別です。「開示なし」と書かれた瞬間、それは調べ終わったという意味になります。

記録を残す

• 拾った送信メールのID、件名、送信日時、宛先ドメイン、添付ファイル名
• 共有リンクのファイルID、発行日、共有先、公開範囲
• 生成AIに渡した内容と、返ってきたJSONの全文
• 担当者が out_of_scope_suspected を外した行と、外した理由
• 「自動で拾った分」と「人が足した分」の区別
• 返却・破棄の依頼を送った日、宛先、相手からの回答と回答日

4つ目がたまると、どういう資料が目的の範囲を出やすいのかが分かります。5つ目が無いと、台帳がどこまで網羅しているのかを誰も言えなくなります。