Grafana社は、Kafkaを用いてLokiを再設計し、コーディングエージェントにオブザーバビリティをもたらすCLIをリリース

原文リンク(2026-04-23)

バルセロナで開催されたGrafanaCON 2026において、Grafana Labs社はGrafana 13を発表した。新たなLokiのKafkaを基盤とするアーキテクチャを取り込みレイヤーに備え、さらにGrafana CloudにおけるAI Observabilityを搭載し、AIシステムをリアルタイムで監視および評価する機能を特徴とする。とりわけ、GCXと呼ばれる新たなCLIが発表され、エージェント型の開発環境内でGrafana Cloudのデータを表出させることを目的として設計された。

従来のLokiのアーキテクチャは、レプリケーションによって高可用性を達成する。すなわち、すべての受信ログ行は3つのインジェスターに送られ、レプリケーション係数は3となる。理論上は十分に単純である。 問題は、重複排除がファイル名に依存している点にある。インジェスターが同一の時間範囲をカバーする場合、同一のファイル名を生成するはずであり、それらの重複は統合される。

従来および現在のLokiのアーキテクチャ

Grafana Labsのスタッフソフトウェアエンジニアであるトレバー・ホイットニー氏は、GrafanaCONでのブリーフィングでその仕組みについて説明した。

分散システムにおいては、インジェスターがわずかにずれ、その時間同期におけるいかなるずれも、ファイル名によってそれらのファイルが重複排除されない結果をもたらします。当社の内部指標によると、実際には、取り込むログの各行につき、平均して2.3倍を保存していることが明らかになりました。すなわち、取り込んだログ1行ごとに、2.3回保存している計算です。

その2.3倍という乗数は抽象的なものではない。それはすべての項目に現れている。すなわち、取り込み時のCPU、メモリの圧迫、ネットワーク費用、オブジェクトストレージの請求額、そしてさらに、重複をその場で照合しなければならないクエリ時にも再び現れる。

新しいアーキテクチャは、取り込み時に複製する戦略を、耐久性層としてのKafkaに置き換えるものである。ログはKafkaに一度だけ書き込まれ、インジェスターはキューからそれを消費し、実効的な複製係数は1に低下する。 さらに、パーティション全体にわたって作業を分散し、並列に実行するよう再設計されたクエリエンジンと組み合わせることで、Grafana社は、集約クエリにおいて、スキャンするデータ量が最大20分の1になり、性能が最大10倍に向上したと主張している。

明確にしておくべきトレードオフがある。Lokiの当初の設計原則は、依存関係を最小限にすることであり、オブジェクトストレージ以外は何も必要としないというものであった。新しいアーキテクチャは、その原則を崩すものである。Whitney氏はこれを率直に認めた。

これまで当社の唯一の依存先はオブジェクトストレージであり、それは当初からこのプロジェクトの目標の一つです。したがって、今回の変更は第二の依存先を導入します。今後、Lokiのいかなる分散構成のインストールにおいても、オブジェクトストレージとKafkaの両方が必要になります。

単一バイナリのデプロイメントは影響を受けない。ローカル環境やホームラボではレプリケーションの調整が不要なため、ファイルシステムやオブジェクトストレージだけで問題なく動作する。しかし、Lokiを大規模に運用する場合は、Kafkaを運用環境に組み込む必要がある。

GrafanaCONの開催中、AI主導のワークフローにオブザーバビリティを統合するためのエージェント対応CLIであるGCXが、パブリックプレビューとして公開された。前提は単純である。現在、多くのエンジニアはClaude Code、Cursor、またはGitHub Copilotの内部で1日の大半を過ごしており、本番環境で何かが故障した場合、ワークフローはコンテキストの切り替えを強いる。すなわち、Grafanaへ移動し、ダッシュボードを経由し、エディタに戻り、その後、修正が機能したかを確認するため再びGrafanaに戻る流れである。GCXはその循環を統合するよう設計されている。

GCXの取り組みを率いたWard Bekker氏は、ライブデモの中で、CLIツールを採用した理由を説明した。

CLIはこれまで時代遅れになったことはないが、現在はとくにエージェント型コーディングツールの影響で、さらに注目を集めています。コマンドライン上でCLIをCursorやClaude Codeと組み合わせて使用すると、きわめて効果的であると多くの人が認識しています。

Bekker氏は代表的なシナリオを示した。すなわち、シンセティックモニタリングのチェックが電子商取引の注文フローにおける障害を検知し、Grafana Assistantが自動化された根本原因分析する。GCXはその分析結果を関連するソースファイルとともにClaude Codeに取り込み、Claude Codeは修正案を提示し、それを適用する。その後、GCXがシンセティックモニタリングの指標を直接照会し、復旧を確認する。ブラウザのタブは不要である。

Grafana Labs社は、単一の統合モデルに賭けていない。同社のチームは、GCXをCLIとして提供する一方で、リモートMCPサーバーも並行して開発している。それぞれ異なる利用者層とユースケースがあり、支援する価値があるとの見解に基づくのである。

これらの発表は、Grafana 13の発表と並行して行われた。Grafana 13は、動的ダッシュボードを一般提供とし、Gitベースのワークフロー対応を追加し、データソースのエコシステムを170以上の統合へと拡大するものである。 さらに、Grafana Labs社は、本番環境でLLM搭載アプリケーションを監視するチーム向けに、AI Observability製品をパブリックプレビューとして公開した。

Grafana 13およびLokiのアップデートは現在利用可能である。GCXはパブリックプレビュー段階にある。AI Observabilityソリューションも、Grafana Cloudにおいてパブリックプレビューとして提供されている。