はじめに：AI導入は順調。しかし、成長は鈍化。
「AIを導入すれば、開発生産性は劇的に向上する」
その期待通り、私たちのチームにAIコーディングツール「Cursor」を導入してからの滑り出しは順調でした。導入前の4月を基準に、生産性は5月に1.2倍、6月には1.4倍へと着実に向上。
しかし、7月の実績は 1.45倍 。成長は鈍化し、「1.5倍の壁」とでも言うべき停滞期に直面しました。
なぜ成長は止まってしまったのか？ AIを使いこなせていないのか？何が私たちの生産性を阻んでいるのか？
この記事では、エンジニア全員へのアンケート結果から見えてきた生産性停滞の根本原因についての私たちの仮説と、それを乗り越えるために現在検討している3つのアプローチを共有します。同じようにAI導入後の「成長の鈍化」に悩むすべての開発チームにとって、一つの思考のヒントになれば幸いです。
前編：データが示す「生産性1.5倍の壁」の正体
成長鈍化の原因を探るため、私たちはエンジニア全員にアンケートを実施しました。そのデータを分析する中で、直感に反するいくつかの事実が明らかになりました。
1. AIの利用時間が長いメンバーほど、生産性が伸び悩んでいた
まず、客観的な生産性の伸び率でメンバーを「高成長グループ」と「低成長グループ」に分け、AIツールの平均利用時間を比較しました。
グループ 平均利用時間(時間/日) 高成長グループ 1.75 低成長グループ 3.00
生産性が停滞したグループの方が、AIの利用時間は約1.7倍も長かったのです。
これは、以前から感じていた「AIへのリクエスト数と生産性は必ずしも比例しない」という仮説を裏付ける結果となりました。
2. 生産性が高いメンバーは、AI活用への「実感値」（AI活用度の自己評価）も高かった
次に、彼らの主観的な自己評価（AI活用がうまくいっているか）をスコア化して比較しました。
グループ 平均自己評価スコア(満点10) 高成長グループ 7.00 低成長グループ 5.20
こちらは予想通り、客観的な生産性の高さと、主観的な「手応え」は強く相関していました。生産性の鍵は、利用時間ではなく、AIを 「うまく使えている」という実感、つまり活用の「質」 にあるようです。
3. 分水嶺は「コンテキストの壁」にあり
では、活用の「質」の違いはどこから生まれるのでしょうか？両グループが直面する課題についてのフリーコメントを分析すると、決定的な差が見えてきました。
「（既存の）仕様解析からコード生成がうまくいかない」
「既存機能に対する実装に関してはAIをいまいち信用しきれていない。0→1の場合はかなり有効に使えるので個人的に活用はしていきたい」
両グループ共通して、「AIがプロジェクトの文脈を理解できない」という声が上がっていました。低成長グループは、AIとの非効率な対話に多くの時間を費やした結果、生産性が上がらないという悪循環に陥っていたのです。
私たちは、このAIが文脈を理解できない問題を「コンテキストの壁」と名付けました。
4. 高成長グループは「AIとの付き合い方」を知っていた
一方で、高い生産性を維持しているメンバーは、どのようにAIと向き合っているのでしょうか。彼らの工夫には、AIとの絶妙な距離感が表れていました。
高成長グループの工夫:
「AIを使って生産性が上がるか予測し、生産性向上が期待できない場合はAI利用にこだわらない」
「丁寧に聞くことで、見当はずれの回答が生成されるのを防ぐ」
彼らはAIを盲信するのではなく、「AIの得意・不得意を見極め、人間が主導権を握る」という共通のスタンスを持っていました。
5. 仮説：生産性を阻む壁の正体は「技術的負債」だった
ここまでの分析で、「コンテキストの壁」が生産性を阻害していること、そしてその壁を乗り越えるには「見極め力」が必要なことが分かりました。
では、なぜ「コンテキストの壁」は生まれるのでしょうか？
AIツールtabnineのの公式ブログにある一節「Struggles with legacy/high-debt codebases (レガシー・高負債コードベースとの闘い)」がちょうど表現してくれていました。
There’s evidence that AI agents perform poorly in codebases that are already messy, which can worsen the situation. An engineering blog “Gauge” observed that “in ‘high-debt’ environments with subtle control flow, long-range dependencies, and unexpected patterns, [AI tools] struggle to generate a useful response.” They give dramatic speedups only for clean, well-structured code, whereas “companies with gnarly, legacy codebases will struggle to adopt them.”
(（AIエージェントは、既に乱雑なコードベースではパフォーマンスが低下し、状況をさらに悪化させる可能性があるという証拠がある。微妙な制御フロー、広範囲にわたる依存関係、予期せぬパターンを伴う「負債の多い」環境では、有用な応答を生成するのに苦労する。AIツールは、クリーンで構造化されたコードに対してのみ劇的な高速化をもたらすが、「複雑なレガシーコードベースを持つ企業は、AIツールの導入に苦労するだろう。）)
引用元：
How to avoid vibe coding your way into a tsunami of tech debt - tabnine Blog
AIが文脈を理解できない「コンテキストの壁」の根本原因は、私たちのコードベースに蓄積された「技術的負債」だったのです。
この関係性を図にすると、以下のようになります。
**凡例**
- 🟦 右肩下がりの線: 開発生産性
- 🟩 右肩上がりの線: 要求されるプロンプト技術
グラフの解説：
右肩下がりの曲線：技術的負債が高まるにつれて「開発生産性」が低下
右肩上がりの曲線：低下する生産性を補うため、「要求されるプロンプト技術」がより高度に
技術的負債が少ない「効率ゾーン」（左）では、高度なプロンプト技術がなくてもAIの力で高い生産性を発揮できます。しかし、負債が増えるにつれてAIのパフォーマンスは低下し（青線）、それを補うためにより高度なプロンプト技術（緑線）が要求されるようになり、最終的に「非効率ゾーン」（右）に陥ってしまいます。
後編：解決策 - 壁を乗り越えるために、私たちが今考えていること
原因が「技術的負債」という根深い問題にある以上、付け焼き刃の対策では不十分です。
「1.5倍の壁」を乗り越えるため、私たちは現在、以下の3つの方向性でチーム戦略を検討しています。
戦略1：AIが迷わないコードベースを育てる
まず取り組むべきは、AIがその能力を最大限に発揮できるような「土壌」を整えること、すなわち技術的負債の返済です。AIとの協業を前提とした、コーディングのベストプラクティスを整理しました。
✅AIが文脈を理解できるコードにする
ベストプラクティス1：意図を「見える化」、説明可能なコードにする
| 技術的負債 | 解決策 |
|---|---|
| 暗黙知や背景情報がコードに現れていない | - ドキュメントコメントで関数の目的と理由を記述 - 業務用語や特別な処理にコメントを追加 |
| 理由不明の処理がある | - 暫定対応やパフォーマンス上の工夫には「なぜ必要か」をコメントで明示 |
💡 AIは“コードの意図”を説明されないと誤解しやすい。
ベストプラクティス2：コードは「構造」で語れ
| 技術的負債 | 解決策 |
|---|---|
| 巨大で責務の不明瞭なコード | - SOLID原則に従って設計 - 単一責任でクラス・関数を小さく保つ |
| 命名や設計の一貫性がない | - 命名規則を定義して統一 - 同様の処理はパターンを共通化 |
💡 AIは構造とパターンに強い。構造化されたコードは学習効果を最大化する。
✅AIが安全に作業できる土台を整える
ベストプラクティス3：テストコードはAIの“仕様書”
| 技術的負債 | 解決策 |
|---|---|
| テストコードがない／不十分 | - 単体テストを最優先 - 正常系・異常系をカバー |
| テストコードが壊れている／CIに統合されていない | - 自動化してCIで常に実行 - 失敗を検知・通知する仕組みを構築→オールグリーンをキープ |
💡 AIはテストを仕様として学ぶ。明確なテストが安全な提案の鍵。
ベストプラクティス4：データ・設定は明示し、管理する
| 技術的負債 | 解決策 |
|---|---|
| 型やデータ構造が曖昧 | - DataAnnotations を活用- APIの入出力はOpenAPIで定義 |
| ハードコードされた設定 | - appsettingsを利用して環境に応じた設定を分離 |
💡 AIは「明示されている情報」しか理解できない。型と設定は明示的に。
ベストプラクティス5：バージョンと履歴で文脈を補う
| 技術的負債 | 解決策 |
|---|---|
| コードの履歴が不明 | - Gitの粒度あるコミット + メッセージ - 「なぜ」変更したかを記録する |
| ライブラリ・モデルのバージョン管理が曖昧 | - .csproj, モデルバージョンの明記 |
💡 AIは過去の意図を推測できない。バージョンと履歴が補助線になる。
✅ AIと人間が協業できる設計をする
ベストプラクティス6：AIと「責任分担」できる構成にする
| 技術的負債 | 解決策 |
|---|---|
| 全作業をAI任せにして崩壊 | - 設計・構成・命名は人間が主導 - 実装・反復・改善はAIに任せる |
| AIの出力が信頼できず毎回手直し | - インターフェースと期待値を明確に設計 - テストでAI出力の正当性を保証する文化を作る |
💡 AIは道具であって主体ではない。設計は人間、実装はAIの役割分担がベスト。
戦略2：プロンプトを「個人技」から「チームの型」へ
技術的負債の返済には時間がかかります。それまでの間、私たちは高度なプロンプト技術でAIの性能を補う必要があります。
しかし、このスキルを「個人の感覚」に依存させていては、チーム全体の生産性は安定しません。そこで私たちは、この属人的な「個人技」を、誰もが再現可能な「チームの型」へと昇華させるための仕組みづくりを検討しています。
「プロンプトテンプレート」の導入
「こういう時は、こう聞くと上手くいく」という成功パターンを、具体的なテンプレート、つまり「型」として整備するアイデアです。「複雑なレガシーコードのリファクタリング」「カバレッジの高いテストコード生成」など、頻出するタスクごとに"型"を用意することで、誰でも一定水準のアウトプットをAIから引き出せるようにする狙いです。
ナレッジ共有の仕組み化
優れた「型」は一度作って終わりではありません。個人の新たな発見をチームの資産として取り込み、常に「型」をアップデートし続けるための場づくりも重要です。例えば、週次で「プロンプト改善会」のような時間を設けたり、Slackに成功事例を共有するチャンネルを作ったりといった方法が考えられます。高成長グループが持つ暗黙知を、チーム全体の「型」へと形式知化していくプロセスそのものをデザインしていきます。
これらの施策を通じて、チーム全体のプロンプトスキルを標準化し、技術的負債の量に左右されにくい安定した開発体制を築くことを目指しています。
皆さんのチームでは、どのようにプロンプトの「型」を作り、共有していますか？もし良いアイデアがあれば、ぜひコメントで教えていただけると嬉しいです。
戦略3：「自発的リファクタリング」を促す文化と仕組みづくり
最も重要かつ根深いのが、これらを実践し続けるための「文化と仕組み」です。
率直に言って、現在の組織構造は、メンバーがリファクタリングを積極的に行うインセンティブが働きにくいという課題を抱えています。この構造的課題に対し、私たちは「どうすれば、メンバーが自発的に、長期的な視点でコード品質に向き合う文化を育めるのか？」という問いと向き合っています。
その中で、解決策の有力な仮説として浮上しているのが、「ドメイン縦割りチーム制」への回帰です。
各チームが担当ドメインのコードベースに長期的な責任を持つことで、リファクタリングが「誰かのため」ではなく、「自分たちの未来の生産性を上げるための投資」へと変わるのではないか。コードが改善されればAIのサポート精度も上がり、自分たちの開発効率が向上する。このサイクルが、自発的な動機付けになると考えています。
もちろん、組織の変更は簡単なことではありません。AIによる生産性2倍の世界を目指すために、チームにとって最適な形は何か、私たちはこれからも議論を続けていきます。
おわりに
AI導入で見えた「1.5倍の壁」。その正体は、ツールではなく、私たち自身のコードと文化にありました。この壁にチームとしてどう向き合っていくか、挑戦はこれからです。技術的負債を解消し、AIとの協業を前提とした開発体制を作り上げていきたいと考えています。
Discussion