インフラ屋が書く Amazon Bedrock AgentCore の主要機能を動かして確かめる（1）Runtime・Memory・Code Interpreter・Browser・Observability

Last updated at 2026-10-18Posted at 2026-10-17

変更履歴

2026-10-17：公開
2026-10-17：文言修正
2026-10-18：2 本目へのリンクを足した

初めに

これから仕事で AgentCore に触れる機会がある。ただ、正直あまり知らない。ドキュメントを開いても機能が 13 個並んでいて、どれが何を受け持つのか分からない。そこで、まずは自分で動かしてみることにした。

動かして画面を見るだけでは、「動いた」ことしか分からない。なので、機能ごとに「本当にそう動くのか」を実験で確かめる。量が多いので 2 本に分け、この 1 本目では、エージェントを動かすための 4 つの機能を試す（どんな機能かは 1 章で説明する）。残りの機能は 2 本目で書いた。

結論

検証用の AWS アカウントにエージェントを 2 つ作り、4 つの機能に 1 つずつ問いを立てて試した。問いと結果は以下。

Runtime：会話（セッション）ごとに、本当に別の環境に分かれるか → 分かれた。別の会話からは、置いたファイルが見えなかった。同じ会話でも、しばらく何もしないと（今回は 3 分）環境が作り直され、ファイルは消えた
Memory：記憶は、利用者ごとに分かれるか → 分かれた。会話から好みや事実が 1〜2 分で取り出されて残り、次の会話では本人の分だけが使われた
Code Interpreter・Browser：インターネットに出られるか → Code Interpreter は出られなかった（1 回だけの確認）。Browser は出られた
Observability：何も設定しなくても、エージェントの動きが見えるか → 見えた。デプロイしただけで、トレース（処理の記録）を検索する CloudWatch の設定まで有効になった

4 つの問いには、どれも実験で答えが出た。**ただ、モデルの返事は実際の動きとずれていた。**覚えておけないと答えた好みは記憶されていて、「再度試します」と書いた操作は試されていなかった。本当に動いたかは、返事ではなく記録やトレースを見ないと分からなかった。

本記事の構成

AgentCore の全体像
検証の構成
Runtime（実行環境）のセッションの隔離
Memory（記憶）の利用者ごとの分離
Code Interpreter・Browser の外への出口
Observability（観測）の初期設定
Bedrock Agents（Classic）との違い
費用

1. AgentCore の全体像

項目	内容
目的	AgentCore がどんな機能でできていて、それぞれがどうつながるかを整理する
背景	ドキュメントには機能が 13 個並んでいて、どれが何を受け持つのか分からない
やったこと	機能のつながりを図にし、この記事で扱う 6 つを表にまとめた

AgentCore は、エージェントを作って動かし、運用するための AWS の基盤。サーバーなどのインフラは自分で管理しない。

AgentCore が貸すのは、エージェントを置く場所と、その周りの機能（記憶・ツール・観測など）。エージェントの中身の書き方は縛らない。エージェントを書くためのライブラリ（フレームワーク。Strands Agents・LangGraph・CrewAI など）も、使うモデルも、自分で選べる。今回は Strands Agents と、Bedrock のモデル（Nova 2 Lite）を使った。

機能どうしのつながりを図にすると以下。

利用者やアプリが呼ぶと、Identity が呼んだ人を確かめ、Runtime が会話ごとに環境を立ててエージェントを動かす。エージェントはモデルで考え、Memory で覚えたことを思い出し、Code Interpreter や Browser をツールとして使う。外のツールを呼ぶときは Gateway を通り、Policy がその呼び出しを許すかを決める。動いた記録は Observability に集まり、Evaluations はその記録を使って出来を評価する。

この 1 本目で扱うのは、図のオレンジの 6 つ。

