[アップデート] AWS MCP Server がcross-account と cross-role accessをサポート、Claude Codeで試してみた

• URL: https://dev.classmethod.jp/articles/20260606-aws-mcp-server/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: AWS MCP Serverがマルチアカウント・マルチロールアクセスをサポート。セッション再起動なしにリクエスト単位でAWSプロファイルを切り替えられる。MCP Proxy for AWS v1.6.0以降で利用可能で、Claude Code・Kiro・Codexなどから利用できる。

詳細

従来の課題

• AWSアカウントやIAMロールを切り替えるには、AIコーディングセッション停止→認証情報更新→MCPサーバー再起動が必要だった

新機能の仕組み

• mcp-proxy-for-aws がプロキシとして動作し、aws_profileパラメータをツールスキーマに追加
• 指定プロファイルの認証情報でSigV4署名してリクエストをルーティング
• aws_profileパラメータはバックエンド転送前に除去（AWS MCP Server側は受け取らない）
• 未指定時はデフォルト（先頭）プロファイルを使用、無効なプロファイル指定はエラー

設定方法

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": ["mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp"],
      "env": {
        "AWS_MCP_PROXY_PROFILES": "prod-readonly dev staging"
      }
    }
  }
}

Claude Codeでの実際の動作

• スキーマのenum/descriptionから利用可能プロファイルを自動認識
• 「ishikawaとcloud-consの両プロファイルでaws sts get-caller-identityを実行して比較して」の1指示でクロスアカウント調査が完結

セキュリティ設計

• 明示的許可リスト: 起動時宣言済みプロファイルのみ利用可能（エージェントが~/.aws/configを探索して勝手に使うことはできない）
• ステートレスルーティング: 各呼び出しが独自の認証情報を持ち並列リクエストが干渉しない
• 読み取り専用プロファイルをデフォルトに設定し、書き込みプロファイルは明示選択を推奨

対応リージョン: us-east-1 / eu-central-1（API呼び出し自体は任意リージョン）

AgentCore RuntimeでCodex CLI（GPT-5.5）とClaude Codeを動かしてみた

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-runtime-codex-cli-claude-code/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: Amazon Bedrock AgentCore Runtime上でCodex CLI（GPT-5.5 via Bedrock Mantle）とClaude Code（claude-sonnet-4-6 via Bedrock SigV4）の両方が動作することを確認。IAM認証のみで個人APIキー不要、1つのRuntimeから複数モデルを使い分け可能。

詳細

AgentCore + Bedrockで IAM 認証する利点

• OpenAI/Anthropic APIキー・ユーザーサブスクリプション不要
• execution_roleでBedrock API呼び出し権限境界を定義
• 1 Runtimeから複数モデル（GPT-5.5 + Claude）を使い分け可能
• CloudTrailでAPI呼び出しを監査可能

Codex CLI（GPT-5.5）の設定

• AWSマネージドポリシー AmazonBedrockMantleInferenceAccess の追加が必要
• ~/.codex/config.toml で model_provider = "amazon-bedrock" を指定
• Bedrock MantleエンドポイントへGPT-5.5リクエストを送信
• 実行結果: こんにちは。（1,600トークン使用）

Claude Codeの設定

• 追加ポリシーは不要（基本のBedrock InvokeModel権限のみ）
• 環境変数: CLAUDE_CODE_USE_BEDROCK=1, AWS_REGION=us-east-2, ANTHROPIC_MODEL=global.anthropic.claude-sonnet-4-6
• グローバル推論プロファイル (global.anthropic.claude-sonnet-4-6) とUS推論プロファイル (us.anthropic.claude-sonnet-4-6) いずれも動作確認

認証方式の比較

3つのコーディングエージェント（Kiro・Codex・Claude Code）がすべてAgentCore上で動作することを確認した最初の包括的な検証記事。

