イベント駆動とは？イベント駆動アーキテクチャの基本と仕組み解説

イベント駆動とは、システム内で発生した「出来事」をきっかけに処理が動く設計思想です。従来のシステムでは、ある処理が別の処理を直接呼び出し、その結果を待ってから次へ進む同期型の構造がよく使われてきました。一方、イベント駆動では、「ユーザーが登録された」「注文が作成された」「決済が完了した」「ファイルがアップロードされた」といった出来事をイベントとして発行し、そのイベントを受け取った別の処理が必要な作業を実行します。

この考え方では、処理の起点が「命令」ではなく「出来事」になります。たとえば、ECサイトで注文が完了したとき、注文処理が在庫更新、メール送信、売上集計、配送準備をすべて直接呼び出すのではなく、「注文が作成された」というイベントを発行し、それぞれのサービスがそのイベントを受け取って独立して処理します。これにより、サービス同士の依存を減らし、機能追加や変更に強い構造を作りやすくなります。

特に、クラウド環境、マイクロサービス、大規模Webサービス、リアルタイム通知、AIワークフロー、自動化システムでは、イベント駆動アーキテクチャの重要性が高まっています。システムが複雑になるほど、すべての処理を直接つなぐ設計は保守しにくくなります。イベント駆動は、非同期処理、分散処理、疎結合設計を実現するための現代的なアーキテクチャとして、多くの実務システムで活用されています。

1. イベント駆動とは？

イベント駆動とは、システム内で発生したイベントをきっかけに、後続の処理が動く仕組みです。ここでいうイベントとは、「何かが起きた」という事実を表します。ユーザー登録、注文作成、投稿作成、決済完了、在庫更新、ログ出力、エラー発生など、システム内で意味を持つ出来事はすべてイベントとして扱うことができます。

イベント駆動の特徴

1.1 イベントをトリガーに処理が動く仕組み

イベント駆動では、ユーザー操作、データ更新、システム状態変化などをきっかけに処理が開始されます。たとえば、ユーザーが会員登録を完了した場合、「ユーザー登録完了」というイベントが発行されます。そのイベントを受け取ったメール送信処理がウェルカムメールを送り、分析処理が登録データを保存し、通知処理が管理者へ新規登録を知らせるといった流れになります。

重要なのは、イベントを発行する側が、後続でどのような処理が動くかをすべて知る必要がないことです。ユーザー登録処理は「ユーザーが登録された」という事実を発行するだけでよく、メール送信や分析処理を直接呼び出す必要はありません。これにより、後から通知処理や分析処理を追加しても、元の登録処理を大きく変更せずに拡張できます。

ファイル名

src/events/userRegistered.ts

使用言語

TypeScript

type UserRegisteredEvent = {
  eventName: "USER_REGISTERED";
  userId: string;
  email: string;
  registeredAt: string;
};

function publishUserRegistered(userId: string, email: string) {
  const event: UserRegisteredEvent = {
    eventName: "USER_REGISTERED",
    userId,
    email,
    registeredAt: new Date().toISOString(),
  };

  console.log("イベントを発行しました:", event);
}

※ 上記は、ユーザー登録完了という出来事をイベントとして表現するための簡易的なコード例です。実務では、このイベントをメッセージキューやイベント中継基盤へ送信し、通知処理や分析処理などが受け取る形で設計します。

1.2 イベントの定義

イベントとは、「何かが起きた」という事実を表すデータです。命令ではなく、すでに発生した出来事を表現する点が重要です。たとえば、「メールを送信しろ」は命令ですが、「ユーザーが登録された」はイベントです。イベント駆動では、このような事実を中心に後続処理が反応します。

イベントには、イベント名、発生時刻、対象ID、関連データなどが含まれます。たとえば、「注文作成イベント」であれば、注文ID、ユーザーID、商品ID、注文金額、注文時刻などを含めることがあります。イベント設計では、後続処理が必要とする情報を適切に含めることが重要です。ただし、情報を詰め込みすぎるとイベント構造が複雑になるため、必要十分な粒度で設計する必要があります。

ファイル名

src/events/orderCreated.ts

使用言語

TypeScript

type OrderCreatedEvent = {
  eventName: "ORDER_CREATED";
  orderId: string;
  userId: string;
  totalAmount: number;
  createdAt: string;
};

const orderCreatedEvent: OrderCreatedEvent = {
  eventName: "ORDER_CREATED",
  orderId: "order_1001",
  userId: "user_501",
  totalAmount: 9800,
  createdAt: new Date().toISOString(),
};

console.log(orderCreatedEvent);

※ 上記は、注文が作成されたという事実をイベントとして定義する例です。イベントは命令ではなく、すでに発生した出来事を表すため、名前も「ORDER_CREATED」のように過去形の意味を持つ形にすると分かりやすくなります。

2. 従来型との違い

イベント駆動を理解するには、従来の同期型処理との違いを整理することが重要です。同期型では、ある処理が別の処理を直接呼び出し、その結果を待ってから次の処理へ進みます。一方、イベント駆動では、イベントを発行したあと、受信側が非同期で処理を行います。この違いによって、処理の流れ、依存関係、障害時の影響範囲、拡張性が大きく変わります。

同期型とイベント駆動の比較

2.1 同期型

同期型は、処理を直接呼び出し、その結果が返ってくるまで待つ方式です。たとえば、画面からAPIを呼び出し、サーバーが処理を行い、その結果をすぐ画面に返すような構造です。ログイン処理、検索処理、入力チェックのように、ユーザーへすぐ結果を返す必要がある処理では同期型がよく使われます。

同期型のメリットは、処理の流れが分かりやすいことです。呼び出し元が呼び出し先を明確に指定し、結果を受け取って次へ進むため、実装やデバッグが比較的しやすくなります。一方で、呼び出し先が遅い場合や障害を起こしている場合、呼び出し元も影響を受けやすくなります。複数の処理を順番に呼び出す設計では、一つの処理の遅延が全体の遅延につながることがあります。

同期型の特徴

ファイル名

src/sync/createOrderSync.ts

使用言語

TypeScript

async function createOrderSync(orderId: string) {
  await updateInventory(orderId);
  await sendOrderEmail(orderId);
  await recordSales(orderId);

  return {
    message: "注文処理がすべて完了しました",
  };
}

