【AWS re:Invent 2025】AgentCore でマーケティングキャンペーン作成を効率化した軌跡

こんにちは、アジャイル事業部のみちのすけです。AWS re:Invent 2025 に現地参加しています。

この記事は「Concept to campaign: Marketing agents on Amazon Bedrock AgentCore (AIM365)」のセッションレポートです。

Epsilon（Publicis Groupe の子会社）のプロダクトエンジニアリングチームと AWS のソリューションアーキテクトが、マーケティング自動化における AI エージェント活用について紹介しました。

概要

セッションでは、Epsilon が Amazon Bedrock AgentCore を使ってマーケティングキャンペーン作成を自動化した事例が紹介されました。特に印象的だったのは、キャンペーン作成時間を 30% 削減、パーソナライゼーション能力を 20% 向上させたという具体的な成果です。

マルチチャネルマーケティングの課題から始まり、AI エージェントの基礎、AgentCore の各サービスの説明、そして実際のデモまで、かなり実践的な内容でした。

こんな方におすすめ

• マーケティング自動化に AI エージェントの導入を検討している方
• マルチエージェントシステムのアーキテクチャパターンに興味がある方
• Amazon Bedrock AgentCore の実際の活用事例を知りたい方
• エンタープライズでの AI エージェント本番運用の課題を学びたい方

登壇者

• Jiten Dedhia さん（AWS Senior GenAI/ML Solution Architect）
• Sandeep Veldi さん（AWS Senior Solutions Architect）
• Prashanth Athota さん（Epsilon SVP of Product Engineering）

マルチチャネルマーケティングの課題

セッションは Sandeep さんによるマルチチャネルマーケティングの課題説明から始まりました。マルチチャネルマーケティングとは、顧客が接触するすべてのチャネル（メール、SMS、ソーシャルメディアなど）でシームレスな体験を提供し、一貫したメッセージングを実現する戦略とのことです。

ワークフローオーケストレーションの課題

従来のワークフローは非常に硬直的で、決められたスクリプトに従うしかありませんでした。一方、エージェント AI ベースのワークフローでは、複数のエージェントがリアルタイムで連携し、顧客の行動に応じて動的に適応できます。

特定のマーケティングチャネル専用のエージェントを配置したり、クロスチャネルでコンテキストを保持したりすることで、一貫したメッセージングが可能になります。

リアルタイムパーソナライゼーションの課題

何千もの顧客に対して、複数のチャネルでパーソナライズされたメッセージを配信するのは、従来のシステムでは対応しきれない複雑さがあります。

エージェント AI では、顧客セグメントや行動に応じて動的にコンテンツを生成し、リアルタイムで意思決定を行えます。顧客がメールとソーシャルメディアのどちらで活発に活動しているかを観察し、適切なチャネルに切り替えることができます。

また、ブランドガードレールをエージェント自体に組み込むことで、ブランドの一貫性とコンプライアンスを保証できるという点も面白いと思いました。

データサイロの課題

エンタープライズでよくある問題として、CRM、e コマース、データアナリティクスなど、データが複数のシステムに分散しているという課題があります。

エージェント AI は、API や MCP サーバー（Model Context Protocol）を通じて各システムからデータを取得し、特定の顧客に関する統合されたビューを構築できます。データクレンジングやシステム間のデータマッピングも自動化できます。

この辺りは、多くの企業が抱える課題だと思うので、かなり参考になりそうですね。

市場投入スピードとキャンペーンの俊敏性

従来のマーケティングキャンペーンは、コンテンツ生成、ターゲットオーディエンスのセグメンテーションなど、立ち上げに数週間かかるという課題がありました。これでは市場機会を逃してしまいます。

エージェント AI では、自然言語でキャンペーンを定義できます。たとえば「25 歳以下で Instagram をよく使っているカリフォルニア在住の人をターゲットにしたい」と言えば、エージェントが適切なオーディエンスを特定し、必要なコンテンツを生成してくれます。

キャンペーンパフォーマンスデータがストリーミングで入ってくる場合、AI エージェントがリアルタイムで最適化を行えるという点も魅力的でした。

アトリビューションと ROI 測定の課題

複数のタッチポイント（メール、SMS、店舗など）を経由する顧客ジャーニーにおいて、どのチャネルが効果的だったのかを測定するのは非常に困難です。

