快手技術、複雑業務における RCA エージェントの探索実践を公開

「古い地図を持っていても、新しい大陸は発見できない。」

AI コーディングツールの成熟が進む今日、コード生成の領域はほぼ制覇されたと言っても過言ではありません。しかし、ソフトウェアエンジニアリングにおける全体的な課題が解決されたわけではありません。

本稿は、快手（クァイショウ）のシニアサーバーサイドアーキテクトである郭勇良氏が、QCon 全球软件开发大会 2026 北京站 で行った基調講演「複雑なビジネスシーンにおける RCA Agent の探索実践」の内容を整理したものです。

郭氏は、大規模言語モデル（LLM）を活用した業務トラブルシューティングの仕組みについて詳しく解説しました。そこでは、AI に業務を理解させる方法、アラートノイズへの対処法、不確実性の定量化、そしてモデルの幻覚（ハルシネーション）を抑制する手法という 4 つの核心的な課題が取り上げられています。さらに、これらの課題に対応するために設計された Agent アーキテクチャや評価体系、そして継続的な進化の方向性についても言及されています。

背景と課題：なぜ RCA Agent が必要なのか

Claude Code の責任者である Boris Cherny 氏は、かつてあるポッドキャストで「コーディング作業は概ね AI によって制覇された」という見解を示しました。この発言は、より深い問いを投げかけます。「ソフトウェアエンジニアリングは本当に解決されたのか？」という問いです。

2 つの調査レポートから得られる答えは「いいえ」です。2025 年の DORA レポートでは、AI コーディングの導入後の生産性変化が統計されています。個人レベルでの効率向上は顕著でしたが、組織全体の生産性向上は限定的でした。また、マイクロソフト社内の調査でも同様の傾向が見られました。約 6,000 件の勤務日における時間配分のサンプルを分析した結果、会議やコミュニケーション、学習、事務作業を除くと、開発とトラブルシューティングがエンジニアの時間を最も多く占めていることが分かりました。

自然な帰結として、「AI コーディングによる恩恵が頭打ちになった今、次なる生産性のボトルネックはトラブルシューティングである」と言えます。

もう一つの現象もこの見解を裏付けています。OpenClaw は今年 3 月に大規模なバージョンリファクタリングを行いました。そのリリース後、多くのユーザーからプラグインの停止や機能不全に関する報告が殺到しました。注目すべき点は、OpenClaw のコードの大部分が AI コーディングによって生成されたものであるという事実です。

これは何を意味するのでしょうか？AI 時代において人間によるコードへのコントロールが低下するにつれ、AI によるトラブルシューティングは「選択肢」から「必須事項」へと進化していく可能性があります。人間が自らのシステムを完全に理解できなくなった時、対等な保障として AI ドライブ型の診断体系が必要不可欠となるのです。

技術システムは概ね3つの層に分類できます。

インフラストラクチャ層では、コンテナやノード、ネットワークの障害が対象です。ミドルウェア層にはキャッシュ（Cache）、データベース（DB）、メッセージキュー（MQ）の異常が含まれます。一方、私たちが注力しているのは業務層の故障です。これはコア指標の急落、警報の嵐、そして他システムへの連鎖的な影響を直接引き起こすものです。

業務層には3つの特徴があります。第一に、ユーザー体験と収益に直結する点です。第二に、コードの更新が非常に頻繁で、状態が変化しやすい点です。第三に、問題が発生した際の調査手順を事前に予測できない点です。

例えば、動画再生時間の低下という現象一つとっても、その原因は Redis のクエリ遅延かもしれませんし、サービス自体の GC（ガベージコレクション）によるものかもしれません。あるいは、下流の某サービスで導入されたバグが起因している可能性もあります。このように、調査の道筋が不確定であることが業務層でのトラブルシューティングにおける最大の難所です。

二、業務現場での実装における課題

実際の現場では、4 つの段階的な核心課題に直面しました。

第一は「AI に業務を理解させる」ことです。典型的な四象限図において、業務指標の変動を引き起こす要因には、内部要因と外部要因、能動的なものと受動的なものが混在しており、信号とノイズが高度に絡み合っています。例えば、新学期開始による自然なトラフィックの変化と、コード欠陥による異常な減少が混在し、巨大な状態空間を形成しています。

第二の課題は「ノイズとの戦い」です。警報のうちノイズが 75% を超えるシステムにおいて、AI エージェントが無効な信号に計算リソースを浪費しないようにどう制御するかという問題があります。

