目次
この記事のポイント
- IDoc=SAP内部の容器、EDI=業界標準の封筒、ALE=配送ルール、Partner Profile=接続設定の4層構造
- Outbound/Inboundとも4段フロー（業務→ALE→Port→外部）で、状態コードは01→53で推移する
- WE02/WE05/BD87/WE19/BD64が日常の運用Tコード、WE47で状態コードの意味を引く
- 「見えない失敗」が最大の落とし穴なので、①プラットフォーム指標②異常③業務照合の三層で監視する
01WHAT IDoc/EDI/ALE/Partner Profileの4つの役割
SAPの統合系を語るとき、IDoc・EDI・ALE・Partner Profileという4つの言葉が必ず出てきます。どれも「データの送受信」に関係する言葉ですが、指しているレイヤーがまったく違います。混同したまま設計に入ると、運用段階で「どこに何を設定すればよいのか分からない」「障害が起きたときに誰に連絡すべきか見えない」という混乱が起きやすくなります。
4つの言葉が指すレイヤーを分解する
まず結論として、4つの言葉は次のレイヤーに分かれます。EDIは「企業間の国際規格」、IDocは「SAP内部のデータ容器」、ALEは「SAP内部の配送エンジン」、Partner Profileは「接続設定の登録台帳」です。
業務観点での使い分け：誰が何を設定するか
実務では「業務担当がEDI規格を決める」「BASIS/EDI担当がPort・Partner Profileを設定する」「アプリ担当がIDocタイプ・メッセージを拡張する」という分業が基本です。つまり、4つの言葉は「4人の役割」に対応しています。1人の担当者がすべてを見ることはありませんが、全体像を知っていないと分業の境界でトラブルが起きます。
用語補足：EDIFACT・X12・ODETTE・VDA
EDIの国際規格には、欧州中心のEDIFACT、北米のANSI X12、自動車業界のODETTE/VDAなどがある。SAP側はIDocという共通形式で受け持つため、相手規格の差分はEDI翻訳器（VAN/PI/PO/OpenText等）が吸収する。
02POINTS 4層アーキテクチャで電文を追う6ステップ
全体像を一度に把握するには、4層の地図に沿って電文を上から下まで追うのが一番早い方法です。次のステップで、Outboundの電文がどこを流れていくかを見ていきます。
- ①業務イベント発生VA01（受注）／ME21N（発注）／MIGO（入荷）／MIRO（請求書照合）などの業務アプリで帳票が起票されると、対応するメッセージタイプ（ORDERS/ORDCHG/INVOIC/DESADV等）からIDocが自動生成される。
- ②ALEエンジンで包装WE20のPartner Profileが「どのパートナーに・どのメッセージで・どのPortで送るべきか」を解決し、Inbound/OutboundキューにIDocが格納される。
- ③Portでチャネルを選択tRFC（SAP-to-SAP）／File Port（App. Server）／HTTP・XI・PI・PO（XML/SOAP/REST）／XML・X12 Portのいずれかで送出。多対多のEDIではFile Port→VAN経由が定番。
- ④チャネル→外部パートナーEDI翻訳器がEDIFACT/X12へ変換し、相手側ERP／EDI VAN／WMS／銀行／税関などへ配達。997/Functional Ackで受領確認が返る。
- ⑤Inbound：パートナー→Port→ALE→業務起票File Port監視ディレクトリ／HTTP受信で `IDOC_INBOUND_ASYNCHRONOUS` が起動し、構文チェック→Partner Profile解決→BAPI/FM呼出でSD/MM/FIに伝票が起票される。
- ⑥状態コード01→53の遷移で成否を判定正常時は01生成→順次状態推移→53終端。失敗時は02（構文）／51（アプリ）／68（アーカイブ）等が残り、WE02/WE05で再処理対象として見える化される。
主要Tコードと日常業務での使い方
電文流通を運用するために、SAPは以下のTコードを日常的に使います。障害調査はWE02/WE05、再処理はBD87、テスト送信はWE19、モデル変更はBD64の4つを押さえれば日常運用は回せます。
障害初動はWE02で時系列検索
WE02はIDocを「作成日時」「方向」「ステータス番号」「パートナ番号」で絞り込める。状態51/53が残っている電文を抽出し、WE19でテスト再送→通れば本番再送（BD87）と段階を踏むのが安全。闇雲に再送すると、同じ電文が二重で相手に届くリスクがある。
Outbound/Inboundの代表業務フロー
実際の業務では、SD・MM・LE/WM・FIの4モジュールから電文が発生します。Outboundは「SAP→EDI VAN→相手」、Inboundは「相手→EDI VAN→SAP」の双方向で、次の4パターンが頻出します。
豆知識：997 Functional Ack とは何か
ANSI X12の997は「機能受領確認（Functional Acknowledgement）」。EDI翻訳器が構文上受信できたことをSAPに返す電文で、業務的に「正しく処理された」ことを示すのは上位のORDRSP/INVOIC相当のApplication Ack。997だけ成功して業務Ackが返らない場合は、翻訳は通っても業務連携で詰まっている、というのが典型パターン。
03INSIGHT 監視・再処理・業務照合の現場運用
アーキテクチャが綺麗でも、現場運用が弱いと「見えない失敗」が積み上がります。SAP IDoc/EDI運用では、次の3つの層で監視するのが定石です。
①プラットフォーム指標：1分あたりの送受信量、ポート可用性、tRFCエラーコード数をSolution ManagerやFocused Runで常時監視。②異常イベント：状態コード02/04/51/53/68が残ったら担当者へ自動通知。L1は自動リトライ（バックグラウンドジョブで5/15/60分間隔）、L2はBD87/WE19で人手再送、L3は業務側で取消＋再作成の3階層に分けて対応します。③業務照合：SAP受注 vs パートナーORDERS/ORDRSP、SAP出荷 vs パートナーDESADV/RECADV、SAP請求 vs パートナーINVOIC/REMADV の3点セットを月次で照合し、片方だけ立っている電文を抽出してクローズドループを完成させます。
EDIDC/EDIDSテーブルの保管期間は法令で7〜10年が求められることが多く、S/4HANA移行時にはアーカイブ戦略と情報ライフサイクル管理（ILM）を併せて設計する必要があります。S/4HANA移行、最初に押さえるべき5つのポイントでも触れていますが、IDoc/EDIは業務継続に直結するため、移行時のカットオーバー設計では特に慎重なリハーサルが必要です。AIによる監視の高度化は、SAP AI Core／Generative AI Hubのような基盤を組み合わせれば、IDocログの自動要約や異常検知に応用できます。
よくある落とし穴：状態29と「処理中」誤解
状態29は「処理中（In Process）」で、必ずしも失敗ではない。バッチ処理の直後に見ると29が残っていて、後から01や53に推移することがある。逆に、本当の原因は状態の遷移ログ（WE05の詳細ビュー）を見ないと掴めない。状態番号だけで「失敗／成功」を判断しないことが、誤検知・誤再送を防ぐコツ。
まとめ
- IDoc・EDI・ALE・Partner Profileは4つの異なるレイヤーで、混同しないこと
- 業務→ALE→Port→外部の4層で電文が流れ、状態コード01→53でライフサイクルを追える
- WE20（Partner Profile）/ WE21（Port）/ WE02・WE05（監視）/ BD87（再処理）/ WE19（テスト）/ BD64（モデル）が日常6点セット
- ①プラットフォーム指標③異常イベント⑤業務照合の三層で「見えない失敗」を可視化する
- 状態29など処理中状態の存在を理解し、誤再送を避ける運用設計が現場成功の鍵
出典・参考
- SAP Help Portal — IDoc / ALE / EDI（SAP） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE
- SAP Community — IDoc, EDI & ALE topics（SAP） https://community.sap.com/topics/idoc-edi
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-16）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
IDoc・EDI・ALEは何が違うのですか？
IDocはSAP内部のデータ容器（Intermediate Document）、EDIは企業間の国際規格（Electronic Data Interchange：EDIFACT/X12/ODETTE/VDAなど）、ALEはSAPの配送エンジン（Application Link Enabling）です。電文は「EDI（外側の封筒）→IDoc（SAP内部の容器）→ALE（配送ルール）」の三層構造で動きます。
Outboundで送る側とIncomingで受ける側で、最初に何を確認すべきですか？
OutboundはWE20のPartner ProfileとWE21のPort定義が一致しているかを確認します。InboundはFile Portの監視ディレクトリの権限、IDocタイプ／メッセージタイプ／パートナ番号の組み合わせがパートナー設定と合っているかをWE02/WE05で時系列検索して確認します。状態02が出たら構文、状態51ならアプリ側のマスタ不整合が多いです。
状態コード51/53が大量発生した場合、最初に何をすればよいですか？
WE02/WE05でパートナ番号・メッセージタイプ・時刻で絞り込み、共通原因（マスタ不整合・Port障害・翻訳器エラー）を特定します。原因がアプリ層ならBAPI呼出側（得意先マスタ／品目マスタ／価格マスタ）、通信層ならPortとEDI VANの状態を切り分けます。再送はWE19でテスト→BD87で本番の順で行い、闇雲な再送は避けてください。
S/4HANA移行時にIDoc/EDIで注意すべきすべきですか？
EDIDC/EDIDSテーブルのアーカイブ戦略、ALEモデル（BD64）の再生成、Partner Profile（WE20）の再エクスポート、状態コードの意味差分をS/4HANAに合わせて確認する、の4点が重要です。カットオーバー直前にEDI VAN側ともリハーサルを行い、Inbound側のFile Port監視ディレクトリや権限を引き継ぐかも併せて設計してください。