11/13にCO-LAB Tech Night vol.5 事業を成長させるサービス開発×生成AIのリアルでLT登壇させていただきました。
内容が多くなりすぎてどう考えても発表時間が足りず削りまくったので、補足記事を書くことにしました。
AI導入で困っている人の助けになればと思います。
LT内容の補足
スライドの内容を前提にしているので合わせて見ていただければ幸いです。
今日お話すること
昨今、AIで〇〇をたった何時間で作成して効率はn倍でした！みたいな話はよく聞くようになりました。
実際私も前回はPHPカンファレンス関西で使った景品抽選アプリをVibe Codingで作成した話をしました。
しかし、ゼロから作るのは早くても実際に会社のプロダクト開発でn倍速で開発できるようになるかというとそんな事はなく、
むしろうまく開発効率上がらないとさえ感じている人も多いかと思います。
今回は実際に既存の巨大サービスにAI開発をどう取り入れていったのかという話をさせていただきました。
前提: なんのAI使ってるの？
話し足りなかったところその1です。
弊社ではGitHub Copilotから始まり、Claude Codeなど色々なAIツールを試して来ています。
チームにより採用しているツールは若干異なったりするのですが、私がメインで携わっているチームではCursorを利用しています。
理由として、AIツールはまだまだ次から次へと新しいものが出て来ますが、
プロンプトなどの設定がツール固有なので、しっかり使っていればいるほどちゃんと乗り換えようと思うと意外と乗り換えコストがかかります。
現状AIツールの性能はエージェントより基盤モデルの影響の方が大きいので、
ツールはモデルの縛りが少ないCursorに固定してしまって、いいモデルが出たらすぐ乗り換えていくことでお手軽に最先端のモデルの恩恵を受ける方針にしています。
もちろん、ステージが変わるような画期的なAIエージェントが出れば採用を検討しますが、AIエージェントはモデルより改善しやすいので大体はほかもすぐ追従すると思います。
実際にGPT-5にもすぐ切り替えて生成されるコード品質は上がりましたし、
今ではCursorにマルチエージェント機能がついたのでモデル比較なんかも簡単にやれるようになりました。
ただしCursorはAIエージェントとしては優秀なのですがエディタとしてはVSCodeのフォークです。
私たちがバックエンド開発でメインで使っているphpの場合、VSCodeとIntelliJ系のIDEであるphpstormでは開発体験にかなり差があります。
そのためCursorはあくまでAIエージェントとしての利用にとどめ、
AIが出してきたコードを手で変更するときなどは、静的解析やファジーではない確実な補完に優れているphpstormを使う形にしています。
ファジーではないというのは結構重要で、AIの進化で少なくなったとはいえ大文字小文字のミスなどをAIはやらかします。
なのでちゃんとコード品質を維持する場合、この定数名大文字小文字ミスってないよな、という確認が必要で結果手間がかかることもあります。
実際AIが実装した部分で、ローカル環境はMacだからファイル名の大文字小文字が間違っていても動いたけどサーバーに上げるとLinux系なので大文字小文字の違いで動かずエラーになったというケースもありました。
その点機械的な補完であればサジェストされた値を使った時点で表記揺れはなく、namespaceの指定なども漏れなくやってくれるので安心してコードを採用できます。
AIが補完できていない部分も静的解析で波線で強調表示してくれるので問題に気づけたり、様々な恩恵があるのでエディタを統一したいけれど両方使う方が効率がいいなというのが現在の判断です。
ちなみにphpstormで使えるAIとしてAI AssistantやWindsurfプラグインなども試しましたが、これらは使い物にならないという判断でやはりCursorを手放すことも難しいです。
ちなみにモデルは現状GPT-5が頭一つ抜けている印象です。
難解な実装の精度が高いのはもちろん、AIはコードの付け足しでなんとかしようとしてくることが多いですが、GPT-5は既存箇所を適切に修正して行数を抑えてくれたりもします。行数が爆発的に増えるとコード品質はすぐ低下してAIの精度も下がるのでこれはかなり大きい差です。
私たちが直面した壁
AIがレガシーも増幅する
こちらはスライド記載の通りであまり補足はありません。
ちゃんとto-beをDocコメントやルールなどで示すことで(GPT-5なら)かなり改善されます。
とはいえ周りが全部レガシーコード一色で並列的なコードを一行いれるだけならレガシーコードで記載されたりはします。
その場合でも一回指示をいれると周りも一緒に書き換えてくれます。
メンバー間のAIスキル格差
顕在化しにくい割に対応に時間がかかるので難しいトピックです。
ペアプロやモブプロの重要性はAIにより上がっていると感じます。
それぞれペアを組んで相手が実装するのを1時間手伝う、くらいからでもいいので早めに始めるとよいでしょう。
輪読会も割とよいです。技術について話して認識をあわせる時間になるのでレビューの効率化にもつながります。
AI出力を改善するためにコード品質は上げるに越したことはないので、サクッと読めるリーダブルコードから輪読会を始めるのがおすすめです。
私たちはリーダブルコードから初めて自動テストの本など色々読み進めています。
隔週開催1時間で、あらかじめ決めた順番で事前に読んで発表をします。ちなみにリーダブルコードは3回に分かれたので3人が順番に読んだ形になります。
とある賛否両論ある有名な本を読んだときは「これは取り入れたいね」「ここはちょっと思想強くてうちとは毛色が違うね」というように議論が活発になりました。メンバー間の認識が合って開発の方向性が揃っていくと感じます。
AIに仕様背景が届かない（暗黙知）
Project as Codeは重要です。コードを書くために必要な情報はなるべくリポジトリ内に入れましょう。
補足としては、弊社ではRedmineでIssue(チケット)管理をしており、MCP連携しているので
現在はタスクに取り掛かるときに仕様を詰めてチケットの記載を充実させ、MCPでチケットを読ませて対応させるということをしています。
レビューの壁（時間がない）
AIが使えてきているチームは大体この壁にぶち当たっているのではないでしょうか。
利用しているAIエージェントにレビューさせるのもよいのですが、各自が手元でレビューさせるだと結局レビュイーがごまかせてしまうのでレビュアーの負荷は下がりづらいです。
プルリクエスト/マージリクエストを作成すると必ずAIのレビューが走る状態には最低限しておきたいです。
コード品質が下がるとAIの出力頻出もしっかり下がり、よりレビューがしんどくなっていく悪循環に入るのでレビューは妥協できない部分です。
トークンの節約Tips
チャットでより影響が強い話で他の"壁"ほど大きな話ではないのでTipsにしました。
しかしながら、した方はいいのに意外と聞かない話だと思ったのでどうしても話しておきたく削らずに話しました。
今後も色んなところで伝えていくことになる気がしています。
エージェントがファイルを探索する範囲も消費トークンの量にかなり影響を与えるのでここに記載した限りではないのですが、
それでもトークンを節約したり間違った指示を覚えさせないというのは現状かなり重要です。
新しいモデルが出ると「コンテキストウィンドウがxxもある！」ということを言うような人もいますが、
エラーにならないだけでその量をちゃんと理解してくれるかは全然別の話なので個人的にはコンテキストウィンドウのサイズはあてにしてません。
コンテキストウィンドウが大きくても結局ちゃんとした品質のものがほしければこちらでうまく小さく分けたり圧縮する必要があります。
また別の指標として記載した内容をちゃんと理解できる限界のサイズが欲しいですね。
おわりに
以上でスライドに書ききれなかったことは大体書いたと思います。
魚より"釣り方"を伝えるよう意識しているので覚えることで長期的にメリットが出るようにしているつもりです。
皆様の糧となれば幸いです。