Skip to content

Latest commit

 

History

History
1523 lines (1057 loc) · 35.9 KB

File metadata and controls

1523 lines (1057 loc) · 35.9 KB

Menreiki Product Requirements Document

文書バージョン: 0.1 製品名: Menreiki 種別: ローカルファーストの機密文書仮名化・一般化ツール ライセンス方針: オープンソース 想定形態: デスクトップアプリケーション、CLI、再利用可能な処理ライブラリ


1. 製品概要

Menreikiは、PDFや画像などの文書に含まれる人物名、組織名、製品名、型式、所在地、管理番号などの識別情報をローカル環境で検出し、人間のレビューを経て、削除・マスキング・仮名化・一般化するアプリケーションである。

単なる黒塗りツールではなく、文書内の意味、構造、対象間の関係を維持しながら、機密性のある表現を安全な別名や汎用表現へ置き換える。

主な用途は、機密文書からアルゴリズム、技術仕様、構造、一般化可能な知識だけを抽出し、オンラインAI、外部委託先、研究者、社外関係者などへ渡せる派生文書を生成することである。

キャッチコピー

意味を残して、面を替える。

英語での位置付け

Local-first document de-identification, pseudonymization, and generalization workbench.


2. 背景と課題

企業や研究機関が保有する技術文書には、外部へ公開できない情報と、一般化すれば有効活用できる情報が混在している。

例として、次の情報が同一文書内に含まれる。

  • 顧客名、協力会社名、担当者名
  • 製品名、型式、開発コード
  • 文書番号、契約番号、管理番号
  • 施設名、所在地、組織構成
  • 日付、金額、数量、具体的な性能値
  • 技術仕様、処理フロー、計算式、アルゴリズム
  • 図表、スクリーンショット、ロゴ、印影
  • ヘッダー、フッター、透かし

既存の黒塗りツールには、以下の問題がある。

  1. 文書の意味や対象間の関係が失われる。
  2. 同一人物や同一組織が文書内で一貫して処理されない。
  3. 表記揺れや略称を人間が個別に探す必要がある。
  4. PDFの非表示テキスト、注釈、メタデータなどが残る危険がある。
  5. 検出結果を一覧化し、処理前に承認するUIが不足している。
  6. 処理後に機密情報が残っていないことを再検査できない。
  7. オンラインOCRやオンラインAIへ原文を送信できない。
  8. 型式や数値を完全削除すると、技術的な分析価値まで失われる。

Menreikiは、検出、レビュー、エンティティ統合、変換、再検査を一つのローカルワークフローとして提供する。


3. 製品ビジョン

機密文書の匿名化を、個別の黒塗り作業から、再現可能で監査可能な文書変換工程へ変える。

Menreikiは、文書に記載された対象の「存在」や「役割」を残しつつ、その対象を直接特定できる「顔」を安全な別の面へ置き換える。

変換例

変換前:

株式会社アルファは、株式会社ベータから受領したZX-140制御装置を、横浜第一試験場で田中太郎が評価した。

変換後:

発注元企業Aは、供給企業Bから受領した制御装置Aを、試験施設Aで担当者Aが評価した。

技術的な関係は維持される。

  • 発注元と供給元は異なる主体である。
  • 評価対象は制御装置である。
  • 評価は試験施設で実施された。
  • 評価担当者が存在する。

一方で、元の組織、製品、施設、人物は特定できない。


4. 目的

4.1 主要目的

  • 機密文書をローカル環境だけで解析できること。
  • 識別情報の検出候補を、処理前に一覧確認できること。
  • 同一対象を文書全体で一貫して置換できること。
  • 黒塗りだけでなく、仮称や汎用名称へ置換できること。
  • アルゴリズムや技術的関係を可能な限り維持できること。
  • 処理後に元の識別情報が残っていないか再検査できること。
  • 変換判断と出力工程を監査可能にすること。
  • GUIとCLIの両方から利用できること。

4.2 副次目的

  • 案件ごとの匿名化ポリシーを再利用できること。
  • チーム内でレビュー結果を共有できること。
  • OCR、ローカルLLM、正規表現などを交換可能にすること。
  • 将来的にCIやバッチ処理へ組み込めること。
  • PDF以外のオフィス文書や動画にも拡張できること。

5. 非目的

