PDF アップロードのサイズ上限には実際のコストがあります。また、エンタープライズソフトウェアで最も過大に主張されている数値の一つでもあるため、本記事では、あなた自身で測定する方法を提供し、作り上げられた数値ではなく実際の数値を得られるようにします。

はじめに

レガシーな文書管理システムは、PDF アップロードに対してしばしば 25 メガバイト のハード上限を設定しています。この制限はほとんどの文書がそれ以下であるため緩やかに感じられますが、例外が出ると手作業で対処しなければなりません。

ここで自分たちの立場を率直に述べるべきです。Doconut.app の無料ビューアも PDF の 25 MB で停止します。 これが私たちの上限であり、本記事は上限が正当化できないという議論ではありません。上限を超えるために費用を支払う前に、そのコストを把握すべきだという議論です。

この記事の数値、あるいはその欠如についての注意点です。このジャンルのコストモデルは通常、誰も検証できない調査や出典不明のベンチマークに依存しています。私たちはそれらを持っていないので、印刷もしません。以下は算術と質問です — あなた自身のシステムから実際の値を供給してください。

1. 拒否されたアップロードの実際のコスト

PDF が上限を超えると、誰かが分割、圧縮、または再作成します。これが直接コストであり、測定可能な3つの要素があります：

ボリューム。 サイズで拒否されたアップロードは何件ですか？アプリケーションログが把握しています。拒否理由が記録されていない場合、まずそれを修正すべきです。以下のすべてがこの数に依存し、誰の推定も正確ではありません。

処理時間。 回避策にどれだけ時間がかかりますか？推測せずに実際の5ファイルで計測してください。Acrobat でスキャンした契約書を圧縮して再アップロードするのと、400ページのマニュアルをそれぞれ単独で機能する部分に分割するのは同じ作業ではありません。

チケット率。 これらの拒否のうち、デスクで解決されずにサポートチケットになる割合はどれくらいですか？チケットシステムで検索語で取得してください。

rejections per quarter
  x handling time in hours
  x blended hourly rate
+ (rejections x ticket rate x cost per ticket)
= direct quarterly cost

自分で計算する理由は、結果が組織間で桁違いに変わるためです。ほぼ完全にボリュームに依存します。月に2回上限に達するチームにとっては、正直な答えは測定に値するコストはなく、読むのをやめるべきです。一方、スキャンファイルを一日中処理するクレーム部門にとっては、実際の費用項目となります。

2. 真剣に考慮すべき間接コスト

遅延や失注は通常の第2幕であり、収益モデリングは省きます。アップロード上限が失注に直接関与したことを証明する証拠はほとんど存在しないからです。

ただし、質的に異なるため名前を挙げる価値がある間接コストがあります：文書を分割すると損傷します。

PDF を3つに分割すると、別々に送信でき、別々にバージョン管理され、完全にアーカイブされない3つのファイルになります。署名は操作後に残らず、分割されたデジタル署名 PDF はすべての断片で無効な署名となります。なぜなら署名はファイル全体のバイトを対象としているからです。メタデータ、タグ、PDF/A をアーカイブ可能にする構造は、ユーザーが使用したツールによって一貫性なく保持されます。

保持や監査の義務が文書を単一のオブジェクトと想定している場合、定期的に分割を強いるサイズ上限は、生産性の仮面をかぶったコンプライアンス問題です。労務算術が何と言おうと、エスカレーションすべきです。

3. 何かを購入する前に、ファイルの中身を確認する

このステップはしばしば省略されますが、プロジェクトを終了させることもあるため、独立したセクションにする価値があります。

拒否されたファイルを50件取り出し、何が大きくしているかを確認してください。私たちのフォーマット経験では、一般的な答えは元の撮影解像度の画像です。たとえば、カラーで600 dpi でスキャンされた契約書は、200 dpi のグレースケールで十分読めるはずです。また、スマートフォンから直接取り込んだ写真が入ったレポートも同様です。そのような PDF は必要以上に数倍大きくなることが多く、スキャナのプロファイルやエクスポート設定といったソースで修正すれば、全く追加の調達なしに拒否を解消できます。

場合によっては、正真正銘大きな文書が原因であり、実際の要件が存在します。重要なのは自分がどのケースにいるかを把握することです。

4. ベンダー（当社を含む）に尋ねるべきこと

上限を引き上げる必要がある場合、重要な質問は上限そのものについてではありません：

制限はどこで適用され、なぜですか？ アプリケーション自身のアップロード処理で設定された制限は、レンダリングエンジンが課すものとは異なります。私たちの場合は前者で、25 MB は公開サイトが受け入れる上限であり、エンジンが描画できる上限ではありません。
上限に達したときはどうなりますか？ アップロード時に数値が示された拒否は、90 % でのタイムアウトよりも親切です — ユーザーはどちらにせよ何かを学びますが、迅速なのは前者だけです。
メモリ使用曲線はどのようになりますか？ 大きな PDF のレンダリングはサーバーメモリを消費します。セルフホストの場合、そのコストはインフラに転嫁され、"無制限" は "現在購入しているハードウェアに依存する制限" を意味します。
何が保持されますか？ ファイル分割を防ぐために上限を引き上げる場合、文書が完全に保持されること（署名、タグ、メタデータを含む）を確認してください。

念のため記しておくと、本記事には裏付けできない数値は含まれていません：Doconut SDK は、実環境にインストールする .NET コンポーネントで、実際のサイズ上限は当社のポリシーではなくサーバーのメモリに依存します。メガバイト数は記載しません。なぜならハードウェアと文書に依存し、単一の数値は測定ではなくマーケティングになるからです。

5. 実行可能なステップ

拒否を計測する。 理由とファイルサイズをログに記録します。実際のデータの四半期分はどんなモデルよりも有用です。
ファイルをサンプリングする。 拒否された PDF を 50 件調べることで、サイズ問題かスキャナ設定問題かが分かります。
上記の算術を 自分のボリュームとレートで実行し、コストが小さすぎて対策不要と結論付ける覚悟を持ちます。
コンプライアンス面を別途確認する。 分割が署名や監査トレイルを破壊する場合、その議論は単独で成立し、コストモデルは不要です。
最悪のファイルでパイロットする。 サンプルではなく、会話のきっかけとなった 300 ページのスキャンバンドルです。

結論

サイズ上限は実際の制約であり、実際のコストが伴います。また、エンタープライズソフトウェアで数値が最も簡単に提示される場所でもあります。コストはボリューム、処理時間、レート次第であり、かなり大きくなることもあれば、全く無いこともあります。

移行する前に測定してください。そして、もし今日読むには少し大きすぎる PDF が1つだけでも、Doconut.app は 25 MB まで受け入れ、費用はかからず、タブを閉じるとファイルを削除します。

SDK が適合するかどうかを検証していますか？ ダウンロードページにはトライアルがあり、最も重い文書でテストすれば、どの計算機よりも多くを教えてくれます。