恒久的なアクセス権限はゼロ
本番環境への恒久的な書き込み権限は、一切付与しません
AIエージェントに本番環境への恒久的な書き込み権限を与えるのは悪手です。私たちもそう考えます。
エージェントは内部の認証情報ブローカーを介して、対象タスクのみにスコープされた短命のジャストインタイム トークンを取得します。タスクが完了すれば認証情報は失効。常設の権限は持たず、エージェントが侵害されても影響範囲は生じません。
CloudOps、FinOps、SecOpsのために設計
私たちが対話するエンジニアリングチームは、いずれも分断されたシグナルに埋もれています。監視ツールはPodのクラッシュを通知し、FinOpsツールはSnowflakeコストの急増を伝え、セキュリティスキャナーはポートの開放を警告する。 しかし「壊れたことを知る」のは仕事のごく一部にすぎません。私たちは、その手作業のトリアージを肩代わりするエージェントを開発しました。
CloudOps / SRE
監視・デプロイ・コードのツールを手作業で突き合わせる必要はもうありません。エージェントがシグナルを相関分析し、修正案を提示します。
FinOps
コスト異常はレポートでフラグを立てるだけでなく、原因となった特定のデプロイや構成変更まで遡って特定します。
SecOps
セキュリティの検知結果をインフラのコンテキストと突き合わせます。恒久アクセス権ゼロのモデルにより、エージェント自体がリスク要因になることはありません。
SREのインシデント対応時間のうち、手作業のトリアージに費やされる割合
インシデント1件あたりに参照されるツール数(平均)
設計段階から徹底するゼロアクセスポリシー
その仕組み
イベントメッシュと変更台帳
コスト異常やエラー急増を検知すると、エージェントは自動で影響範囲をマッピング。統合された変更台帳を照会し、最近のインフラ変更とインシデントを突き合わせて根本原因を診断します。
単にアラートを通知して終わりではありません。具体的なコード修正や構成変更を生成し、プルリクエストとして提示。あとは承認するだけです。
スタックに溶け込む
シグナルから対処まで
Datadogのアラート → 直近のTerraform変更 → サービス全体への影響範囲 → ロールバック/構成修正のPR
もう一つのダッシュボードではなく、共に働く同僚として
エンジニアの作業場所はそのままに
環境を学習し続ける
エピソード・意味・手続きの3層記憶
記憶がなければ、インシデント対応は毎回ゼロからのやり直し。同じ教訓を何度も学び直すことになります。
このエージェントは3つの記憶層を備えています。一度修正すれば(例:「このサービスは今、チェックアウトチームの担当です」)、意味記憶が更新され、次回からはそれを踏まえて動きます。過去のインシデントは将来の診断に活かされ、Runbookは実行可能な手続き的知識として蓄積されます。
ギャップを埋める
アラートを、承認済みの修正へ。
Frequently asked
questions
エージェントは本番環境への書き込み権限を持っていますか?
いいえ。恒久アクセス権ゼロのモデルを採用しています。修復タスクのみにスコープされた短命のジャストインタイム トークンを都度取得し、タスクが完了すると認証情報は失効します。常設の権限は一切ありません。
既存の監視ツールやアラートツールを置き換える必要はありますか?
いいえ。エージェントはDoiT Cloud Intelligence、PerfectScale、Kubernetes、そしてすでにお使いのアラートツールの上で動作します。既存スタックからシグナルを取り込み、相関分析、診断、自動修復を上乗せします。
エージェントはどのように自社固有の環境を学習しますか?
エピソード記憶(過去のインシデント)、意味記憶(チームのオーナーシップ、サービスマップ)、手続き記憶(Runbookやプロセス)の3層で記憶を保持します。修正を受けるとその内容を学習し、以降のインシデントに反映します。
検知結果はどこに表示されますか?
Slackのスレッド、CLI、GitHubのプルリクエストです。私たちはあえて新たなダッシュボードを作りませんでした。エンジニアがすでに働いている場所に、エージェントが歩み寄ります。
対応しているクラウドやプラットフォームは?
DoiT Cloud IntelligenceによりAWS、Google Cloud、Azureに対応。さらにPerfectScaleを介してKubernetes環境にも対応します。一般的なオブザーバビリティ・デプロイツールとも連携可能です。