以下の内容はhttps://error-daizenn.hatenablog.com/entry/2026/02/11/200816より取得しました。

Ricoh PMC「Workflow error codes」完全ガイド：スキャンワークフロー障害を最短で切り分ける方法

 

Ricoh PMC「Workflow error codes」完全ガイド：スキャンワークフロー障害を最短で切り分ける方法

スキャンのワークフローが失敗すると、管理者に通知メールが届き、そこにエラーコードが記載されることがあります。問題は「どこで失敗したのか」を素早く特定しないと、復旧までの時間が伸び、現場のスキャン業務が止まり続けてしまうことです。
この記事では、代表的なワークフローエラーコードを“原因の系統”で整理し、管理者が最短で切り分け・対処できるように実務目線でまとめます。

ワークフローエラーの見方：まずは「どの工程か」を決め打ちする

Ricoh PMCのワークフローは、ざっくり言うと次のような工程群で構成されます。

  • 認識処理（OCR、バーコード、ハイライト、ゾーナルOCR）

  • 文書の構造化（ドキュメント分割）

  • マスキング（テキストリダクション）

  • 外部処理（外部コマンド/API、拡張、スクリプト）

  • 配送・連携（Box、Dropbox、Email、Exchange、OneDrive、SharePoint、HPRMなど）

  • コア処理・サービス到達性（PMC↔WPSの疎通など）

  • 制限（ジョブサイズ上限）

通知メールにあるエラーコードは、ほぼ必ずこのどれかに紐づきます。復旧を早めるコツは、「エラーコードの接頭辞（WPS-◯◯◯）」で工程を特定してから、設定・権限・容量・ネットワークの順に潰すことです。

1) 認識系エラー（OCR・バーコード・ハイライト・ゾーナルOCR）

スキャン画像の品質や認識設定が原因になりやすい領域です。再現性が低い（ある時だけ失敗）ことも多いため、切り分けは「入力品質→設定→負荷」の順が有効です。

WPS-BARCODE-9999：バーコード認識失敗

よくある原因

  • バーコードが小さい／かすれている／傾きが大きい

  • 解像度不足（一般に低解像度で失敗しやすい）

  • バーコード領域が背景に埋もれている、反射で白飛びしている

対処の考え方

  • まず同一原稿で再スキャンして再現するか確認

  • 解像度やコントラストを上げる、原稿の傾きを減らす

  • バーコードの位置が固定なら、後述の「ゾーナルOCR」的な発想で“領域指定”を検討（運用設計側の改善）

WPS-OCR-9999：OCR処理失敗

WPS-ZONAL_OCR-9999：ゾーナルOCR失敗

WPS-HIGHLIGHT-9999：ハイライト文字認識失敗

よくある原因

  • 画像が暗い／ブレ／傾き、背景のノイズが強い

  • 対象言語や文字種の想定違い（例：手書き混在、特殊記号が多い）

  • 領域指定（ゾーナル）が実際の帳票レイアウトとズレている

  • 一時的な負荷（同時実行が多い時間帯など）

対処の考え方

  • 原稿サンプルを確認し「画像品質の問題」か「設定の問題」かを分ける

  • ゾーナルOCRは、帳票の版ズレや余白変更で失敗しがちなので、帳票改定のタイミングで設定も見直す

  • 同時間帯に大量処理が集中している場合、スキャン投入の平準化やワークフロー分割を検討

2) 文書構造化のエラー（ドキュメント分割）

WPS-DOCUMENT_SEPARATION-9999：文書分割失敗

よくある原因

  • 分割ルール（区切りページ、バーコード、白紙判定など）と原稿が一致していない

  • 片面/両面、白紙の混入、差し込み紙など運用要因

  • 仕分けに必要な識別子（バーコード等）が読み取り不良

対処の考え方

  • まず「分割が必要なワークフローか」を見直す（不要なら工程削減が最速の改善）

  • 分割条件がバーコード依存なら、バーコード印字品質とスキャン設定を優先的に改善

  • 白紙判定が絡むなら、白紙判定の閾値やスキャン濃度の調整が効く場合が多い

3) マスキング（リダクション）関連

WPS-REDACT-9999：テキストリダクション失敗

