新しい技術の扱いを決めるときに、社内のノウハウ登録台帳と過去の「出願か秘匿か」の判断記録から似た技術を探し、当時の判断と理由を根拠付きで知財の担当に返す

処理の起点を決める

知財部の受付フォームに、技術の扱いの検討票が登録されたことを起点にします。 検討票は月に30件ほどで、届いた順に担当が決まります。担当が決まった時点で検索を動かし、担当者の権限で探します。 担当が決まる前に動かすと、誰の権限で探したのかが曖昧になります。

担当者が検討票に補足を書いたときにも、もう一度動かします。 研究所の検討票は「焼成条件の改良」のように短いことが多く、担当者が依頼元に聞いて「粒界に添加物を偏らせる」と書き足すと、当たる記録が変わります。 2回目以降は、前の結果を残したまま新しい結果を並べます。

索引の更新は別に動かします。 知財委員会で判断が決まり、判断票が確定したときに、その1件だけを索引に入れ直します。ノウハウの登録票も、登録や閲覧範囲の変更が承認されたときに入れ直します。閲覧範囲の変更は、検索に反映されるまでの間が最も危ないので、変更の承認と同時に入れ直します。

入力データを集める

質を決めるのは、判断記録の「理由」の書き方です。 「秘匿とする」の1行だけでは、今回にも当てはまるかを比べられません。判断票に「理由」の欄を置き、製品から分かるか、他社の実施を外から確かめられるか、技術の寿命はどれくらいかのように、何を根拠にしたかを書く決まりにします。

見直しの時期も必ず書かせます。 秘匿にした技術でも、数年たてば製品の分析で分かるようになることがあります。見直しの時期が過ぎた判断は、今回の参考にする前に「見直し前」と印を付けます。

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

判断記録は、知財委員会で確定したものだけを索引に入れます。 検討中の判断票には、あとで取り消された理由や、結論が変わる前の議論が残っています。確定の前は、検索の対象にしません。

閲覧の属性は、段落の1つずつに持たせます。 判断票には、関係する登録票の管理区分を引き継がせます。判断票だけが「秘」で、そこに書かれた技術の登録票が「極秘」というずれがあると、判断票の検索から極秘の中身が漏れます。 関係する登録票の中で最も厳しい区分を、判断票の区分にします。

線引きは、クエリの中ではなくロールに置きます。 公式のドキュメントでは、ドキュメントレベルセキュリティのクエリに ${user.name}、${user.roles}（バックエンドロールの一覧）、${attr.<種類>.<名前>}（ユーザーの属性） などの変数を使え、属性による制御では terms_set クエリと組み合わせ、索引側の属性の項目を keyword 型にする必要があるとされています。検索のプログラムが絞り込みを書き忘れても、ロールの側で絞られるので、線引きが1か所にまとまります。

AIへ渡す前に整形する

1. 見出しで段落に分ける … 登録票は概要・関係する製品・管理の方法、判断票は結論・理由・見直しの時期で分け、段落ごとに種類を付けます
2. 閲覧の属性を付ける … 段落ごとに管理区分と閲覧を許す部署を keyword の項目に入れます
3. 埋め込みを作る … 段落の本文から、Amazon Titan Text Embeddings V2 でベクトルを作ります
4. 人名を外す … 発明者や委員の個人名は、探すのに要りません。部署名に置き換えてから索引に入れます
5. 言葉をそろえる … 製品の型番と社内の呼び名の対応表を作り、両方で当たるようにします

3番目は、段落ごとに作るのが前提です。 公式のドキュメントでは、Titan Text Embeddings V2 は最大8,192トークンまたは50,000文字を受け付け、出力は1,024次元（既定）、512、256から選べます。長い文書も受け付けますが、検索に使うときは段落や節のような論理的な単位に分けることが勧められています。 日本語は多言語対応の一覧に入っていますが、英語に最適化されたモデルで、多言語は「100以上の言語でプレビュー」とされています。索引を作る前に、自社の判断記録20件ほどで当たり方を確かめます。