機能	何をしてくれるか	この記事で確かめたこと
Harness（ハーネス）	使うモデル・ツール・記憶を設定に書くだけで、エージェントが動く。「考える → ツールを使う → 答える」の繰り返しは AgentCore が回す	2 章で作り、4・5 章で使う
Runtime（実行環境）	エージェントのプログラムを置く場所。呼ばれたときだけ、会話（セッション）ごとに専用の小さな VM を立てて動かす	3 章：会話ごとに環境が分かれるか
Memory（記憶）	会話をそのまま残す短期の記憶と、そこから好みや事実を抜き出して残す長期の記憶の 2 段	4 章：利用者ごとに分かれるか
Code Interpreter（コードの実行）	エージェントが書いたコードを、隔離された環境で実行する	5 章：外のサイトに出られるか
Browser（ブラウザの操作）	クラウドにあるブラウザを、エージェントが操作する（ページを開いて読む）	5 章：同上
Observability（観測）	エージェントが何をしたか（呼び出し・かかった時間・トークン）を CloudWatch で見られるようにする	6 章：何もしなくて見えるか

東京リージョンでは、Payments 以外が使える（2026-10-17、公式のリージョン対応表で確認）。

2. 検証の構成

項目	内容
目的	3〜6 章の実験に使うエージェントと、その作り方をまとめる
背景	設定だけで作るハーネスでは、中で動くプログラムに手を入れられない。仕事で使うなら、ハーネスとコードのどちらで作るかも選ぶことになる
やったこと	ハーネスとコードのエージェントを 1 つずつ作り、AgentCore の CLI でデプロイした

2 つにした理由を詳しく書くと以下。

3 章の隔離の実験では、環境の中身（起動した時刻や置いたファイル）をエージェント自身に答えさせたい。これは自分でコードを書いたエージェントでないとできない
ハーネスとコードのどちらで作るかを選ぶには、何が違うのかを知りたい。同じ問いを両方に投げて、トレースの大きさ（処理の数）を 6 章で比べる

どちらも同じ Runtime の上で動く。違うのは、「考える → ツールを使う → 答える」の繰り返し（ループ）を AgentCore が回すか、自分のコードで回すか。

どちらのエージェントも、作るのは 1 回。会話（セッション）は、呼ぶたびに --session-id で指定する。1 つのエージェントで、会話はいくつでも持てる。誰の会話かは --actor-id で指定する（4 章）。

agentcore invoke --harness labagent --session-id <セッション ID> --actor-id alice "私に合うおやつを 1 つ勧めて"

labagent：ハーネス。設定だけで作り、ループは AgentCore が回す。中身は Strands Agents¹。ツールに Code Interpreter と Browser を付け、長期の記憶を有効にした。4 章（記憶）と 5 章（ツール）で使う
codeagent：コード。同じ Strands Agents を Python で書き、ループも自分のコードで回す。隔離を確かめるための命令（/whoami など）を持たせた。3 章（隔離）で使う

条件は以下。

リージョン：東京（ap-northeast-1）
日付：2026-10-17
CLI：@aws/agentcore 0.31.1
モデル：Amazon Nova 2 Lite（jp.amazon.nova-2-lite-v1:0）。東京ではクロスリージョン推論²のプロファイル名で指定する

作るのには、AgentCore の CLI（@aws/agentcore）を使った。今回は 2 つのエージェントを同じ条件で並べたい。CLI なら 1 つのプロジェクトにまとめて作れて、設定もファイルとして手元に残る。

CLI のプロジェクトは、設定ファイル（agentcore/agentcore.json）と、それを AWS に作るための CDK（AWS の構成をコードで書く仕組み）の一式でできている。add で設定を足していき、最後の deploy でまとめて AWS に作る流れ。

作ったコマンドは以下。

# 1. プロジェクトの雛形だけを作る（エージェントは後から足すので --no-agent）
agentcore create --project-name QiitaAgentLab --no-agent
cd QiitaAgentLab

