Oracle Integration Cloud (OIC)

解決する課題

業務システムは ERP・CRM・人事・EC など複数の SaaS や自社アプリに分散し、それらを横断したデータ連携や業務フローの自動化が常に課題になります。OIC は、こうした「アプリ同士をつなぐ」「業務プロセスを自動で流す」作業を、ローコードのビジュアル開発で実現します。

• 多数の SaaS や DB を個別にコードで連携するのが重く、保守しきれない
• 受発注・申請承認のような業務フローを、人手や個別スクリプトで回している
• システム間のデータ形式やプロトコルの差（REST・SOAP・ファイル・DB）を毎回吸収するのが大変
• 連携が失敗したときの再試行・エラー追跡・可視化を自前で作り込みたくない

AWS では、ステップ実行のオーケストレーションを担う Step Functions と、SaaS 間のデータ転送を担う AppFlow を組み合わせた領域に近く、OIC はそれを 1 つの統合サービスとして提供します。

主要概念と用語

• インテグレーション（Integration）: 連携処理の実体。トリガー（起点）とインボーク（呼び出し先）をつないだ 1 本のフロー
• アダプター（Adapter）: SaaS や DB、技術プロトコルへ接続するためのコネクタ部品。ERP・CRM・人事系などの事前構築済みアダプターが数百種類用意される
• コネクション（Connection）: アダプターに接続先 URL・認証情報を設定した接続定義。トリガーまたはインボークとして再利用する
• オーケストレーション（Orchestration）: 分岐・ループ・マッピング・エラー処理を含む複数ステップの業務フロー。AWS の Step Functions に近い役割
• マッピング（Mapper）: 送信元と送信先のデータ項目を視覚的に対応づける変換定義
• プロセス（Process Automation）: 人の承認や長期間の業務プロセスを扱うワークフロー機能
• インテグレーションフロー（Integration Insight 等の可視化）: 実行状況やビジネス指標を追跡する仕組み
• B2B / ファイル連携: EDI などの企業間取引やファイルベースのバッチ連携をサポートする機能群
• 接続性エージェント（Connectivity Agent）: オンプレミスや閉域網のシステムへ、インバウンドのポート開放なしに安全に接続するための中継エージェント

仕様・制限・クォータ

• トリガー方式は、外部からの REST 呼び出しによる同期/非同期、スケジュール起動、イベント駆動（メッセージ受信）など複数に対応する
• アダプターは SaaS・データベース・技術系プロトコルを幅広くカバーし、標準の REST/SOAP/FTP/データベースアダプターのほか、主要 SaaS 向けの専用アダプターが提供される
• 1 メッセージあたりのペイロードサイズや同時実行数、保管期間などにはサービス上の上限があり、超える場合は分割処理やファイル連携（ステージング）を用いる
• 大容量データはメッセージ本文で流すのではなく、Object Storage 等にステージングして参照渡しするのが定石
• キャパシティは利用形態（メッセージ数ベース等）に応じたサービス制限として管理され、必要に応じて引き上げを申請する
• 具体的な上限値・料金・対応アダプター数はリージョンや提供形態で変わるため、最新の公式ドキュメントで確認する

内部の仕組み

OIC はマネージドな統合ランタイムで、開発者はビジュアルなデザイナでフローを組み立て、実行・スケーリング・監視はサービス側が引き受けます。基本的な流れは「トリガー（起点）→ 変換・分岐などの処理 → インボーク（呼び出し先）」というパイプラインです。

• トリガーが起点となるイベントや呼び出しを受け取り、マッピングで送信先の形式へデータを変換し、インボークで対象システムを呼び出す
• 分岐・ループ・並列・エラーハンドラといった制御フローを視覚的に組めるため、Step Functions のステートマシンに近い表現力を持つ
• 接続性エージェントを使うと、OIC からオンプレへ直接ポートを開けることなく、エージェント経由のアウトバウンド接続でオンプレ資産へ到達できる
• 連携の各実行はインスタンスとして記録され、成功/失敗、滞留、再処理の状態を追跡できる
• 失敗時はフォールト（エラー）ハンドリングで再試行や代替処理を定義でき、設計次第で回復力を高められる

設計パターン / ベストプラクティス

