外部デクリプションサービス経由の暗号化ファイル取り込み

Automation Anywhere Enterprise Knowledge Base（AAEKB / EKB） — 管理者および統合ガイド

この機能の作用

AAEKB は、アップロードされたファイルを自分がホストし管理する外部デクリプションサービスに渡し、復号されたバイトを受け取り、その復号コンテンツに対して通常の Knowledge Base 取り込みパイプライン（テキスト抽出、OCR、チャンク化、埋め込み、インデックス化）を実行できます。

これは、保存中の文書にエンタープライズ DRM またはエンベロープ暗号化を適用し、復号鍵をサードパーティアプリケーションに送信できない組織のために存在します。鍵、復号ロジック、平文の境界はすべて自分のネットワークの中に留まります。AAEKB は HTTP エンドポイントを呼び出し、バイトストリームを読み戻す方法だけを知っています。

統合は意図的に汎用的で設定駆動です。AAEKB の中にベンダー固有の DRM SDK はありません。ファイルを受け取りファイルを返す任意の HTTP サービス — 同期でもジョブ/ポーリングパターンでも — が、あなたのデクリプションサービスが実装すべき契約に適合すれば、接続できます。

主要な特性：

アップロードごとのオプトイン。 ユーザーが明示的にトグルをチェックしたときのみ、ファイルがデクリプションサービスに送信されます。通常のアップロードは完全に影響を受けません。
単一のグローバル構成。 AAEKB デプロイメントごとに、スーパー管理者がデクリプションサービスを1つ構成します。
メモリ内のみ。 暗号化バイト、サービスへのリクエスト、復号されたレスポンスはすべてメモリで処理されます。AAEKB はあなたのサービスを呼び出す前に暗号文を一時ファイルに書きません。
AAEKB に鍵素材なし。 AAEKB はエンドポイント URL と、任意でサービスを呼び出すための API 資格情報を保存します。文書の暗号化鍵を保存も取り扱いもしません。

エンドツーエンドの仕組み

 User (browser)                AAEKB backend                 Your decryption service
      |                              |                                  |
      |  1. Upload file +            |                                  |
      |     "Requires Decryption"    |                                  |
      |----------------------------->|                                  |
      |                              |                                  |
      |            2. File security validation                          |
      |               (runs on the ENCRYPTED bytes)                     |
      |                              |                                  |
      |                              |  3. POST encrypted file          |
      |                              |--------------------------------->|
      |                              |                                  |
      |                              |  4a. sync: 200 + decrypted bytes |
      |                              |<---------------------------------|
      |                              |                                  |
      |                              |  4b. async: 202 + { job_id }     |
      |                              |<---------------------------------|
      |                              |  5b. GET poll/{job_id}  (repeat) |
      |                              |--------------------------------->|
      |                              |  6b. 200 + decrypted bytes       |
      |                              |<---------------------------------|
      |                              |                                  |
      |            7. MIME type re-detected on decrypted bytes          |
      |            8. Decrypted file stored in KB raw storage           |
      |            9. Normal ingestion: extract, chunk, embed, index    |
      |                              |                                  |
      |  10. Resource appears in KB  |                                  |
      |<-----------------------------|                                  |

ステップごとに：

アップロード。 ユーザーは Knowledge Base のアップロードモーダルでファイルを選択し、Requires Decryption トグルを有効にします。フロントエンドはファイルに合わせて追加のフォームフィールドとして needs_decryption=true を送信します。
ファイルセキュリティ検証。 AAEKB の標準アップロードセキュリティミドルウェアは、復号の前に暗号化バイトと元のファイル名に対して実行されます。これが単一で最も重要な互換性制約です — 互換性をご覧ください。
サービスに送信。 AAEKB はファイルをメモリに読み、構成済みの復号エンドポイントに送信します。
平文を受け取る。 直ちに（sync モード）か、結果エンドポイントのポーリング後（async モード）。
ファイルタイプを再検出。 AAEKB は復号バイトから MIME 型を導出し直します：まずファイル名の拡張子から、それが何も生まない場合は復号コンテンツの先頭 2KB をスニッフィング。
保存と取り込み。 復号されたファイルが Knowledge Base の raw ファイルストレージに書き込まれ、通常の取り込みパイプラインで処理されます。復号メタデータはドキュメントのメタデータレコードにマージされます。

2つのアップロード経路が存在し、どちらも同じようにこの機能をサポートします：

経路	エンドポイント	復号が実行される場所
同期アップロード（レガシー / Quick Upload）	`POST /v3/project/knowledge/add/file`	Web リクエスト内
バックグラウンドアップロード（デフォルト）	`POST /v5/project/knowledge/add/file`	バックグラウンドワーカープロセス内

実務的な帰結：Web/API コンテナとバックグラウンドワーカーコンテナの両方がデクリプションサービスに到達できる必要があります。

サービスの構成（スーパー管理者）

スーパー管理者としてサインインします。
Super Admin → Platform & integrations → KB Decryption Service を開きます。
完全な構成リファレンスで説明する構成を入力します。
Enabled トグルをオンにします。
Save Changes をクリックします。

管理画面に関する注意：

Async Polling Configuration カードは、Response Mode が Asynchronous に設定されているときのみ表示されます。
認証資格情報フィールドは構成の読み戻し時にマスクされます。最初の4文字のみ表示され、残りは箇条書き文字に置換されます。フィールドに触れずに再保存しても保存済みの資格情報は変わりません。資格情報をローテーションするには、フィールドをクリアして新しい値を完全に入力してください。
保存はフォーム全体でアトミックです — フィールドごとの保存はありません。
Enabled をオフにすると、エンドユーザーのトグルが即座に非表示になり、まだ needs_decryption=true を主張するアップロードは明確なエラー付きで拒否されます。

同じ構成は自動プロビジョニングのために REST API 経由でも利用できます：

メソッド	パス	アクセス	目的
`GET`	`/admin/kb-decryption-service`	Super Admin	構成の読取（資格情報はマスク）
`PUT`	`/admin/kb-decryption-service`	Super Admin	部分更新；送信したフィールドのみ変更
`GET`	`/kb-decryption-service/status`	すべての認証済みユーザー	`{"available": true}` を返す

プロビジョニング呼び出しの例：

