AI エージェントに 1 回のプロンプトでフォルダー全体のドキュメントを監査させ、ローカルで例外の単一テーブルを返すことで、署名ポリシーを強制できます。エージェントは Claude Desktop、Claude Code、Cursor、または GitHub Copilot 上で実行され、GroupDocs.Signature.Mcp サーバーがチェックを行います。スイープを開始するプロンプトは次のとおりです:

私の documents フォルダー内のすべての PDF について、デジタル署名がされていてまだ有効かどうかを確認してください。テーブルで返してください: ファイル、署名者、署名日、ステータス。

設定とトラブルシューティングを含むステップバイステップ版はドキュメントにあります: AI エージェントで署名済みドキュメントのフォルダーを監査する方法.

なぜ署名ポリシーに自動スイープが必要なのか

「アーカイブ内のすべての契約書に有効なデジタル署名が付いている」というようなポリシーは、実際に検証されなければ単なるポリシーに過ぎません。手動チェックはファイルを一つずつ開くため、実施頻度が低く、サンプルしかカバーしません。コンプライアンスが問う質問はアーカイブ全体に関するもので、署名されていない契約書はどれか、証明書が期限切れになっているのは誰か、署名後に変更されたファイルはどれか、ということです。

AI エージェントだけではこれらに答えることはできません。PDF を読むモデルは署名構造を見ることができないからです。エージェントはループと要約を提供し、エンジンがファイルごとの事実を提供します。

ワークフロー、ステップバイステップ

  1. サーバーをフォルダーに指す。 GROUPDOCS_MCP_STORAGE_PATH をドキュメントフォルダーに設定します。ファイルは名前で解決されるため、エージェントは contract-042.pdf を渡し、マシン上のパスは渡しません。
  2. ライセンスモードを確認。 エージェントに get_license_status を呼び出すよう指示します。評価モードでは各ドキュメントの最初の 2 ページしか処理されないため、クリーンなレポートでも誤っている可能性があります（下記の制限をご参照ください）。
  3. スイープを実行。 上記のプロンプトを使用します。各ファイルについてエージェントは search_digital_signatures を呼び出し、テーブルを組み立てます。デジタル署名が見つからないファイルは未署名として報告されます。
  4. 例外を確認。 テーブルをステータスでソートし、以下で説明する 3 つのグループを処理します。
  5. スケジュールで再実行。 同じプロンプトを翌月も同じフォルダーで使用できるため、監査はプロジェクトではなくルーティンになります。

エージェントが決定することとエンジンが行うこと

ステップ エージェントが決定すること エンジンが行うこと
チェックするファイル プロンプトからフォルダー内の PDF を一覧表示する ストレージから名前で各ファイルを解決する
署名されているか、有効か、誰が署名したか ファイルを選択する 署名者、発行者、シリアル番号、有効期間、タイムスタンプ、そして isValid を返す（search_digital_signatures）
レポート テーブルを作成し、例外をグループ化する なし；エンジンは要約しません

例示セッション（抜粋）

あなた:    私の documents フォルダー内のすべての PDF について、デジタル署名がされていてまだ有効かどうかを確認してください。テーブルで返してください: ファイル、署名者、署名日、ステータス。

エージェント:  [get_license_status]  mode: licensed
        [search_digital_signatures] x N
        | ファイル           | 署名者        | 署名日      | ステータス |
        | contract-041.pdf | Dana Whitfield | 2026-09-14 | 有効       |
        | contract-042.pdf | -              | -          | 未署名     |
        | contract-043.pdf | Omar Haddad    | 2026-08-02 | 無効       |
        例外: 未署名 1 件、無効 1 件。無効は通常、署名後にファイルが変更されたことを意味します。

例示的な出力です：ファイル名と署名者名は架空です。ツールは上記で説明したフィールドを返します。

重要な 3 つの例外

  • 未署名ファイル。 これが監査が存在する理由です。
  • 無効な署名。 ほぼ常に署名後に何かが変更されています：後からスタンプが追加された、再保存された、ページが追加された、など。どれがそうか知る価値があります。
  • 期限切れ証明書。 署名は作成時には有効でしたが、まだ有効とみなすかはポリシー次第です。有効期間は返されたデータに含まれるので、エージェントに有効期間が本日以前に終了したすべての証明書を一覧させてください。その比較で見つけられます。

スイープを低コストかつ信頼できるレポートにするには？

  • すべてのファイルで search_digital_signatures を実行します。verify はオプションの簡易スクリーニングとしてだけ追加し、詳細レコードを真実の情報源として扱います。
  • バルクで search_image_signatures をスキップします。ヒットごとに base64 画像を返し、無駄に実行時間が増えます。
  • コード検索時は returnImage をオフにしておきます。
  • 従量課金ライセンスでは各呼び出しが使用量として課金されるため、対象を絞ったスイープはコストが低く、かつ高速に実行できます。
  • ファイルごとの証明書詳細（署名者、発行者、シリアル、タイムスタンプ）を記録として保持してください。エージェントの文章要約はレポートであり、証明ではなく、公証行為でもありません。

例外に対処する

同じセッションでスイープで見つかった問題を修正できます。例えば、未署名ファイルにリファレンスマークを適用することで：

未署名の 3 ファイルに標準の QR リファレンスで署名し、実施内容を一覧してください。

何をするか正確に指示してください。QR コードは視覚的なマークであり、証明書ベースの署名ではないため、必須のデジタル署名の代わりにはなりません。署名が必要なファイルには、最後に sign と type: "digital" を使用して適用してください。

自社プロセスで明示すべき制限

評価モードでは各ドキュメントの最初の 2 ページのみが処理され、すべてのページにトライアルバッジが付与されます。4 ページ目の署名は表示されないため、ライセンスなしのバルク監査では実際には署名があるファイルを「クリーン」と報告する可能性があります。毎回最初に get_license_status を確認してください。サーバーはファイルから署名データを読み取りますが、ポリシーは把握していないため、許容できる証明書の定義は利用者側に残ります。

FAQ

どの契約書が未署名ですか？
エージェントにフォルダーを監査させ、デジタル署名がないファイルを一覧させてください。各ファイルに search_digital_signatures が呼び出され、署名が見つからなかったファイルは未署名として一覧に表示されます。結果は 1 つのテーブルです。

AI は PDF 署名のバルクチェックができますか？
はい、フォルダー全体に対して 1 回のプロンプトでローカルに実行できます。ライセンスがない場合は各ファイルの最初の 2 ページのみが検査されます。

レポートはコンプライアンス証拠として使用できますか？
エンジンが返すファイルごとの証明書詳細を証拠として保持してください。エージェントの要約は便利なものですが、証明ではありません。

詳細を見る