Grafana Assistantによるスマートなオンボーディングと観測計画：オブザーバビリティを「最初から」組み込む方法
月曜日の午後。担当している機能の実装もほぼ終わり、ホッと一息ついたところです。しかし、チケットの一番下には「監視の追加」というタスクが手つかずのまま残っています。
もちろん、やるべきだとは分かっています。しかしスプリントの最終日は明日。チーム内にオブザーバビリティの専門家はおらず、何を測定すべきか、ましてやそのためのPromQLをどう書くかを考えるだけでも、ひとつの大きなプロジェクトのように感じてしまいます。そして結局、「まあ、壊れたら追加しよう」といつものように後回しにしてしまうのです。
厄介なことに、そういう時に限って、数週間後の火曜日の深夜2時といった最悪のタイミングで障害は起きるものです。対象は自分が担当しているサービスですが、今回は頼れるダッシュボードも有用なシグナルもありません。プレッシャーの中で、当てずっぽうの調査を強いられることになります。午後の数時間を節約するために監視の実装をスキップした結果、夜の睡眠を奪われ、長引くストレスフルな障害対応に追われることになるのです。
実際のところ、オブザーバビリティが後回しにされがちなのは、エンジニアが怠慢だからではありません。それが「専門家の領域」であり、事前に計画するのが難しいと考えられているからです。しかし、ソフトウェア開発のスピードが劇的に変化している今、その前提は見直す価値があります。
オブザーバビリティは、開発の最後に「取って付けたように」追加するものではありません。ソフトウェアの設計から運用に至る、すべての段階に組み込まれるべきものです。そしてGrafana Assistantを活用すれば、社内にオブザーバビリティの専門家がいなくても、どんなチームでもそれを現実のものにすることができます。
本記事では、その最初の一歩である「計画」フェーズにおいて、オブザーバビリティを自然に組み込む具体的な方法をご紹介します。
Grafana Assistantの紹介 — OSSが「最強の切り札」になる理由
オブザーバビリティを最初から組み込む方法に入る前に、Grafana Cloudに組み込まれたコンテキスト対応のAIエージェント「Grafana Assistant」についておさらいしておきましょう。やりたいことを自然言語で入力するだけで、Assistantは実際のテレメトリデータに対して、クエリの実行、ダッシュボードのドラフト作成、適切な画面へのナビゲート、調査のサポートといったアクションを実行してくれます。
これにより、どんなエンジニアにとってもオブザーバビリティが一気に身近なものになります。たとえば、「アプリケーションの不具合の原因を突き止めたいが、PromQLを学ぶ時間がなかった」という人でも、「このサービスのエンドポイント別のエラー率を表示して」と入力するだけで、数秒で答えにたどり着くことができます。
そして、Assistantが他のAIツールと一線を画す最大の理由が、「オープンソース（OSS）であること」がチート級の強みになっている点です。Grafana、Prometheus、Loki、Tempo、OpenTelemetryは完全にオープンな標準技術であり、世界中で使われ、ドキュメントも網羅されています。つまり、LLM（大規模言語モデル）はすでに、それらのクエリ言語やルール、ベストプラクティスを学習し尽くしているのです。あなたが言葉を1文字入力する前から、その専門知識はすでにモデルに組み込まれています。クローズドで独自のツールではこうはいきませんが、オープンスタンダードだからこそこの恩恵を無料で享受できるのです。
Assistantはこうした強力な基盤の上に成り立っており、さらに「あなたの環境（データソース、ダッシュボード、今見ているGrafanaのページなど）」の文脈を理解します。つまり、OSSコミュニティが持つ膨大な集合知を、自社のシステム構成にそのまま適用できるということです。専任のオブザーバビリティチームがいないことは、もはや言い訳になりません。オブザーバビリティは「最後に付け足すもの」から「一番最初に考えるもの」へと変わります。
最近では、この作業は「Grafana Assistant Workspace」で行われることが増えています。これは、より長い対話や複雑なワークフローのために専用設計された、画面全体を使うAIファーストな体験です。サイドバーやダッシュボード、個別のレポートを行き来する代わりに、Workspaceは会話、グラフの出力、調査のログを1つの画面にまとめてくれるため、計画から実装へと進む際にも集中力を切らすことがありません。
ただし、1つ注意点があります。白紙の状態から計画が始まることはめったにありません。多くの場合、新たに開発する機能やサービスは、すでに存在するシステムと連携することになりコードの半分は他の誰かが書いたものです。そのため、オブザーバビリティを適切に計画するには2つのステップを踏む必要があります。まず「現在何が動いているかを把握すること」、そして次に「初日からオブザーバビリティが組み込まれた新しいコンポーネントを設計すること」です。それぞれ詳しく見ていきましょう。
ステップ1：既存システムへのオンボーディング（キャッチアップ）
計画がゼロから始まることはほぼありません。何かを新しく追加する前に、まず追加先のシステムを理解する必要があります。そして、まさにこのフェーズで、オブザーバビリティに対する多くの労力がひっそりと消え去っています。だからこそ、最初のステップは「オンボーディング」なのです。
これが実際の現場でどのように役立つのか、仮想のシナリオを見てみましょう。
あなたは数十のサービスを担当する新しいチームに配属されて1週間が経ちました。どのサービスもあなたが構築したものではありませんが、お約束のようにすでに何かが壊れ始めています。あなたはシステム構成も、どのチームがどのサービスを管理しているのかも、役立つログがどこにあるのかも知りません。通常であれば、Slackの過去ログを何日もかけて掘り返し、全体像を知っている数少ない古参メンバーに質問して回るところですが、もうその必要はありません。
代わりに、Assistantを使って一気にキャッチアップしましょう。Assistantを開き、本来ならシニアエンジニアに聞くようなことを尋ねるだけです。 「チェックアウト周りのサービス関係をマッピングして、今パフォーマンスが低下しているものを教えて」Assistantはステップバイステップで作業を進め、Knowledge Graph（サービス、依存関係、シグナルのつながりを示すGrafana Cloudのリアルタイムマップ）からコンテキストを抽出します。メトリクスが羅列された画面を睨みつける代わりに、何が何と通信し、実際にどこで問題が起きているかという全体像がすぐに掴めます。
こうした初動の圧倒的なスピードアップこそ、Assistantを導入したチームが高く評価しているポイントです。
「私たちがオンボーディングをしていた2〜3年前にこのツールがなかったのが本当に悔やまれますね。当時の質問の半分はおそらく削減できたはずです」 — Chris Carter氏（OutSystems、リードソフトウェアエンジニア）
さらに掘り下げていくと、本当の問題は「オブザーバビリティ自体に抜け漏れがあること」だと気づきます。重要なサービスなのにレイテンシのダッシュボードがない、誰もエラーメトリクスをグラフ化していない、といった具合です。そこで、その場ですぐにそのギャップを埋めてしまいましょう。「チェックアウトのエラー率とp99レイテンシを表示して」と指示すれば、Assistantは適切なデータソースを見つけ、PromQLとLogQLを書き、チャット内に直接ライブパネルを表示してくれます。保存する前に実際のデータで事前確認ができるのです。「これをダッシュボードにして」と指示すれば、ダッシュボード作成モードに移行し、パネルを構築し、$serviceのような変数を追加し、リンク付きでGrafana Cloudに直接保存してくれます。
この例でAssistantが特に優れているポイントは以下の通りです：
- 自然言語からPromQL、LogQL、TraceQLを生成: クエリが組み立てられる過程を見ることができるため、作業しながらスタックの書き方を学べます。
- チャット内のライブパネル: 変更を保存する前に実際のデータを確認できます。Assistantの提案が正しいかどうかを当てずっぽうで判断する必要はありません。
- ダッシュボード作成モード: パネル、変数、レイアウトを「言葉で説明するだけ」で構築・編集できます。
- 既存リソースの@メンション: 既存のダッシュボード、データソース、クエリをメンションして、今あるリソースをベースに指示を出せます。
最も素晴らしい点は、Knowledge Graphの確認からダッシュボードの抽出、ギャップの発見に至るこの一連のプロセス全体を「再現可能」にできることです。Assistantの「スキル」機能を使えば、/onboard-serviceのような再利用可能なスラッシュコマンドを作成できます。これにより、次に入社する新メンバーは数日ではなく数分でシステムを理解できるようになり、苦痛だった最初の1週間を、きれいに舗装された道に変えることができるのです。
「オンボーディングにかかる時間を約1週間節約できました。ダッシュボード作成にかかる時間も、半分から3分の1には短縮されたと思います」 — Mark Cicoria氏（Transmute Data）
ステップ2：監視の「抜け漏れ」を生まないための新機能計画
すでに稼働しているシステムを理解したら、いよいよ新しいコンポーネントの計画です。そしてこここそが、最初からオブザーバビリティを組み込むことが最も威力を発揮する場面です。状況把握で活躍したのと同じAssistantが、サービスを新設する「前」の段階でさらに役立ちます。
何を測定するかを決め、形にする 設計段階で、「新しい決済サービスでは何を監視すべきか？」と尋ねてみてください。AssistantはRED（Rate、Errors、Duration）やUSE（Utilization、Saturation、Errors）といった実績のある定石に基づいて、どのシグナルが重要で、「正常」な状態がどうあるべきかを教えてくれます。つまり、経験豊富なSREに頼らざるを得なかったような専門的なアドバイスをAIが提供してくれるのです。
次に、その計画をGrafanaのコアである「ダッシュボード（チーム全体が状況を把握・推論するための共通ビュー）」へと変換します。歴史的に見ても、ダッシュボードを正しく設定するのは最も専門知識と忍耐が要る作業でした。しかしダッシュボード作成モードを使えば、1行のコードをデプロイする前に、Assistantがチャット内で面倒な作業をすべて片付けてくれます。クエリを書き、パネルを配置し、変数を追加して、単一のダッシュボードがあらゆるインスタンスや環境に対応できるように設定します。かつては数週間かかっていたスターターダッシュボードが、サービスがデプロイされた瞬間にすでに用意されているのです。
もしすでにAssistantを有効にしている環境であれば、以下のリンクから今すぐこのプロンプトを試してみることができます。 「新しい決済サービス用の初期ダッシュボードを作って。エンドポイントごとのリクエストレート、エラーレート、p99レイテンシを表示し、$environment 変数を設定して。」と指示するだけです。
アラートの対象を何にするか決めることも、同じ会話の中で行えます（ただし、アラートルールやSLO自体のプロビジョニングは、これまで通りIaCやGrafana Cloud UIを介して行うのがベストです）。Assistantは「何をアラートにすべきか」の判断を支援し、実際のプロビジョニングは既存のワークフローが担います。
スタック全体を連携させる オブザーバビリティに必要な情報がGrafanaの中だけで完結することは稀です。必要なコンテキストは、ソースコード、プルリクエスト、過去のインシデント履歴などあちこちに分散しています。そこで「MCPサーバー」の出番です。 AssistantをGitHub、Jira、PagerDutyなど普段使っているツールに接続すれば、サービスのコードを読み取って監視すべきポイントを提案させたり、最近のデプロイ履歴と照らし合わせたり、過去のインシデントを呼び出したりといった作業が、すべて同じチャット画面から行えるようになります。
これを、必要なツールを自動承認する「スキル」と組み合わせれば、計画のフローはスタック全体をカバーします。インシデントが起きた後に慌てて付け足すのではなく、システムの全体像を見据えた上で、最初からオブザーバビリティが設計されるようになるのです。
成果：障害発生時の劇的なスピード解決
さて、冒頭でお話しした「午前2時の呼び出し」の話に戻りましょう。しかし今回は違います。オブザーバビリティが最初から組み込まれていたからです。
計画時に作ったダッシュボードを見れば、何が起きているかは一目瞭然です。チームで設定しておいた「スキル」のおかげで、ランブック（対応手順書）も1コマンドで呼び出せます。さらに、AssistantがMCPを通じて他のツールと連携しているため、スパイクの原因となった最近のデプロイや関連するインシデントについても、質問一つで確認できます。
自然言語で「過去1時間の間にチェックアウト周りで何が変更されたか？」と尋ねるだけです。プレッシャーの中で焦って手動でPromQLを書く必要はもうありません。
これこそが、オブザーバビリティが本来あるべき姿への回帰、つまり「最初から組み込まれている状態」です。設計時の数分や、いくつかのスキルの設定など、日々の業務の中で少しずつ分散して行っておいた事前の努力が複利のように働き、スプリント中の最悪の夜に、劇的に素早い解決をもたらしてくれるのです。
Grafana Cloudは、メトリクス、ログ、トレース、ダッシュボードなどを始める最も簡単な方法です。私たちは、充実した永久無料枠と、あらゆるユースケース向けのプランを用意しています。今すぐ無料でアカウントを作成しましょう！