購読している文献データベース・規格の利用条件を、使う前に確かめられるようにする

処理の起点を決める

利用者が Teams のチャットでエージェントに話しかけたときを起点にします。

エージェントを、研究者が日常的に使うチャネルに公開してください。 研究所ごとのチームに入れておくと、「これ聞いていい？」という感覚で使われます。専用のチャネルを新設すると、そこを見に行く習慣ができません。

もう1つの起点として、契約の更新日が近づいたときに、条件の差分を検出する処理を置きます。更新後の契約書を取り込み、変わった項目（同時アクセス数、共有の範囲、転載の可否）を担当者へ知らせます。 これがBeforeの（f）への対処です。

利用者への周知は、更新の直後ではなく、その条件に関わる照会が来たときに行います。 「今年度から社外への配布ができなくなりました」と全社メールで流しても読まれません。照会のたびに現行の条件を答えるほうが、確実に伝わります。

入力データを集める

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

契約条件の索引が、この構成の土台です。 契約書のPDFのまま検索させないでください。42契約を、次の形に構造化します。

「原文」の列を必ず持ってください。 回答に添える根拠は、構造化した値ではなく原文です。構造化の過程で意味が変わっている可能性があるため、利用者が原文で確かめられる形にします。

42契約を一度に作る必要はありません。 照会の多い上位10契約で、件数の7割を占めることが多いはずです。そこから始めてください。

資料マスタ： 利用者は正式名称を使いません。「Nature」「ネイチャー」「あのジャーナル」と言います。略称と表記ゆれを対応表に入れておかないと、契約を特定できません。 これも運用しながら足していきます。

部署と人数： 「研究部の30名で共有したい」という照会に対し、同時アクセス数5の契約なら注意が要ります。人数の情報があると、判定に厚みが出ます。

構造化の作業は、契約書を読める人が行ってください。 英文の契約条項を構造化する作業を、生成AIに任せたくなります。下書きとして使うのは構いませんが、そのまま索引にしないでください。 条件の読み違いが索引に入ると、以後すべての回答が誤ります。知財部の担当者が1条項ずつ確かめる工程を、必ず挟んでください。

1契約あたりの構造化には、1〜2時間かかります。 10契約なら15時間程度。まとまった時間が必要なので、日常業務の合間ではなく、期間を確保して進めてください。

構造化の粒度で迷ったら、実際の照会から逆算してください。 過去3か月の照会を並べ、「この質問に答えるには、契約書のどの情報が要るか」を書き出します。そこに出てきた項目だけを構造化すれば足ります。契約書の全条項を構造化する必要はありません。 支払条件や準拠法は、この用途では使いません。

AIへ渡す前に整形する

1. 契約書の版の特定 … 同じ事業者の契約書が複数ある場合、現行のものを特定します。ファイル名に年度を入れる運用を先に決めてください
2. 条項の抽出 … 契約書から「Permitted Uses」「Prohibited Uses」「Authorized Users」に当たる節を取り出します。英文と和文が併記されている契約は、両方を保持します
3. 利用者の言葉への対応づけ … 「社内で回す」→「社内共有」、「講演で使う」→「転載」、「システムに入れる」→「システムへの取り込み」といった対応表を作ります。30語程度から始めてください
4. 索引の版の管理 … 契約が更新されたら索引も更新します。索引の版と契約の版がずれていないかを、回答の前に確認します
5. 判定に使わない条項の除外 … 支払条件、準拠法、紛争解決の条項は、この用途では使いません。索引から外して検索の精度を上げます

AIに処理させる

2つの工程に分けます。

照会を整える工程（Copilot Studio のエージェント）：

条件に当てはめる工程：

契約に書かれていない使い方について、答えを作らせません。 「一般的にはこの範囲なら問題ないでしょう」という回答は禁止です。「この契約には定めがありません。知財部へお問い合わせください」と返させます。

法令上の適否（著作権法の引用に当たるか等）も判定させません。 この構成が扱うのは契約の条件だけです。法令の解釈は別の判断であり、担当者と法務部が行います。

指示内容を固定する

照会を整える側では、Copilot Studio のトピックとして組みます。

【対話の方針】
- 最初に次の3点を伝えてください。
  (1) 購読契約の利用条件についてお答えすること
  (2) 契約に定めのない使い方は知財部へ回すこと
  (3) 著作権法上の判断（引用に当たるか等）はここでは扱わないこと
