このカテゴリのほとんどのツールは、同じ判断に対して二重に課金する。コーディングエージェントを名簿に加えるためにシート単位で料金を払い、さらに、そのエージェントが作業中に消費するトークンに対しても、多くの場合同じベンダーに、もう一度払うことになる。このモデルのもとで10人のチームに5つのエージェントを投入すれば、請求額は同時に2つの軸で膨らんでいく。Sharklyの料金体系はそれを避けるように設計されており、その仕組みは、さらにエージェントをボードに加えるかどうかを決める前に、きちんと説明しておく価値がある。
TL;DR
Sharklyは現在、5人までの組織であれば無料で、製品の全機能が使え、機能制限もない。5人を超えると、Teamプランで年払い・ユーザーあたり月額7ドル、製品は同じ。セルフホストはチームと直接価格を相談する形だ。Agents、Crews、Computers、Runtimesを追加しても、これらは一切変わらない。シートとは組織に属する人間のことであり、これら4つは人間ではない。モデルの利用はbring-your-own-key方式。Sharklyはトークンを販売していない。実行にかかる費用は、その実行を担うRuntimeにすでに紐づいているClaude Code、Codex、またはAPIプランに対して請求される。
3つのプラン、そしてそれらの間で変わるたった1つの数字
プランは3つあり、最初の2つの違いはたった1つの数字だけだ。
Freeは0ドルで、5人までの組織を対象とし、全機能をシート課金なしで利用できる。Teamは年払いでユーザーあたり月額7ドル、組織が5人を超えた時点で適用される。料金ページには月払いへの切り替えトグルがあるが、月額の数字は公表されていないので、あると想定しないほうがいい。セルフホストはカスタムで「当社と価格を相談」する形であり、Sharklyを自社インフラで運用する必要があるチーム向けだ。この話はデモ通話で行われるもので、価格表に載っているものではない。
FreeとTeamは同じ機能リストを提供する。共有AgentsとCrews、共有Skills、Issues、Projects、Sprints、ボード・リスト・テーブル・ダッシュボード・ガントの各ビュー、Spaceワークフロー、分離されたworktree、ComputersとRuntimes、利用状況ダッシュボード、ゲスト、双方向同期付きのJiraインポート、SlackとFeishuのチャットブリッジ。Teamで新たに解放される機能は何もなく、Freeにすでにある機能がすべて使える。有料対象となる2つのティアで唯一変わるのは組織の規模であり、これはこの分野のほとんどのツールが使う価格のレバーとは大きく異なる。だからこそ、以下のシート計算は丁寧にやっておく価値がある。
実際にシートとして数えられるもの
Sharklyの定義では、シートとは組織に属する人間のことだ。ルールはこれだけだが、聞こえ以上に厳格で、人間でないものはほぼすべて除外される。
Agentsはシートを占有しない。Agentとは保存された作業構成（指示、Skills、Runtime、リポジトリ、実行設定、可視性）であり、人間でも単発のプロンプトでもない。したがって、10個目や50個目のAgentを作成しても、請求上の人数には影響しない。リーダーAgentと他のAgentやPeopleメンバーを1人のオーナーのもとにまとめるCrewsも、組織にすでにいる人間を除けば、シートを追加しない。Computersは、実行が実際に走るホストであり、人間ではない。だからノートPC1台とクラウドホスト3台を接続してもシート数は動かない。そしてRuntimes、つまりSharklyがComputer上で検出する具体的なコーディングツールは構成であり、人数ではない。
ゲストも言及しておく価値のあるもう1つのケースだ。ゲストもシートを占有しない。これは、クライアントや請負業者が組織に正式に加わらずにTaskを閲覧する必要がある場合に重要になる。
まとめると、請求額を増やす唯一の要素は人間を追加することだ。Agentが実行するために必要なものすべて、そしてAgent自体も、そのカウントの外側にある。
これを検討する価値のある計算
4人のエンジニアチームが、Claude CodeとCodexの習慣と並行して5つのコーディングエージェントを稼働させるかどうかを検討しているとしよう。エージェントをユーザーとして数えるシートモデルでは、4人のチームに5つのエージェントを加えると、誰かがTaskを入力する前に、請求書上の人数が2倍以上になる。Sharklyのモデルでは、5つのAgentを動かそうと15個を動かそうと、チームは4シートのままで、Freeの組織上限である5人に余裕で収まる。Teamの料金に移行するかどうかは、追加するAgent、Crew、Computerの数とはまったく関係がない。純粋に6人目の人間が組織に加わるかどうかで決まる。
ここで注目すべきはこの逆転だ。このカテゴリのほとんどは、エージェントの導入をコストセンターとして価格設定する。エージェントに委任すればするほど請求額が大きくなり、しかもシートとその背後にある推論の両方で二重に払うことになる。Sharklyは代わりに価格を組織の規模に結びつけているので、チームはプラットフォーム自体に払う金額を気にせずに、動かすエージェントの数を増やせる。新たなAgentを追加する判断と、6人目を雇う判断は、金銭面では無関係のままだ。
これは、複数のエージェントを同時に動かすことで生じる調整の問題を実際に経験したチームにとって、より重要になる。どのAgentがどのTaskを担当しているか、一晩で何が終わったか、何が人間の返答を待っているか、どのComputerに余力があるか。チームが3つ目や4つ目のAgentを追加するのをためらう本当の理由は、請求書ではなくこの問題だ。試すだけで二重に罰せられる価格モデルは、そのためらいをさらに悪化させる。人間だけを数えるモデルなら、少なくともその反対理由は取り除かれる。そうなれば残る疑問は、調整が管理可能かどうか、つまり予算ではなくワークフローの問題になる。
Sharklyはトークンを販売していない
「二重課金」問題のもう半分は推論だ。これについてSharkly自身の立場は明確で、トークンを販売していない。モデルの利用はbring-your-own-key方式で、実行にかかる費用は、その実行を担うRuntimeにすでに紐づいているClaude Code、Codex、またはAPIプランに対して請求される。チームがすでにClaude CodeのシートやCodexのサブスクリプションを支払っているなら、Agentの実行は、人間が同じターミナルに同じコマンドを打ち込んだ場合と同じように、その既存プランから消費される。
だからこそ、料金ページではシートとRuntimesがまったく別の行として扱われている。組織は、支払うとしても、Sharklyには調整レイヤー（割り当て可能なAgents、Taskの記録、Computers、Crews、レビュー、可視性）に対して支払う。トークンについては、それらのAgentが実際に消費した分を、モデルプロバイダーに直接支払う。この2つの間にマークアップは存在しない。転売するトークンがないからだ。
「現在無料」の本当の意味
これははっきりと言っておこう。割引の枠組みで語られる以上の意味があるからだ。Sharklyは現在無料であり、永遠に無料なわけではない。上記のTeam価格は、成長する組織が移行する公表価格であり、組織が5人を超えるか、Sharklyが公表された条件とともに無料の範囲を変更するまでは、誰もその料金を請求されない。今日無料であることは、組織がどれだけ大きくなってもFreeプランが永久に続くという意味ではないし、今日の条件が無期限に固定されるという意味でもない。ページに書かれているとおりの意味だ。今、この組織規模では、価格はゼロだ。
この区別は、無料が永続的な下限だと前提としたワークフローを構築する前に、じっくり考えておく価値がある。今日4人でいくつかのAgentを動かしているなら、この記事の計算は、5人を超えて成長するか、条件自体が変わるか、どちらか早いほうが来るまで成り立つ。実際の料金ページを、その一行要約ではなく読んでいれば、どちらの結果も驚きではないはずだ。
エージェントを追加する価値があるかを見極める
この価格モデルは、特定のTaskに対してClaude CodeとCodexのどちらが適したエージェントかという問いには答えないし、答えるべきでもない。その判断は依然としてチームに委ねられており、Sharklyは意図的にそこには踏み込まない。すでに動かしたいAgentsを管理するのであって、どれを望むべきかは教えない。価格が答えるのは、ずっと狭く、ずっと実用的な問いだ。実験が始まる前にたいていそれを妨げる問い、つまり3つ目や5つ目のAgentをチームに加えることでプラットフォームに払う金額が変わるかどうか。Sharklyでは変わらない。変わるのはトークンに払う金額であり、その請求はすでに関係のあるプロバイダーに飛ぶのであって、その上にSharklyからの2枚目の請求書が載るわけではない。
すでに複数のコーディングエージェントを動かしていて、請求書ではなくエージェント間の調整こそが実際の摩擦なら、それこそがSharklyが取り組むより広い問題だ。
