2026 年 3 月 30 日週、私はチームと一緒に AWS 香港ユーザーグループ を訪問しました。香港には小さいながらも強力なコミュニティがあり、彼らにはすばらしいエネルギーと情熱があります。彼らは最近、新しい AI ユーザーグループを立ち上げたので、私たちはさらに多くの人が参加することを願っています。すばらしい料理と会話を通して、コミュニティとの絆を強めることもできました。 2026 年 4 月 6 日週は、まずいくつかの主要な発表について詳しく見ていきます。 AWS DevOps エージェントおよびセキュリティエージェント GA 前回の re:Invent では、複数のステップにわたって自律的に作業して成果を達成し、仕事が完了するまで継続的に活動する フロンティアエージェントの概念 を紹介しました。最初の 2 つ ( AWS DevOps エージェントと AWS セキュリティエージェント ) は、プレビュー後に一般提供されるようになりました。 AWS DevOps エージェント は、インシデントの調査、解決までの時間の短縮、問題の発生前の防止など、クラウド運用の実行に役立ちます。ユナイテッド航空、ウエスタンガバナーズ大学 (WGU)、T-モバイルなどのお客様は既に DevOps エージェントを使用してインシデント対応を加速し、大規模な運用を簡素化しています。WGU では、解決にかかる時間が数時間から数分に短縮され、プレビュー版では MTTR が最大 75% 短縮され、解決が 3～5 倍早くなったという報告が顧客から寄せられています。詳細については、 Sébastien のプレビューブログ投稿 と GA の発表 をご覧ください。 AWS セキュリティエージェント は、開発ライフサイクルに継続的かつ状況に応じたペネトレーションテストを行います。このエージェントは人間のペネトレーションテスターのように動作します。LG CNS、HENNGE、Wayspring などのお客様は好調な業績を上げています。LG CNS では、誤検出が大幅に減り、テストにかかる時間が 50% 以上短縮され、コストも最大 30% 削減されるという結果が出ています。詳細については、 Esra のプレビューブログ投稿 と GA の発表をご覧ください。 どちらも AWS クラウド、マルチクラウド、オンプレミス環境で機能するように設計されています。面倒な作業を処理できるチームメイトをいつでも確保できるので、最も重要なことに集中できます。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変化した場合、私たちは運用の中断を最小限に抑えるために、利用可能な代替案について AWS 製品ライフサイクル の変更に関するガイダンスをお客様に提供し、移行をサポートします。次のライフサイクル変更は、2026 年 3 月 31 日に更新されました。 メンテナンス中のサービスの可用性変更ガイド AWS App Runner AWS Audit Manager AWS CloudTrail – Lake AWS Glue – Ray のジョブ AWS IoT FleetWise Amazon Application Recovery Controller (ARC) – 準備状況チェック Amazon Comprehend – トピックモデリング、イベント検出、および迅速な安全分類 Amazon Rekognition – ストリーミングイベント と バッチイメージコンテンツモデレーション Amazon Simple Notification Service (Amazon SNS) – メッセージデータ保護 (MDP) 日没時のサービスの可用性変更ガイド: AWS Service Management Connector Amazon RDS Custom for Oracle Amazon WorkMail Amazon WorkSpaces – シンクライアント 日没時のサービスリーチ: Amazon Chime SDK – プロキシセッション 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 2026 年 3 月 30 日週のリリース 2026 年 3 月 30 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon ECS が ECS マネージドインスタンス用のマネージドデーモンを発表 新しい AWS サステナビリティコンソール: スコープ 1～3 のレポートを 1 か所に Amazon Bedrock AgentCore Evaluations が一般提供されました AWS Transform カスタムが自動コードベース分析の一般提供を発表 Amazon CloudWatch が OpenTelemetry Container Insights for Amazon EKS を発表 (プレビュー) 最大 72 個の vCPU を搭載した Amazon Lightsail 用の新しいコンピューティング最適化インスタンスバンドル Amazon CloudFront が署名付き URL と署名付きクッキーの SHA-256 をサポートするようになりました AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 AWS 上のエージェンティック AI 開発のためのアーキテクチャ AWS Network Load Balancer を使用する際のデータ転送コストの最適化 AWS World Sports Innovation Cup の発表 – お客様のアイデアはゲームチェンジャーになるでしょうか? 本番環境での AI エージェントハルシネーションを阻止する 5 つのテクニック 3D インタラクティブグローブを通じてグローバルな AWS コミュニティを探索する AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、それらに参加してください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 4 月 6 日週のニュースは以上です。2026 年 4 月 13 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