第三は「AI の不確実性を評価する」ことです。再現性があり、定量化可能な評価体系を構築する必要があります。

第四は、「大規模言語モデル（LLM）における数値計算やトレンド認識の誤り（ハルシネーション）」に直接対抗することです。

課題一：AI に業務を理解させるには？

具体例として、メインサイトで突然ユーザーのフィードストリームへのリクエスト数が急増し、警報閾値を超えたケースがあります。このフィードストリームを直接受け持つ入口サービス A の場合、そのすべての下流サービスの可用性は正常に示されていました。

しかし、サービス A の依存関係は極めて膨大で、数百のサービスと複数の部署にまたがっています。このような状況では、当直エンジニアの前に2 つの段階的な問題が立ちはだかります。

まず、「この指標異常自体が本当に問題なのか」という点です。内部故障によるものか、それとも外部の急な人気（ホットスポット）によって自然発生した現象なのかを判断する必要があります。

次に、仮にこれを問題として処理すると決めた場合でも、すべての下流サービスの担当者を一斉に呼び出して逐一調査するのは現実的ではありません。

実際の根本原因は「推薦品質の低下」でした。情報ストリームの質が落ちたことでユーザーが動画を繰り返し再生し、結果としてリクエスト数が異常に増加したのです。

故障の伝播経路は非常に複雑です。入口サービス A は下流の B を呼び出しますが、B 自体には異常が見られませんでした。これは B の内部にフォールバック（デグラデーション）ロジックが存在していたためです。しかし、B が依存する下流部署のサービス E では Core Dump が発生していました。

E で Core Dump が起きた理由は、E が呼び出した別のサービス F において「インターフェースフィールドの欠落」が発生したためです。最終的な原因は、F サービスの設定変更によって、以前実行されたことのないロジックパスが通ってしまっていたことにあります。

この事例にはいくつかの常識に反する点があります。一般的に推薦品質が低下すればユーザーのリクエスト数は減るはずですが、今回は逆にリクエスト数が増加しました。

異常な伝播経路は、A が B を呼び出すノードと、E が F を呼び出すノードの 2 つで断絶しています。指標上ではすべて正常に見え、依存関係を示すメトリクス（Metrics）からは一切関連付けができませんでした。さらに、部署を跨ぐ連携によって人為的な難易度も高まりました。メインサイトの担当者は、下流部署内部での設定変更イベントを把握していなかったのです。

この問題は最終的に膨大な人的リソースを消費し、トラブル対応グループには一時 100 名以上が参加することになりました。

従来の監視の「3 つの斧」である Trace（トレース）、Metrics（メトリクス）、Log（ログ）を用いた場合でも、この事例では少なくとも2つの明確な断点が存在しました。

最初の断点は A が B を呼び出す地点です。リクエストは正常に処理され、メトリクスからは関連付けられませんでした。そのため、業務上の経験則に頼り、メインサイトの担当者が部署 B の担当者へ人手で確認を取る必要がありました。

2 つ目の断点はより隠蔽性が高いものです。E が F を呼び出す際の故障は「インターフェースフィールドの欠落」が原因でしたが、リクエスト自体は正常でした。さらに、このロジックパスは過去に実行されたことがなかったため、ログが出力されていない可能性さえあります。

この断点の発見もまた、内部関係者による人手でのコミュニケーションに依存していました。

結論は明白です。Agent にこのタスクを任せるには、技術指標の理解だけでは不十分で、業務の本質を理解する必要があります。そうでなければ、必ず壁にぶつかることになります。

では、どうすればよいのでしょうか？従来の Trace（追跡）、Metrics（指標）、Log（ログ）、および変更イベントに加え、私たちは「業務コードの GIT」を導入しました。なぜなら、コードこそが唯一の真実なるドキュメントであり、すべてのシステムはコードの上に構築されているからです。

初期の実践は非常にシンプルでした。Coding Agent を導入してコードをリアルタイムで分析する手法です。当初は Claude Agent SDK を使用していましたが、一つのコードベースを分析するのに約 30 分かかりました。これは障害対応の現場では到底許容できない時間です。PI Coding Agent に切り替えたことで、単一リポジトリの分析時間を約 5 分まで短縮できました。しかし、それでも実際の運用場面ではボトルネックが残っていました。

業務の障害対応は通常、一つのサービスだけでなく、チェーン上に存在する複数のサービスをまたぐケースがほとんどです。さらに Java システムでは、SDK のような多くの基盤ライブラリの依存関係を整理する必要があり、同時に 3〜5 つのリポジトリを分析する必要があります。合計で 15〜25 分かかる計算になりますが、故障対応の現場においてこの時間は依然として長すぎます。

