OCI Functions & API Gatewayサーバーレス実践Vol1 料金と実装ガイド

1. この記事について — 4サービス統合のイベント駆動E2Eと正確な料金比較を軸に

OCI Functions・API Gateway・Events・Notificationsは、それぞれ単体で見ればAWSのLambda・API Gateway・EventBridge・SNSに近い役割を持つサービスですが、4つを組み合わせて初めて、イベント駆動アーキテクチャとしての全体像が見えてきます。本記事は、この4サービスを実際に結線し、動く状態まで構築することを通じて、OCIにおけるサーバーレス実践の勘所を掴んでもらうことを目的としています。

サーバーレスの領域では、AWSとOCIのサービス名が偶然一致していたり、逆にまったく異なる名前でありながら似た役割を担っていたりと、名前だけでは判断できないケースが多く存在します。本記事では、こうした対応関係を各章で個別に整理しながら、最終的に§6で対応表として一覧化します。まずは、本記事全体のゴールと想定読者、そしてなぜ今この構成を扱うのかという背景から見ていきます。

1-1. 本記事のゴール

本記事は、「OCI Functions & API Gatewayサーバーレス実践」シリーズの第1弾として、OCI Functions・API Gateway・Events・Notificationsという4つのサービスを1つの記事の中でイベント駆動アーキテクチャとして結線し、実際に動く状態まで構築することをゴールとしています。

具体的には、API Gatewayが受けたHTTPリクエストをFunctionsが同期的に処理する経路と、Object StorageへのファイルアップロードをきっかけにEventsがFunctionsを起動し、処理結果をNotificationsで通知する非同期経路という、性質の異なる2つの経路を、1つのテナンシ上で同時に動かせる状態を目指します。

多くのハンズオン記事は、1つのサービスを単体で動かして終わりますが、実際のプロダクション環境では、複数のマネージドサービスを組み合わせて初めて意味のあるシステムになります。本記事がAPI Gateway・Functions・Events・Notificationsという4サービスをあえて1本にまとめているのは、この「組み合わせて初めて見える設計判断」を体験してもらうためです。たとえば、同期経路ではAPI GatewayとFunctionsの間のタイムアウト設定の整合性が問題になり、非同期経路ではEventsのルールがどこまで細かくフィルタできるかが設計の分かれ目になります。こうした、単体のドキュメントだけでは気づきにくいポイントも、本記事の中で扱っていきます。

なお、前作「OCI Generative AIサービス実践 Vol1」では、東京(ap-tokyo-1)リージョンが非対応で大阪(ap-osaka-1)リージョンでの実演が必須という制約がありました。本記事が扱う4サービス(API Gateway・Functions・Events・Notifications)は、Generative AIのようなAIモデルホスティングを伴う特殊サービスとは異なり、東京リージョンで実演可能です。

本記事を読み終えると、次の状態になっていることを目指しています。

• API Gateway経由でREST APIを公開し、Functionsで同期的に処理してレスポンスを返す構成を、自分の手で構築できる
• Object Storageへのアップロードをトリガーに、Events経由でFunctionsを起動し、Notificationsで結果を通知する非同期パイプラインを構築できる
• AWSのLambda/API Gateway/EventBridge/SNSの実務経験を踏まえて、OCIでの対応実装における本質的な違いを説明できる

本記事は、次の構成で進みます。§2〜§3で前提環境とアーキテクチャ全体像を整理し、続く§4・§5に同期経路(API Gateway → Functions)と非同期経路(Object Storage → Events → Functions → Notifications)の実装を示します。§6でAWSサービスとの対応表を整理し、§7で料金の正確な内訳、§8で落とし穴と注意点、§9でまとめと次のステップという流れです。前半(§1〜§3)で全体像と前提を押さえ、後半(§4〜§9)で実装と実務上の注意点を扱うという構成になっています。

本記事は「OCI入門」シリーズのような、コンソールの初回セットアップから丁寧に案内する記事ではありません。テナンシ・コンパートメント・基本的なVCNの操作にはすでに慣れており、次のステップとしてサーバーレスの実践的な構成に進みたい読者を想定した、実践レベルの記事として位置づけています。そのため、コンソールの各メニューの場所を1つずつ説明するのではなく、「なぜその設定が必要なのか」「AWSの経験があるとどこでつまずきやすいのか」という判断のポイントに重点を置いて解説します。

また、本記事はあくまで「Vol1」として、4サービスの結線と基本的な動作確認までをスコープとしています。次のようなテーマは本記事のスコープ外とし、読者からの要望を踏まえて続編での取り扱いを検討します。

• 認証・認可の高度な設定(OAuth/JWTバリデーション、カスタム認証Functionsなど)
• 複数リージョンにまたがる高可用性構成・災害復旧設計
• 負荷試験を踏まえたスケーリング設計・同時実行数のチューニング
• OCIRを起点としたCI/CDパイプラインの構築(前述の通り今後公開予定の別記事で扱います)

これらのテーマは、いずれも本記事で構築する4サービスの基本構成が前提となるため、まず本記事でイベント駆動E2E構成の基礎を固めたうえで取り組むことをお勧めします。

1-2. 読者像

本記事は、AWSでLambda・API Gateway・EventBridge・SNSを使ったサーバーレスアーキテクチャの構築・運用経験があり、OCIでの対応実装を実務レベルで知りたいエンジニアを主な読者として想定しています。具体的には、マルチクラウド戦略の一環で自社システムの一部をOCIに移行する検討をしているエンジニア、あるいは顧客からOCI上でのサーバーレス構成の提案を求められたインフラ/クラウドエンジニアなどを想定しています。

いずれのケースでも、「AWSでできていたことが、OCIでも同じようにできるのか」という素朴な疑問が出発点になることが多く、本記事はその疑問に実装レベルで答えることを目指しています。マルチクラウド戦略においては、機能の有無だけでなく、料金体系や運用上の制約の違いを正確に把握することが意思決定の質を左右するため、本記事は実装手順だけでなく、そうした判断材料の提供にも重点を置いています。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIのFunctionsはAWS Lambdaと同じ感覚で使えるのか、それともコンテナベースという点で運用の勘所が変わるのか
• OCIのAPI Gatewayは、名前が同じAWSのAPI Gatewayとどこまで役割が近く、どこが違うのか
• OCIのEventsとNotificationsは、AWSのEventBridgeとSNSにそれぞれ何が対応するのか
• 純粋なAlways Freeテナンシだけで、この記事の内容を最後まで実践できるのか
• API GatewayからFunctionsを呼び出す際、AWSのAPI Gateway統合(Lambda Proxy統合など)に相当する仕組みはOCIにも存在するのか
• Object Storageのイベント通知は、AWSのS3イベント通知(S3 Event Notifications)とどこまで同じ感覚で扱えるのか