埋め込みのモデルは、OpenSearch の ML コネクタで呼びます。 公式のドキュメントでは、OpenSearch Service から Amazon Bedrock などへつなぐときはIAM ロールを用意し、きめ細かなアクセス制御を使っている場合は ml_full_access のロールにそのIAMロールを対応付ける手順が示されています。モデルを意味検索に使うときは、登録のときに model_config を入れ、embedding_dimension をモデルの出力の次元に合わせます。

AIに処理させる

検索そのものは OpenSearch が行います。 言葉の一致と意味の近さを1つの問い合わせで組み合わせます。

{
  "_source": { "excludes": ["embedding"] },
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "text": "{検討票の概要と補足}" } },
        { "neural": { "embedding": { "query_text": "{検討票の概要と補足}", "model_id": "{埋め込みのモデル}", "k": 50 } } }
      ]
    }
  }
}

2つの点数は、検索パイプラインでそろえて足し合わせます。 公式のドキュメントでは、hybrid クエリは検索時に動く検索パイプラインを必要とし、normalization-processor が各クエリの点数を共通の尺度に直してから組み合わせるとされています。例では正規化に min_max、組み合わせに arithmetic_mean を使い、weights で各クエリの重みを割合で指定しています。

意味の近さを重く置くのは、第3章の（a）のためです。 「粒界制御」と「結晶粒の成長抑制」は、言葉では当たらなくても意味では近くなります。言葉の一致は、型番や材料名がそのまま一致する記録を確実に拾う受け皿にします。

閲覧の線引きは、この問い合わせには書きません。 担当者の権限で問い合わせると、ドキュメントレベルセキュリティがロールのクエリで絞ります。問い合わせの側で絞ると、絞り忘れた1回で極秘の記録が出ます。

生成AIにさせるのは、当たった記録ごとに4つの見出しで並べることだけです。

4行目が、この構成の線引きです。 生成AIは「ほかにも関連する極秘の登録があるかもしれません」と書きがちで、それ自体が、見られない記録があることを知らせてしまいます。 渡した記録の外には触れさせません。

指示内容を固定する

あなたは知財部で、新しい技術を出願するか秘匿するかを検討する担当のために、
過去の判断記録を整理する立場です。
渡した検索結果（ノウハウの登録票と判断票の段落）だけを根拠にしてください。

【今回の検討票】技術の概要：{summary}／関係する製品：{products}／工程：{process}
【担当者の補足】{notes}
【今日の日付】{today}

【やること】
当たった記録ごとに、次の4つを短く書いてください。
1. 当時の結論：結論と判断日
2. 判断の理由：理由の段落から、何を根拠にしたか
3. 今回との共通点と違い：今回の技術と、記録の技術の重なりとずれ
4. 見直しの時期：記録に書かれた時期と、今日の日付から見て過ぎているか

【厳守事項】
- 検索結果に書かれていないことを書かないでください。
  理由が書かれていなければ「理由の記載なし」としてください。
- 今回の技術を出願すべきか秘匿すべきかを書かないでください。
- 渡した検索結果のほかに関連する記録があるかどうかに触れないでください。
- 管理区分（極秘・秘）を判断したり、変えるよう勧めたりしないでください。
- 人名を書かないでください。部署名で書いてください。
- 近くない記録は、無理に関連付けず「関連が薄い」と書いてください。
- 全体で、最も近い記録から順に5件までにしてください。

「理由の記載なし」を明記しないと、結論から理由を作ります。 「秘匿」と書かれた判断票を渡すと、生成AIは秘匿にする一般的な理由をもっともらしく書き足し、それが当時の判断の理由として読まれます。 書かれていないことは、書かれていないと返させます。

「ほかの記録に触れない」は、閲覧の線引きを文章の側でも守るためです。 検索の段階で絞っていても、生成AIの一言で線引きの外の存在が伝わることがあります。

