トップ > クラウド > OCI Generative AIでアラート通知を自動要約！運用効率化のための設計と構成【前編】

OCI Generative AIでアラート通知を自動要約！運用効率化のための設計と構成【前編】

クラウド AI 検証レポート

はじめに

NTT西日本株式会社2年目社員の山塚です。私は現在、OCIを活用したインフラ運用の高度化に取り組んでいます。

OCIの監視アラートは運用上欠かせないものですが、JSON形式のまま通知されるため、内容を把握するまでに時間がかかるという課題がありました。経験豊富なエンジニアであっても、JSON形式のままでは一目で状況を把握しづらく、特に深夜のオンコール対応では認知負荷が高くなりがちです。

本稿では、この「アラート通知の可読性」という課題に対し、OCI Generative AI（GenAI）を活用して自動要約する仕組みを構築した事例をご紹介します。

なお、OCI Generative AIは日本国内では大阪リージョンでのみ提供されています（2026年2月時点）。一方、多くの企業やユーザーは東京リージョンをメインリージョンとして利用しています。本記事では、東京リージョンをメインで利用しながら大阪リージョンのGenAIにプライベート接続するという、実務で直面しやすいクロスリージョン構成の設計思想と全体像を詳説します。

【Before / After：要約のイメージ】

GenAIによる要約を導入すると、以下のようにJSON通知が自然言語で整理されます。

【Before：JSON形式のまま届く通知】
{"type":"OK_TO_FIRING","severity":"CRITICAL","alarmMetaData":[{"status":"FIRING",...}]}

【After：GenAIによる要約】
[概要]
「web-server-01」にて、「high-cpu-alarm」（現在の値: 95%）が発生しました。
緊急度はCRITICALです。

[詳細分析]
CPU使用率が閾値80%を超過し、現在95%に達しています。
...

[推奨されるアクション]
1. 該当インスタンスにSSH接続し、topコマンドでプロセス状況を確認してください。
...

※本記事は2026年2月時点の情報に基づきます。

※本記事では生成AIを活用した内容が含まれており、AIによる情報の生成過程でハルシネーション（事実に基づかない情報の生成）が発生する可能性があります。AIが生成した「詳細分析」や「推奨されるアクション」は参考情報としてご活用いただき、実際の運用判断は必ずご自身で確認のうえ行ってください。

対象読者

本記事は、以下の方を対象としています。

  • OCIのアラート通知運用を効率化したいエンジニア
  • OCI Generative AIの具体的な活用例を知りたい方
  • クロスリージョン構成やプライベートエンドポイントの設計に興味がある方
  • 東京リージョンをメインで使いながら大阪のGenAIを利用したい方

前提知識： 本記事では、以下の知識があることを前提としています。

  • OCI VCN（Virtual Cloud Network）の基本的な構成（サブネット、ルート表、セキュリティリスト）
  • DRG（Dynamic Routing Gateway）の概念
  • OCI Functionsの基本的な使い方
  • OCIコンソールでのリソース作成操作

目次

  1. 背景・課題：OCIアラート運用の現場から
    1. JSON形式の通知が抱える問題
    2. 既存の解決策とその限界
  2. 解決策：GenAIによるアラート自動要約
    1. なぜGenAIを選んだのか
    2. 期待される効果
  3. 構成検討：立ちはだかる4つの壁
    1. 壁①：GenAIは大阪リージョンにしかない
    2. 壁②：サービスゲートウェイでは届かない
    3. 壁③：インターネット経由のセキュリティ懸念
    4. 壁④：専有モデルのコスト
  4. 解決策：GenAIプライベートエンドポイントの発見
  5. 採用した構成の全体像
    1. 東京リージョン側の構成
    2. 大阪リージョン側の構成
    3. リージョン間接続とセキュリティの設定
  6. 通知の流れ：アラート発生から要約配信まで
    1. アラーム定義からの通知
    2. イベント・Connector Hubからの通知
    3. なぜ原本をバケットに保存するのか
  7. 検討して却下した構成案
  8. まとめと後編への導線

1. 背景・課題：OCIアラート運用の現場から

1.1 JSON形式の通知が抱える問題

OCIで運用監視をしていると、以下のようなサービスからアラート通知を受け取ることがあります。