初期バージョンでは以下を保証しない。

  • 法律上の「完全匿名化」の自動保証
  • 人間のレビューなしでの安全性保証
  • あらゆる文書形式の完全なレイアウト再現
  • 暗号化されたPDFの解除
  • 元文書を安全に外部AIへ送信する機能
  • クラウド上での原文解析
  • 文書内容の正しさや技術的妥当性の検証
  • 悪意ある文書に対する完全なマルウェア防御
  • 画像に写り込んだすべての機密情報の完全自動検出

Menreikiは、匿名化判断を支援し、見落としを減らすツールである。最終的な公開可否は利用者または組織の責任者が判断する。


6. 想定利用者

6.1 エンジニア

機密仕様書から一般化可能なアルゴリズムや構成だけを抽出し、AIへ質問したい。

6.2 研究者

共同研究先、被験者、装置名、施設名などを仮名化したうえで、文書を外部解析へ渡したい。

6.3 セキュリティ・法務担当者

文書内の機密候補と処理結果を一覧で確認し、公開可否を承認したい。

6.4 テクニカルライター

社内資料を一般公開向けの技術資料へ変換したい。

6.5 OSS開発者

バグ報告やIssueへ添付するログ、画面、設計資料から機密情報を除去したい。

6.6 AI活用担当者

ローカルLLMで原文を処理した後、安全な派生文書だけをオンラインAIへ投入したい。


7. 主要ユースケース

UC-01:技術文書をオンラインAIへ渡す

  1. 利用者が機密PDFをMenreikiへ取り込む。
  2. PDFを安全なページ画像へ変換する。
  3. OCR、ルール、ローカルLLMで機密候補を検出する。
  4. 検出候補を一覧表示する。
  5. 利用者が保持、削除、仮名化、一般化を判断する。
  6. 同一対象をグループ化し、一貫した仮称を割り当てる。
  7. 変換済みPDF、画像、Markdownを生成する。
  8. 変換済み出力を再OCRし、残存情報を検査する。
  9. 合格した出力だけをオンラインAIへ渡す。

UC-02:フッターや透かしを全ページから一括除去する

  1. 利用者が一つのフッター領域を選択する。
  2. Menreikiが同一位置または類似内容の領域を全ページから検出する。
  3. 対象ページと検出件数を一覧表示する。
  4. 利用者が一括適用を承認する。
  5. 対象領域を削除または置換する。

UC-03:特定名称を文書全体で置換する

  1. 利用者が組織名または製品名を検索する。
  2. 完全一致、部分一致、OCR揺れ、略称候補を表示する。
  3. 同一エンティティとしてまとめる。
  4. 「開発会社A」などの置換名を設定する。
  5. 文書全体へ一括適用する。

UC-04:技術的意味を保って型式を一般化する

変換前:

STM32H750VBT6は、FDCAN1を使用して1 Mbpsで通信する。

変換後:

Cortex-M7系マイクロコントローラAは、CANコントローラAを使用して1 Mbpsで通信する。

具体的な型式は削除するが、分析に必要な技術分類と通信条件は残す。

UC-05:複数文書へ同一ポリシーを適用する

同一案件の仕様書、試験記録、議事録へ共通のエンティティ辞書と置換方針を適用する。


8. コアコンセプト

8.1 Document

取り込まれた一つの文書。

8.2 Page

文書を構成するページ画像。

8.3 Span

OCRで認識された文字列と、その位置情報。

8.4 Region

文字列、ロゴ、顔、印影、図表などが存在する画像領域。

8.5 Finding

機密情報である可能性がある検出候補。

8.6 Entity

文書中で同一の人物、組織、製品、施設などを表す論理的対象。

8.7 Alias

Entityに割り当てられる一貫した仮称。

8.8 Generalization

具体的な情報を、より粗い分類または範囲へ変換する処理。

例:

  • 東京都港区○○町1-2-3 → 東京都内
  • 2026年7月17日 10時15分 → 2026年7月
  • STM32H750VBT6 → Cortex-M7系マイクロコントローラ
  • 0.973ミリ秒 → 約1ミリ秒

8.9 Decision

Findingに対して人間が行った判断。

8.10 Policy

検出、分類、置換、出力、検査に関する設定。

8.11 Audit

変換後の文書に元の情報が残っていないか確認する工程。


9. 情報分類

初期バージョンでは以下の分類を提供する。

  • 人物名
  • 組織名
  • 部署名
  • 製品名
  • 型式
  • 開発コード
  • プロジェクト名
  • 施設名
  • 所在地
  • 電話番号
  • メールアドレス
  • URL
  • IPアドレス
  • ホスト名
  • ユーザー名
  • ファイルパス
  • 文書番号
  • 契約番号
  • 注文番号
  • シリアル番号
  • 日付
  • 時刻
  • 金額
  • 数量
  • 性能値
  • 署名
  • 印影
  • ロゴ
  • QRコード
  • バーコード
  • ヘッダー
  • フッター
  • 透かし
  • 自由分類