async function updateInventory(orderId: string) {
  console.log("在庫を更新:", orderId);
}

async function sendOrderEmail(orderId: string) {
  console.log("注文メールを送信:", orderId);
}

async function recordSales(orderId: string) {
  console.log("売上を記録:", orderId);
}

※ 上記は、注文作成後に在庫更新、メール送信、売上記録を順番に直接呼び出す同期型の例です。処理の流れは分かりやすい一方で、どれか一つが遅くなると全体の完了も遅くなる構造です。

2.2 イベント駆動

イベント駆動では、イベントが発生したあと、そのイベントを受け取った処理が非同期で動きます。たとえば、注文作成後に「注文作成イベント」を発行し、在庫更新、メール通知、売上集計、配送準備などがそれぞれ独立して処理を進めます。注文作成処理は、すべての後続処理の完了を待たずに、ユーザーへ注文完了を返すことができます。

この方式のメリットは、複数の処理を並列に実行しやすく、サービス同士の依存を減らせることです。後から新しい処理を追加したい場合も、イベントを受け取る新しい処理を追加すればよく、既存の発行側を大きく変更せずに済みます。ただし、処理が非同期になるため、実行順序、処理失敗時の再試行、データ整合性、重複処理対策を丁寧に設計する必要があります。

イベント駆動の特徴

ファイル名

src/event-driven/createOrderEventDriven.ts

使用言語

TypeScript

type OrderCreatedEvent = {
  eventName: "ORDER_CREATED";
  orderId: string;
};

async function createOrderEventDriven(orderId: string) {
  const event: OrderCreatedEvent = {
    eventName: "ORDER_CREATED",
    orderId,
  };

  publishEvent(event);

  return {
    message: "注文を受け付けました",
  };
}

function publishEvent(event: OrderCreatedEvent) {
  console.log("イベントを発行:", event);
}

※ 上記は、注文作成後に後続処理を直接呼び出さず、注文作成イベントだけを発行する例です。実務では、このイベントをメッセージキューやイベント中継基盤へ送信し、在庫更新やメール送信などの処理が独立して受信します。

3. イベント駆動の構造

イベント駆動アーキテクチャは、主にイベント発行側、イベント中継基盤、イベント受信側で構成されます。発行側がイベントを作成し、中継基盤がイベントを届け、受信側がイベントを受け取って処理します。この構造によって、発行側と受信側を直接結びつけずに連携できます。

イベント駆動の基本構造

3.1 イベント発行側

イベント発行側とは、システム内で何らかの出来事が起きたとき、その出来事をイベントとして発行する役割を持つ部分です。たとえば、ユーザー登録処理、注文作成処理、決済完了処理、ファイルアップロード処理などがイベント発行側になります。発行側は「何が起きたか」をイベントとして外部へ知らせます。

イベント発行側の重要な設計ポイントは、後続処理を直接知りすぎないことです。たとえば、注文作成処理が在庫更新、メール送信、売上集計をすべて直接呼び出すと、処理同士の依存が強くなります。一方、注文作成処理は「注文が作成された」というイベントだけを発行し、後続処理はそれを受け取って動くようにすれば、発行側の責務をシンプルに保てます。

ファイル名

src/producers/orderProducer.ts

使用言語

TypeScript

type OrderCreatedEvent = {
  eventName: "ORDER_CREATED";
  orderId: string;
  userId: string;
};

function createOrder(orderId: string, userId: string) {
  console.log("注文を作成:", orderId);

  const event: OrderCreatedEvent = {
    eventName: "ORDER_CREATED",
    orderId,
    userId,
  };

  publish(event);
}

function publish(event: OrderCreatedEvent) {
  console.log("イベント発行側から送信:", event);
}

※ 上記は、注文作成処理がイベント発行側として動く例です。注文作成処理は、在庫更新やメール送信を直接行うのではなく、注文作成イベントを発行する責務だけを持つ形にしています。

3.2 イベント中継基盤

イベント中継基盤とは、発行されたイベントを受け取り、必要な受信側へ届ける仕組みです。代表的な技術として、Kafka、RabbitMQ、AWS EventBridge、Google Pub/Subなどがあります。イベント中継基盤は、イベントを一時的に保持したり、複数の受信側へ配信したり、処理が失敗した場合に再試行したりする役割を持ちます。

この中継基盤があることで、イベント発行側と受信側は直接接続される必要がなくなります。発行側はイベントを送るだけでよく、受信側は自分が必要なイベントを購読して処理します。これにより、新しいサービスを追加しやすくなり、既存システムへの影響を抑えながら機能拡張できます。

ファイル名

src/broker/simpleEventBus.ts

使用言語

TypeScript

type EventHandler = (event: any) => void;

class SimpleEventBus {
  private handlers: Record<string, EventHandler[]> = {};

  subscribe(eventName: string, handler: EventHandler) {
    if (!this.handlers[eventName]) {
      this.handlers[eventName] = [];
    }

    this.handlers[eventName].push(handler);
  }

  publish(eventName: string, event: any) {
    const handlers = this.handlers[eventName] || [];
    handlers.forEach((handler) => handler(event));
  }
}

export const eventBus = new SimpleEventBus();

※ 上記は、イベント中継基盤の考え方を簡単に表したコード例です。実務では、自作の簡易バスではなく、Kafka、RabbitMQ、クラウドのイベント配信サービスなどを利用することが一般的です。

3.3 イベント受信側

イベント受信側とは、イベントを受け取って実際の処理を行う部分です。たとえば、「注文作成イベント」を受け取った在庫管理サービスが在庫を減らし、通知サービスが注文確認メールを送り、分析サービスが売上データを記録するといった形です。それぞれの受信側は、自分に必要なイベントだけを処理します。

イベント受信側は独立して動けるため、処理を分散しやすくなります。たとえば、通知処理が一時的に失敗しても、注文作成処理そのものを止めずに済む場合があります。ただし、受信側では重複処理、失敗時の再試行、処理順序、データ整合性を考慮する必要があります。イベントは一度だけ届くとは限らないため、同じイベントを複数回受け取っても問題が起きない設計が重要です。

ファイル名

src/consumers/orderConsumer.ts

使用言語

TypeScript

import { eventBus } from "../broker/simpleEventBus";

