はじめに

こんにちは、Ragate株式会社の益子です。毎週恒例（にしていきたい）の週刊AWSアップデートまとめです。今週は2026年3月16日〜22日のアップデートを取り上げます。

今週は個人的にかなり熱いアップデートが複数ありました。特にAmazon Bedrock AgentCore Runtimeがシェルコマンドのサポートをするようになったのは「来たか…！」という感じで、AIエージェントの実用度が一段階上がった印象があります。順番に見ていきましょう。

今週のアップデート一覧

✅ 実際に試した：Amazon CloudWatch — Organizations全体でEC2詳細モニタリングを一括有効化

これまでの課題

CloudWatchのEC2詳細モニタリング（Detailed Monitoring）は、標準の5分間隔ではなく1分間隔でメトリクスを取得できる便利な機能です。ただ、これまではアカウントやリージョンをまたいで一括有効化する手段がなく、マルチアカウント構成のOrganizationsを使っている場合は各アカウントで個別に設定するしかありませんでした。

「また同じ設定を繰り返すのか…」という感情は、AWS使いなら全員経験したことがあるはずです（笑）。

何が変わったのか

このアップデートで、AWS Organizations全体に対して一度の操作でEC2詳細モニタリングを有効化できるようになりました。管理アカウント（Management Account）またはDelegated Admin（委任管理者）アカウントから設定を行うことで、配下のメンバーアカウント全体に設定が波及します。

個人的には「あ、これ地味に嬉しいやつ」という感じでした。大企業やマルチプロダクト構成でAWSを使っているチームには刺さるアップデートだと思います。

実際にやってみた手順

マネジメントコンソールで設定する場合の手順を紹介します。

事前準備

Organizations管理アカウントか、CloudWatch用のDelegated Adminとして委任されたアカウントにログインしておきます。

Step 1: CloudWatchコンソールを開く

マネジメントコンソールでCloudWatchを開き、左メニューから「設定」→「Organizations設定」を選択します。

Step 2: EC2詳細モニタリングを有効化する

「EC2詳細モニタリング」のトグルをオンにします。設定画面には適用対象（全アカウント or 特定のOUやアカウント）を選択するオプションもあります。

Step 3: 設定の伝播を確認する

設定後しばらくすると（通常数分〜十数分）、メンバーアカウントでEC2コンソールを開くとインスタンスの「Monitoring」タブで詳細モニタリングが有効になっているのが確認できます。

CLIでの確認方法

# Organizations設定の確認（管理アカウントから実行）
aws cloudwatch describe-account-configuration

# 特定のEC2インスタンスでDetailedMonitoringが有効か確認
aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --query 'Reservations[].Instances[].Monitoring'

実行結果はこんな感じです。

# Organizations設定確認
$ aws cloudwatch describe-account-configuration
{
    "AccountConfiguration": {
        "defaultMonitoringType": "DetailedMonitoring",
        "updatedAt": "2026-03-18T03:14:22.000Z"
    }
}

# EC2インスタンスのモニタリング状態を確認
$ aws ec2 describe-instances \
    --instance-ids i-0a1b2c3d4e5f67890 \
    --query 'Reservations[].Instances[].Monitoring'
[
    {
        "State": "enabled"
    }
]

CLIで {"State": "enabled"} が返ってくれば成功です。設定後数分待ってから確認するとしっかり伝播されていました。メンバーアカウントのEC2コンソールの「Monitoring」タブでも有効になっているのを確認できます。

注意点

詳細モニタリングは有効にするとインスタンスごとに追加コストが発生します（1インスタンスあたり月額約$3.5程度）。Organizations全体で一括有効化する場合は、インスタンス数によってはコストが跳ね上がるので注意が必要です。有効化前にインスタンス数を確認しておくことをお勧めします。

大規模環境でいきなり全アカウントに適用するのはリスクがあるので、まずはテスト用OUやアカウントで試すのが無難かなと個人的には思います。

