社員から届く「この資料を社外に出してよいか」「展示会・論文で話してよいか」の質問に、営業秘密の管理規程・発表前の手続き・秘密保持契約の一覧を根拠にチャットで答え、判断の要るものを知財部へ回す

処理の起点を決める

社員がチャットで質問を送ったことを起点にします。 社内ポータルに知財のチャットを置き、社員の ID を付けて中継プログラムに渡します。メールで届いた質問も、知財部の担当者がチャットへの案内を返す運用にし、入口を一つに寄せます。

資料を送る前に聞いてもらうことが目的です。 送った後に聞かれても、できることは限られます。社内ポータルの資料の置き場と、メールの送信の画面に「社外に出す前に知財チャットで確認」の案内を置きます。

回された質問には、締め切りがあります。 発表の質問なら事前審査の締め切り、資料の提供なら社員が書いた提出の予定日です。知財部の待ち行列は、この日付の近い順に並べます。

入力データを集める

質を決めるのは、規程と手引きの「区分ごとの手続きの表」です。 規程が文章だけで書かれていると、どの区分の資料をどの相手に出すときにどの手続きが要るかが、検索で一つの箇所に当たりません。区分（3つ）×相手（顧客・共同研究先・仕入先・展示会や論文）の表にしておくと、回答の根拠がその表の1行になります。

過去の質疑は、知財部が選んだものだけを入れます。 個別の相手先や未発表の技術が書かれた質疑を入れると、ほかの社員の質問の回答に、その内容が根拠として出ます。

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

規程・手引き・事前審査の手順は、データストアに入れ、メタデータで絞り込みます。 公式のドキュメントでは、絞り込みは ANY() で値のいずれかとの一致を、<・<=・>・>=・= で数値や日時の比較を書け、AND／OR で組み合わせ、- か NOT で否定できます。日時は ISO 8601 の文字列で書きます。絞り込みに使う項目は、スキーマで索引可能にしておく必要があります。

秘密保持契約の台帳は、データストアに入れません。 中継プログラムが、相手先の名前で台帳を引き、有無・目的・範囲・期限の4つだけを回答の材料にします。台帳をデータストアに入れると、ほかの相手先の契約の内容が検索の結果として出るおそれがあります。

相手先の名寄せは、台帳の側の別名の一覧で行います。 社員は「A社」「A社の研究所」「旧B社」などで書きます。台帳に正式な社名・略称・旧社名・グループ会社の別名の一覧を持たせ、中継プログラムがそこから引きます。一つに決まらないときは、選択肢で社員に選んでもらいます。

回答に使う検索結果の件数は、少なめに絞ります。 公式のドキュメントでは、answer メソッドが回答に使う検索結果は既定で10件、最大で25件です。規程・手引き・手順は合わせても数十の文書なので、件数を増やすと関係の薄い過去の質疑まで根拠に混ざります。 規程と手引きを先に、過去の質疑を後に並べるため、doc_type で絞った検索を2回に分けることも考えます。

聞き返しの往復は、同じセッションで続けます。 前の回の応答に含まれるセッションの ID を次の質問に付けると、会話の続きとして扱われます。相手先と区分を聞き返した後の答えが、最初の質問とつながった形で検索に渡ります。

AIへ渡す前に整形する

1. 質問の種類を判定する … 資料の提供、発表、区分の扱いのどれかを決めます。決まらなければ選択肢で聞き返します
2. 足りない情報を聞き返す … 相手先、資料の秘密区分、目的、予定日のうち、書かれていないものを選択肢で聞きます
3. 相手先を名寄せする … 台帳の別名の一覧で正式な相手先に寄せます
4. 契約を確かめる … 有無・目的・範囲・期限を引き、有効／期限切れ／目的が違う／無し のどれかにします
5. 締め切りを計算する … 発表の日から事前審査の締め切りの日付を出し、過ぎていれば回す条件にします
6. 個人の情報と技術の中身を外す … 質問の本文に書かれた未発表の技術の詳細は、検索に渡す前に「（技術の内容）」に置き換えます

2番目で、区分を自由記述にしないでください。 「たぶん社外秘」と書かれても判定できません。「資料に付いている表示を選んでください：極秘／社外秘／社内限り／表示が無い」と選択肢で聞きます。表示が無い資料は、それだけで回す条件にします。区分の付け忘れは、規程の上でいちばん危ない状態だからです。

6番目は、知財のチャットに技術の中身を書かせないためです。 社員は丁寧に、発表しようとしている技術の詳細を書いてきます。チャットの記録に未発表の技術が残るので、検索に渡す前に置き換え、元の本文は知財部だけが見られる記録に分けます。

AIに処理させる

回答を作るのは answer メソッドで、中継プログラムが前処理の結果を前置きの指示として渡します。

1行目がこの構成のいちばん大事な線引きです。 社外秘の資料で、有効な契約がある相手なら、規程の上では手続きを踏めば出せます。それでもチャットが「出してよい」と書けば、社員は承認の申請を飛ばします。 答えるのは「出すための手続き」までです。

指示内容を固定する

あなたは知財部の窓口として、社員からの「社外に出してよいか」
「発表してよいか」の質問に答えます。検索結果の規程・手引き・
手順だけを根拠にしてください。

【質問の種類】{question_type}
【資料の秘密区分】{classification}
【相手先】{counterparty}
【秘密保持契約の確認結果】{nda_status}（プログラムが台帳から引いた値）
  有効／期限切れ／目的が違う／無し
