CursorのBugbot努力レベル選択が開発を変える理由｜コストと品質の最適化

AIに「努力」を割り当てる。CursorのBugbotに「努力レベル」の設定が追加された。Defaultは効率重視、Highは推論重視。バグ発見数は0.7個から0.95個へ。この0.25個の差にコストを払う。開発は「単なる自動化」から「コストと品質の最適化」へ移行した。

AIエージェントの「努力」を制御する

CursorのBugbotに、レビューの「熱量」を制御する機能が加わった。Default、High、Customの3つの努力レベルを選択できる。

Default設定は効率とスピードを重視する。1回の実行で発見されるバグは平均0.7個。そのうち79%がマージ時に解決されている。

High設定はAIがより長い時間をかけて推論を行う。バグ発見数は平均0.95個に向上する。レビュー時間は長くなり、コストも増える。賢さを金で買う状態だ。

Custom設定は自然言語で指示を出せる。「認証周りはHigh」「CSS変更はDefault」といった運用が可能だ。AIエージェントの運用は、画一的な自動化から文脈に応じた動的最適化へ移った。

AnthropicはClaude Codeのレート制限を全プランで2倍に引き上げた。SpaceXとの提携による計算リソースの確保が背景にある。22万基のNVIDIA GPUと300MWを超える電力供給が、開発者の待ち時間を削る。

OpenAIはSymphonyという仕様を公開した。GitHubのチケット管理からPRの実装、CIの結果確認、マージまでを複数のエージェントが連携して行う。AIはコード補完の枠を超え、自律的に働くチームメンバーとなる。

しんたろー：
CursorのBugbotの「努力レベル」という言葉選びが気になる。AIも人間と同じで、リソースをかけるほど精度が上がる。全部のタスクに全力投球すればコストと時間が溶ける。どこでAIに本気を出させるか、管理職のような目線が必要だ。

階層的エージェント設計

開発者は「モデルの使い分け」を考える時期だ。ThreadPostの開発でClaude Codeを使う際、すべてのタスクに最強モデルのOpusを割り当てるのは非効率だ。レート制限とコストの壁に直面する。

タスクの性質に応じてモデルの知能とコストを配分する「階層的エージェント設計」が有効だ。以下の3層で考える。

第一の層は「意思決定レイヤー」だ。根本原因の調査や計画立案、クリティカルなバグ発見を行う。ここにはOpus級の知能を投入する。1回の判断ミスが3ステップ以上の手戻りを生む場所だ。CursorのHigh努力レベルを適用する。

第二の層は「実装・分析レイヤー」だ。規約に沿ったコーディングや長いコンテキストの分析を行う。ここではSonnet級のモデルが活躍する。大半の開発タスクはこの層で完結する。

第三の層は「定型処理レイヤー」だ。入出力フォーマットの整形やドキュメント生成を行う。これらはHaiku級のモデルで十分だ。遅さを許容する価値がない処理に高いコストはかけない。

CursorのBugbotの努力レベル選択は、この階層化をGUIで扱えるようにしたものだ。迷ったらデフォルト、重要な場面でブーストをかける。この選択的投資がAI駆動開発の必須スキルになる。

インフラの強化がこの流れを加速させる。Anthropicがレート制限を緩和したことで、制限を気にして並列度を下げる制約から解放されつつある。必要な瞬間に最大火力の推論を並列で走らせる。

OpenAIのSymphonyが目指す世界も同じだ。エージェントが独立した環境でコードを書き、テストを回し、PRを出す。人間はその結果を見てマージを判断する。各ステップで推論コストを最適化する。

しんたろー：
Claude Codeでつい全部を最強設定にしたくなる。だがThreadPostの修正で気づいた。コードの整形にOpusを待つ時間は無駄だ。複雑なロジックのデバッグにHaikuを使って「問題ありません」と言われるのも無駄だ。知能の適材適所が1人SaaS開発の利益率に直結する。

ハーネスエンジニアリングへの役割変容

