doc-processing-std-tools · ロナク・ゾエブ

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

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

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

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

サーバーとツール

このライブラリを接続すると、エージェントは、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の別の書き方になります。各修正には、旧コードでは失敗するテストを添えています。最後の独立レビューで、これらの経路がふさがったことを確認しました。これで抜け穴がないと証明できるわけではありませんが、これまでに見つかったものはいずれもテストでカバーしており、ラウンドを重ねるごとにコードはより安全になっています。

この仕事の進め方については、『仕様ファースト、テストファースト』に書いています。

活用先

本番運用では、私が日本の顧客企業向けに構築したAIドキュメントプラットフォームのサンドボックス内で、ツール層として動いています。

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

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

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)