みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 7 月 28 日（火）に「 AWS Bedrock LLM Day Japan 」が東京 赤坂インターシティにて開催されます。AWS Summit New York で発表された最新のサービスアップデートを日本のお客様向けにいち早くお届けするとともに、Amazon Bedrock上でのAnthropic・OpenAIモデルの活用法や、AIエージェント構築基盤AgentCoreの最新機能を実践的に解説します。ぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「エムシーディースリー株式会社様：AI-DLC Unicorn Gym による3日間の開発変革」を公開 三菱商事グループの一員として産業 DX を推進するエムシーディースリー株式会社様と実施した、AI 駆動開発ライフサイクル（AI-DLC）の体験型プログラム「Unicorn Gym」のレポートです。7 つのチームが Kiro を活用して実際のプロダクト課題や業務課題に挑み、3 日間で商用レベルに近いアプリケーション開発やレガシー環境のコンテナ化を実現した様子と、各チームが得た学び・活用の工夫を紹介しています。 ブログ記事「フロンティアモデルの安全なリリースに向けた AWS の取り組み」を公開 Anthropic の Claude Fable 5 が、悪用を防ぐためのさらに強力なガードレールを備えて Amazon Bedrock で再び利用可能になりました。本ブログでは AWS の CISO である Amy Herzog が、Project Glasswing を通じた Anthropic との連携のもと、サイバーセキュリティ分野で強力な能力を持つフロンティアモデルを防御側に届けつつ、攻撃者への悪用を防ぐための考え方を説明しています。ガードレール作動時には Opus 4.8 に自動フォールバックする仕組みも紹介されています。 ブログ記事「Amazon Bedrock のゼロデータ保持の強制方法」を公開 Claude Fable 5 のようにモデルプロバイダーとのデータ共有を必要とするモデルの登場を受けて、Amazon Bedrock のデータ保持モード（none / default / inherit / provider_data_share）の仕組みを解説しています。Amazon Bedrock Projects によるプロジェクト単位のきめ細かい制御や、サービスコントロールポリシー（SCP）で組織全体にゼロデータ保持を強制する方法を、具体的なポリシー例と検証手順付きで紹介しています。データガバナンス要件のある組織の方は必見です。 ブログ記事「【公共向け】Claude Mythos 時代の脅威対策ワークショップ開催報告 & 耐障害性ライフサイクル実践ワークショップのご案内」を公開 パブリックセクターのお客様向けに月次開催しているセキュリティワークショップの第 3 回・第 4 回の開催レポートです。「Claude Mythos 時代の脅威への対応」をテーマに、Amazon Inspector による脆弱性管理・パッチ運用自動化と、AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストのハンズオンを実施しました。ワークショップ教材は 一般公開 されていますので、ぜひお試しください。 ブログ記事「AWS パートナーと実現する生成 AI — 現場を変える8つの実践事例 AWS Summit Japan 2026 Partner Breakout Session レポート」を公開 AWS Summit Japan 2026 で 4 部構成にてお届けした Partner Breakout Session のレポートです。東邦ガス情報システム様の Kiro 導入、青森放送様の Amazon Bedrock を活用した文字起こしシステム、品川区様の音声 AI 実証、日本取引所グループ様の GraphRAG による暗黙知の形式知化など、8 組の AWS パートナーとお客様による実践事例のハイライトと、全セッションを通して見えてきた「AI の価値を現場で実現するために本当に必要なこと」を紹介しています。 ブログ記事「AWS Parallel Computing Service と Kiro CLI で HPC のデプロイを加速する」を公開 従来数週間かかっていた HPC クラスターのデプロイを、Kiro CLI のカスタムエージェントで自動化する方法を紹介しています。AWS PCS のベストプラクティスを組み込んだエージェントとの対話だけで、ネットワーク、コントローラー、キュー、コンピュートノードを備えたクラスターを約 30 分で構築する手順を、 デモリポジトリ とともに順を追って解説しています。 ブログ記事「Kiro の超過利用の上限設定と前払い機能のご紹介」を公開 Kiro の超過利用 (overage) の支出をコントロールする 2 つの新機能を紹介しています。IAM Identity Center 等でサインインするチーム向けには AWS Service Quotas コンソールから超過利用の上限を設定できるようになり、個人開発者向けには最小 5 ドルからのクレジットパックを前払いで購入できるようになりました。想定外の請求を防ぎたい方におすすめのアップデートです。 ブログ記事「Kiro で Claude Sonnet 5 が利用可能になりました」を公開 2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE、CLI、Web で利用可能になりました。Sonnet 5 は推論力・ツール利用・コーディング能力が大幅に強化され、Sonnet クラスの価格のまま Opus 4.8 に近いエージェント性能を発揮します。クレジット倍率は Sonnet 4.6 と同じ 1.3 倍、100 万トークンのコンテキストウィンドウを備えており、タスクに応じて Opus 4.8 とのコスト・性能バランスを選べるようになりました。 サービスアップデート Amazon SageMaker HyperPod が Prefill と Decode の分離 (Disaggregated Prefill and Decode) をサポート Amazon SageMaker HyperPod で LLM 推論の Prefill と Decode を専用の GPU プールに分離する DPD がサポートされました。従来は両フェーズが同じ GPU を奪い合い、長いコンテキストのリクエストが他のトークン生成を停滞させていましたが、今回のアップデートで安定したレイテンシと高いスループットを実現し、両フェーズを独立してスケールできます。長いリクエストだけを自動で分離パスに振り分けるルーターも備えています。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターでディープヘルスチェックをサポート 継続的プロビジョニングで作成した Slurm クラスターでも、GPU の健全性や接続性を検証するディープヘルスチェックが実行可能になりました。非同期に追加される新しいノードを、稼働中のワークロードを中断せずにジョブ投入前に検証できます。自動ノード復旧機能と組み合わせれば、失敗したインスタンスは自動で再起動・交換されます。詳細は こちらのユーザーガイド をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターで AMI ベースのノードライフサイクル設定をサポート 継続的プロビジョニングを使用する Slurm クラスターでも AMI ベースの設定が利用可能になりました。これまで必要だったライフサイクル設定スクリプトの管理が不要になり、Docker や Slurm アカウンティングなどを備えた本番対応のノードを AMI から直接構成できます。ノード追加時点で設定が完了するため、より早くジョブをスケジュールできます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Studio がワンクリックのモデルデプロイとカスタマイズのために Hugging Face と統合 Hugging Face のモデルページから「Deploy on SageMaker AI」などを選ぶだけで、モデルがロード済みの Studio 環境に直接アクセスできるようになりました。従来はコンソールでの環境構築や IAM 設定、GPU クォータ申請が必要でしたが、今回のアップデートで数秒で環境が作成され、ファインチューニングやデプロイに必要な権限も事前設定されます。 AWS Neuron 2.31.0 が NKI 0.5.0 と UltraServer Operator とともに利用可能に AWS Neuron 2.31.0 がリリースされました。NKI 0.5.0 では MX FP8 スケール dtype や新しいテンソルビュー API が追加され、Amazon EKS 上の Trainium UltraServer ワークロードの管理を自動化する UltraServer Operator がパブリックベータで登場しました。Trn2・Trn3 でデフォルト有効になった新コンパイラバックエンドによる性能向上や、14 の実験的カーネル追加も含まれます。 AWS MCP Server が OAuth をサポート AWS Sign-In を使って AI エージェントを AWS MCP Server に直接接続できるようになりました。業界標準の OAuth を利用するため追加の認証ソフトウェアは不要で、既存の AWS ID や IAM 権限、ガバナンス制御がそのまま適用されます。ブラウザでの対話型認可とヘッドレス認可の両方に対応し、トークン失効 API や CloudTrail 監査などの統制機能も提供されます。詳細は こちらの Blog 記事 をご参照ください。 AWS DMS Schema Conversion が AI エージェントによる自動化をサポート AWS DMS Schema Conversion が AWS MCP Server を通じた AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などを接続し、IDE から自然言語でスキーマ変換や評価レポート生成などの移行ワークフロー全体を実行できます。専用スキルが API パターンや操作手順をエージェントに提供するため、試行錯誤を削減できます。追加料金なしで利用可能です。詳細は こちらのドキュメント をご参照ください。 Kiro IDE 1.0.116 — エージェント書き込み時のフック、遅延 MCP 認証、マルチウィンドウ同期 Kiro IDE 1.0.116 がリリースされました。エージェントによるファイル変更をトリガーにフックを実行できるようになり、サインインが必要な MCP サーバーへの自動 OAuth 認証や、複数ウィンドウ間での設定同期にも対応しました。trust 機能や接続まわりの修正も含まれています。 Kiro CLI 2.12 — MCP OAuth サポートの拡張 Kiro CLI 2.12 がリリースされました。Figma のように厳格な OAuth 要件を持つ MCP サーバーに対応し、クライアントシークレットの設定、カスタムコールバックパスの指定、独自クライアント ID 使用時の動的クライアント登録のスキップが可能になりました。複合フラグを持つコマンドのより正確な承認プロンプトや、ASCII モードの完全対応も含まれています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

