はじめに：大規模プロジェクト復帰とレビュー負荷の課題
こんにちは、DevRelの大熊です。本記事では、育休復帰直後という制約の大きい状況の中で、AIを活用したコードレビューの仕組みを構築し、週6時間の業務削減とレビュー品質の向上を同時に実現した事例を紹介します。
お話を伺ったのは、リサーチプラットフォーム「LINE Surveys」の開発を担うソフトウェアエンジニア、上土井涼馬です。約1年の育休を経て復帰した先に待っていたのは、歴史が長く、 レガシーコードや複雑なSQL（Structured Query Language）が多い大規模なプロジェクト。育児と仕事を両立しながら成果を出し続けるという、大きなチャレンジでした。
そんな状況の中、Claude Code、Model Context Protocol（以下、MCP）、NotebookLMなどを組み合わせて「AIレビュー」の仕組みを構築。週あたり約6時間の業務効率化に加え、レビュー品質の向上も実現したといいます。復帰後の不安と向き合いながら、どのようにしてこのワークフローを作り上げていったのか。本記事では、その過程と工夫を詳しく掘り下げていきます。
復帰直後に直面した3つの課題
上土井は、約1年の育休を経て職場に復帰したタイミングで、LINE Surveysの開発チームに新たにアサインされました。このプロジェクトはドメインが非常に広く、長年の開発によって蓄積された情報量も膨大です。復帰直後から「できるだけ早くキャッチアップしなければならない」という強い焦りを感じていたといいます。
さらに、不安に拍車をかけたのが、育休中に進んでいた現場でのAI活用の加速でした。最初に語ってくれたのは、復帰直後に直面した3つの大きな不安です。
1つ目は、約1年にわたる技術的なブランクでした。育休前は、AIがようやく開発現場に浸透し始めた段階でしたが、その間にAIの進化は急速に進み、ツールやワークフローも大きく変化していました。「復帰したとき、現場がまったく別の世界になっているのではないか」「自分だけが取り残されているのではないか」という不安を感じていたといいます。
2つ目は、大規模プロジェクトへのアサイン です。LINE Surveysは背景となる仕様や前提条件が多く、これまで体験した中で最も規模の大きなプロジェクトでした。時短勤務という制約もあり、限られた時間の中で十分に理解し、戦力として貢献できるのかに不安を抱えていました。
3つ目は、育児との両立でした。家庭でも多くのエネルギーを割く必要がある中で、仕事でも成果を出し続けられるのか。その点についても、大きな不安を抱えていたと振り返ります。
レビュー前の仕様理解が最大のボトルネックだった
復帰直後、特に大きな負担となっていたのがレビュー前の仕様理解でした。長年にわたって積み重ねられたレガシーコードは複雑で、100行を超える巨大なSQLや入り組んだ条件分岐が当たり前のように存在しています。設計書を読んでも当時の意図が読み取れないことも多く、PRの背景説明にもばらつきがありました。
さらに、ドキュメントはJiraやConfluenceなど複数の場所に分散しており、必要な情報にたどり着くまでに多くの時間を要しました。「何を見ればいいのかわからない」という状態が続き、精神的な負担も非常に大きかったといいます。その結果、自信を持てないままレビューを続けてしまう時期もありました。
AI駆動開発ワークショップで見えた「AIレビュー」の可能性
そんな状況を打開するきっかけとなったのが、AI駆動開発をハンズオン形式で体験できる社内勉強会 Orchestration Development Workshop（※1）でした。
この勉強会で、Claude Code Commandsを使ったテンプレート処理を体験したことで、「この仕組みはコードレビューにも応用できるのではないか」という手応えを感じたといいます。さらに、MCPサーバー（※2）を介してJiraやConfluenceと連携し、必要な情報にAIがアクセスできるワークフローを知ったことで、AIレビューの具体的なイメージが一気に明確になりました。
「PRのURLを渡すだけで、背景情報まで含めたレビューができるはずだ」。そう確信し、思い立ってすぐにPoC（Proof of Concept）に取り組み始めました。
※1 LINEヤフーで2025年10月より始動した、実践型のAI駆動開発ワークショップのこと。生成AIや非生成AIの活用が各現場で進む一方で、「AIを業務プロセスにどう組み込むか」という課題に向き合うため、複数のAIやツールを連携（Orchestration）させ、人とAIが協働する開発スタイルを体験的に学ぶ場として設計されています。
※2 MCPは、AIがGitHubやJira、Confluenceなどの外部システムにアクセスするための仕組み。これにより、PRのURLを渡すだけで、関連する設計書やチケット情報まで含めたコンテキストをAIに与えることが可能になります。
AIレビューの仕組み：PR URLからレビューサマリを生成する2ステップ
上土井が構築したAIレビューの仕組みは、大きく分けて2つのステップで成り立っています。
まず1つ目が、レビューに必要な情報を自動で収集する仕組みです。PRのURLをAIコマンドに渡すと、GitHub MCPやGitHub CLI（gh）コマンドを通じてPRの情報を取得します。さらに、PRサマリに含まれるJiraやConfluenceのリンクをたどり関連情報を自動で収集することで、レビューに必要な背景情報を一式そろえる流れを作りました。
この仕組みによって、これまで多くの時間を費やしていた「レビュー前に情報を探し集める作業」がほぼ不要になり、レビューを始める前の準備コストは実質ゼロに近づいたといいます。
2つ目が、テンプレートを活用したレビュー生成です。あらかじめ用意したテンプレートに基づいて、AIがMarkdown形式でレビューサマリを作成します。このテンプレートには、実装ガイドラインやレビュー観点に加え、ERD（Entity-Relationship Diagram）やシーケンス図、ステート遷移や業務フローの解説といった要素も盛り込まれており、アウトプットの品質が一定に保たれるよう工夫されています。
こうしてAIが生成するのは、単なるコードの要約ではありません。背景から仕様、図解、指摘ポイントまでが体系的に整理された「解説ドキュメント」としてまとめられます。図解とともに全体像を把握できるため、レビューを始める段階で、すでに理解がかなり進んだ状態になります。
生成されるAIレビューサマリは、単なるコード要約ではなく、仕様・設計・データモデル・指摘事項までを網羅したドキュメントになります。以下は、架空の機能と架空のPRに対して作成されたレビューサマリの一例です。
特に注目してほしいポイントは次の3点です。
- 冒頭でPRの背景・目的が整理されている点
- アーキテクチャ図・ERD・シーケンスが自動で補完されている点
- Must/Should Fix といったレビュー観点が構造化されている点
NotebookLMを併用した背景理解の深化
さらに、このAIが生成したサマリを起点に、必要に応じてNotebookLMも併用しながら背景理解を深めたうえで、実際のコードレビューに進むフローを採用しています。
Confluenceなどの関連ドキュメントをNotebookLMに読み込める形式に変換し、チャット形式で質問できるようにすることで、実ドキュメントを根拠とした回答を得られるようにしているとのことです。
「まるでプロジェクト専用のドメインエキスパートが手元にいるような感覚です」と語る言葉からも、この補助的な使い方が理解を大きく支えていることが伝わってきます。
テンプレート化とMCP連携で再現性を担保
AIは非決定論的な挙動をとるため、テンプレートを用意しないまま使うと、どうしてもアウトプットにばらつきが生まれてしまいます。個人利用であれば許容できたとしても、チームの開発プロセスに組み込むには、誰が使っても一定の品質が担保されることが不可欠です。
そこで、出力の再現 性を高めるためにレビュー内容のテンプレート化を進めました。この取り組みによって、出力フォーマットのばらつきやレビュー観点の抜け漏れといった課題が整理され、「PRサマリにJira／ConfluenceのURLさえあればレビューできる」という状態を実現しています。
導入効果：どこで週6時間が削減されたのか
削減された「週6時間」という数字は体感値ではあるものの、その内訳は明確です。従来は、PRを1件レビューするたびに、設計書や企画書、その他関連資料を収集して、そこから仕様を理解する必要があるため、コードレビューの前準備だけでも1時間かかることもありました。しかし、AIによって事前に背景情報や仕様が整理されるようになったことで、この工程は最低でも30分短縮されています。
1日に平均して3件のレビューを担当し、週4日勤務する（※3）と仮定すると、1.5時間×4日で、合計すると週6時間の削減になります。さらに、レビュー作業を並行して進められるようになったことで、実際の業務における体感的な負担軽減は、この数字以上に大きかったといいます。
※3 育児や介護を担う社員が、家族のサポートをしながらでも安心して働けるよう、働き方の選択肢を広げる制度の「えらべる勤務制度」を利用し、土日の休日に加えて、週1日休暇を取得しているため。
レビューの「深さ」と「幅」の変化
AIの導入によって、レビューには「深さ」と「幅」の両面で変化が生まれました。以前はドメイン理解が十分でないまま、コード単体の観点にとどまったレビューになりがち でしたが、現在ではステータス遷移や業務フローとの整合性といった、より上位の視点から指摘できるようになっています。
また、人間のレビューでは見落としがちなバリデーションの抜けや境界条件の未処理といったポイントを、AIが補完してくれるようになり、レビュー全体としての抜け漏れが大きく減りました。
AI導入による失敗経験とその学び
一方で、AIを活用する中での失敗も経験しています。AIの指摘を受けて自らコードを確認し、その内容に納得したうえでレビューコメントを残したものの、実際にはその実装は正しく、テストも問題なく通っていた、というケースがありました。
この経験について、「AIの見解をそのまま信じたというよりも、自分自身がその見立てに引っ張られてしまった感覚でした」と振り返ります。この出来事をきっかけに、AIの出力を無条件に受け入れるのではなく、「なぜその判断に至ったのか」という根拠を問い直す姿勢を強く意識するようになったそうです。
チームへの展開とプロセス化の工夫
AIレビューの取り組みをチーム内で共有したところ、反応は非常に前向きなものでした。PoCの結果を見たメンバーからは「すぐに導入したい」という声が上がり、実際に使ってみたメンバーからも「ここまで見てくれるとは思わなかった」といった驚きの感想が寄せられました。
一方で、継続的な運用という観点では、全員が同じAIリソースを利用できるわけではないといった課題も見えてきました。現在は、誰でも利用できるAIツールを前提にプロセスを再設計し、試行錯誤を重ねています。
時間に制約のある人へ：まずは“AIファースト”で
育休復帰や時短勤務など、限られた時間の中でAIを活用したい人に向けて、上土井が強調していたのは「まずはAIファーストで考えること」でした。
よくあるつまずきとして挙げられたのが、「AIがすべて答えてくれるはずだ」と思い込んでしまうことです。実際には、適切なプロンプトや十分な情報ソースを与えなければ、AIの力を引き出すことはできません。その結果、思ったような回答が得られず、「AIは使えない」と感じてしまうケースも少なくないといいます。
復帰直後の上土井自身も、最初から効率よく使えていたわけではありません。むしろ、あえて多くの作業をAIに任せてみることを意識し、試行錯誤を重ねる中で、どのようなコンテキストを渡すと良いアウトプットが得られるのかを少しずつ掴んでいきました。
「深く考えすぎず、まずは試してみること。その積み重ねこそが、AI活用への一番の近道だと考えています」
時間的な制約があるからこそ、完璧を目指すのではなく、小さく試しながらAIとの付き合い方を見つけていく。その姿勢が、結果として大きな成果につながっていったことが伝わってきます。
おわりに：AIはコードレビューの“増幅器”になる
AI導入の効果は、作業時間の短縮や品質向上だけにとどまりません。レガシーコードや複雑なSQLに対しても、AIが図解を交えながら説明してくれることで、理解にかかる負荷が大 きく軽減されました。また、要件定義や設計といった上流工程においても、ドメインの背景や前提条件を補足してくれることで、意思決定の精度が高まったといいます。
さらに、難解で手をつけにくい課題に対しても、AIが問題を細かいタスクへと分解し、具体的なToDoとして提示してくれる点は大きな助けになっていました。こうしたサポートによって、技術的な理解だけでなく、心理的な負担も大きく軽減されたと振り返ります。
「暗闇の中に光が差し込んだような感覚でした。正直、AIがなければ復帰してから軌道に乗るまで、数年はかかっていたと思います」
最後に、こんなメッセージを届けてくれました。
「もし育休復帰直後の自分にひと言かけられるなら、『全部を理解しなくていい。AIがいるから大丈夫』と伝えたいです」
AIは「仕事を奪う存在」ではなく、人間の強みを最大化し、弱みを補い、機会を広げる“増幅器”。制約のある環境の中でも前に進む力を与えてくれる存在であることを、実感させてくれる事例でした。
「LINEヤフー Development with Agents Meetup #2」開催します
本記事で取材した上土井が登壇するMeetupを開催します。記事には書ききれなかったリアルな体験談や、ここだけの話も飛び出すかもしれません。「もう少し深掘りしたい」「直接聞いてみたい」という方、ぜひお気軽にご 参加ください。
- 開催日時：2月24日（火）19:00-22:00
- 開催形式：オフライン（JRJP博多ビル）
- 言語：日本語
- 公式サイト：https://lycorptech-fukuoka.connpass.com/event/379537
