すべてを自動化する：Grafana CloudのAIを活用して運用負荷を軽減する方法

CI/CD（継続的インテグレーション／継続的デリバリー）は、私たちがソフトウェアをリリースする方法を劇的に変えました。しかし、コードが本番環境に到達した後の運用作業は、驚くほど手作業のままです。エンジニアは絶えずシステムを監視し、予期せぬ挙動を調査し、どの問題に対応すべきかを判断しています。

そして、ここにAI主導の自動化がもたらす次なるチャンスがあります。

例えば、現在のCI/CDワークフローでは、誰かがパイプラインの画面を更新してキューが進んだかを確認し、別の誰かが「おそらく不安定（Flaky）なだけだろう」と失敗したテストを再実行しています。さらに別のメンバーが今日のビルド時間を先週と比較し、4人目がログを読み、最近のプルリクエストを確認してSlackに状況を投稿する、といったことが行われています。

これには正当な理由があります。障害の原因が曖昧な場合、開発者は作業を中断し、それが無害なノイズなのか、リリースを止めるべき問題なのかを判断しなければならないからです。問題なのは、私たちは「パイプライン」は自動化しましたが、パイプラインが要求してくる「人間の注意力（監視の目）」までは自動化していないということです。

チームがAIを使ってより速く変更を生み出している今日、このギャップはさらに重要性を増しています。DORAの2025年の調査では、AIを「増幅器（amplifer）」と表現しています。AIはソフトウェアデリバリーのスループットを向上させますが、同時にフィードバックループの弱さや下流のボトルネックをも増幅させます。基本的に、デリバリーシステムに投入されるコードの量が増えたからといって、自動的に価値が高まるわけではありません。強力なテスト、明確なフィードバック、そして信頼できるコントロールがなければ、むしろシステムの不安定化を招くことすらあります。

したがって、自動化の次なるチャンスは「決まった手順を実行する新たなスクリプト」を作ることではありません。何が起きているかを監視し、何が「正常」かを理解し、意味のある異常事態（例外）を調査し、エンジニアが行動を起こすために必要な証拠（エビデンス）を提供する「適応型のデリバリー・ループ」を構築することなのです。

Grafana CloudのAI機能は、そのループの構築を支援します。具体的には以下のことが可能です：

• 定期的な運用チェックの自動化
• 本番環境のテレメトリの継続的な監視
• オブザーバビリティデータや連携する開発ツールを横断した異常の調査
• 調査結果のチームへの共有

ここでの目標は、本番環境の運用責任をAIに丸投げすることではありません。監視、トリアージ、調査といった「反復的な作業」の負荷を、責任を手放すことなくAIにオフロード（代替）することです。本記事では、Grafana Assistantの最新アップデート（Automations、Watchers、Workspace機能を含む）、Assistant Investigations、Agent Observabilityを活用して、それを実現する方法をご紹介します。

定期的なリリースチェックを自動化する（Automations）

デリバリーにおけるタスクの多くは予測可能なものです。リリースの前に毎回同じチェックを行い、毎朝同じステータスレポートをまとめ、テストスイートの終了後に決まったシグナルセットを確認します。入力されるデータは変わっても、プロセス自体は決して変わりません。

現在一般提供されている「Assistant Automations」を使用すると、Assistantへのプロンプトを保存し、手動または定期的なスケジュールで実行することができます。実行のたびに専用の会話と履歴が残るため、出力結果が一時的なジョブログに埋もれて消えてしまうことはありません。また、自動化タスクが完了・失敗した時、あるいは承認が必要な時に、Slackチャンネルやダイレクトメッセージで通知するよう設定することも可能です。

例えば、あなたがプラットフォームチームの一員だとしましょう。毎朝の業務開始時に、次のようなプロンプトでリリース準備のブリーフィングをスケジュールすることができます。

「過去24時間のチェックアウトサービスの稼働状況を要約して。新規インシデント、繰り返し発生しているアラート、レイテンシの悪化、異常なエラーパターン、そして未解決の調査をハイライトすること。結果は250文字以内でまとめ、今日対応が必要になりそうな問題を先頭に持ってくること。」