- 次の4点が揃うまで質問してください。ただし一度に聞くのは2点までにしてください。
  ・資料名（ジャーナル名、データベース名、規格番号など）
  ・使いたい方法（社内で共有／印刷／社外へ提供／講演や論文へ転載／システムへ取り込み）
  ・範囲（何人、どの部署、社外なら相手先の種類）
  ・時期（いつまでに必要か）
- 利用者が資料名を曖昧にしか言えない場合、資料マスタの候補を3つまで示して選ばせてください。
  **推測で1つに決めないでください。**
- 「たぶん大丈夫だと思います」のような曖昧な返答をしないでください。
- 利用者を評価しないでください。「その使い方は不適切です」と言わないでください。
  条件に合わない場合は「この契約では◯◯までとなっています」と事実を伝えてください。

条件に当てはめる側の指示は次のようになります。

あなたは購読契約の利用条件を案内する担当者です。
下の照会について、契約条件の検索結果に基づいて可否を判定してください。

【厳守事項】
- 判定は、下の「契約条件の検索結果」に含まれる条項のみを根拠にしてください。
  **一般的な購読契約の慣行や、他の事業者の条件で補わないでください。**
  該当する条項がない場合は status を "not_specified" にし、
  「この契約には定めが見当たりません」と回答してください。
  **推測で可否を答えないでください。**
- 根拠として、該当する条項の**原文をそのまま**引用してください。
  要約や翻訳をしないでください。英文であれば英文のまま示し、
  その下に参考訳を付ける形にしてください。
- 次の場合は status を "needs_check" にし、理由を書いてください。
  ・複数の条項が関係し、どちらが優先するか読み取れない
  ・照会された範囲（人数・部署）が、対象ユーザーの定義に当たるか判断できない
  ・用語の解釈が分かれる（「internal use」に関係会社を含むか等）
  **迷ったときに "permitted" にしないでください。**
- 付帯条件（出所の表示、点数の上限、事前連絡の要否）があれば、
  conditions に漏れなく列挙してください。
- 著作権法その他の法令に照らした判断を書かないでください。
- 契約の見直しや、別の契約への変更を提案しないでください。

【照会の内容】
{inquiry}

【特定された契約】
{contract_info}

【契約条件の検索結果（条項の原文つき）】
{retrieved_terms}

【過去の類似照会と回答（上位3件）】
{past_inquiries}

【照会元の部署と人数】
{department_info}

「迷ったときに permitted にしない」の1行が、この構成でもっとも重要です。 誤って「使ってよい」と答えると、契約違反が起きます。答えられないことを正直に返すほうが、間違った許可を出すより安全です。

「原文をそのまま引用する」も必須です。 購読契約は英文が多く、要約すると意味が変わります。「for internal research purposes」を「社内利用のため」と訳すと、research の限定が落ちます。 原文を示したうえで参考訳を添える形にしてください。

出力形式を固定する

{
  "inquiry_id": "",
  "status": "permitted | prohibited | conditional | not_specified | needs_check",
  "contract": {
    "contract_no": "",
    "vendor": "",
    "resource_name": "",
    "contract_type": "",
    "valid_until": ""
  },
  "use_type": "社内共有 | 印刷 | 社外提供 | 転載 | システム取り込み",
  "matched_clause": {
    "clause_ref": "",
    "source_text": "",
    "reference_translation": ""
  },
  "conditions": [],
  "needs_check_reason": "",
  "scope_note": "",
  "concurrent_access_note": "",
  "past_inquiry_refs": [],
  "answer_text": "",
  "index_version": ""
}

JSON Schema を指定して出力を固定します。Claude API を使う場合、output_config の format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。Copilot Studio 側で完結させる場合も、出力の項目を同じ形にそろえておくと、記録の作りが揃います。

index_version を持たせることに実務上の意味があります。 契約は更新されます。「この回答は2026年度の契約条件に基づく」ことが記録に残っていないと、後から検証できません。

scope_note は、照会された範囲が対象ユーザーの定義に当たるかについての注記です。 「関係会社の従業員は対象ユーザーに含まれません」といった内容が入ります。社内共有の可否は、人数だけでなく「誰が」で決まることが多くあります。

concurrent_access_note は、同時アクセス数の制約についての注記です。 「30名で共有したい」という照会に対し、同時アクセス数が5なら、共有そのものは可でも運用上の制約があります。可否だけでなく、この注記があると実務で使えます。

システムへ連携する

