2026年10月27日、日本で初めて開催されたAWSパートナー向けイベント「AWS PartnerEquip: Live – Tokyo 2026」に参加してきました！
AWSといえば、AWS re:InventやAWS Summit Japanなどの大規模イベントが有名ですが、今回のAWS PartnerEquip: Liveは、AWSパートナーを対象とした技術・ビジネスイベントです。
今回が東京での初開催となり、AIを中心とした最新技術や実践的なアーキテクチャについて学べる貴重な機会となりました。
本記事では、イベントの概要と、私が参加した「エージェントを支えるデータ基盤とクラウドインフラストラクチャ」トラックについて、特に印象に残った内容や技術的なポイントを紹介します。
AWS PartnerEquip: Live – Tokyo 2026とは？
AWS PartnerEquipは、AWSパートナー向けの招待制イベントです。
AWSの専門家による技術セッションや参加者同士の交流を通じて、AWSの最新技術、アーキテクチャ、ビジネス活用について理解を深めることができます。
公式サイト：
今回のイベントの3つのトラック
今回の東京開催では、AIをテーマに以下の3つのトラックが用意されていました。
| トラック | テーマ | 主な内容 |
|---|---|---|
| AI for Infrastructure | エージェントを支えるデータ基盤とクラウドインフラストラクチャ | AIエージェントを支える基盤、データ連携、セキュリティ |
| AI for Development | AIを活用したソフトウェア開発の実践 | AIを活用した開発プロセスの効率化 |
| AI for Business | エージェントで変革するビジネス生産性 | AIエージェントによる業務効率化とビジネス変革 |
今回は、インフラエンジニアとして特に興味のあった「AI for Infrastructure」に参加しました。
AIの進化によって、従来のクラウドインフラやアプリケーションアーキテクチャがどのように変化するのか、非常に興味深いテーマでした。
AI for Infrastructure Track Keynote
最初に参加したのは、「AI for Infrastructure Track Keynote」です。
今回のトラックを通じて特に印象に残ったのは、AIエージェントを実際の業務システムに組み込むためには、AIモデルだけでなく、それを支えるインフラやデータ基盤が重要になるという点です。
従来のアプリケーションからAIエージェントへ
これまでの一般的なWebアプリケーションでは、以下のような構成がよく利用されてきました。
ユーザー
↓
Web / Application
（EC2 / ECS / Lambda）
↓
Database
（RDS / DynamoDB など）
ユーザーのリクエストをアプリケーションが受け取り、あらかじめ実装されたビジネスロジックに従って処理を実行します。
一方、AIエージェントを活用したシステムでは、以下のような構成が考えられます。
ユーザー
↓
AI Agent
（Amazon Bedrock AgentCore）
↓
Tools / API / MCP
↓
既存アプリケーション・データ基盤
（Lambda / ECS / RDS / S3 など）
AIエージェントはユーザーの要求を理解し、必要なツールやAPIを選択して処理を実行します。
ただし、AIエージェントが従来のアプリケーションサーバーを完全に置き換えるわけではありません。
むしろ、AIエージェントが新しいインターフェースやオーケストレーション層となり、既存のAWSサービスと連携するアーキテクチャが重要になっていくと考えています。
Amazon Bedrock AgentCoreによるAIエージェントの本番設計
今回、個人的に特に興味深かったのが、Amazon Bedrock AgentCoreに関するセッションです。
セッションタイトルは、
「モデルとハーネスから考える安全なAIエージェントの本番設計 — Amazon Bedrock AgentCore」
Amazon Bedrock AgentCoreとは？
Amazon Bedrock AgentCoreは、AIエージェントを本番環境で安全に実行・運用するためのマネージドサービス群です。
AIエージェントを開発する際には、LLMを呼び出すだけでなく、以下のような機能が必要になります。
| 機能 | 役割 |
|---|---|
| Runtime | AIエージェントの実行環境 |
| Gateway | 外部APIやツールとの連携 |
| Identity | エージェントの認証・認可 |
| Memory | エージェントが利用する記憶の管理 |
| Observability | 実行状況やトレースの可視化 |
| Browser | ブラウザ操作を行うための環境 |
| Code Interpreter | コード実行環境 |
これらの機能を利用することで、AIエージェントの実行基盤をすべて独自開発する必要がなくなります。
Harness（ハーネス）とは？
今回のテーマにも登場した「Harness」という言葉は、AIエージェントを理解するうえで重要な概念だと感じました。
AIエージェントにおけるHarnessとは、LLMを中心に、ツール呼び出し、状態管理、実行制御などを組み合わせ、エージェントとして動作させるための仕組みを指します。
LLM自体が高性能であっても、周辺の実行制御やツール連携が適切に設計されていなければ、安定したAIエージェントを構築することは難しくなります。
そのため、モデルの性能だけでなく、Harnessを含めたシステム全体の設計が重要になります。
AIエージェント時代にインフラエンジニアの役割はどう変わる？
今回のイベントを通じて、個人的に最も考えさせられたのは、今後のインフラエンジニアの役割についてです。
従来のAWSインフラ構築では、以下のようなサービスを組み合わせてアプリケーション基盤を設計することが一般的でした。
- Amazon EC2 / Amazon ECS
- AWS Lambda
- Amazon RDS / Amazon DynamoDB
- Amazon S3
- Amazon VPC
- Amazon CloudWatch
- AWS IAM
今後、AIエージェントを活用したシステムが普及すると、これらに加えてAmazon BedrockやAmazon Bedrock AgentCoreなどのサービスを組み合わせる機会が増えると考えられます。
EC2やECSは不要になるのか？
AIエージェントが普及すると、従来のアプリケーションサーバーが不要になるのではないか、という疑問もあります。
個人的には、完全になくなるわけではないと考えています。
AIエージェントは、ユーザーの意図を理解し、必要な処理を判断する役割を担います。
一方で、データベースへのアクセス、業務ロジックの実行、外部システムとの連携などは、引き続きLambdaやECSなどのサービスが担うケースも多いと考えられます。
ただし、これまでアプリケーション側に実装していた一部の処理やオーケストレーションをAIエージェントが担当することで、システム構成が変化する可能性は十分にあります。
今後のインフラエンジニアには、従来のAWSインフラの知識に加えて、AIエージェントの実行基盤、データ連携、認証認可、Observabilityなどの知識が求められるようになると感じました。
最後に
今回のイベントを通じて、AIエージェントは単にLLMを利用したチャットボットではなく、既存のアプリケーションやデータ基盤と連携する新しいシステム構成の一部になっていくと感じました。
特にインフラエンジニアの視点では、AIモデルそのものだけでなく、AIエージェントを安全かつ安定して動作させるためのインフラ設計が非常に重要になると思います。
今後もAmazon Bedrock AgentCoreやAgentic RAGなどの技術を学びながら、実際のAWS環境で検証していきたいと思います！