📊
Gemini API でシステム監視レポート作成業務を自動化する

2025/09/01に公開
 1. はじめにクラウドエース安田です。
システム運用において、システムの負荷を定期的に確認することは非常に重要な業務です。これにより、障害を事前に検知できる場合もあります。定期的な確認結果を共有するため、作業者全員に負荷情報をメールで報告しているチームもあるかと思います。
私もそういった業務をする中で、以下の作業に時間がかかり、課題だと感じました。
報告すべきデータの収集
報告に適した文面の作成
メールで報告する内容は、監視対象のリソースの CPU とメモリの期間内最大値と、メール送信時の負荷でした。その値を HTML テーブルで報告する必要がありました。この作業は煩雑で、運用業務の本質ではありません。しかし、運用プロセスを変えられない場合、実施せざるを得ないこともあるかと思います。
そこで、本記事では、Gemini API を使ってこの作業を自動化します。このシステムにより、運用の作業効率を向上させることができます。

 2. Gemini API についてGemini API は、Google が開発した AI である「Gemini」を API として利用できるサービスです。本記事では、この Gemini API の特徴と活用方法を説明します。

Gemini API では、テキスト生成、コード生成、データ分析など、様々なタスクに対応できます。今回は、Cloud Monitoring API から取得したメトリクスデータ（JSON 形式の構造化されたデータ）の処理と、HTML 形式での出力生成に Gemini API を活用します。

 本記事で使用するモデルGemini は処理に使うモデルを指定して、処理を実行させます。Gemini API でも同じようにモデルを選択する必要があります。

本記事では gemini-2.0-flash モデルを使用します。このモデルは以下の特徴があります。
高速処理: レスポンス時間が短く、リアルタイム処理に適している
テキスト生成: 様々な形式のテキストを出力可能
コスト効率: 比較的安価で利用可能
Gemini API には、特定のユースケースに最適化されたさまざまなモデルが用意されています。

他のモデルについては以下をご覧ください。

https://ai.google.dev/gemini-api/docs/models?hl=ja

 3. Gemini API による運用の効率化ここからは、Gemini API を活用して監視レポート作成業務をどのように効率化できるかを具体的に説明していきます。今回は監視対象の例として Cloud SQL を使用します。従来の課題からどのような機能を実現するのか、システム全体の構成、そして実装とデプロイまでを解説します。

 3.1 効率化させる内容ここでは、解決すべき課題と、実現する機能について具体的に説明します。
リソース使用量の監視報告業務には、さまざまな課題が存在します。

たとえば、運用業務において、以下のようなメールを送信する業務があるとします。

このような業務の課題を整理すると、以下の点が挙げられます。
ヒューマンエラーの発生

手動で監視画面からデータを集計・転記するため、数値の見落としや記載ミス、集計ミスなどの人的ミスが発生しやすい。
レポート作成の手間と運用担当者への負担

毎回、最大値や現在値を手作業で調べてメール文面や表を作成する必要があり、本来注力すべき運用改善や障害対応以外の定型作業に多くの時間を取られてしまう。
このような課題を Gemini API を活用することで解決していきます。

今回は以下のような機能を Gemini API で実現していきます。
取得したメトリクスの処理

Monitoring API で取得したデータから、各メトリクスの現在値と Cloud SQL の負荷が最大になった時のメトリクスの値とその時刻を特定します。
レポート生成

上記で処理したメトリクスの値をまとめて、HTML 形式で見やすいレポート生成を行います。
上記の機能を Gemini API で実装し、運用業務の定期報告のメール文面を自動で作成します。
この機能を実現するために、まずローカル環境で Gemini API を使った監視レポート生成を試行し、その後 Google Cloud 上での自動化システムを構築していきます。

 3.2 Gemini API での効率化ここからは、Gemini API を活用して監視レポート作成業務をどのように効率化できるかを具体的に説明していきます。まず、ローカル環境で Gemini API を使った監視レポート生成を試します。

 3.2.1 プロンプトの設計生成 AI アプリケーションにおいて最も重要なのがプロンプトの設計です。今回のシステムでは、以下の要求を満たすプロンプトを設計する必要がありました。
