営業秘密として守る文書を仕分けて、表示とアクセス記録の状態を点検する

処理の起点を決める

毎週、新規作成・更新された文書を抽出することを起点にします。既存12万件を一度に処理しません。

この順番を守ることが、この構成でもっとも重要な設計です。 全件を対象にすると、初回に数万件の指摘が出て、そこで止まります。新しく作られる文書から先に正しい状態にすれば、区分の付いていない文書の割合は自然に下がります。 既存分は、その後で古いものから順に回します。

抽出の量は、確認できる件数で決めてください。2名で月800件なら、週200件です。指摘が出る件数は、そのうち2〜3割です。

もう1つの起点として、アクセス権限が変更されたときに、その場所の文書を再点検する形が考えられます。フォルダの共有範囲が広がったのに、中の文書が極秘のまま、という状態を検出できます。これは運用が回り始めてから足してください。

入力データを集める

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

文書ファイル： ストレージのAPIで取得します。すべてのファイル形式を対象にしないでください。 Office 文書、PDF、図面の形式に絞り、画像ファイルや動画は対象外にします。対象を広げると、処理時間も費用も跳ね上がります。

Document Intelligence のカスタム分類モデルは、PDF と画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）に加えて、Word・Excel・PowerPoint にも対応します。PDF と TIFF は最大2,000ページ、有料プランでのファイルサイズは500MBまでです。 分類のトレーニングデータは合計2GB・最大25,000ページまでです。

アクセス権限： ここの取得がもっとも手間のかかる部分です。SharePoint のサイト・ライブラリ・フォルダのどの階層で権限が設定されているかを追う必要があります。「継承している」場合は、親をたどって実際の範囲を出します。

権限の「範囲」は、人数で見るのが実務的です。「このフォルダは全社1,500名が見られる」「このフォルダは設計部40名だけ」という粒度で十分です。 誰が見られるかの完全なリストは不要です。

閲覧記録： 監査ログから、直近90日の閲覧者を取得します。見るのは「区分に見合わない範囲からの閲覧があったか」だけです。 個人の閲覧行動を評価する目的で使わないでください。運用の目的が変わると、社内の受け止め方が変わります。

文書種類のラベル付きサンプル： 種類ごとに5〜20件を用意します。ここが準備の山場です。 ただし、一度作れば使い回せます。分類モデルは増分トレーニングに対応しており、既存のクラスに新しいサンプルを追加したり、新しいクラスを追加したりできます。

AIへ渡す前に整形する

1. 対象外の除外 … テンプレート、社内報、公開済みの製品カタログ、他社から受領した資料を除きます。受領資料は自社の営業秘密ではなく、相手先との秘密保持の対象です。別の管理が要ります
2. 重複の統合 … 同じ文書が複数の場所にコピーされていることがあります。ハッシュで検出し、コピー元とコピー先の両方を記録します。「極秘の文書が誰でも見られる場所にコピーされている」がここで見つかります
3. 本文の抽出 … 文書からテキストを取り出します。図面はテキストが少ないため、タイトル欄と注記欄に絞ります
4. 機密性の高い部分の除去 … 個人名、口座番号など、区分の判断に不要な情報は伏せてから渡します
5. 文書の長さの調整 … 長い報告書は、判断に効く部分（表題、目的、結論、数表の見出し）に絞ります。全文を渡す必要はありません

AIに処理させる

3つの役割に分けます。

カスタム分類モデルにさせること： 文書の種類の仕分け。ここは生成AIにさせません。 レイアウトの特徴で判別できるものは、専用モデルのほうが安定し、費用も安く済みます。

生成AI（Claude API）にさせること：

突合の処理（計算側）：

「どの区分にすべきか」を断定させません。 出せるのは候補と根拠までです。特に「極秘」の判断は、業務への影響が大きいため、人が決めます。

指示内容を固定する

あなたは情報管理を支援する担当者です。
下の文書について、社内の情報管理規程に照らして、秘密区分の候補を出してください。

【厳守事項】
- 判断は、下の「情報管理規程の区分の定義」に書かれている条件のみを根拠にしてください。
  一般的な情報管理の考え方や、他社の慣行で補わないでください。
- 候補は1つに絞らず、当てはまりうる区分を確信度つきで最大2つ挙げてください。
- 各候補について、文書のどの記載が根拠かを、原文から20字程度そのまま引用してください。
  **引用のない候補を出さないでください。**
- 含まれる情報の種類を、下の一覧から選んで列挙してください。
  一覧にないものは "その他" とし、内容を書いてください。
- 文書に書かれていない情報が含まれていると推測しないでください。
- 区分を変更すべきか、権限をどう変えるべきかを書かないでください。
  判断は情報管理担当が行います。
- 判断できない場合は candidates を空にし、undetermined_reason に理由を書いてください。
  **「おそらく社内限り」のような当て推量をしないでください。**

【文書の種類（分類モデルの判定）】
{doc_type}

【文書の内容（抜粋）】
{doc_excerpt}

