低コストでバースタブルな新しい Amazon EC2 インスタンス T8i の一般提供開始をお知らせします。Amazon EC2 T8i は AWS 専用にカスタマイズされた第 6 世代インテル Xeon スケーラブルプロセッサ (Granite Rapids) を搭載しています。T8i インスタンスは最も低価格な EC2 インスタンスのひとつとなり、前世代の T3 インスタンス と比較して最大 30% 優れた料金パフォーマンスを提供します。T8i インスタンスは、CPU 使用率が低から中程度のさまざまなワークロード (フリーミアムサービス、トレーニングおよびデモ環境、ステージングと開発、データ処理、マイクロサービス、低トラフィックの Web サイト、ログインゲートウェイなど) を実行するように設計されています。 T8i インスタンス T3 インスタンスは、小規模かつ費用対効果の高いコンピューティング構成が求められる軽量ワークロードの実行において、非常に多くのお客様から利用されています。これには、マイクロサービスアーキテクチャ、低トラフィックの Web サイト、開発およびテスト環境、小規模データベース、データ処理ジョブ、短時間のコンピューティングタスクなどが含まれます。こうしたお客様の多くからは、T ファミリーのバースタブル性能モデルが好まれています。このモデルでは、ベースラインレベルの CPU パフォーマンスが提供され、必要に応じて CPU クレジットを使用してベースラインを超えるバーストが可能です。 インフラストラクチャのモダナイズや、オンプレミス環境からの移行、イベント駆動型およびマイクロサービスアーキテクチャの採用、さらには AI 推論ワークロードの実験を進める中で、お客様から次の 3 点が求められています。それは、1. コスト最適化された新世代の小規模インスタンス、2. 総所有コストを削減できる優れた価格パフォーマンス、3. 既存の知識とツールを活用できるシームレスな移行パスです。 T8i インスタンスはこうした要望にお応えします。 最大 30% 優れた料金パフォーマンス。 T8i インスタンスは、 AWS Nitro System を基盤とし、カスタムの第 6 世代インテル Xeon スケーラブルプロセッサー (Granite Rapids) を搭載。最大 30% 優れた料金パフォーマンスにより、総所有コストの削減を実現します。 最大 70% 向上したコンピューティング性能。 T8i インスタンスは、T3 インスタンスと比較してコンピューティング性能が最大 70%、ネットワーク帯域幅は最大 1.25 倍、EBS 帯域幅は最大 2.4 倍に向上しています。 T3 からのシームレスなアップグレード。 すでに T3 をお使いのお客様は、T8i へのアップグレードが簡単です。T8i では、お客様がすでに使い慣れた CPU クレジットシステムと軽量コンピューティングオプションをそのままご利用いただけます。T3 から T8i に変更するだけで、より高いコストパフォーマンスが得られます。 高いコスト効果で新規に始めやすく。 AWS を初めて利用するお客様やオンプレミスから移行されるお客様にとって、T8i インスタンスは、低～中程度の CPU 使用率が必要なワークロードの実行のほか、バッチ処理、イベント駆動型関数、CI/CD パイプラインなどの短期間のコンピューティングタスクの実行において、最もコスト効果の高いエントリーポイントの一つとなります。 インスタンスの仕様 T8i インスタンスには 4 つのサイズがあり、いずれも 2 つの vCPU をシングルコアで提供します。次の表は、仕様をまとめたものです。 インスタンスサイズ vCPU メモリ (GiB) ベースラインパフォーマンス/vCPU (%) 1 時間あたりの CPU クレジット獲得数 ネットワーク バースト 帯域幅 (Gbps) t8i.nano 2 0.5 5 3 最大 6.25 t8i.micro 2 1 10 6 最大 6.25 t8i.small 2 2 20 12 最大 6.25 t8i.medium 2 4 20 12 最大 6.25 T3 と同様、T8i インスタンスは 1:0.25、1:0.5、1:1 といった、他の EC2 インスタンスにはない、独自の vCPU 対メモリ比率を提供します。また T3 と同様、CPU クレジットシステムを採用しており、 Standard モードおよび Unlimited モードの 2 つのクレジット設定モードを利用できます。T8i ではデフォルトで Unlimited モードが有効です。 T8i で提供されるサイズ ( nano 、 micro 、 small 、 medium ) よりも大きなインスタンスが必要なワークロードには、 M8i Flex インスタンス をお勧めします。これは、同等の前世代の T3 インスタンスと比較して最大 30% 優れた価格パフォーマンスを提供するとともに、 16xlarge までスケールアップできる柔軟性を備えます。 今すぐご利用いただけます Amazon EC2 T8i インスタンス は現在、以下の AWS リージョンでご利用いただけます: 米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、アジアパシフィック (ハイデラバード、マレーシア、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ)。リージョンごとの提供状況と今後のリージョン拡張については、 AWS Capabilities by Region の CloudFormation リソースタブでインスタンスタイプを検索してください。 T8i インスタンスは、 オンデマンドインスタンス および スポットインスタンス で購入でき、Savings Plan オプションは近日提供予定です。T8i インスタンスは共有テナンシーのみをサポートしており、Dedicated テナンシーや専有ホストはサポートしていません。 t8i.micro インスタンス および t8i.small インスタンス は、 AWS 無料利用枠 でもご利用いただけます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 T8i インスタンスを Amazon EC2 コンソール でお試しいただき、 AWS re:Post for EC2 または通常の AWS サポート窓口までフィードバックをお寄せください。 — Channy 原文は こちら です。