curl -X PUT "https://ekb.example.com/admin/kb-decryption-service" \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{
        "enabled": true,
        "display_name": "Corporate DRM Gateway",
        "description": "Intranet decryption service for classified documents",
        "decrypt_endpoint": "https://drm.corp.internal/api/v1/async/decrypt/stream",
        "decrypt_http_method": "POST",
        "decrypt_content_type": "multipart/form-data",
        "decrypt_file_field_name": "file",
        "decrypt_extra_headers": {"X-Tenant": "aa-ekb"},
        "decrypt_extra_body_fields": {"purpose": "ingestion"},
        "response_mode": "async",
        "poll_endpoint_template": "https://drm.corp.internal/api/v1/async/download/stream/{job_id}",
        "poll_interval_seconds": 5,
        "poll_max_attempts": 120,
        "poll_job_id_json_path": "job_id",
        "poll_status_json_path": "status",
        "poll_completed_status": "COMPLETED",
        "poll_failed_statuses": "FAILED,ERROR",
        "auth_type": "api_key_header",
        "auth_token": "s3cr3t-api-key",
        "auth_header_name": "X-API-Key"
      }'

完全な構成リファレンス

一般

フィールド	型	デフォルト	意味
`enabled`	boolean	`false`	マスタースイッチ。オフの場合、エンドユーザーのトグルは非表示で、復号リクエストは拒否されます。
`display_name`	string	`Default Decryption Service`	親しみやすい名前。各復号ドキュメントのメタデータに記録されます。
`description`	string	（空）	管理者向けの自由記述メモ。ランタイムでは使用されません。

復号リクエスト

フィールド	型	デフォルト	意味
`decrypt_endpoint`	URL	（空）	AAEKB が暗号化ファイルを POST する絶対 URL。API とワーカーの両コンテナから到達可能でなければなりません。
`decrypt_http_method`	`POST` \| `PUT`	`POST`	送信リクエストに使用される HTTP メソッド。
`decrypt_content_type`	`multipart/form-data` \| `application/octet-stream`	`multipart/form-data`	ファイルの送信方法。下記の注意をご覧ください。
`decrypt_file_field_name`	string	`file`	ファイルを運ぶ multipart フォームフィールド名。multipart モードでのみ使用。
`decrypt_extra_headers`	JSON オブジェクト	`{}`	送信リクエストとすべてのポーリングリクエストの両方にマージされる追加ヘッダー。
`decrypt_extra_body_fields`	JSON オブジェクト	`{}`	ファイルと一緒に送信される追加フォームフィールド。multipart モードでのみ使用。
`response_mode`	`sync` \| `async`	`async`	復号バイトが送信呼び出しで返るか、ポーリング経由か。

警告

application/octet-stream モード。 コンテンツタイプが application/octet-stream の場合、AAEKB は生のファイルバイトをリクエストボディ全体として送信します。このモードではファイル名は送信されず、decrypt_extra_body_fields は無視されます。これらを運ぶマルチパートエンベロープが存在しないためです。サービスがファイル名や追加コンテキストを必要とする場合は、multipart/form-data を使うか、decrypt_extra_headers を通じてコンテキストを渡してください。

非同期ポーリング（`response_mode = async` のときのみ使用）

フィールド	型	デフォルト	意味
`poll_endpoint_template`	テンプレート URL	（空）	結果 URL。リテラルのプレースホルダー `{job_id}` を含まなければならず、抽出されたジョブ識別子に置換されます。
`poll_interval_seconds`	integer	`5`	ポーリング間の待機秒。AAEKB は最初のポーリングの前にスリープするため、最小の復号レイテンシは1インターバルです。
`poll_max_attempts`	integer	`120`	最大ポーリング回数。合計バジェット = `poll_interval_seconds × poll_max_attempts`（デフォルト 600秒 / 10分）。
`poll_job_id_json_path`	ドットパス	`job_id`	送信レスポンス内のジョブ識別子の場所。例：`data.jobId`。
`poll_status_json_path`	ドットパス	`status`	JSON ポーリングレスポンス内のジョブステータスの場所。例：`result.state`。
`poll_completed_status`	string	`COMPLETED`	「完了」を意味するステータス値。大文字小文字を区別せず比較。
`poll_failed_statuses`	カンマ区切り	`FAILED,ERROR`	ジョブを即座に中断するステータス値。大文字小文字を区別せず比較。

ドットパスは単純なネスト辞書ルックアップです。data.job.id は response["data"]["job"]["id"] を解決します。配列インデックスはサポートされません — パスのセグメントはリストインデックスであってはなりません。

認証

フィールド	型	デフォルト	意味
`auth_type`	`none` \| `bearer` \| `api_key_header` \| `custom_headers`	`none`	認証スキーム。認証オプションをご覧ください。
`auth_token`	シークレット文字列	（空）	ベアラートークンまたは API キー値。読取時にマスク。
`auth_header_name`	string	`Authorization`	`auth_type = api_key_header` のときに使用されるヘッダー名。

あなたのデクリプションサービスが実装すべき契約

これは、デクリプションサービスを構築・運用する人へ渡す仕様です。

妥協できない要件

HTTP(S) で話す。 ファイルを受け取る1つのエンドポイント；async モードでは、ジョブの結果を返す2つ目のエンドポイント。
復号ファイルを生のバイトで返す — base64 ではなく、JSON に包まず、ダウンロード URL へのリダイレクトでもない。AAEKB はレスポンスボディをそのまま取り込みパイプラインにストリームします。
ファイルの元の形式を保持する。 暗号文が PDF に復号されるなら、正常な PDF を返す。AAEKB は形式変換を一切行いません。
成功時に空でないボディを返す。 空のレスポンスは失敗として扱われます。
AAEKB の API とワーカーコンテナから到達可能で、それらのコンテナが信頼する TLS 証明書を持つこと。
ポーリングエンドポイントでの反復 GET を生き延びるだけの冪等性を持つこと。2重 GET の挙動をご覧ください。

送信エンドポイント

Multipart モード（推奨）。 AAEKB は以下を送信します：

メソッド：構成どおり（POST または PUT）
Content-Type：生成された境界付きの multipart/form-data
decrypt_file_field_name という名前の1つのファイルパーツ、filename は元のアップロードファイル名
decrypt_extra_body_fields からの0個以上の追加フォームフィールド
構成どおりの認証と追加ヘッダー

Octet-stream モード。 AAEKB は Content-Type: application/octet-stream でリクエストボディとして生バイトを送信します。ファイル名なし、追加ボディフィールドなし。

期待されるレスポンス：

