AIがコードを書いて、AIがレビューする。Money Forward 1,000人・PlanetScale 2FTE削減の現場で何が起きているか

「Composer 2の正体、実はKimi K2.5でした」——そんなTechCrunch（テッククランチ）の記事が出た2026年3月22日、私はある一次データを読んでいた。

PlanetScaleという海外のデータベースSaaS企業が、Cursor（カーソル）の公式ブログに掲載したレポートだ。

“Code has become cheap. The bottleneck is now whether your code is correct and whether you understand what it does.”

「コードが安くなった。ボトルネックは、コードが正確かどうかと、自分がそのコードを理解しているかどうかだ」

この一文が、バイブコーディング（AIと対話しながらコードを書くスタイル）のフェーズが変わったことを端的に表していると思う。

「速く書ける」は達成された。次の問いは「任せられるか」だ。

今回はComposer 2リリース直後の炎上も含めて、この変化の本質をデータで読み解いていく。PlanetScaleとMoney Forwardの一次ソース数値、そしてチームに展開するための実践設計まで。

Bugbotの現在地——解決率76%・月200万PRの「今」

Cursor Bugbot（バグボット）は、プルリクエスト（PR：コードの変更提案）を自動でレビューしてバグを検出・修正するAIエージェント（自律的に動くAIプログラム）だ。

2026年2月25日に正式リリースとなった現行バージョンの数字を見てほしい。

解決率: 76%（初期の52%から40回の改善実験を経て到達）
月次処理量: 月200万プルリクエスト
自動マージ率: Autofixの提案のうち35%がそのままベースブランチにマージ

バグ発見件数は旧バージョン比でほぼ2倍。自動マージ率35%というのは、「AIが直したコードを、人間がほぼそのまま採用している」ことを意味する。

価格は$40/ユーザー/月（Cursor本体とは別料金）で、200PR/ユーザー/月のプール制。エンタープライズ向けには無制限プランも用意されている。

Rippling、Discord、Samsara、Airtableなどが導入済み。University of Chicago（シカゴ大学）の調査では、Bugbotをデフォルトのレビュアーに設定した企業でPRマージ数が39%増加したというデータも出ている。

「レビューがボトルネックになっているから開発が遅い」という現場の課題に対して、Bugbotは構造的な回答になりつつある。

# BugbotをデフォルトレビュアーとしてGitHub連携する設定例
# .cursor/bugbot.yaml

bugbot:
  default_reviewer: true   # 全PRにBugbotを自動追加
  autofix: true            # 修正可能なバグはAutofix PRを自動作成
  severity_threshold: medium  # medium以上のバグを報告（low以下はスキップ）
  languages:               # 対象言語を明示
    - typescript
    - python
    - ruby

BugbotのPRレビューワークフロー図。PR作成→Bugbot自動起動→問題検出→Autofix PR作成→人間レビューの流れ

PlanetScaleの証言——「2FTE削減」の中身

PlanetScaleはMySQL互換のクラウドデータベースを提供する企業で、GitHubやStripe（ストライプ）などの大規模サービスを顧客に持つ。

同社がBugbot導入後にCursor公式ブログのケーススタディとして報告した数字がこれだ。自社媒体への掲載という性格上、企業側にとって好意的な文脈での発表である点は留意してほしい。ただし、PlanetScaleとMoney Forwardはいずれも実名で語っており、数値の虚偽申告は企業信用に直結する。参考情報として一定の信頼度は置ける。

Bugbotコメントの80% がマージ前に解消
コードレビュー工数が 2FTE相当 削減

FTE（Full-Time Equivalent：フルタイム換算の人員数）とは、フルタイム社員1人分の工数を1FTEとする単位だ。Bugbotがフルタイム社員2人分のコードレビュー工数を肩代わりした計算になる。

なぜここまでの効果が出たのか。背景にあるのは、AIエージェントが書くコードの量が爆発的に増えたことだ。

