Croft、全アプリに監視機能を標準搭載

2026年9月22日付でRich Chetwynd氏が執筆したCroftのブログ記事は、ClaudeやChatGPTと会話してアプリを作る人が増える中で生じた空白を描いている。そうしたアプリは動き、チームで共有され、業務の一部になった——そして壊れた。チームに見えるのは「問題が発生しました」という表示だけで、コードを書いたアシスタントには何も見えなかった。従来の監視ツールはアカウント、コードに組み込むSDK、そして通常はセットアップと結果の読み取りを担うエンジニアを必要とし、記事はこれを、午後ひとときの会話でアプリを作った人には合わないと論じる。

Croftが提案する解決策は、監視を別製品ではなくプラットフォームの一部にすることだ。応答時間の内訳、スループットと失敗率のチャート、エラーグループ、遅いリクエストのウォーターフォール、最も遅いSQL、7日間のログ、ヘルスチェック、デプロイマーカーに加え、Croftは3つのMCPツール——app_errors、app_metrics、logs——を公開し、コードを書いたのと同じアシスタントがエラーを読み、ログとスタックトレースを確認し、コードを修正して再デプロイできる。Fix with Buildボタンも同様に、スタックトレースとログをCroft Buildに渡す。アラートはアプリごとに1日1回までで、新規エラー、高い失敗率、不健全なアプリの3つのトリガーがある。

鍵を握るのは、アシスタントがスタックトレースとログから正確な修正を導き、人の介入なしに再デプロイできるかどうか、そしてログ、エラー、トレースを顧客自身のサーバーに置き、集計数とタイミングのみをコントロールプレーンに送る構成が、テレメトリの保存場所を気にするチームに十分かどうかだ。エンジニアリングではなく会話でアプリを作った人々にとっての魅力は、修理の道筋がすでに持っているスキル——アシスタントに尋ねること——で済む点にある。