Ai4 2025 ラスベガス参加レポート：AI駆動開発、エージェントについて - MONEX ENGINEER BLOG │マネックスエンジニアブログ

こんにちは、マネックス証券でAI関連の開発を担当している倉田です。

先日、ラスベガスで開催された Ai4 2025（8月11〜13日）に参加してきました。自分のような技術者向けに深い技術解説のセッションもありましたが、マネージャー層を意識したAI導入の事例や課題に焦点を当てたセッションが多くを占めていました。さらに、現在進行中のプロジェクトに直結するヒントも得られ、とても有意義な参加となりました。

本記事では、Ai4を通じて得られた気づきや、実際のプロジェクトでの経験と重なった部分を皆さんとシェアしたいと思います。エージェントに関連した多くの内容を盛り込んだため少々長めになっていますが、お付き合いいただければ幸いです。

今年のキーワードは「エージェント」

今、AI界隈で最も注目されているのが「エージェント」です。 Ai4のKeynoteでも「今年のキーワード」として大きく取り上げられ、多くのセッションがエージェントをテーマにしていました。ですので、ここでは「エージェント」（目標達成のために思考 → ツール実行 → 観察を自立的に繰り返し、計画を立ててタスクが完了するまで遂行する仕組み）についてフォーカスしていきたいと思います。

最初に「AI駆動開発」（既製のコーディングエージェントに、コーディングの大部分を任せる開発手法）を取り上げた後、自社で構築する独自の「エージェント」について取り上げます。

AI駆動開発（コーディングエージェント）へのシフト

Amazonのチャットボット（Rufus）と、現在はMetaでプロダクトマネージャーをしている方と話す機会があり、「LLMによる生成に対する企業の慎重な姿勢」や「Metaによる高額な研究者引き抜きに現場が感じた疑問」など、日本では耳にしづらい現場の話ができたのは貴重な体験でした。中でも特によく話した「AI駆動開発」についてまとめます。

従来使っていたCopilotのエージェントモードは、私のユースケースでは実用性に乏しく、活用には至っていませんでした。しかし、Sonnet 4（AIのモデル）の登場とAIコードアシストツールの発展が重なり、「人間が主体となりAIを補助的に使う」よりも、「開発そのものをエージェントに任せる」方が合理的になるほど、コーディングエージェントの性能が上がりました。

彼からの第一声も「Sonnet 4、使った？」でした。それだけこのモデルの向上をみんなが体感しているのだなと思いました。Sonnet 4を初めてQChat（コーディングエージェント）で試したときは、初めてGPTを触ったときのように大いに感心させられ、その経験をきっかけに技術スタック（開発に使う言語・フレームワーク・ライブラリなどの構成）をAI駆動開発前提に見直しました。互いに「Sonnet 4は開発のやり方を変える転換点だ」という認識で一致しました。

この会話は自分にとって非常にタイムリーでした。というのも、今開発中のプロジェクトでmonorepoやtRPC等を採用した直後だったので、同じように考える人がいたことで、今後はこうしたAI駆動開発と相性の良い技術スタックが、より一般的に使われていくと感じました。

monorepo
フロントエンド・バックエンド・IaC（Infrastructure as Code）・共通ライブラリなどを一つのリポジトリで効率的に開発できるようになります。これにより、LLMに「プロジェクト全体の文脈」を容易に与えられることで実装の精度が上がりますし、プロンプトひとつで複数レイヤー（フロント・バック・インフラ）を一度に開発できるようになる点が非常に革新的です。

tRPC
従来はフロントとバックで同じ型を二重に定義する必要がありましたが、tRPCならサーバー側で一度定義するだけでフロント側でも型安全が保証され、不整合はエディタやビルド時に即検出できます。
また、AWS Lambdaの場合は「ひとつの入り口」でまとめて扱えるため、APIごとに個別の設定が不要になり、IaCのコード量も減らせるのが大きな利点です。
これによりAI駆動開発においても、自動補完が強化され誤実装が減少し、コード量が減ることでLLMが処理する際のトークンやコンテキスト消費も抑えられます。