モード	許容ステータス	ボディ
`sync`	`200` のみ	復号されたファイルバイト
`async`	`202`（典型的）または `200`	ジョブ識別子を含む JSON、または — バイナリコンテンツタイプでの `200` — 復号バイトそのもの

async モードで AAEKB はポーリングするかどうかを決める前に送信レスポンスを検査します：

200 かつバイナリに見える Content-Type → バイトが直接使用され、ポーリングなし。（これによりサービスは小さなファイルで短絡できます。）
それ以外 → ボディを JSON として解析し、poll_job_id_json_path を使ってジョブ識別子を抽出。

「バイナリに見える」コンテンツタイプとは、octet-stream を含むもの、または application/ で始まり json を含まないものを指します。したがって application/octet-stream と application/pdf はバイナリとして扱われ、application/json はそうではありません。text/plain はバイナリとして扱われません — Content-Type の指針をご覧ください。

ポーリングエンドポイント（async モード）

AAEKB は、{job_id} を置換した poll_endpoint_template に GET を発行し、送信リクエストと同じ認証と追加ヘッダーを運びます。poll_interval_seconds ごとに、poll_max_attempts 回までこれを繰り返します。

サービスは以下のいずれかで応答すべきです：

状況	ステータス	ボディ	AAEKB の挙動
作業中	`202`	任意（無視）	待って再ポーリング
作業中	`200`	ステータスフィールドが完了値でも失敗値でもない JSON	待って再ポーリング
完了	`200`	バイナリ `Content-Type` の生の復号バイト	推奨。バイトが使用され；ポーリング停止
完了	`200`	ステータスフィールドが `poll_completed_status` に等しい JSON	同じ URL にバイナリを期待うもう1回の `GET` を発行；それがバイナリでなければアップロード失敗
失敗	`200`	ステータスフィールドが `poll_failed_statuses` にある JSON	ステータスを名指ししたエラーで即座に中断
エラー	`>= 400`	任意	即座に中断。再試行しない

警告

まだ準備だけが済んでいないジョブに 404 を返さないでください。400以上のステータスコードはすべて、硬い失敗でジョブを終了させます。「準備中」には 202 を使用してください。

2重 GET の挙動（async モード）

ポーリングエンドポイントが、ジョブが完了したことを示す JSON ボディで 200 に応答した場合、AAEKB はファイルを別途取得する必要があると判断し、まったく同じ URL に2回目の GET を直ちに発行し、今度はバイナリストリームを期待します。2回目の呼び出しも JSON を返した場合、アップロードは "Decryption job completed but no file stream was returned." で失敗します。

これを満たす方法は2つあります：

推奨： ジョブが完了したらすぐにポーリングエンドポイントが Content-Type: application/octet-stream で生バイトを直接返す。AAEKB は最初のポーリングでこれを検出し、2回目のリクエストを決して発行しません。これが最も単純で最速の設計です。
許容： ペンディング/完了時にエンドポイントが JSON ステータスを返し、後続の呼び出しでバイトストリームを返すように切り替える。ジョブは、最初に完了を報告した後、少なくとも1回分の追加 GET で取得可能でなければなりません。

サポートされないのは、完了 JSON が別のダウンロード URL を含む設計です。AAEKB はそれを追いません。

Content-Type の指針

レスポンス	推奨される `Content-Type`
復号されたファイルバイト	`application/octet-stream`
ジョブ受理 / ジョブステータス	`application/json`

async モードで復号ペイロードを text/plain や text/csv で返すと、AAEKB はそれをジョブステータスの JSON ドキュメントとして解析しようとして失敗します。sync モードではレスポンスのコンテンツタイプは一切検査されません — 任意の 200 が復号バイトとして扱われます — ただし一貫性のため application/octet-stream がまだ推奨されます。

AAEKB が決して行わないこと

復号鍵、ユーザー資格情報、エンドユーザーのアイデンティティをあなたのサービスに送信しない。サービスがドキュメントごとやユーザーごとに認可する必要がある場合、そのコンテキストは decrypt_extra_headers / decrypt_extra_body_fields から来なければならず、これらは静的でデプロイ全体です。
失敗した送信や失敗したポーリングを再試行しない。1回の失敗でアップロードは終了します。
完了ハンドシェイクの一環として、別のダウンロードホストへのリダイレクトを追わない。
大きなファイルをチャンク化したりレンジリクエストしたりしない。ファイル全体が1つのリクエストで入り、1つのレスポンスで返ります。

具体例：同期モード

構成：

{
  "enabled": true,
  "decrypt_endpoint": "https://drm.corp.internal/api/v1/decrypt",
  "decrypt_http_method": "POST",
  "decrypt_content_type": "multipart/form-data",
  "decrypt_file_field_name": "file",
  "decrypt_extra_body_fields": { "purpose": "ingestion" },
  "decrypt_extra_headers": { "X-Tenant": "aa-ekb" },
  "response_mode": "sync",
  "auth_type": "bearer",
  "auth_token": "eyJhbGciOi..."
}

AAEKB が送信するリクエスト：

POST /api/v1/decrypt HTTP/1.1
Host: drm.corp.internal
Authorization: Bearer eyJhbGciOi...
X-Tenant: aa-ekb
Content-Type: multipart/form-data; boundary=----AAEKBBoundary7MA4YWxk
Content-Length: 2481037

------AAEKBBoundary7MA4YWxk
Content-Disposition: form-data; name="purpose"

ingestion
------AAEKBBoundary7MA4YWxk
Content-Disposition: form-data; name="file"; filename="Q3-Financials.pdf"
Content-Type: application/octet-stream

<...encrypted bytes...>
------AAEKBBoundary7MA4YWxk--

サービスが返す必要のある成功レスポンス：

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 2394112
Content-Disposition: attachment; filename="Q3-Financials.pdf"

%PDF-1.7
<...decrypted bytes...>

Content-Disposition は任意で無視されます；AAEKB は元のアップロードファイル名を保持します。

失敗レスポンス — 200 以外はいずれもアップロードを終了させます。短く人間が読めるボディを含めてください；AAEKB はその先頭500文字をエンドユーザーに表示します。

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "Document policy forbids export for this identity"}

ユーザーが見るもの：Decryption service returned HTTP 403: {"error": "Document policy forbids export for this identity"}

具体例：非同期（ポーリング）モード

構成：

