【IT温故知新】WS-* の栄光と黄昏：エンタープライズITはいかにして「実装」に敗北したか

こんにちは。

—— 2003年のSOAから、2026年のAIへ ——

この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。

歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。

そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。

だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。

はじめに：20年前の熱狂を覚えていますか

2000年代初頭。

私はSOA（サービス指向アーキテクチャ）に本気で取り組んでいました。

当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。

カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。

SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。

あれから約20年余り。

今、新規プロジェクトでWS-ReliableMessagingの実装を検討している人はいるでしょうか。おそらく、その仕様の存在すら知らない開発者のほうが多いと思います。

私たちQualitegは今、生成AIの領域で事業を展開しています。GPUクラスター構築からディープラーニングモデル開発、LLMプラットフォームの実装まで手がけています。

その経験から言えることがあります。

技術の世界では、同じパターンが繰り返されます。

だからこそ今、WS-*とSOAという壮大な実験を振り返ってみたいと思います。これは懐古趣味ではありません。AI時代を生きる私たちが、同じ失敗を繰り返さないための、ささやかな「温故知新」です。

第1章：言葉が生まれるとき

1996年、魔法の言葉の誕生

「サービス指向アーキテクチャ」——この言葉を最初に世に送り出したのは、1996年のGartnerレポートでした。著者の一人であるRoy Schulte氏は、その後も「Enterprise Service Bus」（2002年）、「Business Activity Monitoring」といった用語を次々と生み出していくことになります。

用語の発明は、IT業界において独特の力を持っています。

新しい言葉が生まれると、その言葉を冠した製品が生まれ、その製品を解説するレポートが売れ、そのレポートを読んだCIOが予算を確保する。言葉は、それ自体がエコシステムを生み出すわけです。

Schulteのビジョンは壮大でした。ESBを「メッセージ指向ミドルウェアの信頼性とSOAのサービス抽象化を組み合わせた統合レイヤー」として位置づけ、2003年には「Predicts 2003: Enterprise Service Buses Emerge」というレポートで、ESBが企業ITの中核になると予言しています。

この予言は、ある意味で自己成就的でした。

影響力のあるアナリストが「これが来る」と言えば、CIOたちは準備を始めます。ベンダーは製品を作ります。コンサルタントは専門知識を磨きます。そして市場が生まれます。

エンタープライズという魔法の形容詞

当時の空気を覚えていますか？

「エンタープライズ」という言葉には魔力がありました。

「エンタープライズグレード」と言えば、それは「本格的」「信頼できる」「大企業にふさわしい」という意味でした。

「SOAPだけでは足りない」「本格的なシステムにはWS-*が必要だ」という声が、カンファレンスの廊下に響いていました。SOAPは十分おもたいプロトコルですがシンプルであることは、むしろ欠点とみなされていたようです。複雑さこそが、専門性の証だったのかもしれません。

私自身、当時はその空気の中にいました。

複雑な仕様書を読み解けることが、一種のステータスだったんです。今思えば、それは「裸の王様」だったのかもしれません。

米国から来たガートナー社のアナリストとの1on1の機会でも、その熱量に圧倒された記憶もあります。

第2章：標準化という名の戦場

仕様をめぐる陣取り合戦

SOAの概念が広まるにつれ、標準化の動きが加速しました。

OASIS、W3Cといった標準化団体には、IBM、Microsoft、Oracle、Sunといった大手ベンダーが集結していました。

彼らは「相互運用性」という崇高な目標を掲げていました。でも、会議室の中で起きていたのは、もう少し人間くさい駆け引きだったようです。

WS-Securityを例に取りましょう。

この仕様は元々、IBM、Microsoft、VeriSignが2002年4月に共同で公開したものでした（ライターにはその他IT企業、メーカー社員なども名を連ねています）。

ところが、その後OASISに提出されて標準化される過程で、仕様は「大きく」変更されてしまいます。結果として、元の仕様に基づいて構築されたシステムと、OASIS標準に基づくシステムは、相互運用できなくなってしまったんです。