# 2. ハーネス labagent を足す。長期の記憶を有効にし、取り出し方（戦略）を 3 つ付ける（4 章で説明）
#    --memory-event-expiry-days 7：会話をそのまま残した記録は 7 日で消える
agentcore add harness --name labagent --memory-mode managed --memory-strategies SEMANTIC,SUMMARIZATION,USER_PREFERENCE --memory-event-expiry-days 7

# 3. labagent にツールを 2 つ付ける（Code Interpreter と Browser）
agentcore add tool --harness labagent --type agentcore_code_interpreter --name code-interpreter
agentcore add tool --harness labagent --type agentcore_browser --name browser

# 4. コードのエージェント codeagent を足す
#    --build CodeZip：コードを ZIP にして置く（コンテナのイメージは作らない）
#    --memory none：記憶は付けない（3 章の隔離の実験を、記憶が邪魔しないように）
#    --idle-timeout 120：何もしないまま 120 秒たつとセッションを終える（既定は 15 分。3 章の実験を短く回すため）
agentcore add agent --name codeagent --type create --build CodeZip --language Python --framework Strands --model-provider Bedrock --memory none --idle-timeout 120

# 5. デプロイ先とモデルを、設定ファイルに書く（下で説明）

# 6. ここまでの設定を、CDK で AWS にまとめて作る
agentcore deploy

5 で書くのは次の 2 つのファイル。

agentcore/aws-targets.json には、デプロイ先（アカウントとリージョン）を書く。

agentcore/aws-targets.json

[
  { "name": "default", "account": "<アカウント ID>", "region": "ap-northeast-1" }
]

name はデプロイ先の名前で、deploy は何も指定しなければ default を使う。

app/labagent/harness.json はハーネスの設定で、modelId に使うモデルを書く。今回は検証なので、安い Nova 2 Lite にした（該当の行だけを示す）。

app/labagent/harness.json

"modelId": "jp.amazon.nova-2-lite-v1:0"

6 の deploy は 4 分ほどで終わった。

1 つハマった。実は、検証用のアカウントは作業の前日に作ったばかりだった。そのアカウントでモデルを呼ぶと、Your account is currently being verified（アカウントを確認中）で断られた。メッセージには「通常 2 時間以内に終わる。過ぎても続くなら aws-verification@amazon.com に連絡を」とある。今回は待つだけで、最初に断られてから 1 時間半ほどで呼べるようになっていた。

新しいアカウントは、AWS の確認が済むまで Bedrock のモデルを呼べない。検証用にアカウントを新しく作るなら、作った日のうちにモデルを 1 回呼んで確かめておくと安心。

3. Runtime（実行環境）のセッションの隔離

項目	内容
目的	会話（セッション）ごとに、本当に別の環境に分かれるかを確かめる
背景	分かれていないと、ある利用者の会話で作ったファイルや途中の結果が、別の利用者の会話から見えてしまう
やったこと	codeagent に、起動時刻を返す命令とファイルを読み書きする命令を足し、2 つのセッションから順に送った

公式の説明では、セッションごとに専用の microVM³ が割り当てられ、計算・メモリ・ファイルは別になる。何もしないまま一定の時間がたつと、そのセッションは終わる。この時間は既定で 15 分、60 秒から設定でき、今回の codeagent は 120 秒にした（2 章のコマンドの --idle-timeout）。

これを次の 2 つで確かめた。

別のセッションから、ファイルが見えないか
同じセッションで、120 秒を過ぎるまで何もしなかったら、ファイルは残るか

codeagent の本体のプログラム（main.py）は、Runtime から呼ばれるたびに invoke を実行する。invoke は利用者の文を受け取り、Strands のエージェント（agent）に渡して、返事を返す。モデルを呼ぶのは agent の中で、main.py が Bedrock の API を直接呼ぶのではない。2 章の「ループを自分のコードで回す」は、この部分のこと。

試すために、agent に渡す手前に、/ で始まる命令を 3 つ割り込ませた。命令にはモデルを呼ばずにプログラムが直接答え、それ以外の文は今までどおりモデルに渡る。隔離の実験にモデルの費用をかけないため。

