本ブログは、キヤノンIT ソリューションズ株式会社様と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクト木村、アカウントマネージャーの池田です。 本記事では、キヤノン IT ソリューションズ株式会社様が 、Amazon Q Developer を開発現場に導入し、3 か月間効果検証を実施した取り組みをご紹介します。コード生成やレビュー支援による効率化、現場での活用事例、そして検証から得られた知見について詳しく解説します。 なお、本ブログに登場する Amazon Q Developer は 2026 年 4 月 30 日に AI 駆動開発IDE「Kiro」へと進化的に統合されることが発表されています 。 本検証で培ったAI駆動開発のプラクティスやノウハウは、Kiro の仕様駆動開発（Spec-driven Development）へとそのまま活かせるものであり、キヤノン IT ソリューションズ様 の取り組みはまさにこの進化を先取りしたものと言えます。 背景/課題 キヤノンITソリューションズ株式会社様(以下、キヤノン ITS )では、生成 AI ツールの社内推進活動を積極的に実施しています。今後 SIer としての競争力を維持していくために、生成 AI の活用は不可欠です。しかし、個人レベルでの試行には限界があるため、企業として活用のための基盤整備や推進を進める必要がありました。 そこでキヤノン ITS 様は、2024年に「生成 AI ビジネス検討委員会」を立ち上げて、生成 AI ビジネスにおける 5 年後のありたい姿と戦略を策定し、その具体的な施策を推進するための「生成 AI ビジネス推進室」を発足。社内の利用ガイドラインの整備、生成 AI ツールの全社的な導入を推進してきました。 生成 AI ツールの導入後に現場への定着をいかに進めるかは、多くの企業にとって共通の課題です。キヤノン ITS 様は全社横断向けの複数回に渡るイベント形式で「AI 駆動開発の普及」を行うことで、より深い活用推進を実施しました。 なぜ Amazon Q Developer を選択したのか(導入当時) 全社利用が可能な生成 AI ツールは導入済みではありましたが、「AI 駆動開発の普及」という目的に対し、コスト・運用・性能のバランスに優れた選択肢であることから Amazon Q Developer を選択しました。 コスト: 月額ユーザー数の固定料金で予算計画が容易 同機能の固定費用で使えるサービスとしては最も安価 運用: 既存の AWS 環境（情報システム部門の管轄）でアカウント管理可能 AWS から導入・普及の支援を受けることができる 性能: Claude Sonnet 4（実施当時）による高精度の生成 MCP 対応による拡張性の高さ セキュリティ・脆弱性診断、モダナイゼーションなど SI に役立つ機能搭載 AI駆動開発の普及をする上での工夫ポイント 本施策が単なるツール導入だけで終わらぬよう、事前に懸念事項を洗い出し、キヤノン ITS 様と AWS にて、役割分担を行い施策設計をしました。 懸念事項 Amazon Q Developerのリリース・キックオフがなされただけで、ツールが使われない 事業部側での予算制限があり、積極利用がなされない ツールの認知はされているが、使い方が分からずに利用がされない AI駆動開発の取組自体が限られた少数のメンバーにしか知られない 対策 オペレーション整備 ツールを使ってもらえるような申請フローの整備（キヤノン ITS） 興味喚起 「このツールは面白い」と思ってもらえるイベント。継続するための仕掛けづくり（AWS） 障壁排除 ハンズオン/定期的なオフィスアワーを行うことで技術的な懸念点を払拭（キヤノンITS/AWS） イベント化 打ち上げ花火のようなオンラインイベントで終わらせず、興味喚起、ハンズオン研修、利用者のトラッキングを行いランキング発表等、全社向けの年末までのロードマップを敷いて継続施策として打ち出す（キヤノンITS/AWS） エグゼクティブスポンサー エグゼクティブスポンサーである、金澤社長からの支援と声かけを実施（キヤノンITS） ロードマップ全体像 AI駆動開発の社内展開に向けて、Amazon Q Developer の業務適用検証を実施しました。本取り組みは、9 月 5 日に開催した「AI Agent DAY」をキックオフとし、Amazon Q Developer を実際の業務に適用した際の有効性を約 3 か月間にわたり検証したものです。 キックオフイベントには約 250 名が参加し、100 名以上の技術者が Amazon Q Developer のハンズオンを体験しました。その後の業務適用検証フェーズでは、生成 AI ビジネス推進室がツール利用費を負担する形で施策を企画し、57 名が参加しています。検証期間中は、インフラおよびアプリケーションを対象としたハンズオンセッションやオフィスアワー、中間イベントを実施しました。あわせて、Teams 上の「生成 AI 交流広場」での情報共有やアンケートを通じた成果の可視化にも取り組んでいます。 最終的には、技術者向けイベント「CITS Day 2025」において、Amazon Q Developer を効果的に活用した取り組みを表彰しています。なお、表彰対象検討のための利用状況のデータ分析においても、Amazon Q Developer を活用しました。 Amazon Q Developer の利用状況を示すダッシュボード Amazon Q Developer へ利用率ランキングを集計するプロンプト CITS Day 2025 での表彰 活用事例 CITS Dayのイベント内では、複数の事例が共有されました。 事例1: 開発ツール×生成AI（佐野様の発表） 抱えていた課題 プログラミングの抽象化レイヤーの進化と開発ツールの変化への対応 開発業務の効率化と生産性向上 資料作成やアイデア整理などのコーディング以外の作業の効率化 導入した理由・きっかけ 新しい開発スタイルで「速さ」「安全性」「柔軟性」を実現するため Kiro との出会い（2024年夏）がきっかけ 生成 AI の柔軟性を活かしつつ、課題（コード品質のばらつき、非機能要件への対応不足など）を解決するため 導入して得られた結果 バイブコーディングモードを活用することで、マークダウン形式で効率的に資料作成が可能に レイアウト案をアスキーアートで事前確認するなど、視覚的な提示が可能に 仕様駆動開発モードではプロトタイプの迅速な作成が実現 バーコードスキャナーアプリの要件からタスク分解、実装まで効率的に進行 事例2: PoCでのAmazon Q Developer活用（可知様の発表） 抱えていた課題 SNS バズ検知を需給マネジメントに繋げるための PoC を短期間・低コストで実施 SNS API や可視化技術など、未経験の技術を習得して実装 技術検証フェーズに時間やコストをかけられない 導入した理由・きっかけ 社内からの提案で、生成 AI の活用が適した題材と判断 低コスト（$19/月）で社内環境も整備されていたため 短期間での技術獲得とプロトタイプ開発、生成 AI 活用のノウハウ獲得を目指して導入 導入して得られた結果 新規技術（SNS API 活用技術、Streamlit によるアプリ開発技術）の習得が迅速に進んだ 開発スピードが約 3 倍に向上（通常 2 週間かかる作業が 3 日で完了） コスト削減（10 人日 → 3 人日＋$19の料金のみ、約 1/3 のコスト） 事例3: Amazon Q Developerを使用したインフラ構築（谷様の発表） 抱えていた課題 インフラ構築業務での効率化とエラー削減 Terraform の定義言語 HCL の習得や適切なコーディングの必要性 インフラコード化（IaC）におけるコードレビューと品質確保 導入した理由・きっかけ インフラ構築業務の流れが「パラメーター設計 → コード生成 → デプロイ → テスト」に変わる中で効率化を図るため コード生成からドライテスト、デプロイまでのプロセスを改善するため Claude Sonnet 4.5 が API 課金ではなく使える点が魅力的だった 導入して得られた結果 パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能に AI によるコードレビューが人間のレビューを補完し、エラー検出が向上 validate、plan、apply の各段階でのエラー検出と修正が効率化 事例4: 仕様駆動開発の手引き（古川様の発表） 抱えていた課題 「仕様が主、実装が従」という本来あるべき開発の構図が逆転しがち 仕様書の陳腐化や実装との乖離の発生 vibe coding は業務で活用するには曖昧すぎる 導入した理由・きっかけ 自分で設計して自分で実装するケースが多く、生成 AI 導入の恩恵が大きいと考えたため 他の生成 AI ツールと Amazon Q Developer の比較検討を自分自身でやってみたかったため 仕様駆動開発が開発手法として確立しつつあり、業務に適用してみたかったため 導入して得られた結果 ルール制定 → README記述 → 設計書作成 → TODOリスト作成 → 実装という流れで社内用の小規模なツールを効率的に開発できた AI が設計図やタスク分解などを自動化し、人間はレビューと意図合わせに集中できる 仕様駆動開発の考え方を取り入れることで、開発の最初に充実したドキュメントを作れるようになった 事例5: Amazon Q Developer 活用事例紹介（鈴木様の発表） 抱えていた課題 製品機能設計に向けて AI エージェント技術の理解と実験環境構築が必要だった AgentCore や CloudFormation など、大量コードの読解や IaC 化の負荷が高い 新しい技術領域で情報が少なく、定義ミスやドキュメント解釈間違いが発生しやすい 導入した理由・きっかけ Amazon Bedrock AgentCore を使った機能検討のため、AI エージェントの仕組み理解と環境構築を効率化したかった GitHub の AgentCore サンプルを活用する中で、Q を使えばコード理解・修正・IaC 化まで一気に進められると判断 大量コードの理解、React アプリ実装など AI に向いている作業が多かったため Q 活用を決断 導入して得られた結果 AgentCore + Knowledge MCP + CloudFormation による再利用可能なAIエージェント実験環境を構築 React チャットアプリやブラウザ動作確認まで実装〜テストの大部分を Q が自動化 Rules 整備やレビューを通じて、Q を“正解を出す AI ”ではなく“協働する相棒”として運用する体制を確立 Try & Error の混乱を Git コミットや TODO 管理で整理し、AI と協働できる実践的な開発フローを確立 定量的な成果 3か月間の業務適用検証期間において、Amazon Q Developerを利用した取組は以下の定量的な成果を達成しました。 コード生成・開発効率 開発スピード 3 倍向上: 通常 2 週間かかる PoC 開発が 3 日で完了 工数削減 67%: 10 人日から 3 人日へ削減、コストは約 1/3 に コード生成数: 検証期間中、57 名の参加者が累計で数千行のコード生成を実施 レビュー・品質向上 レビュー時間短縮: AIによるコードレビュー支援により、人間のレビュー工数を削減しつつエラー検出精度が向上 エラー早期発見: validate、plan、apply の各段階でのエラー検出が効率化され、手戻りコストを削減 継続利用 参加率 95% : 募集定員 60 名に対し 57 名が参加し継続して利用 アクティブ利用: 検証期間中、定期的なオフィスアワーやTeams「生成AI交流広場」での活発な情報交換を実施 イベント参加: キックオフイベントに 250 名、ハンズオンに 100 名以上が参加 定性的なフィードバック（利用者の声） 検証期間中のアンケートやCITS Day 2025での発表から、以下のような利用者の声が得られました。 「SNS API や Streamlit など、未経験の技術を短期間で習得できた。新規技術獲得へのハードルが大幅に下がった」 「PoC の進め方が大きく変わることを実感。人は課題抽出やロジック検討、結果確認に注力できるようになった」 「生成 AI と開発の構造を組み合わせることで、柔軟性・速さと品質・一貫性の両立が可能になった」 「仕様書を起点に、AI エージェントに任せながら効率的に開発できる。仕様駆動開発が現実的な選択肢になった」 「パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能になり、インフラ構築業務が大幅に効率化された」 検証の総括 キヤノンITS 様は、生成 AI ビジネス推進室を中心に Amazon Q Developer の展開を推進し、3 か月間の業務適用検証を通じて組織的な AI 駆動開発の定着を実現しました。エグゼクティブスポンサーの支援と予算負担の工夫により現場の参加障壁を排除し、専用 Teams チャネルでのコミュニティ形成、定期的なオフィスアワー、実践的なハンズオンセッションという段階的な学習支援を提供しました。 検証期間中、57 名の技術者が実務で Amazon Q Developer を活用し、開発スピード 3 倍向上、工数 67 %削減という具体的な定量効果を達成。Amazon Q Developer 自身で作成したダッシュボードにより利用状況を可視化し、CITS Day 2025 での表彰制度により 5 つの優秀事例を全社で共有しました。 成功の鍵は、生成AIビジネス推進室の設立による組織的な推進体制、単発イベントで終わらせない年間ロードマップに基づく継続的な支援施策、そして実ビジネスでの活用という 3 つの要素にあります。キックオフから始まり、ハンズオン、中間イベント、表彰へと続く一連の取り組みにより、SNS バズ検知システムなど実際の PoC 案件での成果を創出し、新規技術習得の加速、PoC プロセスの変革、インフラ構築の効率化など、多様な領域での効果を実証しました。 キヤノンITS 様からAmazon Web Services Japanへの期待 今回の取り組みを通じて、Amazon Q Developer を開発現場の生産性向上に有効活用できることが実感できました。PoC からインフラ構築、既存システムの改善まで、多様な領域で活用の可能性が広がっています。 今後は、今回の検証で得られた知見をもとに、社内での活用パターンの整理やナレッジの共有を進め、より多くのプロジェクトで生成AIを活かせる環境づくりを進めていきます。また、Amazon Web Services Japan 様と連携しながら、新機能の検証や他サービスとの組み合わせなど、さらなる活用領域の拡大にも取り組んでいく予定です。 生成AI が IT ライフサイクル全般の在り方を大きく変えつつある中、私たちは、現場の開発体験を改善するとともに、社会やお客様へ更なる価値提供に向けて積極的に活用していくための取り組みを継続して進めていきます。 執筆者 キヤノンITソリューションズ株式会社 生成AIビジネス推進室 石堂 きよみ Amazon Web Services Japan ハイテク&ヘルスケア事業本部 アカウントマネージャー Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)

