幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

AI Engineering Summit Tokyo 2025 に参加しました

AI Engineering Summit Tokyo 2025 に参加しました。
カンファレンスに参加した学びをまとめます。

イベントの概要

ソフトウェア開発の最前線では、AIが開発プロセスに組み込まれ、従来の開発プロセスからAIを前提とした開発フローへと急速に変化しています。

特に、ClineやCursor, Claude Codeのような自律的AIコーディングツールの登場は、ソフトウェア開発に生産性革命をもたらす可能性を秘めており、実際の企業での導入事例とその効果検証が業界全体の注目を集めています。

AI Engineering Summit Tokyo 2025では、「AIが変えるプロダクト開発の未来」をテーマに、AIの活用・開発における最先端の事例や取り組みをご紹介します。

参加者の皆様がAIエンジニアリングの実践的な知見を得て、自社での開発に活かせるヒントを持ち帰れる場を提供いたします。

引用:

ai-engineering-summit-tokyo.findy-tools.io

イベント参加の背景

  • AI駆動開発を進めている中で、AIを利用した開発についてもっと理解したい。
  • Findyさんのカンファレンスは可能な限り参加する方針。
  • 今回は同じプロダクト開発に携わるお客様のエンジニアとも一緒に参加!!うれしい!!

セッション

Findy AI+の開発、運用におけるMCP活用事例

speakerdeck.com

メモ

Findyはエンジニアを応援する企業。
MCPはデータ企画。Linux Foundation参加に新設されたAAIFに寄贈された。
FindyのMCP事例。
・GitHubMCP:プルリクエスト自動生成。
・SentryMCP:不具合自動修正
MCPサーバー内製:TS SDKを利用。レビューコメントの傾向分析。

Findy AI+。生成AIの利活用を促進するためのプロダクト。
今年は困りごとの収集を行った。来年は利活用の可視化を行っていく。
リモートMCPの採択理由。
・MVPでの開発。画面が不要となる。
・データ取得、加工に専念
β版。ユーザー側画面を提供。サービス全体の管理機能はローカルMCPを利用した。

MCPサーバーとクライアントのやり取りは基本的に一方通行だった。
Eliciationにより、対話型が可能になった。

MCPの可能性は無限大。プロダクトの作り方が分かっていく。
LLMや生成AIツールが変わっても、MCPは変わらない。長く使える知識・技術。

学び

MCPという標準規格を通した可能性を学びました。いろいろ試行錯誤したい。
AIのPoCとの親和性も改めて理解しました。仮説検証速めたい。

AI時代の新規LLMプロダクト開発

メモ

Findy Insights。

生成AIによってスピードと安定を両どりできた。
スピード:1日1プロトタイプ
安定:既存資産による安定稼働

新規事業の企画部分をサポートするためのプロダクト。
ディスカバリー部分の支援プロダクト。
そこに至る流れ・背景を追って、企画を出してくれる。
より素早い仮説検証と、ナレッジの資産化も行う。

音声・テキストデータをS3にアップロードし、Postgresに文字を保存。
RAGをもとにAIエージェントが対話可能とする。

・開発の流れ
LLMの経験者は1名のみ。Pythonでの開発もはじめて。
2月:PoC、5月:プロトタイプをもとにキックオフ、9月:α版
プロトタイプ起点に開発フローを回している。
実働するプロトタイプでUXや挙動の認識齟齬を早期解決。

・PoC
大事にしたこと:並列処理による時間短縮。細かいロギングによるデバッグ時間短縮。
捨てたこと:エラーハンドリング・テスト、複雑なフロントエンド実装、複雑なインフラ

・新規機能開発
大事にしたこと:既存技術との整合性、バックエンドでのデータや処理フロー作成
捨てたこと:品質(ハッピーパスのみ確認)。インフラデプロイ。Figmaとのデザインの完全一致。

設計ふりかえり。
良かった点:
・レビュープロセス。未経験者も積極的にレビューに参加できるようにランダムレビュワー。
・pgvector + HNSW インデックス