「相互運用性のための標準化」が、「相互運用不能」を生み出した。この皮肉を笑えるのは、当時その実装に苦しんだエンジニアだけかもしれません。私も、その一人でした。

二つの信頼性

さらに興味深いのは、「信頼性のあるメッセージング」という同じ問題に対しても、二つの競合する仕様が生まれたことです。

当時からSOA界隈では有名なはなしでした。

一方には、IBMとMicrosoftが推進するWS-ReliableMessaging。

もう一方には、SunとOracleが推進するWS-Reliability。目標は同じ——メッセージの確実な配信を保証することでした。でも、アプローチは異なり、当然ながら相互運用性はありませんでした。

なぜ一つの標準にまとめられなかったのでしょうか。技術的な理由もあったでしょう。でも、それぞれの仕様の背後に、それぞれの企業の製品戦略があったことは想像に難くありません。

同様の競争は、WS-AddressingとWS-MessageDeliveryの間でも起きていました。両者は同時期にW3Cに提出され、「標準化プロセスの普通の一部」として扱われました。でも、実装者にとっては、どちらに賭けるかという不確実性を意味していたんです。

また、シンプルなSOAPのメッセージングでさえ、Java系とMicrosoft系で異なっていました。

rpc-encoded（rpc/encoded）とdocument-literal（doc/lit） の違いがあり、そもそも何も考えないで作ると通信すらできませんでした。

（とはいえ仕様先行だけでもなく、Apache Axis など、「実装」発のWebサービス・SOAP実装は存在していましたし、当時の人気OSSでした）

しびれを切らした巨人たち

IONAのCTOは後に、興味深い証言を残しています。IBMとMicrosoftは、W3Cでのセキュリティ標準化の遅さに「しびれを切らして」、OASISに仕様を持ち込んだのだそうです。

標準化団体の間にも、微妙な力学がありました。W3Cは慎重で、合意形成に時間がかかります。OASISはより機動的で、企業主導の仕様を受け入れやすい。ベンダーたちは、自分たちに有利な土俵を選んだわけですね。

結果として、WS-*の仕様群は「オープン標準」の体裁を取りながら、実質的には大手ベンダーの製品戦略に沿ったものになっていきました。「オープン」という言葉の定義について、哲学的な議論ができそうな状況でした。

第3章：ハイプの頂点から谷底へ

2003年：期待のピーク

WS-*関連の技術は、2003年のハイプサイクルに華々しく登場しました。「WS-*ベースのビジネスモデル」は、新しい時代の到来を告げるものとして紹介されていたんです。

カンファレンスは盛況でした。ベンダーのブースには人が群がり、セッションは満員御礼。「SOAロードマップ」を描くコンサルティング案件が飛ぶように売れていました。

私もその渦中にいました。複雑な仕様書と格闘し、ベンダーの技術者と議論し、なんとか動くものを作ろうとしていたんです。

2005年：幻滅の谷

ところが、わずか2年後の2005年、WS-*は「幻滅の谷」に落ちていました。

何が起きたのでしょうか。端的に言えば、「技術的な肥大化による自壊」でした。開発者たちはWS-*のAPIを書くことを嫌がりました。仕様書は複雑怪奇で、ある仕様を理解するためには別の三つの仕様を読む必要がありました。相互運用性のテストは悪夢だったんです。

ある仕様を完璧に実装したつもりでも、相手側のベンダーの実装と繋がらない。サポートに問い合わせると、「その部分はまだ実装していません」と言われる。「標準化とは一体何だったのか」——そう問いかける声が、開発者コミュニティから聞こえ始めていました。

2009年：死亡宣告

そして2009年1月、衝撃的な「死亡宣告」が出されます。

Burton Groupのアナリスト、Anne Thomas Manesが「SOA is Dead; Long Live Services」というブログ記事を公開しました。彼女はこう書きました。「SOAは2009年1月1日、経済不況の壊滅的な影響によって息を引き取った」

これは単なる挑発ではありませんでした。Manesと彼女の同僚たちは、SOAイニシアチブを進めている企業を対象に広範な調査を行っていたんです。その結論は厳しいものでした。

