Hugging Faceが提供しているText Embeddings Inference (TEI)はembeddingモデルにrustを使って最適化されています。今まで知らなかった・・・。そこで、以前作成した日本語embeddingモデルでmodernBERTを採用しているRuri v3を使ったAPIサーバーに適用してみます。
出来たものはこちら。
同時10ユーザーによる高負荷テストにおいて、TEIプロキシ構成によるパフォーマンス向上がはっきりしました。(RTX3060にて)
| 評価指標 | ローカルモデル推論 | TEI プロキシ推論 | 性能向上率 |
|---|---|---|---|
| 全体平均応答時間 | 1,117 ms | 21 ms | 約 53 倍高速化 |
| Embeddings 応答時間 | 1,219 ms | 17 ms | 約 71 倍高速化 |
| Rerank 応答時間 | 810 ms | 32 ms | 約 25 倍高速化 |
| 最大スループット (req/s) | 2.42 req/s | 3.38 req/s | +39.6% |
| リクエスト失敗率 (Fails) | 0.00% | 0.00% | 同等 (0.00% で極めて安定) |
ついでに、uvに変更したりと整理しました。
Open GENAIがupdateしていたので、それに合わせてupdateしました。小規模組織だと十分使えます。
このブランチでは、LiteLLMを使っていること、外からのアクセス前提で実施すること、embeddingモデルをmodernBERTベースのものも使える用意したことは、変わらずです。実験環境が貧しいのでCPU/GPU切り替えあたりはテストを実施する必要あり。
2025/07/12
脆弱性対応の状況詳細:
https://github.com/chottokun/open-genai/blob/dev/docs/security-fix-2026-07.md
2025/07/07
2026/07/06
2026/07/05時点でのまとめ：
APIをまとめています。
https://github.com/chottokun/open-genai/blob/dev/docs/microservices-api-spec.md
こちらのdevブランチで進めています。詳細は以下。
Upstream：感謝
デジタル庁が公開した「源内」。触ってみたいなぁと思っていたのですが、各種クラウド前提なので様子をみていたところ、クライド依存部分を置き換えたOpen-Genaiが公開されていました。有難い。Difyとの連携もできるので、さらに有難い。
デジタル庁がOSSとして公開したガバメントAI「源内」をオープンアーキテクチャ＆ローカルAI対応にした Open GENAI （オープン源内）を作りました。
— Hiro KAWAGUCHI（川口弘行）｜自治体のデジタル変革を支援中 (@kawaguchi_com) 2026年6月27日
「源内」はクラウド依存（クラウド上でなければ動作できない）しているため、非常に見通しが悪く気持ち悪いんですよね。… pic.twitter.com/nTftlL2NUs
こちらのFolkしたブランチで作ってみています。
ざっくり変更点
- localhost以外からも動作。
- LiteLLMを利用しOpenAI互換APIの機能強化。自動フォールバックも念のため実装。
- Whisperもlitellmで出来るようにしたが未確認
まだ、雑ですが、動作したので遊んでみました。シンプルだけどいい感じですね。大人数で使わないなら十分利用できるのではないでしょうか。
動作状況：
詳細はこちら
Difyは、画面上で簡単にチャットフローが作れて、コードを書く必要もありません。「プログラムなんて分からない……」という非エンジニアの方が社内ツールをつくるのにも本当に便利です。
しかし、いざ実務で使おうとすると、必ずと言っていいほど日本の伝統芸能「方眼紙エクセル」問題が立ちはだかります。セルの結合、複雑なレイアウト、そして中に埋め込まれた現場写真・・・。これらをそのままDifyに放り込んで、分割されたチャンクデータを見てみると、もうカオスです。
対策として「ExcelをPDF化して投入する」のも手っ取り早い方法ではあります。しかし、適切な印刷設定（1ページに収める等）が必要ですし、Linuxサーバー等でLibreOfficeを使って自動変換しようとすると、Excelとまったく同一のレイアウトが再現できないケースも多いのが悩ましいところです。そこで、昔検討していた「方眼紙エクセルの構造化」のノウハウを再利用し、Difyへのデータ投入に利用する流れを検討しました。これから、徐々に作りこんでいきます。
通常、DifyなどのRAGツールでExcel（.xlsx）をそのまま読み込むと、単なる「テキストの羅列」として処理されがちです。もしくは、全体が無理やり1つの巨大な表として扱われてしまいます。今後、DifyのExcelパース機能やLLM自体が賢くなれば解決するのかもしれませんが、現時点では目の前にいくつかの大きな課題があります。
これらを解決するために以前作った方眼紙エクセルの構造化を行う kami_excel_extractor を利用してみます。これをDifyのデータ投入用に最適化し、2つのアプローチを試してみます。
「特定の現場のデータだけを検索対象にしたい」「日付で絞り込みたい」といった、精緻なフィルタリング（ハイブリッド検索）を行いたい場合に強いのがこの手法です。
ツールを使ってExcelを解析すると、{ファイル名}_rag.jsonl というファイルが生成されます。中身は以下のような構造です。
{"content": "現場写真の説明: 2階廊下のひび割れ状況...", "metadata": {"sheet_name": "点検記録", "location": "A棟"}}
これにより、「A棟の点検記録だけを参考にして回答して」といったプロンプトに対し、LLMがフィルターを効かせて迷わず正確なデータを見つけ出せるようになります。
【注意点】 ただし、この方式だと「画像データ」はJSONLに直接埋め込めないため、別途自前のサーバー等に画像をアップロードし、そのURLをcontent内に記載するなどの工夫が必要です。正直、管理の手間が増えてしまうのがデメリットです。
「JSONLのメタデータ設定はちょっと面倒……」「もっと直感的に画像を検索対象に入れたい」「なにより、Difyに投入する前にデータを手動で修正・編集したい！」
そんな現場のワガママを解決するのが、Wordファイル（.docx）による「ハイブリッド構造DOCX」を利用する方法です。
Difyの標準Wordパーサーは非常に便利ですが、実は「Wordの表の中に貼り付けられた画像」は認識してくれないようです。
そこで本ツールでは、Excel内の表をLLM（VLM: Vision-Language Model）にあらかじめ解釈させ、「画像の内容を説明したテキスト」に変換した上で、文中に埋め込んだWordファイルを出力します。
これをDifyにインポートすれば、Wordファイル1つアップロードするだけで、標準パーサー経由でも、本来なら表中の図であったために無視されていたはずの『図や写真の情報』までしっかりインデックスされます。 （※ただし、Difyに添付できるファイル数やサイズには制限があるため、公式ドキュメントの制限事項には注意してください）
例えば、「ひび割れが写っている報告書を出して」というユーザーの検索に対し、画像解析結果のテキストをフックにして正解のドキュメントに辿り着けます。将来的にはここからさらにマルチモーダルなLLM（VLM）へ繋ぐことで、より社内情報をうまく活用できるのではないか・・・と考えての実装です。
VLMによる図の解釈は、冗長気味です。もっとキーワードや数字中心にするといった工夫が必要でしょう。まだまだ、詰める余地があります。
こちらのドキュメントにて MarkdownやYAML形式についても出力するようにしています。どこまでうまく行くかはこれからボチボチと検証していきたいと思っています。
Difyはワークフローをサクッと作れるのが最大の魅力ですが、その真価を発揮させるのは「データの質」であるのは言うまでもありません。
方眼紙エクセルという日本の伝統芸能（？）を、LLMで理解しやすい構造化データに変換してあげるだけで、チャットボットの回答精度は劇的に向上します。
実務においては「AIがパースした出来栄えを人間の目で一度確認・修正してからナレッジに投入する」というプロセスがとても大事だったりします。その意味でも、途中で手動編集できる「ハイブリッド構造DOCX」の手法は、実用的なアプローチになるのではないでしょうか。また、Difyのプラグイン（拡張機能）に落とし込めればもっと手軽になるのかもしれません。
先月、Wiki風markdownを生成してobsidian閲覧・編集するRAGを試してみるという記事を書いたのですが、Googleが発表したOKF v0.1 で構成できないか、検討しました。 [https://github.com/chottokun/md-wiki:embed:cite]
通常のRAGは、とりあえずPDFなどの一次情報をベクトルDBに突っ込めば動きますが、運用を続けると「どの情報が最新なのか分からない」「人間が後からナレッジを修正・体系化できない」といった問題に行き当たります。しかし、ソースからベクトルDBにすると、DBの中身を精査することはやり難いです。LLM Wikiは、そういった課題を解決できる可能性がありますし、またAgentとの融和も高く、利用しようと挑戦しました。今回は、それにOKF v0.1の考え方を勉強がてら盛り込みます。
単なる「マークダウンを出力するスクリプト」から脱却し、自律的に成長するナレッジベースとして機能させるため、以下のコンセプトでシステムを再設計しました。
Google Cloudが提唱する「Open Knowledge Format (OKF) v0.1」の仕様に則り、WikiページのYAMLフロントマターをPydanticで入れちゃいます。
これにより、ページが「概念（Concept）」なのか「記事（Article）」なのか、あるいは「元のソース（RawSource）」なのかをシステム（Agent）が正確に把握できるようになりました。また、ディレクトリ直下に配置する index.md や、更新履歴を束ねる log.md の運用などもOKFの規格に沿って自動生成されます。
Qdrant（ベクトルDB）の中に、2種類のインデックスを共存させています。
生データの網羅性と、Wikiの構造化された文脈（Dense + Sparseのハイブリッド検索）を掛け合わせることで、RAGの検索精度を担保しようとしてみました。
「LLM Wiki」構想のキモは、最終的な知識のオーナーシップを人間が持てることです。
システムがPDFを読み込むと、AIがWikiのドラフトを作成し、フロントマターに自動で tags: [未審査] を付与して wiki/ フォルダに出力します。
人間は使い慣れたObsidian上でそのページを開き、差分を確認。ヨシ！と思ったら 未審査 タグを消す（承認）。その後、明示的に同期コマンドを叩くことで初めてベクトルDBへ反映され、Gitにコミットされるというフローを構築しました。
ベースのLLMはローカルで動く Ollama (Gemma 4等) を活用しつつ、複雑な推論が必要なタスク（L3）だけ外部の強力なAPIへ投げるルーティングを組んでいます。チャレンジしていますが、賢いLLMが正義です。
Wikiが構造化されているため、LangGraphで組んだエージェントが「Wiki内のリンク切れ（空リンク）を検知し、自律的にスタブページを起票する（Linting機能）」といった動きも可能になりました。
「とりあえずチャンクに区切ってDBに投げる」従来のRAGから、「LLMをコンパイラとして使い、人間とAgentが共同でWikiを編纂する」アプローチに変えたことで、見通しが良くなりますね。OKFのような標準フォーマットがあると助かります。
まだまだ、お遊び実験レベルですが、やってみたら楽しかった。
Ansible（アンシブル）は、サーバーやネットワーク機器の構成管理を自動化するためのIaC（Infrastructure as Code）ツールです。
Ubuntu Desktopも現在ではWindowsと大差ない感覚で簡単にインストールできます。しかし、複数台を管理したり、設定を再現したりしようとすると意外と手間がかかります。OSを入れ直した際、「前は何を設定したっけ？」となって、細かな設定を飛ばしてしまい、後からエラーに遭遇したこともありました。
そんなときに役立つのがAnsibleです。
オンプレミス環境でもクラウド環境でも利用でき、設定ファイルを記述してCLIから実行する仕組みなので、AIエージェントとの相性も良さそうです。
今回の目的は、Ansibleそのものを学ぶことだけではなく、「AIエージェントが安全にLinux環境を管理するための土台を作ること」です。
ラズパイとWSLを実験台にしてAGENTS.mdやSKILLS.mdなどのテンプレートを作ってみました。Antigravityを利用するのは、使える環境があるからで、他のAIエージェントでもほぼほぼ同じではないかと思います。
servers-with-ansible/
├── .agents/ #SKILLS
├── ansible.cfg # プロジェクト固有のAnsible動作設定（Pipelining、キャッシュ等）
├── inventories/ # 環境別の変数およびホスト定義（Staging / Production）
│ └── <environment>/
│ ├── hosts.yml # インベントリ定義のテンプレート（Git管理対象）
│ ├── hosts_local.yml # 各自のローカル検証用ホスト定義（Git管理除外）
│ └── group_vars/all/
│ ├── vars.yml # 平文の変数定義およびマッピング（Git管理対象）
│ └── vault.yml # 暗号化されたシークレット情報（Git管理対象）
├── roles/ # 再利用可能なタスクを格納するロール定義
├── playbooks/ # メインの実行用Playbook
├── reports/ # 構成調査レポート（テンプレートのみGit管理、実レポートは除外）
├── AGENTS.md
├── .vault_pass # ローカル検証用の平文Vaultパスワード（Git管理除外）
└── .vault_pass_client.sh # 環境変数等から動的にパスワードを取得するスクリプト（Git管理対象）
公式に準拠して構成したつもりです。大事なのはsshアクセスなど、鍵やパスワードの管理です。暗号化されたシークレット情報も取り扱えるので、共同管理もしやすいです。また、GithubやGitlabのレポジトリで管理もできますね。
試した例
SSH接続回り等々設定したあと、Antigravityから、ラズパイOSの状況を調べさせます。すると、利用可能なセキュリティアップデートを検出して、upgradeせよと言うと次のコマンドを実行してくれます。
uv run ansible -i inventories/production/hosts.yml raspberrypi -m apt -a "upgrade=safe update_cache=yes" --become
ラズパイのパッケージ更新がなされました。
Preparing to unpack .../0-openssh-server_1%3a8.4p1-5+deb11u7_armhf.deb ...
Unpacking openssh-server (1:8.4p1-5+deb11u7) over (1:8.4p1-5+deb11u6) ...
Unpacking openssh-client (1:8.4p1-5+deb11u7) over (1:8.4p1-5+deb11u6) ...
Unpacking openssl (1.1.1w-0+deb11u7) over (1.1.1w-0+deb11u5) ...
Unpacking sudo (1.9.5p2-3+deb11u4) over (1.9.5p2-3+deb11u3) ...
Setting up openssh-server (1:8.4p1-5+deb11u7) ...
Setting up openssl (1.1.1w-0+deb11u7) ...
Setting up sudo (1.9.5p2-3+deb11u4) ...
さくっと行けそうなので、.envの書き換えや、docker composeのoverride設定といった作業も、Antigravityで調査・計画を行い、構築まで進めることができました。エラーが出たら調査の流れも問題なく実施できました。.envの書き換え、書き換え部分だけをansibleで管理できるので、後から参照できるのも助かります。また、ログを残しておけば後から「なにしたっけ・・・？」と調べることも簡単です。
自動化（IaC）は便利ですが、一歩間違えると機密情報の流出や不要なポート開放、情報露出のリスクあり。そこで、「セキュアな設計」を意識して作ってみました。「AIエージェントとの協調作業」前提までサクッと構築できました。
AIエージェントとAnsibleを組み合わせることで、「環境調査 → 設定変更 → 検証 → ログ保存」という一連の作業を比較的安全に自動化できそうだという手応えを得られました。思っていた以上に「何を変更したか」をAnsible側に残せるのも便利でした。
詳細は以下のレポジトリを参照してください。
WindowsDeveloperConfigが気になったので、試しに使ってみましたので、メモ。
Windowsで開発するための道具を一気に入れるmicrosoftツール
1. Dev Config: Windowsの設定やWSL、ターミナル、関連ソフトを一気にインストール
2. WSL Comfort: zshやCLIツールを一気にいれる。
3. 言語インストール: Pythonだたり、Goだったり。
具体的にはWingetで一気にセットアップします。
git clone https://github.com/microsoft/WindowsDeveloperConfig.git
cd WindowsDeveloperConfigwinget configure -f .\windows-dev-config\dev-config.winget --accept-configuration-agreements --disable-interactivity
で、次々に導入されます。色々入るので、ちょっとビビりました。
インストールされる開発ツール
ターミナル環境の設定
WindowsのOS設定
WSL（Windows Subsystem for Linux）
Oh My Poshが有効化されるのでターミナルがカラフルになります。
WSLまで一気にwingetで導入されるのは、便利。
Pythonを入れたければ
winget configure -f .\Workloads\python\configuration.winget --accept-configuration-agreements --disable-interactivity
uvも入れるようになってます。
不要なものを削るには、以下から# Software Installsの項目から削除。
そのまま利用しなくても参考に必要な環境だけをセットアップしたスクリプトを作り上げておくのは悪くないと感じました。
Google ColabにCLIが発表になり、AIエージェント系との親和性が一気に高くなりました。MCPはいまいち使いにくかったけれども、CLIで完結する方が私は楽そうだ、と、試してみました。
UltoshさんのGemma4チューニング用のColabノートで試してみつつ、今後も使えるようにSKILLS.mdを書いてみるところまで実施しました。
何は、ともあれ、Google Driveのアクセス用の認証要求もCLIでできそうなので、とても便利に利用できそうです。
# 🚀 AI ASSISTANT SKILLS & OPERATIONAL MANUAL > **Google Colab CLI (colab) クラウド計算制御・最適化マニュアル** > > 本マニュアルは、AIアシスタント（あなた）がクラウド計算資源を極限まで効率的、かつ安全に利用するための拡張スキルおよび運用規約である。 --- ## 1. 共通行動指針 (Core Guidelines) * 💻 **環境認識**: Windows（ホスト）と WSL2（Ubuntu/Linux）のハイブリッド環境。 * ⚡ **リソース最適化**: ローカル環境（VRAM 12GB、CPU 8コア）を基準とし、これを超える高負荷タスクは自動的に本「クラウド計算スキル」へオフロードせよ。 * 📢 **自動発動ルール**: ユーザーから「Colabを利用する」等の明示的指示があった場合、または以下の条件を検知した場合は**本スキルを自動発動**し、ローカル実行を回避すること。 --- ## 2. 【拡張スキル】Google Colab CLI によるクラウド計算 ### 2.1 自動発動条件 (Trigger Conditions) 以下に該当する重い処理は、即座にクラウド実行へ移行せよ： * ⏳ **長時間の処理**: 10時間を超えるLLM/VLMの微調整・学習スクリプトの実行 * 📦 **大量データ処理**: 大量ドキュメントに対する重いデータ前処理（例: 100ファイル以上のPDFパース、画像のバッチ変換など） * 🧠 **巨大モデルの推論**: ローカルVRAM（12GB）に収まらないサイズのモデルのロードおよび推論・評価検証 ### 2.2 コマンド実行の絶対制約 (Constraints) 1. **Linux実行の徹底**: すべての `colab` コマンドは、必ず `wsl colab ...` のようにWSL2を経由して発行すること。WindowsのCmdやPowerShellから直接呼び出してはならない。 2. **自動消滅バッチ優先**: 原則として、実行終了後にVMが自動破棄される `wsl colab run` を最優先で選択すること（消し忘れ・リソース浪費の防止）。 3. **セルタイムアウトの延長（超重要）**: デフォルトのセル実行タイムアウトは **10.0秒** である。モデルロードや学習ステップを含む処理では、タイムアウトによる停止を避けるため、必ず `--timeout 1800`（30分）〜`--timeout 3600`（1時間）などの十分な値を指定せよ。 4. **Keep-Aliveの監視**: GCPプロジェクト権限（`serviceusage.serviceUsageConsumer` 等）の不足により、バックグラウンドのKeep-Aliveが403エラーで強制停止する場合がある。この場合、**約20分でVMが自動終了**するため、短時間の学習に抑えるか、権限設定を確認すること。 --- ### 2.3 コマンド・クイックリファレンス (Quick Reference Sheet) | 分類 | コマンド例 | 用途・注意点 | | :--- | :--- | :--- | | **自動破棄型** | `wsl colab run --gpu L4 ./train.py --timeout 1800` | スクリプトのワンショット実行（推奨）。終了後VMを自動破棄。 | | **セッション開始**| `wsl colab new -s [session_name] --gpu L4` | 状態を保持するインタラクティブなセッションを開始。 | | **パッケージ追加**| `wsl colab install -s [session_name] unsloth torch`| `uv`優先でVM上にパッケージを高速インストール。 | | **コード/ノート実行**| `wsl colab exec -s [session_name] -f [path.ipynb] --timeout 1800` | 指定ファイルを実行。重い処理には必ず `--timeout` を設定。 | | **ファイル転送 (UP)**| `wsl colab upload -s [session_name] [local] /content/[remote]` | ローカルファイルをVM上の任意のパス（基本 `/content/` 以下）にアップロード。 | | **ファイル転送 (DL)**| `wsl colab download -s [session_name] /content/[remote] [local]` | VM上のファイルをローカルにダウンロード。（※カレントディレクトリは `/content/`） | | **Drive連携** | `wsl colab drivemount -s [session_name]` | `/content/drive/MyDrive` をマウント。大容量データや永続保存に使用。 | | **ログ回収** | `wsl colab log -s [session_name] -o [output.md]` | 実行履歴ログを回収。**VMが途中でシャットダウンした後でも回収可能。** | | **セッション停止** | `wsl colab stop -s [session_name]` | **【最重要】** セッションを即時停止・破棄し、クレジット消費を止める。 | --- ### 2.4 トラブルシューティング対応指針 (Troubleshooting) > [!WARNING] > **TimeoutError: Timeout waiting for reply が発生した場合** > - **原因**: 特定のセルまたは処理がデフォルト値（10秒）を超過して実行されたため。 > - **対策**: 実行コマンドに `--timeout 1800` (秒数) を追加して再実行せよ。 > [!IMPORTANT] > **Keep-Aliveエラー (consecutive_4xx_errors) によりVMが突然シャットダウンした場合** > - **原因**: サービス使用権限が不足し、接続維持デーモンが異常終了したため。 > - **対策**: > 1. すぐに `wsl colab log -s [セッション名] -o execution_log.md` を実行して、停止前までの進捗ログをローカルにサルベージせよ。 > 2. 大容量のモデル学習を行う際は、保存先をGoogle Drive（`/content/drive/MyDrive/...`）に指定しておき、VM停止時の中間生成物損失を抑えること。 --- 💡 **詳細マニュアル**: 各種コマンドのさらに詳細な仕組みや活用手順は、[usage.md](docs/usage.md) を参照すること。
詳細はこちら
Claude Code や Codex のような AI エージェントを利用すれば、Python を用いたデータ解析やファイル操作を手軽に実行できます。しかし、実際の業務環境では必ずしもそれらを自由に利用できるとは限りません。
セキュリティやコストの観点から AI エージェントの利用が制限されている環境も多く、ちょっとした解析やファイルの書き換えといった簡単な作業ですら、意外と手間やストレスが発生します。また、AI エージェントは便利である一方、実行内容やアクセス範囲の制御が難しいという課題もあります。
そこで、AI やコンテナ技術に詳しくない人でも気軽に利用でき、かつ安全に実行できる環境を提供したいと考えました。コンテナ内に任意の実行環境を構築し、外部通信を制限した状態で処理を実行できれば、情報漏えいのリスクを抑えながら柔軟な解析環境を実現できます。
もちろん、このような仕組み自体は既に存在しています。しかし、自分のサーバー上で完結させ、手元の計算リソースを最大限活用したいという思いがありました。加えて、コンテナや AI エージェントの仕組みをより深く理解するための学習も兼ねて、本システムを作成することにしました。
以前にも同様の仕組みを試作したことがありましたが、その際は LibreChat 側の制約により、日本語ファイル名を正しく実行コンテナへ渡せないという問題がありました。
しかし、LibreChat のファイル管理機構が刷新されたため、今回は新しい LibreChat（v0.8.6-rc1）をベースに再実装を行いました。
実装にあたっては、日本語ファイル名の取り扱い改善に加え、Matplotlib などで発生しがちな日本語文字化けへの対策も組み込んでいます。また、検証の過程で LibreChat 側に起因すると考えられるいくつかの不具合にも遭遇したため、それらを回避する仕組みも追加しました。
以下は、実際に実行して得られた結果の一部です。
※qwen3.5:4bによる結果
※Kimi-2.6
さらに連続して解析させると・・・。
できたもの。
前回まで
AIエージェントに検索をさせる場合、クエリに個人情報やトークンが勝手に送信されないような工夫を実施してみます。今回は、Microsoftが開発した個人特定情報（PII）の検出・匿名化用オープンソースフレームワーク「Presidio」の実装をテストしてみます。
なお、検索側にはSearXNGを利用しますが、契約したAPIの利用など、各エンジンの利用規約に注意してご利用ください。
利用するライブラリは以下になります。
presidio-analyzer
presidio-anonymizer
テキスト（クエリ）解析には、spaCyを用いているようです。デフォルトではpresidioは英語(en_core_web_lg)のモデルを使います。日本語モデル（ja_core_news_lg）を利用すれば日本語にも対応できます。日本語の場合は、「日本語（ja）」の設定に加え、分かち書きのためにsudachiも必要となります。
さらに精度を上げたい場合、今どきのGPUであればBERTベースのカスタムモデルをローカルでファインチューニングすることも簡単にできます。また、このライブラリは、固有表現抽出(NER)だけでなく、パターン認識(Regex)もマッチングでの排除もできますし、匿名化処理もできます。なにより、ローカルLLMを使うよりも軽量です。
プロンプトインジェクション検知機能はありませんが、プロンプトインジェクションにありがちな表現をNER学習させてしまえば、同じ要領で高速なフィルタリングが可能だと考えます。
ちなみに、LLMの外部ツール接続規格である「MCP」でツールを公開する場合は、LLM向けのdescription（説明文）に「秘密情報は入力しないでね」と明記するようにしています。お守りですね。
解析に利用されているspaCyは、長く開発されてきた言語処理ライブラリで安定感があります。
作ってみたものはこちら