エージェント AI では、インテリジェントなアトリビューションモデリングを使って、すべてのタッチポイントと複雑なカスタマージャーニーを考慮できます。リアルタイム ROI 最適化により、パフォーマンスの良いチャネルに予算を再配分することも可能です。

マーケティングの世界では常に ROI が問われるので、この機能はかなり重要だと感じました。

AI エージェンシーの進化

Sandeep さんから、AI エージェンシーの進化についての説明がありました。

従来の ルールベース RPA（Robotic Process Automation） は、タスク指向で硬直的。人間の監督が必要です。

次に登場した 生成 AI アシスタント は、特定のタスクに対して何をすべきかを理解していますが、まだ人間の監督が必要です。カスタマーサービスチャットボットやインテリジェント文書処理などが例として挙げられました。

ゴール駆動エージェント になると、個々のタスクを定義する必要がなく、ビジネス目標を伝えるだけで、エージェントが必要なタスクとワークフローを自動的に決定して実行してくれます。ここで初めて真のビジネス変革が見られるようになったという説明でした。

最終的には 完全自律型エージェントシステム に向かっています。これらは戦略的な意思決定を行い、他のエージェントやツールと連携し、支払いなどの操作も代理で実行できるレベルを目指しています。ただし、現時点ではまだ珍しいとのことです。

この進化の説明は分かりやすかったですね。エージェントがどこまで自律的になれるかというのは、今後の大きなテーマだと思います。

AI エージェントとは何か

LLM（Large Language Model）は、「詩を書いて」と言えば書いてくれますが、「この目標を達成して」と言っても、何をすべきかを具体的に指定しない限り実行できません。

一方、AI エージェントは、自律的または半自律的に計画を立て、最小限の人間の監督で行動し、環境（API、データソースなど）と相互作用しながら独立した意思決定を行えます。

エージェントの本番運用の課題

エージェントを構築するのは比較的簡単ですが、本番環境に持っていくとなると話は別です。何千もの呼び出し、他のエージェントやツールとの相互作用、インフラ管理など、複雑さが一気に増します。

多くの顧客がプロトタイプは作るものの、本番環境には持っていけていないという現状がありました。これは、まさに Amazon Bedrock AgentCore が解決しようとしている課題ですね。

Amazon Bedrock AgentCore とは

AgentCore は、AI エージェントを本番環境で構築、デプロイ、スケール、セキュア、観察するためのモジュラーサービス群です。

重要なポイントは、任意のエージェントフレームワーク（LangGraph、CrewAI、Strands など）と任意の LLM（Bedrock、OpenAI、Gemini など）を使える柔軟性 があることです。必要なサービスだけを選択して使えます。

AgentCore Runtime

フルマネージドサービスで、AI エージェントと MCP サーバーを実行できます。インフラ管理は不要で、エージェントのコードに集中できます。

セッション分離やデータ保護機能が組み込まれており、リアルタイムの対話型エージェントや、最大 8 時間実行される長時間エージェントにも対応しています。

AgentCore Identity

エージェントが Salesforce、Slack、GitHub などの外部サービスや、エンタープライズ API と安全に連携するためのサービスです。

認証・認可のライフサイクル全体を管理してくれるので、トークンの保存、有効期限の管理、再利用などのボイラープレートコードを書く必要がありません。デコレータ関数を参照するだけで済みます。

Okta、Cognito、Entra ID などの既存の ID プロバイダーとも統合できます。開発時間を大幅に短縮できそうですね。

AgentCore Gateway

既存の API や Lambda 関数、外部サービスと統合するための安全なゲートウェイです。

特に便利なのは、API を自動的に MCP 互換ツールに変換してくれる 点です。各 API の前に MCP サーバーを構築する必要がありません。

さらに、何千もの API がある場合、エージェントのコンテキストウィンドウが肥大化してしまう問題がありますが、Gateway はセマンティック検索機能を提供しています。エージェントが「メールを送信したい」と言えば、関連するツールだけを公開してくれます。これはかなり賢いアプローチだと思いました。

AgentCore Memory

エージェントの複数セッションやinvoke 間で情報を保存・取得するためのサービスです。短期記憶と長期記憶の両方をサポートしています。

チャット履歴やエージェントの実行内容を保持する必要がある場合に活用できます。

AgentCore Observability