利用できる具体的なデータは、CI/CDシステムや開発ツールをどのようにGrafana Cloudに接続しているかによって異なります。しかし、関連するメトリクス、ログ、コンテキストをAssistantが利用できるようになれば、チームはチェックリストを記憶し、各システムを見回り、チームメンバーのために結果を書き直す手間から解放されます。

これは小さな変化ですが、効果は絶大です。1日を始めるのに必要な情報がすべて揃い、自分でデータをかき集める作業から解放されるからです。繰り返しになりますが、目的はエンジニアの「判断力」を代替することではありません。Automationsを使えば、空のブラウザタブを開いてあちこち探し回るのではなく、最初から「準備されたレポート」を元に判断を下すことができるようになるのです。

デリバリーシステムに「AIの監視の目」を追加する（Watchers）

スケジュールされたレポートは予測可能な作業を処理してくれますが、もう一つの運用負荷、つまり「注意を払うべき変化が起きているかを継続的にチェックする」という作業まではカバーできません。

現在パブリックプレビュー中の「Assistant Watchers」を使えば、常時稼働するエージェントが、指定されたPrometheusとLokiのシグナルを一定間隔で評価してくれます。Watcherに監視すべき対象を説明し、関連するデータソースを選択し、感度を設定し、AI自身では推測できない「運用のコンテキスト（背景情報）」を与えます。すると、Watcherは使用するクエリと、比較基準となるベースラインを自ら調整します。

この「コンテキスト」が非常に重要です。テストの失敗が常にプロダクトの破損を意味するわけではありませんし、始業時の一時的なキューの急増は正常かもしれません。依存関係のアップデートによって、想定内のキャッシュ再構築が一度だけ発生することもあります。有用なWatcherであるためには、単なる「数値のブレ」と「本当の問題」の違いを理解している必要があります。

先ほどのプラットフォームチームの例に戻りましょう。忙しいCIパイプラインのためにWatcherを設定したとします。Grafana Cloudは、ジョブの実行時間、キューのレイテンシ、ランナーの稼働率、テスト結果、再試行回数に関するメトリクスと、対応するビルドログを受け取っています。チームはWatcherに対し、「少数の再試行は正常だが、複数のテストスイートで再試行の増加が継続した場合、または新しいエラーパターンが出現した場合は注意を払う必要がある」と伝えます。

Watcherは実行のたびに、現在の状態とベースラインを比較し、運用者の意図、調整時のメモ、過去の観測結果を考慮します。そして、「正常ok」「警告warning」「クリティカルcritical 」という簡潔な評価を記録し、未解決の懸念事項をランク付けしたリストを維持します。また、すでに報告した内容を記憶しているため、問題が解決していない間に数分おきに同じ通知を送りつけてくる心配もありません。

例えば、プラットフォームチームのWatcherは、チェックアウトのレイテンシが過去2日間で徐々に上昇していることに気づくかもしれません。しかし、エラー率は安定しており、顧客への影響も見られないため、Watcherは本格的な調査（Investigation）は開始しません。その代わりに、観測結果を記録し、短い要約をSlackに投稿して、チームにそのトレンドが注意を払うべきものかどうかを判断する機会を与えます。

これは、静的なしきい値からの大きな進歩です。しきい値は「値がラインを超えたこと」を教えてくれますが、Watcherは「その変化が異常かどうか」「複数のシグナルがそれを裏付けているか」「既知の正常なイベントと一致しているか」まで考慮できます。さらには、「誰かの作業を中断させるほど重要かどうか」まで判断できるのです。Watcherが「これはフラグを立てる価値がある」と判断した場合、証拠に基づいた短い観測結果をSlackに投稿することができます。

先ほどの例で言えば、メッセージには「過去6時間でチェックアウトのレイテンシが20%増加した」という説明があり、裏付けとなる証拠が要約され、関連するダッシュボードへのリンクが添えられます。エンジニアは、この傾向を監視し続けるか、さらに深い調査を開始するかを即座に決定できます。

ノイズではなく、「真の異常」をエスカレーションする

