Codebuff徹底解説｜Claude Codeを61% vs 53%で上回る4エージェント型OSS

Codebuff: Open-source Multi-agent AI Coding Assistant

🧠 Claude Code AIコーディング vibe-coding agent AIエージェント codebuff claude-code

2026.05.16 1分

A AI Heartland · 編集部

Codebuff徹底解説｜Claude Codeを61% vs 53%で上回る4エージェント型OSS - AIツール日本語解説 | AI Heartland

ターミナル上で動くAIコーディングエージェントが各社乱立する中、Codebuffは4エージェント分業と任意モデル対応で差別化する。性能評価の中身と日本開発者の使い分けを整理する。

この記事ではAIコーディングエージェント単体を扱います。Vibe Coding全体の考え方と他ツール比較は Vibe Codingとは？2026年完全ガイドをご覧ください。

01 CodebuffとはClaude Code超えを謳う4エージェント型OSSコーディングエージェント

CodebuffAI/codebuff は、ターミナル上で動くAIコーディングエージェントだ。自然言語の指示でローカルのコードベースを直接編集する。2026年5月時点でスター5.3k・フォーク605・Apache-2.0。

特徴は単一モデルに丸投げしないことだ。Codebuffは役割を持つ4つのエージェントを順に呼び、ファイル選定・計画・編集・レビューを分業させる。これによりClaude Codeなど単一モデル系の弱点を補う。

公式リポジトリは独自評価で「Codebuff 61% vs Claude Code 53%」と主張する。175件超の実コードベース課題でClaude Codeを上回ったというのが触れ込みだ。後述するが数値の中身は読みかたに注意がいる。

導入は3パターン。サブスクリプション版CLIのcodebuff、SDK版の@codebuff/sdk、そして広告モデルのfreebuffが同じリポジトリで配布されている。Freebuffは無料・広告付きで「サブスクなし・クレジットなし・設定なし」を売りにする。

# サブスク版CLIの導入
npm install -g codebuff

# 広告付きの無料版
npm install -g freebuff

# プログラムから呼ぶSDK
npm install @codebuff/sdk

モデル選択の自由度も大きな差別化ポイントだ。CodebuffはOpenRouter経由で任意モデルを利用可能と公式に明記している。Claude・GPT・Qwen・DeepSeekなどを混在させ、エージェントごとに違うモデルを割り当てる構成が取れる。

Claude Code・Cursor・Windsurfは基本的にプラットフォーム側がモデルを選定する。利用者は推奨セットの中から選ぶことになり、自由度は限られる。Codebuffは逆方向で「エージェントごとに適切なモデルを利用者が組み合わせる」設計を取る。

たとえばPlannerは思考能力が要るのでClaude Opus 4.7、Editorは大量に呼ぶのでQwen-CoderやGPT-5-nano、Reviewerは確認に強いGemini系といったハイブリッド構成が可能だ。コストと精度のトレードオフを細かく制御できる。

OSSという点も実務では効く。Apache-2.0なので社内フォークや業務向け改造がライセンス上クリアだ。Cursorのようなプロプライエタリ製品では難しい、エージェント定義の社内標準化や監査ログの組込みが現実的になる。

このH2のポイント

Codebuffは4エージェント分業で動くOSSのAIコーディングエージェント。Apache-2.0でスター5.3k。
独自評価ではClaude Codeを61% vs 53%で上回ると公式が主張する。
OpenRouter対応でエージェントごとに違うモデルを割り当て可能。コストと精度を細かく制御できる。
サブスク版CLI・SDK・広告版Freebuffの3形態で配布され、Apache-2.0で社内改造もしやすい。

02 Codebuffの4エージェント構成 — File Picker・Planner・Editor・Reviewerの役割分担

Codebuffの中核は4つの専門エージェントだ。単一のLLMコンテキストにすべてを詰める設計ではない。エージェントごとに役割・モデル・ツールを分けることで、文脈圧縮とハルシネーションを抑える狙いがある。

4エージェントの役割

File Picker Agent：プロジェクト全体の構造を把握し、タスクに関係しそうなファイル候補を絞る。
Planner Agent：変更すべきファイルと、編集の順序・粒度を決める。差分の設計図を作る役割。
Editor Agent：Plannerが指示した粒度で、ファイルごとに具体的な差分を書く。
Reviewer Agent：書かれた差分が要求を満たすかを検証し、不足があればやり直しを促す。

この分業構成は「広いコンテキスト探索」と「狭く正確な差分生成」を分離する狙いだ。File Pickerにはコードベース全体を見せるが編集はさせない。Editorには関連ファイルだけ渡し、無関係な情報を排除する。