フルマネージドの observability サービスで、エージェントが何をしているか、どのモデルを呼び出しているか、トークン使用量、入出力、ツール呼び出しなどを一元的に確認できます。

LangGraph や Strands などのフレームワークは既にサポートされており、ログ・メトリクス・トレースは OpenTelemetry 互換です。CloudWatch、Datadog、LangSmith などにもエクスポートできます。

本番環境での observability は必須なので、これが標準で提供されているのは大きいですね。

マルチエージェントシステムのアーキテクチャパターン

ここから Jiten さんによる、マルチエージェントシステムの実装パターンの深掘りがありました。

エージェント間通信

マルチエージェントシステムでは、エージェント間の通信が「神経系」のように重要です。

重要なポイントは、異なるフレームワークで構築されたエージェント（LangGraph、Strands など）を混在させることができる ということです。企業として1つのフレームワークに標準化することもできますが、必須ではありません。

通信方法には2つの選択肢があります。

Boto3 API は、AWS ネイティブの方法で、組み込みのリトライロジックやエラーハンドリングが利用できます。AWS 内でエージェント間通信を行う場合は、これがシンプルでお勧めです。

A2A（Agent to Agent）プロトコル は、オープンソースの標準です。AWS 外部のエージェントと通信する必要がある場合や、クラウド横断的な互換性が必要な場合に使います。

両方を混在させることも可能で、使い分けが柔軟にできる点が良いですね。

レガシーエージェントとの統合

AgentCore 登場前に ECS や EKS で動かしていた既存のエージェントがある場合、新しい AgentCore のエージェントから API 経由で呼び出せます。ツール内から API コールを実装すれば良いとのことです。

既存資産を活かしながら段階的に移行できるのは、現実的なアプローチだと思います。

マルチアカウント構成

複数の AWS アカウントにエージェントを分散配置する必要があるケースもあります。

考えられるユースケースとして、複数チームによる開発（所有権とコスト配分のため）や、特定のアカウントのプライベート VPC 内のデータベースにアクセスする必要がある場合、共有サービス型のエージェントを別アカウントで管理する場合などが挙げられました。

マルチアカウント構成でも、同じように Boto3 または A2A で通信できます。IAM を使う場合はクロスアカウントロールを設定する必要がありますが、それ以外は変わりません。

MCP サーバーとの通信

エージェントは MCP プロトコルを使って MCP サーバーと通信します。これも AgentCore で標準サポートされています。

セキュリティの考え方

セキュリティチームがまず聞いてくることは「エージェントへのアクセスをどう制御するのか」です。認証、認可、きめ細かなアクセス制御が必要になります。

IAM vs OAuth

2つの認証方法が用意されています。

IAM 認証 は、AWS ネイティブの認証です。AWS エコsystem 内で完結する場合や、新しいプロジェクトを始める場合は、セットアップがシンプルで良いとのことです。

OAuth は、既に組織で OAuth プロバイダー（Cognito、Okta など）を使っている場合や、クラウド横断で使いたい場合、オープンソース標準にこだわる場合に適しています。セットアップは少し複雑ですが、標準化されたアプローチを取れます。

重要なのは、両方を混在させることができる という点です。あるエージェントは IAM、別のエージェントは OAuth、といった使い分けが可能です。

MCP サーバーのセキュリティ

標準の MCP は OAuth を使いますが、AgentCore では IAM もサポートするように拡張されています。AgentCore Runtime 内に MCP サーバーをデプロイすれば、IAM 認証だけで統一することもできます。

OAuth の仕組み

OAuth を使う場合、AgentCore がすべてのリクエストをインターセプトし、OAuth トークンの存在を確認します。トークンが存在すれば OAuth プロバイダーで検証し、有効な場合のみエージェントコードの最初の行が実行されます。

つまり、セキュリティチェックは AgentCore が保証してくれる ということです。開発者はセキュリティのボイラープレートコードを書く必要がなく、ビジネスロジックに集中できます。これはかなり大きなメリットだと思いました。

OAuth トークンには、ユーザー生成トークンとマシン間トークンの2種類があります。

ユーザー生成トークンは、アプリケーションからエージェントへの最初の呼び出しで使われ、ユーザーの ID が伝播されます。

マシン間トークンは、エージェント間や、エージェントから MCP サーバーへの通信で使われます。