Watcherは意図的に監視範囲を絞っています。Watcherはテレメトリの限定された範囲を観察し、注意を払う価値があるかどうかを判断します。「原因を診断したり、修正案を提示したりするのに十分な情報がある」と見せかけることはしません。

より深い分析が必要だと判断された場合、Watcherは現在一般提供されている「Grafana Assistant Investigations」をトリガーし、システム全体を調査させることができます。Investigationsは、メトリクス、ログ、トレース、プロファイルを横断して仮説を立てて検証し、構造化されたレポートを作成します。「Assistant Workspace」では、その進捗状況を追いかけたり、元になったクエリやパネルを調べたり、除外された要因を確認したり、作業中のAIに追加の指示を与えたりすることができます。

この役割の分離により、非常に有用な運用パターンが生まれます。

• Watcherが継続的かつ低コストに、絞り込まれたシグナルを評価する。
• 挙動が正常な場合や、異常の証拠が弱い場合はエスカレーションしない。
• 独立した、より深い分析が必要な場合のみエスカレーションする。
• Investigationsがシステム全体の証拠を収集し、レビューのために結論を提示する。

例えば、あなたのチームのテスト再試行回数が急増したものの、ビルド時間やランナーの負荷は正常だったとします。Watcherは、その理由を推測することなく変化を報告します。それを受けて開始されたInvestigationは、最初のシグナルだけでなく、ビルドログを調べ、失敗したタイミングを比較し、影響を受けたテストの依存関係への呼び出しをトレースし、他のサービスでも同じ挙動が起きていないかを確認します。

もしチームがMCP（Model Context Protocol）サーバーを通じてGitHubをAssistantに接続していれば、Investigationsは最近のプルリクエスト、コミット、Issue、コードのコンテキストも分析に取り込むことができます。新たなテストの失敗が依存関係の変更後に始まったことを突き止め、影響を受けたコードパスを特定し、その変更とテレメトリを結びつける証拠を提示するかもしれません。そこから、「テスト環境を修正する」「共有の依存関係を隔離する」「チームがさらに調査する間、変更をロールバックする」といった、焦点を絞った次のステップを推奨してくれます。

もちろん、証拠をレビューして何を変更するかを決定するのはエンジニアです。ここでの価値は、問題の原因と考えられる変更（regression）、関連するコンテキスト、そして提案された解決策が「すでに組み立てられた状態」で、エンジニアが判断を下せるという点にあります。

これこそが、AIを活用した今日のデリバリーワークフローにおける「解決」のあるべき姿です。何が起きたかを再構築する時間を減らし、情報に基づいた判断と修正に多くの時間を割くことができるのです。

結果をSlackでチームに共有する

別のタブで静かに待っているだけのインサイト（洞察）では、運用負荷はあまり軽減されません。フィードバックループは、決定を下す責任者の元に届く必要があります。

AutomationsとWatchersは、Slackでチームにプロアクティブに通知を送ることができます。

先ほどのプラットフォームチームの例で言えば、Watcherはチェックアウトのレイテンシが着実に増加していることを投稿し、なぜその傾向を異常だと判断したかを説明し、根拠となるダッシュボードへのリンクを提示します。朝のスタンドアップミーティングで、エンジニアは「この上昇は最近のインフラ変更後に始まったものだ」と即座に認識し、Assistant Investigationsで本格的な調査を開始する価値があると判断します。

Watcherからの通知には、評価結果、それを裏付ける最も強力な証拠、現在進行中の懸念事項の数、そしてWatcherや開始された調査へのリンクが含まれます。スクリーンショットやログの一部をチャンネルに貼り付ける代わりに、エンジニアはコンテキストが保たれたままの「実際の調査画面」を開くことができます。

チームはSlackから直接Assistantと対話することも可能です。メンバーは追加の質問をしたり、関連するダッシュボードを探したり、メトリクスやログをクエリしたり、自分自身のGrafana権限をリンクさせた状態でインシデントの会話を続けることができます。これにより、オブザーバビリティの証拠から離れることなく、チームの既存のワークフローの中で日常的な連携を維持できます。

