実践！ AIネイティブ開発 —— 社内AIコンテスト優勝チームの活用術

こんにちは、今年も暑いですね！暑すぎて、私は毎週高地に避暑してしまっていますが、皆さんはいかがお過ごしでしょうか？私が住む福島県には会津磐梯山を中心に猪苗代湖と裏磐梯という避暑地がありまして、自宅から1時間ほどで到着できる距離にあるため、今年はそちらで快適に過ごしています。関東からも車で来訪する人が多くいまして、ご興味ある方はぜひ訪れてみて頂ければと思います。前置きが長くなりました、新規事業開発チームでプロダクトエンジニアをしているmuranoです。

今回は、先日公開されました「AI活用コンテスト「A-1グランプリ」開催レポート —— 全チーム参加で生産性向上を加速！ - SmartHR Tech Blog」で第1位に入賞しました新規事業開発チームのAIの活用について紹介します。

A-1グランプリは、開発組織全体の生産性向上を目指し、各チームのAI活用事例を共有・表彰する取り組みです。7月に第1回が開催されました。

A-1グランプリ第1位獲得の背景

新規事業開発チームが今回のコンテストで第1位を獲得できた理由ですが、大きな要因としてAIネイティブ開発が評価されたことが挙げられます。

AIネイティブ開発とは、プロダクトの要件定義および設計ドキュメントの作成、設計ドキュメントをもとにしたJiraチケットの作成、そして実装までの一連の流れを、すべてAIを使って完結させ今までにない開発の質と量の向上を目指す開発スタイルです。この手法では、先述の全てのプロセスでAIが活用し、効率化をしています。

このAIを単に既存業務の効率化に使うだけでなく、新しい開発者体験や開発プロセスそのものを構築したこと、「改善を超えて根本的に変える」という姿勢が、A-1グランプリで高く評価されました。また、これらの定量的な成果を明確に示せたことも、審査の中で特に素晴らしい点として挙げられました。

従来の開発体制が抱えていた課題

AIネイティブ開発を紹介する前に、前提として今までの開発とそれが抱える課題について触れます。

新規事業開発チームでは、事業責任者を中心に少人数の体制で開発を行っており、プロダクトエンジニアがヒアリングから要件定義、設計、実装までの一連の流れを担当しています。この体制のもと、AIを要件定義からテストまで幅広く活用し、開発全体のリリースサイクルを加速させることを目指しています。

従来の開発プロセスでは、いくつかの課題がありました。まず、要件定義の段階では、プロダクト要件記述書を作成するのに多くの時間がかかっていました。必要な情報をテンプレート化して効率化を図ってはいるものの、開発の最初の段階であるため、どうしても記述に時間がかかってしまいます。また、シーケンス図などの図をMermaid記法で作成する際も手間がかかり、更新作業も煩雑でした。図を省略するとヌケモレの検査や他のメンバーの理解が難しくなるため、完全に省くこともできません。

設計フェーズでも同様の課題がありました。設計ドキュメントのフォーマットに沿って記述する作業や、ER図などの図を作成・更新する作業に時間がかかります。さらに、要件が変更された際に設計ドキュメントへの反映漏れが発生しやすい点も問題でした。設計内容をJiraチケットに落とし込む際も、Jiraのフォーマットに合わせて記述したり、Jiraの操作自体に手間がかかるため、全体のスピードが落ちてしまうことがありました。

実装・テストの段階では、要件をシンプルなCRUD画面に落とし込むこと自体は難しくありませんが、実際にファイルを作成し、コードやテストを書く作業は地道で手間がかかります。「やること自体は単純なのに、細かい作業が多くてもやっとする」という感覚を持つことも少なくありませんでした。

これらの課題を解決するために、私たちはAIを積極的に活用し、開発プロセス全体の効率化と品質向上を目指しています。

AIネイティブ開発の詳細

ここからはAIネイティブ開発で行ったことを詳しく説明していきます。 AIネイテイブ開発として、先述の課題に対して以下のように改善する方針を立てました。

Cursorエディタを使用し、AIモデルはClaude-4-sonnet(thinking)を利用
- 生成精度の低下によるAI疲れをなるべく減らす
Markdown形式で作成したPRDや設計ドキュメントなどを作成し、GitHubリポジトリの docs/配下に管理してCursorが閲覧・更新できる状態にする
- 後工程でのCursorの生成精度を向上させる

全体像

上記方針のもと、要件定義から実装までのフェーズでAIを活用した改善を実施しています。以下の図は、AIネイティブ開発におけるプロセス全体の流れと、各フェーズでの改善ポイントを示しています。