今回、6月25日・26日に幕張メッセで開催された AWS Summit Japan 2026 に、SREチームで参加してきました！ 会場では多くの企業によるAWSの活用事例や、生成AI・セキュリティ・運用改善に関するセッションが行われており、日々の開発やSRE活動に活かせそうな学びが多くありました。 SREチームとしても、普段取り組んでいる信頼性向上や運用改善のヒントを得る良い機会になりました。 こちらのブログでは、弊社の参加メンバーが特に印象に残った講演について、自社の課題や活かせそうなポイントを踏まえて紹介します！ 実践！Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上 「 AWS Brand Event PPT Template_v1 」1ページより引用 こんにちは！5月にクラシルへ入社しました、satsukiです 🌱 現在はクラシルのSREとしてインフラ運用や信頼性向上のための取り組みを行っています。 今年のAWS Summitは、ブレイクアウトセッションの約半数がAIエージェント関連でした。テーマも「何ができるか」より「本番でどう運用するか」を扱うものが目立っていて、各社が運用フェーズの課題に向き合い始めているんだなと肌で感じました。 一方で、やりたいことが増えるほど気になるのがコストです。新しい技術を試し続けるためにも、既存インフラのコストは常に見直しておきたいところです。 クラシルでもAuroraを運用しているのでコスト見直しのヒントになりそう💡と思い、こちらのセッションを聴講し、実際に多くの学びがありました。 セッションは、架空の企業が抱える7つの課題を、Database Insightsで現状を可視化→ボトルネックを特定→コンピュート・ストレージ・バックアップを適正化していく、という流れで解決する構成です。性能問題が起きるとインスタンス増強で対処しがちですが、垂直スケール以外の選択肢が次々と紹介されていて、 コストとパフォーマンスは両立できる と実感できる内容でした。 「 AWS Brand Event PPT Template_v1 」70ページより引用 Aurora I/O-Optimizedをクラシルに当てはめてみる 特に気になったのが、このセッションで初めて知ったAurora I/O-Optimizedです。I/Oリクエストへの課金がなくなる代わりにインスタンスとストレージの単価が上がる料金モデルで、I/Oの多いワークロードならコストを最大40%削減できるとのこと。夕食どきにトラフィックが跳ね上がるクラシルに合うかもしれないと思い、クラスタのメトリクスを確認してみました。 結果、I/O支出の割合は 目安の25% を大きく下回っていました。読み取りのほとんどがバッファプール（メモリ上のキャッシュ）で完結していて、課金対象になるストレージ層へのI/Oが少なかったためです。切り替えは見送りましたが、メモリとI/O課金がトレードオフの関係にあると分かったのは収穫でした！バッファプールの余裕は、インスタンスサイズを検討するときの新しい判断材料になりそうです。 バックアップ要件を見直す バックアップコストの削減では、保持期間を要件ごとに分けて考えるやり方が紹介されていました。 「 AWS Brand Event PPT Template_v1 」60ページより引用 データベースとして復元が必要なのは直近どの期間までかを決め、自動バックアップはその期間だけ保持する それより古いデータは監査などで参照できれば十分なことが多いので、スナップショットをParquet形式でS3へエクスポートする クラシルのバックアップも、この軸で要件を整理し直せばさらにコストを下げられる余地がありそうです。 なお、弊社のバックアップ運用については、次のjoeさんのパートで詳しく紹介されています！ まとめ コストの削減は、パフォーマンスをどこまで我慢するかという話になりがちです。でも今回紹介された解決策はどれも、現状を可視化して選択肢を知ってさえいれば、性能を落とさずにコストを下げられるものでした。クラシルには、トレードオフを前提にせず両方を成立させる道を探しにいく「 Trade on 」というバリューがあります。データベース運用でトレードオンするための引き出しが、今回のセッションでぐっと増えました。 他にもRDS・Auroraのコスト削減事例が紹介されているので、気になる方はぜひセッションの 資料 を見てみてください！ 参考URL: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html ランサムウェアに対して最優先で取るべき AWSの復旧対策 「 R01_0625_STG205_v2.pdf 」1ページより引用 SREチームのjoeです！AWS Summitの現地参加は久しぶりだったのですが、相変わらずの規模の大きさでとても楽しかったです！ 私が紹介するセッションは、ランサムウェアに対して最優先で取るべき AWSの復旧対策です。 近年、ランサムウェアをはじめとするサイバー攻撃において、Backupデータそのものが標的になるケースが増えています。本番データを暗号化するだけでなく、復旧手段であるBackupも同時に破壊・暗号化することで、身代金の支払いを強制する手口です。 こうした攻撃に対して、単純なスナップショット取得だけでは防御として不十分です。こちらの講演は、AWS Backupがそのソリューションに最適である、という話となっています！ 実際弊社としてもこちらの課題を抱えており、去年AWS Backupを導入しました。 弊社はAWSのマルチアカウント環境であり、開発チームがそれぞれBackupを運用している場合、取得頻度や保持期間にムラが出やすく、いざというときに復元できないリスクもありました。実際にPRC（Production Readiness Check）を運用する中で、Backupは負荷の高い項目でした。その課題に対してOrganization単位でAWS Backupを導入しました。Organization側で、AWS Backupを実装することで、各AWSアカウント側はリソースタグ付けのみで3-2-1-1-0ルールを踏襲したバックアップが取得できるようになりました。実際に入れてみてとてもいいソリューションで、運用工数も大幅に下がりました。 ただしいくつかハマりポイントがあったのでこちらの講演を見てAWS Backupを導入する方は参考にしてみてください！ AWS Backupで実際に体験したハマりポイント コストについて 1. DynamoDB 弊社のDynamoDBのテーブルサイズが大きく、数TBあるテーブルではBackupコストが想定を大幅に上回りました。 S3は増分Backupに対応していますが、DynamoDBのAWS Backupは増分Backupに対応していません。毎日フルBackupを取得すると莫大なコストがかかります。 対策として、巨大なテーブルに対しては以下の構成にしています。 AWS BackupによるDynamoDBの取得は月1回に抑制 S3にはPITR（Point-in-Time Recovery）を有効化し、S3をBackup対象にする 復元時には、日次の差分をGlueジョブでPITRの情報からテーブルに補填する仕組みを構築 これによりBackupコストを大幅に抑えつつ、復元時のデータロスを許容範囲に収めています。 2. S3 S3は増分Backupに対応しているものの、RequestTier2（データ取得リクエスト）のコストが想定以上にかかりました。オブジェクト数が多い場合は、Backupコストの見積もり時にリクエスト料金も含めて試算することをおすすめします。 PolicyとVaultの切り分け方について AWS BackupにはPolicyとVaultという概念があります。 Policy: バックアップを「どう取るか」を決めるルール（スケジュール・保持期間・保存先） Vault: 取ったバックアップを「どこに置くか」となる保管庫（暗号化・アクセス制御の単位） 両者は設計の自由度が高い分、PolicyとVaultをどういう単位で分けるかで迷いました。これはいち意見なので、正解ではありませんが、個人の意見を載せておきます。 1. Policyの切り分け 結論として、 Backupの要件（重要度）ごとに分ける のが運用しやすいと考えます。例えば「重要度 高・中・低」のような分類です。 また、Policyの命名規則ですが、要件の意味（重要度）で命名し、具体的な設定値はPolicy定義の中に閉じ込めるほうが安全だと思っています。　例えば daily-30days-retention のような命名にすると、途中からBackup要件を変更したくなったとき、Policy名やタグと実態がズレてしまいます。 2. Vaultの切り分け コンプライアンスモードの有無や保持期間の違いで分けるのが一般的なのかなと思いますが、運用してみて 復元設定を変えたい単位で分けるパターンもあると感じました。復元の設定はVault単位一括でしか行えないためです。 逆にそれ以外の軸で細かく分ける必要はないと考えています。弊社のパターンでは、Vaultを統一しておけばアカウントが増えてもVaultを追加する必要がなく、運用が楽になりました。 ECS 最新デプロイパターン Deep Dive SREのmoikeiです！ 弊社はほぼ全サービスでECS/Fargateを利用しており、デプロイも多いです。 こちらのセッションではECSのデプロイ周りに関して直近のアップデートを扱うセッションでした。大きく2点です。 高解像度メトリクス によるスケールアウト: 高解像度メトリクス（20秒粒度）を使ったスケーリング Seekable OCI (SOCI) v2: コンテナイメージの遅延読み込みによる起動高速化。 特に2はFargateも2025年7月に対応したこともあり、弊社に全体的に活用できそうと感じました。使用感を確認してみましたので、参考にしてください！ サクッと試してみた SOCIとは、コンテナイメージを全部ダウンロードし終わってから起動するのではなく、必要なファイルだけ先に取り出してコンテナを起動できるようにする仕組みです（レイジーローディング）。 ECRのイメージをローカルにダウンロードしイメージ変換後、再プッシュしてECS起動し、どのくらい早くなるかみてみました。イメージサイズが小さいと効果が出ないとのことで、 458MB のイメージでやってみました。 必要なものは以下です。 レジストリ/OCI layout操作系 : ECRからイメージを取り出し、変換後のイメージをECRへ戻すために使用。ローカル(Mac)で動作確認したかったため今回は crane を使用。 SOCI専用ツール : soci convert を使用。SOCI v2のSOCI-enabled imageを生成する こんな手順でやってみました。 今使っているイメージをECRから手元のOCI image layoutとして取り出す crane pull --format=oci <ECR_REPO>:<TAG> image-oci soci convert で、元イメージのレイヤーとSOCI indexを紐付けたSOCI-enabled imageを生成する # 今回はMac上でサクッと確認したかったため、Linux/arm64のコンテナ内で soci を実行しました。soci バイナリは事前にローカルへダウンロードし、作業ディレクトリに置いています。 docker run --rm --platform linux/arm64 \ -v "$(pwd)":/work \ -w /work \ alpine:3.20 \ /work/soci convert --standalone --format oci-dir /work/image-oci /work/image-soci 変換後のイメージを、別タグでECRへpushする crane push image-soci <ECR_REPO>:<TAG>-soci ECSタスク起動 ECRを見ると、以下の3つが確認できました。 Type サイズ 役割 Image 458.53MB コンテナイメージ本体 Soci Index 21.23MB レイヤー内のファイル位置など、遅延読み込みに使う索引 Image Index（tag付き） 458.53MB ECS/Fargateのタスク定義から指定するSOCI-enabled image ECRコンソール上では、tagなしのImage Indexなど追加の行が見えることもありますが、SOCI v2として理解するうえでは、元イメージ本体・SOCI index・それらを紐付けるImage Indexの3つを見ると分かりやすいです。 結果どうだったか? pull時間 全体起動時間 Before（通常イメージ） 約13.6秒 約30.1秒 After（SOCI v2） 約3.9秒 約19.6秒 pull時間 約71%減 、全体起動時間 約35%減 となりました！ デプロイやスケール時にも高速に完了できそうです。デプロイプロセスへ組み込みも検討しようと思います！ 参考URL: https://aws.amazon.com/jp/blogs/news/improving-amazon-ecs-deployment-consistency-with-soci-index-manifest-v2/ AWS における Kubernetes の未来 レシチャレのSREチームに所属しているKJです。弊社はほぼ全サービスで ECS/Fargate を利用していますが、最近 AI 基盤やプラットフォーム化の流れで EKS / Kubernetes を採用するケースが増えてきた感覚があり、動向を掴んでおきたくてこのセッションを聞いてみました。ECS ユーザー目線でも「これはいいな」と思えた点が多かったので、まとめておきます。 一番の学び：EKS と ECS の選択基準 個人的に一番の学びだったのが、EKS と ECS の選択基準の話です。「 Kubernetes のエコシステム（周辺の OSS ツール群）をそのまま使いたい 」というニーズが採用理由になる、というのは、ECS 中心でやってきた自分には新鮮な視点でした。セッションでも 「Kubernetes API とエコシステムのツールは使いたい。しかし、クラスターやアップグレードのことは考えたくない」 という声が紹介されていて、まさにこの需要を言い当てているなと感じました。こうした背景もあって採用が増えているのかもしれません。 ECS ユーザーとして「いいな」と思った点 EKS もメンテナンスフリーの方向に進んでいる ：アップグレードやノード管理を AWS 側にオフロードする流れ（ Auto Mode 、アップグレードインサイト、アップグレード前提の AWS Backup 対応 など）が印象的でした。Kubernetes は採用したはいいものの、その後のアップデートライフサイクルに追従し続けるのが辛い、という話は現場でもよく耳にします。だからこそ「運用をなるべく AWS 側で引き受ける」方向への進化は、素直にありがたいなと感じました。 グローバルダッシュボードが便利そう ：AWS Organizations からワンクリックで、全アカウント・全クラスターのインベントリやバージョンをまとめて俯瞰できます。これは Kubernetes に限った話ではなく、マルチアカウントで運用していると複数アカウントをまとめて見たい場面が多いので、こうした横断ビューは素直に便利そうだと感じました。 ロードマップは引き続き注視したい ：セッションで案内された公開ロードマップ（github.com/aws/containers-roadmap）には、EKS だけでなく ECS の情報も載っています。たとえば ECS Service Connect の Zone-Aware ルーティング は、ちょうど 2026 年 7 月に GA になったばかりの機能で、同一 AZ 内のサービス間通信を優先することで AZ 間（cross-zone）のデータ転送を削減できます。デフォルト有効（既存サービスは一度再デプロイすれば有効化）とのこと。ある程度トラフィックのあるシステムだと AZ 間のデータ転送コストも無視できない規模になってくるので、コスト面でかなり効いてきそうです！ EKS の進化の方向性は、ECS のこれからを考えるうえでも参考になります。引き続きロードマップは追いかけていきたいと思います。 参考にしたURL - aws/containers-roadmap（GitHub） AWS DevOps Agentによる自律的インシデント対応 - その能力を引き出す設計のベストプラクティス SREチームのkaitoです！ 弊社ではすでにDevOps Agentを導入していますが、まだ活用しきれていない部分もあります。インシデント対応での初動の遅さや、各種ダッシュボードの行き来で調査速度に課題を感じていたため、一次対応時にすでにエージェントによる調査結果が出力され、初動の速度が上がることを期待してこのセッションを聴きました。 セッションの概要 DevOps Agentは「調査はAI、判断は人」をコンセプトにした障害対応特化のAIエージェントです。アラートをトリガーに自律的に調査を開始し、メトリクス・CloudTrail・ログを収集して根本原因を特定、緩和計画の提案まで行います。セッションではデモに加え、DevOps Agentの能力を引き出すベストプラクティスが紹介されていました。 能力を引き出す設計のベストプラクティス 調査スコープを決めて精度を引き出す：DevOps AgentにはAgent Spaceという概念があります。標準ではアカウント単位ですが、マルチアカウントで同一システムを構成している場合はシステム単位でまとめないと、別アカウントの変更が調査対象に入らず根本原因を特定できません。逆に同一アカウント内でも、stg/prdでAgent Spaceを分けて本番環境の調査にステージングのリソースが混入しないようにする設計も可能です。弊社もマルチアカウント構成なので、この設計方針はそのまま使えそうです。 テレメトリを充実させて正確性を上げる：デモでは、あるサービスのアプリケーションログがインシデント時間帯に存在せず原因特定できないケースが紹介されていました。Container/Database/Lambda InsightsでAWSマネージドサービスを観測し、OpenTelemetry（AWS Distro for OpenTelemetry）でアプリケーション側の情報を取得できるようにしておくことで、調査の精度を上げる例が発表されていました。 ナレッジを共有して時間を短縮する：同じ障害シナリオでナレッジ整備前後を比較したデモでは、根本原因に到達するまでの時間が6分32秒から3分38秒に短縮されていました。個別の調査手順はSkills、共通の前提知識はAgent Instructions（AGENTS.md）で渡すことが推奨されていました。既存のRunbookをmarkdownやPDF、画像からそのまま取り込めるので、導入のハードルは低そうでした。障害対応のナレッジは属人化しがちですが、「人に教える」のではなく「エージェントに教える」ことでチーム全体の調査品質を底上げできるという考え方が面白かったです。 応用：MCPサーバーによる拡張 ビルトイン連携（CloudWatch、New Relic、GitHub）等に加え、MCPサーバー経由で社内の独自ツールとも接続できます。紹介された事例では、AWS上で構築されたMCPサーバーを利用し、DBの中身まで安全に調査する拡張が紹介されていました。（CyberAgent社） 全体的に実用性の高い内容のセッションでした！既存の構成をベストプラクティスに寄せながら、属人化しないインシデント対応を目指していきたいと思います！ まとめ 以上がクラシル社のSREチームが気になった講演と、自社のシステムを踏まえたうえでポイントに感じたこととなります。 引き続きAWSを利用し、スピード感を持ってユーザーに価値貢献できればと思います！