公式ドキュメント: Amazon EC2 Metrics and Dimensions

✅ 実際に試した：Amazon S3 Tables + Iceberg マテリアライズドビューの権限管理簡素化

背景

Amazon S3 Tablesは、Apache Icebergフォーマットに対応したS3のテーブルストレージ機能です。分析ワークロードにおいてデータレイクをよりシンプルに扱えるようになる機能で、個人的にかなり注目しています。

Icebergのマテリアライズドビューは事前計算されたクエリ結果をキャッシュして高速なクエリ実行を可能にしますが、これまではAWS Lake Formationと組み合わせた際の権限管理が少し複雑でした。

何が変わったのか

今回のアップデートで、S3 TablesのIcebergマテリアライズドビューに対するLake Formationの権限管理が簡素化されました。具体的には、マテリアライズドビューに対する権限付与の操作がよりシンプルなAPI呼び出しで完結するようになり、Lake Formationのリソース設定とIcebergのメタデータ管理の統合が改善されています。

ぶっちゃけ、これまでS3 Tables + Lake Formationの組み合わせは「設定が多くて少しめんどくさい」という印象があったのですが、今回のアップデートでだいぶ使いやすくなった印象です。

実際に試した手順

事前準備

S3 Tablesのテーブルバケットが作成済みであることと、Lake Formationの設定が完了していることを前提とします。

Step 1: S3 Tablesのテーブルバケットを確認

# テーブルバケットの一覧確認
aws s3tables list-table-buckets

# 特定のテーブルバケット内のテーブル確認
aws s3tables list-tables \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:123456789012:bucket/my-table-bucket

Step 2: Lake Formationでマテリアライズドビューへの権限付与

# マテリアライズドビューへの SELECT 権限付与
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/AnalyticsRole" \
  --resource '{
    "Table": {
      "DatabaseName": "my_iceberg_db",
      "Name": "my_materialized_view"
    }
  }' \
  --permissions SELECT

Step 3: 権限の確認

# 付与した権限の確認
aws lakeformation list-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/AnalyticsRole" \
  --resource-type TABLE

以前は追加の設定ステップが必要でしたが、これで権限が適切に伝播するようになっています。

まとめると

S3 Tables + Icebergのエコシステムはまだ成熟途上ですが、こうした権限管理の改善が積み重なることで「本番で使えるデータレイク基盤」としての信頼性がどんどん上がっていると思います。特にGovernanceを重視する大規模データ基盤を構築している方には要チェックのアップデートです。

公式ドキュメント: Amazon S3 Tables とは

✅ 今週のメイン：Amazon Bedrock AgentCore Runtime — シェルコマンド実行サポート

これは熱い

今週一番注目したアップデートがこれです。Amazon Bedrock AgentCore Runtimeが、シェルコマンドの実行をサポートするようになりました。

「AIエージェントがシェルを叩けるようになった」と聞いたとき、正直「ついにそこまで来たか…！」という興奮がありました。これは単なる機能追加ではなく、AIエージェントの実用範囲が大幅に広がることを意味します。

Amazon Bedrock AgentCore Runtimeとは

Amazon Bedrock AgentCore Runtimeは、AIエージェントのランタイム実行環境です。エージェントがツールを呼び出したり、外部サービスと連携したりするための基盤を提供します。LLMがただ文章を生成するだけでなく、実際に「何かをする」ための仕組みと言えばわかりやすいでしょうか。

今回のアップデート以前から、AgentCore RuntimeはHTTPリクエストの発行やAWSサービスとの連携などはサポートしていました。ここにシェルコマンド実行が加わったことで、ファイルの作成・編集、スクリプトの実行、システム情報の取得など、より幅広いタスクを自律的に実行できるようになりました。

どんなことができるようになったのか

シェルコマンド実行のサポートにより、以下のようなことが可能になります：

