AI Coding Meetup #2 を開催しました #aicoding

こんにちは。バクラク事業部エンジニアの omori (@onsd_) です。

2025年6月12日、「AI Coding Meetup #2」を「Cline / Roo Code / Claude Code の活用事例」をテーマにオンライン・オフラインのハイブリッド形式で開催しました。

この記事では、イベントレポートとして発表内容やパネルディスカッションについてご紹介します。

layerx.connpass.com

AI Coding Meetup とは？

AI Codingツールの個人利用は急速に広がっていますが、それを一歩進めたチームや組織での実践的な導入・活用となると、その知見はまだ十分に共有されていません。

明確な成功パターンがない今だからこそ、組織でのAI活用に挑む方々が試行錯誤の過程や直面した課題をオープンに共有し、共に次のステップを探る場が必要だと考え、本ミートアップを企画しました。

また、LayerXの行動指針 Bet AI と 徳 の観点から、このイベントを通じて AI Coding の裾野を広げていきたいと思っています。

今回のテーマ：Cline / Roo Code / Claude Codeの活用事例

GitHub Copilot、Cline、Roo Codeなどのツールに関するAI Codingのノウハウは、個人開発者向けのコミュニティでは多く共有されており、勉強会などで幅広く議題にあがるようになりました。実際、弊社でも以前「 AI Coding Meetup #1 」を開催したところ、大変盛況でした。

AI Coding Meetup #1 の開催レポートは @serima が書いているのでそちらも御覧ください。 tech.layerx.co.jp

しかし、チーム開発や大規模なコードベースや新規開発など、それぞれの用途におけるCline, Roo Codeなどに限定したより実践的な事例はまだまだ多くありません。

そこで今回のイベントでは企業の第一線で活躍するエンジニアたちが、Cline/ Roo Codeに絞って、実際のチーム開発やプロダクション環境でのより実践的な活用事例、知見を共有することで個人の経験を組織全体で活かせるようなベストプラクティスの確立を目指したいと考えています。

実は、イベント開催決定時点では Cline / Roo Code についてのイベントだったのですが、昨今の Claude Code の急激な盛り上がりをうけて急遽 Claude Code も対象になりました。登壇内容もClaude Code にフォーカスした内容があったりと、AI Coding Agent の移り変わりの速さを実感することができました。

発表内容

今回は３名の方々にご登壇いただきました。当日の登壇内容について簡単にご紹介します。

バクラクのモノレポにおける AI Coding のための環境整備と {Roo,Claude} Code活用事例

発表者：株式会社LayerX ソフトウェアエンジニア upamune さん (X: @upamune)

発表ではまずモノレポで AI Coding をするうえでの特有の課題とそれらの解決策が説明されました。発表内で触れられた自作ツールは OSS として公開されているので、皆さんの環境でも試していただけると思います。

また、登壇タイトルにもある {Roo,Claude} Code の活用事例だけでなく、AI Coding Agent 一般の使い方や Tips も多く含まれていて、明日から使える知識になりました。

登壇資料

speakerdeck.com

AIコーディング新時代を生き残るための試行錯誤

発表者: 株式会社ジェイテックジャパン CTO 高丘知央さん (X: @tomohisa)

前半ではここ数ヶ月のAIコーディングの進歩について解説されたあと、後半は Claude Code とどう付き合っていくのかについてお話がありました。特に、AIはシニアの力になるだけではなく若手の伸びしろをブーストすることもできるというところで、「熱意と探究心」がAIコーディング新時代でも重要になるんだと再確認できました。

tomohisa さんはアメリカ在住ということで、現地時間の朝３時からご登壇いただきました。朝早い中のご登壇本当にありがとうございました。

登壇資料

speakerdeck.com

Claude Code活用において、メンタルモデルを変える必要がある

発表者: 株式会社Algomatic AIエンジニア erukiti さん (X: @erukiti)

Claude Code を活用するにあたって、従量課金ではなく定額使い放題であるという特性を正しく認識し、思考の前提を変える必要がある、というお話がされました。 Cline / Roo Code といった既存の Coding Agent との比較から、新しいメンタルモデルへの流れがとてもわかりやすく、腑に落ちるものがありました。