問題の根源は、コードが唯一の真実なるドキュメントである一方で、抽象度が極めて低い点にあります。抽象度が低ければ、当然ながら効率は低下します。

人間が障害対応を行う際、たとえサービスの担当者であっても、すべての行を暗記しているわけではありません。人間の脳内では業務コードに対して何らかの抽象化が行われています。AI に理解させるためには、この認知コストを下げる必要があります。

そこで私たちは、「ビジネス・アセット（業務資産）」と呼ばれるコードの抽象化レイヤーを構築しました。具体的には、エラーコードに業務上の意味付けを行い、Metrics の意味を業務文脈で記述し、指標間のトポロジー関係を定義します。例えばフィードストリームの例では、「下流の推薦サービスの可用性が低下すると、上流のサービスがフォールバック率を変化させ、最終的にフィード配信量に影響を与える」といった関係性をモデル化します。

また、業務ロジックに直接影響を与えるスイッチ設定についても、その影響範囲をマッピングしました。これらのアセット構築には二つのアプローチがあります。

一つはオフラインでの蓄積です。Coding Agent を用いてコアコードの関係記述を生成し、それをナレッジベースとして Markdown 形式で保存します。

もう一つはオンデマンドでの生成です。障害対応の過程で特定のタスクを分析した際、その知見を「スキル」として即時に生成し、ナレッジベースに登録します。

この二つの手法によって、業務アセットは回転し始めます。

要解决“让 AI 理解业务”这一挑战，本质在于消除人与 AI 之间的上下文代差。AI 获取传统监控数据相对容易，但研发人员脑中同时运转着大量隐性信息——代码逻辑、指标间的关联、业务常识（例如主播开播后可能引发送礼请求激增），以及外部事件的影响。这些信息与代码逻辑同等重要，若想让 AI 进行排查，就必须将这些背景全部提供给它。

挑战二：如何对抗噪声

在实际执行中，告警噪声是让人倍感疲惫的难题。统计数据显示，系统中大部分告警并无实际价值，噪声占比往往超过 75%，真正需要关注的不足四分之一。

告警噪声带来的危害是实实在在的。我们曾复盘过一个 P2 级以上的故障：故障发生后约十分钟，某指标已发生波动并触发告警，但当时的值班人员直接将其静默。此后该指标在十五分钟内迅速恶化至严重程度，却无人察觉。原因正是该告警在七天内触发了超过 15 次，导致值班人员产生了严重的“告警疲劳”，基本不再查看详情便直接忽略。

但如果让 AI 全量处理所有告警，又会引发新问题。内部试验表明，Agent 在 ReAct 循环中完成一次完整推理的 Token 消耗大约在 60 万到 100 多万之间。快手主站每月的告警事件总量约为两三万起，若由 AI 处理全部告警，每月 Token 消耗将接近百亿，年化成本高达数百万人民币。除了高昂的成本问题，ReAct 循环的交互次数不可控，延迟也无法保证。

我们的解决方案是分两层架构。第一层引入一个极轻量的“告警置信度评估 Agent”或 Workflow。它的任务是提取告警的“画像”，包括周期性规律、触发后的阈值偏离程度、恢复时间、服务分布以及曲线聚集情况等统计特征。以偏离分析为例：某可用率告警通常维持在 98%（四个九），若某天突然跌至 60%，显然需要重点关注；若仍停留在 98% 附近，则可能无需干预。周期性同理：如果告警每天凌晨固定触发，其置信度相对较低；但若某天下午突然开始报警，这很可能是一个明显的异常信号。

经过置信度评估筛除部分噪声后，下一步是对保留下来的问题进行排障推理。然而即便经过初步过滤，推理阶段仍存在大量噪声干扰。系统中充斥着各类技术指标的波动，例如服务恰好发生了 GC（垃圾回收），但并未引起核心业务指标变化，这类情况极易导致 Agent 误判。另一个典型的噪声来源是变更事件：在发布高峰期，一条核心服务的关联链路上可能在单小时内关联出 500 多个变更。这些变更绝大多数不会导致故障，但当故障真正发生时，Agent 必然会拉取如此庞大的变更列表。如何判断它们与告警之间是否存在真实关联？这些都是潜在的误判信号。

