要約

  • Gravwellは調査や運用点検を担うエージェントのプレビューを発表し、Community Editionを含む各エディションに提供する。
  • 現行文書では、対話中の変更確認と無人フローの実行を区別している。フローが先へ進んでも、AI分析が成功したとは限らない。

画面上で一度うまく動いた調査を、そのまま夜間の自動処理に移せるとは限らない。変わるのはスケジュールだけではない。エージェントが変更の前に人へ尋ねられるかどうかも変わる。Gravwellの新しいプレビューを評価するなら、この違いを機能一覧より先に確認したい。

同社は9月9日の製品ブログで5.10を紹介し、翌10日に発表文を出した。Case Agentは分析担当者のクエリー作成や実行を支援し、Alert Triage Agentはアラートに関する証拠を集めて初期報告を作る。Audit Agentの役割は、環境を変更せずに健全性を調べることだ。これらを一括して「自律的な事故対処」と受け取る根拠はない。

AI Agent PreviewキットはCommunity Editionを含む各エディションで利用でき、別の上位AI専用枠に限定されない。ただし、現在5.10.1と表示される文書はAIサービスをベータと位置付けている。利用可能であることは、個々の本番環境で効果が実証されたこととは違う。

確認画面がなくても、権限は消えない

現行のエージェント文書では、エージェントは指示、許可されたツール、多段階処理の手順図で構成される。チャットで読み取り専用ツールを使う際は停止しない。一方、クエリーの保存、マクロの作成、アラートの更新など、変更を伴うツールは承認を求める。利用者は一回だけ認めるほか、その会話の残りについて同じツールを許可できる。

フローから呼び出されたエージェントは、途中で利用者に尋ねられない。ツール呼び出しは承認の表示なしで実行される。これは権限の迂回ではない。実行ユーザーの権限が上限となり、エージェントの定義でさらに対象ツールを絞れる。つまり、無人運用に書き込みツールを渡す時点で、承認を前倒ししている。

アクセス制御の説明も条件付きで読む必要がある。CBACという機能単位のアクセス制御を有効にすると、一般ユーザーは原則として何も許可されていない状態から始まり、ユーザーや所属グループへの付与で機能とデータタグにアクセスする。管理者はCBACの制約を受けない。「権限機能がある」だけでは、実環境が最小権限になっているとは判断できない。

先へ進んだ処理が渡すもの

Logbotノードの文書によれば、AI APIでエラーが起きてもフローは後続ノードへ進む。エラーは出力変数に入り、ログにも記録される。また、送信する入力の既定上限は65,536バイトで、超過分は警告付きで切り詰められる。この上限を、ツールで取得する全データやモデルの文脈全体の上限に読み替えてはいけない。

処理を止めない設計と、有効な調査結果があることは別だ。後続の通知や判断は、正常な報告とエラーを区別し、入力の欠落も考慮する必要がある。これは文書から導く運用上の確認点であり、特定の顧客事故を報告しているわけではない。

さらに、顧客の環境に対してツールを動かす場所と、モデルが処理する場所は一致するとは限らない。AI文書は、メッセージと添付検索記録を設定された接続先へ送ると説明する。Gravwellのホスト型サービスについては、学習には使わないとする一方、メモリーやログに残る可能性や担当者が確認する可能性も記している。互換性のある第三者または自社運用モデルの接続先を選ぶこともできる。

各エディションでの提供は無制限利用でもない。Gravwellのホスト型AIでは会話数や語数にライセンス上の制限があり、外部サービスならその条件が適用される。分析工数、誤検知、モデル総費用について、ここで確認した公開資料は個別顧客の実績を示していない。証拠収集を減力化する可能性はあるが、権限と異常時の扱いを決める仕事までなくなるわけではない。