この記事は99.9%人間が書きました（画像多いです）
みなさま日々のAIエージェント構築おつかれさまです。
数千兆のAIエージェント稼働には、マネージドなプラットフォームが必須です。
弊社もオレオレプラットフォームでAIエージェントの構築に取り組んでいましたが、そんな時にAWSから新しいサービス Amazon Bedrock AgentCore の発表がありました。
今回は、（個人的に）もっともシンプルに実践できる方法をご紹介します。
こんな方におすすめ
・まずは最小限のシンプルな構成で、Amazon Bedrock AgentCore Gatewayをステップバイステップで試して理解を深めたい。
・シンプルな構成に +1 で外部システムを追加する手順を知りたい。
Amazon Bedrock AgentCore(プレビュー)とは
デベロッパーが Amazon Bedrock または他の場所でホストされているあらゆるフレームワークとモデルを使用して、AI エージェントを大規模、迅速、安全にデプロイおよび運用するのに役立つ、包括的な一連のエンタープライズグレードのサービスです。
Amazon Bedrock AgentCoreは、様々な機能が提供されています。今回は AgentCore Gatewayに着目し、ServiceNowをツールとして活用するAIエージェントを作成してみます。
AgentCore Gateway – 既存の API と AWS Lambda 関数をエージェント対応ツールに変換し、MCP などのプロトコルやランタイム検出にわたる統合アクセスを提供します。
ServiceNowとは
ServiceNowは、企業のデジタルトランスフォーメーションを推進するAIを搭載したインテリジェントプラットフォームです。
IT、人事、カスタマーサービス、ファイナンスなど各部門の業務を一つのプラットフォームに統合し、AIと自動化によって業務プロセスを最適化します。既存システムの上に配置され、総入れ替えの必要なく導入できる「System of Action®」として機能します。
これにより、手作業を自動化して効率を大幅に向上させ、部門間のデータと業務フローをシームレスに連携。従業員は複雑な操作から解放され、より戦略的な業務に集中できるようになります。
ServiceNowは、成長促進とコスト削減を同時に実現する、企業のデジタル変革の中核となるプラットフォームです。
利用するサンプルノートブック
サービス発表前にAWSソリューションアーキテクト勢が総力を結集して作成したであろう以下のリポジトリから、AgentCore Gatewayのサンプルノートブックを利用します。
アーキテクチャ
今回実践するシステムのアーキテクチャは以下の通りです。実行環境には Amazon SageMaker AI ノートブックインスタンスを利用します。基本はサンプルノートブックのままです。追加で、ServiceNowをツールとして追加して、AIエージェント(Strands Agents)がServiceNowに関するタスクを行います。
番号をつけた処理フローを説明します。
- ユーザーは、Amazon SageMaker AI ノートブックインスタンス上で、サンプルノートブックを実行します。AIエージェントにはStrands Agentsが使われています。
- AgentCore Gatewayを利用する前に、Amazon Cognitoで認証を行い、Tokenを取得します。
- 取得したTokenを持ち、AgentCore Gateway を利用します。
- 外部システムを利用するために、AgentCore Identity と AWS Secrets Manager からキー情報を取得します。
- 取得したキー情報を用いて、外部システムを利用します。
実践1：サンプルノートブックの実行(ServiceNowなし)
冒頭に示した、サンプルノートブックを実行してみましょう。リージョンは、「米国（北部バージニア）:us-east-1」としています。
1-1. Amazon SageMaker AI ノートブックインスタンスの構築
マネジメントコンソールから Amazon SageMaker AI を開き、
左メニューから、Notebooksを選択します。
「ノートブックインスタンスの作成」をクリックします。
まず、新しいIAMロールを作成します。
新しいIAMロール作成後、下記の画面のように入力していきます。
ノートブックインスタンス名は、test-agentcore-servicenowとしました。
Git リポジトリも設定しておきます。設定しなくても、JupyterLabのコンソールから git clone すればよいです。
https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
「ノートブックインスタンスの作成」をクリックします。
3分待ちましょう。
作成されました。
IAMロールARNをクリックすると、作成されたIAMロールの詳細を見ることができます。
作成されたIAMロールは以下のような状態です。
「JupyterLabを開く」をクリックします。
Jupyter Labが起動しました
左のメニューから
01-tutorials > 02-transform-apis-into-mcp-tools > 01-transform-openapi-into-mcp-tools >
01-openapis-into-mcp-api-key.ipynb
を開きます。
カーネルは、conda_python3を選択します。
1-2. サンプルノートブック実行 - 準備編
サンプルノートブックを実行していきます。
最初のセルにて、いくつかエラーが出力されますが、ノートブックの実行は可能です。
ちなみに、requirements.txtでインストールされたライブラリのバージョンは以下：
bedrock-agentcore 0.1.2
bedrock-agentcore-starter-toolkit 0.1.7
boto3 1.40.21
strands-agents 1.6.0
strands-agents-tools 0.2.5
uv 0.8.14
uvicorn 0.35.0
次のセルにいきます。
SageMakerノートブックインスタンスなので、AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYの設定は不要です。
リージョンも今回はus-east-1なので変更不要です。us-east-1以外で実施している場合は、リージョンを修正してください。
次のセルを実行します。AgentCore Gateway用のIAMロールを作成をします。
はい、IAMロールの作成権限がないので怒られます。
ノートブックインスタンスのIAMロールに、権限を追加しましょう。
マネジメントコンソールに戻り、ノートブックインスタンスの詳細画面を出します。
IAMロール ARNをクリックします。
IAMのロール詳細画面に遷移しました。
「ポリシーをアタッチ」をクリックします。
検索窓にIAMfull などと入力し、
IAMFullAccessを選択して、「許可を追加」をクリックします。
ポリシーがアタッチされました。
この対応、この後数回発生します。
JupyterLabに戻り、再度セルを実行します。
無事完了しました。
次のセルを実行します。Amazon Cognitoの構築です。
また権限エラーが発生しました。
先ほどと同じ手順で、Amazon Cognito用のロールをアタッチします。
アタッチされました。
JupyterLabに戻り、実行します。
成功しました。
次のセルを実行します。AgentCore Gatewayを作成します。
はい、IAMロールを追加します。
再実行し、成功しました
マネジメントコンソールで、Amazon Bedrock AgentCore を確認すると、Gateway が作成されていることがわかります。
次のセルを実行、、、の前に、ここでNASA Open APIのAPIキーを入力する必要があります。
ノートブックの「here」をクリックして、APIキーを入手してください。登録したメールアドレス宛にAPIキーが送付されてきます。
変数に格納し、セルを実行します。
成功しました。マネジメントコンソールから、AgentCore Identityを確認すると、Outbound Authが作成されていることがわかります。
詳細を見ると、AWS Secrets Managerが利用されていることがわかります。
詳細はこちら。
セルの実行に戻ります。 OpenAPIのスキーマ情報を作成し、Amazon S3に格納します。
ツールを利用するための、OpenAPI スキーマのJSONファイルをS3に保存しました。
マネジメントコンソールからも確認できます。
ちなみに、JSONファイルは以下のとおりです。
{
"openapi": "3.0.3",
"info": {
"title": "NASA InSight Mars Weather API",
"description": "Returns per‑Sol weather summaries from the InSight lander for the seven most recent Martian sols.",
"version": "1.0.0"
},
"servers": [
{ "url": "https://api.nasa.gov" }
],
"paths": {
"/insight_weather/": {
"get": {
"summary": "Retrieve latest InSight Mars weather data",
"operationId": "getInsightWeather",
"parameters": [
{
"name": "feedtype",
"in": "query",
"required": true,
"description": "Response format (only \"json\" is supported).",
"schema": {
"type": "string",
"enum": ["json"]
}
},
{
"name": "ver",
"in": "query",
"required": true,
"description": "API version string. (only \"1.0\" supported)",
"schema": {
"type": "string",
"enum": ["1.0"]
}
}
],
"responses": {
"200": {
"description": "Successful response – weather data per Martian sol.",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/InsightWeatherResponse"
}
}
}
},
"400": {
"description": "Bad request – missing or invalid parameters."
},
"429": {
"description": "Too many requests – hourly rate limit exceeded (2 000 hits/IP)."
},
"500": {
"description": "Internal server error."
}
}
}
}
},
"components": {
"schemas": {
"InsightWeatherResponse": {
"type": "object",
"required": ["sol_keys"],
"description": "Top‑level object keyed by sol numbers plus metadata.",
"properties": {
"sol_keys": {
"type": "array",
"description": "List of sols (as strings) included in this payload.",
"items": { "type": "string" }
},
"validity_checks": {
"type": "object",
"additionalProperties": {
"$ref": "#/components/schemas/ValidityCheckPerSol"
},
"description": "Data‑quality provenance per sol and sensor."
}
},
"additionalProperties": {
"oneOf": [
{ "$ref": "#/components/schemas/SolWeather" }
]
}
},
"SolWeather": {
"type": "object",
"properties": {
"AT": { "$ref": "#/components/schemas/SensorData" },
"HWS": { "$ref": "#/components/schemas/SensorData" },
"PRE": { "$ref": "#/components/schemas/SensorData" },
"WD": { "$ref": "#/components/schemas/WindDirection" },
"Season": {
"type": "string",
"enum": ["winter", "spring", "summer", "fall"]
},
"First_UTC": { "type": "string", "format": "date-time" },
"Last_UTC": { "type": "string", "format": "date-time" }
}
},
"SensorData": {
"type": "object",
"properties": {
"av": { "type": "number" },
"ct": { "type": "number" },
"mn": { "type": "number" },
"mx": { "type": "number" }
}
},
"WindDirection": {
"type": "object",
"properties": {
"most_common": { "$ref": "#/components/schemas/WindCompassPoint" }
},
"additionalProperties": { "$ref": "#/components/schemas/WindCompassPoint" }
},
"WindCompassPoint": {
"type": "object",
"properties": {
"compass_degrees": { "type": "number" },
"compass_point": { "type": "string" },
"compass_right": { "type": "number" },
"compass_up": { "type": "number" },
"ct": { "type": "number" }
}
},
"ValidityCheckPerSol": {
"type": "object",
"properties": {
"AT": { "$ref": "#/components/schemas/SensorValidity" },
"HWS": { "$ref": "#/components/schemas/SensorValidity" },
"PRE": { "$ref": "#/components/schemas/SensorValidity" },
"WD": { "$ref": "#/components/schemas/SensorValidity" }
}
},
"SensorValidity": {
"type": "object",
"properties": {
"sol_hours_with_data": {
"type": "array",
"items": {
"type": "integer",
"minimum": 0,
"maximum": 23
}
},
"valid": { "type": "boolean" }
}
}
}
}
}
この OpenAPI スキーマを使って、AgentCore Gatewayに外部ツールを登録します。Targetと呼ばれます。
セルを実行します。
マネジメントコンソールでGatewayを確認すると、ターゲットが作成されていました。
1-3. サンプルノートブック実行 - 処理プロセス実施編
ここまでで、アーキテクチャの構築が整いましたので、処理プロセスを実施していきます。
まずは、AgentCore Gatewayにアクセスするためのトークンを、Amazon Cognitoから取得します。
AIエージェント（Strands Agentsを利用）を使う準備をします。モデルには、Amazon Bedrock の Amazon Nova を指定します。
エラーが長すぎるので省略...
はい、Amazon Bedrock用の権限がないためですね。
いつもの対応をします。
再びセル実行、応答が返ってきました。
応答は毎回違います。「できません」ということもありました。
おつかれさまでした！サンプルノートブックは、一旦完走しました。
補足：再度サンプルノートブックを先頭から実行したい場合
いくつかのセルで、すでにリソースが存在するためにエラーが発生します。
AgentCore Gateway作成で、すでに存在するエラー
後続で必要なのは、
・gatewayID
・gatewayURL
なので、マネジメントコンソールから取得して次のセルで直接入力してしまいましょう。
以下のように、無理やり変数代入してやればヨシ！
AgentCore Identity作成で、すでに存在するエラー
Identityの作成もエラーが発生。
credentialProviderARNを次のセルで代入すればヨシ！
エラー！
マネジメントコンソール確認！！
ヨシ！！！
AgentCore Gatewayのターゲット作成で、すでに存在するエラー
エラーでも無視でヨシ！
後続で必要な変数宣言などは特にないためです。
1セルずつ先頭から実行
はい、無事にAIエージェントを実行することができました。
実践2：ServiceNowをツール(AgentCore Gatewayのターゲット)登録してみよう
AgentCore GatewayのTargetにServiceNowを登録して、AIエージェントがServiceNowを利用できるようにします。
2-1. ServiceNow側の設定
PDI（個人開発者インスタンス）を取得します。
PDIにログインした状態
All → System OAuth → Application Registry
と進みます。
「New」をクリックします。
[Deprecated UI] Create an OAuth API endpoint for external clients をクリックします。
左上から 三メニュー -> Configure -> Form Layout を選択します。
Form Builder をお勧めされますが、続行します。
OAuth Application User を追加します。
フォームに表示されました。
2-2. Application Registryレコード作成
AWS側の、リダイレクトURIを確認します。以下のドキュメントに記載があります。
https://bedrock-agentcore.us-east-1.amazonaws.com/identities/oauth2/callback
リージョンは利用しているAgentCoreのリージョンに変更しましょう。今回はus-easet-1なのでそのままです。
ServiceNowのフォームに戻り、赤枠部分を入力していきます。
「Submit」をクリックします。
レコードが作成されました。
クリックしてレコードを開き、AWS側の設定で利用する、クライアントIDとクライアントシークレットをメモしておきます。
2-3. ServiceNowシステムプロパティの設定
以下のページにあるように、glide.oauth.inbound.client.credential.grant_type.enabled システムプロパティを作成します。
All で、検索窓に、sys_properties.list と入力します。
レコード一覧が表示されます。
右上の「New」をクリックします。
Name、Type、Valueをドキュメント通りに入力していきます。
「Submit」をクリックします。
作成されたはずのレコードを検索します。
ありました。
これで、システムプロパティが設定されました。
2-4. AgentCore GatewayのTarget登録
AWSマネジメントコンソールで作業していきます。
先ほど作成したAgentCore Gatewayを開き、Targets → Addをクリックします。
Outbound Auth configurationsの項目で、「OAuth client」を選択します。
表示された文章内の、「create new」をクリックし、ページ遷移します。
[補足]ちなみに、2025/8/31現在、以下のようなIntegrationsが用意されています。
「create new」をクリックし、AgentCore Identity ページ遷移しました。
「Add OAuth client」をクリックします。
残念ながらServiceNowは用意されていないので、Custom providerを選択し、設定していきます。
以下の赤枠を設定していきます。
Client IDとClient secretは、先ほどのServiceNow PDIでメモした値を入力します。
Issuer、Authorization endpoint、Token endpointは、それぞれ以下のように入力します。
XXXXXXには、ご自身のPDIの番号を入力します。
Issuer
https://devXXXXXX.service-now.com/
Authorization endpoint
https://devXXXXXX.service-now.com/oauth_auth.do
Token endpoint
https://devXXXXXX.service-now.com/oauth_token.do
ここの疎通が一番時間を溶かしました...
参考ドキュメント
oauth_auth.do
oauth_token.do
マネジメントコンソールに戻ります。
AgentCore Identityの OAuth Clientが作成されました。
OAuthクライアントを作れたので、Gatewayのターゲット作成に戻ります。
（一度更新ボタンを押さないとOAuth clientが表示されないので、再度入力。。。）
Add targetをクリックし、ターゲットが作成されました。
2-5. サンプルノートブックから実行してみる。
先ほどまで実行完了したサンプルノートブックに、以下のセルを追加していきます。
今回は、Claudeモデルを利用してみます。
yourmodel = BedrockModel(
#model_id="us.amazon.nova-pro-v1:0",
model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
temperature=0.7,
)
以下のinstanceはご自身のPDIのインスタンス名devXXXXXXに変更してください。
with client:
# Call the listTools
tools = client.list_tools_sync()
# Create an Agent with the model and tools
agent = Agent(model=yourmodel,tools=tools) ## you can replace with any model you like
print(f"Tools loaded in the agent are {agent.tool_names}")
# Invoke the agent with the sample prompt. This will only invoke MCP listTools and retrieve the list of tools the LLM has access to. The below does not actually call any tool.
print("1.========================================================")
agent("利用できるツールをリストアップしてください。")
print("")
print("")
print("2.========================================================")
agent('''ServiceNowのインシデントテーブルの最新レコードを取得してください。
引数は、以下を利用してください。
{'instance': 'dev202339',
'sysparam_limit': 3,
'sysparam_query': 'ORDERBYDESCopened_at',
'sysparam_fields': 'number,short_description,opened_at,sys_id,state,priority,description,sys_created_by'
}''')
実行してみます。
成功です！利用できるツールとして認識されて、実際にインシデント情報を読み取ることができました！
補足：ツールを指定して実行する
AIエージェントがうまく外部システムから情報を取得できない場合、認証周りの問題なのか、問い合わせクエリの問題なのか、はたまたモデル性能の問題なのか？と切り分けに苦労することがあります（私）。
下記のようにcall_tool_sync()メソッドを用いて明示的にツールを利用すると、ツール自体の正常性は検証することができます。私はこれでLLMがServiceNowに対して適切な問い合わせクエリを送れていないことに気付けました。プロンプトに引数指定しているのはこのためです（改善策検討中...）
import json
with client:
result = client.call_tool_sync(
tool_use_id="list-incidents-1",
name="target-quick-start-i2i37j___listIncidents", ### 【要健康】ツールを指定
arguments={
"instance": "dev202339", ### 【要健康】ご自身のPDIインスタンス
"sysparam_limit": 50, # ServiceNowからは多めに取っておく
"sysparam_query": "ORDERBYDESCopened_at",
"sysparam_fields": "number,short_description,opened_at,state,priority"
}
)
# ServiceNowからの応答を整形して表示
data = json.loads(result['content'][0]['text'])
incidents = data.get("result", [])
# 先頭5件だけ表示
for inc in incidents[:5]:
print(f"{inc['number']}: {inc['short_description']} "
f"(opened_at={inc['opened_at']}, state={inc['state']}, priority={inc['priority']})")
以下のように実行することができます。
以上で、AgentCore GatewayによるServiceNow連携も完了です！おつかれさまでした！！
実践3: 後片付け
サンプルノートブックの後片付けコマンドだけでは不十分なので、マネジメントコンソールから作成されたリソースを削除していきます。
3-1. AgentCore Gateway（サンプルノートブック）
以下のセルを実行します。
マネジメントコンソールで確認します。Gatewayが削除されました。
3-2. AgentCore Identity(AWS Secrets Manager含む)
マネジメントコンソールで作業していきます。
目を見開きながら、「削除、削除、削除」と消していきます。
AgentCore Identityを削除すると、紐づいていた AWS Secrets Manager のレコードも削除されます。
3-3. Amazon Cognito
マネジメントコンソールでAmazon Cognitoに移り、削除します。
削除
3-4. Amazon S3
同上です。バケットを空にして、
削除
3-5. Amazon SageMaker AI ノートブックインスタンス
IAMロールを削除
ノートブックインスタンスを、停止からの削除
削除
完了です。おつかれさまでした！
まとめ
今回は、きたる数千兆AIエージェント時代に必要不可欠になるであろうAmazon Bedrock AgentCore Gatewayを最もシンプルな構成で実践する手順を解説しました。実践して感じたことは、外部システムとの連携には泥くさく対応する必要があるなということです。コーディングエージェントを駆使しながらも、自分でAgentCoreとServiceNowの最新ドキュメントをあさり、仕組みを理解する必要があり、日々のスキル研鑽は今後も必要だと身に沁みました。引き続き、新しい技術にチャレンジしていきます！
参考にさせていただいた記事
[YouTube] Bedrock AgentCore & Strands Agentsハンズオン（JAWS-UG東京）
[YouTube] Building your first production-ready AI agent with Amazon Bedrock AgentCore | AWS Show & Tell