改善点:
・最初からLangGraphを利用すればよかった。
・LLMを含む関数のテスト戦略。LLMの出力が非決定的のため従来のCIに適用しづらい。ベストプラクティス模索中

学び

Insightsの開発背景をお聞きできて嬉しかったです。
そして、エンジニアとしてPoC開発からすこし縁遠いため、興味深く聞くことができました。
LLMの出力に対するテストについて、自分も気になりました。

CARTAのAI CoEが挑む「事業を進化させるAIエンジニアリング」

speakerdeck.com

メモ

・AIアプリケーションの難しさと向き合う
今までのアプリケーションは確定的な振る舞いをしてきた。
大規模言語モデルは予測不可能性の塊。
ハルシネーションは人間の解釈。生成AIの個性。
AIを使うことは簡単だが、特性を理解して対策をすることは難しい。

・AI-CoE機能とタイガーチーム機能の2軸が全社横断しながらAI活用促進する
AI-CoE機能:
支援機能。
全社のAI活用を支援する。
コンサル、ガイドライン作成だけでなく、インフラを構築する。
プロトタイピング基盤。AIに対するエントリーポイントの提供を行う。
LLMOpsと観測可能性の向上を担う(LAngfuse)。

タイガーチーム機能:
実行機能。みんなが欲しがるものは作らない。
一般的なニーズにこたえるものは、大手が解決策を提供する。
であれば、固有の事業課題の解決に向き合った方が良い。

ドメインエキスパート自身でPoCできるようにAI-CoEが支援する。
そのうえで、解消されない課題に対して、タイガーチームがプロダクト開発の支援する。
二つのチームが全社横断して支援する。
PoCから実用化への道のりでは、精度向上のための泥臭い試行錯誤が重要。

学び

CARTAさんの実践の話。
改めてAIにおいてもPlatformEngineeringのような要素が重要になると感じました。
また事業にエンジニアが身近にいることで、プロダクト成長に向き合えることが素敵と思いました。

AIネイティブプロダクト開発現場のリアル

メモ

第二創業期。AIに全賭け、ユニコーンを量産していく。
DeNA内製。
AI-Nativeのプロダクト戦略とは。
プロダクトのサイクルの中心部分をAIが回す状態を作っていく。

AI-NAtive度の再定義を行い、注力する範囲を決めた。
・プロダクトコアにAIによるフィードバックループがあるプロダクト
・プロダクトコアバリューにAIによる新しい体験があるプロダクト。

想定体験を検証する企画&モックから、コアなUXの確認のための、プロトタイプが高速に回せるようになった。
企画&モックは1人、プロトタイプ1-3人で行っている。
企画でのイテレーションの速度をあげようとしている。
企画立ち上げは、ドメインスペシャリスト、実績のあるPdM、若手が多い。
全社の企画公募も行っている。
公募に対する壁打ちではAI住吉を利用している。

prtimes.jp


初期エンジニアの傾向。AIエンジニア、シニアエンジニア、若手。

AIネイティブ度の高いプロダクトづくりに必要なこと。
・PdM:生成AIを触って何かを作ることが好き。ユーザーのことを考えて作ることが好き。
・デザイナー:AIネイティブなUI・UXを作ることに興味ある。
・ソフトウェアエンジニア:AIネイティブなアーキテクチャや構造に興味がある
・AIエンジニア

多くの本数を作るためにも小規模で、スムーズな企画立ち上げを行えること。

学び

より早く仮説検証を繰り返すために最小の人数で最小のサイズにインクリメントを作り続けることが重要と学びました。
そのうえで、生成AIがそれを実現可能性を容易にしているイメージもできました。
AI住吉使ってみたい。

エンジニア組織として全社のAI活用をどうリードしていくのか

メモ

サイバーエージェント
研究開発:AIラボ、基盤モデル
文化醸成:リスキリング、会社全体の温度感を上げるためのコンテスト
事業インパクト創出:AIを取り込んだプロダクト増えてきている