なお、本記事は「OCI入門」シリーズでVCN・IAMポリシーの基礎を扱い済みであることを前提としています。VCN・サブネットの基礎自体の再説は行わず、API Gatewayの配置要件など、本記事に固有の範囲のみを扱います。

こうした読者は、多くの場合「まずAWSで動かしてきた構成をそのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。その際、最初につまずきやすいのが、サービス名の類似からくる誤解です。たとえば「API Gateway」という名前はAWSとOCIで共通していますが、実装の思想や課金体系はまったく異なります。また「Events」という名前だけでは、AWSのEventBridgeに相当するのか、それとも別の何かなのかが直感的にわかりません。本記事は、こうした名前の類似に惑わされず、実際の役割と挙動を基準にサービスを理解し直すことを狙いとしています。

なお、本記事はOCIのFunctions・API Gateway・Events・Notificationsを初めて触る読者を想定していますが、OCIそのものが初めての方(テナンシのサインアップすら済んでいない方)は、まず「OCI入門」シリーズVol1(テナンシ・コンパートメント・Always Free枠)から着手することをお勧めします。本記事は、テナンシとコンパートメントの基本的な操作にはすでに慣れていることを前提として進めます。

逆に言えば、OCIの基本操作に慣れてさえいれば、Functions/API Gateway/Events/Notificationsのいずれも本記事が初めての利用であっても問題ありません。これらのサービス固有の概念(Fn Projectベースのコンテナ実行モデル、CloudEvents準拠のイベント形式など)は、本記事の各章で必要な範囲を都度説明します。

1-3. なぜ今これを書くか

本記事を今書く理由は、大きく3つあります。

1つ目は、API Gateway・Functions・Events・Notificationsという4サービスを、単体の機能紹介にとどめず、同期経路と非同期経路の両方を1つのイベント駆動E2E構成として結線して実践する記事が、現時点で他に見当たらないことです。個々のサービスのチュートリアルは存在しても、4サービスを1つのアーキテクチャとして動かし切る記事は稀です。Web検索で見つかる多くの記事は、Functions単体の「Hello World」実行や、API Gateway経由でFunctionsを呼び出すシンプルなAPI(ブログ投稿APIなど)の構築にとどまっており、Object Storageのイベントをトリガーに非同期処理へと連鎖させる構成まで踏み込んだ実例は限られています。本記事は、この「単体では動くが、組み合わせるとどうなるか」という空白を埋めることを目指します。

とりわけ、同期経路(API Gateway → Functions)は比較的多くの記事で扱われている一方、非同期経路(Object Storage → Events → Functions → Notifications)まで含めて1つの記事の中で結線している例は多くありません。Eventsのルール設定とFunctionsの起動条件の組み合わせ方、Notificationsへの結果通知の設計まで一気通貫で扱う点が、本記事の独自性です。

2つ目は、料金情報の正確性です。第三者のブログ記事の中には「API Gatewayは月100万コールまで無料」という情報が出回っていますが、2026年8月2日時点でOracleの公式価格表(apexapps.oracle.com)を確認する限り、API Gatewayに無料の呼び出しレンジは存在せず、$3/百万コールの定額課金がすべてのAPIコールに適用されます。本記事では、こうした誤情報を踏襲せず、一次情報に基づく正確な数値のみを記載します。料金に関する具体的な内訳(サービスごとのAlways Free対象の有無、従量課金の単価)は本記事の§7で改めて詳しく扱いますが、§1・§2の時点でも、Always Freeテナンシだけでは実演できない部分がある旨をあらかじめ明示しておきます。誤った無料枠情報をもとに検証環境を構築してしまうと、想定外の課金が発生した段階になって初めて誤りが判明しかねません。本記事は、実践を始める前の段階でこうした誤解を解消しておくことを重視しています。

3つ目は、シリーズとしての継続性です。本記事は、前作「OCIネットワーク実践(Production編) Vol1」でVCN・ロードバランサー・DRGの本番設計を扱った続きとして、サーバーレス領域での実践シリーズと位置づけています。ネットワークの土台を理解した読者が、次にアプリケーション層のサーバーレスサービスへと進む際の橋渡しとなることを意図しており、両記事に共通して、AWS実務者の視点からOCIサービスの実装レベルの違いを掘り下げるという姿勢を貫いています。

「OCI入門」シリーズが基礎を固める記事群であるのに対し、前作および本記事は、その基礎の上に実践・運用レベルの深さを積み上げる位置づけの記事群です。ネットワーク(前作)の次にサーバーレス(本記事)を扱うのは、実際のシステム構築が「まずネットワークの土台を用意し、その上にアプリケーションロジックを載せる」という順序で進むことが多いためでもあります。

この3つの軸——記事の希少性・料金の正確性・シリーズの継続性——が、本記事を今このタイミングで書く理由です。特に料金の正確性については、読者が実際に課金設定を判断する材料になるため、憶測や伝聞ではなく、公式情報の裏取りを徹底したうえで記載しています。

→ OCIネットワーク実践(Production編) Vol1: Flexible LB/NLB設計とDRGルーティング実装

それでは、次の§2で本記事の前提環境と使用技術スタックを整理したうえで、§3で全体アーキテクチャを俯瞰し、実際の構築に進んでいきましょう。

2. 前提・環境・準備

2-1. 前提環境

本記事の実践には、次の前提が必要です。

• 有効なOCIテナンシと、Functions・API Gateway・Events・Notificationsの各サービスを操作できるIAMポリシーが設定されたユーザーまたはグループ
• Functionsのコンテナイメージを保存するOCIR(Oracle Cloud Infrastructure Registry)へのアクセス権
• API Gatewayを配置するための、リージョナルなパブリックサブネット(プライベートAPIゲートウェイの場合はプライベートサブネットでも可)を含むVCN

これらの前提を、チェックリストの形で整理すると次の通りです。