他にもAI駆動開発と相性が良いと感じた技術が多くあります。技術寄りの内容になるので、本記事の最後の「AI駆動開発を前提とした技術スタック」にまとめました。興味のある方はぜひ参考にしてみてください。

AI駆動開発の最大のメリット「少人数でスピード開発できること」

参加した「Ai4」のセッション “Building Scalable, Enterprise AI Systems Solo with LLMs, AWS Bedrock & Serverless Architecture” では、登壇者（Yahooのエンジニア）が一人でエンタープライズレベルのアプリを構築し、AWS Well-Architected Frameworkの観点で評価され、平均スコア9/10を獲得したという事例が紹介されていました。セキュリティやパフォーマンス、可用性、運用、コスト最適化など、企業システムに必要な要件をサーバレスできちんと満たせるという点が強調されていました。システム構成や考え方など、実務で重なる部分が多く、特に比較的新しいS3 Vectorがとても参考になりました。他にも、セッションで触れられていた SonarLint（エージェント開発の精度向上）やLangSmith（LLM挙動の評価）を今後試してみたいと思っています。

セッションのタイトルが示す通り、「1人でエンタープライズレベルのシステムを構築する」という考え方が、今後さらに浸透していくように感じました。AI駆動開発やサーバレス環境を前提にすれば、少人数でも短期間でアプリを構築・運用できる現実味が増しています。ただ、そのためにはチームメンバー一人ひとりが幅広い領域に触れられるような柔軟さが求められる場面も増えていきそうです。

多くの事例で強調されていたのは、AI駆動開発により開発スピードが劇的に変わる点です。これまで数週間〜数ヶ月かかっていたアプリが、エージェントを活用することで数日〜数週間で形になるケースが紹介されていました。フロントからバックエンド、インフラまで一気に進められる点が、開発効率を高める大きな要因となっています。実際、グループ会社のトレードステーションでは、開発者ひとりで顧客向けLLMアプリを開発からリリースまで担当した事例もあります。こうした取り組みは、すでに「少人数でエンタープライズレベルのアプリを構築できる文化」が広がりつつあることを示していると言えるでしょう。

このようにコーディングに特化したエージェントが「開発」のあり方を変えつつあるように、どの業界においても変革をもたらし得るのが、次に取り上げる自社独自の「エージェント」です。

エージェントを活用しコアビジネスで新たな価値を創出することが鍵

Ai4では、エージェントの可能性と「企業がエージェントをどのように実用化するか」に焦点が当てられていました。

エージェントがテーマだったKeynoteでも触れられていましたが、MITの最新レポートによると、300件以上の企業AIプロジェクトを分析した結果、なんと95％が収益や実質的な成果を生み出せていないことがわかっています。その要因の一つとして、AI投資を「単なる効率化のための導入」にとどめてしまっている点にある、という趣旨の話でした。たとえば、どんなに高性能な問い合わせ対応チャットボットを導入しても、それは「競合他社より問い合わせがしやすい」程度の差にすぎず、企業の優位性につながりにくいです。

登壇者は、AI投資を既存業務の効率化にとどめず、コアビジネスで新たな価値を創出し高いROIを実現することが賢明な戦略だと強調していました。例えば証券会社なら、コアである「投資」に関わる学習・情報収集・資産把握・分析・売買を、従来にない形でより便利に提供できれば、自社の強みにつながる可能性があります。

AIコーディングアシスタントの分野で、Cursorが早くから高いエージェントの性能を発揮し、わずか数年で評価額が99億ドルに到達し、多くの開発者のコーディング方法を変えるような大きな影響を与えました。これは、他分野でもエージェントで同様の変革を起こし得ることを示してると思います。

各企業での実用的なエージェントを実現するには

現状のLLM性能を前提にすると、実用的なエージェントを形にするためには、以下の3要素をどう設計・組み合わせるかが鍵となります。

