マッシュアップとは？Web APIを組み合わせる仕組みと作り方を実演

この記事で実際に動かしたもの：127.0.0.1 に立てた自作の「天気API」と「イベントAPI」（どちらもモック）を、curl と jq、Node.js のサーバー、Python、Chromium のページから組み合わせ、出力・時間・エラー原文を記録しました。外部のAPIには接続していません。

マッシュアップの全体像を先に図にします。利用者が見るのは1つの画面ですが、裏では別々の提供元のAPIを呼び、結果を1つにまとめています。

flowchart TD
    U[利用者の画面] --> M[マッシュアップ<br>アプリ]
    M --> A[天気API<br>提供元A]
    M --> E[イベントAPI<br>提供元B]
    A --> J[結果を突き合わせる<br>都市コードで対応]
    E --> J
    J --> R[雨なら屋内を先に<br>1つの画面で表示]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB）。Node.js 22.23.4 の標準機能（http・fetch・AbortSignal.timeout・Promise.allSettled）だけで、天気API（127.0.0.1:18215。APIキー必須・10秒に5回まで・応答に300ms）とイベントAPI（127.0.0.1:18216。キー不要・応答に200ms・CORSヘッダーなし）のモックと、2つを組み合わせるマッシュアップのサーバー（127.0.0.1:18217）を作りました。curl 8.5.0 と jq 1.7、Python 3.13.18（標準ライブラリのみ）、Playwright 1.63.0 から起動した Chromium 153 でも同じAPIを呼んでいます。時間は同じマシンで21回測った中央値です。外部のAPIには接続しておらず、APIの利用規約・CORS・Retry-After の記述は各公式ドキュメントで確かめた範囲です。図は mermaid 11 で描画を確かめています（確認日 2026年10月29日）。

マッシュアップとは（Web・音楽での意味）

この節では、マッシュアップという言葉の意味を、ふだんの意味とITでの意味に分けて整理できます。

マッシュアップ（mashup）は、英語の mash up（すりつぶして混ぜ合わせる）から来た言葉で、IT では「複数のWebサービス・ソフトウェア・データベースなどを組み合わせて、新しいサービスを作る手法」を指します。 Webの提供者が外部から呼び出せるように公開しているデータや機能（Web API）を、別の提供者のものと組み合わせるのが典型です。

もとは音楽の言葉で、2つ以上の曲を重ねて再生し、1曲に仕立てる制作手法を指します。2000年代半ばに「Web 2.0」という言葉とともに、Webサービスを組み合わせる意味でも広く使われるようになりました。

音楽のマッシュアップで既存の曲や音源を使う場合は、著作権法の複製権（第21条）・翻案権（第27条。編曲も含む）、音源を作ったレコード製作者の権利（第96条ほか）に関わります。公開する前に、権利者の許諾や配信サービスの規約を確かめます（この記事は法的な助言ではありません）。以下はWeb・ITでの意味に絞って説明します。

最初の5分：2つのAPIを curl と jq でマッシュアップする

この節では、プログラムを書く前に、コマンド2つでマッシュアップの最小形を体験できます。

まず、天気APIとイベントAPIをそれぞれ呼んだ結果です。2つのAPIは提供元が違うという想定なので、都市の表し方（tokyo と TYO）も、時刻の形式（ISO 8601 の文字列と UNIX 時間）も揃っていません。

$ curl -s --noproxy '*' -i -H 'X-API-Key: demo-key-weather' \
    'http://127.0.0.1:18215/v1/weather?city=tokyo'
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=60
X-RateLimit-Limit: 5
X-RateLimit-Remaining: 4

{"city":"tokyo","name":"東京","forecast":"rain","temp_c":17,"pop":80,"updated_at":"2026-10-29T09:00:00+09:00"}

$ curl -s --noproxy '*' 'http://127.0.0.1:18216/events?area=TYO'
{"count":3,"items":[{"id":"e1","area_code":"TYO","title":"屋外マルシェ","indoor":false,"start":1793235600},{"id":"e2","area_code":"TYO","title":"プラネタリウム特別上映","indoor":true,"start":1793239200},{"id":"e3","area_code":"TYO","title":"美術館の夜間開館","indoor":true,"start":1793260800}]}

2つの結果を jq で1つにまとめます。降水確率（pop）が50%以上なら屋内のイベントだけを残す、という小さな決まりを入れました。

$ W=$(curl -s --noproxy '*' -H 'X-API-Key: demo-key-weather' 'http://127.0.0.1:18215/v1/weather?city=tokyo')
$ E=$(curl -s --noproxy '*' 'http://127.0.0.1:18216/events?area=TYO')
$ jq -n --argjson w "$W" --argjson e "$E" \
  '{city:$w.name, forecast:$w.forecast, pop:$w.pop,
    picks:[$e.items[] | select(if $w.pop>=50 then .indoor else true end) | .title]}'
{
  "city": "東京",
  "forecast": "rain",
  "pop": 80,
  "picks": [
    "プラネタリウム特別上映",
    "美術館の夜間開館"
  ]
}

天気APIだけでもイベントAPIだけでも出せなかった「雨の東京で行ける屋内イベント」という答えが、2つを組み合わせて初めて出ました。 これがマッシュアップの芯です。以降の節では、これをアプリにしたときに必要になること（速さ・キー・制限・障害）を1つずつ確かめます。