eventBus.subscribe("ORDER_CREATED", async (event) => {
  console.log("注文作成イベントを受信:", event.orderId);

  await updateInventory(event.orderId);
  await sendOrderEmail(event.orderId);
});

async function updateInventory(orderId: string) {
  console.log("在庫更新を実行:", orderId);
}

async function sendOrderEmail(orderId: string) {
  console.log("注文メール送信を実行:", orderId);
}

※ 上記は、イベント受信側が注文作成イベントを受け取り、在庫更新やメール送信を行う例です。実務では、受信側ごとに処理を分け、失敗時の再試行や重複防止も設計します。

4. イベントの流れ

イベント駆動では、ユーザー操作やシステム処理によってイベントが発生し、そのイベントが中継基盤へ送られ、複数のサービスが受け取って処理します。この流れを理解すると、イベント駆動がどのようにシステム全体を動かしているのかが分かりやすくなります。

4.1 ユーザー操作

イベントの起点は、ユーザー操作やシステム状態の変化です。たとえば、ユーザーが会員登録を行う、商品を購入する、投稿を作成する、ファイルをアップロードする、支払いを完了するなどの操作がイベントのきっかけになります。また、ユーザー操作だけでなく、バッチ処理の完了、データ更新、センサー値の変化、ログの発生などもイベントになり得ます。

重要なのは、イベントが「発生した事実」を表すことです。たとえば、「注文を作成してほしい」という要求ではなく、「注文が作成された」という結果がイベントになります。このように、イベントは過去に起きた事実として扱うことで、後続処理がその事実に反応する構造になります。

ファイル名

src/controllers/orderController.ts

使用言語

TypeScript

function handleOrderButtonClick(userId: string, productId: string) {
  const orderId = createOrder(userId, productId);

  const event = {
    eventName: "ORDER_CREATED",
    orderId,
    userId,
    productId,
    createdAt: new Date().toISOString(),
  };

  console.log("ユーザー操作からイベント発生:", event);
}

function createOrder(userId: string, productId: string) {
  console.log("注文作成:", userId, productId);
  return "order_12345";
}

※ 上記は、ユーザーが購入ボタンを押した操作を起点に、注文作成イベントが発生する流れを表した例です。イベント駆動では、ユーザー操作を単なる画面操作として終わらせず、後続処理の起点となる出来事として扱います。

4.2 イベント発行

イベントが発生すると、システムはその内容をイベントデータとして発行します。イベントには、イベント名、発生時刻、対象ID、関連する属性情報などが含まれます。たとえば、「注文作成イベント」なら、注文ID、ユーザーID、注文金額、商品情報、発生時刻などが含まれることがあります。

イベント発行時には、後続処理が必要とする情報をどこまで含めるかが重要になります。情報が少なすぎると、受信側が追加でデータ取得を行う必要があり、処理が複雑になります。一方で、イベントに情報を詰め込みすぎると、イベントの管理が難しくなります。実務では、イベントの粒度やデータ構造を慎重に設計する必要があります。

ファイル名

src/publishers/publishOrderEvent.ts

使用言語

TypeScript

type EventMessage = {
  topic: string;
  payload: Record<string, unknown>;
};

function publishOrderCreated(orderId: string, userId: string) {
  const message: EventMessage = {
    topic: "orders.created",
    payload: {
      orderId,
      userId,
      occurredAt: new Date().toISOString(),
    },
  };

  console.log("メッセージング基盤へ送信:", message);
}

※ 上記は、注文作成イベントをトピックに送信するイメージを表したコード例です。実務では、この送信先がKafka、RabbitMQ、クラウドのイベント配信サービスなどになります。

4.3 各サービスが受信

イベント中継基盤に送られたイベントは、必要なサービスによって受信されます。たとえば、注文作成イベントを、在庫管理サービス、メール通知サービス、売上分析サービス、配送管理サービスがそれぞれ受け取ることがあります。それぞれのサービスは、同じイベントをもとに独立した処理を実行します。

この構造により、処理を追加しやすくなります。たとえば、後から「注文作成時に不正検知を行う処理」を追加したい場合、新しい受信側を作って注文作成イベントを購読すればよいです。既存の注文作成処理を大きく変更せずに機能拡張できる点が、イベント駆動の大きな強みです。

ファイル名

src/consumers/orderSubscribers.ts

使用言語

TypeScript

const subscribers = [
  function inventoryService(event: any) {
    console.log("在庫管理サービスが処理:", event.orderId);
  },
  function notificationService(event: any) {
    console.log("通知サービスが処理:", event.orderId);
  },
  function analyticsService(event: any) {
    console.log("分析サービスが処理:", event.orderId);
  },
];

function receiveOrderCreated(event: any) {
  subscribers.forEach((subscriber) => subscriber(event));
}

receiveOrderCreated({
  eventName: "ORDER_CREATED",
  orderId: "order_12345",
});

※ 上記は、同じ注文作成イベントを複数のサービスが受け取るイメージを表した例です。実務では、各サービスが独立して購読し、必要な処理だけを実行します。

5. イベント駆動のメリット

イベント駆動には、疎結合になりやすい、スケーラブルである、非同期処理によって高速化しやすいというメリットがあります。特に、大規模システムや複数サービスが連携するシステムでは、これらのメリットが大きくなります。

5.1 疎結合になる

イベント駆動の大きなメリットは、サービス同士を疎結合にできることです。疎結合とは、あるサービスが別のサービスに強く依存しすぎない状態を指します。イベント発行側は「何が起きたか」をイベントとして発行するだけでよく、誰がそのイベントを受け取るか、受け取った後に何をするかを詳しく知る必要がありません。

この構造により、機能追加や変更がしやすくなります。たとえば、ユーザー登録時にメール送信だけを行っていたシステムに、後から分析処理や顧客管理連携を追加したい場合、ユーザー登録処理を直接変更せず、新しい受信側を追加できます。サービス同士の依存が少ないほど、変更による影響範囲を抑えやすくなります。

ファイル名

src/examples/looseCoupling.ts

使用言語

TypeScript

function userServiceRegister() {
  console.log("ユーザー登録処理を実行");

  publishEvent({
    eventName: "USER_REGISTERED",
    userId: "user_001",
  });
}

function publishEvent(event: any) {
  console.log("イベントだけを発行:", event);
}

