# doc-processing-std-tools

> AIエージェントに、ファイル、ドキュメント、Webリサーチ、ブラウザーやデスクトップの操作のためのツールを提供するMCPサーバーのライブラリ。

- 役割：設計・構築・保守
- 期間：2026年2月〜現在
- ステータス：保守中
- 使用技術：Python, MCP, FastMCP, Pydantic, Playwright, PyMuPDF, LibreOffice, Pillow, httpx, Docker
- リンク：[ドキュメント](https://doc-processing-std-tools.vercel.app/)
- 数字で見る：
  - **10** MCPサーバー：8個のコアサーバーと、オプションのブラウザーサーバー・デスクトップサーバー
  - **56** 8個のコアサーバーが提供するツール（v0.6.1時点、2026年10月）
  - **1,104** v0.6.1のリリース時点で合格したユニットテスト（2026年10月）
  - **149** 同じリリースで合格した、Docker上で実行するLinux統合テスト
- URL：https://www.rounakzoeb.com/ja/work/doc-processing-std-tools

---

![アーキテクチャ図：コンテナ内で1つのランチャーの背後に並ぶ10個のFastMCPサーバーと、外向き通信に対する安全制御。](https://www.rounakzoeb.com/_astro/02_architecture-ja.BpDLpjD3_Z134GEJ.png)

## 共通のツールライブラリをつくった理由

初期の顧客プロジェクトでは、同じ機能が繰り返し必要になりました。PDFを読む、ビジョンモデル向けにページを画像化する、Webを検索する、画像を編集する、コマンドを実行する、といった機能です。プロジェクトごとに少しずつ違う方法で解決していたため、それらを1つのPythonライブラリにまとめました。既製のツール群を使うこともできましたが、エージェントフレームワークと同じ理由で自作しました。各ツールは私のプロジェクトに必要なことを行い、ライブラリの依存関係も少ないので、その下で変わりうるものも少なくなります。

このライブラリは、MCPサーバーの集まりです。MCP (Model Context Protocol) は、AIアプリケーションとツールをつなぐためのオープンな標準規格です。サーバーが自身のツールを公開し、MCPに対応したクライアントであれば、どれでもそのツールを見つけて呼び出せます。そのため、同じツールを私の[エージェントフレームワーク](https://www.rounakzoeb.com/ja/work/doc-processing-toolkit)でも、コーディングエージェント、デスクトップアシスタント、独自アプリケーションといった他のMCPクライアントでも使えます。

詳しくは[ドキュメント](https://doc-processing-std-tools.vercel.app/)をご覧ください。設定ガイド、APIリファレンス、複数のサーバーを組み合わせてタスクを完結させるレシピ、コードから生成したツールリファレンスを掲載しています。ドキュメントは公開していますが、ソースコードは非公開です。ライブラリはPyPIでも公開していません。アプリケーションは、リリースタグを指定して非公開のGitリポジトリからインストールします。詳しく知りたい場合は、LinkedInでつながってください（[お問い合わせ](https://www.rounakzoeb.com/ja/contact)のページをご覧ください）。

## サーバーとツール

このライブラリを接続すると、エージェントは、PDFやOfficeファイルを読む、ビジョンモデル向けにページを画像化する、スキャンした文書にOCRをかける、Webを検索してページを取得する、画像を編集する、シェルコマンドを実行する、セッションをまたいで残るメモリを保持する、といったことができるようになります。オプションのサーバーを有効にすれば、ブラウザーやデスクトップも操作できます。

サーバーは全部で10個あり、FastMCPで構築しています。8個のコアサーバーは常時有効で、合わせて56のツールを提供します（v0.6.1時点、2026年10月）。

- ドキュメントとファイル：ファイルサーバー、ドキュメントサーバー（PDF、Word、Excel、PowerPoint、OCR、ビジョンモデル向けのページ画像化、LibreOfficeによる変換）、画像編集、スクリーンショット、永続メモリ
- Web：検索とページの取得
- 実行：シェルと、Agent Skills（タスクに必要なときにエージェントが読み込む、指示とスクリプトをまとめたパッケージ）のためのサーバー

残りの2個はオプションで、デフォルトでは無効です。1つはPlaywrightによるブラウザー、もう1つは、独自の仮想ディスプレイまたはユーザーの実際の画面を操作するデスクトップサーバーです。

各サーバーは単独で使うことができ、私のフレームワークからインプロセスで使うこともできます。また、ランチャーでサーバーをまとめ、stdioまたはstreamable HTTPで単一のMCPエンドポイントとして提供することもできます。2つのツールの名前が重複する場合、ランチャーはエラーで停止します。

## セキュリティモデル

ブラウザー、シェル、デスクトップへのアクセスには明確な制限が必要です。そのため、セキュリティはホストアプリケーションとサーバーで分担しています。

屋根の上で作業する大工には、技術があります。寸法を測り、材料を切り、取り付ける方法を知っています。しかし、どれだけのことを、どれだけ安全にできるかは、何を与えられるかで決まります。仕事に合った道具、作業のもとになる図面、作業場所に届くための足場、そして頑丈なところに留めた安全帯です。std-toolsのサーバーは、エージェントにとっての道具です。ドキュメントとファイル、Web、シェルです。セキュリティモデルは、その安全帯にあたります。影響の大きい操作は実行前に承認が必要で、作業は隔離されたコンテナの中で行われ、制限はエージェントの手の届かないところでサーバーが強制します。そのため、ミスがあっても転落にはつながりません。

サーバーは、ホストが管理するコンテナ（Dockerのような隔離されたサンドボックス）内で動かす前提で設計しており、そのコンテナがセキュリティの境界です。ホストが用意すべきもの（隔離、ネットワークポリシー、シークレットをエージェントの手の届かない場所に置くこと、慎重を要する操作の承認）は、ドキュメントに明記しています。

コンテナの中では、サーバー自身も次のチェックを強制します。

- サーバーサイドリクエストフォージェリ (SSRF)、つまり取得リクエストを内部アドレスへ誘導する攻撃への対策。リダイレクトのホップごとに、IANAの特殊用途アドレスレジストリと照合します
- ブラウザー用のエグレスプロキシ
- キー名のみに制限したデスクトップ入力と、キルスイッチ
- 取得データとファイルのサイズ上限
- プロセスツリー全体を終了させるタイムアウト

影響の大きい操作に対しては、設定可能な確認ゲートもあります。デフォルトでは無効です。有効にすると、該当する操作を拒否するか、MCPのelicitation（サーバーがユーザーに入力を求めるための、プロトコル上の仕組み）を通じて人に確認します。

残るリスクのある操作は、ホストアプリケーションが承認します。私のフレームワークでは、人の確認を待つか、呼び出しをスキップできる承認フックでこれを行います。サーバーのチェックは、ホストの隔離や権限管理と組み合わせて機能するものであり、それらを省いたホストの代わりにはなりません。

## デスクトップサーバーの抜け穴をふさぐ

最近のあるリリースは、主にセキュリティに関するものでした。デスクトップサーバーは、仮想デスクトップ上のキー入力にxdotoolを使います。xdotoolは、キー入力やマウス操作を画面に送るLinuxのプログラムです。xdotoolは特定の単語を独自の命令として扱い、そのうちの1つは別のプログラムを実行します。レビューで、デスクトップサーバーのキー入力ツールに送ったテキストが、そうした命令としてxdotoolに届きうることがわかったのです。ツールの入力をキー名のみに制限し、修正を実際に動かして確認しました。旧コードは注入されたコマンドを実行し、新コードはそれを拒否しました。

この変更に対するレビューで、さらに問題が見つかりました。私のプルリクエストをレビューするAIエージェントであるGitHub Copilotは、クリック時の修飾キーがデスクトップの確認ゲートをすり抜けうることに気づき、それを検証する過程で、ゲートをすり抜ける経路がさらに2つ見つかりました。続いて独立したレビュアーエージェントが、キーを数値やUnicodeで表記した場合にも通過できてしまうことを発見しました。キーは通常、F4のように名前で指定しますが、xdotoolは同じキーを数値やUnicodeのコードでも受け付けます。そのため、alt+0xffc1は、フォーカスのあるウィンドウを閉じるalt+F4の別の書き方になります。各修正には、旧コードでは失敗するテストを添えています。最後の独立レビューで、これらの経路がふさがったことを確認しました。これで抜け穴がないと証明できるわけではありませんが、これまでに見つかったものはいずれもテストでカバーしており、ラウンドを重ねるごとにコードはより安全になっています。

この仕事の進め方については、『[仕様ファースト、テストファースト](https://www.rounakzoeb.com/ja/writing/spec-first-test-first-building-with-ai-coding-agents)』に書いています。

## 活用先

本番運用では、私が日本の顧客企業向けに構築した[AIドキュメントプラットフォーム](https://www.rounakzoeb.com/ja/work/bilingual-ai-document-platform)のサンドボックス内で、ツール層として動いています。

また、共同開発者と構築中のパーソナルAIプラットフォーム（仮称：[AI App Builder](https://www.rounakzoeb.com/ja/work/ai-app-builder)）の基盤の一部でもあります。長めのタスクを実行し、小さなアプリを作るエージェントのためのプラットフォームです。現在の設計では、std-toolsはこのプラットフォームが使う共通のツールライブラリであり、ファイル操作やコード実行のツールの隔離は、プラットフォームのサンドボックスが担います。

私のフレームワークでは、サーバーをそのままツールとしてエージェントに渡せます。ドキュメントのクイックスタートにある例です。

```python
from doc_processing_toolkit import Agent
from doc_processing_std_tools import document_processing_server, file_system_server

agent = Agent(
    model="claude-sonnet-5",
    instructions="You read documents in the workspace and answer questions about them.",
    tools=[file_system_server, document_processing_server],
)

result = agent.run_sync("List the PDFs in ./reports and summarise the newest one.")
print(result.output)
```

エージェントは、ファイルサーバーでPDFを見つけ、ドキュメントサーバーでそれを読めます。

他のMCPクライアントも、ランチャー経由でサーバーを利用できます。ドキュメントには、そのためのレシピも用意しています。ウォークスルーやライブデモをご希望の場合は、[お問い合わせ](https://www.rounakzoeb.com/ja/contact)ください。

## プロジェクトのその他の画像

![機能ごとにグループ化した10個のMCPツールサーバーと、ツール名の例、オプションのブラウザーとデスクトップ、ワークフローの例を示す図。](https://www.rounakzoeb.com/_astro/03_servers_at_a_glance-ja.Xb1D1e9T_1lmXLF.png)

*10個のサーバーを役割ごとにまとめた図。8個のコアサーバー、オプションのブラウザーサーバーとデスクトップサーバー、そして複数のサーバーを組み合わせてタスクを完結させる、ドキュメント掲載のレシピを示しています。*

![セキュリティの層を示す図：アプリによる承認、設定可能な確認ゲート、ホストのコンテナ内でサーバー側が適用する固定の安全対策、そしてホストが提供するもの。](https://www.rounakzoeb.com/_astro/04_security_layers-ja.F1Bqp6ic_2sGvkH.png)

*セキュリティの役割分担。ホストアプリケーションによる承認、オプションの確認ゲート、サーバーに組み込まれた固定の安全対策、そしてホストのコンテナが提供する隔離とネットワークポリシーです。*