生成AIを導入したのに工数が増加？複雑で冗長なコードが招いたレビュー負荷増加
トヨタ自動車の子会社であるトヨタファイナンシャルサービスの傘下で、モビリティサービスの技術開発を担うKINTOテクノロジーズ。小林氏が担当するMaaSアプリ「my route」は、九州エリアを中心に展開され、リアルタイム運行情報やパーソナライズされたお出かけ情報、デジタルチケット機能などを提供している。
同アプリのAndroid開発を担当する小林氏は、2017年に新卒でSIerに入社後、C言語による組み込み開発からWeb開発を経てモバイルアプリ開発に転身。2023年12月にKINTOテクノロジーズに入社した。
小林氏のチームでも生成AIによるコーディングを積極的に導入している。「私たちのチームは規模が大きく複雑な仕様が多いアプリを担当しています。納期前に割り込み作業が入ることが多く、余裕がなくなりミスが増加することが課題でしたが、生成AIのコーディング導入によって負担が減り、工数削減によって余裕が生まれました」と小林氏は導入効果を語る。
しかし、その一方で新たな問題が浮上した。生成AIが複雑で冗長なコードを生成した結果、レビューが困難になり、結果として工数が増加してしまう逆転現象が生じた。せっかく生成AIでコーディング工数を削減したはずが、レビュー工数の増加によって全体の生産性向上が相殺されてしまったのだ。
複雑な修正がレビューを通してわずか1行に、原因は「コードの意図・背景への理解不足」
小林氏はレビュー負荷増加の要因として「コミュニケーションコストの発生」と「自分が持つ知識以上のコードの出現」を挙げ、それぞれの具体事例を紹介した。
前者の事例は、Androidアプリのボトムシート（画面の下部から上にスライドして表示するUI要素）の実装で発生したトラブルだ。コンテンツのスクロール時に、意図せずボトムシート全体が隠れてしまう不具合に直面した小林氏は、自力での解決を断念し生成AIの力を借りた。
「ボトムシートを実装していて内部のコンテンツのみをスクロールさせたいのにボトムシートが動いてしまう。どう解決すればよいか」という質問に対し、AIは複雑な処理を使った解決策を提示した。
動作確認で問題なく動いたため、小林氏はそのままプルリクエストを作成したが、レビュアーとの間で長いやり取りが発生した。レビュアーは「このような問題はAndroid開発でよくあることなので、ネット上にも同様の事象がありますが、確認されましたか」と指摘。最終的に判明したのは、わずか1行の修正で済む内容だったということだ。
小林氏は「検索すれば答えは見つかったはずですが、私は生成AIに依存するばかりで検索が不十分でした」と振り返る。
後者の事例は、レビュアーになったときに発生した問題だ。生成AIが出力する「やや複雑で、初見では読み解きにくい構造」や「見慣れないAPIや文法が使われている」コードに直面した際、「このコードはどのような意図なのだろうか」「何からチェックすればよいのか全く見えない」という状態になり、結果として見落としが発生してしまった。
小林氏は両事例の共通点として「コードの意図・背景への理解不足」を指摘し、「レビューは動作するかどうかだけでなく、なぜそう書いたのかが問われる場です。AIでコードを書くことは珍しいことではなくなりましたが、レビューの場ではAIが実装したコードに対して、人間が実装したコードと同様にその意図と背景を理解することは必須です」と注意を促した。
レビュー負荷軽減へ、生成AIを「説明補助ツール」として活用
「コードの意図・背景への理解不足」を原因としたレビューの課題に対し、小林氏のチームが採用したのは「AIの説明能力を活用することでレビューしやすいプルリクエストを目指す」アプローチだ。
小林氏はレビュー時の課題を「AIでコードは書けても、何を理解したのかは伝えてくれません。だからこそ、人間側がレビュアーに意図を伝える仕組みをうまく作る必要があります」と分析する。
そこで同チームは、生成AIを「他者と協力するための説明補助ツール」として活用するために、ターミナル内で動作するエージェント型コーディングツール「Claude Code」と、GitHub Actionsワークフロー内でClaude Codeを実行可能にする「Claude Code Action」を導入した。
Claude Code Actionには以下の観点でチェック作業を指示している。「潜在的なバグがないか」「冗長な構造や不必要な分岐がないか」「コーディングガイドラインに違反していないか」。特にプロジェクト固有のガイドラインがある場合、それに基づいた違反箇所の洗い出しも可能だという。
重要なのは、AIがレビューを「代行する」のではなく「補助する」という考え方だ。小林氏は「レビューの経験が浅くても、AIの指摘をきっかけにコードの疑問点を絞り込むことができます。ガイドライン違反を機械的に洗い出すことで、レビューの観点漏れを防ぐことができます」と効果を説明する。
運用の流れは、まずClaude Code Actionがコードの内容を要約する。レビュアーはこの要約を読むことで、AIが生成した複雑なコードでも構造と意図の大枠を素早く把握することができる。一方、実装者は要約を確認し、「自分の意図とずれていないか」をチェックする。ずれがあれば補足コメントをプルリクエストに添える。
この運用により、レビュアーは「このページを参考にしましたか」「この機能は、別の場所に似た実装がありますよ」など、より具体的で建設的なフィードバックに時間を使えるようになった。
先に挙げたボトムシートの不具合修正の事例にあてはめてみよう。Claude Code Actionに実装を要約してもらい、レビュアーはその要約を見て実装の目的を把握する。それに対して実装者が「この仕様・機能を実現するために、この実装を行いました。私はこのような理解をしています」と補足することで、レビュアーは実装者の理解度を測ることができる。これにより、正解のコードに到達するまでの長いやり取りを削減し、コミュニケーションコストの削減につなげることができるのだ。
また、GitHub Actionsにより自動化ワークフローにAIレビュー機能を組み込み、コードの変更に対して自動的かつ継続的にレビューを実行する仕組みも構築している。これにより、新しいコミットが追加された際も差分のみを効率的に再評価することで、開発フローを阻害せずにレビューを支援できる。
レビュー観点は「コード品質とベストプラクティス」「アーキテクチャ準拠性」「セキュリティとパフォーマンス」「レビュー出力形式」の4項目に大別される。これらの観点から「ガイドライン違反を機械的に洗い出すことで、レビューの観点漏れを防ぐことができます」と、小林氏は自動化ワークフローへの導入効果を説明する。
一方、小林氏がレビュー負荷増加の要因として挙げた「知識以上のコードの出現」は、要約機能で対応している。AIが生成する複雑な構造のコードを要約して可視化することで、チーム全体のレビュー能力の底上げを図っている。
出力は具体的で実行可能なフィードバックとコードの改善提案を含み、かつ日本語版と英語版の詳細レビューを両方提供する形式で統一している。my routeの開発は多国籍チームのため、英語版も出力しているのだ。
小林氏は「この取り組みを始めたばかりで、発展途上」としながらも、既に手応えを感じているという。「レビューの負荷を減らして工数を削減することも、生産性向上につながると考えています」とその意義を改めて強調した。
同時に、根本的な解決策として「よほど特殊な作業環境でない場合は、どの現場でも実施されている取り組みだと思いますし、率直に申し上げて、レビュー負荷を下げるには、そもそも実装で最善を尽くすことに帰結すると思います」と話し、講演を締めくくった。