私たちの対応策は、証拠医学で用いられる「エビデンス・ピラミッド（証拠の金字塔）」を参考にしたものです。このアプローチは医療現場に由来します。医師は毎日多数の症例を扱いますが、その多くは不安から受診した患者であり、実際の疾患がないケースも少なくありません。そのためまずノイズをフィルタリングし、本当に病気を抱える患者に対してのみ、原因究明へと進む必要があります。医学はこの点で非常に厳密な科学体系を持っており、成熟したベストプラクティスが存在します。それをそのまま技術現場に適用できるのです。

このピラミッドの最下層は「生データ」です。その上には「背景文脈」が位置します。具体的には、外部のトレンドやホットなトピック、静的なサービス依存関係、エンジニアの経験知などが含まれます。さらに上位には「単一観測データ」があります。例えば、特定のメトリクスや単一サービスの指標異常などです。

これらの単一異常を、Trace（トレース）やシステムトポロジーによって関連付けると、「多様な証拠が融合した情報」となります。例えば、問題発生時に連鎖的に影響を受けた変更履歴や、過去の故障パターンとの一致などがこれに該当します。これがより確実性の高い層を形成します。

最上層は「直接的な因果関係の推定」です。指標間に明確な有向グラフのトポロジーが存在する場合、ソースコードレベルで事実が確定している場合、あるいは障害発生時に時間的に一致する直接の変更が行われていた場合などが該当します。これらはすべて、確実性の高い因果推論として扱われます。

課題3：不確実性をどう測るか

現在、本番環境向けAIシステムには共通認識があります。「Good Case（良いケース）」を動かすのは簡単で、デモを見せるのも容易ですが、「Bad Case（悪いケース）」を排除し、実際に本番投入するのは極めて困難だということです。そこには大量の「コーナーケース」や「サイレントエラー（目に見えないエラー）」が存在します。

あるAIスタートアップのCTOは、以前の記事でこう述べています。「デモでは正解へのパスさえ見つかればよいが、本番環境では9割のケースが悪条件である」と。なぜこのようなギャップが生じるのでしょうか？

それは、従来のプログラムでは「決定論的」だった要素が、AIにおいては「不確定的」なものに変化しているからです。同じ問題に対して複数回推論を行っても、経路や結論が異なる可能性があります。また、極めて大規模な業務システムでは影響要因が多岐にわたり、わずかな変数の変化が結果に大きな偏りをもたらすこともあります。これはまさに「バタフライ効果」と言える状況です。

実際に遭遇した事例があります。当初、Agent（エージェント）で「単点の揺らぎ」を検出しようとした際のことです。多くのRPC可用性アラートは、下流の特定のPodが瞬間的に不安定になることで生じる全体指標の変動によるものです。解決策としては、従来の異常検知アルゴリズムを導入し、さらに詳細な分析次元を追加してAgentに提供するというものでした。

しかし、このツールを追加した結果、単点問題は確かに検出されるようになったものの、全体のケース精度はむしろ低下しました。その理由は明白です。単点問題は極めて頻繁に発生する現象であり、数千のPodが稼働するクラスターでは決して珍しいことではありません。コア業務指標の変動時には、必ずといっていいほど単点問題も同時に発生します。

Agentが「アクセス数減少」を調査した際にも「検索数減少」を調査した際にも、単点問題を検出しました。そして、それらを誤って因果関係として結びつけてしまったのです。このケースの根本原因は明確です。従来のソフトウェアのように一つのケースを修正すれば解決するのではなく、あるBad Caseへの対策が別のBad Caseを生み出す可能性があるということです。

この課題に対する解決策についても、業界内で強いコンセンサスが得られつつあります。アンドレイ・カルパシ（Andrej Karpathy）は3月のツイートで、「現在のベンチマークこそが新たなメタ（基準）である」と指摘しています。また、昨年発表された影響力のある論文『Agent Design is Still Hard』も同様の見解を示しており、「評価とテストがいかに困難か」を強調し、一定の規模に達した段階では必ずベンチマークを導入すべきだと述べています。

当社のベンチマーク体系は、2 つのフェーズに分かれています。

最初のフェーズは「ケース収集」です。障害が発生すると、専門家による注釈付けを経て、インテリジェントな原因特定までを完了させた後、評価フェーズへと移行します。このプロセスで得られたケースは評価セットに追加され、その価値が判断されます。関連データは転送保存され、その後、評価エージェントを実行して効果を比較検証します。

評価セットの設計段階では、実際のビジネス問題空間を網羅することが目標です。すべてのケースは、オンライン上の実際の異常シーンから収集されたものです。一方、評価セットのデータ構築段階では、実際のトラブルシューティング環境を再現することが目標となります。そのため、スナップショット形式の監視データ転送アプローチを採用しました。