皆さま、こんにちは！ 駅メモ！開発チームエンジニアの id:szeto です。 今回は、毎月行う報酬配布作業について、これまで行っていた本番環境のCLIでのスクリプト実行から、管理画面（運営が駅メモ！のゲーム設定を閲覧・更新できるシステム）の操作に変更した事例を皆さまに共有したいと思います。この取り組みのおかげで、運用効率が約66%改善されました！ これまでは本番サーバーにSSHでログインし、スクリプトを実行していましたが、Webブラウザから安全に、いくつかのクリックで操作できるように改善しました。この記事では、その背景、実装方法、そして得られた効果についてご紹介します。 目次 目次 背景・当時の課題 従来の運用フロー 具体的な課題 解決アプローチ 改善方針の検討 UI化の基本方針 期待される効果 実装詳細 UI設計 ワークフロー 実装で遭遇した課題と対応 課題1: 配布対象者数が多く画面表示に課題 課題2: 本実行結果の表示によるブラウザのパフォーマンス問題 バックエンド実装 API設計 運用・効果測定 まとめ 背景・当時の課題 駅メモ！では、特定のイベント形式にランキング要素があるため、イベント終了後に上位プレイヤーの皆さまへ報酬配布を行っています。従来、この作業は本番環境でエンジニアが直接CLIでスクリプト実行により実施していました。 従来の運用フロー 従来の作業フローは、ドキュメント作成から作業の見守り募集、DBバックアップ、本番サーバーのCLIでのスクリプト実行、ログ確認、告知作成まで、多くのステップと時間を要していました。 【改善前】本番サーバーのCLIでスクリプト実行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. ドキュメント管理サイトで手順書作成 2. 作業の見守り募集 3. DBスナップショット作成 (x3) ⏱️ 15分 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. 本番サーバーにSSH接続 5. CLIでのスクリプト実行 ⚠️ ヒューマンエラーリスク $ script1 --dry-run $ script2 --dry-run 6. 結果確認 7. 本番実行 ⚠️ ヒューマンエラーリスク $ script1 --execute $ script2 --execute 8. ログ確認・アーカイブ ⏱️ 75分 x 2人 = 150分 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 9. 告知文章作成 10. レビュー・公開 ⏱️ 25分 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 合計: 190分 (約3時間10分) 具体的な課題 この運用方法には、いくつかの課題がありました。 まず、操作の記録についてです。SSHによる本番サーバーへの直接ログインが必要で、操作ログの閲覧に手間がかかり、後から見返しづらい状況でした。 次に、ヒューマンエラーのリスクです。本番環境でスクリプトを実行する前には、パラメータやコマンドの内容を何度も確認する必要があり、1つのミスも許されないという大きな責任とプレッシャーが常につきまとっていました。 そして作業効率の問題です。 特に以下の作業に手間がかかっていました。 DBバックアップ 3プラットフォーム（コロプラ版駅メモ！・駅メモ！・アワメモ！）それぞれでAWSマネジメントコンソールを開いて手動操作が必要でした。各プラットフォームごとにコンソールを開き、スナップショット作成を実行し、完了するまで画面を確認し続ける…という作業を3回繰り返していました。完了通知もないため、定期的にコンソールを確認する必要があり、待ち時間が発生していました。 CLIでのスクリプト実行 対象イベントや配布環境の指定、ログファイルの作成など、すべて手動でコマンドに入力する必要がありました。本番環境での実行のため、実行前に何回もコマンドを再確認する必要があり、また手動操作でのミスを防ぐため同時実行が基本禁止となっており、スクリプト実行だけで毎回75分 x 2人という作業時間がかかっていました。 告知文章作成 報酬配布後、毎回お知らせ文章を手動で作成し、レビュー・公開する作業が必要でした。 これらの課題により、運用担当者の負担も大きく、より安全かつ作業負荷を軽減できる仕組みが求められていました。 解決アプローチ これらの課題を解決するため、報酬配布作業を管理画面から実行できるようにする方針を立てました。これにより、エンジニアだけでなく、プランナーも安全に作業を実行できることを目指しました。 改善方針の検討 改善方針を検討しました。 1つ目は報酬配布専用のスタンドアロンツールを開発する案です。しかしこれは認証基盤などを新規に構築する必要が生じます。2つ目は既存の管理画面に機能を追加する方法です。 また、プランナーから「自分たちで報酬配布を実行できるようにしたい」という要望がありました。実現できれば、エンジニアの作業時間をほぼゼロにすることも可能になります。 検討の結果、管理画面への統合を採用しました。理由は、まずエンジニアの作業効率化から始め、将来的にプランナーへの権限開放も検討できるという段階的な改善が可能なためです。また、既存の認証・認可機能を活用できるため新規にセキュリティ基盤を構築する必要がない点も大きな決め手となりました。 UI化の基本方針 まず、報酬配布に関連する自動化機能として、DBバックアップを実行するSlackワークフローを作成しました。従来は3プラットフォームそれぞれでAWSコンソールを開いて手動操作していましたが、Slackワークフローから1回の操作で3プラットフォーム全てのバックアップを実行できるようになりました。ワークフローが裏側でAWS APIを呼び出してスナップショットを作成し、完了するとSlackに通知が届きます。実行状況と結果はログとして保存されます。 次に、管理画面に以下の機能を追加しました。 ドライラン機能を実装しました。実行前に配布対象者と配布アイテムを確認でき、既存スクリプトの標準出力と同等の内容を表示します。プランナーでも理解できる形式にしました。 本実行機能では、ドライランの結果を確認後に本実行ボタンを有効化します。実行ログはJSON形式でダウンロード可能で、Slack通知機能も備えています。 また、従来は複数のスクリプトに分かれていた報酬配布作業を1つの機能に統合しました。 最後に、報酬を配布した後にお知らせを非公開状態で自動作成する機能を追加しました。テンプレート文言を使用するため、プランナーはレビュー・公開のみ実施すれば作業は完了です。 期待される効果 この改善により、以下の工数削減を見込んでいました。 作業項目 改善前 改善後 削減 エンジニア準備 15分 0分 -15分 エンジニアx2実行 150分 60分 -90分 プランナー告知 25分 5分 -20分 合計 190分 65分 -125分（約66%削減） 【改善後】管理画面でUI操作 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. Slackワークフローでバックアップ実行 ⏱️ 自動化 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. 管理画面にアクセス ✅ SSH不要 3. イベント選択 4. [ドライラン実行] クリック ✅ 誤操作防止 5. 画面で結果確認 6. [実行を確認] クリック ✅ 操作記録 7. Slack通知を確認 ⏱️ 30分 x 2人 = 60分 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8. お知らせ下書き自動生成済み 9. レビュー・公開 ⏱️ 5分 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 合計: 65分 (約1時間) 💡 125分削減 (約66%の時間削減) 実装詳細 UI設計 管理画面に専用のランキング報酬配布ページを追加しました。 ワークフロー 操作の流れは3ステップで明確化しました。 Step 1: イベント選択 Step 2: ドライラン結果確認 Step 3: 実行リクエスト送信完了 実装で遭遇した課題と対応 実装中にいくつかの課題に直面しました。 課題1: 配布対象者数が多く画面表示に課題 ランキング報酬の配布対象者が数千人規模になると、ユーザーリストが非常に長くなります。その結果、画面の可読性が低下しました。 【対応前】スクロールが大変 ━━━━━━━━━━━━━━━━━━━━━ イベント情報 配る報酬 配布結果 1位: 太郎 2位: 花子 ... 999位: 健太 <- スクロールが大変 1000位: さくら 実行ボタン <- 遠い！ ━━━━━━━━━━━━━━━━━━━━━ 対応策として、画面右側に固定のナビゲーションメニューを追加し、各セクションへワンクリックでジャンプできるようにしました。 課題2: 本実行結果の表示によるブラウザのパフォーマンス問題 本実行の結果表示では、数千件の配布対象ユーザーを配列からフィルタリングし、それぞれに対応する個別リンクをマッピングして画面に出力する必要がありました。初回の本番配布時、この結果をそのまま画面上にレンダリングしたところ、ブラウザが長時間フリーズしてしまいました。配布自体は成功していたものの、フリーズが解消されるまで長時間待つ必要があり、運用担当者の作業時間を削減するという本来の改善目的に反する状態でした。 【対応前】 実行完了！ 配布結果: 1位: 太郎 - ✅ 配布完了 2位: 花子 - ✅ 配布完了 ... 999位: 健太 - ✅ 配布完了 <- 数千件のデータで 1000位: さくら - ✅ 配布完了 ブラウザがフリーズ 【対応後】 実行中 - Slackで通知します 報酬配布結果確認リンク: 🔗 1位 [ランキング] <- 新しいタブで開く 🔗 50位〜51位 [ランキング] <- ボーダーラインのみ 🔗 100位〜101位 [ランキング] リンク提供 🔗 1000位〜1001位 [ランキング] 対応策として、詳細な配布結果は個別ページへのリンクとして提供しました。これにより、確認が必要なときに新しいタブで開けるようにしました。 バックエンド実装 既存の配布スクリプトを活用しつつ、管理画面から呼び出せるようAPI化しました。 既存の報酬配布スクリプトが安定して動作していたため、ゼロから作り直すのではなく、既存資産を活かす方針を採用しました。 API設計 管理画面からのリクエストを受け付け、報酬配布処理を実行するAPIを実装しました。 運用担当者 ↓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 管理画面 ・イベント選択 ・ドライラン実行 ・本実行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ API呼び出し ━━━━━━━━━━━━━━━━━━━━━━━━━━━ バックエンドAPI ・dry_run: true -> 即座に結果 ・dry_run: false -> 非同期実行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ スクリプト実行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 既存スクリプト群 ・報酬配布 ・勲章付与 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ DB操作 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ データベース ・報酬データ ・ランキングデータ ━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ 完了通知 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ Slack 「報酬配布が完了しました」 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 報酬配布APIでは、既存スクリプトを呼び出して報酬を配布します。APIが呼ばれると従来の配布スクリプトを順次実行します。スクリプトの実行順序は従来の運用フローと同じです。実行完了時にはSlackへ通知を送信するようにしています。 お知らせ下書き自動作成機能では、工数削減を目的として報酬を配布した後に自動的にお知らせの下書きを作成します。配布完了直後に非公開状態のお知らせを自動生成し、テンプレート文言を使用するためプランナーはレビュー・公開のみ対応すれば完了します。これにより、告知作成の工数を約80%削減できました。 ログ管理も改善しました。従来の標準出力形式から構造化されたJSON形式へ変更し、ログファイルを自動生成して管理画面からダウンロード可能にしました。JSON形式のためプログラムでの解析が容易で、トラブルシューティング時の調査が効率化されました。 また、ログ管理をサポートする補助的なAPIも実装しました。過去の実行ログ一覧を取得するAPIと、指定したログファイルをダウンロードするAPIです。これにより管理画面から実行履歴を簡単に確認できます。 運用・効果測定 実際に運用を開始し、期待される効果で見込んでいた内容と比較してみました。 作業時間の削減については、ほぼ期待通りの結果となりました。UI化により手動操作のミスリスクが軽減されたことで、従来禁止していた3プラットフォーム同時配布が可能になり、作業時間は60分×2人から30分×2人に短縮されました。お知らせ文章を作成する作業も省けるようになっています。 一方、期待以上の効果だったのは、配布実施者の心理的なプレッシャーの軽減です。もうコマンドを打つ必要がないため、本番環境での操作に対する緊張感が和らぎました。これは当初の工数削減という目的を超えた、想定外のメリットでした。 まとめ 今回は、ランキング報酬配布作業のUI化についてご紹介しました。 本番環境のCLIでのスクリプト実行から管理画面操作への変更により、作業時間を約66%削減できました。しかし、最も大きな効果は数値では測れないものでした。それは「本番環境でコマンドを打つ必要がなくなった」ことによる心理的なプレッシャーの軽減です。 エンジニアとしてCLI操作に慣れていたため、当初は「UI化してもそんなに変わらないだろう」と効果に疑問を持っていました。しかし実際に運用してみると、ボタンをクリックするだけで済む安心感は想像以上でした。技術的には単純な変更でも、手作業を減らすことで運用の質は大きく変わります。もし似たような定型的な手作業がチームにある場合、ぜひUI化を検討してみてください。 今まで報酬配布は全てエンジニアが担当していましたが、将来的には他のメンバーも実行できる可能性が見えてきました。運用の効率化を実現できた本プロジェクトは、チーム全体にとって大きな前進となったと感じています！

この記事の狙い Windows 11への移行や第12世代以降のハイブリッドCPU採用が進む中、企業端末の運用・セキュリティ対応の現場では、「CPU使用率は高くないのに操作が重く見える」「更新・同期・セキュリティ関連のバックグラウンド処理が前面操作に影響しているように見えるが、原因を説明しにくい」といった事象を、従来より丁寧に整理・説明する必要性が高まっています。 特に、セキュリティ対策ソフト、ログ収集、更新適用、同期処理など、業務上必要なバックグラウンド処理がユーザー体感や業務アプリの応答性に影響している可能性がある場合、単にCPU使用率や優先度だけを見ても十分に説明できないことがあ