main.py

@app.entrypoint
def invoke(payload, context):
    text = payload.get("prompt").strip()

    reply = handle_command(text, context.session_id)  # / で始まる命令なら、ここで答えて終わる
    if reply is not None:
        return reply

    result = agent(text)  # それ以外はエージェントに渡す（モデルを呼ぶのはこの中）
    return result.message["content"][0]["text"]

割り込ませた命令は以下。

main.py

def handle_command(text, session_id):
    if text == "/whoami":
        return (
            f"session_id={session_id} host={socket.gethostname()} "
            f"started_at_utc={STARTED_AT} pid={os.getpid()}"
        )
    if text.startswith("/write "):
        with open(NOTE_PATH, "w", encoding="utf-8") as f:
            f.write(text[len("/write "):])
        return f"wrote {NOTE_PATH}"
    if text == "/read":
        if not os.path.exists(NOTE_PATH):
            return f"{NOTE_PATH} は無い"
        with open(NOTE_PATH, encoding="utf-8") as f:
            return f"{NOTE_PATH}: {f.read()}"
    return None

/whoami は、プログラムが起動した時刻（STARTED_AT）を返す。環境が別なら、プログラムもそれぞれで起動するので、起動時刻が違う。つまり、起動時刻が同じなら同じ環境、違えば別の環境と見分けられる。/write と /read は、環境の中のファイル（/tmp/note.txt）に書いて読む。セッション ID は、Runtime から呼ばれる関数（エントリポイント）の引数 context の session_id で受け取れる。

これを 2 つのセッション（A と B）から順に送った。セッション ID は呼ぶときに --session-id で指定する。

順	セッション	送った文	結果
1	A	`/whoami`	起動時刻 03:22:43（UTC）
2	A	`/write セッションAのメモ`	`wrote /tmp/note.txt`
3	A	`/read`	`/tmp/note.txt: セッションAのメモ`
4	B	`/whoami`	起動時刻 03:23:17
5	B	`/read`	`/tmp/note.txt は無い`
6	A	3 分（120 秒を過ぎるまで）待ってから `/read` と `/whoami`	`/tmp/note.txt は無い`・起動時刻 03:26:42

A の中ではファイルが残り、B からは見えなかった。起動時刻も A と B で違い、別の環境で動いていた。

3 分待ったあとの A では、ファイルが消えて起動時刻が変わった。120 秒何もしなかったので A のセッションは終わり、同じセッション ID で呼んだときに新しい環境が立ち上がった。同じセッション ID でも、中身は別物になる。なので、時間をおいて続く会話の途中の結果を、環境の中のファイルに置いておくことはできない。残したいものは、Memory（4 章）や S3 のような、環境の外の置き場に置く必要がある。

送ってから返事が来るまでは、新しいセッションの最初の 1 回が 14〜15 秒、同じセッションの 2 回目からが 9〜11 秒だった（どちらも手元の CLI が起動する時間を含む）。最初の 1 回だけ長い数秒が、環境を新しく立ち上げる分だと見ている。

ハーネスの labagent も、harness_ で始まる名前でランタイムの一覧に並んだ。管理の列は「ハーネス」。ハーネスも、中身は同じ Runtime の上で動いている。

4. Memory（記憶）の利用者ごとの分離

項目	内容
目的	記憶が、利用者ごとに分かれるかを確かめる
背景	分かれていないと、ある人が話した好みや個人の事情が、別の人への返事に混ざってしまう
やったこと	alice と bob の 2 人に好みを話させ、新しいセッションでおやつを勧めさせた。残った記録の中身も読んだ

記憶は 2 段ある。短期はセッションの中の発言をそのまま残し、長期はそこから知識を取り出して残す。取り出し方は「戦略」で選ぶ。今回は SEMANTIC（事実）・SUMMARIZATION（要約）・USER_PREFERENCE（好み）の 3 つを付けた。

