エラーレポートからプルリクエストを起草するAI

実際に費用を払っているワークフロー。

2026年の手動バグトリアージは次のようになります。

1. Sentryアラートが発報。
2. 誰かが通知を受け取る（営業時間外であれば朝まで待つ）。
3. エンジニアがSentryを開き、スタックトレースを読み、コードベースを開く。
4. 何が起こっているかを理解するために周辺のコードを読む。
5. 修正が明白であれば、それを書く。
6. そうでなければ、Slackを開いて、最後にこのファイルを触った人を見つける。
7. コンテキスト付きでPRを開く。
8. マージ。

ベストケース：エラーあたり30分。ポートフォリオオペレーターの現実的なケース：エラーあたり2時間。なぜなら、「コードベースを開く」には、数週間見ていなかった製品のコンテキストを読み込む作業が含まれるためです。

1日あたり数十のエラーが発生する15の製品の場合、これはフルタイムの役割になります。あるいは、毎週増え続けるバックログになります。

AIチームメイトが代わりにすること。

1. Sentryアラートが発報。
2. AIチームメイトは、アラート、スタックトレース、周辺コード、git blame、最近のコミット、および Slack のコンテキストを読み取ります。
3. 判断：実際のバグかノイズか？（不安定なテスト、サードパーティAPIの一時的な障害、既知の重複をフィルタリングします。）
4. 実際のバグであれば、修正案を作成し、適切なブランチに対してPRを開き、PRの説明にコンテキストを追加し、レビュー担当者をタグ付けします。
5. エンジニアがレビューし（通常5〜20行）、承認または編集します。
6. マージ。

時間短縮：単純な修正で90%、複雑な修正で60%。

ポートフォリオ規模では、これは「バグトリアージ専任者がいる」と「修正が入り次第出荷する」の違いです。詳細については、 自律運用 のより広範なパターンを参照してください。

PRを作成するAIに求めるもの。

• 1. エラーだけでなく、実際のコードを読み取る。 エラーメッセージしか見ない製品は、幻覚的な修正を生み出します。
• 2. git履歴を読み取る。 このファイルを最後に触ったのは誰か？gitを認識しない製品は、既に修正されたバグを再導入します。
• 3. チームのPRパターンを使用する。 記述的なコミットメッセージ、必要に応じてテスト。
• 4. ノイズをフィルタリングする。 すべてのアラートが実際のバグではありません。
• 5. リポジトリ単位ではなく、ポートフォリオ全体を認識する。 単一の製品であれば、どんなコーディングAI（Cursor, Claude Code, Codex）でも機能します。5つ以上の製品のポートフォリオの場合、AIはどの製品、どのリポジトリ、どのチームかを理解する必要があります。
• 6. 誤ったPRを適切に処理する。 間違ったPRを閉じるのはワンクリックであるべきです。

2026年にこれを実現する製品。

コミットする前に評価する方法。

• ステップ1. 過去30日間の実際のSentryエラーから10個を選びます。単純なものと複雑なものを混ぜます。
• ステップ2. それぞれのエラーをAI employeeに与えます。PRをドラフトするよう依頼します。
• ステップ3. 各PRを評価します：正確性、完全性、慣例、コンテキスト。
• ステップ4. 製品間で比較します。10個中8個を正しく処理し、残りの2個を適切に処理する製品は、単純なエラーでは10個中10個を正しく処理するが、複雑なエラーでは幻覚を起こす製品よりも優れています。

よくある間違い。

• レビューゲートなしでのデプロイ。 AIがドラフトしたPRを自動マージさせないでください。
• AIをgit履歴に接続しない。 エラーしか見ないAIは、既に修正されたバグを再導入します。
• フィルタリングが積極的すぎる。 「実際のバグのみ」ではエッジケースを見逃します。「すべて」はノイズです。2週間かけて反復します。
• リポジトリスコープ製品からポートフォリオスコープへ移行。 単一リポジトリツール（Cursor、Copilot）は、「どの製品、どのリポジトリ」をネイティブに処理できません。

よくある質問。

読み続ける。

• 5人チームで10以上の製品を運用する方法 →
• AI employeeとは？ →
• ユースケース：自律運用 →
• Qualia vs Viktor →
• デモを予約する →