前処理したデータから、各メトリクスの現在値と Cloud SQL の負荷が最大になった時のメトリクスの値とその時刻を特定する。
メトリクス名を日本語に変換する.
HTML のテーブル形式での出力にする。
これらの要求を満たすために、以下のようなプロンプトを設計しました。
Cloud SQL データ: {metrics_data}
各インスタンス・各メトリクスごとに、与えられた「time（HH:MM）, value（%）」のリストから
- ピーク値（最大value）とそのtime
- 最新値（リストの最後のvalueとtime）
を計算し、「メトリクス名」「現在値（%）」「ピーク値（%）」「ピーク発生時刻（HH:MM）」の4列の HTML テーブルで出力してください。
valueはすでにパーセント値（例: 8.12, 12.10）です。
メトリクス名は日本語で（例: CPU Utilization→CPU使用率、Memory Utilization→メモリ使用率、Disk Utilization→ディスク使用率）。
純粋な HTML テーブルのみを出力してください。
取得時刻: {current_time}
このプロンプトにより、Gemini API が先ほど説明した要求を満たした出力をします。

 3.2.2 精度向上のための処理Monitoring API から取得した生のメトリクスデータは、処理のしにくいデータ構造になっています。

実際の生データは以下のような形式で取得されます。
Metric: cloudsql.googleapis.com/database/cpu/utilization
Resource: type: "cloudsql_database"
labels {
  key: "region"
  value: "asia-northeast1"
}
labels {
  key: "project_id"
  value: "<Project ID>"
}
labels {
  key: "database_id"
  value: "<SQL インスタンス名>"
}

Points:
Point 0: value=0.01615343719034475, time=2025-07-09 08:46:00+00:00
Point 1: value=0.08858312965858203, time=2025-07-09 08:45:00+00:00
Point 2: value=0.0927597018746989, time=2025-07-09 08:44:00+00:00
Point 3: value=0.0932000290073726, time=2025-07-09 08:43:00+00:00
Point 4: value=0.09049499703772501, time=2025-07-09 08:42:00+00:00
Point 5: value=0.08846497854622914, time=2025-07-09 08:41:00+00:00
・・・
この生データを分析すると、以下の課題が挙げられます。
数値形式の問題

value が 0.01615343719034475 のような 0-1 の範囲の小数値で表され、CPU 使用率として期待される「1.62 %」という表示になっていない。
時間形式の問題

time が time=2025-07-09 08:46:00+00:00 のような UTC 形式になっている。日本時間に合わせるため JST での表示が必要。
データ構造の問題

複雑なオブジェクト構造であり、Gemini API が直接処理をするには不適切なデータになっている。
生データのままだと上記のような課題がありました。実際に生データを Gemini API に処理させると、Cloud SQL の負荷が最大になった時のメトリクスの値と実際の値が全く異なる、% 表示ができていない、時間が日本時間になっていないなどのミスが発生する可能性があります。

このような課題を解決するために以下のような前処理を行っています。
数値の正規化
# 0-1の範囲の値をパーセンテージに変換し、小数点以下2桁に丸める。
percent_value = round(value * 100, 2)
時間データの変換
  # UTC 時刻を JST 時刻に変換し、HH:MM 形式で出力
  time_str = datetime.fromtimestamp(ts_seconds, tz=timezone.utc)\
      .astimezone(timezone(timedelta(hours=9)))\
      .strftime('%H:%M')
この処理により、2025-07-09 08:46:00+00:00 のような UTC 時刻を 17:46 のような日本時間の HH:MM 形式に変換します。
データ構造の簡素化
# 処理されたデータを Gemini API が処理しやすい構造に変換
points.append({"time": time_str, "value": percent_value})