OCIRへのコンテナイメージpush準備

Functionsのデプロイでは、関数のコードをコンテナイメージとしてビルドし、OCIRへpushする流れになります。事前準備として、OCIのユーザー設定画面で「Auth Token」を発行し、次のようにdockerコマンドでOCIRにログインしておく必要があります。

docker login <リージョンキー>.ocir.io -u <テナンシ名前空間>/<ユーザー名> -p <Auth Token>

リージョンキーは、東京リージョンの場合はnrtです。この準備は、後述するFunctions CLIのセットアップ(fn CLI)とあわせて§4の冒頭で改めて確認します。

Auth Tokenは、発行時のみ表示される値であり、後から再表示できません。発行直後に安全な場所へ控えておく必要があります。

紛失した場合は、古いAuth Tokenを取り消し、新規に発行し直すことで対応します。

コンパートメント設計の考え方

本記事では、ネットワークリソース(VCN・サブネット)とアプリケーションリソース(Functions・API Gateway)を、同一のコンパートメントにまとめる構成を前提とします。本番運用では、ネットワークとアプリケーションのコンパートメントを分離し、IAMポリシーで権限を最小化する構成が一般的ですが、本記事はVol1として構成をシンプルに保ち、コンパートメント分離の設計は今後公開予定のOCIセキュリティ関連記事に委譲します。

これは、AWSでVPCと個々のサービス(Lambda・API Gateway)を別々のAWSアカウントやOU(Organizational Unit)で管理する構成に慣れた読者にとっては、やや大雑把に見えるかもしれません。本記事では、まず4サービスの結線を最短で確認することを優先し、権限分離の設計判断は次のステップとして切り出しています。

API GatewayがFunctionsを呼び出すためのIAMポリシー

API GatewayからFunctionsを同期呼び出しするには、dynamic groupを使ってAPI Gateway自身にIDを持たせ、そのdynamic groupにFunctionsへのアクセス権を付与する必要があります。まず、次のようなmatching ruleでdynamic groupを作成します。

ALL {resource.type = 'ApiGateway', resource.compartment.id = '<API Gatewayのコンパートメントocid>'}

続けて、作成したdynamic groupに対して、Functionsを呼び出す権限を付与するポリシーを作成します。

ALLOW any-user to use functions-family in compartment <Functionsのコンパートメント名> where ALL {request.principal.type = 'ApiGateway', request.resource.compartment.id = '<API Gatewayのコンパートメントocid>'}

このポリシーは、dynamic groupを介した間接的な権限付与ではなく、request.principal.type = 'ApiGateway'という条件で直接API Gatewayからのリクエストを許可する形式です。AWSでLambdaの実行ロールにAPI Gatewayからの呼び出し許可(リソースベースポリシー)を付与してきた読者にとっては、権限の与え方の思想自体は近いものの、OCIではポリシー文がテナンシ共通の1つの構文で記述される点が異なります。

ユーザー/グループがAPI Gatewayリソースを管理するためのIAMポリシー

開発者がコンソールやCLIからAPI Gatewayリソース(ゲートウェイ・デプロイメント)を作成・管理するには、次のようなポリシーが必要です。

Allow group <開発者グループ名> to manage api-gateway-family in compartment <対象コンパートメント名>

FunctionsがOCIリソースにアクセスするためのresource principal

非同期経路では、Functions自身がObject Storageからオブジェクトを読み取ったり、Notificationsにメッセージを発行したりする必要があります。これには、Functions用のdynamic groupを作成し、resource principalを使ってFunctionsに他のOCIリソースへのアクセス権を与えます。resource principalのトークンは15分間キャッシュされるため、ポリシーやdynamic groupを変更した場合、変更が反映されるまで最大15分程度かかる点に注意してください。

本記事で使用するリソース命名規則

本記事の§4以降で作成するリソースは、次の命名規則に統一します。読者が実際に手を動かす際、どのリソースがどの役割を持つか把握しやすくするための工夫です。

【重要・落とし穴】OCIのAlways Free対象リソース一覧には、Functions・API Gatewayのいずれも含まれていません(2026年8月2日時点の公式ドキュメントで確認済み)。したがって、純粋なAlways Freeテナンシのみでは本記事のFunctions/API Gateway部分を実演できず、Pay As You Go(従量課金)への移行、または一定額の課金発生を前提とした環境が必要になります。一方、EventsはSKU自体が存在せず下流サービスの消費分のみが課金対象となり、Notificationsは前述の通りAlways Free対象(HTTPS配信100万件/月・email 1,000件/月)であるため、この2サービス単体であれば追加課金なしで実演できます。

VCN・サブネット要件の詳細

fig02が示す通り、本記事の前提環境は、1つのVCN上にAPI Gateway用のリージョナルサブネットとFunctions用のサブネットを配置し、それぞれにIAMポリシー(dynamic group + resource principal)を紐付ける構成です。API Gatewayを配置するVCNには、次の要件があります。

• サブネットは、可用性ドメイン固有のサブネットではなく、リージョナルサブネットである必要があります(単一可用性ドメインしか持たないリージョンでも、高可用性のためリージョナルサブネットが必須です)
• パブリックにホスト名を公開する場合、DHCPオプションのDNSタイプを「OracleプロビジョニングのInternetおよびVCNリゾルバー」(デフォルト)に設定する必要があります。オンプレミス等、社内限定のホスト名を解決する場合はカスタムリゾルバーの設定が必要です
• バックエンドがパブリックインターネット上にある場合、API GatewayがバックエンドへルーティングできるようVCNにインターネット・ゲートウェイが必要です
• トラフィック制御のため、適切なセキュリティリストまたはネットワーク・セキュリティ・グループ(NSG)の設定が必要です

Functions側にも、独自のサブネット要件があります。Functionsは、アプリケーション作成時に指定したサブネット上で実行されます(サブネットは最大3つまで指定可能です)。パブリックサブネットを指定する場合はVCNにインターネット・ゲートウェイが、プライベートサブネットを指定する場合はサービス・ゲートウェイが必要です。なお、プライベートサブネットを指定しても、Functionsの呼び出しエンドポイント自体へのインターネットからのアクセスが自動的に遮断されるわけではなく、アクセス制御はIAMポリシーで別途行う必要がある点に注意してください。

