はじめに
弊社でも時代の流れを受け、エンジニア全員がAIを使って開発するようになりました。
一方で目の前の開発に追われ、AIの使い方を見直す時間はあまり取れておらず、まだまだ有効活用出来ているとは言い難い状況にあります。
そんな中、あるプロダクトチームが企画した生産性向上MTGに私も参加し、そこでの「AIをどう使えば生産性をさらに高められるのか」という議論は、当たり前のようで見落としていた気づきも多く、とても参考になりました。
既存プロダクトを任されているエンジニアの方々の中には、同じような境遇にいる方もいるかと思うので参考になれば幸いです。
前提：ドキュメントと開発スタイル
存在するドキュメント
- ざっくりとした機能概要（notion管理）
- マニュアルレベルのドキュメント（PDFやpowerpoint）
- 機能変更の頻度が激しく詳細設計レベルの仕様書は存在しません（Githubのissueに仕様が点在）。
開発スタイル
- Issueベースで進むアジャイル開発であり、コードと過去issueを参照しながら開発が進む
- IDEは個人の好きなものを選定できますが、プロダクトがRubyという事もあり全員RubyMineを利用
- AIツールもIDE同様ですが全員Github Copilotを利用
開発現場でのAI利用に関する共通認識
まずはAIをどのように活用し、どのように感じているか参加者それぞれがコメントしました。
- 現状ではGoogle検索の代替のような使われ方に留まっている
- そのレベルではインパクトが弱く、時間短縮を実感できず活用が進まない
- 不具合や動作不良の調査をよく担当するが、その場合ほとんど役に立たない
- 検討違いな提案が多く逆に時間がかかる
- Viewなどの画面の実装、新規機能のバックエンド実装など「新しく作る」作業ではAIが生産性向上に貢献している。一方で、既存コードの修正や仕様変更では期待通りの提案が得られない
- エラー番号などの具体的な情報がある場合は有効なこともあるが、ビジネスロジックに深く関わる修正はAIが苦手な印象
まとめると
「新機能には強く、既存コードに弱い」
という感覚が、チーム全体の共通認識でした。
なぜAIは既存コードが苦手なのか
議論を通じて見えてきた理由は、そこまで複雑なものではありませんでした。
AIは、
- Controller / Model / View といった比較的近いコード同士の関係
- 単一ファイル、もしくは限定的な文脈
については、ある程度考慮して提案してくれます。
しかし、既存コードの修正では次のような情報が重要になります。
- データ構造の前提（どのテーブルにどのようなデータがあるか）
- 外部サービスとの連携やアーキテクチャ構成（例：SQS + Redis + Workerといった非同期処理の仕組みなど）
- それらによって生じるシステム特性
- なぜその実装になっているのかという背景や経緯といった経験値
これらはコード上に明示されていないことが多く、AIはほとんど考慮できていません。
つまり、コードが成立している「前提知識」が足りない。という結論に至りました。
前提知識をAIに与えられない理由
言語化する事はなくても、皆同じような事を薄々感じながら日々過ごしていたようです。
では、なぜその前提知識をAIに与えられなかったのでしょうか？
- 情報が点在しているうえにフォーマットの違いもあり、それらを全て取り込むのは片手間に出来ない
- ドキュメントはコードとの対応関係が弱く、そのままでは精度向上もあまり見込めないのでイマイチやる気が出ない
- データ量が多すぎてトークン消費の観点からも現実的ではない
人向けに作られたドキュメントをそのままAIに取り込むには限界があり、皆そこで壁にぶつかっていました。
Repositoryに前提知識を蓄積する
これまで出てきた課題感を踏まえ、当該チームでは以下の施策を実施する事になりました。
AIに読み込ませる前提知識として、Repository内に情報を蓄積する
AI用に別に用意するのではなく、点在している情報を徐々に集約（移行）していく事を考えています。
- markdown形式であれば人とAIでドキュメントを共有できる
- 開発時に自然と目に入るのでコードと同時にメンテナンスも行い易く、コードとの対応関係も書き易い
- そのままAIに読み込ませ易い
- AIに当該ドキュメントを前提知識として指定する事で、コード全体を読みこませなくてもAIが全体像を把握し易くトークン効率やパフォーマスが期待できる
- 徐々に移行でき（無理が無い）、その成果を他のメンバーとも共有し易い
という点で、かなり相性が良さそうに感じました。
ネクストアクション
まずは早急にドキュメントの保管ルールを決めて、過去にうまくいかなかった既存バグ修正を題材にして試してみる事になりました。
- 不足していそうな前提知識をファイルとして追加する
- AIに修正案を出させる
- 満足いく修正がでなければ、さらに必要と思われる情報を追加する
- 再度AIに修正案を出させ、提案の変化を見る
これを繰り返すことで、
- AIにとって本当に必要な情報は何か
- ナレッジをどう蓄積すれば有効活用できるか
見えてくるはずです。
1つのバグ修正にフォーカスすれば、そこまで時間をかけずに有用性の確認とガイドライン作成もできそうです。
おわりに
プロダクトにとってノウハウの俗人化は頭を悩ます問題でもあります。
今回の施策は開発メンバーの負荷軽減だけでなく、マネジメントにとってもノウハウ共有や俗人化の観点から有効な施策に感じました。
時間経過と共に徐々にAIが育ってきて、新たな戦力になってくれる事を期待したいなと思いました。
お知らせ
2026/5/28に博多でエンジニア向けのLT会開催します。
お食事＆ドリンクでワイワイする会です。
是非お気軽にお越しください。
https://layered.connpass.com/event/378115/
若手エンジニア募集しています。
自社サービス開発、フルスタックエンジニア、要件定義・設計等に味のある方は是非。
https://www.wantedly.com/projects/2297977