こんにちは。
ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。
現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。
GitHub Copilot や Claude Code など、生成AIを活用した開発支援ツールが次々と登場し、日常的なワークフローに組み込まれつつあります。
生成AIを開発フローやプロダクトに組み込んだ事例を耳にする機会も増えました。弊社も例に漏れず、多方面で生成AIを継続的に組み込んでいます。
一方で「思ったような効果が出なかった」「むしろ生産性が下がったのでやめた」「効果の出る使い方がわからなかった」といった声も確かに存在します。
生成AIを導入したものの、思っていたような結果が出なかったと感じるとき、原因はAIではなく環境と人にあることが多いです。そこで今回は、その原因と解決策を紹介します。
それでは見ていきましょう！
プロンプトがわからない
生成AIに依頼する内容が思い浮かばない。Vibe Codingに入るきっかけがわからない。長文を一気に渡して生成AIが混乱する。要件が頭の中に留まり言語化できない。要求がイシューやチケットに分解されず認知負荷が高止まりしている。このような経験をした読者の方も少なくないと思います。
根本的な原因を突き詰めると 人間が問題を十分に分解・言語化できていない ことが大きな要因となっています。生成AIは整理の補助にはなりますが、曖昧な思考を自動で明確に構造化する“魔法”ではありません。
タスク分解
最初の一歩はタスク分解です。「何を / なぜ / どうやって」を説明できる粒度まで言語化できたら、初めて生成AIに委ねる土台が整います。
いきなり生成AIに依頼するのではなく、まずは依頼主が理解することが重要です。
これがなぜ重要かというと、依頼主が理解していないタスクを生成AIに依頼しても、期待した結果が出力されることも、出力された内容が正しいかどうか判断することもできないからです。
生成AIに依頼する内容を自分自身が理解できているのか、内容そのものの認識や方向性が間違っていないかを判断するためにも、まずはIssue等に書き出してタスクリスト化することをおすすめします。
タスク分解については過去記事でも紹介しているので、ぜひ読んでみてください。
レビュー疲れ
レビュー疲れの主な要因の1つは 人間が理解しづらいPull requestを大量に作成している ことに起因します。
ジュニアエンジニアが生成AIを使って出力したコードを理解せず、そのままレビュー依頼を出してリードクラスのエンジニアのレビュー負担が増加している。というケースをよく耳にしますし、実際にこの目で見たこともあります。
つまり質の低いPull requestが大量に作成され、そのレビューに追われているという状況なのです。
これは AIを使っている というよりも、AIに使われている 状態と呼ぶのが近いかもしれません。
セルフレビュー
生成AIが出力したコードを理解した上でレビュー依頼を出すことが大事です。ここで重要なのは、読むだけではなく読み解いて理解するということです。
Pull requestの作成者自身が説明できない内容のままでレビュー依頼を出すのは、基本的にNGであるはずです。これは生成AIの有無に関わらず、普遍的な価値観といえます。
Pull requestをセルフレビューして、解説や説明が必要なのであれば、公式ドキュメントなどの一次情報を参照して、理解して解説するレビューコメントを残しましょう。これだけでレビューの負担は下がります。
生成AIが出力したコードの責任は人間にあります。 出力してもらったコードに自分自身が責任を持ちましょう。
Pull requestの粒度
要件をすべて同じPull request内で実現しようとしない方が良いです。
同じPull request内で多くの事を実現しようとすると、 生成AIが一度に認知すべきコードの範囲が広がってしまい、出力されるコードの質が落ちます。
また、 一度に広い範囲のコードを変更することで、レビューの負担も上がってしまいます。 仮に生成AIにレビューしてもらったとしても、コンテキストが大きくなるので精度が落ちてしまいます。
適切なPull requestの粒度を維持するためには、前述したタスク分解が重要となってきます。
要件を実現するために必要なタスクに分解して、そのタスクごとに生成AIにコード生成してもらいPull requestを作成することで、出力するコードの質だけでなくレビューの質にも繋がってくるのです。
AIに使われないためにも、タスク分解とPull requestの粒度の考え方は今後ますます重要となってくるでしょう。
Pull requestの粒度については過去記事でも紹介しているので、ぜひ読んでみてください。
思ったようなコードが生成されない
「出力したコードの命名や規則がバラバラ」「ルールから逸脱したコードが出力される」「既存コードが壊れてしまう」このようなコードを生成AIが出力する背景には 生成AIが迷ってしまう環境 があります。
生成AIが迷わないように生成AIフレンドリーな開発環境を整えましょう。
ガードレール（迷わせない環境）整備
不要コードを削除
生成AIは現時点のリポジトリ情報を根拠に推論することがあります。
不要なコードが残っていることで、生成AIが余計な内容まで学習してしまうことに繋がっています。
不要コードは存在そのものがノイズと化します。まずは不要なコードやモジュールを削除しましょう。
統一したコーディング規約
Google Style Guide 等を参考にして、統一したコーディング規約をルール化しましょう。
コードのルールが一貫していると、生成AIはそのルールのみを学習するため迷いにくくなります。
その結果、出力されるコードにも一貫性が生まれ、質の高いコード生成に繋がります。
ドキュメント
実装コードだけではなく、ドキュメントも重要です。
READMEやカスタムインストラクションだけに留まらず、docコメントやAPIドキュメント、型定義ファイルなどは生成AIがコードの意図を理解するために非常に有用です。
テストコード
テストコードは生成AIが仕様を把握するための情報源になるだけでなく、暴走しないためのガードレールの役割も担います。
生成AIが出力したコードが原因で既存のテストコードが失敗した場合、エラーメッセージをチェックして何がどう間違っていたのかを生成AIが学習できます。
その結果、テストコードのエラーの内容を元に生成AIが実装、テストコードを修正できます。この時、テストが落ちた原因が実装コードにあるのか、テストコードにあるのかの判断を間違わないようにするのがポイントです。
このように 思ったようなコードが出力されない原因は、そもそも生成AIが迷ってしまうようなコードの質、環境にあります。 生成AIが出力するコードの質は現時点でのコードの質と比例するのです。
ガードレール整備については過去記事でも紹介しているので、ぜひ読んでみてください。
生成AIと開発生産性、どちらが先か？
これまで見てきた現場で、生成AIを導入して効果が出ていないケースの原因は、 生成AIを活用できていない のではなく 生成AIを活用する準備ができていない というものでした。
事前準備や環境、ガードレールの整備などの日々の小さな積み重ねが重要です。まずは 生成AIと自然に協働できるAIフレンドリーな環境 を目指しましょう。
結局のところ、やるべきことは変わらないのです。 人間の開発生産性を上げることが、生成AIフレンドリーな環境、ガードレール整備に繋がります。
生成AIで開発生産性は上がりません。高い開発生産性をさらに上のレベルへ引き上げるものが生成AIなのです。
生成AIを活用して効果を出したいのであれば、まずは人間の開発生産性に投資することをおすすめします。その結果、新メンバーとして生成AIを招待して活躍してもらえる環境が整うのです。
まとめ
今回の内容は先日開催した D-Plus Fukuoka でも紹介させてもらいました。
こちらがその時の資料となります。ぜひ参考にしてみてください。
また、 11月13日(木)に福岡で Findy AI Meetup の開催が決定 しました。
今回は YAPC::Fukuoka の前日の開催 です。県外からの参加者のみなさん、前日入りしてこちらへの参加もぜひ検討ください。
現在、ファインディでは一緒に働くメンバーを募集中です。
興味がある方はこちらから ↓
herp.careers
