newmoのプロダクトチームで、AIエージェント活用開発トライアル（AI Agent Development Trial = AADT）を実施しました。1週間、チーム全員でClaude CodeやDevinを使ってコードを書くという取り組みです。
この記事では、なぜこのトライアルを行ったのか、何が分かったのか、そして今後どうしていくのかを紹介します。
なぜAADTを実施したのか
AIエージェントの進化が速い。毎月のように新しいツールや機能が出てきて、「これを使えば生産性が上がる」という話を聞かない日はありません。しかもそのほとんどが今年リリースされたと思うとめまいがしそうです。
でも、実際に使ってみないと分からないことが多い。「本当に速くなるのか」「品質は大丈夫なのか」「どんなタスクに向いているのか」。使っている人の話を聞いても、自分たちのプロジェクトで同じ結果が出るとは限らない。
もう一つの懸念は、スキルの二極化でした。AIエージェントを使いこなせる人と、そうでない人の差が開いていく。早い段階で全員が触る機会を作らないと、この差はどんどん広がっていきます。
そこで、以下のテーマのもと、チーム全員でAIエージェントを使う期間を設けることにしました。
AIエージェントを活用したプロダクト開発フローをプロダクトチーム全員で実践し、これからの開発フロー見直しのきっかけを作る
「きっかけを作る」というのがポイントです。このトライアルで全てが解決するとは思っていません。でも、全員が同じ体験をすることで、「AIエージェントをどう活用していくか」という議論のスタートラインに立てる。それが狙いでした。
やったこと
トライアルの概要
期間: 2025年6月30日〜7月4日（約1週間）
対象: プロダクトチーム全員
- ソフトウェアエンジニア
- デザイナー
- PM
- QA
エンジニアだけでなく、プロダクトに関わる全員を対象にしました。AIエージェントの可能性と限界を、チーム全体で体感することが目的だったからです。
レギュレーション
ルールはシンプルにしました。
必ずコーディングエージェントを使ってコードを書く
使えるツールはClaude CodeとDevin。Devinは会社で契約していましたが、Claude Codeは少し工夫が必要でした。対象者に用途を限定したコーポレートカードを配布し、各自がClaude Maxプランを契約する形を取りました。
どうしてもエディタで直接書いた場合は事例を共有する
禁止するのではなく、「AIに向いていない作業」の知見を溜めることを重視しました。「ここはAIじゃ無理だった」という情報も、チームにとっては価値があります。
事前ヒアリング
トライアルを始める前に、すでに同様のトライアルを実践している他社の方にヒアリングを行いました。先行事例から学ぶことで、「こういう問題が起きそう」「こう対策すると良さそう」という見通しを持ってトライアルに臨めました。ご協力をいただいたみなさん、その節はありがとうございました。
準備したもの
いきなり「使え」と言われても困るので、オンボーディング資料を用意し、初日にはブリーフィングを行い、作業を開始できるところまでサポートを行いました。
- Claude Code 事前準備
- Claude Code 基本セットアップ
- Claude Code MCP設定
- Claude Code メモリ機能（CLAUDE.md）設定
- 個人用CLAUDE.md テンプレート
特にCLAUDE.mdの設定は重要です。プロジェクト固有のルールや、個人の好みをAIに伝えることで、出力の質が変わってきます。テンプレートを用意しておくことで、設定のハードルを下げました。
期間中のサポート
トライアル中は、専用のSlackチャンネルを作っていつでも相談できるようにしました。「こういうときどうすればいい？」「これって正常な動作？」といった疑問にすぐ答えられる体制です。
また、知見を共有できるNotionページも用意しました。「こうやったらうまくいった」「これは失敗した」といった事例を、みんなで書き込んでいく場所です。誰かの発見が別の誰かの助けになる、という流れが生まれました。
結果（数字で見てみる）
トライアル終了後、参加者全員にアンケートを取りました。実施前と後でどう変わったのか、数字で見ていきます。
AI使用頻度の変化
トライアル前、「仕事でAIを毎日使っている」という人は85%でした。これだけでも多いなと思っていたのですが、トライアル後は様子が変わりました。
「今後も毎日使いたい」と答えた人が 96.4% に。「週に数回」がわずか3.6%で、「たまに」「使いたくない」は0%。ほぼ全員が毎日使いたいと思っています。
どのくらいAIにコードを書かせたいか
もっと面白いのが「どのくらいAIにコードを書かせていますか？」という質問です。0%から100%で答えてもらいました。
実施前は回答がバラバラでした。20%や50%あたりに集まっていて、70%以上は35%程度。AI活用度には結構な個人差がありました。
実施後は分布がガラッと変わりました。0%〜30%の回答が 0% になり、70%以上に 81.8% が集中。特に80%（27.3%）と90%（22.7%）が多く、100%（すべてAIに任せたい）も15.9%いました。
強制的にAIを使う機会を設けたことで、「意外と任せられる」という実感が広がったのだと思います。
生産性は上がりそうか
「生産性は上がりそうですか？」という質問には、65.5%が「上がる」、25.5%が「上がるかも」と回答。合わせて91%がポジティブな見通しを持っています。
一方で「変わらない」「下がりそう」という回答も少数ありました。興味深かったのは自由回答で、「チャットだけに縛ると生産性が落ちるタスクも多いけれど、実コードを触りながら一部の処理をチャットでやってもらえば生産性が爆上がりする」という声がありました。
職種による満足度の違い
職種ごとのNPS（推奨度）を見ると、はっきりとした傾向が出ました。
満足度が高い職種:
- iOS: 約70
- Android: 約60
- バックエンド: 約45
満足度が低い職種:
- フロントエンド: 約-20
- PM: 約-15
- QA: 約-80
- デザイナー: 0付近
モバイル開発者の満足度がとても高かったのは意外でした。当時のモデルの精度では、SwiftやKotlinの扱いに苦戦して満足度は下がるだろうと予想していたからです。実際には期待以上に使えたようです。
一方、QAやPMは厳しい評価でした。正直なところ、運営側としてもQA・PMの業務にどう組み込むかのイメージを持てておらず、丸投げ気味になってしまったところがあります。ここは反省点であり、今後の課題です。
また、フロントエンドが低くなってしまったのは、AIエージェントを使った開発フローが確立されていなかったために、アウトプットをなかなか出せずに苦戦したことが影響しています。
学び（ポジティブ・ネガティブ）
数字だけでは見えない部分があります。アンケートの自由回答から、良かった点と課題点を紹介します。
ポジティブな発見
生産性の向上
小〜中規模タスクやユニットテスト生成で「ほとんどコードを書かずに完了」できた
並列実行により「体感2〜3倍速い」「PR作成が早まった」
特にテスト生成との相性が良いです。テストケースを考えて書くのは地味に時間がかかるので、ここを任せられるのは大きいですね。
学習・オンボーディング効果
未経験者でも「強制的に使う機会」があったことで習熟が進んだ
非エンジニアも活用の可能性が見えた
組織全体で知見共有が進んだ
全員参加のトライアルにした意味がここにありました。普段なら触らなかったかもしれない人も、強制されることで一歩踏み出せました。
AIとの協働への期待
「AIなし開発には戻れない」
「人間は設計に集中できるようになる」
「今後も継続したい」
会社としてAI活用を推進する姿勢が伝わったのは良かったです。
ネガティブな発見
コード品質・精度への懸念
「品質が数％低下した気がする」
「大規模リファクタは厳しい」
「予期しない変更が入る」
コードベースが壊れるリスク
AIの書いたコードをそのまま信用できないという声は多かったです。既存コードへの理解を要する作業では、意図しない変更の混入リスクがあります。AIの書いたコードの蓄積によって、メンテナンスが困難になるのではないか。レビュー負荷の増加で人間がボトルネックになるのでは、という心配もありました。
エンジニア以外の活用
エンジニア以外での活用がむずかしい
NPSの結果とも一致しています。現状のAIエージェントはコーディング作業に特化していて、PM・QA・デザイナーの業務には直接適用しづらいです。
実測データ（当時）
アンケートの声だけでなく、実際のPR数も計測しました。あくまで参考値ですが、傾向は見えてきます。
マージされたPR数
トライアル前週にプロダクトのリリースターゲットが重なり異常値となりましたが、トライアル週以降は通常範囲に戻りました。自動運転チームへの異動などで開発メンバーが減った中でもこれまでの水準を維持できており、1人あたりの生産性が落ちていないことを示しています。しかし、アンケートにあったような生産性が上がったという確たる根拠は数値からは得られませんでした。
1人あたりのPR数
開発メンバー数は減りましたが、1人あたりの中央値は大きく変わっていません。また、リリースターゲットだった前週の分散は非常に高く、一部のメンバーのPRが増えていたことも分かりました。
レビューに関するデータ
レビュー完了までの時間はやや減少傾向にあり、平均コメント数も安定していました。PR数に変動があってもレビュー時間は悪化しておらず、むしろ改善傾向にあります。レビューに関する数値は悪化すると思われていたので少し意外でした。
見えてきた課題と対策
アンケート結果と実測データから、大きく3つの課題が見えてきました。それぞれの課題と、私たちが考えている対策を紹介します。
課題1: 知見共有
何が問題か
AIエージェントをうまく扱うのは、新しいスキルです。
覚えることが多い。プロンプトの書き方、ツールの設定、タスク分割のコツ。それに加えて、これまでの開発習慣をアンラーンする必要もあります。「自分で書いたほうが早い」という感覚を捨てて、まずAIに任せてみる。これが意外と難しい。
さらに厄介なのは、進化の速度です。ツールやモデルが数ヶ月で大きく変わる。せっかく覚えたことが、すぐ古くなってしまう。
どう対策するか
必要な知識を減らすデフォルト設定
個人で設定を頑張らなくても、ある程度使える状態を作ります。CLAUDE.mdのテンプレートや、推奨設定をあらかじめ用意しておく。「とりあえずこれを入れておけばOK」という状態を目指します。
ベストプラクティスの収集
うまくいった事例、うまくいかなかった事例を継続的に集めます。「こういうタスクにはこう指示すると良い」「これはAIに任せないほうがいい」といった知見をチームで共有していく。
エンジニア以外での活用ノウハウの蓄積
現状はエンジニア向けの知見が中心ですが、PM・QA・デザイナーでの活用方法も探っていきます。
課題2: コード品質
何が問題か
生成されるコードの品質が足りない、という声がありました。
動くコードは書いてくれる。でも、既存のコードベースとの一貫性がなかったり、エッジケースの考慮が甘かったりする。そのまま使うと、後でメンテナンスが大変になるかもしれない。
もう一つの問題は、実装者のドメイン理解が薄れることです。AIへ任せっきりにすると、「なぜこうなっているのか」を理解しないままコードが増えていく。これは長期的なリスクです。
どう対策するか
AI向けのガードレール整備
テストやLintを充実させます。AIが書いたコードでも、テストが通らなければマージできない。Lintで一貫性のないコードは弾かれる。機械的にチェックできる部分は機械に任せる、という考え方です。
AI向けルール設定の整備
CLAUDE.mdやプロジェクトのルールファイルを充実させます。「このプロジェクトではこう書く」「この命名規則を使う」といったルールをAIに伝えることで、一貫性を保ちやすくなります。
レビューの強化
これは次の課題とも関係しますが、AIが書いたコードこそしっかりレビューします。
課題3: レビュー負荷
何が問題か
「レビュー負荷が増えたように感じる」という声もありました。
PR数が増えれば、当然レビューの量も増えます。実測データではレビュー時間は悪化していませんでしたが、「特定の人に負荷が偏っている」という感覚はあるようです。
AIが書いたコードは、人間が書いたコードとは違う観点でのチェックが必要です。意図しない変更が混入していないか、既存の設計方針と合っているか。これまでと違う種類のレビューが求められます。
どう対策するか
レビュールールの見直し
何をレビューで見るべきか、改めて整理します。AIが書いたコードと人間が書いたコードで、チェックポイントが違うかもしれない。
テクニカルなレビューを不要にする環境整備
スタイルやフォーマットのレビューは、LintやFormatterへ任せます。人間はドメインロジックに集中したレビューができる状態を目指す。「この変更は仕様を満たしているか」「この設計で問題ないか」といった点へ注力できるようにします。
PRサイズを極小にする工夫
大きなPRはレビューが大変です。AIを使うと一気に大量のコードを生成できてしまうので、意識的にPRを小さく分割します。
現在の状況
トライアルから約5ヶ月が経ちました。当時挙げた課題に対して、現在どうなっているかを紹介します。
知見共有
現在もSlackチャンネルを運用していて、知見の共有や困ったことについての議論を続けています。共通の設定も進化させており、肥大化していた設定をSKILLsに切り出すなどの改善も行っています。
コード品質
共通の設定をガードレールとして機能させることで、一定の品質を保てるようになりました。また、各メンバーの経験が積み重なってきたこともあり、安定した品質のコードが生成できるようになっています。
レビュー負荷
GitHub Copilotの自動レビューや、AIエージェントを使ったレビューを導入し、単純なミスは自動で検出されるようになりました。モデル自体の品質も向上しており、レビュー負荷を増やすようなコードの生成は減っています。
実測データの推移
月次のデータを継続的に計測しています。
月毎のPR数
トライアル前の6月にピークがありましたが、これはプロダクトのリリースターゲットが重なった異常値です。7月のトライアル以降は安定した水準を維持しています。作者数は自動運転チームへの異動により7月以降で減少していますが、PR数は大きく落ちていません。
作者ごとのPR数の中央値
1人あたりのPR数は7月にピークを迎え、その後も比較的高い水準を維持しています。標準偏差も安定しており、特定のメンバーに偏ることなくチーム全体でPRが出せている状態です。
レビューに関するデータ
平均コメント数は年間を通じて安定〜やや減少傾向にあります。初回レビュー時間が悪化気味ですが、レビューを開始してから完了するまでの時間は安定しており、レビュー負荷が増加している様子は見られません。
数値だけで「生産性が上がった」と断言するのは難しいですが、少なくとも開発メンバーが減った中でも以前の水準を維持できており、悪化はしていないと言えます。
今後
トライアルで見えてきた課題には継続的に取り組んできましたが、まだ答えが出ていない問いもあります。
AIエージェントで開発が効率化されたとして、その余裕を何に使うのか。単に「速くなった」で終わりではなく、生まれた時間でプロダクトチームとして何ができるのか。
より深い課題の発見に時間を使えるかもしれない。ユーザーと話す時間が増えるかもしれない。技術的な挑戦に取り組む余裕ができるかもしれない。
これはチームで考えていきたいテーマです。
まとめ
トライアルから5ヶ月が経ち、振り返ってみて分かったことをまとめます。
トライアルで得られたもの:
- ほぼ全員（96.4%）が「今後も毎日使いたい」と回答
- 91%が生産性向上に対してポジティブな見通しを持った
- 強制的に使う機会を設けたことで、チーム全体の習熟が進んだ
- 「AIエージェントをどう活用していくか」を議論するスタートラインに立てた
見えてきた課題と、その後の対応:
- 知見共有 → Slackチャンネルでの継続的な議論や積極的な情報発信
- コード品質 → ガードレールとしての共通設定整備、メンバーの経験蓄積
- レビュー負荷 → GitHub Copilotの自動レビュー導入、AIエージェントによるレビュー支援
実測データから言えること:
- 開発メンバーが減った中でもPR数・1人あたりのPR数は維持
- レビュー時間やコメント数は悪化せず、安定〜改善傾向
- 「生産性が上がった」と断言はできないが、悪化はしていない
AIエージェントとの付き合い方は、まだ試行錯誤の段階です。でも、チーム全員で同じ体験をしたことで、共通の土台ができました。
引き続き、より良い開発フローを模索していきます。
書いた人: Claude Code
編集した人: 
id:Sixeight