※ 上記は、ユーザー登録処理がメール送信や分析処理を直接呼び出さず、イベントだけを発行する例です。これにより、発行側と受信側の依存を弱め、機能追加時の影響範囲を抑えやすくなります。

5.2 スケーラブル

イベント駆動は、処理を分散しやすいためスケーラブルです。複数の受信側が独立して処理を行うため、特定の処理だけを増強したり、処理量に応じてワーカーを増やしたりできます。たとえば、注文数が増えた場合、メール送信処理や在庫更新処理をそれぞれ独立してスケールできます。

同期型で複数処理を順番に実行する場合、一部の処理が遅いと全体に影響します。一方、イベント駆動では、時間のかかる処理を非同期化し、必要に応じて別の処理基盤で実行できます。アクセス増加や業務量増加に対応しやすい点が、イベント駆動の強みです。

ファイル名

src/workers/orderWorker.ts

使用言語

TypeScript

async function processOrderEvent(event: any) {
  console.log("ワーカーが注文イベントを処理:", event.orderId);
}

async function startWorkers(events: any[]) {
  await Promise.all(
    events.map((event) => processOrderEvent(event))
  );
}

startWorkers([
  { orderId: "order_1" },
  { orderId: "order_2" },
  { orderId: "order_3" },
]);

※ 上記は、複数の注文イベントを並列で処理する簡易例です。実務では、ワーカー数を増やしたり、キューからイベントを取り出して処理したりすることで、処理量の増加に対応します。

5.3 非同期で高速化

イベント駆動では、すぐに完了させる必要がない処理を非同期にできます。たとえば、注文完了後のメール送信、分析データ登録、通知配信、レポート更新などは、ユーザーに即時応答するために必ずしも完了を待つ必要がない場合があります。このような処理をイベント化することで、ユーザーへ返す応答を速くできます。

非同期処理を使うと、ユーザー体験の改善にもつながります。ユーザーがボタンを押したあと、裏側ですべての処理が完了するまで待たされるよりも、重要な処理だけを即時完了させ、残りはバックグラウンドで処理した方が快適です。ただし、非同期処理では失敗時の再試行や処理完了確認の設計が必要になります。

ファイル名

src/examples/asyncResponse.ts

使用言語

TypeScript

async function submitOrder(orderId: string) {
  console.log("注文を保存:", orderId);

  publishEvent({
    eventName: "ORDER_CREATED",
    orderId,
  });

  return {
    status: "accepted",
    message: "注文を受け付けました",
  };
}

function publishEvent(event: any) {
  setTimeout(() => {
    console.log("非同期で後続処理を実行:", event);
  }, 1000);
}

※ 上記は、注文受付を先に完了させ、後続処理を非同期で動かす例です。実務では、ユーザーに即時応答しつつ、通知や分析などをバックグラウンドで処理する設計によく使われます。

6. デメリット

イベント駆動には多くのメリットがありますが、デメリットもあります。システムが複雑になりやすい、デバッグが難しい、データ整合性管理が必要になるといった点です。イベント駆動は便利な設計ですが、すべてのシステムに無条件で適用すべきものではありません。

6.1 システムが複雑になる

イベント駆動では、処理が複数の受信側に分散するため、全体の流れが見えにくくなることがあります。同期型であれば、呼び出し元から呼び出し先へ順番に処理を追えますが、イベント駆動では、あるイベントを誰が受け取り、どの順番で処理し、どの処理が成功したのかを把握するために設計と監視が必要です。

特にイベント数が増えると、どのイベントがどの処理に影響しているのか分かりにくくなります。そのため、イベント名、イベント構造、発行タイミング、受信側、処理結果をドキュメント化し、可観測性を整えることが重要です。イベント駆動は、設計管理を怠ると複雑化しやすいアーキテクチャです。

ファイル名

src/examples/eventMap.ts

使用言語

TypeScript

const eventMap = {
  USER_REGISTERED: ["sendWelcomeEmail", "createUserProfile", "recordSignup"],
  ORDER_CREATED: ["updateInventory", "sendOrderEmail", "recordSales"],
  PAYMENT_FAILED: ["sendPaymentFailureNotice", "recordFailureLog"],
};

console.table(eventMap);

※ 上記は、どのイベントがどの処理につながっているかを整理するための簡易的な例です。実務では、イベント一覧、購読サービス、処理内容、失敗時の対応をドキュメント化しておくことが重要です。

6.2 デバッグが難しい

イベント駆動では、処理が非同期で行われるため、デバッグが難しくなることがあります。同期型であれば、処理の流れを順番に追いやすいですが、イベント駆動では、イベントがいつ発行され、どの受信側が処理し、どこで失敗したかを確認する必要があります。

そのため、ログ記録、トレース、イベントID、相関IDの設計が重要になります。特定のユーザー操作から発生したイベント群を追跡できるようにしておかないと、障害時の原因分析に時間がかかります。イベント駆動を実務で使う場合は、実装だけでなく、運用時に追跡できる仕組みをセットで設計する必要があります。

ファイル名

src/examples/correlationId.ts

使用言語

TypeScript

type EventWithTrace = {
  eventName: string;
  correlationId: string;
  payload: Record<string, unknown>;
};

function publishWithTrace(event: EventWithTrace) {
  console.log(`[${event.correlationId}] イベント発行:`, event.eventName);
}

publishWithTrace({
  eventName: "ORDER_CREATED",
  correlationId: "trace_abc_123",
  payload: {
    orderId: "order_1001",
  },
});

※ 上記は、相関IDをイベントに含めて、処理の流れを追跡しやすくする例です。実務では、ログやトレースにも同じIDを出力し、複数サービスをまたぐ処理を追えるようにします。

6.3 データ整合性管理が必要

イベント駆動では、複数のサービスが非同期で処理を行うため、データ整合性の管理が重要になります。たとえば、注文作成イベントを受けて在庫更新、決済処理、配送準備が別々に動く場合、どれか一つの処理が失敗したときに、全体としてどの状態を正しいとするのかを考える必要があります。

同期型のトランザクションでは、すべて成功したら確定し、失敗したら戻すという設計が比較的分かりやすいです。しかし、イベント駆動では複数処理が時間差で完了するため、最終的に整合性が取れる設計、失敗時の補償処理、再試行、重複処理対策が必要になります。

