島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

Claude Code Team プランで管理者がメンバー別コストを確認する方法を調べたが、2026年3月時点ではいい方法がなかった

AIと会話しつつ調べたりした後の雑なまとめです。

やりたいこと

Claude Code を Team プランで利用しているとき、管理者がメンバーごとのコスト消費量やトークン使用量を把握したい。

結論

2026年3月時点では、Team プランでメンバー別コストをまともに確認する手段がほぼない。

調べたこと

1. Claude Code Analytics Admin API

GET /v1/organizations/usage_report/claude_code
というエンドポイントがあり、ユーザー別・モデル別のコスト・トークン消費量を取得できる。一見これで解決しそうだが、Team プランのメンバー(OAuth認証 = customer_type: "subscription")のデータが返ってこないというバグ(もしくは未実装)がある。

  • GitHub Issue: #27780(2026年2月報告、未解決)
  • API キー認証(customer_type: "api")のユーザーデータしか返らない
  • ドキュメント上は両方サポートと書いてあるが、実態が伴っていない

2. Web ダッシュボード(claude.ai/analytics/claude-code)

Team / Enterprise プラン向けの管理画面があるが、表示されるのはコードの行数・PR数・コミット数などの生産性指標のみ。コストやトークン消費量は表示されない。

3. OSS ツール

GitHub 上にはいくつか Claude Code のダッシュボード系 OSS があるが、どれもローカルの ~/.claude/ を読む個人向けツール。Admin API
をラップしたチーム向けコストダッシュボードの OSS は見つからなかった。

4. OpenTelemetry ベースのアプローチ(claude-code-otel 等)

Admin API が使えない現状を補うために、Claude Code が出力する OpenTelemetry テレメトリを Prometheus + Grafana で収集・可視化する OSS
が存在する。メンバー別コストの計測は可能だが、インフラ構築や各端末への設定配布が必要で、導入コストはそれなりに高い。

まとめ

手段 メンバー別コスト 現状
Admin API 本来は可能 Team プラン(subscription)のデータが返らないバグあり
Web ダッシュボード 不可 行数・PR数など生産性指標のみ
OSS ダッシュボード 不可 個人向けのみ、チーム用は未登場
OpenTelemetry(claude-code-otel) 可能 インフラ構築・端末設定が必要で導入が重い

Admin API の subscription 対応が修正されれば状況は改善されるはずだが、時期は不明。今すぐ必要なら OpenTelemetry で頑張るか、Issue#27780 にリアクションして対応を待つしかない。

AI時代に分業のあり方が変わりそうだがまだ答えがない

最近は自分が個人の趣味的に作成しているシステムも、自社のプロダクトもAI並行開発が当然のようにできるようになった。 これは基本的に私がメインでAIエージェントの群れを率いてやっているので何も気にせずにタスク作成、アサインなどできるようになっている。

この開発、人間のスケールがとても難しい気がしてきた。

  • タスクごとにアサインとすると、アサインの速度がはやくないと進捗に問題ができる
  • アサイン自体をなくすと同じタスクを取り合ってしまう
  • そもそもアサイン、という作業がコストに感じ始めている

単純に誰がやるかを決めてUI操作するだけなんだが、それをやるよりAI CTO にシュッと依頼してすぐやらせる方がストレスが少ないのだ。

だとすると

  • 完全にアサインをルール化して考えることなくお互いが進められるようにする
  • そもそもタスク進捗を複数人でやることをやめる

が考えられる気がした。

アサインのルール化は「どういうタスクなら誰」というのが難しい。ちょっと考えてみたが例えば新機能開発はAさん、メンテはBさん、のような棲み分けならバッティングはしない。その上でさらに1つのスコープで複数人作業がやりやすいかは疑問だ。

別の分け方として開発はAさん、レビューはAさんとBさん、という形はありかもしれない。人間レビューの遅延が起きやすい状態なので、レビュアーに盛った形。これはドリブンしそうだ。余程の巨大プロジェクトでない限り、このレベルでいける気がする。それ以上の人数になった時に効率いいやり方があまり思いつかない。「人間が相談する」「他の人間のアクションを待つ」がボトルネックになってしまうので、人間 to AI を基本に考える方が楽だ。

もっと広げて考えると、CTOエージェントに対して複数の人間が依頼すればいいのかもしれない。もはやタスク管理はAIエージェントの役割として完全に委譲する。そうするとCTOエージェントはチームで共有されるメンバー的になるんだな。今の性能を考えるとこれが妥当にも思えてきた。

ちなみに、1タスク1PRのルールをエージェントに課しておくとPRの単位が人間のそれと同等になるので大変やりやすいし、AIエージェントからタスクスコープの調整を提案してくるので良い。これはレビューしないといけない系のプロジェクトでは大体適用して良さそうに感じる。

もっと「上手くやろう」とすると、難しい

AIのCTOを立てたから楽になると思っていたんだけれど、確かに並行作業はすごくやりやすくなって、PRのマージまでの時間やコストははるかに下がっている。この2日くらいの成果が笑えるくらい多い。