{
  "enabled": true,
  "decrypt_endpoint": "https://drm.corp.internal/api/v1/async/decrypt/stream",
  "decrypt_content_type": "multipart/form-data",
  "decrypt_file_field_name": "file",
  "response_mode": "async",
  "poll_endpoint_template": "https://drm.corp.internal/api/v1/async/download/stream/{job_id}",
  "poll_interval_seconds": 5,
  "poll_max_attempts": 120,
  "poll_job_id_json_path": "job_id",
  "poll_status_json_path": "status",
  "poll_completed_status": "COMPLETED",
  "poll_failed_statuses": "FAILED,ERROR",
  "auth_type": "api_key_header",
  "auth_token": "s3cr3t-api-key",
  "auth_header_name": "X-API-Key"
}

ステップ1 — 送信

POST /api/v1/async/decrypt/stream HTTP/1.1
Host: drm.corp.internal
X-API-Key: s3cr3t-api-key
Content-Type: multipart/form-data; boundary=----AAEKBBoundary7MA4YWxk

------AAEKBBoundary7MA4YWxk
Content-Disposition: form-data; name="file"; filename="Q3-Financials.pdf"
Content-Type: application/octet-stream

<...encrypted bytes...>
------AAEKBBoundary7MA4YWxk--

レスポンス：

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "job_id": "8f14e45f-ceea-467a-9f7a-2a1d4b0c9e33",
  "status": "PENDING"
}

ネストした識別子の場合、代わりに poll_job_id_json_path を data.job.id に設定し、次を返します：

{ "data": { "job": { "id": "8f14e45f-ceea-467a-9f7a-2a1d4b0c9e33" } } }

ステップ2 — ペンディング中のポーリング

AAEKB は5秒待ち、次を実行します：

GET /api/v1/async/download/stream/8f14e45f-ceea-467a-9f7a-2a1d4b0c9e33 HTTP/1.1
Host: drm.corp.internal
X-API-Key: s3cr3t-api-key

以下のいずれも AAEKB を待ち続けさせます：

HTTP/1.1 202 Accepted
Content-Type: application/json

{"status": "PROCESSING", "message": "File is still being processed."}

HTTP/1.1 200 OK
Content-Type: application/json

{"status": "PROCESSING", "progress": 42}

ステップ3 — 完了時のポーリング（推奨パターン）

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 2394112
Content-Disposition: attachment; filename="Q3-Financials.pdf"

%PDF-1.7
<...decrypted bytes...>

AAEKB はポーリングを停止し、取り込みに進みます。

ステップ3（代替）— JSON で完了してからストリーム

HTTP/1.1 200 OK
Content-Type: application/json

{"status": "COMPLETED"}

AAEKB は同じ GET を直ちに再発行し、あなたのサービスは上記のバイナリストリームで応答しなければなりません。再度 JSON で応答した場合、アップロードは失敗します。

ステップ3（失敗）

HTTP/1.1 200 OK
Content-Type: application/json

{"status": "FAILED", "reason": "Key not available for principal"}

ユーザーが見るもの：External decryption job failed with status: FAILED

表示されるのはステータス値だけであり、あなたの reason フィールドではないことに注意してください。ユーザー向けメッセージに詳細が欲しい場合は、ステータス文字列にエンコードするか、代わりに記述的なボディ付きの 4xx/5xx を返してください。

参照モックサービス

実サービスの準備ができるまで、配管を検証するのに有用な、最小のエコー-back モック：

# Minimal AAEKB-compatible async decryption mock (FastAPI).
# Returns the uploaded bytes unchanged.
import io, uuid
from fastapi import FastAPI, UploadFile, File
from fastapi.responses import JSONResponse, StreamingResponse

app = FastAPI()
JOBS: dict[str, tuple[bytes, str]] = {}


@app.post("/api/v1/async/decrypt/stream")
async def submit(file: UploadFile = File(...)):
    job_id = str(uuid.uuid4())
    JOBS[job_id] = (await file.read(), file.filename or "file")
    return JSONResponse(status_code=202, content={"job_id": job_id, "status": "PENDING"})


@app.get("/api/v1/async/download/stream/{job_id}")
async def download(job_id: str):
    entry = JOBS.pop(job_id, None)
    if entry is None:
        # Not ready (or unknown). Must NOT be a 4xx — that would abort the job.
        return JSONResponse(status_code=202, content={"status": "PROCESSING"})
    data, filename = entry
    return StreamingResponse(
        io.BytesIO(data),
        media_type="application/octet-stream",
        headers={
            "Content-Disposition": f'attachment; filename="{filename}"',
            "Content-Length": str(len(data)),
        },
    )

認証オプション

`auth_type`	AAEKB が送るもの	備考
`none`	`decrypt_extra_headers` のみ	ネットワークレベルのコントロールと併用（プロキシで終端する mTLS、IP 許可リスト、サービスメッシュ）。
`bearer`	`Authorization: Bearer <auth_token>`	加えて `decrypt_extra_headers`。
`api_key_header`	`<auth_header_name>: <auth_token>`	加えて `decrypt_extra_headers`。典型的：`X-API-Key`。
`custom_headers`	`decrypt_extra_headers` のみ	資格情報を含む完全なヘッダーセットを extra headers の JSON に置く。署名スキームやマルチヘッダー認証に使用。

すべてのモードで decrypt_extra_headers がマージされ、結果のヘッダーセットは送信リクエストとすべてのポーリングリクエストの両方に適用されます。

ネイティブにはサポートされないもの： トークンリフレッシュ付きの OAuth 2.0 クライデンシャルス、HMAC リクエスト署名、AAEKB がクライアント証明書を提示する相互 TLS。3つとも、AAEKB とデクリプションサービスの間に小さな認証リバースプロキシまたはサイドカーを置き、decrypt_endpoint をプロキシに向けることで処理できます。ここで構成する静的トークンは自動リフレッシュしません；ローテーションする資格情報は管理画面で再保存するか PUT API 経由でプッシュする必要があります。

エンドユーザー体験

可視性。 Knowledge Base のアップロードモーダルは開くときに GET /kb-decryption-service/status を呼びます。Requires Decryption トグルはそれが {"available": true} を返したときにのみレンダリングされ、これは構成行が存在し enabled が true であることを要求します。構成済みサービスのないデプロイのユーザーは決してそれを見ません。ステータス結果はブラウザに短時間（約30秒）キャッシュされるため、機能の有効/無効化が既に開いているセッションに現れるまでにそれほどの時間がかかる場合があります。

表示場所。 KB の2つのアップロードエントリポイントが両方ともトグルを公開します：