【落とし穴】DHCPオプションのDNS設定を変更した場合、変更が反映されるまで最大2時間かかることが公式ドキュメントで明示されています。API Gatewayの動作確認時にDNS解決エラーが発生した場合、設定ミスと決めつける前に、この反映遅延の可能性も考慮してください。

AWS実務者向けに、VCN・サブネット要件をAPI Gatewayの前提条件という観点でAWSと対比すると、次のようになります。

本記事は、次の範囲についてはあえて深掘りせず、既存記事・今後公開予定の記事に委譲します。いずれも本記事の§4以降(同一記事内)で扱う範囲ではなく、別記事に委譲する範囲である点をご留意ください。

• VCN・サブネット・ゲートウェイの基礎: 「OCI入門」シリーズVol3を参照してください。本記事ではAPI Gatewayの配置要件(リージョナルサブネットが必須である点など)のみを扱います。
• IAMポリシー・dynamic group・resource principalの基礎: 「OCI入門」シリーズVol2を参照してください。本記事では、Functionsが他のOCIリソースにアクセスするための実例のみを扱います。
• OCIR(コンテナレジストリ)やCI/CDパイプラインの詳細: 今後公開予定のOCI DevOps関連記事に委譲します。本記事では言及にとどめます。
• Logging/Monitoring/アラーム設定: 今後公開予定の可観測性関連記事に委譲します。
• OKE(Kubernetes)との連携: 「OCI入門」シリーズVol6を参照してください。本記事のFunctionsは、OKE上ではなくOCIのマネージドFunctions基盤上で動作させます。

これらの委譲は、本記事のスコープを「4サービスのイベント駆動E2E結線」に絞り込むための判断です。個々の基礎技術の説明に紙幅を割くよりも、4サービスを組み合わせたときに初めて見えてくる設計判断(IAMポリシーの権限境界・ネットワーク到達性・料金構造の組み合わせ)に焦点を当てることを優先しています。

2-2. 使用技術スタック

本記事で使用する4サービスは、いずれもOCIのマネージド型サービスであり、インフラの管理・パッチ適用・スケーリングをOracle側が担う点で共通しています。一方で、各サービスが担う役割(APIの入口・処理の実行・状態変化の検知・結果の通知)は明確に異なります。基盤とバージョンは、次の通りです(2026年8月2日時点の公式ドキュメント準拠)。

なお、Functionsのリクエスト/レスポンスペイロードは最大6MB、Eventsのルールはテナンシあたり50個(上限緩和申請可)という制限があり、本記事で構築する構成はいずれもこの制限内に収まります。

API Gateway: デプロイメントとルートの概念

API Gatewayでは、公開したいAPIの単位を「デプロイメント」として定義します。1つのデプロイメントには、パスベースの複数の「ルート」を定義でき、各ルートに対して、バックエンド(Functions・HTTPバックエンド・スタティックレスポンスのいずれか)を割り当てます。本記事の同期経路では、特定のルートに対してFunctionsバックエンドを割り当てる構成を扱います。AWSのAPI Gatewayにおける「リソース」+「メソッド」の組み合わせに近い概念ですが、OCIではデプロイメント仕様をJSON形式で一括定義する点が特徴です。

Functions: アプリケーションと関数の関係

Functionsは、リージョンレベルのサービスで、VCNのサブネットに「アプリケーション」という単位で紐付きます。1つのアプリケーションは、共通のネットワーク設定(サブネット)と環境変数を複数の関数(Function)で共有する仕組みです。DEV/UAT/PRODのように環境ごとにアプリケーションを分けて関数のコード自体は共通化する構成と、1つのアプリケーション内で環境変数の切り替えによって挙動を変える構成の、いずれかを選択できます。本記事では、Vol1としてシンプルな単一アプリケーション構成を採用します。

Events: フィルタとアクションによるルール構造

Eventsのルールは、「フィルタ」と「アクション」の組み合わせで構成されます。フィルタでは、特定のイベントタイプ(例: Object Storageのcom.oraclecloud.objectstorage.createobject)や、リソースのタグ、属性値を条件として指定できます。アクションでは、条件に一致したイベントの送信先として、Notifications・Streaming・Functionsのいずれかを選択します。本記事の非同期経路では、Object Storageのオブジェクト作成イベントをフィルタし、Functionsをアクション先とするルールを構築します。テナンシあたりのルール数は50個までで、上限緩和はサポートリクエストで申請可能です。

Notifications: トピック・サブスクリプション・配信プロトコル

Notificationsは、「トピック」(通信チャネル)に対して「サブスクリプション」(配信先)を登録する方式で動作します。1つのトピックに複数のサブスクリプションを登録でき、トピックに発行されたメッセージは、有効な全サブスクリプションに配信されます。対応する配信プロトコルと、代表的な配信レート上限は次の通りです。

本記事の非同期経路では、実演のしやすさを優先し、HTTPSまたはemailサブスクリプションでの通知確認を扱います。なお、PublishMessage APIのメッセージサイズ上限は64KB、トピックあたりの発行レート上限は60TPM(メッセージ/分)です。配信に失敗した場合は、即時リトライの後、1分・2分・4分・8分・16分・32分という指数バックオフでリトライされ、既定では2時間でリトライが打ち切られます。

2-3. ゴール状態の定義

本記事における「動作している状態」とは、次の2つの経路がいずれも実際にHTTPリクエストやファイルアップロードをトリガーとして動作し、期待した結果を得られる状態を指します。

• 同期経路: クライアントがAPI Gatewayのエンドポイントに対してHTTPリクエストを送信すると、API GatewayがFunctionsを同期呼び出しし、Functionsの処理結果がHTTPレスポンスとしてクライアントに返る
• 非同期経路: クライアントがObject Storageバケットにファイルをアップロードすると、EventsがObject Storageの状態変化を検知してFunctionsを起動し、Functionsの処理結果をNotifications経由でHTTPSエンドポイントまたはemail宛てに通知する

この2つの状態を、それぞれ次の観点から確認できることをもって「動作している」と判定します。

この2つの状態を、本記事の§4以降で実際に構築しながら確認していきます。§4・§5ではそれぞれの経路の構築手順とあわせて、上記の確認項目をどのように検証するかも扱います。

