本記事は 2026 年 6 月 8 日 に公開された「 Announcing Amazon RDS for Db2 12.1 with additional community edition 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 で IBM Db2 12.1 がサポートされました。Db2 データベースエンジンの最新世代です。今回のアップグレードに加えて、新しいエディション Community Edition (db2-ce) も導入され、Amazon RDS for Db2 インスタンスのプロビジョニング時に、3 つのエディションから選択できるようになりました。 本記事では、Db2 12.1 の新機能の紹介、Community Edition の概要と活用シーン、AWS マネジメントコンソール・AWS Command Line Interface (AWS CLI)・Terraform を使った開始方法、そして Db2 11.5 からのアップグレードパスについて説明します。 エディション エンジン識別子 推奨用途 Community Edition (new) db2-ce 開発、テスト、非本番ワークロード Standard Edition db2-se 汎用的な本番ワークロード Advanced Edition db2-ae より多くの CPU とメモリリソースを必要とするミッションクリティカルなワークロード Db2 12.1 の新機能 IBM Db2 12.1 は、 200 以上の新機能と機能強化 を含むメジャーリリースです。RDS ユーザーに特に関連するハイライトを紹介します。 AI を活用したクエリ最適化 Db2 12.1 には、機械学習 (ML) でカーディナリティ推定を改善する AI Query Optimizer が統合されています。カーディナリティ推定とは、クエリプランの各ステップで何行のデータが処理されるかをエンジンが予測することです。推定精度が向上すると、より適切なクエリプランが生成され、手動チューニングなしで複雑な分析やミックスワークロードのパフォーマンスが向上します。モデルのトレーニングは高速化され、よりコンパクトになり、mod pack (マイナーバージョン)リリースごとに精度も向上しています。 名前空間の分離とマルチテナンシー Db2 12.1 では論理的な名前空間の分離が導入されました。単一のデータベース内で、異なるデータベーススキーマのセットを互いに分離できます。データベース管理者は、別々のデータベースインスタンスを用意する手間なく、複数のチームやアプリケーション層のデータオブジェクトをきれいに分割できます。 セキュリティの強化 今回のリリースでは、テーブルスペース管理権限が追加されました。DBA はストレージグループ内でのテーブルスペースの作成と管理を委任できます。最小権限アクセスモデルにとって大きな改善です。既存の RDS for Db2 と AWS Key Management Service (AWS KMS) および AWS Secrets Manager の統合と組み合わせることで、データベースエンジンと AWS インフラストラクチャ層の両方にまたがる多層的なセキュリティ体制を構築できます。 管理性の向上 12.1 のその他の機能強化には、外部テーブル管理、KMIP クライアント証明書の一元管理、カラムナーテーブルのオンライン移動などがあります。本日 RDS for Db2 で提供開始される 12.1.4 mod pack は、運用の効率化と最新のデータプラットフォームへのデータ接続性の拡張に重点を置いています。 Community Edition (db2-ce) の紹介 Community Edition は ライセンス無料 の Db2 エディションで、RDSでは12.1から利用可能になります。開発者、パートナー、小規模ワークロードを運用するチーム向けに設計されています。Standard Edition や Advanced Edition と同じ Db2 コードベースを使用しており、違いは機能の深さではなくリソースのエンタイトルメントにあります。 Community Edition には、IBM ライセンスによる以下のリソース制限があります。 リソース 制限 メモリ 8 GB CPU コア 4 vCPU この制限は、基盤となる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスサイズに関係なく、Db2 エンジンレベルで適用されます。Community Edition デプロイ用のインスタンスクラスを選択する際は、この範囲内に収まるものを選択してください。例えば、Community Edition で利用可能なインスタンスは db.t3.small、db.t3.medium、db.t3.large、db.m7i.large (m7i が利用できないリージョンでは db.m6i.large) です。 注意 : 上記のリソース制限を超えるインスタンスクラスはプロビジョニング時にブロックされませんが、Db2 はライセンス制限までのリソースしか使用しません。 Amazon RDS for Db2 の Community Edition を使えば、IBM ソフトウェアライセンス費用なしでフルマネージドの Db2 12.1 インスタンスを起動できます。支払いは、標準の RDS 料金モデルに従い、基盤となる AWS インフラストラクチャ (インスタンス、ストレージ、I/O) のみです。 注意: Community Edition には IBM ライセンス料がかかりませんが、Amazon RDS for Db2 では db2-ce を含むすべてのエディションで、DB パラメータグループに IBM カスタマー ID と IBM サイト ID が必要です。IBM が使用状況とエンタイトルメントの追跡に使用します。IBM アカウントを使って IBM の Web サイトで無料登録して取得できます。各 ID の用途と入力場所について詳しくは、 Amazon RDS for Db2 のライセンス を参照してください。 Community Edition により、以下のような用途で Db2 on AWS を始めやすくなります。 アプリケーションの開発とテスト – ライセンスコストを気にせず、ブランチやスプリントごとに Db2 インスタンスをプロビジョニングできます。 概念実証 (PoC) – 本番ライセンスを契約する前に Db2 の機能を評価できます。 小規模な非本番ワークロード – Community Edition のリソース範囲で十分な小規模アプリケーションを実行し、必要に応じて Standard Edition や Advanced Edition に切り替えられます。 要件が拡大した場合、Community Edition から Standard Edition または Advanced Edition へのアップグレードは、インプレースのエンジンエディション変更で簡単に行えます。データの移行やインフラストラクチャの再構築は不要です。 既存の RDS for Db2 機能はすべて Db2 12.1 に適用 Db2 11.5 で利用されてきたフルマネージド機能のすべてが、3 つのエディション共通で Db2 12.1 に引き継がれます。 高可用性 同期スタンバイと自動フェイルオーバーによる Multi-AZ デプロイメント。 災害復旧とリードスケーリング リードレプリカとスタンバイレプリカ。地理的な災害復旧のためのクロスリージョンレプリカも含みます。 運用の自動化 ポイントインタイムリカバリ (PITR) 付きの自動バックアップ、マイナーバージョンの自動パッチ適用、ストレージの自動スケーリング。 セキュリティ AWS KMS カスタマーマネージドキーによる保存時の暗号化。 SSL/TLS による転送時の暗号化。 AWS Directory Service for Microsoft Active Directory またはオンプレミスの Active Directory を使用した Kerberos 認証。 モニタリング、Amazon Simple Storage Service (Amazon S3) 統合、ディレクトリサービスアクセス、監査ログに対する AWS Identity and Access Management (IAM) ベースのロール分離。 ライセンスの柔軟性 Bring Your Own License (BYOL) – AWS License Manager で追跡される既存の IBM Db2 ライセンスを使用。 AWS Marketplace 経由の時間課金ライセンス – Standard Edition と Advanced Edition で利用可能な従量制の IBM ライセンス課金。 Community Edition (db2-ce) – IBM ソフトウェアライセンス料なし。ただし IBM カスタマー ID とサイト ID は引き続き必要です。 IBM の Web サイトで無料で取得できます。 可観測性(オブザーバビリティ) Amazon CloudWatch メトリクスとログによるデータベースパフォーマンスモニタリング。 OS レベルのメトリクスの拡張モニタリング。 AWS Lambda 関数を使用した Db2 モニタリングのセルフ構築 。 開始方法 RDS for Db2 12.1 インスタンスは、AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、または Terraform で今すぐ起動できます。 コンソール AWS コンソールで Amazon RDS に移動し、 データベースの作成 を選択します。 エンジンとして IBM Db2 を選択します。 エンジンバージョン 12.1.4 を選び、エディション ( db2-ce 、 db2-se 、 db2-ae ) を選択します。 インスタンスクラス、ストレージ、Multi-AZ、VPC 設定を構成します。 IBM カスタマー ID と IBM サイト ID を入力します。Community Edition を含むすべてのエディションで必須です。Standard Edition と Advanced Edition では、時間課金用の AWS Marketplace ライセンスオプションも選択できます。 データベースの作成 を選択します。 CLI aws rds create-db-instance \ --db-instance-identifier my-db2-12-1 \ --engine db2-ce \ --engine-version 12.1.4.0.sb00080714.r1 \ --db-instance-class db.r6i.xlarge \ --master-username admin \ --manage-master-user-password \ --allocated-storage 100 \ --storage-type gp3 \ --db-subnet-group-name my-subnet-group \ --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \ --no-publicly-accessible 注意: デプロイ時に最新のエンジンバージョンを確認するには、以下のコマンドを使用してください。 aws rds describe-db-engine-versions \ --query "DBEngineVersions[?contains(Engine,'db2')].{Engine:Engine,Version:EngineVersion,Family:DBParameterGroupFamily}" \ --region <RegionName> --output table Terraform Infrastructure as Code を使用する場合、RDS for Db2 のモジュラー Terraform テンプレートが GitHub リポジトリで公開されています。このテンプレートは、リモートステート、ネットワーキング、IAM ロール、AWS KMS 暗号化、パラメータグループ、RDS インスタンス、AWS License Manager 統合を 7 つの組み合わせ可能なモジュールでカバーしています。詳しい手順は、 Deploying Amazon RDS for Db2 using Terraform を参照してください。 Community Edition を選択するには、 5-rds/terraform.tfvars でエンジンとエディションを設定します。 engine = "db2-ce" engine_version = "12.1.4" 4-parameter-group/terraform.tfvars では、パラメータグループモジュールが Db2 12.1 の有効なエディションとして ce を受け付けます。Community Edition でも IBM カスタマー ID とサイト ID は必須です。Standard Edition や Advanced Edition と同様に、パラメータグループの tfvars で設定してください。両方の ID は Create an IBMid ページで無料で取得できます。 Db2 11.5.9 からのアップグレード 現在 RDS for Db2 でエンジンバージョン 11.5.9 を実行している場合、標準の RDS メジャーバージョンアップグレードパスで 12.1 にアップグレードできます。アップグレード前に、 Db2 エンジンバージョンのアップグレード のドキュメントでアップグレード前のチェック事項とアプリケーションの互換性に関する注意事項を確認してください。 注意点: Community Edition (db2-ce) は 12.1 で新たに追加されたもので、11.5.9 には同等のエディションがありません。11.5.9 の Standard Edition または Advanced Edition インスタンスを移行する場合、アップグレード時にエディションを変更できます。ただし、Community Edition を選択すると、IBM のリソース制限 (4 vCPU、8 GB RAM) が適用されます。 ソース DB インスタンスがアップグレードされると、レプリカも自動的にアップグレードされます。 パラメータグループの IBM カスタマー ID とサイト ID のパラメータは、Standard Edition と Advanced Edition のアップグレードで引き続き必須です。 提供リージョン Amazon RDS for Db2 12.1.4+ (Community Edition と db2-se、db2-ae) は、AWS GovCloud (US) リージョンを含む、RDS for Db2 がサポートされているすべての AWS リージョンで本日から利用可能です。完全なリストは、 Amazon RDS for Db2 の提供リージョン を参照してください。 まとめ Amazon RDS for Db2 12.1 は、IBM の最新データベースエンジンをフルマネージドサービスとして提供します。AI Query Optimizer、名前空間の分離、テーブルスペース管理権限といった新機能と、Multi-AZ 高可用性、リードレプリカとスタンバイレプリカ、自動バックアップ、AWS KMS による暗号化といった既存の運用機能を組み合わせています。新しい Community Edition (db2-ce) により、利用の障壁が下がりました。開発、テスト、非本番ワークロード向けに IBM ソフトウェアライセンス料なしでフルマネージドの Db2 12.1 インスタンスを実行でき、ニーズの拡大に応じて Standard Edition や Advanced Edition にアップグレードできます。コンソール、AWS CLI、 GitHub リポジトリの Terraform テンプレートのいずれを使っても、数分で開始できます。始めるには、 Amazon RDS コンソール にアクセスするか、 Amazon RDS for Db2 のドキュメント を参照してください。ぜひ Amazon RDS for Db2 12.1 をお試しいただき、ご質問やフィードバックはコメント欄にお寄せください。 謝辞 Rajib Sarkar 氏にこの記事のレビューを感謝します。 著者について Vikram S Khatri Vikram は、Amazon RDS for Db2 のシニアエンジニア。プロダクトマネジメント、アーキテクト、リーダーシップ、AI エキスパートユーザーなど複数の役割を担当。20 年以上の経験を持ち、ゼロから新しいプロダクトを生み出すことに情熱を注いでいます。 Ashish Saraswat Ashish は、Amazon RDS for Db2 のシニアソフトウェア開発エンジニア。10 年以上のソフトウェア開発経験があります。 Umair Hussain Umair は、Amazon RDS for Db2 チームのシニアデータベースエンジニア。20 年以上のテクニカルリーダーシップと Db2 および Oracle の深い専門知識を活かし、お客様のクラウドでの高パフォーマンスデータベースワークロードの構築と運用を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