マッシュアップの3つの型（表示・データ・ロジック）

この節では、マッシュアップを「何を組み合わせるか」で3つに分ける考え方と、それぞれの実物が分かります。

マッシュアップは、組み合わせるものによって次の3つに分けて説明されることがあります。情報処理技術者試験（基本情報技術者試験など）では「ロジックマッシュアップ」の例を選ぶ問題も出ています。ただし、この分類は主に試験の文脈で使われる言葉で、開発の会話で毎日聞くものではありません。

ロジックマッシュアップの実物です。天気APIの出力（降水確率80%）から「屋内」という条件を作り、イベントAPIへの問い合わせに使いました。最初の5分の例（両方を取ってから絞る）と違い、イベントAPIは最初から屋内の2件だけを返します。

$ W=$(curl -s --noproxy '*' -H 'X-API-Key: demo-key-weather' 'http://127.0.0.1:18215/v1/weather?city=tokyo')
$ IN=$(echo "$W" | jq -r 'if .pop>=50 then "true" else "false" end'); echo "indoor=$IN"
indoor=true
$ curl -s --noproxy '*' "http://127.0.0.1:18216/events?area=TYO&indoor=$IN" | jq -c '[.items[].title]'
["プラネタリウム特別上映","美術館の夜間開館"]

ロジックマッシュアップは、Bの呼び出しがAの結果を待つため、後で測る「並列化」ができません。速さと取ってくるデータの量のどちらを優先するかで、データマッシュアップと使い分けます。

マッシュアップの例と、広まった経緯

この節では、マッシュアップのよく知られた例と、言葉が広まった流れが分かります。

マッシュアップの説明で必ず出てくるのは、地図のAPIに別のデータを重ねる例です。地図は自前で用意するのが特に大変なため、2005年に Google マップの API が公開されてから、地図に店舗・物件・天気・写真を重ねるサービスが次々に作られました。

2006〜2008年ごろには、Yahoo! Pipes や Microsoft Popfly のように、部品をつなぐだけでマッシュアップを作れる道具も登場しました（いずれも現在は提供されていません）。今は「マッシュアップ」という言葉を前面に出すサービスは減りましたが、APIを組み合わせてサービスを作るやり方そのものは、Webアプリの標準的な作り方になりました。 決済・地図・認証・メール送信・生成AIを外部のAPIで済ませるアプリは、どれも広い意味のマッシュアップです。

関連記事「REST APIの設計｜URL・ステータスコード・エラー形式の決め方」で扱っています。

作ってみる：天気APIとイベントAPIのマッシュアップ（Node.js）

この節では、モックAPI2つと、それを組み合わせるサーバーの全コードと動かした結果が分かります。

外部のAPIには接続しないため、提供元の違う2つのAPIを自分で用意しました。天気APIは「APIキー必須・10秒に5回まで」、イベントAPIは「キー不要・CORSヘッダーなし」と、性格を変えています。どちらも Node.js の標準モジュールだけで書いています。

// 天気API（モック）: 127.0.0.1:18215  APIキー必須・10秒に5回まで・300ms遅延
import http from 'node:http';
const KEY = 'demo-key-weather';
const DATA = {
  tokyo:  { city: 'tokyo',  name: '東京', forecast: 'rain',  temp_c: 17, pop: 80 },
  osaka:  { city: 'osaka',  name: '大阪', forecast: 'sunny', temp_c: 20, pop: 10 },
  sapporo:{ city: 'sapporo',name: '札幌', forecast: 'cloudy',temp_c: 9,  pop: 30 },
};
const LIMIT = Number(process.env.LIMIT ?? 5), WINDOW = 10_000; let hits = [];
let served = 0;
http.createServer((req, res) => {
  const u = new URL(req.url, 'http://x');
  const send = (code, body, h = {}) => { res.writeHead(code, { 'Content-Type': 'application/json; charset=utf-8', ...h }); res.end(JSON.stringify(body)); };
  if (u.pathname === '/stats') return send(200, { served });
  if (u.pathname !== '/v1/weather') return send(404, { error: 'not_found' });
  if (req.headers['x-api-key'] !== KEY) return send(401, { error: 'invalid_api_key' });
  const now = Date.now(); hits = hits.filter(t => now - t < WINDOW);
  if (hits.length >= LIMIT) {
    const wait = Math.ceil((WINDOW - (now - hits[0])) / 1000);
    return send(429, { error: 'rate_limited' }, { 'Retry-After': String(wait), 'X-RateLimit-Limit': String(LIMIT), 'X-RateLimit-Remaining': '0' });
  }
  hits.push(now); served++;
  const city = (u.searchParams.get('city') || '').toLowerCase();
  const d = DATA[city];
  setTimeout(() => {
    if (!d) return send(404, { error: 'unknown_city', city });
    send(200, { ...d, updated_at: '2026-10-29T09:00:00+09:00' }, {
      'Cache-Control': 'max-age=60', 'X-RateLimit-Limit': String(LIMIT), 'X-RateLimit-Remaining': String(LIMIT - hits.length) });
  }, Number(process.env.DELAY ?? 300));
}).listen(18215, '127.0.0.1', () => console.log('weather-api on 127.0.0.1:18215 pid', process.pid));

