「他のモデルは、私たちがすでに修正した後でも、何度も何度も同じ問題を指摘し続けました。Enter Proを試してみたところ、何が本当の原因なのかを突き止めてくれました」

WhyVenvは、エンジニアが本番環境のエラーから根本原因へとより迅速に移行できるように、Quackathon向けに自律型インシデント対応エージェントであるKronosを構築しました。

ポケベルの鳴動は始まりに過ぎない

本番環境が破損したとき、アラート自体が難所になることは滅多にありません。

Grafanaは何かがダウンしていることを教えてくれます。ログは何かが失敗したことを教えてくれます。ダッシュボードは、午前2時に誰かを叩き起こすのに十分なほど大音量で赤く点滅します。

しかし、その後に本当の仕事が始まります。

エンジニアは依然として、ログを開き、エラーを理解し、コードベースを検索し、どの関数が重要かを推測し、問題が緊急かどうかを判断し、次の適切なステップがGitHubのイシュー作成なのか、パッチ適用なのか、あるいは本格的なエスカレーションなのかを判断しなければなりません。

何かが壊れたことを知ることと、何が壊れたのかを理解することの間のそのギャップこそが、インシデント対応が苦痛になる場所です。

そこはまた、Dawood KhanがKronosのアイデアを見つけた場所でもあります。

DawoodはAIを学びましたが、大学卒業後はシステムエンジニアリングへと軸足を移しました。彼の関心は抽象的なものではありませんでした。彼は本番システムがどのように故障し、チームがどのように対応し、アラートと修正の間にどれほど多くの手動調査が依然として存在しているかを見てきました。

ハイデラバードで開催されたGrafanaのイベントで、その課題はさらに明確になりました。エンジニアたちは同じパターンを説明していました。システムがダウンし、誰かが呼び出され、そしてチームは手作業で障害を追跡するというお決まりの作業を開始するのです。

Quackathonは、何か違うものを構築する瞬間となりました。WhyVenvによって構築されたKronosは、本番環境のインシデント対応をエージェントワークフローに変換したことで際立ち、Quackathonで準優勝を果たし、「Track 01: Software - The Sentient Workspace」チャレンジで頭角を現しました。

WhyVenvが構築したもの

WhyVenvのプロジェクトは、QuackathonのSentient Workspaceトラック向けに構築された自律型インシデント対応エージェントであるKronosでした。

そのアイデアはシンプルですが、野心的なものでした。

Kronosは本番環境のエラーを受信し、ログを読み取り、関連するコードを取得し、AIモデルに可能性のある根本原因を診断させ、次に何が起こるべきかを決定します。

それは時に、GitHubのイシューを作成することを意味します。

問題の深刻度によっては、修正を試みることを意味する場合もあります。

重要なのは、本番環境が壊れていることをエンジニアに通知することだけではありません。通常、アラートの後に続く作業をエンジニアが有利にスタートできるようにすることです。

インタビューの中でDawoodが語ったように、Grafanaのアラートによって、何かがダウンしていることを知るのは簡単になりました。問題はその後のすべてでした。何が問題を引き起こしたのか、バグはどこにあるのか、そしてチームがどのような行動をとるべきかを見つけ出すことです。

Kronosはその中間層を自動化するために構築されました。

Kronosの背後にあるエンジニアリングの洞察

「私が最も誇りに思っている部分は、情報取得の段階です。ASTやエンベディングだけを使用するのではなく、トレースログから作業を進めました。それが、エンジニアが通常問題を見つける方法だからです」

Dawoodが最も誇りに思っていたのは、ダッシュボードでも、GitHubの連携でも、AIによる診断でもありませんでした。

それは情報取得の段階でした。

多くのAIコーディングシステムは、エンベディング、AST解析、または広範なコンテキストの読み込みを通じてコードベースを理解しようとします。Kronosは、よりエンジニアに馴染みのあるルートを採用しました。トレースログから開始し、それらを使用して検索範囲を絞り込むという方法です。

その選択が重要になります。

エンジニアが本番環境の障害をデバッグするとき、最初にAIモデルにリポジトリ全体を読み込ませるようなことは滅多にしません。彼らはエラーを見ます。スタックトレースを追います。コードをgrepします。症状から原因へと移行していくのです。

Kronosもまさにその直感に基づいて設計されました。

このシステムはログをエントリポイントとして使用し、最も関連性が高いと思われるコードを取得し、その後初めてAIモデルをワークフローに組み込みます。これにより、モデルはすべてを見通す神託のような存在ではなく、焦点を絞った証拠のパケットから作業するレビューアのようになります。

Dawoodは、このアプローチを大規模に信頼できるようになるには、まだ洗練させる必要があることを明確に認めていました。しかし、デモにおいては機能しました。さらに重要なことに、それは真剣な製品への直感を反映していました。優れたAIシステムは、エンジニアのワークフローを盲目的に置き換えるものではありません。エンジニアがすでに問題を解決している方法から学ぶのです。

Enter Proでオブザーバビリティスタックを構築する

Kronosは、チームがこれまで深く使用したことのないツールをまたいで機能させる必要がありました。

Grafana、Prometheus、Loki、ダッシュボード、ログ、メトリクス、アラート。