23年:日本で最も利用している企業になる
24年、25人:AIを駆使できる人間を増やす

AI駆動で人間とAIが協働できる開発組織を目指している。

・ZOZO
グループ全体でChatGPTを使えるようにしている。
チャットツール、コーディングAI、生成AIモデル基盤、その他、複数種のAIツールを選択できるようにしている。

・Findy
60名のエンジニア組織でAI活用している。
AI系のプロダクトリリースしている、AIチームの立ち上げも行った。

AI時代の開発組織の未来像。5年後の姿をどう考えるか?
サイバーエージェント
プロダクトを作るエンジニアリングから、事業を作るエンジニアリングへ。
それをどのようにスケールするか。
自分が何エンジニアだったかで進め方が異なる。
パスの広げ方は人それぞれだが、幅は広がっていく。

・ZOZO
役割が広がっていく。コーディングだけをする仕事は無くなる。
AIの方がタイピングが圧倒的に早い。
より抽象度の高い部分に人が入っていくはず。
今までアウトソーシングしていた部分も、自分たちでやるという選択肢が増えていく。

求められなくなるタスク・業務
サイバーエージェント
コミュニケーションが気になる。
ビジネスを自分達でやっていくうえで、コミュニケーションの在り方が変わる。
人と人の間にAIが入ることで、調整系の仕事がなくなっていく。
組織的な広がりとは別に、属人性が薄まることで、複数プロダクトを担当するような人が増えていく。
今後、フルスタック的な強みがより重要になっていく。

・ZOZO
今現在、組織的な変化は起こっていない。
新規プロダクトに向けてコードに対する良し悪しが判断できる。

育成
サイバーエージェント
作ることに対する言語化が求めれていく。

リスク
・ZOZO
AIが出力したコードを人間が評価できなくなることがリスクと考えている。
コード起票する能力を用意し、人間がコードを管理できる状態を作っていく。

サイバーエージェント
コード分からなくなるという議論もあるが、新卒研修にコードを含めないことも考えている。
若手に生成AIを利用することを100%使うことを許容している。

育成方針
・ZOZO
コードを批評する能力を身に付けて欲しい。
コーディングだけじゃなく設計を身に付けて欲しい。

サイバーエージェント
開発プロセスそのものの見直しを行っており、それを身に付けてもらう。
企業としてはいったん使う。それを線でつなぐことを重視している。

開発プロセス
・ZOZO
ツールはいっぱい導入したが、うまい使い方を浸透しないといけない。
現状は個別最適しているが、効果最大化するためにベストプラクティスを定める必要がある。
現状は効果を測るために、Team+で客観的な数値からの確認を行っている。
マージまでのリードタイムは短くなっている。

サイバーエージェント
効果。コードの変更量やマージまでの時間ではよくなった。
コード品質に対しては確認したいと思っている。
効果あるかどうか確認するためにもAIを使っている。

・ZOZO
ROIの面ではAIを使う方が良いということが確立されている。
どんどん使っていった方が良い。
ベストプラクティスを全社展開をし、組織全体で使えるようにしている。

5年後の姿
サイバーエージェント
エンジニアの仕事は無くならない。むしろ忙しくなっている。
エンジニアの幅は広がっていく。

・ZOZO
エンジニアがAIツールを使いこなして、幅を広げていく。

学び

エンジニアが事業領域に染み出していくことは、大前提になってきている気がしています。
そして、それを可能にするはずのAIに振り回されないために、人間がオーナーシップを持って扱っていく重要性を学びます。

まとめ

今日は普段会えない同じプロダクト開発をするメンバーと一緒に参加ができて嬉しかったです。
同じ学びを得ることで、よりプロダクト開発に可能性が生まれる気がしています。
そして、開発生産性カンファレンスや、アーキテクチャカンファレンスともまた違った雰囲気も興味深かったです。
ソフトウェアが置かれる環境の多様性なのか。
AIを扱う上で人間がオーナーシップを持つことの重要性を改めて学びました。