サービス 用途 JSON形式
アラーム定義 メトリクスの閾値超過監視 ※オプションで整形テキスト形式に変更可能
イベント（Event） リソースの状態変化検知 必ずJSON
Connector Hub ログの転送・フィルタリング 必ずJSON

これらの通知をトピック経由でメールやSlackに流すと、以下のようなJSON形式のまま届くケースがあります。(実際に検証の中で発火させたアラーム定義のJSONを、一部マスキングして掲載しています。)

{
  "dedupeKey": "a1b2c3d4-5e6f-7890-abcd-ef1234567890",
  "title": "high-cpu-alarm",
  "body": "高CPUアラート",
  "type": "OK_TO_FIRING",
  "severity": "CRITICAL",
  "timestampEpochMillis": 1739512560000,
  "timestamp": "2026-02-14T05:36:00Z",
  "alarmMetaData": [
    {
      "id": "ocid1.alarm.oc1.ap-tokyo-1.aaaaaaaaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "status": "FIRING",
      "severity": "CRITICAL",
      "namespace": "oci_computeagent",
      "query": "CpuUtilization[1m]{resourceId = \"ocid1.instance.oc1.ap-tokyo-1.aaaaaaaayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy\"}.mean() > 80",
      "totalMetricsFiring": 1,
      "dimensions": [
        {
          "instancePoolId": "Default",
          "resourceDisplayName": "web-server-01",
          "faultDomain": "FAULT-DOMAIN-1",
          "resourceId": "ocid1.instance.oc1.ap-tokyo-1.aaaaaaaayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
          "availabilityDomain": "xxxx:AP-TOKYO-1-AD-1",
          "imageId": "ocid1.image.oc1.ap-tokyo-1.aaaaaaaa_example_image_id_xxxxxxxxxxxxxxxxxxxx",
          "shape": "VM.Standard.E4.Flex",
          "dedicatedVmHostId": "DefaultVmHostId",
          "region": "ap-tokyo-1"
        }
      ],
      "alarmUrl": "https://cloud.oracle.com/monitoring/alarms/ocid1.alarm.oc1.ap-tokyo-1.aaaaaaaaxxxxxxxx...",
      "alarmSummary": "CPU使用率監視アラーム",
      "metricValues": [
        {
          "CpuUtilization[1m]{resourceId = \"ocid1.instance.oc1.ap-tokyo-1.aaaaaaaayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy\"}.mean()": "95.2"
        }
      ]
    }
  ],
  "notificationType": "Grouped messages across metric streams",
  "version": 1.5
}

このJSONを見て、瞬時に「何が起きたか」「どのリソースか」「どれくらい深刻か」を把握できるでしょうか？

経験豊富なエンジニアであっても、JSON形式のままでは直感的に状況を把握しづらく、特に深夜のオンコール対応ではこの情報を解読する時間が運用上のボトルネックになります。

1.2 既存の解決策とその限界

OCIには、アラーム定義に対して「フォーマットされたメッセージの送信」というオプションがあります。

アラーム定義の「フォーマットされたメッセージ」オプション アラーム作成時の「メッセージの書式」でフォーマットされたメッセージの送信を選択すると、人間が読みやすい整形テキスト形式でメッセージを受け取ることができます。

しかし、この機能には以下の制約があります。

制約 詳細
アラーム定義限定 イベントやConnector Hubには適用できない
フォーマットの固定 独自の形式にカスタマイズできない
対応策の提示なし 「次に何をすべきか」は含まれない

こういった制約を鑑みると、すべての通知サービスが一貫した形式で、また解決策まで提示される仕組み作りを検証する価値があると感じました。

2. 解決策：GenAIによるアラート自動要約

2.1 なぜGenAIを選んだのか

上記の課題を解決するために、OCI Generative AI（GenAI）を活用してアラート通知を自動要約するという構成を検討しました。

GenAIを選択した理由は以下の通りです。

理由 詳細
非構造データの理解 JSONの構造が異なっても、文脈を理解して要約できる
日本語での出力 誰にとっても伝わりやすい
対応策の提示 考えられる原因や推奨アクションを提示できる
OCI内での完結 外部サービスを使わず、OCIのセキュリティ境界内で処理できる

