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エンジニアリングの実践的な知見を得て、自社での開発に活かせるヒントを持ち帰れる場を提供いたします。

Cursorをはじめとした開発支援ツール、エンタープライズAI、エージェント型AI、SaaSでの活用事例など、非常に幅広いテーマの講義を聴くことができました。

全体を通して感じたのは、
「AIは導入するだけで成果が出るものではなく、使い方そのものが問われるフェーズに入っている」 という点です。

本記事では、特に印象に残った講義をいくつかピックアップしつつ、全体を通した学びや感想をまとめていきます。

「AIを導入したのに成果が出ない」という現実

オープニングで語られていた話が、まずとても印象的でした。

• AIを導入しても、マージされたプルリク数はあまり変わっていない
• 若手層に限ると、むしろ生産性が下がっているケースもある (!?)

「AIを入れれば自動的に生産性が上がる」という考えは正しくないようです。
この前提を最初に共有した上で講義が進んだことで、「現場でどう使うべきか？」という視点を持って話を聞くことができました。

自分も若手層だと思いますが、プルリク数がAIを使っても増えないというのは「本当にそうか？」と思いましたが、全体で見たらそうでもないのかもしれないですね。コーディングの内容にもよるかも。

How Cursor Builds Cursor

Cursorのセッションでは、「AIに全部任せる」のではなく、人とAIの役割分担がかなり現実的に設計されている という印象を受けました。

特に印象に残ったポイントです。

• まずは Plan Mode で計画を立てる（Planモード知らなかった...
• プロンプトを最適化し、できるだけ多くのコンテキストを与える
• ユースケースに合わせてモデルを選ぶ
• 自分で手作業するより、エージェントにコードを書いてもらった方が速い場面は素直に任せる

また、デバッグやレビュー周りの話も興味深かったです。

• デバッグ専用のモードが用意されている

• GitHubと連携した Cursor Bug Bot

  • 信頼度の高いものだけコメントする仕組みになっているそうです

「考えるところは人、手を動かすところはAI」という分業が、すでに実用レベルで成立していると感じました。

自分はcursorに課金してコーディングをしてますが、コーディングはほとんどカーソルがやってくれます。しかし求めている以上の範囲まで仕様を無視してコーディングしてしてしまうこともあるので、そこは人側が適切にAIに指示を与える必要がありそうです。

Planモードの使い分けはせず、すべてAgentモードで済ませていたのでこのモードも使用していきたいです。

「協働」で拓くAI開発の最前線 - VoC活用と生成AIエージェント開発の舞台裏

こちらの講義では、AIプロダクトの技術的な工夫だけでなく、開発体制そのものをどのように設計しているかに重きが置かれていた点が特に印象的でした。

紹介された「PKSHA Insight Builder（PIB）」は、コールセンターの通話書き起こしログを対象に、AIを用いて顧客の声（VoC）からインサイトを高速に抽出できるツールです。もともとクライアントごとに個別開発していたソリューションを、現在はマルチテナント型SaaSとして展開しており、ソリューション事業で培った知見がプロダクトとして昇華されている点が興味深く感じられました。

技術面では、以下のような構成・設計が紹介されました。

• Webサーバは TypeScript
• 分析・学習処理は Python
• ビジネスロジックやDB操作は TypeScript側に集約
• Python側は可能な限り ステートレス に保つ

両言語を併用する構成において、責務を明確に分離することで、保守性や運用性を高めている点が印象的でした。

また、ChatAgentの事例では、従来のFAQ・チャットボットが抱えていた次のような課題が挙げられていました。

• 質問意図が曖昧で、ユーザーの本当の目的が分からない
• FAQが長文で、読まれにくい
• 本来自己解決できる問い合わせが有人対応に流れてしまう

これらに対し、

• LLMによる 高精度な聞き返し
• 既存FAQを基にした 回答の要約・生成

を行うことで、自己解決率を高めるアプローチが取られていました。LLMを単なる回答生成ではなく、対話を通じた意図理解に活用している点が特に印象に残りました。

下記はシステム構成です

AIプロダクト開発においては、モデルやLLMの性能だけでなく、どのような体制・設計で仮説検証を回し続けられるかが重要であることを改めて認識しました。

LLMは計画業務のゲームチェンジャーか？ 最適化業務における活用の可能性と限界

AtCoderで世界4位の方の講義でした。

物流最適化の事例では、LLMの得意・不得意がとても分かりやすく整理されていました。

• 要件がある程度固定されている計画問題では、LLMは非常に強い
• 試行錯誤の比重が高いヒューリスティックな領域は、まだ人間の判断が重要

実際にLLMに実務を任せられるかというとそんなことはさそうでした。業務は複雑で仕様の量の多さだけでなく、暗黙知と言った隠れた仕様もあり、またそれらの一部はプロジェクトを進めていくうちに明らかになってきます。

そういったところも汲み取りながらLLMが作業していくのはまだまだ難しそうです

「LLMは人間を超えた」という表現がありつつも、万能ではない前提で使われている 点が非常に現実的だと感じました。

個人的にこの方のスライドの内容や話し方などが非常にわかりやすく、プレゼン自体が参考になりました。ブースで話す機会があったのでお礼を言いました＾＾