【予定日】{planned_date}  【事前審査の締め切り】{review_deadline}

【答え方】
1. 最初に、この質問に当たる手続きの名前を書く
2. 手続きの順序を番号付きで書く（申請の窓口、承認者、開示の記録）
3. 根拠にした規程の条と手引きの箇所を示す
4. 発表なら、事前審査の締め切りの日付を書く

【厳守事項】
- 「出してよい」「問題ない」と書かないでください。
  「規程では、次の手続きを経て出すことになっています」と書いてください。
- 秘密保持契約の有無は、渡した確認結果だけを使ってください。
  あなたが契約の有無を推測しないでください。
- 資料の区分を判断しないでください。区分は社員が答えた値を使ってください。
- 規程に根拠が見つからないときは、答えずに
  「知財部の担当者に確認します」とだけ書いてください。
- 規程に書かれていない例外や、抜け道を案内しないでください。
- 未出願の技術を発表してよいかには答えないでください。

「出してよいと書かない」を明記しないと、必ずそう書きます。 社外秘・有効な契約・目的が一致、という条件がそろえば、規程を読む限り出せるからです。手続きを経て出す、という書き方に言い換えさせることで、承認の申請が省かれないようにします。

「抜け道を案内しない」も同じ理由です。 社員は「区分の表示を外して渡せばよいか」と聞いてくることがあります。規程の文言の隙間を答えに使わせず、そうした質問は知財部へ回します。

この指示は、answer メソッドの promptSpec の preamble に入れます。 公式のドキュメントでは、前置きの指示で回答の口調・文体・長さを調整できるとされています。

出力形式を固定する

中継プログラムは、次の形にまとめてチャットに返し、記録にも残します。

{
  "session": "projects/.../sessions/...",
  "question_type": "provide",
  "classification": "confidential",
  "counterparty": { "input": "A社の研究所", "resolved": "A株式会社", "nda_status": "有効",
                    "nda_purpose": "共同研究", "nda_expiry": "2027-03-31" },
  "answer": "",
  "citations": [{ "doc": "営業秘密管理規程", "section": "第12条" }],
  "grounding_score": 0.0,
  "routed": false,
  "route_reason": "",
  "deadline": "2026-10-20"
}

1つ目の理由は、nda_status を回答の外に置けることです。 契約の確認の結果は、生成AIが書いた文章の中ではなく、プログラムが引いた値として別の項目に残ります。 後から「チャットは契約があると言った」と問題になったとき、どの値で答えたかが確かめられます。

2つ目は、grounding_score で返すか回すかを機械的に決められることです。 answer メソッドは、回答の文ごとと回答全体の根拠の強さを返せます。閾値に届かない回答は、filteringLevel を FILTERING_LEVEL_HIGH にすると返らず、根拠が弱いために答えなかった理由（LOW_GROUNDED_CONTENT）が返ります。関係のある内容が無いときは NO_RELEVANT_CONTENT です。どちらも、知財部へ回す条件にします。

3つ目は、route_reason で回した理由を残せることです。

システムへ連携する

契約管理の台帳には書き込みません。 契約が無い、期限が切れていると分かっても、締結や更新の手続きは法務部がこれまでどおり行います。

データストアの閲覧の範囲は、作成のときに決めます。 公式のドキュメントでは、データソースのアクセス制御はプレビューの機能で、データストアを作るときにしか設定できず、後から有効にも無効にもできません。 知財部の内部の運用メモを同じデータストアに入れるなら、作る時点で閲覧の範囲を設定します。Microsoft Entra ID などの社内の ID 基盤は、Workforce Identity Federation でつなげます。

人が確認する

チャットの回答は、社員にそのまま返します。 知財部が確かめるのは、回された質問と、回答の記録の抜き取りです。

1. 回された質問に答える … route_reason を見て、締め切りの近い順に答えます
2. 毎週、回答の記録を抜き取って読む … 返した回答から20件を選び、「出してよい」と読める書き方が無いかを確かめます
3. low_grounded と no_relevant を数える … 規程に根拠が見つからない質問が多い分野は、規程と手引きに書き足す候補です
4. 規程を改定したら、版を差し替える … valid_to を付けて古い版を絞り込みから外します

2番目を省かないでください。 指示で禁じていても、言い換えで「出して差し支えありません」のような書き方が出ることがあります。見つけたら前置きの指示に例として書き足します。

目標は、1件6分です。 200件をならした時間で、チャットだけで終わる質問はほとんど時間がかからず、回された質問に知財部が答える時間と、抜き取りの確認の時間がここに入ります。

例外に対処する

2行目の書き方に注意してください。 台帳に無いのは、契約が無いからとは限りません。グループ会社の名前で結んでいる、社名が変わった、台帳への登録が遅れていることもあります。「台帳で見つからない」と伝え、法務部が確かめます。

記録を残す

• 質問の本文（技術の内容は置き換えた後のもの）と、聞き返しの答え
• 相手先の名寄せの結果と、契約の確認の結果
• answer メソッドに渡した絞り込みと前置きの指示、返ってきた回答と引用・根拠の強さ
• 回した質問と route_reason、知財部の回答
• 抜き取りで見つけた不適切な書き方と、指示の修正
• 規程に根拠が見つからなかった質問の分野別の件数

最後の行が、規程を良くする材料になります。 社員がどこで迷っているかが、毎月の件数として見えます。同じ分野の質問が続くなら、規程か手引きにその場面の手続きが書かれていません。 書き足せば、回される質問がその分減ります。