こんにちは、スタンバイで求人の取り込みシステムを開発・運用をしている鈴木です。 今回は proto ファイルの定義からモデルファイルを作成する際に taskfile を利用してみたお話です。 背景 私たちは、求人取り込みのプロセスを役割に応じて分割したコンポーネントプロジェクトを連携したマイクロサービスで実現しています。 データストアに保存するデータ型の定義やコンポーネント間のインターフェースは、コンポーネント毎に同じものを定義してしまうと不具合の元になるため、プロトファイルとして定義して各コンポーネントで同じになるよう利用しています。 このプロトファイルの運用を改善していきました。 概要 今回の作業をする前の前提や経緯は次のとおりでした。 ver 1.0 Taskfile でコマンド化 モデルやコンポーネント間のIF定義をprotoファイルで定義し管理している ver 2.0 バージョン差分の対応 それぞれのローカル環境で実行すると protoc のバージョンにより不要な差分が発生した コンテナで生成することによりバージョン差分が発生しない運用にした ver 3.0 プラグインの対応 コンポーネントごとに依存関係のあるファイルはそれぞれ異なる 一部のコンポーネントのみ利用しているプラグインがある コンポーネントごとの固有の定義を設定するタスクとそこから呼ばれる共通の生成タスクの構成に変更した おまけ タスク一覧が増えて可視性が悪くなったため peco で絞り込みと実行ができるようコマンドを作成 ver 1.0 Taskfile でコマンド化 proto ファイルの導入当初は作業者の端末にインストールされた protoc コマンドを直接実行して .pb.go ファイルを作成していました。 始めのうちは対象のファイル数も少なく、メンバーも同じタイミングで環境構築をしていたので特に問題は発生していませんでした。 ただ、それでも変更があった場合に手動で protoc コマンドを実行して再作成するのは手間で更新漏れの元になるため、 Taskfile でコンポーネントごとに一括して全体の更新もできるように作りました。 以下のように実行していたコマンドが protoc -I=../proto --go_out=. modA.proto modB.proto modC.proto このようになりました。 task proto:component1 変更があった場合に Taskfile の定義も更新する必要がありますが、生成対象が抜けてしまうリスクは多少下がりました。 一旦これで運用していたのですが、新メンバー(私)が参加したことで protoc コマンドのバージョン差異が発生してしまい、作成された .pb.go ファイル内のバージョン情報が差分として検出されてしまうようになりました。 ver 2.0 バージョン差分の対応 バージョン差分問題の対応として、端末にインストールされた protoc を直接実行するのではなく、 protoc が含まれた Docker イメージを作成して .pb.go の作成はそのイメージを利用する方針にしました。 それにあたりイメージを作成するための Dockerfile と起動するための docker-compose.yml を追加しました。 ファイルやディレクトリの構成はざっくりこのようになりました。 project_root ├── app │ ├── component1 │ │ ├── modA.pb.go │ │ ├── modB.pb.go │ │ └── modC.pb.go │ ├── component2 │ │ ├── modB.pb.go │ │ └── modC.pb.go │ └── component3 │ └── modC.pb.go ├── proto │ ├── modA.proto │ ├── modB.proto │ ├── modC.proto │ └── modD.proto └── taskfile └── protoc ├── Dockerfile ├── docker-compose.yml └── Taskfile.yml Taskfile.yml 内ではコンポーネント毎のタスクから .pb.go を生成する共通タスクを呼び出すような構成にしました。 version: 3 tasks: generate: summary: | パラメータを受け取って .pb.go の生成を行います dir: '{{.USER_WORKING_DIR}}' cmd: protoc -I=../proto --go_out=. ${PROTO_FILES} component1: desc: component1 に必要なパラメータを設定して generate を呼び出し .pb.go を生成します vars: # コンポーネントのディレクトリを指定します WORKING_DIR: /path/to/component1 # 作成対象の proto ファイルのリストを指定します PROTO_FILES: - ./modA.proto - ./modB.proto - ./modC.proto # .pb.go ファイルを作成するコンテナで生成処理を実行します cmd: | docker compose run -T --rm -w {{.WORKING_DIR}} \ -e PROTO_FILES="$(echo {{.PROTO_FILES}} | tr -d '[]')" \ protoc task generate component2: desc: component2 に必要なパラメータを設定して generate を呼び出し .pb.go を生成します vars: WORKING_DIR: /path/to/component2 PROTO_FILES: - ./modB.proto - ./modC.proto cmd: docker compose run -T --rm -w {{.WORKING_DIR}} -e PROTO_FILES="$(echo {{.PROTO_FILES}} | tr -d '[]')" protoc task generate component3: desc: component3 に必要なパラメータを設定して generate を呼び出し .pb.go を生成します vars: WORKING_DIR: /path/to/component3 PROTO_FILES: - ./modC.proto cmd: docker compose run -T --rm -w {{.WORKING_DIR}} -e PROTO_FILES="$(echo {{.PROTO_FILES}} | tr -d '[]')" protoc task generate タスクの概要です。 generate 環境変数で受け取ったファイルパスを元に .pg.go ファイルを生成します。 component1,2,3 各コンポーネント毎のタスクで依存関係のあるファイルを定義しておき、コンテナの実行時に環境変数として渡すようにしています。 これでバージョン情報が差分として検出されることがなくなりました。 ですが、追加でカスタムタグを埋め込みたいという要件が発生しました。 ver 3.0 プラグインの対応 機能の追加で .pb.go の定義に xml タグとの関連付けをする必要性が出てきました。 go で実装する場合は構造体の定義にタグを付けることでマッピングできますが、protoc の機能ではサポートされていませんでした。 そのため、protoc で .pb.go ファイルを作成した後に protoc-go-inject-tag のプラグインを使ってタグを埋め込むことにしました。 version: 3 tasks: generate: summary: | Generate .pb.go files from .proto files called by each component. environment variables: - INJECT_FILES: List of relative paths to .pb.go files that need to inject object tags - PROTO_FILES: List of .proto files that need to generate .pb.go files dir: '{{.USER_WORKING_DIR}}' cmds: # .pb.go を生成します - protoc -I=../proto --go_out=. ${PROTO_FILES} # 追加のタグが必要な場合にタグを追加します - cmd: | if [ -n "${INJECT_FILES}" ]; then IFS=' ' for file in ${INJECT_FILES}; do protoc-go-inject-tag -input="${file}" gofmt -w "${file}" done fi component1: desc: component1 に必要な .pb.go を生成します vars: # コンポーネントのディレクトリを指定します WORKING_DIR: /path/to/component1 # タグの追加が必要な .pb.go を指定します INJECT_FILES: - ./modA.pb.go # 作成対象の proto ファイルのリストを指定します PROTO_FILES: - ./modA.proto - ./modB.proto - ./modC.proto # .pb.go ファイルを作成するコンテナで生成処理を実行します cmd: | docker compose run -T --rm -w {{.WORKING_DIR}} \ -e PROTO_FILES="$(echo {{.PROTO_FILES}} | tr -d '[]')" \ -e INJECT_FILES="$(echo {{.INJECT_FILES}} | tr -d '[]')" \ protoc task generate # component2: は修正なし # component3: は修正なし これで必要に応じて .pg.go にカスタムタグを付与できるようになりました。 また、各コンポーネントのタスクはコンテナを呼び出す形式のため、 proto のパスなのか inject のパスなのか区別して渡すことができました。 当初はタスクから直接別のタスクを呼び出すやり方を調べていたため苦戦していました。 おまけ: peco で task コマンドのフィルタリング Taskfile は便利な反面、定義が増えると必要なものが見つけにくくなります。 実際にメンバーからそういった意見が上がったため peco を使ってフィルタリングできるように検証をしています。 cmd=$(task -l | grep '*' | peco | awk '{print $2}' | sed "s/:$//") if [ "$cmd" != "" ]; then task $cmd fi コマンドの内容は以下になります task -l | grep '*' タスク一覧からヘッダを除外して取得しています。 | peco タスク一覧から1行を選択します。タスク定義や description に含まれる文字でフィルタリングができます。 | awk '{print $2}' | sed "s/:$//" task コマンドで実行できるようにタスク名を取得しています。 終わりに proto ファイルの生成を taskfile にまとめることでコンポーネントごとの依存関係が明確になったり、作業者ごとの環境の差分を吸収できるようになりました。 手作業でやるには間違いが発生しそうな作業をまとめておくのに taskfile はとても便利ですね。 ただし、taskfile の修正、作成が職人芸にならないよう管理していく必要がありそうです。 スタンバイでは、常に新しいアイデアや技術を調査し、試しています。新しいことに挑戦したい方や、素晴らしいプラットフォームで素晴らしい仲間と仕事をしたい方は、ぜひ 採用ページ をご覧ください！ スタンバイのプロダクトや組織について詳しく知りたい方は、お気軽にご相談ください。 www.wantedly.com