快手（Kuaishou）では毎日膨大な量の監視データが発生しますが、一部のデータには有効期限があります。そのため、障害発生期間中の監視データを可能な限り転送保存する必要があります。

なぜシミュレーション環境や混沌工学（チャオスエンジニアリング）の手法を採用しなかったのかといえば、解決すべきはビジネス固有の問題だからです。こうした問題は混沌工学で模擬することが非常に困難です。

例えば、「検索数が減少した」というケースを想定してください。実際に検索数の減少という障害を人為的に作り出すことは不可能です。リクエスト量が膨大になるため、シミュレーションコストが高すぎるのです。そのため、私たちは実際の異常から事例を収集し、障害現場の状況を保存することに注力しています。

評価フェーズでは、モデルの効果を測定することが目標となります。ここでは「ヒューリスティック（手がかり）の的中率」などの主要指標に焦点を当て、定量的なスコアリングを行い、期待される挙動と比較します。

課題 4：ハルシネーション（幻覚）への対抗

大モデルにおける「ハルシネーション（幻覚）」は避けて通れない話題です。昨年、Claude Opus 4 モデルで発見されたある典型的な事例があります。現在はバージョン 4.7 が登場してこの問題は解消されているかもしれませんが、その教訓は今なお有効です。

ある時、同僚から「時間をタイムスタンプに変換してほしい」という非常にシンプルなプロンプトをもらいました。これをそのまま Claude に投げたところ、変換がほとんどできず、毎回不正確な結果しか返ってきませんでした。その後、私はプロンプトを少し修正し、「Python スクリプトを実行して変換してほしい」と指示したところ、結果は劇的に精度が高まりました。

この小さな実験は、大モデルの本質を如実に示しています。大モデルは確率予測器に過ぎず、数値計算タスクには不得意なのです。

実際のビジネス現場で直面した最初の課題は、監視画像から単純なトレンド（例えば 8:00 から 8:20 の間に指標が上昇しているか下降しているか）を認識することでした。本来は非常に簡単なはずのことですが、大モデルで試みると明らかなハルシネーションが発生しました。

当初の解決策として、マルチモーダル技術を用いて監視スクリーンショットを直接大モデルに読み込ませる案がありました。しかし、この方法ではハルシネーションが深刻でした。画像には確かに 8:00 から 8:20 の間に下降傾向があるものの、時間点が不正確で、モデルは非常に曖昧な時間範囲しか提示できませんでした。

さらに悪いことに、大モデルが縦軸の解釈を誤るケースもあり、「8:30 に下降を確認した」といった明らかな事実と異なる発言をするさえありました。これは深刻なハルシネーションです。また、このアプローチはチャートのスタイルが安定していることに依存しており、フロントエンド担当者が色やレイアウトを少し変更しただけで、精度が即座に低下してしまいます。

2 つ目の解決策は、時系列データを用いて認識する方法でした。一定期間のすべてのデータポイント（「時間 - 値」のペア）を巨大な JSON リストとして構成し、大モデルに直接送信する手法です。しかし、これも計算ミスを免れることはできませんでした。

まず、トークン消費量が膨大になりすぎます。データシーケンスがあまりにも長いためです。さらに、モデルは依然として計算を実行する必要があります。「どの程度の割合で下降したか」を判断するなどですが、大モデルはこの種の処理も得意ではありません。

最終的にこの課題は、従来のアルゴリズムを用いるタスクへと転換されました。具体的には「孤立森林（Isolation Forest）アルゴリズム」に特定のルールを組み合わせることで判断を行っています。このアプローチを採用した結果、精度が大幅に向上し、トークン消費も不要となりました。何より、処理の確実性が根本的に強化されたのです。

ここから得られる重要な結論は、一定以上の「確実性」が求められる場合、工程化してツール（Tool）やスキル（Skill）として封装する方が、より優れた解決策となるということです。

ある判断能力を標準化された演算子（オペレーター）として封装すれば、それは標準的なインターフェースを獲得し、再利用が可能になります。また、パラメータの調整も柔軟に行えます。一度、標準化された演算子として定着すれば、徐々に蓄積して「演算子ライブラリ」を構築していくことができます。

AutoResearch や CodeAct のようなアプローチを参考に、確実性が高く反復的な問題をアルゴリズムとして定着させ、それらのアルゴリズムに対して一連の入出力ペアを用意します。本質的にはこれは「関数」の作成です。例えば、「入力 A なら出力 B」「入力 C なら出力 D」といったケース（Case）を準備し、繰り返し実行してアルゴリズムのスコアを向上させることを目指します。