その結果得られるのは、単に「クリック数が減る」ことだけではありません。「コンテキストを再構築する手間が省ける」のです。通知を受け取った人は、「誰がどのダッシュボードを確認したか」「どの時間枠を見たか」「その結論は一つのノイズ混じりのシグナルに基づいているのではないか」といったことを尋ねる必要がなくなります。調査内容とそのソースは、すでにそこに揃っているからです。

AIエージェントの品質をCIシグナルとして扱う（Agent Observability）

今デプロイしようとしているソフトウェアに「AIエージェント」が含まれている場合、これらの原則はさらに重要になります。

従来のソフトウェアは通常、テストのアサーションが失敗する、プロセスがクラッシュする、レスポンスがスキーマ違反を起こすなど、デリバリーシステムが理解できる方法で失敗します。しかし、AIエージェントの品質低下は、より気づきにくい形で現れることがあります。

プロンプトの変更により、エラーは出ないが回答の有用性が下がる。

• 新しいモデルで品質は向上したが、レイテンシやコストが倍増する。
• ツールの変更により一般的なリクエストにはうまく機能するが、重要なエッジケースで不安定になる。
• 全く同じ入力でも、実行するたびに異なる結果が返ってくる。

近日中に一般提供が開始される「Grafana Agent Observability」は、会話、生成内容、ツール呼び出し、トレース、評価スコア、レイテンシ、トークン使用量、コストをすべてまとめて観測可能にします。また、エージェントのバージョンもカタログ化されるため、プロンプト、モデル、ツールの変更が、時間の経過とともにどのように挙動に影響するかを理解できます。

オフライン実験機能を使用すれば、この可視性をCIに直接組み込むことができます。YAMLまたはJSONで既知のテストシナリオを定義し、既存のテストハーネスやCIジョブから候補となるエージェントに対して実行します。そして、実行結果として得られた試行データ、スコア、トレース、会話履歴、成果物をAgent Observabilityに送信します。実験レポートでは、テストケースごとに結果がグループ化され、候補（新バージョン）とベースライン（現行バージョン）を横並びで比較できます。

先ほどのプラットフォームチームが、カスタマーサポートエージェントのアップデートをロールアウトしようとしていると想像してください。新バージョンを本番環境に採用する前に、現在の本番環境をベースラインとして比較します。実験の結果、「新しいモデルは全体の品質を向上させる一方で、返金に関する会話でリグレッションを引き起こし、レイテンシを30%増加させている」ことがすぐに浮き彫りになり、チームはロールアウトを延期するだけの十分な証拠を得ることができます。

この比較により、単なる「ビルドが成功した」ということだけでは分からない、以下のような疑問に答えることができます。

• 候補はテストスイート全体で品質を向上させたか？それとも平均的に向上しただけか？
• 同じシナリオを複数回実行しても、一貫して成功するか？
• どのテストケースが劣化し、その会話の中で何が起きたか？
• モデルやプロンプトの変更によって、レイテンシ、トークン使用量、コストは増加したか？
• 結果は、チームのリリースクライテリア（基準）をパスするのに十分か？

この実験機能は、スコアと基盤となるエージェントの会話やトレースを結びつけているため、「品質チェックでの不合格」が行き止まりにはなりません。スコアの低かった試行を開き、プロンプトとツールのフローを検査し、評価者（Evaluator）の説明を確認し、ベースラインの挙動と比較することができます。あなたのCIゲートは、単なる「判断の場」であると同時に、「その背景にある証拠への入り口」にもなるのです。

デプロイ後も、オンライン評価機能がライブトラフィックのスコアリングを継続し、品質が低下した際にアラートを発行します。オフラインとオンラインの評価を組み合わせることで、AIエージェントの品質チェックは「1回限りの手動レビュー」ではなく「継続的なデリバリーシグナル」へと変わります。

責任ではなく、「監視の手間」をオフロードする

AIシステムがより自律的になるにつれ、問題はもはや「自動化するかどうか」ではなく、「人間がどこでコントロールを維持すべきか」に移っています。最新のAIはテレメトリを解釈し、可能性の高い原因を特定し、ワークフローを開始することができますが、現場のエンジニアは依然として「なぜその決定が下されたのか」を理解し、重大な結果をもたらすアクションのコントロール権を維持する必要があります。