精緻に設計されたシステムプロンプト

目的や利用シーンに合わせてエージェントの行動を制御。
目的に沿ったツール群の統合

APIや外部サービス、他エージェントと連携し、実際の業務フローに組み込む。
質の高いデータ（RAG）

社内知識やドメイン特有の情報を活用し、エージェントの回答を強化。

これらを巧みに設計・統合・調整することで、各企業は「独自の実用的なエージェント」を生み出せる可能性を秘めています。成果はすぐには現れませんが、試行錯誤を重ねる中で徐々に形になり、もしハマれば企業の競争優位を一変させる力を持っていると思います。

ただし、調整を繰り返す中でその効果を正しく判断するには、全体の影響を把握できる評価・テストの仕組みが欠かせません。セッションでは、特に「Golden Dataset」を定義し、「LLM as Judge」と「Human-in-the-Loop」を組み合わせて自動テストスイートを構築することの重要性が強調されていました。

Golden Dataset

AIモデルや実装したエージェントを評価するための基準となるテストデータセット。入力と理想的な出力のペアを用意し、それに基づいて出力を評価する。
LLM as Judge

GPT-5などの、より大規模で賢いLLMに他モデルの出力を採点してもらう手法。
Human-in-the-Loop

評価や運用などの各段階で人が介入し、品質や安全性を確保する手法。

エージェントの使い分けと工夫

とはいえエージェントは万能ではありません。自立的に複雑な処理を担える一方で、その分だけ従来型の実装に比べて実行時間やコストが増加するというトレードオフがあります。したがって「すべてをエージェントで解決する」のではなく、LLMの強みを活かす領域と従来型プログラムの方が合理的な領域を見極めることが不可欠です。

たとえば、互いに関連性のないタスクでは、無理にエージェント化するより、直列や並列のシンプルなリクエストで処理した方が効率的です。逆に、無数の組み合わせが存在し、文脈理解が欠かせない場面では、エージェントとして構築することで本来の力を発揮できます。

さらにツール設計にも工夫が必要です。例えば、あるツールの出力を必ず別のツールに渡す場合は、その二つの個別のツールを一つにまとめて実装してしまうことで、無駄な思考を省き、トークン消費を抑えながら安定した挙動を実現できます。

要するに、実用化の鍵は「どのユースケースにエージェントが適しているか」を見極めることです。手段ありきではなく、目的から逆算してアプローチを選ぶこと。また、「いかにコストを下げて安定的に実装できるか」を当事者が工夫し調整することが重要だと考えています。

この点については、Anthropic公式ブログ「Writing Tools for Agents」でもツール定義のガイドラインが示されており、実践的な知見が整理されています。

そして、こうしたツールを独自のエージェントや外部アプリ間で共通化する仕組みが、次にご紹介する「MCP」です。

MCP導入をどう考えるか➖まずはエージェントを構築するべき

LLMと外部システムをつなぐ標準仕様である Model Context Protocol (MCP) は、今後のエージェントの開発において重要な位置を占めることは間違いありません。 AIコーディングアシスタントや Claude Desktop などで活用が進んでおり、外部アプリやツールとの連携を簡単にしてくれる点が非常に魅力的です。私も開発の中で、コーディングエージェントがライブラリを活用した実装でうまくいかないときは、Context7やAWSのMCPを使うことがあります。

そこで、自社MCPを構築するメリットは以下のとおりです。

ツールの共通化
エージェントを使ったアプリ開発において、個別にツール定義や処理の実装をする必要がなくなり、工数をかなり削減できます。
多様なプラットフォームとの統合
自社のサービスをClaude DesktopやVS Codeなど、MCP対応のプラットフォームと容易に統合できるようになり、ユーザーの新規獲得にもつながる可能性があります。

MCP導入のトレードオフ

