アーカイブ動画

毎月のように変化するAIツール環境…

株式会社AI Shift（サイバーエージェントグループ）
AIコールセンター事業
PdM
木村 正弘（きむら・まさひろ）氏

木村氏は、エンタープライズ向けシステム開発を経て2014年に株式会社サイバーエージェントに中途入社。バックエンドエンジニア、テックリード、EM（エンジニアリングマネージャー）を経験した後、2023年に株式会社AI Shiftに転籍。サイバーエージェントグループのなかでもAIプロダクト・サービスを展開する企業である同社のAIコールセンター事業部で、プロダクトマネージャー（PdM）を担当している。

木村氏はまず、AIツールの急速な変化を振り返る。「2年前ぐらいに『GitHub Copilot』が出てきて、このころはコード補完がすごいってなっていましたが、今となってはだいぶ前の感じがしますね」と語るように、AIツールの進化スピードは想像を超えている。現在も「毎月のように新しいツールが登場するので、どのように活用するかを日々考えている」と明かした。

同社では「『Claude Code』派と『Cursor』派が多くて、『Claude Code』派の方が若干多い」状況だが、木村氏自身は「Cursor」派で一部「Devin」も併用している。そんななかサイバーエージェントグループでは、気軽に新しいAIツールにチャレンジできるよう「どのエンジニアも毎月200ドル自由に生成AIに使える」全社施策を導入したという。

AI生成コーディングの光と影

まず木村氏は、バイブコーディングの効果的なケースとして、プロトタイプ開発、自作ツール・スクリプト作成、シンプルなデータアクセス機能を挙げた。

実際に同氏が手がけたプロダクトでは、飲食店や歯医者の予約時に顧客の「行きたい日」と予約システムの「空枠」をすり合わせる機能をFunction Callingで実現した。顧客ごとに外部システムのAPI仕様が異なるため、間の層で実装変換処理を入れることで、ファンクションコーリングによって希望と空きを柔軟に組み合わせられる仕組みを構築。プロトタイプを作成して事業部に提案し、実際にプロダクトに組み込まれた成功例として紹介した。

一方で、バイブコーディングの効果が限定的なケースも率直に説明。「コードベースが巨大である、複雑なビジネスロジックである、複雑に絡み合ったコードを修正する必要がある、などの状況では、人でもAIにとっても難易度が高い」と指摘した。

その理由として、既存コードの全体像把握の困難さ、仕様理解の必要性、暗黙的な規約、ビジネス要件などのコンテキスト理解の重要性を挙げ、「どんなにすごいエンジニアでもジョインしてすぐに100%の力を発揮できないのと同じ」だと説明した。

より良いプロダクトを作るためのAI活用3つのポイント

PdMとしての視点から、木村氏は「良いプロダクトは試行錯誤を何回も積み重ねて改善していった先にある」と語る。

講演後半では、「生成AIと一緒にプロダクトをどんどん改善していく」ための重要な要素として、生成AIが理解しやすいコード作り、不具合調査・修正活用での生成AI活用、コンテキストを加味した段階的な指示という3つのポイントを挙げ、解説した。

1 生成AIが理解しやすいコード設計

1つ目のポイントは、AIが理解しやすいコード設計だった。「新規で生成するわけではなく、既存コードを含めて修正する場合はとくに、1つの仕様変更に対してあっちもこっちも調整が必要になるなど、生成AIも理解しづらい。また、修正箇所が局所化されていないとコンテキストに乗り切らない」と指摘。

そこで、AI時代におけるアーキテクチャ設計の重要性を語った。「クリーンアーキテクチャやDDDであれば、ディレクトリ構成やパッケージ構成もある程度決まってくるので、AIにとってもコードが探しやすく、修正が局所的になる」とし、ドメインロジックとそれ以外の分離、データベースアクセスコードの適切な配置など、「整理ができているとAIにとっても理解しやすい」と具体的なアプローチを示した。

2 不具合調査・修正での総合的活用

2つ目のポイントは、不具合調査・修正での活用である。木村氏自身の実践例として、アプリケーションログのコマンドを「Cursor」に事前に教えておくことで調査依頼を簡素化する手法を紹介。さらに「データベースを生成AIが見れるようにする」ことで、コード・データベースのデータ・ログを組み合わせた総合的な不具合調査を実現している。

「コードとデータベースのデータとログがあれば、不具合調査は大体解決すると思う」と語る一方で、「データベースはdev環境に留める」「selectしかできない権限を付与」など、セキュリティ面での工夫は必要であると強調した。

「Cursor」の具体的な設定として、メモリ機能、ユーザールール（「返答は日本語で」「コードの修正よりも原因究明を優先」）、プロジェクトルール（ディレクトリ構造、データベース接続先など）を活用。「修正方針や設計方針をパターン出しして、評価させたうえで修正させると手堅い」として、最近の試行錯誤から得たベストプラクティスを共有した。

3 段階的な指示で成果物の精度を高める

3つ目のポイントは、コンテキストを加味した段階的な指示である。「LLMは1ターンで解決しようとしてすぐ修正しようとする癖がある。根本原因の分析を十分にしてから修正させるのが遠回りのようで最終的に最短になる印象」として、段階的なアプローチの重要性を説明。

「修正・設計方法を複数パターンを出して評価させ、そのうえでコード修正させると手戻りが少なく、やり方として一番良かったと思う」と木村氏は明かした。

「驚きすぎない」生成AIと適切な距離感で向き合う大切さ

木村氏は講演の締めくくりで、「驚きすぎない。適切な距離感で向き合うのが大事」と強調。「どんどん変わっていくものがある一方、アーキテクチャ設計の重要性やビジネス価値は変わらないエンジニアの価値だ」と説明し、技術の変化に一喜一憂せず、本質的なエンジニアスキルの価値を見失わないことの重要性を説いた。

【Q&Aセッション】

Q&Aセッションでは、株式会社AI Shiftの木村氏がイベント参加者から投げかけられた質問に回答した。

Q. 「Cursor」を使ったことがないが、ほかのIDEと比べてどうか？

木村氏：「Claude Code」はプランニングがしっかりしていて、一発のコード生成力は強いと思います。ただ原因特定など、壁打ちしながらちょっとずつ進めたいケースでは、「Cursor」が使いやすいと個人的に思っています。

Q. 「Cursor」 と「GitHub Copilot」 を比較するとどうか？

木村氏：「GitHub Copilot」はエージェントモードが追加される前に離れてしまったので、最新事情がわからないのですが、コマンド呼び出しなどエージェンティックなことができるのは「Cursor」だと思っています。MCPも使えるのですが、大体コマンド呼び出しで事足りているので「Cursor」で十分です。

Q. 質問しただけでコード修正を始めてしまうのは、どう対処しているか？

木村氏：コードの修正よりも原因究明を優先するようルールに追加しているのが1つ。あとはプロンプトで「まだコードは修正しないでください」と指示するようにしています。

文＝宮口 佑香（パーソルイノベーション）

※所属組織および取材内容は2025年8月時点の情報です。

株式会社AI Shift
https://www.ai-shift.co.jp/

株式会社AI Shiftの採用情報
https://hrmos.co/pages/cyberagent-group