図2●Webサービスを使うための技術的な課題 トランザクションやセキュリティなどの機能が不足しているほか，アプリケーションの更新方法や障害時対応といった運用面で不透明な部分も多い

実用上の課題は山積み

　Webサービスの開発や利用が現実化してきたが，実際の企業システムで前述のようなメリットがすぐに得られるわけではない。SOAPやWSDL，UDDIといった現状の技術だけでは，インターネットを介した単純なRPC（Remote Procedure Call）のような利用形態しか実現できない＊2。天気予報やカレンダ，株価情報の提供，といった単機能のサービスは実現できても，実際の業務システムとなると，現状ではまだ課題が多い。　

　例えば，JTBおよびマイクロソフトと協力して出張を手配するWebサービスの試験サイトを構築したイーストは，「一度公開したサービスを追加，削除すると，（公開したインタフェース名が変わったり，無くなったりする可能性があるので，それを呼び出すアプリケーションで）互換性の問題が出てくる」（Webソリューション事業部 主任の浜谷充伸氏）という弱点を指摘する＊3。これは一例に過ぎない。Webサービスを実現するための課題はほかにも多くあり，整理すると大きく2つに分けられる。一つはサービス（アプリケーション）を連携する際の技術的な課題，もう一つは業務を連携する際のビジネス・プロセス面での課題，である。

　現状の技術面での大きな課題としては，（1）トランザクションの規定が無い，（2）セキュリティを確保するための機能が不足，（3）開発・運用に関するノウハウが無い，（4）サービスの登録方法に関するガイドラインが無い――といった点が挙げられる（図2[拡大表示]）。

　例えば，（1）は複数のサービスにまたがった2フェーズ・コミットができない，（2）はデータの部分的な暗号化や複数のサービスにまたがったアクセス権の設定ができない，といった制約につながる。セキュリティに関しては，暗号化や電子署名などで標準化も進んでいるが，まだ実システムで運用するための機能はカバーしきれていない。もちろん，XMLやSOAPといった標準以外の部分でセキュリティやトランザクションなどの機能を独自に実装することも可能だが，そうした場合，相互接続性というWebサービス本来のメリットは失われてしまう。

　（3）実際の開発・運用に関するノウハウが無いという点も見逃せない。前述したサービスを追加，削除した際の互換性の問題はUDDIを参照することで回避できるが，この参照頻度をどの程度にするかが問題になる。

　また，各Webサービスにどの程度の機能を実装するかという“粒度”も難しい。「細かくし過ぎるとデータのやり取りが何往復にもなるのでサーバーやネットワークに負荷がかかる」（イーストの浜谷氏）。複数のサービスにまたがってトランザクションを保証する仕組みが無いことを考えると，ある程度大きな単位が前提となるが，その場合は必要以上の機能を提供して無駄が多くなる可能性もある。これらの点を踏まえた上で，インターネット上で十分なレスポンスを確保できるのかという疑問もある。

ビジネス・プロセスの定義が不可欠

　BtoBシステムの構築という観点では上記の技術面の問題を解決しても，業務を連携させる際に生じるビジネス・プロセス面での課題が残っている。中でも重大なのが，データ項目が何を意味しているのかというボキャブラリが規定されていないことである。例えば，「配達日」という項目があるとすると，ある企業では「出荷日」，他の企業では「到着日」と認識してしまう可能性がある。「値の意味が一つ一つ明らかになっていないと，業務システム同士を接続することはできない」（インフォテリア 事業開発部 エバンジェリストの江島健太郎氏）。Webサービスはデータの定義にXMLスキーマを利用するが，XMLスキーマで定義できるのはデータの型や範囲だけであり，データ項目の持つ意味までは定義できない。

　BtoBのシステム間連携では，「（データ項目の意味も含めて）両方のシステムを100%理解していないと駄目。データの付き合わせ作業を標準化していく必要がある」（インフォテリアの江島氏）。企業間取引のプロセスを標準化しているRosettaNetやebXMLのように，ビジネス・プロセスの部分まである程度規定しないと実際の相互接続は難しいだろう。

　ただし，ビジネス・プロセスまでを規定してしまうとWebサービス本来の自由度は失われてしまう。そのため，Webサービスの世界ではビジネス・プロセスまでは標準化せず，この部分に関してはRosettaNetやebXMLなどの標準規約が利用されていく可能性が高いだろう。ここにきてRosettaNetやebXMLでもSOAPを採用しており，Webサービスの実装形態の一つとして見る向きも出てきた。

信用照会や品質保証も必要

図3●現状ではB2Bシステムへの適用は難しい Webサービスは，現時点ではXML，SOAP，WSDL，UDDIといったインフラ部分しか標準化されていない。B2Bでの利用を考えた場合，データ項目が何を意味するかといったボキャブラリの定義などが欠けている。RosettaNetやebXMLのようにビジネス・プロセスまである程度規定しないと業務システムの連携は難しい

　不特定多数の企業と自由に接続する，というWebサービス本来の目標を実現するための課題は他にもある。取引の相手は信用できるのか，取引が失敗した場合は誰が保証してくれるのか，決済などの契約はどうなるのか，サービスの品質は誰が決めるのか――といったことである。

　これらの課題は，サービス提供者や利用者の信用情報を提供するサービス，取引が失敗した場合の保険サービス，などが確立しない限り解決は難しい。Webサービスにはサーバー間を連携することで既存のWeb-EDIを置き換えるという期待もかかるが，実用レベルではかなり厳しい状況にある（図3[拡大表示]）。当面はこれらの課題が問題とならない世界，すなわち相手を特定した上でRosettaNetのようにビジネス・プロセスまである程度規定した世界での利用が中心となりそうだ。

　このような状況で，ユーザー企業が今から取り組むべきことは少ない。Webサービスは，特にBtoBの分野では相手がいなければ自社だけで始めても意味がない。また，将来的にWebサービスが確立したとしても，SOAPやXMLなどの実装はツールに任せられるため，対応自体はそれほど難しくないからだ。