◉ANTIGRAVITY LABEN
記事一覧/連携・プラグイン
⬡ 連携・プラグイン/2026-03-29中級

Antigravity × Prometheus + Grafana — AIエージェントでアプリケーション監視基盤を自動構築する

Antigravity のAIエージェントを活用して Prometheus と Grafana によるアプリケーション監視基盤を構築する方法を解説。メトリクス収集・アラート設定・ダッシュボード作成までをステップバイステップで紹介します。

antigravity435prometheusgrafanamonitoring5observability17devops4

取り組みの背景 — なぜアプリケーション監視が重要なのか

アプリケーションを本番環境にデプロイした後、「動いているはず」という感覚だけで運用していませんか。実際のところ、レスポンスタイムの悪化やメモリリーク、予期しないエラーの急増といった問題は、ユーザーからのクレームが届くまで気づけないケースが少なくありません。

Prometheus と Grafana を組み合わせた監視基盤は、こうした問題をリアルタイムに検知し、障害の予兆を可視化するための業界標準のソリューションです。しかし、設定ファイルの記述やダッシュボードの設計には一定の知識と手間が必要でしました。

ここで Antigravity の AI エージェントが力を発揮します。設定ファイルの自動生成、アラートルールの策定、Grafana ダッシュボードの JSON 定義まで、AI に指示を出しながら効率的に構築できるのです。

ここではAntigravity を使って Prometheus + Grafana 監視基盤をゼロから構築する手順を、実際のコード例とともに解説します。

Prometheus と Grafana の基本アーキテクチャ

監視基盤の全体像を理解しておくと、各コンポーネントの役割が明確になります。

Prometheus はプル型のメトリクス収集システムです。監視対象のアプリケーションが /metrics エンドポイントを公開し、Prometheus が定期的にスクレイピング（データ取得）します。収集したメトリクスは時系列データベースに格納され、PromQL というクエリ言語で検索・集計できます。

Grafana は収集したメトリクスを可視化するダッシュボードツールです。Prometheus をデータソースとして接続し、グラフ・ゲージ・テーブルなどのパネルを組み合わせて直感的な監視画面を作成できます。

基本的なデータフローは以下の通りです。

  • アプリケーションがメトリクスを /metrics エンドポイントで公開
  • Prometheus が定期的にスクレイピングしてデータを蓄積
  • Grafana が Prometheus に PromQL でクエリを投げて可視化
  • Alertmanager がしきい値超過時にSlack・メール等で通知

Antigravity でプロジェクトをセットアップする

まず、Antigravity で監視基盤プロジェクトを立ち上げましょう。Antigravity のターミナルで以下のコマンドを実行します。

# プロジェクトディレクトリの作成
mkdir monitoring-stack && cd monitoring-stack
 
# Docker Compose ファイルと設定ディレクトリの準備
mkdir -p prometheus grafana/provisioning/datasources grafana/provisioning/dashboards

次に、Antigravity の AI エージェントに Docker Compose ファイルの生成を依頼します。エージェントへの指示例は次の通りです。

Prometheus, Grafana, Alertmanager を含む Docker Compose ファイルを作成してください。
Prometheus は localhost:9090、Grafana は localhost:3000 でアクセスできるようにしてください。
ネットワークは monitoring という名前のブリッジネットワークを使用します。

AI エージェントが生成する docker-compose.yml は以下のようになります。

# docker-compose.yml
# Prometheus + Grafana + Alertmanager の監視スタック
version: "3.8"
 
services:
  prometheus:
    image: prom/prometheus:v2.53.0
    container_name: prometheus
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/alert-rules.yml:/etc/prometheus/alert-rules.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
    networks:
      - monitoring
    restart: unless-stopped
 
  grafana:
    image: grafana/grafana:11.1.0
    container_name: grafana
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=your-secure-password
    networks:
      - monitoring
    restart: unless-stopped
 
  alertmanager:
    image: prom/alertmanager:v0.27.0
    container_name: alertmanager
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"
    networks:
      - monitoring
    restart: unless-stopped
 
volumes:
  prometheus_data:
  grafana_data:
 
networks:
  monitoring:
    driver: bridge

Docker を使ったコンテナ開発環境の構築に慣れていない方は、先にそちらの記事を確認しておくとスムーズです。

Node.js アプリケーションにメトリクスを組み込む

監視対象のアプリケーションに Prometheus 用のメトリクスエンドポイントを追加します。Node.js（Express）の場合、prom-client ライブラリを使うのが最も一般的です。

Antigravity のエージェントに以下のように指示します。

Express アプリに prom-client を使って /metrics エンドポイントを追加してください。
HTTP リクエストの総数、レスポンスタイムのヒストグラム、アクティブ接続数のゲージを計測します。

生成されるコードの例は以下の通りです。

// src/metrics.ts
// Prometheus メトリクス定義とエンドポイント設定
import { Registry, Counter, Histogram, Gauge, collectDefaultMetrics } from "prom-client";
 
// カスタムレジストリを作成（デフォルトメトリクスと分離可能）
const register = new Registry();
 