このステップは非常に定量化しやすく、明確なフィードバックループを形成できます。これにより、継続的にアルゴリズムを磨き上げていくことが可能になります。

三、核心となるメカニズムとアーキテクチャ設計

全体としての進化のロードマップを振り返ると、AI が導入される前は純粋なルールベース（Rule-Based）の段階でした。AI が登場した当初は、いくつかの標準作業手順書（SOP）をプロンプトで編成する試みを行いました。その後、ワークフロー（Workflow）が登場すると、そのワークフローと MCP（Model Context Protocol）を組み合わせたアプローチも検討しました。

しかし昨年後半に入り、私たちはついに、エージェント（Agent）が大規模言語モデルの自律判断によって「いつ停止し、いつ調査を続けるか」を完全に決定する試みを本格化させました。

ここには、真剣に考えるべき問いがあります。「ワークフローからエージェントへ進化することは、必ずしもより優れた選択なのか？」という点です。

ワークフローの明確な利点は、処理が確実で制御しやすいことです。しかし、その限界もまた明白です。それは厳密に編成されたプロセスと固定されたフローに依存しており、非常に柔軟性に欠けます。一方、エージェントは柔軟性の問題を解決し、発散的な対応や汎化能力を備えています。ただし、その代償として「不確実性」が生まれます。

さらに、ワークフローからエージェントへ切り替えることで、レイテンシ（遅延）が増大するという問題も生じます。ReAct パターンにおけるループ処理が多輪にわたれば必然的に遅延は大幅に増加し、トークン消費量も爆発的に膨らみます。これに対し、ワークフローにはこれらの欠点がありません。遅延が低く、トークン消費も少なく、何より確実性が強いのです。

つまり、エージェントがワークフローを完全に置き換える関係にあるわけではありません。エージェントは「より賢い」ものの代名詞ではなく、「より柔軟な」進化の形と言えます。特定のシナリオにおいては、むしろワークフローの方が効果的な場合もあるのです。

では、なぜ私たちはエージェントを採用するのか？それは、複雑な業務上のトラブルシューティング（排障）現場には、静的な SOP ではカバーしきれない「極めて不確実な問題」が数多く存在するからです。これが、エージェントを導入する核心的な価値です。

全体としてのアラートガバナンスのアーキテクチャは、階層構造で設計されています。

最下層では、従来のアラートガバナンスや一般的な戦略、そしてインテリジェント（AI）によるアラートの導入を通じて、ノイズを削減します。

その上の2つのレイヤーが AI によって処理される領域です。第一層では、いくつかのワークフローを用いて「システム思考（ファストシンキング）」を実行し、比較的固定されたシステム系アラートに対応します。具体的には、SOP シナリオや Redis の排障、Java の例外発生などです。これらは非常に定型化された事象であり、「ファストシンキング」による単純な問題処理として扱えます。

最上層では、コアビジネス指標の急激な変化（突変）に対応します。ここではエージェントを導入して「スロウシンキング（遅い思考）」を行い、深い推論を行います。

「快思考」の段階では、告警イベントが発生すると、まず抑制ルールが適用されます。例えば、単一ポイントの問題と判断されれば、そのポイントを再起動するだけで対応でき、告警は即座に抑制できます。さらに特徴量の分析を加えることで、多くの告警を自動的にフィルタリングすることが可能です。

残った告警については、複雑度の簡易判定を行います。次元分析や影響範囲の簡単な評価を通じて、ワークフロー内で解決できると判断されたケースでは、直接原因を特定して同期処理で完了させます。一方、より複雑な問題に対しては、非同期の Agent による分析プロセスへ移行します。この場合、通常は 10 分以上を要する可能性があります。

ワークフロー側の処理は決定性が高く、比較的迅速に結論を出すことができます。

複雑な問題に対する「慢思考」の段階では、マルチエージェント（Multi-Agent）アーキテクチャを採用しています。告警イベントがトリガーされるとプラットフォームへ流入し、メイン Agent がループを開始します。ここでプランニングを行い、動的に複数のサブエージェントを呼び出します。

基盤となるのは業務資産とデータインフラストラクチャーです。最終的には、人間にも理解可能な形で解釈可能なレポートが出力されます。

このプロセスでは、以下の 3 つの重要な技術ポイントを活用しています。

