はじめに
先日 AI Ops Squad として全社を対象に進めてきた AI 活用の取り組みを紹介しました。半年をかけてウォンテッドリーでは目標としていた「レベル2:業務フローの複数ステップに AI を組み込む」の到達率100%を達成しました。
AIの有効活用率を100%にするために、ウォンテッドリーがやっていること | Wantedly, Inc.
各自が生成 AI を自律的に使うようになったことで、私たちは新しい2つの課題に直面しました。
ひとつは定量評価ができていないことです。体感としては生産性が上がっているように思えるものの、それを裏づける証拠が少ないという状況が見えてきました。実際に開発生産性を測ろうとしたところ、 Pull Request の数は増えているもののデプロイ数はあまり増えていなかったという事実もありました。
もうひとつはコストの高騰です。一人あたりの利用量が増え、さらに同時に使う人数も増えました。掛け算でコストに反映されるので伸び方は想像以上でした。際限なくコストがかかるという問題には対策が必要ですが、利用が進んだことによる恩恵は最大限活用できるようにしたいと考えています。
全社員がAIを使う組織へ、ウォンテッドリーの全社AI活用の実現まで | Wantedly Engineer Blog
ウォンテッドリーにおけるコスト管理のスタンスは、「コスト削減のために一律で利用制限をかける」ことではありません。トークン使用量の増加は“悪”ではなく、むしろ「全社で活用が進んでいる健全な兆し」と捉えています。
この2つの課題を解決するため、私たち AI Ops Squad では AI 利用状況を可視化し分析を行う仕組み作りと運用を始めています。この記事では、賢く AI に投資するために行っている取り組みについて紹介します。
AI の利用分析の難しさ
取り組みを始めて分かったこととして、AI の利用状況の分析には2つの壁があります。
壁①:アウトカムが測れない
各サービスで様々な指標を出してくれていますが、機械的に取れる指標では本当の効果は測れません。生成したコードの行数やマージした PR 数は取得できますが、それが業務効率化や付加価値にどうつながったかはその数字からは分かりません。
さらに厄介なのが職種による非対称性です。開発部門なら PR 数のような代理指標がまだ存在しますが、セールス・コーポレート・マーケティングといった部門にはそもそも当てはまる指標がありません。全社を横断して同じ物差しで効果を測ることは事実上できませんでした。
壁②:コストと利用データが技術的に取りづらい
一般的にクラウドサービスのコスト最適化を行う場合、課金のベースとなる指標が実際の請求にどう反映されるかを理解して実行可能な対策を考える必要があります。AI サービスはシート数とトークン数に応じて課金される体系が多いですが、各社どう計算するかという点に差異があります。
AI 利用の最適化は他社でも必要とされているため、複数のサービスを取りまとめて可視化するサービスが登場していますが、私たちが利用しているサービスを全てカバーできる製品は現状存在しません。市販サービスとして多いのは OpenTelemetry で AI のトレースを取得するタイプのもので、実際にいくつか試しましたが社内で使っている全サービスをカバーできず、加えて表示されるコストが実際の請求情報と一致しないという問題がありました。単独では要件を満たせず、別の方法との併用が必要でした。
どう可視化と分析の仕組みを運用しているか
ここからはウォンテッドリーで実際に運用している可視化と分析の仕組みについて紹介します。
アウトカムをどう見積もるか
壁①の対処として、私たちはアウトカムの評価を全社統一では行わず各チームに任せるという判断をしました。
アウトカムは業務内容に依存するもので、その仕事を実際にやっている各チームでしか判断できません。測るべき人が別にいるという役割の切り分けをしました。
その上で AI Ops Squad としては「個人が AI をどう使っているか」「その使い方にどれだけコストがかかっているか」を分析し各チームのリーダーに渡すという取り組みを実施しています。これを受け取ったリーダーはそれを自チームの成果と突き合わせて判断します。
データをどう集めるか
複数の AI サービスの利用実績を可視化するために、以下の手段を組み合わせてデータを収集しています。
- API: ユーザー一覧やシート(契約ライセンス)一覧など、サービス側が構造化データとして公開している基本情報はここから取ります。統一された仕様はなく、各社に合わせて実装が必要です。サービスによってはプランにより制限されている場合もあります。
- OpenTelemetry: 利用側でどう使ったかのデータを送ることで、どのモデルを・いつ・どれだけ(リクエスト数、トークン消費量)使ったか、どのスキルやツールを使ったかといった、リクエスト単位の詳細な情報が取得できます。この方法で取得する指標は実際の請求とは結びつかないことが多いため、主に利用分析に仕様しています。
- WebUI: 請求書やコストの詳細、契約シートの利用実態などは API や OpenTelemetry では取得できないことが多いため、直接各サービスの管理画面から取得します。
集めているデータ項目は次のとおりです。
- シート数・ユーザー一覧
- ユーザー、利用モデル、トークン種別のトークン使用量とコスト
- 請求書の一覧と各請求書の詳細
- 各サービス固有の利用指標(プルリクエスト数、生成したコードの行数など)
何を出力しているか
集めたデータは、大きく3つの形にまとめています。
- ユーザーごとのコストランキング: 誰にどれだけコストがかかっているかを一覧にしたもの。組織全体のコスト構造を把握する起点になります。
- ユーザーごとの利用アドバイス: 本人が自分の使い方を見直すための示唆をまとめたもの。
- 管理者に対するアドバイス: 契約内容や座席の見直しなど、組織単位の意思決定に使う提案をまとめたもの。
ここで言う「アドバイス」とは利用状況から見えた仮説をもとにした、ROI を上げるための提案です。コストが高いという事実を伝えるだけでは何も変わりません。なぜ高いのか、どうすれば成果を落とさずに下げられるのか、あるいはもっと使ったほうがいいのかまで踏み込みます。
特にコストが大きいメンバーについては詳細なデータまで集めた上で、具体的にアクションできる内容を伝えられるようにしています。解像度を高くすることで受け取った本人とリーダーが行動に繋げられ、効果的な最適化につながると考えています。
可視化と分析の仕組み自体には AI を活用
この一連の手順はスキルとして AI が利用できるように言語化しています。理由は2つあります。
ひとつは実行頻度です。月次でまとめて振り返るのではなく気づいたタイミングで最適化を回したいので、月に数回は実行することになります。手順が固まっていないとその頻度には耐えられません。
もうひとつは属人化の回避です。手順が言語化されていれば誰が実行しても一定の品質でデータを集められます。「あの人しか集められないレポート」は運用として続きません。
「賢く使う」ための分析観点
データを集めただけでは行動に繋げられないと考え、誰に何を伝えるかから逆算し利用分析の観点を整理しました。実際の運用で利用しているドキュメントから抜粋し紹介します。
個人向けの分析観点
モデルの使い方
高コストモデルと軽量モデルの利用比率、特定モデルへの偏り、用途に対して過剰な性能のモデルを使っていないかを確認します。非推奨やレガシー化したモデルを使い続けていないかも確認します。単純なタスクに高い effort を使うと、コストとレイテンシが不必要に増えるため reasoning effort や thinking(拡張思考)の設定も見ます。
ここでモデルの使い分けをコスト削減の話として伝えないことに注意します。軽量モデルのほうが速く回せるという利点があり、イテレーション回数が増えれば体験としても良くなります。「格下げして節約しろ」ではなく「適材適所にしたほうが速い」という位置づけで伝えています。
トークンの使い方
input と output の比率、cache write と cache read の比率から、使い方のクセが読めます。cache read が多ければ、同じ大きなコンテキストを繰り返し使う定型作業が中心。逆に cache write ばかりで read が少なければ、毎回コンテキストを作り直しており、再利用で効率化できる余地があります。
比率だけでなく1リクエストあたり、1セッションあたりの総トークン量が肥大化していないかという絶対量も確認します。コンテキストが大きすぎると精度が落ち、やり直しが増えて結果的にコスト効率も悪化します。
コストが高いメンバーに対しては OpenTelemetry で取得したテレメトリを使いリクエスト単位で具体的なアドバイスを行います。
サービス・機能の使い分けと、契約とのギャップ
同じ用途に複数のサービスを使っている場合、より安価な選択肢がないかを確認します。アカウントがあるのに利用実績が薄い場合は、本人から「不要なので返却してよいか」と申し出てもらう形にしています。座席の解約そのものは管理者側の操作ですが、申し出は本人のみが起こせるアクションです。
シートに無料枠が設定されているサービスはその枠内なら従量課金が発生しない前提で分析します。従量課金額が上位ティアとの差額より小さい場合はティア引き上げの優先度を下げます。
生産性指標(コミット数・PR数)の扱い
コミット数や PR 数は、コードを書く職種にしか意味を持たない指標です。デザイナー、プロダクトマネージャー、セールスに対してこれらの数値を根拠に「成果に結びついていない」と書かないように注意します。職種が判別できない場合は、アクティブ時間やトークン量のように職種を問わず解釈できる指標だけを使います。
エンジニアの場合でも PR 作成数に対してマージ済み数が少ないときは「作成数と比べてマージ率が低い」という事実だけを示し、原因は断定せず推測として書きます。レビューで止まっているのか、要件が固まる前に着手して手戻りしているのかはデータからは分かりません。逆にコミットや PR が少なくてもアクティブ時間やトークン量が多い場合、調査やレビュー、相談が中心の使い方である可能性があります。これ自体を問題としては扱いません。
指示の出し方と繰り返し作業の効率化
利用傾向を元に本人が今日から実行できるアクションとして提案します。
- 定型化できる依頼はスキル化やテンプレート化を検討する
- 出力形式を明確に指定して不要な前置きを求めない
- 要件と期待するフォーマットを最初のメッセージにまとめて手戻りを減らす
- 大量のタスクを一度に詰め込まず検証可能な単位に分割する
- 堂々巡りになったら早めに見切って新しいセッションでやり直す
管理者向けの分析観点
座席・シート・ティアが実利用に見合っているか
契約座席数と実利用座席数を突き合わせます。利用がゼロなのに座席を保持しているものは剥奪の候補です。
いくつか注意点もあります。
枠が大きいティアは、枠を使い切っていても従量額はゼロ近くになります。従量額だけを見ると使っていないように見えてしまうため、実利用量(リクエスト数、トークン数)、最終アクティブ日、アクティブ日数、セッション数、機能別の利用頻度といった複数の情報を組み合わせて判断します。
ティアの上げ下げについても基準を決めています。下位から上位への引き上げが正当化されるのは、座席単価の差額を従量超過額が恒常的に上回る場合のみです。逆に、上位ティアであっても実利用が薄ければ、下位ティアへの変更や座席自体の削除を提案します。最上位ティアで枠超過が続いているユーザーはティア変更では解決しないので、モデルの使い方など別の観点に切り替えます。
プラン・サービス構成が組織の実態に合っているか
契約プラン自体(座席数・従量枠)が過剰または不足していないかを見ます。このとき契約期間(月次か年次か、ロックインの有無、更新タイミング)も併せて確認します。年間契約なら期中の見直しはかえってコスト増になることがあるためです。
用途が重複する複数サービスを契約していないか、1サービスに寄せられないかというサービス集約の観点、そして高コストモデルへの利用が組織的に偏っていないかというモデル変更の観点も、ここで扱います。
繰り返し作業の組織的な効率化
個人向けの分析を見ていると複数の人が同じような手作業を個別にやっているパターンが見つかります。これはチーム単位でスキル化・テンプレート化する候補として、組織的に提案します。個人の工夫として閉じさせないことがポイントです。
新しい指標の提案
分析していると「この指標があればもっと精度よく判断できる」と気づく瞬間があります。そう気づいた時点で次の収集項目としてフィードバックし、収集の設計そのものを更新しています。分析と収集を分離せず上手くループさせられるようにします。
実際に運用してみて
可視化と分析により実際には使われていないアカウントが見つかりました。利用量が多いメンバーと利用が減ったメンバーに応じてシートを適切に変更することでコストの最適化が進んでいます。
個人向けの分析結果を各チームのリーダーに共有することで、チーム内で AI の使い方について話す機会が生まれているという話も聞いています。利用の質そのものも変化があり、適切なモデル、適切なサービスを選びながら使う人が増えていることが利用状況の推移から見えています。各個人が自分のデータを見て、理解し動いた結果として組織的なスキル化や AI エージェントとの協業が各チームやメンバー主導で生まれるようになりました。
これらの成果は仕組みだけでなく、実際の運用まで意識した運用を続けた結果生まれたものだと考えています。仕組みと泥臭い運用の両輪で取り組むことの重要さを実感しました。
ウォンテッドリーでは今後も AI をビジネスパートナーとして賢く使い、事業価値の最大化につなげていきたいと考えています。ここに書ききれなかった取り組みもあるので、興味のある方は話を聞きに来てもらえると嬉しいです。