UIと機能の通信・実行方式

• 日程: Day 3 / セッション 7
• 時間: [14:30-15:00]
• 形式: 座学
• ゴール: RPC・CORBA・HTTPの位置づけと、SOAP/XML/WSDL型とREST/JSON/WADL型のWebサービスの違いを説明できる。実行方式（ネイティブアプリ、Webアプリ、クラウド SaaS/PaaS/IaaS）を選択の観点つきで列挙できる
• 学習形式: 対話型解説

Day 2 で、あなたは機能一覧とプレゼンテーション一覧を分離して抽出しました。今日の午前は多層アーキテクチャで、その分離が業界標準の構造であることも確認しました。

ここで問いかけです。プレゼンテーション（画面）と機能（ロジック）を別の場所に分離したら、次に何が必要になるでしょうか？

答えは通信です。画面はブラウザに、機能はサーバにある。分離した瞬間、両者の間に「会話の手段」が必要になります。分離は無料ではなく、通信というコストを払って手に入れるものなのです。

このセッションでは、その通信の歴史と現在の主流（REST/JSON）、そしてソフトウェアをどこで動かすかという実行方式を学びます。次のセッションで RESTful API を自分で設計し、明日 Day 4 ではそれをそのまま実装します。つまりここは、明日の実装に直結する30分です。

「離れた場所にある機能を呼び出したい」という願いは、インターネットより古くからありました。

• RPC（Remote Procedure Call）: 1980年代に普及した「遠くの関数をあたかも手元の関数のように呼ぶ」仕組みです。書き心地は最高ですが、呼ぶ側と呼ばれる側が同じ言語・同じ環境であることを前提にしがちでした
• CORBA: 1991年に登場した、言語もOSも越えて呼び出せる共通規格です。理想は壮大でしたが、仕様が複雑になりすぎて開発者に敬遠されました
• HTTP: もともとWebページを運ぶための単純なプロトコルです。ところが2000年代、UIと機能の通信の主役はこのHTTPになりました

ここで少し考えてみてください。理想を追求したCORBAではなく、なぜ「ただの文書運搬プロトコル」だったHTTPが勝ったのでしょうか？

理由は3つあります。

• 単純: リクエストを送り、レスポンスを受け取る。それだけ
• 普及済み: すべてのブラウザ・サーバ・ファイアウォールがHTTPを通す前提で作られていた
• 疎結合: 呼ぶ側と呼ばれる側が、互いの言語や実装を知らなくてよい

これは物流に例えると、専用の特別列車（CORBA）より、どの町にも届く郵便網（HTTP）が選ばれたようなものです。性能や厳密さより「どこでも使えること」が勝敗を分けました。

RPCとHTTPの発想の違いを、家計簿の「支出記録を1件取る」処理で対比します。

// RPCの発想: 遠くの「関数」を呼ぶ（手元の関数呼び出しに見える）
const expense = remoteServer.getExpense(1);

// HTTP(REST)の発想: 遠くの「リソース」をURLで指して取り寄せる
const response = await fetch("https://api.example.com/expenses/1");
const expense = await response.json();

RPCの主役は「関数名」、HTTPの主役は「URL（リソースの住所）」です。この主役の違いが、次のトピックのRESTにつながります。

• 分離には通信が必要。通信方式の選択は「分離の設計」の一部
• RPC→CORBA→HTTPの流れは「厳密さ・専用性」から「単純さ・普遍性」への移行
• 技術は優れたものが勝つとは限らない。「すでに広く通じるもの」が勝つことが多い

CORBAを策定したのはOMG（Object Management Group）という業界団体で、最盛期には800社以上が参加していました。ところが参加企業が増えるほど、各社の要望を盛り込んで仕様が肥大化し、「仕様書は分厚いのに、相互接続すると動かない」という皮肉な状態に陥ります。この失敗は「委員会設計（design by committee）」の代表例としてよく引用されます。船頭多くして船山に上る、の国際規格版です。一方のHTTPは少人数の設計で単純さを保ち続けました。設計に関わる人数と設計の良さは、比例しないどころか反比例することさえあるのです。