利用者は独自分類を追加できる。


10. 変換方式

Findingごとに以下の方式を選択できる。

10.1 保持

元の情報を変更しない。

10.2 完全削除

対象を出力から除去する。

10.3 マスキング

対象領域を矩形、模様、置換記号などで覆う。

10.4 仮名化

同一Entityへ一貫した別名を割り当てる。

例:

  • 株式会社アルファ → 開発会社A
  • アルファ社 → 開発会社A
  • 同社 → 開発会社A

10.5 汎用名称化

固有名称を役割またはカテゴリへ置換する。

例:

  • 横浜第一試験場 → 試験施設
  • ZX-140 → 制御装置
  • 田中太郎 → 担当者

10.6 範囲化

具体値を範囲へ変換する。

例:

  • 1,274,500円 → 約100万円
  • 0.973ミリ秒 → 約1ミリ秒
  • 2026年7月17日 → 2026年7月

10.7 相対化

絶対的な表現を文書内で一貫した相対表現へ変換する。

例:

  • 2026年7月17日 → 基準日
  • 2026年7月18日 → 基準日の翌日
  • 横浜第一試験場 → 拠点A

10.8 文脈置換

同じ文字列でも、文脈によって異なる処理を行う。

例:

  • 「Apple」が企業名として使われる場合 → 企業A
  • 「apple」が果物として使われる場合 → 保持

11. ユーザー体験

11.1 プロジェクト作成

利用者は次を指定する。

  • 入力文書
  • 作業フォルダー
  • 匿名化ポリシー
  • 使用するOCRエンジン
  • 使用するローカルLLM
  • 出力形式
  • ネットワーク利用ポリシー

初期状態ではネットワークアクセスを無効にする。

11.2 インポート画面

表示項目:

  • ファイル名
  • ページ数
  • ファイルサイズ
  • 暗号化の有無
  • テキストレイヤーの有無
  • 添付ファイルの有無
  • 注釈の有無
  • フォームの有無
  • メタデータ
  • 変換予定方式

利用者に対し、元PDFの内部構造をそのまま編集するのではなく、安全な派生文書を再構築することを明示する。

11.3 解析画面

解析処理の進行状況を表示する。

  • ページ画像化
  • OCR
  • 規則ベース検出
  • 辞書照合
  • エンティティ抽出
  • ローカルLLM解析
  • 類似表記の統合
  • ヘッダー・フッター検出
  • 画像領域検出

解析途中でも、完了したページからレビューを開始できる。

11.4 候補一覧画面

画面の中心となる機能。

列の例:

項目 説明
判定 保持、削除、仮名化、一般化、保留
原文 検出された文字列
分類 人物、組織、型式など
置換後 適用予定の表現
信頼度 検出エンジンの確信度
件数 出現回数
ページ 出現ページ
検出元 OCR、正規表現、辞書、LLMなど
適用範囲 単一箇所、同一ページ、文書全体、案件全体
状態 未確認、確認済み、競合、要再確認

操作:

  • OK
  • NG
  • 保留
  • 保持
  • 削除
  • マスキング
  • 仮名化
  • 一般化
  • 同一Entityへ統合
  • Entityを分割
  • 文書全体へ適用
  • 類似候補へ適用
  • 変更を元に戻す

11.5 文脈プレビュー

候補を選択すると、以下を同時表示する。

  • ページ画像
  • 対象領域
  • 前後のOCR文章
  • 同一候補の全出現箇所
  • 置換前後の比較
  • 検出理由
  • ローカルLLMの説明
  • 他の候補との関係

ローカルLLMの判定は、確定事項ではなく参考情報として表示する。

11.6 エンティティ画面

表記揺れを一つのEntityへまとめる。

例:

Entity: organization-001

代表表記:
株式会社アルファ技研

別表記:
アルファ技研
アルファ社
株式会社アルファ
同社

分類:
開発会社

置換:
開発会社A

主な操作:

  • 表記を追加
  • 表記を除外
  • Entityを統合
  • Entityを分割
  • 役割を設定
  • 仮称を自動採番
  • 仮称を手動編集
  • 案件全体へ登録

11.7 ルール画面