2.2 期待される効果

GenAIによる自動要約で、以下の効果を期待しました。

【期待される要約出力のイメージ】

[概要]
「web-server-01」にて、「high-cpu-alarm」（現在の値: 95%）が発生しました。
緊急度はCRITICALです。

[詳細分析]
CPU使用率が閾値80%を超過し、現在95%に達しています。
メトリクス「CpuUtilization」が継続的に高い状態にあり、
バッチ処理の集中実行やアプリケーションの異常動作が考えられます。

[推奨されるアクション]
1. 該当インスタンスにSSH接続し、topコマンドでプロセス状況を確認してください。
2. OCIコンソールのメトリクス画面で、過去の推移を確認してください。
3. 必要に応じてスケールアップまたはスケールアウトを検討してください。

[ログ参照]
パス: 20260214/053000_Alarm_a1b2c3d4.json

このように、誰が見ても状況を把握でき、次のアクションが明確になる形式をめざしました。

3. 構成検討：立ちはだかる4つの壁

「GenAIで要約すればいい」というアイデアは良かったのですが、実際に構成を検討すると、いくつかの壁に直面しました。

3.1 壁①：GenAIは大阪リージョンにしかない

OCI Generative AIの基盤は、日本国内では大阪リージョンでのみ提供されています（2026年2月時点）。

しかし、多くの企業やユーザーは東京リージョンをメインリージョンとして利用しています。そのため今回の検証では、以下のリソースはすべて東京リージョンにあるものとして構成しました。

  • 監視対象のCompute インスタンス
  • アラーム定義、イベントルール
  • 通知用のトピック
  • ログ保存用のObject Storage

東京リージョンで発生したアラートを処理したいのに、GenAIは大阪にしかない——これが最初の壁でした。

図1.GenAIの提供リージョン(2026年2月時点)

参考：生成AIリージョン

3.2 壁②：サービスゲートウェイでは届かない

OCIには、パブリックIPを使わずにOCIサービスへアクセスできるサービスゲートウェイ（SGW）があります。

「SGW経由で大阪のGenAIにアクセスできないか？」と考えましたが、これは不可能でした。

理由：SGWはリージョン内のサービスに対してのみ有効

SGWはVCNと同じリージョン内のOCIサービス（Object Storage、Autonomous Databaseなど）へのアクセスを提供するものであり、クロスリージョンでのサービスアクセスには対応していません。

【NG構成】
東京VCN → 東京SGW → 大阪GenAI（×到達不可）

3.3 壁③：インターネット経由のセキュリティ懸念

検証の過程で、NATゲートウェイ（NATGW）経由であれば東京リージョンから大阪GenAIのパブリックHTTPSエンドポイントを叩けることは確認できました。

【検証した構成】
東京VCN → NATGW → インターネット → 大阪GenAI（○到達可能）

この方法のメリットは東京リージョンだけで構成が完結すること。DRGやRPC（Remote Peering Connection）接続といったクロスリージョン設定が不要で、構築が比較的シンプルです。

しかし、以下の懸念がありました。

懸念点 詳細
インターネット経由 アラートログがパブリックネットワークを経由する
セキュリティポリシー 組織によってはNGとなる可能性
監査・コンプライアンス プライベート通信が求められるケース

アラートログには、リソース名やOCID、場合によってはエラーメッセージなど、インフラの内部情報が含まれます。これをインターネット経由で送信することに抵抗がある組織も多いでしょう。

3.4 壁④：専有モデルのコスト

GenAIには専有ホスティングモデルとオンデマンド（共有）モデルがあります。

専有ホスティングモデルであれば、プライベート接続は比較的容易です。しかし、コスト面で大きな差があります。

項目 オンデマンド 専有ホスティング
課金単位 文字数（トランザクション）ベース AIユニット/時
最低利用 なし 744単位時間（約31日）/クラスタ

※価格は変動するため、最新情報はOCI生成AIの価格設定を参照してください。

今回は検証目的ということもあり、オンデマンドモデルを前提に構成を考えました。

4. 解決策：GenAIプライベートエンドポイントの発見

4つの壁に直面する中で、2026年1月、GenAIのプライベートエンドポイントという機能がオンデマンドモードに対応するというリリースノートが発表されました。

