現在、FinOps プラクティショナーは増え続ける AI ツール群を利用できるようになりました。しかし、それぞれのユースケースに適したツールを組み合わせることこそが、プラクティスを加速させるか、不要な複雑さを持ち込むかの分かれ目になります。AWS は、AI ラインナップの各ツールを、それぞれ異なるコンテキストと異なる種類の作業に向けて設計しています。このブログでは、5 つのツールについての実践的な整理、それぞれをいつ使うべきか、そしてなぜそれが FinOps にとって重要なのかを説明します。 ここで重要なのは、ある仕事をこなせるツールと、専用のツールとの間には意味のある違いがあるという点です。 AWS FinOps Agent は、Cost Optimization Hub および AWS のコストと使用状況データとのネイティブなインテグレーションを備えたフルマネージドソリューションであり、精選され、検証されたインサイトを提供します。このブログで説明されている他のアプローチは、追加の設定やデータ接続が必要であり、マネージドソリューションが持つ深さ、精度、運用面での即応性には及ばない場合があります。最適な選択肢を選ぶ際には、これらのトレードオフを自社の要件と照らし合わせて評価することが重要です。 FinOps プラクティショナーはどのような AI ツールを利用できるか？ AWS FinOps Agent Amazon Quick Kiro Amazon Q （In Console） AWS DevOps Agent それぞれのツールについて、その中核となる目的と理想的なユースケースを見ていきます。 AWS FinOps Agent AWS FinOps Agent とは：コスト異常を根本原因まで調査し、組織全体のコストに関する質問に答え、すでに使用している Jira や Slack などのツール上に直接インサイトを届ける、エージェント型 AI ソリューション（現在パブリックプレビュー中）です。 FinOps Agent をいつ使うのか： コスト異常調査： コストのスパイクを関連付けて根本原因と責任者を特定し、オーナーチーム宛の Jira チケットまたは Slack メッセージを作成するのに役立ちます。 自然言語によるコスト問い合わせ： エンジニアが「先月支出が増えたのはなぜですか？」といった質問をして、FinOps チームの関与を必要とせずに、実際の AWS Cost Explore r データに基づいた回答を得られるようにします。 定期的なコストレポート ：ステークホルダーごとに内容を調整したレポートを、そのままプレゼンテーションに使える形式（HTML、PDF、PPT）で、設定したスケジュール（日次／週次／月次）に従って生成します。 最適化の推奨事項 ： AWS Cost Optimization Hub と AWS Compute Optimizer から節約機会を取得し、エンジニアリングチームがすぐに着手できる Jira チケットとしてまとめます。 Amazon Quick Amazon Quick とは：既存のデータソースやツールに接続する、AI を活用したデスクトップおよび Web サイトのコンパニオンです。FinOps にとっての価値は、プラクティショナーがターミナルに触れることもコードを書くこともなく、コストデータ、ダッシュボード、ワークフローに対する会話型のインターフェースを得られる点にあります。 コストデータに接続する方法は 2 つあります。Billing Cost Management MCP (Model Context Protocol) を介して AWS Cost Explorer やその他の請求 API に接続すると、状況に応じたリアルタイムの回答が得られます。一般的なチャットボットの応答ではありません。自社のアカウント、自社のデータ、自社の数値です。あるいは、複数の Payer を持つ組織で Amazon Quick dashboards (CUDOS/CID) を導入している場合は、 Quick Spaces を使用してそこから支出データをクエリできます。CUDOS と組み合わせて Quick を使用する方法については、こちらの ガイド を参照してください。結果が得られたら、それを Slack、メール、その他の ツール に接続して、テキスト、PPT、または必要な形式で関連付けて共有できます。 Quick は、再利用可能なスキル（平易な言葉で記述できる、自動化された多段階のワークフロー）、インタラクティブなアプリ（計算ツール、モデリングツール、数秒で作成できるダッシュボード）、そしてスケジュール実行される監視（毎日のコスト異常ダイジェストを毎朝フィードに配信）をサポートしています。 FinOps で Amazon Quick をいつ使うのか： 「X はいくらかかりますか？」という質問にその場で回答 （料金の確認、サービス比較、影響のモデリング） 複数の Payer をまたいだクエリ： 実際の AWS コストデータに会話形式で問い合わせ（「今月と先月のコスト要因の上位 5 つ」） 手動で掘り下げる代わりに、 Amazon Quick のダッシュボード上の数値について「なぜ」を質問 スキル作成： アカウントのビジネスコンテキストを使用して、チームメイトからのコストに関する質問への回答を自動化 定期的なレポートの自動化： エグゼクティブサマリー、タグ付けコンプライアンス、チャージバックの配分 その場で軽量 アプリ を構築 （Savings Plan の損益分岐点計算ツール、予算バーンレートトラッカー） ステークホルダー向けコミュニケーションのドラフト作成： 責任追及しないコスト通知、エグゼクティブサマリー、トレーニング資料 Kiro Kiro とは：ユーザーと並んで自律的にコードの記述、読み取り、変更を行うエージェント型 IDE です。FinOps にとっての価値は、コーディングを高速化できることだけではありません。何かをデプロイする前に、開発ワークフローにコスト意識を組み込めることです。Kiro は、実装の時点でコストの問題を捉えてシフトレフトすることを支援します。そのために  Kiro Cost Optimization Power  が役立ちます。Kiro Power は、MCP、コストのベストプラクティスを含むステアリングファイル、最適化の機会を自動化するためのフックをまとめたものです。詳細は、動画「 Kiro for Cost Optimization: Agentic AI for FinOps 」をご確認ください。 FinOps で Kiro をいつ使うのか： Infrastructure as Code の構築または変更： Terraform または CDK で構築する際、作業を進めるうちに Kiro が高価なリソースの選択肢にフラグを立て、より安価な代替案（適切なサイズのインスタンス、Graviton、gp2 ではなく gp3）を提案します。 コスト見積もりの生成： Kiro に IaC を分析させ、デプロイ前に毎月の予測コスト内訳を作成してもらうと、計画段階で想定外の出費に気づけます。 Cost Optimization Hub の推奨事項をコードに変える： 推奨事項を取得し、Kiro に変更（インスタンスのサイズ変更、ライフサイクルポリシーの追加、アイドルリソースの削除）をリポジトリへ直接実装させ、レビュー用にプルリクエストを作成させます。 コード全体のリソースに一括タグ付与： ファイルを手動で編集する代わりに、コードベース内のすべてのリソースに一貫したコスト配分タグ付け戦略（コストセンター、プロジェクト、環境）を 1 回で適用できます。 出力がコード、設定、またはデプロイメントアーティファクトであるあらゆる技術的な FinOps タスクの自動化： タグ付けを強制するポリシー、コストガードレールとなるSCP、予算アラーム、または未使用リソース用のスケジュール実行されるクリーンアップスクリプトを作成します。 1 つのプロジェクトについて複数アカウントにまたがるコストをクエリ： Cost Explorer の請求ビューを使用して、支出を 1 つのプロジェクトに絞り込み、Kiro に数値の取得と要約、およびその数値に基づく対応を依頼します。 Amazon Q Amazon Q （in the AWS Console）とは：AWS マネジメントコンソールに直接組み込まれた、生成 AI によるコスト管理アシスタントです。AWS への支出について自然な言葉で質問すると、分析、可視化、実行可能な推奨事項が得られるため、複数のツールを行き来する時間を削減できます。主な利点は、Amazon Q がお客様のアカウント内で動作するため、ワークロードのすべての要素とそれらの相互作用を把握できることです。 FinOps で Amazon Q をいつ使うのか コンソール内での根本原因のコスト調査： 「先週、コストが増えたのはなぜですか？」と聞くと、Q が複数のソースから自律的にデータを収集し、仮説を検証し、変化の背後にある特定のサービス、アカウント、および使用量の要因を特定します。 節約機会の発見： Cost Optimization Hub と Compute Optimizer から、サイズ適正化、アイドルリソース、コミットメントベースの割引に関する推奨事項を 1 つの会話で明らかにします（例：「コスト最適化の機会として上位のものは何ですか？」）。 オンデマンドのコスト見積もり： 「ダブリンの  Amazon Simple Storage Service  (S3) に 1 PB を保管するにはどれくらいの費用がかかりますか？」といった料金と予測に関する質問に答えます。コンソールから離れずに構築前のコストモデリングを行えるため、この機能が役立ちます。 セルフサービスのコスト可視化： Amazon Q が Cost Explorer のフィルターを自動更新できるようになったため、チャートやテーブルなどを動的に作成することも、Cost Explorer 経由で作成することもできます。 AWS DevOps Agent AWS DevOps Agent とは：いつでも対応できるチームメイトとして機能するフロンティア AI エージェントです。本番環境のインシデントを自律的に調査し、オブザーバビリティスタック、デプロイパイプライン、コードリポジトリにまたがるシグナルを相互に関連付けることで根本原因を特定し、将来の問題を防ぐための改善を積極的に推奨します。現在は GA で、2 か月の無料トライアルがあります。DevOps Agent は FinOps にとどまりませんが、スキルとデータへのアクセスを提供することで、コストを意識した状態を保たせることができます。動画「 AWS DevOps Agent for FinOps 」をご確認ください。 FinOps で AWS DevOps Agent をいつ使うのか 自動インシデント調査： CloudWatch のアラームが発生すると、エージェントはすぐに調査を開始できます。そのため手動でのトリアージが不要になり、エージェントがログ、メトリクス、トレース、最近のデプロイを相互に関連付けて、根本原因を数時間ではなく数分で特定します。インフラストラクチャにサイズ適正化の変更を加えている場合は、DevOps Agent に使用状況への影響を監視してもらうことで、問題が起きていないかを確認できます。 ダウンタイムのコスト削減： インシデントを 3〜5 倍速く 解決することで、停止による収益や生産性への影響を軽減できます。これは多くの場合、組織内で追跡されていない最大のクラウドコストです。 インフラストラクチャの推奨事項についてコストを念頭に置く： エージェントは過去のインシデントを毎週分析して改善を提案します。DevOps Agent に、コストも考慮すべき要素であると伝えておけば、最適化された改善案を探し、事後対応型から計画的な最適化作業へと支出をシフトするのに役立ちます。 まとめ：FinOps ペルソナに合った適切なツールを選ぶ それぞれのツールが何をするのかを知ることと、特定の場面でどのツールを使うべきかを知ることは別のことです。下のグリッドは、6 つの FinOps ペルソナ （行）と 5 つの AI ツール（列）をマッピングしています。各セルには、適切なデータ接続を前提として、そのツールで使用するサンプルプロンプトが各ペルソナの視点から書かれています。クイックリファレンスガイドとして活用してください。自分の役割を見つけ、行を横に見ていき、各ツールが日常業務にどのように役立つかを確認しましょう。一部のツールは機能が重複していることに気づくでしょう。どのツールが最適かは、どこで作業しているか、何を作ろうとしているのか、そしてどれだけ深く掘り下げる必要があるのかによって決まります。 ペルソナ別の FinOps AI ツールのプロンプト ペルソナ AWS FinOps Agent Amazon Quick Kiro Amazon Q AWS DevOps Agent FinOps Practitioner 「CRON 自動化を使用して、いずれかのチームの 1 日の支出が 30 日間の移動平均を 25% 超えたら通知してください。根本原因分析を行い、オーナーチーム向けの Jira チケットを作成してください。」Jira インテグレーションが必要です 「フレームワークの進捗状況を追跡するために、タグ付けコンプライアンス、コミットメントカバレッジ率、およびチームレベルの導入指標を含む FinOps 成熟度の概要を作成してください。」 「毎週すべてのアカウントをスキャンし、チームの FinOps 成熟度を評価し、改善アクションプランを生成するタグ付けコンプライアンスの自動化を構築してください。」 「コミットメントカバレッジが最も低く、無駄が最も多いチームはどれですか？今四半期の FinOps 支援の重点分野を優先的に決めるのを手伝ってください。」 「チームが FinOps のベストプラクティスに従わなかったことが原因で発生した前四半期のインシデントを分析してください。FinOps 文化への投資のビジネスケースを構築するのを手伝ってください。」 Engineering 「過去 3 か月で最大のコスト要因は何でしたか？アーキテクチャを大きく変更せずにコストを節約するにはどうすればいいですか？」 「リソーストラッカーを構築してください。サービス別のデプロイあたりのコスト、環境別のアイドルリソースインベントリ、オートスケーリングの効率指標を含めてください。」 「コスト最適化の機会について、この Terraform モジュールをスキャンしてください。サイズが大きすぎるインスタンス、オートスケーリングが設定されていないもの、コスト配分タグが付いていないリソースにフラグを付けてください。タグ付けを自動修正し、コスト削減のためのアーキテクチャ変更を提案してください。」 「us-east-1 のどの Amazon EC2 インスタンスが 10% の CPU 使用率を下回っていますか？サイズ適正化による推定月間節約額はどれくらいですか？」 「オートスケーリンググループは、オフピーク時にオーバープロビジョニングになっています。CloudWatch のメトリクスを分析し、SLO の目標を維持しながら、スケジュールベースまたは予測に基づくスケーリングポリシーを推奨してください。」 Finance 「標準テンプレートを使用して、CFO 向けの PowerPoint ファイナンスレポートを生成してください。Slack 経由で毎月第 1 月曜日の午前 8 時に配信をスケジュールしてください。」Slackインテグレーションが必要です 「ファイナンスレポートを設計してください：事業部別の毎月の実績対予算、予測精度の追跡、チャージバック／ショーバックビュー、請求書の照合状況。」 「毎月の CUR／FOCUS ファイルに基づいて、コストセンター、環境、ビジネスユニットごとにグループ化されたコスト配分レポートを生成してください。」 「第 1 四半期と第 2 四半期のサービス別の前月比コスト差異を、連結アカウント別に表示してください。20% を超える差異を強調表示し、承認された予算基準を超える差異があればフラグを付けてください。」 「インフラ支出をサービスの信頼性指標と関連付けてください。投資不足による財務リスクを定量化してもらえれば、インシデント関連の費用に備えて正確な予算準備金を積むことができます。」 Product 「今月、ML 推論コストが 40% 増加した理由は何ですか？支出が当社の戦略的投資の優先事項と一致しているかどうかを判断できるように、製品機能とユーザーセグメントごとに分類してください。」 「アクティブユーザー 1 人あたりのコストの傾向を、6 か月にわたって製品ラインごとにビジュアライゼーションで示してください。ユーザー 1 人あたりの収益と重ね合わせ、ユニットエコノミクスの観点でどの製品が改善または悪化しているかを示してください。投資の優先順位付けに役立てます。」 「新機能リリースのコストモデルを作成してください。1 万人、5 万人、10 万人のユーザー規模でのインフラストラクチャコストを見積もり、各規模での ROI を示すビジネスケース文書を生成してください。」 「過去 90 日間で product:ProdA とタグ付けされたリソースの総費用はいくらですか？ユーザーあたりのコストを計算してください。当社の価格モデルがビジネスケースを裏付けていることを検証できます。」 「ProdA のコストパフォーマンス比を評価してください。コンピューティングに 20% 多く投資した場合、信頼性の向上はどのくらい見込まれますか？」 Procurement 「月額 5,000 ドル以上の節約額で絞り込んだ最適化の推奨事項を見せてください。次のベンダー契約交渉に使用できる調達概要を作成してください。」 「ベンダーコミットメントのポートフォリオダッシュボードを作成してください。すべてのテクノロジーカテゴリにわたって追跡できるようにしてください。」 「MCP で現在の Savings Plans と RI ポートフォリオを問い合わせてください。90 日後に期限が切れる契約を特定し、更新シナリオをモデル化し、レバレッジポイントを含む交渉概要を作成してください」AWS Billing and Cost Management MCP サーバーインテグレーションが必要です 「現在のコミット済み支出レートをオンデマンド料金と比較してください。ベンダー交渉に役立つ情報として、当社が過剰にコミットしている箇所とカバレッジにギャップがある箇所を特定してください。」 「特定されたリソースに基づいてインスタンスの一覧を作成してください。Graviton または Spot インスタンスの恩恵を受けるインスタンスファミリーとリージョンはどれですか？」 Leadership 「毎日午前 8 時に Slack のメッセージを送り、昨日の支出と戦略的予算、そして経営陣の注意が必要な異常を含めてください」 「すべての BU のクラウド ROI、コスト効率比、単価の傾向を示すエグゼクティブスコアカードを作成してください」 「自動化された経営層向けアラートシステムを構築してください。予算の 80% に達したときにマネージャーに通知を送り、どの取り組みが支出に影響を与えているかを伝えてください。」 「戦略的な概要を教えてください。12 か月間の AWS 総支出の傾向、次の四半期の予測、成長を牽引する上位 3 つのサービス、そしてクラウドへの投資と収益の伸びの相関関係です。」 「戦略的リスクレポートを生成してください。当社のインフラ投資がビジネスの優先事項と一致していない箇所に焦点を当ててください。」 結論 最も成果を上げている FinOps プラクティショナーは、AI ツールの機能を成果に合わせて選び、ビジネス価値が確実に提供されるようにしています。今いるところから始めましょう。コストのスパイクを手動で調査するのに何時間も費やしている場合は、AWS FinOps Agent を試してみてください。ステークホルダーからの「X はいくらかかりますか？」という場当たり的な質問に追われているなら、コンソールの Amazon Q を案内するか、Amazon Quick を設定してください。開発者がコストガードレールなしでリソースをデプロイしている場合は、Kiro から始めてもらいましょう。そして、既製の選択肢のどれも自社独自のワークフローに合わない場合、それがまさに Amazon Bedrock の出番です。 FinOps を取り巻く AI の状況は急速に進化しています。早い段階で実験に取り組むプラクティショナーこそが、人員を増やさずに影響力を広げられるようになります。これらのツールはすべて価格体系が異なるため、使い始める前に必ず確認してください。完璧なタイミングを待たないでください。小さく始めて、早く学び、繰り返してください。まずは、このブログの各所でリンクしているツールを見てみてください。また、より実践的なコスト最適化のガイダンスについては、「The Keys to AWS Optimization」を参照してください。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Steph Gooch Steph は Sr. Optimization Solutions Architect Advocate です。現在および将来の AWS 支出を最適化する方法についてお客様を導く、当該分野の専門家です。お客様が請求データや使用状況データを整理して解釈し、そのデータから実用的なインサイトを特定し、コストを企業文化に組み込むための持続可能な戦略を策定できるよう支援しています。以前のキャリアでは、ビッグ 4 の 1 社で FinOps チームを率いていました。 Jenny Shen Jenny は、AWS で通信・メディア・エンターテインメント分野を担当するソリューションアーキテクトです。お客様が本番環境に対応したシステムを構築できるよう支援し、チームによるクラウドワークロードの運用を簡素化する方法を見つけることに情熱を注いでいます。以前のキャリアでは、ビッグ 4 の 1 社の FinOps プラクティスで働いていました。

