何が起きたか

Composioは、DeepSeek V4 Flashという同一モデルを、Claude Code、Codex、OpenCode、Oh My Piという4つのエージェントフレームワークに載せ替えて30タスクを実行しました。タスクにはGmail、GitHub、Slack、Notionといった実運用のツールが使われています。

結果は「全カテゴリで勝つフレームワークは存在しない」というものでした。成功率が最も高かったのはOh My Piの30問中17問ですが、1タスクあたり272秒と最も遅い。OpenCodeは成功率14/30とわずかに劣るものの、成功タスクあたり0.073ドルで最安。Claude Codeは122秒と最速で、ツール呼び出し回数が最も少なく出力トークンも最少だったにもかかわらず、成功タスクあたり0.195ドルで最も高くつきました。

なぜ重要か

注目すべきは、成功率がフレームワーク間でおおむね近い水準に収まった一方、差が大きく開いたのがコストと速度だったという点です。つまり「どのモデルを選ぶか」ではなく「どの器に載せるか」が、請求額と処理時間を左右する変数として立ち上がってきました。

さらに示唆的なのが、30問のうち7問は、どのフレームワークが実行したかだけで成否が分かれたという事実です。モデルの能力ではなく、ツール呼び出しの組み立て方やコンテキストの渡し方といった実装の差が、タスクの成否そのものを決めていることになります。

点をつなぐ：速い＝安い、ではない

Claude Codeの数字は直感に反します。ツール呼び出しが最少で出力トークンも最少、しかも最速なのに、最も高い。これは、成功タスクあたりの単価という指標が、単純なトークン消費量だけでなく、失敗して無駄になった試行のコストや、入力側に積まれるコンテキスト量を含めて効いてくることを示しています。「出力が短いから安い」という見積もりは成立しません。

逆にOh My Piは、時間をかけて試行を重ねることで成功率を稼いでいる構図が読めます。272秒という数字は、対話的な用途では致命的でも、夜間バッチや非同期の処理では許容範囲です。速度・コスト・成功率の三つは、用途によってどれを人質に取るかが変わる、というのがこの検証の実務的な読み方です。

検証の射程

30タスクという規模は、統計的な決着をつけるには小さく、傾向を示すものと捉えるのが妥当です。またモデルはDeepSeek V4 Flashに固定されており、別のモデルで同じ順位になる保証はありません。それでも「同じモデルでも器で3倍変わる」という事実は、自社の構成を測り直す十分な理由になります。

💼 事業会社視点：これは自社にどう効くか

経営として受け取るべき論点は「AI予算の見積もり単位を、モデル単価からフレームワーク込みの成功タスク単価に変える」ことです。ベンダーが提示するトークン単価だけで年間コストを弾いている場合、3倍の見積もり誤差を抱えている可能性があります。

受託開発・SIerにとっては直接的な収益問題です。エージェント運用を月額固定で請け負うなら、器の選定ミスがそのまま粗利を削ります。逆に、Composioのような比較検証を自社で回せることを提案材料にできれば、単価交渉の武器になります。

SaaS事業者は、Gmail・GitHub・Slack・Notionのような外部ツール連携を前提としたエージェント機能を売っているなら、フレームワーク差で7/30のタスク成否が変わる現実を前提に、SLAとリトライ設計を見直すべきです。ECや事業会社の情報システム部門では、対話型の社内アシスタント（速度優先）と夜間のデータ整備バッチ（コスト優先）で、あえて別のフレームワークを併用する判断が合理的になります。

今週の打ち手は一つ。自社で最も件数の多いAI処理を10〜30件切り出し、成功タスクあたりの実コストと所要時間を実測することです。モデルを変えずに数割のコストが落ちる余地は、この検証が示す通り現実に存在します。