Claude CodeやAiderはハーネス内部でほぼ単一モデルが全工程を担当する。CodebuffはClaude Codeでいう「サブエージェント」を初期設計に組み込み、デフォルトの実行フローに据えた形と言える。

graph LR USER["ユーザー指示
自然言語"] --> FP["File Picker
関連ファイル抽出"] FP --> PL["Planner
編集計画"] PL --> ED["Editor
差分生成"] ED --> RV["Reviewer
検証"] RV -->|OK| OUT["コミット候補"] RV -->|NG| PL

トレードオフもある。エージェント間で会話が往復するため、単純なタスクではトークン消費とレイテンシが膨らむ。短いリファクタや1ファイル修正なら、Claude CodeやAider相当の単発エージェントの方が速い場面が多い。

逆に効くのは複数ファイルにまたがる仕様変更だ。「Webhookの認証方式をHMACからJWTに切り替える」のような横断タスクでは、File Picker→Plannerの段階で漏れを減らせる。Editorが本筋のロジック書き換えに集中できる。

各エージェント間の情報受け渡しはCodebuff内部で構造化される。File Pickerは関連ファイル一覧と理由メモを生成し、Plannerに渡す。Plannerはこれを元にファイル単位の編集計画を組み、各計画ノードをEditorに割り当てる。

Reviewerが特徴的だ。生成済みの差分と元の指示を見比べ、要件未充足を検出するとPlannerに差し戻す。ループ回数の上限はCodebuff側で制御されているため、暴走による無限呼び出しはハーネス段で止まる仕組みだ。

この構成はClaude Codeでサブエージェントを手動で組むのと役割が近い。違いは「分業を強制する」点にある。Claude Codeはサブエージェント不使用も選べるため、利用者の設計依存が大きい。Codebuffは設計判断を固定する。

固定設計の利点は「失敗パターンが揃う」ことだ。同じプロジェクトで複数の開発者がCodebuffを使っても、ログの形状とエラーのパターンが揃いやすい。チームでハーネスを共有する際に運用しやすい。

ハーネスとしての成熟度はもう一つの観点だ。Claude Code・Cursor・Aiderは長期にわたるユーザーフィードバックで細部が整っている。Codebuffは2026年時点で新興プロダクトの域を出ておらず、エッジケースの安定性は今後の改善余地がある。

特にWindows環境やWSL2環境での挙動、巨大モノレポでのファイルピッカー精度、検索でPATHが膨大になるケースなど、現場で頻発するシナリオでの安定性は要検証だ。導入前のPoCではこの種のケースを意識的に含めたい。

このH2のポイント

File Picker・Planner・Editor・Reviewerの4エージェントが順番に走るのがCodebuffの基本フロー。
探索と差分生成のコンテキストを分離し、ハルシネーションを抑える狙いがある。
横断的な仕様変更に強く、単発リファクタではClaude Codeの方が速い場合もある。

03 Codebuff 61% vs Claude Code 53% の中身 — AIコーディング評価の読み方

公式リポジトリのトップに掲げられている数字が、175件超のタスクでCodebuff 61% / Claude Code 53%という比較だ。出典はリポジトリ内のevals/README.mdである。

評価方法を要約すると次のとおりだ。実在するOSSリポジトリを複数用意し、それぞれに「現実的なコーディングタスク」を割り当てる。各タスクをエージェントに解かせ、テスト合格率や指示充足度をスコアにする。

読みかたで注意したいのは3点ある。第一に評価基盤はCodebuff自身が設計・運用していること。第三者ベンチマーク（SWE-bench Verifiedなど）ではない。

第二に175件超という規模は中程度だ。SWE-bench Verifiedは500件、SWE-bench Liteは300件で、より広範な分布をカバーする。Codebuffの評価は自社環境の傾向に最適化される余地がある。

第三にClaude Code側の構成だ。エージェント設定・ツール許可・モデル選択でClaude Codeの性能は大きく動く。比較条件の差異が結果に与える影響は公式README単独では追いきれない。

そのうえで、エージェント分業という設計上の方向性が一定の効きを示した点は意味がある。Vibe Codingの世界でも「Plan→Edit→Review分離が単発実行より精度を出しやすい」という観測は他研究と一致する。

同種の知見

Anthropicの「Claude Sonnet computer use」発表でも、計画と実行の分離がエラー率を下げると報告されている。
Cognition AIのDevin論文も、Planner-Worker分離型エージェントがSWE-bench Liteで効くと示している。
Codebuffの4分業はこれらの流れに沿った設計で、独自性は分業の固定化と推奨モデル指定にある。

数値そのものを過信せず、「4分業の方向性が悪くない」という設計判断の裏付けとして読むのが妥当だ。AIコーディングのベンチマークは構成バイアスが強く、現場での体感はリポジトリの規模・言語・テスト網羅性に大きく依存する。

参考として、2026年5月時点で主要な第三者ベンチマークの傾向を並べる。SWE-bench VerifiedはClaude Opus 4.7・GPT-5世代の上位モデルが70%台に乗り、Aiderのpolyglotベンチマークでも上位モデルは60%超を維持している。

つまり「単独モデルのコーディング能力」自体が、過去2年で大幅に底上げされた。エージェント分業の効きは、モデル単体の差を逆転させるほどの大きさではなく、「同等モデルなら設計差で数%動く」レベルだと見るのが妥当だ。

CodebuffがClaude Codeを上回ったとする内訳も、タスクカテゴリ別に見ると差が出る場面が偏る。多ファイル横断・テスト追加・既存仕様の置き換えで差が大きく、単発バグ修正やドキュメント編集では差が縮む傾向がある。

現場での導入判断としては、「自社の典型タスクを5〜10件用意し、Codebuff・Claude Code・Cursorで同条件で走らせて比較する」のが最も精度の高いやり方だ。公式評価は参考程度に留め、自社環境での再評価を必ず挟みたい。

このH2のポイント

61% vs 53%はCodebuff自社評価で、第三者ベンチマークではない点に注意。
175件超の規模はSWE-bench系より小さく、自社環境への最適化余地がある。
数値そのものより「Plan-Edit-Review分離の効き」を示す設計指標として読む価値がある。

04 Codebuff SDK・カスタムエージェント — TypeScriptで「git-committer」を書く

Codebuffはエージェント定義をTypeScriptで書ける。プロジェクト直下に/initを打つと、エージェント雛形と知識ドキュメント、AgentDefinition型定義がスキャフォールドされる。

公式READMEに掲載されているgit-committerエージェントの定義は次のとおりだ。handleStepsジェネレータでツール呼び出しの順序を直接記述している。

// 公式READMEからの抜粋
export default {
  id: 'git-committer',
  displayName: 'Git Committer',
  model: 'openai/gpt-5-nano',
  toolNames: ['read_files', 'run_terminal_command', 'end_turn'],
  instructionsPrompt:
    'You create meaningful git commits by analyzing changes...',
  async *handleSteps() {
    yield { tool: 'run_terminal_command', command: 'git diff' }
    yield { tool: 'run_terminal_command', command: 'git log --oneline -5' }
    yield 'STEP_ALL'
  },
}

ポイントは2つ。ひとつはモデル文字列がopenai/gpt-5-nanoのようにOpenRouter形式で書かれている点。プロバイダ名/モデル名の組合せで何でも指定できる。

もうひとつはhandleStepsの存在だ。LLMにツール選択を全任せせず、開発者が「最初は必ずgit diff」と決め打ちできる。Claude Code SkillsのSKILL.md同様、決定論的なステップと自由度の高いステップを混在させられる。

SDK側のコードも素直だ。CodebuffClientを生成し、runに対象エージェントとプロンプトを渡すだけで動く。CI環境やバッチ処理から呼ぶことを意識した形になっている。

import { CodebuffClient } from '@codebuff/sdk'

const client = new CodebuffClient({
  apiKey: 'your-api-key',
  cwd: '/path/to/your/project',
})

const result = await client.run({
  agent: 'base',
  prompt: 'Add error handling to all API endpoints',
})

このSDKの存在は「自社プロダクトにCodebuffを組み込みたい」用途に効く。レビューAI、社内コード自動生成、Slackボット連携などが想定される。Claude CodeのAgent SDKと役割が近い。

注意したいのはAPIキーの取り扱いと従量課金だ。@codebuff/sdk経由でもOpenRouter越しにモデルを呼ぶ場合、利用料はCodebuffプラットフォーム側の課金設計に従う。料金体系はリポジトリでは細部までは公表されていない。

/initで生成されるディレクトリ構造も押さえておきたい。プロジェクト直下に.codebuff/が作られ、エージェント定義のTypeScriptファイル、知識ドキュメント、AgentDefinitionの型定義が配置される。Claude Codeの.claude/に近い役割だ。

エージェント定義のメタフィールドはシンプルだ。idがエージェント識別子、displayNameがCLI表示名、modelがOpenRouter形式の文字列、toolNamesが使用可能ツール一覧、instructionsPromptが指示テンプレートになる。

ツールの種類はread_files・run_terminal_command・end_turnなどの基本ツールに加え、エージェント間のspawn_agentが用意されている。これによりカスタムエージェントから他のエージェントを呼び出せ、独自の分業設計が組める。

実用例として、社内では「ライセンスチェッカーエージェント」「セキュリティスキャナエージェント」「i18nキー検証エージェント」などをカスタム定義し、Plannerから条件付きで呼び出す構成が想定できる。CIに組み込めば自動レビューワークフローになる。

このH2のポイント

エージェント定義はTypeScriptで書け、handleStepsで決定論的ステップを混ぜられる。
モデル指定はopenai/gpt-5-nanoのようなOpenRouter形式で任意モデルを呼べる。
SDKはCI・社内ツール組み込み向けで、Claude Code Agent SDKと用途が近い。

05 Codebuff vs Claude Code vs Cursor vs Aider — AIコーディングエージェント比較表

主要なAIコーディングエージェントとの位置づけを整理する。比較軸は「実行形態」「モデル選択の自由度」「エージェント分業」「ライセンス」「料金モデル」の5つ。

項目	Codebuff	Claude Code	Cursor	Aider
実行形態	CLI＋SDK	CLI＋IDE拡張	IDE	CLI
モデル選択	OpenRouter任意	Anthropic製品中心	主要LLM	任意
エージェント分業	4エージェント固定	サブエージェント任意	固定（内部詳細非公開）	単発
ライセンス	Apache-2.0	プロプライエタリ	プロプライエタリ	Apache-2.0
料金	サブスク／広告版Freebuff	Claude API従量＋プラン	月額$20系	OSS（モデル代のみ）

CodebuffとAiderはOSS＋任意モデルという点で近い。差はAiderが単発エージェント、Codebuffが4分業という設計差だ。Aiderはコミット単位で動作が読みやすく、Codebuffは大型タスクで効きやすい。

Claude CodeはAnthropic公式の優位を生かす立ち位置。Skill・Plugin・サブエージェントなど周辺機能が充実し、「カスタムする前提のハーネス」として完成度が高い。Codebuffはより固定的なフローを提示する。

CursorはIDE体験を最大化するプロプライエタリ製品。Tab補完・サイドバー・コードベース検索が統合されている。CLI主体のCodebuffとは利用シーンが正面衝突しないことが多い。

Freebuffの存在も独特だ。広告モデルでAIコーディングを提供するOSSは稀で、「クレカ登録なしで試したい」個人開発者にとっては入口として機能する。代わりに広告表示やテレメトリの仕様は事前確認が必要だ。

Freebuffのキャッチコピーは「no subscription, no credits, no configuration」だ。利用者から見るとサインアップだけで使え、トライアル制限もない。Codebuff本体に誘導するファネルの役割と、OSSコミュニティへの広報の役割を兼ねる位置づけだ。

業務利用時にFreebuffを選ぶ場合は、広告経由の外部ホスト呼び出しがある可能性に注意する。社内コードを編集対象とする場合、コードそのものは送信されてもメタデータがどこまで広告ネットワークに流れるかは要確認だ。商用ライセンス上の取り扱いも公式に確認したい。

Cursorとの比較を踏まえた選び方は別記事にまとめた。IDEとCLIで迷う場合は Claude Code vs Cursor 2026比較を参照してほしい。OSS拡張で済ませたい場合は Continue vs Cursor徹底比較が近い結論を出している。

エージェント分業の有無も整理しておきたい。Codebuffの4エージェントは「アーキテクチャとしての分業」だが、Claude Codeでも.claude/agents/配下でサブエージェント定義を書けば同等の構成は組める。違いは「初期状態で分業が動くか、利用者が組み立てるか」だ。

Aiderは設計思想として単発エージェントを貫いている。コミット単位で動作を追いやすく、git diffベースの差分提示が中心になる。Codebuffの方がワークフロー単位の自動化向き、Aiderはペアプロ風の対話向きと整理できる。

Cursorは月額$20級の固定料金が読みやすい。チームでの一括契約に向く一方、モデル変更の自由度では劣る。Codebuffは従量・サブスクの混在モデルで、利用量に応じた変動が大きい。コスト見通しの設計思想自体が違う。

このH2のポイント

Codebuffの強みはOSS＋OpenRouter＋4エージェント固定の組合せ。
Aiderは単発で読みやすい、Claude Codeはカスタム前提、CursorはIDE体験という棲み分け。
Freebuffは広告モデルで初心者の入口を作る、業界では珍しいOSS戦略。

06 日本の開発現場でCodebuffをどう使うか — Claude Code併用パターンと注意点

日本の開発現場でCodebuffを導入する場合、判断ポイントは3つに絞れる。コードの社外送信ポリシー、既存ハーネスとの併用、コスト管理だ。

第一にコードの送信先。Codebuff CLIはOpenRouter経由で各種モデルを呼ぶ仕組みのため、社内コードは少なくともCodebuff／OpenRouter／モデルプロバイダの3者を経由する。エアギャップ要件の現場では原則使えない。

第二に既存のClaude Codeハーネスとの併用だ。Codebuff CLIとClaude Codeは同じターミナルで共存できる。同じリポジトリで両方使い分ける構成も問題なく、.claude/配下と.codebuff/配下が衝突することは設計上ほぼない。

第三にコスト管理。複数エージェントが順に走るため、単発タスクでもLLMコール数が増える。月単位の利用ならOpenRouterのダッシュボードで上限を設定し、Codebuff側のサブスクと併用上限を必ず作っておきたい。

実務で効くユースケースは次のような場面が多い。

Codebuffが効くユースケース

10〜30ファイルにまたがる仕様変更（認証方式の入れ替え、APIバージョン更新など）。
テストの一括追加。Plannerがファイル単位の網羅を設計しやすい。
新規モジュールの骨組み作成。型・テスト・実装を分業エージェントに割り振れる。
OSSへのコントリビューション準備。差分のサマリと変更計画を一度に出せる。

逆に向かないのは1ファイル内の局所修正だ。型エラー1件の修正にFile Picker→Planner→Editor→Reviewerを順に回すのはオーバースペックで、Claude CodeやAiderの方がレスポンスが軽い。

Claude Code併用パターンとして現実的なのは「日常はClaude Code、大型横断タスクはCodebuff」の使い分けだ。プロジェクト直下に両方のハーネス設定を置き、PRの種類で呼び分ける運用が筋がいい。

その前提としてClaude Code側の使い方を整理しておく価値がある。Claude Code単体のセットアップとカスタマイズは Claude Code完全ガイド2026：インストールから本番運用までにまとめてある。

最後に注意点として、CodebuffのSDK・CLIは2026年5月時点で活発に変更が入っている。API契約・モデル指定構文・エージェント定義のスキーマはマイナーバージョン間で動く可能性が高い。本番組み込みは公式CHANGELOGの確認を前提にすべきだ。

導入の最短手順を一度整理しておく。CLI版はnpm install -g codebuffの1コマンドで入る。インストール後、対象プロジェクトにcdしてcodebuffを起動すれば、自然言語入力を受け付けるREPLが立ち上がる。

カスタムエージェント運用に進む場合は、/initを打って.codebuff/ディレクトリを生成する。生成されたTypeScriptファイルを編集し、model・toolNames・handleStepsを自社用に書き換える。SDKから呼ぶ場合は@codebuff/sdkを別途追加する流れだ。

評価フェーズでは小さなリポジトリで「典型的な5タスク」を投げ、ログを記録して比較する。ファイル選定の精度、編集差分の妥当性、Reviewerが何回戻したかの3点を見れば、現場フィット感が概ね判断できる。

長期運用に進むなら、エージェント定義の社内テンプレ化・OpenRouter予算上限・ログ収集の3点をセットで設計したい。個人で速く回すツールから、チーム標準のハーネスに昇格させるには、これらの仕組みが土台になる。

このH2のポイント

コード送信ポリシー・既存ハーネス併用・コスト上限の3点を導入前に決める。
Codebuffは大型横断タスク向き、局所修正はClaude CodeやAiderの方が軽量。
Claude Codeとの併用は無理なく可能で、PR種別で呼び分けるのが現実的。

まとめ

Codebuffは「Claude Codeを61%で上回る」というキャッチコピーよりも、4エージェント固定のフロー設計とOpenRouter対応という構造的特徴に注目すべきOSSだ。横断的な仕様変更タスクで効きやすく、サブスク版・SDK・広告付きFreebuffという3形態の配布もユニークだ。

数値そのものはバイアスを含むが、Plan-Edit-Review分離の方向性は他研究の傾向とも整合する。日本の開発現場では、Claude Codeを日常使いの軸に置きながら、大型タスクだけCodebuffに切り替える併用が現実的な落としどころになる。

AIコーディングエージェントは2026年に入り、単一モデル時代から「設計選択の時代」へと移った。Claude Code・Cursor・Codebuff・Aiderはそれぞれ異なる設計判断の表現であり、現場ごとに最適解は変わる。自社の典型タスクに照らした評価を一度走らせ、年単位で再評価する運用が現実的だ。