flowchart TD
    ReqPhase["要件定義<br/><br/>・人間: 7割程度の要件を定義<br/>・Cursor: 壁打ち相手として対話・補完<br/>・Mermaid図自動生成"]
    
    ReqPhase --> DesignPhase
    
    DesignPhase["設計ドキュメント作成<br/><br/>・Cursor: 要件定義から設計ドキュメントを自動生成<br/>・ER図・シーケンス図自動作成・更新<br/>・要件変更時にAIで反映"]
    
    DesignPhase --> JiraPhase
    
    JiraPhase["Jiraチケット作成<br/><br/>・Cursor: 設計ドキュメントから自動でチケット作成"]
    
    JiraPhase --> ImplPhase
    
    ImplPhase["実装<br/><br/>・Cursor: JiraチケットをもとにAIによる実装<br/>・ファイル作成からコード記述まで効率化"]

以降は各フェーズごとに詳細を説明します。

要件定義

要件定義の作成においては、Cursorを壁打ち相手として活用しています。

要件定義の初期段階では、プロダクトに必要な機能の背景や意義など、前提となる知識がAI側に十分に伝わっていないことが多いです。そのため、まずは人間側で7割程度の完成度の要件定義を作成し、残りの3割をCursorと対話しながら補完していく進め方が効果的です。

Cursorに壁打ち相手になってもらう際には、いくつかのポイントを意識しています。

要件定義を作成する際の観点や注意点を明文化し、CursorルールにすることでAIの出力品質を安定させる
「疑問点があれば都度質問して」と明示的に指示することで、AIが独断で進めてしまうことを防ぎ、認識齟齬を減らす
既存実装の知識をAIに与えたい場合は、関連するファイルやドキュメントのパスを必ず共有する

このような工夫を通じて、要件定義の精度とスピードを両立し、AIと人間の協働による開発プロセスの最適化を実現しています。

設計ドキュメント作成

作成した要件定義を元にして設計ドキュメントに反映させます。

まずはCursorと人間との間で合意を取るところから始めます。指示例として「本アプリケーションに@要件定義.mdに記載した『返済の請求対応』を機能追加するための設計アプローチを提案してください。その際に、メリット・デメリット、技術的なトレードオフも合わせて教えてください」といった具体的な指示を出します。

こうした指示により、Cursor側から「仕様について確認させてください」といった確認が来るため、良さそうな設計アプローチが固まってきたら次の段階に進みます。

次に、テンプレートに沿って合意した内容を設計ドキュメントに落とし込ませます。指示例としては「ここまで話してきた設計アプローチが良さそうなので、設計ドキュメントとして残します。docs/design配下に@template.mdのフォーマットに沿った設計ドキュメントを新規作成してください」といった形です。いきなりイチから作成させるとCursorも迷子になってしまうため、テンプレートを用意しておくことが重要です。

この段階でそれなりの質の設計ドキュメントが出来上がってくるため、人間で手直したり、Cursorと会話しながらブラッシュアップして完成まで持っていきます。設計ドキュメントの最下段に「チケット案」というセクションを用意しておき、このあとJiraに作成するチケットの草案も固めておきます。

Jiraチケット作成

設計時に固めた「チケット案」通りにJiraに作成するのをCursorに代行してもらいます。

事前に、MCPを利用してCursorがJiraチケットの閲覧・作成・更新をできるようにしておきます（設定の詳細は環境によって異なるため割愛しますが、Jiraの公式ページなどを参考にしてください）。また、Jiraチケットを作成するCursor Commandを用意しておきます。このCommandにはJiraチケットのテンプレートも含んでいて、人間がチケットを作成する時と同様のテンプレートで作成できるようにしています。

実際にチケットを作成するときには、上記Commandを使って指示を出します。指示例としては「/Jiraチケット作成コマンド @20250513_新しい機能.mdの設計のチケット案に基づき、新しい機能のJiraのエピックにチケットを作成してください」といった形になります。

これにより、Cursorで一貫したルールのチケットを作成しています。

実装

Jiraチケットの内容に沿って実装を進めてもらいます。ただし、チャット量が増えすぎると生成精度が突然低下するため、適切な粒度でチャットを分けることが重要です。最新のCursorでは、チャットの中にコンテキストの使用量が表示されるので、そちらの数値を参考にしながらチャットを分けると良いと思います。

チャットを分けても一貫した開発ができるように、最初に実装完了に向けてのTODOリストを作成させます。指示例としては「『新しい機能のAPI』を実装したい。実装プランをたてて、やらなければならないタスクをTODOリスト化してくれますか？」といった形です。

あとはTODOリストの1つ1つをチャットを分けて実装させていきます。この方法により、大きな機能開発でも迷子になることなく、効率的に実装を進めることができます。最近では、CursorにもTodo機能が追加されため、ケースバイケースで使い分けていますが、過渡期のため効果的な使い分け方はまだ手探りの状態です。将来的にはCursorのTodo機能のみで使いこなせれば嬉しいなと思います。

