AIエージェントが「インフラ化」する時代に問われること
AIエージェントを「動かす基盤」を自前で作る時代が、静かに終わり始めている。
2026年4月、AWSが「Amazon Bedrock AgentCore Managed Harness」のプレビューを開始した。開発者がやることはシンプルだ。使うモデル（BedrockかOpenAIかGemini）、システムプロンプト、そしてツールのリストを宣言する。それだけで、モデル呼び出し・ツール選択・ReActループ・セッション管理・エラー復旧がすべて自動的に処理される。
社内チャンネルでこのニュースが共有されたとき、「ハーネスって何？」という声があった。AgentCoreの文脈では、エージェントを動かすためのオーケストレーション基盤を指す。ちょっとバズワード気味ではあるが、本質は「今まで自前で書い ていたAIエージェントのインフラコードが、マネージドサービスに吸収された」ということだ。
コンソールから数分でエージェントが動く
具体的に何が変わるのか。従来、AIエージェントをゼロから作ろうとすると、こんな処理を自分で実装する必要があった。
- LLMへのAPIコールとレスポンス処理
- ToolCallが返ってきたときのディスパッチロジック
- 会話履歴（コンテキスト）の管理
- ツール実行の失敗時リトライ
- セッションの永続化
これらをフレームワーク（LangChainやLlamaIndex）で組み上げて、テストして、デプロイして…という工程が、それなりの工数を取っていた。
AgentCoreのManaged Harnessはこれを「設定ファイルで宣言するだけ」に変える。各セッションは独立したmicroVMで動き、ファイルシステムも持つ。セッションが途中で中断しても、状態が保持されて再開できる。シェルコマンドはモデルのトークンを消費せずに実行される設計になっているので、コスト効率も良い。
AWS Consoleから数分で動くエージェントが作れる——これは言葉にするより実際のインパクトが大きい。
同時にGoogleも「データ基盤」を宣言した
少し前、Google Cloud Next 2026で「Agentic Data Cloud」が発表された。AIエージェントが必要とするデータを、クラウドをまたいで統合して提供するプラットフォームだ。AWS・Azure上のデータもApache Iceberg形式で連携でき、コピーせずにそのまま参照できる。
つまり「エージェントを動かす実行基盤」はAWSが、「エージェントが参照するデータ基盤」はGoogleが——それぞれ囲い込みを始めている構図が見えてくる。
インフラとしてのAIエージェントが、着々と整備されている。
「動かすこと」の難易度が下がった先に何があるか
ここで少し立ち止まって考えてほしいのだが、インフラが整備されると何が起きるか。
かつてWebアプリケーションを作るには、サーバーの調達・OSのセットアップ・ミドルウェアの構成が必要だった。AWSのEC2が登場して、これらの「インフラを用意する工数」は大幅に下がった。クラウドネイティブの時代になると、ECSやLambdaがさらにそれを減らした。
それによって「Webアプリを作るスキル」の価値が下がったかというと、逆だ。インフラ構築の障壁が下がったことで、より多くの開発者がより高速にアプリケーションを作れるようになった。差がつくのは「何を作るか」「なぜ作るか」「誰のために作るか」という上流の判断になった。
AIエージェントでも、同じことが起きる。
SIerが本当に問われていること
Managed Harnessで「エージェントを動かすこと」のハードルが下がる。これはSIerにとってチャンスでもあり、脅威でもある。
チャンスの側面: これまで「AIエージェントを導入したいが、インフラ構築が大変で踏み出せない」という顧客に、速く・安く提案できるようになる。PoC段階でのハードルが大幅に下がる。
脅威の側面: 「エージェントを動かす」部分の差別化が難しくなる。技術的なベンダーロックインを前提に提案してきた場合、そのアドバンテージが薄れる。
ではどこで差をつけるか。
正直なところ、「どのエージェントが業務に必要か」を設計する能力だと思う。
マネージドのハーネスにシステムプロンプトとツールを渡すだけでエージェントが動く時代に、何をシステムプロンプトに書くか、どんなツールを与えるか、どの業務フローに組み込むか——これらは顧客の業務を深く理解しなければ設計できない。
「設定する人」から「設計する人」へ
私たちがAIエージェントの開発支援をする中で感じているのは、「何をさせるか」の設計が最も難しく、最も価値があるという点だ。
ツールの選定、コンテキストの渡し方、エラー時の振る舞い、人間が介在すべきポイント——これらはすべて、業務の流れと判断の構造を理解した上でないと設計できない。マネージドのインフラがどれだけ整っても、この部分は自動化されない。
AgentCoreのManaged Harnessが登場しても、AIエージェントの振る舞いを設計する難しさは変わらない。むしろ、「動かすこと」が簡単になった分、「何を動かすか」の設計品質が直接成果に影響するようになる。
要件定義でAIが「効かない」プロジェクトの多くは、技術的な問題ではない。「エージェントに何をやらせたいのか」が曖昧なまま実装に入ることが原因だ。インフラが整備されると、この問題がより明確に浮き彫りになる。
「動かせる」と「動く」は違う
AWSのプレビューページには、コンソールからエージェントを作るデモが示されている。確かに、数分で動くものができる。
ただ、「数分で動くもの」と「業務の中で継続的に価値を出すもの」の間には、大きなギャップがある。
このギャップを埋めるのが、要件定義・業務設計・仕様の構造化——いわゆる上 流工程の力だ。AIが読める仕様書の書き方や、コンテキストをどう設計するかは、インフラが何であれ問われ続ける。
クラウド大手がAIエージェントのインフラを整備してくれるのは、ありがたいことだ。開発チームが「動かすための仕組み」に時間を使わなくて済むようになる。
その分を、「何を動かすか」に使えるかどうか。
それが、これからのAI開発チームに問われていることだと思う。
アツメルでは、AIエージェントの「何を・なぜ・どう動かすか」の設計から支援しています。インフラの話だけでなく、業務に組み込むための上流設計を一緒に考えたい方は、お気軽にご相談ください。