以下の一括ルールを作成できる。

  • 完全一致
  • 大文字小文字を無視
  • 正規表現
  • OCR誤認識を許容
  • 座標範囲
  • ページ範囲
  • ヘッダー領域
  • フッター領域
  • 画像類似度
  • ロゴ画像
  • 文脈条件
  • Entity分類
  • 辞書一致

例:

rules:
  - name: Remove footer organization
    match:
      region: footer
      text_contains:
        - 株式会社アルファ
    action:
      type: replace
      value: 開発会社A
    scope: all_pages

11.8 出力前確認

以下を表示する。

  • 未確認候補数
  • 保留候補数
  • 低信頼度候補数
  • 競合する置換数
  • 元の固有名詞残存候補数
  • メタデータ残存数
  • 非表示オブジェクト残存数
  • 出力予定ファイル
  • 出力ポリシー

危険度の高い未確認項目がある場合、警告を表示する。


12. 検出機能

12.1 OCR

ページ画像から以下を取得する。

  • 認識文字列
  • 文字または単語単位の座標
  • 行情報
  • ブロック情報
  • 信頼度
  • 読み順
  • 回転角度
  • 言語

日本語と英語の混在文書を優先的に扱う。

12.2 PDFテキスト抽出

PDFにテキストレイヤーが存在する場合は、OCR結果と併用する。

ただし、出力時に元のテキストレイヤーをそのまま再利用しない。

12.3 正規表現

以下の候補を規則的に検出する。

  • 電話番号
  • メールアドレス
  • URL
  • IPアドレス
  • 日付
  • 文書番号
  • ファイルパス
  • 型式らしい文字列
  • シリアル番号
  • 郵便番号
  • 金額

12.4 辞書照合

利用者が登録した名称辞書と照合する。

  • 組織辞書
  • 人物辞書
  • 製品辞書
  • プロジェクト辞書
  • 禁止語辞書
  • 保持語辞書

12.5 エンティティ抽出

ローカルの自然言語処理モデルを用いて、固有表現を分類する。

12.6 ローカルLLM

ローカルLLMまたはローカルVLMは、以下を補助する。

  • 文脈依存の固有名詞検出
  • 組織、製品、施設の役割推定
  • 表記揺れの統合候補生成
  • 適切な汎用名称の提案
  • 技術的意味を残す一般化候補の提案
  • 図表内の機密候補検出
  • 文書全体からの見落とし候補抽出

LLMへ与えるデータはローカル環境から外部送信しない。

12.7 レイアウト反復検出

ページ間で同じ位置に存在する要素を検出する。

  • ヘッダー
  • フッター
  • ページ番号
  • 文書番号
  • ロゴ
  • 透かし
  • 機密区分表示

利用者は一つの領域を指定し、全ページへ適用できる。

12.8 画像検出

将来的に以下を扱う。

  • 社章
  • ロゴ
  • 印影
  • 手書き署名
  • QRコード
  • バーコード
  • 画面キャプチャ内の機密文字列

13. 置換処理

13.1 文字領域処理

  1. 対象文字の領域を特定する。
  2. 元の文字を除去する。
  3. 背景を復元する。
  4. 必要に応じて罫線を再描画する。
  5. 置換後の文字列を描画する。
  6. 変更領域を記録する。

13.2 背景復元方式

  • 単色塗り
  • 周辺色による補間
  • 罫線再描画
  • 周辺画像の複製
  • インペインティング
  • 置換済みであることを示す明示的なボックス

13.3 文字描画

元文書と完全に同じフォントを再現することは必須としない。

優先順位:

  1. 可読性
  2. 置換後の意味
  3. レイアウト維持
  4. 元文書との視覚的一貫性

置換文字が領域に収まらない場合は、以下を選択可能とする。

  • 自動縮小
  • 自動改行
  • 領域拡張
  • 短い仮称へ変更
  • 脚注形式へ変更

13.4 仮称の一貫性

同一Entityには同一Aliasを使用する。

異なるEntityに同一Aliasを誤って割り当てない。

案件単位で採番順序を固定できる。

例:

organization-001 → 発注元企業A
organization-002 → 供給企業B
person-001       → 担当者A
product-001      → 制御装置A

14. 出力

14.1 必須出力形式

  • 画像再構築PDF
  • ページ単位PNG
  • Markdown
  • プレーンテキスト
  • JSON形式の検出結果
  • JSON形式の判断履歴
  • 監査レポート

14.2 出力構成例