今のAIは「動く」までのところをちゃんとやってくれるようになった。昨年はそれをやらせるのをすごく工夫していたけど、この成長は本当に目覚ましいと感じている。

次は適切なコードの状態をできる限り維持したいのだけど、それをしようとすると最後のPRレビューの自分がしんどくなる。人間が相手の時はそれは育成的なものと一緒になるから次第に良くなる期待を元に説明もできたし修正依頼もしていた。AIの場合それはあまり関係なくてスキルの書き方だったりモデルの進歩に期待することになる。ある種の不毛感がある。

もしかするともう少し諦めると幸せにはなるのかもしれない、という気はする。

ついにAIのロールとしてCTOを用意した

最近の開発だと、1つのAIエージェントにビジネスやIssueの情報を理解させてその1人と会話し、彼(?)が新たなWorktreeを作って仕事を振ってくれる流れを作っていたんだが、基本的にこの1人に求めることはいつも一定しているので、/cto スキルを作ってしまった。

昨夜からかなりの並行作業をこなしてもらってえらい数のPRをマージしたんだが、いかにコンテキストウィンドウが1Mになったとは言え色々忘れ始めてしまったので、そのAIの撤収とともにスキル化を検討した。

前に Shogun というのが話題になっていたけれど、あそこまでカッチリしたものではなく一旦親子関係だけがあるレベル。でも十分な気がしている。やはり5タスク以上が一緒に動くようになると人間が制御するコストが厳しくなるので、この方式が良さそう。

あとはWorktreeのクローズを自動化するかはちょっと迷っている(少し残しておきたい時もある)。

そういえば、クライアントワークでスクラムに携わっているんだが、AI主導の開発とスクラムって相性悪い気がする。1人1タスクなんて効率悪いから、空いたらどんどんタスクとって、どんどんレビューしてマージできるようなある意味カオスに進められる手法の方がマッチしている気がした。空いた時間でdependabotのPR見てマージしたり、エラー通知に対応したりしてた。そしたら「佐藤ばかりやっててバランス悪いから他の人が取るように」と言われてしまい、むしろ手が空いてしまう始末。

多分なんだけど、人間が意識するIssueの単位をこれまでよりも大きくして、AIが小さくタスク分けたPRを順番にレビューするスタイルに落ち着く気がする。もしくは並行してやって良いIssueが大量にあってジャンジャン取っていいとか。並行作業の管理をするのにIssueみたいな概念はあっていいので、そこはまだ崩れなさそう。

新しいトライとしてAIのためのテスト量産をしてみている

うまくいくかはわからないけれど、AIにコード書かせて人間レビューコストを下げようと思うと、レビューAIが確認するまでの間の作業AIが拠り所になるものは必要だと感じている。特にシステム境界についてモックしがちな性質だから境界の契約違反がかなり厳しくなる。

私はブラウザ含めたE2Eテストモリモリはあまりやりたがらないため、いわゆるインテグレーションテストを増やして対応する方針。例えばフロントエンドからサーバーのAPIをコールするところについて、フロントエンドの呼び出し口からサーバーの処理を呼ぶ箇所までの範囲でモックを使わずに呼び切らせるイメージ。

昨年までのAIと違って、コード自体が呼び出し不能だったりするようなことはほとんどなくなったから、今度はこの境界をうまくやる方向がいいと思っている。また、人間のプロジェクトでやるとコスト過多になりがちな「やれるなら書いたらいい」というものは書かせて良いと判断していて、StoryBookやスナップショットテストも導入してみている。

どうしてもスタックしてしまう仕事

AI エージェントを並列でゴリゴリ稼働させられるから、簡単なタスクのマージは素早くなったんだけれど、今回作っていたような課金機能みたいなところはどうしてもまとまった時間をとって自分が動作チェックをすることが必要で、多分10日近く起きっぱなしになってしまった。その間、ユニットテストとかレビューとかはみっちりさせておいたけれど、やはり実際にやろうとすると色々出てくる。

今日やっとどうにかマージできそうな気配。

MCPまだ死んでない。もしくは新規のWebサービスへの入力をスムーズにさせようと思った時に作るものの話。

最近2つくらいの新規サービスで、AIから機能を操作させたい要望があった。

  • REST API: APIの説明をどうにかしてAIに教えないといけないが、いい方法がなかった。スキルをユーザーが書いたとしても呼び出してもらえるかの不確実性が高い。
  • CLI: サービスのために新たにダウンロードさせるのが憚られた。しかも使い方をどうにかしてAIに教え...
  • MCP: そのツールがあるということを明確にわからせることができて、適切に呼んでくれた。

というわけで自分はどちらもMCPで提供している。

もしかしたら、懐かしの WSDL 的なものが今あったりしたらそういう標準があると素晴らしいのかもしれない。今だとOpenAPIスキーマか?そうかも。でも、今度はそのURLを教えさせるスキルが(と、振り出しに戻ってしまう)。MCP で OpenAPIスキーマのURLのリストを提供したらできるんかな?そういうことかも。いつかやりたくなったら試す。