短期と長期は、別々のメモリに分かれるのではない。1 つの Memory の中に、形の違う記録として入る。短期は会話をそのまま残した「イベント」で、今回は 7 日で消える設定にした（2 章の --memory-event-expiry-days 7）。長期はそこから取り出した「メモリレコード」で、イベントとは別に残り、意味の近さで検索して引く。

メモリは、ハーネスごとに持たせ方を選ぶ。ハーネスが自分専用のメモリを作って持つ「管理メモリ」、別に作ったメモリを付ける方法（複数のハーネスで共有できる）、メモリを持たない方法の 3 つ。CLI でハーネスを作ると、既定は「持たない」になる。今回は 2 章のコマンドの --memory-mode managed で管理メモリにした。

記憶は、利用者（actorId）とセッションの組で分けて保存される。ハーネスなら、呼ぶときに --actor-id で利用者を指定できる。

alice と bob の 2 人分で、次の順に送った。4 と 5 を新しいセッションにしたのは、同じ会話の中の短期の記憶ではなく、会話をまたいで残る長期の記憶が使われるかを見るため。

alice（セッション S1）：「甘いものが苦手で、辛いものが好き。覚えておいて」
bob（S2）：「コーヒーが好きで、毎朝飲む。覚えておいて」
長期の記録が入るのを待つ
alice（新しいセッション S3）：「私に合うおやつを 1 つ勧めて」
bob（新しいセッション S4）：「私に合うおやつを 1 つ勧めて」

1 を送ったとき、モデルは「私は対話内容を覚えておくことができません」と答えた。2 の bob には、覚えたと答えた。返事が食い違ったので、記録のほうを確かめた。

長期の記録は、会話のあとに裏で（非同期で）取り出される。なので、送った直後にはまだ無い。長期の記録の件数を CLI で 30 秒おきに数えると、alice は送ってから 1 分半ほどで、bob は 2 分ほどで入っていた。

記録の中身は CLI で読める（aws bedrock-agentcore list-memory-records）。

/actors/alice/preferences/ → {"context":"食べ物や料理の選択","preference":"甘いものが苦手で、辛いものが好き。","categories":["食べ物","味の好み","辛い料理"]}
/actors/alice/facts/       → 「ユーザーは甘いものが苦手で、辛いものが好き。」「ユーザーは辛い食べ物を好む。」
/actors/bob/preferences/   → {"context":"毎朝の飲み物を選ぶとき","preference":"コーヒーが好きで、毎朝飲む","categories":["コーヒー","飲み物","朝のルーティン"]}
/actors/bob/facts/         → 「ユーザーはコーヒーが好きで、毎朝飲む習慣がある。」

置き場所（名前空間）は、SEMANTIC が /actors/{actorId}/facts/、USER_PREFERENCE が /actors/{actorId}/preferences/、SUMMARIZATION が /actors/{actorId}/summaries/{sessionId}/。利用者ごとに分かれている。同じ 1 文から、事実は文で、好みは場面と分類の付いた JSON で、別々に取り出されていた。

「覚えておくことができません」と答えた alice の好みも、ちゃんと入っていた。モデルが何と答えても、会話はそのまま記録され、裏で好みや事実が取り出される。覚えるかどうかを決めているのはモデルではなく、ハーネスに付けたメモリの設定のほうだった。

新しいセッションで 4 と 5 を送った結果は以下。

alice：「辛うま肉みそマヨネーズおにぎり」を勧め、甘さを感じない点を理由に挙げた
bob：「モカチーノクッキー」を勧め、「コーヒーとよく合う」と書いた

alice の好みは bob に混ざらなかった。

5. Code Interpreter・Browser の外への出口

項目	内容
目的	Code Interpreter と Browser が、どこまで外（インターネット）に出られるかを確かめる
背景	ツールを持ったエージェントは、モデルの判断で外のサイトにつなぎに行ける。外に出られるツールなら、手元のデータを外へ送ってしまうこともできる
やったこと	ハーネスに付けた 2 つのツールに、計算・外のサイトの取得・ページの閲覧の 3 問を投げた