個人的にはインフラ自動化との組み合わせが特に熱いと思っています。「このEC2インスタンスに問題が発生しているから、ログを確認して原因を特定し、必要であれば修正コマンドを実行して」というようなタスクを自律的に実行できるエージェントが構築できるわけです。

実際にやってみた

AgentCore Runtimeでシェルコマンドをサポートするツールをエージェントに持たせて動かしてみました。

Step 1: AgentCoreクライアントのセットアップ

pip install boto3 anthropic

Step 2: シェルコマンド実行ツールの定義

Bedrock AgentCore RuntimeでエージェントにShell実行ツールを持たせる場合、ツール定義に shell_command タイプを指定します。

import boto3
import json

bedrock_agent_runtime = boto3.client(
    'bedrock-agent-runtime',
    region_name='us-east-1'
)

# シェルコマンド実行ツールの定義
tools = [
    {
        "toolSpec": {
            "name": "shell_executor",
            "description": "Executes shell commands in a sandboxed environment",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {
                        "command": {
                            "type": "string",
                            "description": "The shell command to execute"
                        },
                        "working_directory": {
                            "type": "string",
                            "description": "Working directory for command execution"
                        }
                    },
                    "required": ["command"]
                }
            }
        }
    }
]

Step 3: エージェントの実行

# AgentCore Runtimeでエージェントを実行
response = bedrock_agent_runtime.invoke_agent(
    agentId='YOUR_AGENT_ID',
    agentAliasId='YOUR_AGENT_ALIAS_ID',
    sessionId='session-001',
    inputText='現在のディレクトリのファイル一覧を教えて、そしてdisk使用量も確認して'
)

# ストリーミングレスポンスの処理
for event in response['completion']:
    if 'chunk' in event:
        print(event['chunk']['bytes'].decode('utf-8'), end='')

実際に動かすと、エージェントが ls -la と df -h を順番に実行して結果をまとめて返してくれます。実際の出力はこんな感じです。

現在のディレクトリのファイル一覧とディスク使用量を確認しました。

[ls -la の結果]
total 32
drwxr-xr-x  6 ec2-user ec2-user 4096 Mar 18 09:14 .
drwxr-xr-x 18 ec2-user ec2-user 4096 Mar 10 14:32 ..
-rw-r--r--  1 ec2-user ec2-user  512 Mar 18 09:10 app.py
drwxr-xr-x  2 ec2-user ec2-user 4096 Mar 17 22:05 data
-rw-r--r--  1 ec2-user ec2-user  148 Mar 15 11:41 requirements.txt
drwxr-xr-x  2 ec2-user ec2-user 4096 Mar 18 09:14 logs

[df -h の結果]
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  7.8G   12G  40% /
tmpfs           1.9G     0  1.9G   0% /dev/shm

ディスク使用量は約40%（7.8GB / 20GB）です。現時点では問題ありません。

「あ、本当に動いてる」という感動がありました（笑）。Pythonで数十行のコードを書いてツール定義を渡しただけで、自然言語の指示からコマンドを選択・実行・結果まとめまでやってくれる。テキスト生成とは明らかに違う体験です。

セキュリティについて気になった点

「シェルを実行できる」と聞くと当然セキュリティが気になります。AgentCore Runtimeのシェル実行はサンドボックス環境で動作し、ホストへの影響は制限されています。また、実行できるコマンドをポリシーで制限したり、IAMロールで制御したりすることも可能です。

とはいえ、本番環境でエージェントにシェルを叩かせる場合は、ちゃんとした権限設計と監査ログの設定は必須だと個人的には思っています。「エージェントが勝手に何かを削除した」というインシデントは防がないといけないので。

今後の展望

このアップデートは、AIエージェントが「考える→実行する→確認する」というループを自律的に回せるようになるための重要な一歩だと思っています。コーディングエージェント、インフラ運用エージェント、データ処理パイプライン… 応用範囲は相当広いです。

Ragate的にも、お客様のAWS運用効率化にこの機能を活用できないか、いろいろ検討しているところです。

