この記事で伝えたいこと（ポイント）
- Amazon Bedrock AgentCore Code Interpreterがどんなものか概要を知る
- Amazon Bedrock AgentCore Code Interpreterがどれだけ便利なのかを知る
- 実際にコードを書いて動かしてみる
- 今までやってきたことなども踏まえて気になることを書く
はじめに
この記事ではAWSが提供するAmazon Bedrock AgentCore Code Interpreter（以下、本文ではAgentCore CIと記載）を手を動かしながら、製品概要を見ていく内容となっています。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば修正していく想定です。
今回はAmazon Bedrock AgentCoreがGAしたということで少し前に書いたコードをおさらいしつつ、Amazon Bedrock AgentCore Code Interpreterの概要と使い方を見ていきます。
GAの告知
公式紹介ブログ
XでPOSTもされたよ！！
で、Amazon Bedrock AgentCore Code Interpreterって何者
サクッと結論から言うと、コードを実行するための環境です。
「え、それだと、Lambdaその他と全然変わらないじゃん？!どういうこと？！」と思ったかもしれません。
厳密には「Amazon Bedrockをより拡張性の高いAIプラットフォームとして使うためのAgentCoreに、ビルトインされた機能としてコードを実行するための環境が用意されている」と表現できます。
加えて、Amazon Bedrock AgentCore のご紹介: AI エージェントをあらゆる規模で安全にデプロイおよび運用するという記事によると以下のように説明されています。
エージェントが生成したコードを実行するための独立した環境を提供します。
つまりはAIエージェントが使うコードの実行環境（ツールの実行環境）といえます。
ほいで、Lambdaその他ではダメな理由はなんぞ？
サービス用途の分離といっても、なかなか納得できない人も多いと思います。
そもそも、LambdaがLambdaという名前になる前はS3 Scriptという名前になる予定だったこともあり、他のサービス同士を糊付けするようなものでした。
※今ではGlue Lambda（糊付けLambda）がアンチパターンになることもあります。
ですので、AWSで他のサービスのAPIを実行すると言ったらLambdaであるという側面があるかなと思います。
AIエージェントがAWSのAPIを使ったツールを実行するといった場合においてもLambdaが有効になるでしょう。
ただし、AIエージェントとなった場合は話が変わってくると考えられます。理由をいくつか見ていきましょう。
BedrockによるAIエージェント開発とLambda実行
結論から先に説明すると、以下のようなつらみがBedrockによるAIエージェント開発とLambda実行にはあると考えられます。
- MCPやA2AといったプロトコルでAIのツールを開発する場合においてもサーバレスにしたいが、Lambdaの実行時間900秒の壁にぶち当たる
- じゃあ、Step Functionsを使えばいいかというとそうでもない
- AIエージェントの可観測性の観点で見るといつどこでどのAIエージェントがどのツールを実行したのかがわからない
- 上記に合わせて、「レイテンシを計測したいが難しい。AWS X-Rayを導入していれば、可能か？」かどうかと言われると、できないことはないが難しい
- AIが生成したコード内容に応じてツールを実行したい
こんな感じで3つあります。簡単にそれぞれ見ていきましょう。
MCPとA2A、サーバレスで開発したい
AIエージェントが使うツールというのはいつ実行されるかわからないものです。それらをサーバ上で実行するというのはとてもナンセンスなことです。
また、仮にサーバレスで実際に作るとなった場合は以下のサービスを使って対応できると考えられます。
- AWS Lambda
- ECS（ジョブ実行）
- AWS Batch
- AWS Step Functions
運用に対してのツール実行であれば、以下のサービスも利用できます。
- AWS SSM RunCommmand
- AWS SAW
AIエージェントが複数のツールを持ちながらという要件を実装しようと思ったら個々に実装が必要になるということが容易に想像できると思います。
なお、AgentCore Runtimeを使うと長時間の実行にも耐えられます。少なくとも900秒よりは長いです。
さらに、AgentCore Gatewayを使うとツールに変換することもできます。（MCPサーバの役割になる）
By the way：AgentCore Runtime
AgentCore Runtimeを使うと、AWS Marketplace から事前構築済みのエージェントとエージェントツールを検索、購入、実行できます。（これもいわゆる、AWSにビルトインされたものを使うという話）
AIエージェントの可観測性の観点
次にAIエージェントの可観測性についてです。生成AIのオブザーバビリティというところです。
AgentCoreファミリーにはAgentCore RuntimeやAgentCore Observability、AgentCore Memoryが存在します。
つまり、「閉じられた環境下（Runtime）で可観測性（Observability）を高め、エージェントのセッション（Memory）を管理できる」ということです。
AIエージェントが「どういう状況でどんなコンテキストをもとにどんなことを実行しようとしているのかが見えるようになる」ともいえます。これが従来のAWSサービスでは実現が難しいところでした。
AgentCoreファミリーを最大限に活用することで「AIエージェントの行動を細かく観測できる」ということです。
AIが生成したコード内容に応じてツールを実行したい
これはつまり、動的に生成されたコードを実行するということになります。実のところ、この機能はLambdaで実装しようと思えばできる範囲のことです。
例えば、Pythonの場合はサブプロセスを発行して、サブプロセス内でPythonプログラムと実行したいコードを渡すことで実行することが可能です。具体的には以下のようなコマンドをsubprocess.runで実行できます。
python -c "print('Amazon Bedrock')"
subprocess.runで実行するコードは以下のとおりです。
import subprocess
# Pythonコードを実行
result = subprocess.run(
['python3', '-c', "print('Amazon Bedrock')"],
capture_output=True,
text=True
)
# 実行結果を表示
print("返り値:", result.returncode)
print("標準出力:", result.stdout)
print("標準エラー出力:", result.stderr)
このコードはLambdaでも実行可能であるため、AIが生成したコードを動的に実行させることも可能になりますが、実際にやってみるとエラーハンドリングがとても大変になります。こういった実装を踏まえてもAgentCore CIはとても良いものと言えるでしょう。
ハンズオン
説明が長くなってしまいました。実際に動かしていきましょう。
今回はAWS Identity Centerによるシングルサインオンとアクセスキーを使ってやっていきます。
環境はGitHub Codespacesです。
セットアップ方法：AWS CLI インストールと SSO ログイン手順 (Linux環境)
AgentCore Code Interpreterを動かす
では、実際に書いたコードをベースに話をしていきます。
今回はGA前だったのでリージョンはus-east-1にしていますが、現在は東京リージョンも対応しています。環境によってリージョンを変えると良いでしょう。
このコードを実行すると'Hello,World'という文字列が返ってきます。ただ、気になるところとしてはstart_code_interpreter_sessionやstop_code_interpreter_sessionというところでしょう。
AgentCore Code Interpreterはセッション単位で実行される
もうすでにお気づきかと思いますが、AgentCore CIはセッションを構築した上で実行されます。
※これを見てAWS SDKに詳しい人は「boto3のSessionとは何が違うんだ」と思ったかもしれませんが、それはまた別の機会に検証します。
重要なことはAgentCore CIでセッションを構築してセッションIDを取得したら、そのセッションIDでセッションをStopするということが重要になってきます。
セッションを止めないとセッションだらけになってしまうので気をつけましょう。
※一応、タイムアウトは存在する。
なお、このQiitaの筆者はこれに気づいたので決まったセッションIDだけを削除するスクリプトも作成しました。
他気になること
ハンズオンは以上です。ここからは気になることを書いていきます。
他のアカウントに対してAgentCore Code Interpreterを実行したい
要するにAgentCore CIが有効になっているアカウントで別のAWSアカウントにコマンドを実行するということ（クロスアカウントアクセス）はできるのかどうかというところです。
クロスアカウントアクセスをAgentCore CIで実行する場合において、まだドキュメントを細かく見ていないのでビルトインされた機能があるかはわかりませんが
仮に実装するのであれば、AgentCore CIのセッション上においてAssume Roleすることでクロスアカウントアクセスは実行できるものと考えられます。
具体的にはAWS SDKのSessionオブジェクト（STSを利用したセッション）をAgentCore CIのセッション上において作成することでクロスアカウントアクセスは実現可能だと考えられます。
※STSを利用したセッション構築については「【AWS】手を動かしながら学ぶAWS AWS SDK for Python (boto3)」のクロスアカウントアクセスを意識するを参考
まだ理屈の範囲なので試せたら、ここに進捗を書こうと思います。
AgentCore Code InterpreterのセッションとAWS SDKのセッションの関係
AgentCore CIではセッションを構築してからコードを実行するというものでした。そして、大前提としてAWSのサービスはクライアントとセッションを構築してAPIを実行します。
AWS SDKではSessionオブジェクトで表現されるものであり、このSessionオブジェクトが有効である間はサービスにアクセスできるというものです。
検証方法としてはstart_code_interpreter_session => stop_code_interpreter_session という順番で実行したのち、再度、start_code_interpreter_sessionした際にどういう動きをするかというところです。
筆者の予想だと問題なく接続できるというのが見解ですが、これも理屈の範囲なので試してみたいと思いました。
また、AWS SDK(boto3)のセッションはbotocore.Configによって制御されるのでConfigを修正したことでどんな変化があるのかという点が気になりました。
※botocore.Configについては【AWS】検証！botocoreでboto3のリクエストを制御するを参照
まとめ
今回はAmazon Bedrock AgentCore Code Interpreterの使い方を実際のコードを見ながら学習しました。まだわからないことが多いですが、AIエージェントを作るかどうかに関係なく、夢のあるサービスだと思いました。
最近やっていることにも近いのでもうちょっと検証したいと思います。（クロスアカウントアクセスも含めて）