どちらのツールも、呼ばれるとツールの側にセッションが作られ、既定では 15 分で切れる。

送った文	問い	結果
「1 から 100 までの素数の合計を、Python で計算して答えて」	Code Interpreter が実際にコードを書いて動かすか（正しければ 1060）	1060
「Python の urllib で https://aws.amazon.com/jp/ を取得して、HTTP の状態コードを答えて。コードを実行して確かめて」	Code Interpreter は外に出られるか	出られない
「https://aws.amazon.com/jp/ を開いて、ページの見出しを 3 つ教えて」	Browser なら外に出られるか	出られた（1 回目は失敗）

Code Interpreter のネットワークには、外に出ない「Sandbox」と、外に出られる「Public」がある。ハーネスの組み込みがどちらで動くかは、文書に書いていなかった。既定は「いちばん制限の強い設定」とだけある。2 問目はそれを確かめるための問い。

2 問目は、15 秒ほどで「コード実行環境から aws.amazon.com にリーチできない」と返ってきた。組み込みの Code Interpreter は外に出られない設定で動いていると見てよさそう。

3 問目は 1 回目で失敗した。ブラウザを使うとき、モデルはツールを呼ぶ中でブラウザのセッションに名前を付ける。その名前に _ を入れてしまい、使えない文字だと返された。モデルは「有効な名前に変更し、再度試します」と書いたが、試さずにそのまま返事を終えた。新しいセッションで同じ文を送ると、今度は開けた。ただ、返ってきた見出しは「Cookie の設定を選択する」「Cookie の設定をカスタマイズする」「Essential」だった。ページの本文ではなく、手前に出た Cookie の同意のダイアログを読んでいた。外に出られることは分かったが、ページの中身を正しく読めたわけではない。

3 問目を送ってから 13 分ほどたって、コンソールでツールのセッションを見た。Code Interpreter のセッションは「Terminated」だったが、Browser のセッションは「Ready」のまま残っていた。「ライブセッションを見る」を開くと、リモートのブラウザが aws.amazon.com/jp/ を表示したまま待っていた。

Browser のセッションは、開いている間の分が課金される。エージェントが開いたまま返事を終えると、セッションは残り、その間も課金が続く。

6. Observability（観測）の初期設定

項目	内容
目的	何も設定しなくても、エージェントの動き（トレース）が見えるかを確かめる
背景	返事だけでは、裏で何が動いたかは分からない。それを見るのがトレース
やったこと	デプロイの前後で、トレースの設定の状態を見た。同じ問いを 2 つのエージェントに送り、トレースを比べた

トレースは、1 回の呼び出しの中で何が起きたかの記録。その中の 1 つ 1 つの処理（モデルを呼ぶ、ツールを使う、など）をスパンと呼ぶ。

トレースを見るには、CloudWatch の Transaction Search⁴ が有効になっている必要がある。設定はアカウントのそのリージョン全体にかかり、追加の料金がかかることがある。

ここは文書同士が食い違っていた。AWS の開発者ガイドは「利用者が 1 回有効にする」前提で書いている。CLI の GitHub の文書は「初回のデプロイで自動で有効にする」と書いている。なので、デプロイの前後で状態を見た。見るのは、X-Ray のトレースの送り先を返す次のコマンド。

aws xray get-trace-segment-destination --region ap-northeast-1

"Destination": "CloudWatchLogs" で "Status": "ACTIVE" なら有効。

デプロイの前は "Destination": "XRay" で、有効になっていなかった。デプロイの最後に Note: Transaction search enabled. と出て、直後は "CloudWatchLogs"・"PENDING"、22 分後に見たときは "ACTIVE" だった。Transaction Search を有効にする設定は、何も追加していない。CLI の GitHub の文書のほうが正しかった。

Runtime・メモリ・Code Interpreter・Browser の詳細画面には、どれも「トレース：有効になっていません」と出る。この表示のままでも、トレースは CloudWatch に届き、下の GenAI Observability で見えた。