成功事例として挙げられたのは、Bechtel、British Telecom、MassMutualなど、ほんの一握りの企業だけ。それ以外の大多数は、SOAが約束した「コスト削減」と「ビジネスアジリティの向上」を実現できていなかったんです。

むしろ、多くの組織では状況は悪化していました。コストは上がり、プロジェクトは長引き、システムは以前より脆くなっていた。部品（サービス）は増えたのに、それを管理するインフラが追いつかなかったということです。

Manesの記事は業界に波紋を広げました。同意する声、反発する声、様々な反応がありました。でも、誰も否定できなかったのは、SOAという言葉がもはや「魔法」を失っていたということでした。

第4章：舞台裏の経済学

誰が得をしたのか

WS-*/SOAの時代を振り返るとき、避けて通れない問いがあります。「結局、誰が得をしたのか」

答えは、ある程度明らかです。

まず、用語とコンセプトを生み出し、レポートを販売した人々。新しいバズワードが生まれるたびに、それを解説するレポートの需要が生まれました。企業のIT部門は、「最新のトレンドに遅れないため」にレポートを購入したり、コンサルのインクワイアリ（要するになんか質問したら、なんか答えてくれるというサービスです）にお金をはらっていました。

次に、複雑な仕様に対応した高価なミドルウェアを販売したベンダーたち。ESB製品、SOAスイート、統合プラットフォーム——これらの製品は、決して安くありませんでした。そして、複雑であればあるほど、サポート契約も高額になりました。

そして、導入を支援したコンサルティングファーム。SOAの導入には、アーキテクチャの設計から、ガバナンスの策定、移行計画の作成まで、膨大なコンサルティング工数が必要でした。

当時のある記事は、辛辣にこう評しています。「大手コンサルファームは成果よりも戦術とビラブルアワーに集中し、多くのSOAプロジェクトを破綻させた」

誰が損をしたのか

一方、損をしたのは誰でしょうか。

まず、実際に実装を担当したエンジニアたち。彼らは、複雑怪奇な仕様書と格闘し、相互運用性のない「標準」に苦しみ、そして最終的に「なぜ動かないのか」という問いに答えなければなりませんでした。

そして、何百万ドル、時には何千万ドルもの投資を行った企業。彼らは「コスト削減」と「アジリティ向上」を約束されていました。でも、得られたのはその逆だったんです。

Manesの調査結果は冷酷でした。「何百万も投資した後、ITシステムは以前より良くなっていない。多くの組織では状況は悪化した：コストは上がり、プロジェクトは長引き、システムは以前より脆くなった」

ビジネスモデルとしてのバズワード

この構造を理解すると、なぜバズワードが定期的に生まれるのかが見えてきます。

新しい用語が生まれる。その用語を解説するレポートが売れる。その用語を冠した製品が売れる。その製品を導入するコンサルティングが売れる。そして数年後、その用語は「古い」とされ、新しい用語に置き換えられる。

このサイクルは、関係者全員（エンドユーザー企業を除く）にとって利益をもたらす構造になっています。だからこそ、繰り返されるんですね。

SOAの後には、クラウド、ビッグデータ、IoT、ブロックチェーン、メタバース、そして生成AI... と、新しいバズワードが次々と登場しました。もちろん、これらの中には本当に革新的な技術もあります。でも、ハイプとリアリティを見分ける目は、常に必要です。

第5章：もうひとつの世界で起きていたこと

Googleの静かな革命

WS-*の仕様が委員会で議論されていた頃、カリフォルニアのある企業では、まったく別のアプローチが取られていました。

Googleは2000年代初頭、急速に成長するインフラを管理するという切実な問題に直面していました。毎日数十億のリクエストを処理し、数千台のサーバーを効率的に運用する必要がありました。仕様書が完成するのを待っている余裕なんてなかったわけです。

彼らが構築したのが「Borg」と呼ばれる内部システムでした。コンテナ化されたワークロードを数十万のジョブとして管理し、リソースの効率的な利用を実現したんです。Gmail、Google検索、YouTube、Google Maps——これらすべてがBorg上で動いていました。