場合によっては、ユーザーの ID を MCP サーバーまで伝播させて、データベースアクセスをユーザーベースで制限したい場合もあります。その場合はユーザートークンを使い、そうでない場合はマシン間トークンを使えば良いとのことです。

きめ細かなアクセス制御

エージェント内でさらに細かいアクセス制御が必要な場合もあります。たとえば、あるユーザーは操作 A と B の両方を実行できるが、別のユーザーは操作 A のみ実行できる、といったケースです。

AgentCore は、コンテキストからユーザーの ID トークンを簡単に取得できるメソッドを提供しています。開発者はそれを使ってユーザーの権限を検査し、コード内で制御を実装できます。

AgentCore Gateway のセキュリティ

Gateway は OAuth を認証メカニズムとしてサポートしており、すべてを MCP サーバーとして公開します。

エージェントが Gateway 経由でエンタープライズ API を呼び出す場合、マシン間 OAuth トークンを Gateway に渡します。Gateway はそれを検証し、有効な場合のみ API を呼び出します。

さらに、エンタープライズ API 自体が API キーや OAuth で保護されている場合も、Gateway で設定するだけで対応できます。API コード自体を変更する必要はありません。

柔軟性が高く、既存システムとの統合も容易そうですね。

マルチテナンシーのパターン

マルチテナンシーのパターンは、SaaS システムで使われるものと似ています。

オプション1：テナントごとに別インスタンス

同じエージェントを複数インスタンスとしてデプロイし、テナントごとに1つずつ割り当てる方法です。完全な分離と境界を得られます。

オプション2：エンドポイント分離

AgentCore では、1つのエージェントに複数のバージョンを持たせ、各バージョンに複数のエンドポイントを関連付けられます。エンドポイント A はクライアント A 用、エンドポイント B はクライアント B 用、といった使い方ができます。ある程度の分離を保ちつつ、バックエンドは同じエージェントというアプローチです。

オプション3：単一エンドポイント、コード内で制御

単一のエンドポイントで、コード内でテナントを識別して処理を分ける方法です。

重要なのは、AgentCore は invoke ごとに完全に分離されたセッションを提供する という点です。テナント A のユーザーとテナント B のユーザーが同じエージェントを呼び出しても、セッションは完全に分離されます。

そのため、必ずしもオプション1や2を選ぶ必要はなく、オプション3で単純化することも可能です。ただし、より強い分離が必要な場合は、多少の管理オーバーヘッドと引き換えにオプション1や2を選ぶという判断になります。

コストアトリビューション

マルチテナント環境では、コストをテナントごとに配分する必要があります。そのために OpenTelemetry ログを活用し、監査とコスト配分のために十分なログを残すことが重要です。

Observability の重要性

エージェントの observability は、通常のシステムとは少し異なります。

すべてのコンポーネントをトレースし、「なぜエージェントがこの決定をしたのか」「どのシステム、エージェント、ツールを呼び出したのか」といった詳細を把握する必要があります。デバッグだけでなく、監査のためにも必要です。

AgentCore は、標準で CloudWatch ダッシュボードを提供しています。セッションレベルのトレースが可能で、各コンポーネントの実行時間、リクエスト、レスポンスなどの詳細が確認できます。

また、LangFuse などのサードパーティ製 observability システムを使いたい場合も、OpenTelemetry 互換のログを提供しているので、そちらに送ることもできます。

将来的には、他のエージェントを監視するエージェント（メタエージェント）のようなものを目指しています。これは面白いアイデアですね。

Epsilon の実装

ここから Prashanth さんによる、Epsilon 社の具体的な実装例の紹介がありました。

Epsilon について

Epsilon は Publicis Groupe の子会社で、世界有数の広告・マーケティング企業です。データドリブンなマーケティング企業として、データ、テクノロジー、サービスを提供し、クライアントが顧客を理解し、さまざまなコミュニケーションチャネルで顧客と関わるのを支援しています。

クイックサービス、金融、小売、自動車、CPG、旅行、広告など、多くの業界にサービスを提供しています。

Epsilon の強み

カスタマーアイデンティティ が強みです。2億以上のプライバシー保護された ID を保有し、住所、名前、少なくとも1つのトランザクションをリンクしています。95% が検証済み、100% が決定論的（確実）とのことです。