はじめに 　レバレジーズ株式会社 テクノロジー戦略室 SRE チームの中野です。レバレジーズでは「SRE 化を通して、Developer Experience の改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。 　過去記事 (= Terraform による IaC の標準化を通じた、全社規模の開発体験の向上への取り組み ) では、社内標準となる IaC ツールの選定と、IaC 化の作業負荷の軽減を狙ったライブラリ・テンプレートの作成についてご紹介しました。 　今回はその続編として、これらの製品を Template as a Service として提供する中で見えてきたユーザペインと、AI Agent Skills によるペインの解消・製品強化の取り組み、そして今後の展望についてご紹介します。 　現在、SRE・Platform Engineering の取り組みで Template as a Service を社内展開しているが、製品を使いこなすまでのハードルが高く製品普及が思う様に進まない。この様なペインを抱える開発組織の参考になれば幸いです。 　なお、本記事で紹介する取り組みは、2026年4月開催の AWS Container Platform Engineering Meetup のパネルディスカッションでご紹介した話の詳細版です。当日話し切れなかった部分を本記事でお伝え出来ればと思います。 背景 　現在は、下表の Template as a Service を提供中です。初めにインフラ作業の効率化・省力化を狙って Terraform Modules、GitHub Composite Actions、GitHub Repository Template を作成し、学習による知識強化も狙って Terraform Handson というハンズオン形式の学習教材も作成しました。これらの製品により、IaC 化推進の環境を整えてきました。 提供製品 概要 Terraform Modules (AWS Provider 向け) ELB・ECS・RDS 等の単体リソースに対応する Component Modules、CloudFront・WAF 等の複数のリソース群を組み合わせた Catalog Modules の2種類がある GitHub Composite Actions Terraform 用の CI/CD、アプリ用の CI/CD 等の共通処理をパッケージ化したものが多い GitHub Repository Template (Terraform 向け) Terraform Backend の環境構築、CI/CD 用の IAM リソース設定、Slack 関連設定、アラート用のリソース設定等の手順・設定を同梱しており、IaC 導入時の初期作業を低工数で済ませられる Terraform Handson Terraform 用のハンズオン教材であり、Terraform の基礎から発展までを短期間で学習出来る 　一方、製品利用が進むにつれて、製品の改善点が見え始めました。以下は、ヒアリングやフィードバックを通して得られた代表的なペインです。 　当初は Embedded SRE 等の手慣れたエンジニアを対象に製品のファンを増やすことを目的としていましたが、今後のユーザ拡大を考えると、ペインを解消して製品の使い勝手を強化することを優先すべきだと考えました。 Terraform Modules モジュールの使い方や必要な変数の組み合わせが、仕様や利用例だけでは判断しにくい モジュール毎の使い分け基準は書かれているが、どのモジュールを使うかの判断が難しい GitHub Repository Template 初期整備の手順資料・作業工程が多く、作業全体の流れや進捗を把握しにくい 設定項目が多く、必須なものが分からないため、何を埋めるべきか判断しにくい AI の活用方針の検討 　社内では AI Agent の利用が広がっており、これを活用すれば作成コストを抑えながらペインを十分に解消可能だと考えました。実際、社内要件・命名規則やクラウドのベストプラクティスに沿って提供製品が作り込まれており、AI による代行が十分に可能でした。そこで、AI Agent Skills の作成を決めました。 　次に、先述のペインを起点に Skill で解決可能なことを整理して製品案を考え出し、次の基準をもとに作成優先度を決めました。その結果、下表の「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」を高優先で作成すべきだと判断し、これらの作成から始めることにしました。 作成優先度の決定基準 ペインの程度や発生頻度 負荷・コスト等の削減効果 直近の利用予定、社内要望 作成候補の優先度一覧 作成候補 優先度 対象者 判断理由 コード生成 Skill 高 ユーザ Terraform コードの実装・修正が他の作業よりも高頻度である 初期整備 Skill (GitHub Repository Template 用) 高 ユーザ IaC 関連の初期作業のみの利用だが、自動化の効果が大きい スタイルガイド Skill、 製品仕様ガイド Skill 中 ユーザ 運用フェーズでの実装・仕様把握の負荷を継続的に下げられる モジュール開発 Skill、 コードレビュー Skill 中 メンテナー 開発・レビューの作業負荷を下げ、省力化・体制分散に繋がる Terraform Ops Skill、 コスト試算 Skill、 インフラ構成図 Skill 低 ユーザ、メンテナー 発生頻度・現在の負荷が比較的小さく、将来の開発対象とする AI Agent Skills の作成 　ここでは、高優先で作成した「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」の概要・ワークフローや設計・工夫についてご紹介します。 　前者は Terraform Modules の「使い方・使い分けの判断が難しい」というペインに、後者は GitHub Repository Template の「初期整備の工程が多く進捗や設定値の判断が難しい」というペインに、それぞれ対応するものです。 Terraform コード生成 Skill (AWS / Google Cloud) 概要・ワークフロー 　Terraform コード生成 Skill とは、ユーザへのヒアリングに基づいて Terraform コードを生成する Skill です。AWS・Google Cloud の Provider 毎に Remote Skill (= terraform-codegen-aws / terraform-codegen-google ) として提供しており、EC2・RDS 等の単体サービスから、静的サイト (CloudFront・WAF・S3) や Web システム (ALB・ECS・RDS 等) といったインフラ構成のコードまで生成出来ます。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング サービス名・環境名・リージョン等の要件情報を聞き出し、必要なインフラリソースを洗い出した上でリソース設定の追加確認を行う 2 Terraform コードの生成 ヒアリング結果に基づき、必要なインフラリソースに関する Terraform コードを生成し、実行場所にコードを書き込む 3 Terraform コードの検証 生成したコードに対して terraform fmt/validate のコマンドを実行し、エラーが無くなるまで検証・修正のサイクルを繰り返す 4 完了報告と追加確認 設定の判断理由を含めて作業結果を報告し、コードの追加・修正の要望を確認する 　ヒアリングでは、推測可能な情報は聞かないことを原則として、要件等の推測が難しい情報だけを AI Agent がユーザへ確認します。また、どのリソース・モジュールを用いるか、変数設定をどう組み合わせるか等のコード生成に必要な判断を AI Agent が担います。この様な設計により、ユーザの確認負荷を抑えています。 　コード生成では、下記の優先順位で生成方法を選択します。terraform-codegen-aws は、該当する社内向け Terraform Modules があれば必ず利用し、無い場合はモジュールを用いずに生成します。一方、terraform-codegen-google は、社内向け Terraform Modules を提供していないため、モジュールを用いない生成を基本としています。 　なお、Public Modules の利用については、両方の Skill に共通で、バージョン更新時の追従負荷を考慮して要望があった場合のみ利用可能なオプションとしています。 terraform-codegen-aws の生成方法の優先度 (a) 社内向け Terraform Modules を利用する (b) モジュールを用いずにコードを生成する (c) Public Modules を利用する (要望時のみ) terraform-codegen-google の生成方法の優先度 (a) モジュールを用いずにコードを生成する (b) Public Modules を利用する (要望時のみ) 　この優先順位には、社内標準の資産を AI のコード生成経路そのものに組み込む狙いがあります。ユーザが社内モジュールの存在や使い分けを知らなくても、生成されるコードは自然と社内標準に沿ったものになり、個々のエンジニアの習熟度に依存していた社内標準への準拠を仕組みの側で担保出来ます。 設計・管理のポイント 　各々の Terraform コード生成 Skill に共通する設計・方針の枠組み (= SSoT の管理方針、検証の実施方針等) を定めており、これに基づいて各 Skill が作り込まれています。 　まず、Skill では SSoT の管理方針を明確に決めています。モジュールの仕様・バージョン等は外部情報として Skill 内で持たずに CLI コマンドで取得し、ヒアリングの進め方・コーディング規約・組織固有の情報等は Skill 内で参照情報やテンプレートとして管理します。この方針で外部情報の更新への Skill の追従が最小限になり、Skill の管理・運用のコストを抑えられました。 　また、参照情報を取得出来なかった場合に AI が推測で値を埋めることを禁止しており、ユーザへの確認に基づくコード修正かプレースホルダの残置に必ず倒す設計としています。 　コード検証では、 terraform plan の実行を意図的にスコープ外としています。コード生成の段階では静的なコード検証さえパスすれば問題無く、クラウド上での検証までスコープを広げると検証が複雑になり、副作用のリスクが生まれると考えたからです。そのため、 terraform fmt/validate の実行によるコード検証として設計しています。 動作検証時の挙動改善 　動作検証で、簡単なコード生成でも一律に時間・トークンを大きく消費するという挙動面の課題が判明しました。実測したところ、主な原因は「参照情報を何度も取得しに行っていること」及び「簡単なコード生成でも複雑な手順で処理していること」にあり、次の改善を行いました。 　これらを「修正、検証、品質チェック」の処理サイクルで適用したところ、ユーザの入力・待機等を除いた処理自体の所要時間やトークン消費を、改善前よりも 30% 〜 40% 程度削減出来ました。 参照情報の取得方法の見直し 参照の度に発生していた取得処理を、最初に一括で取得・保存する方式に変更した 参照情報の取得の繰り返しを防ぎつつ、必要な情報を適切・十分に参照可能にした 生成内容に応じた処理の使い分け コード生成の進め方に応じた処理群のパターン分けを、生成モードとは別に設けた 生成処理の複雑さに応じて処理パターンを当てはめ、適切な処理をさせる様にした 機械的なチェックへの移行 文章ルールに基づくチェックを、スクリプトを用いたチェック処理に置き換え、照合のやり取りを削減した チェックルールは機械可読な一覧表で管理し、ルールの追加・変更が表の編集だけで済む様にした AI モデルの能力や実行毎のばらつきに品質が左右されにくくなり、安定化に繋がった GitHub Repository Template の初期整備 Skill 概要・ワークフロー 　初期整備 Skill は、Terraform 向け GitHub Repository Template から作成した GitHub Repository の初期整備を AI Agent が代行する Skill です。現在提供中の4種類の Repository Template に Local Skill (= terraform-repo-init ) として導入しており、Repository の作成後に Skill を発動するだけで初期整備を簡単に進められます。 　この Skill により、人間が対応すべき箇所は「ヒアリングへの応答、残りの限られた手動作業の消化」だけに絞られ、その他の作業を AI Agent が代行してくれます。手順書に沿った作業で起きがちなミスも、スクリプトを用いた機械的なチェックにより極力発生しない様にしています。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング 構成・仕組みの要否 (= 開発環境、定期チェック、通知設定) や設定値等の初期整備で決めるべき情報を冒頭で一括して確認する 2 クラウド認証の確認・実施 実行環境やクラウド認証の状態を確認し、未認証だった場合に認証コマンドを実行する 3 初期整備の自動実行 雛形の削除、テンプレート情報の置換、Terraform Backend の環境構築、GitHub Repository Secrets の登録、CI/CD の有効化、作業のセルフチェック等の自動化可能な作業を実行し、GitHub PR の作成まで進める 4 残作業リストの出力 実行するだけで済む様な文面・スクリプト等を用意した上で、残りの手動作業に関するチェックリストを出力して終了する 設計・管理のポイント 　Repository の初期整備には、自動化が難しい作業 (= 外部への依頼・承認等) や、統制の観点から人間が担うべき作業 (= 秘匿情報の設定、PR のマージ判断等) が含まれます。そこでまず、AI Agent とユーザの作業分担を明確に定めました。 　具体的には、環境検証・テンプレート置換・Backend 構築・Secrets 登録・PR 作成までを AI Agent が実行し、それ以外の作業は意図的に人間側に残しています。この線引きが、AI による作業代行を安心して組織展開するための前提だと考えています。 　この分担を前提に、自動化可能な作業を先に進めて手動作業を最後にまとめる形へ作業全体の流れ・手順資料を再整理し、初期整備の自動実行とユーザへの残作業の提示を AI Agent に行わせる Skill を作りました。どの工程でも開始時に完了状態・前提条件・スキップ条件等を確認してから進行させる様になっており、途中で中断した場合でも安全に再開出来ます。 　なお、コード生成 Skill と同様に SSoT の管理方針も定めています。手順・コマンド等の具体値は Repository Template の資料・スクリプトを SSoT として参照し、Skill 自体は判断ロジックと工程の順序のみを持つ構成としています。 Skills の管理・配布 　Terraform コード生成 Skill は、特定の GitHub Repository に依存しない用途のため、Skill 専用の GitHub Repository で Remote Skill として管理しています。一方、GitHub Repository Template 用の初期整備 Skill は、Template 内の手順資料・スクリプトと一体で動く用途のため、Template 内で Local Skill として管理しています。 　配布についても、管理方式に合わせて分けています。Terraform コード生成 Skill は GitHub CLI コマンド ( gh skill install ) で利用可能にしており、GitHub Copilot・Claude Code 等の AI Agent 間の仕様差異を GitHub CLI が吸収してくれるため、統一的な手順で配布出来ます。初期整備 Skill は、Template から Repository を作成した時点でそのまま利用可能なため、配布作業が不要です。 今後の展望 　今後は、作成候補の優先度一覧で中優先以下とした Skill を順次作成し、ユーザ向けのインフラ作業のペイン解消だけでなく、製品メンテナーの開発・改善における作業負荷の軽減にも AI を活用していく予定です。これにより、Template as a Service の提供サイクルを現在の開発体制でも十分に回せる様に強化したいと考えています。 　過去記事では「Template as a Service を作り、IaC 化を推進する」をご紹介しました。今回は「AI Agent が Template as a Service を使いこなし、エンジニアの代わりに作業する」への進化をご紹介しました。Template as a Service × AI の組み合わせで、AI を前提としたゴールデンパスを引き続き提供し、利用の障壁の無いプラットフォームへと育てていきます。 最後に 　レバレジーズでは、全社の SRE・プラットフォームエンジニアリングの推進に向けて、開発生産性の向上に一緒に取り組んでいただけるエンジニアを募集しています。 　SRE の文化・体制に興味があったり創っていきたい方や、プラットフォームエンジニアリングの実践による開発生産性の向上に興味がある方は、是非ともご応募をお待ちしております。