• SaaS 間データ同期: CRM の顧客データを ERP や DWH へ定期同期する。専用アダプターでローコードに実装し、差分連携で負荷を抑える
• API オーケストレーション: 複数バックエンド呼び出しを 1 本のフローに集約し、外部には REST トリガーで公開する。API Gateway を前段に置いて認証・流量制御を分離する
• イベント駆動連携: メッセージや通知を起点にフローを開始し、システム間を疎結合に保つ
• ステージング連携: 大容量・バッチは Object Storage にファイルを置き、参照渡しで処理する
• オンプレ接続は接続性エージェント: 閉域網の DB や基幹システムへは、ポート開放せずエージェント経由で接続する
• エラー処理の標準化: フォールトハンドラと再試行ポリシーをテンプレ化し、失敗インスタンスの再処理運用を最初から設計に組み込む
• 環境分離: 開発・検証・本番を分け、コネクション情報は環境ごとに切り替えて昇格（プロモーション）する

運用・監視

• 各連携の実行はインスタンス単位で追跡でき、成功/失敗、滞留、処理時間を可視化できる
• 失敗インスタンスはエラー要因の特定と再処理が運用の中心。フォールトの分類（接続エラー・データエラー・タイムアウト）で対応を分ける
• ビジネス観点の可視化（処理件数・滞留・SLA など）は可視化機能で指標化し、現場や業務側と共有する
• メトリクスやログは OCI Monitoring / Logging と連携して一元的に監視し、しきい値超過をアラート化する
• 連携定義の変更・公開はバージョン管理と環境昇格で統制し、本番への直接変更を避ける

コスト

OIC のコストは主に**利用キャパシティ（メッセージ処理量や割り当て規模）**に応じて発生します。連携の本数そのものより、流れるメッセージ量と実行頻度がコストを左右する点を意識します。

セキュリティ

• IAM ポリシーとコンパートメントで OIC インスタンスの操作権限を最小化する
• 接続先の認証情報（API キー・OAuth トークン・DB パスワード）は Vault（Secrets）で集中管理し、フローや設定に直書きしない
• 外部公開する REST トリガーは、前段の API Gateway で認証・認可・流量制御を行い、OIC を直接インターネットへ晒さない
• オンプレ接続は接続性エージェントを用い、インバウンドのポート開放を避けてアウトバウンド接続で完結させる
• 連携データに個人情報や機密が含まれる場合は、ログ出力やステージング先での露出範囲に注意し、暗号化と最小権限を徹底する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: ローコードでフローを標準化し、実行をインスタンス単位で可視化できる。環境昇格とバージョン管理で変更を統制し、再処理運用を設計段階から織り込む
• 信頼性（Reliability）: フォールトハンドリングと再試行で一時的な障害から回復できる。冪等設計とステージングにより、再処理や大容量処理を安全に行える
• 連携先サービスのスロットリングや障害に備え、タイムアウトと再試行の上限を定め、失敗を握りつぶさず可視化する

試験で問われるポイント

関連サービス・比較

OIC はオーケストレーションと SaaS 連携の両面を持つため、AWS では複数サービスに対応づきます。代表的な相当サービスと対比します。

関連して、外部公開と保護には API Gateway、イベント駆動の起点には OCI Events、非同期のバッファリングには Queue / Streaming、サーバーレス処理には Functions、秘密情報管理には Vault を組み合わせるのが定番です。

ハンズオン / CLI例

OIC のインスタンス自体の管理は OCI CLI（oci integration）で行えます。連携フローの中身はコンソールのビジュアルデザイナで作成するのが基本ですが、インスタンスの作成・確認・スケール変更は CLI で自動化できます。

# OIC インスタンスを作成（メッセージ規模などは要件に合わせて指定）
oci integration integration-instance create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name my-oic \
  --integration-instance-type ENTERPRISE \
  --is-byol false \
  --message-packs 1

# コンパートメント内の OIC インスタンスを一覧
oci integration integration-instance list \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --query "data.items[].{name:\"display-name\", state:\"lifecycle-state\", url:\"instance-url\"}" \
  --output table

# 単一インスタンスの詳細を取得（エンドポイント URL や状態を確認）
oci integration integration-instance get \
  --integration-instance-id ocid1.integrationinstance.oc1..xxxxx

# メッセージ規模（キャパシティ）を変更してスケールする
oci integration integration-instance change-integration-instance-message-pack \
  --integration-instance-id ocid1.integrationinstance.oc1..xxxxx \
  --message-packs 2