前提環境の整理はここまでです。IAMポリシー・VCN/サブネット要件・使用技術スタック・ゴール状態の定義という4つの観点を押さえたことで、§4以降で実際にリソースを作成していく準備が整いました。次の§3では、ここまで整理した4サービスが、全体としてどのように連携するのかをアーキテクチャ図に沿って俯瞰します。

3. アーキテクチャ全体像 — 同期経路と非同期経路

本章では、本記事全体で構築する2つの経路を、fig01の全体アーキテクチャ図に沿って整理します。個々の実装手順は本記事の§4(同期経路)・§5(非同期経路)で扱うため、ここでは経路全体の流れと、各サービスが担う役割の分担を先に押さえます。

同期経路: API Gateway → Functions

同期経路は、クライアントからのHTTPリクエストに対して、その場でレスポンスを返す構成です。API Gatewayが受け取ったリクエストを、あらかじめ定義したデプロイメント仕様に基づいてFunctionsへルーティングし、Functionsの処理結果がそのままHTTPレスポンスとしてクライアントに返ります。API GatewayとFunctionsの間の呼び出しは同期的であり、クライアントはFunctionsの処理が完了するまでレスポンスを待つ形になります。この経路の実装は本記事の§4で扱います。

処理の流れをステップに分解すると、次の通りです。

1. クライアントが、API Gatewayのエンドポイントに対してHTTPリクエストを送信する
2. API Gatewayが、リクエストのパスをデプロイメント仕様のルートと照合する
3. マッチしたルートの設定に従い、API GatewayがFunctionsを同期呼び出しする(この呼び出しは、§2で整理したIAMポリシーによって許可されている)
4. Functionsがリクエストを処理し、処理結果を返す
5. API Gatewayが、Functionsからの処理結果をそのままHTTPレスポンスとしてクライアントに返す

非同期経路: Object Storage → Events → Functions → Notifications

非同期経路は、Object Storageへのファイルアップロードをきっかけに、複数のサービスを経由して最終的にNotificationsで結果を通知する構成です。Object Storageでオブジェクトが作成されると、Eventsサービスがその状態変化を検知し、あらかじめ定義したルール(フィルタ+アクション)に基づいてFunctionsを起動します。Functionsの処理が完了すると、その結果をNotificationsのトピックに発行し、Notificationsが購読者(HTTPSエンドポイントまたはemail)に通知を配信します。クライアントはアップロード時点で処理を終えるため、Functions・Notificationsの処理完了を待つ必要はありません。この経路の実装は本記事の§5で扱います。

処理の流れをステップに分解すると、次の通りです。

1. クライアントが、Object Storageバケットにファイルをアップロードする
2. Object Storageが、オブジェクト作成イベント(CloudEvents準拠)を発行する
3. Eventsサービスが、あらかじめ定義したルールのフィルタ条件とイベントを照合する
4. 条件に一致した場合、Eventsがアクション先として設定されたFunctionsを起動する(この起動は、§2で整理したFunctions用dynamic groupのIAMポリシーによって許可されている)
5. Functionsが処理を実行し、結果をNotificationsのトピックに発行する
6. Notificationsが、トピック配下の購読者(HTTPSエンドポイントまたはemail)に通知を配信する

2つの経路の役割分担

同期経路と非同期経路は、Functionsを処理の中核に据える点は共通していますが、呼び出しのトリガーと応答のタイミングが異なります。同期経路はクライアントからの明示的なリクエストに応じて即座に処理・応答するのに対し、非同期経路はリソースの状態変化(ファイルアップロード)をきっかけに、クライアントの応答を待たずにバックグラウンドで処理が進みます。この違いは、AWSでLambdaを同期呼び出し(API Gateway統合)・非同期呼び出し(S3イベント通知経由)の両方で使い分けてきた読者にとっては馴染みのある区別です。本記事の§6では、この2経路とAWSサービスとの対応関係を改めて整理します。

この表が示す通り、非同期経路は関与するサービス数が多い分、エラー発生時の切り分けにログの確認がより重要になります。この点は本記事の§8(落とし穴と注意点)で改めて扱います。

4. 同期経路実装: API Gateway → Functions

本章では、§3で整理した同期経路(API Gateway → Functions)を、実際に手を動かして構築します。大きく分けて、(1) Functionsのセットアップとデプロイ、(2) API Gatewayの作成とルーティング設定、(3) 動作確認、という3つのステップで進めます。

4-1. Functions CLI(fn CLI)のセットアップ

§2で準備したOCIRへのdockerログインに加えて、Functions CLI(fn CLI)にOCIのコンテキストを設定します。ローカル端末にすでにfn CLIがインストールされている前提で、次のようにコンテキストを作成・切り替えます。

fn create context oci-functions-apigw-vol1 --provider oracle
fn use context oci-functions-apigw-vol1
fn update context oracle.compartment-id <コンパートメントOCID>
fn update context api-url https://functions.ap-tokyo-1.oci.oraclecloud.com
fn update context registry <リージョンキー>.ocir.io/<テナンシ名前空間>/<リポジトリ名>

東京リージョンのAPIエンドポイントとリージョンキー(nrt)を指定する点がポイントです。コンテキストの設定後、fn list appsを実行してエラーなくレスポンスが返れば、IAMポリシーとコンテキスト設定が正しく機能しています。

続けて、Functionsアプリケーションを作成します。アプリケーションには、§2-1で確認したリージョナルサブネットを指定します。

fn create app oci-functions-apigw-vol1-app --annotation oracle.com/oci/subnetIds='["<サブネットOCID>"]'

4-2. 関数(Function)の作成とデプロイ

同期経路で使う関数を、Python(またはNode.js)のboilerplateから作成します。

fn init --runtime python sync-handler
cd sync-handler

生成されたfunc.pyを、リクエストボディのJSONを受け取り、簡単な加工結果を返すロジックに書き換えます。処理内容自体は本記事のスコープの中心ではないため、ここでは「リクエストで受け取ったnameパラメータを使って挨拶文を返す」程度のシンプルな実装とします。実装後、次のコマンドで、コンテナイメージをビルドしOCIRへpushしたうえで、Functionsへ自動的にデプロイします。

fn deploy --app oci-functions-apigw-vol1-app

デプロイが成功すると、fn invoke oci-functions-apigw-vol1-app sync-handlerのようにCLIから直接関数を呼び出して動作確認ができます。この時点でAPI Gatewayを経由せずFunctions単体の動作を確認しておくと、後続のトラブルシューティングの切り分けが楽になります。