ニフティに新卒入社したエンジニアは、3か月間の新入社員研修と技術研修を経て、7月からOJT期間に入ります。8か月の間に3つの部署をジョブローテーションし、業務知識やチームでのプロジェクトの進め方、エンジニアとしての技術を身につけたうえで、4月からの本配属に備えるという流れです。 実際にプロジェクトの一員として働くニフティのOJTは、単に仕事を覚えるだけでなく、自分自身の適正を知り、会社員やエンジニアとしての歩み方を見定めていく期間でもあります。前回は2025年度に新卒入社した4名の新人に、OJTで得た学びや気づき、入社前のイメージと実際に働いてみてのギャップについて聞きました。今回は、ニフティの働きやすさや休みの取りやすさについて、また、本配属を前にした決意を語ってもらいました。 ニフティは良い意味で「ゆるふわ」な会社？ 職場の雰囲気も含めた、働きやすさという点に関してはどのように感じていますか？ Nさん 職場の雰囲気はとても良いです。ニフティって固い会社だと思われがちなのですが、良い意味で年次による壁がないように感じます。1年目のジョブローテで3つの部署を回りましたが、どのチームもコミュニケーションを大事にしていて、新人が遠慮なく先輩や上司に相談できる雰囲気でしたね。 Sさん 言い方が適切か分かりませんが、ちょっと“ゆるふわ”な空気がありますよね。自分もどちらかというと緩いタイプなので居心地は良いです（笑）。また、今は原則出社なのですが、個人的にはそのほうがやりやすいですね。特に新人のうちは分からないことが多いので、色んな部署の人に直接会いに行ってコミュニケーションできるのはありがたいです。 Yさん 私も風通しの良さは感じます。たとえば、所属部署の定例会議に新人も参加するのですが、1年目なので理解できないことも多くて。ただ、分からないことがあってもSlack上にある「会議実況チャンネル」に投稿すれば、会議の合間で誰かが拾ってくれて、マネージャーや部長がその場で回答してくださるので全くついていけないということはなかったです。 Tさん 社内の雰囲気やコミュニケーションの部分については、私もみんなと同意見です。たまにオフィス内のフリースペースで仕事をしていると、他部署の先輩たちがフランクに話しかけてくれたりして、いいリフレッシュにもなっています。業務で凝り固まった思考を、雑談でほぐしてくれるんです。 自由参加の社内飲み会みたいなものも週1であって、ここにいるメンバーは全員参加したことがあります。他部署の人だったり、マネージャーだったり、普段の業務ではあまり接点のない人ともお酒を飲みながらコミュニケーションできるのがいいですね。 それから個人的に感じるのは、ニフティって「褒め上手」な人が多いなと。たとえ些細なことでも、誰かが何かしらの成果を出せば素直に称える。そんな文化が根付いている気がします。逆に、否定から入る人は少ないです。たとえば、私が出したアイデアに対して頭ごなしに否定されるようなことはなく、まずは検討してくれる。結果的に採用されなかったとしても、ちゃんと理由を説明してくれるので納得感がありますし、また提案してみようと思えます。 1年目から有給休暇をフル活用し、海外旅行へ ワークライフバランスに関してはいかがでしょう？　休みの取りやすさや業務量など、不満も含めて感じていることを教えてください。 Nさん 休みはすごく取りやすいです。有給休暇は1年目から20日間付与され、新人だから遠慮して取得しづらいみたいなことも全くないですね。逆に私の場合は取得しすぎて、あと3日しか残っていません。先日は海外旅行に行くために5日間ほど休みました。先輩たちも有給やフレックス制度をうまく使ってライブに行ったりと、仕事とのバランスを取りながらプライベートを充実させている印象です。 Yさん 逆に有給休暇を全く取っていないと、周囲が取得を促してくれます。私も、ほぼ使わずにいたら当時の上長から「ちゃんと有給を消化しようね」と言われました。有給休暇以外の休暇制度も充実していますし、雰囲気的にも休みを取ることに対する抵抗はないですね。業務量についてはまだ1年目ということでセーブしてもらっているところもあると思いますが、先輩たちを見ていても過重労働にならないようコントロールされているのかなと。 Sさん 有給休暇に関しては相談するというよりも、「この日に取ります」と宣言するような形ですね。取得するのが当たり前というか。今のチームではSlack上で申請するだけで勤務表への打刻まで自動でやってくれるシステムを使っているので、そういう意味でも取りやすい。私自身も有給はしっかり消化しています。土日休みとくっつけて実家にちょくちょく帰ったりしてました。 Tさん 私も有給休暇は積極的に取得しています。土日に趣味のイベントがある時に、月曜を有給にすることが多いですね。土日は思い切り楽しんで、月曜は静養に充てています。 休みも取りやすいですし、仕事中に体調が悪くなった場合もすぐに早退できたり、お子さんが急に熱を出した時に在宅勤務に切り替えたりと、急なアクシデントにも柔軟に対応してもらえます。フレックスタイムにしても在宅勤務にしても、現場の要望や社員の働きやすさを考慮した上で制度が設計されているように感じますね。 新人たちがこれからチャレンジしたいことは？ 1年目のOJTとジョブローテが終わり、4月からはそれぞれの部署に本配属となります。これからニフティで挑戦したいことや、現段階で思い描く将来像を教えてください。 Tさん 直近で取り組みたいと思っているのは、ニフティの会員様の満足度向上です。新しい会員を増やすことも大事ですが、今ご契約いただいているお客様に対してインターネットの接続サービス以外の部分でも、「ニフティの会員になって良かった」と思っていただけるような施策に携わっていきたいと思っています。 将来像については、ざっくりとしていますが「なんでもできる人」になりたいです。技術に関しても、何か一つを極めるというよりも色んな選択肢を持てるよう、幅広い知見を身につけたいと思っています。その点、幅広いサービスを手掛けるニフティはうってつけですし、オンライン学習や社外イベントへの参加を通じて業務外の技術にアプローチできる環境をうまく活かしていきたいですね。 Sさん OJTを通じて感じたことでもあるのですが、直近でやりたいのは社内業務フローの改善です。どんどん自動化を進めて工数を減らし、本来エンジニアがやるべき業務に注力できるような取り組みを進めていきたいですね。将来像はTさんと似ていますが、いわゆるフルスタックエンジニアとして、どんなことにも挑戦していきたいと思っています。そういう意味では、ジョブローテではバックエンド、フロントエンド、インフラ関連と、異なる領域に触れることができたので、いい経験になりました。 Yさん まだ配属先が決まっていない段階（2026年3月5日時点）ですので、やりたいことが具体的に固まっているわけではないのですが、現在ニフティでは全社的にAWSへの移行を進めていて、どのチームに配属されたとしてもクラウドにまつわる知見やスキルは重要になってくると思います。まずはそこを深めていきたいですね。将来は、社内インフラの整備やサポートといった、ニフティの社員に快適に働いてもらうための業務に携わりたいと考えています。 Nさん ニフティには職人的に技術をひたすら磨き抜いているスーパーエンジニアもいますが、私自身は技術に特化するというよりも、技術をベースとしつつもサービスの知識や、ビジネス側との調整スキル、顧客ニーズを捉える力などを総合的に伸ばしていきたいと思っています。プロダクトマネジメントに主眼を置いて、サービスをよりよいものにしていけるエンジニアになりたいですね。 前編もご覧ください！ 今回はニフティの2025年度 新卒社員のインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】入社から1年。成長の実感は？　新人たちが振り返るOJTの日々【2025年度 新卒社員 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

