本記事は 株式会社SUPER STUDIO Advent Calendar 2025 の3日目の記事です。
2025年を振り返ると、前年と比べても急速な勢いで生成AI関連のツールが発展しました。
それに伴い、実務での開発スタイルにも大きな変化が生まれた1年だったように思います。
我々の組織全体でも各チームでAIツールを使ったトライアンドエラーが活発に行われ、日々活用事例が増えてきています。
AI関連ツールを使うのが当たり前になってきた一方で、 「よりAIを活用しやすい環境に整備できているか」 が生産性を上げる上での重要なポイントになってきていると感じています。
本記事では、実務で扱うコードベースをAIツール活用しやすいようにシフトしていくために、2025年にチーム内で取り組んだことを振り返っていきます。
前提
我々のチームで扱うメインアプリケーションは、ローンチから2年弱の比較的新しいプロダクトです。
おおまかな技術構成
- 使用言語: TypeScript
- フレームワーク: Next.js (Webフロントエンド、Route HandlerにtRPCを統合したモノリス)
- ORM: Prisma
- DB: MySQL
- リポジトリ: pnpm workspace + Turborepoを使ったモノレポ
チームで利用している主要なAIツール
- Cursor
- Claude Code
- GitHub Copilot
- Gemini
- Notion AI
チーム運営
- メンバー構成: エンジニア 4名, PdM 1名, デザイナー 2名
- スクラム開発: 2週間スプリント
戦略
AIツールを利用すると、人間だけでコードを書いていた時代と比較して、圧倒的な速度で「差分」を生み出すことができます。
一方で、その差分が適切かどうかは人間が判断していく必要があります。
つまり、コーディング速度が上がっても、最終的には人間がボトルネックになります。
そのため、品質をしっかり担保しつつ、極力人間がボトルネックにならないような状態を目指すべきだと考えました。
「どんな状態だと人間の負荷が高くならないか」をイメージし、以下の3点を定義しました。
-
a: AIが意図した通りにコードを生み出してくれる
- 精度が高く手戻りの数が少ない
-
b: 客観的にみて品質に問題がないか判断しやすい
- 受け入れ基準が明確
-
c: AIが間違ってないか自分で確認して修正できる
- 検証・修正作業を委譲できる
上記の状態を実現するための仕組み作りとして、本年は以下の優先度が高い事項を中心に取り組みました。
やったこと
ここからは我々のチームで2025年に取り組んだ施策の中から、いくつかをピックアップして紹介します。
1. 開発に関わるコミュニケーションフローの整理
戦略で挙げた a, b を実現するのに必要なのは 「仕様の明確化」 です。
AIが良いアウトプットをするためには良いインプットが必要であり、アウトプットが合っているか判定するための明確な基準も不可欠です。
当初、我々のチームでは仕様があいまいな状態でスクラムが開始し、開発の過程で考慮漏れが発覚、都度仕様の擦り合わせ直しが発生することが多々ありました。
ゴールが曖昧な状態ではAIをうまくナビゲートできず、たとえ実装コストが下がっても、人間側の調整コストによりリードタイムが短縮できないという課題がありました。
そこで、元々運用されていたスクラムの仕組みを以下のようにブラッシュアップしました。
- PBIのリファインメント比重を増加: それを前提としたスケジュールでスクラムイベントを組む
- スパイク（調査）と実装の分離: 不確実性を先に潰す
- Readyの定義の徹底: PBIの要件、完了の定義を明確にしてからスプリントに持ち込む
PBIが明確になったかどうかの目安としては、 「そのままAIにプロンプトとして指示出しできるレベルか？」 という基準を持っています。
AIに作業を委譲する上で重要なのは、日頃からゴールを意識した質の高いコミュニケーションをとれるフローができているかだと感じています。
（このトピックだけで1記事書けそうなので、機会があれば別途まとめたいと思います）
2. チケットテンプレートの整備
AIに指示出しする上では、アウトプットに必要な情報が出揃っているかが重要になります。
改善前はチケット（PBI）の記載内容がバラバラで、作業に必要な情報がカバーされていないこともありました。
そこで、チケットに必要な情報が記載されるようテンプレートを整備しました。
記載項目の一例
- 目的
- 背景
- 要件
- 完了の定義
- 対応内容
- 参考資料
実装作業時はこのチケットをもとに、AIに作業指示を行います。
しっかり情報の出揃ったPBIがあれば、AIにSBIの起票自体を委譲することも可能です。
3. 設計ドキュメントの整備
新機能の開発や既存機能の改修前に、設計ドキュメントをMarkdownで作成するようにしました（戦略 a, b に関連）。
ドキュメントには機能概要や自然言語でまとめた処理の流れに加え、Mermaidで書いたシーケンス図やER図などを記載しています。
目的
- 考慮漏れがないかの事前レビュー
- 実装時のAIへの指示出し（コンテキストとして与える）
- テストケース作成のインプット
コードよりも人間にとってリーダブルなため判断しやすいのが利点です。
以前はMermaidを手で書くのは大変でしたが、AIの支援により作成・修正が容易になったため、ドキュメント化のコストパフォーマンスは格段に良くなっています。
このドキュメントはバージョン管理しやすいようにリポジトリ内の docs ディレクトリでGit管理しています。
Markdown形式なので、必要に応じてNotion等に転記して共有もしやすく、何よりAI（Cursor等）に読み込ませやすいのがポイントです。
4. コーディングガイドラインの整備
コーディング規約は基本Linterで自動化しつつ、ファイルの命名規則や設計指針など、静的チェックではカバーしづらい部分をドキュメント化しました。
こちらも docs ディレクトリ配下でGit管理しています。
現状、複数のコーディングエージェントを併用しているため、ドキュメント自体は1箇所にまとめ、CLAUDE.md や .cursor/rules にはドキュメントへの参照を記載する運用としています。
このドキュメントは分厚いルールブックにするのではなく、 「AIの出力結果が微妙だった際に、再発防止としてルールを追加する」 という運用方針でアップデートしています。
5. 静的チェックの速度改善
コーディングエージェントの実装後に自動でコマンドを実行し、ESLintとTypeScriptの型チェック（tsc）を行うようにしています。
このチェックは高頻度で行うため、実行時間が長いと開発者体験を著しく損ないます。
そこで、tsc より高速化が見込まれる、 tsgo を導入しました。
参考程度ですがローカル環境でメインアプリケーションのコードに対して、time コマンドでそれぞれ10回ずつ実行した計測結果は以下の通りです。
| コマンド | 初回実行 (total) | 2回目以降 (平均) | 備考 |
|---|---|---|---|
tsc |
2.867s | 約 2.85s | 毎回フルチェック |
tsgo |
1.994s | 約 0.71s | 約4倍高速化 |
tsgoは初回こそ通常のtscに近い時間がかかりますが、2回目以降はキャッシュが効くため、実行時間が 1秒以下 にまで短縮されました。
実行ログの詳細（10回計測）
tsc の実行結果
実行 1: pnpm tsc --noEmit 4.52s user 0.70s system 182% cpu 2.867 total
実行 2: pnpm tsc --noEmit 4.54s user 0.66s system 184% cpu 2.828 total
実行 3: pnpm tsc --noEmit 4.60s user 0.68s system 181% cpu 2.905 total
実行 4: pnpm tsc --noEmit 4.62s user 0.67s system 183% cpu 2.881 total
実行 5: pnpm tsc --noEmit 4.56s user 0.67s system 184% cpu 2.826 total
実行 6: pnpm tsc --noEmit 4.54s user 0.67s system 183% cpu 2.841 total
実行 7: pnpm tsc --noEmit 4.55s user 0.67s system 184% cpu 2.831 total
実行 8: pnpm tsc --noEmit 4.57s user 0.67s system 184% cpu 2.847 total
実行 9: pnpm tsc --noEmit 4.59s user 0.67s system 183% cpu 2.855 total
実行 10: pnpm tsc --noEmit 4.57s user 0.66s system 183% cpu 2.847 total
tsgo の実行結果
実行 1: pnpm typecheck 7.10s user 1.07s system 409% cpu 1.994 total
実行 2: pnpm typecheck 2.29s user 0.90s system 441% cpu 0.723 total
実行 3: pnpm typecheck 2.06s user 0.70s system 391% cpu 0.705 total
実行 4: pnpm typecheck 2.10s user 0.73s system 395% cpu 0.715 total
実行 5: pnpm typecheck 2.42s user 0.98s system 475% cpu 0.715 total
実行 6: pnpm typecheck 2.18s user 0.95s system 448% cpu 0.696 total
実行 7: pnpm typecheck 2.27s user 0.72s system 431% cpu 0.692 total
実行 8: pnpm typecheck 2.22s user 0.68s system 404% cpu 0.718 total
実行 9: pnpm typecheck 2.20s user 0.68s system 396% cpu 0.726 total
実行 10: pnpm typecheck 2.27s user 0.71s system 413% cpu 0.721 total
AIとの対話では「コード生成 → 静的チェック → AIによる修正」というループを何度も回すことになります。
この待ち時間が数秒単位でも短縮されることで、開発のリズムが途切れず、体感としてかなり快適になりました。
今後はESLintについても、OXLintやBiomeを取り入れ、さらなる短縮ができないか検討しています。
6. 自動テストの整備
戦略 b, c に関連する取り組みです。
既存コードベースは手動テスト中心だったため、AIが生成した大量の変更をスピーディに検証できず、AIの強みを活かしきれない課題がありました。
そこで、以下の実現を目指して自動テストを整備しました。
- 仕様への適合を判定しやすくする
- AIがコマンドラインからテストを実行・結果確認できるようにし、修正のループをAIへ委譲可能にする
テスト戦略: 結合テスト（IT）の重視
Jestを用い、バックエンド・フロントエンドで境界を分けた「結合テスト（IT）」を充実させる方針をとりました。
- UT（単体テスト）: ユースケースレベルの担保にはやや不向き
- E2E: 実行時間が長く不安定なため、AIが頻繁に回すには不向き
- IT（結合テスト）: 両者のバランスが良い
実装フロー
- テスト戦略や書き方をドキュメント化（AIへの指示書となる）
- 既存コードを元にAIにテストケースを洗い出させる（人間がレビュー）
- ドキュメントに沿ってAIにテストコードを書かせる
- AI自身がテストを実行 → エラー修正のループを回す
このフローにより、かなりのスピードでテストカバレッジを向上できました。
「変更の検証」は大変な作業ですが、AIが自力で動作確認できる状態（=テストがある状態）になっているのは非常に心強いです。
なお、アプリケーションを一気貫通した動作、画面遷移を伴う操作やiframe内の操作など、現状の自動テストでカバーしきれない部分は引き続き手動テストと併用しています。
7. AIコードレビュー
コードレビューの一次チェックとして、以下のツールを活用しています。
- GitHub Copilot
- Claude
人間がレビューする前のフィルタリングとしてAIを利用することで、レビュアーの負荷を大幅に軽減できています。
その分、人間は「コードを通じたナレッジの共有」や「設計の妥当性」など、より本質的な議論に時間を使えるようになりました。
8. MCPサーバーの活用
現状、以下のMCPサーバーを利用しています。
-
Notion MCP
- Notion上の仕様やドキュメントをインプットできるように導入
- CursorからNotion上のSBIを参照させて実装 → GitHub CLIでPR作成までをシームレスに
-
Serena MCP
- Claude Codeの精度アップのため導入
- （現状も必要かは検討の余地あり？）
MCP周りはまだ深掘りできていないため、今後さらにブラッシュアップしていきたい領域です。
所感
振り返ると、今回紹介した取り組みの多くは「AIツールの有無に関わらず、開発プロセス改善に効果的なもの」でした。
しかし、AIツールを活用する上では、特に 「情報の整理（インプットの質）」 が重要であると痛感しました。
言語化されていない抽象度の高い課題はAIに委譲しづらいです。
人間がやるべきなのは、 「曖昧で複雑性の高い問題をクリアにし、AIへ委譲できる形（方向性とゴール）に変換すること」 です。
そして、AIが出したアウトプットに対する責任は人間が負うため、それを検証しやすい仕組みづくり（テストや静的解析）がセットで必要になります。
AIに対するパイロットであるエンジニアが「方向性」と「ゴール」を高解像度で持っていれば、AIは最高のパフォーマンスを発揮してくれます。
今後やりたいこと
-
AIに委譲できる作業の拡大
- 障害原因の調査やパフォーマンスボトルネックの特定など
-
E2Eテストの拡充
- 現状の自動テストではカバーできていない部分の品質担保
-
モニタリングの強化
- 変更スピードが上がる分、異変検知の仕組みを強化したい
-
スクラムのスプリント期間の短縮
- 早く作れるようになった分、デリバリーサイクルをさらに短くする
まとめ
2025年は、AIツールをフル活用するための「環境整備」の重要性を強く感じた1年でした。
環境をブラッシュアップしつつ、実際のAIツールの具体的な活用事例についても、また改めて記事にできればと思います。
また我々の組織、チームではプロダクト機能へのAI組み込みも積極的に行っています。
今後もAI技術の進化をキャッチアップし、良いプロダクト開発に繋げていきたいと思います。