ただし、実際に導入するとなると負担も無視できません。サーバーや認証の仕組みを整える必要がありますし、セキュリティや運用コストもついて回ります。特にエージェントを開発する初期の段階では、ツールの仕様やデータ形式を試行錯誤しながら調整を繰り返すことが多く、MCPとして分離して実装すると開発スピードが落ちてしまいます。

また、複数チームでMCPを共通利用すると「1つのMCPに対して複数が依存する」構造になります。そのため、MCPを調整するたびに他システムへの影響を確認する必要があり、特定プロジェクトの要件だけで柔軟に調整することが難しくなります。

どのタイミングで導入するか

こうした点を踏まえると、アプリを開発する側の意見としては、初期段階で積極的にMCPを取り入れるよりも、まずはアプリ側で直接ツールを実装し、調整しやすい形で進める方が合理的だと考えます。構築したエージェントが十分な精度で公開できる水準に達し、かつ複数チームでの利用ニーズが明確になった段階でMCPへ移行しても遅くはありません。その頃には導入事例も増え、構築を支援するソリューションやフレームワークも整っている可能性が高いでしょう。

それでも「先行導入」の価値はある

一方で、戦略的に早い段階からMCPを構築することも、有効な選択肢です。特にMCP対応プラットフォームでの連携は、AI活用に前向きなユーザー層に響きやすいですし、AIコーディングアシスタントのように一気に広がる可能性もあります。もし先行して整備できれば、証券業界におけるMCP活用の事例として注目される可能性もあります。たとえ社外公開をしなくても、社内でMCPが普及することで非エンジニアにもLLMやエージェントの仕組みが理解されやすくなり、新しいアイデアが生まれるきっかけにもなるでしょう。

Ai4に参加したことによって大いに感じたこと

Ai4 では「エージェント」が大きな注目を集めていました。これは一時的なブームではなく確かな価値を持つ一方、MITの調査が示す通り多くのAIプロジェクトは成果に結びついていません。そこで、実用化に向けて特に重要だと考えられる点は、次の通りです。

エージェントをコアビジネスで活用し、新たな価値を創出する

単なる業務効率化ではなく、コアビジネスそのもので新しい価値を生み出す視点が重要
従来の手法を超える利便性を提供する

高品質な社内データを整備し、エージェントがアクセスできる環境を整える

LLMが理解しやすい形式でデータを整理・調整する
当事者がデータの調整や、不足しているデータを補完できる仕組みを作る

LLM の出力調整と評価・テストを行うための仕組みを構築する

LLMの出力に特化した評価/テスト手法を導入する
現場の専門家が、プロンプトやツール定義、テストデータ等を直接調整できる仕組みを作る
LLMの出力を可視化し、フィードバックループを構築して継続的にエージェントの性能を向上させる
特定のモデルに依存しない、柔軟なシステムを設計する

会社独自のエージェント開発には、従来とは異なる視点と地道な取り組みが欠かせません。Ai4を通じてAIを俯瞰的に捉え、自社におけるAI活用の方向性と、実務に生かせる具体的な知見を得ることができました。特に、一人でもエンタープライズレベルの開発を実現できる事例に触れ、企業でのAI駆動開発の可能性を改めて実感しました。
エージェントに関連した内容を多く取り上げましたが、それだけ、未来に向けて大きな可能性を感じるテーマでした。今回の参加で得た多くの気づきや学びを、熱量そのままにブログとして共有できることを嬉しく思います。

最後に、これからAI駆動開発に取り組むエンジニアの方に向けて、参考になればと技術スタックを整理してみました。ぜひご覧ください。

AI駆動開発を前提とした技術スタック

技術スタック採用の評価軸