よくある原因

  • OCR結果を前提にマスキングしている場合、OCR失敗の連鎖で起きる

  • マスキング対象のルール（正規表現、キーワード）が過度に複雑

  • 処理対象が想定外（手書き、画像化された文字のみ等）

対処の考え方

  • まずOCR系エラーの有無を確認（上流工程の失敗が原因のことが多い）

  • ルールを段階的に簡素化し、どの条件で落ちるかを切り分ける

  • “完璧な自動化”より、例外を別フローに逃がす設計も現実解

4) 外部処理・拡張・スクリプト系エラー

ワークフロー内で外部コマンドや拡張、スクリプトを呼ぶ場合は「相手側の失敗」が多く、ログ確認と責任分界が重要になります。

WPS-EXTERNAL-9999：外部処理ステップ失敗

WPS-EXTERNAL-0002：外部コマンドが非ゼロ終了（ログのAPI exit code確認が必要）

よくある原因

  • 外部コマンドの戻り値がエラー（環境変数、引数、認証、タイムアウト）

  • API連携先が一時障害／レート制限／仕様変更

  • 連携先の入力データ不正（サイズ、文字コード、形式）

対処の考え方

  • まず「外部処理に渡している入力」を確認（ファイル形式、サイズ、必須項目）

  • WPS-EXTERNAL-0002は“外部側が失敗した”サインなので、ログからexit codeを取り、連携先ベンダー/開発側で原因特定する

  • タイムアウトや一時障害が多いなら、リトライ設計やキューイングの導入を検討

WPS-EXTENSION-9999：拡張コネクタでエラー

WPS-SCRIPT-9999：スクリプトコネクタでエラー

よくある原因

  • スクリプトの例外、依存ライブラリ不足、実行権限不足

  • コネクタ設定値の不足（URL、トークン、パラメータ）

  • 実行環境差（テスト環境では動くが本番で落ちる）

対処の考え方

  • 直近の変更（スクリプト更新、設定変更、証明書更新など）があればそこから疑う

  • エラーが特定ユーザー/特定原稿でのみ発生するなら、入力データ差分を比較する

5) 配送・連携（Box/Dropbox/Email/Exchange/OneDrive/SharePoint/HPRM）

ここは「認証」「権限」「容量制限」「接続性」が主因です。エラーコードが具体的なので、復旧は比較的早い領域でもあります。

Box / Dropbox

  • WPS-BOX-9999：Boxアップロード失敗

  • WPS-DROPBOX-9999：Dropboxアップロード失敗

切り分けポイント

  • 連携トークンの期限切れ・無効化

  • 保存先フォルダ権限

  • ファイル名規則や禁止文字

  • ファイルサイズ上限・同時アップロード制限

Email

  • WPS-EMAIL-9999：メール送信失敗（総合）

  • WPS-EMAIL-0001：クライアント未認証

  • WPS-EMAIL-0002：SMTPのサイズ制限超過（最大ジョブサイズ設定を確認）

  • WPS-EMAIL-0003：ユーザープロファイルにメールアドレス未設定

  • WPS-EMAIL-0004：接続拒否（SMTP稼働・設定を確認）

  • WPS-EMAIL-0005：同時接続数制限超過

最短復旧の順番

  1. 0003ならユーザーのメールアドレス設定を埋める（即復旧）

  2. 0001なら認証設定（SMTP認証、資格情報）を確認

  3. 0004ならネットワーク到達性とSMTPサーバ稼働確認

  4. 0002ならサイズ圧縮、分割送信、または最大ジョブサイズ設定の見直し

  5. 0005ならピーク時の同時送信を減らす（投入時間分散、キュー制御）

Exchange

  • WPS-EXCHANGE-9999：Exchange送信失敗
    対処の考え方

  • 認証（OAuth/資格情報）と権限（送信権限、代理送信）を確認

  • 組織側のセキュリティ変更（MFA必須化、基本認証無効化など）が影響しやすい