Amazon Bedrock AgentCoreのShell APIで、ブラウザーからKiro CLIを操作できるWebターミナルを作ってみた

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-shell-api-web-terminal-poc/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: 2026/06/05に追加されたBedrock AgentCore RuntimeのShell API（InvokeAgentRuntimeCommandShell）を使い、xterm.js + Node.js中継サーバーでWebターミナルPoCを構築。WebSocketフレーム形式・SigV4署名・再接続設計を詳細に検証・解説。

詳細

Shell APIの概要

• AgentCore上のmicroVMにある対話シェルをWebSocket経由でリモート操作できる
• 接続エンドポイント: wss://bedrock-agentcore.<region>.amazonaws.com/runtimes/<arn>/ws/shells

フレーム形式（本検証で確認）

制約値

• フレームサイズ: 64KB（超過でclose code 1009）
• フレームレート: 250 frames/sec（超過で1008）
• 接続TTL: 1時間
• 同時セッション上限: 10

再接続設計の発見

• ch255を送らずにWebSocket切断するとAgentCore側のShellセッションが維持される
• 同じsession_id + shellIdで再接続するとreplay bufferが再送される
• ブラウザー↔Node.jsは指数バックオフ（最大5回）で自動再接続

セキュリティ注意事項（本PoCは認証なしlocalhost専用）

• 0.0.0.0バインドのため -p 127.0.0.1:3000:3000 でループバック限定公開が必須
• Cross-Site WebSocket Hijacking対策のためOriginチェックが必要（本PoCでは省略）
• KIRO_API_KEYをstdin経由で渡すためPTYエコー・bash_history・replay bufferへの露出リスクあり

【非エンジニアのためのClaude/ClaudeCodeシリーズ】Claude Coworkのスケジュール機能でITニュース収集を自動化してみた

• URL: https://dev.classmethod.jp/articles/claude-beginner/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: 営業担当者がClaude CoworkのスケジュールをGUIだけで設定し、毎朝のITニュース収集を自動化した体験記。コード不要でプロンプト入力のみで構築できる手軽さと、CRMとの組み合わせ展望を紹介。

詳細

課題: 毎朝15〜20分かかるニュースサイトの巡回が「地味な消耗」だった

構築内容

• Claude.aiのチャット画面で話しかけるだけで「morning-news-briefing」スケジュールを設定
• プログラミングゼロ、コード一行も書かずに完成

プロンプトのポイント

• dateコマンドで日付確認 → サイト巡回 → 記事ページを必ず開いて掲載日を検証（検索結果の日付は不使用）→ トピック別タブ形式でアーティファクト更新
• 調査トピック: クラウド動向/AI・生成AI/経済・ビジネス
• 営業活用のポイント列も自動生成

制約・注意点

• Proプラン以上が必要
• 実行のたびに通常の利用枠を消費するため頻度は最小限に
• Coworkのスケジュール機能は実行時にPCが起動してClaude Desktopアプリが開いている必要がある（クラウド実行ではない）
• 顧客情報をCRMと連携する場合は社内セキュリティポリシー確認が必要

応用例: 顧客情報CRMと組み合わせ、担当顧客に関連するニュースのみを自動収集

CognitoとVPCオリジンでAgentCoreのインタラクティブシェル環境を構築してみた

• URL: https://dev.classmethod.jp/articles/cognito-cloudfront-vpc-origin-agentcore-websocket/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: AgentCore RuntimeのWebシェルにCognito + CloudFront署名付きCookieで認証を追加し、VPC Origin（2026年5月GA）のWebSocketサポートとRegional NAT Gatewayを活用したパブリックサブネットレス構成をCDKで構築した。

詳細

全体アーキテクチャ

ブラウザー → CloudFront → VPC Origin → Internal ALB → ECS Fargate（WebShell中継）
→ NAT GW → AgentCore Runtime Shell API

認証の仕組み

1. /login → Lambda → Cognito Hosted UI へ302リダイレクト
2. ログイン成功 → /callback?code=xxx → CallbackLambdaがauthorization codeをtokenに交換
3. CloudFront署名付きCookie（Policy/Signature/Key-Pair-Id）を発行（有効期間8時間）
4. Cookie付きでリクエスト → CloudFront Trusted Key Groupで検証