出力形式を固定する

生成AIへは、検索結果のブロックで渡します。 公式のドキュメントでは、search_result のブロックに source・title・content を入れると、自社の文書を引用付きで答えます。 source に登録番号か案件番号、title に技術名と判断日、content に段落を1つずつのテキストブロックで入れます。引用は search_result_location の形で返り、cited_text は引用したブロックの全文です。引用はテキストブロックの単位で付き、引用の設定はリクエストの中のすべての検索結果でそろえる必要があります。

返った文章と引用から、検討票に添える前に次の形に組み立てます。

{
  "request_id": "",
  "searched_as": { "user_department": "", "roles": [] },
  "matches": [
    {
      "record_id": "",
      "record_type": "knowhow | decision",
      "title": "",
      "decided_on": "",
      "conclusion": "patent | secret | neither | pending",
      "reason": { "text": "", "cited_text": "" },
      "common_points": "",
      "differences": "",
      "review_due": "",
      "review_overdue": false
    }
  ],
  "no_match": false
}

1つ目の理由は、searched_as で誰の権限で探したかを残せることです。 同じ検討票でも、担当者が変われば当たる記録が変わります。「この結果は誰の目に見える範囲か」を、結果と一緒に持たせます。

2つ目は、review_overdue を見出しにできることです。 見直しの時期が過ぎた判断は、結果の先頭に「見直し前の判断を含む」と出します。過ぎた判断の理由は、いまは当てはまらないかもしれません。

3つ目は、conclusion を記録の値から入れることです。 結論は判断票の項目にそのまま入っているので、生成AIの文章からではなく、索引の値から入れます。

システムへ連携する

台帳と判断記録へは書き込みません。 見直しの時期が過ぎた判断が見つかっても、見直すかどうかは知財委員会が決めます。

ロールの対応付けは、台帳の閲覧範囲と同じ表から作ります。 公式のドキュメントでは、複数のロールのドキュメントレベルセキュリティのクエリは OR で組み合わされ、またドキュメントレベルセキュリティは読み取りだけを制限し、書き込みは制限しないとされています。担当者のロールは検索だけの権限にし、書き込みの権限を持たせません。

人が確認する

1. 根拠の確認（担当者） … 結果の引用から登録票と判断票を開き、理由の段落を確かめます
2. 今回との違いの確認（担当者） … 「今回との違い」に書かれた点を、依頼元に聞いて確かめます
3. 見直し前の判断の扱い（担当者） … 見直しの時期が過ぎた判断は、理由がいまも当てはまるかを別に確かめます
4. 当たり外れの記録（担当者） … 検討が終わったら、結果の記録が役に立ったかを印で残します

目安は、1件あたり20分です。 根拠の記録を2〜3件開き、理由の段落を読み、検討票と比べる時間です。全部の候補を読む必要はありません。

担当者が見られない記録を、別の担当者に頼んで見せてもらう運用は作りません。 必要なら、台帳の正規の手続きで事業部の了解を取ります。検索の結果を他人の権限で取り直すと、線引きを置いた意味がなくなります。

例外に対処する

2行目が、この構成でいちばん大事な止め方です。 ロールが引けないときに、仕組みの持ち主の権限で代わりに探すと、その1回だけ線引きの外の記録が担当者に届きます。 引けなければ止めます。

記録を残す

• 受け取った検討票と補足、担当者と担当が決まった時刻
• 検索に使った担当者のロール、返した記録の番号と点数
• 生成AIに渡した段落の番号と、返った文章と引用
• 担当者が付けた当たり外れの印
• 閲覧範囲の変更と、索引に反映した時刻

検索の記録は、それ自体を極秘の扱いにします。 どの技術を検討しているかと、どの記録に当たったかが分かるからです。記録を見られるのは知財部の管理者だけにします。

最後の行は、線引きが崩れていないかを確かめる材料です。 閲覧範囲の変更が承認されてから索引に反映されるまでの時間を、毎月数えます。