サークルK、障害の初動調査を15分未満に短縮

サークルKは2026年4月、Amazon Bedrock AgentCoreを基盤とするAI障害調査システムを導入し、平均調査時間を45〜60分から15分未満に短縮しました。社内のインシデント対応指標によると、短縮幅は67〜75％です。システムは同社のAWS環境でアラートを調べ、構造化した要約をSlackでエンジニアに送ります。サークルKは27カ国で17,200店を超えるコンビニエンスストアや燃料小売店を運営し、AWSを販売時点情報管理、ロイヤルティ、電気自動車充電の各アプリケーションに利用しています。

自動化前は、Grafanaのアラートを受けたエンジニアがCloudWatchのログ、OpenSearchのトレース、ECSのタスク状況、GitHubの手順書やコードを確認していました。サークルKは、繰り返し発生する情報収集を自動化しつつ、運用上の判断はエンジニアに委ねるためにシステムを構築しました。モデルのホスティング、プロンプトの版管理、ツール連携、セキュリティ制御を自社で管理する必要を避けるため、セルフホスト型のオープンソース・エージェント基盤ではなくAmazon Bedrockを選びました。同社によると、Bedrockは既存のAWS Identity and Access Managementのポリシー、Virtual Private Cloudの構成、ログ収集パイプラインに適合しました。また、顧客データはモデル提供者と共有せず、基盤モデルの訓練にも使わないとしています。

初期システムではAmazon Bedrock Flowsを使い、専門化した3つのエージェントを連携させていました。GrafanaのアラートはAmazon SNSとSQSキューを経由してLambda関数に届き、関数がFlowを呼び出します。並行して、一つ目のエージェントがECSタスクの稼働状況、ロードバランサーの対象、CloudWatchの指標とログなどAWSリソースを調査し、二つ目がOpenSearchのログとトレースを検索して、管理されたナレッジベースからサービス情報を取得します。三つ目は対象サービスのGitHubリポジトリ、インフラ定義、直近のコミットを調べます。最後にモデルが調査結果をまとめ、推定原因、根拠、影響を受けるサービスと担当者、推奨する修正策を含む要約を作成します。調査には複雑さに応じて5〜15分かかり、エンジニアは一貫した形式の要約を2分未満で確認できました。

事例では、HTTP 5xxエラー率が3分連続で5％を超えたとアラートが通知しました。エージェントはデータベース接続プールの枯渇、サービスとPostgreSQL間の「connection refused」エラー、リクエストごとに新しいデータベース接続を開くコードを見つけました。最終分析は、アラートの10分前に始まったマーケティングキャンペーンと発生時刻を結び付け、コードの修正を提案しました。

数カ月間Flowsを使った後、サークルKはデータ量とコンテキストの増加に伴い、一部の調査により長い処理時間が必要だと分かりました。ログの絞り込み、コンテキスト範囲の短縮、サービスごとのFlow分割を試しましたが、長時間の分析に必要な処理には対応しきれませんでした。そこで、最大8時間のセッションに対応するAgentCore Runtimeへ移行しました。現在の調査で8時間すべてを必要とするものはありません。3つのエージェントはコンテナ化した単一のエージェントセッションに統合し、Lambdaがセッションを開始して15分以内に結果をSlackへ投稿します。AgentCore Gatewayは、OpenSearch、Bedrock Knowledge Bases、GitHubをツールとして利用できるようにし、アクセス制御を一元化します。

サークルKによると、単純な障害の要約は現在5〜8分で届き、以前は手作業での調査に1時間超を要した複数サービスにまたがる複雑な障害も15分以内に調査を終えます。システムはオンコール担当者に一貫した要約と、別チームへ引き継ぐ際に役立つ関連情報を提供します。また、サービスが正常でアラートと関連するエラーが見つからない場合に、担当者がより早くアラートを確認できるようにします。

チームによると、セッションの状態を保持することで、エージェントは前の調査結果を失わずに対象を絞ったログの再確認を行えます。AgentCoreはOpenTelemetry規格を使ってセッションのトレースを記録し、CloudWatch上で確認できるようにします。これにより、チームは各処理の所要時間、ナレッジベースへの検索、ボトルネックを調べ、プロンプトを調整できます。Runtimeは異なるフレームワークで構築されたコンテナ型エージェントにも対応します。チームが挙げた教訓には、ロググループ名と時間範囲だけでなく関連するログ行をエージェントに直接渡すこと、検索設定を試すこと（同社のデータではナレッジベースの既定設定が最適でした）、システムプロンプトと温度を調整すること、ログとリソースの分析で原因候補を絞ってからGitHubを検索することが含まれます。提供された原文は、これらの教訓を説明する途中で終わっています。