人間が書く速度でコードが増えていた時代は、人間のレビュアーがなんとか追いつけた。AIが書くと速度が10倍以上になる。レビュアーの処理限界を超えるのは時間の問題だった。

「コードが安くなった」の意味はここにある。生産コストが下がった一方で、品質保証のコストが相対的に上がった。PlanetScaleが直面したのはこの問題で、Bugbotはその解決策として機能している。

もう一つ注目すべき点がある。「コードが正確かどうか」という問いだ。バイブコーディングで量産されたコードは、動くが危うい可能性がある。Sia Partners（戦略コンサルティング会社）が2026年3月に出した調査では、AIコーディングで速度は急増したが「組織が捕捉できる価値は追随していない」という指摘がある。これを「生産性パラドックス」と呼んでいる。

Bugbotが76%のバグを検出・修正することで、この「捕捉できる価値の差」を埋める役割を担っている。

# Bugbotの実際のレビューコメント例（Cursor公式ブログより）
# PR: ユーザー認証処理のリファクタリング

# Bugbotの指摘例:
# 🔴 High severity: SQLインジェクションの脆弱性
#    Line 42: f"SELECT * FROM users WHERE id = {user_id}"
#    Fix: プレースホルダーを使用してください
#    ↓
#    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# 🟡 Medium severity: 未処理の例外
#    Line 67: db.connect() の戻り値のエラーハンドリングなし
#    Fix: try/except でラップして適切にログを取る

# Autofixが適用可能な場合はPRを自動作成

Money Forwardで1,000人が使う理由——エンジニア以外への拡散

マネーフォワードのデータは、また別の角度を見せてくれる。

同社のMEPAR（マネーフォワードエンジニアリング生産性・AIリサーチ）部門のレポートによると、現在1,000人超が毎日Cursorを使っている。驚くのはその内訳だ。エンジニアだけでなく、PM（プロダクトマネージャー）・デザイナー・QA（品質保証担当）にまで使用が拡大している。

定量的な効果の数字はこうだ。

エンジニアの週15〜20時間の節約
QAチームのテストケース生成時間70%削減

週15〜20時間というのは、週の実働時間の約40%に相当する。半分近くの時間が他のことに使えるようになる計算だ。

Money ForwardがCursorを選んだ理由として公式が挙げているのが「モデル非依存のインフラ」という点だ。特定のAIモデルに依存しない構造なので、Composer 2のようなモデルアップデートがあっても業務フローを変えずに移行できる。

エンジニア以外への拡散という点が、私には特に刺さった。CS（カスタマーサクセス）出身の自分からすると、「ツールがエンジニアの領域を超えた」という事実は組織の変化を意味する。PMやQAがコードに近い存在になると、エンジニアとの認識齟齬が減る。チーム全体の品質への感度が上がる。

「自分の仕事を自動化できる人」の定義が変わってきている。

Composer 2の炎上を読み解く——透明性問題の本質

2026年3月19日にリリースされたComposer 2は、アーキテクチャーの大幅変更を伴う。

主なスペックはこうだ。

ベースモデル: Moonshot AIのKimi K2.5（誰でも中身を確認できるオープンソースのAIモデル）
コンテキスト長: 200,000トークン（約15万文字分の文脈を一度に処理できる）
価格: Standard $0.50/Mトークン、Composer 1.5比で86%安
ベンチマーク: Terminal-Bench 2.0でClaude（クロード） Opus 4.6を超える

問題は、Cursorが当初「ベースモデルはKimi K2.5である」と開示していなかったことだ。

3月22日、TechCrunchが「Cursor admits its new coding model was built on top of Moonshot AI’s Kimi」という記事を公開し炎上した。その後Cursorは事実を認め、「継続事前学習とRLにかけた計算コストの約75%がCursor側」という補足説明を出している。