トレースを見る場所は、CloudWatch の中にあるエージェント向けの画面「GenAI Observability」。エージェントごとの呼び出し回数・時間・トークンと、トレースの一覧が出る。同じ問い「AgentCore の Runtime とは何か、2 文で説明して」を 2 つのエージェントに送り、トレースを並べた。

スパンが多いほど、裏で多くの処理が動いている。同じ問いのトレースは、コードの codeagent が 5 スパン、ハーネスの labagent が 16 スパンだった。同じ 1 問でも、ハーネスのほうが裏の処理が 3 倍ある。ブラウザを使った回（5 章の 3 問目）は 57 スパンになった。

コードのエージェントのトレースも、追加の設定なしで出た。トレースを送るためのライブラリ（aws-opentelemetry-distro）が、agentcore add agent で作った雛形の依存に最初から入っていたため。

7. Bedrock Agents（Classic）との違い

項目	内容
目的	従来の Bedrock Agents と AgentCore の違いを知る
背景	Bedrock には、AgentCore より前から Bedrock Agents というエージェントの仕組みがある。すでに使っている人は、どう違うかが気になる
やったこと	公式の移行ガイドの対応を表にまとめた

従来の Bedrock Agents は「Bedrock Agents Classic」に名前が変わった。2026-07-30 から、過去 12 か月に使った実績のないアカウントでは新しく作れない（CreateAgent が 403 を返す）。使っている人はそのまま使えるが、新しい機能は足されない。

公式の移行ガイドの対応は以下。

Bedrock Agents Classic	AgentCore
管理されたオーケストレーション	ハーネス
アクショングループ	Gateway を通した MCP⁵ のツール
ナレッジベースへの直結	Gateway を通すか、検索のツール
コードインタープリター	Code Interpreter
セッションとメモリ	Memory（短期と長期）
制御の返却（return of control）	ハーネスの inline function

ただし、段階ごとのプロンプトの上書き（前処理・後処理など）は、ハーネスでは直接は再現できない。凝った作りにしていたなら、コードで書いて Runtime に載せ直すことになる。

8. 費用

この検証で送った問いの分のモデルの料金は、合わせて約 $0.075（17.4 万トークン）だった（図A9 の直近 12 時間の集計。トークン数からの推定で、確定した料金とは別）。ほぼ全部がハーネスの分で、codeagent は 3 章の命令がモデルを呼ばないので、ほとんどかかっていない。

Runtime そのものは CPU とメモリの秒単位の課金で、I/O 待ちの CPU は課金されない。エージェントの時間の多くは LLM の返事待ちなので、この課金の仕方はありがたい。

最後に

一番意外だったのは、モデルの返事と実際の動きがずれていたこと。覚えておけないと答えた好みは記憶されていて（4 章）、「再度試します」と書いたブラウザは試されていなかった（5 章）。エージェントを仕事で使うなら、返事を信じるのではなく、記録とトレースで確かめる前提で組むことになりそう。

2 本目では、Gateway で Lambda をツールにつなぎ、Identity・Policy・Evaluations を同じように実験で確かめた（記事）。

参考（2026-10-17 確認）

AWS が公開している、エージェントを作るためのオープンソースのフレームワーク。ハーネスの中身もこれで動いている。 ↩
東京で受けたリクエストを、近くの複数のリージョンに振り分けてモデルを動かす仕組み。モデル ID の代わりに apac. や jp. などで始まるプロファイル名を指定する。jp. は東京と大阪だけに振り分ける。 ↩
小さな仮想マシン。コンテナより隔離が強い。 ↩
CloudWatch の X-Ray のトレースを、全件まとめて検索できるようにする設定。アカウントとリージョンの単位で有効にする。 ↩
Model Context Protocol。AI のアプリと外部のツールをつなぐための共通の決まり。ツールの側を MCP の形にしておけば、どのエージェントからも同じ手順で呼べる。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up