// Node.js のデフォルトメトリクス（CPU、メモリ、GC等）を自動収集
collectDefaultMetrics({ register });
 
// HTTP リクエスト総数カウンター
export const httpRequestsTotal = new Counter({
  name: "http_requests_total",
  help: "Total number of HTTP requests",
  labelNames: ["method", "route", "status_code"],
  registers: [register],
});
 
// レスポンスタイムのヒストグラム（秒単位）
export const httpRequestDuration = new Histogram({
  name: "http_request_duration_seconds",
  help: "Duration of HTTP requests in seconds",
  labelNames: ["method", "route", "status_code"],
  buckets: [0.01, 0.05, 0.1, 0.3, 0.5, 1, 2, 5],
  registers: [register],
});
 
// アクティブ接続数のゲージ
export const activeConnections = new Gauge({
  name: "active_connections",
  help: "Number of active connections",
  registers: [register],
});
 
export { register };

続いて、Express のミドルウェアとしてメトリクスを収集します。

// src/middleware/metricsMiddleware.ts
// リクエストごとにメトリクスを記録するミドルウェア
import { Request, Response, NextFunction } from "express";
import {
  httpRequestsTotal,
  httpRequestDuration,
  activeConnections,
} from "../metrics";
 
export function metricsMiddleware(
  req: Request,
  res: Response,
  next: NextFunction
) {
  // アクティブ接続数を増加
  activeConnections.inc();
 
  // レスポンスタイム計測開始
  const end = httpRequestDuration.startTimer();
 
  res.on("finish", () => {
    // リクエスト完了時にメトリクスを記録
    const route = req.route?.path || req.path;
    const labels = {
      method: req.method,
      route,
      status_code: res.statusCode.toString(),
    };
 
    httpRequestsTotal.inc(labels);
    end(labels); // ヒストグラムにレスポンスタイムを記録
    activeConnections.dec();
  });
 
  next();
}
// src/app.ts
// Express アプリケーションのエントリポイント
import express from "express";
import { register } from "./metrics";
import { metricsMiddleware } from "./middleware/metricsMiddleware";
 
const app = express();
 
// メトリクスミドルウェアを全ルートに適用
app.use(metricsMiddleware);
 
// /metrics エンドポイント（Prometheus がスクレイピングする）
app.get("/metrics", async (_req, res) => {
  res.set("Content-Type", register.contentType);
  res.end(await register.metrics());
});
 
// 期待する出力: curl http://localhost:4000/metrics
// # HELP http_requests_total Total number of HTTP requests
// # TYPE http_requests_total counter
// http_requests_total{method="GET",route="/api/users",status_code="200"} 42
// ...
 
app.listen(4000, () => {
  console.log("Server running on port 4000");
});

Prometheus のスクレイピング設定

Prometheus がアプリケーションのメトリクスを収集するための設定ファイルを作成します。

# prometheus/prometheus.yml
# Prometheus のグローバル設定とスクレイピングターゲット
global:
  scrape_interval: 15s      # 15秒ごとにメトリクスを取得
  evaluation_interval: 15s   # 15秒ごとにアラートルールを評価
 
# アラートルールファイルの読み込み
rule_files:
  - "alert-rules.yml"
 
# Alertmanager の接続先
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "alertmanager:9093"
 
# スクレイピング対象の定義
scrape_configs:
  # Prometheus 自身の監視
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
 
  # Node.js アプリケーションの監視
  - job_name: "node-app"
    static_configs:
      - targets: ["host.docker.internal:4000"]
    metrics_path: "/metrics"
    scrape_interval: 10s  # アプリは10秒間隔で取得

scrape_interval はメトリクスの取得間隔です。短くするほどリアルタイム性が増しますが、負荷も上がるため、アプリケーションの特性に合わせて調整してください。

アラートルールの設定

障害を早期に検知するためのアラートルールを定義します。Antigravity のエージェントに「本番環境で一般的なアラートルールを作成して」と指示すると、実用的なルールセットを生成してくれます。

# prometheus/alert-rules.yml
# アプリケーション監視のアラートルール定義
groups:
  - name: application-alerts
    rules:
      # 高エラーレート検知
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status_code=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))
          > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "5xx エラー率が 5% を超過"
          description: "過去5分間のエラー率: {{ $value | humanizePercentage }}"
 
      # レスポンスタイム悪化検知
      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          ) > 1.0
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "P95 レスポンスタイムが 1秒 を超過"
          description: "現在の P95 レイテンシ: {{ $value }}秒"
 
      # メモリ使用量アラート
      - alert: HighMemoryUsage
        expr: |
          process_resident_memory_bytes / (1024 * 1024) > 512
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "メモリ使用量が 512MB を超過"
          description: "現在のメモリ使用量: {{ $value }}MB"

for パラメータは、条件が継続する期間を指定します。一時的なスパイクでアラートが発火しないよう、2〜5分程度の猶予を設けるのがベストプラクティスです。

Grafana ダッシュボードの自動プロビジョニング