Add Resources モーダル（Knowledge Base 内のドラッグアンドドロップ / ファイル選択）
Selected Files モーダル（KB ビューにファイルをドロップしたときに使用）

スコープ。 トグルはファイルごとではなく、アップロードバッチごとです。オンの場合、そのバッチ内のすべてのファイル — 選択したフォルダ内のすべてのファイルを含む — がデクリプションサービスに送信されます。暗号化と非暗号化ファイルの混合バッチはサポートされません；別々にアップロードしてください。

デフォルト状態。 オフ。モーダルを閉じて開くたびにオフにリセットされます。

失敗時の挙動。 復号に失敗すると、そのファイルのアップロードが失敗し、エラーがアップロード進捗リスト / トーストに表示されます。バッチ内の他のファイルは影響を受けません。部分的なものは何もインデックス化されません。

進捗。 ブラウザの進捗バーは AAEKB へのバイトのアップロードのみを追跡します。あなたのデクリプションサービスで費やされる時間はその後サーバー側で発生し、アップロード進捗ではなく処理時間として表示されます。デフォルトのポーリング設定では、即座の復号でもファイルあたり少なくとも5秒の追加レイテンシを見込んでください。

互換性：動作するものとしないもの

警告

このセクションを注意深く読んでください。ほぼすべての統合上の驚きの源です。

重要な制約：検証は復号の前に発生する

AAEKB は、ファイルをあなたのデクリプションサービスに送る前に暗号化バイトと元のファイル名に対して標準のアップロードセキュリティ検証を実行します。needs_decryption のバイパスはありません。これは、暗号化ファイルはアップロードの時点で、正当で許可されたファイルタイプに見える必要があるということを意味します。

検証は順に以下を行います：

ファイル名チェック — パストラバーサルなし、ヌルバイトなし、Windows 違法文字なし、最大255文字、疑わしい二重拡張子なし。
拡張子許可リスト — ファイルは拡張子を持たなければならず、サポートされるタイプのいずれかでなければなりません。
サイズ制限 — 4096 MB（4 GB）の上限。
コンテンツスニッフィング（libmagic） — 先頭2KBを検査し、主張された拡張子と比較。実行可能シグネチャ（PE / ELF / Mach-O）はそのまま拒否されます。
タイプ固有のコンテンツチェック — 例：画像は開いて検証され、テキストファイルはテキストとして正しくデコードされなければなりません。

サポートされるファイル拡張子

これらの拡張子のみ受け付けられます（スクリプトタイプは、デプロイがスクリプトアップロードを明示的に有効化している場合のみ）：

ドキュメント： pdf、doc、docx、xls、xlsx、pptx
テキストとデータ： txt、md、csv、tsv、json、xml、dita、yaml、yml、html、htm
メール： eml、msg
アーカイブ： zip
画像： png、jpg、jpeg、gif、webp
音声： mp3、wav、m4a、ogg
映像： mp4、mov、avi、wmv、webm
スクリプト（オプトインのみ）： py、sh、bash、js、php、rb、pl、bat、cmd、ps1

デプロイのライブリストは GET /upload-capabilities で利用できます。

ファイル名とラッパーの互換性

アップロードされるファイル名	結果
`Report.pdf`（中に暗号文）	暗号文エンベロープに依存 — 下記参照
`Report.pdf.enc`	拒否。 `.enc` は許可された拡張子ではない
`Report.enc`、`Report.drm`、`Report.aes`	拒否。許可されていない拡張子
`Report`（拡張子なし）	拒否。「File must have an extension」
`Report.pdf.gpg`	拒否。 `.gpg` は許可されていない

暗号化スキームは元のファイル拡張子を保持しなければなりません。 .enc、.drm、.p7m や類似を追記するラッパー形式は入口で拒否されます。DRM システムがそのようなファイル名を生成する場合、アップロード前に元の拡張子にリネームするか、クライアント側のエクスポートをそれを保持するよう構成してください。

暗号文エンベロープの互換性

これが2つ目の門です。暗号化バイトは、元の拡張子を主張したままコンテンツスニッフィングを生き延びなければなりません。

暗号化形式	互換？	理由
Microsoft Information Protection / OOXML パスワード暗号化で暗号化された Office ドキュメント（`.docx`、`.xlsx`、`.pptx`）	はい	これらは OLE2 / CDF 複合コンテナに包まれます。AAEKB は拡張子が Office タイプのとき OLE2、CDFV2、`application/vnd.ms-office`、`application/octet-stream` を明示的に受け付けます。これが最もサポートされているケースです。
その場で暗号化されたレガシー Office（`.doc`、`.xls`）	はい	同じ OLE2 許可。
標準 PDF 暗号化（`/Encrypt` 辞書、パスワード保護）の PDF	はい	ファイルは構造的に有効な PDF のまま；`%PDF-` がまだ先頭シグネチャ。
不透明エンベロープに包まれたが、先頭1024バイト内に `%PDF-` が存在する PDF	はい	AAEKB は先頭1KBから `%PDF-` マーカーを検索し、それを根拠に受け付けます。PDF プリアンブル/ヘッダーを保持する DRM エンベロープは合格します。
先頭1KBに `%PDF-` がなく、完全に不透明な暗号文に暗号化された PDF	いいえ	`.pdf` 拡張子に対してスニッフィングが `application/octet-stream`（または無関係なもの）を返す → "File content does not match extension" や "File detected as generic binary type." で拒否。
バイナリ暗号文に暗号化されたプレーンテキスト形式（`.txt`、`.csv`、`.json`、`.md`、`.xml`、`.html`）	いいえ	スニッフィングが `text/*` 型を返さないため、拡張子/コンテンツチェックが失敗。
全体として暗号化された ZIP アーカイブ	いいえ	外側のアーカイブは読み可能な ZIP でなければならず；AAEKB はそのエントリを検査します。加えて、暗号化メンバを含む ZIP ファイルはアーカイブバリデータによって拒否されます。
不透明な暗号文に暗号化された画像、音声、映像	いいえ	同じスニッフィングの不一致。

経験則： この統合は、認識可能なヘッダーを保持する暗号化 Office ドキュメントと暗号化/DRM保護 PDF を想定して設計され、安定して動作します。暗号化がすべての構造マーカーを破壊する形式は、あなたのサービスが呼ばれる前にブロックされます。

DRM システムが完全に不透明な暗号文を生成する場合、サポートされる回避策は、エクスポート側システムにペイロードを、適切なヘッダーバイトを保持する OOXML または PDF コンテナに包ませることで、ファイルが伝送中に認識可能に保たれるようにすることです。あるいは、AAEKB の担当者にご相談ください — コンテンツ検証レイヤーはデプロイレベルで構成可能で、オンプレミスインストールには調整できます。

復号後

復号バイトが返ると、AAEKB は次のように型を決定します：

元のファイル名に対する mimetypes.guess_type() — したがって、ほぼすべてのケースでアップロードした拡張子が取り込み経路を決定します。
それが何も生まない場合、libmagic が復号されたコンテンツの先頭2KBをスニッフィング。

その後、復号コンテンツは適切なハンドラーにルーティングされます：PDF、Word、Excel、PowerPoint、HTML、XML/DITA、プレーンテキスト、JSON、CSV/TSV、EML、MSG、音声（書き起こし）、映像（書き起こし）、または ZIP（メンバを抽出して取り込み）。

型を決定できない場合、ファイルはベストエフォートのテキスト抽出を試みる汎用ハンドラーに落ちます。アップロードはそれでも成功し、ファイルは保存・ダウンロード可能ですが、空のテキストコンテンツでインデックス化される可能性があります — つまり意味検索では取得できません。これは、期待する形式（例：生バイトの代わりの base64 テキスト）以外を返すデクリプションサービスの通常の症状です。

機能の相互作用

機能	相互作用
Quick Upload トグル	互換。復号はリクエスト内でインラインに実行；ユーザーはモーダルが完了するまで復号の往復全体を待ちます。
フォルダアップロード	互換；トグルはフォルダ内のすべてのファイルに適用。
暗号化ファイルのコンテナとしての暗号化 ZIP	非サポート。復号はアーカイブ抽出の前に、アップロードされたファイル全体に適用。ZIP 内のメンバは個別に復号されません。
URL / コネクタ取り込み（SharePoint、Confluence、Web クロール、Google Drive など）	非サポート。復号は Knowledge Base アップロードモーダルと `add/file` API エンドポイントを介した直接ファイルアップロードにのみ適用。
チャット添付アップロード	UI では公開されていません。
既存ドキュメントの再同期 / 再処理	保存済みファイルは既に復号済みのため、再処理は通常どおり動作し、あなたのサービスを再度呼びません。

タイムアウト、制限、サイジング

操作	制限	設定可能
復号エンドポイントへの送信リクエスト	300秒	いいえ
個々のポーリングリクエスト	60秒	いいえ
JSON「完了」後の追加バイナリ取得	120秒	いいえ
ポーリング合計ウィンドウ	`poll_interval_seconds × poll_max_attempts` — デフォルト 600秒（10分）	はい
最大アップロードサイズ	4096 MB（4 GB）	デプロイレベル
失敗時の再試行	なし	いいえ

サイジングの指針：

復号は完全にメモリ内です。同時復号1件あたりのピークメモリはおおよそファイルサイズの2倍（暗号文 + 平文）で、通常のリクエストオーバーヘッドの上乗せです。API とワーカーコンテナをそれを見越してサイジングするか、暗号化アップロードの実用的なアップロードサイズを 4GB 上限より十分下に制限してください。
サービスが送信の受理に5分以上かかる場合、async モードを使わなければなりません — 300秒の送信タイムアウトは調整できません。
復号自体に10分以上かかる場合、poll_max_attempts（または poll_interval_seconds）を相応に引き上げてください。
進行中の各復号は、ポーリングのスリープ時間も含め、その全期間ワーカースレッドを占有します。復号時間が長い暗号化ファイルの大量バルク取り込みはワーカー容量を消費します；それを念頭に並行性を計画してください。

保存、セキュリティ、監査の挙動

何が保存されるか

AAEKB は暗号文ではなく、復号されたファイルを Knowledge Base の raw ファイルストレージに保存します。

これは、取り込み後に製品の複数の部分が保存済み raw ファイルを読み戻すためです：アプリ内ドキュメントプレビュー、ダウンロード、引用レンダリング、テーブルとスプレッドシートの抽出、そしてドキュメントのその後の再処理や再インデックス化。平文を保存するとそれらすべてが直接機能し、デクリプションサービスがドキュメントごとにちょうど1回 — アップロード時に — 呼ばれ、読み取りのたびに呼ばれないことを意味します。また、日常のユーザーアクティビティのクリティカルパスからデクリプションサービスを取り除くため、そこでの障害が既に Knowledge Base 内にあるドキュメントへのアクセスに影響することは決してありません。

取り込み後、ドキュメントは AAEKB 自身のコントロールによって保護されます：基盤オブジェクトストレージが提供する保存時暗号化に加え、誰が閲覧・検索・ダウンロードできるかを支配する AAEKB のプロジェクト、チーム、ロールレベルのアクセス制御。

各復号ドキュメントに書き込まれるメタデータ

{
  "originally_encrypted": true,
  "decryption_service": "Corporate DRM Gateway",
  "decrypted_at": 1774000000.123
}

decryption_service は構成された Display Name です。
decrypted_at は Unix エポックタイムスタンプ（秒、浮動小数点）です。
originally_encrypted は情報マーカーで、管理者とエンドユーザーがどのドキュメントが暗号化されたまま到着したかを識別できます。処理には影響しません：保存済みファイルは既に復号済みであるため、ドキュメントの再処理がデクリプションサービスを再度関与させることは決してありません。

資格情報の取り扱い

auth_token は AAEKB アプリケーションデータベースに保存されます。
管理 API や UI から構成を読み戻すたびにマスクされます：最初の4文字のみが返され、残りは箇条書き文字に置換されます。マスクされた値の保存は検知されて無視されるため、フォームの再保存が保存済み資格情報を損なうことは決してありません。
構成のすべての変更は、イベント kb_decryption_service_updated としてスーパーアドミン監査ログに書き込まれ、資格情報を除くすべてのフィールドの前後値を記録し、資格情報のみ auth_token_rotated: true として記録されます。トークン値が監査レコードやログに現れることは決してありません。

アクセス制御

構成の読取と書には スーパー管理者特権が必要です。
利用可否ステータスエンドポイントは認証済みセッションを要求しますが特別なロールは不要で、ブール値のみを返します。
非管理者ユーザーはエンドポイント URL、ヘッダー、資格情報を決して見られません。

ロギング