CDKの実装ポイント

• 署名鍵ペアはカスタムリソースでデプロイ時にRSA 2048bit生成
• 秘密鍵はSSM Parameter Store（SecureString）保存、公開鍵はCloudFront Public Key + Key Group登録
• Lambda関数URLはOAC（Origin Access Control）+ AWS_IAM 認証でCloudFront経由以外の直接アクセスを拒否

CloudFront VPC Origin（2026年5月GA）

• WebSocketサポートが追加され、プライベートサブネットにあるWebSocketアプリをCloudFront経由で公開可能
• デフォルトビヘイビアの設定ポイント: CACHING_DISABLED + ALL_VIEWER + ALLOW_ALL
• CloudFront・VPC Origin側にWebSocket固有の追加設定は不要、HTTP Upgradeを透過的に中継

Regional NAT Gateway（2025年11月GA）

• CDKのL2 VpcコンストラクトはRegional NAT Gatewayに非対応のため CfnNatGateway (L1) で作成
• availabilityMode: 'regional' + vpcId を直接指定（従来のzonal NAT Gwと異なり subnetId 不要）
• パブリックサブネットなしのVPCからAgentCore Shell APIへのアウトバウンドを実現

Cortex Agentsに問い合わせする際に、集計ポリシーがロールに応じて適用されるか確認する

• URL: https://dev.classmethod.jp/articles/cortex-agents-agg-policy-with-role/
• 日付: 2026-06-08
• Tier: Tier 3
• 要旨: Snowflake Cortex Agentsを経由したクエリにも集計ポリシー（min_group_size制約）がロールに応じて正しく適用されることを実験で確認。Snowflake CoWorkとSnowSight（直接API）の両経路で検証済み。

詳細

検証の背景

• SnowflakeのデータガバナンスポリシーはAIエージェントにも適用されるか不明だった
• Snowflake CoWorkのガイドには「ロールベースのアクセス制御・マスキングポリシーが適用される」と記載があるが、集計ポリシーについては明記なし

検証方法

1. サンプルデータ（PRIVATE_DATA テーブル）を作成
2. 集計ポリシーを作成・適用（SYSADMIN以外には min_group_size=3 の制約）
3. セマンティックビューを作成し、Cortex Agentsのエージェントを設定
4. Snowflake CoWorkでSYSADMINとCM_NAYUTSロールを切り替えて問い合わせ

検証結果

• SYSADMIN: 集計ポリシーなし→自由に集計分析が可能
• SYSADMIN以外（CM_NAYUTS）: 集計ポリシーが適用→制約内でのみ分析可能
• Snowflake CoWork（UI経由）・SnowSight（直接Cortex Agents API経由）いずれも同様

ポイント

• AIエージェントが生成・実行するSQLにも既存のデータ保護ポリシーが透過的に適用される
• セマンティックビューのサンプル値には生データが入る可能性があるため注意が必要

GitHub Actionsを使ってAmazon Bedrock経由でClaudeを定期実行するワークフローを構築してみた

• URL: https://dev.classmethod.jp/articles/github-actions-bedrock-claude-scheduled/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: GitHub Actions cronトリガー + Claude Code CLI + Bedrock + GitHub OIDCでAPIキー不要のClaude定期実行基盤を構築。CDKでGitHub OIDCプロバイダとIAMロール（bedrock:InvokeModelのみ）を管理し、チーム運用・属人化しない設計を実現した。

詳細

構成の特徴

• Anthropic APIキーを使わずAmazon Bedrock経由でClaude Codeを実行
• GitHub OIDC → IAMロール（一時クレデンシャル）でLong-term Secretsが不要
• 課金をAWSにまとめられる
• チームリポジトリに属するため個人サブスク依存を排除（claude.ai Routinesとの違い）

CDK構成のポイント

// 信頼条件でリポジトリを限定
StringLike: {
  [`${githubDomain}:sub`]: `repo:${githubOwner}/${githubRepo}:*`,
}
// 最小権限: Claude モデルへの InvokeModel のみ
resources: [
  "arn:aws:bedrock:*::foundation-model/anthropic.claude-*",
  `arn:aws:bedrock:*:${this.account}:inference-profile/*anthropic.claude-*`,
]

ワークフローの核心部分

- name: Claudeを実行（Bedrock）
  env:
    CLAUDE_CODE_USE_BEDROCK: "1"
    ANTHROPIC_MODEL: jp.anthropic.claude-opus-4-8
  run: |
    claude -p "タスク" --max-turns 30 --dangerously-skip-permissions

事前要件: Bedrockコンソールでモデルアクセスを有効化（忘れると403エラー）

推奨ユースケース: 毎晩リポジトリを走査して要約を作る / 定期的にドキュメントを更新するなど

ハノーバーメッセ2026で見た製造業AIと、データ基盤の段階的な作り方

• URL: https://dev.classmethod.jp/articles/slug-fcc-osaka-data-driven/
• 日付: 2026-06-08
• Tier: Tier 3
• 要旨: ハノーバーメッセ2026（4月・13万人来場）の現地レポートと、ロッテ浦和工場での段階的データ基盤構築事例を組み合わせた登壇記事。世界の最前線でIndustrial AIが全体テーマとなり、各社がAIエージェントで既存システムを「上から束ねる」アーキテクチャに収斂している。

詳細

ハノーバーメッセ2026の概況

• テーマが「Industrial AI」へ完全に振り切れた（昨年より濃度が増した）
• 50カ国以上・来場者約13万人

主要ベンダーの展示

• AWS: 「Built for Industrial AI」1,400㎡ブース。製造ラインデモでAMR・協働ロボット・ヒューマノイドが自律連携。AIエージェントがMCP経由でMES/MOM/PDM/在庫管理に疎結合接続
• Microsoft: Fabric IQ・Work IQ・Foundry IQの3層基盤。Kronesのボトリング段取り替えを4時間→30分へ短縮。AnsysシミュレーションをNVIDIA GPUで実行しCopilotが機械設定を自動提案
• Siemens: PLM（Teamcenter）とTIA Portal・Industrial Copilotを組み合わせ、設計から制御プログラミングをAI支援。バーチャルコミッショニングで物理製造前に9割のバグ検出
• SAP: Jouleと40以上のエージェントによるマルチエージェント基盤。企業をまたいでスペアパーツを削り出すデモ

共通キーワード: OPC UA（製造業の機器間オープン通信規格）が各社展示の共通前提。EU CRA（Cyber Resilience Act）対応でも必須化しつつある。

段階的データ基盤の3フェーズ

1. Phase 1（可視化）: データを集めて見える化、小さな成功体験
2. Phase 2（統合・分析）: 複数ソース統合、全体最適・相関発見
3. Phase 3（新サービス・AI活用）: 予知保全・品質予測・ナレッジ活用

AI Readyの3要件: アクセス可能 / 統合済み / 品質担保 — 高価な基盤は不要でExcelでも条件を満たせる。

ロッテ浦和工場の事例

• ガーナチョコ1ラインから開始
• PLCデータ→AWS→Grafanaダッシュボード（OEE・サイクルタイム・品質管理パネル）
• 紙帳票の約50%を電子化、設備単位での生産性評価、温度異常のオンコールアラーム実現
• データが整えばAIチャットボットの実装コストは「驚くほど楽」という現場実感（Grafana MCP Server活用）

CloudflareがViteやRolldownの開発元であるVoidZeroの買収を発表

• URL: https://www.publickey1.jp/blog/26/cloudflareviterolldownvoidzeroastrovitecloudflare.html
• 日付: 2026-06-07
• Tier: Tier 2
• 要旨: CloudflareがVite・Rolldown・Oxc・Vitest開発元のVoidZeroを買収。Astroに続く開発ツール連続買収でVercel・Netlifyと競合するWebアプリプラットフォームへの転換を明確にした。MITライセンスとベンダーニュートラルな運営の継続を明言している。

詳細

背景

• VoidZeroはVite（開発サーバー兼ビルドツール）・Rolldown（バンドラー）・Oxc（JSツールチェーン）・Vitestを開発
• ViteはState of JavaScript 2025でwebpackに追いつく勢いで成長中の最大人気ビルドツール
• VoidZeroのマネタイズ手段「Void」（ViteネイティブWebプラットフォーム）はCloudflare上に構築されており、両社はもともと近い関係

CloudflareによるM&Aの流れ

• 2026年1月: Astro（静的サイトジェネレータ）の開発元Astro Technology Companyを買収
• 2026年6月: VoidZero買収を発表

戦略的意味

• Viteエコシステムに100万ドルのOSSファンドを拠出し、独立した開発継続を保証
• VercelやNetlifyと同じWebアプリケーションプラットフォームのプレイヤーに
• Cloudflareがインフラ（CDN・Workers）だけでなく、開発ツールチェーンからフロントエンドデプロイまでを垂直統合する戦略が鮮明

マイクロソフト独自のLinuxディストリビューション「Azure Linux 4.0」パブリックプレビュー開始

• URL: https://www.publickey1.jp/blog/26/linuxazure_linux_40azurewsl.html
• 日付: 2026-06-07
• Tier: Tier 2
• 要旨: MicrosoftがFedora由来のRPMベースLinuxディストリ「Azure Linux 4.0」のパブリックプレビューを発表。同社初のサーバー向け汎用Linuxとして、Hyper-V/Azure最適化・サプライチェーンセキュリティ・MSサポートを特徴とする。

詳細

Azure Linuxの歴史

• 2012年: AzureでCentOS/UbuntuのLinux VMを提供開始
• 2019年: WSL向け独自カーネル提供
• 2023年: AKS（Azure Kubernetes Service）向けに「Azure Linux」を提供
• 2026年: Azure Linux 4.0としてサーバー向け汎用用途に初めて提供（Fedora由来RPMベース）

主な特徴

• Hyper-VおよびMicrosoft Azure環境に最適化
• ソフトウェアサプライチェーン・構成・品質をMicrosoftが検証・保証
• Microsoftによるサポート
• Azure Marketplaceから仮想マシンとして展開可能
• WSL（Windows Subsystem for Linux）向けにも近日提供予定

Microsoft Build 2026のセッション「Build, deploy, and run Linux workloads on Azure」で詳細が紹介された。

vol.208 システムインサイトによる容量予測｜セイテク・シス管道場（Web）

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026vol208
• 日付: 2026-06-07
• Tier: Tier 2
• 要旨: Windows Server 2019から利用可能な「System Insights」機能を解説。機械学習ベースのローカル予測分析でCPU・ネットワーク・ストレージ・ボリュームを最大30日先まで予測でき、PowerShellまたはWindows Admin Centerで管理できる。

詳細

System InsightsはWindows Server 2019以降で使用できる機械学習ベースの容量予測機能。既定で4種の予測（CPU使用率・ネットワーク使用量・ストレージ・ボリューム）を1日1回AM3:00に実行し、過去1年の履歴データに基づいて向こう30日の予測値を生成する。

管理方法

• Windows Admin Center (v2) のGUIで即時有効化・グラフ確認が可能
• PowerShell (Install-WindowsFeature, Invoke-InsightsCapability, Get-InsightsCapabilityResult) でも完全に制御できる

予測結果の通知とアクション

• イベントログ Microsoft-Windows-System-Insights/Admin にID 151/150/149/148/132 (Ok/Critical/Error/Warning/None) で記録
• 警告 (Warning): 30日以内に容量超過予測
• 重大 (Critical): 7日以内に容量超過予測
• Set-InsightsCapabilityAction でイベント発生時にPowerShellスクリプトを自動実行可能

データ構造

• 各予測結果のJSONファイルに ForecastingResults.ObservationSeries（過去1年の履歴）と ForecastingResults.Prediction（30日予測）が格納
• 常に最新30個のJSONファイルを保持（毎日1ファイル生成・最古を削除）
• 著者作成のPowerShellスクリプトで4機能すべての平均・最大・最小値を一括取得できる