ハッカソンチームにとって、実際の製品が機能し始める前に理解すべきインフラストラクチャとしては、これは非常に膨大な量です。

ここで、Enter ProがWhyVenvにとって有用なものとなりました。

チームはプロジェクト全体を通じて、調査、アイデアの洗練、デバッグにEnter Proを使用しました。Dawoodと彼のチームメイトは、オブザーバビリティスタックを理解し、コンポーネントがどのように適合するかを把握し、システムが期待通りに動作しないときの統合の問題を乗り越えるためにこれを使用しました。

ある瞬間が際立っていました。

チームは、データアラートがなぜ正しく届かないのかという問題で行き詰まっていました。彼らは他のAIモデルを試していましたが、Dawoodは、チームがすでに修正した後でも、一部のモデルが同じポイントをぐるぐると指摘し続けているように感じていました。

彼らがEnter Proを試してみたところ、より直接的に実際の原因を特定するのに役立ちました。

それこそが、ビルドスプリントにおいて重要な瞬間です。洗練されたデモの回答でも、一般的な提案でもありません。本物の障害物を突き破る具体的な後押しです。

WhyVenvにとって、Enter Proは単にコードを生成する場所ではありませんでした。構築を継続するのに十分な速さで、馴染みのないシステムを論理的に思考するための手段だったのです。

2日間の集中

Dawoodは、チームが本格的な開発を開始する前にプロジェクトを計画していました。

彼は自分たちが何を構築したいのかを知っていました。基本的なアーキテクチャを考え抜いていました。作業をどのように分担すべきか、大まかな感覚を持っていました。

そして、実際のハッカソンのリズムが始まりました。

初日はコードばかりではありませんでした。チームは一緒に時間を過ごし、話し、冗談を言い、自分たちの足場を固めました。本当の構築はその後にやってきました。作業を分担し、馴染みのない部分を調査し、コアフローを実装し、製品が形を保てるようになるまで洗練させるという、集中したスプリントです。

アーキテクチャはシンプルに始まりました：

クラッシュレポート -> 関連コード -> LLM診断 -> イシュー作成または修正。

その後、チームが構築を進めるにつれて、各パーツはよりシャープになっていきました。

そのシンプルさこそが、Kronosが魅力的である理由の一部です。これは、エージェント型ソフトウェアの複雑な理論から始まるのではありません。オンコールのエンジニアなら誰でも理解できるワークフローから始まります。何かが壊れた、原因を見つける、次に何をすべきかを決定する、という流れです。

Kronosが示唆するAIエージェントの姿

Kronosは、コードベースの横に座っているチャットボットではありません。

それはワークフローエージェントに近いものです。現実世界からシグナルを受け取り、適切な証拠を収集し、推論が有用な場合にのみ推論を求め、その結果をエンジニアがすでに使用しているツールにルーティングするシステムです。

その違いが重要です。

Dawoodは、AIシステムを取り巻くコストと制御の問題に敏感です。インタビューの中で、彼はトークンの使用量、高価なモデルの呼び出し、そして決定論的なバックエンドロジックが作業の一部をより効率的に処理できる場合に、エージェントにすべてを処理させないことの重要性について語りました。

それは、2026年にAIを使って構築を行う人物として、成熟した直感です。

AIエージェントの未来は、より強力なモデルを使用することだけではありません。いつそれらを使用しないかを知ることでもあります。どの部分をコードにすべきか？どの部分を情報取得にすべきか？どの部分をモデルの推論にすべきか？どの部分を人間のレビュー下に残すべきか？

Kronosは、ハッカソンのプロジェクトでありながらも、その問いを指し示しています。

次に何が来るか

このプロジェクトが本番環境に対応できるようになる前に、まだ解決すべき疑問があります：

情報取得のアプローチは、より大規模なコードベースにおいてどの程度うまくスケールするのか？
深刻度と自律性はどのように調整されるべきか？
エージェントは、修正を試みる代わりに、いつイシューを作成すべきか？
モデルが実際のインシデントを診断するのに、どれだけのコンテキストがあれば十分なのか？
何かが本番環境に到達する前に、人間は何を承認すべきか？

これらは小さな疑問ではありません。これらこそまさに、Kronosに注目する価値を与える疑問です。

なぜなら、本番環境のインシデントがなくなることはないからです。唯一の疑問は、すべての対応が手動のパニックから始まらなければならないのかどうかです。

Kronosは異なる第一歩を想像しています。障害を検知したシステムが、それを理解し始めることもできるというステップです。

それこそが、Enterが支援するために存在している理由です。

単にコードを速く書くだけではありません。実際の痛点から機能する製品へと、より迅速に移行することです。

そしてWhyVenvにとって、その移行は、苦痛を伴うエンジニアリングのパターンをQuackathonの受賞プロジェクトの1つへと変えるのに十分なものでした。

探索する： Kronos。

このストーリーは、私たちのQuackathon Builder Seriesの一部です。このシリーズでは、開発者がEnter Proを使って何を作ったのか、なぜそれを作ったのか、そして彼らの仕事がAIを活用したソフトウェア作成の未来について何を物語っているのかを理解するために、プロジェクトを1つずつ取り上げていきます。今後の展開にご期待ください。