# メトリクス単位でデータを構造化
instance_data["metrics"].append({
    "name": metric_type,
    "values": points
})
この処理により、複雑な Cloud Monitoring API の生データを、時刻と値のペアのシンプルなリスト構造に変換します。
このような処理により、前処理後の生データは以下のようになります。
{
  "instance": "< SQL インスタンス名>",
  "metrics": [
    {
      "name": "cloudsql.googleapis.com/database/cpu/utilization",
      "values": [
        { "time": "17:46", "value": 1.62 },
        { "time": "17:45", "value": 8.86 },
        { "time": "17:44", "value": 9.28 },
        { "time": "17:43", "value": 9.32 },
        { "time": "17:42", "value": 9.05 },
        { "time": "17:41", "value": 8.85 },
        { "time": "17:40", "value": 8.76 },
        { "time": "17:39", "value": 9.48 },
        { "time": "17:38", "value": 10.2 },
        { "time": "17:37", "value": 9.87 }
      ]
    }
  ]
}
この前処理工程により、Gemini API が正確にデータを分析し、各メトリクスの現在値と Cloud SQL の負荷が最大になった時のメトリクスの値とその時刻を特定できるようになります。

データ分析の精度と安定性を確保するため、この前処理工程は本システムにおいて必須の要素となります。
前処理を行わなかった場合と行った場合でどのような違いが出るか比較してみます。
前処理を行わなかった場合の出力結果は以下の通りです。



前処理を行わなかった場合の出力結果
前処理を行わなかった場合、% 表示がされているものとされていないものがあったり、実際の値とかけ離れている数値が示されることがありました。
一方、前処理を行った場合の出力結果は以下のようになります。



前処理を行った場合の出力結果
前処理を行なった場合、% 表示が全てに適用されおり、実際の値と同じ値になっていました。
この結果から、前処理工程が Gemini API の分析精度向上に必要であることがわかります。

 3.2.3 Python コードでの実装前処理とプロンプト設計が完了したら、実際にローカル環境で Python コードを実装し、Gemini API による監視レポート生成を試します。

 Gemini API キーの取得Gemini API を使用するために、API キーを取得する必要があります。Gemini API キーの取得は、Google AI Studio でも可能ですが、今回は Google Cloud 上で発行する方法を紹介します。
Google Cloud のコンソールを開く
左サイドバーより「API とサービス」→「有効な API とサービス」を開く
「API とサービスを有効にする」から「Gemini API」を検索して有効化
同じ「API とサービス」のサイドバーから「認証情報」に移動
上部にある「認証情報の作成」から API キーを選択
その後即座にキーが発行され、API キーが表示される（発行されたキーは後で使用するため、安全に保管してください）


作成されたキーを押下し編集に入る
「API の制限」より「キーを制限」を選択し、Select APIs から「Generative Language API」のみに制限を設定


必要であれば、IP アドレスでの制限も可能です。
この API キーによる Gemini API の処理は有償になります。

しかし、モデルによっては無料枠も用意されています。リクエスト数やモデルを調整すれば無料で使用することも可能です。詳しくは以下を参考にしてください。

https://ai.google.dev/gemini-api/docs/pricing?hl=ja

 必要なライブラリまず、アプリケーションの実装に必要なライブラリを以下の内容でインストールします。
pip install requests google-generativeai python-dotenv

 環境変数の設定今回のローカル環境での実装では、機密情報を .env ファイルで管理します。以下のような .env ファイルを作成してください。
.env
SENDGRID_API_KEY=your-sendgrid-api-key
GEMINI_API_KEY=your-gemini-api-key
EMAIL_FROM=your-sender-email@example.com
EMAIL_TO=recipient1@example.com,recipient2@example.com

 事前データの準備ローカル環境での実行では、Cloud Monitoring API から取得した生のメトリクスデータを事前に metrics_data.json ファイルとして保存しておきます。このファイルには、前処理前の生データが含まれています。

 アプリケーションの実装コードローカル環境での実行用にコードを実装します。このコードでは、事前に準備した生データを読み込み、前処理を行ってから Gemini API でレポートを生成します。
