はじめに：なぜIDocは今でも現役なのか
「IDocって古い技術でしょ？」と言われることがありますが、実際には世界中のSAPユーザーで今も毎日数十億件のIDocが流れています。SAP S/4HANA時代の今でも、企業間EDI連携・銀行連携・物流連携・倉庫システム連携・税務当局報告など、非同期で確実にデータを送受信したい場面ではIDocがほぼデファクトです。
なぜIDocが廃れないのか（why so）。理由は「非同期・順序保証・再送可能・モニタリング標準装備」という4点が業務システム間連携で必須要件であり、これらをIDocほど成熟した形で提供する仕組みが他にあまりないからです。OData APIやREST APIはリクエスト/レスポンスの同期通信が得意ですが、「失敗したら再送」「障害復旧後にまとめて取り込み」といった業務要件にはIDocのほうが圧倒的に向いています。
ではどう向き合えばよいか（so what）。「IDocは古い・新しい」ではなく「同期API」「非同期メッセージ（IDoc）」「イベント駆動」を業務特性に応じて使い分けるのが現代SAPアーキテクチャの基本姿勢です。本記事ではIDocの基本概念、構造、モニタリング、S/4HANA時代の位置づけまでを整理します。SAP全体の連携基盤についてはSAP Integration Suite入門も参照してください。
IDocとは何か
IDoc（Intermediate Document）は、SAPシステムがアプリケーションデータを構造化して外部システムや他SAPシステムとやり取りするための「中間ドキュメント」フォーマットです。ALE（Application Link Enabling）という枠組みの中で動き、IDocそのものはデータ構造、ALEは送受信を制御する仕組み、と考えると役割が整理できます。
IDocには大きく2種類あります。
| 種類 | 用途 |
|---|---|
| Outbound IDoc | SAP→外部システムへの送信 |
| Inbound IDoc | 外部システム→SAPへの受信 |
業務的には「請求書を取引先システムに送る」「倉庫システムから入庫実績を受け取る」「銀行からの入金消込を受け取る」といった用途で使われます。
IDocの構造：3層モデル
IDocは3つの階層で構成されます。これを理解するとWE02でのデバッグが一気に楽になります。
| 階層 | 名称 | 内容 |
|---|---|---|
| 1 | コントロールレコード（EDIDC） | 送信者・受信者・IDocタイプ・メッセージタイプ・ステータス |
| 2 | データレコード（EDIDD） | 業務データ本体。セグメント単位で階層構造を持つ |
| 3 | ステータスレコード（EDIDS） | 各処理ステップでのステータス遷移履歴 |
flowchart LR A[コントロール
EDIDC] --> B[データ
EDIDD] B --> C[ヘッダ
セグメント] B --> D[明細
セグメント] B --> E[条件
セグメント] A --> F[ステータス
EDIDS]
ポイントは、データレコードが「セグメント」という単位で繰り返し可能な階層構造を持つことです。たとえば請求書IDocなら、ヘッダ1件・明細N件・条件M件、という構造を1つのIDocに収められます。なぜこうなっているか：1業務ドキュメント（請求書1枚など）を1IDocとしてまるごと運ぶことで、トランザクション境界とデータ境界を一致させ、再送時の整合性を保ちやすくするためです。
主要なIDocタイプとメッセージタイプ
IDocには「IDocタイプ（構造の型）」と「メッセージタイプ（業務の意味）」の2軸があります。同じIDocタイプを違うメッセージタイプで使い回すこともあるため、両方を理解する必要があります。
| メッセージタイプ | 業務 | IDocタイプ例 |
|---|---|---|
| ORDERS | 受注 | ORDERS05 |
| DESADV | 出荷通知 | DELVRY07 |
| INVOIC | 請求書 | INVOIC02 |
| MATMAS | 品目マスタ | MATMAS05 |
| DEBMAS | 顧客マスタ | DEBMAS07 |
| CREMAS | 仕入先マスタ | CREMAS05 |
| PAYEXT | 支払指図（銀行連携） | PEXR2002 |
| WMMBXY | 在庫転記 | WMMBID02 |
世界中のEDIで標準化されているメッセージタイプ（ORDERS/DESADV/INVOICなど）はEDIFACTやANSI X12といった国際標準のSAP実装になっており、取引先システムとの連携で頻繁に登場します。
ALE：IDocの送受信を制御する仕組み
ALEはIDocを「誰から」「誰に」「どのフィルタで」送るかを制御する仕組みです。代表的な要素は次の3つです。
- 論理システム（Logical System）：送信元・受信先のシステムを論理名で識別
- パートナプロファイル（WE20）：パートナごとにメッセージタイプ・処理オプション・ポートを設定
- 配信モデル（BD64）：どのシステムからどのシステムへ何を送るかの全体マップ
なぜこれらが分離されているか（why so）。実システム名を直接コーディングしてしまうと、テスト→本番の移送時にすべて書き換えが必要になるからです。論理システム名で抽象化することで、環境ごとの差異を設定だけで吸収できます。論理システム→物理システムのマッピングを正しく設計することが、IDoc運用の安定性を決める最大のポイントです。
IDocのモニタリングとリカバリ
IDocは「送りっぱなしで終わらない」ことが最大の強みです。標準で多数のモニタリング画面が用意されています。
| Tコード | 用途 |
|---|---|
| WE02 | IDoc一覧表示（最頻出） |
| WE05 | IDoc一覧（旧版） |
| WE19 | テストツール／既存IDocのコピー＆編集 |
| BD87 | ステータスモニタ／再処理 |
| WE60 | IDocタイプの構造表示 |
| WE21 | ポート定義 |
| WE20 | パートナプロファイル設定 |
| SM58 | tRFCキューモニタ（IDoc送信失敗時の確認） |
主要ステータス番号
IDocステータスは2桁の数字で表されます。覚えておくと運用が楽になります。
- 03：通信OK（送信成功）
- 12：処理OK
- 16：機能モジュールが見つからない
- 26：構文エラー（送信側）
- 29：ALEサービスエラー
- 51：アプリケーション処理エラー（インバウンド）
- 53：処理OK（インバウンド）
- 64：処理待ち（インバウンド）
- 68：エラーで中止
特に51は実務でもっとも頻出するエラーで、「IDocは届いたがアプリケーション側で業務エラーが出た」という状態を表します。WE02で開いて、ステータスレコードのエラーメッセージを読むのが復旧の第一歩です。
リカバリの流れ
flowchart LR A[エラー検知
BD87] --> B[原因分析
WE02] B --> C{修正方法} C -->|データ修正| D[WE19で
編集再投入] C -->|マスタ修正| E[マスタ修正後
BD87再処理] C -->|プログラム
修正| F[修正後
再処理]
なぜ標準でここまで揃っているか。業務システム間連携の大半の障害は「データ不備」「マスタ不整合」「プログラムバグ」のいずれかであり、IDocを再送可能に設計しておけば運用担当者がコードを書かずに復旧できるからです。
S/4HANA時代の位置づけ
「S/4HANAでIDocはどうなる？」という質問はよく出ますが、答えは「現役のまま、しかし新規連携は他の選択肢と比較する」です。
S/4HANAではIDocに加え、以下の選択肢が整備されています。
| 方式 | 主な用途 | IDocとの違い |
|---|---|---|
| OData / REST API | 同期型のリクエスト/レスポンス | リアルタイム性が高い、再送機構は呼び出し側責任 |
| Event Mesh | イベント駆動の非同期通知 | 1対多の配信が容易、ペイロードは軽量 |
| CPI / Integration Suite | 統合フロー | IDocも扱えるし、他フォーマットへの変換も可能 |
| SOAP Web Service | 同期/非同期Web Service | XML中心、IDocより自由度が高い |
なぜIDocが残るか。「順序保証・再送・モニタリング標準装備」を必要とする業務要件は今後も消えないからです。新規プロジェクトでも、銀行・税務当局・大手取引先との連携ではIDocが選ばれることが多く、近年はIDocをIntegration Suiteに通して外部にREST APIとして公開する「IDoc延命型ハイブリッド構成」も一般的になっています。
現場で頻出するアドオン事例
事例1：エラーIDocの自動アラートメール
WE02で毎朝担当者がチェックする運用は破綻しがちです。日次バッチでステータス51/68のIDocを抽出し、自動でメール通知するアドオンは定番です。
事例2：IDoc処理の優先度キュー
特定のメッセージタイプ（請求書など）を優先的に処理したい場合、tRFC設定だけでは不十分なことがあり、BAdIで優先度キューを実装することがあります。
事例3：IDocのアーカイブ運用
IDocは大量に発生するためEDIDC/EDIDDテーブルが肥大化します。標準のアーカイブオブジェクト（IDOC）を使った定期アーカイブをジョブで自動化するアドオンが必要です。
事例4：IDocからAPIへの段階移行
新規取引先はAPIで連携、既存取引先はIDocのまま、という共存運用を支援するため、Integration Suiteを介したフォーマット変換アドオンを構築します。
事例5：監査向けIDocトレーサビリティレポート
特定取引先・期間のIDoc送受信履歴を監査向けに出力するレポート。CDSビューとFioriで構築するのが現代的です。
よくある疑問（FAQ）
Q. IDocとREST APIはどちらを選ぶべきですか？ A. リアルタイム参照ならREST API、確実な配信と再送が必要ならIDocです。両者は競合ではなく補完関係です。
Q. IDocは外部システムが受け取れる形式ですか？ A. SAP固有のXMLフォーマットです。EDIFACTやXML/JSONなど標準形式に変換するにはIntegration SuiteやSEEBURGER等の変換ツールを通します。
Q. ステータス03で止まったIDocはどう確認しますか？ A. SM58でtRFCキューを確認します。通信エラーで止まっていることが多く、ネットワークかRFCコネクションの問題です。
Q. IDocの構造を変更できますか？ A. 標準IDocタイプの拡張はZ拡張セグメント（CIMTYPE）で行います。標準セグメントに直接カスタム項目を追加するのはNGです。
Q. S/4HANA Public Cloudでも使えますか？ A. 使えますが、扱えるIDocタイプとカスタマイズの自由度は制限されます。外部連携はIntegration Suite経由が推奨されます。詳しくはPublic vs Private比較も参照してください。
まとめ
- IDocはSAPの非同期メッセージング基盤で、ALEと組み合わせて送受信を制御する
- 構造は「コントロール／データ／ステータス」の3層、データはセグメント階層を持つ
- 主要メッセージタイプ（ORDERS/DESADV/INVOICなど）は国際EDI標準に対応
- WE02・BD87・WE19が運用三種の神器、ステータス51の意味を覚えると復旧が早い
- S/4HANA時代でも現役、特に銀行・税務・大手取引先連携で第一選択
- 新規プロジェクトでは同期API・イベント・IDocを業務特性で使い分けるのが定石
- アドオンはアラート・優先度・アーカイブ・トレーサビリティ等、運用品質の底上げに使う
IDocは「古い技術」ではなく、「成熟しきって動くべきところで動き続ける技術」です。新しい連携手段を検討するときも、まずIDocで実現できないかを比較対象に置くことで、無駄な作り直しを避けられます。SAP連携を扱うエンジニアにとって、IDocの読み書きは今後も必須スキルであり続けます。
IDocの先にあるモダンな連携基盤がBTP上のIntegration SuiteやEvent Meshです。BTP全体を体系的に学んでおくと、IDocと新しい連携手段の使い分けに自信が持てます。