4-3. API Gatewayの作成(public/privateサブネット要件)

API Gatewayを作成する際、最初に決めるのはゲートウェイタイプ(パブリック/プライベート)です。§2-1で整理した通り、この選択はVCNのサブネット要件に直結します。

本記事では、動作確認のしやすさを優先し、パブリックゲートウェイを採用します。プライベートゲートウェイを選択する場合、追加でプライベートエンドポイントへの到達経路(VCNピアリングやFastConnect)を用意する必要があるため、社内システムからのみアクセスさせたい本番構成でなければ、まずパブリックゲートウェイから始めることをお勧めします。

oci api-gateway gateway create \
  --compartment-id <コンパートメントOCID> \
  --display-name oci-functions-apigw-vol1-gateway \
  --endpoint-type PUBLIC \
  --subnet-id <パブリックサブネットOCID>

ゲートウェイの作成には数分かかります。ステータスがACTIVEになったことを確認してから次のステップに進みます。

4-4. デプロイメントとルートの作成

ゲートウェイがACTIVEになったら、デプロイメント仕様をJSONで定義します。パス/greetに対するGETリクエストを、§4-2で作成したsync-handler関数にルーティングする最小構成は次の通りです。

{
  "routes": [
 {
"path": "/greet",
"methods": ["GET"],
"backend": {
  "type": "ORACLE_FUNCTIONS_BACKEND",
  "functionId": "<sync-handler関数のOCID>"
}
 }
  ]
}

このJSONをdeployment.jsonとして保存し、次のコマンドでデプロイメントを作成します。

oci api-gateway deployment create \
  --compartment-id <コンパートメントOCID> \
  --gateway-id <ゲートウェイOCID> \
  --path-prefix /v1 \
  --display-name oci-functions-apigw-vol1-deployment \
  --specification file://deployment.json

--path-prefixで指定した/v1と、ルート側の/greetが連結され、最終的なエンドポイントはhttps://<ゲートウェイのホスト名>/v1/greetになります。デプロイメントの作成が完了すると、§2-1で整理したIAMポリシー(dynamic group経由でのFunctions呼び出し許可)がここで初めて実際に使われる形になります。

4-5. 動作確認

デプロイメントがACTIVEになったら、curlでエンドポイントを直接叩いて動作確認します。

curl "https://<ゲートウェイのホスト名>/v1/greet?name=World"

期待通りのレスポンスが200系ステータスで返れば、同期経路は動作しています。もし404や502が返る場合、次の順序で切り分けます。

1. oci api-gateway deployment getでデプロイメントのライフサイクル状態がACTIVEか確認する
2. Functionsのロギングを有効化している場合、関数側にリクエストが到達しているかログで確認する(到達していなければAPI Gateway側のルート設定かIAMポリシーの問題)
3. 関数が起動しているがエラーを返している場合、関数のコード自体の問題(到達しているためIAMポリシーは問題なし)

AWSでAPI Gateway + Lambda統合のデバッグ経験がある読者にとっては、この「まずゲートウェイ側の到達を確認し、次にバックエンド側のログを見る」という切り分けの流れ自体は馴染みのあるものです。

5. 非同期経路実装: Object Storage → Events → Functions → Notifications

本章では、§3で整理した非同期経路(Object Storage → Events → Functions → Notifications)を構築します。同期経路とは異なり、リソースを作成する順序が結果に影響します。具体的には、Eventsルールがアクション先として参照するNotificationsトピックとFunctionsを先に用意しておく必要があるため、(1) Notificationsトピックの作成、(2) 非同期処理用Functionの作成、(3) Object Storageバケットの作成、(4) Eventsルールの作成、(5) 動作確認、という順序で進めます。

5-1. Notificationsトピックとサブスクリプションの作成

まず、非同期処理の結果を通知するためのNotificationsトピックを作成します。

oci ons topic create \
  --compartment-id <コンパートメントOCID> \
  --name oci-functions-apigw-vol1-topic

作成したトピックに対して、通知の受け取り先(サブスクリプション)を登録します。本記事では、実演のしやすさを優先し、emailサブスクリプションを例に進めます。

oci ons subscription create \
  --compartment-id <コンパートメントOCID> \
  --topic-id <トピックOCID> \
  --protocol EMAIL \
  --subscription-endpoint <通知先メールアドレス>

emailサブスクリプションは、作成直後はPENDING状態です。登録したメールアドレス宛てに確認メールが届くので、メール内のリンクをクリックしてACTIVE状態に変更しておく必要があります。この確認を忘れると、後続のテストで「Functionsは正常に完了しているのに通知が届かない」という状態になり、原因の切り分けに時間がかかるため、先に済ませておきます。

5-2. 非同期処理用Functionの作成

次に、Object Storageのイベントを受け取り、Notificationsへ結果を発行する関数を作成します。§4-1で作成したFunctionsアプリケーションに、新しい関数として追加します。

fn init --runtime python async-handler
cd async-handler

この関数の実装では、次の2点が同期経路の関数と異なります。

• 受け取るペイロードが、API Gatewayからのリクエストボディではなく、CloudEvents準拠のイベント本文(Object Storageのバケット名・オブジェクト名などを含む)である点
• 処理結果をHTTPレスポンスとして返すのではなく、oci.onsのPublishMessage APIを呼び出してNotificationsトピックに発行する点

関数内でOCI SDKを使ってPublishMessage APIを呼び出す際は、resource principalを使った認証を利用することで、Auth Configファイルを関数内へ埋め込まずに済みます。§2-1で整理したFunctions用dynamic groupのIAMポリシーが、ここで実際に使われます。実装後、§4-2と同様にfn deployでデプロイします。

fn deploy --app oci-functions-apigw-vol1-app

5-3. Object Storageバケットの作成

非同期経路のトリガーとなるバケットを作成します。

oci os bucket create \
  --compartment-id <コンパートメントOCID> \
  --name oci-functions-apigw-vol1-bucket

バケット自体にはイベント発行の可否を示す設定はなく、Object Storageは常にオブジェクトの作成・更新・削除イベントを発行します。どのイベントをどう処理するかは、次のEventsルール側で制御します。

5-4. Eventsルールの作成