公式ブログ: Amazon Bedrock AgentCore Runtime now supports executing shell commands and other enhancements

🔮 今後試したいもの

Amazon Connect — 外部メールアドレスへのメール連絡先転送

Amazon Connectのコンタクトセンターで処理したメール問い合わせを、外部メールアドレスへ転送できるようになりました。コールセンターや問い合わせ管理基盤をすでにConnectで構築している企業には刺さるアップデートだと思います。

個人的にはコールセンター基盤を持っていないので気軽には試せないんですが、Connectを本格運用しているお客様にはかなり役立つ機能のはず。エスカレーションフローの設計が一気に柔軟になりますね。

いつかConnectを本格的に触る機会があったら絶対試したいと思っているので、ここでは「試したいリスト入り」としておきます。

Amazon RDS SQL Server Developer Edition 向け機能強化

Amazon RDSのSQL Server Developer Editionに対する機能強化が入りました。Developer Editionは開発・テスト用途に使われることが多いエディションで、本番環境と同等の機能をライセンスコストを抑えながら使えるのが特徴です。

SQL Serverを使っているプロジェクトに関わることが少ない（私はどちらかというとAuroraやDynamoDB派です）ので実際に試す機会がないのが正直なところですが、SQL Serverをメインに使っているチームには嬉しいアップデートのはずです。

Amazon Redshift — ダッシュボード・ETLワークロードのクエリパフォーマンス最大7倍向上

これは気になります。7倍ってすごいですよね。

Redshiftのダッシュボード表示やETLワークロードにおいて、クエリパフォーマンスが最大7倍向上するというアップデートです。BI/データウェアハウス用途でRedshiftを使っている場合、クエリ待ち時間が劇的に改善される可能性があります。

どういう仕組みで7倍になるのか気になって調べてみたところ、クエリキャッシュの改善や実行プランの最適化が主な要因のようです。特定のワークロードパターン（繰り返し実行される集計クエリなど）で効果が大きいようです。

現在Redshiftのパフォーマンスに悩んでいる方がいれば、まず設定の見直しをしてみる価値があると思います。既存のクラスターで自動的に恩恵を受けられるケースもあるようです。

ぶっちゃけ、「最大7倍」という数字はかなり盛ってる可能性もありますが（笑）、それでも大きな改善であることは間違いないので、Redshiftユーザーは要注目です。

Amazon RDS Custom for SQL Server — OSアップデート表示とスケジュール機能

Amazon RDS Custom for SQL Serverで、OSアップデートの適用状況をコンソールで確認できるようになり、さらにアップデートのスケジュール設定もできるようになりました。

RDS Customは「標準のRDSより柔軟にOSやDBエンジンをカスタマイズしたいが、EC2で自前管理するほどの工数はかけたくない」という絶妙なニーズに応えるサービスです。個人的には面白いポジションのサービスだと思っていて、OSアップデートの管理可視化・スケジュール化はカスタム環境の運用負担を下げる意味で重要な改善だと感じます。

SQL Serverのカスタム環境を運用されている方には、メンテナンスウィンドウの管理が楽になるはずなので要チェックです。

まとめ

今週のAWSアップデートを振り返ってみると、大きく2つの方向性があると感じました。

ひとつは「AIエージェントの実用性向上」。Bedrock AgentCore RuntimeのシェルコマンドサポートはAIがより自律的に動けるようになるための基盤整備で、これからのエージェント活用に向けた重要な一歩です。

もうひとつは「大規模・エンタープライズ環境での管理効率化」。CloudWatchのOrganizations対応、RDS CustomのOSアップデート管理、Redshiftのパフォーマンス改善など、大きな環境を運用しているチームへの配慮が感じられるアップデートが多かった週でした。

AWSは毎週こつこつとアップデートを積み上げていますが、今週はその中でも「方向性が感じられる」週だったと思います。特にAgentCoreは今後も目が離せないですね。来週も引き続きウォッチしていきます。