現場のエンジニアもその可能性には関心を持っていますが、同時に透明性とコントロールを求めています。『Grafana Labs 2026 Observability Survey』では、回答者の92%が「ダウンタイムが発生する前にAIが異常を検知すること」に価値を見出しています。その一方で、AIの自律的なアクションに対しては、他のどのAIオブザーバビリティのユースケースよりも強い懐疑論があり、回答者の95%が「AIがその推論の根拠を説明することが重要だ」と述べています。

AIを活用した効果的なデリバリーシステムは、この調査結果の両面を反映している必要があります。

AutomationsとWatchersは、設定されたスコープと権限の中で実行されます。Watchersは自身の評価、根拠、調整済みのチェック内容、そしてテレメトリの要約を開示します。Assistant Investigationsは、根拠のない答えを返すのではなく、仮説と元のクエリを提示します。接続されたツールは、引き続き権限と承認のコントロールを使用します。そして、重大な変更や最終的なリリース決定については、引き続き「人間」が責任を負います。

重要なのは、CI/CDから人間を排除することではありません。ポーリング、比較、相関関係の分析、要約、ツール間のコンテキストの持ち運びといった「システムが繰り返し実行できる作業」に、あなたの注意力を浪費するのをやめてほしいということです。あなたは、「人間の判断力」が最も価値を発揮するタイミングで、ループに参加すべきなのです。

「一つの退屈なループ」から始めよう

このアプローチの恩恵を受けるために、ソフトウェアのデリバリープロセス全体を再設計する必要はありません。チームがすでに頻繁に行っており、よく理解しているタスクから始めてください。

関連する本番環境のテレメトリをGrafana Cloudに取り込みます。定期的な運用チェックを「Assistant Automation」に置き換えます。何が「正常」で、どのような時にチームを中断させてほしいかを明確に記述して「Watcher」を設定します。意味のある発見をSlackに送信させ、重大な例外事態が発生した場合は、Assistant Workspaceに保存された証拠を使って「Investigation」を開始させましょう。

どこから始めるべきかわからない場合はAssistantで以下のサンプルプロンプトを試してみてください。テキストをニーズに合わせて変更し、チャットウィンドウに直接入力するだけです。

Automation 「平日の毎朝8:00に実行するオートメーションを作成して。過去24時間のチェックアウトサービスの稼働状況を要約し、異常なレイテンシ、エラー率、インフラの変更、未解決の調査をハイライトすること。要約は250文字以内に抑え、今日注意が必要になりそうなものを優先すること。」

Watcher 「チェックアウトサービスを監視し、顧客に影響を与える可能性のある問題をチェックするWatcherを作成して。利用可能なテレメトリ全体から異常なパターンを探し、注意を払う価値のあるものを特定したら私に通知し、なぜそれが重要だと思うのかを説明して。」

もしAIエージェントをリリースする場合は特に不具合を起こしたくないシナリオを対象に小規模なオフライン評価スイートを用意してください。各候補を現在のリリースと比較し、品質、一貫性、レイテンシ、コストをデプロイの判断基準に組み込みましょう。

最初に手掛けるワークフローとして最適なのは、おそらく最も野心的なものではありません。「全員が退屈で、必要不可欠で、あまりにも頻繁に繰り返されていると認める、お馴染みのタスク」こそが最適なのです。そのループを自動化し、人間の判断が依然として重要になるポイントを学び、そこから範囲を広げていってください。

CI/CDは私たちに「再現性のある実行」をもたらしました。AIを活用したオブザーバビリティは、「その実行の周囲にある注意力（監視の目）」をも再現可能なものにしてくれます。それはつまり、作業の中断が減り、より速く答えが得られ、リリースの判断がより明確になり、エンジニアが「永続的な改善」に使える時間が増えることを意味しているのです。

Grafana Cloudは、メトリクス、ログ、トレース、ダッシュボードなどを始める最も簡単な方法です。私たちは、充実した永久無料枠と、あらゆるユースケース向けのプランを用意しています。今すぐ無料でアカウントを作成しましょう！