// イベントAPI（モック）: 127.0.0.1:18216  キー不要・200ms遅延・CORSヘッダーなし・形式が天気APIと違う
import http from 'node:http';
const EVENTS = [
  { id: 'e1', area_code: 'TYO', title: '屋外マルシェ',       indoor: false, start: 1793235600 },
  { id: 'e2', area_code: 'TYO', title: 'プラネタリウム特別上映', indoor: true,  start: 1793239200 },
  { id: 'e3', area_code: 'TYO', title: '美術館の夜間開館',     indoor: true,  start: 1793260800 },
  { id: 'e4', area_code: 'OSA', title: '河川敷フェス',       indoor: false, start: 1793235600 },
  { id: 'e5', area_code: 'OSA', title: '水族館ナイト',       indoor: true,  start: 1793257200 },
  { id: 'e6', area_code: 'SPK', title: '屋内スケート開放',     indoor: true,  start: 1793242800 },
];
let served = 0;
http.createServer((req, res) => {
  const u = new URL(req.url, 'http://x');
  if (u.pathname === '/stats') { res.writeHead(200, {'Content-Type':'application/json'}); return res.end(JSON.stringify({ served })); }
  if (process.env.BROKEN === 'html') { res.writeHead(502, {'Content-Type':'text/html'}); return res.end('<html><body><h1>502 Bad Gateway</h1></body></html>'); }
  if (u.pathname !== '/events') { res.writeHead(404); return res.end(); }
  served++;
  const area = u.searchParams.get('area');
  const indoor = u.searchParams.get('indoor');
  let items = EVENTS.filter(e => e.area_code === area);
  if (indoor !== null) items = items.filter(e => String(e.indoor) === indoor);
  if (process.env.RENAME === '1') items = items.map(({ title, ...r }) => ({ ...r, name: title }));
  setTimeout(() => { res.writeHead(200, { 'Content-Type': 'application/json; charset=utf-8' }); res.end(JSON.stringify({ count: items.length, items })); },
    Number(process.env.DELAY ?? 200));
}).listen(18216, '127.0.0.1', () => console.log('event-api on 127.0.0.1:18216 pid', process.pid));

2つのAPIの違いを表にしました。実際の外部APIでも、提供元が違えばこの程度の違いは普通にあり、マッシュアップのコードはこの差を吸収する役目を負います。

都市の対応表やタイムゾーンは、間違えてもエラーにならず、違う都市・違う時刻の結果が静かに混ざるのが厄介な点です。対応表に無い値は先に弾く、時刻は必ずタイムゾーンを指定して変換する、という2つを決めておきます。

マッシュアップの本体です。2つのAPIを同時に呼び（Promise.allSettled）、都市名の対応表で結果を突き合わせ、天気で並べ順を決めます。APIキーは環境変数から読み、ブラウザには渡しません。

// マッシュアップ（BFF）: 127.0.0.1:18217  天気API＋イベントAPI を組み合わせて「今日の過ごし方」を返す
import http from 'node:http';
import { readFileSync } from 'node:fs';
const WEATHER = 'http://127.0.0.1:18215/v1/weather';
const EVENTS  = 'http://127.0.0.1:18216/events';
const KEY = process.env.WEATHER_API_KEY;          // キーはサーバー側だけに置く
const AREA = { tokyo: 'TYO', osaka: 'OSA', sapporo: 'SPK' }; // 2つのAPIの「都市の表し方」の対応表
const TTL = Number(process.env.TTL ?? 60_000);
const MODE = process.env.MODE ?? 'parallel';      // parallel | serial
const cache = new Map(); let blockedUntil = 0;

async function getJSON(url, opt = {}) {
  const r = await fetch(url, { ...opt, signal: AbortSignal.timeout(Number(process.env.TIMEOUT ?? 1500)) });
  const text = await r.text();
  if (!r.ok) { const e = new Error(`HTTP ${r.status} ${url.split('?')[0]}`); e.status = r.status; e.retryAfter = r.headers.get('retry-after'); throw e; }
  return JSON.parse(text);
}
async function weather(city) {
  const hit = cache.get(city);
  if (hit && Date.now() - hit.at < TTL) return { ...hit.v, cached: true };
  if (Date.now() < blockedUntil) {   // Retry-After の間は呼ばない
    if (hit) return { ...hit.v, cached: true, stale: true };
    throw Object.assign(new Error('rate limited (waiting Retry-After)'), { status: 429 });
  }
  try {
    const v = await getJSON(`${WEATHER}?city=${encodeURIComponent(city)}`, { headers: { 'X-API-Key': KEY } });
    cache.set(city, { at: Date.now(), v }); return { ...v, cached: false };
  } catch (e) {
    if (e.status === 429) blockedUntil = Date.now() + Number(e.retryAfter ?? 10) * 1000;
    if (hit) return { ...hit.v, cached: true, stale: true };  // 期限切れでも手元の値で返す
    throw e;
  }
}
const events = (city) => getJSON(`${EVENTS}?area=${AREA[city]}`);
const fmt = (unix) => new Date(unix * 1000).toLocaleTimeString('ja-JP', { timeZone: 'Asia/Tokyo', hour: '2-digit', minute: '2-digit' });