第一に、「Sub-Agent のドメイン別カプセル化」です。利用可能なツールは合計 80 以上ありますが、これらをすべてメイン Agent に直接投げると、認知負荷とトークン消費量が膨大になってしまいます。そのため、類似した領域のツールをグループ化し、サブエージェントとしてカプセル化して管理しています。

第二に、「長期間タスクにおけるコード分析の非同期化」です。複雑なタスクでは依然としてコード分析が必要になる場合がありますが、これを非同期処理としてキュー（信箱）へ投下し、メイン Agent が順次消費する仕組みを採用しています。

第三に、「Agent 間通信チームの構築」です。Sub-Agent を用いた調査手法では、各エージェント間の情報が隔離されているため、特定のサブエージェントが無効なパスに陥るリスクがあります。例えば、あるエージェントがすでに重要な手がかりや変更イベントを発見した場合、他のエージェントが RPC の詳細な下層調査を続ける必要はなくなります。

これを解決するため、Agent 間通信チームを構成し、Sub-Agent 間で必要な情報を共有させることで、全体の調査パスを短縮しています。

エージェントの自己進化に関する私たちの考え方は、大モデルが抱える二つの極端な課題にあります。

一つは、過度に汎用的でケーススタディを与えないゼロショット推論モードです。これは思考が散漫になりがちです。もう一つは、SOP（標準作業手順）をプロンプト内で完全に固定化し、「まず何をして、次に何をする」と厳密に指示するアプローチです。これでは過学習のリスクが生じます。

そこで私たちは、Few-shot（少サンプル）モードを採用しました。類似した故障事例に対して、おおよその処理方針を示すのです。ただし、Few-shot の事例を一つずつ人間が構築するのはコストがかかります。この課題を解決するため、自動で事例セットを構築するシステムを設計しました。

事前にいくつかの質問と正解を用意し、エージェントに反復実行モードを開始させます。この際、モデルは軽量な小規模モデルに切り替え、温度パラメータ（Temperature）を高めに設定して多様な探索経路を生成します。最終的に正解に到達するまでこれを繰り返すのです。

評価モジュールが「正解にヒットした」と判断すると、その推論プロセス全体を抽出・要約し、ナレッジベースとして蓄積していきます。

エージェントの「記憶」機能については、トラブルシューティングには膨大な情報量の参照が必要です。例えば、アラート画像の統計データや、開発者の頭脳内に存在する業務知識などです。これらは推論開始時にコンテキスト（Context）やシステムプロンプトに初期化される必要があります。

推論中に行われるのは、動的な検索プロセスです。過去のオフライン業務資産、推論過程で蓄積された長期記憶、そして特定のシナリオに特化したスキル（SOP に近い性質のもの）を検索します。

これらの情報を統合・整理する作業については、人間が手動で行うのではなく、エージェント自身に任せるようにしています。これにより、人的リソースの消費を最小限に抑えています。

製品インタラクションの観点では、ずっと一つの疑問を抱いていました。昨年の Claude Code の登場から、今年 1 月の OpenClaw のリリースに至るまでです。

私の周囲にいる多くのエンジニアは OpenClaw に大きな熱狂を見せませんでしたが、社会全体からは大きな反響を呼びました。なぜ Claude Code は同様のインパクトを持たなかったのでしょうか？その決定的な違い（增量）は何だったのか。

観察の結果、OpenClaw にはいくつかの独自機能があることが分かりました。IM（インスタントメッセージング）への接続、デフォルトでの全権限付与、そしてタスク進行状況を感知するハートビート機構です。

要約すると、現在の同種製品に共通しているのは、AI をより「プロアクティブ（能動的）」にしていくという方向性です。

そのため、製品開発の方向性もこの流れに沿って進めています。

当初は、エンジニアが問題を投入すると Agent が推論を行い、その過程で重要な発見を提示し、リアルタイムにトポロジー図を描くという Chatbot 形式でした。しかし、将来的にはより AI ネイティブな自律型へと進化させる必要があります。Agent が自ら問題を検知し、必要な場合は自動的にチャットグループを作成して参加し、発見した重要情報を次々と投稿する形です。

最終的には「問題の検知」から「トラブルシューティング」「協働処理」、さらには「ナレッジの蓄積」までを完結させる完全なクローズドループを実現すること。これが目指すべき理想の姿です。

コア指標の運用においては、アラートや障害対応に対しては MTTR（平均修復時間）の短縮を最終目標とします。しかし実際には、故障が発生する頻度は低く、事例数も限られています。そのため、プロセス指標を導入しました。