私の見立てでは、これは「詐欺」ではなく「説明の失敗」だ。ゼロから作ったわけではないが、Cursorの独自チューニングが実質的な性能差を生んでいるのも事実。オープンソースモデルをベースに企業が独自で鍛え直すのは今や一般的なアプローチで、透明性をどこまで示すかはまだ業界で規範が定まっていない。

この炎上から実務として学べることがある。モデルの出自より性能で判断するのがプラグマティックだということだ。

# Composer 2 価格比較（2026年3月時点）

# Standard モード
# 入力: $0.50/Mトークン
# 出力: $2.50/Mトークン
# 用途: ドラフト生成・大量テキスト処理

# Fast モード
# 入力: $1.50/Mトークン
# 出力: $7.50/Mトークン
# 用途: 複雑なマルチファイル編集・リアルタイム応答が必要な場面

# Composer 1.5 → 2 の変化
# コスト: -86%（Standard比較）
# コンテキスト: 100K → 200K トークン
# ベンチマーク: SWE-bench Multilingual で大幅改善

Composer 2とComposer 1.5の性能・価格比較表。コスト86%削減とベンチマーク改善を視覚化

Automations × Bugbotのフルスタック設計

2026年3月3日リリースのCursor v2.6に含まれた「Automations（オートメーションズ）」は、Bugbotとの組み合わせで真価を発揮する。

AutomationsはSlack・Linear（プロジェクト管理ツール）・GitHub・PagerDuty（インシデント管理ツール）などのイベントをトリガーに、Cursorのエージェントが自動で起動する仕組みだ。「コードレビューパイプラインの自動化」と言えば伝わりやすい。

実際のフローはこうなる。

GitHubにPRが作成される
AutomationsがトリガーしてCursorエージェントが起動
エージェントがコードを解析してBugbotにレビューを依頼
Bugbotが76%の問題を自動解決してAutofix PRを作成
残り24%だけ人間がレビュー

このフローが回ると、人間が集中すべき箇所が「全レビュー」から「複雑な判断の24%」に変わる。チームで回している場合、ここの変化は大きい。

実際に試したところ、PRのファーストレビューにかかる時間が体感で半分以下になった。エラーのある箇所はBugbotが先に指摘しているので、人間のレビューが「確認と設計の議論」に集約される形になった。

# .cursor/automations.yaml の設定例（チーム運用向け）
automations:
  - name: pr-review-pipeline
    trigger:
      event: github.pull_request.opened    # PRが作成されたとき
      filter: "draft: false"               # ドラフトPRは除外
    steps:
      - agent: code-review
        action: analyze_changes            # 差分を解析
        options:
          check_security: true             # セキュリティ脆弱性チェックを有効化
          check_performance: true          # パフォーマンス問題をチェック
      - agent: bugbot
        action: scan_and_fix              # バグスキャン＋Autofix
      - notify:
          channel: slack                   # Slackに結果を通知
          template: "bugbot-summary"       # 要約テンプレートを使用

Automations×Bugbotのフルスタック設計フロー図。GitHub PR作成→Automationsトリガー→Cursorエージェント起動→Bugbotスキャン→Autofix PR作成→Slack通知→人間レビュー（24%のみ）という流れを1枚に整理

「ここまで設定できるの？」と思った人もいるかもしれない。最初は私も半信半疑だった。Money ForwardやPlanetScaleの実績を見ると、これが絵空事でないことはわかる。チームの規模が大きいほど、このフローの恩恵は大きくなる。

「品質保証フェーズ」の設計3原則

実践編として、バイブコーディングを「速く書けるフェーズ」から「任せられるフェーズ」に移行するための3原則を共有する。

原則1: 人間のレビューを「例外処理」として設計する

BugbotのAutofix率は35%だ。言い換えると、65%は人間のジャッジが必要ということでもある。全部AIに任せようとすると、この65%でつまずく。