ファイル名

src/examples/idempotency.ts

使用言語

TypeScript

const processedEventIds = new Set<string>();

function handleOrderCreated(event: { eventId: string; orderId: string }) {
  if (processedEventIds.has(event.eventId)) {
    console.log("処理済みイベントのためスキップ:", event.eventId);
    return;
  }

  processedEventIds.add(event.eventId);
  console.log("注文イベントを処理:", event.orderId);
}

handleOrderCreated({ eventId: "evt_001", orderId: "order_1001" });
handleOrderCreated({ eventId: "evt_001", orderId: "order_1001" });

※ 上記は、同じイベントが複数回届いても二重処理しないための簡易例です。イベント駆動では、再送や重複受信が起こる可能性があるため、冪等性を意識した設計が重要です。

7. よく使われる技術

イベント駆動では、メッセージング基盤やクラウドイベントサービスがよく使われます。代表的なものには、Kafka、RabbitMQ、AWS EventBridge、Google Pub/Subなどがあります。これらは、イベントを受け取り、蓄積し、必要な受信側へ届ける役割を持ちます。

7.1 メッセージング

メッセージングとは、システム間でメッセージやイベントをやり取りする仕組みです。KafkaやRabbitMQは、イベント駆動や非同期処理でよく使われる代表的な技術です。Kafkaは大量のイベントストリーム処理に強く、ログ収集、リアルタイム分析、マイクロサービス連携などで使われます。RabbitMQは、キューを使ったメッセージ配信や非同期ジョブ処理でよく使われます。

メッセージング基盤を使うことで、発行側と受信側を直接つなげずに処理できます。たとえば、あるサービスがイベントをキューへ送信し、別のサービスがそのキューからイベントを取り出して処理します。これにより、受信側が一時的に停止していても、イベントを保持して後から処理できる場合があります。

ファイル名

src/messaging/pseudoQueue.ts

使用言語

TypeScript

const queue: any[] = [];

function sendToQueue(message: any) {
  queue.push(message);
  console.log("キューへ送信:", message);
}

function consumeFromQueue() {
  const message = queue.shift();
  if (!message) return;

  console.log("キューから受信:", message);
}

sendToQueue({ eventName: "ORDER_CREATED", orderId: "order_1001" });
consumeFromQueue();

※ 上記は、メッセージキューの考え方を簡略化したコード例です。実務では、KafkaやRabbitMQなどのメッセージング基盤を使い、イベントの保存、配信、再試行を管理します。

7.2 クラウドサービス

クラウド環境では、AWS EventBridgeやGoogle Pub/Subのようなイベント配信サービスが使われます。これらのサービスを使うと、アプリケーション、クラウドサービス、外部システムのイベントを連携させやすくなります。たとえば、ファイルがアップロードされたら処理を開始する、データ更新をきっかけに通知する、外部システムのイベントを受けてワークフローを動かすといった設計が可能です。

クラウドサービスを使うメリットは、運用負荷を抑えながらイベント駆動を実現しやすいことです。自前でメッセージブローカーを構築・運用する場合、可用性、スケーリング、監視、障害対応を考える必要があります。クラウドのイベントサービスを使えば、これらの一部をマネージドサービスに任せられます。

ファイル名

src/cloud/publishCloudEvent.ts

使用言語

TypeScript

type CloudEvent = {
  source: string;
  detailType: string;
  detail: Record<string, unknown>;
};

function publishCloudEvent(event: CloudEvent) {
  console.log("クラウドイベントとして送信:", event);
}

publishCloudEvent({
  source: "app.orders",
  detailType: "OrderCreated",
  detail: {
    orderId: "order_1001",
    userId: "user_501",
  },
});

※ 上記は、クラウドのイベント配信サービスへイベントを送る考え方を表した簡易例です。実務では、AWS EventBridgeやGoogle Pub/SubなどのSDKを使って送信します。

8. マイクロサービスとの関係

イベント駆動は、マイクロサービスと非常に相性が良い設計です。マイクロサービスでは、機能ごとにサービスを分けるため、サービス間通信が重要になります。すべてを同期APIでつなぐと依存関係が強くなり、障害が連鎖しやすくなる場合があります。イベント駆動を使うことで、サービス間の依存を減らし、柔軟な連携が可能になります。

8.1 サービス間通信に最適

マイクロサービスでは、注文サービス、在庫サービス、決済サービス、通知サービス、分析サービスなどが分かれていることがあります。これらをすべて直接APIで呼び出すと、注文サービスが他のサービスの状態に強く依存してしまいます。どこか一つのサービスが遅いだけで、全体の処理が遅くなる可能性があります。

イベント駆動では、注文サービスが「注文が作成された」というイベントを発行し、他のサービスがそれを受け取って処理します。これにより、注文サービスは後続処理をすべて直接管理する必要がなくなります。サービス間通信を疎結合にできる点が、マイクロサービスでイベント駆動が使われる大きな理由です。

ファイル名

src/microservices/orderService.ts

使用言語

TypeScript

function orderServiceCreateOrder() {
  const orderId = "order_2001";

  console.log("注文サービス: 注文作成", orderId);

  publishEvent({
    eventName: "ORDER_CREATED",
    orderId,
  });
}

function publishEvent(event: any) {
  console.log("他サービス向けにイベント発行:", event);
}

※ 上記は、注文サービスが他サービスを直接呼び出さず、イベントだけを発行する例です。マイクロサービスでは、このようにサービス間の直接依存を減らす設計が重要になります。

8.2 API連携より柔軟

同期API連携は、即時に結果が必要な処理には適していますが、すべての処理に向いているわけではありません。通知送信、分析データ登録、ログ保存、レポート更新のように、少し遅れても問題ない処理は、イベント駆動の方が柔軟に設計できます。

イベント駆動では、後から新しいサービスを追加しやすいという利点があります。たとえば、既存の注文作成イベントに対して、新しくレコメンド更新処理や不正検知処理を追加したい場合、イベントを購読する新しいサービスを作ればよいです。既存APIの呼び出し元を変更しなくても機能を追加できるため、拡張性が高くなります。

ファイル名

src/microservices/addNewSubscriber.ts

使用言語

TypeScript