本記事は 2026 年 6 月 2 日 に公開された “ Unlock license mobility with Bring Your Own Media on fully managed Amazon RDS for SQL Server ” を翻訳したものです。 長年にわたり、エンタープライズワークロードをクラウドに移行する理由は、管理の容易さ、柔軟なスケーリング、コスト削減を中心に語られてきました。これらは重要な理由ですが、既存のライセンス契約やすでに投資したインフラストラクチャとの兼ね合いで正当化する必要がありました。エージェンティック AI アプリケーションの登場により、その判断基準は変わりました。これらのアプリケーションは、柔軟にスケールする GPU キャパシティ、最新の AI サービスへの低レイテンシーアクセス、そしてデータに直接アクセスして推論できる AI モデルに依存しています。この基盤をセルフマネージドのデータセンターで再現することはますます困難になっています。オンプレミスのインフラストラクチャは管理が難しいだけではありません。クラウドネイティブなエージェンティック AI サービスへのアクセスが限られるため、ビジネスの次の一手に対する制約となりつつあります。 この制約は、業務データが存在するあらゆる場所で顕在化します。多くの企業において、そのデータの大部分は Microsoft SQL Server に格納されており、顧客レコード、注文、在庫、基幹業務システムを支えています。こうしたお客様にとって、移行を妨げていたのは移行したいという意思ではなく、すでに行ったライセンス投資でした。これまで、 Software Assurance を持つお客様が SQL Server ライセンスを AWS に持ち込めるのは、 Microsoft の License Mobility プログラム を利用したセルフマネージドの Amazon Elastic Compute Cloud (Amazon EC2) 上に限られていました。 Amazon Relational Database Service (Amazon RDS) のようなフルマネージドデータベースの場合、既存の SQL Server ライセンスを持つお客様は、License Included モデルでライセンス費用を二重に支払う必要がありました。 Amazon RDS for SQL Server の Bring Your Own Media (BYOM) がこの問題を解決します。既存の SQL Server インストールメディアと、すでに投資済みのライセンスを持ち込み、フルマネージドデータベースサービスである RDS for SQL Server 上で追加のライセンス費用なしに利用できます。BYOM では、既存の SQL Server Enterprise Edition または Standard Edition のライセンスを再利用できます。AWS License Manager を設定済みであれば、BYOM インスタンスは自動的に追跡され、SQL Server のライセンス使用状況とコンプライアンスを継続的に可視化できます。移行を検討されているお客様のために、Amazon RDS は リフト & シフト のパスを提供し、SQL Server の業務データをフルマネージド環境に移行できます。RDS はパッチ適用、バックアップ、高可用性、モニタリングを自動化しつつ、AWS ネイティブのエージェンティック AI や分析サービスに直接アクセスできる環境を提供します。 本記事では、SQL Server のインストールメディアを Amazon Simple Storage Service (Amazon S3) にアップロードし、BYOM インスタンスを起動する方法を説明します。 ソリューション概要 既存の SQL Server ライセンスを再利用するには、ライセンスの配布条件に基づき、ライセンス済みの SQL Server Release to Manufacturing (RTM) メディアを Amazon RDS に提供する必要があります。BYOM では、AWS Console から RTM メディアをアップロードします。開始するには、RTM メディアを Amazon S3 にアップロードし、それに対してフルマネージドの RDS for SQL Server BYOM インスタンスを起動します。AWS License Manager を使用すると、Amazon RDS が BYOM インスタンスを自動的に検出し、vCPU 使用量をレポートするため、SQL Server のライセンス消費を継続的に可視化できます。ライセンスコンプライアンスの責任はお客様にあります。 Amazon RDS Console では、データベース作成ページから RDS for SQL Server BYOM インスタンスを直接作成できます。 ウォークスルー このセクションでは、SQL Server 2022 Standard Edition で BYOM インスタンスを作成する手順を説明します。 前提条件 開始する前に、Software Assurance 付きの有効な SQL Server ライセンス (Standard Edition または Enterprise Edition) があることを確認する必要があります。 ここ からMicrosoft に License Mobility Verification Form を提出する必要があります。 ステップ 1: Visual Studio サブスクリプションから SQL Server RTM メディアをダウンロードする まず、SQL Server の RTM メディアを Amazon RDS がアクセスできる S3 バケットに配置する必要があります。有効なサブスクリプションをお持ちの場合は、Visual Studio サブスクリプションを通じて Microsoft から RTM ISO ファイルをダウンロードできます。ボリュームライセンスで製品を購入した場合は、Microsoft 365 管理センターからもダウンロードできます。 ダウンロードページで「SQL Server 2022」(またはターゲットバージョン) を検索し、SQL Server 2022 Standard を見つけます。言語として English を選択し (他の言語はサポートされていません)、ダウンロード形式として ISO を選択します。 注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。 ステップ 2: Amazon S3 にファイルをアップロードする S3 バケットがまだない場合は、「バケットを作成」を選択して一意の名前を付けます (この例では sqlserver-byom-media を使用します)。次にアップロード画面で「ファイルを追加」を選択し、SQL Server RTM メディアファイルを選択して、「アップロード」を選択して転送を開始します。 ステップ 3: 最初の BYOM インスタンスを作成する RTM メディアが S3 に配置されたら、最初の BYOM インスタンスを作成する準備が整いました。特定のメジャーバージョンに対して初めてインスタンスを起動する際、Amazon RDS Console はバックグラウンドで 2 つのオペレーションを単一のワークフローで処理します。RTM メディアから BYOM エンジンバージョンを作成し (約 20 分)、その BYOM エンジンバージョンに対してインスタンスを起動します。 Amazon RDS Console を開き、左のナビゲーションペインで「データベース」を選択します。 「データベースの作成」を選択します。 「エンジンのオプション」で以下を設定します: エンジンのタイプ : Microsoft SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Standard Edition を選択 ライセンス : bring-your-own-media を選択 メジャーエンジンバージョン : SQL Server 2022 を選択 マイナーエンジンバージョン : ターゲットバージョンを選択 (例 : 16.00.4245.2.v1 ) 「S3 からの SQL Server RTM メディア」 (メジャーバージョンごとに初回のみ表示) で「S3 を参照」を選択 : バケット名 (sqlserver-byom-media) から RTM ファイルを選択し、ISO ファイルを選択します。例 : “Enu_sql_server_2022_standard_core_edition_x64_dvd.iso” DB インスタンス識別子 : 名前を入力します (例 : sqlserver-se-2022-byom) 残りの設定 (DB インスタンスクラス、ストレージ、接続、認証、バックアップ、メンテナンス) は、License Included インスタンスと同様に設定します。 すべての設定を確認し、「データベースの作成」を選択します。 注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。 重要な制限事項と考慮事項 Amazon RDS for SQL Server で BYOM を使用する際は、以下の考慮事項に留意してください。 まず、SQL Server ライセンスが Microsoft のライセンス契約に準拠していることを確認する責任はお客様にあります。AWS License Manager を使用してライセンス使用状況を追跡できますが、ライセンス上限を超過しても AWS がオペレーションをブロックすることはありません。コンプライアンスはお客様の責任です。 次に、RTM ファイルはコアベースライセンスかつ English 言語のみに対応しています。これらの条件を満たさない場合、BYOM エンジンバージョンの作成は失敗します。 最後に、関連する RDS インスタンス、スナップショット、またはバックアップが存在する間は、BYOM エンジンバージョンを削除できない点に注意してください。 クリーンアップ 不要な課金を避けるため、このウォークスルーで作成したリソースが不要になったら削除してください。 RDS インスタンスの削除 : RDS Console → 「データベース」を選択 → インスタンスを選択 → 「アクション」 → 「削除」 S3 オブジェクトとバケットの削除 : S3 Console → バケットを選択 → 「空にする」 → 「削除」 まとめ SQL Server のライセンス投資を守ることと、クラウドで新たな可能性を生み出す AWS の分析およびエージェンティック AI サービスへのデータアクセスパスを確保することを、二者択一にする必要はありません。Amazon RDS for SQL Server の Bring Your Own Media がその道を開きます。Software Assurance をお持ちであれば、Microsoft の License Mobility プログラムを利用して、既存の SQL Server Standard Edition または Enterprise Edition ライセンスをフルマネージドの Amazon RDS 環境に持ち込むことができます。Amazon RDS では、自動バックアップ、モニタリング、パッチ適用、高可用性の恩恵を受けられます。 本記事では、Amazon RDS for SQL Server で Bring Your Own Media (BYOM) を使い始める方法を説明しました。ウォークスルーでは、Release to Manufacturing (RTM) ファイルの S3 へのアップロードと BYOM エンジンバージョンの作成を取り上げました。 SQL Server の業務データとエージェンティック AI の間にあったライセンスの壁は、もはや存在しません。Amazon RDS for SQL Server の Bring Your Own Media サポートの詳細については、以下のリソースをご参照ください : Amazon RDS for SQL Server ドキュメント AWS License Manager ドキュメント create-custom-db-engine-version CLI リファレンス  BYOM は、Amazon RDS for SQL Server がサポートされているすべての商用 AWS リージョンで利用可能です。最新の利用可能状況については、 Amazon RDS for SQL Server の料金ページ をご確認ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Srikanth Katakam Srikanth は AWS のシニアデータベースエンジニアで、Oracle、MySQL、PostgreSQL、Amazon Aurora、Microsoft SQL Server、Amazon Redshift などのデータベース技術、および Oracle Apps や Informatica を含むデータ統合プラットフォームにおいて 10 年以上の経験を持っています。Amazon RDS for SQL Server や Amazon RDS Custom for SQL Server を含む Amazon RDS の商用データベースエンジンを専門としています。AWS 上の SQL Server に関する深い専門知識を活かし、AWS のお客様の多様なニーズに応える機能設計に情熱を注いでいます。 Colleen Betik Colleen は AWS のシニアテクニカルプロダクトマーケティングマネージャーで、Amazon Relational Database Service を担当しています。新しい製品や機能のローンチに向けた差別化されたメッセージングとコンテンツの構築をチームと共に推進しています。Southern Methodist University でマーケティングの B.B.A.、University of Virginia で Global Commerce の M.S.、ESADE で Global Strategic Management の MSc を取得しています。

