はじめに

楽楽請求開発チームのkyoshimotoです。バックエンド開発チームに所属し、開発チームをスケールさせるための開発プロセス整備、チーム内でのAI活用の推進を担当しています。本記事では、現時点のAI活用状況や、うまくいっている点・うまくいっていない点、学んだことを共有します。

AI関連の話題

AI活用に関する期待を一段と高める話題が増えています。代表例を挙げます。

こうした記事を読むと心が踊る一方で、今後のエンジニアの仕事はどうなるのかと不安になる方もいると思います。とはいえ、商用プロダクトのソフトウェア開発の現場では、直近でエンジニアがAIに置き換わる気配は正直感じていません。ツール導入の成果は確かに出ていますが、効果が顕著な領域はまだ限定的で、期待値は少し落ち着いたというのが正直な実感です。

AI活用状況のスナップショット

現在、チームで利用・検証している主なツールです。新しいツールが日々リリースされ乱立する中、IntelliJ+GitHub Copilot を標準的な開発環境としつつ、他のツールも試用しながら開発プロセスに組み込んでいます。なお、バックエンドのプログラミング言語はKotlinがメインとなります。

AIツール	主な用途
ChatGPT	ドキュメント作成／コード生成／コードレビュー
Claude（検証中）	コード生成
Codex	コードレビュー
Devin	コード生成／ロジック調査／CIエラー対応／コードリーディング支援
Gemini	ドキュメント作成／コード生成／コードレビュー
GitHub Copilot	コード補完／コード生成／ロジック調査／コードレビュー／コードリーディング支援
NotebookLM	仕様検索／新規メンバーのオンボーディング支援

うまくいっていること

オンボーディング支援

外部設計書をNotebookLMに取り込み、仕様Q&Aを即時化。心理的安全性の高い質問窓口として機能し、新規メンバーの立ち上がりが加速しました。
2025年度はKotlin未経験者が10名以上ジョインしましたが、GitHub Copilotのタブ補完／チャットにより新しいプログラミング言語の習得が障壁になることなく、スムーズに実装タスクを開始できています。

コードリーディングの支援

IntelliJ＋GitHub Copilotで既存ロジックの理解を効率化。実装から仕様を逆引きして整理でき、質問対応の精度も向上。処理内容の要約や、UMLやER図の抽出など、コードリーディングの時間短縮やシステム理解に活用できています。

私の担当プロダクトは昨年10月にリリースしたばかりで、自社の別プロダクト（楽楽精算など）の機能実装を参考にする場面が多くあります。そこでDevinを用い、複数リポジトリを横断して実装を調査することで、調査コストを削減できています。プロダクト横断のコードリーディングが格段に楽になりました。

ボイラープレートの自動生成

マスタ系CRUDのAPI実装やValidationなどの定型実装の一部をDevinで自動生成できる成功事例が増えています。現在は、プロンプトのテンプレート化とプロセス組み込みを進めています。

単純で広範な一括修正の自動化

スキーマ変更に伴うエンティティ／テストデータ更新、APIリクエスト／レスポンス構造変更など、ロジックは単純だが影響範囲が広い作業は、数百ファイル規模でもDevinを使ってワンショットで完了するケースが多く、開発コスト削減の効果が出ています。

AIによるプルリクの一次レビュー

PR作成直後にAIがタイポ、コメントの誤り、表記ゆれ、スタイル不一致といった軽微な指摘を先出しします。これにより、レビュアーは設計やロジックなど本質的な論点に専念できています。（GitHub Copilot Code Review, OpenAI Codexを利用）

うまくいかなかったこと（限界と落とし穴）

自立型コードエージェントによる実装

Devin、GitHub Copilot、Cursorを使って、実装タスクの自動化を検証しましたが、成功はボイラープレート生成と単純一括修正にほぼ限定されます。その他では、以下のような課題が上がりました。

セッション（会話）が長引くほど生成精度が劣化し、生成コードの採用に至らない。
指示の具体化や前提整理に時間がかかり、人が実装した方が速い場面が多い。

非決定性（出力の揺らぎ）

同一プロンプトでも出力がぶれるため、AIツールで生成したコードの比較や精度評価の収束に難航しました。 AIの「非決定性」問題を認識せず、プロンプトやコンテキストに“おまじない”的な調整やハックに頼った結果、再現性のない成功パターン探しに時間を浪費してしまうことがありました。

コンテキスト忘却

プロンプトが長くなると冒頭・末尾が優先され中盤が抜けやすい（Lost in the Middle問題）。さらに、コンテキストウィンドウ上限を避けるためのコンテキスト圧縮過程で重要事項が脱落。結果として、

ガイドラインを与えても全項目の遵守は期待しづらい。
コードレビューもごく一部の規約しか参照されない。
セッションが長くなるほど残り10〜20%の実装をAIで完遂するのが難しい。
指定外リポジトリへのPR作成、プロンプトに明示した指示の無視が散見される（例:「PRを作成しないで」「プロパティファイルの定義は辞書順で」といった指示が無視される）。

Kotlin×IDEロックイン問題

標準の開発環境は IntelliJ＋GitHub Copilotですが、VS Code版と比べて機能提供の遅れや不具合が目立ち、体験品質に課題が残ります。いっぽうでVS Code系（Copilot in VS Code／Cursor）はKotlinの言語サポートやコードジャンプが不十分で、AIツール導入の移行障壁になっています。結果として、Kotlinの採用により、IntelliJへの事実上のベンダーロックインが生じ、AI活用推進のボトルネックになっていると分かりました。

学んだこと

「ボイラープレートの自動生成」「単純だが広範な一括修正」「要約・逆引き」はAIの得意分野です。ここを主戦場に据えると、費用対効果は安定します。一方で、非決定性と忘却の問題を抑え込めば、AI活用の適用範囲は広がります。プロンプトやコンテキストの小手先の最適化に偏るよりも、静的解析やユニットテストで出力を厳密に検証できる土台の強化に重きを置くべきだと考えます。期待値をコードで固定できれば、エージェントは失敗に一貫して反応し、自己修復ループに乗りやすくなります。

まとめ

AIは「補助輪」です。走り出しを助け、速度を上げ、転びにくくし、学びを加速します。ただし、進むべき方向を決めるのは人間です。できること／できないことをチームで共有し、使いどころを明確にする。こうした地道な運用こそが、いま現場で効いています。次は、この運用を標準化し、対象領域を段階的に拡大していくことが重要だと考えます。