main.py
import os
import requests
import json
import google.generativeai as genai
from datetime import datetime, timedelta, timezone
from dotenv import load_dotenv

load_dotenv()

SENDGRID_API_KEY = os.environ['SENDGRID_API_KEY']
GEMINI_API_KEY = os.environ['GEMINI_API_KEY']
EMAIL_FROM = os.environ['EMAIL_FROM']
EMAIL_TO = os.environ['EMAIL_TO']

genai.configure(api_key=GEMINI_API_KEY)
model = genai.GenerativeModel('gemini-2.0-flash')

def preprocess_metrics_data(raw_data):
    processed_data = []
    for instance_data in raw_data:
        processed_instance = {"instance": instance_data["instance"], "metrics": []}
        
        for metric in instance_data["metrics"]:
            points = []
            for point in metric["points"]:
                value = point["value"]
                time_str = point["time"]
                
                percent_value = round(value * 100, 2)
                time_jst = datetime.fromisoformat(time_str.replace('Z', '+00:00')).astimezone(timezone(timedelta(hours=9))).strftime('%H:%M')
                
                points.append({"time": time_jst, "value": percent_value})
            
            processed_instance["metrics"].append({
                "name": metric["name"],
                "values": points
            })
        processed_data.append(processed_instance)
    
    return processed_data

def generate_report():
    now_jst = datetime.now(timezone(timedelta(hours=9)))
    current_date = now_jst.strftime('%Y年%m月%d日')
    current_time = now_jst.strftime('%Y年%m月%d日 %H:%M')

    with open('metrics_data.json', 'r') as f:
        raw_metrics_data = json.load(f)

    metrics_data = preprocess_metrics_data(raw_metrics_data)

    email_content = model.generate_content(f"""
    Cloud SQL データ: {metrics_data}
    各インスタンス・各メトリクスごとに、与えられた「time（HH:MM）, value（%）」のリストから
    - ピーク値（最大value）とそのtime
    - 最新値（リストの最後のvalueとtime）
    を計算し、「メトリクス名」「現在値（%）」「ピーク値（%）」「ピーク発生時刻（HH:MM）」の4列の HTML テーブルで出力してください。
    valueはすでにパーセント値（例: 8.12, 12.10）です。
    メトリクス名は日本語で（例: CPU Utilization→CPU使用率、Memory Utilization→メモリ使用率、Disk Utilization→ディスク使用率）。
    純粋な HTML テーブルのみを出力してください。
    取得時刻: {current_time}
    """).text

    print("生成された HTML レポート:")
    print(email_content)

    try:
        response = requests.post(
            "https://api.sendgrid.com/v3/mail/send",
            headers={"Authorization": f"Bearer {SENDGRID_API_KEY}", "Content-Type": "application/json"},
            json={
                "personalizations": [{"to": [{"email": addr} for addr in EMAIL_TO.split(',')]}],
                "from": {"email": EMAIL_FROM},
                "subject": f"システム監視レポート - {current_date}",
                "content": [{"type": "text/html", "value": email_content}]
            }
        )
        response.raise_for_status()
        print("メール送信成功!")
        return email_content
    except Exception as e:
        print(f"メール送信エラー: {e}")
        return None

if __name__ == "__main__":
    generate_report()

 ローカルでの実行実装が完了したら、ローカル環境で実際に実行してみます。
# スクリプト実行
python main.py
実行すると、以下のような流れで処理が進みます：
事前に準備した JSON ファイルから生のメトリクスデータを読み込み
データの前処理（パーセンテージ変換、時刻変換など）
Gemini API で HTML レポートを生成
SendGrid API でメールを送信
実行結果として、コンソールに生成された HTML レポートが表示され、指定したメールアドレスにレポートが送信されます。