重要なのは、Borgは「将来必要になるかもしれない機能」ではなく、「今日この問題を解決するために必要な機能」から構築されたということです。仕様書を書いてから実装したのではありません。問題を解決し、その解決策を洗練させていきました。

Netflixの選択

同じ頃、Netflixも自社のアーキテクチャを根本から見直していました。2008年、DVDレンタルからストリーミングへの転換期に、彼らは既存のモノリシックなアーキテクチャの限界に直面したようです。

Netflixが選んだのは、WS-*ではなく、マイクロサービスアーキテクチャでした。そして彼らは、サービスディスカバリ、ロードバランシング、フォールトトレランスといった分散システムの課題を解決するためのツールを自ら構築しました。

さらに注目すべきは、Netflixがこれらのツールをオープンソースとして公開したことです。Netflix OSSと呼ばれるこれらのライブラリは、他の企業が同様の課題を解決する際の貴重なリソースになりました。

ここに、WS-*時代との決定的な違いがあります。

Netflixは仕様を策定したのではありません。動くコードを公開したんです。

第6章：パラダイムシフト

実装が標準を作る時代

2014年、Googleは驚くべき決断を下しました。

Borgで培った知見をベースに、オープンソースのコンテナオーケストレーションシステムを公開したんです。それが「Kubernetes」です。

Kubernetesの開発者たちは、BorgとOmegaの設計・展開を通じて学んだすべてを取り入れ、エレガントでシンプルで使いやすいUIと組み合わせたものを構築することを目指しました。わずか3ヶ月でプロトタイプが完成したそうです。

オープンソース化によって、フィードバックループは即座になりました。問題があればすぐにわかり、世界中の優秀なエンジニアが改善に貢献しました。2017年には、KubernetesはDocker SwarmやApache Mesosを抜いて、コンテナオーケストレーションの業界標準になっています。

この標準化のプロセスは、WS-*のそれとは根本的に異なっていました。

委員会で仕様を決めてから実装したのではありません。

実装が先にあり、その実装が広く使われることで、事実上の標準となりました。

REST/JSONの勝利

同様のことがAPIの世界でも起きていました。

WS-*が複雑なXMLエンベロープと厳格なスキーマを要求していたのに対し、RESTはHTTPの単純な動詞（GET、POST、PUT、DELETE）を使い、JSONは人間が読める軽量なデータ形式を提供しました。

理論的には、WS-Securityの方がセキュリティ機能は豊富でした。WS-ReliableMessagingの方が信頼性の保証は強固でした。

でも、開発者たちはRESTとJSONを選びました。REST"ful"かどうかは別としてそちらの系統が流行しました。

今日、ほとんどの新しいAPIはRESTとJSONで構築されています。Google Maps API、Twitter API、GitHub API——主要なサービスのAPIは軒並みRESTfulです。WS-*は、レガシーシステムとの連携が必要な場合を除いて、ほぼ姿を消しました。

第7章：二つの時代の「失敗と成功」を分けたもの

WS-*と現代のクラウドネイティブ技術の違いは、
単に「古い技術 vs 新しい技術」ではありません。

それは、標準が生まれる場所の違いです。

WS-*の多くは、標準化委員会の会議室で生まれました。
そこでは、「将来必要になるかもしれないあらゆるケース」を想定し、
仕様として完全性を追求することが善とされていました。

一方、現代の分散システム技術の多くは、
実際に巨大なサービスを運用する現場から生まれています。
Google、Netflix、Amazonといった企業が直面していたのは、
「今日、この瞬間にシステムが落ちる」という現実でした。

この違いは、設計思想にそのまま現れます。

WS-*は、
「仕様に準拠すれば、正しく動くはずだ」
という世界観に立っていました。

現代の技術は、
「壊れることを前提に、どう復旧するか」
という世界観に立っています。

たとえば、WS-ReliableMessagingは
メッセージ配送を仕様レベルで保証しようとしました。
一方、KafkaやSQSは、
「失われる可能性がある」ことを前提に、
再処理・冪等性・ログという運用設計で信頼性を担保します。