エージェントが自律化し、努力レベルを選べる今、開発者は「コードを書く監督」から「仕組みを整えるマネージャー」へシフトする。ハーネスエンジニアリングの重要性が高まる。

ハーネスエンジニアリングとは、AIエージェントが安全に働くためのテスト環境やCI/CDパイプラインの整備だ。AIにHighでバグを探させるなら、AIがコードを実行して挙動を確認できる環境が必要だ。テストコードがない場所でAIに頑張らせても、静的解析の範囲でしか機能しない。

開発者の仕事は以下の3つに集約される。

1. タスクの分解と受け入れ条件の定義

AIに何をさせるか、何をもって完了とするかを明確にする。

1. 評価環境（ハーネス）の構築

AIが書いたコードを自動でテストし、パフォーマンスを測定する仕組みを作る。

1. 推論コストの最適化指示

どのタスクにどれだけの努力を割くかを判断する。CursorのCustom設定のように、自然言語でAIの動きを制御するプロンプトを書く。

AIがコードを生成しマージまで行う世界では、人間が一行ずつ書く能力の価値は下がる。AIが生成したコードが正しいと即座に判定できるテストスイートを持つこと。AIに適切な努力をさせて最短ルートでゴールに導くこと。このマネジメント能力が新しい武器になる。

Symphonyのような仕様が普及すれば、この傾向は強まる。独立した環境でエージェントが走り回り、動画付きでPRを送ってくる。コードを書く行為は、AIへの指示と検証に置き換わる。

既存のプロジェクトに強力なテスト環境を構築する。AIにバグを探させる前に、バグを検知できる仕組みがあるかを確認する。そこに投資することが、AI時代の開発者として生き残るルートだ。

しんたろー：
AIがどれだけ賢くなっても、最後に責任を取るのは人間だ。AIが責任を持って働ける土俵を作るのが仕事になる。Claude Codeにコードを書かせながら、横でテストコードを充実させる。この分業体制がしっくりきている。

AI活用に関するFAQ

Q1: Bugbotの努力レベルはどのように設定すべきですか？

基本はDefaultで運用する。スピードとコストのバランスが最適化されているためだ。レビュー漏れが致命的な障害につながるクリティカルな機能や、リファクタリングの影響範囲が広いPRにはHighを設定する。Custom設定を使い、特定のディレクトリ（例：authやbilling）が変更された時だけ自動的にHighにするよう指示する。

Q2: モデルの使い分け（Opus/Sonnet/Haiku）を自動化すべきですか？

初期段階では手動による事後最適化を行う。最初からすべてのタスクを厳密に振り分けると、設計自体に時間を奪われる。デフォルト設定でエージェントを走らせ、速度に不満があれば下位モデルへ、品質に不満があれば上位モデルへと、課題を感じた箇所から調整する。

Q3: エージェントのオーケストレーション（Symphony等）を導入すべきタイミングは？

導入の条件はハーネスエンジニアリングが整っていることだ。エージェントが自律的にコードを書きマージまで行うには、自動テストが不可欠だ。手動でのコード生成やレビューがメインのチームは、まずはCursorやClaude Codeといった単体ツールを使い倒し、開発プロセスにAIを組み込むことに慣れる。

最適化の先にある「書かない開発」へ

AIエージェントの運用は「いかに効率よく、賢く使い分けるか」というフェーズだ。Cursorの努力レベル設定、Anthropicのインフラ強化、OpenAIの自律化仕様はすべて同じ方向を向いている。開発者がコードの細部に拘泥する時間を減らし、上位の設計や価値創造に集中できる世界だ。

AIに努力をさせる権利を手に入れた。どのタスクにHighな推論をぶつけ、どのタスクをDefaultで流すか。この判断がプロダクトの品質と開発体験を形作る。

AIに本気を出させる準備をする。まずは、AIが全力で走れるための「テストという名の土俵」を整える。

👉 ThreadPostでSNS運用を自動化する