「自治体のためのクラウドコスト最適化」シリーズについて 自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行後も構成の見直しをすることでコストを最適化することができます。 ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、 自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態 を目標にしています。 ただしコスト最適化は、マネジメントコンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。 # タイトル 扱う領域 自治体職員 ベンダー 情報政策 担当 財政担当 運用管理 補助者 ASP ① 定期レビューで回すコスト最適化の手順 日々の運用 ● ○ ● ○ ②-1 運用管理補助者との協働体制を調達仕様書に落とし込む（本記事） 調達・契約 ● ○ ○ ○ ②-2 AI Agent でコスト分析を自動化する（公開予定） 運用の効率化 ● ○ ○ ③ 予算要求・執行・決算の実務（公開予定） 予算・会計 ○ ● ④ 20業務の最適化設計と実践（公開予定） 基盤の設計 ○ ● ● 補足： ②-2、③、④は今後公開予定です。公開時にはこの表からリンクします。 凡例 ： ● は主な対象、 ○ は関連する範囲で参考になる読者です。 情報政策担当 ：情報システム部門でクラウド環境の運用を所管する職員 財政担当 ：予算要求・執行・決算の手続きを担当する職員 運用管理補助者 ：ガバメントクラウドの運用管理を自治体から受託する事業者 ASP ：業務システム（パッケージ）を提供し、その動作保証を担う事業者 どこから読むか ：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になりますが、①も前提知識としてご確認ください。 本記事について 本記事では、コスト最適化を「継続的な取組み」にするため、契約上、どのような裏付けをとるべきか、具体的なアクションを記載しています。担当者の熱意に頼った取り組みは、異動や事業者の変更で途切れるリスクがあります。何を・どの頻度で・どのような形式で実施するかを調達仕様書に記載すれば、担当者が変わっても同じ水準で継続できます。 補足： 本記事の記載例は、 シリーズ① で扱うコスト最適化の実務（マネジメントコンソールで何を確認し、どのレポートを受託者に依頼するか）を要求水準の形に書き換えたものです。そのため随所で該当箇所を参照しています。 目次 1. はじめに 1.1 FinOps とは 1.2 本記事の目的とスコープ 1.3 対象とする利用方式 2. 仕様書に盛り込む3つの要件 2.1 3つの要件 2.2 登場人物と役割 3. 調達仕様書への織り込み方 3.1 クラウド利用実績の可視化 3.2 クラウド利用料の削減提案 3.3 翌事業年度の改善提案・目標設定 3.4 その他 4. まとめ 1. はじめに 1.1 FinOps とは FinOps は、クラウドの利用状況を可視化し、コストを継続的に最適化していく取り組みを指します。「Finance（財務）」と「Operations（運用）」を組み合わせた言葉で、技術部門・財務部門・調達部門が連携してクラウド費用を管理する考え方です。 クラウドではリソースの追加・削除が随時可能ですが、これは裏返せば 稼働させ続けている限り費用が発生し続ける ことを意味します。検証用に作成したサーバーの停止忘れ、業務量の増加に伴うストレージの自然増、機能追加に伴うサーバー追加。いずれも少額ずつですが、放置すれば積み上がります。 そのため、クラウドでは一度きりの削減施策ではなく、次のサイクルを回し続ける必要があります。 段階 内容 対応者 見える化 利用状況とコストを可視化し、増減を把握する 受託者が情報提供、担当課が確認 分析 増減の要因を特定し、削減余地を洗い出す 受託者 改善提案 削減施策を費用対効果とともに提示する 受託者 実行 担当課の判断を経て施策を実施し、効果を測定する 受託者（ASPの確認が必要な場合あり） このサイクルを回すには、担当課だけでも受託者だけでも完結しません。 どちらが何を、どの頻度で、どのような形式で行うかを事前に取り決めておく必要があります。 その取り決めを口頭の依頼ではなく調達仕様書に明記し、契約事項として織り込むことが重要です。 補足： FinOps の実践方法そのものは シリーズ① で扱っています。本記事は、その実践を組織的に継続させるための「契約上の裏付け」をどう用意するかに焦点を当てています。 1.2 本記事の目的とスコープ 自治体が運用管理補助事業者への調達仕様書に FinOps 要件をどう書くかについて、デジタル庁が提供する GCAS ガイド「継続的運用経費最適化(FinOps)ガイド」に、 別紙1-1「調達仕様書の追加文言案（ガバメントクラウド運用管理補助委託料）」 という文言案（参考例）が示されています。本記事は、この文言案を実際の調達仕様書のどこに、どのような粒度で書けばよいかを具体化するものです。 仕様書に書かれた業務は、受託者にとって正当な業務範囲として計画・実行できます。逆に書かれていなければ、契約外の作業を依頼する形になり、受託者は都度の判断を迫られます。「言った・言わない」のすれ違いも起きます。クラウド利用料の最適化は、契約期間が始まってから慌てて検討するのではなく、 調達仕様書の段階で盛り込んでおくことで、契約開始後すぐに着手できます。 文言案は2つの費目に分かれており、本記事が扱うのは前者です。 費目 本記事での扱い 内容 クラウド利用料の継続的な削減 対象 (1) 可視化、(2) 削減提案、(3) 改善提案・目標設定 運用管理補助委託料の継続的な削減 対象外 本記事では扱いません 1.3 対象とする利用方式 本記事では、以下の利用方式を対象とします。 共同利用方式（アカウント分離方式） 単独利用方式 補足： 共同利用方式のうち「ネットワーク分離方式」「アプリケーション分離方式」については、コスト管理の権限構成が異なるため、本記事では割愛します。利用方式の区分・名称は本記事作成時点のものであり、今後変更される場合があります。 2. 仕様書に盛り込む3つの要件 2.1 3つの要件 文言案が求めているのは、次の3つです。 # 要件 頻度 概要 (1) クラウド利用実績の可視化 随時（担当課の求めに応じ） クラウドリソースの利用状況及びコスト推移の詳細情報をマネジメントコンソール等から取得し、担当課に提供する。加えて、予算超過の兆候を早期に把握するためのアラート機能等を設定し、予実管理を支援する (2) クラウド利用料の削減提案 定期的（少なくとも3か月に一度） 各CSPが提供するレコメンデーションサービスや過去の利用実績等を活用し、クラウド利用料の削減に向けた改善提案を行う。提案内容は担当課と共有し、必要に応じて対応を実施する (3) 翌事業年度の改善提案・目標設定 年次 クラウド利用料の最適化に向けた改善活動の一環として、翌事業年度における削減目標を担当課と協議の上で検討する。目標値はレコメンデーションサービスや過去の利用実績等を踏まえて合理的に算定し、翌事業年度のKPI（達成指標）として活用する これらは独立した要件ではなく、相互につながった 継続的な改善サイクル を形成しています。(1)の可視化で現状を把握し、(2)の削減提案で改善策を立てて実行し、(3)の目標設定で次年度の水準を定める、という循環です。 図: 3つの要件が形成する改善サイクル 補足： このサイクルは PDCA（Plan-Do-Check-Act）の考え方に通じるものですが、3つの要件がそのまま PDCA の4段階に対応するわけではありません。例えば (1)可視化は現状把握（Check に相当）と施策後の効果測定の両方で使われ、施策の実行（Do）は3要件とは別に、担当課の判断を経て行われます。本記事では厳密な段階分けよりも、「把握 → 提案 → 実行 → 次期目標」が途切れず続くことを重視して「改善サイクル」と呼んでいます。 次章では、この3要件を調達仕様書のどこに・どのような粒度で記載するかを、条文例とともに見ていきます。 補足： 上表は本記事作成時点の文言案の内容を筆者が要約したものです。正確な文言・最新の内容は原文（出典: デジタル庁「継続的運用経費最適化(FinOps)ガイド」別紙1-1）をご確認ください。 2.2 登場人物と役割 本記事における登場人物と役割は以下の通りです。 登場人物 本記事での略称 役割 自治体 情報政策担当 担当課 調達仕様書の作成、FinOps のオーナーシップ 運用管理補助事業者 受託者 可視化・分析・提案の実行、レポート提供 自治体 財政担当 財政課 予算管理、コスト情報の活用（間接的） オーナーシップを担当課が持つ理由： これは法令等で定められた役割分担ではありませんが、実務上はこの整理がうまく機能します。「このサーバーは夜間停止してよいか」「この検証環境は年度末まで残す必要があるか」を判断できるのは、業務の実情を知る担当課だけです。受託者は技術的な選択肢を示せますが、業務上の可否までは判断できません。受託者が契約期間ごとに変わり得ることも理由の一つで、オーナーシップを受託者側に置くと事業者が交代した時点で取り組みが途切れます。 ただし、担当課がオーナーシップを持つには、判断に必要な情報が手元に届いていることが前提になります。その情報提供を要求水準として書くのが、次章以降の内容です。 3. 調達仕様書への織り込み方 本章では、第2章の3つの要件（可視化・削減提案・目標設定）を、調達仕様書にどのように記載するかを条文例とともに解説します。 調達仕様書上の位置づけ 以降の記載例は、調達仕様書に「継続的運用経費最適化（FinOps）の実施」として独立した一つの章を設け、その中に並べる想定で書いています。冒頭に総則を置き、続く各条で本章の 3.1〜3.4 に対応する要件を規定する構成です。 第○章 継続的運用経費最適化（FinOps）の実施 X.1 総則 受託者は、FinOpsの原則に基づき、クラウド利用状況の可視化及び 分析を通じて、クラウド利用料の削減に向けた継続的な改善活動を 実施すること。提案にあたっては費用対効果を定量的に示すもの とする。 X.2 クラウド利用実績の可視化 ......... 3.1 の記載例 X.3 クラウド利用料の削減提案 ......... 3.2 の記載例 X.4 翌事業年度の改善提案・目標設定 ... 3.3 の記載例 X.5 その他 ........................... 3.4 の記載例 既存の調達仕様書に運用管理補助の業務要件を記載する章がある場合は、その中の一節として組み込む形でも構いません。重要なのは章立ての形式ではなく、可視化・削減提案・目標設定・報告体制の4点が漏れなく規定されていることです。 補足： 以下の記載例は 一例 です。自治体の実情に合わせて項目・数値・頻度を調整してください。また、記載例は 次期調達の仕様書への反映を前提 としています。 3.1 クラウド利用実績の可視化 記載のポイント （要件の詳細は 2.1 を参照） コスト情報の提供: クラウドリソースの利用状況・コスト推移を取得して担当課に提供 予実管理の支援: アラート設定による予算超過の早期検知 調達仕様書への記載例 ： X.X クラウド利用実績の可視化 (1) 受託者は、以下の情報をクラウド管理画面等から取得し、月次で担当課に提供すること。 提供は担当課が開催する定例会（月次）の場で行うものとし、担当課から求めがあった場合は、 随時、同様の情報を提供すること。 ア. サービス別月次コスト推移 （直近12か月分。利用開始から12か月に満たない場合は利用開始以降の全期間分） イ. 前月比・前年同月比の増減率（前年同月の実績がある場合） ウ. コスト上位5サービスの内訳と増減要因の簡易分析 (2) 受託者は、クラウド利用料の予算超過を早期に把握するため、以下のアラートを設定し、 担当課に通知する仕組みを構築すること。 ア. 月次予算の80%到達を検知した時点での通知 イ. 月次予算の100%到達を検知した時点での通知 ウ. 通常の利用パターンから逸脱したコスト急増を検知した場合の通知 （検知条件はCSPの標準機能で実現可能な範囲で担当課と協議の上定める） (3) 提供形式は、担当課と協議の上で定めるものとする。 （例：レポート（PDF/Excel）、クラウド管理画面のダッシュボード共有、メールによるサマリー通知 等） (4) 受託者は、担当課の職員がクラウド管理画面においてコスト関連情報を自ら確認できるよう、 閲覧権限（参照のみの権限）を付与し、必要な設定を行うこと。 対象とする機能及び付与する職員の範囲は、担当課と協議の上で定めるものとする。 実務上のポイント ： ポイント 解説 随時対応について 文言案は随時対応を求めています。記載例では随時対応の義務を維持したまま、月次の定期提供を組み合わせています。定期提供があることで随時依頼の件数を抑えられ、受託者側も業務を計画しやすくなります。 定例会との関係 記載例 (1) では、情報提供の場を担当課が開催する月次の定例会に紐づけています。これは シリーズ① のレビュー会議に相当します。報告のためだけに別途資料を作成・送付する運用にすると受託者の稼働が増えるため、会議の場で画面や資料を共有して完結させる形が実務的です。定例会の頻度を見直す場合は、この条項の「月次」も合わせて協議してください（3.4 参照）。 AWS での具体的な実現手段 AWS Cost Explorer によるコスト推移確認、AWS Budgets による予算アラート設定が該当します。コスト急増の検知には AWS Cost Anomaly Detection（機械学習による異常検知）が利用できます。なお、コストデータの更新は1日数回であり、通知はリアルタイムではない点にご留意ください。詳細な操作手順はシリーズ① をご参照ください。 担当課自身によるマネジメントコンソール確認 記載例 (4) は、職員自身がマネジメントコンソールでコストを確認できる状態を作るための条項です。受託者のレポートと自身の確認を突き合わせられるため、報告内容の妥当性をその場で確かめられます。職員自身での確認が定着すれば、受託者の定期報告の頻度を減らして委託料を抑える見直しにもつながります（シリーズ① 2.4 参照）。 付与する権限は 参照のみ とし、リソースを変更できる権限は含めないことが基本です。対象機能は シリーズ① で扱う3つ（AWS Cost Explorer、AWS Cost Optimization Hub、AWS Compute Optimizer）を想定して協議するとよいでしょう。なお、コスト最適化ハブは利用開始時にオプトイン（有効化）が必要なため、「必要な設定を行うこと」に含めています。 「月次予算」の設定 アラートの基準となる月次予算は、年間予算の按分や過去実績をもとに、担当課が受託者と協議して設定します。財政課とも整合を取っておくと、予算執行管理（シリーズ③）との連携がスムーズです。 3.2 クラウド利用料の削減提案 記載のポイント （要件の詳細は 2.1 を参照） 分析手段: CSP（クラウドサービス提供事業者）のレコメンデーションサービス＋過去の利用実績を活用 頻度: 少なくとも3か月に一度 プロセス: 担当課と共有し、合意の上で実施 補足： なお、コスト確認・推奨事項のレビュー自体は シリーズ① の手順に沿って定期的に実施し、本節の削減提案はその蓄積をもとに作成します。 調達仕様書への記載例 ： X.X クラウド利用料の削減提案 (1) 受託者は、クラウド利用料の削減に向けた改善提案を、少なくとも3か月に一度、担当課に提出すること。 なお、新たな削減余地がない場合は、その旨の報告及び既存施策の効果測定の報告をもって代えることができる。 (2) 提案にあたっては、以下の情報源を活用すること。 ア. CSPが提供するコスト最適化の推奨機能 イ. 過去の利用実績データに基づくトレンド分析 ウ. 業務特性を踏まえた稼働時間・リソースサイズの適正化分析 (3) 提案書には以下の項目を含めること。なお、提案にあたっては費用対効果を定量的に示すものとする。 ア. 現状のコスト構造と課題 イ. 削減施策の内容（具体的な変更内容） ウ. 期待される削減効果（月額○○円または年間○○%のように、金額または割合で定量的に示すこと） エ. 施策の実施に要する作業内容及び工数の見込み オ. 想定される業務影響及びリスク（性能への影響、停止を伴う作業の有無等） カ. 実施の優先度（「削減効果」及び「実施の容易さ」の2軸で評価し、その理由を付すこと） キ. ASPとの協議が必要な場合は、協議に必要な資料 （対象リソース、想定される変更内容、コストインパクトの概算） (4) 担当課は提案内容を確認し、実施の可否を判断する。受託者は担当課の承認を得た施策のうち、 受託者が管理権限を有する範囲のものを実施する。ASPとの調整が必要な施策については、担当課と協議の上、 必要な範囲でASPへの情報提供及び協議の場の設定に協力すること。 (5) 受託者は、CSPが提供するコスト最適化の推奨機能が示す推奨事項について、 対応状況を以下の区分で整理し、担当課に報告すること。 ア. 対応済み（実施日・削減実績） イ. 対応予定（実施時期・必要な調整事項） ウ. 対応しない（業務要件・技術制約・ASPの動作保証等の理由を付記） (6) 削減施策の実施後、受託者は効果測定を行い、実績を担当課に報告すること。 実務上のポイント ： ポイント 解説 報告の頻度 記載例は文言案の頻度をそのまま採用しています。一方 シリーズ① では、着手当初は月次のレビュー会議で削減提案と対応状況を扱い、落ち着いてきたら頻度を減らす進め方を紹介しています。仕様書上の義務は「少なくとも3か月に一度」を最低ラインとして固定し、運用上は月次のレビュー会議の中で提案を扱う、という二段構えにすると、委託料を固定的に増やさずに シリーズ① の運用と整合します。 費用対効果の定量化 文言案の冒頭に「費用対効果を定量的に示すものとする」とあります。これを記載例 (3) の柱書きと (3)ウ に反映しています。「コストを削減できます」という定性的な提案では判断できないため、金額・割合での明示を求めます。あわせて (3)エ で作業工数の見込みも求めることで、「削減額は大きいが作業工数も大きい」施策を正しく評価できます。 削減提案の優先度 提案が多数出た場合に備え、記載例 (3)カ で「削減効果」と「実施の容易さ」の2軸による優先度評価を求めています。この2軸は シリーズ① 3.2 で解説するコスト最適化ハブの推奨事項の並べ方（推定削減額と実装作業の負荷）と対応しており、受託者がツールの出力をそのまま活用しやすい形にしています。 業務影響の記載を求める理由 記載例 (3)オ で業務影響とリスクの記載を求めています。作業負荷が低い施策であっても業務影響がないとは限らないためです（例：インスタンスタイプの変更は操作自体は短時間ですが、パッケージの動作保証に関わります）。担当課が可否を判断するには、削減額と作業工数だけでなく業務影響の情報が必要です。 「対応しない」理由の記録 記載例では推奨事項の対応状況を「対応済み・対応予定・対応しない」の3区分で報告させ、3つ目については理由の付記を求めています（(5)ウ）。業務要件上サイズを下げられない、ASP の動作保証が得られないなど理由が明確であれば、監査や議会説明の際の根拠になります。理由が記録されていないと、次回の報告で同じ推奨事項について議論を繰り返すことになります。 業務アプリケーションの動作保証との関係 インスタンスタイプやストレージ種別の変更は、業務アプリケーション（パッケージ）の動作保証に関わるため、ASP の確認が前提となります。運用管理補助者が変更操作を行える場合でも、ASP が推奨しない構成に変更すると保守の対象外となるおそれがあります。(3)エ・(4)でASPとの協議に関する規定を置いているのはこのためです（役割分担の詳細は シリーズ① 1.2 参照）。 AWS での具体的な実現手段 AWS Cost Optimization Hub が推奨事項を推定削減額つきで一覧表示します（利用にはオプトインが必要です）。AWS Compute Optimizer はインスタンスサイジング等の推奨を提供します。詳細は シリーズ① 第3章をご参照ください。 3.3 翌事業年度の改善提案・目標設定 記載のポイント （要件の詳細は 2.1 を参照） 時期: 年度末（翌事業年度の計画策定時） 内容: 削減目標の設定＋改善提案 根拠: レコメンデーション＋実績に基づく合理的な算定 調達仕様書への記載例 ： X.X 翌事業年度の改善提案・目標設定 (1) 受託者は、毎事業年度の第4四半期（1月〜3月）に、担当課の求めに応じ、 翌事業年度のクラウド利用料に関する以下の資料を提出すること。 ア. 当該年度の削減実績サマリー（施策別の削減額・達成率） イ. 翌事業年度の削減目標案（金額または割合） ウ. 目標達成のための具体的施策と実施スケジュール案 (2) 削減目標は、以下に基づき合理的に算定すること。 ア. CSPのレコメンデーションサービスが示す最適化余地 イ. 過去12か月の利用実績とコスト推移 (3) 担当課と受託者は、目標値について協議の上で合意し、合意内容を書面で記録すること。 実務上のポイント ： ポイント 解説 KPI の活用 設定した目標値は、毎月の削減提案（3.2）における進捗確認の指標として活用します。 初年度の特殊性 ガバメントクラウド移行直後は実績データが少なく、目標設定が困難な場合があります。仕様書には「利用開始後6か月未満の場合は、目標設定に代えて現状分析レポートの提出をもって代替できる」等の柔軟な規定を設けることを推奨します。 3.4 その他 上記(1)〜(3)の運用を支える体制面の要件として、以下も調達仕様書に盛り込むことを推奨します。 調達仕様書への記載例 ： X.X その他 (1) 受託者は、担当課が実施する定期報告会（開催頻度は担当課と受託者の協議により定める）に出席し、 クラウド利用実績及び削減提案の内容を報告すること。 (2) 受託者は、削減提案の実施にあたり、ASPとの調整が必要な場合、 担当課と協議の上、必要な範囲でASPとの連携・調整を行うこと。 実務上のポイント ： ポイント 解説 定期報告会の位置づけ シリーズ① で解説するレビュー会議がこれに該当します。シリーズ① では、最適化に着手した当初は月次で開催し、最適化が進んだら頻度を減らす・時間を短くするといった見直しを推奨しています（シリーズ① 2.4）。記載例で開催頻度を固定せず協議事項としているのはこのためです。3.1〜3.3 のレポート・提案を、この場で担当課と共有・協議する運用にすると実務が回りやすくなります。 ASPとの連携範囲の明確化 受託者とASPは異なる事業者であり、直接の契約関係がないことが一般的です（同一事業者やグループ会社が両方を担うケースもあります）。「調整」の範囲（情報提供のみか、協議の場の設定まで含むか）を仕様書上で明確にしておくことで、受託者・ASP双方が対応しやすくなります。受託者に求める役割が過度な負担（ASPへの指示権限を伴うもの等）にならないよう、自治体側で委託内容を精査することを推奨します。 4. まとめ 本記事では、運用管理補助者への調達仕様書に FinOps の観点から盛り込むべき事項をまとめました。 3つの要件は、(1)可視化で現状を把握し、(2)削減提案で改善策を立てて実行し、(3)目標設定で次年度の水準を定めるという 継続的な改善サイクル を形成しています。このサイクルを回し続けるには、担当課と受託者のどちらが何をするかを事前に取り決めておく必要があり、その取り決めを調達仕様書に明記するのが本記事の主題でした。 条文例で具体化したのは、提供する情報の項目、報告の頻度、提案書に含めるべき項目です。「コスト削減に努めること」という書き方では、受託者は何をすべきか判断できず、担当課も履行状況を確認できません。コスト削減につながる具体的な活動を継続的なサイクル（可視化→削減提案→目標設定）に則り記載することで、運用管理補助者と同じ目線でコスト削減に取り組むことができます。 ただし、要求水準を厚くすれば受託者の稼働が増え、運用管理補助委託料に跳ね返ります。本記事の条文例をそのまま採用するのではなく、活動の実効性、自治体の規模と体制に照らして項目・頻度を削ってください。職員自身がマネジメントコンソールで確認できる範囲が広がれば、受託者に求める報告を削減できます（3.1・シリーズ① 2.4 参照）。 シリーズ他記事との接続 やりたいこと 参照先 受託者に依頼するレポートの内容を具体的に知りたい シリーズ① 2.4・2.5 レビュー会議の進め方を知りたい シリーズ① 第2章 AI Agent を活用してコスト分析を効率化したい シリーズ②-2（公開予定） 予算要求への反映方法を知りたい シリーズ③（公開予定） 受託者（運用管理補助事業者）として具体的に何をすべきか知りたい シリーズ④（公開予定） 免責事項 : 本記事の内容は情報提供を目的としたものであり、法的助言を構成するものではありません。また、本記事はデジタル庁・GCASの公式見解を示すものではなく、GCASガイドの引用・要約は本記事作成時点の内容に基づきます（ガイドは改訂される場合があります）。調達仕様書の記載例は参考情報であり、その使用により生じた結果について保証するものではありません。実際の調達にあたっては、各自治体の規定に照らし、 自治体内の 契約担当部門・法務部門にご確認の上でご利用ください。AWS サービスの料金・機能は変更される場合がありますので、最新の情報は AWS 料金ページ をご確認ください。 ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、 AWS ガバメントクラウド相談窓口 までお問い合わせください。 筆者について Hitoshi Ebiko 蛯子 准吏（Hitoshi Ebiko）は、パブリックセクターで自治体・デジタル庁を担当しています。住民・自治体の代弁者＝DXアドボケートとして、クラウドやAIを活用した業務変革の実現、より住民に寄り添った持続可能な行政サービスの未来の実現に取り組んでいます。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。