Object Storageへのオブジェクト作成をフィルタし、§5-2で作成した非同期処理用Functionをアクション先とするルールを作成します。

{
  "eventType": ["com.oraclecloud.objectstorage.createobject"],
  "data": {
 "additionalDetails": {
"bucketName": ["oci-functions-apigw-vol1-bucket"]
 }
  }
}

oci events rule create \
  --compartment-id <コンパートメントOCID> \
  --display-name oci-functions-apigw-vol1-rule \
  --is-enabled true \
  --condition file://filter.json \
  --actions '{"actions":[{"actionType":"FAAS","isEnabled":true,"functionId":"<async-handler関数のOCID>"}]}'

このルールが機能するには、§2-1で整理したFunctions用dynamic groupに対して、Eventsサービスからの関数起動を許可するポリシーが別途必要です。dynamic groupのmatching ruleにresource.type = 'fnfunc'を含め、ALLOW any-user to use functions-family in compartment <コンパートメント名> where ALL {request.principal.type = 'cloudevents-rule'}のようなポリシーを追加しておきます。

5-5. 動作確認

EventsルールがACTIVEになったら、実際にファイルをバケットへアップロードして一連の流れを確認します。

oci os object put \
  --bucket-name oci-functions-apigw-vol1-bucket \
  --file ./sample.txt \
  --name sample.txt

アップロード後、次の順序で各サービスのログを確認します。

1. Eventsのルールがマッチしたかは、直接のログ画面はないため、後続のFunctionsが起動したかどうかで間接的に判断します
2. Functionsのロギングで、async-handler関数が起動し、処理が完了しているかを確認します
3. §5-1で登録したメールアドレスに、Notifications経由の通知メールが届いているかを確認します

同期経路とは異なり、この経路ではクライアント側(アップロードを行った端末)には成功・失敗の情報が返らないため、必ずログとNotificationsの到達確認で動作を判定する必要があります。この点は§8で改めて注意点として整理します。

6. AWS実務者向け対応表

ここまで§4・§5で実際に構築した内容を踏まえ、AWSの4サービスとOCIの4サービスの対応関係を整理します。§1・§3で予告した通り、「名前が似ている=仕組みも同じ」とは限らない点に注意しながら見ていきます。

この4組の対応関係のうち、実務上もっとも誤解が生じやすいのはAPI Gatewayです。「AWSでAPI Gatewayを使ってきたから、OCIのAPI Gatewayも同じ感覚で使える」という思い込みで設計を始めると、§4で見たVCNサブネット要件や、後述する料金体系の違いでつまずくことになります。逆に、名前がまったく異なるEvents↔EventBridgeやNotifications↔SNSは、名前から役割を推測しにくい分、かえって「別物として理解しよう」という心構えで臨みやすいとも言えます。

Fn Projectがオープンソースであるという点も、実務上見落とされがちなポイントです。OCI FunctionsはFn Projectのマネージドホスティングという位置づけであるため、原理的には同じFn Project基盤をオンプレミスやKubernetes上(OKE含む)で自前運用できます。AWS Lambdaにはこうしたオープンソース基盤への直接的な対応物はなく、マルチクラウド/ハイブリッド戦略における可搬性という観点では、OCI Functionsの方に選択肢の幅があると言えます。

7. 料金の正確性 — 公式価格表準拠

§1で予告した通り、本章では4サービスの料金を、Oracleの公式価格表(apexapps.oracle.com、2026年8月2日取得)に基づいて正確に整理します。特にAPI Gatewayについては、第三者ブログで出回っている情報と公式価格表の記載が食い違っているため、丁寧に確認していきます。

7-1. API Gateway: 無料レンジは存在しない

API Gatewayの料金は、APIコール数に応じた完全な従量課金であり、無料で処理できるコール数の枠(free range)は存在しません。公式価格表準拠の単価は、次の通りです。

Web検索で「OCI API Gateway 月100万コールまで無料」という趣旨の情報を見かけることがありますが、2026年8月2日時点の公式価格表を確認する限り、この情報は誤りです。この誤情報の出所が定かではありませんが、他社クラウドの無料枠や別製品の料金体系との混同が原因と考えられます。本記事が扱うOCIネイティブの「API Gateway」サービスには、そうした無料コール枠は用意されていません。少量のテストコールであっても課金対象になる点を、実演を始める前に押さえておいてください。

7-2. Functions: 無料枠あり(2M回 + 400,000 GB-sec/月)

Functionsは、月次で次の無料枠を持っています。

AWS Lambdaの無料枠(月100万リクエスト+40万GB-秒)と比較すると、呼び出し回数の無料枠はOCI Functionsの方が大きく設定されています。本記事のVol1で構築する規模のハンズオン(動作確認レベルの呼び出し回数)であれば、Functions単体の課金は無料枠内に収まる可能性が高いです。

7-3. Events: 課金SKU自体が存在しない

Eventsサービスには、単体の課金SKUがありません。ルールの作成数やイベントのマッチ回数そのものには課金が発生せず、Eventsルールがアクション先として起動する下流サービス(本記事ではFunctions)の消費分のみが課金対象になります。したがって、Eventsルールを増やすこと自体のコストは、テナンシあたり50個という上限緩和申請可能な件数制限(§2-2参照)以外、料金面での制約はありません。

7-4. Notifications: Always Free対象

Notificationsは、Always Free対象のサービスです。

本記事の非同期経路で構築する規模の通知量であれば、Notifications単体の課金は発生しません。§2-2で触れたPublishMessage APIのメッセージサイズ上限(64KB)や発行レート上限(60TPM)は、料金とは別の制約である点に注意してください。

7-5. 本記事の構成全体での費用感

以上を踏まえると、本記事で構築する構成全体の費用感は、次のようにまとめられます。

• Object Storage・Events・Notificationsは、いずれもAlways Free対象または課金SKUなしのため、本記事のハンズオン規模では追加課金がほぼ発生しません
• Functionsは無料枠が大きいため、動作確認レベルの呼び出し回数であれば無料枠内に収まる可能性が高いです
• API Gatewayのみ、無料レンジが存在しないため、デプロイメントを作成してテストコールを送信した時点で、少額(1回あたり$0.000003)の課金が確定します

