こんにちは！広報の留置です。
AIを活用した各種プロダクトや日本最大級のクラウドソーシングサービスなどを提供するランサーズ株式会社（以下ランサーズ）様が開催するオンラインイベントに、弊社 技術本部長の飯田（@kosuke_iida）と、技術戦略室のKAWANO（@talk_like_staw）が登壇しました。
この記事ではイベントレポートとして、当日お話しした講演内容や、当日の質疑応答で回答しきれなかった質問への回答をまとめています。
イベント概要と登壇の背景
本イベントは、2025年4月17日（木）にオンラインで開催されました。
テーマは「失敗と成功のサイクルから学ぶ、プロダクト開発におけるAI駆動開発導入の"リアル"とは？」と題し、生産性向上を目的に導入した技術スタックやツール、その選定理由など導入の入り口から、AI駆動開発で失敗したことや苦労したこと、そこから得た学びをお伝えしました。
実は弊社エンジニアがこのようなイベントで講演する機会は初めての取り組みでした。
弊社のプロダクト開発の裏側、特に昨年から力を入れているAI駆動開発についての知見を共有し、参加者の方のお役に立てればという思いで登壇させていただきました。
当日は事前申込100名以上と、多くの方にご参加いただきました。
登壇者のご紹介
SecureNavi株式会社 技術本部部長 飯田 康介
SIerからエンジニアキャリアを始め、CTOやVPoE兼CHROとして組織改革や技術戦略を推進。現在はSecureNaviで技術本部長として技術戦略と組織構築に取り組む。
SecureNavi株式会社 技術戦略室 KAWANO Fumihiko
富士通株式会社、株式会社豆蔵を経てSecureNavi株式会社に入社。現在は技術戦略室で既存・新規プロダクト開発を担当。2002年のXP本、2005年のSeleniumとの出会いを機に、テスト自動化とコード/テスト生成をライフワークとしながら効率化を追求し、開発現場の課題解決に情熱を注いでいる。
AI駆動開発導入の背景
弊社では、2023年4月頃からGitHub Copilotを利用した開発を行ってきました。
河野の提案で2024年の10月からSecureNaviを開発しているプロダクト開発部の全エンジニアにCursorのライセンスを付与しています。その後11月から新規プロダクトの立ち上げ開発を行うことになり、AI駆動開発を全面的に取り入れています。
AI駆動開発導入の一番の目的は開発生産性の向上。
新規プロダクト事業が発足し、少数先鋭で開発が求められ「AIを使わないと間に合わない‼︎」という状況でした。
また、既存のSecureNavi（プロダクト）に比べ新規プロダクトは機能も少なく、規模感も適切だったため、全面的なAI駆動開発を行うことに決まりました。
AI駆動開発導入で苦労したこと
AI駆動開発のリアルな苦労話、対処方法は河野のブログ記事でもお伝えしてきましたが、今回のイベントでは以下3つの点についてお話ししました。
-
短期記憶と無限ループ
AIが直前の指示を忘れてしまうため、同じ作業を繰り返す無限ループに陥るケースが頻発 -
自己評価の甘さと誤報
AIが自ら生成したコードのバグを他人事のように報告したり、基本的な文字数カウントなどで自信過剰な誤りを示す問題があった -
危険なコマンド実行
環境破壊のリスクを孕むシステムコマンドの自動実行や、常駐型コマンドによるデッドロックなど、予期せぬ動作に対する対策が必要だった
AI駆動開発導入で良かったこと
-
生産性が大幅に向上！
生成AIが主導してコード生成を行うことで、従来の手法に比べて作業効率が劇的にアップし、実際の開発スピードも向上。
苦労も多々あったものの、AI駆動開発の実践ができたことに加え、新規プロダクトのリリース目処が立っている状況👏 -
刺激的な開発体験
AIエージェントとの協働により、従来の開発手法とは異なる斬新なアプローチを体験できた！
組織内でも導入して良かったという声も多数。 -
ドメイン駆動設計との相性の良さ
ドメイン駆動設計により、AIに与えるコンテキストを最小に抑え、システム全体の整合性を保ちながら効率的な開発が可能に。
より良い開発体験のために
苦労も重ねたAI駆動開発の経験から、より良い開発体験のために重要なのは適切なコンテキスト管理と人間の介在です。
-
コンテキストの最適化
.cursorrulesやプロジェクトルール、Rules for AIなどを組み合わせ、AIに与える情報量を必要最小限に抑えることで、混乱を防止する。 -
ログ活用とデバッグの徹底
詳細なログ出力により、問題発生時に迅速に原因を特定し、AIの不得意な複雑なシステム全体の問題切り分けを補完することが重要。 -
人間のレビューと補完
AIが生成したコードは必ず人間がレビューし、システム全体の品質や整合性を確認するプロセスが不可欠。
質疑応答
当日は参加者の皆様から多くの質問を寄せていただきました！
時間の都合上お答えできなかったご質問に回答させていただきます。
Q1.既存プロダクト開発にCursorを使うのはリスキーだというお話しがありましたが、それはなぜでしょうか？
A.2024年10月頃の状況として、生成AI技術は目覚ましい進歩を遂げ、実用的な場面も増えてきていましたが、誰もが容易に使いこなし、常に期待通りの成果を出せるという段階にはまだ至っていませんでした。これは現時点（※執筆時点 2025年5月）でも完全に解消されたわけではありません。
このような状況において、特に開発の歴史がある程度長く、コードベースがある程度大きい既存プロダクトに対して、生成AI（Cursorのようなツールを含む）を全面的に導入し、直ちに生産性を最大限に向上させようと試みるのは、技術的な成熟度や、ツールを効果的に使いこなすための学習コストなどを考慮すると、まだ挑戦的な側面が大きいという意味で「リスキー」という表現をさせていただきました。
また、生成AI、特にAIエージェントは変な特性を持つITエンジニアといえ、それをうまくコントロールできるにはある程度のマネージメント能力や経験が必要であると言えます。
生成AIツールは非常に強力ですが、既存の複雑なシステムへ適用する際には、その特性や潜在的なリスクを理解した上で、導入範囲や方法を慎重に検討する必要があると考えています。（河野）
Q2. 社内の開発言語がvueなのですが、V0とCursorの仕様は相性が悪いでしょうか？
A. v0とCursorは、それぞれ異なる目的を持った独立したツールですので、両者の間に直接的な「相性」の良し悪しがあるわけではありません。
まず前提として、v0は主にNext.js（Reactベースのフレームワーク） を使用したWebフロントエンドのUI（ユーザーインターフェース）を、テキスト指示から自動生成することに特化したサービスです。デフォルトでは、スタイリングにTailwind CSS、UIコンポーネントライブラリとしてshadcn/uiを使用することが想定されています。
もし開発プロジェクトがこの技術スタック（Next.js, Tailwind CSS, shadcn/ui）を採用している、または採用できる場合、v0が生成したコードは比較的スムーズにプロジェクトへ統合でき、その恩恵を大きく受けることができます。
一方で、v0が生成したコード（React/Next.jsベース）を、異なるフレームワークのVue.js用に生成AIを使って書き換えて利用すること自体は、不可能ではありません。しかし、その場合はv0の最大のメリットである「特定の技術スタック（Next.js）へのシームレスな統合と開発スピード向上」という点が大きく損なわれてしまいます。英語をフランス語に翻訳して日本語にするような行為を実施するのであれば他の方法(figmaとfigma MCPなど)を取る方が良いと感じます。
どの程度メリットが薄れてしまうかは実際に変換作業を試してみないと具体的な判断は難しいというのが私の見解です。（河野）
Q3. 保守も可能ですか？
A. 新規プロダクトといっても、一筆書きで任意の画面や機能を作成できるわけではありません。
TODOアプリやポケモンのような公知な仕様のものであればできるのですが、最初の生成以降は基本的に保守と同じです。そうは言ってもガチの保守とは複雑性は異なります。
既存プロダクトの保守効率を低減する複雑性とAIが変更しやすいかなどの観点が重要になります。（河野）
Q4. 人間がさらに向上すべきスキルセットがあれば教えてください
A. IT系の専門知識も当然大事ですが、それ以上に問題分析と言語化、問題分析の考え方を身につけることが大事だと感じます。
ミノ駆動さんのこちらの記事がとても参考になると思います。（河野）
Q5. rulesにはどのような事をどの程度の粒度で書いていらっしゃいますか？
A.ルール作成で目指しているのは、AIが生成するコードの一貫性を高め、予測可能性を向上させること（エントロピーを下げること）です。
具体的な粒度としては、例えば「特定の責務を持つファイルは、常にこの命名規則に従い、このディレクトリパスに配置する」といった、ファイル構造や命名規則に関する規約を定義しています。これは、AIが常に同じ判断をするとは限らないため、プロジェクト標準を一貫して守らせるためです。
また、ルール内に「現在の機能名」のような動的な情報を変数（プレースホルダー）のように埋め込むことで、状況に応じてAIが解釈できるようにし、ルール自体を簡潔に保つ工夫もしています。
ただし、『Gemini 2.5 Pro』 のような新しいAIの登場で、今後ルールの重要性や書き方は変わる可能性もあり、現在の手法が最適であり続けるとは限りません。（河野）
Q6. 開発前に、AIに対して、プロジェクト内ルールやコーディングルール等を事前学習させておく必要があるかと思いますが、そのための工数はだいたいどの程度、見積る必要があるのでしょうか？
A.ルール作成に必要な工数は、対象プロジェクトの要件の複雑さ（例：特定の技術要素『AWS SQSを利用した非同期処理』などをルールに含めるか）や、求めるルールの完成度（詳細度）によって大きく変動するため、一概に「何日」と申し上げるのは難しいです。
ただし、最近ではAI自身にルール作成を手伝ってもらうことも可能で、例えばCursorエディタにはルール作成支援機能が実装されています。
こうしたAIの支援も活用することを前提とすれば、一般的なWebアプリケーションの機能実装に必要なレベルのルールであれば、概ね2日程度の作業で、実用的な初期セットアップは可能だと思います。（河野）
Q7. AIにプロダクトの企画からやらせるのは現実的なのでしょうか？採算まで考えたりとか、スコープ広げると際限がないのではと感じています。
A.AIのプロダクト企画への活用については、いくつかの段階や側面で現実味を帯びてきていると考えています。
-
ニッチな機会の発見と高速開発: AIが埋もれたニーズを発見し、それに基づいた企画からリリースまでを爆速で実行する、といった活用法は、今後のトレンドになる可能性があります。
-
アイデア創出のパートナー: 既存製品の新機能検討などの初期段階で、人間がAIをアイデアを深める対話相手（壁打ち相手）として利用することは、すでに一般的になりつつあります。
-
大規模計画の初期検討: 既存プロダクトのリプレースや大型アップデートのような複雑なシナリオを検討する際の初期段階で、AIが様々な可能性を提示し、議論を助けることも現実的に可能だと考えられます。
現時点では、AIが行うのは主に多様な「仮説」を効率的に立案・提示する段階です。しかしこれは、従来のように外部コンサルタント等に多額の費用と時間をかけて調査・相談する前の、迅速かつ低コストな「最初のステップ」として非常に価値があります。
AIによって本当に採算の取れる、価値あるプロダクト企画が生み出せるかどうかは、今後の技術の進化と実際の成功事例によって証明されていくと思います。（河野）
Q8. お二人の人柄がすごく良さそうだと感じました。そんな雰囲気の会社（組織）づくりのポイントを知りたいです。
A.お褒めの言葉をいただき、ありがとうございます！SecureNaviが大切にしているバリューや、行動指針である「31のDo」を体現することで、チームには良い雰囲気が醸成されていると感じています。
例えば「多様な意見を歓迎する」ことや「情報を公開しチーム全体で共有する」ことによって、誰もが安心して発言できる環境づくりを意識しています。
さらに「仲間の成功を皆で祝う」、「謙虚さと敬意を忘れない」、「仲間の置かれた立場や状況を理解する」などのバリューを日々の行動に体現することで、メンバー間の相互理解と尊敬を深め、良い雰囲気になっているのだと思います。（飯田）
【まとめ】試行錯誤の中で見えてきた、AI駆動開発の可能性と課題
-
シンプルなアプリケーションでは劇的な生産性向上を実現する一方、複雑なシステム開発では課題がある
-
失敗や試行錯誤を経ながら、AIの持つポテンシャルを最大限に引き出すことにより、より良い開発体験へと繋げることが可能
-
経験とタフさを持ち、適切な運用体制を整えた者のみが、AI駆動開発に挑戦すべき
最後に
今回はSecureNaviの新規プロダクト開発におけるAI駆動開発を紹介したイベントレポートを紹介しました。AI駆動開発に取り組むきっかけや、AI駆動開発を進めるご参考になりますと幸いです。
登壇の場を設けていただいたランサーズ様、ありがとうございました！
今後もこのような登壇の場やテックブログ等で弊社の取り組みをご紹介していきますのでどうぞご期待ください。
SecureNaviでは、情報セキュリティ分野の「悲報をなくす」を実現するために、一緒に働く仲間を募集しています。プロダクト開発や技術に少しでも興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください。
カジュアル面談
プロダクト開発応募ポジション
Discussion