送られてくるレポート
この検証を通じて、システムの基本機能が正常に動作することを確認した後、次の 3.3 で Google Cloud 上での自動化システムを構築します。

 3.3 システムでの自動化3.2 で作成した Python コードを Google Cloud 上にデプロイして、メール送信までを自動化していきます。

 3.3.1 システム構成今回は、以下のようなシステム構成でメトリクスデータの取得、Gemini API での分析とレポート作成、SendGrid API でメール送信を行います。
上記の図で示したシステムは、以下のような流れで動作します。各役割と、データがどのように処理されていくかを説明します。
Cloud Scheduler: 指定されたスケジュール（例：6 時、12 時、18 時）に従って HTTP リクエストを送信
Cloud Run functions: メインの処理を実行する関数
Cloud Monitoring API から Cloud SQL のメトリクスデータを取得
Gemini API にデータを送信して HTML レポートを生成
SendGrid API を使用してメールを送信

Cloud Monitoring API: Cloud SQL インスタンスのメトリクスデータを提供
Gemini API: 取得したメトリクスデータを分析し、HTML 形式のレポートを生成
SendGrid API: 生成されたレポートをメールとして送信
!今回は検証を簡単に実施するために Cloud Run functions（第 2 世代）を使用しています。本番環境で運用される場合は Cloud Run ジョブ でコンテナイメージでアプリを管理することを推奨します。

 3.3.2 システム構築デプロイを開始する前に、必要な事前準備を行います。サービスアカウントの作成と権限設定、Secret Manager の設定など、セキュリティ面での準備を整えます。

 サービスアカウントの作成と権限設定サービスアカウントの作成と必要な権限付与を Terraform で次のように作成します。
!この記事では、Cloud Scheduler と Cloud Run functions で同じサービスアカウントを使っていますが、こちらも本番環境に適用するときは別々にサービスアカウントを作成することを推奨します。
service-account.tf
resource "google_service_account" "main" {
  account_id   = "sql-monitoring-sa"
  display_name = "Cloud SQL Monitoring Service Account"
  description  = "Cloud SQL の監視レポートを生成するためのサービスアカウント"
}

# 必要な権限の付与
resource "google_project_iam_member" "cloud_functions_invoker" {
  project = var.project_id
  role    = "roles/cloudfunctions.invoker"
  member  = "serviceAccount:${google_service_account.main.email}"
}

resource "google_project_iam_member" "monitoring_viewer" {
  project = var.project_id
  role    = "roles/monitoring.viewer"
  member  = "serviceAccount:${google_service_account.main.email}"
}

resource "google_project_iam_member" "secretmanager_secretAccessor" {
  project = var.project_id
  role    = "roles/secretmanager.secretAccessor"
  member  = "serviceAccount:${google_service_account.main.email}"
}

 Secret Manager の設定次に、API キーなどの機密情報を安全に管理するための Secret Manager の設定について説明します。この設定により、API キーをコードに直接記述することなく、安全に管理できます。

Gemini API キーと SendGrid API キーでそれぞれ以下のように Terraform で作成します。
secret-manager.tf
# SendGrid API キー
resource "google_secret_manager_secret" "sendgrid_api_key" {
  secret_id = "secret-sendgridapi-key"
  replication {
    automatic = true
  }
}

resource "google_secret_manager_secret_version" "sendgrid_api_key" {
  secret = google_secret_manager_secret.sendgrid_api_key.id
  secret_data = "{your-sendgrid-api-key}"
}

# Gemini API キー
resource "google_secret_manager_secret" "gemini_api_key" {
  secret_id = "secret-geminiapi-key"
  replication {
    automatic = true
  }
}

resource "google_secret_manager_secret_version" "gemini_api_key" {
  secret = google_secret_manager_secret.gemini_api_key.id
  secret_data = "{your-gemini-api-key}"
}

 デプロイ手順事前準備が完了したら、実際のデプロイ手順について説明します。作業ディレクトリの準備から、ファイルの配置、デプロイ用変数の設定、そして Cloud Run functions のデプロイまで解説します。