output/
├─ sanitized.pdf
├─ sanitized.md
├─ sanitized.txt
├─ pages/
│  ├─ page-001.png
│  ├─ page-002.png
│  └─ page-003.png
├─ audit/
│  ├─ report.html
│  ├─ findings.json
│  └─ residuals.json
└─ manifest.json

14.3 PDF再構築

安全性を優先し、原則として変換済みページ画像から新しいPDFを生成する。

元PDFから以下を引き継がない。

  • 元のテキストレイヤー
  • 注釈
  • 添付ファイル
  • フォームデータ
  • JavaScript
  • しおり内の機密文字列
  • サムネイル
  • 編集履歴
  • 作成者情報
  • カスタムメタデータ
  • 非表示レイヤー
  • 元画像オブジェクト

検索可能PDFを生成する場合は、置換後のOCR結果だけから新しいテキストレイヤーを構築する。

14.4 Markdown出力

文書構造を可能な範囲で維持する。

  • 見出し
  • 段落
  • 箇条書き
  • 数式
  • 図の参照
  • ページ番号
  • 置換済み名称

オンラインAIへの入力には、画像PDFだけでなくMarkdownも利用できるようにする。


15. 再検査

変換後の出力へ再度解析を行う。

15.1 文字列再検査

  • 元の固有名詞一覧との照合
  • 元の識別子一覧との照合
  • 辞書との照合
  • 正規表現による再検出
  • OCR結果との差分確認

15.2 画像再検査

  • 元領域が視覚的に残っていないか
  • 薄い透かしが残っていないか
  • 置換領域の外に文字がはみ出していないか
  • ロゴや印影が残っていないか

15.3 PDF構造検査

  • 元のテキストが含まれていないこと
  • 注釈が含まれていないこと
  • 添付ファイルが含まれていないこと
  • 不要なメタデータが含まれていないこと
  • JavaScriptが含まれていないこと
  • 非表示レイヤーが含まれていないこと

15.4 合否判定

監査結果は以下に分類する。

  • Pass
  • Pass with warnings
  • Review required
  • Fail

自動的なPassは、「絶対に安全」という意味ではなく、設定された検査項目を通過したことを意味する。


16. プロジェクト保存形式

Menreikiは作業状態をプロジェクトとして保存する。

example.menreiki/
├─ project.json
├─ source/
│  └─ original.pdf
├─ pages/
├─ ocr/
├─ findings/
├─ entities/
├─ decisions/
├─ rules/
├─ models/
├─ renders/
└─ audit/

保存対象:

  • 入力ファイルのハッシュ
  • ページ画像
  • OCR結果
  • 検出候補
  • Entity構造
  • Alias対応表
  • 人間の判断
  • 使用したルール
  • 使用したモデル
  • モデル設定
  • 出力履歴
  • 監査結果

原本をプロジェクト内へコピーせず、外部参照だけにするモードも提供する。


17. 対応表の保護

元名称とAliasの対応表は、最も機密性の高いデータの一つである。

例:

株式会社アルファ技研 ⇔ 開発会社A
田中太郎             ⇔ 担当者A
ZX-140               ⇔ 制御装置A

以下を提供する。

  • 対応表を保存しないモード
  • 対応表だけを暗号化するモード
  • プロジェクト全体の暗号化
  • OSの資格情報ストアとの連携
  • 一時ファイルの自動削除
  • 案件終了時の安全な削除支援
  • 出力物へ対応表を含めないことの検証

18. セキュリティ要件

18.1 ローカルファースト

デフォルトでは、すべての処理をローカルで行う。

18.2 ネットワーク無効

初期状態ではネットワーク通信を行わない。

必要なモデルや辞書のダウンロードは、文書を開いていない状態で明示的に実行する。

18.3 外部AI連携

将来的に外部AI連携を実装する場合も、原文を直接送信できない設計とする。

送信可能対象:

  • 変換済み文書
  • 監査合格済みファイル
  • 利用者が明示的に選択した範囲

18.4 ログ

ログへ原文の機密文字列を記録しない。

デバッグモードで原文を含むログを出す場合は、明示的な警告を表示する。

18.5 一時ファイル

  • OSの安全な一時領域を使用する。
  • 終了時に削除する。
  • 異常終了後の残存を検出する。
  • 保存場所を利用者が指定できる。

18.6 サプライチェーン

OCR、PDF、画像、LLM関連の依存コンポーネントを明示する。

プロジェクトはSBOMを生成できることが望ましい。


19. 非機能要件

19.1 対応環境

MVPではWindowsを最優先する。