これは技術の進歩というより、思想の転換です。

この思想の違いが、最も象徴的に現れているのが
UDDI です。

UDDIは、「サービスディスカバリ」の失敗例として語られることが多いですが、
その発想自体は、実は極めて先進的でした。

UDDIが目指していたのは、
「URLではなく、意味でサービスを探す世界」です。

それは、後に「セマンティックウェブ」と呼ばれる思想と地続きでした。
サービスは単なるエンドポイントではなく、
「何ができるのか」「どの業務に対応するのか」という
意味的なメタデータを持つべきだ、という考え方です。

ただし、UDDIには決定的に欠けていたものがありました。

それを“使う主体”です。

第8章：SOAが早すぎた理由、AIが成立し始めた理由

UDDIが想定していた世界では、
サービスは意味で記述され、意味(セマンティック)で発見されるはずでした。

しかし実際にそれを検索し、選択していたのは人間でした。
エンジニアがカテゴリを選び、キーワードを入力し、
最終的には仕様書を読んで判断する。（しかも、検索はコンピューターがするという「建前」で設計されていたので検索しづらかった）

このモデルでは、
意味を厳密に記述するコストに見合うリターンが生まれません。
UDDIは「正しい思想」を持ちながら、
それを活かす知性を持たない世界（というか時代）に生まれてしまったのです。

ここで、視点を2026年に戻しましょう。

現在、私たちは LLMという「意味を扱える実体」 を手に入れました。
そして MCP やエージェントフレームワークは、
UDDIが夢見た世界を、まったく別の形で再構築し始めています。

重要な違いはここです。

• UDDIは「人間が意味を読む」世界だった
• MCPは「機械が意味を読む」世界である

MCPにおけるツール定義やスキーマは、
人間のためのドキュメントではありません。
LLMが「能力として理解し、実行するための記述」です。

これは、セマンティックウェブが抱え続けた
「人間と機械の二重構造」という問題を、
力技で解決したとも言えます。

AI時代の教訓を一段深くする

SOAは失敗したのではありません。
多くのアイデアが、早すぎただけなのです。

• 仕様で世界を完全に記述しようとしたこと
• 意味でサービスを発見しようとしたこと
• ベンダー非依存を目指したこと

これらは、今のAI時代の価値観と驚くほど近い。

違うのは、
当時はそれを本当に使いこなす「知性」が存在しなかったことです。

私たちが今、AIの世界で注意すべきなのは、
SOAと同じ過ちを繰り返すことではありません。

むしろ、
「今度こそ成立してしまう」ことへの自覚です。

意味でツールを選び、
仕様ではなく実行結果で正しさを判断し、
動くコードが標準を決めていく。

この世界は、もう仮説ではありません。
すでに、動き始めています。

歴史は韻を踏む

私たちQualitegは今、生成AIの領域で事業を展開しています。LLMプラットフォーム、AIアバター、LLMセキュリティ——毎日、最先端の技術と向き合っています。

そして、ふと気づくことがあります。今のAI業界の熱狂は、2003年のSOAブームと、どこか似ていないでしょうか。

新しい用語が次々と生まれています。AGI、ASI、マルチモーダル、RAG、エージェント、MCP... カンファレンスは満員御礼。

「AI戦略」を描くコンサルティング案件が売れる（ありがたいことです）

「AIを導入しないと遅れる」という空気が、経営層を包んでいます。

もちろん、生成AIは本物の技術革新です。

私たちはその可能性を信じているからこそ、この領域で事業を行っています。でも、だからこそ、SOAの教訓を忘れてはならないと思います。

三つの問い

AI技術を評価するとき、私は常に三つの問いを立てます。SOAの時代に学んだことです。

第一の問い：「それは実際に動くのか」

仕様書やホワイトペーパーがいくら美しくても、実際に動かなければ意味がありません。私たちは、自社のGPUインフラで実際にモデルを動かし、検証しています。理論と実装の間には、常にギャップがあります。

第二の問い：「誰が得をするのか」