従来型AIからエージェント型AIへ〜ラグジュアリー業界におけるエンタープライズ変革と大規模マルチエージェントシステムの構築

エージェント型AIのセッションで繰り返し強調されていたのは、

なぜAIを使うのかを考えるべき

という点でした。

• エージェントはマルチタスクが苦手
• 単一の事象に対して役割を明確に振ることが重要
• 従来型AIとエージェント型AIのどちらか一方ではなく、重なり合うスイートスポットを狙うことは大事

また、

バッグを買うことは楽しいが、バッグを買うことを知られることは楽しくない

という例えが非常に分かりやすく、
ユーザー体験とプライバシーのバランスをどう取るか、改めて考えさせられました。
AIは人が不快に思うラインを考えるのは難しいと思うのでこちらで適宜設定をして上げる必要があるそうでした。

普段コーディングをしているだけだとそこまで思慮が及ばないことではあったので聞いていて面白かったです。

企業価値につながるAI事業とは

複数の講義を通して、共通して投げかけられていた問いがあります。

• なぜAIを使うのか、きちんと説明できるか
• そのAI活用は企業価値につながっているか

AIはあくまで手段であり、この軸に乗らないAI活用は評価されにくい、という話はとても現実的でした。

また、AI駆動開発については、

• 支援型（人の補助）では、思ったほど生産性が上がらないケースもある
• 丸投げ型（任せきる）方が、結果的に効果が出ている

という話もあり、「どこまでAIに任せるか」の設計が重要だと感じました。

オープニングでもAIで生産性が上がらないケースがある話していました。今後どのようにAIを使っていくのか、今一度考えて行きたいと思いました。

またこれはAIとは関係ありませんが、
事業を進めていくうえでやっておいたほうがよかったことは「攻めの守り」だそうで

例えば特許申請や法務・契約まわり等、何がどう転んでもいいようにリスク管理を徹底することで、結果それが企業価値につながるといったことも教えてもらえました。

「偉大な会社になるための3K」を軸に事業展開していたそうです

• 高成長
• 高収益
• 広大なTAM

エンタープライズにおけるAI駆動開発の最前線と展望（CTO対談）

こちらの講座では、エンタープライズCTOの対談を通じて、Devin・CursorといったAIコーディングツールの実運用に基づく知見が共有されました。特に印象的だったのは、「人間を支援するAI」と「人間を置き換えるAI」では、組織全体の生産性への影響が大きく異なるという点です。

モノタロウにおける導入実績

2025年11月時点で、モノタロウではAIコーディングツールを全社的に導入し、効果検証を進めています。

数値として成果が可視化されており、実験段階を超えた運用フェーズに入っていることが伝わってきました。

人間とAIの役割分担

実運用では、以下のような線引きが行われていました。

• AI（Devin）に任せる領域

  • 定型作業（依存関係更新、設定変更など）
  • スキーマが明確な修正
  • 初期調査、PR作成・レビュー対応

• 人間が担保する領域

  • 要件充足の確認
  • 内部品質・仕様の裏取り
  • 最終成果物としての判断

なぜDevinは効いたのか

CursorやClineは生産性向上が個人差に依存しやすい一方で、

DevinはIssue駆動・非同期で開発プロセスに組み込めるため、組織全体のスループットを押し上げたと整理されていました。

• 支援型AI：人間主導、効果は個人依存
• 置き換え型AI：AI主導、プロセス全体を変革

この違いが、成果の差として表れている点が非常に印象的でした。

会社でDevinは使われていますが、自分は使ったことがありません
他の講義でもDevinによって生産性が向上したことが数値で証明されていたので、かなり興味が湧きました。使ってみようと思います。

また最後の方に将来必要となるエンジニア像についてお話されてました。

今もそうなりつつありますが、コーディング力はだれがやっても同じになってしまうような時代は近い将来来そうなきがします。他の講義でも触れられてはいましたが、AIでは汲み取れないような知識や価値を持つ人が必要とされるのだろうと思います。

その他ブースでの体験

AIが生まれた場所がわかる地図パネルあった

アメリカやっぱり強いなというのと、日本から生まれたAIツールが有るの知らなくてびっくりしました。最新技術に対するアンテナ強くしていきたいなと思います。

脆弱性検知を体験できるガラガラ抽選器やった

GMO Flatt security様のブースでした。
抽選器回したら赤い玉が出てきて「はい、脆弱性検知できましたね」的なことをいわれて笑いました

脆弱性検知できるツールはたくさんあって、検知率はどのツールも90％超えで差別化が難しいそうです。そのため誤検知を減らすことに注力しているそうです。

特典でストレス解消ボールもらいました！思い切り握っても意外と潰れないので仕事でうまくいかないとき、これに力を込めたいと思います。

おわりに

今回のカンファレンスを通して感じたのは、

• AIはもはや必須のツールである
• 業務にどう組み込むかでアウトプットの量や質がかなり変わってくる

ということです。

また、成果が出ている事例ほど、

• 目的が明確
• 人とAIの役割分担がはっきりしている
• AIに過度な期待をしていない

といった共通点がありました。

「AIを使うこと」自体が目的になるのではなく、
「AIとどう協働するか」 を考えるフェーズに、入っているのだと感じました。

非常に学びの多いカンファレンスでした。