Amazon Web Services ブログ
自治体のためのクラウドコスト最適化 ②-1：運用管理補助者との協働体制を調達仕様書に落とし込む
「自治体のためのクラウドコスト最適化」シリーズについて
自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行後も構成の見直しをすることでコストを最適化することができます。
ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態を目標にしています。
ただしコスト最適化は、マネジメントコンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。
| # | タイトル | 扱う領域 | 自治体職員 | ベンダー | ||
|---|---|---|---|---|---|---|
| 情報政策 担当 |
財政担当 | 運用管理 補助者 |
ASP | |||
| ① | 定期レビューで回すコスト最適化の手順 | 日々の運用 | ● | ○ | ● | ○ |
| ②-1 | 運用管理補助者との協働体制を調達仕様書に落とし込む（本記事） | 調達・契約 | ● | ○ | ○ | ○ |
| ②-2 | AI Agent でコスト分析を自動化する（公開予定） | 運用の効率化 | ● | ○ | ○ | |
| ③ | 予算要求・執行・決算の実務（公開予定） | 予算・会計 | ○ | ● | ||
| ④ | 20業務の最適化設計と実践（公開予定） | 基盤の設計 | ○ | ● | ● | |
補足： ②-2、③、④は今後公開予定です。公開時にはこの表からリンクします。
凡例：●は主な対象、○は関連する範囲で参考になる読者です。
- 情報政策担当：情報システム部門でクラウド環境の運用を所管する職員
- 財政担当：予算要求・執行・決算の手続きを担当する職員
- 運用管理補助者：ガバメントクラウドの運用管理を自治体から受託する事業者
- ASP：業務システム（パッケージ）を提供し、その動作保証を担う事業者
どこから読むか：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になりますが、①も前提知識としてご確認ください。
本記事について
本記事では、コスト最適化を「継続的な取組み」にするため、契約上、どのような裏付けをとるべきか、具体的なアクションを記載しています。担当者の熱意に頼った取り組みは、異動や事業者の変更で途切れるリスクがあります。何を・どの頻度で・どのような形式で実施するかを調達仕様書に記載すれば、担当者が変わっても同じ水準で継続できます。
補足： 本記事の記載例は、 シリーズ① で扱うコスト最適化の実務（マネジメントコンソールで何を確認し、どのレポートを受託者に依頼するか）を要求水準の形に書き換えたものです。そのため随所で該当箇所を参照しています。
目次
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 ガバメントクラウド相談窓口 までお問い合わせください。