本日 AWS は、 AWS FinOps Agent  のパブリックプレビューを発表します。これは、コスト異常を調査して根本原因を特定し、組織全体のエンジニアに対して、すでに使っているツールの中でコストに関する質問に回答する、エージェント型 AI ソリューションです。 FinOps（financial operations の略）は、財務・エンジニアリング・ビジネスの各チームを結びつけ、財務上の責任を共有し、コスト・スピード・品質の間でデータに基づくトレードオフを行うことを通じて、クラウド投資のビジネス価値を最大化するものです。FinOps は、ダッシュボード主導の定期的なレビューから、エンジニアリング・財務・FinOps の各チームが一緒に運用する継続的なワークフローへと移行しつつあります。その移行には、専門的なコストの知見、多数のアカウントとワークロードにまたがる規模での実行、そしてエンジニアリングチームがすでに使っているツールとの統合が必要です。AWS FinOps Agent は、これらそれぞれに対応するよう設計されています。エンジニアリング・財務・FinOps のプラクティショナーに専門的なコストの知見をもたらし、チームが Jira や Slack ですでに行っている方法にも適合します。また、定期的なスケジュール、異常が検出されたとき、またはエンジニアからコストに関する質問があったときなど、作業に必要な頻度で実行されます。本エージェントは  AWS Cost Explorer 、 AWS Cost Anomaly Detection 、 AWS Cost Optimization Hub 、 AWS Compute Optimizer を活用するため、その回答には、中央の FinOps チームが依拠しているのと同じデータが反映されます。 Workday、AVIV Group、Convera、Mitre 10 などの初期のお客様は、AWS FinOps Agent を使用して、クラウド財務管理をリアクティブな月次レビューから、スケジュールされたイベント駆動型の運用へと移行しています。これは、コスト異常が積み重なる前に調査し、コストに関する回答をエンジニアに直接届けているということです。 コスト異常を今までより迅速に調査する チームがコスト異常を早く調査できれば、その異常が、新しいワークロードの成長のようなポジティブなビジネスシグナルを反映しているのか、それとも環境を最適化する機会を反映しているのかを、より早く判断できます。 Cost Anomaly Detection のアラートは、何らか変更があったことを知らせます。AWS FinOps Agent はその次のステップを自動的に実行します。コストの変化を AWS CloudTrail イベント（AWS 環境全体で誰がいつ何を変更したかの記録）と関連付けて、急増の原因となった変化を特定し、考えられる根本原因と責任者を含む調査概要を作成します（図 1 参照）。オプションで、エージェントは Jira チケットを開くか、Slack チャンネルに投稿して調査結果を伝えることができます（図 2 参照）。これにより、リソースを所有するエンジニアはコンテキストを理解し、次に何をすべきかを決めることができます。エージェントを最も重要なことに集中させるために、自動化プロンプトにフィルターを含めることができます。たとえば、特定の金額のしきい値を超える異常のみを調査して、チームの注意を最もインパクトの大きい変更に集中させることができます。 図 1 – FinOps Agent によるコスト異常の調査 図 2 – FinOps Agent の Slack チャンネルメッセージ コストの回答をすべてのエンジニアに AWS FinOps Agent を使用すると、エンジニアは自然言語でコストに関して質問し、実際のコストと使用状況データに基づいた回答を得ることができます（図 3 参照）。エンジニアは、「なぜ AWS コストが先月上がったのですか？」と聞くと、コストの変化、要因となったサービスおよびその背後にある使用量の要因を特定した回答を得ることができます。エージェントを組織に合わせて調整するために、アカウントとオーナーのマッピング、チーム定義、タグ付け規則、レビュー頻度などのコンテキストファイルをアップロードできます。エージェントはこのコンテキストを利用して、質問を組織の用語で解釈できます。たとえば、「チーム X のコストはいくらですか？」という質問をそのチームが所有する特定のアカウントに紐づけて回答します。エンジニアは必要なときにすぐ答えを得られ、FinOps チームはその時間を戦略的な仕事に費やすことができます。 図 3 – 自然言語によるコストに関する質問  パブリックプレビューで提供されるもの パブリックプレビューには以下が含まれます。 イベントトリガーによるコスト異常調査。 AWS Cost Anomaly Detection イベントを監視し、統合された調査レポートを作成して、Jira または Slack に配信するようにエージェントを設定できます。 自然言語でのコスト問い合わせ。 ワークロードについてコストに関する質問をして、コストと使用状況のデータに基づいた回答を得られます。 定期的なコストレポート。ダウンロード可能なプレゼンテーション用の HTML、PDF、または PPT フォーマットで、定期的なコストレポート（日次、週次、月次など）をスケジュールできます。 最適化の機会を 1 か所で。 AWS Cost Optimization Hub と AWS Compute Optimizer から推奨事項を取得し、それらを Jira チケットにまとめて、エンジニアリングチームがすでに使用しているツールで作業を引き受けられるようにできます。 コンテキストファイルとメモリ。 組織特有のコンテキストファイルをアップロードできます。エージェントはそれらを回答に適用し、セッションを跨いでコンテキストを記憶できます。 始め方 AWS FinOps Agent は、本日よりパブリックプレビューでご利用いただけます。設定方法は次のとおりです。 最初のエージェントを作成する方法 エージェントを作成。 AWS マネジメントコンソールにサインインし、US East（バージニア北部）（us-east-1）リージョンに切り替え、AWS FinOps Agent コンソールページを開いて、最初のエージェントを作成します（図 4 参照） 図 4 – エージェントを作成する ワンクリックによる IAM ロールの設定。 エージェントがコスト、使用状況、運用データを読み取るために使用するカスタマーマネージドのロールをプロビジョニングします。 Jira と Slack の接続（オプション）。 エージェントがチケットを作成し、メッセージを投稿できるように、Jira のスペース キーと Slack チャンネルを設定します。 エージェントが作成されたことの確認。 AWS FinOps Agent コンソールでエージェントの設定を確認してください。 ウェブアプリケーションを開く。 AWS FinOps Agent コンソールのページから、エージェントのウェブアプリケーションを開いて操作を開始します。 コンテキストのアップロード（オプション）。 ウェブアプリケーションで、アカウントとオーナーのマッピングと組織特有の指示（既知の例外、優先順位付けルール、レビュー頻度など）を追加します。 クエリの実行。 自然言語で尋ねます。たとえば、「先月のコスト要因の上位 10 件をリストアップし、リージョン別にグループ化してください」や「データプラットフォームアカウントで 1,000 ドルを超えるコスト異常を調査し、根本原因を記載した Jira チケットを作成してください」などです。 イベントトリガーのコスト異常検知自動化の設定。 エージェントに「AWS Cost Anomaly Detection イベントを監視し、それぞれの異常の根本原因を調査し、その結果を #finops-anomalies Slack チャンネルに投稿してください」のように依頼してください。この時点から、手動のトリアージなしに異常が調査され、チャンネルに投稿されます。 カスタマーサクセスストーリー 初期のお客様は、AWS FinOps Agent を使用して、継続的な運用として定期的なコストレビュー、コスト異常への対応、そしてエンジニアのフォロースルーを行っています。 Workday Workday は、人事、財務、IT 向けのエンタープライズ AI プラットフォームです。AI プラットフォームインフラストラクチャチームは Workday の AI プラットフォームを AWS で運用しています。 私たちの AI プラットフォームは多数の AWS アカウントにまたがっており、チームの時間を奪っていることが 2 つあります。予算の問題になる前にコストの外れ値を追跡することと、リーダーシップがレビューする月次コストレポートを作成することです。AWS FinOps Agent は、AWS 環境において両方を 1 か所で行うのに役立ちます。対処するために必要なコンテキストとともに潜在的なコスト異常を明らかにし、手作業でまとめていた傾向と支出ビューを生成します。以前はチームが毎月何時間もかけて手動でダッシュボード作業を行っていたことが、今では自然言語のインターフェースから始められます。異常検知と報告が 1 か所にまとめられているおかげで、エージェントは単なる保守ツールではなく、すぐにクラウド運用の中核的な部分になりました。 Serjesh Sharma, Manager, Software Development Engineering、Workday. Mitre 10 Mitre 10 はニュージーランド最大のホームセンター小売業者です。そのプラットフォームエンジニアリングチームは、会社の小売テクノロジーを支える AWS プラットフォームの構築と運用を担当すると同時に、クラウドコストの可視化とガバナンスの管理も担当しています。 私たちのプラットフォームエンジニアリングチームは、2 つの役割を果たしています。私たちは、他のチームがアプリケーションを実行する共有 AWS プラットフォームを構築して運用しています。また、クラウド支出の管理方法についても責任を負っています。これまで、定期的なコストレビュー、異常調査、最適化チェックは、信頼性向上や改善作業と直接競合していました。 AWS FinOps Agent が私たちにもたらすことは、コスト調査とレビューのワークフローを一度定義するだけで、それらの確認作業がバックグラウンドで継続的に実行されることです。異常の特定、未使用のリソースの発見、定期的なコストインサイトの準備などの活動は、もはや誰かがそれを実行することを覚えているかどうかにかかっていません。代わりに、本当に注意が必要なものがあるときに関連する調査結果が浮かび上がります。 限られた人数のプラットフォームチームにとって、手作業から継続的で状況に応じたコストインサイトに移行することは、力を倍増させる意味があります。 Eduard Kleynhans, Platform Engineering Manager, Mitre 10 New Zealand. Convera Convera は、規制のある金融サービス環境で事業を展開する商業決済のグローバルリーダーです。 私たちの FinOps プログラムの課題は、大規模な最適化ではなく、開発者が導入する意図しない小さなコスト変更を、複雑化する前に捉えることです。AWS FinOps Agent はそれをエンドツーエンドで処理します。異常を検出し、何が変更されたかを調査し、そしてリソースを所有するエンジニアリングチームに Jira チケットを作成します。これにより、誰も見ていない共有キューに埋もれることなく、適切なエンジニアの目に直接届くようになります。変化の速いエンジニアリング組織にとって、クローズドループのワークフローが、リアクティブな月次レビューに留まるか、継続的なコストガバナンスを実現できるかを分ける決定的な要素です。 Ramesh Singaraj, Infrastructure Engineering and Operations Leader, Convera. AVIV Group AVIV Group は、フランス、ドイツ、ベルギーで主要なデジタル不動産マーケットプレイスを運営しています。その一元化された FinOps チームは、さまざまな事業部門にわたる数百の AWS アカウントと、複数の共有サービスをサポートしています。 私たちの FinOps チームは、さまざまな事業部門の何百もの AWS アカウントをサポートしており、純粋な集中型モデルからハイブリッドモデルに移行するにつれて、ローカルチームがより多くのコスト作業を自ら引き受けるようになってきています。この移行で最も難しいのは、オンデマンドと Savings Plan の違い、支出予測の計算方法、コスト異常が発生した理由などのエンジニアの質問が、リソース所有者が行動する前に、すべて小さな中央チームにまわってきてしまうことです。AWS FinOps Agent は、独自のアカウントとビジネスユニットの対応関係のコンテキストに基づいて、エンジニアに対してこれらの質問に直接答えます。これにより、私たちの中央チームは、質問ごとのやり取りではなく、チャージバックロジック、最適化戦略、リーダーシップレポートに時間を費やすことができます。大規模な組織を支える小規模な FinOps チームにとって、それはまさに、私たちが可能な限り効果的に機能するために必要なレバレッジです。 Jordi Espasa, FinOps Director, AVIV Group. 提供状況と料金 US East（バージニア北部）リージョンで、AWS FinOps Agent を今すぐ試すことができます。エージェント自体は US East（バージニア北部）リージョンで実行され、管理アカウントで設定すると、AWS リージョンとアカウント全体のコストを管理できます。プレビュー期間中は、AWS FinOps Agent を追加料金なしで使用できますが、月単位の使用制限があります。AWS FinOps Agent に関連して使用される他の AWS サービスには標準料金が適用されます。 まとめ AWS FinOps Agent は、コストの異常が発生した瞬間に調査し、その結果を自動的に所有者に転送します。また、コストに関する答えをすべてのエンジニアが直接手に入れることができるため、すでに使用しているツールから離れることなくクラウド支出を把握できます。時間が経つにつれて、エージェントは AI ワークロードのコスト分析など、より多くの FinOps 機能に拡大するでしょう。これらの機能を組み合わせることで、お客様はクラウドコスト管理を FinOps チームとエンジニアリングチームの両方で継続的に実践できるようになります。 詳細については、 AWS FinOps Agent（プレビュー） にアクセスして、 ユーザーガイド を確認してください。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Jason Wu Jason Wu は AWS のシニアテクニカルプロダクトマネージャーであり、AWS Billing and Cost Management 内で AI for FinOps プロダクトポートフォリオを率いています。彼は FinOps、クラウドのコストおよび使用状況データ、AI を活用したクラウド運用にわたる豊富なプロダクトマネジメントの経験を持っています。複雑なデータについて推論し、インサイトを浮かび上がらせ、アクションを促進する自律型 AI エージェントの構築に注力し、お客様がクラウド環境をより効果的に管理・運用できるよう支援しています。 Letian Feng Letian Feng は AWS のシニアマネージャー（プロダクトマネジメント – テクニカル）であり、AWS のクラウド財務管理プロダクトポートフォリオを率いています。彼は FinOps、クラウド管理、AI/ML インフラストラクチャ、データ分析の分野で、15 年以上のプロダクトマネジメントおよびソフトウェアエンジニアリングの経験を持っています。AI を活用して、お客様がクラウド環境を管理・運用・最適化する方法を変革すること、そして実際の顧客の課題を解決する革新的なソリューションを提供することに情熱を注いでいます。