3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI Engineering Summit Tokyo 2025 に参加して学んだこと

3
Last updated at Posted at 2025-12-23

はじめに

12/16に行われた、AI Engineering Summit Tokyo 2025に参加してきたので、現地のレポートをまとめました。

AI Engineering Summitって?

ファインディ株式会社が主催するAI技術に関するカンファレンスです。
前回は2025/6/18に開催されており、今回は2回目の開催となりました。
前回の資料はこちら

AI Engineering Summit Tokyo 2025では、「AIが変えるプロダクト開発の未来」をテーマに、AIの活用・開発における最先端の事例や取り組みをご紹介します。
参加者の皆様がAIエンジニアリングの実践的な知見を得て、自社での開発に活かせるヒントを持ち帰れる場を提供いたします。

公式サイト

セッション

当日は各時間でそれぞれ4つほどの講演が同時に行われており、興味があるものに自由に参加できる形式となっておりました。
自分が参加した講演についてまとめます。

当日の登壇資料のまとめ

How Cursor Builds Cursor

テーマ

Cursorが描くAI時代のプロダクト開発体験

Cursorの強みとは

現在は様々なAIモデルがあり、それぞれ特徴が異なっている。
Cursorは特定のAIモデルに限定されず、ユーザーに合わせて選択可能になっていること。

Cursorのエンジニア組織の開発ツール

実際にCursorの開発をする際にもチームではエディタでCursorを使用してコーディングを行うことでユーザーの目線に立った改善をすることができる。

開発スピードの向上

いかに開発スピードを上げるかということを目的としており、機能追加を行っている。
Cursorブラウザーの追加も開発者がエディタ内で開発を完結することができ、画面の行き来をなくすことを優先した結果。

コードレビューの効率化

AIが生成した大量のコードを人間がレビューするのは時間がかかるが、Bugbot を用いることで人間がレビューする前に精度の高い修正を行うことができる。Cursor以外のツールでも、AIを活用したコードレビューを開発フローに組み込むことが重要

Cursorでは、実際に開発チームがエディタとして使用していくことでユーザーの視点に立って開発をしていることが参考になりました。またチームがAIを取り入れ開発スピードの向上を重視しているからこそ、進化が早い業界でシェアを確保できるんだと感じました。

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

テーマ

協働で開くAI開発の最前線

VOC分析の課題と解決

従来の課題として、

  • 入力データの多くがテキストや音声などの非構造化データで量が膨大
  • 有用なインサイト抽出に専門的知識・スキルが必要
  • 工数がかかり継続的な実施が困難という点があった

これを解決するために、AIを用いた分析ツールとして開発し、顧客接点データをコンタクトセンター業界全体、企業活動全体の改善に活用

技術的チャレンジと解決策

大量データ処理

  • 課題: 数ヶ月分で10万件規模のデータがあるためLLMだけでは、コンテキストウィンドウを超えてしまう
  • 解決策:
    • ハイブリッド構成: LLMと機械学習モデルの組み合わせ
    • 機械学習モデルを自社開発し、学習はCPU上で混合精度、推論はメモリ上で実施
    • LLMの柔軟性とコスト効率・スケーラビリティを両立

言語間連携の工夫

  • 課題: TypeScript(サーバー側)とPython(分析・学習側)の統合
  • 解決策:
    • ビジネスロジックとデータベース操作をバックエンド側に集約
    • Python側はデータベースを直接触らない
    • Python側はステートレスに設計し、ジョブ入力で必要なデータを受け取る
    • Pythonで動的データ取得が必要な場合はHonoを経由

3職種の協働によるプロダクト開発

職種を超えた協働がプロダクト開発の鍵

  • 各職種が専門性を発揮しつつ連携
  • エンジニアが顧客と直接接する機会

アルゴリズムエンジニアとソフトウェアエンジニア間の協働による高速開発

  • インターフェースだけを先に決めて並行で開発
  • 社内のナレッジシェアやAI製品をフル活用

IMG_0249.jpg

VOC分析の課題解決にあたり、LLMと機械学習モデルを組み合わせることで解決できる課題の幅が広がると感じました。技術的には、TypeScriptとPythonの連携において、それぞれの責務を明確に分離する設計が印象的でした。また、アルゴリズムエンジニアとソフトウェアエンジニアがインターフェースを先に決めて並行開発する手法も参考になりました。

マルチテナントAI Agent(Agent as a Service)の実装

テーマ

マルチテナントAI Agent(Agent as a Service)の実装

SaaSからAaaSへの進化

SaaSの本質:
ある業務に対するベストプラクティスを提供するビジネス及びソフトウェアデリバリーのモデル

AaaSへの進化:

  • マルチテナントがより重要に
  • ビジネスを深く理解した設計がさらに求められる
  • テクノロジーの話だけでは不十分