AAEKB は復号中に INFO レベルでファイル名、バイト数、ジョブ識別子をログに記録します。ファイルコンテンツや資格情報はログに記録しません。ユーザーに返されるエラーメッセージには、あなたのサービスのエラーレスポンスボディの先頭最大500文字が含まれます — エラーボディに機微な材料を返さないでください。

エラーリファレンスとトラブルシューティング

ユーザーが見るメッセージ	HTTP	原因	修正
`File type '.enc' not allowed. Allowed types include: ...`	400	許可リスト外の拡張子	エクスポート時に元の拡張子を保持
`File must have an extension`	400	ファイル名に拡張子がない	正しい拡張子を追加
`File content does not match extension`	400	暗号文が主張された型としてスニッフィングされない	暗号文エンベロープの互換性をご覧ください
`File detected as generic binary type. Cannot verify file safety.`	400	Office 以外の拡張子の不透明暗号文	暗号文エンベロープの互換性をご覧ください
`Encrypted ZIP files are not allowed`	400	パスワード保護メンバを持つ ZIP	ドキュメントを個別にアップロードするか、非暗号化アーカイブを使用
`File too large (max 4096MB)`	400	サイズ上限超過	ドキュメントを分割
`File was marked as needing decryption, but no external decryption service is currently enabled...`	400	サービス無効時に `needs_decryption=true` が送信された	サービスを有効化するか、ページを更新してトグルを消す
`Failed to reach the external decryption service: ...`	502	DNS、TLS、接続拒否、タイムアウト	API とワーカーの両コンテナからのネットワーク経路、ファイアウォール、TLS 信頼を確認
`Decryption service returned HTTP 4xx/5xx: ...`	502	サービスが送信を拒否	引用されたボディを検査；認証ヘッダーを確認
`Decryption service returned a non-JSON response without file content.`	502	非同期送信がバイナリボディも解析可能 JSON も返さなかった	JSON ジョブオブジェクト付きの `202`、または `application/octet-stream` の `200` を返す
`Could not extract job_id from decryption response using path 'job_id'.`	502	`poll_job_id_json_path` がレスポンスの形と合わない	ドットパスを修正。例：`data.jobId`
`Decryption poll returned HTTP 404: ...`	502	ポーリングエンドポイントが未準備のジョブに `4xx` を返した	ペンディング中は `202` を返す
`External decryption job failed with status: FAILED`	502	サービスが失敗ステータスを報告	サービスのログで調査
`Decryption job completed but no file stream was returned.`	502	ポーリングが JSON で完了を報告したが、追加 GET がバイナリを返さなかった	完了時にバイトストリームを返す — 2重 GET の挙動をご覧ください
`Decryption service returned empty content.`	502	ゼロ長レスポンスボディ	実際の復号バイトを返す
`Decryption service timed out after 600s of polling.`	504	`interval × max_attempts` を超過	`poll_max_attempts` を引き上げるか、復号を高速化
`Decryption service config not found. Run the migration first.`	404	データベース移行が適用されていない	AAEKB データベース移行を実行

診断のヒント

トグルが表示されない → GET /kb-decryption-service/status を確認；{"available": false} を返す場合、構成行がないか enabled が false。ブラウザ側キャッシュの失効に約30秒を待つこと。
Quick Upload では動くが通常のアップロードでは動かない（またはその逆） → ほぼ常に API コンテナとバックグラウンドワーカーコンテナ間のネットワーク到達性の差。
アップロードは成功するがドキュメントに検索可能なコンテンツがない → サービスが元の形式の生バイト以外（一般的には base64 や JSON ラッパー）を返している可能性大。curl でレスポンスボディが期待されるマジックバイトで始まることを検証。

デプロイとネットワーク要件

2箇所からの到達性。 AAEKB API コンテナと AAEKB バックグラウンドワーカーコンテナの両方が decrypt_endpoint と poll_endpoint_template を解決・到達できなければなりません。Kubernetes デプロイでは、ネットワークポリシーが両ワークロードからのegressを許可していることを確認してください。
TLS 信頼。 AAEKB はコンテナイメージの標準の信頼 CA バンドルを使用して TLS 証明書を検証します。プライベート/内部 CA の証明書を提示するデクリプションサービスは、その CA がデプロイの一環として AAEKB コンテナの信頼ストアに追加されない限り接続に失敗します。これを計画してください — イントラネットデプロイでの一般的な初回実行の障害です。証明書検証は管理 UI から無効化できません。
プレーン HTTP。 http:// エンドポイントは動作しますが強く非推奨です。レスポンス側で平文ドキュメントが無保護のままネットワークを走行するためです。
安定したホスト名。 エンドポイントはリテラル URL として保存されます。pod IP の代わりに安定した内部 DNS 名またはサービスアドレスを使用してください。
レイテンシバジェット。 送信呼び出しは接続を最大300秒保持します。中間のロードバランサー、ingress コントロール、プロキシが少なくともその長さのアイドル/リードタイムアウトを持つことを確認してください。そうでなければ、AAEKB が諦める前に接続を切断します。
データベース移行。 この機能は kb_decryption_service_config テーブルを要求し、無効なデフォルト行を1つシードする標準 AAEKB 移行によって作成されます。スーパー管理者が有効化するまで機能は不活性です。

ロールアウトと検証チェックリスト

本番での有効化の前に

デクリプションサービスがデプロイされ、AAEKB 名前空間のテスト pod から到達可能（API pod および worker pod の中からの curl）
TLS 証明書チェーンが AAEKB コンテナから信頼されている
AAEKB データベース移行が適用済み；KB Decryption Service タブが「table not found」エラーなしでロード
代表的なサンプルで暗号化ファイルがアップロード検証を通過することを確認 — 取り込み予定の各形式について実際の暗号化ドキュメントを3つ取り、アップロードする。これで最も一般的な失敗点である暗号文エンベロープの互換性を検証

構成

decrypt_endpoint 設定済み、メソッドとコンテンツタイプがサービスと一致
decrypt_file_field_name がサービスが期待するフォームフィールドと一致（multipart モード）
response_mode がサービスの挙動と一致
非同期の場合：poll_endpoint_template が {job_id} を含む；JSON パスをサービスから取得した実レスポンスで検証済み
poll_interval_seconds × poll_max_attempts が最悪の復号時間に十分余裕をもって超過
認証が構成され、AAEKB が送信するのとまったく同じヘッダーで curl により検証済み
Display Name に意味のあるものを設定 — 各復号ドキュメントのメタデータに記録される