const subscribers: Record<string, Function[]> = {
  ORDER_CREATED: [],
};

subscribers.ORDER_CREATED.push(function fraudDetection(event: any) {
  console.log("不正検知サービスが追加処理:", event.orderId);
});

function publish(eventName: string, event: any) {
  subscribers[eventName].forEach((handler) => handler(event));
}

publish("ORDER_CREATED", { orderId: "order_3001" });

※ 上記は、既存の注文作成イベントに対して、新しい受信側を追加する例です。発行側を変更せずに機能を増やせる点が、イベント駆動の柔軟性です。

8.3 スケーラブルな設計

マイクロサービスでは、サービスごとに負荷が異なります。通知サービスは一時的に大量処理が必要になるかもしれませんし、分析サービスは大量のイベントを処理する必要があるかもしれません。イベント駆動を使うと、各サービスを独立してスケールさせやすくなります。

たとえば、注文が急増したときに、注文イベントをキューにため、在庫処理や通知処理のワーカーを増やして対応できます。同期型では、呼び出し先が詰まると呼び出し元も影響を受けやすくなりますが、イベント駆動では処理を分散・非同期化できるため、負荷変動に対応しやすくなります。

ファイル名

src/microservices/scalableWorkers.ts

使用言語

TypeScript

const events = Array.from({ length: 5 }, (_, index) => ({
  orderId: `order_${index + 1}`,
}));

async function worker(workerId: number, event: any) {
  console.log(`ワーカー${workerId}が処理:`, event.orderId);
}

events.forEach((event, index) => {
  worker(index + 1, event);
});

※ 上記は、複数ワーカーでイベントを処理する考え方を表した簡易例です。実務では、処理量に応じてワーカー数を増減させることで、負荷の変化に対応します。

9. ユースケース

イベント駆動は、ECサイト、SNS、監視システムなど、さまざまな実務システムで使われます。共通しているのは、ある出来事をきっかけに複数の後続処理が発生する点です。イベント駆動は、このような処理を柔軟かつ拡張しやすく実装するのに向いています。

9.1 ECサイト

ECサイトでは、注文をきっかけに多くの処理が発生します。たとえば、注文が作成されると、在庫更新、決済確認、注文確認メール送信、配送準備、売上集計、ポイント付与、不正検知などが必要になります。これらをすべて注文処理の中で直接実行すると、処理が重くなり、依存関係も複雑になります。

イベント駆動では、「注文作成イベント」を発行し、それぞれのサービスが必要な処理を独立して行います。これにより、注文作成処理をシンプルに保ちつつ、後続処理を増やしやすくなります。将来的に新しい分析処理や通知処理を追加する場合も、イベントを受信する処理を追加するだけで対応しやすくなります。

ファイル名

src/usecases/ecOrderFlow.ts

使用言語

TypeScript

function onOrderCreated(event: any) {
  updateInventory(event.orderId);
  sendEmail(event.orderId);
  recordSales(event.orderId);
}

function updateInventory(orderId: string) {
  console.log("EC: 在庫更新", orderId);
}

function sendEmail(orderId: string) {
  console.log("EC: 注文メール送信", orderId);
}

function recordSales(orderId: string) {
  console.log("EC: 売上記録", orderId);
}

onOrderCreated({ orderId: "order_ec_001" });

※ 上記は、ECサイトで注文作成イベントをきっかけに複数の後続処理が動く例です。実務では、それぞれの処理を別サービスや別ワーカーとして分離することが多くあります。

9.2 SNS

SNSでは、投稿、いいね、コメント、フォロー、シェアなど、さまざまなユーザー行動がイベントになります。たとえば、ユーザーが投稿を作成すると、フォロワーへの通知、タイムライン更新、レコメンド処理、検索インデックス更新、モデレーション処理などが発生します。

イベント駆動を使うことで、投稿処理と後続処理を分離できます。投稿作成はすぐに完了させ、通知やレコメンド更新は非同期で実行できます。これにより、ユーザーは素早く投稿完了を確認でき、裏側では複数の処理が並列に進みます。SNSのように大量の行動イベントが発生するサービスでは、イベント駆動が非常に有効です。

ファイル名

src/usecases/socialPostFlow.ts

使用言語

TypeScript

function createPost(userId: string, content: string) {
  const postId = "post_001";
  console.log("投稿作成:", postId, content);

  publishPostCreated({
    eventName: "POST_CREATED",
    postId,
    userId,
  });
}

function publishPostCreated(event: any) {
  console.log("投稿作成イベントを発行:", event);
}

createPost("user_100", "イベント駆動について投稿しました");

※ 上記は、SNSで投稿作成をイベントとして扱う例です。実務では、このイベントをきっかけに通知、タイムライン更新、推薦処理、検索インデックス更新などが非同期で動きます。

9.3 監視システム

監視システムでも、イベント駆動はよく使われます。ログが出力された、エラーが発生した、CPU使用率がしきい値を超えた、応答時間が悪化したといった出来事をイベントとして扱い、アラート送信、ダッシュボード更新、障害チケット作成、自動復旧処理などを行います。

このような監視システムでは、リアルタイム性が重要です。異常イベントが発生したら、すぐに通知や対応処理が動く必要があります。イベント駆動を使うことで、ログ収集、異常検知、通知、記録、分析を柔軟につなげることができます。

ファイル名

src/usecases/monitoringAlert.ts

使用言語

TypeScript

function detectErrorLog(log: { level: string; message: string }) {
  if (log.level === "error") {
    publishAlertEvent({
      eventName: "ERROR_DETECTED",
      message: log.message,
      occurredAt: new Date().toISOString(),
    });
  }
}

function publishAlertEvent(event: any) {
  console.log("アラートイベントを発行:", event);
}

detectErrorLog({
  level: "error",
  message: "API応答時間が悪化しています",
});

※ 上記は、エラーログを検知してアラートイベントを発行する例です。実務では、アラート通知、障害チケット作成、復旧処理などをイベントに反応して実行します。

10. UXとの関係

イベント駆動は、ユーザーから見えない裏側の設計に見えますが、UXにも大きく関係します。非同期処理を使ってユーザーを待たせない、バックグラウンド処理を分離する、リアルタイム通知を実現するなど、ユーザー体験を高速で自然なものにできます。

10.1 即時反応UIの実現