はじめに 「監視モニタリングのIaCとか机上の空論だろ。労力とリターンが見合わんわ」 …と思っていた時期が私にもありました（慣用句） 前回の記事 でも少し触れましたが、 AIエージェントの登場によってDatadog × Terraformのような監視モニタリングのIaCの実践が劇的に楽になり 、気づけば手動でポチポチとモニタリングの設定をする運用の方が限りなく非効率になってしまいました。 AIエージェントをどう利用するかという部分は、まだまだ過渡期であり皆さま試行錯誤中ではあると思いますが、 弊社SREチームではAIエージェントを活用し 、 モニタリング対象の飛躍的な拡充 、 モニタリングコード品質の大幅な改善 、 運用負荷の劇的な軽減 を実現できました。そこで、どのような取り組みを行い、これを実現したかを紹介したいと思います。 ※ 本記事で扱うのはDatadog × Terraform での実践内容となります 前回の記事はこちら tech.mntsq.co.jp はじめに これまで: 監視モニタリングのIaCは重い課題だった AIエージェントの登場で何が変わったか 実装はブラックボックスで良い 規約によって品質を揃える 監視モニタリングIaCの実践例 コードを最小に保つ多層構成 実装サンプル 弊社で運用している監視モニタリングの規模 おわりに これまで: 監視モニタリングのIaCは重い課題だった 一般的にSaaSを運営している開発組織では、本番環境のみではなくステージング環境、開発環境など複数の環境を管理しています。モニタリングを真面目にやろうとすると、 「環境数 × 対象」でモニタやダッシュボードが乗算的に増えていく ため、手動で管理はほぼ不可能に近いです。（頑張って作ったとしても、細かな変更を全体に反映できず、結局保守はできない） 弊社の場合、ダッシュボードは本当に重要な対象に絞って本番環境だけで整備、モニタはマルチアラートを利用して数を減らすなどの工夫で凌いでいましたが、やはり保守の手間はなかなか重いものでした。 「じゃあコード管理すれば良いのでは？」と思うかもしれませんが...... Fargate用ダッシュボード CPU、メモリ、エフェメラルストレージのウィジェットを記載するコードの一部 # ── Fargate サービスのメトリクスウィジェット ── fargate_widgets = { for svc in var.services : svc.ecs_service => [ # CPU使用率 { definition = { title = "CPU使用率(%, コンテナ単位)" title_size = "16" title_align = "left" show_legend = true legend_layout = "auto" legend_columns = [ "avg" , "min" , "max" , "value" , "sum" ] type = "timeseries" requests = [{ formulas = [{ formula = "query1 / query2 * 100" }] queries = [ { name = "query1" data_source = "metrics" query = "avg:container.cpu.usage{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } ,$ { local.container_filter [ svc.ecs_service ]} } by {task_arn}" } , { name = "query2" data_source = "metrics" query = "avg:container.cpu.limit{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } ,$ { local.container_filter [ svc.ecs_service ]} } by {task_arn}" } ] response_format = "timeseries" style = { palette = "dog_classic" order_by = "values" line_type = "solid" line_width = "normal" } display_type = "line" }] } layout = { x = 0 , y = 2 , width = local.widget_width, height = 3 } } , # メモリ使用率 { definition = { title = "メモリ使用率(%, コンテナ単位)" title_size = "16" title_align = "left" show_legend = true legend_layout = "auto" legend_columns = [ "avg" , "min" , "max" , "value" , "sum" ] type = "timeseries" requests = [{ formulas = [{ formula = "query1 / query2 * 100" number_format = { unit = { type = "canonical_unit" unit_name = "percent" } } }] queries = [ { name = "query1" data_source = "metrics" query = "max:container.memory.usage{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } ,$ { local.container_filter [ svc.ecs_service ]} } by {task_arn}" } , { name = "query2" data_source = "metrics" query = "max:container.memory.limit{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } ,$ { local.container_filter [ svc.ecs_service ]} } by {task_arn}" } ] response_format = "timeseries" style = { palette = "dog_classic" order_by = "values" line_type = "solid" line_width = "normal" } display_type = "line" }] } layout = { x = 0 , y = 5 , width = local.widget_width, height = 3 } } , # エフェメラルストレージ { definition = { title = "エフェメラルストレージ空き領域(%)" title_size = "16" title_align = "left" show_legend = true legend_layout = "auto" legend_columns = [ "avg" , "min" , "max" , "value" , "sum" ] type = "timeseries" requests = [{ formulas = [{ formula = "(query2 - query1) / query2 * 100" }] queries = [ { name = "query2" data_source = "metrics" query = "max:ecs.fargate.ephemeral_storage.reserved{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } } by {task_arn}" } , { name = "query1" data_source = "metrics" query = "max:ecs.fargate.ephemeral_storage.utilized{$ { local.service_tag [ svc.ecs_service ]} :$ { svc.ecs_service } } by {task_arn}" } ] response_format = "timeseries" style = { palette = "dog_classic" order_by = "values" line_type = "solid" line_width = "normal" } display_type = "line" }] } layout = { x = 0 , y = 8 , width = local.widget_width, height = 3 } } ] if !svc.is_ec2 } これは流石に無理では......？何かを追加したくなる度に、どのように宣言すれば良いかを調べ、↑のようなコードを書かなければいけないわけです。少なくとも私はダッシュボードを1つ作成する前にPCを叩き割る自信があります。 そもそも IaCは宣言的な記述が求められる故に常に一定の学習コストがかかり 、自分が得意とする領域か、やらないことが許されない状況（プロダクトのインフラとか）でもない限りなかなか実践できないというのが現状だったのではないでしょうか。少なくとも、監視モニタリング領域でIaCを実践するのは、確保できる工数と照らし合わせると、不可能に近いというのが、弊社の実態でした。 AIエージェントの登場で何が変わったか ここに大きな転機が来ました。 冗長なコードを人間が理解する必要がなくなった のです。 実装はブラックボックスで良い これまでなら、新しい監視をひとつ足すたびに次のような作業が必要でした。 Datadog provider の最新仕様を確認する 似たような既存モニタの実装を探してコピーし、差分を埋めていく メトリクスのタグ表記（ env: / service: / container_name: など、起動形態で違う）を調べる メッセージのテンプレート構文（ {{#is_alert}} 等）を思い出す・調べる これらを、エージェントが規約と既存コードを参照しながら、ものの数十秒でこなします。人間は「ECS タスクの CPU が 100% に張り付いたら検知したい」「RDS Serverless v2 の ACU 使用率が高騰したらアラートを送ってほしい」と指示を出すだけでよく、そのまま PR にできるレベルの成果物が出てきます。 ここで重要なのは、 実装をブラックボックスのまま受け入れて構わない ということです。 関心があるのは見たいデータが正しく取れているかのみ です。それを確認できれば、生成されたコードは読む必要がないし、覚えない。それぞれが独立している故に、挙動がおかしければ捨てて作り直せばよく、それでも GUI でポチポチ作るより圧倒的に速い。「書く頻度が低くて、毎回仕様を忘れる」性質を持つ監視モニタリングコードと、この使い方は非常に相性がよいです。 これまで「IaC 化したいが、書く労力に見合うリターンが見えない」という理由で諦めていた領域に、はじめて手を出せるようになりました。 規約によって品質を揃える とはいえ、ブラックボックスを丸ごと信用すると品質がブレるリスクは当然あります。命名がバラつき、通知先がバラつき、タグ付けがバラつくと、運用負荷はむしろ増えてしまう。 弊社ではClaudeCodeを使用しているので、これを避けるためにコーディングの規約を .claude/rules/ 配下に書き溜めています。Datadog 関連では、たとえば以下のようなルールを明文化してあり、エージェントは生成時にこれらを参照します。 モニタ・ダッシュボード名は 🤖 プレフィックスで Terraform 管理であることを示す Slack チャンネル・メンションは locals.tf で集中管理し、モジュール側は変数経由で参照のみ メトリクスのタグには env:<env> を必ず入れ、全環境平均を見てしまうミスを防ぐ 新しい AWS メトリクスを使うときは、CloudWatch Metric Stream の送信対象フィルタも更新する これに加えて、 .claude/rules/datadog-monitors.md には「シンプルアラートとマルチアラートの違い」「 renotify_interval の標準値」「環境フィルタ漏れの典型ミス」など、具体的なコードパターンまで載せてあります。 結果として、誰が、あるいはどのエージェントが書いても、ほぼ同じ形のコードが出てきます。レビュアは「規約からの逸脱がないか」だけを確認すればよく、レビュー労力もかなり下がりました。 コードはブラックボックスにしつつ、規約は人間が育てる 、という分担です。 規約の一部抜粋 規約の一部です。全体ではサンプルコードを含む記述を400行くらい書いてます # .claude/rules/datadog-monitors.md --- paths: - "terraform/aws/services/datadog/monitors_*.tf" - "terraform/aws/services/datadog/modules/monitors/**" - "terraform/aws/services/datadog/*.tf" --- # Datadog Monitor 作成ガイド ## アーキテクチャ概要 モニターは以下の 3 層構造で実装する: 1 . **呼び出し層**: `terraform/aws/services/datadog/monitors_<監視対象>.tf` - 監視対象リソースの一覧を `locals` で定義 - `for_each` で環境 × リソースの組み合わせごとにモジュールを呼び出す 2 . **モジュール層**: `terraform/aws/services/datadog/modules/monitors/<monitor_name>/` - `main.tf` にモニターの実体（`datadog_monitor` リソース）を定義 - `variables.tf` にモジュールの入力変数を定義 3 . **共通設定**: `terraform/aws/services/datadog/locals.tf` - `slack_channel`, `error_channel`, `mention` 等 ## ファイル配置 ``` terraform/aws/services/datadog/ ├── monitors_<監視対象>.tf # 呼び出し層 ├── modules/monitors/<monitor_name>/ │ ├── main.tf # モニター実体 │ └── variables.tf # 入力変数 ├── locals.tf # 共通設定（slack_channel, mention等） ├── variables.tf # サービスモジュールの入力変数 └── provider.tf # プロバイダ設定 ``` ## モニター名の規約 - 必ず `🤖` プレフィックスを付ける（Terraform管理であることを示す） - 環境名は **Terraform変数 `var.env`** で埋め込む: `🤖 【$ { var.env } 】...` - 旧: `【 {{ env.name }} 】`（Datadogテンプレート変数）→ 廃止 - 新: `【$ { var.env } 】`（Terraform変数、for_eachで環境ごとに生成するため） - **Datadogテンプレート変数（` {{ xxx.name }} `）をモニター名・メッセージに使わない** - 環境名、リソース名等はすべてTerraform変数（`var.env`, `var.display_name` 等）で埋め込む - Datadogテンプレート変数はモニター一覧画面では未展開のまま表示されるため視認性が悪い - 例外: ` {{ value }} `（アラート発火時の値）や ` {{ #is_alert}}` 等の条件分岐は引き続き使用する ## Slackチャンネル / メンションの使い方 `locals.tf` で定義された変数をモジュールに渡して使う: ```hcl # Slackチャンネル（重要度別） local.slack_channel.info # 情報レベル local.slack_channel.warning # 警告レベル local.slack_channel.alert # 緊急レベル # エラー通知チャンネル（環境別） local.error_channel [ env ] # 環境ごとのエラー通知先 # メンション（チーム別） local.mention.sre # SREチーム local.mention.swe # SWEチーム local.mention.eng # エンジニア全体 local.mention.cre # CREチーム local.mention.algo # アルゴチーム local.mention.ai_agent # AI Agentチーム ``` --- <以下省略> --- 監視モニタリングIaCの実践例 具体的に弊社がどのようなコード構成をとっているかも軽く紹介しておきます。 コードを最小に保つ多層構成 Datadog 関連リソースは、以下の 3 層で管理しています。 envs/<env>/datadog/datadog.tf ← ① 環境呼び出し層 │ ▼ services/datadog/ ← ② サービスラッパー層（module） ├─ monitors_<対象>.tf （locals + for_each で展開） └─ dashboard_<対象>.tf │ ▼ services/datadog/modules/ ← ③ モジュール層（sub module） ├─ monitors/<name> （datadog_monitor の実体） └─ dashboards/<name> （datadog_dashboard_json の実体） 層 役割 ① 環境呼び出し層 環境リストや、プロダクトコードのoutputなどの依存関係を渡してサービスを呼ぶだけ ② サービスラッパー層 監視対象や閾値などの設定差分を列挙しモジュール層に渡す ③ モジュール層 datadog_monitor / datadog_dashboard の実体。「SQSの滞留モニタ」「ECSサービスのダッシュボード」といった、環境やプロダクト毎によらない抽象的なコードを配置する 弊社の場合、Datadogのアカウントは本番用と開発用の2アカウントで運用しているため、①の環境呼び出し層でproduction, stagingなどの複数の環境をまとめてサービスラッパー層に渡しています。 ポイントは ② のラッパー層で、 setproduct関数 を使って「環境 × 監視対象リソース」や「監視対象 × 閾値」などの組み合わせを for_each で展開している点です。こうすることで、例えば新しい環境を足すときは環境リストに 1 行、新しい監視対象を足すときも locals に 1 行といった具合に、 追加コストが "リスト 1 行" にまで圧縮されている のがこの構成の効きどころです。AIエージェントによる生成とも非常に噛み合います。 実装サンプル ③モジュール層、②サービスラッパー層の実装サンプルはこんな感じです。 ③SQSのDLQにメッセージが落ちてきたことを知らせる抽象モニタ # ~/modules/monitors/sqs_dlq/main.tf locals { doc_link_line = var.doc_link != "" ? "\n[こちらの手順]($ { var.doc_link } )を参考に対処してください。" : "" } resource "datadog_monitor" "main" { name = "🤖 【$ { var.env } 】$ { var.service_display_name } SQS DLQ $ { var.display_name } にメッセージが見つかりました" type = "query alert" query = "min(last_5m):min:aws.sqs.approximate_number_of_messages_visible{queuename:$ { var.env } -$ { var.queue_name } ,env:$ { var.env } } > 0" message = <<EOT $ { var.slack_channel.alert } $ { var.mention.sre } $ { var.mention_team } {{ #is_alert}} $ { var.env } 環境の $ { var.service_display_name } SQS DLQ $ { var.display_name } にメッセージが入りました。 ワーカーの処理に失敗したメッセージが存在している可能性があります。$ { local.doc_link_line } メッセージ数: {{ value }} メッセージ {{ /is_alert }} {{ #is_recovery}} $ { var.env } 環境の $ { var.service_display_name } SQS DLQ $ { var.display_name } からメッセージが削除されました。 DLQへの失敗メッセージへの対応が完了しました。 {{ /is_recovery }} EOT monitor_thresholds { critical = 0 } on_missing_data = "show_no_data" require_full_window = false renotify_interval = 120 renotify_statuses = [ "alert" ] tags = [ "service:$ { var.service_tag } " , "env:$ { var.env } " , "managed_by:terraform" , ] } ②DLQモニタに「CLM」というプロダクトのSQSを設定を渡すラッパー層 # ~/services/datadog/monitor_clm_sqs_dlq.tf # CLM SQS DLQモニター # DLQにメッセージが落ちてきた時にアラートを発する # 環境 × キューごとにモニターを生成する # キュー定義は locals_clm_sqs.tf の local.clm_sqs_queues から導出 module "monitor_clm_sqs_dlq" { for_each = { for pair in setproduct (var.dashboard_envs, local.clm_sqs_queues) : "$ { pair [ 0 ]} -$ { pair [ 1 ] .display_name } " => { env = pair [ 0 ] queue_name = "$ { pair [ 1 ] .queue_name } -dlq" display_name = pair [ 1 ] .display_name } } source = "./modules/monitors/sqs_dlq" env = each.value.env queue_name = each.value.queue_name display_name = each.value.display_name service_display_name = "CLM" service_tag = "clm" mention_team = local.mention.clm doc_link = "<対応手順書のURL>" slack_channel = local.slack_channel mention = local.mention } # ~/services/datadog/locals_clm_sqs.tf locals { # CLM SQSキュー定義（環境プレフィックスなし） # listを使用して定義順序を保持 clm_sqs_queues = [ { queue_name = "clm-default-app-job-worker-sqs-critical" display_name = "critical" } , # 取り扱うキューを列挙する。ここでは省略 ] } ②のコードはあくまで「CLM」という特定のプロダクトのDLQモニタを定義するものです。別のプロダクトの監視を行いたいときは、②のコードを別途作成します。③のコードは再利用可能です。 このように抽象化を行うことによって、コードを最小にして多数のモニタを管理することが可能になります。そして実装部分はAIエージェントに丸投げしてしまえば、 少ない運用工数 で、 多数のモニタリング対象 を、 高品質なコード で管理できる わけです。 弊社で運用している監視モニタリングの規模 2026/05/20現在の規模感は以下のとおりです。 項目 数 対象環境 8 環境 モニター種別 / 生成されるモニター数 30 種類 / 約 800 個 ダッシュボード種別 / 生成されるダッシュボード数 7 種類 / 約 80 個 ラッパー＋モジュール層のコード行数 約 1 万行 おおざっぱに 1 万行で 800 のモニタと 80 のダッシュボードを支えている 計算です。 先に述べたように、実装規約を整備したおかげで誰でも気軽に対象の追加ができるようになり、現在でも日々監視モニタリングは充実していっています。 おわりに 本記事執筆のきっかけは、AIエージェントの登場による監視モニタリングIaCの変化は、 単に"運用が楽になった" だけの話ではない と感じたためです。 これまでは「重要なものだけ厳選して監視するのが限界」と言わざるを得ませんでした。リソースを増やすほど管理コストが増えるため、観測対象は常に「これは本当に必要か」というフィルタを通って絞り込まれていたわけです。 それが、追加コストがほぼ無視できるほど軽くなった瞬間、 「観測したいものは全部観測する」というスタンスに振り切れる ようになりました。新しいワーカーを足したら CPU・メモリ・レイテンシのアラートを同時に足し、新しい SQS キューを切ったら滞留と DLQ のモニタも足し、新しい RDS クラスタを建てたらスロークエリやコネクション数のダッシュボードも足す ── これらが開発フローの中で容易に実現できるようになります。 開発組織全体への良い影響もあります。 新機能リリース時に「とりあえずダッシュボードはある」状態が標準 になり、初動の異常検知が早くなります。モニタを足すコストも軽いため、開発者が「この指標を見たい」と SRE に相談する敷居も下がる、あるいは開発者自身がダッシュボードやモニタを追加することも今後可能となっていくはずです。 モニタリングは「保険」のように扱われがちで、潤沢な工数を割きづらい領域です。だからこそ、 コストを劇的に下げてくれる手段が出てきたなら、観測の "深さ" そのものを変えにいくべきでしょう。 MNTSQ株式会社 SRE 西室

Hello, everyone! I’m Xin Wei, working as an SRE here at ONE CAREER. It’s already been a whole year since I joined the company as a new grad in April 2025! Time really flies! I did a short interview for this tech blog when I was in my third month, but today, I want to use my own words to look back on this amazing year. I’ll share the challenges I’ve overcome and how much I’ve grown as an engineer. Today, I’m super excited to share what ONE CAREER's culture really looks like through the eyes of a first-year SRE!