HTTPの上で機能を提供する仕組みをWebサービスと呼びます。ここに2つの流派があります。

• SOAP/XML/WSDL型: SOAPという封筒形式のXMLでメッセージを包み、WSDLという契約書で呼び出し方を厳密に定義する流派。銀行間取引などエンタープライズ領域で使われてきました
• REST/JSON/WADL型: HTTPそのものの語彙（GET/POST/PUT/DELETE）で操作を表し、データはJSONで運ぶ流派。現在のWeb APIの主流です

これは手紙に例えると、SOAPは「公文書」です。定型の封筒に入れ、書式を厳守し、内容証明をつける。RESTは「はがき」です。宛先（URL）と用件（メソッド）と本文（JSON）だけ。公文書は確実ですが書くのも読むのも重く、はがきは軽くて速い。

用語の整理をしておきます。SOAPとRESTの対比で「REST/JSON/WADL」と並べますが、WADLはWSDLに対応する「API記述言語」であって、RESTに必須ではありません。実際、WADLは該当技術として存在しますが、現在の主流ではありません。なぜなら、RESTの世界では後発の OpenAPI（Swagger）が事実上の標準になったからです。

ここで分からないことがあれば、遠慮なくAIに質問してみましょう。「SOAPとRESTの違いを郵便以外のたとえで説明して」と頼むのも良い練習です。

同じ「支出記録1件の取得」を両流派で書きます。SOAPの冗長さに注目してください。

SOAP（リクエストのXML）

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getExpense xmlns="http://example.com/kakeibo">
      <expenseId>1</expenseId>
    </getExpense>
  </soap:Body>
</soap:Envelope>

REST（リクエストは1行、レスポンスはJSON）

GET /expenses/1 HTTP/1.1

{
  "id": 1,
  "date": "2026-07-06",
  "amount": 480,
  "category": "食費",
  "memo": "コーヒー"
}

RESTの通信を図にすると、こうなります。明日あなたが実装するのは、まさにこの往復です。

• RESTは「リソース（情報）をURLで指し、HTTPメソッドで操作する」様式。ROA（リソース指向アーキテクチャ）の実装形と言える
• JSONはJavaScriptと相性が良く、ブラウザでそのままオブジェクトになる。これがREST/JSON普及の追い風になった
• どちらが優れているかではなく「何を重視するか」で選ぶ。厳密な契約が必要ならSOAP系、軽さと普及ならREST系

RESTは製品でも規格でもなく、一人の博士学生の論文から生まれました。ロイ・フィールディングが2000年に発表した博士論文 "Architectural Styles and the Design of Network-based Software Architectures" の第5章がRESTです。彼はHTTP 1.1仕様策定の中心人物でもあり、論文は「なぜWebはこれほどスケールしたのか」を分析して、その設計原則に名前を与えたものでした。つまりRESTは発明ではなく発見です。すでに世界最大の分散システムとして動いていたWebの成功理由を言語化したからこそ、RESTは説得力を持ちました。博士論文が20年以上も世界中のAPI設計を支配している例は、他にほとんどありません。

通信方式が決まっても、まだ問いが残ります。そのソフトウェアはどこで動くのかです。

• ネイティブアプリケーション: PCにインストールして動く（例: Excel）
• モバイルアプリ: スマートフォンにインストールして動く（例: 家計簿アプリ）
• Webアプリケーション: ブラウザで動き、インストール不要（例: Webメール）
• クラウドコンピューティング: 事業者のサーバ群を借りて動かす

  • SaaS: ソフトウェアごと借りる（例: Gmail）
  • PaaS: 実行環境を借りて自分のアプリを載せる（例: Heroku、Monaca）
  • IaaS: 仮想サーバを借りてOSから自分で構築（例: EC2）
• オンプレミス: 自社に物理サーバを置いて運用する（クラウドの対義語）

SaaS/PaaS/IaaSの違いは「どこまで借りるか」です。ピザに例えると、SaaSは宅配ピザ（全部お任せ）、PaaSはピザ生地だけ買って具は自分で載せる、IaaSはキッチンを借りて粉から作る、のようなものです。