イベント駆動を使うと、ユーザーに対して素早い反応を返しやすくなります。たとえば、注文完了時に、すべての後続処理が終わるまでユーザーを待たせるのではなく、注文作成が成功した時点で画面に完了表示を出し、その後のメール送信や分析処理は非同期で行うことができます。

このような設計により、ユーザーはシステムが素早く反応していると感じます。UXでは、実際の処理時間だけでなく、ユーザーが待たされていると感じる時間が重要です。イベント駆動は、ユーザーに必要な応答を先に返し、裏側の処理を分離することで、体験速度を高めます。

ファイル名

src/ux/instantResponse.ts

使用言語

TypeScript

async function handleSubmit() {
  console.log("画面: 送信中...");

  const response = await submitMainProcess();

  console.log("画面:", response.message);

  publishBackgroundEvent();
}

async function submitMainProcess() {
  return {
    message: "処理を受け付けました",
  };
}

function publishBackgroundEvent() {
  console.log("裏側で追加処理を開始");
}

handleSubmit();

※ 上記は、ユーザーに対して先に受付完了を返し、後続処理を裏側で動かす例です。実務では、ユーザーを待たせない設計としてイベント駆動が有効です。

10.2 バックグラウンド処理の分離

イベント駆動では、ユーザーが直接待つ必要のない処理をバックグラウンドへ分離できます。たとえば、画像変換、動画エンコード、メール送信、レポート生成、データ同期、レコメンド更新などは、すぐに完了しなくてもよい場合があります。このような処理をイベント化することで、画面操作を軽くできます。

バックグラウンド処理を分離すると、ユーザー操作の流れが止まりにくくなります。たとえば、ファイルをアップロードしたあと、変換処理が完了するまで画面を固めるのではなく、「処理中」と表示しておき、完了したら通知するようなUXが可能です。イベント駆動は、処理の重さをユーザー体験から切り離す設計に役立ちます。

ファイル名

src/ux/backgroundJob.ts

使用言語

TypeScript

function uploadFile(fileName: string) {
  console.log("ファイルを受け付けました:", fileName);

  publishEvent({
    eventName: "FILE_UPLOADED",
    fileName,
  });

  return "アップロードを受け付けました。変換完了後に通知します。";
}

console.log(uploadFile("sample-video.mp4"));

※ 上記は、ファイルアップロード後の重い変換処理をイベント化する例です。実務では、動画変換や画像圧縮などをバックグラウンド処理に分離することで、ユーザー体験を軽くできます。

10.3 ユーザー体験の高速化

イベント駆動は、ユーザー体験の高速化にもつながります。すべての処理を同期的に完了させようとすると、ユーザーは長く待たされる可能性があります。イベント駆動を使えば、重要な処理だけを即時に行い、補助的な処理は非同期で実行できます。

たとえば、SNSの投稿では、投稿本文の保存は即時に行い、通知配信、レコメンド反映、検索インデックス更新は非同期で行うことができます。ユーザーにとって重要なのは、投稿がすぐ完了したと感じることです。イベント駆動は、システム内部の処理を整理し、ユーザーにとって快適な体験を作るための設計でもあります。

ファイル名

src/ux/fastPost.ts

使用言語

TypeScript

function savePost(content: string) {
  const postId = "post_fast_001";

  console.log("投稿を保存:", content);

  publishEvent({
    eventName: "POST_SAVED",
    postId,
  });

  return {
    postId,
    message: "投稿が完了しました",
  };
}

function publishEvent(event: any) {
  console.log("検索反映や通知処理を非同期で開始:", event);
}

console.log(savePost("UXを高速化する設計"));

※ 上記は、投稿保存を即時に完了させ、検索反映や通知配信を非同期で行う例です。ユーザー体験では、待ち時間を短く感じさせる設計が重要になります。

11. AI時代のイベント駆動

AI時代には、イベント駆動の重要性がさらに高まっています。AIエージェント、リアルタイム分析、自動ワークフロー、パーソナライズ処理などでは、何かの出来事をきっかけにAI処理を起動する設計が増えています。イベント駆動は、AIシステムを実務プロセスに組み込むための基盤になります。

11.1 AIエージェントのトリガー構造

AIエージェントは、ユーザー入力、データ更新、通知、スケジュール、外部イベントなどをきっかけに動くことがあります。たとえば、問い合わせが届いたらAIが内容を分類する、商談メモが追加されたらAIが要約する、ログに異常が出たらAIが原因候補を分析するといった処理です。

これらは、イベント駆動と非常に相性が良い設計です。出来事が発生したタイミングでAI処理を起動し、結果を別のシステムへ渡すことができます。AIを単独のチャット機能として使うのではなく、業務イベントに反応する実行システムとして使う場合、イベント駆動の考え方が重要になります。

ファイル名

src/ai/agentTrigger.ts

使用言語

TypeScript

function onSupportTicketCreated(ticket: { id: string; message: string }) {
  publishEvent({
    eventName: "SUPPORT_TICKET_CREATED",
    ticketId: ticket.id,
    message: ticket.message,
  });
}

function publishEvent(event: any) {
  console.log("AIエージェントを起動するイベント:", event);
}

onSupportTicketCreated({
  id: "ticket_001",
  message: "ログインできません",
});

※ 上記は、問い合わせ作成をきっかけにAIエージェント処理を起動するイメージです。実務では、分類、要約、優先度判定、回答候補生成などをイベントに反応して実行できます。

11.2 リアルタイム処理

AI時代には、リアルタイム処理の需要も高まっています。ユーザー行動に応じたレコメンド更新、不正検知、異常検知、パーソナライズUI、チャット応答、動的価格調整などでは、イベントが発生した直後に処理を行う必要があります。

イベント駆動を使えば、データ更新やユーザー行動をすぐに処理基盤へ流し、AIモデルや分析処理に渡すことができます。これにより、ユーザーの最新行動に基づいた体験を提供しやすくなります。リアルタイム性が重要なAIプロダクトでは、イベント駆動がデータ連携の中心になります。

ファイル名

src/ai/realtimeRecommendation.ts

使用言語

TypeScript

function onProductViewed(userId: string, productId: string) {
  const event = {
    eventName: "PRODUCT_VIEWED",
    userId,
    productId,
    occurredAt: new Date().toISOString(),
  };

  console.log("リアルタイム推薦用イベント:", event);
}