1. 作業ディレクトリの準備# 作業用ディレクトリを作成
# {your-project-name} は任意のプロジェクト名に変更して下さい
mkdir {your-project-name}
cd {your-project-name}

# ソースコードを配置するディレクトリを作成
mkdir src
2. ファイルの配置以下のようにファイルを配置します。

src/main.py: メインの Python コード

src/requirements.txt: 依存パッケージの定義

env.yaml: 環境変数の設定
3. デプロイ用変数の設定デプロイを実行する前に、必要な環境変数や設定値を定義します。これらの変数により、プロジェクト ID やリージョン、サービスアカウントの情報などを管理します。
# Cloud Run functions をデプロイするプロジェクト ID
export PROJECT_ID="{your-project-id}"

# プロジェクト番号を自動取得
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

# 関数をデプロイするリージョン
export REGION="{your-region}"

# 関数名
export FUNCTIONS_NAME="{your-functions-name}"

# 関数が使用するサービスアカウントのメールアドレス
export SERVICE_ACCOUNT_EMAIL="{sql-monitoring-sa@your-project.iam.gserviceaccount.com}"

# Secret Manager に登録した SendGrid API キーのシークレット名
export SENDGRID_API_KEY="secret-sendgridapi-key"

# Secret Manager に登録した Gemini API キーのシークレット名
export GEMINI_API_KEY="secret-geminiapi-key"
4. Cloud Run functions のデプロイ準備が整ったら、実際に Cloud Run functions をデプロイします。このコマンドにより、アプリケーションが Google Cloud 上で動作する環境が構築されます。
gcloud functions deploy ${FUNCTIONS_NAME} \
  --region=${REGION} \
  --project=${PROJECT_ID} \
  --runtime=python39 \
  --trigger-http \
  --no-allow-unauthenticated \
  --entry-point=main \
  --source=src/. \
  --env-vars-file=env.yaml \
  --set-secrets="SENDGRID_API_KEY=projects/${PROJECT_NUMBER}/secrets/${SENDGRID_API_KEY}:latest" \
  --set-secrets="GEMINI_API_KEY=projects/${PROJECT_NUMBER}/secrets/${GEMINI_API_KEY}:latest" \
  --memory=256MB \
  --timeout=180s \
  --service-account=${SERVICE_ACCOUNT_EMAIL}
デプロイコマンドのオプション説明

--runtime=python39: Python 3.9 ランタイムを使用

--trigger-http: HTTP リクエストによるトリガー

--no-allow-unauthenticated: 認証が必要

--entry-point=main: main.py 内の main 関数をエントリーポイントとして指定

--source=src/.: src ディレクトリをソースコードのルートとして指定

--env-vars-file=env.yaml: 環境変数の設定ファイル

--set-secrets: シークレットを取得

--memory=256MB: メモリ割り当て

--timeout=180s: タイムアウト時間（3 分）

--service-account: 実行時に使用するサービスアカウント
5. Cloud Scheduler の設定最後に、定期的にアプリケーションを実行するための Cloud Scheduler の設定について説明します。この設定により、指定したスケジュールに従って自動的に監視レポートが生成されます。
cloud-scheduler.tf
resource "google_cloud_scheduler_job" "sql_monitoring" {
  name        = "sql-monitoring-job"
  description = "Cloud SQL の監視レポートを生成するジョブ"
  schedule    = "0 6,12,18 * * *"  # 6時、12時、18時に実行
  time_zone   = "Asia/Tokyo"

  http_target {
    http_method = "POST"
    uri         = "<Cloud Run functions の URL>"
    oidc_token {
      service_account_email = google_service_account.main.email
    }
  }
}

 4. 実行結果の評価ここからは、実装したシステムの実行結果と、Gemini API による分析の精度について確認していきます。実際に生成されたレポートの内容と、データの正確性について確認します。
