多くのエージェントプラットフォームは、あなたとモデルプロバイダーの間に立ち、通過するトークンごとにマークアップを上乗せして課金します。Sharklyはそうではありません。モデル利用はbring-your-own-key（BYOK）方式です。実行にかかる費用は、それを実行するRuntimeにすでに紐づいているClaude Code、Codex、あるいはAPIプランに対して請求され、Sharklyが販売するトークン残高に対してではありません。これは聞こえるほど小さな話ではなく、それが自分にとって重要かどうかを判断する前に、何を節約できるかだけでなく何を負担することになるかについても正直に伝える価値があります。
転売モデルがあなたのインセンティブに与える影響
まずは、実際にトークンを販売しているプラットフォームから見ていきましょう。これがこのカテゴリの既定の姿であり、遠回しに言わずはっきり名指しする価値があります。
プラットフォームがモデルアクセスを転売する場合、その収益はあなたのエージェントが消費するトークン量に結びつきます。これは隠された欠陥ではなく、設計どおりに機能しているビジネスモデルであり、予測可能なインセンティブを生みます。つまり、プラットフォームには実行を安くする理由がありません。より効率的なプロンプト、より小さなコンテキストウィンドウ、より少ないトークンで完了するRuntime——それらはすべて、あなたのアカウントにおけるプラットフォームの収益を減らします。トークン転売業者に、基盤モデルベンダーが行う値下げを還元する義務はなく、あなたの出費を減らすことに報酬もありません。あなたはコーディネーションに対してマークアップを払っていますが、そのマークアップは、プラットフォームがあなたにより多く消費してほしい通貨で建てられているのです。
2つ目のコストはより静かで、後になって表面化します。チームがすでにClaude CodeやCodexのプランを持っている、あるいはプロバイダーとのAPI利用額を確約しているなら、その価格——サブスクリプション階層、ボリュームディスカウント、確約利用料金——はおそらく交渉して勝ち取ったものです。その利用を転売業者経由に回すと、同じレバレッジに対して二重に支払うことになります。アクセス権を得るために転売業者へ一度支払い、さらに直接確保した料金の恩恵を失うのです。今適用されるのは転売業者の料金だからです。モデルベンダーとの間に築いた価格関係は、自社アカウントでトークンを転売するプラットフォームには付いてきません。
ざっくり数字にしてみましょう。いくつかのエージェントを転売業者経由で、控えめなトークン単価のマークアップであっても上乗せして動かし、さらにモデルベンダーと直接結んでいる確約利用額も抱えているチームは、同じトークンに二重に払っています。もう使えない交渉済みの料金で一度、転売業者が決めた任意の料金でもう一度。これを単一のTaskではなく、Sprint分の実行全体に広げると、その差は転売業者が望むまさにその方向に複利的に膨らんでいきます。
だからといって、トークン転売が不誠実だというわけではありません。ただ、プラットフォームの利害とあなたのコストの利害が異なる方向を向くモデルだということであり、ベンダーに実行を預ける前に知っておく価値があります。
BYOKに実際にかかるコスト
この分離はSharkly側にとっても無料ではありません。BYOKの利点だけを並べた記事は、トレードオフを正直に語ったものではなくマーケティングのように読めてしまいます。コストは率直に述べましょう。
キーとクォータは自分で管理します。コーディネーションレイヤーの誰かが、あなたに代わってClaude Codeプランのレート制限やAPIアカウントの残クレジットを見張っているわけではありません。チームが5つのエージェントを1つのAnthropic APIキーで動かしていて、そのキーがレート制限に達したなら、それに気づき対処を計画するのはあなたの責任です。チームの誰かがターミナルから直接それらの呼び出しを行っている場合と同じです。
実行はSharklyとは無関係な理由で失敗することがあります。Runtimeに紐づいたClaude Codeプランがレート制限に達したり、それを支えるAPIアカウントのクレジットが尽きたりすると、実行は停止し、障害はSharklyのダウンではなく、モデルプロバイダーからのトークンエラーまたは認証エラーとして現れます。そのデバッグは、1つではなく2つのシステムを確認することを意味します。Taskが止まっているのはSharkly側の何かが原因なのか、それとも基盤のプランが枯渇したからなのか。これは実在する継ぎ目であり、プラットフォームが管理するトークンプールで滑らかに覆い隠さないことの直接的な代償です。
支出の可視性は2か所に分かれます。Sharklyの使用状況ダッシュボードはエージェントごとの消費を示しますが、請求書自体はClaude Code、Codex、またはAPIプロバイダーの請求書に現れ、Sharklyの1つの明細項目には載りません。経理チームが「今月のAIコーディングにかかったコスト」を1つの数字で知りたければ、1つのサマリーを読むのではなく2つのソースを突き合わせる必要があり、その突き合わせは誰かが実際に行わなければならない手作業です。
オンボーディングのコストもあります。これは無視して当然と決め込むのではなく、明言する価値があります。接続するRuntimeごとに、それぞれのキーやプランを設定する必要があり、チームの誰かがそれらの認証情報の更新とローテーションを担当しなければならず、エージェントを動かしたい新入社員は、Sharklyへの招待だけでなく、基盤となるプロバイダーアカウントへのアクセスも必要とします。転売型のプラットフォームなら、これらすべてを1回のサインアップの裏に隠せます。BYOKは設計上そうではありません。Sharklyを評価するチームは、セットアップがゼロだと期待するのではなく、Runtimeごとに実際に1〜2時間を見込むべきです。
とはいえ、これはBYOKを避ける理由にはなりません。トークンのマークアップを払わない代わりに何を引き受けることになるかの正直なリストであり、チームはインシデントの最中に気づくのではなく、最初からそれを知ったうえで臨むべきです。
管理レイヤーが依然として価値を発揮する場面
Sharklyがトークンを販売しておらず、プロバイダーのレート制限を滑らかにしてくれるわけでもないとなれば、コーディネーションレイヤーが実際に何をしているのかを問うのはもっともです。具体的には3つです。
実行をどのComputerで動かすかを決めます。エージェントのRuntimeには、ローカルでもクラウドでも、Taskが必要とするリポジトリとリソースを備えたホストが必要であり、その割り当ては、実行が消費するトークンを誰が支払っているかに関係なくSharklyの仕事です。トークンの課金と実行の配置は別々の関心事であり、BYOKは前者からプラットフォームを外すだけです。
承認プロセスに人間を関与させ続けます。Agentsは調査し、実行し、テストし、報告します。人間は方向性を定め、権限を与え、結果を受け入れます。そのレビュー工程——Taskがマージまたはクローズされる前に誰が承認するか——は、その下のモデル呼び出しを誰が支払っているかに依存しません。転売業者のマークアップが安いからといって優れたレビュープロセスが手に入るわけではなく、BYOKモデルだからといってそれを失うわけでもありません。
さらに、トークン自体の請求は別の場所で行われるにもかかわらず、エージェントごとの消費を示す使用状況ダッシュボードを提供します。Sprintでどのエージェントが最も多く消費したか、どの種類のTaskが自動化にコストがかかるか、どのRuntimeが高負荷になっているかを把握できます。しかも、その可視性のためにSharklyが報告対象のトークンを課金する側である必要はありません。ダッシュボードの有用性は、Sharklyが請求を握っているかどうかに依存しないのです。
これがこの分離の実際の姿です。Sharklyは、作業をどこで動かすか、誰がレビューするか、動かすのにいくらかかっているかを管理しますが、測定対象そのものを販売するベンダーである必要はありません。
そのトレードオフに見合う価値があるかを見極める
チームが小さく、Runtimeが1つで、レート制限にほとんどぶつからないなら、転売型かBYOKかという問いは、どちらでも日々の仕事を大きく変えることはおそらくありません。トレードオフが現実になるのは、同じ基盤プランに対して複数のエージェントを動かしたり、複数のComputerをまたいでCrewsを連携させたり、複数のチームについて「今SprintのAIコーディングに実際いくらかかったか」に答えようとしたりするときです。その段階では、あなたのトークン支出を高く保つ隠れたインセンティブを持つプラットフォームは、完全には見えないコストであり、売り手側に回ることなく、使った分をただ教えてくれるプラットフォームは、ダッシュボードが2つになる不便さに見合う価値があります。
Sharklyの賭けは、課金・計測の問題ではなく、コーディネーションの問題こそが対価を払う価値のあるものだという点にあります。それは、あなたとエージェントが消費するトークンの間にもう一社ベンダーを挟むものではなく、すでに動かしているエージェントの上のレイヤーです。すでにClaude CodeやCodexに直接支払っていて、トークンの上にマークアップが乗ることなく、実行を割り当て可能・レビュー可能・可視化された状態にしたいなら、それがSharklyが目指してつくられたレイヤーです。そのシート側が具体的にどうなっているかは現在の料金をご覧ください。
