◆監修・編集責任者
B2B EC-COLUMN
目次
「Web-EDIの画面が表示されない・操作できない」ときに最初に確認すること
取引先から案内されたURLを開いたのに、明細の表が崩れてボタンが押せない。
昨日まで受注データを取り込めていたのに、今朝はログイン画面から先へ進めない。
こうしたとき最初に突き合わせるのは、提供元が公表しているWeb-EDIの動作要件です。
原因がシステム側の不具合ではなく、Internet Explorer 11のサポート終了やChromeにおけるCookieの扱いの変更といった、ブラウザ側の仕様が動いたことにある場合があるからです。
IEを前提に作られた画面はMicrosoft EdgeのIEモードで当面開けますが、これは期限のある暫定策にあたります。
要件を満たしているのに動かないときはCookieの設定を確かめ、症状を整理して提供元に確認しながら、並行して移行の時期も見ておきましょう。
画面が崩れる・ボタンが反応しない典型例
取引先から案内されたWeb-EDIのURLを開くと、ログインまでは進めるのに、明細の一覧が枠からはみ出して読めない。
検索ボタンを押しても何も起きない。
納品データのダウンロードリンクを押すと、空白のタブが開いて終わる。
Web-EDIが使えないと言われる状態は、システム全体が落ちているというより、こうした部分的な不具合として現れることがよくあります。
もうひとつ多いのが、昨日まで問題なく使えていたのに今朝から入れない、という現れ方です。
IDとパスワードを入れても、エラーメッセージが出ないままログイン画面に戻される。
あるいは画面は開くのに、受注一覧の部分だけが真っ白のままになる。
自分は何の設定も変えていないという感覚があるぶん、どこから手をつければよいのか見当がつきにくいのがこのパターンです。
利用者側だけでできる切り分けは、そう多くありません。
同じ端末で別のブラウザを開いて同じURLにアクセスしてみる、隣の担当者の端末でも同じ症状が出るかを見てみる。
この二つで、症状が自分の端末とブラウザに限られるのか、その画面を開いた全員に起きているのかまでは分かります。
ただし、ここで分かるのは症状の範囲であって、原因ではありません。
原因に当たりをつけるには、その画面がどんな環境で動くことを前提に作られているのかを知る必要があります。
提供元が公表する「動作要件」が唯一の判断基準になる理由
動作要件とは、提供元がこの環境なら動くことを確認している、と示した範囲のことです。
一般的にはOSの種類とバージョン、ブラウザの名称とバージョン、JavaScriptやCookieを有効にしておく必要の有無、推奨する画面解像度といった項目が並びます。
Web-EDIによっては、電子証明書の導入や特定のファイル形式の取り扱いが前提になっていることもあります。
裏を返せば、そこに書かれていない組み合わせで開いたときの挙動は、動くかもしれないし動かないかもしれない、という扱いになります。
だからこそ、症状から原因を推測する前に、まず自分の環境が要件の内側にいるのか外側にいるのかを確かめる価値があります。
ここで「Chromeなら大丈夫」「Edgeにしておけば安心」といった一般論が役に立たないのは、Web-EDIが発注企業ごとに画面も入力項目も異なる、個別に作り込まれた仕組みだからです。
流通業界の標準である流通BMSにおいても、Web-EDIは別途ガイドラインとして整備され、第1.0版が2012年に公開されています3。
策定にあたっては、実際の利用者と、アプリケーションを開発・提供するITベンダーなどから意見を集めたとされています3。
標準化の取り組みが行われてきたこと自体が、提供元ごとの作りの違いが大きい領域であることを示しています。
つまり、対応ブラウザの答えは業界一般ではなく、目の前のWeb-EDIの提供元が持っています。
では、その要件はどこに書かれているのか。
ログイン画面の下部にある「動作環境」「ご利用にあたって」といったリンク、提供元のヘルプページやオンラインマニュアル、取引先から配布された利用手引きのいずれかに記載されていることがあります。
一方で、サービスの紹介ページを見ても具体的な記載が見つからないこともあります。
あるWeb-EDIサービスの紹介ページでは、利用環境について、インターネットに接続できるPC環境（Webブラウザ）があれば可能です、と記載されており、対応ブラウザ名やバージョンの具体的な記載は同じページ上にはありません4。
これは一社の紹介ページでの記載であり、業界全体の慣行として広げられる話ではありません。
ただし、営業向けの紹介ページと技術的な要件を示すページが分かれている場合があると知っておくと、探す場所を切り替えやすくなります。
要件が見つかったら、OSのバージョン、ブラウザ名、ブラウザのバージョンの三点を、自分の端末の実際の値と並べて確認します。
ブラウザのバージョンは、設定メニューのバージョン情報から確認できます。
ここで要件の外にいると分かれば、対応しているブラウザで開き直すという答えが出ます。
要件の内側にいるのに動かない場合は、別の要因を疑うことになります。
次の節では、要件の内側にいたはずの人が、ある日突然外側に押し出されてしまう仕組みを見ていきます。
なぜ「今まで使えていたWeb-EDI」が急に使えなくなるのか
Internet Explorer 11のサポート終了（2022年6月）
Internet Explorer 11のデスクトップアプリケーションは、2022年6月に、特定のバージョンのWindows 10でサポートを終了しました1。
ここで対象となっているのは、そのバージョンのWindows 10上で動くIE11デスクトップアプリであり、すべての環境のIEが同じ日に一斉に消えたという話ではありません。
それでも、受注業務で使うWeb-EDIにとってこの変化が大きかったのは、IEを前提に作られた画面が業務システムの側に数多く残っていたためです。
Microsoftは、レガシーなIEサイトに依存する組織に対して、そのサイトをInternet Explorerモードを使ってMicrosoft Edgeで開くように構成する必要があるとしています1。
この案内の言い回し自体が、状況をよく表しています。
IEでしか正しく動かない画面は、ブラウザを新しくすれば自動的に動くようになるものではなく、そのまま残っているという前提に立った案内だからです。
受注側の担当者から見れば、自分が使うブラウザの問題ではなく、取引先が用意した画面の作りの問題が、ブラウザの世代交代によって表に出てきたことになります。
利用者にとっては、この変化は端末の入れ替えや社内のWindows更新をきっかけに突然やってきます。
これまでデスクトップのアイコンから開いていたはずのIEが起動せず、代わりにEdgeが立ち上がる。
Edgeで同じURLを開くと、レイアウトが崩れたり、ボタンが反応しなかったりする。
このとき起きているのは、Web-EDIの側が変わったのではなく、自分の手元の環境が要件の外へ移動したという事態です。
だから、提供元に問い合わせる前に、いつ端末やOSを入れ替えたかを思い出しておくと、話が早く進みます。
Chromeなど主要ブラウザのCookie仕様変更（SameSite）
もうひとつ、IEとは別の経路で「昨日まで動いていたのに」を引き起こすのがCookieの扱いです。
Cookieは、ログインした状態を保つためにブラウザが預かっている小さなデータのことです。
ログイン画面で認証したあと、受注一覧や明細画面へ移動しても本人だと認識されるのは、このデータがブラウザからシステムへ送られているからです。
Chrome 80が公開された2020年2月、このCookieの既定の扱いに変更が入りました2。
SameSite属性が指定されていないCookieは制限のある扱いとなり、サイトをまたいでCookieを送信するサービス、たとえばウィジェットや埋め込みコンテンツの側は、SameSite=None; Secureとして明示的に更新する必要があるとされています2。
これはChromeにおける既定動作の話であり、システム側がCookieの属性を明示していない場合に影響します2。
Web-EDIの画面でこれが問題になりやすいのは、サイトをまたぐ構成が使われている場合です。
認証の画面と業務の画面でドメインが異なる、あるいは取引先のポータルサイトの中にWeb-EDIの画面が埋め込まれている、といった作りが該当します。
この構成でCookieが送られなくなると、利用者の目には、ログインしたはずなのにログイン画面へ戻される、一覧だけが読み込まれない、といった形で映ります。
操作している側からは認証の失敗にしか見えないため、パスワードを何度も打ち直してアカウントをロックしてしまう、という遠回りも起こり得ます。
ただし、どのCookieにどの属性が指定されているかはシステム側の実装によるため、利用者側から原因を断定することはできません。
この節で押さえておきたいのは、ブラウザは自動更新で新しくなり続けるという点です。
自分は設定を何も変えていなくても、ブラウザの既定の振る舞いは変わります。
Web-EDIが急に使えなくなったとき、心当たりがないのは当然で、変わったのは多くの場合こちら側ではなく、足元のブラウザのほうです。
この見取り図を持っておくと、次に何を確かめればよいかを落ち着いて選べます。
| ブラウザ側の変更 | 時期 | 利用者側に現れやすいこと |
|---|---|---|
| Internet Explorer 11デスクトップアプリのサポート終了 | 2022年6月 | IEを前提に作られた画面が正しく表示・操作できない |
| ChromeにおけるSameSite属性の既定の扱いの変更 | 2020年2月（Chrome 80） | サイトをまたぐ構成でログイン状態が保たれないことがある |
Internet Explorer依存のWeb-EDIをどう延命するか
Microsoft EdgeのIEモードとは
IEモードは、Microsoft Edgeの中で、指定したサイトだけをInternet Explorerの表示方式で開く仕組みです。
普段の業務では新しいEdgeをそのまま使い、IEでなければ正しく動かないWeb-EDIの画面を開いたときだけ、内部的に従来の表示方式へ切り替わります。
利用者から見れば、ブラウザを二つ使い分ける必要がなくなり、URLを開くだけで従来どおりの画面に戻る、という位置づけになります。
注意したいのは、Microsoftの案内が、レガシーなIEサイトに依存する組織が、そのサイトをIEモードで開くように構成する、という形になっている点です1。
どのURLをIEモードで開くかは、あらかじめ決めて設定しておく必要があるという前提に立っています。
企業が配布する管理された端末では、Edgeの設定が情報システム部門のポリシーで制御されていることがあり、利用者が自分の画面から設定を変えるだけでは完結しないことがあります。
逆に言えば、この設定は担当者が一人で悩むべき領域ではなく、社内の管理者と一緒に進める話です。
社内の管理者に相談するときは、次の情報をそろえておくと、確認が一往復で済みます。
対象のWeb-EDIのURL、その画面で起きている症状、いつから起きているか、取引先や提供元からIEでの利用を前提とした案内が出ていないか。
特にURLは、ログイン画面と業務画面でドメインが違うことがあるため、症状が出ている画面のアドレスをそのまま伝えるのが確実です。
提供元がIEモードでの利用を想定した案内資料を出している場合は、その資料を添えると設定の対象範囲が定まります。
IEモードにも終了時期がある（暫定措置である）
IEモードは、いつまでも使える仕組みとして案内されているわけではありません。
2022年6月時点の発表では、Microsoft EdgeのInternet Explorerモードでは下位互換性が有効になり、少なくとも2029年までサポートされるとされています1。
ここは「少なくとも」という表現であり、それ以降も続く可能性を否定するものではありません。
同時に、終了時期が確定していないということは、いつ具体的な期日が示されてもおかしくない、ということでもあります。
この期限の読み方が、実務では判断を分けます。
IEモードを設定すれば目の前の受注業務は止まらずに済みますが、それはWeb-EDIの側が新しいブラウザに対応したという意味ではありません。
画面の作りは古いまま残り、提供元が改修しない限り、状況は変わらないからです。
つまりIEモードは、提供元や取引先が対応を進めるまでの時間を買う手段であって、問題を解いたわけではありません。
受注側の担当者が単独でできることには、はっきりと限界があります。
画面を作り直せるのは提供元であり、どのWeb-EDIを使うかを決めるのは発注側の取引先です。
その前提で自分の側にできるのは、IEモードで業務を止めないようにしつつ、提供元や取引先が今後どうするつもりなのかを確かめ、社内の端末更新の計画と突き合わせておくことです。
この二つを並行して進めておくと、期限が示されたときに慌てずに済みます。
動作要件を満たしているはずなのに動かない場合に確認すること
ブラウザ側のCookie設定を確認する
対応ブラウザにも対応バージョンにも当てはまっているのに、画面が正しく動かない。
このときに見ておきたいのがCookieの設定です。
ブラウザの設定にあるプライバシーやセキュリティの項目で、Cookieの受け入れがどう設定されているか、サイトをまたぐCookieを制限する設定が有効になっていないかを確認します。
広告やトラッキングを抑える目的で入れた拡張機能が、結果として業務システムのCookieまで止めてしまうこともあります。
対象のサイトだけを例外として許可できる場合は、その画面のドメインを例外に加えると挙動が変わることがあります。
ただし、ここで直らなかったとしても、自分の設定が悪かったという結論にはなりません。
Cookieが送られるかどうかは、ブラウザのバージョンや設定だけでなく、システム側がCookieにどの属性を指定しているかにも左右されるためです2。
SameSite=None; Secureのような指定が行われていない場合、利用者がどれだけ設定を見直しても、意図したとおりにCookieが送られないことがあります。
つまり、利用者側の確認は原因を絞り込むための作業であって、原因を断定するための作業ではありません。
社内の端末では、ブラウザの設定自体が管理ポリシーで固定されていて、利用者が変更できないこともあります。
その場合は、変更を試みるより先に、どの設定が固定されているかを管理者に確認したほうが早く進みます。
確認した結果は、次に提供元へ問い合わせる際の材料になります。
提供元のサポート窓口へ確認すべきこと
ここまでの確認で解決しなければ、提供元への問い合わせが最短の道になります。
紹介ページに対応ブラウザ名やバージョンの具体的な記載が見つからない場合4、要件を確定させる方法は提供元に聞くこと以外にありません。
あいまいな情報のまま試行錯誤を続けるより、確認済みの答えを一つ得たほうが、結果として早く業務に戻れます。
問い合わせるときに伝えると話が進みやすいのは、環境と症状の具体です。
OSの種類とバージョン、ブラウザの名称とバージョン、症状が出ている画面のURL、いつから起きているか、他の端末や他の担当者でも同じ症状が出るか、画面に表示されたメッセージの文言。
これらは先ほどの切り分けで既に手元にそろっているはずのものです。
スクリーンショットがあれば、レイアウトの崩れ方まで一度で伝わります。
あわせて聞いておきたいのは、次の点です。
対応しているブラウザとバージョンの範囲はどこまでか、その画面はIEを前提にした作りになっているのか、IEモードでの利用を想定しているのか、同じ症状の報告が他にもあるのか。
取引先が指定したWeb-EDIの場合、問い合わせ窓口が提供元に直接つながらず、発注企業の担当者を経由する運用になっていることもあります。
誰にどの順で連絡するかを最初に決めておくと、同じ説明を何度も繰り返さずに済みます。
受注側として押さえておきたいのは、ここで確認した内容が一度きりの復旧作業で終わらないという点です。
対応ブラウザの範囲やIEモードの要否は、次に端末を入れ替えるときにも、担当者が交代するときにも必要になります。
回答を受け取ったら、その内容を社内で参照できる形にしておくと、同じ調査をもう一度することを避けられます。
恒久対応としてIE依存からの移行をいつまでに検討すべきか
移行検討を始める目安の考え方
IEモードで画面が開くようになると、目の前の困りごとは消えます。
受注データは今日も取り込めて、出荷も止まらない。
だからこそ、この状態は後回しにされやすいものです。
しかし延命策が効いているのは、少なくとも2029年までとされたIEモードのサポート期間の内側にいるからであり1、その先は現時点で確定していません。
期日が示されてから動き出すと、社内の調整と取引先とのやり取りを同時に進めることになります。
ここで区別しておきたいのは、何が移行の本体かという点です。
受注側の担当者にとって、自分の端末のブラウザを新しくすることは移行ではありません。
本体は、IEを前提に作られたWeb-EDIの画面そのものが更新されるかどうかであり、それを決めるのは提供元と、そのシステムを指定している発注側の取引先です。
自分の側でできるのは、相手の予定を早めに知り、それを社内の計画に反映させることです。
この関係を取り違えると、自社だけで解決しようとして時間を使ってしまいます。
現実的な進め方としては、すでに予定が決まっている変更の時期に合わせて確認するのが無理がありません。
端末のリース更新、OSの入れ替え、取引先との取引条件の見直し。
こうした節目は社内で日程が押さえられているため、そこに「このWeb-EDIは新しいブラウザで動くのか」という確認を一つ足すだけで、独立した検討課題を立ち上げずに済みます。
確認した結果、提供元から対応の予定が示されればその時期を控えておき、示されなければ、IEモードの期限が近づく前にもう一度聞く、という進め方になります。
立場が発注側、つまりWeb-EDIを取引先に使ってもらう側であれば、話の向きが変わります。
対応ブラウザを公表し、その範囲を更新していくこと自体が自社の責任範囲に入るためです。
ブラウザ側の既定動作が変わったときに、受注側の取引先から同じ問い合わせが並ぶ前に告知を出せるかどうかで、取引先の作業量が変わります。
どちらの立場であっても、確認すべき項目そのものは大きく違いません。
次に挙げる項目は、自社だけで分かることと、相手に聞かなければ分からないことを並べたものです。
確認の順番が決まれば、今の環境で何を見て、誰に何を聞くかが具体的になります。
動作要件を読んで自分の環境と突き合わせるところまでは手元で進められますが、IEを前提にした画面を今後どう扱うかは、取引先のシステムの事情と自社の受注業務の流れの両方を見ないと決められません。
現在の受注の受け取り方と、使っているWeb-EDIの数や画面の使い方を整理すれば、どこまでを延命で持たせ、どこから受注データの扱い方を変えるべきかの見通しを確かめられます。無料相談で要件を整理する
IE依存からの移行検討で確認しておきたい項目
自社の中だけで確かめられることと、提供元や取引先に聞かなければ分からないことを分けて並べています。
- どの取引先のどのWeb-EDIがIEを前提にしているか（画面のURLと利用している担当者を含めて洗い出す）
- その画面を今どうやって開いているか（IEモードの設定は誰が行い、どこまでの範囲に適用されているか）
- 提供元が対応ブラウザの更新予定や代替手段を示しているか
- 取引先から仕様変更の告知がどの経路で誰に届く運用になっているか
- 社内の端末更新やOS入れ替えの計画と、確認のタイミングが重なるか
- その画面が使えなくなった場合に、受注情報を受け取る別の方法が用意されているか
提供元が対応ブラウザの更新時期を示した場合は、自社での延命策をどう続けるかよりも、その時期に合わせて社内の端末や運用をどう揃えるかへ確認の重心が移ります。
要点の整理
| 確認する軸 | 判断の基準 |
|---|---|
| 動くかどうかの判断 | 提供元が公表する動作要件に、自分のOS・ブラウザ・バージョンが含まれているか |
| 急に使えなくなった原因 | IE11デスクトップアプリのサポート終了（2022年6月・特定バージョンのWindows 10が対象）や、ChromeにおけるCookieの既定の扱いの変更（2020年2月・Chrome 80）といったブラウザ側の変化 |
| IEを前提にした画面の当面の対処 | Microsoft EdgeのIEモードで開く構成。管理された端末では社内の管理者による設定が必要な場合がある |
| 延命できる期間 | IEモードは2022年6月時点の発表で少なくとも2029年までサポート。それ以降は未確定 |
| 要件を満たすのに動かないとき | Cookieの設定と拡張機能を確認し、環境と症状を整理して提供元に確認する |
期限が確定していない延命策の上で業務を続けるかどうかは、社内の端末更新の予定と取引先の対応方針が重なる位置で判断するもので、担当者が一人で抱えると判断材料がそろいません。 複数の取引先のWeb-EDIをどう使い分けているかを一度並べて見れば、どの画面から先に確認を進めるべきか、その確認で誰に何を聞けばよいかを具体的にできます。
よくある質問
Windows 11ではWeb-EDIの動作要件は変わりますか
動作要件はOSとブラウザの組み合わせで示されることが多いため、OSを入れ替えると要件の内側にいるかどうかが変わる可能性があります。
確認済みの事実として言えるのは、Internet Explorer 11のデスクトップアプリが2022年6月に特定のバージョンのWindows 10でサポートを終了したこと1、そしてレガシーなIEサイトに依存する組織はMicrosoft EdgeのIEモードで開くように構成する必要があるとされていること1です。
個別のWeb-EDIがどのOSを対象にしているかは提供元の動作要件に書かれているため、端末を入れ替える前に、移行後のOSが要件に含まれているかを確認しておくと、入れ替え直後に受注業務が止まる事態を避けられます。
スマートフォンやタブレットでWeb-EDIは使えますか
提供元の動作要件次第で、一律には言えません。
あるWeb-EDIサービスの紹介ページでは、利用環境としてインターネットに接続できるPC環境（Webブラウザ）があれば可能です、と記載されています4。
これは一社の記載であり業界全体の話ではありませんが、PCでの利用を前提に書かれている例があることは分かります。
要件にスマートフォンやタブレットの記載がなければ、動くかどうかは確認されていない範囲になりますので、外出先での確認に使いたい場合は提供元に対応の可否を聞くのが確実です。
Microsoft EdgeのIEモードは個人の設定だけで有効にできますか
必ずしも個人の設定だけで完結するとは限りません。
Microsoftの案内は、レガシーなIEサイトに依存する組織が、そのサイトをIEモードで開くように構成する、という形になっています1。
企業が配布する管理された端末では、Edgeの設定が情報システム部門のポリシーで制御されていることがあり、その場合は対象URLの登録を管理者側で行う必要があります。
まずは対象の画面のURLと症状を整理して、社内の管理者に設定が可能かを確認するところから始めるとよいでしょう。
IEモードが将来終了したら今のWeb-EDIはどうなりますか
2022年6月時点の発表では、Microsoft EdgeのInternet Explorerモードは少なくとも2029年までサポートされるとされています1。
それ以降の扱いは現時点では確定していません。
重要なのは、IEモードが使える間もWeb-EDIの画面自体は古い作りのまま残っているという点で、提供元が新しいブラウザに対応した画面へ更新しない限り状況は変わりません。
したがって、受注側としては、提供元や取引先に対応の予定を確認し、その回答を社内の端末更新の計画と突き合わせておくことが、期限が示されたときに慌てないための備えになります。
- 1 出典：日本マイクロソフト株式会社（Microsoft Learn）「Internet Explorer 11 デスクトップ アプリケーションは、特定のオペレーティング システムのサポートを終了しました」（2022年）
- 2 出典：Google（web.dev／Chrome Developers）「SameSite cookies explained」（2020年）
- 3 出典：一般財団法人流通システム開発センター（流通BMS協議会／GS1 Japan）「流通BMSにおけるWeb-EDI」（2012年）
- 4 出典：株式会社JSOL「JSOL Web-EDI（サービス紹介ページ）」（確認時点）