また、生成精度向上のためにCursorルールの改善も頻繁にしました。こちらについては先日、「実践Cursorプロジェクトルール —— Rails向けテンプレートを大公開！ - SmartHR Tech Blog」という記事を公開しましたので、ご興味ある方はご覧ください。

AI活用による生産性向上の効果

定量的・定性的な観点から、AI活用による効果を測定した結果をお伝えします。

定量的な成果

AIネイティブ開発実施前は、スクラム開発におけるストーリーポイント1ポイントあたりの作業時間は1.5時間未満〜2.5時間でばらつきが多く、安定しない状態が続いていました。実施後は1.5時間程度で安定して推移するようになりました。

1スプリントが1週間で、2ヶ月間で9スプリント分のデータを比較しています。

特に、実施前後の2ヶ月間で比較すると1ポイントあたりの作業時間が2.04時間から1.43時間に大幅に減少していることがわかりました。新規事業開発チームは、AIをフル活用することで価値提供のスピードを最大限速くできていると思います。

定性的な成果

定性的な観点からも、いくつかの改善効果を実感しています。

開発者体験の向上
- ドキュメントの修正に割く時間が減ったため、最終的な成果物のコードに直接寄与しない作業でも、心理的な負担が減りました
品質の向上
- 設計的な不備をAIが指摘してくれたり、設計ドキュメントの品質が上がることで人間が設計段階での不具合・検討漏れに気づくことが増え、総合的な品質が向上しました
属人性の低下
- 設計は比較的属人性が高い作業に分類されると思いますが、AIのおかげで人によるばらつきが少なくなったと感じています

AI活用を成功させるためのポイント

Cursorルールや各フェーズのドキュメントのテンプレートを事前に用意することで、実装フェーズだけでなく、要件定義・設計なども安定した出力をCursorから得られるようになりました。

2025年上半期だけでも、Claudeが3.5→3.7→4とどんどんと性能が良くなっているのを実感し、チームの開発速度向上（1ポイントあたりに費やす時間が0.5~1.0時間ほど短縮された）も確認できています。引き続きAIをどう活用するかを模索しながら更に開発のスピード感を高めていきたいと思います（Claude 4の次が待ち遠しい）。

今後のAI活用計画

新規事業開発チームとしては、今後もAIの活用を推し進めていきたいと考えています。ちょっと夢のような妄想もありつつですが、以下のようなことを検討中です。

Devinを使ったゼロタイム実装

すでにDevinの活用も進んでいますが、現状は作業量が少なくやることが明確なものを実装してもらっています。大きい単位の実装もDevinが作業しやすいようにチケットの作り方を工夫することで、Devinのみで実装を完結できないかと考えています。

DevinとはAIエージェントツールの1つで、コーディングの作業環境も含めてAIが内包し、実装からテストなどの実行までをオールインワンで完結してくれるサービスです。SmartHRでの導入については「Cursor/Devin全社導入の理想と現実 - Speaker Deck」をご覧ください。

Cursorルールの継続的改善

今現在、バックエンド（Rails）を中心にルールの整備が進んでいますが、バックエンドの中でもテスト部分の精度が低かったり、フロントエンド（Next.js）の整備があまり進んでいない状況があります。

グラフのrootは.cursor/rules直下にあるリポジトリ全体に関するルールの合計行数、backendはバックエンドに関するルールの合計行数、frontendはbakcendと同様にフロントエンドに関するものを集計したもの、schemaはAPIスキーマ定義に関するルールの合計行数になります。

こちらも日々の開発を行う過程でブラッシュアップしていきます。

活用の方向性

新規事業開発チームでは、今後もAIの活用を推進していきます。その結果、人間がより高度な作業（ディスカバリーや設計作業）に集中することで、プロダクト開発とそれによる事業の高速化を進めていきたいと考えています。その過程で、技術的負債の解消や作業自動化による開発者体験の向上もAIを活用し、より充実させていければと思います。一方で、プロダクト開発の本質的な部分（機能開発の意思決定や顧客からのヒアリングなど）は今まで以上に人間が行うことに意義が出てくるため、今までも重視してきましたがよりコミットしていきたいと考えます。

まとめ

というわけで、いい感じにAIを活用してさらにはA-1グランプリで優勝をいただいて、チームの活動を表層的に見ると、この数ヶ月でAIの活用がどんどん進んだように見えるかもしれません。しかし、個人的にはこの1年くらいの地道な活動がAIと偶発的に結びついた結果だと思っています。

具体的には、開発のプロセスを定義してテンプレートを作成・改善したり、属人的な作業のマニュアルを作成したりしてきたことで、AIを活用する下地ができていたように感じています。つまり、AIを入れたらなんでもうまくいくとは全く思っていなくて、むしろちゃんと開発を頑張っている組織がAIによってさらに強くなっているんじゃないかと思い、これからも地道な活動を大切に頑張っていきたい所存です。