Application Integration

解決する課題

業務システムや SaaS、データベースをまたいだ連携を個別のスクリプトや常駐バッチで書くと、認証・データ変換・リトライ・エラー処理がそれぞれの実装に散らばり、保守が難しくなります。Application Integration は、こうしたアプリケーション間連携を トリガーとタスクをつなぐ統合フローとしてローコードで設計し、実行基盤をマネージドに任せます。

• 複数の SaaS や社内システムを データ連携したいが、API ごとの認証やデータ変換を毎回書きたくない
• 「あるイベントが起きたら別システムを更新する」連携を ローコードで素早く組みたい
• 連携処理の スケジュール実行・エラー時のリトライ・通知を共通の仕組みに任せたい
• Google Cloud のサービス（Pub/Sub、BigQuery、Cloud Storage など）と外部システムを コネクタ経由でつなぎたい
• 連携処理の 実行状況や失敗箇所を可視化し、運用を一元管理したい

主要概念と用語

• 統合（Integration / 統合フロー）: トリガー・タスク・エッジ（接続線）で構成される連携処理の定義。視覚的なエディタで設計する
• トリガー（Trigger）: 統合を起動するきっかけ。API 呼び出し、スケジュール、Pub/Sub メッセージ、Cloud Storage のイベントなどがある
• タスク（Task）: 統合内で実行する処理の単位。データマッピング、条件分岐、コネクタ呼び出し、サブ統合の呼び出し、JavaScript 実行などを表す
• エッジ（Edge）と条件: タスク間のつながりと、進む経路を分岐させる条件を定義する
• 変数（Variable）: トリガーやタスク間で受け渡すデータ。入力・出力・中間値を保持する
• Integration Connectors（コネクタ）: SaaS やデータベース、Google Cloud サービスへの接続を提供する部品。認証や接続管理をマネージドに肩代わりする
• データマッピングタスク: ある形式のデータを別の形式へ変換・整形するためのタスク
• バージョンと公開（Publish）: 統合は下書きとして編集し、テスト後に公開して実行可能な状態にする。バージョン管理で変更を追跡できる

仕様・制限・クォータ

• 統合は ビジュアルなローコードエディタで設計し、トリガー・タスク・分岐・ループ・エラーハンドラを組み合わせて表現する
• 連携先との接続は Integration Connectors が担い、多数の SaaS・データベース・Google Cloud サービス向けのコネクタが提供される
• トリガーには API トリガー（同期/非同期）、スケジュールトリガー、Pub/Sub トリガー、Cloud Storage トリガーなどがある
• 統合は リージョン単位のリソースとして作成・実行される。利用できるリージョンには対応状況がある
• 1 実行で扱える データサイズ・タスク数・同時実行数・実行時間などに上限（クォータ）があり、一部は引き上げ申請が可能
• 具体的な上限値・クォータの数値・対応コネクタの一覧は変動するため、最新は公式ドキュメントで確認すること

内部の仕組み

統合を起動すると、Application Integration のマネージド実行基盤がトリガーから順にタスクを評価し、エッジの条件に従って経路をたどりながら処理を進めます。各タスクの 入出力変数の値や実行状態はサービス側で管理されるため、利用者が状態管理の基盤を自前で用意する必要はありません。

• 外部 SaaS やデータベースへの呼び出しは Integration Connectors を経由し、コネクタが認証・接続プール・プロトコルの差異を吸収する
• データマッピングタスクが入力データを宛先の形式へ変換し、後続タスクへ受け渡す
• 失敗時は エラーハンドラやリトライ設定でハンドリングでき、再試行や代替経路を定義できる
• 同期 API トリガーは呼び出し元へ結果を返し、非同期トリガーは受け付けだけ行ってバックグラウンドで実行する

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

• SaaS データ連携のハブ: 複数の SaaS や社内システムの間でデータを同期・転送する中心役として使う
• イベント駆動の連携: Pub/Sub や Cloud Storage のイベントをトリガーに、後続システムを自動更新する
• 冪等性の確保: リトライにより同じ処理が再実行されうるため、宛先への書き込みは冪等に設計する
• コネクタの再利用: 接続定義（Integration Connectors）を共有し、認証情報を統合定義に直書きしない
• オーケストレーションとの使い分け: Google Cloud サービス中心の手順制御は Workflows、SaaS を含むローコードのデータ連携は Application Integration、と役割を分ける
• 疎結合な配信が主目的なら: 単純なイベント配信は Pub/Sub や Eventarc に寄せ、変換やマッピングを伴う連携を Application Integration に集約する

運用・監視

• 各実行は 状態（成功・失敗・実行中）と入出力、タスクごとの経過を保持し、コンソールで実行ログを追跡できる
• Cloud Logging に実行ログが出力され、どのタスクで何が起きたかを確認できる
• Cloud Monitoring で実行回数・失敗率・所要時間などを監視し、アラートを設定する
• 失敗した実行は入力データと失敗箇所を確認して原因を切り分ける。コネクタの認証エラーや権限不足、データ形式の不一致が典型的な原因
• 統合は バージョン管理され、公開済みの定義を保ちつつ下書きで安全に変更・テストできる

コスト

Application Integration は 統合の実行回数やデータ処理量、利用するコネクタの接続ノードなどに応じた従量・利用ベースの課金が基本です。常駐サーバーを自前で用意しないため、連携基盤の固定的な運用コストを抑えられるのが特徴です。

セキュリティ

• 統合の実行には サービスアカウントを割り当て、そのアカウントの権限でタスクが実行される。最小権限の IAM ロールのみを付与する
• 外部システムへの接続情報や API キーは統合定義に直書きせず、Secret Manager や Integration Connectors の認証設定を通じて安全に管理する
• 統合の作成・編集・実行は IAM ロールで操作を分離し、編集権限と起動権限を分ける
• データは Google Cloud 内で 保存時・転送時に暗号化され、要件に応じて CMEK（顧客管理鍵） での保護にも対応する
• 外部システムへの接続は、必要に応じて専用の接続経路や認証方式を用いてアクセス範囲を限定する

関連サービス・比較

Application Integration は SaaS を含むローコードのデータ連携に向き、Workflows は Google Cloud サービス中心のプログラマブルな手順制御に向きます。役割が近い両者を比較します。

ハンズオン / CLI例

# 利用リージョンで Application Integration を有効化（初回セットアップ）
gcloud integrations clients provision \
  --location=asia-northeast1

# プロジェクト内の統合を一覧表示
gcloud integrations list \
  --location=asia-northeast1

# 統合のバージョン一覧を確認
gcloud integrations versions list \
  --integration=my-integration \
  --location=asia-northeast1

# 公開済みの統合を入力データ付きで実行
gcloud integrations execute \
  --integration=my-integration \
  --location=asia-northeast1 \
  --input-file=input.json