この費用構造は、§8で扱う「純粋なAlways Freeテナンシでの実演可否」に直結します。Always Freeテナンシのままではクレジットカード登録も従量課金も有効化されていないため、API Gateway部分の課金が発生した時点で処理が失敗します。実演にあたっては、Pay As You Goへの移行、または一定の課金発生を許容できる環境を事前に用意しておく必要があります。

8. 落とし穴と注意点

本章では、ここまで各章で触れた注意点を、つまずきやすい順に整理し直します。

8-1. 純粋なAlways Freeテナンシでは最後まで実演できない公算が高い

§7で見た通り、API Gatewayは無料レンジが存在しないため、Always Freeテナンシのままではデプロイメントを作成しテストコールを送信した時点で課金が発生し、Pay As You Goへの移行(またはクレジットカード登録による従量課金の有効化)をしていない環境では処理が失敗します。本記事へ着手する前に、テナンシの課金設定(Always Free専用か、Pay As You Goに移行済みか)を確認しておくことを強くお勧めします。Functions・Events・Notificationsだけであれば無料枠内に収まる可能性が高い一方、API Gatewayを含む同期経路(§4)全体を最後まで動かすには、課金設定の見直しが実質的に必須です。

8-2. Functionsのコールドスタート

Functionsはコンテナベースのため、しばらく呼び出されていない関数を初めて呼び出す際、コンテナの起動(コールドスタート)によるレイテンシが発生します。AWS Lambdaでも同様の現象は見られます。OCI Functionsはコンテナイメージ全体をpullしてから起動するアーキテクチャのため、イメージサイズが大きいほどコールドスタートの影響は大きくなる傾向です。§4-2・§5-2で作成する関数のベースイメージを必要最小限に保つ(不要な依存パッケージを含めない)ことが、レイテンシを抑える基本的な対策です。同期経路(§4)では、このレイテンシがそのままクライアントの体感待ち時間になるため、特に注意が必要です。

8-3. API GatewayのVCNサブネット要件

§4-3で扱った通り、API Gatewayのゲートウェイタイプ(パブリック/プライベート)は、配置先のVCNサブネットタイプと直結しています。既存のVCNを流用しようとした際、想定していたサブネットがリージョナルサブネットではなく可用性ドメイン固有のサブネットだった、あるいはインターネット・ゲートウェイが設定されていなかった、というケースでゲートウェイの作成やデプロイメントの動作確認に失敗することがあります。§2-1のVCN・サブネット要件チェックリストを、着手前に必ず再確認してください。また、DHCPオプションのDNS設定を変更した直後は、最大2時間の反映遅延がある点も、§2-1で触れた通り見落としやすいポイントです。

8-4. Events「Event Hub」との名称混同

§5-4で扱った通り、本記事のOCI Eventsサービスと、2023年5月31日にEOLとなった「Event Hub Cloud Service」(Event Hub Classic)は完全な別サービスです。Web検索でOCIの「Events」を調べる際、廃止済みのEvent Hub関連ドキュメントや、後継サービスであるOCI Streamingの情報が混ざって出てくることがあります。本記事のEventsルール(§5-4)は、CloudEvents準拠のリソース状態変化通知を扱うものであり、Kafka互換のストリーミングメッセージングとは目的が異なるため、参照するドキュメントのサービス名を都度確認してください。

8-5. 非同期経路のエラーはクライアントに伝わらない

§3・§5-5でも触れた通り、非同期経路(Object Storage → Events → Functions → Notifications)は、クライアントがファイルをアップロードした時点で処理が完了したように見えますが、実際の処理結果(成功・失敗)はクライアントには返りません。Eventsのフィルタ条件の誤り、Functionsの実行エラー、Notificationsの配信失敗のいずれが起きても、アップロードを行った端末側からは正常に見えてしまいます。動作確認の際は、必ずFunctionsのログとNotificationsの到達状況の両方を確認する運用を徹底してください。本番運用では、これらのログをMonitoringのアラームと連携させることが望ましいですが、アラーム設定自体は§2-1で述べた通り今後公開予定の可観測性関連記事のスコープとしています。

9. まとめと次のステップ

本記事では、OCI Functions・API Gateway・Events・Notificationsという4サービスを、同期経路(API Gateway → Functions)と非同期経路(Object Storage → Events → Functions → Notifications)という2つの性質が異なる経路として結線し、実際に動く状態まで構築しました。

§4・§5で構築した内容を振り返ると、次の点が本記事全体を通じたポイントです。

• 同期経路(§4)では、API Gatewayのゲートウェイタイプ(パブリック/プライベート)がVCNサブネット要件を左右し、デプロイメント仕様のJSON定義でルートとバックエンドを紐付けました
• 非同期経路(§5)では、Eventsルールが参照するNotificationsトピックとFunctionsを先に用意する順序が重要であり、OCI Eventsと廃止済みのEvent Hub Classicとの名称混同にも注意が必要でした
• AWS実務者向けの対応表(§6)では、Lambda↔Functions・API Gateway(同名異実装)・EventBridge↔Events・SNS↔Notificationsという4組のうち、名前の一致するAPI Gatewayがもっとも誤解を招きやすいことを確認しました
• 料金(§7)では、API Gatewayに無料レンジが存在しない点は第三者情報と食い違う最重要ポイントであり、Functions・Events・Notificationsは本記事の規模であれば追加課金がほぼ発生しないことを、公式価格表に基づいて整理しました
• 落とし穴(§8)では、純粋なAlways Freeテナンシでの実演不可の公算、Fnのコールドスタート、VCNサブネット要件、Events名称混同、非同期経路のエラー不可視性という5点を、実演でつまずきやすい順に整理しました

本記事は、§1-1で述べた通り、4サービスの結線と基本的な動作確認までをVol1のスコープとしています。認証・認可の高度な設定、複数リージョンにまたがる高可用性構成、負荷試験を踏まえたスケーリング設計、OCIRを起点としたCI/CDパイプラインといったテーマは、いずれも本記事で構築した基本構成を土台として、続編や今後公開予定の別記事(OCI DevOps関連記事、可観測性関連記事)で扱う予定です。

まずは本記事の手順に沿って、実際にご自身のテナンシで同期経路・非同期経路の両方を動かしてみてください。特に§7で整理した料金構造を踏まえたうえで、Always Freeテナンシのままなのか、Pay As You Goへの移行が必要なのかを事前に確認しておくことで、想定外の課金や実演の中断を避けられます。