erukiti さんはご体調が優れなかったところ、リモートでご登壇いただきました。ありがとうございました。

登壇資料

speakerdeck.com

パネルディスカッション

発表の後、登壇者の方々を前に招いて30分ほどパネルディスカッションを行いました。

erukiti さんのご体調が優れないとのことで、急遽現地参加いただいていた t_wada さん(X: @t_wada) にパネラーとしてご登壇いただきました。

🎙️パネルディスカッションが始まりました！

急遽代打でご登壇いただいた @t_wada さん、LayerX @upamune、ジェイテックジャパン CTO @tomohisa の3名がパネラー、モデレーターは LayerX の @onsd_ がつとめています！ #aicoding pic.twitter.com/kpZ4I38pNG
— LayerX Tech (@LayerX_tech) June 12, 2025

質問は当日 slido を使って参加者の方から募り、投票数が上位のものから質問しました。

ここでは質問と回答を抜粋してご紹介します。

Q. 新しいモデルが出たときのコーディングエージェントの精度評価はどうしていますか？

tomohisa さんの回答: いろいろ試したうえでの「個人の感覚」を重視する
- 以前はローカルで動くモデルも試していたが、オンラインの高性能なモデルが結局優れていた。
- 新しいモデルが出たらまず動かしてみて、既存のモデルとどれくらい違うかを試す。
- 最終的には色々試したうえでの「自分の感覚」を信じてメインで使うモデルを決めている。
- 現在は Claude を使いつつ、他のモデルも時々試している。
upamune さん: 正式な評価はせず「社内外の口コミ」を参考にすることが多い
- 「精度評価」のようなきっちりとした評価は特に実施してない。
- 特に社外のツイートで誰かが新しいモデルを試してみて、「良かった」という内容が共有されたらとりあえず試してみている
t_wada さん: プロンプトを記録しておき、モデルを変えて再実行することで比較・観察する
- 自身のプロダクト開発で使ったプロンプトをすべて Git で記録・保存している。
- 新しいモデルが出たときの評価方法は、その保存しているプロンプトを新しいモデルに投げてみて出力がどう変わるか比較して楽しむというもの。

Q. LLMがコードを書いてくれるようになり、コードレビューがブロッカーになることが増えたと思いますが、どのようなアプローチを考えていますか？

tomohisa さんの回答：テストによる「振る舞い」の確認を重視する
- LLMにコードレビューをさせても、現状では表面的で浅い部分しか見てくれない。
- そのため、人間がコードを細かく読むのではなく、テストで振る舞いを保証するアプローチが重要になる。
- 具体的には、Playwright のようなE2Eテストを LLM に書かせることで、コードの中身を精査する代わりに、アプリケーションが意図通りに動くかどうか（振る舞い）を確認する。これにより、レビューの負荷を下げていく。
upamune さんの回答：AIレビューツールを積極的に評価・導入する
- コードレビューがボトルネックになるというのは、まさに直面している課題だと認識している。
- この課題を解決するため、CodeRabbit のようなAIによるコードレビュー支援サービス・ツールに注目している。
- どのツールが効果的かを見極めるため、チームで様々なツールを試す「コードレビューツール天下一武道会」のような取り組みを計画している。
  - AIが生成したコードを、別のAIにレビューさせることで人間の負荷を軽減しようと試みている。
t_wada さんの回答：「振る舞いの変更」と「構造の変更」を分離する
- コードレビューのボトルネック化はAI登場以前からの課題であり、本質は変わらない。
- 鍵となるのは、ケント・ベックの著書『Tidy First?』でも提唱されている「振る舞いの変更」と「構造の変更（リファクタリング）」をプルリクエストの段階で明確に分離することでコードレビューがボトルネックになることを防ぐこと。
  - 構造の変更: 振る舞いが変わらない安全な変更。これはAIによる自動レビューで対応し、並列でどんどんマージできる。
  - 振る舞いの変更: 機能が変わる重要な変更。これだけを人間が集中してレビューする。
- AIにまず「構造の変更」を徹底させることで、人間がレビューすべき「振る舞いの変更」の差分（diff）が小さくなり、レビューの認知負荷が劇的に下がる。この分離こそがボトルネック解消の鍵となる。