はじめに
Amazon Bedrock AgentCore Managed Harness ありますよね。このハーネスにAgent Skillsを追加して動かしてみました。
Harness発表直後は追加がうまくできなかったのですが、最近になってできるようになった？みたいなので、試してみました。
前提
諸々のバージョンをアップデートしておく
実施前に必ずツールのバージョンを確認しておくことをお勧めします。私はここでつまづきましたので....
| ツール | 最小バージョン | 出典 | 確認/更新コマンド |
|---|---|---|---|
| boto3 / botocore | 1.43.17 以上（s3ソース込み。基本だけなら1.42.94） | botocore CHANGELOG：1.42.94 で Harness API、1.43.17 で S3/Git ソース追加 | venv で pip install -U "boto3>=1.43.17"
|
| aws CLI | 2.34.56 以上（control plane用。s3ソース込み） | aws-cli CHANGELOG：2.34.35 で Harness、2.34.56 で S3/Git 追加 |
aws --version / brew upgrade awscli
|
また、更新履歴は以下のリポジトリからも確認できますので、何かしらアップデートがある際に定期的に確認することをお勧めします。
仮想化環境
実施する際はpythonの仮想環境で実施するのがいいかもしれません。
仮想環境下でharness関連のAPIが見えることを確認しておきます。
cd /hogehoge
python3 -m venv .venv
.venv/bin/pip install -U "boto3>=1.43.23"
# 確認: invoke 系APIが見えるか
.venv/bin/python -c "import boto3;c=boto3.client('bedrock-agentcore',region_name='us-west-2');print([o for o in dir(c) if 'harness' in o or 'runtime_command' in o])"
# => ['invoke_agent_runtime_command', 'invoke_harness'] と出ればOK
demo用のスキルを作成する
今回使用する確認用のスキルですが、わかりやすいものを作成しました。
今回はこいつを使って確認します。
---
name: commit-message
description: hogehogeチームのGitコミットメッセージ規約に従い、1行の日本語コミットメッセージを生成する。コミットメッセージの作成・修正・提案を求められたら必ずこのスキルを使う。
---
# コミットメッセージ作成スキル
## 規約（必須）
1. **1行のみ**。本文やフッターは付けない。
2. 全文を**日本語**で書く。
3. 先頭に必ず **🌙 の絵文字**を付ける（チーム共通の目印）。
4. 形式は `🌙 <種別>: <変更内容を簡潔に体言止め>`。
5. 種別は次のいずれか：**追加 / 修正 / 改善 / 削除 / 文書 / 雑務**。
判定方法
スキルにしか無いルール（先頭に 🌙）を仕込んでおき、invoke の出力に 🌙 が出れば「スキルがロードされた」と判定します。スキル無しだと普通の feat: ... などになります。
準備（検証用のロールを作成する）：任意
今回の検証では（Bedrock呼び出し / コンテナpull / ログ / Workload Identity）これらの権限が必要になるためあらかじめロールの作成をしておきます。
ハーネスからのスキル利用パターンまとめ
公式ドキュメントで明示されているパターンを大きく二種類あるのですが、そのほかにも実現可能な方法は他にも数パターンあるので比較として併記しておきます。
他にもこんな使い方知っとるで〜という方いればぜひ教えていただきたいです！
①セッション開始時にインストールする
ハーネスの microVM に、invoke する前にスキルファイルを書き込んでおく方法。InvokeAgentRuntimeCommand でシェルコマンドを流して配置します。
[SKILL.md] →(コマンド実行で書込)→ microVM:/app/... → Agentが読む ※そのセッションのVMにだけ残る（揮発）
お手軽ですが、配置したスキルはそのセッションのVMにしか残らないので、その都度入れ直しが必要になることだけ注意が必要になります。
②コンテナイメージに直接組み込む
スキルをイメージに COPY で焼き込んで ECR に push し、ハーネスの containerUri に指定する方法。
[SKILL.md] → Dockerイメージに同梱 → ECR → 各microVMに最初から内蔵 → Agentが読む
毎セッション最初からスキルが入っているので、取得も配置も不要。公式でも本番はこちら推奨です。
③S3 or gitのパスを指定する
APIリファレンスを参照すると、harness作成時に指定可能であることがわかります。
skills の各要素（HarnessSkill）は path / s3 / git の3択で、s3/git を指定すると環境に置かなくてもハーネスが起動時に取得してくれます。書き方はこんな感じ：
// path型（①②はこれ。環境に置いたパスを指す）
{ "path": "/app/.agents/skills/commit-message" }
// s3型（s3://バケット/スキルのディレクトリ/ を指す）
{ "s3": { "uri": "s3://my-bucket/skills/commit-message/" } }
// git型（HTTPSのリポジトリ。サブディレクトリや認証も指定可）
{ "git": { "url": "https://github.com/xxx/yyy.git", "path": "skills/commit-message" } }
また、ロールに別途s3:GetObject / s3:ListBucket権限が必要となります。
④S3 Files, EFS（Elastic File System）に配置してマウントする
最近のアップデートでRuntimeからファイルシステムをマウントできるようになりました。
内部的にはRuntimeが動いているので、ハーネスで作成したエージェントでもスキルをマウントできます。これを使って共有のストレージとしてスキルをエージェント間で利用できます。
これに関しては次回記事化しようと思いますが、この構成はNAT Gatewayなど作成した際にコストが発生する為検証する際は注意しましょう。
試しにやってみる
今回は次の2パターン（①セッション開始時 / ②コンテナ焼き込み）を実際にやってみた手順を書いていきます。
それ以外のパターンは次回以降書こうと思います...
前提
マネコン等であらかじめハーネスを作成済としています。本当はマネコンだけで完結したかったのですが、どうやらマネコンだけだとskillsの追加は難しそうだったので今回は省略します。また、記事冒頭で言及しているskillsも作成済としています。
こんな感じでとりあえず作成できていればよしとします。
セッション開始時にインストールする
1. スキルを配置して invoke する（同じ session_id で）
VSCodeかなんかでSkillsを作っておく。
$ cd ~/hogehoge/hugahuga # SKILL.md がある場所
ARN="<マネコンで作ったハーネスのARN>"
SID=$(uuidgen) # 33文字以上必須（uuidは36文字でOK）
B64=$(base64 < skills/commit-message/SKILL.md | tr -d '\n')
# 1) スキルを配置（--exec：runtimeでシェル実行）
$ npx -y @aws/agentcore@preview invoke --harness-arn "$ARN" --region us-west-2 \
--session-id "$SID" --exec \
"mkdir -p /app/s/commit-message && printf %s '$B64' | base64 -d > /app/s/commit-message/SKILL.md"
# 2) スキルを指して実行（--skills：★同じ --session-id を使う）
$ npx -y @aws/agentcore@preview invoke --harness-arn "$ARN" --region us-west-2 \
--session-id "$SID" --skills "/app/s/commit-message" \
"コミットメッセージ書いて: 合計金額の丸め誤差を修正した"
動作の確認
実行後、お月さんマークが出てくれば正常にskillsが読み込まれているということでしょう。
もし出てこなければ何かしらのエラーです。
実際にツールを実行している様子はCloudWatchからも確認できます。
設定画面に出てこないんだけど...
一つ残念なお知らせですが、この適用方法だとマネコンにあるハーネスの設定画面のスキル欄には表示されません。
それもそのはずで、この方法はセッションごとに立ち上がるマイクロVMに対してスキルを適用するからです。
途中で長いセッションIDを指定してましたよね？そういうことです。マネコンに出したいのであれば後述する方法のように、ハーネスそのものに適用するのがいいです。
コンテナイメージに直接組み込む
この方法は少し複雑なので、飛ばしてもらっても構いませんが、ざっくりいうと以下のような手順になります。
Dockerfile作成→ECRにpush→イメージをもとにハーネスを作成→設定にパスを持たせる
1. スキルを焼き込んだイメージを作る
その前に、構成はこんな感じになっていることを想定しています。
commit-skill-agent/ ← プロジェクトのルート（任意の名前）
├── Dockerfile ← スキルを焼き込むイメージ定義
└── skills/
└── commit-message/ ← ディレクトリ名 = スキル名（SKILL.mdのnameと一致）
└── SKILL.md ← スキル本体
Dockerfileはこれだけです。作成後はビルドし、ECRにプッシュしましょう。
FROM public.ecr.aws/docker/library/python:3.12-slim
# スキルを既知のパスに同梱（ディレクトリ名 = スキル名 commit-message）
COPY skills/commit-message/SKILL.md /app/.agents/skills/commit-message/SKILL.md
2. イメージを指定してハーネスを作る
カスタムイメージを使ったハーネスの作成は現状ではマネコン上では難しそうです。そのため、aws cliのリファレンスを引っ張ってきて書いてみましょう。
# これではハーネス作成時にイメージ適用
$ aws bedrock-agentcore-control create-harness --region us-west-2 \
--harness-name skilldemo_image \
--execution-role-arn "$ROLE_ARN" \
--model '{"bedrockModelConfig":{"modelId":"global.anthropic.claude-sonnet-4-6","apiFormat":"converse_stream"}}' \
--environment-artifact '{"containerConfiguration":{"containerUri":"'"${REPO_URI}:latest"'"}}' \
--skills '[{"path":"/app/.agents/skills/commit-message"}]'
$ HID=$(aws bedrock-agentcore-control list-harnesses --region us-west-2 \
--query "harnesses[?harnessName=='skilldemo_image']|[0].harnessId" --output text)
$ aws bedrock-agentcore-control get-harness --region us-west-2 --harness-id "$HID" --query 'harness.status' --output text
動作確認
はい、ということでプレイグラウンドからも自前のスキルをハーネス経由で使えました。
もちろん設定にも適用されております。
結局ハーネスはどうなの？
私の想像としては、もっと気軽に使えるようになるのかもと思っていたのですが、少し違うのかもしれません。（エージェントの作成はさくさくできるけど）
どっちかというと、skillsとかのツールも丸っと内包したエージェントを動かしたり、カスタマイズするための基盤みたいな感じでしょうか...
AWSにおけるハーネスというのは以下の記事でも言及されていますが、
機能追加はコードを書き直す必要はなく、設定の変更だけでいいとあるのでスピードと柔軟性を兼ね備えた基盤というのはあながち間違ってはいなそう（もっといじりたいなら自前のコードでやれということですが）
なので、AgentCore ハーネス = とにかく楽にすぐ作れてなんでもできる！というの少し違うよ。というのだけ知っていただければと思います。
さいごに
これ書いてる時ずっと鼻に風邪薬が詰まってる感覚でした。
参考