OneDrive / SharePoint Online（OAuth系が多い）

  • WPS-ONEDRIVE_BUSINESS-9999 / WPS-ONEDRIVE_BUSINESS_OAUTH2-9999：OneDriveアップロード失敗

  • WPS-ONEDRIVE_BUSINESS_OAUTH2-0001：ユーザーがOneDriveを認可していない

  • WPS-SHAREPOINT_ONLINE-9999 / WPS-SHAREPOINT_ONLINE_OAUTH2-9999：SharePointアップロード失敗

  • WPS-SHAREPOINT_ONLINE_OAUTH2-0001：SharePointを認可していない

  • WPS-SHAREPOINT_ONLINE_OAUTH2-0003：SharePointサイトが見つからない（サイト名設定確認）

  • WPS-SHAREPOINT_ONLINE_OAUTH2-0004：ライブラリが見つからない（ライブラリ名設定確認）

最短復旧の順番

  1. 0001は“認可未実施”なので、ユーザーに認可フローを実施させる

  2. 0003/0004は“名前不一致”がほとんど。サイト名・ライブラリ名の表記揺れや移設を確認

  3. 9999系は権限、トークン期限、M365側の制限・障害も含むため、直近の変更履歴と併せて確認

HPE Records Manager

  • WPS-HPRM-9999：HPRMコネクタでエラー
    対処の考え方

  • コネクタ側設定（接続先、認証、API仕様）と、HPRM側権限・受付条件を確認

  • 外部連携のため、障害切り分けは「PMC→コネクタ→HPRM」の順でログを追う

6) コア処理・サービス到達性

WPS-CORE-9999：スキャンファイル処理失敗

よくある原因

  • 一時的なサービス不調、処理基盤の負荷、ファイル破損

  • 上流工程の失敗が表面化しているケースもある

対処の考え方

  • 同時間帯に同種エラーが多発しているか確認（多発なら環境側の問題が濃厚）

  • まずは対象ジョブの入力（ファイル）とワークフロー設定の変更履歴を確認

SQ-WPS-9999：PMCがWPSサービスに到達できない

よくある原因

  • ネットワーク疎通（DNS、FW、プロキシ、ルーティング）

  • サービス停止、メンテナンス、証明書更新に伴う通信失敗

対処の考え方

  • まず到達性確認（名前解決→TCP接続→TLS/証明書）

  • 直近のネットワーク変更、証明書更新、メンテ有無を確認

  • このエラーが出ている間は“認識や配送以前に基盤が使えない”ので、個別設定より先に復旧作業を優先

7) 制限系：容量・サイズが原因のエラー

WPS-RESTRICTION-0001：スキャンジョブのサイズ上限に達した

よくある原因

  • 高解像度・フルカラー・ページ数過多でジョブが肥大化

  • 画像形式や圧縮設定が非効率

対処の考え方

  • 画像圧縮・解像度・カラーモードの見直し（業務要件に影響しない範囲で）

  • 大量ページは分割スキャン、または別ワークフローへ逃がす

  • Email連携も併用している場合は、SMTP側のサイズ制限（WPS-EMAIL-0002）とセットで設計する

実務で効く「最短の切り分け手順」テンプレ

最後に、管理者が迷いにくい手順をテンプレ化します。

  1. エラーコードの接頭辞で分類（認識／分割／外部／配送／到達性／制限）

  2. 0001〜0005など具体番号があるものは“指示通り”に潰す（認証、サイズ、ユーザー属性、接続、同時接続）

  3. 9999系はログと変更履歴を確認（直近の設定変更・権限変更・外部サービス障害）

  4. 入力データ（原稿）依存か、環境依存かを判定

    • 特定原稿だけ→画像品質・帳票ズレ・ルール設計

    • 同時多発→基盤負荷・ネットワーク・外部サービス

  5. 再発防止は“例外設計”が鍵（特殊原稿は別フロー、サイズ大は分割、認可は事前チェック）

まとめ：エラーコードは「原因」ではなく「場所」を示す

ワークフローの障害対応で大事なのは、エラーコードを暗記することではなく、どの工程で止まったかを即断し、設定・権限・容量・ネットワークを順番に潰すことです。
特に、OAuth認可不足（0001系）、SMTPサイズ超過（0002）、ユーザー属性不足（0003）、接続拒否（0004）、同時接続（0005）は復旧が早い反面、運用で繰り返しやすいので、事前チェックやガードレールを整備すると効果が出ます。

この整理をベースに、通知メールのエラーコードを見た瞬間に“次の一手”が決まる状態を作っていきましょう。



以上の内容はhttps://error-daizenn.hatenablog.com/entry/2026/02/11/200816より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14