サムネイル

1. AIエージェント導入の期待と現実のギャップ
2. 調査概要と主要な発見
- 調査結果
3. 組織とシステム構造によるAIエージェントとの相性の違い
- パターン1. 「新規開発 × 少人数」
  - 現実的な生産性向上の上限と人間の限界
- パターン2. 「歴史があるシステム × 大人数」
  - 「説明責任」が果たせない盲目的なプルリクエストは遅延と成長の阻害要因
4. 「銀の弾丸」ではないAIエージェントの正しい位置づけ
- 一周回って、エンジニアのスキルが重要になる
5. DORA 2025レポートが示す現実
- AIは「増幅器」である
- AIが「組織の鏡」である理由
6. おわりに

こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣（@i35_267）です。現在、PF-AX戦略を進めています。

1. AIエージェント導入の期待と現実のギャップ

皆さんの現場では、AIエージェントによって生産量や生産性は上がっていますか？

CursorやClaude Code、CodexなどのAIエージェントツールが急速に普及し、多くのエンジニアが日常的に利用するようになりました。コード生成、バグ修正、ドキュメント作成など、様々な場面でAIの支援を受けていることでしょう。

しかし、実際のところAIエージェントの導入によって開発チーム全体の生産性は本当に向上していると確信が持てる開発現場はどのぐらいあるでしょうか。 「便利だな」や「ラクになったな」 と感じていても、それがチームの生産性にどのぐらい関与しているのか、はたまた経営層に見えるレベルで期待していたような劇的な生産性向上は実現できているでしょうか？

今回は、DMM.comのプラットフォーム基盤を支えるエンジニア200名を対象に行ったAIエージェントの業務プロセスへの浸透度の調査結果とそこから見えた生産性との関連性についてご紹介します。

2. 調査概要と主要な発見

DMM.comのプラットフォーム開発本部では、PF-AX戦略（AI Transformation）の一環として、「プロセスを"AI"に置き換えるのではなく、"AIネイティブ"なプロセスに作り変える」 を作っていくという方針があります。

その中で、まず取り組んだのは所属する人数から算出される約200人月の業務工数の分析です。あらためて普段行っている業務の内容と目的の可視化を行い、どんな業務がAIに置き換えられるかの筋道を立てていきます。

具体的には、以下の観点で業務プロセスを分析し、下図のような形で整理しています。

業務プロセス

業務プロセスの区分（投資工数）
- 運用工数
  - 問い合せ・顧客対応
- 障害対応・ルーチンワーク
- 組織管理工数
  - 組織管理のルーチンワーク
  - プロジェクトルーチンワーク
- 新規開発工数
  - 要件定義・企画フェーズ
  - 設計フェーズ
  - 実装フェーズ
  - テストフェーズ
  - デプロイ
- 保守開発
  - リファクタリング
  - ライブラリのアップデート等
業務プロセスの意味
- 業務プロセスの内容
- 業務プロセスの目的
- 課題は何か

業務プロセスの区分に対しての課題感の重要度を測るうえで、毎月どのぐらいの工数を投資しているかは重要です。

工数データのローデータとしている勤怠情報・工数管理のデータ（誰がどの業務にどのぐらいの時間割り当てているか）をBigQueryに投入し、Lookerでビジュアライズしています。所属している部門やチーム単位、そしてどのプロダクトに対してどのぐらいの工数をどの業務プロセスの区分に投資しているかを見ています。

業務プロセス

調査結果

上記の業務プロセス表をもとに、各区分のプロセスごとのAIエージェント利用率の調査を開始しました。

調査対象：DMM.comのプラットフォーム基盤のエンジニア約200名
調査期間：25年7月~9月
回答率 : 96%
調査方法：アンケートによる定性調査（業務プロセス別のAIエージェントとの協働の利用状況を「0%/10%/50%/100%/対象の業務を行っていない」の内から回答）

アンケート結果としては以下のようになりました。

アンケート結果

おおよそ、予想通りではありますが開発フェーズを中心とした要件定義から実装、テストやリファクタリングといったエンジニアリングを中心とした作業はすでに多くの組織でほぼ利用されています。所属しているプラットフォーム開発本部内でも、以下のような取り組みは浸透しつつあります。

保守開発（リファクタリング）へのAI活用 developersblog.dmm.com