Grafana を起動するたびに手動でデータソースやダッシュボードを設定するのは非効率です。プロビジョニングファイルを使って自動化しましょう。

# grafana/provisioning/datasources/prometheus.yml
# Grafana データソースの自動設定
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false

ダッシュボードの JSON 定義も Antigravity のエージェントに生成させることができます。エージェントへの指示例はこちらです。

Grafana ダッシュボード JSON を作成してください。以下のパネルを含めます:
1. HTTP リクエスト率（リクエスト/秒）の時系列グラフ
2. エラー率（5xx / 全リクエスト）のゲージ
3. P50 / P95 / P99 レスポンスタイムの時系列グラフ
4. アクティブ接続数のスタットパネル

生成されるダッシュボード定義（抜粋）は以下のようになります。

{
  "dashboard": {
    "title": "Application Monitoring",
    "panels": [
      {
        "title": "Request Rate (req/s)",
        "type": "timeseries",
        "targets": [
          {
            "expr": "sum(rate(http_requests_total[1m]))",
            "legendFormat": "Total Requests/s"
          }
        ],
        "gridPos": { "h": 8, "w": 12, "x": 0, "y": 0 }
      },
      {
        "title": "Error Rate",
        "type": "gauge",
        "targets": [
          {
            "expr": "sum(rate(http_requests_total{status_code=~\"5..\"}[5m])) / sum(rate(http_requests_total[5m])) * 100"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "thresholds": {
              "steps": [
                { "color": "green", "value": 0 },
                { "color": "yellow", "value": 1 },
                { "color": "red", "value": 5 }
              ]
            },
            "unit": "percent"
          }
        },
        "gridPos": { "h": 8, "w": 12, "x": 12, "y": 0 }
      }
    ]
  }
}

より高度なオブザーバビリティ（トレース・ログの統合）については、Antigravity × OpenTelemetry: AI 駆動オブザーバビリティパイプライン構築で詳しく解説しています。

監視スタックの起動と動作確認

すべての設定ファイルが揃ったら、Docker Compose で監視スタック全体を起動します。

# 監視スタックをバックグラウンドで起動
docker compose up -d
 
# 各コンテナの状態を確認
docker compose ps
 
# 期待する出力:
# NAME          IMAGE                       STATUS
# prometheus    prom/prometheus:v2.53.0     Up 10 seconds
# grafana       grafana/grafana:11.1.0      Up 10 seconds
# alertmanager  prom/alertmanager:v0.27.0   Up 10 seconds

起動後、以下の URL でそれぞれのサービスにアクセスできます。

  • Prometheus: http://localhost:9090 — PromQL クエリの実行、ターゲットの状態確認
  • Grafana: http://localhost:3000 — ダッシュボードの閲覧（初期ユーザー: admin）
  • Alertmanager: http://localhost:9093 — アラートの確認・サイレンス設定

Prometheus の「Status > Targets」画面で、node-app ターゲットが UP 状態になっていれば、メトリクスの収集が正常に動作しています。

まとめ

Antigravity の AI エージェントを活用することで、Prometheus + Grafana による監視基盤の構築を大幅に効率化できます。設定ファイルの生成、アラートルールの策定、Grafana ダッシュボードの JSON 作成まで、AI がサポートしてくれるため、監視の専門知識が少なくても本格的なモニタリング環境を構築できるのが大きなメリットです。

監視は「あったほうがいい」ではなく「なければ障害に気づけない」ものです。この記事を参考に、まずは開発環境で Docker Compose を使った監視スタックを立ち上げてみてください。小さく始めて、運用しながらアラートルールやダッシュボードを育てていくのが成功への近道です。

CI/CD パイプラインとの統合で監視のデプロイまで自動化したい方は、Antigravity × GitHub Actions 上級CI/CDパイプライン構築も参考になるでしょう。また、本記事の内容

シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ（¥150）で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

⬡ 連携・プラグイン2026-04-23
Antigravity の AI エージェントを Langfuse で観測する — 本番投入前にやっておきたい可視化設計
Antigravity で組んだ AI エージェントを本番に出す前に、Langfuse を使ってトレース・トークン消費・コストを可視化する設計を、実際に動く Python コードと失敗談付きで解説します。
⬡ 連携・プラグイン2026-03-27
Antigravity × OpenTelemetry で可観測性を組み立てる — 計装・サンプリング・カーディナリティ・AI異常検知の実運用メモ
Node.js バックエンドに OpenTelemetry を導入し本番運用した記録。計装オーバーヘッドの実測、テールサンプリング設定、カーディナリティ爆発の回避、AI異常検知を承認制で運用する設計までをまとめました。
⬡ 連携・プラグイン2026-07-13
無人ランのログを SQLite に流し込み、失敗を横断で数える
Antigravity CLI を無人スケジュールで回すと、ランごとに JSON Lines のログが溜まっていきます。ファイルを grep で追うのをやめ、小さな SQLite に取り込んで「どのステップがいつ落ちるか」を1本のクエリで数える方法を、取り込みスクリプトと診断 SQL、実際の集計結果ごと共有します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →