はじめに # 前回の記事（ AWS×UserDataでvLLMを自動起動！停止時コストほぼゼロのローカルLLM環境 ）では、AWSのUserDataとS3を活用してvLLMを全自動起動し、使い終わったらTerminate（終了）することで停止中のEBS維持コストをほぼゼロにするエフェメラルなLLM推論環境を作りました。 コマンド一発でGPUインスタンスが立ち上がり、手軽に自前の推論APIを呼び出せるようになった次のステップとして、「これを日々の開発ワークフローにどう組み込むか」という実用化の検討に入りました。 VS Code上で自律的にコード編集やテスト実行を行うAIコーディングエージェント「 Cline 」の頭脳として自前GPUを活用できれば、商用APIの従量課金やレートリミットを気にせず、完全定額（インスタンス稼働分のみ）でエージェントを動かし放題にできます。 ただし、いきなりエージェントにすべてを任せる前に、まずはブラウザ上でモデルの推論速度や日本語の応答品質を手軽に対話検証したいところです。 そこで今回は、現在オープンソースの世界で最も活発に開発されているフロントエンド 「Open WebUI」 （GitHub Star 6万超）を採用しました。Open WebUIは美しいチャット画面を提供するだけでなく、自身がOpenAI互換のAPIゲートウェイとして機能するため、 「ブラウザでの対話検証」と「VS Code連携」を一挙両得で実現 できます。 本記事では、手元のローカルPC（ Windows WSL2 + docker ）上で Open WebUI を動かし、AWS上のGPUインスタンスで稼働する定番オープンソースモデル Qwen/Qwen2.5-Coder-7B-Instruct へ SSHポートフォワード 経由でセキュアに直結。トークンフリーな自律コーディング環境を実現する手順とノウハウをご紹介します！ なぜ「Open WebUI」を採用するのか？ # 📌 このセクションの要点 vLLM単体だとCUIや直叩きになりがちですが、Open WebUIを挟むことで「ブラウザでの気軽な対話検証」と「VS CodeからのOpenAI互換API利用」の両方をローカルURL固定（ http://localhost:3000 ）で両立できます。 自前の推論基盤とクライアントの間に Open WebUI を挟むことには、開発体験において大きなメリットがあります。 flowchart TD subgraph LocalPC ["ローカル開発環境 (Windows + WSL2)"] Browser["ブラウザ (WebチャットUI)<br>http://localhost:3000"] Cline["VS Code (Cline拡張機能)<br>Base URL: http://localhost:3000/api<br>API Key: Open WebUI発行キー"] subgraph DockerEnv ["Docker on WSL2 (ポート 3000)"] OpenWebUI["Open WebUI<br>・ChatGPTライクなリッチUI<br>・APIキー発行 & ユーザー管理<br>・OpenAI互換APIプロキシ (/api)"] end SSHTunnel["SSH トンネル クライアント<br>(ssh -N -f -L 8000:localhost:8000)"] Browser -->|1. Webチャット & 設定操作| OpenWebUI Cline -->|2. OpenAI形式 APIリクエスト| OpenWebUI OpenWebUI -->|"3. HTTP: 8000 (内部転送)"| SSHTunnel end subgraph AWS ["AWS 東京リージョン (ap-northeast-1)"] subgraph EC2Env ["EC2: g6.xlarge (使い捨て)【ポート8000は外部非公開】"] SSHD["SSHD (ポート22のみ開放)"] vLLM["Docker: vLLM (ポート8000)<br>OpenAI互換 推論サーバー<br>Qwen/Qwen2.5-Coder-7B-Instruct"] LocalStorage[("/opt/dlami/nvme<br>(インスタンスストア NVMe)")] SSHD -->|4. 内部ループバック転送| vLLM LocalStorage --> vLLM end S3[("Amazon S3<br>(モデル保管: Qwen2.5-Coder-7B)")] S3 -->|同一リージョン間 高速同期<br>【データ転送無料】| LocalStorage end SSHTunnel == インターネット越しにSSH暗号化通信 (ポート22) ==> SSHD 1. 「Webチャット」と「VS Code連携」の一石二鳥 # Open WebUIは、ブラウザからChatGPT / Claudeと同等の洗練されたWeb UIを提供してくれます。 コーディングエージェントに大きなタスクを任せる前に、 「このモデルは日本語の指示にどう答えるか？」「関数のプロトタイプはどう作るか？」をブラウザ上で手軽に対話・検証 できます。 会話履歴の保存、プロンプトテンプレート管理、Markdownコードハイライトなど、日常的なLLMフロントエンドとしても非常に便利です。 2. OpenAI互換APIプロキシ（ /api ）の標準搭載 # Open WebUIは単なる画面表示ツールにとどまりません。自身が OpenAI互換のAPIゲートウェイ として振る舞う機能を備えています。 設定画面から独自の APIキー を発行可能。 外部ツール（Clineなど）から http://localhost:3000/api を叩くだけで、Open WebUIが認証・ログ記録を行いつつ、背後のvLLMへリクエストを安全にルーティングしてくれます。 3. SSHポートフォワードによる「接続先URLの完全固定化」と安全性 # 使い捨て運用のEC2は起動ごとに動的パブリックIPが変わります。 EC2側のセキュリティグループでは ポート8000を外部公開せず、SSH（ポート22）のみ開放 。 ローカルPC（WSL2）から ssh -N -f -L 8000:localhost:8000 で暗号化トンネルを確立。 Open WebUIはホストネットワーク経由で常にローカルの http://127.0.0.1:8000/v1 に接続。 Cline側の接続先も常に http://localhost:3000/api で固定 できます。EC2を何度再起動・破棄してもエディタやブラウザの設定変更は不要です。 なぜエージェントに「Cline」を選ぶのか？ # vLLMと組み合わせるAIコーディング拡張機能として Cline を選定した理由は明確です： OpenAI互換APIのネイティブサポート : 特定のプロバイダ専用ツールとは異なり、Clineは公式に「OpenAI Compatible」プロバイダに対応しています。独自スキーマの変換に悩まされることなく、標準的な /v1/chat/completions エンドポイントへ極めてスムーズに接続できます。 VS Codeエディタとの一体感と自律実行力 : サイドバーのチャットから指示を出すだけで、ファイルツリーの走査、コード差分（Diff）の提示・適用、統合ターミナルでのビルドやテスト実行までをエディタ内で完結して自律実行してくれます。 Plan / Act モードによる確実なタスク遂行 : 設計・方針決定を行う「Planモード」と、実際のファイル編集・コマンド実行を行う「Actモード」をシームレスに行き来でき、オープンソースモデル（7B〜32Bクラス）でも脱線せずに着実なコーディングを進められます。 環境構築ステップ # Step 1: WSL2 + Docker で Open WebUI を起動 # 📌 このステップでやること WSL2上で公式Dockerコンテナを立ち上げます。ホストネットワーク（ --net=host ）を使うことで、後述のSSHトンネルとシームレスに直結させます。 まずは手元のWSL2環境で「Open WebUI」を起動します。 公式のDockerコンテナイメージが提供されているため、Docker Composeまたは docker run コマンド一発で立ち上がります。 方法A: Docker Compose で起動（推奨） # docker-compose.open-webui.yml services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: always network_mode: host environment: # ポート3000で待ち受け - PORT=3000 # SSHトンネル（localhost:8000）をOpenAI互換バックエンドとして指定 - OPENAI_API_BASE_URL=http://127.0.0.1:8000/v1 - OPENAI_API_KEY=none volumes: - open-webui-data:/app/backend/data volumes: open-webui-data: docker compose -f docker-compose.open-webui.yml up -d 方法B: docker run コマンドで起動 docker run -d --net=host \ -v open-webui-data:/app/backend/data \ -e PORT=3000 \ -e OPENAI_API_BASE_URL=http://127.0.0.1:8000/v1 \ -e OPENAI_API_KEY=none \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main --> Information 💡 なぜホストネットワーク（ network_mode: host / --net=host ）を使うのか？ WSL2環境でSSHポートフォワード（ ssh -L 8000:localhost:8000 ）を実行すると、SSHプロセスはホストのループバックアドレス（ 127.0.0.1:8000 ）のみで待ち受けます。 Dockerの通常のブリッジネットワーク（ -p 3000:8080 ）でコンテナを動かすと、 host.docker.internal 経由のアクセスはDocker仮想NIC（ docker0 ）から入ってくるため、 127.0.0.1 にしかバインドしていないSSHトンネルにパケットが届かず接続エラー（Connection refused）になってしまいます。 ホストネットワークを使用することで、コンテナがWSL2ホストと同一のネットワーク空間（ 127.0.0.1 ）を共有するため、余計な設定を気にせず http://127.0.0.1:8000/v1 で確実に直結できます。 起動後、ブラウザで http://localhost:3000 を開きます。 ※ 初回アクセス時に管理者アカウント（名前・メール・パスワード）の作成画面が表示されます。手元のローカル環境ですので、お好みの情報でサインアップしてください。 ※ 本記事の画面キャプチャでは、サインイン後に左下のユーザーアイコン → \rightarrow → 「設定（Settings）」 → \rightarrow → 「全般（General）」 → \rightarrow → 「言語（Language）」 で表示言語を 「日本語」 に設定しています（英語UIのままでも問題なく利用可能です）。 Step 2: EC2起動 ＆ 暗号化SSHトンネルを自動確立 # 📌 このステップでやること コマンド1発でEC2（GPU）の起動、UserDataによるvLLMの自動セットアップ、安全な暗号化SSHトンネル（ポート8000）のバックグラウンド確立までを全自動化します。 --> Information 📋 スクリプト実行前のチェックリスト（前提条件） ローカル環境 : Windows (WSL2) + Docker が導入済みであること EC2キーペア : ~/.ssh/ 配下に秘密鍵（ .pem ）が存在すること IAMロール : S3読み取り（モデル取得用）権限を持つIAMロール（例: EC2-S3-FullAccess-Profile ）が作成済みであること AWS CLI : 事前に aws configure で認証が通っていること EC2インスタンスの自動構築と接続は、以下の2つのスクリプトで行います： 02_ec2_userdata.sh : EC2の起動時に自動実行され、S3からモデルを同期し、ツール呼び出し（Tool Calling）を有効化したvLLMコンテナを起動するUserDataスクリプト 02_ec2_launch_and_tunnel.sh : ローカルPCからEC2インスタンスを起動し、上記UserDataを流し込んで暗号化SSHトンネルを自動確立するスクリプト 1. EC2内部の自動構築スクリプト（ 02_ec2_userdata.sh ） まずは、EC2起動時にサーバー内部で実行されるUserDataスクリプトです。第1回のスクリプトをベースに、自律型コーディングエージェント（Cline）やOpen WebUIからのツール呼び出し（Tool Calling）に対応するため、 vLLMの起動引数に --enable-auto-tool-choice および --tool-call-parser hermes を追加 しています。 02_ec2_userdata.sh（クリックで展開） #!/bin/bash set -euo pipefail # ============================================================================== # 02_ec2_userdata.sh # EC2起動時に実行されるUserDataスクリプト # # 前提: # - AMI: Ubuntu 22.04 Deep Learning AMI (NVIDIA Driver & Docker導入済み) # - インスタンスタイプ: g6.xlarge (NVIDIA L4 GPU: 24GB VRAM, 250GB NVMe SSD付属) # - IAMロール: S3(ReadOnly/FullAccess) 及び ECR(ReadOnly) 権限アタッチ済み # ============================================================================== LOG_FILE="/var/log/userdata-vllm.log" exec > >(tee -a "${LOG_FILE}") 2>&1 echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] UserData 実行開始 ===" # 設定パラメータ AWS_REGION="${AWS_REGION:-ap-northeast-1}" S3_BUCKET_NAME="${S3_BUCKET_NAME:-my-llm-models-tokyo}" HF_MODEL_ID="${HF_MODEL_ID:-Qwen/Qwen2.5-Coder-7B-Instruct}" SERVED_MODEL_NAME="${SERVED_MODEL_NAME:-Qwen/Qwen2.5-Coder-7B-Instruct}" VLLM_PORT="8000" GPU_MEMORY_UTILIZATION="0.90" MAX_MODEL_LEN="16384" DOCKER_IMAGE="${DOCKER_IMAGE:-vllm/vllm-openai:latest}" echo "取得モデル(HF) : ${HF_MODEL_ID}" echo "公開モデル名 : ${SERVED_MODEL_NAME}" echo "S3バケット : s3://${S3_BUCKET_NAME}" # 1. ローカル NVMe インスタンスストア（250GB）の検出と活用 # ※ AWS Deep Learning AMI (DLAMI) は、起動時にローカルNVMeを自動で /opt/dlami/nvme にマウントしてくれます NVME_DIR="/opt/dlami/nvme" if mountpoint -q "${NVME_DIR}" || [ -d "${NVME_DIR}" ]; then echo "DLAMI既定の NVMe マウント (${NVME_DIR}) を検出しました。モデル＆Docker領域として活用します..." mkdir -p "${NVME_DIR}/models" "${NVME_DIR}/docker" mkdir -p /data ln -sfn "${NVME_DIR}/models" /data/models else # DLAMI以外のAMIや未マウント時のフォールバック処理 NVME_DEV=$(lsblk -d -n -o NAME,SIZE | grep -E '250G|232G' | head -n1 | awk '{print $1}') if [ -n "${NVME_DEV}" ]; then echo "ローカル NVMe SSD (/dev/${NVME_DEV}) を検出しました。/data にマウントします..." mkfs.ext4 -F "/dev/${NVME_DEV}" || true mkdir -p /data mount -o noatime "/dev/${NVME_DEV}" /data || true else mkdir -p /data fi mkdir -p /data/models /data/docker NVME_DIR="/data" fi LOCAL_MODEL_ROOT="/data/models" LOCAL_MODEL_DIR="${LOCAL_MODEL_ROOT}/${HF_MODEL_ID}" mkdir -p "${LOCAL_MODEL_DIR}" chmod 777 "${LOCAL_MODEL_ROOT}" # 2. Docker & containerd のデータ領域を NVMe に配置し、EBS枯渇防止＆レイヤー展開を爆速化 # ※ Docker 24+ および containerd は /var/lib/containerd にスナップショットを展開するため、 # 両方を 250GB NVMe SSD にバインドマウントして 40GB EBS のディスク満杯 (no space left on device) を完全に防止します echo "Docker/containerd を停止して NVMe 領域へのバインドマウントを設定します..." systemctl stop docker containerd || true mkdir -p "${NVME_DIR}/docker" "${NVME_DIR}/containerd" mkdir -p /var/lib/docker /var/lib/containerd # 既存データがあれば移行 cp -a /var/lib/docker/* "${NVME_DIR}/docker/" 2>/dev/null || true cp -a /var/lib/containerd/* "${NVME_DIR}/containerd/" 2>/dev/null || true mount --bind "${NVME_DIR}/docker" /var/lib/docker mount --bind "${NVME_DIR}/containerd" /var/lib/containerd if ! grep -q "/var/lib/docker" /etc/fstab; then echo "${NVME_DIR}/docker /var/lib/docker none defaults,bind 0 0" >> /etc/fstab fi if ! grep -q "/var/lib/containerd" /etc/fstab; then echo "${NVME_DIR}/containerd /var/lib/containerd none defaults,bind 0 0" >> /etc/fstab fi mkdir -p /etc/docker cat <<EOF > /etc/docker/daemon.json { "data-root": "/var/lib/docker" } EOF systemctl daemon-reload systemctl start containerd systemctl start docker # 3. モデルデータの準備 (S3にあれば高速同期、無ければEC2上でHugging Faceから直接取得してS3へバックアップ) echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] モデルデータの準備確認... ===" S3_SRC="s3://${S3_BUCKET_NAME}/models/${HF_MODEL_ID}" echo "S3ターゲット: ${S3_SRC}/ (リージョン: ${AWS_REGION})" aws configure set default.s3.max_concurrent_requests 20 # IAMクレデンシャルとS3疎通の待機 (起動直後はメタデータサービスからのSTSトークン反映に数秒かかる場合がある) echo "IAM認証およびS3バケット接続を確認中..." for i in {1..15}; do if aws s3 ls "s3://${S3_BUCKET_NAME}" --region "${AWS_REGION}" >/dev/null 2>&1; then echo "S3バケットへの接続を確認しました。" break fi echo "S3接続/IAM認証待機中 ($i/15)..." sleep 2 done HAS_S3_MODEL=false echo "S3上のモデル存在チェックを実行中: aws s3 ls ${S3_SRC}/ --region ${AWS_REGION}" S3_CHECK=$(aws s3 ls "${S3_SRC}/" --region "${AWS_REGION}" 2>&1 || true) echo "S3チェック結果:" echo "${S3_CHECK}" if echo "${S3_CHECK}" | grep -E '(\.safetensors|\.bin|\.json)' >/dev/null; then HAS_S3_MODEL=true fi if [ "${HAS_S3_MODEL}" = "true" ]; then echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] S3上にモデルを発見しました。S3から高速同期します... ===" aws s3 sync "${S3_SRC}" "${LOCAL_MODEL_DIR}" \ --region "${AWS_REGION}" \ --no-progress else echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] S3上にモデルがありません。EC2上で直接Hugging Faceから高速取得します... ===" python3 -m pip install -U "huggingface_hub[cli]" || pip3 install -U "huggingface_hub[cli]" || true echo "Hugging Face ('${HF_MODEL_ID}') からモデルを直接ダウンロード中..." python3 -c " import sys from huggingface_hub import snapshot_download try: snapshot_download(repo_id='${HF_MODEL_ID}', local_dir='${LOCAL_MODEL_DIR}', local_dir_use_symlinks=False) print('Hugging Faceからのダウンロードに成功しました。') except Exception as e: print(f'ダウンロードエラー: {e}', file=sys.stderr) sys.exit(1) " echo "ダウンロード完了。容量:" du -sh "${LOCAL_MODEL_DIR}" fi echo "モデル準備完了。ローカル容量確認:" du -sh "${LOCAL_MODEL_DIR}" # 4. vLLMコンテナの起動 echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] vLLMコンテナ起動 ===" CONTAINER_NAME="vllm-server" # ECR イメージの場合はログイン認証を実行 if [[ "${DOCKER_IMAGE}" == *".dkr.ecr."* ]]; then echo "ECR イメージを検出しました。ログイン認証を実行中..." ECR_REGISTRY=$(echo "${DOCKER_IMAGE}" | cut -d'/' -f1) aws ecr get-login-password --region "${AWS_REGION}" | docker login --username AWS --password-stdin "${ECR_REGISTRY}" || true fi # 既存コンテナがあれば停止・削除 if docker ps -a --format '{{.Names}}' | grep -q "^${CONTAINER_NAME}$"; then echo "既存の ${CONTAINER_NAME} を停止・削除します..." docker rm -f "${CONTAINER_NAME}" fi docker run -d \ --name "${CONTAINER_NAME}" \ --restart unless-stopped \ --gpus all \ --ipc=host \ -p "${VLLM_PORT}:8000" \ -v "${LOCAL_MODEL_ROOT}:/models" \ "${DOCKER_IMAGE}" \ --model "/models/${HF_MODEL_ID}" \ --served-model-name "${SERVED_MODEL_NAME}" \ --gpu-memory-utilization "${GPU_MEMORY_UTILIZATION}" \ --max-model-len "${MAX_MODEL_LEN}" \ --trust-remote-code \ --enable-auto-tool-choice \ --tool-call-parser hermes # 5. ヘルスチェック (起動待機) echo "vLLM サーバーの起動ヘルスチェックを開始します (ポート ${VLLM_PORT})..." MAX_RETRIES=120 # 初回起動・CUDAグラフ構築に余裕を持たせる (最大10分) RETRY_COUNT=0 while [ ${RETRY_COUNT} -lt ${MAX_RETRIES} ]; do if curl -s "http://127.0.0.1:${VLLM_PORT}/health" > /dev/null 2>&1; then echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] vLLMサーバーが正常に起動しました！ ===" break fi echo "起動待機中... (${RETRY_COUNT}/${MAX_RETRIES})" sleep 5 RETRY_COUNT=$((RETRY_COUNT + 1)) done if [ ${RETRY_COUNT} -eq ${MAX_RETRIES} ]; then echo "警告: vLLMヘルスチェックがタイムアウトしました。'docker logs ${CONTAINER_NAME}' を確認してください。" else # 起動成功時: HFから直接ダウンロードしていた場合は、裏でS3へ自動バックアップ (I/O優先度を下げて推論を阻害しない) if [ "${HAS_S3_MODEL}" = "false" ]; then echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] 起動完了を確認。次回以降の高速同期のため、裏でS3へバックアップを開始します ===" ( if ! aws s3 ls "s3://${S3_BUCKET_NAME}" --region "${AWS_REGION}" 2>/dev/null; then if [ "${AWS_REGION}" = "us-east-1" ]; then aws s3api create-bucket --bucket "${S3_BUCKET_NAME}" 2>/dev/null || true else aws s3api create-bucket --bucket "${S3_BUCKET_NAME}" --region "${AWS_REGION}" --create-bucket-configuration LocationConstraint="${AWS_REGION}" 2>/dev/null || true fi fi ionice -c 3 aws s3 sync "${LOCAL_MODEL_DIR}" "${S3_SRC}" --region "${AWS_REGION}" --no-progress 2>/dev/null || \ aws s3 sync "${LOCAL_MODEL_DIR}" "${S3_SRC}" --region "${AWS_REGION}" --no-progress 2>/dev/null || true echo "[$(date '+%Y-%m-%d %H:%M:%S')] S3モデルバックアップ完了！次回からはS3から超高速同期されます。" ) > /var/log/s3-backup.log 2>&1 & fi fi # 6. 1時間アイドル時の自動シャットダウン（自爆Terminate）デーモン起動 echo "=== アイドル自動終了デーモンを設定・起動します ===" cat <<'EOF' > /usr/local/bin/auto-idle-shutdown.sh #!/bin/bash IDLE_LIMIT_SEC=3600 # 1時間 (3600秒) IDLE_COUNT=0 CHECK_INTERVAL=300 # 5分おきにチェック while true; do sleep "${CHECK_INTERVAL}" # 直近5分間のvLLMへの推論リクエスト数をログからカウント REQ_COUNT=$(docker logs --since 5m vllm-server 2>&1 | grep -c "POST /v1" || true) if [ "${REQ_COUNT}" -eq 0 ]; then IDLE_COUNT=$((IDLE_COUNT + CHECK_INTERVAL)) echo "[$(date '+%Y-%m-%d %H:%M:%S')] アイドル継続中: ${IDLE_COUNT}s / ${IDLE_LIMIT_SEC}s" if [ "${IDLE_COUNT}" -ge "${IDLE_LIMIT_SEC}" ]; then echo "[$(date '+%Y-%m-%d %H:%M:%S')] 1時間アイドル状態が継続したため、自動終了(Terminate)を実行します。" shutdown -h now exit 0 fi else IDLE_COUNT=0 # リクエストがあったらタイマーリセット fi done EOF chmod +x /usr/local/bin/auto-idle-shutdown.sh nohup /usr/local/bin/auto-idle-shutdown.sh > /var/log/auto-idle-shutdown.log 2>&1 & echo "=== [$(date '+%Y-%m-%d %H:%M:%S')] UserData 全処理完了 (自動アイドル監視稼働中) ===" 2. EC2起動 ＆ 暗号化SSHトンネル自動確立スクリプト（ 02_ec2_launch_and_tunnel.sh ） 続いて、ローカルPCから上記UserDataを渡してEC2を起動し、SSHトンネルをバックグラウンドで自動開通させるスクリプトです。 02_ec2_launch_and_tunnel.sh（クリックで展開） #!/bin/bash set -euo pipefail # ============================================================================== # 02_ec2_launch_and_tunnel.sh # EC2 GPUインスタンスを起動し、SSHポートフォワードで安全にvLLMをローカル(8000)に接続するスクリプト # # 特徴: # - EC2のポート8000をインターネットに一切公開せず、ポート22(SSH)のみで運用 # - ローカルPCでSSHトンネル(-L 8000:localhost:8000)を自動確立 # - Open WebUI はローカル(http://127.0.0.1:8000/v1)を向くだけなので設定固定！ # ============================================================================== SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" USER_DATA_FILE="${USER_DATA_FILE:-${SCRIPT_DIR}/02_ec2_userdata.sh}" INSTANCE_STATE_FILE="${SCRIPT_DIR}/.current_instance_id" TUNNEL_PID_FILE="${SCRIPT_DIR}/.current_ssh_tunnel_pid" # --- AWS 設定 --- AWS_REGION="${AWS_REGION:-ap-northeast-1}" INSTANCE_TYPE="${INSTANCE_TYPE:-g6.xlarge}" # NVIDIA L4 GPU (24GB VRAM) AMI_ID="${AMI_ID:-}" IAM_ROLE_NAME="${IAM_ROLE_NAME:-EC2-S3-ReadOnly-Profile}" SECURITY_GROUP_IDS="${SECURITY_GROUP_IDS:-}" SUBNET_ID="${SUBNET_ID:-}" KEY_NAME="${KEY_NAME:-my-vllm-models-hackathon-2026}" KEY_PATH="${KEY_PATH:-${HOME}/.ssh/${KEY_NAME}.pem}" EBS_SIZE_GB="${EBS_SIZE_GB:-40}" # --- モデル & UserData 設定 --- S3_BUCKET_NAME="${S3_BUCKET_NAME:-my-vllm-models-hackathon-2026-$(aws sts get-caller-identity --query Account --output text)-ap-northeast-1-an}" HF_MODEL_ID="${HF_MODEL_ID:-Qwen/Qwen2.5-Coder-7B-Instruct}" SERVED_MODEL_NAME="${SERVED_MODEL_NAME:-Qwen/Qwen2.5-Coder-7B-Instruct}" MAX_MODEL_LEN="${MAX_MODEL_LEN:-16384}" GPU_MEMORY_UTILIZATION="${GPU_MEMORY_UTILIZATION:-0.90}" DOCKER_IMAGE="${DOCKER_IMAGE:-vllm/vllm-openai:latest}" echo "=== 1. 設定確認 ===" if [ ! -f "${USER_DATA_FILE}" ]; then echo "エラー: UserDataスクリプトが見つかりません: ${USER_DATA_FILE}" echo "第1回の 02_ec2_userdata.sh を配置するか、環境変数 USER_DATA_FILE を指定してください。" exit 1 fi echo "使用するSSH秘密鍵: ${KEY_PATH}" # 一時UserDataスクリプトを生成して環境変数を注入 TEMP_USERDATA=$(mktemp) trap 'rm -f "${TEMP_USERDATA}"' EXIT sed -e "s|^AWS_REGION=.*|AWS_REGION=\"${AWS_REGION}\"|" \ -e "s|^S3_BUCKET_NAME=.*|S3_BUCKET_NAME=\"${S3_BUCKET_NAME}\"|" \ -e "s|^HF_MODEL_ID=.*|HF_MODEL_ID=\"${HF_MODEL_ID}\"|" \ -e "s|^SERVED_MODEL_NAME=.*|SERVED_MODEL_NAME=\"${SERVED_MODEL_NAME}\"|" \ -e "s|^MAX_MODEL_LEN=.*|MAX_MODEL_LEN=\"${MAX_MODEL_LEN}\"|" \ -e "s|^GPU_MEMORY_UTILIZATION=.*|GPU_MEMORY_UTILIZATION=\"${GPU_MEMORY_UTILIZATION}\"|" \ -e "s|^DOCKER_IMAGE=.*|DOCKER_IMAGE=\"${DOCKER_IMAGE}\"|" \ "${USER_DATA_FILE}" > "${TEMP_USERDATA}" if [ -z "${AMI_ID}" ]; then echo "Ubuntu 22.04 Deep Learning AMI を自動検索中..." AMI_ID=$(aws ec2 describe-images \ --region "${AWS_REGION}" \ --owners amazon \ --filters "Name=name,Values=Deep Learning OSS Nvidia Driver AMI GPU PyTorch * (Ubuntu 22.04)*" "Name=state,Values=available" \ --query 'sort_by(Images, &CreationDate)[-1].ImageId' \ --output text) echo "使用AMI ID: ${AMI_ID}" fi # SSH専用セキュリティグループの自動取得または作成 if [ -z "${SECURITY_GROUP_IDS}" ]; then SG_NAME="vllm-ssh-tunnel-sg" SG_ID=$(aws ec2 describe-security-groups \ --region "${AWS_REGION}" \ --filters "Name=group-name,Values=${SG_NAME}" \ --query 'SecurityGroups[0].GroupId' --output text 2>/dev/null || true) if [ -z "${SG_ID}" ] || [ "${SG_ID}" = "None" ]; then echo "SSH専用セキュリティグループ (${SG_NAME}) を作成します..." DEFAULT_VPC=$(aws ec2 describe-vpcs --region "${AWS_REGION}" --filters "Name=isDefault,Values=true" --query 'Vpcs[0].VpcId' --output text) SG_ID=$(aws ec2 create-security-group \ --region "${AWS_REGION}" \ --group-name "${SG_NAME}" \ --description "Allow SSH port 22 only for vLLM tunnel" \ --vpc-id "${DEFAULT_VPC}" \ --query 'GroupId' --output text) aws ec2 authorize-security-group-ingress \ --region "${AWS_REGION}" --group-id "${SG_ID}" \ --protocol tcp --port 22 --cidr "0.0.0.0/0" fi SECURITY_GROUP_IDS="${SG_ID}" fi # --- 2. EC2 インスタンス起動 --- echo "=== 2. EC2インスタンス起動 (使い捨てエフェメラル仕様) ===" INSTANCE_ID=$(aws ec2 run-instances \ --region "${AWS_REGION}" \ --image-id "${AMI_ID}" \ --instance-type "${INSTANCE_TYPE}" \ --key-name "${KEY_NAME}" \ --iam-instance-profile "Name=${IAM_ROLE_NAME}" \ --security-group-ids ${SECURITY_GROUP_IDS} \ --instance-initiated-shutdown-behavior terminate \ --block-device-mappings "[{\"DeviceName\":\"/dev/sda1\",\"Ebs\":{\"VolumeSize\":${EBS_SIZE_GB},\"VolumeType\":\"gp3\",\"DeleteOnTermination\":true}}]" \ --user-data "file://${TEMP_USERDATA}" \ --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=vllm-openwebui-server}]" \ --query 'Instances[0].InstanceId' \ --output text) echo "インスタンス起動リクエスト完了: ${INSTANCE_ID}" echo "${INSTANCE_ID}" > "${INSTANCE_STATE_FILE}" echo "インスタンスの起動完了を待機中..." aws ec2 wait instance-running --region "${AWS_REGION}" --instance-ids "${INSTANCE_ID}" PUBLIC_IP=$(aws ec2 describe-instances \ --region "${AWS_REGION}" \ --instance-ids "${INSTANCE_ID}" \ --query 'Reservations[0].Instances[0].PublicIpAddress' \ --output text) echo "パブリックIP : ${PUBLIC_IP}" # --- 3. SSHポートフォワード接続 (暗号化トンネル確立) --- echo "=== 3. SSHポートフォワード接続 (暗号化トンネル確立) ===" while ! nc -z -w 3 "${PUBLIC_IP}" 22 2>/dev/null; do sleep 3 done echo "EC2 SSHD応答確認！" if [ -f "${TUNNEL_PID_FILE}" ]; then OLD_PID=$(cat "${TUNNEL_PID_FILE}" | tr -d '[:space:]') kill -9 "${OLD_PID}" 2>/dev/null || true rm -f "${TUNNEL_PID_FILE}" fi ssh -i "${KEY_PATH}" \ -o StrictHostKeyChecking=no \ -o UserKnownHostsFile=/dev/null \ -o ServerAliveInterval=15 \ -o ServerAliveCountMax=3 \ -N -f -L 8000:localhost:8000 \ "ubuntu@${PUBLIC_IP}" TUNNEL_PID=$(pgrep -f "ssh.*-L 8000:localhost:8000.*ubuntu@${PUBLIC_IP}" | head -n1 || true) if [ -n "${TUNNEL_PID}" ]; then echo "${TUNNEL_PID}" > "${TUNNEL_PID_FILE}" fi echo "SSHトンネル確立完了！ (PID: ${TUNNEL_PID})" # --- 4. vLLMサーバーの初期化＆ヘルスチェック待機 --- echo "=== 4. vLLM サーバーの起動待機 (http://localhost:8000/health) ===" while ! curl -s -m 3 "http://localhost:8000/health" > /dev/null 2>&1; do sleep 10 done echo "==========================================================" echo " 全工程が完了しました！" echo " EC2 Instance ID: ${INSTANCE_ID}" echo " SSH Tunnel : localhost:8000 -> EC2:8000 (暗号化中)" echo " Web UI URL : http://localhost:3000" echo "==========================================================" # 実行コマンド export KEY_NAME="my-vllm-models-hackathon-2026" export IAM_ROLE_NAME="EC2-S3-FullAccess-Profile" ./02_ec2_launch_and_tunnel.sh このスクリプトは以下の処理を全自動で実行します： aws ec2 run-instances でGPUインスタンスを起動（ DeleteOnTermination: true および --instance-initiated-shutdown-behavior terminate を明示）。 セキュリティグループはポート22（SSH）のみ許可でOK （ポート8000を外部開放する必要はありません）。 インスタンスの起動完了後、パブリックIPを取得。 インスタンスのSSHD応答を確認後、 バックグラウンドでSSHポートフォワードを自動確立 （ ssh -N -f -L 8000:localhost:8000 ubuntu@<PUBLIC_IP> ）。 ローカル経由（ http://localhost:8000/health ）で vLLM の起動完了を待機。 --> Information ⚠️ 第1回からの進化点：エージェント連携に向けた起動パラメータのチューニング 第1回のUserData（シンプルなチャット検証用）から、本記事のUserData（ 02_ec2_userdata.sh ）および起動スクリプトでは、Cline連携およびOpen WebUIでのツール利用を見据えて以下のパラメータを変更・追加しています。 MAX_MODEL_LEN=16384 （コンテキスト長を 4,096 から 16,384 へ拡張） 通常のチャットAIと異なり、 Clineなどの自律コーディングエージェントは初回リクエスト時に「システムプロンプト」「ツール定義」「プロジェクトの環境情報」などを一括送信するため、プロンプトだけで約4,000トークン近くを消費 します。vLLMデフォルト（4096）のままだと、数往復のコード修正で 400 BadRequest: maximum context length exceeded エラーが発生するため、16k（16,384）に拡張しています。 GPU_MEMORY_UTILIZATION=0.90 （VRAM利用率を 0.85 から 0.90 へ引き上げ） コンテキスト長を16kへ拡張したことで、モデルの推論時に必要なKVキャッシュ（Key-Value Cache）のメモリフットプリントが増加します。g6.xlarge（NVIDIA L4 24GB VRAM）のメモリ空間を最大限に活かし、キャッシュ枯渇を防ぐために 0.90 へ引き上げています。 --enable-auto-tool-choice & --tool-call-parser hermes （UserDataでのTool Calling / 関数呼び出しの有効化） Open WebUI や Cline は、モデルにファイル操作やターミナルコマンド、Web検索を実行させるためにツール呼び出し（Function Calling / tool_choice: "auto" ）を発行します。UserData（ 02_ec2_userdata.sh ）内の docker run 引数にこれらを追加しないと "auto" tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set というエラーが発生します。Qwen2.5モデルは Hermes 形式のツール呼び出しプロンプトをサポートしているため、パーサーに hermes を指定して有効化しています。 --> Information 💡 コラム：コンテキスト長はさらに拡張できる？（32k設定とFP8 KVキャッシュ） 「16kでも十分だが、巨大なコードベースを読み込ませるために 32k や 64k まで拡張できないか？」と思われるかもしれません。結論から言うと、 さらに拡張することは十分可能 です！ 個人利用なら MAX_MODEL_LEN=32768 （32k）が今すぐ利用可能 : Qwen2.5-Coder-7B は GQA（Grouped Query Attention）を採用しており、KVキャッシュのメモリフットプリントが非常に小さく、32k トークンでも 1 リクエストあたり約 1.9 GB に収まります。L4 GPU（24GB VRAM）のモデルロード後の空き（約 6.6 GB）であれば、個人〜2人利用なら MAX_MODEL_LEN=32768 でも安定して動作します。本記事で 16k を標準としたのは、後半で述べる「3〜5人のチームで相乗りした際のメモリ枯渇（Preemption）を防ぐ安全マージン」のためです。 さらに伸ばす裏ワザ（FP8 KVキャッシュ） : g6.xlarge の NVIDIA L4 GPU は FP8 演算 にネイティブ対応しています。vLLM 起動引数に --kv-cache-dtype fp8 を追加するだけで、 KVキャッシュの消費メモリを半減（約 28 KB / token） できます。これを使えば 32k や 64k でも複数人の並行アクセスに耐えられます。 注意点（トレードオフ） : コンテキスト長を伸ばしすぎると、初速（TTFT: Time To First Token / 最初の1文字が出るまでの待ち時間）が長くなるほか、7Bモデルではプロンプト中央部の指示を読み落としやすくなる（Lost in the Middle現象）傾向があります。実用上のレスポンス速度と精度のバランスとしては 16k〜32k 付近が最も快適です。 # スクリプト実行ログのイメージ === 1. 設定確認 === 使用するSSH秘密鍵: /home/user/.ssh/my-key.pem === 2. EC2インスタンス起動 (使い捨てエフェメラル仕様) === インスタンス起動リクエスト完了: i-0123456789abcdef0 インスタンス起動完了！ パブリックIP : 54.xxx.xxx.xxx === 3. SSHポートフォワード接続 (暗号化トンネル確立) === EC2 SSHD応答確認！ SSHトンネル確立完了！ (PID: 12345) ローカルの http://localhost:8000 が安全にEC2内部のvLLMへ転送されます。 === 4. vLLM サーバーの起動待機 (http://localhost:8000/health) === ............................... vLLM サーバーが正常に応答しました！ ========================================================== 全工程が完了しました！ SSH Tunnel : localhost:8000 -> EC2:8000 (暗号化中) Web UI URL : http://localhost:3000 ========================================================== 画面に完了メッセージが表示された時点で、AWS上のvLLMとローカル環境が暗号化トンネルで直結されました！ Step 3: ブラウザでチャット確認 ＆ APIキーの発行 # 1. ブラウザからチャット動作確認 ブラウザで http://localhost:3000 を開きます。 上部のモデル選択プルダウンに Qwen/Qwen2.5-Coder-7B-Instruct が自動認識されていれば準備完了です！ 「こんにちは！自己紹介と、得意なプログラミング言語を教えてください。」 と入力してみましょう。GPUからスムーズに日本語のストリーミング応答が返ってくるはずです。まずはここで推論基盤の正常性を確認できます。 --> Information 💡 ブラウザチャット時のワンポイント（組み込みツールの解除） もしチャット時にモデルが回答する代わりに {"name": "ask_user", ...} のようなJSON形式の引数を出力してしまう場合は、モデルに組み込みツールが紐付いています。 左下のユーザーアイコンから 「設定（Settings）」 → \rightarrow → 「モデル（Models）」 （またはワークスペースのモデル管理）を開き、対象モデル（ Qwen/Qwen2.5-Coder-7B-Instruct ）を「編集」で開いて、 組み込みツールにある「ユーザーに質問（Ask User）」のチェックを解除 して保存してください。 これで余計なツール呼び出しを行わず、通常のテキストでスムーズに対話できるようになります（※Step 4で接続するCline連携時は、Cline側が独自のツール定義を適切に制御するため影響ありません）。 2. Cline接続用 APIキーの発行 ClineからOpen WebUIを経由してアクセスするためのAPIキーを発行します。 管理者設定でAPIキーを有効化 : 左下のユーザーアイコンから 「管理者パネル（Admin Panel）」 → \rightarrow → 「設定（Settings）」 → \rightarrow → 「システム（System）」 → \rightarrow → 「認証（Authentication）」 を開き、 「API キー（API Key）」 がONになっていることを確認します（※OFFの場合はONにして右下の「保存」をクリックします）。 個人のAPIキーを発行 : 左下のユーザーアイコンから 「設定（Settings / プロフィール）」 → \rightarrow → 「アカウント（Account）」 を開きます。 「API キー」 セクションにある 「＋ 新しいシークレットキーを作成」 （またはキー作成アイコン）をクリックします。 生成されたAPIキー文字列（※ sk- 形式ではなく英数字の長いトークン文字列が表示されます）をコピーして控えておきます。 Step 4: VS Code「Cline」の接続設定と実行 # 📌 このステップでやること VS Codeの拡張機能「Cline」にOpen WebUIのエンドポイントとAPIキーを設定し、トークン無制限の自律コーディングを開始します。 いよいよVS Codeから自前のvLLM環境へ接続します！ 1. Cline のインストール VS Codeの拡張機能マーケットプレイスで 「Cline」 を検索してインストールします。 2. プロバイダ設定 サイドバーの Cline アイコン（ロボット）をクリックし、上部の歯車アイコン（Settings）を開きます。 以下の項目を設定します： 設定項目 入力値 備考 API Provider OpenAI Compatible プルダウンから選択 Base URL http://localhost:3000/api Open WebUIのエンドポイント（末尾の /api に注目） ※もし Cline からの接続時に 404 Not Found が返る場合は、Base URL を http://localhost:3000/api/v1 に変更してお試しください。 OpenAI Compatible API Key 発行したAPIキー文字列 Step 3で取得したOpen WebUIのキー Model ID Qwen/Qwen2.5-Coder-7B-Instruct vLLMで提供しているモデル名 Context Window Size 16384 vLLMの max_model_len （16k）に合わせる Max Output Tokens 8192 （または 4096 ） 1リクエストあたりの最大出力トークン数 --> Information ⚠️ トークン数設定の注意点（重要） Clineの初期設定では最大出力トークン（ max_tokens ）が 32000 に設定されていることがあります。この値がバックエンド（vLLM）の最大コンテキスト長（ 16384 ）を超えていると、vLLMから以下のエラーが返されて接続に失敗します： max_tokens=32000 cannot be greater than max_model_len=16384. Please request fewer output tokens. 必ず 「Context Window Size」を 16384 、 「Max Output Tokens」を 8192 （または 4096 ） に設定してください（項目が表示されていない場合は、設定画面の「MODEL CONFIGURATION」や「Advanced Settings」を展開してください）。 ※もしStep 2のコラムを参考にvLLMを32k（32,768）で起動した場合は、それぞれ 32768 と 8192 に設定してください。 入力後、設定画面下部の「Done」または「Save」をクリックします。 3. 動作確認：自律コーディングを実行！ VS Codeで新規の空フォルダを開き、Clineのチャット入力欄に開発タスクを依頼してみましょう。 空のプロジェクトから、PythonでシンプルなTODO管理CLIツールを作成してください。 - タスクの追加・一覧表示・完了機能を持たせる - Python標準の unittest を使った単体テストコードを作成する - ターミナルでテストを実行し、すべて成功することを確認する 送信すると、Clineが自律的にプロジェクト構成を考え、ファイル作成やコード記述を始めます。 ローカル端末からOpen WebUIを経由し、暗号化SSHトンネルを通ってAWS上のGPUで稼働する Qwen/Qwen2.5-Coder-7B-Instruct から高速にトークンがストリーミングされ、VS Code上でファイル（ todo.py , test_todo.py など）が順次作成・編集されていきます。 さらにActモードであれば、統合ターミナルでテストコマンドを実行して動作確認まで自動で行ってくれます。 ブラウザのOpen WebUI管理画面の利用ログにもリクエストがしっかり記録されているのが確認できます。 --> Information 🔧 つまづきやすいポイントと解決策（Q&A） Q1. 「APIキーが無効 / 401 Unauthorized」と言われる → \rightarrow → Open WebUIのキーは sk-... 形式ではなく英数字の長い文字列です。また、管理者パネルの「認証（Authentication）」で 「API キー」が有効（ON） になっているか再度ご確認ください。 Q2. 「404 Not Found」でエンドポイントが見つからない → \rightarrow → Open WebUIのバージョンによってはパスが異なります。Base URL を http://localhost:3000/api から http://localhost:3000/api/v1 に変更してお試しください。 Q3. 「400 BadRequest: max_tokens cannot be greater than max_model_len」が出る → \rightarrow → Clineの Max Output Tokens （既定値32000など）が、vLLMの max_model_len （16384）を超えています。Cline設定で 8192 または 4096 に下げてください。 Q4. 「接続エラー（Connection refused）」になる → \rightarrow → SSHトンネルが切断されているか、Open WebUIがブリッジネットワークで起動している可能性があります。バックグラウンドで ssh -L 8000:localhost:8000 が生存しているか、Open WebUIが --net=host で動いているか確認してください。 実際に動かしてみた所感 # 実際に自前の Qwen/Qwen2.5-Coder-7B-Instruct バックエンドでClineを使ってみて感じたメリットは以下の通りです。 従量課金を気にしない「心理的安全性」 : 公式APIを使っていると、「長いログや巨大なソースコードを全部読ませたら何千トークン（何円）消費するだろうか……」と無意識にブレーキがかかりがちです。しかし自前GPUなら、 何十万トークン消費させようが課金はインスタンスの稼働時間分のみ 。気兼ねなく巨大なコードベースやテスト出力を丸ごと放り込めます。 高速なレスポンス : vLLMの最適化された推論エンジンのおかげで、東京リージョン間のレイテンシも含めて非常にレスポンスが良好です。 完全なプライベート性＆セキュア通信 : コードやプロンプトがサードパーティのAPIプロバイダに送信されないだけでなく、EC2との間もSSHトンネルで強力に暗号化されているため、機密性の高い社内コードの検証にも安心です。 💡 チームでシェアできる？ 同時に何人くらい使えるのか # 📌 このセクションの要点 24GB VRAM（L4）環境では、エンジニアの「思考時間」を考慮すると 1台あたり3〜5人のシェアが最もコストパフォーマンス高く実用的 です。 個人での利用はもちろん、現場のエンジニアとしては「チームメンバー数人で1台の推論サーバーをシェア（相乗り）して使えるか？」という点も気になるところです。 推論サーバー（ g6.xlarge : NVIDIA L4 / 24GB VRAM）のスペックとClineの特性を踏まえると、実用的な人数の目安は以下の通りです。 利用形態 推奨人数 使用感・体感 快適（専有） 1 〜 2 人 待ち時間ほぼなし。60〜80 tokens/sec のストリーミング速度を十分活用可能。 実用的なチーム利用 (★推奨) 3 〜 5 人 実務で最もバランスが良い規模 。誰かのリクエストと多少被っても体感20〜30 tokens/secを維持し十分快適。 混雑（許容限界） 6 〜 8 人 リクエストが重なると初速（TTFT: 最初の1文字が出るまで）に数秒の待ちが発生し始める。 厳しい（非推奨） 10 人以上 キュー待ちや速度低下が頻発。VRAMキャッシュ溢れのリスクが高まる。 なぜ「3〜5人」がベストバランスなのか？ KVキャッシュ（文脈メモリ）の容量 : VRAM 24GBのうち、モデル本体（約15GB）を除いた空きメモリ（約6.5〜7GB）が会話文脈のキャッシュ用プールになります。自律型エージェントはコード全体を大量に読むため、1リクエストあたり約300〜500MBを消費し、同時にメモリ保持できるアクティブな会話は物理的に12〜14本程度です。 エンジニアの「思考時間」の存在 : エンジニアは常にキーボードを叩いてプロンプトを送り続けているわけではありません。「プロンプト送信 → \rightarrow → 推論（15〜30秒） 」のあと、「生成コードの確認・ビルド・テスト → \rightarrow → 思考（3〜5分間は推論ゼロ） 」というサイクルを挟みます。1人あたりの推論稼働率は実質10〜15%程度のため、 3〜5人規模のチームであればリクエストの衝突が自然と回避され、1台のGPUをストレスなくシェア可能 です。 コスト面で見ても、 g6.xlarge のオンデマンド料金（約 $1.38/h ≒ 1時間あたり約 228 円 ※1ドル=165円換算）を3〜5人で割れば、 1人1時間あたり約 45 〜 75 円 。モデルを保管しているS3のストレージ費（月額 約 62 円）と合わせても、極めて高い費用対効果でチーム開発に導入できます。 検証終了時はワンコマンドで完全破棄 # 作業が終わったら、放置課金を防ぐためにインスタンスをTerminateします。 04_ec2_terminate.sh（クリックで展開） #!/bin/bash set -euo pipefail # ============================================================================== # 04_ec2_terminate.sh # 検証終了時にEC2インスタンスを即座に完全破棄(Terminate)するスクリプト # # ポイント: # - EBSボリュームごと削除されるため、停止中のストレージ課金を完全にゼロにします。 # ============================================================================== SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" INSTANCE_STATE_FILE="${SCRIPT_DIR}/.current_instance_id" TUNNEL_PID_FILE="${SCRIPT_DIR}/.current_ssh_tunnel_pid" AWS_REGION="${AWS_REGION:-ap-northeast-1}" INSTANCE_ID="${1:-}" if [ -z "${INSTANCE_ID}" ] && [ -f "${INSTANCE_STATE_FILE}" ]; then INSTANCE_ID=$(cat "${INSTANCE_STATE_FILE}" | tr -d '[:space:]') fi if [ -z "${INSTANCE_ID}" ]; then echo "エラー: 終了対象のインスタンスIDが指定されていません。" echo "使用例: ./04_ec2_terminate.sh <i-xxxxxxxxxxxxxxxxx>" exit 1 fi echo "=== EC2インスタンスの完全終了 (Terminate) ===" echo "対象インスタンスID: ${INSTANCE_ID}" echo "リージョン : ${AWS_REGION}" echo "" echo "※ EBSボリューム(DeleteOnTermination=true)も連動して完全削除されます。" aws ec2 terminate-instances \ --region "${AWS_REGION}" \ --instance-ids "${INSTANCE_ID}" \ --output table echo "インスタンスの終了完了を待機中..." aws ec2 wait instance-terminated \ --region "${AWS_REGION}" \ --instance-ids "${INSTANCE_ID}" rm -f "${INSTANCE_STATE_FILE}" # バックグラウンドのSSHトンネルプロセスを停止 if [ -f "${TUNNEL_PID_FILE}" ]; then TUNNEL_PID=$(cat "${TUNNEL_PID_FILE}" || true) if [ -n "${TUNNEL_PID}" ] && kill -0 "${TUNNEL_PID}" 2>/dev/null; then echo "SSHトンネルプロセス (PID: ${TUNNEL_PID}) を停止します..." kill "${TUNNEL_PID}" 2>/dev/null || true fi rm -f "${TUNNEL_PID_FILE}" fi echo "==========================================================" echo " インスタンスおよびEBSボリュームの完全破棄が完了しました！" echo " これ以降、本インスタンスに関する課金（コンピュート/EBS共に）は一切発生しません。" echo "==========================================================" # 実行コマンド ./04_ec2_terminate.sh 起動スクリプトが記録しておいたインスタンスIDとSSHトンネルのプロセスIDを自動で読み込み、 EC2・EBSボリュームの完全破棄と、ローカルのSSHトンネルプロセスの終了をワンコマンドでクリーンに完了 してくれます。 これで停止中のストレージ課金も1円たりとも発生しません。 --> Information 😴 筆者の実話：検証中に寝落ちしても、自動終了タイマーが動作してくれた話 実は今回の検証中、夜間にモデルの応答速度やプロンプトの挙動を試している最中、うっかりPCを開いたまま寝落ちして朝を迎えてしまいました……。 朝起きて「GPUインスタンスを立ち上げっぱなしにしてしまったかも……」と焦りながらAWSマネジメントコンソールを確認したところ、UserDataに仕込んでおいた 「1時間アイドル自動終了デーモン」 が正常に動作しており、推論リクエストが途絶えてからちょうど1時間後にインスタンスが自動的にTerminate（破棄）されていました。 追加の課金は最小限（数十円程度）で済みました。 エフェメラル設計とアイドル監視による自動終了の有り難みを、身をもって実感した体験でした。 まとめ # 今回は、前回の記事で作成したvLLM自動起動環境から一歩進めて、 「Open WebUI によるリッチなWeb対話＆APIゲートウェイ機能」と「SSHポートフォワードによる安全な通信路確立」を組み合わせることで、VS Codeの自律型コーディングエージェント「Cline」のバックエンドを完全自前化 してみました。 Webチャットとコーディングエージェントの両立 : ブラウザから対話検証しつつ、発行したAPIキーでそのままVS Code（Cline）から自律コーディングを実行。 Open WebUIによる安心の保守性 : 世界中で支持される活発なコミュニティにより、セキュリティや新機能の追従も盤石。 SSHポートフォワードの一挙両得 : ポート8000をインターネットに晒さず暗号化しつつ、Base URLをローカル固定化することでIP変動問題も同時に解決。 トークンフリーな自律開発環境 : インスタンス稼働費用のみの定額感覚で、コーディングエージェントを気兼ねなく活用できる環境を構築。 手軽にGPUを起動し、使い終わったら破棄するエフェメラル運用だからこそ、モダンなフロントエンドとオープンソースモデルの組み合わせを低リスクで試すことができます。興味のある方はぜひ活用してみてください。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 9 月 17 日に更新された About Amazon の記事「 AWS、米国とアイルランドを結ぶ海底ケーブル Fastnet を展開 」では、米国メリーランド州とアイルランドのコーク県を結ぶ大西洋横断の海底光ファイバーケーブル Fastnet が紹介されています。2028 年の運用開始時には 320 Tbps を超える設計容量（HD 映画 1,250 万本の同時ストリーミングに相当）を備え、従来のケーブル回廊から離れた陸揚げ地点によって、他の海底ケーブルに問題が起きてもサービスを継続できる経路の多様性を確保します。増え続ける AI のトラフィックを見据えた設計で、生成 AI やエージェントを支える土台となるネットワーク層にも AWS の投資が続いていることが分かります。AWSを支えるインフラの裏側に興味がある方は是非読んでみてください。 また、お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が予定されています。是非カレンダーをチェックしてご参加ください。 それでは 9 月 14 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 AWS Professional Services と実現する第一興商カラオケ聴感採点 AI の開発 」 株式会社第一興商と Amazon Web Services Japan の共同執筆記事です。通信カラオケ「DAM」シリーズの採点機能を高度化するため、第一興商は AWS Professional Services と共同で人間の聴感に即した歌声評価 AI「聴感採点モデル」を開発し、フラッグシップモデル LIVE DAM WAO! に搭載された採点機能「精密採点Ai Heart」の中核として活用しています。従来の機械採点は音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式で、人間が心地よいと感じる歌声のニュアンスを十分に評価できず、機械的に高得点を狙う「採点歌い」を過大評価しがちという課題がありました。最も困難だったのは「人間の聴感」を表す教師データの作成で、当初の 5 段階尺度法は審査員のブレが大きかったため、AWS Professional Services の提案で 2 つの歌声を聴き比べる一対比較法に切り替え、約 15 万回のラベル作業を経て Bradley-Terry 法で聴感スコアに変換しています。歌唱音源はオープンソースの深層学習モデル Audio Embedding Generator で 1 秒ごとに 128 次元のベクトルに変換し、AWS Fargate for Amazon ECS による最大 1,000 並列の基盤で約 13 万ファイルを 1.5 時間で処理しました。ラベリングには Amazon SageMaker Ground Truth、モデルの学習には AutoGluon Tabular と Amazon SageMaker AI を使い、製品化の際には DAM 端末のスペックに合わせた軽量化も行っています。人の感性という定量化しにくいものを教師データに落とし込む工程の工夫は、他分野の機械学習にも参考になります。 AWS生成AI国内事例ブログ「 【寄稿】株式会社レスター、Amazon Bedrock で顧客課題とグループの解決力をつなぐ情報プラットフォームを構築 」 半導体・電子部品の販売やソリューション提供などを手がける株式会社レスターによる寄稿記事です。事業領域の拡大とグループ再編で顧客基盤や商材、知見が広がる一方、他の会社・事業・部門が何を得意とし、どの顧客と接点を持つのかを把握しにくいという課題に対し、分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（RMS）は、顧客ニーズと解決手段を結びつけるマッチングの仕組みであると同時に、顧客・取引実績・担当者・商材・議事録などを関係性を保ったまま蓄積するグループ共通のデータウェアハウスです。情報の流れを「データ化」「蓄積・統合」「引き出して提案へつなぐ」の 3 段階に整理し、AI 議事録では商談の録音を Amazon Transcribe で文字起こし・話者分離したうえで Amazon Bedrock 上の Anthropic Claude が議事録として整理し、AI チャットボットでは LangGraph で構築したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless による RAG（検索拡張生成）で社内文書や議事録を検索します。録音時の同意取得、議事録ごとに参照対象へ含めるかの選択、競合情報の閲覧制限、人による最終判断といった運用ルールに加え、モデルの追加学習と RAG での参照を混同しないよう「AI に学習させる」ではなく「社内 AI 回答時の参照対象に含めるか」と表現する工夫も紹介されています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第1回）：フィジカルAI領域でのML開発への適用 」 株式会社NTTドコモ モバイルイノベーションテック部が、AWS が提唱する AI-DLC（AI-Driven Development Lifecycle）の TTT（Train The Trainer）に参加し、フィジカル AI（現実世界で物理的に動作する AI）領域の機械学習パイプラインを 3 日間のチーム開発で構築した取り組みを、全 2 回で紹介する寄稿記事の第 1 回です。対象は SO-101 ロボットアームで「キューブを持ち上げる」タスクで、模倣学習モデル（ACT）は人手で収集した 10 件のデモデータでは成功率 10%、NVIDIA の COSMOS や Mimic によるデータ増幅で 45% まで向上したものの改善が頭打ちになったため、模倣学習で得た動作知識を軽量なポリシーに蒸留し強化学習で改善する RPD（Refined Policy Distillation）論文のアプローチを採用しています。個人が AI と対話しながら進める Vibe Coding では判断やコンテキストが蓄積されないという課題意識から、要件の構造化と設計レビューを重視する AI-DLC を ML 開発に適用し、Inception フェーズではチーム全員が Kiro を囲むモブスタイルで論文や専門情報を読み込ませながら、4 つのタスクリストと 3 つの実装ユニットを定義しました。Kiro による設計レビューでは、チェックポイント形式の不一致や入力次元の食い違いなど 11 個の不整合を実装前に検出し、Inception フェーズだけで 30 以上の構造化ドキュメントを生成しています。「コードが動くが出力が正しくない」不具合が起きやすい ML 開発で、設計段階の整合性チェックが手戻りの削減につながるという実感が語られています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見 」 第 2 回は、Construction フェーズにおける 2 チーム並行開発の実験結果と知見です。両チームは蒸留から PPO（強化学習）、評価までのパイプライン構造を共有しつつ、チームピンクは KL ペナルティの効果検証、チームブルーは蒸留初期化そのものの効果検証と、細部の設計判断を分けて比較しました。実装開始直後に ACT の学習環境構築に想定以上の工数がかかると判明したチームブルーは、AI-DLC のプロセスに従って Inception フェーズに立ち戻り、タスクリストの優先度を根拠にスコープを絞る軌道修正を行っています。3 日間の結果は、模倣学習のみのベースライン 45% に対し、チームブルーで蒸留あり 64%、蒸留なし 90% と「蒸留初期化は逆効果」に見えるものでしたが、TTT 後に構造化された実験記録を読み返して Inception に立ち戻ったところ、座標変換の欠落が真因だったことが数時間で判明しました。座標変換を修正し損失関数を変更して再蒸留したうえで PPO を実行した結果、成功率は 97% に到達し、蒸留なしの 90% を統計的に有意に上回っています。1 日で 3 回の実験サイクルを回せたこと、専門家が不在でもパイプラインを構築でき専門家は品質の最終確認に集中できる状態になったこと、そして失敗の記録が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する利点として整理されています。 ブログ記事「 【開催報告】ファッション・アパレル業界向け 第一回ナレッジ共有会 〜 SMART から始まる業界共通課題への挑戦と学びの場 」 2026 年 7 月 29 日に開催された、ファッション・アパレル業界のお客様 6 社 20 名が参加したナレッジ共有会の開催報告です。AWS Prototyping Program から生まれ 2026 年 4 月に GitHub（aws-samples）で公開された店舗業務支援 AI エージェント SMART（Store Manager Agent for Retail Tech）と、Kiro も活用した合同ブートキャンプを起点に、各社が取り組んできた AI エージェント開発の実践ナレッジを企業の垣根を越えて共有する場です。サザビーリーグ IRIS 様は、グループの飲食ブランドである麺屋 猪一を対象に、SMART をベースとした週報・月報の自動生成機能を Amazon Bedrock、Amazon EventBridge、AWS Lambda、Amazon S3 Tables、Amazon Athena、Amazon SNS などで約 1 ヶ月半で開発し、店舗 PoC では約 15 分かかっていた週報作成が 0 分になり、現在は全 4 店舗で利用が始まっています。ジンズ様は店舗出身で IT 未経験のメンバーが Kiro とともに 2 週間で、Amazon Transcribe による音声テキスト化、Amazon Bedrock による感情分析・ペイン分類、改善案の自動生成、Excel 出力までを行う店舗フィードバック収集 Web アプリを構築し、アンドエスティ HD 様は「AI は判断しない。作戦を複数提示し、人が決める」という設計思想のもと Amazon Bedrock AgentCore を活用した在庫消化 Agent の開発を 2.5 ヶ月進めています。 ブログ記事「 セキュリティにおける AI の現在地: 信頼構築に最も重要な指標の測定 」 AWS は、AI モデルが実際の脆弱性と「危険に見えても本当は安全なコード」を区別できるかを直接測定する初のベンチマーク Deception Benchmark を公開しました。16 のプログラミング言語、70 を超える CWE（Common Weakness Enumeration）カテゴリにわたる 14,822 個のサンプルで構成され、パラメータ化されたステートメントで SQL インジェクションのパスが閉じられている Flask エンドポイントのように、脆弱性パターンは見えるが緩和策によって悪用不可能になっているコードが含まれます。従来のベンチマークは AI が脆弱性を発見・悪用できるかを測るものでしたが、本ベンチマークは誤検出を見分ける防御側の適合率を測る点が新しく、5 社 12 モデルを評価した結果、標準的なプロンプトでは適合率が 50% 台半ばにとどまり、偽陽性率（安全なコードを脆弱と判定する率）と偽陰性率（実際の脆弱性を見逃す率）の両方を本番利用の最低基準とする 10% 未満に抑えられた構成はありませんでした。エクスプロイトの実証を求めるプロンプトでは偽陽性率が 17〜74 ポイント下がる一方で実際の脆弱性の 7〜44% を見逃すなど、どのモデルにも同じ失敗パターンが見られます。サンプルと評価ワークフローは GitHub で公開されており、ベンチマークが暗記の問題にならないようラベルは非公開です。AI セキュリティツールを評価する際は、脆弱性を発見できるかだけでなくどのくらいの頻度で誤るかをベンダーに確認し、リスクの高いコードパスでは人間の検証と組み合わせることが推奨されています。 ブログ記事「 自動推論に立ちはだかる 3 つの難題 」 Amazon の vice president 兼 distinguished scientist である Byron Cook 氏が 2025 年 8 月に Amazon Science Blog に公開した記事の翻訳です。生成 AI ベースのシステムで正しい推論を実現する際に最も厄介な 3 つの側面として、あいまいな自然言語を構造化された言語へ変換すること、絶えず変化し時には矛盾するルールのもとで何を真理とするかを定義すること、そして組み合わせの数が天文学的になる中で確定的に推論することを挙げ、Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）がそれぞれにどう対処しているかを解説しています。自然言語の変換では、形式言語への変換候補を複数生成してソルバーで等価かどうかを証明・反証し、意味が食い違えばユーザーに確認を求めます。確定的な推論では SAT（充足可能性問題）ソルバーを活用しつつ、自身の判定結果を参照して矛盾を生むルールのように正しい答えが存在しないケースを Gödel の不完全性定理と結び付け、無矛盾性と完全性を同時に満たせない中で AWS は無矛盾性を選んだと述べています。自動推論チェックの背景にある考え方を理解するのに役立つ記事です。 ブログ記事「 はじめての自動推論 」 同じく Byron Cook 氏が 2021 年 12 月に Amazon Science Blog に公開した記事の翻訳で、上記「自動推論に立ちはだかる 3 つの難題」を読む前の予備知識としておすすめです。自動推論についてまったく知識のない業界の実務者向けに書かれており、必要な前提知識は短い C と Python のコード断片を読めることだけです。x + y == y + x を返す関数が false を返し得るかを unsigned int の全組み合わせで網羅的にテストすると 1,360 年以上かかる一方、自動推論ツールは代数を使ってミリ秒単位で答えを出せるという例から始まり、ループが必ず停止するかを推論する少し複雑な例を通じて、ツールが制御構造、最終的に真になること、常に真であることをどう推論しているかを直感的に説明します。末尾には書籍、国際会議、ツール、講演やブログへのリンクが豊富にまとめられており、さらに学びたい方の出発点になります。 ブログ記事「 自動推論による数学的確実性の 10 年: Automated Reasoning Group が歩んだ道 」 こちらも同じくByron Cook 氏が 2026 年 8 月に Amazon Science Blog に公開した記事の翻訳で、2016 年に発足した Amazon の Automated Reasoning Group（ARG）の 10 年を振り返ります。2016 年の第 1 回 Demo Day で紹介された、VPC ネットワークに関する質問に答えるツール Tiros は Amazon Inspector のネットワークセキュリティ分析や Reachability Analyzer の基盤になり、そこから派生した Zelkova は S3 Block Public Access や IAM Access Analyzer などポリシーを分析するツールの基盤になっています。現在 ARG の本番サービスは 1 日あたり数十億件のクエリを処理し、生成 AI 向けには Amazon Bedrock Guardrails の自動推論チェックがモデルの応答をポリシーに照らして形式論理で検証しています（検証精度は最大 99%）。自動推論が AWS のセキュリティと信頼性をどう支えてきたのか、その全体像をつかめる記事です。 ブログ記事「 エージェント型 AI による ERP ビジネスプロセス運用の変革 」 ある大手企業の Direct Ship（直送）請求業務では、ERP における手作業の例外処理が請求の遅延や収益認識への影響を招いていました。Accenture は Amazon Bedrock や Amazon Bedrock AgentCore などを用いたエージェント型 AI ソリューションを 5 週間で稼働させ、SOP（標準作業手順書）やジョブエイド、組織内のナレッジを一元化して自然言語で質問できる Digital Assistant と、SAP S/4HANA や認証用の Okta といった既存エンタープライズシステムとの統合機能を提供しています。アーキテクチャは、基盤モデルを提供する Amazon Bedrock、ツールの選択とワークフローのオーケストレーションを担う Strands Agents SDK、複数ターンの会話コンテキストを保持する Amazon Bedrock AgentCore、SAP S/4HANA へ安全に接続する AWS Lambda、事前処理した例外レポートを保存する Amazon RDS、レポートデータのロードを制御する AWS Step Functions の 6 つのサービスで構成されています。複数システムを行き来せずに SAP データへ即時アクセスでき、価値の高い注文を事後対応ではなくプロアクティブに処理できるようになったほか、新しいチームメンバーが対話を通じて組織のナレッジにアクセスできるようになった点が成果として挙げられ、同じパターンは調達や在庫管理など他の SAP モジュールにも拡張できるとしています。 ブログ記事「 ERP例外処理をAWSエージェント型標準作業手順書（SOP）で自動化 」 ERP の例外処理を AI エージェントで自動化するためのフレームワークとリファレンスアーキテクチャを解説する翻訳記事です。請求書の例外や購買発注（PO）の承認ブロック、月次決算などで発生する手作業の介入に対し、SAP ユースケース向けの AWS Agentic AI Solutions Framework と、その中核となるエージェント型標準作業手順書（Agentic SOP）を紹介しています。Agentic SOP は、業務プロセスごとに別々のエージェントを作るのではなく、ナレッジベースから SOP を動的に解釈し、SAP と非 SAP システムをまたいで複数ステップの例外を自律的に解決する単一の AI エージェントで、判断や承認が必要な箇所ではヒューマン・イン・ザ・ループの制御が働きます。フレームワークは、アドバイザリーモードから監督付き実行、自律的な解決へと段階的に信頼を獲得する仕組み、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP（Model Context Protocol）サーバー、ID を意識したセキュリティとコンプライアンス、監査水準の永続的な状態管理という 5 つのコア機能で構成されます。リファレンスアーキテクチャでは、Amazon EventBridge がスケジュール実行する AWS Lambda で SAP OData サービスから例外を検知し、Amazon DynamoDB に状態と監査証跡を記録しながら、Amazon Bedrock AgentCore 上の Strands エージェントが Amazon Bedrock Knowledge Bases から SOP と SAP OData API 仕様を取得して SAP への操作を実行し、必要に応じて Amazon SES 経由で人間へエスカレーションします。あるグローバル製造企業では、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超の購買管理において、1 決算サイクルあたり 30 日超かかっていた手作業が PO あたり数分で完了するようになったとしています。 ブログ記事「 月刊 AWS 製造 2026 年 9 月号 」 製造業向けに 8 月に公開されたブログとサービスアップデートをまとめた月刊記事です。今月のピックアップトピックは「エージェントに現場を任せるとき、境界線をどこに引くか」で、PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあると指摘しています。コニカミノルタ様の「未来の実験室」では AI の担当を目標色・操作候補・停止条件へ分解した JSON の中間表現までに絞って座標制御は人が設計した決定論的な制御層が担うこと、SUMCO 様の SynchroFabAI では AI に任せるのは異常状態と因果関係の推測までで操作は人間が実施すること、AWS Summit の Physical AI デモではエージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ったことなど、AI の判断と現実世界への操作を直結させない共通の構図を取り上げています。境界を決める物差しとしては Amazon Science の SOP-Bench を挙げ、不要なツールを追加すると成功率がほぼ半減した実験結果を紹介したうえで、決めた境界を Amazon Bedrock AgentCore の時間的ポリシーや AgentCore Payments でインフラ側から強制する考え方をまとめています。 ブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」 Kiro の IDE、CLI、Web のすべてで、GPT‑5.6 Sol、Terra、Luna が 100 万トークンのコンテキストウィンドウに対応しました。272K から 1M への拡大により、コードベース全体や長文ドキュメント、長く続いたマルチターンのエージェント履歴を、チャンク分割や要約を挟まず細部を失わないまま 1 回のリクエストで処理できます。記事では、レガシー移行や依存関係のマッピングといったリポジトリ規模の理解、API レイヤーやスキーマ、アプリケーションの状態が絡み合うバグのエンドツーエンドのデバッグ、セッションの全履歴を視界に残したまま進める長時間のエージェンティックなタスクの 3 つを、1 回のパスで可能になる仕事の例として挙げています。 ブログ記事「 Kiro Web の自律モードで技術的負債に大規模に立ち向かう 」 Kani Rust Verifier や CBMC といったオープンソースの形式検証ツールの保守や開発を担う AWS Automated Reasoning Group が、2025 年 11 月時点で 916 件あったオープン issue に Kiro Web の自律モードで取り組んだ事例です。app.kiro.dev でタスクを記述するか、GitHub issue に kiro ラベルを付けるか、コメントで /kiro とメンションすると、Kiro は隔離されたサンドボックスにリポジトリをクローンし、issue と関連コードの分析、作業の分解、変更の実装、テストスイート全体の実行を経てプルリクエストを開きます。Kiro はマージ権限を持たず、人間が書いたコードと同じ承認要件の対象になります。2 か月で Kiro は 87 件のオープン issue に対応するプルリクエストを提出し、これはそれまでの 22 か月でチームが対応した 94 件に迫る数で、マージされた Kiro 生成コードが持ち込んだリグレッションはゼロでした。2 年以上バックログに残っていた Kani コンパイラのクラッシュの issue を人間の作業 5 分未満で修正とリグレッションテストを含むプルリクエストにつなげたケーススタディのほか、CI は通るが修正を検証していないテスト、アーキテクチャ的に誤った修正、プラットフォーム固有の失敗、フォーマット違反といったうまくいかなかったパターンも紹介されています。 ブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」 Anthropic の Claude Fable 5.1 が、Kiro のエンタープライズ顧客向けに利用可能になりました。バグ修正や関数のリファクタリングといったインタラクティブなタスク、大規模なリファクタリングや長時間の自律実行のような複数ステップにわたるタスク、大規模なコードベース全体にまたがる推論を必要とするセキュリティやシステムレベルの複雑なタスクの 3 種類で到達点を引き上げるとしています。モデルはセッション全体を通して計画を保持し、Kiro の spec 駆動のアプローチによりタスクが成功しないと判断された場合には早期に停止してクレジットの消費を抑えます。 ブログ記事「 Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法 」 Kiro Crew をフルタイムで開発する 3 人のエンジニアが、7 日間で 1,000 件のプルリクエストをマージした経緯を振り返っています。1 日あたり 120 件を超えるプルリクエストはすべて CI とレビューを通っており、この数字は狙ったものではなく、並行開発の限界にぶつかるたびに 1 人がより多くのセッションを回せる進め方を生み出してきた結果だとしています。Kiro Crew 自体はこの 3 人を中心に 500 人近いコミュニティコントリビューターとともに開発されています。その変化は、1 セッションを手作業で回す段階、複数のタブを人間がつなぐ段階、memory・ダッシュボード・cron・workflow でセッションが温まった状態から始まる段階（10〜20 セッション）、triage・実装・レビュー・マージを独立したステージとキューでつなぐ agent pipeline の段階（20 セッション以上）、そしてセッションの外側に立つエージェントがゴールの分解・割り当て・巡回・受け入れ・順序付けを担い人間はゴールを持つだけになる Crew Mode の段階（50 セッション以上）の 5 つに整理されています。同時に、エージェント間の調整、memory の境界、ホスト側で強制する権限制御、エージェントが書き換えられない監査ログという 4 つのガバナンス上の問題と、数百セッション規模で立ち上がるコストの問題にも踏みこんでいます。 サービスアップデート 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に Amazon Bedrock AgentCore 内のサーバーレス microVM コンピュートである AgentCore Runtime の次世代版が利用可能になりました。新しい Runtime は、セッション中に使われなくなったメモリを回収する弾力的なメモリ管理によってピーク値ではなく実際の使用量に対して課金されるようになり、エージェント環境を一度準備してスナップショットを取り、新しいインスタンスはそこから復元する仕組みによって、コンテナイメージのサイズや同時実行数に関係なく一貫したコールドスタート時間を実現します。事前プロビジョニング不要、ゼロへのスケール、ハードウェアで強制されるセッション分離、使った分だけの支払いというサーバーレスモデルはそのままです。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）で利用でき、ランタイムの作成または更新時に platformVersion を V2 に設定することで使い始められます。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始となりました。Moonshot AI によれば、Kimi K3 は同社で最も高性能なモデルで、2.8 兆パラメータに到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模リポジトリにまたがる長時間のコーディングセッション、スキャンしたページやスクリーンショットを含む複数ドキュメントの分析、長く続くエージェントワークフローに向いています。クロスリージョン推論を通じて、Amazon Bedrock が利用できるすべての AWS リージョンで利用できます。 Qwen3.6-35B-A3B-NVFP4 と Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA の Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers が Amazon SageMaker JumpStart で利用可能になりました。Qwen3.6-35B-A3B-NVFP4 は Alibaba の Qwen3.6-35B-A3B を NVIDIA が量子化したモデルで、総パラメータ 35B のうちトークンあたり 3B（256 のエキスパートのうち 8 つ）のみを活性化する Mixture-of-Experts 構成です。262K トークンのコンテキストウィンドウは YaRN スケーリングで約 1M まで拡張でき、NVIDIA の ModelOpt フレームワークで NVFP4 に量子化することで、会話ターンをまたいだ thinking の保持、マルチトークン予測、複数ステップのエージェントパイプライン向けのツール呼び出しを、メモリ使用量を抑えながら利用できます。Wan2.1-T2V-1.3B-Diffusers は 1.3B パラメータのテキストから動画への生成モデルで、8.19 GB の VRAM で動作し、RTX 4090 で 5 秒の 480p 動画を約 4 分で生成できます。いずれも SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 モデルが Amazon SageMaker JumpStart で利用可能に Mistral AI の Ministral 3 ファミリーから、Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 が Amazon SageMaker JumpStart で利用可能になりました。いずれもエッジ展開やリソースの限られた環境向けに設計された、ビジョン対応のコンパクトな言語モデルです。3B モデルは 3.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 では 8GB の VRAM に収まりながら 256K トークンのコンテキストウィンドウに対応し、英語、フランス語、スペイン語、ドイツ語、中国語、日本語、韓国語、アラビア語を含む数十言語での指示追従、システムプロンプトへの高い遵守性、構造化 JSON 出力を伴うネイティブな関数呼び出しを Apache 2.0 ライセンスで提供します。8B モデルは 8.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 なら 12GB の VRAM に収まり、より大きな Mistral Small 3.2 24B に匹敵する能力を備えます。SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Gemma-4-31B-it-assistant と Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart で利用可能になりました。Gemma 4 のフラッグシップである 31B の dense モデルを、フル精度版と量子化版の両方で利用できます。Gemma-4-31B-it-assistant はアシスタント向けにチューニングされたモデルで、テキストと画像（フレーム列としての動画を含む）を入力としてテキストを出力し、256K トークンのコンテキストウィンドウと 140 以上の言語に対応します。 granite-speech-4.1-2b、kanana-2-30b-a3b-instruct、OpenFold3 モデルが Amazon SageMaker JumpStart で利用可能に IBM の granite-speech-4.1-2b、Kakao の kanana-2-30b-a3b-instruct、OpenFold Consortium の OpenFold3 の 3 モデルが Amazon SageMaker JumpStart で利用可能になりました。granite-speech-4.1-2b は英語、フランス語、ドイツ語、スペイン語、ポルトガル語、日本語を対象とした多言語の自動音声認識（ASR）と双方向の音声翻訳（AST）向けに構築された 2B パラメータのモデルで、単語誤り率 5.33%、リアルタイムファクター約 231 の性能を Apache 2.0 ライセンスで提供します。kanana-2-30b-a3b-instruct は Kakao が開発した韓国語・英語バイリンガルの指示追従とエージェント型 AI ワークフロー向けモデルで、Multi-head Latent Attention（MLA）と Mixture-of-Experts（MoE）を採用し、30B の総パラメータのうちフォワードパスごとに 3B のみを活性化、YaRN スケーリングで最大 128K トークンに対応します。OpenFold3 は OpenFold Consortium とコロンビア大学の AlQuraishi Lab が開発した拡散ベースのモデルで、タンパク質、DNA、RNA、小分子リガンドを含む生体分子複合体の全原子構造予測を行い、コンピュータ支援創薬などの研究に活用できます。 Amazon SageMaker AI がトレーニングジョブと処理ジョブのインスタンス優先リストに対応 Amazon SageMaker AI のトレーニングジョブと処理ジョブで、インスタンスの優先リストを指定できるようになりました。これまではジョブ投入時に 1 つのインスタンスタイプしか指定できず、需要の高い GPU ではそのインスタンスが確保されるまで待つか、複雑なリトライロジックを組むか、異なるインスタンスタイプで複数のジョブを同時に投入して対処する必要がありました。今回のアップデートでは、たとえば ml.g6.48xlarge を 2 台、または ml.g5.48xlarge を 4 台といった優先順位付きのリストを渡すと、SageMaker がリストを順に確認し、容量が確保できた最初の構成でジョブを起動します。同じジョブ投入の中で、オンデマンドと予約済みの SageMaker Flexible Training Plans のどちらから容量を調達するかも設定できます。既存のトレーニング・処理ジョブの API の範囲で使え、SageMaker が利用できるすべての AWS リージョンで CLI、API、SDK、コンソール UI から利用できます。 Amazon Q Console で CloudTrail イベントを自然言語で分析 AWS CloudTrail が Amazon Q Console と統合され、AWS アカウントのアクティビティを自然言語で調査できるようになりました。クエリを書いたりログファイルを手作業で解析したりせずに、CloudTrail のトレイルが適切に設定されているか、ロギングのカバレッジに抜けがないか、どのデータイベントソースを記録しているかといった設定の確認から、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどんな変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといったセキュリティ調査、特定のリソースを作成・削除したのは誰か、どの API 呼び出しがエラーを発生させているか、なぜ請求が急増したのかといった運用上のトラブルシューティングまで質問できます。Amazon Q Console がサポートされているすべての AWS 商用リージョンで利用できます。 Amazon Quick が個別シートの生成と画像からの分析作成に対応 Amazon Quick の Generate Analysis が拡張され、ダッシュボードをより速く作るための 2 つの方法が追加されました。Generate Sheet では、既存の分析の中に追加したいシートを自然言語で説明すると、データに合わせて選ばれたビジュアル、フィルターコントロール、前年比や前月比といった計算フィールドを含むシートが追加され、ビジュアルを 1 つずつ手作業で組まなくても分析を拡張できます。画像からの分析生成では、他の BI ツールのダッシュボードを含む既存ダッシュボードの画像をプロンプトに添付すると、Amazon Quick がサポートする範囲で編集可能な分析として再作成します。ローンチ時点では Enterprise サブスクリプション / Author Pro ユーザーが利用でき、組織がアクセスを制限していない場合は Author も Amazon Quick Enterprise の一部として 2026 年 12 月までプロモーションアクセスで利用できます。Amazon Quick が利用できるすべての AWS リージョンで一般提供されています。 Kiro IDE 1.1 : Agent Artifacts とネイティブ ARM64 ビルド Kiro IDE 1.1 では、エージェントの出力を後から見返せる成果物として扱う Agent Artifacts が加わりました。ドキュメント、図、コード、画像などのエージェント出力をチャットの履歴に埋もれさせず永続的なアーティファクトとして残し、会話からコンパクトなプレビューを開く、Agent Focus でチャットの横に全体を表示してレビューする、Agent Focus のコンテキストパネルから後で戻る、といった使い方ができます。あわせて Windows と Linux 向けのネイティブ ARM64 ビルドが提供され、x64 エミュレーションに頼らずダウンロードページから各プラットフォーム用の ARM64 版を選べます。エディタの基盤は Code OSS 1.131 に更新され、コンパクションされた会話が適切なコンテキストを保持するようになったほか、MCP の失敗が分かりやすくなり、Hooks の信頼性が向上し、エンタープライズプロファイルが選択したリージョンへリクエストをルーティングするようになりました。 Kiro Model : GPT-5.6 Sol、Terra、Luna が 1M コンテキストウィンドウにアップグレード 2026 年 9 月 14 日付の Kiro のモデル changelog です。Kiro IDE、CLI、Web で GPT-5.6 Sol、Terra、Luna のコンテキストウィンドウが 272K から 1M トークンに拡張され、あわせて GPT-5.6 ファミリーのクレジット倍率が更新されました。詳細は上記のブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」をご参照ください。 Kiro CLI 2.22 : フルスクリーンチャットとセッション一覧の効率化 Kiro CLI 2.22 では、インタラクティブな TUI セッションと Lite セッションでフルスクリーンチャットが使えるようになりました。 /fullscreen と入力すると、現在の会話がシェルの履歴とは独立したスクロール可能な専用のターミナル画面に移り、もう一度 /fullscreen と入力するとインライン表示に戻ります。V2 と V3 のどちらでも利用でき、マウスやタッチパッド、キーボードでスクロールし、クリックとドラッグで選択したテキストをコピーできます。今後の TUI セッションを常にフルスクリーンで始めたい場合は /settings の Display で Start fullscreen をオンにします。V3 のセッションダッシュボードも整理され、 /sessions では検索・フィルター・ソート・グループ化のコントロールがセッション一覧から分離され、最終利用順のフラットな一覧として開き、最終利用・セッション名・メッセージ数でのソートと選択内容の記憶に対応し、Tab キーでコントロールと結果の間を移動できます。あわせて、長時間にわたる作業の信頼性も改善されています。 Kiro Model : Claude Fable 5.1 のプレビューが Kiro Enterprise 向けに展開開始 Kiro Enterprise の組織向けに、Claude Fable 5.1 のプレビューが Kiro の各クライアントで段階的に展開され始めました。1M のコンテキストウィンドウと 6 倍のクレジット倍率で提供され、推論は米国東部（バージニア北部）（us-east-1）のみで実行されます。有効化の手順やデータ保持の扱いなど詳細は上記のブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」をご参照ください。 最後に生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

みなさん、こんにちは。ソリューションアーキテクトの 大前 です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。 AI に判断を任せ、実行は別の層で制御する コニカミノルタ様の「未来の実験室」 では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。 SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。 AWS Summit での Physical AI デモ構築 においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。 では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。 決めた境界をインフラ側で強制する 8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。 時間的ポリシー は、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。 AgentCore Payments では支払い上限をインフラ層で強制できます。 「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。 直近で開催予定のイベント 9/14 – 9/19 IMTS 2026 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 10/26 – 10/31 JIMTOF2026 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造関連ブログのご紹介 8/3 Engineering Development Hub : A unified workbench to accelerate product development 製品開発チームは、 分断されたツール・データサイロ・計算リソース制約 という課題に日々直面しています。 Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。 Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。 大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。 8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。 解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。 8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。 複数拠点の OT データ統合をこれから広げる方におすすめです。 8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。 セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。 8/19 Agentic AI でつなぐモノ・サービスの改善サイクル リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。 製品の改善サイクルを回したい開発・品質部門の方におすすめです。 8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」 コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、 生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。 8/21 Accelerating Chip Tape-out with AWS Unified Operations 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。 AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。 高可用性が求められる HPC ワークロードを抱える方におすすめです。 8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。 エージェントを本番に載せる前の物差しが欲しい方におすすめです。 8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。 AI を活用した開発の効率化に興味のある方におすすめです。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。 AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。 今号のピックアップトピックの実例編として、あわせてお読みください。 製造関連の主要なサービスアップデート 8/3 Amazon SageMaker AI がフルファインチューニングに対応 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。 8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。 8/6 AgentCore に時系列ポリシーとレート制限を追加 ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。 8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。 8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。 8/18 AgentCore payments が一般提供開始 エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。 8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。 最後まで読んでいただきありがとうございました。 今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！ 著者について 大前 遼（Ryo Omae） ソリューションアーキテクト 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習や生成 AI ・ロボティクスで、最近は Physical AI デモの構築に注力しています。