この機能を使うと、オンデマンドホストに対してもプライベートな接続ができることがわかりました。

プライベートエンドポイントの特徴：

特徴 詳細
VCN内に配置 プライベートサブネット内にエンドポイントが作成される
プライベートIPで通信 インターネットを経由しない
オンデマンドモデル対応 専有ホストでなくても利用可能
DNS登録が必要 独自のDNS接頭辞を設定し、名前解決の設定が必要

これを活用すれば、インターネットを経由せずに東京リージョンから大阪のGenAIを利用できます。

つまり、構成のポイントは以下の通りです。

  1. 東京リージョンと大阪リージョンをDRGのRPC接続でつなぐ
  2. 大阪リージョンにGenAIプライベートエンドポイントを作成
  3. DNS転送を設定して、東京から大阪のプライベートエンドポイントを名前解決できるようにする

5. 採用した構成の全体像

最終的に採用した構成を図にまとめました。

図2.採用した構成の全体図

また、具体的なフローは下記の通りです。

ステップ 処理内容
① アラーム定義やイベント、Connector HubからFunctionsへ通知を飛ばす
② ①をきっかけにして、OCIRに格納されているイメージをもとにFunctionsが起動する
③ Functions起動後、指定した保管用のObject Storageに対して、受け取ったJSONログを格納する
④ DRG経由で大阪リージョンに設定したGenAIのプライベートエンドポイントにアクセスする
⑤ プライベートエンドポイントを介してGenAIとやり取りし、再度DRG経由でFunctionsに受け取った内容を飛ばす
⑥ そのままユーザー通知用のトピックに対して飛ばす
⑦ トピック経由で通知を受け取る

5.1 東京リージョン側の構成

東京リージョンには、以下のリソースを配置しています。

リソース 用途 補足
VCN ネットワークの基盤 プライベートサブネットを1つ作成
プライベートサブネット Functionsの配置場所 パブリックIPは付与しない
OCI Functions 通知受信→要約→再送信の処理 Pythonで実装
サービスゲートウェイ（SGW） Object Storageへのプライベートアクセス ログ保存時に使用
Object Storageバケット 元のJSONログを保存 ハルシネーション対策
DRG 大阪リージョンとの接続 VCNアタッチメントで接続
DNS転送エンドポイント 大阪への名前解決転送 GenAIのFQDNを転送
トピック（中継用） アラーム定義の中継 Functionsへのサブスクリプション
トピック（通知用） 要約結果の配信 メールへのサブスクリプション

SGWの用途について： 東京VCNにSGWを配置しているのは、FunctionsからログをObject Storageに保存する際にプライベート通信を使用するためです。SGWがないと、Object Storageへのアクセスがインターネット経由になってしまいます。

5.2 大阪リージョン側の構成

大阪リージョンには、以下のリソースを配置しています。

リソース 用途 補足
VCN ネットワークの基盤 プライベートサブネットを1つ作成
プライベートサブネット GenAIプライベートエンドポイントの配置場所
GenAIプライベートエンドポイント オンデマンドGenAIへのプライベートアクセス DNS接頭辞の設定が必要
DRG 東京リージョンとの接続 VCNアタッチメントで接続
DNSリスナーエンドポイント 東京からのDNSクエリを受信
VCNリゾルバ・ゾーン GenAIエンドポイントのドメイン登録 プライベートビュー

GenAIプライベートエンドポイント作成時の設定：

【プライベートエンドポイント作成時の入力例】

名前: genai-private-endpoint
コンパートメント: <コンパートメントを選択>
VCN: osaka-vcn
サブネット: osaka-private-subnet
DNS接頭辞: mygenai  ← ここが重要

作成後のFQDN例:
mygenai.pe.inference.generativeai.ap-osaka-1.oci.oraclecloud.com

図3.GenAIプライベートエンドポイント作成画面

5.3 リージョン間接続とセキュリティの設定

東京と大阪を接続するために、以下の設定を行います。

DRGとRPC接続：

【設定手順の概要】