async function plan(city) {
  const t0 = performance.now();
  let rw, re;
  if (MODE === 'serial') {
    rw = await weather(city).then(v => ({ status: 'fulfilled', value: v }), e => ({ status: 'rejected', reason: e }));
    re = await events(city).then(v => ({ status: 'fulfilled', value: v }), e => ({ status: 'rejected', reason: e }));
  } else {
    [rw, re] = await Promise.allSettled([weather(city), events(city)]);
  }
  const warnings = [];
  const w = rw.status === 'fulfilled' ? rw.value : (warnings.push(`weather: ${rw.reason.message}`), null);
  const ev = re.status === 'fulfilled' ? re.value : (warnings.push(`events: ${re.reason.message}`), null);
  if (ev?.items?.some(e => typeof e.title !== 'string' || typeof e.start !== 'number'))
    warnings.push('events: unexpected shape (title/start missing)');   // 形の確認
  const rainy = w ? (w.forecast === 'rain' || w.pop >= 50) : null;
  const items = ev?.items?.map(e => ({ title: e.title ?? '(名称なし)', indoor: e.indoor, time: fmt(e.start) }))
    .sort((a, b) => rainy === null ? 0 : (rainy ? b.indoor - a.indoor : a.indoor - b.indoor)) ?? null;
  return {
    city, weather: w && { name: w.name, forecast: w.forecast, temp_c: w.temp_c, pop: w.pop, cached: w.cached, stale: w.stale },
    advice: rainy === null ? '天気が取れないため並べ替えなし' : rainy ? '雨の予報：屋内のイベントを先に表示' : '晴れ・くもり：屋外のイベントを先に表示',
    events: items, warnings, took_ms: Math.round(performance.now() - t0),
  };
}
http.createServer(async (req, res) => {
  const u = new URL(req.url, 'http://x');
  if (u.pathname === '/') { res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' }); return res.end(readFileSync(new URL('./index.html', import.meta.url))); }
  if (u.pathname === '/api/plan') {
    const city = u.searchParams.get('city') ?? 'tokyo';
    if (!AREA[city]) { res.writeHead(400, { 'Content-Type': 'application/json' }); return res.end(JSON.stringify({ error: 'unknown city' })); }
    const body = await plan(city);
    const code = body.weather || body.events ? 200 : 502;
    res.writeHead(code, { 'Content-Type': 'application/json; charset=utf-8' }); return res.end(JSON.stringify(body, null, 1));
  }
  res.writeHead(404); res.end();
}).listen(18217, '127.0.0.1', () => console.log(`mashup on 127.0.0.1:18217 mode=${MODE} pid`, process.pid));

3つを起動して、マッシュアップのAPIを呼んだ結果です。

$ node weather-api.mjs &
weather-api on 127.0.0.1:18215 pid 25212
$ node event-api.mjs &
event-api on 127.0.0.1:18216 pid 25213
$ WEATHER_API_KEY=demo-key-weather node mashup.mjs &
mashup on 127.0.0.1:18217 mode=parallel pid 25214

$ curl -s --noproxy '*' 'http://127.0.0.1:18217/api/plan?city=tokyo'
{
 "city": "tokyo",
 "weather": {
  "name": "東京",
  "forecast": "rain",
  "temp_c": 17,
  "pop": 80,
  "cached": false
 },
 "advice": "雨の予報：屋内のイベントを先に表示",
 "events": [
  { "title": "プラネタリウム特別上映", "indoor": true, "time": "11:00" },
  { "title": "美術館の夜間開館", "indoor": true, "time": "17:00" },
  { "title": "屋外マルシェ", "indoor": false, "time": "10:00" }
 ],
 "warnings": [],
 "took_ms": 364
}

$ curl -s --noproxy '*' -i 'http://127.0.0.1:18217/api/plan?city=nagoya' | head -1
HTTP/1.1 400 Bad Request

UNIX 時間の 1793239200 が日本時間の「11:00」に、TYO と tokyo が同じ都市として扱われています。マッシュアップのコードの多くは、こうした「形の違いを揃える」処理です。 対応表に無い都市（nagoya）は、上流のAPIを呼ぶ前に 400 で返しています。

同じ処理を Python の標準ライブラリだけで書くと次のようになります。2つのAPIはスレッドで同時に呼んでいます。

import json, os, time, urllib.request
from concurrent.futures import ThreadPoolExecutor

KEY = os.environ["WEATHER_API_KEY"]
AREA = {"tokyo": "TYO", "osaka": "OSA", "sapporo": "SPK"}

def get_json(url, headers=None, timeout=1.5):
    req = urllib.request.Request(url, headers=headers or {})
    with urllib.request.urlopen(req, timeout=timeout) as r:
        return json.load(r)

def plan(city):
    t0 = time.perf_counter()
    with ThreadPoolExecutor(max_workers=2) as ex:
        fw = ex.submit(get_json, f"http://127.0.0.1:18215/v1/weather?city={city}", {"X-API-Key": KEY})
        fe = ex.submit(get_json, f"http://127.0.0.1:18216/events?area={AREA[city]}")
        w, e = fw.result(), fe.result()
    rainy = w["forecast"] == "rain" or w["pop"] >= 50
    items = sorted(e["items"], key=lambda x: x["indoor"], reverse=rainy)
    return {"city": w["name"], "rainy": rainy, "events": [x["title"] for x in items],
            "took_ms": round((time.perf_counter() - t0) * 1000)}

print(json.dumps(plan("tokyo"), ensure_ascii=False))

$ WEATHER_API_KEY=demo-key-weather python3 mashup.py
{"city": "東京", "rainy": true, "events": ["プラネタリウム特別上映", "美術館の夜間開館", "屋外マルシェ"], "took_ms": 351}

$ python3 mashup.py      # キーを渡し忘れた場合
KeyError: 'WEATHER_API_KEY'

マッシュアップはブラウザで組むか、サーバーで組むか（CORSとAPIキー）

この節では、ブラウザのJavaScriptから直接2つのAPIを呼ぶ方法と、サーバーで組み合わせる方法の違いが、Chromium での実物で分かります。

マッシュアップのサーバー（127.0.0.1:18217）が返すページに、2つのボタンを置きました。「サーバー経由で取得」は同じオリジンの /api/plan を呼び、「ブラウザから直接」はイベントAPI（127.0.0.1:18216）を直接呼びます。

<!doctype html><meta charset="utf-8"><title>今日の過ごし方（マッシュアップ）</title>
<h1>今日の過ごし方</h1><select id="c"><option>tokyo<option>osaka<option>sapporo</select>
<button id="go">サーバー経由で取得</button><button id="direct">ブラウザから直接2つのAPIを呼ぶ</button>
<p id="w"></p><ul id="ev"></ul><pre id="log"></pre>
<script>
const $ = (s) => document.querySelector(s);
$('#go').onclick = async () => {
  const r = await fetch('/api/plan?city=' + $('#c').value); const d = await r.json();
  $('#w').textContent = d.weather ? `${d.weather.name}：${d.weather.forecast} ${d.weather.temp_c}℃ 降水確率${d.weather.pop}% ／ ${d.advice}` : d.advice;
  $('#ev').innerHTML = ''; for (const e of d.events ?? []) { const li = document.createElement('li'); li.textContent = `${e.time} ${e.title}${e.indoor ? '（屋内）' : '（屋外）'}`; $('#ev').append(li); }
  $('#log').textContent = 'took_ms=' + d.took_ms + ' warnings=' + JSON.stringify(d.warnings);
};
$('#direct').onclick = async () => {
  try { const r = await fetch('http://127.0.0.1:18216/events?area=TYO'); $('#log').textContent = await r.text(); }
  catch (e) { $('#log').textContent = 'events: ' + e.name + ': ' + e.message; }
};
</script>

Playwright から Chromium でページを開き、両方のボタンを押した結果です。

--- tokyo（サーバー経由）
東京：rain 17℃ 降水確率80% ／ 雨の予報：屋内のイベントを先に表示
11:00 プラネタリウム特別上映（屋内）
17:00 美術館の夜間開館（屋内）
10:00 屋外マルシェ（屋外）
took_ms=454 warnings=[]
--- osaka（サーバー経由）
大阪：sunny 20℃ 降水確率10% ／ 晴れ・くもり：屋外のイベントを先に表示
10:00 河川敷フェス（屋外）
16:00 水族館ナイト（屋内）
took_ms=340 warnings=[]
--- ブラウザから直接
events: TypeError: Failed to fetch
[console.error] Access to fetch at 'http://127.0.0.1:18216/events?area=TYO' from origin 'http://127.0.0.1:18217' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
[console.error] Failed to load resource: net::ERR_FAILED
ページのソースに APIキーが含まれるか: false

ポート番号が違うだけでもオリジンは別になります。イベントAPIは Access-Control-Allow-Origin を返さないため、ブラウザはレスポンスをJavaScriptに渡さず、コードに届くのは「Failed to fetch」だけでした。 詳しい理由はコンソールにだけ出ます。一方で、イベントAPI側の受付回数を数えると、このときもリクエストは1回届いていました。CORS は「ブラウザが読ませるかどうか」の仕組みで、サーバーへの到達を止めるものではありません。

関連記事「CORSエラーの原因と解決方法｜エラーメッセージ別に解説」で扱っています。

関連記事「BFF（Backend for Frontend）とは｜構成図とNode.js実装」で扱っています。

マッシュアップの速さ：直列・並列・キャッシュを実測

この節では、2つのAPIを順番に呼ぶか同時に呼ぶか、結果を手元に置くかで、応答時間と上流への呼び出し回数がどれだけ変わるかが分かります。

マッシュアップのサーバーを3つの設定で起動し、/api/plan?city=tokyo を21回ずつ呼んで、サーバー内の処理時間の中央値と、天気APIへの呼び出し回数を数えました（この測定のときだけ、天気APIの回数制限を外しています）。天気APIは300ms、イベントAPIは200msかかる設定です。

serial   ttl=0     server_median=507ms min=504 max=545 client_median=0.506545s
weather calls: 42
parallel ttl=0     server_median=304ms min=302 max=344 client_median=0.304018s
weather calls: 42
parallel ttl=60000 server_median=204ms min=202 max=334 client_median=0.203313s
weather calls: 1

互いに依存しない呼び出しは並列にするだけで約4割速くなり、変わりにくいデータ（天気は60秒ごとに更新という想定）をキャッシュすると上流への呼び出しがほぼ無くなりました。 上流のAPIの回数制限や従量課金を考えると、速さ以上にキャッシュの効果が大きい場面が多くあります。ただし、キャッシュしてよいか・何秒までよいかはAPIの規約で決まっていることがあるため、次の節で確かめます。

利用者が増えたときの上流への呼び出し回数

キャッシュなしのマッシュアップでは、上流への呼び出し回数は「自分のサービスへのリクエスト数 × 組み合わせるAPIの数」になります。今回の42リクエストでも、天気APIに42回・イベントAPIに42回の計84回が流れました。1分に100人が開くページなら、2つのAPIに毎分200回です。天気APIの「10秒に5回」は1分にすると30回までなので、キャッシュが無ければ毎分70回が429になる計算です。

並列化は待ち時間を縮めますが、呼び出し回数は減らしません。回数を減らすのは、キャッシュ、同じ問い合わせをまとめる工夫（同時に来た同じ都市のリクエストを1回の呼び出しで済ませる）、必要な項目だけを取る問い合わせ方です。どれを使えるかは、APIの規約と、データがどのくらいの頻度で変わるかで決まります。

関連記事「JavaScriptのasync/awaitの使い方｜エラー処理と並列実行」で扱っています。

マッシュアップで守るAPIの利用規約とレート制限

この節では、他社のAPIを組み合わせるときに確かめる規約の項目と、回数制限（レート制限）に当たったときの実物が分かります。

マッシュアップは他人のサービスの上に作るため、技術より先に規約を読みます。たとえば OpenStreetMap の標準タイルサーバーの利用ポリシー（Tile Usage Policy）では、地図上の帰属表示を隠さないこと、アプリ固有の User-Agent を送ること、サーバーのキャッシュ指示に従うこと、表示しない範囲の一括ダウンロードやオフライン保存をしないことが定められ、サービスはベストエフォートで保証が無いと書かれています。項目はAPIごとに違いますが、確かめる観点はほぼ共通です。規約のほかに、APIの版（v1・v2）と廃止予定の告知、障害情報を出すステータスページの有無も、長く使えるAPIかを見分ける材料になります。

• 1商用利用・用途の制限無料枠は個人・非商用に限る、特定の用途を禁止する、などの条件がある
• 2回数・料金の上限1秒・1分・1日あたりの回数、従量課金の単価、上限を超えたときの扱い
• 3保存・キャッシュの可否と期間結果を保存してよいか、何秒（何日）までか、Cache-Control に従うか
• 4帰属表示（クレジット）提供元の名前やロゴを画面のどこに出すか。隠してはいけない場合がある
• 5他のAPIのデータとの組み合わせ別の提供元の地図や表示と混ぜることを禁じる規約もある
• 6APIキーの扱いと停止・変更の告知キーの公開禁止、仕様変更や提供終了の告知方法と期間

回数制限に当たると、多くのAPIは HTTP 429 Too Many Requests を返します。天気APIを直接7回続けて呼んだ結果です。

$ for i in 1 2 3 4 5 6 7; do curl -s --noproxy '*' -o /dev/null -w "%{http_code} " \
    -H 'X-API-Key: demo-key-weather' 'http://127.0.0.1:18215/v1/weather?city=osaka'; done
200 200 200 200 200 429 429

$ curl -s --noproxy '*' -i -H 'X-API-Key: demo-key-weather' 'http://127.0.0.1:18215/v1/weather?city=osaka'
HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
Retry-After: 9
X-RateLimit-Limit: 5
X-RateLimit-Remaining: 0

{"error":"rate_limited"}

Retry-After: 9 は「9秒待ってから送ってよい」という意味です（日時で書く形式もあります）。マッシュアップのサーバーは、429 を受けたら Retry-After の間は天気APIを呼ばず、手元に前の値があればそれを返すようにしました。キャッシュを切った（TTL=0）状態で8回続けて呼んだ結果です。

{"n":1,"cached":false,"stale":null,"warnings":[],"took_ms":351}
{"n":2,"cached":false,"stale":null,"warnings":[],"took_ms":317}
{"n":3,"cached":false,"stale":null,"warnings":[],"took_ms":311}
{"n":4,"cached":false,"stale":null,"warnings":[],"took_ms":303}
{"n":5,"cached":false,"stale":null,"warnings":[],"took_ms":306}
{"n":6,"cached":true,"stale":true,"warnings":[],"took_ms":208}
{"n":7,"cached":true,"stale":true,"warnings":[],"took_ms":203}
{"n":8,"cached":true,"stale":true,"warnings":[],"took_ms":203}

# まだ一度も取っていない札幌は、天気なし・イベントだけで返る
{"weather":null,"warnings":["weather: rate limited (waiting Retry-After)"],"events":1}

6回目以降は「少し前の値（stale）」で答え、天気APIには送っていません。最初に書いた版では、Retry-After の待ち時間に入った直後、手元の値を見る前に例外を投げていたため、7回目だけ天気が空になりました。待っている間の分岐でも手元の値を先に見るように直しています。60秒のキャッシュを有効にして100回呼んだときは、100回とも 200 で、天気APIへの呼び出しは1回でした。

関連記事「レート制限の実装アルゴリズム｜6方式を同じ条件で動かして比較」で扱っています。

片方のAPIが止まったときのマッシュアップの作り方

この節では、組み合わせたAPIの1つが止まる・遅い・壊れた応答を返すときに、マッシュアップ全体を止めない作り方が、実際の応答で分かります。

マッシュアップの最大の弱点は、自分では直せない他人のAPIに依存することです。イベントAPIを止めたり、わざと遅くしたりして、マッシュアップのサーバーの応答を記録しました。

# 1. イベントAPIを止めた
{"weather":"rain","advice":"雨の予報：屋内のイベントを先に表示","events":null,"warnings":["events: fetch failed"],"took_ms":324}

# 2. イベントAPIが3秒かかる（タイムアウトは1.5秒）
{"events":null,"warnings":["events: The operation was aborted due to timeout"],"took_ms":1503}

# 3. イベントAPIがHTMLのエラーページ（502）を返す
{"events":null,"warnings":["events: HTTP 502 http://127.0.0.1:18216/events"]}

# 4. イベントAPIが項目名を title から name に変えた
{"events":[{"title":"(名称なし)","indoor":true,"time":"11:00"},{"title":"(名称なし)","indoor":true,"time":"17:00"},{"title":"(名称なし)","indoor":false,"time":"10:00"}],"warnings":[]}

# 5. 天気APIのキーが違う
{"weather":null,"advice":"天気が取れないため並べ替えなし","warnings":["weather: HTTP 401 http://127.0.0.1:18215/v1/weather"]}

# 6. 両方とも止めた
{"city":"osaka","weather":null,"advice":"天気が取れないため並べ替えなし","events":null,
 "warnings":["weather: fetch failed","events: fetch failed"],"took_ms":3}
HTTP 502

Promise.allSettled は、片方が失敗しても両方の結果（成功なら値、失敗なら理由）を待って返します。Promise.all だと1つの失敗で全体が失敗になり、天気が取れているのに画面が空になります。1〜3と5では、取れたほうだけで答え、取れなかった理由を warnings に残せました。 タイムアウトを付けないと、2のような遅いAPIに引きずられて、利用者は3秒以上待たされます。

注意したいのは4です。項目名が変わっても、エラーにならず「(名称なし)」が黙って並びました。warnings も空です。仕様変更は止まるより気づきにくいため、受け取ったデータに必要な項目があるかを確かめる2行を足しました（上の mashup.mjs に入っている「形の確認」の行です）。

  if (ev?.items?.some(e => typeof e.title !== 'string' || typeof e.start !== 'number'))
    warnings.push('events: unexpected shape (title/start missing)');   // 形の確認

# 項目名が name に変わったイベントAPIで、もう一度呼んだ
{"events":[{"title":"(名称なし)","indoor":false,"time":"10:00"},{"title":"(名称なし)","indoor":true,"time":"16:00"}],
 "warnings":["events: unexpected shape (title/start missing)"]}

# 元のイベントAPIに戻した
{"warnings":[]}

今度は warnings に理由が出ました。実際のサービスでは、この警告をログに残して通知し、画面には「イベント名を取得できませんでした」のように出します。項目の数が多いAPIでは、JSON Schema や Zod などの検証ライブラリで受け取る形を決めておくと、確認の漏れが減ります。

1. 1タイムアウトを付けるAbortSignal.timeout(1500) など。待ち時間の上限を自分で決める
2. 2ステータスを見てからJSONとして読むr.ok を確かめる。HTMLのエラーページを JSON.parse しない
3. 3片方の失敗で全体を止めないallSettled で取れたほうだけ返し、warnings に理由を残す
4. 4キャッシュと前の値を使う429 や障害のときは少し前の値で答え、古さを表示する
5. 5データの形を確かめる必要な項目が無ければ警告する。仕様変更に早く気づく

マッシュアップのよくあるエラーとつまずき

この節では、APIを組み合わせるときに出るエラーの原文と、原因・直し方が一覧で分かります。

マッシュアップとWebhook・REST API・BFF・ノーコードの違い

この節では、マッシュアップと一緒に出てくる言葉との関係と、どの記事で何を扱っているかが分かります。

マッシュアップは「複数のサービスを組み合わせて新しいものを作る」という考え方の名前で、特定の技術の名前ではありません。周りの言葉は、その部品や道具にあたります。

ノーコードの道具は、「毎朝天気を取って、雨ならチャットに屋内イベントを送る」のような画面の無い組み合わせを、ブロックをつなぐだけで作れます。今回のように画面に出す・細かい並べ替えや障害時の扱いを決めたい場合はコードで、定期実行や通知が中心なら道具で、と使い分けるのが一般的です。道具を使う場合も、APIの規約・回数制限・キーの置き場所を確かめる点は変わりません。

Webhook は、マッシュアップと組み合わせると呼び出し回数を減らす役にも立ちます。今回の例なら、イベントAPIが「イベントが追加・変更された」ことを Webhook で知らせてくれる場合、マッシュアップ側はイベント一覧を長めにキャッシュしておき、通知が来たときだけ捨てて取り直せます。毎回問い合わせる（ポーリング）より上流の負担が小さく、変更も早く反映されます。通知を受ける側の作り方（署名の検証・再送・二重処理の防止）は、次の記事で扱っています。

関連記事「Webhookとは？実装までわかる｜署名検証・リトライ・冪等性を実行ログで解説」で扱っています。

マッシュアップのメリット・デメリットと判断表

この節では、マッシュアップで作るか、自前で作るかを決めるときの材料が分かります。

何を組み合わせるか決まったら、次の表で作り方を選びます。

マッシュアップのよくある質問

この節では、マッシュアップについてよく聞かれる質問への答えが分かります。

Q. マッシュアップを一言でいうと何ですか？
複数のWebサービスやAPIを組み合わせて、新しいサービスを作ることです。もとは複数の曲を重ねて1曲にする音楽の手法の名前です。

Q. マッシュアップの具体例は？
地図に飲食店や天気を重ねて表示するサービスが代表例です。この記事では、天気APIとイベントAPIを組み合わせ、雨なら屋内イベントを先に出すアプリを作りました。

Q. マッシュアップとAPI連携は同じですか？
ほぼ同じ場面で使われます。API連携はシステム同士のやり取り全般を指し、マッシュアップは組み合わせて新しいサービスを作ることに重きを置いた言い方です。

Q. プログラミングができなくてもマッシュアップは作れますか？
地図などの埋め込み部品をページに貼る、ノーコードの道具でサービスをつなぐ、といった方法なら作れます。画面の細かい動きや障害時の扱いまで決めたい場合はコードが向いています。

Q. ブラウザのJavaScriptだけで作れますか？
APIが CORS を許可していて、キーが不要（またはブラウザ用の公開キー）なら作れます。今回のイベントAPIのように CORS ヘッダーが無いと、リクエストは届いてもブラウザが結果を読ませません。

Q. APIキーはどこに置けばよいですか？
自分のサーバーの環境変数などに置き、ブラウザには組み合わせた結果だけを返します。Git に入れない運用もあわせて決めます。

Q. 429 Too Many Requests が出たらどうしますか？
Retry-After の秒数（または日時）まで待ってから送ります。同じ問い合わせが多いなら、規約の範囲でキャッシュを入れると呼び出し自体が減ります。今回は42回が1回になりました。

Q. APIの結果を保存（キャッシュ）してよいですか？
APIごとの規約で決まります。保存を禁じる、期間を限る、Cache-Control に従うよう求める、などの条件があるため、使う前に確かめます。

Q. マッシュアップしたページが遅いときは、どこから見ますか？
まず各APIを単体で curl して時間を測り、順番に呼んでいないかを確かめます。今回は直列の507msが並列で304ms、キャッシュありで204msになりました。残った時間は、いちばん遅いAPIの応答時間です。

Q. 組み合わせたAPIが提供終了したら？
その機能は使えなくなります。差し替えやすいよう、APIを呼ぶ部分を1か所にまとめ、代わりの提供元を調べておくと影響を小さくできます。

Q. 音楽のマッシュアップを動画サイトに上げてもよいですか？
既存の曲や音源を使う場合、著作権や音源の権利に関わります。権利者の許諾や、投稿先のサービスの規約を確かめてから判断します。

Q. 試験ではどう問われますか？
ITパスポート試験や基本情報技術者試験で、「公開されているWebサービスを組み合わせて新しいサービスを作る手法」を選ぶ問題や、ロジックマッシュアップの例を選ぶ問題が出ています。

まとめ

• マッシュアップとは、複数のWebサービス・APIを組み合わせて新しいサービスを作る手法。もとは複数の曲を重ねる音楽の言葉で、既存曲を使う音楽のマッシュアップには権利の確認が要る。
• 組み合わせ方は表示・データ・ロジックの3つで説明される。データの組み合わせでは、都市コードや時刻の形式を揃える処理がコードの中心になった。
• APIキーが要る・CORS が無いAPIはサーバー側で組む。ブラウザから直接呼ぶと、リクエストは届いても「Failed to fetch」で結果を読めなかった。
• 並列化で507ms→304ms、キャッシュで上流の呼び出しが42回→1回。規約の範囲で呼び出しを減らすことが、速さと回数制限の両方に効く。
• 他人のAPIは止まる・遅れる・形が変わる。タイムアウト、ステータスの確認、allSettled での部分表示、データの形の確認を最初から入れる。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN「Cross-Origin Resource Sharing (CORS)」：https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
• MDN「Retry-After header」：https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After
• MDN「Promise.allSettled()」：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
• MDN「AbortSignal: timeout() static method」：https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout_static
• OpenStreetMap Foundation「Tile Usage Policy」：https://operations.osmfoundation.org/policies/tiles/
• 日本法令外国語訳データベースシステム「著作権法（昭和四十五年法律第四十八号）」：https://www.japaneselawtranslation.go.jp/ja/laws/view/4207
• IT用語辞典 e-Words「マッシュアップ」（情報処理技術者試験の出題履歴）：https://e-words.jp/w/マッシュアップ.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。