デザイン領域へのAI活用 developersblog.dmm.com

マネジメント領域へのAI活用 developersblog.dmm.com

一方、開発作業以外の対応におけるAIエージェントの利用率はまだまだ低い状態です。 組織管理のルーチンワークやプロジェクトマネジメント、DevOpsといったマネジメントラインの作業です。

現在進めている内容としては、障害対応のルーチンワークで言えば、ポストモーテムの自動生成や過去のインシデント情報をLLMに蓄積していって対応の初動を上げていく取り組みは絶賛準備中です。実際のインシデント情報を使わなくても、DiRT（Disaster Recovery Training）の障害訓練のパターンを色々とためていっても良いでしょう。

また、プロジェクトマネジメントやピープルマネジメントの分野での利用も現状はまだ低い状態です。一方、Project as Codeといったプロジェクトの状況とチームの状況をコード化することでAIリーダブルな状態にしていきながら、進捗レポートを自動化したり報告MTGをしなくても良い方向性を取ろうとしています。加えて、ピープルマネジメントの分野でも日頃の会話ログをGoogle Meetの自動録画や自動要約をします。それをローデータとして弊社の評価定義やスキルコンピテンシーとつなぎ合わせて目標トラッキングを細かく自動記録していきます。これによって評価時期に来るハロー効果（ある対象の目立つ特徴に引きずられ、全体的な評価が歪められてしまう心理現象）を防いだり、被評価者自身も評価ポイントを頑張って書く時間を削減する取り組みも始まっています。

さて、ここからは利用率を見ていく中で、組織としてどのような発見があったかを述べていきます。

3. 組織とシステム構造によるAIエージェントとの相性の違い

同じAIエージェントの予算を使っていても、チームの特性によって成果に大きな差が生まれています。

パターン1. 「新規開発 × 少人数」

新規開発で少人数のチームでは、AIエージェントの効果が顕著に現れています。特に新規開発だと、作るものが多く、従来だとエンジニア数によるスケーリングが一般的です。

しかし、そこにAIエージェントが入ることによる1人のスキルレベルをうまくトレースしたうえで量のスケールが可能になります。

そのうえで、少人数での迅速な合意形成、最初からAIが理解しやすい構造で設計されたAIリーダブルな設計、そしてチーム内の技術力のばらつきが少ないことこそ成功要因となっています。

現実的な生産性向上の上限と人間の限界

AIエージェントを活用して成果を出しているチームでも、生産量は25年10月現在、1.3〜1.5倍の向上にとどまっています。理想としては3~5倍の向上を目指したいところですが、そうなっていません。

そこには、人間的なボトルネックがあります。常にAIの提案を判断し、修正する作業は以前の自分ひとりで行う作業に比べて業務濃度の向上を伴い予想以上に精神的負荷が大きくAIとの協働のバランスを取ることが難しくなっています。

いわば、いくら並行に処理できると言っても、人間とAIがHuman-in-the-Loopを続ける中では人間の体力・CPUが限界に達します。

AIエージェントとの協働では、以下のような負荷が常にかかり続けます。 - AIの提案を逐一判断・検証する認知的負荷 - 生成されたコードの意図を理解し、修正する作業の集中力 - AIの出力品質に応じた適切な指示を出すための思考力

メンバーに「生産量が2倍になったなら、同じ時間で2倍の作業をしてもらえれば4倍に生産量が上がる」というわけではありません。これがAIとの協働によって人間側が疲れて逆に生産性が下がってしまう「AI疲れ」現象です。

パターン2. 「歴史があるシステム × 大人数」

一方、既存システムを扱う大人数のチームでは、同じAIエージェントの予算を使っていても生産性向上に苦戦しています。歴史が長く、モデル設計が複雑なレガシーコードや、ドメイン設計をAIに伝えにくい構造、チーム内に蓄積された暗黙の知識やルールの多さがあります。

また、大規模で会社の売上を支える重要な基盤システムほど、多くのエンジニアが関わる大規模な開発プロジェクトになります。そのため、チーム内のエンジニアのスキルレベルにどうしてもばらつきが生まれ、以下のような課題が発生しがちです。

レビュー時間の増加：スキルレベルの違いにより、コードレビューに時間がかかる
品質の不安定化：経験の浅いエンジニアのコードが混在し、品質にばらつきが生まれる
意思決定プロセスの重さ：大人数での合意形成に時間がかかり、開発速度が遅くなる