1. 東京リージョンにDRGを作成
2. 大阪リージョンにDRGを作成
3. 東京DRGにRPCアタッチメントを作成
4. 大阪DRGにRPCアタッチメントを作成
5. 双方のRPCをピアリング接続
6. 東京DRGにVCNアタッチメントを作成（東京VCNを接続）
7. 大阪DRGにVCNアタッチメントを作成（大阪VCNを接続）
8. 各DRGのルート表を設定
9. 各VCNのルート表を設定

ルート表の設定例：

【東京VCNルート表】
宛先CIDR: 10.1.0.0/16（大阪VCNのCIDR）
ターゲット: DRG（東京）

【大阪VCNルート表】
宛先CIDR: 10.0.0.0/16（東京VCNのCIDR）
ターゲット: DRG（大阪）

DNS転送の設定：

GenAIプライベートエンドポイントのFQDNを東京から名前解決できるようにするため、DNS転送を設定します。

【DNS設定の概要】

1. 大阪VCNのリゾルバにプライベートビューを作成
2. プライベートビューにGenAIエンドポイントのゾーンを登録
3. 大阪VCNにDNSリスナーエンドポイントを作成
4. 東京VCNにDNS転送エンドポイントを作成
5. 東京のDNS転送ルールで、GenAIのドメインを大阪リスナーに転送

セキュリティリストの設定：

大阪VCNのセキュリティリストでは、以下のルールを設定します。

イングレスルール（受信）：

プロトコル ポート 送信元CIDR 用途
TCP 443 10.0.0.0/24（東京サブネット） GenAI API通信
UDP 53 10.0.0.0/24（東京サブネット） DNS転送
TCP 443 10.1.0.0/24（大阪サブネット自身） サブネット内通信
UDP 53 10.1.0.0/24（大阪サブネット自身） サブネット内通信

エグレスルール（送信）：

今回の環境においては、エグレスルールの設定は特段不要になります。

重要な注意点：サブネット内通信も許可が必要 大阪サブネット自身のCIDRからの通信も許可する必要があります。これがないと、DNSリスナーエンドポイントとGenAIプライベートエンドポイント間の通信が通りません。

6. 通知の流れ：アラート発生から要約配信まで

6.1 アラーム定義からの通知

アラーム定義からの通知は、以下の流れで処理されます。

図4.アラーム定義から通知までのフロー

なぜトピックを経由するのか：

アラーム定義は、Functionsを直接呼び出すことができません。そのため、一度トピック（中継用）を経由し、そのトピックのサブスクリプションとしてFunctionsを設定しています。

また、アラーム定義には「フォーマットされたメッセージの送信」オプションがありますが、今回はあえてOFFにしています。理由は、イベントやConnector Hubと同じJSON形式で統一し、Functionsで一貫した処理を行うためです。

6.2 イベント・Connector Hubからの通知

イベントやConnector Hubからの通知は、Functionsを直接呼び出すことができます。

図5.イベント・Connector Hubから通知までのフロー

Connector Hubについて： 今回の検証では、OCI Loggingのロググループにたまったログを対象に、Connector Hubのフィルタリング機能で特定の文言（エラーメッセージなど）が検知された場合に発火する構成をテストしました。そのため「ログ検知」としてタイトルをつけていますが、Connector Hubの用途はログ検知に限ったものではなく、さまざまなデータ転送シナリオに対応しています。

6.3 なぜ原本をバケットに保存するのか

GenAIに要約させると、元のJSONは残りません。しかし運用上、以下のケースで原本が必要になることがあります。

ケース 詳細
ハルシネーション検証 AIが誤った情報を生成していないか確認する
詳細情報の確認 要約では省略された情報を確認する
監査・コンプライアンス 元の通知内容を証跡として保持する
トラブルシューティング Functionsの処理が正しいか検証する

そのため、Functionsのコード内でまずJSONをバケットに保存してからGenAIを呼び出すという順序で処理しています。

保存時のファイル名は、後から探しやすいように以下の命名規則を採用しています。

【ファイル名の命名規則】

形式: YYYYMMDD/HHMMSS_Type_UUID.json

例:
20260214/053000_Alarm_a1b2c3d4.json
20260214/053015_Event_b2c3d4e5.json
20260214/053030_ConnectorHub_c3d4e5f6.json

図6.Object Storageに作成されるプレフィックス