将来的にLinux、macOSへ拡張する。

19.2 オフライン動作

インストール後、ネットワークへ接続せずに主要機能を使用できる。

19.3 性能目標

一般的な事務文書を想定する。

  • 100ページのPDFを処理可能
  • 300 DPI相当の画像を扱える
  • ページ単位で逐次処理できる
  • 解析済みページからレビューを開始できる
  • 再起動後に途中状態を復元できる

19.4 再現性

同じ入力、同じモデル、同じルール、同じ判断から、同等の出力を再生成できる。

19.5 監査性

誰が、いつ、どの候補を、どの方式で処理したか記録できる。

個人利用では監査ログを無効化できる。

19.6 拡張性

以下をプラグインまたはアダプターとして交換可能にする。

  • OCRエンジン
  • PDFレンダラー
  • ローカルLLM
  • ローカルVLM
  • エンティティ抽出器
  • 画像修復器
  • PDF出力器
  • 監査器

20. 技術構成案

PRDでは実装技術を完全には固定しないが、以下を推奨構成とする。

20.1 コアエンジン

Rust

担当:

  • プロジェクト管理
  • 座標・領域処理
  • ルールエンジン
  • Entity管理
  • Alias割り当て
  • 変換計画
  • 監査処理
  • CLI
  • ネイティブライブラリ連携

理由:

  • メモリ安全性
  • 単一バイナリ配布
  • CLIとの共有
  • C APIを持つOCR、PDF、画像ライブラリとの連携
  • 将来のクロスプラットフォーム対応

20.2 GUI

候補:

  • TypeScript+Tauri
  • C#+Avalonia
  • C#+WPF

クロスプラットフォームとRustコアの共有を重視する場合は、TypeScript+Tauriを第一候補とする。

Windows固有の操作性とC#資産を優先する場合は、C#+AvaloniaまたはWPFを選択する。

20.3 C#の用途

  • Windows固有機能
  • CubePDF連携
  • 印刷経由の変換
  • COM連携
  • Office文書変換
  • Windows資格情報ストア
  • 既存.NETライブラリとの統合

C#をメインUIに採用し、RustコアをFFIまたはプロセス間通信で呼び出す構成も許容する。

20.4 TypeScriptの用途

  • レビューUI
  • エンティティ一覧
  • ページプレビュー
  • ルール編集
  • 差分表示
  • 監査レポート表示

20.5 ffmpegの用途

PDF静止画変換の主手段にはしない。

以下の将来用途で使用する。

  • 動画フレームの匿名化
  • 画面録画内の機密情報除去
  • 処理済みフレームからの動画再構築
  • 音声トラックの除去

20.6 CubePDFの用途

Windows環境における補助的な変換経路として扱う。

安全性と再現性のため、コア処理ではPDFレンダリングライブラリによる直接画像化を優先する。

CubePDFを利用する場合も、仮想プリンター経由で生成された結果を再検査する。

20.7 ローカルAI

以下を外部プロセスまたはローカルAPIとして接続可能にする。

  • llama.cpp系ランタイム
  • ONNX Runtime
  • ローカルOCRモデル
  • ローカルVLM
  • OpenAI互換のローカルAPI

特定のモデルへ依存しないインターフェースを設計する。


21. CLI案

menreiki import confidential.pdf
menreiki analyze project.menreiki
menreiki findings project.menreiki
menreiki apply project.menreiki --policy policy.yaml
menreiki render project.menreiki
menreiki audit output/sanitized.pdf
menreiki export project.menreiki --format pdf

バッチ処理例

menreiki process confidential.pdf \
  --policy company-policy.yaml \
  --output output/ \
  --require-review

CI向け例

menreiki audit sanitized.pdf \
  --deny-wordlist secrets.txt \
  --fail-on-warning

22. MVP要件

MVPでは、対象を文字中心のPDFと画像に限定する。

必須機能

  • PDF、PNG、JPEGの取り込み
  • PDFのページ画像化
  • OCR
  • OCR文字列と座標の保存
  • 文字列検索
  • 正規表現検出
  • 利用者辞書による検出
  • 検出候補一覧
  • ページプレビュー
  • OK、NG、保留判定
  • 保持、削除、マスキング、置換
  • 文書全体への一括適用
  • フッター領域の一括処理
  • Entityの手動統合
  • 一貫したAlias割り当て
  • 変換済みページ画像生成
  • 画像からのPDF再構築
  • Markdown出力
  • 変換後の再OCR
  • 元文字列の残存検査
  • PDFメタデータ除去
  • プロジェクト保存
  • オフライン動作
  • Windows対応
  • CLIの基本機能

