はじめに
皆さん、こんにちは！
Hayate Esaki（haya21_8）です。
AIエージェント開発が本格化する中、日本でも実際にプロダクションレベルでAIエージェントを運用する企業が現れ始めています。しかし、日本でAIエージェントを作っている会社は少ないのが現状です。
2025年6月24日、LayerXが主催したAIエージェント開発Nightには約 550名（オンライン含む） が参加し、実際にAIエージェントを開発・運用している3社（Algomatic、LayerX、GMO Flatt Security）が貴重な知見を共有しました。
本記事では、イベント内容を詳細にレポートするとともに、各社の技術選択の背景、最新のAIエージェント開発技術についても深掘りしていきます。
イベント概要
開催日: 2025年6月24日 19:00 ～ 21:20
開催場所: LayerX イベントスペース
東京都中央区築地1-13-1 (銀座松竹ビル 5F)
主催: LayerX
参加者数: 約550名（オンライン含む）
テーマ: Algomatic、LayerX、GMO Flatt SecurityのAIエージェント開発のリアル
参加企業の概要:
-
Algomatic: 営業特化AIエージェント「アポドリ」、採用特化AIエージェント「リクルタAI」を提供
-
LayerX: AIエージェントを活用した「AI BPO」サービスを展開
-
GMO Flatt Security: セキュリティ診断AIエージェント「Takumi」を開発
興味深いことに、会場内でAIエージェント構築をしている参加者は約3割と比較的高い水準で、日本におけるAIエージェント開発の黎明期を物語っています。
LT発表の詳細解説
LT① AIエージェントの「作業場」としてのサンドボックス技術
実行環境設計の課題
AIエージェントを実際に動かす際の最大の技術的課題は実行環境の設計です。GMO Flatt Securityが直面した具体的な分離要件：
計算資源の分離 → エージェント実行による他プロセスへの影響を防ぐ
ユーザごとの分離 → マルチテナント環境での安全性確保
データの分離 → セキュリティとプライバシーの保護
仕事ごとの分離 → タスク間での干渉を避ける
Takumi（AIセキュリティ診断AIエージェント）の技術選択
Takumiの詳細スペック
リリース日: 2025年3月24日
料金: 月額70,000円（税別）
技術スタック: Kubernetes（EKS）
実績: 10日間の実証実験で10件の0-day脆弱性を発見
技術的な課題と解決策:
- 構築環境: Kubernetes（EKS）上で構築
- スケジューリング: PodのScheduleは超高速ではないという制約
- 分離レベル: コンテナレベルでの分離を採用（microVMレベルも検討）
Takumiは単なるセキュリティツールを超えて、GMO Flatt Securityが長年取り組んできた脆弱性診断やリサーチのあり方を根本的に変化させ、これまで以上に世界の安全に資することを目指すという壮大なビジョンを持っています。
LT② Agentic Workflowという選択肢を考える
テーマ: アポドリでの失敗が許されないAIエージェント開発
自立型エージェント vs Agentic Workflow
現在のAIエージェント開発には大きく2つのアプローチがあります：
| アプローチ | 特徴 | 適用場面 |
|---|---|---|
| 自立型エージェント | 知覚→判断→行動を自律的に実行 | 探索的タスク、創造性が重要 |
| Agentic Workflow | 事前設計されたワークフローを順次実行 | 定型業務、失敗が許されない場面 |
なぜアポドリはAgentic Workflowを選んだのか
アポドリが直面していた制約：
- 失敗が許されないビジネス要件
- 作業工程が比較的定まっている
- 顧客への直接的な影響
この制約から、Agentic Workflowを採用し、以下の段階的アプローチを実施：
技術選択とガードレール設計
使用技術: Dify
Difyに関しての記事も執筆しています。ぜひご覧ください。
ガードレール戦略:
- LLMによる一次判定: 自動化可能な部分をAIで処理
- 人間による最終確認: 「ここでミスったら取り返しつかない」部分に人間を配置
- 段階的な信頼度向上: 実績を積み重ねながら自動化範囲を拡大
LT③ AIエージェントのチーム化実験
テーマ: エージェントの協調について
コンセプト: 人間と同じチーム構造
「エージェントが人間と同じなら、複数の人格を持ったエージェントでチーム化できるのでは？」という仮説から始まった実験です。
多様な役割設定の試行
職業ベースの役割分担:
プログラマー → コード生成・デバッグ
デザイナー → UI/UX設計
弁護士 → 法的チェック
会計士 → 財務計算
性格ベースの特化:
ルールを守る人 → コンプライアンス重視
独創的な人 → クリエイティブなアイデア
楽をしたい人 → 効率化の追求
このアプローチの狙いはコンテキストを狭めて専門性を高めることにあります。
座談会で語られた実践的知見
Q1: AIエージェント開発何から始める？
実践者たちの答え:
アプローチ:
まず手でやる → 理解 → しんどい部分・難しい部分を自動化
Claude Codeで始める
その他のアプローチ:
- フロントエンドから: インターフェース設計を先行
- アウトプットから: 最終成果物を定義してから逆算
Q2: AIエージェントの評価極意とは？
評価の難しさは、何を評価するかで変わってくる点にあります。
評価手法の多様化:
- 別のLLMによる評価: エージェント同士での相互評価
- ルールベース評価: 明確な基準による自動判定
- 顧客満足度: 最終的には「お客様がこれで良かったかどうか」
- フィードバックループ: 継続的な改善のための仕組み
Q3: 実行環境の現実解
主流な技術選択:
- AWS ECS: コンテナベースの実行環境
- Azure: ヘッドレスブラウザが必要な場合
- API呼び出し: モデル自体は構築せずAPIを活用
現実的な課題:
コンテナビルドがかなり重くなる
→ AIとは関係ない部分で実行環境が分かれる傾向
Q4: 言語・フレームワークの選択
主要な選択肢:
TypeScript + mastra
mastraについて詳しく
Mastraは、LLMを使ったAIアプリケーションやエージェントを迅速に構築するために設計された、TypeScript製オープンソースフレームワークです
特徴:
- Gatsby開発チームによって2024年に創設され、2025年初頭にY Combinator W25バッチ採択企業としてベータ版が公開されました
- ワークフロー、エージェント、RAGを統合
- 日本でMastraのウェブサイトへのトラフィックが32%を超える注目度
mastraの注目ポイント:
コードの可読性が高く、AIにコード生成を任せるならば整っている方が良いという観点から選択される傾向があります。
Q5: AIエージェント開発にAIエージェントを使う？
メタ的な活用事例:
- 完全活用: 細かい部分だけ人間が調整
- チーム開発: すでに個人ではなくチームでの開発が主流
- 知見共有: 会社全体で自律的にノウハウを蓄積
具体的ツール:
- Devin: 初期のAIエージェント開発ツール
- Claude Code: Anthropicが提供するコマンドライン開発ツール
Claude Codeについて詳しく
ターミナル内で動作し、コードベースを理解し、自然言語コマンドを通じてより高速なコーディングを支援するエージェンティックなコーディングツール
主要機能:
- コードベース全体でのファイル編集とバグ修正
- コードのアーキテクチャとロジックに関する質問への回答
- テスト、リンティング、その他のコマンドの実行と修正
- gitの履歴検索、マージコンフリクトの解決、コミットとPRの作成
料金体系:
- Claude Max プラン: $100/月〜
- API従量課金制も利用可能
Claude Codeに関しての記事も執筆しています。ぜひご覧ください。
Q6: AIエージェントは適切なインターフェイス？
この質問が最も興味深い議論を生みました。
MCPサーバの課題と可能性
MCP（Model Context Protocol） の現状：
- 読み元の品質に依存する問題
- しかし標準化されたプロトコルとしての価値
A2A（Agent to Agent）の革新性
新しいパラダイムの提案:
従来: API連携（厳密に定義されたインターフェース）
↓
新時代: AI連携（文脈を読み取る柔軟なインターフェース）
A2Aの特徴:
- エージェント同士が対話することで議論
- 背景を読み取って、やりたいことを推測
- API連携ではないAI連携の実現
A2Aに関しての記事も執筆しています。ぜひご覧ください。
AIエージェントフレームワーク比較
主要フレームワークの特徴
2025年注目のAIエージェントフレームワーク:
| フレームワーク | 特徴 | 適用場面 | 開発元 |
|---|---|---|---|
| CrewAI | 役割ベースの協調に重点を置いており、人間のチームのような直感的な役割分担で複雑な業務を自動化することを得意としています | チーム型協調作業 | オープンソース |
| AutoGen (AG2) | LLMアプリケーションを複数のエージェント間の会話としてモデル化するフレームワーク | 対話型問題解決 | Microsoft |
| LangGraph | LangChainエコシステムの一般的な低レベルライブラリ | 複雑なワークフロー制御 | LangChain |
| OpenAI Swarm | OpenAI Swarm is new and still experimental | シンプルなエージェント連携 | OpenAI |
| mastra | TypeScript製オープンソースフレームワーク | 統合開発環境 | Y Combinator |
フレームワーク選択の指針
現段階での一般的な推奨は以下の通りです：
実行ロジックを非常に細かく定義する必要がある場合には、LangGraphを使う
具体的な選択基準:
CrewAI： CrewAIは最も扱いやすいツールです。ドキュメントが充実していて、豊富なサンプルもあり、コミュニティも活発です。
AutoGen： AutoGenは、自律的なコード生成において非常に優れた性能を発揮します。
LangGraph： LangGraphは、より細かな制御が可能で、複雑なワークフローの構築に最適だと感じています。
mastra： mastraはTypeScriptベースで学習コストが低く、Vercel AI SDKをはじめとするさまざまな抽象化レイヤーを活用することで、複数のLLMやベクターストアとの連携もスムーズに行えます。
今後の展望と技術トレンド
エージェント間連携の進化
MCP（Model Context Protocol）の標準化:
- AIと外部ツールの安全な連携
- JSON-RPCベースのシンプルな通信
- セキュリティとプライバシーの両立
A2A（Agent to Agent）の実用化:
- 異なるAIエージェント間の直接連携
- 「エージェントカード」による機能認識
- 長期タスクへの対応
追加参考記事・技術リソース
最新のAIエージェント開発フレームワーク
Google Cloud発の新フレームワーク:
マルチエージェントフレームワーク比較:
実践的な開発ガイド
CrewAI関連:
技術比較・選択指針:
ビジネス活用事例
業務用AIエージェント:
開発実践ガイド
開発手順・注意点:
まとめ
AIエージェント開発Nightで明らかになったのは、日本のAIエージェント開発は技術的には十分な水準にあるものの、実用化においては慎重なアプローチを取っているということです。
重要な洞察
- 段階的アプローチの有効性: 「まず手でやる→理解→自動化」の重要性
- 安全性と実用性のバランス: 失敗が許されない環境でのAgentic Workflowの価値
- 技術選択の多様化: 要件に応じた柔軟な技術選択の必要性
- エージェント間連携の可能性: A2AやMCPによる新しいパラダイム
- フレームワークの成熟: CrewAI、AutoGen、LangGraph、mastraなど選択肢の豊富さ
著者について
本記事は、AIエージェント開発Nightの参加レポートをベースに、各種技術資料と最新動向を調査して執筆しました。AIエージェント技術の最新情報や実践的な知見について、継続的に発信していきます。
Discussion