はじめに
こんにちは、OPTiM Support & Growth Portal（SGP）のバックエンドエンジニアをしている太田です。
開発での AI 活用が進む中、私たちのチームでも AI を開発フローに本格的に組み込む取り組みを進めてきました。個人のコード補完にとどまらず、設計・実装・レビューといった工程そのものに AI を組み込んで運用しています。
結果として、設計からレビューまでの開発フロー自体が変わりました。以前は機能仕様書なしで実装に入ることも珍しくなかったチームが、今では機能仕様書を起点に、設計で整理した内容をそのまま実装・レビューまでつなぐ形に変わっています。
具体的には、設計では機能仕様書の作成やタスク分割、実装では既存ルールに沿ったコード生成、レビューではセルフレビューや MR*1 レビューの前処理といった形で運用を見直しました。
本記事では、その実践事例と、実際にチームで運用してみて分かった効果や課題を紹介します。
なお、本記事では以下の用語が頻出するため、先に整理しておきます。
| 用語 | 意味 |
|---|---|
| Skills | AI に渡すチーム固有の知識・方針・作法をまとめた指示セット。ドメイン知識やベストプラクティスを定義し、AI の振る舞いをカスタマイズできる |
| Rules | Skills より細かい粒度の実装ルールや制約。コーディング規約、命名規則、エラーハンドリング方針など |
| MCP | Model Context Protocol。AI が外部ツール（Redmine、GitLab など）と連携するための標準プロトコル。対応する MCP サーバーを用意すれば、さまざまなサービスと AI を接続できる |
設計フェーズでの活用
機能仕様書作成の効率化
まず大きく変わったのが、設計フェーズです。
以前はドキュメントを書く手間や工数の都合から、機能仕様書がほぼない状態で実装に入ることも少なくありませんでした。しかし、AI を活用した Skills を整備したことで、機能仕様の整理が大幅に効率化されました。
具体的には、要件定義資料をベース情報として渡すと、以下のようなことをやってくれます。
- 機能仕様書の大枠を自動生成
- 不足情報や矛盾点の指摘
- シーケンス図やフローチャートの自動生成
不足情報や矛盾点を指摘してくれるため、実装フェーズに入ってから判明する考慮漏れがかなり減りました。手作業だと時間がかかる図の作成も支援してくれるため、設計の初期整理がかなり進めやすくなりました。
一方で、これまでドキュメントが十分に整備されていなかった分、AI が参照できる既存の情報が少なく、ドメイン知識や権限処理などプロダクトの基盤に関わる部分では人間による修正が必要になることもあります。
また、以前は実装しながら設計を進める形で、認識合わせも実装ベースで行っていたため、共有範囲が実装者とレビュワーに限られていました。機能仕様書として文章化されたことで、設計者・実装者・レビュワーが異なる場合でも同じドキュメントをベースに認識を共有できるようになりました。フロントエンドとバックエンドの間でも同じ機能仕様書を参照するため、領域をまたいだ認識合わせもしやすくなっています。
今では機能開発の前に機能仕様書で設計を詰め、チーム内で共通認識を取るフローが当たり前になりました。
チケット作成の自動化
設計の効率化はドキュメントだけにとどまりません。チームメンバーが OSS として公開した Redmine MCP を活用して、機能仕様書の内容からタスク分割・チケット作成・スケジュール設定の叩き台を作成しています。最終的な粒度調整や優先度の確認は人間が行いますが、ゼロから起票する手間は大きく減りました。
- Redmine の設定や、望ましいタスク粒度、工数見積もりの目安を Skills に整理
- 機能仕様書の内容をもとに、プロジェクトに合ったチケット案を生成
- 依存関係や優先度を踏まえたスケジュール案までまとめて作成
さらに、機能仕様に変更が入った際も、チケット作成の Skills を再度呼び出すことで、既存チケットを取得して不足分の洗い出しや情報の更新まで行えるため、機能仕様書とチケットが常に同期された状態を保てるようになりました。Slack での議論内容を AI で要約してチケット化する仕組みも導入しており、障害対応やバグ報告の起票漏れの防止にもつながっています（詳細は「AIがSlackをRedmineチケットに変換！モダンなIaCとクリーンアーキテクチャで構築した開発効率化ツール」を参照）。
また、TypeSpec*2 による OpenAPI 定義や、Prisma Schema*3 の叩き台作成にも AI を活用しています。既存実装と機能仕様書を渡すことで、大枠の定義を短時間で作れるようになりました。現状は「完成版を任せる」というより、レビュー前提の叩き台を素早く作る用途で使っています。
実装フェーズでの活用
設計フェーズで整理された機能仕様書やチケットをもとに、実装フェーズでも AI 活用が進みました。
実装の標準化
チーム用の Skills や Rules（コーディング規約や実装上の制約を明文化したルール）を整備し、コーディング規約や既存実装のパターンを AI が参照できるようにしています。これにより、細かい指示をしなくても既存のコードスタイルに合った実装を出しやすくなりました。
API実装では、たとえば、エラーハンドリングやライブラリの使い方といった基本的なパターンが整理されました。特にバリデーション処理では、OpenAPI の定義をもとにミドルウェアで処理する範囲と、実装側で明示的にカバーする範囲の境界が曖昧で、実装者によって対応が分かれていました。この責務分担を Skills として明確にしたことで、実装が統一されるようになりました。
「このパターンはどう実装するんだっけ？」と悩む時間が減り、実装者ごとの差も小さくなりました。コードレビューでの規約関連の指摘も減っています。
バックエンドに限らず、フロント開発でも同様に Skills の整備が進んでいます。デザイントークンや React/TypeScript 向けの規約を Skills として整備したことで、コード規約や静的チェックで拾いづらい部分の指摘が減少しました。結果的にビジネスロジックなどプロダクトの重要な部分のレビューに時間をかけられるようになっています。また、BFF*4 の実装のように、パターン化された処理は Skills で自動生成できるようにしており、従来は 1 時間程度かかっていた作業が 5 分程度で完了するようになりました。また、AI 活用によりコンポーネントの共通化といった、以前は後回しにしがちだった改善にも着手できるようになっています。
レビューフェーズでの活用
実装が終わったら、次はレビューです。ここでも AI を活用することで、レビューの質とスピードの両立を目指しています。
セルフレビューの自動化
実装完了後に、Skills でコーディング規約やプロダクトの基盤知識を参照させたセルフレビューを実行しています。人間がレビューする前に、規約違反や既存パターンとのずれといった基本的なチェックを先に行えるため、人間のレビューでは設計意図や仕様妥当性の確認に時間を使いやすくなりました。
MR レビューの効率化
同じくチームメンバーが OSS として公開した GitLab MCP を使って、以下の流れを自動化しています。
- MR 情報の取得
- 差分の自動レビュー
- 指摘内容の MR へのコメント追加
セルフレビューと同じ Skills/Rules を参照させているので、一貫性のあるレビューが実現できています。
レビュー対応の自動化
レビュー指摘が来たら、GitLab MCP でレビューコメントを取得し、修正対応まで AI に任せることもできます。基本的なコードレベルの問題やケアレスミスであれば問題なく修正してくれますが、ロジックが絡む修正は人間の判断が必要になる部分もあります。
運用としては、タスク担当者が修正方針の計画時点で内容を確認し、実装後もセルフレビューを行うようにしています。場合によっては、別のセッションに切り替えて再度 AI レビューを通すこともあります。レビュワーのコメントに問題点や対応方針が具体的に記載されているほど、AI の修正精度が高くなる印象です。
また、AI が修正時にコメントを参照することを前提として、レビューコメントの書き方自体も変化しました。同一の内容でも具体的な修正箇所それぞれにコメントするなど、AI が正確に修正できるよう意識した書き方になっています。さらに、AI にコメント自体を任せられるようになったことで、類似箇所への横展開も労力を感じにくくなりました。
Codex Automations によるスケジュール実行
さらに進んだ取り組みとして、Codex Automations を使ったレビューのスケジュール実行にも挑戦しています。あらかじめ定義したプロンプトを定期トリガーで自動実行する仕組みで、これまでの「必要なときに人が呼び出す使い方」に加えて、「決まった条件や時刻で自動実行する使い方」が可能になります。
たとえば、一定間隔でレビュー依頼中の MR を検出し、差分を確認してレポートを生成するといった処理を定期実行できます。レビューという「割り込みイベント」のコンテキストスイッチコストを削減できるため、定型的なレビュー作業のバッチ化との相性は良いと感じています。まだ試行段階ではありますが、今後の展開に期待しています。
効果と課題
なお、AI の処理待ちが増えたことで、待ち時間の使い方も工夫するようになりました。たとえば git-worktree-runner を使って実装とレビューを別ブランチで並行して進めたり、複数件のレビューをまとめて AI に任せてレポートだけ後から確認するといった運用をしています。
良かった点
- 案件によって差はあるが、開発開始からレビュー依頼までの時間は大きく短縮した
- Skills/Rules による標準化で実装品質が安定し、コードレビューでの規約関連の指摘が減った
- 定型作業が減ったことで、設計判断やビジネスロジックの検討に時間を使えるようになった
- スケジュール実行によるレビューのバッチ化で、割り込みコストが減った
まだ課題な点
- AI 生成物の精度にはムラがあり、特に例外系の処理、境界条件、既存実装との整合性では人間の確認が欠かせない
- たまに意図しない実装をされることがあり、レビューで見落とすリスクがある
- 並行作業の負荷は高く、並列数が増えると AI の承認をし続けるだけになってしまう
- AI の性能よりもプロンプトの設計品質が結果を左右する。1 つのプロンプトに複数の責務を持たせると安定しないなど、ソフトウェア設計と同じ原則が当てはまる
まとめ
チーム全体で AI を開発フローに組み込むことで、設計・実装・レビューのそれぞれで効率化を実現できました。取り組みを通じて感じたポイントを 2 つ挙げます。
- 機能仕様書を起点にすることで、設計・実装・レビューがつながりやすくなった。AI 活用を個別最適ではなく、開発フロー全体の改善につなげやすくなる
- Skills/Rules を整備したことで、個人の工夫がチームで再現可能な運用に変わった。実装やレビューのばらつきも減りやすくなる
AI 活用はまだ発展途上の分野ですが、チーム開発での効率化には確実に効果があります。今後は AI にもっと任せて人間は別のタスクに集中できるような仕組みを模索していきたいと思います。
オプティムでは一緒に働くエンジニアを募集しています
こうした開発フローの改善を、ツール導入だけでなく運用設計まで含めて一緒に考えられるエンジニアを募集しています。少しでも興味を持っていただけた方は、ぜひ以下をご覧ください。