サークルKは2026年4月、Amazon Bedrock AgentCoreを基盤とするAI障害調査システムを導入し、平均調査時間を45〜60分から15分未満に短縮しました。社内のインシデント対応指標によると、短縮幅は67〜75％です。システムは同社のAWS環境でアラートを調べ、構造化した要約をSlackでエンジニアに送ります。サークルKは27カ国で17,200店を超えるコンビニエンスストアや燃料小売店を運営し、AWSを販売時点情報管理、ロイヤルティ、電気自動車充電の各アプリケーションに利用しています。

自動化前は、Grafanaのアラートを受けたエンジニアがCloudWatchのログ、OpenSearchのトレース、ECSのタスク状況、GitHubの手順書やコードを確認していました。サークルKは、繰り返し発生する情報収集を自動化しつつ、運用上の判断はエンジニアに委ねるためにシステムを構築しました。モデルのホスティング、プロンプトの版管理、ツール連携、セキュリティ制御を自社で管理する必要を避けるため、セルフホスト型のオープンソース・エージェント基盤ではなくAmazon Bedrockを選びました。同社によると、Bedrockは既存のAWS Identity and Access Managementのポリシー、Virtual Private Cloudの構成、ログ収集パイプラインに適合しました。また、顧客データはモデル提供者と共有せず、基盤モデルの訓練にも使わないとしています。

初期システムではAmazon Bedrock Flowsを使い、専門化した3つのエージェントを連携させていました。GrafanaのアラートはAmazon SNSとSQSキューを経由してLambda関数に届き、関数がFlowを呼び出します。並行して、一つ目のエージェントがECSタスクの稼働状況、ロードバランサーの対象、CloudWatchの指標とログなどAWSリソースを調査し、二つ目がOpenSearchのログとトレースを検索して、管理されたナレッジベースからサービス情報を取得します。三つ目は対象サービスのGitHubリポジトリ、インフラ定義、直近のコミットを調べます。最後にモデルが調査結果をまとめ、推定原因、根拠、影響を受けるサービスと担当者、推奨する修正策を含む要約を作成します。調査には複雑さに応じて5〜15分かかり、エンジニアは一貫した形式の要約を2分未満で確認できました。

事例では、HTTP 5xxエラー率が3分連続で5％を超えたとアラートが通知しました。エージェントはデータベース接続プールの枯渇、サービスとPostgreSQL間の「connection refused」エラー、リクエストごとに新しいデータベース接続を開くコードを見つけました。最終分析は、アラートの10分前に始まったマーケティングキャンペーンと発生時刻を結び付け、コードの修正を提案しました。

数カ月間Flowsを使った後、サークルKはデータ量とコンテキストの増加に伴い、一部の調査により長い処理時間が必要だと分かりました。ログの絞り込み、コンテキスト範囲の短縮、サービスごとのFlow分割を試しましたが、長時間の分析に必要な処理には対応しきれませんでした。そこで、最大8時間のセッションに対応するAgentCore Runtimeへ移行しました。現在の調査で8時間すべてを必要とするものはありません。3つのエージェントはコンテナ化した単一のエージェントセッションに統合し、Lambdaがセッションを開始して15分以内に結果をSlackへ投稿します。AgentCore Gatewayは、OpenSearch、Bedrock Knowledge Bases、GitHubをツールとして利用できるようにし、アクセス制御を一元化します。

サークルKによると、単純な障害の要約は現在5〜8分で届き、以前は手作業での調査に1時間超を要した複数サービスにまたがる複雑な障害も15分以内に調査を終えます。システムはオンコール担当者に一貫した要約と、別チームへ引き継ぐ際に役立つ関連情報を提供します。また、サービスが正常でアラートと関連するエラーが見つからない場合に、担当者がより早くアラートを確認できるようにします。

チームによると、セッションの状態を保持することで、エージェントは前の調査結果を失わずに対象を絞ったログの再確認を行えます。AgentCoreはOpenTelemetry規格を使ってセッションのトレースを記録し、CloudWatch上で確認できるようにします。これにより、チームは各処理の所要時間、ナレッジベースへの検索、ボトルネックを調べ、プロンプトを調整できます。Runtimeは異なるフレームワークで構築されたコンテナ型エージェントにも対応します。チームが挙げた教訓には、ロググループ名と時間範囲だけでなく関連するログ行をエージェントに直接渡すこと、検索設定を試すこと（同社のデータではナレッジベースの既定設定が最適でした）、システムプロンプトと温度を調整すること、ログとリソースの分析で原因候補を絞ってからGitHubを検索することが含まれます。提供された原文は、これらの教訓を説明する途中で終わっています。