全国消費者データベースには、2億人以上の消費者が自己申告した 1,000 以上の属性と、3兆ドルを超える支出トランザクションが含まれています。

このデータと ID を使って、潜在的な購入者の包括的な単一ビュー（One View）を提供し、誰にいつエンゲージするかを理解（One Vision）し、各個人に関連性の高いパーソナライズされた体験を提供（One Voice）しています。

データ規模がすごいですね。この規模でパーソナライゼーションを実現するには、AI エージェントが不可欠だと納得しました。

エージェント導入の改善領域

Epsilon がエージェントを導入した領域として、以下が挙げられました。

効果的なパーソナライズドメッセージング では、適切なタイミングで適切な個人にターゲットを絞ったメッセージを提供することで、エンゲージメントを向上させています。

動的カスタマージャーニーオーケストレーション では、ユーザートランザクションに関連するユーザー体験を提供し、コンバージョン率を向上させています。

統合システムによるエンゲージメント では、エージェントを統合することで、製品間の連携を改善し、リソース使用量を削減し、より効率的に運用しています。

迅速なイノベーションと自動化 では、Gen AI プラットフォームを構築することで、エージェントをより速く構築し、市場投入までの時間を短縮しています。

構築したエージェント

Epsilon が構築したエージェントの種類は多岐にわたります。

顧客理解とオーディエンス作成 のために、360度カスタマービューとオーディエンス AI エージェントを構築しました。オーディエンス AI は、複雑なデータベース、リレーション、SQL を理解しなくても、プレーンテキストで書くだけでセグメントを作成できます。これはかなり便利そうですね。

キャンペーン作成 のために、ブリーフエージェント、ブランディングエージェント、コンテンツ作成エージェント、キャンペーンエージェント、オンデマンド支援とスケジューリングエージェントなど、複数のエージェントを組み合わせています。

パフォーマンス測定と最適化 のために、キャンペーン実行後のパフォーマンスを測定し、戦略を再調整・最適化するエージェント、キャンペーン分析エージェント、インサイト消費エージェントなどを構築しています。

導入タイムライン

Epsilon の AI エージェント導入の旅は 2024 年に始まりました。

2024 年 Q2 に、オーディエンス作成のための Gen AI プラットフォームを導入（テキストから SQL への変換）。

Q3 には、Bedrock 上でサブジェクトライン生成、画像タギングなどのエージェントを実装。

2025 年 Q1 には、コンテンツ作成や HTML エージェントを導入。

Q3 には、SDLC（ソフトウェア開発ライフサイクル）に AI を導入し、生産性が向上。短期間で 20 以上のエージェントを作成できました。

現在は、AWS と共に 7 つ以上のチームがエージェントプラットフォームを構築しています。

かなり速いペースで展開していますね。

観測された効果

Epsilon が観測した効果は以下の通りです。

エージェントプロトタイピング時間 が、週単位から日単位に短縮されました。

キャンペーンセットアップ時間 が 30% 改善されました。ただし、キャンペーンマネージャーやアナリストの間で採用が進めば、さらに改善が見込まれます。

パーソナライゼーション能力 が 20% 向上しました。

キャンペーン作成時間 も多くの時間を節約できました。

これらはまだ導入初期段階の数字なので、より多くのエージェントを他の領域に展開していけば、さらに大きな改善が期待できます。

30% や 20% という具体的な数字は説得力がありますね。

Epsilon のアーキテクチャパターン

Epsilon の実装では、セッションで説明されたすべてのパターンが使われています。

通信 には Okta を標準化しています。セキュリティ、認証、認可に Okta を使用しています。

エージェント間通信 には Boto3 API を使用。すべてのエージェントが Boto3 API を使って互いに通信しています。

マルチアカウント構成 で、Neptune などのデータベースがプライベート VPC にある特定のアカウントにエージェントをデプロイしています。

Gateway を使って、エンタープライズ API（PeopleCloud Messaging API など）にアクセスしています。

セキュリティ は Okta で統一。MCP サーバー、Gateway、エージェント間通信すべてに Okta を使用しています。

統一されたアーキテクチャで、セキュリティとスケーラビリティを両立させているのが分かりますね。

学んだ教訓

Jiten さんと Prashanth さんから、学んだ教訓がいくつか共有されました。

モノリシックエージェントを避ける