機能テスト

トグルオンで暗号化ファイルをアップロード → ドキュメントが取り込みされ、コンテンツが検索可能
トグルオフで非暗号化ファイルをアップロード → 影響なし
トグルオンで非暗号化ファイルをアップロード → サービスが明確なエラーを返すべき；メッセージがユーザーに理にかなって表示されることを検証
サービス障害を強制（サービスを停止） → ユーザーが 502 クラスのエラーを見、部分的なドキュメントがインデックス化されない
予想される最大のファイルでテストし、タイミングがポーリングバジェット内に収まることを確認
ファイルバッチとフォルダアップロードをテスト
復号ドキュメントが Knowledge Base から正しくダウンロードでき、メタデータに originally_encrypted: true が表示されることを確認

運用

資格情報ローテーション手順が文書化済み（管理 UI または PUT API で再保存）
デクリプションサービスのモニタリング/アラーティング、自身のエラー率とレイテンシを含む
スーパーアドミン監査ログが構成変更を捕捉していることを確認済み

既知の制限

デプロイごとに1サービス。 プロジェクト別、チーム別、ファイルタイプ別の異なるデクリプションサービスへのルーティングはありません。
バッチレベルのトグルのみ。 暗号化と非暗号化ファイルを単一のアップロードバッチに混合できません。
直接アップロードのみ。 コネクタベースの取り込み（SharePoint、Confluence、Google Drive、Web クロール、類似）は復号を呼びません。
再試行なし。 単発の一時的なネットワーク乱高下でアップロードは失敗します；ユーザーは手動で再試行する必要があります。
静的資格情報。 AAEKB 自体による OAuth トークンリフレッシュ、HMAC 署名、クライアント証明書 mTLS はありません。それらのスキームには認証プロキシを使用してください。
ユーザーごとやドキュメントごとの認可コンテキストはデクリプションサービスに転送されません。AAEKB が送信する情報に基づく principal ごとの DRM ポリシーを強制できません。
ファイルは取り込み後に復号されたまま保存されます、AAEKB 自身のアクセス制御とストレージ暗号化の下で。保存、セキュリティ、監査の挙動をご覧ください。
「接続テスト」ボタンなし。 検証は実際のアップロードによって行われます。
完全に不透明な暗号文は、ほとんどの形式で復号前のコンテンツ検証によってブロックされます。暗号文エンベロープの互配性をご覧ください。
ネストした復号は非サポート。 ZIP 内のメンバは個別に復号されません。

FAQ

AAEKB は私たちの暗号化鍵を見ることはありませんか？ いいえ。AAEKB は暗号文を自分が管理するエンドポイントに送信し、平文を受け取ります。鍵素材、アルゴリズム、DRM ポリシーエンジンについての知識はありません。

デクリプションサービスを完全に社内イントラネットで実行できますか？ はい — それが主たるユースケースです。エンドポイントは AAEKB API とワーカーコンテナから到達できればよいだけです。オンプレミスの AAEKB デプロイでは、何もネットワークの外に出る必要がありません。

どのレスポンスモードを使うべきですか？ 復号が数秒で確実に完了し、サービスが接続を保持できるなら sync を使用。それより遅い、バッチ処理、キュー背景のものは async を使用。ポーリングエンドポイントが完了時にバイトストリームを直接返す async が最も堅牢な構成です。

デクリプションサービスが停止するとどうなりますか？ トグル有効のアップロードは明確なエラーで失敗します。通常のアップロードは影響を受けません。既に取り込みされたドキュメントも影響を受けません — 復号されて保存されており、二度とあなたのサービスを必要としません。

機能を一時的に無効化できますか？ はい。Enabled をオフにします。エンドユーザーのトグルは約30秒以内に消え、まだ needs_decryption=true を主張するアップロードは説明メッセージ付きで拒否されます。

ユーザーはどのドキュメントが元々暗号化されていたかを知れますか？ はい — 復号ドキュメントはメタデータに originally_encrypted: true、デクリプションサービスの表示名、復号タイムスタンプを運びます。

私たちの暗号化ファイルは DRM システムから document.pdf.encrypted という名前で出てきます。それは動きますか？ いいえ。アップロード前に document.pdf にリネームしてください。AAEKB は復号前に拡張子を検証し、ラッパー拡張子を認識しません。ファイル名とラッパーの互換性をご覧ください。

私たちの暗号文は完全に不透明です — 認識可能なヘッダーがまったくありません。選択肢は何ですか？ アップロードはあなたのサービスに到達する前に拒否されます。選択肢：(a) エクスポート側システムに元の形式ヘッダーを保持または前置する、(b) Office ドキュメントには明示的にサポートされている OOXML/OLE2 ベースのエンベロープ暗号化を使う、(c) オンプレミスインストールについては AAEKB の担当者とコンテンツ検証のデプロイレベル調整について相談する。

デクリプションサービスはバイトの代わりにダウンロード URL を返せますか？ いいえ。AAEKB はレスポンスボディから復号コンテンツを読み、JSON に返された URL を追いません。

これは Quick Upload で動作しますか？ はい。ただしユーザーはアップロードモーダルが完了するまで復号の往復全体を待ちます。

ドキュメントバージョン1.0。機能リファレンス：EN-3043。

この機能の作用​

エンドツーエンドの仕組み​

サービスの構成（スーパー管理者）​

完全な構成リファレンス​

一般​

復号リクエスト​

非同期ポーリング（response_mode = async のときのみ使用）​

認証​

あなたのデクリプションサービスが実装すべき契約​

妥協できない要件​

送信エンドポイント​

ポーリングエンドポイント（async モード）​

2重 GET の挙動（async モード）​

Content-Type の指針​

AAEKB が決して行わないこと​

具体例：同期モード​

具体例：非同期（ポーリング）モード​

認証オプション​

エンドユーザー体験​

互換性：動作するものとしないもの​

重要な制約：検証は復号の前に発生する​

サポートされるファイル拡張子​

ファイル名とラッパーの互換性​

暗号文エンベロープの互換性​

復号後​

機能の相互作用​

タイムアウト、制限、サイジング​

保存、セキュリティ、監査の挙動​

何が保存されるか​

各復号ドキュメントに書き込まれるメタデータ​

資格情報の取り扱い​

アクセス制御​

ロギング​

エラーリファレンスとトラブルシューティング​

デプロイとネットワーク要件​

ロールアウトと検証チェックリスト​

既知の制限​

FAQ​