[{"content":"\nはじめに 2026年4月4日のAWSアップデートは8件です。CloudWatch Query StudioがPromQLをネイティブサポート（プレビュー）、EMRにKiro powersによるSparkトラブルシューティングエージェントが追加、Bedrock Guardrailsのクロスアカウント保護がGAになりました。監視まわりの統合が進んだ一日です。\n注目アップデート深掘り Amazon CloudWatch Query Studio Preview - PromQLネイティブサポート PromQLとは？ Prometheusが採用しているクエリ言語です。Kubernetesの監視で広く使われており、rate()やavg_over_time()といった関数でメトリクスを柔軟に集計できます。CloudWatch Metrics Insightsとは構文が異なるため、これまでは使い分けが必要でした。\nCloudWatchにPromQLネイティブサポートが入りました。PrometheusベースのメトリクスとCloudWatchメトリクスを併用している環境では、別々の画面とクエリ言語を使い分ける必要があった。Query Studioでは両方を1つのインターフェースで扱えます。\n対応リージョンは現時点で5つ（バージニア、オレゴン、シドニー、シンガポール、アイルランド）。東京リージョンはまだプレビュー対象外ですが、今後の追加に期待です。\n検証ポイント\nPromQLでEC2のCPU使用率を5分間の平均で取得する例：\n# CloudWatch Metrics Insights SELECT AVG(CPUUtilization) FROM \u0026#34;AWS/EC2\u0026#34; WHERE InstanceId = \u0026#39;i-1234567890abcdef0\u0026#39; # PromQL avg_over_time(aws_ec2_cpuutilization{instance_id=\u0026#34;i-1234567890abcdef0\u0026#34;}[5m]) OpenTelemetryメトリクスとAWSメトリクスを同一クエリで扱えるのが実用上のポイントです。アプリのリクエスト数とEC2のCPU使用率を相関分析するケース：\nrate(http_requests_total[5m]) / on() group_left aws_ec2_cpuutilization 従来は画面を行き来して手動で突き合わせていた作業が、ワンクエリで済みます。\nAmazon EMR - Spark トラブルシューティング with Kiro Powers Kiro powersとは？ AWSのAIコーディングアシスタント「Kiro」のプラグイン機能です。IDE上でKiroをインストールし、各種powersを追加することで特定ドメインのAI支援が受けられます。MCP Proxy for AWS経由でIAMロールベースの認証を行い、操作はCloudTrailに記録されます。\nSparkジョブのトラブルシューティングは、ログを追ってメモリ設定やパーティション戦略を手動で調整する地道な作業でした。Kiro powersはログ・メトリクス・設定を横断的に分析し、根本原因の特定から修正案の提示まで自動化してくれます。\n対応環境はEMR on EC2とEMR Serverless。PySpark向けには具体的なコード改善案も出力されます。\nトラブルシューティングの例\nメモリ不足エラーが発生した場合、従来は手動でログを追う必要がありました：\n$ aws emr describe-step --cluster-id j-1234567890ABC --step-id s-1234567890ABC $ aws logs get-log-events --log-group-name /aws/emr/j-1234567890ABC/spark Kiroはこれらを自動解析し、以下のような改善案を提示します：\n# Kiro が提案する修正例 spark = SparkSession.builder \\ .appName(\u0026#34;OptimizedExample\u0026#34;) \\ .config(\u0026#34;spark.sql.adaptive.enabled\u0026#34;, \u0026#34;true\u0026#34;) \\ .config(\u0026#34;spark.sql.adaptive.coalescePartitions.enabled\u0026#34;, \u0026#34;true\u0026#34;) \\ .getOrCreate() large_df = spark.read.parquet(\u0026#34;s3://bucket/large-dataset/\u0026#34;) \\ .repartition(200) # 最適なパーティション数をKiroが提案 result = large_df.groupBy(\u0026#34;category\u0026#34;).agg({\u0026#34;amount\u0026#34;: \u0026#34;sum\u0026#34;}) \\ .write.mode(\u0026#34;overwrite\u0026#34;).parquet(\u0026#34;s3://output-bucket/\u0026#34;) Sparkバージョンのアップグレード支援も別のpowerとして提供されています。EMR 6.5 → 7.12 のような大きなジャンプでも、コード変換・依存関係の解決・データ品質比較まで対応。全商用リージョンで利用可能です。\nSRE視点での活用ポイント CloudWatch Query Studioの運用活用\nKubernetesクラスター上のマイクロサービス監視では、PrometheusでアプリケーションメトリクスをCloudWatchでAWSリソースメトリクスを別々に見ていたケースが多いはずです。Query Studioで統合できれば、障害対応時の根本原因分析がシンプルになります。\nレスポンス時間の劣化が起きた際、アプリのレイテンシとRDSの接続数、EC2のCPU使用率を同時に分析して相関を特定できる。PromQLベースの複雑な条件でCloudWatchアラートを設定することも可能です。ただしプレビュー段階なので、本番アラートへの組み込みはGA後が無難でしょう。\nEMR Spark運用の自動化\nデータパイプラインのSparkジョブ失敗は深夜や休日に起きがちです。Kiro powersの自動診断をオンコールランブックに組み込めば、一次対応の負荷を減らせます。「Kiroに初期診断を実行させ、提案された修正案を確認する」というステップを加えるイメージ。\nただし本番環境への導入は段階的に。まずdev/staging環境でKiroの提案精度を検証し、誤った修正が適用されるリスクを把握しておくべきです。\nセキュリティとコンプライアンス\nBedrock GuardrailsのクロスアカウントGA化で、Organizations配下でのAIモデル利用ポリシーを一元管理できるようになりました。有害コンテンツの最大88%をブロックできるとされています。Secrets ManagerのカスタムKMSキー対応と合わせて、暗号化ポリシーの柔軟化にも活用できます。\n全アップデート一覧 SageMaker Data Agentとは？ Amazon Bedrockのモデルと連携して、構造化・非構造化データに対する推論を実行するマネージドサービスです。データソースへの接続とプロンプト実行をサーバーレスで処理します。\nサービス アップデート内容 AWS Glue Schema Registry が新たに3リージョンで利用可能に Amazon EMR Kiro powers による Spark トラブルシューティング・アップグレードエージェント Amazon Bedrock Guardrails のクロスアカウント保護が GA Amazon SageMaker Data Agent にチャート機能とマテリアライズドビューを追加 AWS Secrets Manager コンソールでカスタムKMSキーの入力が可能に AWS Marketplace Partner Revenue Measurement で Marketplace Metering をサポート AWS Partner 特定サービスで User Agent 文字列をサポート Amazon CloudWatch Query Studio で PromQL ネイティブサポート（プレビュー） まとめ 8件中、CloudWatch Query StudioのPromQLサポートとEMRのKiro powersが実務へのインパクトが大きいです。前者はPrometheus + CloudWatchの二重管理から脱却できる可能性があり、後者はSparkジョブの障害対応を自動化する手段を提供しています。Bedrock Guardrailsのクロスアカウント保護GA化も、マルチアカウント環境でAIを運用しているチームに効くアップデートです。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260404/","summary":"2026/04/04 のAWSアップデートまとめ。CloudWatch Query StudioでPromQLネイティブサポート、EMRにKiro powersでSparkトラブルシューティング、Bedrock Guardrailsクロスアカウント保護のGA化など8件","title":"【AWS】2026/04/04 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.91 と v2.1.92 がリリースされました。v2.1.92 では Bedrock の対話型セットアップウィザード、/cost のモデル別内訳表示、起動時にリモート設定の取得を強制する forceRemoteSettingsRefresh ポリシーが追加されています。v2.1.91 では MCP ツール結果の最大500K対応と disableSkillShellExecution 設定が入りました。合計32件の変更です。\n注目アップデート深掘り Bedrock 対話型セットアップウィザード（v2.1.92） ログイン画面で「3rd-party platform」を選択した際に、Bedrock 向けの対話型セットアップウィザードが起動するようになりました。AWS 認証、リージョン設定、クレデンシャル検証、モデルピニングまでガイド付きで進められます。\nこれまで Bedrock で Claude Code を使うには、環境変数を手動で設定する必要がありました。AWS_PROFILE、AWS_REGION、ANTHROPIC_MODEL などを正しく設定する手順はドキュメントを読まないと分からず、チームへの展開時にハマりがちだったポイントです。ウィザードがこれを一画面で解決してくれます。\nMCP ツール結果の大容量対応 — 最大500K（v2.1.91） MCP ツール結果のサイズ制限とは？ Claude Code は MCP サーバーからのツール結果が一定サイズを超えると自動的に切り詰めます。DB スキーマのダンプや大きな API レスポンスが途中で切れる原因になっていました。\nMCP ツール結果に _meta[\u0026quot;anthropic/maxResultSizeChars\u0026quot;] アノテーションを付与することで、最大500K文字まで切り詰めずに受け取れるようになりました。\n{ \u0026#34;content\u0026#34;: [{ \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;... 大きなDBスキーマやクエリ結果 ...\u0026#34; }], \u0026#34;_meta\u0026#34;: { \u0026#34;anthropic/maxResultSizeChars\u0026#34;: 500000 } } MCP サーバー開発者向けの機能です。DB スキーマの全量取得や大きな検索結果の返却で切り詰めが発生していた場合、サーバー側でこのアノテーションを付けるだけで解消できます。\nforceRemoteSettingsRefresh ポリシー（v2.1.92） リモート管理設定（managed settings）とは？ 組織の管理者が Claude Code の設定を一元配信する仕組みです。モデル制限やツール権限などを managed-settings.d/ 経由でチーム全体に適用できます。\nforceRemoteSettingsRefresh ポリシーを設定すると、CLI 起動時にリモート管理設定を必ず最新取得し、取得に失敗した場合は起動しません（fail-closed）。\nオフライン時にキャッシュ済みの古い設定で動いてしまうリスクを排除できます。セキュリティポリシーが厳しい環境（金融、医療など）で、設定の鮮度を保証したい場合に有用です。\n実用的な活用ポイント /cost のモデル別・キャッシュヒット内訳（v2.1.92）: サブスクリプションユーザー向けに、/cost でモデルごとの使用量とキャッシュヒット率が確認できるようになりました。どのモデルがトークンを消費しているか把握できます。\ndisableSkillShellExecution（v2.1.91）: スキル・プラグイン内でのインラインシェル実行を無効化する設定です。信頼できないスキルやマーケットプレイスから取得したプラグインに対して、シェル実行を制限できます。Bash ツール自体には影響しません。\n{ \u0026#34;disableSkillShellExecution\u0026#34;: true } Write ツールのdiff計算高速化（v2.1.92）: タブ・\u0026amp;・$ を含むファイルで60%高速化されました。大きなファイルの書き込みが速くなります。\nプロンプトキャッシュ失効ヒント（v2.1.92）: Pro ユーザーがセッションに戻った際、プロンプトキャッシュが失効していると次のターンで送信されるアンキャッシュトークン数が表示されます。コスト感覚を掴みやすくなりました。\n--resume のトランスクリプト断裂修正（v2.1.91）: 非同期書き込みが失敗した場合に会話履歴が途切れる問題が修正されています。長時間セッションの継続が安定しました。\n全変更点一覧 v2.1.92（19件） カテゴリ 変更内容 概要 Feature Bedrock 対話型セットアップウィザード ログイン画面から認証・リージョン・モデル設定をガイド付きで実行 Feature forceRemoteSettingsRefresh ポリシー 起動時にリモート設定を強制取得、失敗時は起動拒否（fail-closed） Feature /cost モデル別・キャッシュヒット内訳 サブスクリプションユーザー向けに使用量の詳細表示 Feature /release-notes 対話型バージョン選択 バージョンピッカーでリリースノートを参照 Feature Remote Control セッション名のホスト名プレフィックス デフォルトで hostname-graceful-unicorn 形式に Feature プロンプトキャッシュ失効ヒント Pro ユーザー向けにアンキャッシュトークン数を表示 Fix サブエージェントの tmux ペインカウント失敗 tmux ウィンドウの削除・リナンバー後にスポーン不可になる問題を修正 Fix Stop フックの誤動作 小型モデルの ok:false で Stop フックが失敗する問題を修正 Fix ストリーミングの配列/オブジェクトバリデーション JSON エンコード文字列として送出されるフィールドの検証を修正 Fix 拡張思考の空白テキストブロック 空白のみのテキストブロックで API 400 エラーになる問題を修正 Fix フィードバックサーベイの誤送信 auto-pilot のキー入力や連続プロンプトの数字衝突を修正 Fix フルスクリーンの「esc to interrupt」ヒント テキスト選択時に「esc to clear」と重複表示される問題を修正 Fix Homebrew 更新プロンプトのチャンネル修正 claude-code → stable、claude-code@latest → latest に修正 Fix ctrl+e のカーソル移動 行末で次の行末にジャンプする問題を修正 Fix フルスクリーンのスクロール重複表示 iTerm2・Ghostty 等で同一メッセージが2箇所に表示される問題を修正 Fix idle-return のトークンヒント セッション累計ではなく現在のコンテキストサイズを表示するよう修正 Fix プラグイン MCP サーバーの接続停滞 未認証の claude.ai コネクタと重複する場合にスタックする問題を修正 Performance Write ツールの diff 計算高速化 タブ・\u0026amp;・$ を含むファイルで60%高速化 Change /tag・/vim コマンド削除 vim モードは /config → Editor mode から切替 v2.1.91（13件） カテゴリ 変更内容 概要 Feature MCP ツール結果 _meta アノテーション maxResultSizeChars で最大500Kまで切り詰め回避 Feature disableSkillShellExecution 設定 スキル/プラグインのインラインシェル実行を無効化 Feature ディープリンクの複数行プロンプト claude-cli://open?q= で %0A エンコード改行に対応 Feature プラグイン bin/ 実行ファイル対応 同梱した実行ファイルを Bash ツールから直接実行可能に Fix --resume トランスクリプト断裂 非同期書き込み失敗時に会話履歴が途切れる問題を修正 Fix cmd+delete の行頭削除 iTerm2、kitty、WezTerm、Ghostty、Windows Terminal で修正 Fix リモートセッションのプランモード コンテナ再起動後にプランファイルを見失う問題を修正 Fix permissions.defaultMode: \u0026quot;auto\u0026quot; の JSON スキーマ検証 settings.json での設定が正しく検証されるよう修正 Fix Windows バージョンクリーンアップ アクティブバージョンのロールバックコピーを保護するよう修正 Improvement /feedback の利用不可時メッセージ 使えない理由を表示（以前は無言で非表示） Improvement /claude-api スキルのガイダンス強化 エージェント設計パターン、ツール設計、キャッシュ戦略のガイドを改善 Performance Bun での stripAnsi 高速化 Bun.stripANSI へのルーティングでパフォーマンス向上 Performance Edit ツールの old_string 短縮 短いアンカーで出力トークンを削減 まとめ 2バージョン合計32件。v2.1.92 の Bedrock セットアップウィザードは、AWS 環境で Claude Code を展開する際の初期設定の手間を一掃してくれます。forceRemoteSettingsRefresh もエンタープライズ向けには刺さるポリシー設定。v2.1.91 の MCP 500K 対応は、大きなデータを扱う MCP サーバーの実用性を上げています。バグ修正も20件近く、特に tmux 連携やフルスクリーンモードのスクロール問題など、日常的に遭遇しやすいものが潰されています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260404/","summary":"v2.1.91・v2.1.92 のClaude Codeリリースノートまとめ。Bedrock対話型セットアップウィザード、MCPツール結果500K対応、/costのモデル別内訳、forceRemoteSettingsRefreshなど計32件","title":"【Claude Code】v2.1.91・v2.1.92 リリースノートまとめ"},{"content":"\nはじめに 2026年4月3日のAWSアップデートは10件です。ElastiCache ServerlessのIPv6・デュアルスタック対応、CloudWatchのOpenTelemetryメトリクスサポート、SageMaker Data Agentの日本・オーストラリア向け地域推論などが含まれます。Lightsailにコンピュート最適化インスタンスが追加されたのも地味に便利です。\n注目アップデート深掘り Amazon ElastiCache Serverless の IPv6・デュアルスタック接続対応 ElastiCache Serverless が IPv6 およびデュアルスタック接続をサポートしました。従来の IPv4 のみという制約がなくなり、IPv6 移行を進めている環境でもキャッシュレイヤーが足枷になりません。\nデュアルスタック接続では IPv4 と IPv6 の両方のエンドポイントが提供されます。レガシーシステムを維持しつつ、新しい IPv6 対応アプリケーションも同時に接続可能。段階的な移行に向いています。\n# デュアルスタックでServerlessキャッシュを作成 $ aws elasticache create-serverless-cache \\ --serverless-cache-name my-dualstack-cache \\ --engine redis \\ --major-engine-version 7 \\ --cache-usage-limits DataStorage={Maximum=10,Unit=GB} \\ --subnet-ids subnet-12345678 \\ --security-group-ids sg-abcdef12 \\ --network-type dual-stack IPv4 → デュアルスタック → IPv6 のように段階的に切り替えれば、ダウンタイムなしで移行できます。CloudWatch で IPv4/IPv6 それぞれのトラフィックを監視しておくと、移行の進捗が可視化できて安心です。\nSageMaker Data Agent の日本・オーストラリア向け地域推論 SageMaker Data Agentとは？ Amazon Bedrockのモデルと連携して、構造化・非構造化データに対する推論を実行するマネージドサービスです。データソースへの接続とプロンプト実行をサーバーレスで処理します。\nSageMaker Data Agent が日本（ap-northeast-1）とオーストラリア向けの地域特化推論に対応しました。データが各地域内で処理され、クロスボーダーでのデータ移転を回避できます。\n個人情報保護法や金融庁ガイドラインに準拠する必要がある場合、データが日本国内で処理される保証は実務上の必須要件。SageMaker コンソールまたは API でリージョン制限付きの Data Agent を作成することで、地域内処理を強制できます。ただし地域制限により利用可能なモデルや機能に制約が生じる場合があるので、導入前のパフォーマンス検証は忘れずに。\nSRE視点での活用ポイント ElastiCache の IPv6 対応は、インフラの段階的移行に使えます。デュアルスタックにしておけば、既存の IPv4 アプリケーションを稼働させたまま新しいサービスを IPv6 で接続可能。Terraform で管理している場合は network_type パラメータの変更だけで切り替えられます。\nSageMaker Data Agent の地域制限は、障害対応ランブックにデータ処理の地域チェックを組み込む際に有用です。ただし利用可能なモデルに制約が出る場合があるため、要件に合うかは事前に確認しておくべきです。\n全アップデート一覧 AWS Deadline Cloudとは？ VFX、アニメーション、映画制作などのレンダリングワークロードを管理するフルマネージドサービスです。レンダーファームの構築・管理を簡素化し、必要なときだけコンピュートリソースをスケールできます。\nサービス アップデート内容 Amazon CloudWatch OTel Container Insights for Amazon EKS (Preview) Amazon ElastiCache Serverless で IPv6 およびデュアルスタック接続をサポート AWS Direct Connect オークランドで100G接続を拡張 Amazon CloudWatch CloudFrontログと3つのリソースタイプで自動有効化を拡張 Amazon CloudWatch OpenTelemetryメトリクスをパブリックプレビューでサポート Amazon ECS ECS Managed Instances向けManaged Daemonsを発表 Amazon SageMaker Data Agent が日本・オーストラリア向け地域特化推論をサポート Amazon SES Mail Manager でセキュリティとメール処理の新機能を追加 Amazon Lightsail コンピュート最適化インスタンスバンドルを提供開始（最大72 vCPU、15リージョン） AWS Deadline Cloud キューのジョブスケジューリングモード（Priority FIFO / Balanced / Weighted）を設定可能に まとめ 10件中、ElastiCache ServerlessのIPv6対応とSageMaker Data Agentの地域推論が実務インパクトとしては大きいです。前者はIPv6移行計画にキャッシュレイヤーを組み込めるようになった点、後者はデータ主権要件を満たしながらAI推論を使える点がポイント。Lightsailのコンピュート最適化インスタンス（最大72 vCPU）も、バッチ処理やエンコーディング用途で選択肢が広がります。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260403/","summary":"2026/04/03 のAWSアップデートまとめ。ElastiCache ServerlessのIPv6対応、CloudWatch OTelメトリクス、Lightsailコンピュート最適化インスタンスなど10件","title":"【AWS】2026/04/03 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.90 がリリースされました。新コマンド /powerup による対話型レッスン、パフォーマンス改善3件（いずれも O(n²) → O(n)）、PowerShell セキュリティ強化が主なトピックです。バグ修正は9件。--resume のキャッシュミス回帰や自動モードのユーザー指示無視など、日常的に引っかかる問題が潰されています。\n注目アップデート深掘り /powerup — 対話型レッスン機能 Claude Code の機能をアニメーション付きデモで学べる /powerup コマンドが追加されました。\n\u0026gt; /powerup フック、MCP、スキルなど、ドキュメントを読むだけでは掴みにくい機能を実際に動くデモで体験できます。新しくチームに入ったメンバーのオンボーディングにも使えそうです。\nパフォーマンス改善 — 3つの O(n²) → O(n) 修正 今回のリリースで地味に効くのが、3箇所の二次時間計算量を線形に改善したパフォーマンス修正です。\nMCP ツールスキーマのキャッシュキー生成: ターンごとに全 MCP ツールスキーマを JSON.stringify していた処理を除去 SSE トランスポートのフレーム処理: 大きなストリーミングフレームの処理が二次時間だったのを線形に SDK セッションのトランスクリプト書き込み: 長い会話でトランスクリプト書き込みが二次時間で遅くなっていたのを線形に SSE（Server-Sent Events）トランスポートとは？ Claude Code がモデルからのストリーミング応答を受信する際の通信方式です。HTTP 上でサーバーからクライアントへの一方向リアルタイム通信を行います。\nMCP サーバーを複数接続している環境や、長時間セッションで体感速度が落ちていた場合、アップグレードで改善するはずです。\n\u0026ndash;resume のプロンプトキャッシュミス回帰修正 v2.1.69 以降、deferred tools・MCP サーバー・カスタムエージェントを使っているユーザーで --resume 時に最初のリクエストのプロンプトキャッシュが完全にミスする回帰がありました。キャッシュミスはレイテンシとコストの両方に響くので、対象ユーザーには体感で分かる改善です。\n実用的な活用ポイント 自動モードで「don\u0026rsquo;t push」「wait for X before Y」といったユーザー指示が無視されるバグが修正されました。自動モードを使っているなら、意図しない操作が実行されるリスクが減ります。\nPostToolUse フックとは？ Claude Code がツール（Edit, Write, Bash等）を実行した直後に自動実行されるシェルコマンドです。settings.json で設定し、ファイル編集後の自動フォーマットや自動リントに使います。\nPostToolUse フックで format-on-save（prettier 等）を動かしている場合、連続した Edit/Write で「File content has changed」エラーが出ていた問題も修正されています。フック経由でファイルが書き換わるケースでの競合が解消されました。\n/resume の全プロジェクト一覧がセッションを並列ロードするようになり、プロジェクト数が多い環境での表示が速くなっています。--resume ピッカーから claude -p や SDK 経由のセッションが除外されるようになり、一覧も見やすくなりました。\n全変更点一覧 カテゴリ 変更内容 概要 Feature /powerup コマンド追加 アニメーション付きデモで Claude Code 機能を学べる Feature CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE 環境変数 オフライン環境で git pull 失敗時もマーケットプレイスキャッシュを保持 Feature .husky を保護ディレクトリに追加 acceptEdits モードでの誤編集を防止 Fix レート制限ダイアログの無限ループ 使用量上限到達時にダイアログが繰り返し開いてクラッシュ Fix --resume プロンプトキャッシュミス deferred tools/MCP/カスタムエージェント使用時の回帰（v2.1.69以降） Fix Edit/Write「File content has changed」 PostToolUse の format-on-save フックとの競合を解消 Fix PreToolUse フックの exit code 2 処理 JSON stdout + exit code 2 でツール呼び出しがブロックされない問題 Fix 検索/読み取りサマリーバッジの重複表示 CLAUDE.md 自動読み込み時にバッジが複数表示される Fix 自動モードのユーザー境界無視 「don\u0026rsquo;t push」等の明示的な制約を尊重するよう修正 Fix ライトテーマでのホバーテキスト不可視 click-to-expand テキストの視認性を改善 Fix パーミッションダイアログの UI クラッシュ 不正なツール入力時の異常終了を修正 Fix 選択画面のヘッダー消失 /model、/config 等のスクロール時にヘッダーが消える問題 Security PowerShell ツール権限チェック強化 trailing \u0026amp; バイパス、-ErrorAction Break ハング、TOCTOU、フォールバック劣化を修正 Security DNS キャッシュコマンドの自動許可除去 Get-DnsClientCache / ipconfig /displaydns をプライバシー保護のため除外 Performance MCP ツールスキーマの JSON.stringify 除去 キャッシュキー生成のターンごとシリアライズを排除 Performance SSE フレーム処理の線形化 大きなフレームの処理が O(n²) → O(n) Performance トランスクリプト書き込みの線形化 長い会話での書き込みが O(n²) → O(n) Improvement /resume 一覧の並列ロード 全プロジェクトセッションの読み込みを並列化 Change --resume ピッカーのフィルタリング claude -p や SDK セッションを非表示に まとめ v2.1.90 は /powerup が新機能の目玉ですが、パフォーマンス修正3件の方が日常的なインパクトは大きいかもしれません。MCP サーバーを複数使っている環境や、長いセッションを --resume で継続している場合、体感速度が変わるはずです。PowerShell 周りのセキュリティ強化も4つのベクトルをまとめて塞いでおり、Windows 環境での利用がより安全になっています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260403/","summary":"v2.1.90 のClaude Codeリリースノートまとめ。/powerupで対話型レッスン、パフォーマンス3件のO(n²)→O(n)改善、自動モードのユーザー境界尊重など19件","title":"【Claude Code】v2.1.90 リリースノートまとめ"},{"content":"\nはじめに 2026年4月2日のAWSアップデートは11件です。VPC暗号化コントロールのGovCloud対応とOpenSearch Serviceのエージェント型AIログ分析が目を引きます。CloudFrontのSHA-256署名URLやSustainabilityコンソールなど、セキュリティと運用周りの機能追加が中心です。\n注目アップデート深掘り AWS VPC 暗号化コントロールが GovCloud（US）で利用開始 GovCloud（US）リージョンでVPC暗号化コントロールが使えるようになりました。VPC内外のトラフィック暗号化を自動的に監視・強制する機能です。\n従来はサービスごとに個別で暗号化設定が必要でしたが、VPCレベルで包括的に制御できるようになります。HIPAA、PCI DSS、FedRAMP、FIPS 140-2などのコンプライアンス要件を持つ環境に向いています。ただし、今回の対象はGovCloud（US）リージョン限定なので、米国政府機関や関連する規制対象組織以外では直接的な影響は少ないです。通常の商用リージョンへの展開が今後あるかは要ウォッチです。\n# VPC の暗号化ポリシーを作成 $ aws ec2 create-vpc-encryption-policy \\ --vpc-id vpc-12345678 \\ --encryption-requirement \u0026#34;required\u0026#34; \\ --region us-gov-west-1 Terraformでの設定例：\nresource \u0026#34;aws_vpc_encryption_control\u0026#34; \u0026#34;secure_vpc\u0026#34; { vpc_id = aws_vpc.main.id encryption_policy { enforce_encryption = true encryption_algorithm = \u0026#34;AES-256\u0026#34; exceptions { service = \u0026#34;ec2-instance-connect\u0026#34; reason = \u0026#34;Administrative access\u0026#34; } } compliance_standards = [ \u0026#34;FIPS-140-2\u0026#34;, \u0026#34;FedRAMP-High\u0026#34; ] } ハードウェアベースのAES-256暗号化なので、パフォーマンスへの影響は通常5%未満とされています。\nAmazon OpenSearch Service エージェント型 AI ログ分析 OpenSearch Serviceに自然言語での対話型ログ分析機能が追加されました。追加コストなし（トークンベースの制限あり）で利用できます。\n従来のElasticsearch DSLクエリ：\n{ \u0026#34;query\u0026#34;: { \u0026#34;bool\u0026#34;: { \u0026#34;must\u0026#34;: [ {\u0026#34;range\u0026#34;: {\u0026#34;@timestamp\u0026#34;: {\u0026#34;gte\u0026#34;: \u0026#34;now-1h\u0026#34;}}}, {\u0026#34;match\u0026#34;: {\u0026#34;log_level\u0026#34;: \u0026#34;ERROR\u0026#34;}}, {\u0026#34;wildcard\u0026#34;: {\u0026#34;message\u0026#34;: \u0026#34;*database*connection*\u0026#34;}} ] } }, \u0026#34;aggs\u0026#34;: { \u0026#34;error_trends\u0026#34;: { \u0026#34;date_histogram\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;@timestamp\u0026#34;, \u0026#34;interval\u0026#34;: \u0026#34;5m\u0026#34; } } } } これが自然言語で問い合わせ可能になります：\nresponse = opensearch_client.query_with_ai_agent( domain_name=\u0026#39;production-logs\u0026#39;, query=\u0026#34;過去1時間のデータベース接続エラーを表示し、根本原因を特定して\u0026#34; ) DSLの書き方を知らないメンバーでもログ分析ができるようになるので、オンコール対応の属人化解消に使えます。ただしAI分析結果は必ず人間が検証するフローを組んでおくべきです。\nSRE視点での活用ポイント VPC暗号化コントロールは、Terraformテンプレートに組み込んでおけば新規環境でも暗号化設定が漏れません。CloudWatchアラームと連携させて、暗号化されていないトラフィックの検出→自動通知まで構築できます。導入は開発環境から段階的に進めるのがよいでしょう。\nOpenSearchのAIログ分析は、ランブックに「AIエージェントへの質問例」を整備しておくと、障害対応の標準化に使えます。「14:30の5xxスパイクの原因は？」「タイムアウトエラーが多いマイクロサービスは？」のような定型質問をテンプレート化しておくと効率的です。\n全アップデート一覧 サービス タイトル 概要 AWS VPC Encryption controls now available in GovCloud (US) VPC内外トラフィック暗号化の自動監視・強制 Oracle Database@AWS High performance networking サブミリ秒ネットワークレイテンシ対応 Amazon RDS for Oracle Cross-account snapshot sharing with additional storage 追加ストレージボリュームでのクロスアカウント共有 Amazon CloudFront SHA-256 signed URLs and cookies 署名付きURL/CookieでSHA-256をサポート AWS Managed Microsoft AD Multi-region replication in opt-in regions Opt-Inリージョンでのマルチリージョンレプリケーション Amazon OpenSearch Service Agentic AI log analytics 自然言語での対話型ログ分析 Amazon CloudWatch Security Hub CSPM findings ingestion Security Hub調査結果の組織全体取り込み AWS Organizations Path information in API responses APIレスポンスで組織パス情報を提供 Amazon SageMaker Unified Studio CloudWatch metrics for Glue jobs GlueジョブのCloudWatchメトリクス統合 AWS IAM Identity Center European Sovereign Cloud (Germany) 欧州ソブリンクラウド（ドイツ）で利用開始 AWS Sustainability Carbon emissions tracking console 炭素排出量追跡コンソール まとめ 11件中、VPC暗号化コントロールとOpenSearchのAIログ分析が実務インパクトとしては大きいです。前者はコンプライアンス対応のコード化、後者はログ分析の属人化解消に効きます。CloudFrontのSHA-256対応も、署名付きURLを使っている環境では早めに移行を検討しておくとよいでしょう。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260402/","summary":"2026/04/02 のAWSアップデートまとめ。VPC暗号化コントロールGovCloud対応、OpenSearchエージェント型AIログ分析、CloudFront SHA-256署名URL、Sustainabilityコンソールなど11件","title":"【AWS】2026/04/02 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.89がリリースされました。パーミッションフックの拡張による動的アクセス制御、LSPサーバーの自動復旧機能が主な追加です。メモリリーク修正や異常系処理の強化など、安定性の改善も含まれています。\n注目アップデート深掘り パーミッションフックの拡張 従来の静的なアクセス制御に加え、実行時の状況に応じた動的な許可判定が可能になりました。\nhooks.register(\u0026#39;permission-check\u0026#39;, async (context) =\u0026gt; { const { resource, action, user, timestamp } = context; // 本番環境は業務時間のみアクセス可 if (resource.environment === \u0026#39;production\u0026#39;) { const hour = new Date(timestamp).getHours(); if (hour \u0026lt; 9 || hour \u0026gt; 18) { return { allowed: false, reason: \u0026#39;Production access outside business hours\u0026#39; }; } } // criticalタグ付きリソースの削除を禁止 if (action === \u0026#39;terminate\u0026#39; \u0026amp;\u0026amp; resource.tags?.critical === \u0026#39;true\u0026#39;) { return { allowed: false, reason: \u0026#39;Critical resource termination requires manual approval\u0026#39; }; } return { allowed: true }; }); 外部APIとの連携も可能なので、SlackやPagerDutyのオンコール状況に基づいた緊急時アクセス許可なども実装できます。\nLSPサーバー自動復旧 LSPサーバーがクラッシュした際に自動で再起動するようになりました。大規模なTerraformプロジェクトなどでLSPサーバーがメモリ不足でクラッシュするケースがありましたが、手動再起動が不要になります。\nv2.1.88以前：\n[ERROR] Terraform LSP server crashed [INFO] Code analysis stopped → 手動で claude-code lsp restart terraform が必要 v2.1.89以降：\n[ERROR] Terraform LSP server crashed [INFO] Attempting automatic recovery (1/3) [INFO] LSP server successfully restarted [INFO] Code analysis resumed CIパイプラインでのコード品質チェックがより安定します。\n実用的な活用ポイント パーミッションフックは、まずは開発環境で時間ベースの制御から試すのがよいでしょう。いきなり複雑なポリシーを入れるよりも、段階的に制御を追加していく方が運用しやすいです。\nメモリリーク修正は、大規模なJSONデータを扱う運用スクリプトや、長時間稼働するモニタリングツールで効果を感じられます。\n全変更点一覧 カテゴリ 内容 概要 Feature パーミッションフック拡張 動的なアクセス制御ロジックの実装が可能に Feature ヘッドレスセッション制御 自動モードでのコマンド拒否時通知機能を追加 Improvement 環境変数サポート拡張 CLIツールの安定性と使用感を向上 Improvement LSPサーバー自動復旧 サーバークラッシュ時の自動復旧機能 Fix メモリリーク修正 大規模JSONデータ処理時のメモリ使用量を改善 Fix パフォーマンス改善 長時間稼働ツールの安定性を向上 Fix 異常系処理強化 エラー検知と対応の効率化 まとめ v2.1.89はパーミッションフック拡張とLSPサーバー自動復旧が2つの柱です。前者は複雑化するクラウド環境でのアクセス制御、後者はIaCを扱う開発者の作業中断削減に効きます。メモリリーク修正も含め、安定性寄りのリリースです。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260402/","summary":"v2.1.89 のClaude Codeリリースノートまとめ。パーミッションフック拡張による動的アクセス制御、LSPサーバー自動復旧、ヘッドレスセッション制御強化、メモリリーク修正など7件","title":"【Claude Code】v2.1.89 リリースノートまとめ"},{"content":"\nはじめに 2026年4月1日のAWSアップデートは13件です。CloudWatchのマルチアカウントログ一元化とAurora DSQLの.NET/Rustコネクタが実務的に刺さる内容でした。DevOpsエージェントのGA、Security Agentのペネトレーションテスト機能も出揃っています。\n注目アップデート深掘り Amazon CloudWatch マルチアカウントログ一元化 複数アカウント・リージョンにまたがるログ管理は、各環境に個別にアクセスして確認する必要がありました。この機能でデータソース名と種類に基づく自動識別が入り、CloudTrail、VPC Flow Logs、EKS Audit Logsなどを一箇所で管理できるようになります。\n組織レベルでのログ集約の設定例：\n$ aws logs create-log-group --log-group-name \u0026#34;/aws/centralized/security-logs\u0026#34; \\ --retention-in-days 365 $ aws logs put-destination \\ --destination-name \u0026#34;MultiAccountLogDestination\u0026#34; \\ --target-arn \u0026#34;arn:aws:logs:us-east-1:123456789012:log-group:/aws/centralized/security-logs\u0026#34; \\ --role-arn \u0026#34;arn:aws:iam::123456789012:role/CloudWatchLogsRole\u0026#34; Terraformで書くとこうなります：\nresource \u0026#34;aws_cloudwatch_log_group\u0026#34; \u0026#34;centralized_logs\u0026#34; { name = \u0026#34;/aws/centralized/multi-account-logs\u0026#34; retention_in_days = 365 tags = { Environment = \u0026#34;production\u0026#34; Purpose = \u0026#34;centralized-logging\u0026#34; } } resource \u0026#34;aws_cloudwatch_log_destination\u0026#34; \u0026#34;cross_account_destination\u0026#34; { name = \u0026#34;CentralizedLogDestination\u0026#34; role_arn = aws_iam_role.cloudwatch_logs_role.arn target_arn = aws_cloudwatch_log_group.centralized_logs.arn } resource \u0026#34;aws_cloudwatch_log_destination_policy\u0026#34; \u0026#34;cross_account_policy\u0026#34; { destination_name = aws_cloudwatch_log_destination.cross_account_destination.name access_policy = jsonencode({ Version = \u0026#34;2012-10-17\u0026#34; Statement = [ { Effect = \u0026#34;Allow\u0026#34; Principal = { AWS = [\u0026#34;arn:aws:iam::${var.source_account_id}:root\u0026#34;] } Action = \u0026#34;logs:PutSubscriptionFilter\u0026#34; Resource = \u0026#34;arn:aws:logs:*:${data.aws_caller_identity.current.account_id}:destination:CentralizedLogDestination\u0026#34; } ] }) } 以前は各アカウントで個別にログ検索し、関連イベントを手動で紐付ける必要がありました。データソース識別で関連ログが自動グループ化されるので、セキュリティインシデント調査のときに効きます。\nAurora DSQL .NET・Rust コネクタ Aurora DSQLに.NETとRust向けのコネクタが追加されました。静的な認証情報を使わず、IAMベースの動的トークン生成で接続する方式です。\n.NETでの実装例：\nusing Amazon.DSQL; using Npgsql; public class DSQLConnection { private readonly IAmazonDSQL _dsqlClient; private readonly string _clusterEndpoint; public DSQLConnection(IAmazonDSQL dsqlClient, string clusterEndpoint) { _dsqlClient = dsqlClient; _clusterEndpoint = clusterEndpoint; } public async Task\u0026lt;NpgsqlConnection\u0026gt; CreateConnectionAsync() { var tokenRequest = new GenerateConnectAuthTokenRequest { ClusterEndpoint = _clusterEndpoint, Region = \u0026#34;us-east-1\u0026#34; }; var tokenResponse = await _dsqlClient.GenerateConnectAuthTokenAsync(tokenRequest); var connectionString = new NpgsqlConnectionStringBuilder { Host = _clusterEndpoint, Database = \u0026#34;testdb\u0026#34;, Username = tokenResponse.DbUser, Password = tokenResponse.AuthToken, SslMode = SslMode.Require }.ToString(); return new NpgsqlConnection(connectionString); } } Rustでも同じパターンで書けます：\nuse aws_sdk_dsql::{Client, Error}; use sqlx::{PgPool, Row}; use sqlx::postgres::PgConnectOptions; pub struct DSQLConnector { client: Client, cluster_endpoint: String, } impl DSQLConnector { pub fn new(client: Client, cluster_endpoint: String) -\u0026gt; Self { Self { client, cluster_endpoint } } pub async fn create_pool(\u0026amp;self) -\u0026gt; Result\u0026lt;PgPool, Error\u0026gt; { let token_response = self.client .generate_connect_auth_token() .cluster_endpoint(\u0026amp;self.cluster_endpoint) .region(\u0026#34;us-east-1\u0026#34;) .send() .await?; let options = PgConnectOptions::new() .host(\u0026amp;self.cluster_endpoint) .database(\u0026#34;testdb\u0026#34;) .username(\u0026amp;token_response.db_user().unwrap_or(\u0026#34;default\u0026#34;)) .password(\u0026amp;token_response.auth_token().unwrap_or(\u0026#34;\u0026#34;)) .ssl_mode(sqlx::postgres::PgSslMode::Require); Ok(PgPool::connect_with(options).await?) } } 静的認証情報が不要になるのが最大のメリットです。トークンは短時間で期限切れになり、IAMポリシーでアクセス制御を細かく設定できます。接続プーリングも最適化されています。\nSRE視点での活用ポイント CloudWatchのログ一元化は、マルチアカウント環境でのインシデント対応に直結します。Terraformでログ集約設定をコード化しておけば、CloudWatchアラームと組み合わせて特定パターン検出時の自動エスカレーションまで持っていけます。\nAurora DSQLの新コネクタは、Secrets Managerで静的認証情報を管理していた環境に効きます。ローテーション作業が不要になり、IAMポリシーだけでアクセス制御が完結します。ただし移行にはアプリケーションコードの修正が必要なので、まずは新規プロジェクトから試すのがよいでしょう。\n全アップデート一覧 サービス タイトル 概要 Amazon S3 S3 Vectors expands to 17 additional AWS Regions ベクター検索機能が17の追加リージョンで利用可能に AWS Marketplace Sellers can now self-serve refunds and agreement cancellations 販売者向けのセルフサービス返金・契約キャンセル機能 Amazon Managed Service for Apache Flink Now supports Apache Flink 2.2 Apache Flink 2.2サポート、Java 17対応、I/O性能向上 AWS Deadline Cloud New fleet scaling configurations for render farms レンダーファーム向けの新しいフリートスケーリング設定 Aurora DSQL New .NET and Rust connectors .NETとRust向けの新コネクタ、IAM認証の簡素化 AWS DevOps Agent Now generally available マルチクラウド・オンプレミス対応のDevOpsエージェント Amazon ECS Managed Instances supports EC2 instance store マネージドインスタンスでEC2インスタンスストアをサポート AWS Services Service Availability Updates 一部サービスのメンテナンスモード移行とサンセット予定 AWS Private CA Publishes utilization metrics to CloudWatch 証明書利用状況メトリクスをCloudWatchに送信 AWS Security Agent On-demand penetration testing GA オンデマンドペネトレーションテスト機能が正式リリース Amazon CloudWatch Multi-account log centralization by data source データソース別のマルチアカウントログ一元化 AWS HealthOmics VPC-connected workflows VPC接続ワークフロー機能、HIPAA準拠 AWS Security Hub Available in GovCloud (US) Regions GovCloud(US)リージョンでSecurity Hubが利用可能 まとめ 13件中、CloudWatchのログ一元化とAurora DSQLコネクタが実務インパクトとしては大きいです。マルチアカウント環境の可観測性と、データベース認証のIAM化という、どちらも地味ですが運用負荷に直結するテーマです。DevOpsエージェントGAとSecurity Agentのペネトレーションテスト機能も、自動化の選択肢が増えた点で押さえておきたいところです。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260401/","summary":"2026/04/01 のAWSアップデートまとめ。CloudWatchマルチアカウントログ一元化、Aurora DSQL .NET/Rustコネクタ、DevOpsエージェントGA、Security Agentペネトレーションテストなど13件","title":"【AWS】2026/04/01 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.88 がリリースされました。今回は新機能3件、バグ修正24件、改善4件を含む大型リリースです。長時間セッションでのプロンプトキャッシュミス修正やメモリリーク解消など、安定性に関わる修正が多く含まれています。\n注目アップデート深掘り フリッカーフリー描画モード（CLAUDE_CODE_NO_FLICKER） 環境変数 CLAUDE_CODE_NO_FLICKER=1 を設定すると、alt-screen レンダリングで画面のちらつきが解消されます。仮想化されたスクロールバックも有効になります。\n# .bashrc / .zshrc / config.fish に追加 export CLAUDE_CODE_NO_FLICKER=1 ストリーミング中に画面がちらつく問題は、特に tmux + iTerm2 環境で顕著でした。このフラグで opt-in できるようになっています。\nPermissionDenied hook 自動モード（--auto）で、コマンド実行の可否を判定する内部の分類器（クラシファイア）が「危険」と判断して拒否した際に発火する PermissionDenied hook が追加されました。{retry: true} を返すとモデルにリトライを指示できます。\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;PermissionDenied\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;echo \u0026#39;{\\\u0026#34;retry\\\u0026#34;: true}\u0026#39;\u0026#34; } ] } } 自動モードで作業中に意図しない拒否が発生した場合のリカバリを自動化できます。拒否されたコマンドは /permissions の Recent タブにも表示されるようになりました。\n名前付きサブエージェントの@メンション @ メンションのタイプアヘッドに、名前付きサブエージェントが候補として表示されるようになりました。複数のサブエージェントを使い分ける場合に、宛先の指定が楽になります。\nプロンプトキャッシュミスの修正（長時間セッション） 長時間セッション中にツールスキーマのバイト列が変わることで、プロンプトキャッシュが効かなくなるバグが修正されました。長いセッションでトークン消費が増えていた原因の一つです。\nあわせて、ネストされた CLAUDE.md が長時間セッションで何十回も再注入される問題も修正されています。\nStructuredOutput スキーマキャッシュバグの修正 複数スキーマを使うワークフローで StructuredOutput の失敗率が約50%になるバグが修正されました。SDK 連携でスキーマを切り替えている場合に影響がありました。\nその他の主要な修正 メモリリーク修正: 大きな JSON 入力が LRU キャッシュキーとして保持され続ける問題を解消 巨大ファイル Edit 時の OOM クラッシュ修正: 1GiB 超のファイルで発生していた問題に対応 CJK/絵文字の履歴消失修正: ~/.claude/history.jsonl の 4KB 境界で CJK やデスクリプタが含まれるエントリが消える問題を修正 Edit/Write の CRLF 二重化修正: Windows で改行が二重になる問題と Markdown ハードラインブレイクが消える問題を修正 LSP サーバーのゾンビ状態修正: クラッシュ後にサーバーが自動再起動するようになりました hooks の if 条件修正: 複合コマンド（ls \u0026amp;\u0026amp; git push）や環境変数プレフィックス付きコマンド（FOO=bar git push）にマッチしなかった問題を修正 Voice モード修正: macOS Apple Silicon でのマイク権限、Windows での WebSocket エラー、push-to-talk の修飾キー問題を修正 /stats 修正: 30日超の履歴データ消失とサブエージェント/フォークのトークン計上漏れを修正 動作変更 Thinking サマリーがデフォルトOFF: 対話セッションでの Thinking サマリーはデフォルトで非表示になりました。showThinkingSummaries: true で復元できます /env が PowerShell にも適用: 以前は Bash のみでしたが、PowerShell でも有効になりました 全変更点一覧 カテゴリ 内容 New CLAUDE_CODE_NO_FLICKER=1 フリッカーフリー alt-screen 描画 New PermissionDenied hook（自動モード拒否時にリトライ指示可能） New 名前付きサブエージェントの @ メンションタイプアヘッド対応 Fix 長時間セッションのプロンプトキャッシュミス Fix ネストされた CLAUDE.md の複数回再注入 Fix Edit/Write の CRLF 二重化・Markdown ハードラインブレイク消失（Windows） Fix StructuredOutput スキーマキャッシュバグ（~50% 失敗率） Fix 大きな JSON 入力によるメモリリーク Fix 1GiB 超ファイルの Edit 時 OOM クラッシュ Fix 50MB超セッションファイルのメッセージ削除時クラッシュ Fix --resume の旧バージョンツール結果によるクラッシュ Fix レート制限エラーメッセージの誤表示 Fix LSP サーバーのクラッシュ後ゾンビ状態 Fix hooks if 条件の複合コマンド・環境変数プレフィックス対応 Fix CJK/絵文字を含む履歴エントリの 4KB 境界消失 Fix /stats の30日超データ消失・サブエージェントトークン計上漏れ Fix 長時間セッションでのスクロールバック消失 Fix 検索/読取グループバッジの重複表示 Fix 通知 invalidates の即時クリア Fix バックグラウンドメッセージ到着時のプロンプト消失 Fix /btw の長文レスポンスクリップ Fix Devanagari 等の結合文字の切り詰め Fix メインスクリーン端末のレイアウトシフト後の描画アーティファクト Fix Voice モード: macOS Apple Silicon マイク権限 Fix Voice push-to-talk の修飾キーコンボ Fix Voice モード: Windows WebSocket エラー Fix Shift+Enter の動作（Windows Terminal Preview 1.25） Fix tmux + iTerm2 でのストリーミング中 UI ジッター Fix PowerShell の stderr 書き込みによる誤報告（Windows 5.1） Fix SDK エラーメッセージの is_error: true 設定漏れ Fix Ctrl+B でのバックグラウンド化時のタスク通知消失 Fix PreToolUse/PostToolUse hooks の file_path 絶対パス化 Improve PowerShell プロンプトのバージョン別構文ガイダンス Change Thinking サマリーがデフォルト OFF Change 自動モード拒否コマンドの通知・/permissions Recent 表示 Change /env が PowerShell にも適用 Change /usage の冗長な週間バー非表示（Pro/Enterprise） Improve ls/tree/du のツールサマリー表示改善 Improve 画像ペースト時の末尾スペース除去 Improve !command ペースト時の bash モード自動切り替え まとめ v2.1.88 は安定性とパフォーマンスに注力した大型リリースです。特に長時間セッションでのプロンプトキャッシュミスとメモリリークの修正は、トークン消費とメモリ使用量の両方に効きます。CLAUDE_CODE_NO_FLICKER=1 は tmux ユーザーなら試す価値があります。PermissionDenied hook も自動モードのワークフロー改善に使えるので、hooks を活用している方はチェックしてみてください。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260331/","summary":"v2.1.88 のClaude Codeリリースノートまとめ。フリッカーフリー描画、PermissionDenied hook、名前付きサブエージェント@メンション、プロンプトキャッシュ修正など30件以上の変更","title":"【Claude Code】v2.1.88 リリースノートまとめ"},{"content":"\nはじめに 2026年3月31日のAWSアップデートは5件です。OpenSearch Service の Cluster Insights が AWS 管理コンソールから直接確認できるようになったことと、Direct Connect で BGP セッションの CloudWatch 監視が可能になったことが実運用に効くアップデートです。\n注目アップデート深掘り OpenSearch Service Cluster Insights のコンソール統合とEventBridge連携 Cluster Insights とは？ OpenSearch クラスターのパフォーマンス、容量、セキュリティに関する推奨事項を自動生成する機能です。シャード配置やインデックスの最適化提案などを提示してくれます。\n従来 OpenSearch Dashboards 経由でしかアクセスできなかった Cluster Insights が、AWS 管理コンソールから直接確認できるようになりました。さらに EventBridge との連携で、問題検知時の自動対応も組めるようになっています。\nコンソール統合で何が楽になるか\nこれまでは運用チームが OpenSearch Dashboards に個別にログインして状態を確認する必要がありました。今回のアップデートで、AWS コンソール上で他のサービスと同じ画面から確認でき、EventBridge 経由で Slack 通知や PagerDuty 連携も自動化できます。\nAWS管理コンソールでの確認手順\nまず、OpenSearch Service 2.17以降のクラスターでCluster Insightsを有効化します：\n$ aws opensearch update-domain-config \\ --domain-name my-opensearch-cluster \\ --cluster-config InsightsSources=Dashboards,API AWS管理コンソールでは、OpenSearch Serviceのドメイン詳細ページに新しく「Cluster Insights」タブが追加されます。ここでは以下の情報を確認できます：\nパフォーマンス推奨事項: インデックスの最適化、シャード配置の改善提案 容量計画: ストレージ使用量の予測とスケーリング推奨事項 セキュリティ設定: アクセス制御や暗号化の改善点 EventBridgeとの連携設定\nCluster InsightsからEventBridgeへのイベント配信を設定することで、問題の自動検知が可能になります：\n{ \u0026#34;Rules\u0026#34;: [ { \u0026#34;Name\u0026#34;: \u0026#34;opensearch-cluster-insights\u0026#34;, \u0026#34;EventPattern\u0026#34;: { \u0026#34;source\u0026#34;: [\u0026#34;aws.opensearch\u0026#34;], \u0026#34;detail-type\u0026#34;: [\u0026#34;OpenSearch Cluster Insights\u0026#34;], \u0026#34;detail\u0026#34;: { \u0026#34;severity\u0026#34;: [\u0026#34;HIGH\u0026#34;, \u0026#34;CRITICAL\u0026#34;] } }, \u0026#34;Targets\u0026#34;: [ { \u0026#34;Id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;Arn\u0026#34;: \u0026#34;arn:aws:sns:us-east-1:123456789012:opensearch-alerts\u0026#34; } ] } ] } Terraformでの設定例\nTerraformを使用してEventBridgeルールを設定する場合：\nresource \u0026#34;aws_cloudwatch_event_rule\u0026#34; \u0026#34;opensearch_insights\u0026#34; { name = \u0026#34;opensearch-cluster-insights\u0026#34; event_pattern = jsonencode({ source = [\u0026#34;aws.opensearch\u0026#34;] detail-type = [\u0026#34;OpenSearch Cluster Insights\u0026#34;] detail = { severity = [\u0026#34;HIGH\u0026#34;, \u0026#34;CRITICAL\u0026#34;] } }) } resource \u0026#34;aws_cloudwatch_event_target\u0026#34; \u0026#34;sns\u0026#34; { rule = aws_cloudwatch_event_rule.opensearch_insights.name target_id = \u0026#34;SendToSNS\u0026#34; arn = aws_sns_topic.opensearch_alerts.arn } AWS Direct Connect BGP監視のCloudWatch統合 BGP（Border Gateway Protocol）とは？ インターネットやネットワーク間でルーティング情報を交換するプロトコルです。Direct Connect では、オンプレミスと AWS 間の経路制御に使われます。BGP セッションが切れると通信不能になるため、監視が欠かせません。\nDirect Connect の BGP セッション状態を CloudWatch で直接監視できるようになりました。これまではカスタムスクリプトや API の定期実行が必要でしたが、標準の CloudWatch メトリクスとして3つの新指標が追加されています。\n新しく追加されたメトリクス\nBGPSessionState: BGPセッションの現在の状態（Established, Idle, Active等） BGPPrefixCount: 受信している経路プレフィックス数 BGPSessionUptime: BGPセッションの稼働時間 CloudWatch監視の設定\nAWS CLIでBGPセッションの状態を確認：\n$ aws cloudwatch get-metric-statistics \\ --namespace AWS/DirectConnect \\ --metric-name BGPSessionState \\ --dimensions Name=ConnectionId,Value=dxcon-xxxxxxxxx \\ --start-time 2026-03-31T00:00:00Z \\ --end-time 2026-03-31T23:59:59Z \\ --period 300 \\ --statistics Average アラーム設定の実装\nBGPセッションダウンを検知するCloudWatchアラームをTerraformで設定：\nresource \u0026#34;aws_cloudwatch_metric_alarm\u0026#34; \u0026#34;bgp_session_down\u0026#34; { alarm_name = \u0026#34;direct-connect-bgp-session-down\u0026#34; comparison_operator = \u0026#34;LessThanThreshold\u0026#34; evaluation_periods = \u0026#34;2\u0026#34; metric_name = \u0026#34;BGPSessionState\u0026#34; namespace = \u0026#34;AWS/DirectConnect\u0026#34; period = \u0026#34;300\u0026#34; statistic = \u0026#34;Average\u0026#34; threshold = \u0026#34;1\u0026#34; alarm_description = \u0026#34;This metric monitors BGP session state\u0026#34; alarm_actions = [aws_sns_topic.direct_connect_alerts.arn] dimensions = { ConnectionId = \u0026#34;dxcon-xxxxxxxxx\u0026#34; } } プレフィックス数監視による経路異常検知\nBGPで受信している経路数の異常を検知するアラーム：\nresource \u0026#34;aws_cloudwatch_metric_alarm\u0026#34; \u0026#34;bgp_prefix_anomaly\u0026#34; { alarm_name = \u0026#34;direct-connect-prefix-count-anomaly\u0026#34; comparison_operator = \u0026#34;LessThanLowerThreshold\u0026#34; evaluation_periods = \u0026#34;3\u0026#34; threshold_metric_id = \u0026#34;ad1\u0026#34; alarm_description = \u0026#34;Detects abnormal BGP prefix count\u0026#34; metric_query { id = \u0026#34;m1\u0026#34; metric { metric_name = \u0026#34;BGPPrefixCount\u0026#34; namespace = \u0026#34;AWS/DirectConnect\u0026#34; period = \u0026#34;300\u0026#34; stat = \u0026#34;Average\u0026#34; dimensions = { ConnectionId = \u0026#34;dxcon-xxxxxxxxx\u0026#34; } } } metric_query { id = \u0026#34;ad1\u0026#34; anomaly_detector { metric_math_anomaly_detector { metric_data_queries { id = \u0026#34;m1\u0026#34; } } } } } Note: BGPメトリクスは5分間隔で更新されます。瞬断検知には ping 監視との併用を検討してください。\nSRE視点での活用ポイント OpenSearch Cluster Insights の使いどころ\n複数環境（本番・ステージング・開発）や複数チームで OpenSearch を共有している場合に効きます。EventBridge 連携で Slack 通知や PagerDuty アラートを自動化し、Cluster Insights の推奨事項を Terraform 設定に反映させる判断材料にできます。小規模クラスターや開発環境のみの場合は、設定コストに見合わないかもしれません。\nDirect Connect BGP 監視の使いどころ\nハイブリッドクラウド環境では、ping や traceroute では検知できない BGP 経路の問題（部分的な経路喪失、フラップなど）を CloudWatch で拾えるようになります。ランブックには BGP セッション状態とプレフィックス数の両方を入れておくと、接続断とルーティング異常を区別して対応できます。Terraform で Direct Connect を管理しているなら、接続作成と同時に BGP 監視も自動化してしまうのがよいでしょう。\n全アップデート一覧 サービス タイトル 概要 Amazon OpenSearch Service Access Cluster Insights through the Amazon OpenSearch Service Console and Amazon EventBridge events Cluster InsightsがAWS管理コンソールからアクセス可能になり、EventBridgeイベント連携も追加 AWS Direct Connect AWS Direct Connect adds CloudWatch metrics for BGP monitoring BGPセッションの健全性を監視する3つの新しいCloudWatchメトリクスを追加 Amazon SageMaker Amazon SageMaker Data Agent is now available in the Amazon SageMaker Unified Studio Query Editor SageMaker Unified Studio Query Editorで、自然言語からSQLクエリを生成するData Agentが利用可能に AWS Elemental MediaTailor AWS Elemental MediaTailor now available in Europe (London) 動的広告挿入サービスがロンドンリージョンで利用開始 Amazon Athena Amazon Athena launches Capacity Reservations in additional regions Athena Capacity Reservationsが追加リージョンで利用可能に まとめ OpenSearch Cluster Insights と Direct Connect BGP 監視の2つは、従来カスタムスクリプトで対応していた領域が AWS 標準機能でカバーされるようになった点で、運用負荷の削減に直結します。どちらも Terraform で IaC 管理しているなら、監視設定も一緒にコード化しておくのがおすすめです。SageMaker Data Agent や MediaTailor のリージョン拡大、Athena の Capacity Reservations 拡大も含め、着実な機能拡充が続いています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260331/","summary":"2026/03/31 のAWSアップデートまとめ。OpenSearch Cluster Insightsのコンソール統合、Direct ConnectのBGP監視CloudWatch対応、Athenaリージョン拡大など5件","title":"【AWS】2026/03/31 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.87 がリリースされました。今回はバグ修正1件のみのホットフィックスリリースです。Cowork 機能のメッセージ配信（Dispatch）が正しく届かないケースがあった問題が修正されています。\n注目アップデート深掘り Cowork Dispatch のメッセージ配信修正 Cowork とは？ Claude Code のバックグラウンドエージェント機能。ターミナルを閉じていてもエージェントが作業を継続し、完了時に通知を送ってくれる。長時間タスクを投げておいて、後から結果を確認する使い方ができる。\nCowork でエージェントが作業を完了した際の通知メッセージ（Dispatch）が、一部のケースで受信側に届かないバグがありました。v2.1.87 でこれが修正され、Dispatch メッセージの配信が安定しています。\n影響範囲\nCowork を使ってバックグラウンドタスクを実行している場合、完了通知が届かずにタスクの結果を見落とす可能性がありました。特に複数の Cowork セッションを並行して走らせているケースで発生しやすかったと思われます。\n対応\nclaude update で v2.1.87 に更新するだけで OK です。\nclaude update claude --version # 2.1.87 であることを確認 全変更点一覧 カテゴリ 変更内容 概要 Fix Cowork Dispatch メッセージ配信 Cowork からの通知メッセージが届かないバグを修正 まとめ バグ修正1件のホットフィックスです。Cowork を日常的に使っている方は早めにアップデートしておくとよいでしょう。通知が来ないのは地味にストレスなので、修正されたのはありがたいところです。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260329/","summary":"v2.1.87 のClaude Codeリリースノートまとめ。Cowork Dispatch のメッセージ配信バグを修正","title":"【Claude Code】v2.1.87 リリースノートまとめ"},{"content":"\nはじめに 2026年3月29日のAWSアップデートは2件です。CloudWatch Logs の低頻度アクセス（IA）クラスに OpenSearch PPL/SQL とデータ保護機能が追加されたことと、Amazon Timestream for InfluxDB に高度なメトリクス機能が入ったことです。どちらもコスト最適化と運用監視に直結するアップデートになっています。\n注目アップデート深掘り CloudWatch Logs IAクラスの機能強化 OpenSearch PPL（Piped Processing Language）とは？ OpenSearchが提供するパイプライン形式のクエリ言語。Unix のパイプのように source=... | where ... | stats ... と処理を連結して書ける。SQLより直感的にログ分析ができるのが特徴。\nAmazon CloudWatch Logsの低頻度アクセス（IA）クラスに、データ保護機能と OpenSearch PPL/SQL サポートが追加されました。これまで標準ログクラスでしか使えなかった分析・保護機能が、IAクラスでも利用可能になります。\nIAクラスの制約が緩和されました\nLogs IAクラスは取り込み料金が標準クラスの50%で済む反面、クエリ機能に制限がありました。今回の追加で、セキュリティ監査やコンプライアンス対応のログ分析をIAクラスのままで実行できるようになっています。\n具体的な検証手順\nまず、既存のログストリームをIAクラスに設定し、新機能を検証してみましょう。\n# ログストリームをIAクラスで作成 $ aws logs create-log-stream \\ --log-group-name \u0026#34;/aws/lambda/security-logs\u0026#34; \\ --log-stream-name \u0026#34;security-events-ia\u0026#34; \\ --log-class INFREQUENT_ACCESS データ保護機能を設定するには、機密データの識別パターンを定義します：\n# データ保護ポリシーの作成 $ aws logs put-data-protection-policy \\ --log-group-identifier \u0026#34;/aws/lambda/security-logs\u0026#34; \\ --policy-document \u0026#39;{ \u0026#34;Version\u0026#34;: \u0026#34;2021-01-01\u0026#34;, \u0026#34;Statement\u0026#34;: [{ \u0026#34;Sid\u0026#34;: \u0026#34;MaskPII\u0026#34;, \u0026#34;DataIdentifier\u0026#34;: [ \u0026#34;arn:aws:dataprotection::aws:data-identifier/EmailAddress\u0026#34;, \u0026#34;arn:aws:dataprotection::aws:data-identifier/CreditCardNumber\u0026#34; ], \u0026#34;Operation\u0026#34;: { \u0026#34;Audit\u0026#34;: { \u0026#34;FindingsDestination\u0026#34;: { \u0026#34;CloudWatchLogs\u0026#34;: { \u0026#34;LogGroup\u0026#34;: \u0026#34;DataProtectionAuditLogs\u0026#34; } } }, \u0026#34;Deidentify\u0026#34;: { \u0026#34;MaskConfig\u0026#34;: {} } } }] }\u0026#39; OpenSearch PPLクエリの実行例：\n# PPLクエリでセキュリティイベントを分析 $ aws logs start-query \\ --log-group-name \u0026#34;/aws/lambda/security-logs\u0026#34; \\ --start-time 1709251200 \\ --end-time 1709337600 \\ --query-string \u0026#39;source=table | where event_type=\u0026#34;login_failed\u0026#34; | stats count() by user_id | sort count desc | head 10\u0026#39; 標準クラスとの比較\n項目 標準クラス IAクラス（今回の追加後） 取り込み料金 100% 50% PPL/SQL クエリ ○ ○（NEW） データ保護 ○ ○（NEW） リアルタイムアラート ○ × Timestream for InfluxDBの高度なメトリクス Amazon Timestream for InfluxDBとは？ InfluxDB 2のフルマネージド版。IoTセンサーやアプリのメトリクスなど、時系列データの保存・クエリに特化したサービス。OSS版InfluxDBとAPIレベルで互換性がある。\nInfluxDB 2インスタンスの詳細な運用メトリクスが、追加設定なしで自動的にCloudWatchへ送信されるようになりました。\n何が変わるか\nInfluxDBはセンサーデータやメトリクスを大量に処理するため、DB自体の健全性監視が欠かせません。これまでは自前でメトリクス収集の仕組みを用意する必要がありましたが、有効化するだけでCloudWatchに流れるようになります。\n実際の設定手順\nTerraformを使用してTimestream for InfluxDBインスタンスを作成し、高度なメトリクスを有効化：\nresource \u0026#34;aws_timestreaminfluxdb_db_instance\u0026#34; \u0026#34;monitoring_db\u0026#34; { name = \u0026#34;production-metrics\u0026#34; db_instance_type = \u0026#34;db.influx.medium\u0026#34; allocated_storage = 20 bucket = \u0026#34;monitoring-bucket\u0026#34; organization = \u0026#34;production-org\u0026#34; username = \u0026#34;admin\u0026#34; password = var.admin_password # 高度なメトリクス機能を有効化 publicly_accessible = false vpc_subnet_ids = [aws_subnet.private.id] vpc_security_group_ids = [aws_security_group.timestream.id] tags = { Environment = \u0026#34;production\u0026#34; Purpose = \u0026#34;metrics-monitoring\u0026#34; } } CloudWatchダッシュボードでメトリクスを可視化：\n{ \u0026#34;widgets\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;metric\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;metrics\u0026#34;: [ [\u0026#34;AWS/TimestreamInfluxDB\u0026#34;, \u0026#34;QueryExecutionTime\u0026#34;, \u0026#34;DBInstanceIdentifier\u0026#34;, \u0026#34;production-metrics\u0026#34;], [\u0026#34;.\u0026#34;, \u0026#34;WriteLatency\u0026#34;, \u0026#34;.\u0026#34;, \u0026#34;.\u0026#34;], [\u0026#34;.\u0026#34;, \u0026#34;ReadLatency\u0026#34;, \u0026#34;.\u0026#34;, \u0026#34;.\u0026#34;], [\u0026#34;.\u0026#34;, \u0026#34;CPUUtilization\u0026#34;, \u0026#34;.\u0026#34;, \u0026#34;.\u0026#34;] ], \u0026#34;period\u0026#34;: 300, \u0026#34;stat\u0026#34;: \u0026#34;Average\u0026#34;, \u0026#34;region\u0026#34;: \u0026#34;us-east-1\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Timestream InfluxDB Performance\u0026#34; } } ] } Python SDKを使用したメトリクス監視の自動化：\nimport boto3 from datetime import datetime, timedelta def check_timestream_health(): cloudwatch = boto3.client(\u0026#39;cloudwatch\u0026#39;) # 過去1時間のCPU使用率を取得 response = cloudwatch.get_metric_statistics( Namespace=\u0026#39;AWS/TimestreamInfluxDB\u0026#39;, MetricName=\u0026#39;CPUUtilization\u0026#39;, Dimensions=[ { \u0026#39;Name\u0026#39;: \u0026#39;DBInstanceIdentifier\u0026#39;, \u0026#39;Value\u0026#39;: \u0026#39;production-metrics\u0026#39; } ], StartTime=datetime.utcnow() - timedelta(hours=1), EndTime=datetime.utcnow(), Period=300, Statistics=[\u0026#39;Average\u0026#39;, \u0026#39;Maximum\u0026#39;] ) # 異常値の検出とアラート for datapoint in response[\u0026#39;Datapoints\u0026#39;]: if datapoint[\u0026#39;Maximum\u0026#39;] \u0026gt; 80: print(f\u0026#34;High CPU detected: {datapoint[\u0026#39;Maximum\u0026#39;]}% at {datapoint[\u0026#39;Timestamp\u0026#39;]}\u0026#34;) SRE視点での活用ポイント CloudWatch Logs IA の使いどころ\n月次レポートや四半期レビューでしか参照しないログは、IAクラスへの移行候補になります。Terraform でログストリームの log_class を INFREQUENT_ACCESS に変えるだけで取り込みコストが半減し、PPL/SQLでの分析もデータ保護も使えます。PCI DSS や GDPR 対応のログも対象にできます。\nただし、リアルタイムアラートが必要なログは標準クラスのまま残してください。判断基準は「そのログに即時性が求められるかどうか」です。\nTimestream for InfluxDB メトリクスの使いどころ\nCloudWatch アラームと組み合わせれば、InfluxDB の異常を早期検知してランブックに組み込めます。これまで自前で構築していた監視パイプラインが不要になるのは地味に効きます。\n注意点として、メトリクス送信分の CloudWatch 料金が加算されます。不要なメトリクスは送信対象から外す設定を入れておくとよいでしょう。\n全アップデート一覧 サービス タイトル 概要 CloudWatch Logs Amazon CloudWatch Logs now supports data protection, OpenSearch PPL and OpenSearch SQL for the Infrequent Access ingestion class 低頻度アクセスログクラスにデータ保護機能とOpenSearch PPL/SQLサポートを追加。コスト効率的なログ分析と機密データ保護を実現 Timestream Amazon Timestream for InfluxDB Now Supports Advanced Metrics InfluxDBインスタンスの詳細な運用メトリクスを自動的にCloudWatchに公開。追加設定不要でリアルタイムモニタリングが可能 まとめ 2件ともコスト最適化と運用監視がテーマです。CloudWatch Logs IA は「安いけど機能が足りない」という従来の弱点が解消され、より多くのログをIAクラスに寄せられるようになりました。Timestream for InfluxDB の高度なメトリクスは、有効化するだけで CloudWatch に流れるので導入コストが低いです。週明けにでも設定を見直してみてはいかがでしょうか。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260329/","summary":"2026/03/29 のAWSアップデートまとめ。CloudWatch Logs IAクラスにPPL/SQL・データ保護が追加、Timestream for InfluxDBに高度なメトリクス機能","title":"【AWS】2026/03/29 のアップデートまとめ"},{"content":"\nはじめに 2026年3月28日、AWSから9件のアップデートが発表されました。今回は特にセキュリティとアクセス制御に関する改善が目立ち、AWS Management Consoleでのサービス・リージョン可視性制御機能の追加と、AWS HealthImagingでの研究レベル細粒度アクセス制御が注目ポイントです。また、Lambda Managed Instancesが最大32GBメモリ・16vCPUに拡張されるなど、パフォーマンス面での大幅な向上も見られます。\n注目アップデート深掘り AWS Management Consoleのサービス・リージョン可視性制御機能 この新機能は、AWS Management Consoleの「Unified Settings」からサービスやリージョンの表示/非表示をコントロールできるUI設定です。IAMポリシーやSCPとは異なり、コンソール画面上の表示そのものを制御します。\n大規模な組織やマルチアカウント環境において、ユーザーに対して必要最小限のサービスやリージョンのみを表示することで、セキュリティとユーザビリティの両面を改善できます。\n従来の方法との比較 従来のアプローチ（IAMポリシーのみ）：\nアクセス権限はないが、サービス一覧には表示される ユーザーが誤って制限されたサービスにアクセスしようとしてエラーが発生 新人教育時に混乱を招く可能性 新機能を使用したアプローチ：\n許可されたサービス・リージョンのみが表示される ユーザーインターフェースがすっきりし、操作ミスが減少 部門や役割に応じたカスタマイズされたコンソール体験を提供 AWS Lambda Managed Instancesの大幅な性能向上 拡張された性能仕様の意義 今回のアップデートで、Lambda Managed Instancesが最大32GBメモリと16vCPUまで拡張されました。これまでLambdaは軽量なワークロード向けとされていましたが、この大幅な性能向上により、従来はEC2やFargateでしか実行できなかった重い処理もサーバーレスアーキテクチャで実現できるようになります。\n性能比較と適用シナリオ 従来のLambda制限：\nメモリ：最大10,240MB（10GB） vCPU：メモリに比例して最大6vCPU相当 新しい制限：\nメモリ：最大32,768MB（32GB） vCPU：最大16vCPU 具体的な設定例：\n# AWS CDKを使用した高性能Lambda関数の定義 from aws_cdk import ( aws_lambda as _lambda, Duration, Stack ) class HighPerformanceLambdaStack(Stack): def __init__(self, scope, construct_id, **kwargs): super().__init__(scope, construct_id, **kwargs) # 32GB メモリ、16 vCPU のLambda関数 high_memory_function = _lambda.Function( self, \u0026#34;HighMemoryFunction\u0026#34;, runtime=_lambda.Runtime.PYTHON_3_11, handler=\u0026#34;index.handler\u0026#34;, code=_lambda.Code.from_asset(\u0026#34;lambda\u0026#34;), memory_size=32768, # 32GB timeout=Duration.minutes(15), environment={ \u0026#39;PYTHONPATH\u0026#39;: \u0026#39;/var/task\u0026#39;, \u0026#39;MEMORY_SIZE\u0026#39;: \u0026#39;32768\u0026#39; } ) Terraformでの設定例：\nresource \u0026#34;aws_lambda_function\u0026#34; \u0026#34;high_performance\u0026#34; { filename = \u0026#34;lambda_function.zip\u0026#34; function_name = \u0026#34;high-performance-processor\u0026#34; role = aws_iam_role.lambda_role.arn handler = \u0026#34;index.handler\u0026#34; runtime = \u0026#34;python3.11\u0026#34; # 最大性能設定 memory_size = 32768 # 32GB timeout = 900 # 15分 environment { variables = { MEMORY_SIZE = \u0026#34;32768\u0026#34; CPU_COUNT = \u0026#34;16\u0026#34; } } } Note: 高メモリ設定を使用する際は、コストが大幅に増加する可能性があります。必要な場面でのみ使用し、適切なタイムアウト設定でコストを制御することが重要です。\nSRE視点での活用ポイント 今回のアップデートは、SREの日常的な運用改善に直接的なインパクトをもたらします。\nAWS Management Consoleの可視性制御は、特にマルチチーム環境での運用標準化に有効です。Terraformでインフラを管理している場合、組織のポリシーとして各チームのアクセス範囲を明確に定義し、それをコンソール表示レベルまで一貫して適用できます。障害対応時の混乱を避けるため、インシデント対応チーム向けには必要最小限のサービス（CloudWatch、EC2、RDS等）のみを表示する設定にすることで、迅速な問題特定が可能になります。\n一方、導入時は段階的なアプローチが重要です。いきなり大幅な制限をかけると、既存の運用フローに支障をきたす可能性があります。まずは非本番環境で設定をテストし、チームのフィードバックを収集してから本番適用するのが安全です。\nLambda の高性能化については、これまでバッチジョブでECS Fargateを使用していたようなワークロードの一部をサーバーレス化できる可能性があります。特に、不定期に発生する重い処理（レポート生成、データ変換等）では、常時起動が不要なLambdaの方がコスト効率が良い場合があります。ただし、実行時間が15分を超える処理や、頻繁に実行される処理については、依然としてFargateやEC2の方が適している可能性が高いため、ワークロードの特性を十分に分析した上で判断することが重要です。\nAmazon GameLiftとは？ オンラインマルチプレイヤーゲーム用のサーバーホスティングサービスです。ゲームセッションの自動スケーリング、マッチメイキング、低レイテンシー接続を提供し、大規模なリアルタイムゲームの運用を支援します。\nAWS HealthImagingとは？ 医療画像（DICOM形式のCT・MRI等）をクラウド上で保存・管理・分析するためのサービスです。医療機関や研究機関向けに、HIPAA準拠のセキュアなデータ管理と高速な画像アクセスを提供します。\nAmazon Bedrock AgentCoreとは？ Bedrock上でAIエージェントを構築・実行するためのマネージドランタイム環境です。Step Functionsとの統合により、AIエージェントをワークフローに組み込んだ自動化が実現できます。\n全アップデート一覧 サービス タイトル 概要 Amazon GameLift EC2次世代インスタンスファミリーサポート拡張 EC2第5～8世代インスタンス（M、C、Rシリーズ）に対応、Intel/AMD/Gravitonプロセッサをサポート AWS Step Functions 28の新サービス統合追加 Amazon Bedrock AgentCoreを含む28の新サービス統合により、AIワークフローの自動化を強化 AWS Management Console サービス・リージョン可視性制御機能 アカウント設定でサービスとリージョンの表示を制御、組織的なアクセス管理を改善 AWS Lambda 32GB メモリ・16vCPU サポート Managed Instancesで大幅な性能向上、重いワークロードのサーバーレス実行が可能 AWS HealthImaging 研究レベル細粒度アクセス制御 DICOM研究レベルでの詳細なアクセス制御をサポート、医療データのセキュリティを強化 Amazon EC2 U7i インスタンス欧州ミラノ展開 高メモリU7i（メモリ最適化・Intel搭載）インスタンスが欧州ミラノリージョンで利用可能 Amazon ECS GovCloud での FIPS 認定ワークロード対応 Managed InstancesがGraviton（ARM系高性能）とGPUアクセラレーテッドインスタンスでFIPS認定ワークロードをサポート Amazon CloudWatch Logs Infrequent Access クラスの分析機能拡張 OpenSearch SQL/PPL対応とデータ保護機能（機密情報の自動検出・マスキング）を追加 Amazon Timestream for InfluxDB Advanced Metrics 機能追加 CloudWatchへの詳細な運用メトリクス自動公開、追加設定不要 まとめ 今回のアップデートは、セキュリティとパフォーマンスの両軸で大きな進歩を見せています。Management Consoleの可視性制御機能は、大規模組織でのガバナンス強化に直結し、Lambdaの高性能化はサーバーレスアーキテクチャの適用範囲を大幅に拡大します。特に、これまでサーバーレスでは難しかった重い処理が実現できるようになったことで、アーキテクチャ設計の選択肢が豊富になりました。\n医療・政府機関向けのコンプライアンス対応強化も顕著で、AWS HealthImagingやECS GovCloudでのFIPS対応など、厳格な規制要件を満たすソリューションが充実してきています。これらの機能は、従来は導入が困難だった分野でのクラウド採用を後押しするものと考えられます。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260328/","summary":"2026/03/28 のAWSアップデートまとめ","title":"【AWS】2026/03/28 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.86 がリリースされました。今回は新機能よりもバグ修正と安定性改善が中心のリリースです。注目すべき改善として、APIリクエストへの X-Claude-Code-Session-Id ヘッダー追加、Read ツールのトークン使用量削減、Bedrock/Vertex/Foundry のプロンプトキャッシュヒット率改善があります。また、--resume の致命的なバグ修正やOOM対策など、日常的な使用感に直結する修正が多数含まれています。\n注目アップデート深掘り Session ID ヘッダーでプロキシのセッション集約が可能に APIリクエストに X-Claude-Code-Session-Id ヘッダーが追加されました。これにより、企業環境でClaude Code のトラフィックをプロキシ経由で管理している場合、リクエストボディをパースすることなくセッション単位でリクエストを集約・監視できるようになります。\nSRE業務への影響\nAPI Gateway やリバースプロキシでClaude Codeのトラフィックを管理している企業では、このヘッダーを使って：\nセッション単位のトークン使用量を集計 特定セッションのリクエストをログから追跡 チーム別・プロジェクト別のコスト配分 # プロキシログからセッション別のリクエスト数を集計する例 $ grep \u0026#34;X-Claude-Code-Session-Id\u0026#34; /var/log/proxy/access.log \\ | awk -F\u0026#39;\u0026#34;\u0026#39; \u0026#39;{print $2}\u0026#39; | sort | uniq -c | sort -rn Read ツールのトークン使用量を大幅削減 Read ツールに2つの最適化が入りました：\nコンパクト行番号フォーマット: 行番号の表示形式を最適化し、トークン消費を削減 重複再読み取りの重複排除: 同じファイルを変更なしに再度読んだ場合、重複コンテンツを省略 大量のファイルを読む作業（コードレビュー、リファクタリング等）でのトークン効率が改善されます。@ によるファイルメンション時もJSON エスケープが不要になり、rawな文字列としてコンテンツが渡されるようになりました。\nBedrock/Vertex/Foundry のキャッシュヒット率改善 3Pプロバイダー（Bedrock、Vertex AI、Foundry）利用者向けに、ツール説明文から動的コンテンツを除去することでプロンプトキャッシュのヒット率が改善されました。\nプロンプトキャッシュとは？ APIリクエストのプロンプト部分が前回と同一の場合、キャッシュされた結果を再利用する仕組みです。キャッシュヒット時はレイテンシーが短縮され、一部プロバイダーではコスト削減にもなります。ツール説明文に動的な値が含まれるとキャッシュが無効化されていた問題が解消されました。\n実用的な活用ポイント \u0026ndash;resume の安定性向上: v2.1.85より前のセッションを --resume で再開すると「tool_use ids were found without tool_result blocks」エラーで失敗するバグが修正されました。長期セッションの再開が安定して動作するようになります。\n外部ファイルの Read/Write/Edit 修正: 条件付きスキルやルールが設定されている環境で、プロジェクトルート外のファイル（~/.claude/CLAUDE.md 等）の読み書きが失敗するバグが修正されました。\nOOM 対策: /feedback を非常に長いセッション（大量のトランスクリプト）で使用するとメモリ不足でクラッシュする問題が修正されました。また、長時間セッションでのマークダウン/ハイライトレンダーキャッシュによるメモリ増加も修正されています。\nmacOS キーチェーンキャッシュ延長: MCP コネクタが多数設定されている場合の起動時イベントループ停滞が改善されました（キャッシュ: 5秒→30秒）。\nOAuth URL コピー修正: c ショートカットでOAuthログインURLをコピーする際、先頭約20文字しかコピーされないバグが修正されました。\n全変更点一覧 カテゴリ 変更内容 概要 Feature X-Claude-Code-Session-Id ヘッダー プロキシでのセッション集約用 Feature .jj / .sl VCS除外 Jujutsu / Sapling メタデータを除外 Improvement Read ツールのトークン削減 コンパクト行番号 + 重複再読み取り排除 Improvement @ メンションのトークン削減 raw文字列化（JSON エスケープ不要に） Improvement 3Pプロバイダーキャッシュ改善 ツール説明文から動的コンテンツを除去 Improvement macOS キーチェーンキャッシュ 5秒→30秒に延長（MCP多数時の起動改善） Improvement /skills 表示最適化 説明文250文字キャップ + アルファベット順 Fix --resume エラー修正 v2.1.85以前のセッション再開が可能に Fix Write/Edit/Read 外部ファイル修正 条件付きスキル設定時のプロジェクト外ファイル対応 Fix /feedback OOM 修正 大量トランスクリプトでのメモリ不足対策 Fix OAuth URL コピー修正 c ショートカットで全URLコピー可能に Fix OAuth トークンマスク漏洩修正 狭端末での行折り返し時のトークン先頭漏洩を防止 Fix プラグインスクリプト権限修正 macOS/Linux で v2.1.83 以降の Permission denied を修正 Fix ステータスライン誤表示修正 複数インスタンス時の /model 表示を修正 Fix --bare モード MCP修正 インタラクティブセッションでのMCPツール欠落を修正 Fix メモリリーク修正 マークダウン/ハイライトキャッシュの文字列保持を解消 Fix (VSCode) \u0026ldquo;Not responding\u0026rdquo; 誤表示 長時間操作中の誤検知を修正 Fix (VSCode) OAuthリフレッシュ後のモデル Max planユーザーのSonnetフォールバックを修正 まとめ v2.1.86は安定性・パフォーマンス改善にフォーカスしたリリースです。新機能は X-Claude-Code-Session-Id ヘッダーと Jujutsu/Sapling VCS除外のみですが、日常的な使用感に直結するバグ修正が豊富です。\n特に --resume の修正、外部ファイル操作の修正、OOM対策は、長期セッションやカスタム設定を活用しているユーザーにとって重要な改善です。Read ツールのトークン削減と3Pプロバイダーのキャッシュ改善は、コスト効率の向上にも寄与します。\nVSCode拡張の修正（\u0026ldquo;Not responding\u0026quot;誤表示、OAuthリフレッシュ後のモデルフォールバック）もあり、IDE経由で利用しているユーザーの体験も改善されています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260328/","summary":"v2.1.86 のClaude Codeリリースノートまとめ。Session IDヘッダー追加、Readツールのトークン削減、Bedrock/Vertexキャッシュ改善、多数のバグ修正","title":"【Claude Code】v2.1.86 リリースノートまとめ"},{"content":"\nはじめに Claude Code v2.1.84 および v2.1.85 がリリースされました。v2.1.84では、Windows環境でのPowerShellツール（opt-inプレビュー）、Bedrock/Vertex AI向けの環境変数による詳細なモデル制御、フック機能の拡張が主な変更点です。v2.1.85ではフック条件フィルタの追加やMCP OAuth改善など、運用品質の向上が図られています。\n注目アップデート深掘り PowerShell ツール（opt-in プレビュー） v2.1.84で最も注目すべき新機能が、Windows向けPowerShellツールのopt-inプレビューです。従来のClaude CodeはBashツールのみでLinux/macOS環境が前提でしたが、PowerShellツールの追加によりWindows Server環境でも直接コマンド実行が可能になります。\n有効化方法\nPowerShellツールはopt-inのため、明示的に有効化が必要です：\n{ \u0026#34;permissions\u0026#34;: { \u0026#34;allow\u0026#34;: [\u0026#34;PowerShell\u0026#34;] } } PowerShellツールとは？ Claude CodeがWindows環境でPowerShellコマンドを直接実行できるようにする新しいツールです。Bashツールと同様の位置づけで、ファイル操作、プロセス管理、Azure CLI呼び出しなどが可能になります。\nWindows ServerでIaCを管理しているチームや、Azure環境との連携が必要なSREにとって、これまでWSL経由で行っていた作業をネイティブなPowerShellで実行できるようになる点が大きなメリットです。\n詳細: https://code.claude.com/docs/en/tools-reference#powershell-tool\n3Pモデル制御の環境変数拡張 Bedrock、Vertex AI、Foundry経由でClaude Codeを利用している企業向けに、モデル制御の環境変数が大幅に拡張されました。\n# デフォルトモデルの能力検出をオーバーライド $ export ANTHROPIC_DEFAULT_OPUS_MODEL_SUPPORTS=\u0026#34;effort,thinking\u0026#34; $ export ANTHROPIC_DEFAULT_SONNET_MODEL_SUPPORTS=\u0026#34;effort,thinking\u0026#34; # /model ピッカーのラベルをカスタマイズ $ export ANTHROPIC_DEFAULT_OPUS_MODEL_NAME=\u0026#34;Claude Opus (Bedrock)\u0026#34; $ export ANTHROPIC_DEFAULT_OPUS_MODEL_DESCRIPTION=\u0026#34;us-east-1 endpoint\u0026#34; 3Pプロバイダー経由ではモデルのバージョンがピン留めされることがあり、能力検出が正しく動作しないケースがありました。これらの環境変数により、effort（推論コスト制御）やthinking（拡張思考）の対応状況を明示的に指定できるようになります。\nHooks の条件フィルタ（v2.1.85） v2.1.85で追加されたifフィールドにより、フックの発火条件をパーミッションルール構文で指定できるようになりました。\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;PreToolUse\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;Bash\u0026#34;, \u0026#34;if\u0026#34;: \u0026#34;Bash(git *)\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;echo \u0026#39;git command detected\u0026#39;\u0026#34; } ] } } 従来はmatcherでツール名を指定するだけでしたが、ifフィールドでBash(git *)のように引数パターンまで絞り込めるようになりました。全てのBash実行でフックプロセスが起動されていた状況が改善され、プロセス生成のオーバーヘッドを大幅に削減できます。\n実用的な活用ポイント ストリーミングタイムアウトの調整: CLAUDE_STREAM_IDLE_TIMEOUT_MS環境変数（デフォルト90秒）で、ストリーミングのアイドル監視閾値を設定できます。ネットワークが不安定な環境や、レスポンスが遅い3Pプロバイダー利用時に値を大きくすることで、不要な切断を防げます。\nリクエストIDによるデバッグ: APIリクエストにx-client-request-idヘッダーが付与されるようになりました。タイムアウトやエラー発生時にAnthropicサポートへ共有することで、問題の特定が格段に容易になります。\nバックグラウンドタスクの通知: Bashのバックグラウンドタスクが対話プロンプトで停止している場合、約45秒後に通知が表示されるようになりました。sudo待ちなどでタスクが固まっている状況を早期に検知できます。\nMCP説明文の2KB制限: MCPツールの説明文とサーバー指示が2KBにキャップされました。OpenAPI生成されたMCPサーバーがコンテキストを圧迫する問題が解消されます。\n全変更点一覧 カテゴリ 変更内容 概要 Feature PowerShell ツール（v2.1.84） Windows向け opt-in プレビュー Feature 3Pモデル制御環境変数（v2.1.84） ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL_SUPPORTS/NAME/DESCRIPTION Feature CLAUDE_STREAM_IDLE_TIMEOUT_MS（v2.1.84） ストリーミングアイドル監視の閾値設定 Feature TaskCreated フック（v2.1.84） タスク作成時に発火するフックイベント Feature WorktreeCreate HTTP フック（v2.1.84） ワークツリー作成時にHTTPフック対応 Feature allowedChannelPlugins（v2.1.84） 管理者向けチャンネルプラグイン許可リスト Feature フック条件フィルタ if（v2.1.85） パーミッションルール構文でフック発火条件を制御 Feature MCPサーバー環境変数（v2.1.85） CLAUDE_CODE_MCP_SERVER_NAME/URL を headersHelper に提供 Improvement x-client-request-id ヘッダー APIリクエストのデバッグ追跡 Improvement MCP説明文 2KB キャップ コンテキスト圧迫防止 Improvement ディープリンクのターミナル選択 優先ターミナルで開くように改善 Improvement Rules/Skills paths: YAML対応 glob のYAMLリスト形式をサポート Fix IME入力（CJK）のインライン描画 日本語入力がカーソル位置に正しく表示 Fix macOS キーチェーン一時エラー \u0026ldquo;Not logged in\u0026rdquo; 誤表示を修正 Fix Partial clone リポジトリ起動性能 Scalar/GVFS での大量blob ダウンロード回避 Fix /compact のコンテキスト超過 大規模会話でのコンパクト失敗を修正（v2.1.85） Fix MCP OAuth スコープ再認可 リフレッシュトークン存在時の昇格フロー修正（v2.1.85） まとめ v2.1.84/v2.1.85は「マルチプラットフォーム対応」と「運用精度の向上」が2大テーマです。PowerShellツールによるWindows対応、3Pモデル制御環境変数によるBedrock/Vertex AI環境でのカスタマイズ性向上は、企業環境でのClaude Code活用範囲を広げます。\nv2.1.85のフック条件フィルタ（ifフィールド）は、PreToolUseフックを多用しているユーザーにとって大きな改善です。不要なプロセス生成を削減し、フックのパフォーマンスオーバーヘッドを最小化できます。\nバグ修正面では、日本語入力（IME）のインライン描画修正やmacOSキーチェーンの一時エラー対応など、日常的な使用感を改善する修正が多く含まれています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260327/","summary":"v2.1.84/v2.1.85 のClaude Codeリリースノートまとめ。PowerShellツール、3Pモデル制御環境変数、Hooks条件フィルタ等","title":"【Claude Code】v2.1.84 / v2.1.85 リリースノートまとめ"},{"content":"\nはじめに 2026年3月27日のAWSアップデートでは、7件の重要な機能強化が発表されました。特に注目すべきは、高性能コンピューティング分野でのGraviton4プロセッサを搭載したEC2 R8gdインスタンスの新リージョン展開と、データベースアクセス最適化を図るAWS Advanced JDBC WrapperでのValkeyキャッシング機能の追加です。これらのアップデートは、パフォーマンス向上とコスト最適化の両面で大きな価値をもたらします。\n注目アップデート深掘り Amazon EC2 R8gdインスタンスの新リージョン展開とGraviton4の実力 Amazon EC2 R8gd（メモリ最適化・ローカルSSD搭載、Graviton4プロセッサ搭載）インスタンスが追加の4つのリージョンで利用可能になったことで、より多くの地域でArmベースの高性能コンピューティングが活用できるようになりました。このアップデートが重要な理由は、Graviton4プロセッサがGraviton3と比較して最大30%のパフォーマンス向上を実現し、特にI/Oインテンシブなワークロードで最大40%の改善を提供する点にあります。\nR8gdインスタンスの具体的な検証手順として、まず既存のワークロードでのベンチマークテストを実施することが重要です。以下にAWS CLIを使用したインスタンス起動例を示します：\n# R8gdインスタンスの起動 $ aws ec2 run-instances \\ --image-id ami-0abcdef1234567890 \\ --instance-type r8gd.large \\ --key-name my-key-pair \\ --security-groups my-security-group \\ --user-data file://performance-test-script.sh Terraformを使用した場合のリソース定義例：\nresource \u0026#34;aws_instance\u0026#34; \u0026#34;r8gd_test\u0026#34; { ami = \u0026#34;ami-0abcdef1234567890\u0026#34; # Arm64対応AMI instance_type = \u0026#34;r8gd.large\u0026#34; root_block_device { volume_type = \u0026#34;gp3\u0026#34; volume_size = 100 } # ローカルNVMe SSDを活用した設定 ephemeral_block_device { device_name = \u0026#34;/dev/sdb\u0026#34; virtual_name = \u0026#34;ephemeral0\u0026#34; } tags = { Name = \u0026#34;graviton4-performance-test\u0026#34; } } パフォーマンス比較を行う際は、CPU集約的タスクとI/O集約的タスクの両方でベンチマークを実施することが推奨されます。例えば、データベースワークロードでは以下のようなPythonスクリプトでIOPSテストを行えます：\nimport boto3 import time # CloudWatchメトリクスでパフォーマンスを監視 cloudwatch = boto3.client(\u0026#39;cloudwatch\u0026#39;) def measure_disk_performance(): start_time = time.time() # ローカルNVMe SSDへの書き込みテスト with open(\u0026#39;/mnt/nvme/test_file\u0026#39;, \u0026#39;wb\u0026#39;) as f: for i in range(10000): f.write(b\u0026#39;0\u0026#39; * 1024) # 1KB書き込み end_time = time.time() return end_time - start_time # メトリクス送信 duration = measure_disk_performance() cloudwatch.put_metric_data( Namespace=\u0026#39;Custom/Performance\u0026#39;, MetricData=[{ \u0026#39;MetricName\u0026#39;: \u0026#39;DiskWriteLatency\u0026#39;, \u0026#39;Value\u0026#39;: duration, \u0026#39;Unit\u0026#39;: \u0026#39;Seconds\u0026#39; }] ) AWS Advanced JDBC WrapperでのValkeyキャッシング機能 AWS Advanced JDBC WrapperにValkeyキャッシング機能が追加されたことで、頻繁に実行されるクエリの読み取りパフォーマンスを大幅に改善できるようになりました。この機能が重要な理由は、従来のデータベース接続において発生していたレイテンシとスループットのボトルネックを、アプリケーションレベルでのキャッシング機能により解決できる点にあります。\nValkeyは Redis のオープンソースフォークとして高い互換性を持ちながら、より優れた性能特性を提供します。従来の方法では、アプリケーション側で独自にキャッシュレイヤーを実装する必要がありましたが、JDBC Wrapperに統合されることで、透過的なキャッシングが実現されます。\n具体的な設定例として、Java アプリケーションでの実装を以下に示します：\n// JDBC接続文字列でValkeyキャッシングを有効化 String jdbcUrl = \u0026#34;jdbc:aws-wrapper:postgresql://mydb.cluster-xyz.us-east-1.rds.amazonaws.com:5432/mydb\u0026#34; + \u0026#34;?wrapperPlugins=readWriteSplitting,queryCache\u0026#34; + \u0026#34;\u0026amp;queryCacheUrl=valkey://my-valkey-cluster.abc123.cache.amazonaws.com:6379\u0026#34; + \u0026#34;\u0026amp;queryCacheTtl=300\u0026#34; + // 5分間のTTL \u0026#34;\u0026amp;queryCacheSize=1000\u0026#34;; // 最大1000エントリ Connection conn = DriverManager.getConnection(jdbcUrl, username, password); // 頻繁に実行されるクエリ例 PreparedStatement stmt = conn.prepareStatement( \u0026#34;SELECT product_name, price FROM products WHERE category = ? AND status = \u0026#39;active\u0026#39;\u0026#34; ); stmt.setString(1, \u0026#34;electronics\u0026#34;); ResultSet rs = stmt.executeQuery(); // 初回はDBアクセス、2回目以降はキャッシュから取得 パフォーマンス測定のためのTerraformによるValkey クラスターの構築例：\nresource \u0026#34;aws_elasticache_serverless_cache\u0026#34; \u0026#34;valkey_cache\u0026#34; { engine = \u0026#34;valkey\u0026#34; name = \u0026#34;jdbc-wrapper-cache\u0026#34; cache_usage_limits { data_storage { maximum = 10 unit = \u0026#34;GB\u0026#34; } ecpu_per_second { maximum = 5000 } } description = \u0026#34;Valkey cache for JDBC wrapper\u0026#34; kms_key_id = aws_kms_key.example.arn security_group_ids = [aws_security_group.valkey.id] subnet_ids = aws_subnet.example[*].id } Note: Valkeyキャッシング機能を導入する際は、データの整合性要件とキャッシュTTLのバランスを慎重に設計する必要があります。特に、更新頻度の高いデータについては、キャッシュ無効化戦略も併せて検討してください。\nSRE視点での活用ポイント 今回のアップデートは、SRE業務における可観測性とパフォーマンス最適化の観点で大きな価値を提供します。\nEC2 R8gdインスタンスについては、既存のモニタリング体制でGraviton4ベースのインスタンスメトリクスを適切に監視できるよう、CloudWatchダッシュボードの更新が必要です。特に、ローカルNVMe SSDのI/Oメトリクスは従来のEBSベースの監視とは異なる観点が必要になります。Terraformで管理しているインフラがあれば、インスタンスタイプの変更は比較的容易ですが、Armアーキテクチャへの移行時はアプリケーションの互換性検証が重要です。段階的な移行戦略として、まずステージング環境でのパフォーマンステストを実施し、本番環境では Blue-Green デプロイメントやカナリアリリースを活用することが推奨されます。\nJDBC WrapperのValkeyキャッシング機能は、データベース起因の障害対応において特に有効です。データベースの負荷が高い状況でも、キャッシュレイヤーが適切に機能していれば、アプリケーションの可用性を維持できる可能性が高まります。CloudWatch アラームと組み合わせて、キャッシュヒット率やデータベース接続数を監視することで、パフォーマンス劣化の早期検知が可能になります。障害対応のランブックに組み込む際は、キャッシュクリアの手順やフォールバック機構の確認項目を追加することが重要です。ただし、導入時はデータの整合性要件を十分に検証し、キャッシュ障害時の影響範囲を事前に把握しておく必要があります。\n全アップデート一覧 Aurora DSQLとは？ AWSが提供する分散SQLデータベースサービスで、PostgreSQL互換でありながら、複数リージョンにまたがるアクティブ-アクティブ構成を実現します。従来のAuroraがリードレプリカ方式だったのに対し、DSQLは全ノードが書き込み可能で、強整合性を保証します。\nValkeyとは？ Redisのオープンソースフォーク（BSDライセンス）で、Redis互換のインメモリキャッシュ・データストアです。2024年にRedisがライセンスを変更した後、Linux Foundationの下で開発が進められています。AWSのElastiCacheでもサポートされています。\nアップデート 概要 AWS Lambda increases the file descriptor limit to 4,096 Lambda関数のファイルディスクリプタ制限が4,096に増加 Amazon SageMaker Studio launches support for Kiro and Cursor IDEs SageMaker StudioでKiro・Cursor IDEのリモートIDE支援を開始 AWS Advanced JDBC Wrapper supports automatic query caching with Valkey AWS Advanced JDBC WrapperでValkeyを使った自動クエリキャッシング機能を追加 Amazon EC2 R8gd instances available in additional AWS Regions Graviton4搭載のEC2 R8gdインスタンスが追加リージョンで利用可能に AWS AppConfig adds enhanced targeting during feature flag rollout AppConfigでフィーチャーフラグ展開時の拡張ターゲティング機能を追加 Aurora DSQL launches connector for Ruby applications Aurora DSQLでRubyアプリケーション構築を簡素化するコネクタを提供開始 Agent Plugin for AWS Serverless accelerates AI-assisted development AWSサーバーレス向けエージェントプラグインでAI支援開発を加速 Kiro IDEとは？ AWSが開発したAIネイティブなIDE（統合開発環境）で、VS CodeやCursorと同じカテゴリの開発ツールです。AWSサービスとの統合が深く、SageMaker Studioとの連携によりML開発のワークフローを効率化できます。\nまとめ 今回のアップデートでは、パフォーマンス最適化とデベロッパー体験向上の両軸で重要な機能強化が行われました。特にGraviton4プロセッサの展開拡大とデータベースアクセス最適化機能は、運用コストの削減と性能向上の両面で大きなインパクトをもたらします。また、AI支援開発ツールの充実やIDE統合機能の拡張により、開発生産性の向上も期待できます。SREとしては、これらの新機能を段階的に検証し、既存システムへの適用可能性を慎重に評価していくことが重要です。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260327/","summary":"2026/03/27 のAWSアップデートまとめ","title":"【AWS】2026/03/27 のアップデートまとめ"},{"content":"\nはじめに 今回は2026年2月〜3月にかけてのNew Relicアップデートをまとめてお届けします。Infrastructure Agentの3リリース（v1.72.7〜v1.72.9）に加え、2月のプラットフォームアップデート11件を取り上げます。\n特に注目すべきは、CVE-2026-22184のセキュリティ修正を含むInfrastructure Agent v1.72.8と、AIによる障害調査自動化を実現するSRE Agentの登場です。また、No Code Parsingによるログ解析の大幅な効率化や、Pipeline Control Gatewayによるテレメトリデータの事前処理機能など、SREの日常業務に直結するアップデートが充実しています。\n注目アップデート深掘り Infrastructure Agent v1.72.8 — CVE-2026-22184 セキュリティ修正 Infrastructure Agent v1.72.8では、CVE-2026-22184への対応が行われました。このセキュリティ修正は、エージェントの安全な運用を維持するために早急なアップグレードが推奨されます。\nアップグレード手順\nLinux環境の場合：\n# 現在のバージョン確認 $ newrelic-infra --version # パッケージマネージャーでアップグレード（Amazon Linux / RHEL） $ sudo yum update newrelic-infra -y # Ubuntu / Debian $ sudo apt-get update \u0026amp;\u0026amp; sudo apt-get install newrelic-infra -y # アップグレード後の確認 $ newrelic-infra --version # 1.72.8 以上であることを確認 # サービス再起動 $ sudo systemctl restart newrelic-infra v1.72.9（3月23日リリース）ではさらに、nr-control メタデータサービスとの統合が追加され、Go 1.25.8・gRPC 1.79.3へのアップデートも含まれています。セキュリティ修正と合わせて、v1.72.9への一括アップグレードを推奨します。\nv1.72.7ではEOL（End of Life）OSのサポートが削除されています。古いOSで運用している環境では、アップグレード前にサポート対象OSの確認が必要です。\nSRE Agent — AIによる障害調査の自律自動化 SRE Agentとは？ New Relicが提供するAIエージェント機能で、テレメトリデータに自然言語でアクセスし、障害の根本原因分析（RCA）と復旧推奨を自動的に行います。従来は人間が手動で行っていたダッシュボード確認→ログ調査→原因特定のプロセスを、AIが数分で自律的に実行します。\nSRE Agentは2月のプラットフォームアップデートで最も注目すべき機能です。障害発生時に自然言語で状況を伝えるだけで、AIがテレメトリデータを横断的に分析し、根本原因の特定と復旧手順の提案を行います。\n従来の障害対応フローとの比較\n従来：アラート受信 → ダッシュボード確認 → ログ検索 → メトリクス相関分析 → 原因特定（30分〜数時間）\nSRE Agent：アラート受信 → AIに状況を伝える → 自動分析 → 原因と復旧手順の提示（数分）\nさらに、インシデントレポートの自動生成機能も備えており、ポストモーテム作成の工数も削減できます。AWS環境でECS/EKSを運用しているSREにとっては、コンテナのリスタートループやメモリリーク調査など、複雑な障害対応シナリオで特に威力を発揮するでしょう。\nNo Code Parsing — 正規表現不要のログ解析ルール作成 No Code Parsingは、ログの構造化を劇的に簡素化する機能です。従来は正規表現（Grok パターン）の知識が必要だったログ解析ルールの作成が、UIで抽出したいテキストを選択するだけで完了します。\nSRE業務への影響\nアプリケーションチームから「このログからエラー率を可視化したい」と依頼された際、従来は正規表現の試行錯誤に時間を取られていました。No Code Parsingなら、サンプルログを表示してフィールドを選択するだけで解析ルールが作成できます。\n特にカスタムアプリケーションのログや、標準フォーマットに準拠していないログの構造化において、大幅な工数削減が期待できます。\nSRE視点での活用ポイント Infrastructure Agentのアップグレード戦略\nv1.72.7でEOL OSサポートが削除されているため、アップグレードパスの確認が重要です。まずステージング環境でv1.72.9を検証し、問題なければ本番環境にローリングアップデートすることを推奨します。Terraformで管理している場合は、Launch Templateのユーザーデータでエージェントバージョンを固定できます。\nPipeline Control Gatewayの導入検討\nPipeline Control Gatewayとは？ テレメトリデータ（ログ、メトリクス、トレース）をNew Relicに送信する前に、サンプリング・フィルタリング・データ変換を行うゲートウェイ機能です。不要なデータを事前に除外することで、データインジェストコストを最適化できます。\n大量のログやメトリクスを送信している環境では、Pipeline Control Gatewayによるコスト最適化が有効です。従来はYAMLでの設定が必要でしたが、UIからの直感的なルール管理が可能になりました。\nダッシュボード変数の活用\nダッシュボードの変数機能が親子関係をサポートし、チャート名への変数埋め込みも可能になりました。たとえば「リージョン → クラスター → サービス」のドリルダウンビューを1つのダッシュボードで実現できます。\nFROM SystemSample SELECT average(cpuPercent) WHERE clusterName = {{cluster}} FACET hostname TIMESERIES 全アップデート一覧 カテゴリ バージョン/機能 概要 Infrastructure Agent v1.72.9 nr-control メタデータサービス統合、Go 1.25.8 / gRPC 1.79.3 更新 Infrastructure Agent v1.72.8 CVE-2026-22184 セキュリティ修正 Infrastructure Agent v1.72.7 EOL OSサポート削除、nri-flex 1.17.5 / nri-winservices 1.4.4 更新 Platform SRE Agent AI による障害調査の自律自動化・インシデントレポート自動生成 Platform No Code Parsing 正規表現不要のログ解析ルール作成 Platform Notebooks データ分析と手順書を統合する次世代ドキュメント Platform Homepage 運用情報を集約した専用ビュー Platform Workflow Automation Azure 連携によるノーコード自動化 Platform User Management メール認証ベースの MFA 対応 Platform Pipeline Control Gateway テレメトリデータの事前処理（サンプリング・フィルタリング） Platform APM Rate Sampling 分散トレーシングのレートサンプリング（Python Agent 対応追加） Platform Infra NRDOT OpenTelemetry 移行支援・コスト最適化 UI Platform Dashboards 変数の親子関係・チャート名への変数埋め込み Platform Infrastructure Elasticsearch OTel Collector ベースの Elasticsearch 統合監視 まとめ 今回のアップデートは「自動化」と「ノーコード化」がキーワードです。SRE Agentによる障害調査の自動化、No Code Parsingによるログ構造化の簡素化、Pipeline Control Gatewayによるデータ管理の効率化と、SREの手作業を減らす方向のアップデートが目立ちます。\nInfrastructure Agentについては、CVE-2026-22184の修正が含まれるため、v1.72.9への早期アップグレードを推奨します。EOL OSサポートの削除（v1.72.7）もあるため、アップグレード前に対象環境の確認を忘れずに。\nNew Relicのプラットフォーム全体として、OpenTelemetryとの統合がさらに進んでおり、ベンダーロックインを避けつつNew Relicの強力な可視化・分析機能を活用できる方向に進化しています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/newrelic-updates-20260326/","summary":"Infrastructure Agent 3リリース（CVE修正・nr-control統合・EOL OS削除）と、2月のプラットフォームアップデート11件（SRE Agent・No Code Parsing・Pipeline Control等）をまとめて解説。","title":"【New Relic】2026年2-3月のアップデートまとめ"},{"content":"\n2026年3月26日 AWS アップデート情報まとめ はじめに 本日は11件のAWSアップデートが発表されました。特に注目すべきは、Amazon SageMaker Unified StudioがCursor IDEからのリモート接続をサポート開始したことと、Amazon Bedrock AgentCoreがChromeエンタープライズポリシーとカスタムルート証明書に対応したことです。これらのアップデートは、MLエンジニアの開発体験向上とエンタープライズ環境でのAIエージェント運用の安全性強化を実現します。また、EC2 I7ieインスタンスの新リージョン展開やAWS BackupのDocumentDBサポート拡大など、インフラストラクチャとデータ保護分野でも重要な進展がありました。\n注目アップデート深掘り Amazon SageMaker Unified StudioのCursor IDE連携で変わるML開発体験 Amazon SageMaker Unified StudioがCursor IDEからのリモート接続をサポートしたことで、機械学習開発のワークフローが大きく変わります。Cursor IDEのAIアシスト機能を活用しながら、クラウドの強力なコンピューティングリソースにシームレスにアクセスできるこの機能は、特にローカル環境のリソース制約に悩むデータサイエンティストにとって画期的です。\nAWS Toolkitの設定手順\nまず、Cursor IDEにAWS Toolkitをインストールし、SageMaker Unified Studioへの接続を設定します：\n# AWS CLIでの認証情報設定 $ aws configure AWS Access Key ID [None]: YOUR_ACCESS_KEY AWS Secret Access Key [None]: YOUR_SECRET_KEY Default region name [None]: us-east-1 Default output format [None]: json # SageMaker Unified Studioへの接続テスト $ aws sagemaker list-domains Cursor IDEからの接続では、IAM認証を通じてセキュアにリモートリソースにアクセスできます。従来のローカル開発では、大容量データセットの処理やGPUを要する訓練時にリソース不足が発生しがちでしたが、この機能により、ローカルのコード補完機能を享受しながらクラウドの拡張性を活用できます。\n開発ワークフローの変化\nリモート接続により、以下のような開発体験の向上が期待されます：\n# Cursor IDEのAIアシストを使いながら、SageMakerのリソースで実行 import sagemaker from sagemaker.sklearn import SKLearn # ローカルで快適にコーディング、実行はクラウドで estimator = SKLearn( entry_point=\u0026#39;train.py\u0026#39;, instance_type=\u0026#39;ml.m5.large\u0026#39;, framework_version=\u0026#39;0.23-1\u0026#39; ) estimator.fit({\u0026#39;train\u0026#39;: \u0026#39;s3://your-bucket/train-data\u0026#39;}) この統合により、コード補完の恩恵を受けながら、メモリ集約的なデータ前処理や長時間の訓練をクラウド上で効率的に実行できるようになります。\nAmazon Bedrock AgentCoreがエンタープライズ環境で本格運用可能に Amazon Bedrock AgentCoreとは？ Bedrock上でAIエージェントを構築・実行するためのマネージドランタイム環境です。LLMにツール呼び出しやブラウザ操作などの「行動」能力を持たせ、複雑なタスクを自律的に実行するエージェントをデプロイできます。従来のBedrock APIが「問いに答える」だけだったのに対し、AgentCoreは「実際に操作する」AIを実現するサービスです。\nAmazon Bedrock AgentCoreのChromeエンタープライズポリシーとカスタムルート証明書サポートは、セキュリティ要件の厳しい企業環境でのAIエージェント導入を現実的なものにします。従来、AIエージェントの企業導入では、ネットワークセキュリティやアクセス制御の制約が大きな障壁となっていましたが、この機能により企業のセキュリティポリシーに準拠した運用が可能になります。\nエンタープライズポリシーの実装\nChrome エンタープライズポリシーの設定により、AIエージェントの動作を組織のセキュリティ方針に合わせて制御できます：\n{ \u0026#34;BlockedDomains\u0026#34;: [\u0026#34;*.social-media.com\u0026#34;, \u0026#34;*.file-sharing.com\u0026#34;], \u0026#34;AllowedDomains\u0026#34;: [\u0026#34;*.company.com\u0026#34;, \u0026#34;*.trusted-partner.com\u0026#34;], \u0026#34;SecurityLevel\u0026#34;: \u0026#34;high\u0026#34;, \u0026#34;DownloadRestrictions\u0026#34;: { \u0026#34;BlockDangerousDownloads\u0026#34;: true, \u0026#34;PromptForDownload\u0026#34;: true } } カスタムルート証明書の設定\n社内のプライベート証明書局（CA）を使用している環境では、以下のような設定でAgentCoreが社内システムに安全にアクセスできます：\n# カスタムCA証明書のアップロード $ aws bedrock put-agent-runtime-config \\ --agent-id \u0026#34;your-agent-id\u0026#34; \\ --custom-ca-certificates file://company-root-ca.pem \\ --chrome-policies file://enterprise-policies.json この機能により、金融機関や医療機関など、高度なセキュリティ要件を持つ業界でも、AIエージェントを活用した業務自動化が実現できます。従来のWebスクレイピングやブラウザ自動化ツールでは困難だった、企業のセキュリティポリシーに完全準拠したAIエージェント運用が可能になります。\nSRE視点での活用ポイント 今回のアップデートをSREの観点から見ると、特に運用の自動化と信頼性向上に寄与する要素が多く含まれています。\nBedrock AgentCoreのエンタープライズ対応は、AIを活用した障害対応の自動化において重要な意味を持ちます。例えば、社内の監視ダッシュボードや運用ツールにアクセスするAIエージェントを構築する際、カスタム証明書とポリシー制御により、セキュリティ要件を満たしながら自動化を実現できます。Terraformでインフラを管理している環境では、以下のような設定でAgentCoreを組み込めます：\nresource \u0026#34;aws_bedrock_agent\u0026#34; \u0026#34;ops_assistant\u0026#34; { agent_name = \u0026#34;ops-assistant\u0026#34; runtime_config { custom_ca_certificates = var.company_ca_certificates chrome_policies = jsonencode(var.enterprise_policies) } } AWS BatchのAMI状態管理とHealth Events連携は、バッチワークロードの安定運用に直接的な改善をもたらします。CloudWatch アラームと組み合わせることで、古いAMIを使用しているコンピューティング環境を事前に検知し、計画的なメンテナンス窓での更新を自動化できます。Amazon EventBridge経由でSlackやPagerDutyに通知を送ることで、インシデント化する前の予防的対応が可能になります。\nEC2 I7ieインスタンスの新リージョン展開は、レイテンシセンシティブなワークロードの地理的分散に活用できます。特に大容量のローカルストレージを活用するログ解析基盤やリアルタイム分析システムにおいて、ユーザーに近いリージョンでの高性能処理が可能になります。ただし、新しいインスタンスタイプの導入時は、既存のモニタリング設定や自動スケーリングポリシーの見直しが必要になる点に注意が必要です。\n導入判断においては、セキュリティ要件とのバランス、既存システムへの影響範囲、そして段階的な移行計画の策定が重要になります。\n全アップデート一覧 Amazon SageMaker HyperPodとは？ 大規模MLモデルの分散トレーニングに特化したマネージドクラスター環境です。SlurmやEKSをオーケストレーターとして使い、数百〜数千GPUの学習ジョブを自動復旧・ヘルスチェック付きで実行できます。自前でGPUクラスターを構築・運用する手間を大幅に削減するサービスです。\nAmazon Timestream for InfluxDBとは？ オープンソースの時系列DB「InfluxDB」をAWSがフルマネージドで提供するサービスです。IoTセンサーデータやアプリケーションメトリクスの収集・分析に適しており、既存のInfluxDB互換クライアントやクエリ（Flux、InfluxQL）がそのまま使えます。\nサービス アップデート内容 概要 Amazon SageMaker Unified Studio Cursor IDEからのリモート接続サポート AWS ツールキット拡張機能を通じて、ローカルIDEからクラウドリソースに直接アクセス可能 Amazon SageMaker AI 12モデルのサーバーレス強化学習ファインチューニング対応 インフラ管理不要で、SFT、DPO、RFTによる高度なモデル調整が可能 Amazon Route 53 Profiles 詳細なIAM権限のサポート リソースとVPCアソシエーションに対する細かなアクセス制御が可能 Amazon Bedrock AgentCore Chromeポリシーとカスタムルート証明書サポート エンタープライズ環境でのセキュアなAIエージェント運用を実現 AWS Batch AMI状態とAWS Health連携 AMIのライフサイクル管理と計画的なメンテナンス対応を強化 AWS Batch SageMakerジョブのクォータ管理とプリエンプション 柔軟なリソース管理と優先度制御による効率化を実現 Amazon Bedrock AgentCore Runtime 永続化セッションストレージ (プレビュー) ファイルシステム状態の永続化による継続的な開発作業をサポート AWS Backup DocumentDBサポートを12リージョンに拡大 グローバル展開でのポリシーベースデータ保護を強化 Amazon SageMaker HyperPod Slurmクラスターの継続プロビジョニング 大規模MLトレーニングでのリソース可用性を改善 Amazon EC2 I7ie 7リージョンで新規利用開始 ストレージ最適化インスタンス（Intel Xeon第5世代、最大120TB NVMe）の地理的展開 Amazon Timestream for InfluxDB 3リージョンで新規サポート 時系列データベースサービスの地理的可用性を拡大 まとめ 本日のアップデートは、AI/ML開発の生産性向上とエンタープライズ環境での実用性強化に重点が置かれています。SageMaker Unified StudioのCursor IDE連携は開発者体験を大幅に改善し、Bedrock AgentCoreのエンタープライズ機能は企業でのAI活用の障壁を取り除きます。\nまた、AWS BatchのAMI管理強化やEC2インスタンスの地理的展開など、インフラ運用の信頼性と効率性を高めるアップデートも充実しています。これらの機能を適切に組み合わせることで、よりロバストで自動化された運用環境の構築が可能になるでしょう。\n特に注目すべきは、AIと従来のクラウドサービスの境界がますます曖昧になり、統合された開発・運用体験が提供され始めていることです。今後もこの傾向は続くと予想され、SREやDevOpsエンジニアにとってAI活用スキルの重要性がさらに高まっていくと考えられます。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260326/","summary":"2026/03/26 のAWSアップデートまとめ","title":"【AWS】2026/03/26 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.83が2026年3月26日にリリースされました。今回のアップデートは、特にSRE業務における環境管理とセキュリティ強化に重点を置いた内容となっています。\n主な変更点として、managed-settings.d/による柔軟なポリシー設定、環境変動に応じた動的制御を実現するCwdChanged/FileChangedフック、セキュリティを強化するサブプロセス認証情報の自動削除機能などが含まれています。また、開発生産性を向上させるトランスクリプト検索機能や、安定性向上のための各種バグ修正も実装されています。\n注目アップデート深掘り managed-settings.d/による柔軟なポリシー設定 managed-settingsとは？ Claude Codeの組織管理者が全社的なポリシーを強制適用するための設定ファイルです。従来は managed-settings.json の1ファイルでしたが、複数チームが独立してポリシーを管理する場合に競合が起きやすい問題がありました。\n今回のリリースで最も注目すべき機能の一つが、managed-settings.d/ディレクトリを利用した設定管理システムです。この機能により、組織レベルでのポリシー管理と個別プロジェクトでのカスタマイズを両立できるようになりました。\n従来は単一の設定ファイルで全てを管理していましたが、複数チームでの運用や環境ごとの細かな制御が困難でした。新しいシステムでは、設定を階層化して管理できるため、本番環境では厳格なセキュリティポリシーを適用し、開発環境では柔軟な設定を許可するといった使い分けが可能です。\n# 組織共通の設定 $ mkdir -p managed-settings.d/org $ cat \u0026gt; managed-settings.d/org/security.json \u0026lt;\u0026lt; EOF { \u0026#34;security\u0026#34;: { \u0026#34;subprocess_credential_removal\u0026#34;: true, \u0026#34;sandbox_isolation_level\u0026#34;: \u0026#34;strict\u0026#34; } } EOF # プロジェクト固有の設定 $ cat \u0026gt; managed-settings.d/project/development.json \u0026lt;\u0026lt; EOF { \u0026#34;channels\u0026#34;: { \u0026#34;debug_mode\u0026#34;: true, \u0026#34;verbose_logging\u0026#34;: true } } EOF 実際のSRE業務では、この機能を活用してコンプライアンス要件を満たしながら、開発チームの生産性を維持できます。設定の優先度は自動的に解決され、より具体的な設定が上位のポリシーを上書きする仕組みになっています。\n動的環境制御を実現するCwdChanged/FileChangedフック もう一つの重要な機能が、CwdChanged と FileChanged の2つの新しいフックイベントです。作業ディレクトリの変更やファイルの変更に応じて、シェルコマンドを自動実行できるようになりました。\nフック（Hooks）とは？ Claude Codeの特定イベント（ツール実行前後、通知時など）にシェルコマンドを自動実行する仕組みです。settings.json で設定し、条件に応じた自動化を実現します。\n典型的なユースケースは、direnv のような環境変数の自動切り替えです：\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;CwdChanged\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;direnv export json 2\u0026gt;/dev/null || echo \u0026#39;{}\u0026#39;\u0026#34; } ], \u0026#34;FileChanged\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;\\\\.env$\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;echo \u0026#39;⚠️ .env file changed — reloading environment\u0026#39;\u0026#34; } ] } } これにより、開発者がプロジェクトディレクトリを移動するだけで、そのプロジェクトに最適化された環境変数が自動で読み込まれ、人的ミスによる本番環境での誤操作を防ぐことができます。\n実用的な活用ポイント 今回のアップデートは、日常の開発ワークフローに大きな改善をもたらします。特にトランスクリプト検索機能は、過去の作業履歴から類似のタスクや解決方法を素早く見つけられるため、繰り返し作業の効率化に直結します。\nSRE業務では、サンドボックス起動失敗時のエラーハンドリング改善により、障害対応時のトラブルシューティングが迅速化されます。エラーメッセージがより詳細になり、根本原因の特定時間を大幅に短縮できるでしょう。\nセキュリティ面では、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 環境変数を設定することで、Bashツール・フック・MCP stdioサーバーなどのサブプロセスからAnthropicやクラウドプロバイダーの認証情報を自動的に除去できます。opt-inですが、複数の外部サービスとやり取りする環境では有効にしておくことを推奨します。\nすぐに試せるTipsとして、外部エディタ起動の新しいショートカット（Ctrl+X Ctrl+E）を活用することで、Claude Code内での編集と外部エディタでの高度な編集をシームレスに切り替えられます。大容量ファイルの差分処理も改善されているため、ログファイル分析などの重い処理でもタイムアウトを気にせず作業できるようになりました。\n全変更点一覧 カテゴリ 内容 概要 Feature managed-settings.d/による設定管理 階層化されたポリシー設定システム Feature CwdChanged/FileChangedフック ディレクトリ・ファイル変更時の動的制御 Feature トランスクリプト検索機能 過去の作業履歴を検索可能 Feature エージェント初期プロンプト自動設定 プロジェクト文脈に応じた自動設定 Feature 外部エディタ起動ショートカット Ctrl+X Ctrl+E（readline互換）を追加 Improvement サブプロセス認証情報削除（opt-in） CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 でサブプロセスからクラウド認証情報を除去 Improvement サンドボックス起動エラーハンドリング より詳細なエラー情報とリカバリ機能 Fix 画面フリーズ問題の修正 UI応答性の改善 Fix 起動時ハングの解決 アプリケーション起動の安定性向上 Fix 大容量ファイル差分タイムアウト実装 パフォーマンス最適化 まとめ v2.1.83は、Claude Codeの成熟度を示す重要なリリースと言えるでしょう。managed-settings.d/システムや動的フックによる柔軟な環境制御は、エンタープライズ利用における運用性を大幅に向上させています。\n特にSRE業務においては、セキュリティを維持しながら開発効率を向上させるバランスの取れた改善が目立ちます。これらの機能は、DevOpsプラクティスをより洗練された形で実現することを可能にし、組織全体の技術的成熟度向上に寄与するでしょう。\n安定性の改善も見逃せないポイントです。日常的に発生していた小さな不具合の修正により、開発者体験が大幅に向上し、Claude Codeを中核とした開発ワークフローがより信頼性の高いものになりました。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260326/","summary":"v2.1.83 のClaude Codeリリースノートまとめ","title":"【Claude Code】v2.1.83 リリースノートまとめ"},{"content":"\nはじめに 2026年3月24日のAWSアップデートは2件。Amazon PollyのGenerative TTSエンジンにBidirectional Streaming APIが追加され、AWS HealthImagingがロンドンリージョンで利用可能になりました。\n注目アップデート深掘り Amazon Polly Generative TTS の大幅機能拡張 Amazon Pollyに10の新しい高表現力音声が追加され、2つの新リージョン（ロンドン、カナダ中部）がサポートされました。さらに、LLMの出力をリアルタイムで音声合成するBidirectional Streaming APIが導入されています。\n新音声のテスト\n新音声は7つのロケール（英語4地域、フランス語、イタリア語、ドイツ語）をカバーしています。AWS CLIで試す場合：\n# Generativeエンジンで新音声をテスト $ aws polly synthesize-speech \\ --output-format mp3 \\ --voice-id Matthew \\ --text \u0026#34;Hello, I\u0026#39;m excited to demonstrate the new expressive capabilities of Amazon Polly\u0026#39;s generative TTS engine.\u0026#34; \\ --engine generative \\ output.mp3 Bidirectional Streaming APIの技術的革新\n従来の方式では、LLMが完全にレスポンスを生成してから音声合成を開始していました。新しいBidirectional Streaming APIでは、部分的なテキストを受け取り次第、即座に音声生成を開始できます。\n以下は概念的な実装イメージです（APIの正確なインターフェースはAWS公式ドキュメントを参照してください）：\nimport boto3 def synthesize_with_generative_engine(text: str, voice_id: str = \u0026#34;Matthew\u0026#34;) -\u0026gt; bytes: \u0026#34;\u0026#34;\u0026#34;Generativeエンジンでの音声合成\u0026#34;\u0026#34;\u0026#34; polly_client = boto3.client(\u0026#34;polly\u0026#34;) response = polly_client.synthesize_speech( Engine=\u0026#34;generative\u0026#34;, OutputFormat=\u0026#34;mp3\u0026#34;, Text=text, VoiceId=voice_id, ) return response[\u0026#34;AudioStream\u0026#34;].read() Bidirectional Streaming APIを使うと、LLMが最初のトークンを生成した時点から音声合成が並行して走るため、ユーザーが音声を聞き始めるまでの待ち時間を大幅に短縮できます。\nTerraformでの権限設定例\nresource \u0026#34;aws_iam_role_policy\u0026#34; \u0026#34;polly_generative_policy\u0026#34; { name = \u0026#34;polly-generative-policy\u0026#34; role = aws_iam_role.app_role.id policy = jsonencode({ Version = \u0026#34;2012-10-17\u0026#34; Statement = [ { Effect = \u0026#34;Allow\u0026#34; Action = [ \u0026#34;polly:SynthesizeSpeech\u0026#34;, \u0026#34;polly:StartSpeechSynthesisTask\u0026#34;, \u0026#34;polly:DescribeVoices\u0026#34; ] Resource = \u0026#34;*\u0026#34; } ] }) } AWS HealthImaging がロンドンリージョンで利用可能に AWS HealthImagingとは？ 医療画像（DICOM形式のCTスキャン、MRIなど）をクラウド上で保存・検索・分析するためのマネージドサービスです。従来のオンプレミスPACS（医療画像管理システム）の代替として、ストレージコスト削減とAI/ML連携を実現します。\n医療画像データの管理・処理サービスであるAWS HealthImagingが、ヨーロッパ（ロンドン）リージョンで利用可能になりました。これにより、欧州の医療機関がデータ主権要件を満たしつつクラウドを活用できるようになります。\nデータ主権とコンプライアンス\n欧州の医療データはGDPRに加え、各国の医療データ規制の対象です。ロンドンリージョンの追加により、英国の医療機関がデータをUK域内に保持したままHealthImagingを利用できるようになりました。\nTerraformでの構成例\nresource \u0026#34;aws_medical_imaging_datastore\u0026#34; \u0026#34;medical_images\u0026#34; { datastore_name = \u0026#34;hospital-imaging-store\u0026#34; tags = { Environment = \u0026#34;production\u0026#34; Region = \u0026#34;eu-west-2\u0026#34; Compliance = \u0026#34;GDPR\u0026#34; } } 既存のus-east-1やap-southeast-2のデータストアとは別に、欧州向けのデータストアをロンドンリージョンに構築することで、地理的な冗長性とコンプライアンスを両立できます。\nSRE視点での活用ポイント Polly Bidirectional Streamingの運用考慮事項\n音声AIアプリケーションでBidirectional Streaming APIを導入する場合、従来のバッチ処理とは異なる監視が必要です。ストリーム中断時の復旧手順や、部分的な音声出力の品質検証を含めたランブックの更新を検討してください。CloudWatchメトリクスで音声合成のレイテンシを監視し、ユーザー体験の品質を定量的に管理できます。\n新しいリージョン（ロンドン、カナダ中部）の追加により、地理的な冗長性を考慮した音声サービスの設計も可能になりました。Generative TTSは従来のNeural TTSよりも高品質ですが処理コストも高くなるため、ユースケースに応じたエンジン選択がコスト最適化の鍵です。\nHealthImagingのリージョン展開\n医療画像系のワークロードを運用している場合、ロンドンリージョンの追加はDR設計の選択肢を広げます。既存リージョンとの間でデータレプリケーションを構成する際は、転送コストとレイテンシのバランスを考慮してください。\n全アップデート一覧 サービス アップデート内容 概要 Amazon Polly Generative TTSエンジンの大幅機能拡張 10の新しい高表現力音声の追加（7ロケール対応）、2つの新リージョンサポート、LLMとリアルタイム統合可能なBidirectional Streaming API導入 AWS HealthImaging ヨーロッパ（ロンドン）リージョン対応 医療画像データの管理・処理サービスがロンドンリージョンで利用可能になり、欧州の医療機関でのデータ主権要件に対応 まとめ PollyのBidirectional Streaming APIは、対話型AIアプリケーションの音声レイテンシ改善に直結するアップデートです。LLMと音声合成を組み合わせている環境では検討の価値があります。HealthImagingのロンドンリージョン対応は、欧州で医療画像ワークロードを扱っている場合にデータ主権とDR設計の両面でプラスになります。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260324/","summary":"Amazon PollyのGenerative TTSエンジン大幅拡張（新音声10個・Bidirectional Streaming API）と、AWS HealthImagingのロンドンリージョン対応の2件。","title":"【AWS】2026/03/24 のアップデートまとめ"},{"content":"\nはじめに Claude Code v2.1.81がリリースされました。今回のアップデートは、セキュリティと安定性の向上に重点を置いたマイナーアップデートです。\n主な変更点として、OAuth認証フローの改善、ボイスモード関連の修正、WebSocketや非同期処理における接続安定性の向上、そしてパーミッション管理の強化が挙げられます。特にSREやインフラエンジニアにとっては、認証処理の信頼性向上と運用スクリプトの安定性改善が大きなメリットとなるでしょう。\n注目アップデート深掘り OAuth認証フローの改善 今回のアップデートでは、OAuth認証における複数セッション間の処理が大幅に改善されました。従来版では、複数のCLIセッションを同時に実行する際に認証トークンの競合が発生し、予期しない認証エラーが起こることがありました。\nこの改善により、以下のような運用シナリオでの信頼性が向上します：\n# 複数の環境で同時にClaude Codeを実行 # セッション1: 本番環境の監視 $ claude-code connect --env production --session monitoring # セッション2: ステージング環境でのデバッグ $ claude-code connect --env staging --session debug # セッション3: 開発環境でのテスト実行 $ claude-code connect --env development --session testing 従来は各セッション間で認証状態が干渉し合うことがありましたが、v2.1.81では各セッションが独立した認証コンテキストを保持するようになりました。これにより、SREチームが複数の環境を並行監視する際の運用効率が大幅に向上します。\nパーミッション管理の強化 Bashコマンド実行時のパーミッション処理が改善され、より細かい権限制御が可能になりました。特に、危険なコマンドに対する事前チェック機能が強化されています。\n# 危険なコマンドの実行前に警告とユーザー確認を表示 $ claude-code exec --command \u0026#34;rm -rf /important/data\u0026#34; --safety-check # 特定のディレクトリに対する操作権限を制限 $ claude-code config set permissions.restricted-paths \u0026#34;/etc,/var/lib/system\u0026#34; # 実行可能コマンドのホワイトリスト設定 $ claude-code config set permissions.allowed-commands \u0026#34;ls,cat,grep,tail,ps\u0026#34; この変更により、自動化スクリプト内でClaude Codeを使用する際のセキュリティリスクを大幅に軽減できます。特に、本番環境での運用スクリプトにおいて、予期しないコマンド実行を防ぐ重要な安全装置として機能します。\n実用的な活用ポイント 今回のアップデートは、日常の開発・運用ワークフローに以下の改善をもたらします：\n認証の安定性向上により、CI/CDパイプライン内でClaude Codeを使用する際の信頼性が向上しました。Jenkins、GitHub Actions、GitLab CIなどの環境で、認証エラーによるビルド失敗のリスクが大幅に削減されます。\nWebSocket接続の安定性改善は、リアルタイム監視ダッシュボードやログストリーミング機能の使用時に特に効果を発揮します。長時間の監視セッションでも接続が途切れにくくなり、24時間体制での運用監視がより確実に行えるようになりました。\nすぐに試せるTipsとして、新しいセッション管理機能を活用した環境分離があります：\n# 環境ごとに名前付きセッションを作成 $ claude-code session create production-monitoring $ claude-code session create staging-debug $ claude-code session create development-test # セッション一覧の確認 $ claude-code session list # 特定セッションへの切り替え $ claude-code session switch production-monitoring SRE視点では、アラート対応時の多環境並行調査や、複数チームメンバーでの同時作業において、セッション分離による作業効率の向上が期待できます。\n全変更点一覧 カテゴリ 内容 概要 Security OAuth認証フロー改善 複数セッション間の認証処理安定性向上 Fix ボイスモード接続修正 音声認識機能の接続エラー解消 Fix WebSocket接続安定性 長時間接続時の切断問題を修正 Fix 非同期タスク実行 バックグラウンドタスクの実行エラー解消 Improvement パーミッション管理強化 Bashコマンド実行権限の細かい制御機能追加 Feature セッション管理機能 名前付きセッションによる環境分離サポート Improvement 実験的機能制御 ベータ機能のオン/オフ切り替えオプション追加 Fix リモートコントロール リモートセッション管理の安定性向上 まとめ Claude Code v2.1.81は、派手な新機能追加よりも、既存機能の信頼性と安定性の向上に重点を置いた実用的なアップデートとなっています。\n特に注目すべきは、エンタープライズ環境での使用を意識したセキュリティ強化です。OAuth認証の改善とパーミッション管理の強化により、本番環境での利用における安全性が大幅に向上しました。また、WebSocketや非同期処理の安定性向上は、長時間の監視業務や自動化スクリプトの信頼性向上に直結します。\nSREやインフラエンジニアにとって、このような「地味だが重要な」改善は、日々の運用品質を底上げする価値の高いアップデートと言えるでしょう。次回のメジャーアップデートに向けた基盤固めとしても、今回の安定性向上は重要な意味を持っています。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/claude-code-updates-20260322/","summary":"セキュリティと安定性の向上に重点を置いたマイナーアップデート。OAuth認証フローの改善、パーミッション管理の強化が主な変更点。","title":"【Claude Code】v2.1.81 リリースノートまとめ"},{"content":"\nはじめに 2026年3月21日のAWSアップデートは6件。Bedrock AgentCore RuntimeへのWebRTC追加、EKS Provisioned Control Planeの99.99% SLA・8XLティア新設が目立ちます。ほかにNeuronのDRAサポート、DataSyncのSecrets Manager対応、RedshiftのIAM Identity Center連携強化など。\n注目アップデート深掘り Amazon Bedrock AgentCore RuntimeにWebRTCサポートを追加 AgentCore Runtimeに、既存のWebSocketに加えてWebRTCプロトコルが追加されました。ブラウザやモバイルアプリでの音声AIエージェント構築で、UDPベースの低レイテンシー双方向ストリーミングが使えるようになります。\nWebSocketとの違い\nWebSocketはTCPベースの永続接続で、テキストや音声のストリーミングには向いています。一方、リアルタイムの音声・映像通信ではUDPベースのWebRTCのほうがレイテンシーが低い。これまで音声AIエージェントを作るには独自のメディアサーバーを構成する必要がありましたが、AgentCore Runtimeが直接WebRTCをサポートしたことでその手間がなくなります。\nTURNリレーの構成オプション\nNAT越え（NAT Traversal）とは？ WebRTCは端末同士が直接通信するP2P方式ですが、ほとんどの端末はルーター（NAT）の背後にいるため、外部から直接繋がりません。この壁を越えるのがNAT越えです。\nまずSTUNサーバーが端末のグローバルIPを特定してP2P接続を試みます。それでもダメな場合（対称NATやファイアウォール環境）、TURNサーバーが中継役としてデータを仲介します。TURNを経由するとP2Pではなくなるのでレイテンシーは若干増えますが、ほぼどんなネットワーク環境でも接続できます。\nNAT越えが必要な場合、3つの選択肢があります。\nAmazon Kinesis Video Streams マネージドTURN（推奨）: フルマネージド。AWS IAM統合済みで、TURNサーバーの自前運用が不要 サードパーティTURNプロバイダー: Twilio、Xirsysなど。すでに使っていれば移行コストが低い セルフホストTURN: coturnなどをEC2上で運用。自由度は高いが、可用性やスケーリングは自分で面倒を見る必要がある 対応リージョン\n東京を含む14リージョンで利用可能（米国3、アジア太平洋5、欧州5、カナダ1）。Amazon Nova Sonicを使った音声エージェントのサンプルや、Pipecat・LiveKit・Strands Agents SDKとの連携実装例も公開されています。\nAmazon EKS Provisioned Control Planeの99.99% SLAと8XLティア EKS Provisioned Control PlaneのSLAが99.95%から99.99%に引き上げられました。また、8XLスケーリングティアが追加され、4XLの2倍のKubernetes APIサーバーリクエスト処理能力を持ちます。\nSLA引き上げの実際の意味\n99.95%→99.99%は、年間ダウンタイム許容量で約26分→約5分。数字としてはわずかですが、ミッションクリティカルなワークロードにとっては大きな差です。可用性は1分間隔で測定されます。\n8XLティアのユースケース\n超大規模AI/MLトレーニングクラスター ハイパフォーマンスコンピューティング（HPC） 大規模データ処理パイプライン 数千ノード規模のクラスター運用 EKS Provisioned Control Planeが提供されている全リージョンで利用可能です。\nAWS NeuronがEKSでDynamic Resource Allocation（DRA）をサポート AWS Neuronとは？ AWSの独自AIチップ「Trainium」（学習用）と「Inferentia」（推論用）向けのSDK。コンパイラ、ランタイム、プロファイラを含み、PyTorchやTensorFlowで書かれたモデルをこれらのチップ上で動かすためのソフトウェアスタック。NVIDIAのCUDAに相当するものと考えるとわかりやすいです。\n従来のKubernetesでは、GPU等の特殊ハードウェアの割り当てはDevice Pluginに依存していて、細かな制御が難しい状態でした。DRAを使うと、ハードウェアトポロジーとデバイス属性がKubernetesスケジューラに直接公開され、柔軟なリソース管理ができるようになります。\n何が変わるのか\n大規模MLワークロードでは、複数のTrainiumチップを効率的に割り当てることが性能に直結します。従来はMLエンジニアがインフラの詳細を把握して手動で設定する必要がありましたが、DRAならKubernetesネイティブなリソース要求として記述できます。\n具体的な検証手順\nまず、EKSクラスターでNeuron DRAドライバを有効化します：\n# Neuron DRAドライバのインストール $ kubectl apply -f https://raw.githubusercontent.com/aws-neuron/aws-neuron-eks-samples/main/dra/neuron-dra-driver.yaml # ResourceClassの確認 $ kubectl get resourceclass 次に、ResourceClaimTemplateを定義してMLワークロードに適用します：\n# resource-claim-template.yaml apiVersion: resource.k8s.io/v1alpha2 kind: ResourceClaimTemplate metadata: name: trainiumv1-claim-template spec: spec: resourceClassName: trainiumv1.neuron.aws parametersRef: apiVersion: resource.neuron.aws/v1alpha1 kind: TrainiumParameters name: multi-chip-params # ml-workload.yaml apiVersion: batch/v1 kind: Job metadata: name: distributed-training-job spec: template: spec: resourceClaims: - name: trainiumv1 source: resourceClaimTemplateName: trainiumv1-claim-template containers: - name: training-container image: your-ml-image:latest resources: claims: - name: trainiumv1 従来の方法との比較\nDevice Plugin方式では、静的なリソース定義しか書けません：\n# 従来の方法 resources: limits: aws.amazon.com/neuron: 8 DRA方式なら、トポロジーを考慮した動的な指定が可能です：\n# DRA方式 parametersRef: apiVersion: resource.neuron.aws/v1alpha1 kind: TrainiumParameters name: optimized-topology-params パフォーマンス測定の観点\nMLワークロードでの効果を測るには、以下のメトリクスを監視します：\nimport time def measure_resource_allocation_time(): \u0026#34;\u0026#34;\u0026#34;リソース割り当て時間の測定\u0026#34;\u0026#34;\u0026#34; start_time = time.time() # Kubernetes APIでPodの状態を監視 # リソース割り当て完了までの時間を測定 allocation_time = time.time() - start_time return allocation_time def compare_training_throughput(): \u0026#34;\u0026#34;\u0026#34;学習スループットの比較\u0026#34;\u0026#34;\u0026#34; # DRA使用時とDevice Plugin使用時のスループット比較 pass AWS DataSyncでSecrets Manager対応強化 DataSyncが全ロケーションタイプでSecrets Managerに対応しました。認証情報を平文で渡す必要がなくなり、Secrets Managerで暗号化・管理できます。\nセキュリティ向上の具体例\n従来は認証情報をパラメータストアやハードコーディングで管理していました：\n# 従来の方法（非推奨） $ aws datasync create-location-smb \\ --server-hostname example.com \\ --user myuser \\ --password \u0026#34;hardcoded-password\u0026#34; \\ --subdirectory /data Secrets Managerを使う方法：\n# Secrets Managerにクレデンシャルを保存 $ aws secretsmanager create-secret \\ --name \u0026#34;datasync/smb-credentials\u0026#34; \\ --description \u0026#34;SMB server credentials for DataSync\u0026#34; \\ --secret-string \u0026#39;{\u0026#34;username\u0026#34;:\u0026#34;myuser\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;secure-password\u0026#34;}\u0026#39; # DataSyncロケーション作成時にSecrets Managerを参照 $ aws datasync create-location-smb \\ --server-hostname example.com \\ --secrets-manager-arn \u0026#34;arn:aws:secretsmanager:region:account:secret:datasync/smb-credentials\u0026#34; \\ --subdirectory /data Terraformでの実装例\nname = \u0026#34;datasync/nfs-credentials\u0026#34; description = \u0026#34;NFS credentials for DataSync transfer\u0026#34; } resource \u0026#34;aws_secretsmanager_secret_version\u0026#34; \u0026#34;datasync_credentials\u0026#34; { secret_id = aws_secretsmanager_secret.datasync_credentials.id secret_string = jsonencode({ username = var.nfs_username password = var.nfs_password }) } resource \u0026#34;aws_datasync_location_nfs\u0026#34; \u0026#34;source\u0026#34; { server_hostname = \u0026#34;nfs.example.com\u0026#34; subdirectory = \u0026#34;/exports/data\u0026#34; secrets_manager_arn = aws_secretsmanager_secret.datasync_credentials.arn on_prem_config { agent_arns = [aws_datasync_agent.on_premises.arn] } } コンプライアンス対応\nSOC 2やISO 27001の要件を満たしやすくなります。認証情報の自動ローテーションも設定可能です：\ndef setup_credential_rotation(): \u0026#34;\u0026#34;\u0026#34;認証情報の自動ローテーション設定\u0026#34;\u0026#34;\u0026#34; secrets_client = boto3.client(\u0026#39;secretsmanager\u0026#39;) response = secrets_client.rotate_secret( SecretId=\u0026#39;datasync/smb-credentials\u0026#39;, RotationLambdaArn=\u0026#39;arn:aws:lambda:region:account:function:rotate-datasync-credentials\u0026#39;, RotationRules={ \u0026#39;AutomaticallyAfterDays\u0026#39;: 30 } ) return response SRE視点での活用ポイント Neuron DRAの導入判断\nTerraformでEKSクラスターを管理しているなら、DRAの導入は検討に値します。MLエンジニアから「リソースが足りない」「配置が最適でない」という問い合わせが多い環境では、DRAで解決できるケースがあります。複数チームが同一クラスターを共有しているなら、リソース競合の軽減にも効きます。\nただし、DRAはまだ新しい機能です。本番投入前にステージング環境で検証し、既存ワークロードへの影響がないことを確認してください。\nDataSync × Secrets Managerの運用\nCloudWatchアラームと組み合わせれば、認証エラーによるデータ転送失敗を即座に検知できます。Systems Managerのメンテナンスウィンドウと連携して、ローテーション後にデータ転送タスクを自動再実行する仕組みも作れます。\n障害対応のランブックには、「認証情報の期限切れによる転送失敗」のシナリオを追加しておくといいでしょう。Secrets Managerのバージョン管理機能を使えば、直前のクレデンシャルに戻すことも可能です。\n全アップデート一覧 サービス アップデート内容 概要 Amazon Bedrock AgentCore RuntimeにWebRTCサポート追加 UDPベースの低レイテンシー双方向ストリーミングで音声AIエージェント構築が容易に Amazon EKS Provisioned Control Planeの99.99% SLAと8XLティア 年間ダウンタイム許容約5分、最大規模のスケーリングティア追加 AWS Neuron EKSでDynamic Resource Allocation対応 TrainiumリソースをKubernetesネイティブな方法で動的に割り当て AWS DataSync 全ロケーションタイプでSecrets Manager対応 認証情報をSecrets Managerで安全に管理可能に AWS Firewall Manager アジアパシフィック（ニュージーランド）リージョン対応 セキュリティポリシーの統一管理がニュージーランドリージョンで利用可能に Amazon Redshift IAM Identity Center連携マルチリージョン対応 複数リージョンのRedshiftクラスターに対して統一されたアクセス管理が可能 まとめ Bedrock AgentCore RuntimeのWebRTC対応で音声AIエージェントの構築ハードルが下がり、EKSの99.99% SLAで「落ちたら困る」クラスターの選択肢が広がりました。Neuron DRAは、Trainiumを使ったMLワークロードのリソース管理をKubernetesの世界に持ち込んだ形です。DataSyncのSecrets Manager対応は地味ですが、認証情報を平文で渡していた環境には刺さるアップデートです。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260321/","summary":"Bedrock AgentCore RuntimeへのWebRTC追加、EKS Provisioned Control Planeの99.99% SLA・8XLティア新設が目立つ6件のアップデート。","title":"【AWS】2026/03/21 のアップデートまとめ"},{"content":"\nはじめに 2026年3月20日のAWSアップデートは7件。LambdaのAZメタデータ取得対応と、Graviton4搭載のC8gnインスタンスの新リージョン対応が目を引きます。ほかにDirect Connectのシドニー拠点追加、EC2 FleetのCapacity Reservations対応、EFAのNIXLサポートなど。\n注目アップデート深掘り AWS Lambdaのアベイラビリティゾーンメタデータサポート Lambda関数が、自身の実行AZ IDを取得できるようになりました。これまでLambdaはどのAZで動いているかを知る手段がなく、RDSやElastiCacheへのアクセスでクロスAZ通信が発生しても制御できませんでした。\nこれで何ができるか\nAZ IDがわかれば、同一AZ内のRDSリードレプリカやElastiCacheノードに優先接続できます。クロスAZ通信はデータ転送料金が発生するうえレイテンシーも増えるため、高頻度で呼ばれるLambda関数では無視できないコスト要因でした。\n具体的な実装方法\nメタデータエンドポイントへHTTPリクエストを送るだけです：\nimport json def lambda_handler(event, context): # メタデータエンドポイントからAZ IDを取得 metadata_url = \u0026#34;http://169.254.169.254/latest/meta-data/placement/availability-zone-id\u0026#34; try: with urllib.request.urlopen(metadata_url) as response: az_id = response.read().decode(\u0026#39;utf-8\u0026#39;) # AZ IDに基づいてRDSエンドポイントを選択 if az_id == \u0026#34;use1-az1\u0026#34;: rds_endpoint = \u0026#34;database-az1.cluster-xxx.us-east-1.rds.amazonaws.com\u0026#34; elif az_id == \u0026#34;use1-az2\u0026#34;: rds_endpoint = \u0026#34;database-az2.cluster-xxx.us-east-1.rds.amazonaws.com\u0026#34; else: rds_endpoint = \u0026#34;database-default.cluster-xxx.us-east-1.rds.amazonaws.com\u0026#34; return { \u0026#39;statusCode\u0026#39;: 200, \u0026#39;body\u0026#39;: json.dumps({ \u0026#39;az_id\u0026#39;: az_id, \u0026#39;selected_endpoint\u0026#39;: rds_endpoint }) } except Exception as e: return { \u0026#39;statusCode\u0026#39;: 500, \u0026#39;body\u0026#39;: json.dumps({\u0026#39;error\u0026#39;: str(e)}) } Powertools for AWS Lambdaを使う場合：\nimport urllib.request logger = Logger() def get_az_id(): metadata_url = \u0026#34;http://169.254.169.254/latest/meta-data/placement/availability-zone-id\u0026#34; with urllib.request.urlopen(metadata_url) as response: return response.read().decode(\u0026#39;utf-8\u0026#39;) @logger.inject_lambda_context def lambda_handler(event, context): current_az = get_az_id() logger.info(f\u0026#34;Lambda executing in AZ: {current_az}\u0026#34;) # AZ情報を使ったルーティング return process_with_az_awareness(current_az, event) クロスAZ通信コストの確認\n$ aws cloudwatch get-metric-statistics \\ --namespace AWS/Lambda \\ --metric-name Duration \\ --dimensions Name=FunctionName,Value=my-function \\ --start-time 2026-03-20T00:00:00Z \\ --end-time 2026-03-20T23:59:59Z \\ --period 3600 \\ --statistics Average EC2 C8gnインスタンスの新リージョン対応 Graviton4搭載のC8gnインスタンスが、東京リージョンを含む追加リージョンで使えるようになりました。C7gn（Graviton3）比で約30%の性能向上、最大600 Gbpsのネットワーク帯域幅を持つネットワーク集約型のインスタンスです。\nTerraformでの定義例\nami = \u0026#34;ami-0abcdef1234567890\u0026#34; # Amazon Linux 2023 ARM64 instance_type = \u0026#34;c8gn.xlarge\u0026#34; # ネットワーク最適化を有効化 ena_support = true sriov_net_support = \u0026#34;simple\u0026#34; # 配置グループでネットワーク性能を最大化 placement_group = aws_placement_group.cluster.name tags = { Name = \u0026#34;high-performance-compute\u0026#34; InstanceFamily = \u0026#34;C8gn-Graviton4\u0026#34; } } resource \u0026#34;aws_placement_group\u0026#34; \u0026#34;cluster\u0026#34; { name = \u0026#34;compute-cluster\u0026#34; strategy = \u0026#34;cluster\u0026#34; } ベンチマーク手順\n# C8gn vs C7gn 性能比較スクリプト # CPU性能テスト echo \u0026#34;Running CPU benchmark...\u0026#34; sysbench cpu --cpu-max-prime=20000 --threads=8 run # ネットワーク帯域幅テスト echo \u0026#34;Testing network performance...\u0026#34; iperf3 -c target-server -t 60 -P 4 # メモリ帯域幅テスト echo \u0026#34;Memory bandwidth test...\u0026#34; sysbench memory --memory-total-size=10G run 公式の数値としては以下が示されています：\nネットワーク仮想アプライアンス: 30%のスループット向上 データ分析処理: 25%の処理時間短縮 AI/ML推論: 20%のレイテンシー削減 SRE視点での活用ポイント Lambda AZメタデータの使いどころ\nTerraformでLambda + RDSの構成を管理しているなら、AZメタデータを使った接続先の最適化は検討する価値があります。CloudWatchアラームと組み合わせれば、AZ単位での障害検知やフェイルオーバーの自動化にも使えます。\n注意点として、メタデータ取得にはHTTPリクエストが1回走ります。高頻度で実行される関数では、初回取得時にキャッシュする実装にしておくのが無難です。\nC8gnへの移行判断\nマイクロサービス間で大量のデータをやり取りする構成では、ネットワーク帯域幅がボトルネックになりがちです。C8gnの600 Gbpsは、そういった構成で効いてきます。ただしGraviton4はARM64なので、移行前にアプリケーションの互換性検証は必須です。段階的に移行して、ベンチマークで比較しながら進めるのが安全です。\n全アップデート一覧 サービス タイトル 概要 Amazon Redshift Redshift supports federated permissions with IAM Identity Center in multiple AWS Regions マルチリージョンでのIAM Identity Centerフェデレーション認証 AWS Direct Connect AWS Direct Connect announces new location in Sydney, Australia シドニーに新しいDirect Connect拠点を追加 Amazon EC2 Fleet Amazon EC2 Fleet now supports interruptible Capacity Reservations 中断可能なCapacity Reservationsに対応 AWS EFA AWS adds support for NIXL with EFA to accelerate LLM inference at scale LLM推論を高速化するNIXLのEFAサポート AWS Lambda AWS Lambda now supports Availability Zone metadata Lambda関数のAZ ID取得が可能に Amazon EC2 Amazon EC2 C8gn instances are now available in additional regions Graviton4搭載C8gnが東京を含む新リージョンで利用可能 Amazon RDS Amazon RDS Custom for SQL Server adds ability to view and schedule new operating system updates RDS Custom for SQL ServerにOSアップデート管理機能を追加 まとめ LambdaのAZメタデータ取得は、地味だけどコスト最適化に直結するアップデートです。クロスAZ通信コストが月数万円に達している環境なら、導入する理由は十分あります。C8gnの東京リージョン対応は、Graviton4への移行を検討していたチームにとっては待望のリリースでしょう。ARM64互換の検証さえ済んでいれば、すぐに試せます。\n","permalink":"https://isseeeeey55.github.io/tech-pulse/posts/aws-updates-20260320/","summary":"LambdaのAZメタデータ取得対応と、Graviton4搭載のC8gnインスタンスの新リージョン対応が目を引く7件のアップデート。","title":"【AWS】2026/03/20 のアップデートまとめ"}]