文脈提供性（コンテキスト参照性）
- コーディングエージェントが既存のコードベース上で新機能の実装や改修などを行う場合、実装に関係するコードを参照していることが不可欠です。この文脈が不足していると、エージェントは存在しない仕様を勝手に作り上げて誤実装したり、場当たり的な修正を繰り返してスパゲッティコードを生み出す可能性があります。
- 関連情報の一元化: フレームワークによっては、本来は別ファイルで記述される情報（例: UIコンポーネントとCSS）が一つのファイルにまとまっており、エージェントが参照・実装しやすくなります。（例: Tailwind CSS）
- モノリポ構成: フロントエンド、バックエンド、インフラのコードをすべて単一のリポジトリで管理することで、プロジェクトの全体を参照・実装しやすくなります。
普及度
- 人気のあるフレームワークを利用すること自体が、コーディングエージェントにプロジェクト全体の構造に関する「暗黙の文脈」を与えます。エージェントはそのフレームワークの標準的なお作法をすでに学習している可能性が高く、そのため実装の精度が向上し、コードの解析もスムーズになります。
型安全性
- スキーマや型安全な仕組みにより誤実装を防ぎ、エディタ上やビルド時のエラーを検出してコーディングエージェントが自動的に修正できるようになります。
コード量節約
- コード量（冗長なボイラープレート）が少ないほど、コーディングエージェントが一度に読み込める情報量が増え、トークン消費も抑えられます。これにより、より広範囲の改修を一度に、かつ低コストで実装できるようになります。

レイヤー：言語、フレームワーク、ツール、その他

採用技術	文脈提供性	型安全性	コード量節約	※普及度	役割	一言まとめ
TypeScript (JavaScript)	⭐️	⭐️⭐️⭐️		87,424,890	言語（フロント・バック・インフラ）	型が文脈となり、誤実装を防ぐ
Next.js (React)	⭐️		⭐️⭐️	14,709,562	フレームワーク (“next.js”)	Webアプリ開発で定番、構成理解しやすく実装も安定
Tailwind + Radix UI (shadcn)	⭐️⭐️⭐️		⭐️	21,689,390	スタイリング / UIコンポーネント	UIとCSSを一体化、効率よく高品質な画面を構築
AWS CDK (IaC)	⭐️⭐️	⭐️⭐️⭐️	⭐️⭐️	2,248,583	IaC用ツール / ライブラリ	型付きIaCで実装の精度と一貫性を確保
Monorepo (turborepo) + pnpm	⭐️⭐️⭐️	⭐️	⭐️⭐️	4,868,436	モノレポ管理 / パッケージマネージャ	全レイヤーを一元管理し、文脈を共有できる

レイヤー：アプリ

採用技術	文脈提供性	型安全性	コード量の節約	普及度※	役割	一言まとめ
zustand	⭐️	⭐️	⭐️⭐️⭐️	10,104,450	クライアントステート管理	シンプルで軽量、ボイラープレートが少ない状態管理
tRPC	⭐️⭐️⭐️	⭐️⭐️⭐️	⭐️⭐️⭐️	1,238,212	型安全なAPI / ルーティング	フロントとバックを型で直結、誤実装を防ぎ補完も便利
Tanstack Query	⭐️	⭐️	⭐️⭐️⭐️	12,882,600	サーバーステート管理 / データフェッチ	サーバーデータの取得とキャッシュを自動管理
zod	⭐️⭐️⭐️	⭐️⭐️⭐️	⭐️	39,312,978	スキーマ定義 / バリデーション	型とバリデーションを一元化し、矛盾を防ぐ

※普及度：npm 週間ダウンロード数（2025/8/14 ~20）

補足

モデル
- 主に Sonnet 4 を利用
- GPT-5-Codexも急速に追いついてきており、選択肢が広がっている
コーディングエージェント（ターミナル/IDE型）
- QChatやKiroなども試したが、根本的な体験は大きく変わらない
- 現在はカスタマイズ性の高いClaude Codeを利用中（エージェントの性能面での優劣は入れ替わるため、今後切り替える可能性もあります）
プロダクションレベルでの Vibe Coding（生成されたコードを一切把握せずに進めるスタイル）はまだ難しい
- プロジェクトが複雑になるほど、的確に指示をしないとメンテナンス性のないスパゲッティコード化しやすい

システム開発二部　第二プロダクトグループ　倉田賢