エンドユーザーへの価値訴求

目標:
エージェントの価値を体感してもらい、より多くの料金を払ってもらえるインセンティブ設計

アプローチ:

  • 明確な価値提示
  • ティア別機能提供
  • 利用量に応じた段階的価値提供

データベース分離の手法

分離レベル:

1. データベース分離

  • 完全に独立したデータベース

2. スキーマ分離

  • 同一データベース内で異なるスキーマ

3. テーブル分離

  • 同一スキーマ内で異なるテーブル

4. ロウレベルセキュリティ(RLS)

  • 同一テーブル内で行レベルでの分離
  • 非常に高速にスケール可能
  • Supabase等で採用されることが多い
  • AI系スタートアップで人気

IMG_0264.jpg

AaaSにおけるマルチテナントの重要性が印象的でした。また、技術だけでなくビジネスを深く理解した設計が求められる点は、今後意識していく必要があると感じました。

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

テーマ

事業を進化させるAIエンジニアリング

なぜAIアプリケーションは難しいのか

従来のプログラムとの違い

従来のプログラムの特徴(確定的な振る舞い)

  • 書いた通りに動く
  • 同じ入力には同じ出力を返す

機械学習モデルの特徴(確率的な振る舞い)

  • 出力が一義に定まらない性質
  • ただし、様々な工夫で問題にならない程度にコントロール可能

LLMの特異性

  • 従来と共通する点

    • 確率的な振る舞い(機械学習と同じ)
  • LLM特有の問題

    • 予測不可能性の拡大:
      • 出力結果の多様性が桁違い
      • 大きく期待から外れた出力も得られる

ハルシネーションの本質

ハルシネーションという現象自体は本来存在しない

  • LLMは正しい出力をしようとしているわけではない
  • LLMは間違った出力をしようとしているわけでもない
  • ただ確率的にあり得そうな出力を出しているだけ

持続可能なAI活用の枠組み

目指す姿: 基盤の提供

  • いかに事業固有の課題に向き合うか
  • 難易度の高い課題を自分たちで解いていく
  • そのための枠組みを作る

IMG_0294.jpg

ハルシネーションは現象として本来存在せず、LLMが確率的にあり得そうな出力をしているだけという点が印象的でした。従来のプログラムとの違いを明確に説明されており、AIアプリケーション開発の難しさと向き合い方について考えさせられました。

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

テーマ

従来型AIからエージェント型AIへ

2つのAIタイプの使い分け

リアクティブ従来型AI

  • 適用場面
    • 非常にシンプルなタスク
    • 大量処理が必要なタスク

プロアクティブAIエージェント

  • 適用場面
    • 目標指向のタスク
    • 高度な自律性が必要
    • 正確な指示が困難

戦略として

  • どちらか一方ではなく、両方を適切に使い分ける
  • タスクに応じた最適なツール選択

IMG_0321.jpg

パーソナライゼーションとプライバシーという矛盾を両立させるために、リアクティブAIとプロアクティブAIエージェントを使い分けるアプローチが印象的でした。ラグジュアリー業界特有の制約の中でAIを活用する実践的な視点が参考になりました。

ダブルCoE体制と「LegalRikai」が支えるリーガルテックの進化

テーマ

全社で推進するAI活用

2つのCOE体制

AICOE

  • 対象: 開発部門に特化
  • 役割:
    • 開発コンテキストでのAI活用推進
    • エンジニア向けツール選定・導入
    • 開発業務の効率化

AMCOE

  • 対象: 全社・全従業員
  • 役割:
    • 開発に限らない全社的なAI活用
    • 全従業員向けの業務効率化
    • AI活用の底上げ

両COEの関係:

  • 独立して運営
  • それぞれが異なる対象にアプローチ
  • 相互に連携

成果が上がっている領域

主要な活用パターン:

①コード・ドキュメント生成

  • 基本的な活用方法

②リサーチ

  • 大量の情報を要約してまとめる能力
  • 大量の情報から特定情報を探し出す能力
  • 業務での効果: 「非常に業務でも効果が上がっている」

③壁打ち・改善

  • 従来の課題:
    • エンジニアが壁打ちしたい時、人と話すしかなかった
    • ジュニアエンジニアがシニアと話す時間が取れない
  • AIによる解決:
    • まずAIと対話してアイデアをブラッシュアップ
    • その後シニアに壁打ち
    • 結果: 壁打ちの品質向上

IMG_0347.jpg

開発組織特化のAICOEと全社向けのAMCOEというダブルCoE体制で、対象に応じたAI活用を推進している点が参考になりました。特に、リサーチや壁打ちでの活用事例は、自分自身も実務で効果を感じており共感できました。

ClickHouseによるAIエージェント革命

テーマ

ClickHouseによるAIエージェント革命

AIエージェントという新しいユーザー

根本的な認識:

AIエージェントは、データベースと対話する根本的に異なる方法である

新しいユーザー像

  • 従来: 人間がSQLを書く
  • 現在: AIエージェントがデータベースと対話

AIは置き換えではなく増幅器

  • 人間の専門知識を補完する
  • 完全自律は現実的ではない
  • ガイダンスと監督が不可欠

精度と速度のトレードオフ

  • すべてのAI性能はこれに帰結
  • 規模に関わらず普遍的
  • コンテキストの質が鍵

IMG_0370.jpg

AIエージェントの登場で、人間がSQLを書くのではなくAIエージェントが代わりに対話するという点がとても印象的でした。またAIが人間に置き換わるのではという認識を持っていましたが、あくまで人間の専門知識を補完するためのものであるという点も参考になりました。

ガバメントAIへの内製エンジニアの関わり方

テーマ

ガバメントAIへの内製エンジニアの関わり方

なぜやるのか:日本政府のAI戦略

人口減少による人材不足

「日本では人口減少による人材不足がとても深刻化してきている」

特に深刻な地方行政

  • 市役所の定員割れ
  • 「このまま行政運営することすら不可能なんじゃないか」という危機的な状況

AIの位置づけ

  • AIがあることで0を創出するというよりマイナスにさせないというような状況

何をやるのか:ガバメントAI庁内利用環境

ガバメントAI(源内)

  • 現在の利用範囲
    • デジタル庁の全職員が利用可能
    • プラットフォームとして機能
    • 様々なAIアプリを提供

ノーコードでのAIアプリ作成:

  • 企画書アップロード→システムプロンプト生成
  • 10分程度でAIアプリ完成

YouTubeでも源内についての説明動画があります。
【政府全職員を"AIエンジニア"に!?】行政の未来を切り拓く「ガバメントAI」とは【解説】

IMG_0389.jpg

日本の人口減少という課題に対して、AIを使って効率化を図るための基盤作りをしている点が印象深かったです。源内を用いて、エンジニア以外の人が社内ツールを簡単に作成しており、作って終わりではなく広めていくための活動が大事だと思いました。

Chatwork×BPaaS×AIエージェントで創る次世代マッチング基盤

テーマ

Chatwork×BPaaS×AIエージェントで創る次世代コーディネート基盤

なぜBPaaSなのか:SaaSモデルの限界

SaaSの2つの課題

①DX人材の必要性

  • 導入人材が必要
  • 使いこなし人材が必要
  • 特に中小企業では人がいない

②業務フローの適合問題

  • 業務がかなりアナログになっている
  • なかなかそのSaaSのプロセスに合わない
  • 中小企業ほどアナログな部分が多い

BPaaSというアプローチ

マジョリティ層に対して特にターゲットとして力を入れていく

BPaaSとAIの相性

技術的な親和性

  • チャットUI × AIの組み合わせ

チャットUIっていう部分とこのAIっていうものが組み合わさった時に、BPaaSみたいな業務のプロセスごと巻き取っていくっていうアプローチが、すごい相性がいい

従来のBPOの課題

  • 昔ながらのBPO(Business Process Outsourcing)は人手が必要
  • かなり固定費もかかって
  • 利益率がなかなか難しいビジネスモデル

AIが解決

  • 市場の成長性: AI活用したBPO市場の成長率が高い

チャットワークのBPaaS戦略

4つのプロセス

基本的な流れ

  1. 依頼受付: クライアント企業から依頼を受ける
  2. AI処理・コーディネート: AIが依頼をコーディネート
  3. 振り分け: 人が対応するのがいいのか、エージェントが対応するのがいいのか
  4. 業務遂行・アウトプット: BPaaSとして業務プロセス・案件を処理し、チャットで返す

IMG_0405.jpg

SaaSの課題として、中小企業への導入がそもそも難しいという点は自分が認識できていなかった部分で、その解決としてBPaaSを広めて行くという視点がとても印象的でした。
また、講演の中でサービスを技術に関して高い理解を必要とせず使用できるようにしたいという思いに共感しました。

まとめ

今回初めてカンファレンスに参加してきたのですが、AIに関しての盛り上がりを実際に感じることができてとても楽しかったです!

カンファレンス全体を通じて得た学び:

  • 各社共通してAIを積極的に活用し、チーム内で共有をするための仕組みづくりをしている
  • AIは人間の仕事を奪うものではなく、協働パートナーとして機能する
  • AIとの適切な付き合い方を日々考え試行錯誤していくことが重要

AIによって自分たちの仕事がなくなるのではというネガティブなニュースもありますが、AIを協働パートナーとして考えることで今まで自分たちができなかったことができるようになり、新しい仕事も生まれていくのだと感じました。

自分自身も、学んだ知見を活かしてチーム内でのAI活用推進や知識共有に貢献していきたいと思います。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?