上記のように、ログが生成されると同時に日単位のプレフィックス（フォルダのような階層構造）が作成され、その中に各JSONログが保管されます。

図7.保管された各種JSONログ

※Object Storageには厳密にはディレクトリという概念がなく、オブジェクト名の接頭辞（プレフィックス）によって階層構造を表現しています。

7. 検討して却下した構成案

今回の構成に至るまで、いくつかの案を検討しました。それぞれの案と、却下した理由を整理します。

案1：NATゲートウェイ経由（インターネット経由）

【構成】
東京VCN → NATGW → インターネット → 大阪GenAI
評価項目 評価
構成のシンプルさ ◎ 東京リージョンだけで完結
セキュリティ △ インターネットを経由する
コスト ○ NATGWの料金のみ
採否 × セキュリティ懸念

案2：大阪リージョンにFunctionsを配置

【構成】
東京（アラート発生）→ 大阪Functions → 大阪GenAI
評価項目 評価
構成のシンプルさ △ 両リージョンにリソースが分散
セキュリティ ○ リージョン内で完結
運用性 △ アラーム定義の送信先はリージョンをまたいで選択することができないため、別途東京のアラートを大阪に転送する必要あり
採否 × 運用の複雑化

案3：GenAIプライベートエンドポイント＋RPC接続（採用）

【構成】
東京Functions → RPC → 大阪GenAIプライベートエンドポイント
評価項目 評価
構成のシンプルさ △ クロスリージョン設定が必要
セキュリティ ◎ 完全プライベート
運用性 ○ Functionsは東京に集約
採否 ✓ 採用

セキュリティと運用性のバランスを考慮し、プライベートエンドポイント＋RPC接続を採用しました。

8. まとめと後編への導線

本記事のまとめ

前編では、OCIアラート通知のJSON問題を解決するために、GenAIプライベートエンドポイントを活用したクロスリージョン構成の設計思想と全体像を解説しました。

今回の成果：

  • 東京リージョンから大阪のGenAIにプライベート接続する構成を設計
  • オンデマンドモデルでもプライベートエンドポイントが利用可能なことを確認
  • DRG + RPC + DNS転送による完全プライベートな通信経路を確立
  • セキュリティとコストのバランスを考慮した構成を採用

前編完了時点での構築到達点：

本記事（前編）の内容を実施すると、以下のリソースが構築された状態になります。

  • 東京リージョン：VCN、プライベートサブネット、DRG、SGW、DNS転送エンドポイント、Object Storageバケット、トピック（中継用・通知用）
  • 大阪リージョン：VCN、プライベートサブネット、DRG、GenAIプライベートエンドポイント、DNSリスナーエンドポイント、VCNリゾルバ設定
  • リージョン間：RPC接続、ルート表設定、セキュリティリスト設定

次回予告：後編へ

「設計はできた。では、実際にどうやってFunctionsを実装するのか？プロンプトはどう設計するのか？」

次回の後編では、以下の内容を詳説します。

  • Functionsの実装コード：リソースプリンシパル認証、ONS（Oracle Notification Service）封筒の展開、通知タイプの判定
  • プロンプト設計：通知タイプに応じた指示の切り替え、出力形式の固定
  • Before/Afterサンプル：実際の要約結果
  • 検証結果：レイテンシ、コスト、運用改善効果
  • ハマりポイント・Tips：DNS設定、セキュリティリスト、タイムアウト設定など

執筆者

山塚 友貴
所属：NTT西日本 ビジネス営業本部
業務：主にOCIの設計や構築、運用に携わっています。
保有資格：Oracle Cloud Infrastructure 2024 Architect Professional、AWS Certified Solutions Architect - Professional、Azure Solution Architect Expert(AZ-305)など。

参考文献

商標

  • Oracle、Java、MySQL及びNetSuiteは、Oracle Corporation、その子会社及び関連会社の米国及びその他の国における登録商標です。
  • SlackはSalesforce, Inc.の商標です。
  • AWSはAmazon.com, Inc.またはその関連会社の商標です。
  • Microsoft AzureはMicrosoft Corporationの商標です。
  • その他、本記事に記載されている会社名、製品名は、各社の登録商標または商標です。

© NTT WEST, Inc.