MVPでの任意機能

  • ローカルLLMによる候補追加
  • ローカルLLMによる置換名提案
  • OCR誤認識の類似検索
  • プロジェクト暗号化
  • PDF検索用テキストレイヤー再生成

MVP対象外

  • 顔認識
  • 印影認識
  • 高度なロゴ認識
  • 動画
  • 音声
  • Word、Excel、PowerPointの直接編集
  • 複数人によるリアルタイム共同編集
  • クラウド同期
  • 自動公開判定

23. MVPの画面構成

23.1 ホーム

  • 新規プロジェクト
  • プロジェクトを開く
  • 最近使用したプロジェクト
  • ポリシー管理
  • モデル管理

23.2 インポート

  • ファイル選択
  • PDF構造情報
  • 画像化設定
  • OCR設定
  • 保存先

23.3 レビュー

三分割を基本とする。

左:

  • ページ一覧
  • サムネイル
  • 状態表示

中央:

  • ページ画像
  • 検出領域
  • 変換前後の切り替え

右:

  • 候補一覧
  • 分類
  • 置換方式
  • Entity
  • Alias
  • 文脈
  • 一括適用

23.4 Entity管理

  • Entity一覧
  • 表記一覧
  • 分類
  • 役割
  • Alias
  • 統合
  • 分割

23.5 出力

  • 出力形式
  • 解像度
  • OCRテキストレイヤー
  • メタデータ
  • 監査条件
  • 出力先

23.6 監査

  • 合否
  • 残存候補
  • ページ位置
  • PDF構造
  • 使用したポリシー
  • 監査レポート出力

24. 成功指標

24.1 製品指標

  • 利用者が手作業で全ページを確認する時間を削減できる。
  • 同一名称の置換漏れを減らせる。
  • ヘッダーやフッターの一括処理ができる。
  • 文書内の関係を維持した仮名化ができる。
  • 元PDFの非表示情報を引き継がない。
  • 出力物をローカル環境だけで生成できる。

24.2 MVP評価指標

  • 100ページの文書を正常に取り込める。
  • 一つの名称を文書全体で一括置換できる。
  • 同じEntityの複数表記を一つのAliasへ統合できる。
  • フッターの同一領域を全ページで除去できる。
  • 出力PDFから元文字列を検索できない。
  • 出力PDFの再OCRで元文字列を検出しない。
  • 元PDFのメタデータ、注釈、添付ファイルを継承しない。
  • アプリケーションがネットワークへ接続せず処理を完了できる。

25. 受け入れ基準

AC-01:名称の一括仮名化

Given:

  • 20ページのPDFに「株式会社アルファ」が10回出現する。
  • 「アルファ社」が5回出現する。

When:

  • 両方を同一Entityへまとめる。
  • Aliasとして「開発会社A」を設定する。
  • 文書全体へ適用する。

Then:

  • 15箇所すべてが「開発会社A」へ置換される。
  • 元名称が出力PDFの画像、OCRテキスト、メタデータに残らない。

AC-02:フッター一括除去

Given:

  • 全50ページの下部に同一の組織名が表示されている。

When:

  • 1ページ目のフッター領域を指定する。
  • 全ページへ適用する。

Then:

  • 類似領域が一覧表示される。
  • 利用者の承認後、全対象ページから除去される。
  • ページ本文の同一文字列には影響しない。

AC-03:一般化

Given:

  • 文書内に特定の型式名が記載されている。

When:

  • 型式を「Cortex-M7系マイクロコントローラA」へ一般化する。

Then:

  • 技術分類を残した置換が行われる。
  • 同一型式は文書全体で同じ表現になる。

AC-04:監査

Given:

  • 変換済みPDFが生成されている。

When:

  • 監査処理を実行する。

Then:

  • 元の検出文字列との再照合が行われる。
  • PDF構造が検査される。
  • 合否と残存候補がレポートに表示される。

AC-05:オフライン動作

Given:

  • PCのネットワークを切断する。

When:

  • 文書の取り込み、OCR、レビュー、出力、監査を行う。

Then:

  • 主要ワークフローを完了できる。

26. リスク

26.1 OCR漏れ

画像品質、縦書き、特殊フォント、背景色などにより文字を検出できない可能性がある。

対策:

  • 複数OCR結果の併用
  • PDFテキストレイヤーとの照合
  • 画像全体の人間レビュー
  • ローカルVLMによる補助
  • 低信頼度ページの警告