【情報管理規程の区分の定義】
{classification_rules}

【含まれる情報の種類の一覧】
原価 / 仕入先名 / 単価・取引条件 / 設計の数値・公差 / 製造条件 / 未公開の計画 /
顧客名 / 人事情報 / 契約条件 / 知的財産（出願前）/ その他

【過去に確定した類似文書（種類と区分が近いもの・上位5件）】
{past_decisions}

「引用のない候補を出さない」の1行が重要です。 これがないと、AIは「技術的な内容を含むため関係者限りが妥当です」という抽象的な理由を返します。その理由では、情報管理担当が検証できません。 原文の引用があれば、その一文を見て判断できます。

「当て推量をしない」も必要です。 判断できない文書は必ず出ます。目次だけのファイル、中身が空のテンプレート、外国語の資料。そこで無理に区分を付けさせると、誤った区分が確定してしまいます。

出力形式を固定する

{
  "document_id": "",
  "file_name": "",
  "doc_type": "",
  "doc_type_confidence": 0,
  "created_by_department": "",
  "candidates": [
    {
      "classification": "公開 | 社内限り | 関係者限り | 極秘",
      "evidence_quote": "",
      "matched_rule": "",
      "confidence": "high | medium | low"
    }
  ],
  "information_types": [],
  "undetermined_reason": "",
  "current_state": {
    "label": "",
    "in_document_marking": "",
    "access_scope_headcount": 0,
    "access_scope_note": "",
    "viewers_90d": 0,
    "out_of_scope_views": 0,
    "copies_in_wider_scope": []
  },
  "findings": [
    { "type": "label_missing | label_mismatch | access_too_wide | out_of_scope_view | wider_copy", "severity": "high | medium | low", "detail": "" }
  ],
  "needs_owner_check": false
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。

findings の type を5つに分けている点が実務上効きます。対処の仕方が種類ごとに違うためです。

out_of_scope_view と wider_copy を最優先にしてください。 この2つは「これから起こること」ではなく「すでに起きたこと」です。ラベルの付け忘れより重い指摘です。

システムへ連携する

点検リストをスプレッドシートまたは Microsoft Lists に作ります。1文書1行で、上の findings を展開して見る形にします。

確定した区分の反映は、情報保護の製品の機能で行ってください。 この構成から直接ラベルを書き込むより、既存の仕組みに乗せるほうが確実です。秘密度ラベルはファイルとメールのメタデータに格納され、保存場所が変わってもコンテンツと一緒に維持されます。

権限の変更は、人が行います。 自動でフォルダの権限を絞ると、業務が止まります。変更の依頼を出し、作成部署と情報システム部が確認したうえで実施してください。

人が確認する

全件、情報管理担当が確認します。区分の自動確定はしません。

理由は3つあります。1つは、区分を厳しくしすぎると業務が止まるためです。共有すべき資料が見られなくなれば、現場は別の経路で回します。2つ目は、規程の側が古い可能性があり、AIの判断が規程どおりでも実態に合わないことがあるためです。3つ目は、作成部署の意図を確認する必要がある場合があるためです。

確認の深さを分けてください。

• out_of_scope_view と wider_copy があるもの … すでに起きている。最優先で対処する
• candidates の第1候補が「極秘」のもの … 影響が大きい。全件、根拠の引用を読む
• label_missing で候補が「社内限り」のもの … 数が多い。まとめて確定してよい
• undetermined_reason があるもの … 人が中身を見る
• doc_type_confidence が低いもの … 仕分けの誤りかもしれない。種類から確認する

確認を速くするための設計が効きます。

• findings の severity と type で並べ替える
• 根拠の引用と、規程の該当条項を左右に並べて表示する
• 同じ作成部署・同じ種類の文書をまとめて表示する（まとめて確定できる）
• 過去に同種の文書をどう確定したかを併記する
• 権限の範囲を人数で表示する（「1,500名が見られる」は一目で分かる）

3つ目が効きます。 「設計部が作った原価表30件」をまとめて「関係者限り」に確定できれば、1件ずつ見るより圧倒的に速くなります。

例外に対処する

記録を残す

この記録は、営業秘密の管理を行っていたことを示す資料になります。

• 点検した文書の一覧と、点検日
• 区分の候補と、その根拠の引用
• 情報管理担当が確定した区分と、確定日・確定者
• 候補と違う区分に確定した場合、その理由
• findings の内容と、対処の結果
• out_of_scope_view の詳細（いつ、どの範囲から閲覧されたか）
• 適用した情報管理規程の版

「候補と違う区分に確定した理由」を残すことが特に重要です。 同じ種類の文書で毎回同じ理由の上書きが起きているなら、規程の定義かAIへの渡し方に原因があります。

適用した規程の版も必ず記録してください。 規程は改定されます。「いつ時点の規程で判断したか」が残っていないと、後から検証できません。

out_of_scope_view の記録は、万一の流出時に経緯を追う材料になります。ただし、個人の閲覧行動の監視が目的ではないことを、社内に明示してください。