最初の指標が「有効な手がかりの発見率」です。なぜ「手がかり」という概念が必要なのかというと、Agent の推論には時間がかかるためです。一つのタスクに 10 分以上かかることも珍しくありません。10 分待ってから結論を伝えるわけにはいきません。その過程で共有すべき重要な手がかりが見つかったら、即座に提示する必要があります。したがって、この「手がかり」の精度が重要な評価基準となります。また、原因特定（アトリビューション）の精度や所要時間も継続的に運用していく必要があります。

現在、全体の精度は 80% を超えていますが、これは多くのアラートノイズを含んだ数字です。実際の推論レベルでの精度はこれほど高くありません。推論面では主に「有効な手がかり」の精度を重視しており、最終的に根因を正確に特定するのは非常に困難ですが、過程で有効な手がかりを見つけられれば、すでにビジネスに実質的な価値をもたらしています。

実践の過程では数多くの課題にも直面しました。例えば、大規模言語モデル（LLM）層での頻発する失敗や、API インターフェースの不整合、異なるベンダー間の LLM API 仕様の大きな違いなどです。これらは本質的にソフトウェアエンジニアリングの問題であり、障害への対応、予防、システムの耐故障性強化が必要です。過去に分散システムを開発していた際も、環境の不確実性と戦い続けてきました。AI の導入は、この不確実性をさらに増幅させ、常態化させてしまいました。その事実を理解した今では、むしろ心構えが楽になりました。これを受け入れるしかないのです。

四、まとめと展望

最後に一つの認識を共有します。「古い地図を持っていても、新しい大陸は発見できない」ということです。

現在の監視システムはすべて「人」を中心に構築されており、人間が使うことを前提に設計されています。人間の認知には帯域制限があり、複雑な情報を処理しきれません。そのため、経営陣への報告では多くの詳細を隠蔽し、抽象化されたシンプルな構造に凝縮する必要があります。システムも同様の論理で動いており、すべての底層データを全量表示することはできず、データのアブストラクション（抽象化）を行います。

しかし Agent にはそのような制約がありません。無限に近い量の複雑なデータを処理することが可能です。では、未来のシステムはどのように進化していくのでしょうか？可観測性（オバザビリティ）の全体体系が再構築されることになるのでしょうか。私にも答えはありませんが、この点については引き続き考え続けています。

もう一点、現在の組織構造は「人」を単位として高度に分業化されています。しかし Agent に分業は不要です。また、人間同士には情報隔離が存在し、組織的な問題と技術的な問題が絡み合うこともあります。例えば、「誰が多く情報を握っているか」が主導権を握る要因になるなどです。

しかし Agent の世界では事情が異なります。第一原理から考え直せば、すでに何かが変わっているのです。

さて、現在の発展状況について振り返ります。Agent 分野の進化は極めて速く、数ヶ月も経てば多くの結論が陳腐化してしまいます。では、一体何を蓄積できるのでしょうか。

私たちは「問題領域における業務資産」「評価（Eval）体系」「構造化された事例集」「人間と機械の協働モデル」など、一定期間にわたって維持可能な要素があると考えています。これらは安定した層であり、継続的に積み上げていくことができます。一方で、モデルの迭代に伴い変化する「変動する層」も存在します。例えば、下半期にさらに強力な新モデルが登場すれば、現在有効な手法がすぐに使えなくなる可能性があります。プロンプトの記述、ツールの選定、プロトコルの規範などはすべてこの変動層に含まれます。

私たちのアプローチは、より多くのリソースを安定した層に投入し、変動する層への投資を最小限に抑えることにあります。そのために、データコンテキストの構築に注力しています。

最後に、全体の方向性は「AI ネイティブな自律化」と「AI の自己進化」へと向かうべきだと考えます。現在の Agent が担っているのは、人間が主導して問題排查を行う際の意思決定支援です。将来的には新たな段階へ発展し、Agent が自ら意思決定の提案を行い、人間が最終的な承認とチェックを行う体制へと進化するでしょう。このプロセスが十分に長く継続され、99% のシナリオにおいて Agent の判断が正確であり、人間の承認者が有効な修正を提案する余地がないことが確認できれば、完全に「Agent による自己進化」と「自律的なクローズドループ」を実現できるはずです。

【快手技術交流群】への参加をお待ちしています。

QR コードをスキャンしてください👇

【原文を読む】をクリックして、講師の PPT をダウンロードしてください！

原文を読む

WeChat で開くにはこちらへ