回答は、Teams のチャットで返します。構成を決めておいてください。

【ご照会】電子ジャーナルA の論文を、研究部30名の勉強会で配布したい

【回答】この契約では、社内の対象ユーザー間での共有は認められています。
     ただし、下の2点にご注意ください。

【根拠】契約 C-2026-018 第4条（Permitted Uses）
  "Authorized Users may share individual articles with other Authorized Users
   within the Subscriber's organization for internal research purposes."
  （参考訳：許諾利用者は、購読者の組織内の他の許諾利用者との間で、
   社内の研究目的のために個々の論文を共有することができます）

【ご注意】
  1. 対象ユーザーは「国内の全従業員（派遣社員を含む）」です。
     関係会社の方が参加される場合は対象外となります（第2条）。
  2. 同時アクセス数は5です。共有そのものは可能ですが、
     30名が同時に本文へアクセスすることはできません。

【この回答について】2026年度の契約条件（索引 v2026.04）に基づいています。
ご不明な点は知財部（情報管理担当）へお問い合わせください。

根拠の原文を必ず含めてください。 これがあることで、利用者が自分で確認できます。「なぜその答えなのか」が分かると、次から似た判断は自分でできるようになります。

照会記録は、Microsoft Lists へ追記します。 列は次の構成です。

not_specified と needs_check の記録が、契約交渉の材料になります。 同じ種類の使い方が繰り返し「定めがない」になるなら、次の更新で条項の追加を交渉する材料になります。

人が確認する

permitted と prohibited は人が確認せず、conditional の一部・not_specified・needs_check を担当者が対応します。

全件確認にすると、この構成の効果が消えます。ただし、次の2つを必ず入れてください。

1. 根拠の原文を回答に含める … 照会者が自分で検証できる
2. 回答のフィードバック … 「解決した」「違う気がする」を返せるボタンを付ける

2つ目が安全装置です。 誤った回答が出ていても、照会者が「違う気がする」と返せれば、担当者が気づけます。

担当者が対応する照会では、次の設計が効きます。

• not_specified を最上部に集める（契約の抜けの可能性）
• needs_check の理由ごとにまとめる（同じ論点が繰り返されていれば索引の問題）
• status が prohibited の照会を別に集める（なぜその使い方をしたかったのかに、業務上の必要がある）
• 「違う気がする」のフィードバックが付いた回答を毎週見る

3つ目が見落とされがちです。 「社外へ提供したい」という照会が禁止と答えられて終わると、利用者は困ったままです。業務上その必要があるなら、別の手段（事業者への個別許諾の申請、別の資料の購入）を担当者が案内すべきです。 この一覧は、その気づきの入口になります。

「違う気がする」のフィードバックは、必ず毎週見てください。 週に1回、5分で済みます。放置すると、同じ誤答が繰り返されます。 フィードバックが付いた回答は、索引のどこが原因だったかを特定し、その場で直してください。

誤答が出たときの対応も、あらかじめ決めておいてください。 すでに回答済みの照会者へ訂正を伝えるか、伝えないか。「許可」と答えたものが実は禁止だった場合は、必ず伝える必要があります。 逆の場合（禁止と答えたが実は許可だった）も、利用者が困っている可能性があるため伝えるべきです。この判断を都度するのではなく、方針として決めておきます。

回答の履歴は、照会者にも見える形にしてください。 「前に聞いたけど答えを忘れた」という照会が、一定数あります。自分の過去の照会を自分で見られれば、その分の照会が減ります。

例外に対処する

記録を残す

この記録は、契約に沿った利用をしていたことを示す資料になります。

• 照会の内容と、回答した可否・根拠の条項
• 判定に使った索引の版
• not_specified と needs_check の理由
• 担当者が判断した案件と、その判断の根拠
• 照会者からのフィードバック
• 契約更新時の条件の差分と、その通知の記録

「索引の版」が特に重要です。 契約は更新されます。「その時点ではこの回答が正しかった」ことを示せる状態にしてください。

not_specified の集計を、契約の更新前に見てください。 「講演への転載についての定めがない契約が8件ある」と分かれば、更新交渉でその条項を入れてもらう材料になります。この構成のもう1つの価値が、ここにあります。

照会者の氏名を記録に残すかは、運用として決めてください。 誰が何を使おうとしたかの記録は、利用の監査には役立ちますが、「聞くと記録される」と思われると照会が減ります。 集計の目的なら部署単位で足ります。