26.2 意味的な機密情報

固有名詞がなくても、技術条件の組み合わせから案件や製品を推定できる可能性がある。

対策:

  • 数値一般化
  • 複数条件の組み合わせ検出
  • ローカルLLMによる再評価
  • 組織固有のポリシー
  • 最終的な人間判断

26.3 仮名からの再識別

文書中の役割や関係が詳細すぎる場合、仮名化後も対象を推定できる。

対策:

  • 役割の一般化
  • 数量、時刻、場所の粗粒度化
  • 不要な関係の削除
  • 再識別リスク警告

26.4 PDF内部情報の残存

見た目上消えていても、元のテキストや画像が内部に残る可能性がある。

対策:

  • 元PDFを直接編集しない
  • ページ画像から新規PDFを構築する
  • 出力PDFの構造検査
  • バイナリ文字列検査
  • 再OCR

26.5 ローカルモデルの誤判定

ローカルLLMが一般技術用語を固有名詞と誤認したり、機密情報を見逃したりする。

対策:

  • LLMを最終判定に使用しない
  • 検出根拠を表示する
  • 人間による承認を必須化できる
  • 複数検出器を併用する

27. 将来拡張

Phase 2

  • ローカルLLM・VLM統合
  • 自動Entity統合
  • 役割ベースAlias提案
  • 画像内ロゴ検出
  • 顔・署名・印影のマスキング
  • OCRテキストレイヤー再生成
  • Linux、macOS対応
  • プロジェクト暗号化
  • ポリシーテンプレート
  • 差分レビュー

Phase 3

  • Word、Excel、PowerPoint対応
  • CAD図面対応
  • 動画・画面録画対応
  • 音声の固有名詞置換
  • 複数文書横断Entity管理
  • Git連携
  • CI向けヘッドレス処理
  • 組織向け承認フロー
  • プラグインSDK
  • 外部DLP製品との連携

28. OSSとしての方針

28.1 コア機能の公開

以下はOSSとして公開する。

  • プロジェクト形式
  • 検出結果形式
  • ルールエンジン
  • Entity管理
  • Alias割り当て
  • 画像変換
  • PDF再構築
  • 監査
  • CLI

28.2 モデル非依存

特定のAIモデルやクラウドサービスへ依存しない。

28.3 再現可能な検証

安全性に関するテスト文書を公開し、以下を自動検証する。

  • 黒塗りの下に文字が残っていないこと
  • 元テキストレイヤーが残っていないこと
  • メタデータが除去されること
  • 添付ファイルが継承されないこと
  • 仮名の一貫性
  • 再OCRによる残存検出

28.4 用語

Menreikiでは、処理を以下のように区別する。

  • Redaction:削除、マスキング
  • Pseudonymization:仮名化
  • Generalization:一般化
  • De-identification:識別可能性を下げる一連の処理
  • Audit:処理後の検査

「匿名化」という言葉だけで安全性を断定しない。


29. 仮のリポジトリ構成

menreiki/
├─ apps/
│  ├─ desktop/
│  └─ cli/
├─ crates/
│  ├─ menreiki-core/
│  ├─ menreiki-project/
│  ├─ menreiki-ocr/
│  ├─ menreiki-detect/
│  ├─ menreiki-entity/
│  ├─ menreiki-render/
│  ├─ menreiki-audit/
│  └─ menreiki-inference/
├─ packages/
│  ├─ ui/
│  └─ policy-schema/
├─ adapters/
│  ├─ pdfium/
│  ├─ tesseract/
│  ├─ onnx/
│  ├─ llama-cpp/
│  └─ windows/
├─ schemas/
├─ examples/
├─ test-documents/
└─ docs/

30. 製品説明

短い説明

Menreikiは、機密文書の識別情報を検出し、レビューを経て仮名化・一般化するローカルファーストのOSSツールです。

標準説明

Menreikiは、PDFや画像に含まれる人物名、組織名、製品名、型式、所在地、管理番号などをローカル環境で検出し、人間のレビューを経て削除、マスキング、仮名化、一般化するオープンソースツールです。同一対象の表記揺れを一つのエンティティとして管理し、文書全体で一貫した仮称へ置換することで、意味や関係性を残したまま外部へ共有可能な派生文書を生成します。

GitHubのDescription候補

Local-first document de-identification, pseudonymization and generalization workbench.

日本語タグライン

意味を残して、面を替える。

英語タグライン

Preserve meaning. Replace identity.