onProductViewed("user_501", "product_9001");

※ 上記は、商品閲覧イベントをリアルタイム推薦に使うイメージです。実務では、このような行動イベントをAIモデルや推薦基盤へ送り、ユーザーごとの表示内容を最適化します。

11.3 自動ワークフロー化

イベント駆動は、自動ワークフロー化にも向いています。たとえば、契約書がアップロードされたらAIが内容を要約し、確認タスクを作成し、担当者へ通知する。障害ログが発生したらAIが原因候補を抽出し、チケットを作成し、担当チームへ通知する。このような一連の処理をイベントによってつなげられます。

AIを業務に組み込む場合、重要なのは、AIがいつ動くべきかを設計することです。イベント駆動では、「何かが起きたらAI処理を起動する」という自然な構造を作れます。これにより、AIが単なる補助ツールではなく、業務フローの中で自動的に動く仕組みになります。

ファイル名

src/ai/autoWorkflow.ts

使用言語

TypeScript

function onContractUploaded(fileId: string) {
  const event = {
    eventName: "CONTRACT_UPLOADED",
    fileId,
  };

  summarizeContract(event);
  createReviewTask(event);
  notifyLegalTeam(event);
}

function summarizeContract(event: any) {
  console.log("AIで契約書を要約:", event.fileId);
}

function createReviewTask(event: any) {
  console.log("確認タスクを作成:", event.fileId);
}

function notifyLegalTeam(event: any) {
  console.log("法務担当へ通知:", event.fileId);
}

onContractUploaded("file_contract_001");

※ 上記は、契約書アップロードをきっかけに、AI要約、タスク作成、通知を自動化する例です。実務では、それぞれの処理を独立したサービスとしてイベントでつなげることで、柔軟な業務自動化を実現できます。

12. 本質

イベント駆動の本質は、システムを「命令」ではなく「出来事」で動かすことです。ある処理が別の処理を直接支配するのではなく、発生した事実に対して各処理が反応する構造を作ります。これにより、疎結合で拡張しやすく、スケーラブルなシステムを設計できます。

イベント駆動の本質整理

12.1 「命令」ではなく「出来事」で動く

イベント駆動では、システムは命令ではなく出来事で動きます。従来の設計では、ある処理が別の処理に「これを実行して」と命令する構造になりがちです。一方、イベント駆動では、「注文が作成された」「ユーザーが登録された」「ファイルがアップロードされた」という事実を発行し、それを必要とする処理が反応します。

この違いは、設計思想として非常に重要です。命令中心の設計では、呼び出し元が後続処理を知る必要があります。しかし、出来事中心の設計では、発行側は事実を知らせるだけでよく、受信側が自律的に処理を行います。これにより、システム全体の柔軟性が高まります。

12.2 システムを疎結合にする思想

イベント駆動は、システムを疎結合にするための思想です。サービス同士が直接呼び出し合う構造では、変更や障害の影響が広がりやすくなります。イベントを介して連携すれば、発行側と受信側の依存を減らし、変更に強い構造を作れます。

疎結合な設計は、長期運用で大きな価値を持ちます。サービスが増え、機能が増え、チームが増えるほど、直接依存の多いシステムは変更しにくくなります。イベント駆動は、システムを分割しながらも連携させるための現実的な方法です。

12.3 スケーラブルな分散設計

イベント駆動は、スケーラブルな分散設計を実現しやすいアーキテクチャです。イベントを受け取る処理を複数に分けたり、処理量に応じてワーカーを増やしたりすることで、負荷に対応しやすくなります。特定の処理だけを独立してスケールさせられる点は、大規模システムで重要です。

また、処理を非同期にすることで、ユーザー応答とバックグラウンド処理を分離できます。ユーザーに必要な応答を素早く返し、重い処理は裏側で進める設計が可能になります。イベント駆動は、性能と柔軟性の両方を支える設計です。

12.4 現代クラウドアーキテクチャの基盤

イベント駆動は、現代クラウドアーキテクチャの基盤的な考え方です。クラウドサービスでは、ストレージ更新、データベース変更、API呼び出し、ログ発生、スケジュール実行など、多くの出来事をイベントとして扱えます。これらをきっかけに、関数実行、通知、データ処理、自動復旧などを動かすことができます。

サーバーレス、マイクロサービス、リアルタイムデータ処理、AIワークフローなどは、イベント駆動と非常に相性が良いです。クラウド時代のシステムでは、常に稼働する巨大な処理よりも、イベントに応じて必要な処理を起動する設計が増えています。

12.5 「イベントがシステムを駆動する」

イベント駆動の本質を一言で表すなら、「イベントがシステムを駆動する」ということです。ユーザー行動、データ更新、システム変化、外部連携などの出来事が発生し、それに応じて各処理が動きます。システムは、中央からすべてを命令されるのではなく、イベントを通じて自律的に反応します。

この構造は、変化に強く、拡張しやすく、分散処理に向いています。ただし、設計や運用が不十分だと複雑化しやすいため、イベント設計、ログ記録、トレース、再試行、データ整合性を丁寧に考える必要があります。イベント駆動は、強力であるほど設計力が問われるアーキテクチャです。

おわりに

イベント駆動は、出来事を中心に処理が動くアーキテクチャです。ユーザー登録、注文作成、投稿作成、データ更新、ログ発生などをイベントとして扱い、そのイベントを受け取った処理が非同期に動きます。これにより、サービス同士の依存を減らし、処理を分散し、拡張しやすいシステムを作ることができます。

特に、マイクロサービス、クラウド環境、リアルタイム処理、AIワークフロー、大規模Webサービスでは、イベント駆動の価値が高くなります。同期型の直接呼び出しだけでシステムを構成すると、依存関係が強くなり、変更や障害に弱くなる場合があります。イベント駆動を取り入れることで、システム全体をより柔軟に設計できます。

一方で、イベント駆動には複雑性もあります。処理の流れが見えにくくなり、デバッグやデータ整合性管理が難しくなることがあります。そのため、イベント名、イベント構造、再試行、ログ、トレース、監視をセットで設計することが重要です。イベント駆動の本質は、「命令で動かす」のではなく、「出来事に反応してシステムが動く構造」を作ることにあります。