アラートが鳴る、あるいは実行時刻になる。エージェントが調査し、レポートを書きます。
Waveコンソール内で動く、4ステップ固定のワークフローです。トリガー、AIエージェント、レポート、通知。エージェントは組み込みツールでクラスターを読むため、事前に配線しておくものはありません。
4ステップ固定。各ステップは自分で設定します。
ワークフローは自分で描くキャンバスではありません。毎回同じ4ステップが同じ順序で走り、それぞれが何をするかを設定します。トリガーが発火するたびに、ワークフローは独立したセッションとして実行されます。
- 1トリガー
アラート、またはスケジュール。
Alerting にすでにあるアラートを選ぶか、cronスケジュールを指定します。Wave AI Agent 側でアラートを新たに定義する必要はありません。
設定する項目使うアラート、またはcron式とタイムゾーン。
- 2AIエージェント
実際に作業をするエージェント。
定義済みのエージェントから1つを選びます。ペルソナ、システムプロンプト、モデルが一緒についてきて、組み込みのクラスターツールは自動で付きます。
設定する項目どのエージェントを実行するか。
- 3レポート
分析し、そして書き残す。
実行の結果として Markdown か HTML のレポートが出ます。必要であれば、その結論に至った推論も残します。
設定する項目レポート形式、推論を残すかどうか。
- 4通知
任意。どこかへ送ります。
Slackチャンネルか HTTP ウェブフックにレポートを送ります。すでに使っているアラートチャンネルをそのまま再利用するため、配信・再試行・ログもついてきます。
設定する項目送信先チャンネル、または送らない。
ステップの追加・削除・つなぎ替えはできません。意図した設計です。チームの誰でも一目で読めるワークフローになり、今回の実行を前回の実行とそのまま比較できます。
あるいは毎朝、自分で書いた指示のとおりに。
スケジュールのワークフローは、同じ4ステップの前に時計を置いたものです。日次レポートと週次レポートはこうして作られます。
- cron式と、次の実行時刻
分から年まで、指定したタイムゾーンで。いま入力した内容がどう動くか分かるよう、次の4回の実行時刻を下に表示します。
- エージェントが見てよいデータ
ノード、Pod、ワークロード、ストレージ、コスト、GPU。コストレビューならコストとノードだけに絞れて、そうすればエージェントは残りを読みません。
- 指示は自分の言葉で
レポートが何を扱い、どのくらいの長さであるべきか。日次の状態、週次のコスト、容量予測といったプリセットが下書きを埋め、そこから書き換えます。
エージェントはペルソナ、プロンプト、モデルです。
エージェントを一度定義すれば、いくつのワークフローでも使えます。診断エージェントとコストエージェントは同じクラスターを読んでも、まったく違うレポートを書きます。そう指示したからです。
- ペルソナ
- このエージェントが何者か。証拠を重んじるシニアSREと、支出を数えるアナリストでは、同じ再起動パターンの読み方が変わります。
- システムプロンプト
- 見つけた内容をどう扱うか。使った指標を明示すること。対策は1つに絞ること。短く書くこと。
- モデル
- このエージェントがどのLLMで動くか、トークン上限はいくつか。エージェント単位で決めるので、日次サマリーは軽いモデル、障害対応はより強いモデル、という使い分けができます。
すべてのエージェントが同じ3つのツールをプラットフォームから受け取ります。先に立てておくサーバーも、配る資格情報もありません。
- クラスターメトリクスCPU、メモリ、再起動など、Waveがすでに収集している時系列データ。
- Kubernetesの状態ノード、Pod、ワークロードとそのspecを、APIサーバーが報告するそのままで。
- Waveデータベース · SQL読み取りWaveがすでに導き出したもの。サイジング推奨、診断結果、コスト履歴。
ツールは読むだけです。ワークフローはレポートを書き、通知を送るだけで、クラスターを変更しません。
実行ごとにファイルが2つ残ります。
トリガー1回につき実行1回、ワークフロー履歴にそのまま残ります。レポートはエージェントの結論を述べ、thinkingファイルはそこへ至った道筋を述べます。だから検証でき、異論も唱えられます。
これらの画面の内容はコンソール設計案から取ったものです。レポートの形を示すもので、お客様のクラスターで測定した結果ではありません。
モデルは自分で選びます。自前でホストしたものでも。
ホスティングAPIに接続するか、自社クラスター内で動くモデルを指定します。エージェントごとに既定値を上書きできるので、モデルは仕事単位の選択になります。
クラスター内のエンドポイントで十分です。
OpenAI互換のエンドポイントであれば何でも動きます。vLLM、TGI、LocalAI、LiteLLMプロキシ、社内ゲートウェイ。サービスURLを入れるだけです。
クラスターのサービスURLはクラスター内で解決されるため、閉域環境でもモデルベンダーへ出ていく経路は必要ありません。資格情報は書き込み専用で、マスクして表示されます。
片方は障害に反応し、片方は毎朝報告します。
OOMインシデント切り分け
アラートワークロードがメモリを使い切ったとき、障害がまだ続いている間に根本原因を突き止めます。
- トリガー
- アラート — メモリが上限の90%を超過
- AIエージェント
- SRE Diagnoser — 根本原因を突き止め、根拠を示し、対策を提案
- レポート
- Markdown、推論も残す
- 通知
- Slack #sre-oncall
日次クラスターレポート
スケジュールクラスター全体の状態とコストを、朝に1枚でまとめます。
- トリガー
- スケジュール — 毎日09:00
- AIエージェント
- Daily Reporter — スタンドアップ向けに状態とコストを要約
- レポート
- HTML、スタイル付きでダウンロード可能
- 通知
- Slack #platform
Wave AI Agent は2026年Q4に登場します。
早期アクセスを受け付けています。まずどのワークフローを動かしたいか、どのクラスターで使うかをお知らせください。
早期アクセスに登録