単一の巨大なエージェントを構築するのではなく、小さな作業を行うマイクロエージェントに分割すべきです。

アーキテクチャ図では複数のエージェントを描いているのに、実装では LangGraph のワークフローなどで1つのエージェントに詰め込んでしまうケースが見られます。分離すれば、各エージェントが独立してスケーラブルになります。

これは、マイクロサービスのベストプラクティスと似ていますね。

セキュリティは初日から

セキュリティは初日、いや Day 0 から組み込むべきです。「信頼するが検証する」がセキュリティの原則とのことです。

マルチテナンシーも初日から

マルチテナンシーが必要な場合、最初から組み込むべきです。後から refactor するのは大変とのことです。

ワークフローから成果へ

以前は手動でワークフローを作成することに多くの時間を費やしていましたが、今は自動化と成果ベースのジャーニーにフォーカスを切り替えました。

チームのマインドセットも、「何をするか、どうやるか」ではなく、「どんな成果を求めるか」に変わってきています。

モデルではなく問題にフォーカス

どのモデルが出てくるか、どのモデルを使うかを心配するのではなく、どんな問題を解決しようとしているのか、どんな成果を求めているのか にフォーカスすべきです。その上で、ニーズに合ったモデルを選ぶアプローチが良いとのことです。

確かに、モデルありきで考えるのではなく、ビジネス課題から入るのが正しいアプローチですね。

迅速なプロトタイピング

AgentCore のようなプラットフォームを使えば、プラグアンドプレイの抽象化レイヤー、プランナー、コンプライアンス、レコメンデーション機能を活用して、エージェントを迅速に構築、実験、デプロイできます。

SDLC への統合

Amazon Q を SDLC に統合することで、開発ライフサイクルと AI パイプラインの両方が改善され、イテレーションを高速化し、fail fast（早期に失敗して学ぶ）できるようになりました。

今後の展開

Epsilon の今後の展開として、以下が挙げられました。

あらゆる場所での自律化。エージェントの利用をマーケティングから、データや他のプラットフォーム、ロイヤルティなど、他の領域に拡大していきます。

自己修復・自己監視エージェント の構築。

SDLC パイプラインと運用の統合。プラットフォームの保守と安定性のために動作する自律エージェントを持ちます。

セキュリティとコンプライアンス の強化。

統一インテリジェンスレイヤー。Agent Gateway を使ってすべての製品を統合し、MCP やツールがすべて連携して動作し、同じエージェントに公開されるデータを共有します。

商業化と加速。これらのアーキテクチャパターンを取り入れ、クライアントが使用できるエージェントを構築したり、クライアントが Epsilon のデータや API を使って独自のエージェントを構築できるようにしたりする予定です。また、一部のエージェントはマーケットプレイスで公開して収益化することも検討しています。

かなり野心的なビジョンですね。エージェントがエンタープライズ全体に広がっていくのが想像できます。

まとめ

このセッションでは、マーケティング自動化という具体的なユースケースを通じて、Amazon Bedrock AgentCore の実践的な活用方法を学ぶことができました。

特に印象的だったのは、Epsilon が短期間で 20 以上のエージェントを構築し、キャンペーン作成時間を 30% 削減、パーソナライゼーション能力を 20% 向上させたという具体的な成果です。理論だけでなく、実際の数字で効果を示してくれたのが説得力がありました。

また、マルチエージェントシステムのアーキテクチャパターンについて、通信方法、セキュリティ、マルチテナンシー、observability と、本番運用で直面する課題を網羅的にカバーしていた点も参考になりました。特に「モノリシックエージェントを避ける」「セキュリティは初日から」「マルチテナンシーも初日から」といった教訓は、これからエージェントを本番環境に持っていく際に覚えておくべきポイントだと思います。

AgentCore のモジュラー設計により、必要なサービスだけを選んで使える柔軟性があること、任意のフレームワークや LLM を使える自由度があること、そしてセキュリティや observability が標準で提供されることで、本番運用のハードルが大きく下がることが理解できました。

マーケティング業界に限らず、エンタープライズで AI エージェントを本番運用したいと考えている方にとって、この事例は参考になると思います。ぜひ AgentCore を試してみてください。

参考リンク

• セッション動画
• Amazon Bedrock Agent Core
• AWS Skill Builder – GenAI Learning
• Agent Core GitHub サンプル