freeeの開発情報ポータルサイト

数字で振り返る freee の AI 駆動開発 - 後編

こんにちは!
この記事は freee Developers Advent Calendar 2025 の 25日目の記事🎅 です。

adventar.org

freee AI駆動開発 (AI-Driven Development) チームのJaeSoon (ジェスン)です。

AI活用がプロダクト開発を超えて全社推進へと拡大する中、私の担当範囲も広がりました。基盤開発や技術アドバイジングはもちろん、BizチームやSuccessチームとも協業し、プロセス整備や検証目的の確立といった組織レベルのEnabling活動も行っています。

最近個人的にはF1のレゴブロックにハマっています 🏎️

1. 概要

1.1. はじめに

9月の前編では、様々なAI AgentとToolの導入を紹介しました。あれから3ヶ月、2025年を締めくくる今、AI駆動開発の成長を数値で振り返ります。

1.2. 2025年のタイムライン

本格的なスタート

今年の3〜4月、AI駆動開発が本格始動しました。Clineを中心としたAI Coding Agentの全社導入とともに、社内LLM基盤とProxy Serverを構築しました。

developers.freee.co.jp

Claude Code全社導入とAI開発マニア制度

8〜9月にClaude Codeを全社導入し、同時に「AI開発マニア」制度を開始しました。一週間で一定のPR数とトークン使用量を達成したエンジニアを認定し、Claude Max利用権限を付与する制度です。

developers.freee.co.jp

Kent Beckが強調したGoodhartの法則「数値が目標になると、それは良い数値ではなくなる」に従い、どの数値を観察するかは決めましたが、どう上げるかは強制しませんでした。目標はシンプルに「まずは、たくさんの人にワイワイ使ってもらいたい!」でした。そして、この目標は大きく達成されました。

2. 詳細指標

2.1. 爆発的な成長

全体利用量の急増

4月から12月までの変化:

  • トークン消費量: 4月比約7-8倍増加
  • 1日あたりのリクエスト数: 最高16万件以上(初期比約10倍)

特に11月末から12月初めに最も急激な増加を見せました。自動コードレビュー導入など、複数要因が複合的に作用した結果です。

全期間のトークン消費量、リクエスト数
全期間のトークン消費量、リクエスト数

ユニーク利用者数の安定化

初期数百名レベルだったユニーク利用者数は、現在月間アクティブユーザー600-700名で安定化しました。開発組織のかなりの数が日常的にAIを使用しています。

最近はClaude Code利用エンジニアが増加し、LLM基盤利用者は減少傾向にあります。

全期間のユニーク利用者数
全期間のユニーク利用者数

2.2. エージェント戦争: Claude Codeの圧倒的優位

ツール別シェアの劇的な変化

現在の分布:

  1. claude_code: 約80% - 圧倒的1位
  2. roo_code: 約10%
  3. cline: 約2%
  4. goose: 約2%
  5. その他: 約6%

5〜8月はclineとroo_codeが主導権を争っていましたが、8〜9月のClaude Code全社導入後、12月にClaude Codeが圧倒的シェアを占めるようになりました。

エージェント別リクエスト割合
エージェント別リクエスト割合

Claude Codeが変えたもの

優れたコスト効率

Claude Codeはコスト効率が優秀で、LLM基盤(Bedrock)の従量課金と比べて同じコストでより多くの作業を処理できました。

Claude Code 利用量の推移
Claude Code 利用量の推移
Claude Codeの利用拡大開始時点から Bedrock 料金予測値が減少傾向を見せる
Claude Codeの利用拡大開始時点から Bedrock 料金予測値が減少傾向を見せる

利用拡大の背景

利用量が急増した要因:

  • 世界的な人気: グローバルな注目による自然な関心増加
  • 社内支援: AI開発マニア制度による利用権限付与
  • 優れたUX: 安定したパフォーマンスと統合IDE体験

運用方式の進化

導入初期は個人契約方式の限界がありました。各エンジニアがMax $200プランを個別契約し経費精算する方式は、個人カード決済の煩わしさ、毎月の精算プロセス、個別契約管理、全社統合管理の難しさがありました。

Enterprise Planへの移行により、従量課金から定額課金へ変わり、次の利点が生まれました:

  • 予算管理の容易性: 毎月予測可能なコストで予算策定が簡単に
  • コスト効率: 全社規模で従量課金より格段に優れた効率
  • 統合管理: 全社の契約状況を一目で把握可能

ただし、Enterprise PlanのRate Limitが個人Maxプランと異なるため、使用パターンによる調整が必要です。これは今後の運用課題です。

2.3. エンジニアはAIをどう使っているのか

AI介入カテゴリ分析

カテゴリ別分布(11月から測定開始):

  • Coding: 約42%
  • Debug: 約21%
  • Test: 約13%
  • Review: 約11%
  • Architect: 約4%

測定開始以降、継続的な増加傾向を示し、12月初めのピーク時は1日あたり120k+の介入を記録しました。