まず、システムを実行した結果を確認します。実際に生成されたレポートの内容を紹介します。

3.2.1 で設計したプロンプトと 3.2.2 で実装した前処理により、期待される出力が得られるかを検証します。
期待される出力
メトリクス名が日本語で表示される
HTML テーブル形式で出力される
%表示が全ての値に適用される
各メトリクスの現在値とピーク値が正確に表示される
以上の要件を満たしているか、実際に送られてきたレポートを見て評価します。
生成されたレポートには、各 Cloud SQL インスタンスごとに以下の情報が含まれています。
メトリクス名: CPU 使用率、メモリ使用率、ディスク使用率
現在値: 最新の測定値
ピーク値: その日の最大値
ピーク発生時刻: 最大値が記録された時刻
レポートの結果から、期待される出力要件である
メトリクス名が日本語で表示される
HTML テーブル形式で出力される
%表示が全ての値に適用される

の三つが満たされていることが確認できました。
次に各メトリクスの現在値とピーク値が正確に表示されているかを確認します。

実際のモニタリングデータと比較して、Gemini API による分析が正確に行われているかを確認します。
Gemini API の分析結果: 1 つ目のインスタンスの CPU 使用率のピーク値が 09:15 に 37.4% と表示

実際のモニタリング画面: Google Cloud Console の Cloud SQL の監視画面で確認
実際のモニタリング画面を確認すると、同じく 09:15 に 37.4%のピーク値が記録されており、各メトリクスの現在値とピーク値が正確に表示されていることが確認できます。
このように、Gemini API を使ってメトリクスデータから適切に最大値と発生時刻を抽出し、人間が理解しやすい形式で出力することができました。

 5. さいごに本記事では、Gemini API を使用して Cloud SQL の監視レポートを自動生成するシステムの実装方法を紹介しました。

以下に実現できたことと、Gemini API を活用したメリットをまとめました。

 実現できたことこのシステムの実装により以下が実現できました。
自動データ分析: Cloud Monitoring API から取得したメトリクスデータを Gemini API で自動分析
レポート生成: 現在値とピーク値、発生時刻を正確に抽出
見やすい HTML レポート: 人間が理解しやすい形式での自動レポート生成
運用効率の向上: 手動作業を自動化し、運用担当者の負荷を軽減

 Gemini API の活用メリットGemini API を活用することで、以下のメリットを実現できました。
データ処理の自動化: 複雑なメトリクスデータの分析を AI に委ねることで、開発工数を削減
高精度な分析: 人間の手作業では見落としがちな詳細な分析を自動実行
柔軟な出力形式: HTML 形式でのレポート生成により、見やすい形式での情報提供
スケーラビリティ: 監視対象の増加にも対応可能な柔軟なシステム
Gemini API は、このような運用業務の自動化において非常に強力なツールだと感じました。適切に使用することで運用の作業効率を向上させることができました。
今後も Gemini API に注目し、さらなる活用方法を探っていきたいと思います。
1. はじめに

2. Gemini API について

本記事で使用するモデル

3. Gemini API による運用の効率化

3.1 効率化させる内容

3.2 Gemini API での効率化

3.2.1 プロンプトの設計

3.2.2 精度向上のための処理

3.2.3 Python コードでの実装

Gemini API キーの取得

必要なライブラリ

環境変数の設定

事前データの準備

アプリケーションの実装コード

ローカルでの実行

3.3 システムでの自動化

3.3.1 システム構成

3.3.2 システム構築

サービスアカウントの作成と権限設定

Secret Manager の設定

デプロイ手順

1. 作業ディレクトリの準備

2. ファイルの配置

3. デプロイ用変数の設定

4. Cloud Run functions のデプロイ

5. Cloud Scheduler の設定

4. 実行結果の評価

5. さいごに

実現できたこと

Gemini API の活用メリット

Discussion