「AIが処理できる問題」と「人間が判断すべき問題」を事前にリストアップしておくことを勧めたい。セキュリティ要件・パフォーマンス要件・ビジネスロジックの変更は必ず人間がレビューする、という線引きだ。

このリストをチームで共有しておくと、レビューの属人化も防げる。

原則2: モデルに依存しない設定ファイルを作る

Composer 2炎上が示すように、モデルは変わる。Money Forwardが「モデル非依存のインフラ」にこだわった理由はここにある。

プロンプトテンプレートと設定ファイルをGitに含めておくと、モデルが変わっても業務フローを変えずに済む。

# チームのCursor設定をgit管理する構成例
# .cursor/
#   ├── bugbot.yaml          # Bugbot設定（severity閾値・対象言語など）
#   ├── automations.yaml     # Automations設定（トリガーとアクション）
#   ├── rules/               # コーディングルール
#   │   ├── typescript.md    # TypeScript固有のルール
#   │   └── security.md      # セキュリティ要件
#   └── prompts/             # チーム共有プロンプト
#       ├── code-review.md   # レビュー観点のプロンプト
#       └── test-gen.md      # テスト生成プロンプト

# コミット例
git add .cursor/
git commit -m "chore: add team cursor config for review pipeline"

原則3: 「書いたコード量」と「リリースできたコード量」の比率を見る

Sia Partnersの「生産性パラドックス」が指摘するように、速度が上がっても品質保証が追いつかなければコードは積み上がるだけだ。

月次で「コミット数」と「リリースに至ったコード量」の比率を確認してみてほしい。Bugbot×Automationsの設計が機能していれば、この比率が改善してくる。比率が改善しない場合、Bugbotの閾値設定やAutomationsのフローに見直しポイントがある。

まとめ——「速さ」から先の問いへ

今回取り上げた数字を整理する。

指標	数値	示していること
Bugbot解決率	76%	AIレビューが実用域に達した
Autofix自動マージ率	35%	AIの修正をそのまま採用できる水準になった
PlanetScale FTE削減	2FTE相当	レビュー工数の構造的な代替が起きている
Money Forward導入規模	1,000人超	エンジニア以外への拡散フェーズに入った
Composer 2コスト削減	86%安	以前より大量に・低コストで使える土台ができた

Composer 2の炎上は「透明性の問題」として報じられたが、実務的な判断軸はベンチマークとコストだ。Composer 1.5比86%安でTerminal-Bench最高クラスのスコアを出している事実の方が、選択基準として重要になる。

「バイブコーディングで書ける」は多くの人が達成しつつある。次のハードルは「チームで運用できる」「品質を保てる」「書いたコードの意味を自分が理解している」に変わってきた。

PlanetScaleの言葉を借りれば、「コードが安くなった」からこそ問われるのは正確性と理解だ。Bugbot×Automations×Composer 2の組み合わせは、そのフェーズへの現実的な入り口だと思っている。

CS出身の自分が「チームへの展開」という視点でツールを見るのは、自分だけが速くなっても組織の成果物が追いつかなければ意味がないからだ。速さの恩恵をチームに渡せるか、が次の問いになっている。

参考・出典

Cursor Blog「Bugbot Autofix is now generally available」(2026-02-25)
Cursor Blog「PlanetScale: Cursor in Production」(cursor.com/blog/planetscale)
Cursor Blog「Money Forward: Cursor in Production」(cursor.com/blog/money-forward)
Cursor Blog「Introducing Composer 2」(cursor.com/blog/composer-2, 2026-03-19)
TechCrunch「Cursor admits its new coding model was built on top of Moonshot AI’s Kimi」(2026-03-22)
Cursor Changelog v2.6 — Automations (cursor.com/changelog, 2026-03-03)
Sia Partners「バイブコーディング生産性パラドックス」(2026-03)
University of Chicago調査データ (cursor.com/blog/bugbot-autofix より引用)