新しい技術やフレームワークが提唱されるとき、その提唱者のインセンティブ構造を理解することはとても有益です。
それを売りたい人が「これは素晴らしい」と言うのは当然のこと。
問題は、実際にそれを使う人にとっても素晴らしいかどうかです。

第三の問い：「シンプルに解決できないか」

複雑さは、それ自体がリスクです。WS-*は、あらゆるケースに対応しようとして、誰も使えない複雑さに達してしまいました。最小限の複雑さで問題を解決できないか、常に問うべきだと思います。

実装者であり続けること

SOAの時代、最も損をしたのは「実装者」でした。仕様書と格闘し、動かないシステムの責任を負わされた人々です。

私たちは、常に実装者でありたいと思っています。コンセプトを語るだけでなく、実際に動くものを作る。GPUクラスターを構築し、モデルをトレーニングし、本番環境で運用する。

なぜなら、技術の真価は実装によってのみ証明されるからです。

Kubernetesは、Googleが内部で10年以上運用したBorgから生まれました。Kafkaは、LinkedInが実際のデータパイプラインで使っていたシステムがオープンソース化されたものです。OAuth 2.0は、数多くの認証システムの試行錯誤から進化しました。

どれも、「動くコード」が先にありました。

AIの民主化に向けて

生成AIの世界でも、同じことが起きつつあります。

OpenAIやAnthropicが切り拓いた技術は、オープンソースコミュニティによって急速に民主化されています。Llama、Mistral、Qwen、そして日本語に強いモデルたち。誰でもダウンロードし、自分のインフラで動かし、カスタマイズできます。

私たちのBestllamは、20以上の最新LLMを単一のインターフェースで利用できるプラットフォームです。これは、「特定のベンダーに縛られない」という、SOA時代に約束されながら実現しなかった理想を、別の形で実現しようとする試みでもあります。

LLM-Auditは、LLMへの情報漏洩を検知・ブロックするセキュリティソリューションです。WS-Securityが複雑すぎて使えなかったのとは対照的に、私たちはシンプルで実用的なセキュリティを目指しています。

おわりに：動くコードは、仕様書に勝る

WS-*とSOAの時代から、現代のクラウドネイティブな世界への移行は、ある意味で「技術における民主主義の勝利」でした。

かつて、技術標準は委員会の会議室で決められていました。大手ベンダーの代表者たちが仕様を策定し、それに従うことが「ベストプラクティス」と思い込んでいました。

今日、技術標準はGitHubのプルリクエストで形作られます。誰でもコードを読み、誰でもイシューを立て、誰でもコントリビュートできる。技術の良し悪しは、仕様書の厚さではなく、実際に動くかどうかで判断されるようになりました。

2003年ごろ、私はSOAの複雑な仕様書と格闘していました。2025年、私は日々リリースされるAIペーパーや、AIプロダクト、Python、LLMのプロンプトと格闘しています。技術は変わりました。でも、本質的な問いは変わっていません。

「それは、実際に動くのか？」

「それは、問題を解決するのか？」

「それは、使う人を幸せにするのか？」

AI時代においても、この問いを忘れないでいたいと思います。バズワードに踊らされず、実装に誠実であり続けること。それが、SOAの時代を経験した者としての、ささやかな教訓です。

もっとも、今のAI時代には、もう一つ新しい誘惑があります。
Claude Codeのようなツールを使えば、驚くほどの速度でコードが生成されます。
仕様書を読むよりも速く、議論するよりも先に、コードが「できてしまう」時代です。

だからこそ、
「動くコードは仕様書に勝る」という言葉も、
以前とは少し違った響きを持つようになりました。

いまや、コードを書くこと自体は、ほとんど努力を要しなくなりました。
何を書くかを考える時間だけが、
静かに、人の側に残っています。

シリーズ「IT温故知新」について

このシリーズでは、IT業界の過去の出来事を振り返り、そこから現代に活かせる教訓を探っていきます。懐古趣味ではなく、「歴史は韻を踏む」という観点から、同じ失敗を繰り返さないための知恵を共有することを目的としています。