選択の観点を整理します。正解は1つではなく、Day 2 で学んだペルソナと保守期間がここでも判断基準になります。

ここで考えてみてください。あなたの開発テーマのペルソナは、電波の届かない場所で使うでしょうか？　10年使い続けるでしょうか？　答えによって選ぶ実行方式が変わります。たとえば「地下鉄で使う家計簿」ならオフラインに強いモバイルアプリが該当しますが、「月末に自宅で見る資産レポート」なら該当しません。なぜなら、後者はオフライン要件がなく、更新の届けやすさの方が価値だからです。

家計簿システムでの選択例です。次セッション以降の前提になる構成です。

• プレゼンテーション: Webアプリ（ブラウザのHTML/JavaScript）
• 機能: RESTful APIサーバ（研修ではPaaS上のAPIモックで代用）
• 選択理由: 受講者全員の環境で配布不要で動き、明日1日で実装できるため

• 実行方式の選択は技術の好みではなく、ペルソナの利用状況・配布/更新・オフライン・コスト・保守期間から決める
• オンプレミスかクラウドかは「所有か賃貸か」の判断。初期費用と統制を取るか、柔軟さと従量課金を取るか
• 本研修の実装（Day 4）は「Webアプリ＋クラウド上のAPIモック」構成を使う

「クラウド」という言葉は、エンジニアがネットワーク図を描くとき、インターネットを雲の絵で省略して描いた習慣に由来します。「詳細は知らなくていい、とにかく向こう側」を表す記号だった雲が、そのままサービス形態の名前になりました。この言葉を有名にしたのは2006年のGoogleのCEOエリック・シュミットの講演と、同年に始まったAmazon EC2だと言われます。ちなみにSaaSの発想自体は新しくなく、1960年代の「タイムシェアリング」（大型計算機を時間貸しする商売）とそっくりです。技術の世界では、同じアイデアが名前を変えて何度も戻ってきます。名前の流行に惑わされず「どこまで借りるのか」という本質で見る癖をつけましょう。

• 「RPC・CORBA・HTTPの歴史を、それぞれが解決しようとした課題と失敗した点に注目して時系列で説明してください」
• 「SOAPが今も使われ続けている業界と、その理由を教えてください。RESTでは代わりにならないのですか？」
• 「家計簿システムを『モバイルアプリ＋IaaS』構成にした場合と『Webアプリ＋PaaS』構成にした場合の利点と欠点を、学生ユーザというペルソナ前提で比較してください」

今回学んだことを一言でまとめると、**「プレゼンテーションと機能を分離すると通信が必要になり、その現在の主流がREST/JSONである」**です。

• 通信の歴史はRPC→CORBA→HTTP。単純で普及したものが勝った
• Webサービスには公文書型のSOAP/XML/WSDLと、はがき型のREST/JSON/WADLの2流派がある
• 実行方式（ネイティブ/モバイル/Web/クラウド SaaS/PaaS/IaaS/オンプレミス）は、ペルソナ・配布・オフライン・コスト・保守期間の観点で選ぶ

次のセッションは実習です。今見たREST/JSONで、あなたの機能一覧からRESTful API設計書を作ります。Day 2 のCRUDがそのままHTTPメソッドに対応するという、気持ちの良い種明かしが待っています。

• CORBAではなくHTTPがUIと機能の通信の主役になった理由を、2つ以上挙げられますか？
• SOAP型とREST型の違いを「封筒・契約書」「URL・メソッド・JSON」という言葉を使って説明できますか？
• あなたの開発テーマに合う実行方式を1つ選び、選択の観点（配布・オフライン・コスト等）を添えて言えますか？

• 参考リンク: Roy Fielding 博士論文 第5章 "Representational State Transfer (REST)"（https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm）
• 参考リンク: MDN Web Docs「HTTPの概要」（https://developer.mozilla.org/ja/docs/Web/HTTP/Overview）
• 発展課題: gRPC（GoogleのRPCフレームワーク）を調べ、「RPCの発想は死んでいない」と言われる理由をRESTとの使い分けの観点でまとめてみる