注目点:

  • CodingとDebugが主要用途だが、ReviewとArchitectも徐々に増加
  • 開発フェーズによる変化: 設計段階ではArchitect、実装段階ではCoding、安定化段階ではReviewとDebugと、プロジェクト状況によりAI活用パターンが変化
  • チーム別分析で各チームの開発状況とAI活用方式を把握

AI介入カテゴリ別割合と時系列推移
AI介入カテゴリ別割合と時系列推移

Slash Commandで見る実際のワークフロー

エンジニアが頻繁に使用するSlash Commandから、AIが日常ワークフローに統合された様子が分かります。Git関連コマンドの高使用率は、AIがコーディング補助を超えて開発ワークフロー全体の一部になったことを示しています。

Slash Command の利用率
Slash Command の利用率

定型作業の効率化

Slash Commandの真価は反復的で定型的な作業を劇的に速くすることです。複数チームでの活用例:

API開発の自動化

  • スキーマ定義から自動的にAPI実装体を生成
  • パターン化されたコードを瞬時に作成
  • 一貫したコードスタイル維持

コミットワークフロー

  • 変更内容を分析し適切なコミットメッセージを自動生成
  • 規約に合ったメッセージフォーマット維持
  • PR description自動作成

設計方式のパラダイム変化

最も興味深いのは設計ドキュメント作成方式の変化です。従来はDesign Docsに実装方法を詳細記述していましたが、今は:

「この機能は /api-crud コマンドで実装」 「テストは /test-suite コマンドを使用」

のように使用するSlash Commandを設計に直接明記する方式に変化しています。

このアプローチにより、具体的な実装詳細でなく意図とパターンに集中でき、実装はAIが一貫処理し、設計ドキュメントがより簡潔でメンテナンスしやすくなります。AI時代の開発方法論の進化を示す好例です。

2.4. 自動コードレビューの進化: CodeRabbit全社導入

コードレビューは開発プロセスで品質保証の核心段階です。そして、このレビューの負荷が、Coding Agentを使った開発によってPR数とともに増加しています。AIを活用した自動コードレビューツールでこのプロセスを改善できるか探索しました。

初期の試み: GitHub Actionsでの自動レビュー

GooseとClaude CodeのCLI特性を活用したGitHub Actionsでの自動レビューを試みました。すべてのPRに自動レビューするアイデアは魅力的でしたが、課題に直面:

  • コスト急増: 導入直後のトークン消費大幅増加
  • ノイズ問題: 小さな変更にも過度なレビュー発生
  • 運用複雑度: 自前構築システムのメンテナンス負担
  • インタラクション不可: AIツールとの追加コミュニケーション不可能
  • コンテキスト維持失敗: レビュー内容やプロジェクト知識が蓄積されない

CodeRabbit導入: 実用的な解決策

いつも Poem を書いてくれる 🐰
いつも Poem を書いてくれる 🐰

専門コードレビューツールCodeRabbitを評価し、複数チームで実際使用した結果:

コスト効率性

  • 自前構築より格段に優れたコスト効果
  • トークン使用最適化で不必要なコスト発生が少ない
  • 全社導入でも予算範囲内で管理可能

機能的満足度

  • コンテキスト理解: PRの文脈を把握し適切なコメント提供
  • 選別的レビュー: 意味ある変更に集中しノイズ最小化
  • 有用な提案: バグパターン、セキュリティ、コーディング規約を効果的に指摘
  • 簡単な設定: GitHub統合が簡便でチーム別カスタマイズ可能

レビュー時に相互作用が可能である
レビュー時に相互作用が可能である

全社導入の決定

複数チームのパイロットテストとフィードバックを経て、CodeRabbitを全社導入しました。現在約500名のエンジニアが活用し、次の効果を得ています:

  • コードレビュー時間短縮
  • 見落としやすいイシューを事前発見
  • レビュアー負担軽減
  • 新入社員のコード品質学習ツールとして活用

学んだこと: Build vs Buy

すべてを直接作る必要はないという重要な教訓:

  • 専門ツールの価値: 最適化された専門ツールは自前構築より良い結果
  • 運用コスト考慮: 開発コストだけでなく継続的メンテナンスコストも重要
  • 迅速な検証: 複数オプションを実際に試してデータで比較することが重要

CodeRabbit導入は「直接作る」と「検証されたツール活用」のバランスを見つける良い事例となりました。

2.5. MCP: ツールとデータの接続

MCP (Model Context Protocol)によるツール統合も徐々に増加しています。

MCP Server の利用状況
MCP Server の利用状況

Jira連携が圧倒的に多く使用されているのは、エンジニアがAIによるイシュー管理とタスク追跡の効率化を望んでいることを示します。新しいMCPサーバー追加と使用方法の浸透により、自然に増加しました。