AWS メディア業界向け勉強会 #9（2026 年 7 月 10 日開催） 2026 年 7 月 10 日（金）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。この記事では、カスタムモデルの生成等を通じてリアルタイム翻訳の精度を向上させた事例や、社内の基幹システムをクラウド移行する際の勘所、AI 会話システムの構築、クラウド編集環境の構築、社内ハッカソンにおける Kiro の活用などのメディア業界におけるクラウド活用事例を知ることができます。登壇者の所属部署および肩書きは登壇当時のものとなります。 鳥人間コンテスト Live 配信におけるリアルタイム英語字幕 読売テレビ放送株式会社 クロステック局 放送DXグループ 福岡 一輝 氏 読売テレビ放送株式会社では、毎年夏に琵琶湖で開催される鳥人間コンテストの公式 YouTube ライブ配信において、海外ファンに向けたリアルタイムの英語字幕付与を昨年から実施しています。エンジニア 1 名がわずか 2 か月で AWS 上にフルマネージドサービスを組み合わせた独自システムを構築し運用を開始しています。 リアルタイム字幕生成の流れは、 Amazon Transcribe による文字起こし、生成 AI サービスによる翻訳、番組専用の校正 AI による後処理の 3 段階で構成されています。Amazon Transcribe ではカスタムボキャブラリーやカスタム言語モデルを活用して認識精度を向上させています。校正処理では、 Amazon SageMaker AI を用いてファインチューニングした番組専用モデルを構築し、 Amazon Bedrock にCustom Model Import 機能を用いてカスタムモデルをデプロイしました。これにより、チーム名や専門用語などの固有名詞の補正や、主語の誤変換などを解決しています。独自モデルの構築にあたっては、Amazon SageMaker AI の JumpStart 機能を活用、過去の 10 時間分の配信音声を全て文字起こしし、正解データを手作業で作成するという学習データ整備も行っています。 映像の処理には Amazon Elastic Container Service（Amazon ECS） を採用し、機能ごとにマルチコンテナ設計とすることでリスク分散を図っています。 AWS Fargate の採用により複雑なインフラ管理が不要となり、開発者がアプリケーションロジックに集中できる環境を実現しています。また、字幕と映像のタイミングを一致させるため、映像をバッファリングして音声処理の遅延を吸収する仕組みを実装し、フロントエンドの UI からも微調整が可能な設計としています。YouTube Live への出力には AWS Elemental MediaLive を使用しています。さらに、 AWS SAM による Infrastructure as Code（IaC）でシステム全体を管理しており、環境の再現やアーキテクチャ情報の把握が容易になっています。配信後には海外視聴者からポジティブなコメントが多数寄せられました。 資料のダウンロードは こちら 社内の基幹システムを AWS に移行してわかった勘所と注意点 株式会社毎日放送 デジタルストラテジー局 副部長 田中 淳史 氏 関西テレビ放送株式会社 DX推進局 DX戦略部 主事 石井 克典 氏 読売テレビ放送株式会社 コーポレート局 情報システムグループ 谷 尚大 氏 読売テレビ放送、関西テレビ放送、毎日放送の 3 社は同一の会計パッケージを AWS 上に導入しています。この共通点を活かしてパネルディスカッション形式にて、基幹システムの AWS 移行における勘所と注意点についてお話しいただきました。放送局の基幹システムがクラウドで安定運用できることを 3 社の実例で示していただいた貴重なセッションです。 移行のきっかけについては、長年稼働してきた会計システムのモダナイズに合わせて自然にクラウドを選択した局がある一方、他局の先行事例や構築ベンダーからの推薦が後押しになった局もありました。共通していたのは、クラウドへの移行に対する社内の抵抗感が以前ほど大きくなかったという点です。 構築においては、 AWS Direct Connect の敷設や社内セキュリティ基準の策定など、初めてのクラウド本格利用ならではの苦労もありました。一方で、従来はハードウェアも含めてベンダーに委ねていた領域を自社で理解し運用する体制へと変化したことで、Savings Plans による長期コミット割引やインスタンスの稼働時間調整といったクラウドならではのコスト最適化を主体的に活用できるようになっています。会計システムの稼働後に他のワークロードでも AWS の利用が広がっていることが前向きに語られました。 もう一度やり直すとしたら何を変えるかという問いに対しては、「会計システム単体ではなく将来的なマルチアカウント構成を見据えた全体設計をすべきだった」「関係者間の役割分担を最初に明確にすべきだった」などの声があり、これから移行を検討される方へのアドバイスとして共有されました。 自社のマスコットキャラクターを AI で再現してみた 株式会社CBC Dテック テクニカルセンター プラットフォーム技術部 大石 祐貴 氏 株式会社 CBC Dテックでは、 Amazon Bedrock を用いて CBC テレビの公式マスコットキャラクター「シェアシェア」の AI 会話システムを開発しました。当初は応答速度を重視して Amazon Nova Lite を使用していましたが、回答精度を重視して Amazon Nova Pro に切り替えました。用途に応じて最適な基盤モデルを簡単に切り替えられることが Amazon Bedrock のメリットです。キャラクターの性格や口調はプロンプトエンジニアリングで制御しており、音声合成には外部サービスでオリジナルの音声モデルを作成して使用しています。コーディングエージェントを活用することで、プログラミング経験がほぼない中でもシステムを構築しました。 今年 3 月の自社イベントにて来場者向けに展示し、フリートーク、定型文のポン出し、しりとりなどの機能を提供しました。今後は RAG や Amazon SageMaker AI によるファインチューニングでキャラクターの再現精度を高めることを検討しています。 資料のダウンロードは こちら Amazon AppStream 2.0 を使用したクラウド編集環境の構築 読売テレビ放送株式会社 クロステック局 放送実施グループ 香川 駿貴 氏 読売テレビ放送株式会社では、 Amazon WorkSpaces Applications（旧 Amazon AppStream 2.0） を使用したクラウド編集環境の構築と検証を実施しました。クラウド上に編集環境を構築することで、場所を問わず映像編集が可能になり、物理的な編集機の台数に縛られない柔軟な運用が実現できます。システム構成は、オンプレミスからクラウドストレージに素材を同期し、Amazon WorkSpaces Applications 上で EDIUS を動作させるというものです。3 つのアベイラビリティゾーンにサブネットを作成し、ここに編集機やライセンスサーバーを配置しています。 セッション起動時に証明書とバックグラウンドサービスを再生成するスクリプトを組み込んだマスターイメージを作成することで、当初から動いていた EDIUS 9 に加えて EDIUS 10、EDIUS 11 でも動作に成功しています。使用時間に基づくコストも明確になり、従量課金モデルによる編集環境のコスト可視化という点でも価値のある検証となりました。 資料のダウンロードは こちら Kiro を使ったエンジニアハッカソンをやってみた 株式会社毎日放送 コンテンツ戦略局 プラットフォームビジネス部 村嶋 優吾 氏 株式会社毎日放送では、社内開発人口の増加を目的として、AWS の AI コーディングツール Kiro を使用した 2 日間のエンジニアハッカソンを開催しました。技術職の若手を中心に参加し、全チームが動くプロトタイプのデプロイまで到達しています。成果物の 1 つである新人研修用システムは、現在も開発が継続され実用化を目指しています。Kiro を選定した理由として、社内に AWS の精算フローが確立されており事務コストが低いこと、ターミナル操作や複雑なコマンド入力が少なく参加者層にマッチしていること、そして Kiro の「スペック駆動開発」の設計思想が放送局の技術職の働き方と相性が良いことが挙げられました。スペック駆動開発では仕様を自然言語で言語化してから AI に開発を指示するため、コーディング経験の少ない参加者でも効率的に開発を進めることができます。 運営者としての学びとして 2 つのポイントが共有されました。1 つ目は「仕様の言語化が最短経路」であること。事前にスペックをしっかり定義してから開発を始めたチームは AI の出力精度が高く、開発もスムーズに進みました。従来のハッカソンでは「早く手を動かす」ことが正義でしたが、生成 AI 開発においてはその気持ちを抑えて仕様の言語化に集中することが結果的に最短経路になるという気づきが得られました。2 つ目は「評価の壁」です。生成 AI により実装は容易になった一方で、セキュリティ設定の適切性やテストケースの網羅性など、成果物の品質担保が新たなボトルネックとして浮上しています。実装コストが削減された分、成果物を正しく評価するリテラシーの強化が今後重要になります。 資料のダウンロードは こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。今回の 5 つのセッションでは、リアルタイム字幕生成、基幹システムのクラウド移行、AI キャラクター、クラウド編集環境、AI 開発ハッカソンと、幅広いテーマが取り上げられました。生成 AI と AWS のマネージドサービスを組み合わせることで、限られたリソースの中でも新しい価値を素早く生み出せることが各社の事例を通じて示されています。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願いいたします。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。