「説明責任」が果たせない盲目的なプルリクエストは遅延と成長の阻害要因

チーム内のスキルレベルのばらつきが大きい場合、AIエージェントの導入がかえって開発プロセスを複雑化させてしまいます。経験の浅いエンジニアがAIの提案をそのまま採用してしまうと、レビュアーは、より詳細な説明を求めざるを得ません。 チームのテックリードがレビューだけに追われているという現状があるチームは少なくないでしょう。 当然、AIが生成したコードの意図や設計思想を理解できないエンジニアが増えると、レビュープロセスが大幅に遅延します。レビュアーは単にコードの動作確認だけでなく、AIの提案の妥当性や既存システムとの整合性まで検証する必要が生じ、結果としてレビュー時間が大幅に増加してしまいます。

もっとも深刻な問題は、AIが生成したコードに対する「説明責任」の問題によるエンジニアの成長がなくなることです。アカウンタビリティーとも言います。エンジニアがAIの提案を採用した際、そのコードの意図や設計思想を十分に理解していない場合、レビュアーからの質問に対して適切に回答できません。「なぜこの実装方法を選んだのか」「この設計判断の根拠は何か」「既存のシステムとの整合性はどうなっているか」といった質問に対して、エンジニアが明確に答えられません。そうなると、深刻な問題としてレビュープロセスの問題にプラスして、エンジニアとしての成長曲線が上がってこないという問題もあります。

端的に言えば、そういったメンバーが増えてくるのであれば、テックリードがAIエージェントと協働し1人で作ったほうが早い場合も出てくるでしょう。

この問題は特に、AIエージェントの活用が進んでいるチームほど顕著に現れます。 AIの提案を盲目的に採用するのではなく、その提案の妥当性を理解し、必要に応じて修正できるスキルが、AIエージェント時代のエンジニアには不可欠となっています。

4. 「銀の弾丸」ではないAIエージェントの正しい位置づけ

一周回って、エンジニアのスキルが重要になる

これまでの調査結果から明らかになったのは、AIエージェントを使いこなすには、むしろエンジニアのスキルがより重要になるということです。数カ月前は「もはや人がCopilotでAIがPilotで開発するのは良いんじゃないか」という風潮もありましたが、実際の運用を通じて、その考え方は修正されつつあります。

人間がAIエージェントを使って開発する場合、自分が想像できるアウトプットに対して早く形にする補助ツールとしてAIエージェントが機能します。あくまでもAIエージェントはエンジニアの能力を拡張するパートナーであり、エンジニアの技術力や判断力が高いほど、AIエージェントの効果も高くなるという関係性があります。

前述した、AIエージェントの提案を盲目的に理解せずに受け入れてしまうことで成長が止まってしまいます。そうではなく、提案を自分の中で腹落ちさせてスキルアップするためのドライバーとして利用するのが良いと思っています。たとえば、AIエージェントのCursorであれば、Agent modeではなくAsk modeやPlan modeを使い、コードを書くところは自分で行うといった方法もありでしょう。

5. DORA 2025レポートが示す現実

開発生産性のレポートとして有名な、DORA - 2025 DORA State of AI-assisted Software Development Reportの最新レポートでも、この現実が数値として示されています。

DORA

AIは「増幅器」である

レポートの冒頭で繰り返し強調されているのは、AIは組織の強みと弱みを増幅する存在だということです。技術的・文化的にも整ったチームでは、AIが生産性と品質を加速させる一方で、基盤が未整備な組織では混乱や不安定さを広げてしまう。つまり、AIの価値はツールそのものではなく、それを取り巻く「システム」―文化、データ、プラットフォーム―に依存しています。

AIが「組織の鏡」である理由

レポートの中では「AIの利用が増えた一方ですべての問題が解決したわけではない」と述べられており、スループット（開発速度）は向上したものの、デリバリーの安定性はむしろ悪化したと述べられています。 DORAは、これを「AIによるスピードアップに、組織システムが追いついていない」状態だと指摘しています。

これらの「増幅器」であるという点と「組織の鏡」であるという部分については、前述した生産性向上に寄与する組織パターンやAIエージェントによって生産性の恩恵を受けたい場合にはエンジニアのスキルが回り回って必要であるという点と繋がっており納得感があります。