興味深いのはツール別活用方式の進化です。例えばGitHubは、MCPサーバーよりghコマンド(GitHub CLI)直接活用が広まり、MCP経由のGitHub使用量が減少しています。エンジニアが状況に合った最も効率的なツール使用法を見つける過程を示しています。

2.6. 使用パターン分析

分散されたユーザー分布

特定少数のパワーユーザーが全体を独占せず、多くのユーザーが満遍なく活用しています。少数のパワーユーザーが一部を占めますが、大部分の使用量は多くのユーザーに均等分散されています。

AI駆動開発が一部のアーリーアダプターの専有物でなく、組織全体に拡散したことを示します。

自然な拡散パターン

新機能やツール追加の度に、アーリーアダプターが素早く試し、その経験がSlackや社内ブログで共有され自然に拡散するパターンです。

AI開発マニア達成状況

AI開発マニア制度は予想以上の成功を収めました:

  • 初期目標: 約200名
  • 結果: 目標の2倍以上達成、約400名
  • 9月から12月まで着実に維持

単にClaude Codeを使いたいからでなく、AI駆動開発そのものがfreeeの開発文化として定着したことを示します。

3. 振り返り・今後の展望

3.1. 組織の反応と課題

全体的に肯定的な反応

組織全体としてAI駆動開発に肯定的な反応を示しています。生産性向上を実感するチームが増え、新ツールを積極的に試す文化が定着し、Slackでのノウハウ共有も活発です。

残る課題と取り組み

並列作業への適応

一部エンジニアはAIと複数作業を並列進行する方式に不慣れです。順次的開発からAI活用並列開発への転換は、思考方式の変化を要求します。

新卒エンジニアの懸念

「AIに過度依存すると基礎が弱くなるのでは?」「AI生成コードを正しく理解できなかったら?」といった懸念があります。最も重要なのは、AI使用の有無で人を評価しないという点です。AIは選択肢の一つであり、手段です。

私たちの取り組み:

  • 基本原理の理解を強調しつつAIを活用
  • 小さな実験から始められる環境造成
  • 個人でなく組織レベルの課題として接近

プロセス最適化へ

使用量増加により、検証段階を超えました。AI駆動開発がプロダクト開発を超えて全社拡大する中、各チームの業務特性を理解した支援、様々な業務プロセスの再設計可能性を探索しています。

これからの方向性:

  • ツール別最適活用方針: 作業特性に応じた最適ツール選択ガイドライン確立
  • freeeに合わせたカスタマイズ: 社内規約、構造、ワークフローを反映
  • 業務プロセスとの統合: AIツール使用を前提とした新しい開発プロセス設計

AIをfreee開発文化の一部として完全統合するプロセスです。

3.2. 一年を振り返って

2025年の数字:

  • トークン使用量 約8倍増加
  • 1日あたりリクエスト 約10倍増加
  • アクティブユーザー 600-700名で安定化
  • AI開発マニア 目標を大幅超過達成

AI駆動開発はもはや実験でなく、freee開発文化の一部になりました。

重要なのは数字の背後にあるもの:より速く問題を解決するエンジニア、より良いコードを書こうとする努力、より創造的なソリューションを見つける試み、お互いの経験を共有するコミュニティです。

Goodhartの法則の助言通り、数値自体を目標にせず、何を測定するかに集中し、どう改善するかは各自に任せ、自発的な参加を奨励しました。その結果、強制でなく自然な成長を生み出せました。

3.3. 2026年に向けて

これからの課題:

  • 品質向上: たくさん使うことを超えて、正しく使うこと
  • 教育とEnabling: 全エンジニアがAIツールをより効果的に活用できる環境構築
  • 柔軟なセキュリティ体制: プロジェクトやデータ特性に応じた適切なポリシー適用

2025年が「AIツールを導入し使用する」年なら、2026年は「AIで実際に何を達成するか」に集中する年になります。

本当に追求するのは、ツール利用率でなく開発プロセスの実質的改善、トークン使用量でなくプロダクトロードマップへの影響、機能追加でなくチームが達成しようとする状態です。

AI駆動開発の旅は今始まったばかりです。引き続き、新しいことを試し、失敗から学び、成功を共有し、共に成長していきます。

4. おわりに

9月の前編で「どのように導入したか」を、今回の後編では「実際にどう使われているか」を数値と共にお見せしました。 約一年の旅を振り返ると、最も印象的だったのは数字でなく、自発的に参加し、実験し、共有する文化が作られたことです。

AIは目的でなく手段です。私たちが本当に望むのは、より多くの選択肢、小さな実験の蓄積、一緒に決めて進むプロセスです。

変化は続きますが、「ただ追いかける」より「一緒に方向を決めて進む」ことを大切にしています。わからないことや難しいことがあれば、一緒に考えて乗り越えていきましょう。小さな質問でも気軽に共有してください。皆さんのフィードバックが次の変化を作ります。

これからもfreeeのAI駆動開発の旅を続けて共有していきます。