今年はGameDayを楽しんだ。
2026-06-25からの2日間、AWS Summit Tokyo 2026 が開催された。 Day01 の GameDay に参加した。初めてのGameDayだった。 当日の短い時間、チームを共にした仲間には感謝を伝えたい。
テーマは Frugal Architect。クラウドアーキテクチャにおいて、コストを後付けの削減対象ではなく、設計初期から扱うべき制約・品質特性として捉える考え方である。
これはGameDayの攻略記事ではない
最初に断っておくと、この記事は GameDay の攻略記事ではない。
ここで書きたいのは、GameDay を通じて自分の中で言語化が進んだ、Frugal Architect の SIer 的な読み替えである。
一言でいえば、Frugal Architect は「クラウド費用を下げる小技集」ではなかった。
むしろ、SIer の現場で曖昧になりがちな、設計・見積・運用・改善の接続を問い直すための言葉だった。
Frugal Architectは「節約家」ではない
Frugal という言葉は、直訳すると「倹約的な」というニュアンスになる。
しかし、ここでいう Frugal Architect は、単に安い構成を選ぶ人ではない。
安くするだけなら簡単だ。冗長性を削る。監視を削る。ログを削る。性能余裕を削る。人間の運用で何とかする。そうすれば、短期的な請求額は下がるかもしれない。
しかし、それはアーキテクチャではなく、ただの我慢である。
Frugal Architect が扱っているのは、コストと価値の対応関係だと思う。
- そのコストは、どのビジネス価値を支えているのか
- その冗長性は、どのリスクを下げているのか
- その監視は、どの意思決定を可能にしているのか
- その性能余裕は、どの体験品質を守っているのか
- その運用負荷は、誰の時間を消費しているのか
つまり、支出を消すのではなく、支出に説明責任を持たせる。
SIer の言葉に寄せるなら、これは「コストを設計根拠に接続する」活動である。
SIerの現場では、コストが設計の外側に置かれやすい
SIer のプロジェクトでは、コストという言葉は頻繁に出てくる。
見積、予算、稟議、契約、工数、保守費、クラウド利用料。むしろ毎日のように出てくる。
それにもかかわらず、アーキテクチャ設計の場面では、コストが本当の意味で設計要件になっていないことがある。
性能要件は書かれる。
可用性要件も書かれる。
セキュリティ要件も書かれる。
バックアップ要件も書かれる。
しかし、コスト要件は「できるだけ安く」「予算内で」「従量課金に注意」といった粒度で止まりやすい。
これでは設計判断に使えない。
「できるだけ速く」とだけ書いても性能設計ができないのと同じように、「できるだけ安く」ではコスト設計はできない。
本来は、少なくとも次のような形で設計対象にする必要がある。
- 通常時の月額ランニングコストの目安
- 利用量増加時に、どの費目がどのように増えるか
- コスト増加を許容する条件
- コストを下げるために犠牲にしてよいもの、いけないもの
- 監視・ログ・バックアップ・冗長化に払う意味
- リリース後に見直すタイミングと責任者
これは、単なるクラウド料金の話ではない。
設計判断を、後から説明可能にするための非機能要件である。
「初期費用」と「運用費」を分けるだけでは足りない
SIer の見積では、初期構築費と運用保守費を分けて考えることが多い。
それ自体は必要な整理だ。
しかし、クラウドアーキテクチャでは、もう一段踏み込む必要がある。
クラウドのコストは、構築時に確定するものではない。使われ方、データ量、アクセスパターン、ログ量、バックアップ保持、運用監視の粒度によって変化し続ける。
つまり、クラウド費用は「見積時に決める金額」ではなく、「運用中に観測し、調整し続ける変数」である。
ここを固定費の感覚で扱うと、二つの事故が起きる。
一つは、最初から過剰に固く作ってしまうこと。
もう一つは、最初は安く見えていたものが、運用中に静かに膨らむこと。
どちらも、SIer 的にはよくある。
前者は「安全側に倒した設計」と呼ばれる。後者は「想定外の利用増」と呼ばれる。
しかし Frugal Architect の観点では、どちらも観測と制御の不足である。
FinOpsは上位概念、Frugal Architectは実装言語
考え直すと、FinOps は Frugal Architect よりも上位の抽象概念だと思う。
FinOps は、クラウドの利用・コスト・価値を、技術、事業、財務、運用の横断で継続的に整えるためのマネジメント体系である。コストの可視化、タグ付け、責任分界、予算管理、利用状況の分析、組織的な意思決定。これらは明らかに FinOps の領域にある。
一方で Frugal Architect は、その思想をアーキテクチャの中に落とすための実装言語に近い。
FinOps が「クラウド利用を経営可能にするための運営思想」だとすれば、Frugal Architect は「その思想を設計判断に変換するための技術者の言葉」である。
どのコンポーネントを同期処理にするのか。
どこを非同期に逃がすのか。
どこにキャッシュを置くのか。
どこまでをマネージドサービスに任せるのか。
どのログを即時検索可能にし、どのログを長期保管に回すのか。
どのリスクにはお金を払い、どのリスクは運用で受けるのか。
こうした判断は、請求書を見てからでは遅いことが多い。
ただし、現実の多くの組織では、FinOps がまだ標語や号令に留まっているのではないかとも感じる。
「クラウドコストを最適化しましょう」
「利用部門にコスト意識を持たせましょう」
「タグを付けましょう」
もちろん、どれも間違っていない。けれど、そこから先の設計判断に接続されなければ、FinOps はスローガンで終わる。
SIer の言葉でいえば、Frugal Architect は「運用費を含んだアーキテクチャ設計」であり、「FinOps を設計・構築・保守の現場に降ろすための非機能設計」でもある。
コストは非機能要件である
Frugal Architect の第一のメッセージは、コストを非機能要件として扱うことだと理解している。
これは SIer にとってかなり重要な言い換えである。
なぜなら、非機能要件に入った瞬間に、コストは単なる購買・契約・請求の話ではなくなるからだ。
- 要件定義で扱う
- 設計レビューで扱う
- テスト観点に入れる
- 運用設計に入れる
- 受入基準に接続する
- 改善サイクルに乗せる
この流れに入る。
「コストは大事です」と言うだけでは弱い。
「コストは非機能要件です」と置くことで、設計成果物の中に居場所ができる。
例えば、次のような問いを非機能要件定義に入れられる。
- このシステムの単位コストは何か
- 利用量が2倍になったとき、コストも2倍になるのか、それ以上に増えるのか
- コスト異常を誰が、どの頻度で、どの指標で検知するのか
- コスト削減時に守るべきSLOは何か
- 平常時と繁忙時で、同じ構成を維持する必要があるのか
- 監査・調査・障害対応のために、どのデータをどの粒度で保持するのか
こういう問いは、クラウドアーキテクトだけで閉じない。
業務側、運用側、セキュリティ側、契約側と一緒に決める必要がある。
だからこそ、SIer が得意とする合意形成の領域でもある。
「高い・安い」ではなく「説明できる・できない」
SIer の現場では、コストレビューが「高いか安いか」の話になりやすい。
もちろん予算は重要だ。
しかし、より本質的なのは「説明できるか」だと思う。
高くても説明できるコストがある。
安くても危険なコスト削減がある。
たとえば、ある冗長構成に追加コストがかかっていたとしても、それが事業停止リスクを下げるためのものなら説明できる。逆に、誰も使っていないリソースや、目的を失ったログ保持に費用がかかっているなら、金額が小さくても説明できない。
Frugal Architect 的な設計レビューでは、次のような問いが効く。
- この費用は、どのリスクを下げているのか
- この費用は、どの顧客体験を守っているのか
- この費用は、どの運用作業を減らしているのか
- この費用は、将来の変更容易性に寄与しているのか
- この費用が増えたとき、増えた理由を追跡できるのか
金額そのものよりも、因果関係を追えること。
それが、クラウド時代のコスト設計の出発点なのだと思う。
「落とせない」がオーバースペックの免罪符になっていないか
もう一つ、SIer として避けて通れない問いがある。
「システムが落とせない」という言葉が、オーバースペックを正当化する免罪符になっていないか、という問いである。
もちろん、落としてはいけないシステムはある。
社会インフラ、決済、医療、セキュリティ、基幹業務、顧客接点。止まれば事業や生活に大きな影響が出るものに対して、可用性へ投資するのは当然である。
問題は、「落とせない」の中身が分解されないまま、すべてのコンポーネントに同じ強度を求めてしまうことだ。
- どの機能が止まると、本当に事業影響が出るのか
- どの時間帯に止まると困るのか
- 何分までなら許容できるのか
- 劣化運転や手動代替は可能なのか
- 読み取りだけ継続できればよいのか
- 復旧時間とデータ損失のどちらを優先するのか
- 全機能を同じ可用性レベルにする必要があるのか
ここを詰めないまま「落とせない」と言うと、設計は安全側に倒れる。
安全側に倒れること自体は悪ではない。しかし、そのコストはどこかに転嫁される。
インフラ費用として乗る。運用費として乗る。保守費として乗る。最終的には、サービス価格や顧客負担として乗る。
つまり、説明されない可用性は、説明されない価格上昇につながる。
Frugal Architect 的に問うべきなのは、「高可用性にするな」ではない。
「その高可用性は、どの業務価値を守るためのものか」
「そのために、利用者や事業はどこまで払う意思があるのか」
「同じ目的を、より安い構成・運用・縮退設計で満たせないか」
この問いである。
可用性は聖域ではない。非機能要件であり、トレードオフの対象である。
だからこそ、削ってはいけない可用性と、過剰に盛られている可用性を分けて言語化する必要がある。
削るも勇気、削らないもまた勇気
可観測性は重要である。
しかし、その前に必要なのは、何を削り、何を削らないかを判断する姿勢だと思う。
削るには勇気がいる。
長く動いてきた構成を見直す。余裕を持たせていたリソースを縮める。過剰な保持や過剰な冗長性をやめる。使われていないものを消す。これらは、単にコストを下げる作業ではない。これまで暗黙に安心材料として扱われていたものに対して、「本当に必要か」と問う作業である。
一方で、削らないにも勇気がいる。
コスト削減の号令が強いと、数字上すぐに効くものから削りたくなる。監視、ログ、バックアップ、冗長性、セキュリティ、検証環境。どれも短期的には削減効果が見えやすい。しかし、それらが障害対応、監査、復旧、顧客信頼を支えているなら、削らない判断にも説明責任がある。
つまり、Frugal Architect は「削る人」ではない。
削るべきものを削り、残すべきものを残す人である。
その判断を支えるために、可観測性が必要になる。
見えないから削れないのではない。見えないまま削るのが危ない。
見えないから残すのではない。見えないまま残すと、オーバースペックが温存される。
だから、可観測性は目的ではなく、削る勇気と削らない勇気を支えるための前提になる。
実践は「小さな改善を回せる形」にすること
GameDay の体験として強く残ったのは、コスト最適化は一発で終わらないということだった。
最初から完璧な構成を当てにいくのではない。
観測する。仮説を立てる。小さく変える。影響を見る。次の改善に進む。
この反復が重要になる。
SIer の案件では、リリースを境にプロジェクトの重心が変わる。
構築チームは離れ、運用保守チームに引き継がれる。初期構築時の設計意図が薄れ、改善余地があっても「安定しているから触らない」状態になりやすい。
しかし、クラウドでは安定して動いていることと、適切なコストで動いていることは別である。
ここに、運用保守の新しい価値がある。
単に障害を起こさないことだけではなく、動き続けるシステムのコスト効率を継続的に整えること。
これは月次報告や定例会の中にも組み込める。
- 先月の主要コスト変動
- 利用量と費用の対応
- 未使用・低使用リソースの確認
- ログ・バックアップ・データ保持の妥当性確認
- 次月に試す小さな最適化
- 削減しないと決めたコストと、その理由
こうした項目が運用報告に入るだけで、保守は「止めない活動」から「価値あたりコストを改善する活動」に変わる。
SIerが持ち帰るべき実践リスト
GameDay の具体的な内容には触れないが、SIer の実案件に持ち帰るなら、次のような実践に落とせると思う。
1. 非機能要件にコスト章を作る
「コストは別紙見積」ではなく、非機能要件の一部として扱う。
書くべきなのは金額だけではない。
単位コスト、増加要因、監視方法、削減時に守る品質、見直し頻度を書く。
2. アーキテクチャ決定記録にコスト理由を残す
ADR に、性能・可用性・セキュリティだけでなく、コスト上の判断理由を残す。
「なぜこの構成にしたのか」「なぜこの余裕を持たせたのか」「なぜ今回は最適化しないのか」を残しておくと、後から見直せる。
3. タグ設計を請求管理ではなく責任設計として扱う
タグは請求を分けるためだけのものではない。
誰が見るのか、誰が直すのか、どのサービス・環境・役割に属するのかを明らかにする責任設計である。
4. ログと監視を「多ければ安心」で決めない
ログやメトリクスは多ければよいわけではない。
必要な可視性と保持期間を定義し、即時に必要なものと、後から参照できればよいものを分ける。
5. 運用保守に継続的コスト改善を含める
クラウド費用の見直しを、障害対応後の特別作業にしない。
月次・四半期の通常運用に組み込む。
6. 「削るコスト」と「削らないコスト」を明文化する
コスト最適化では、削るものだけでなく、削らないものを決めることが重要である。
削るも勇気、削らないもまた勇気である。
セキュリティ、監査、可用性、復旧性など、事業上守るべきものに払うコストは、削減対象ではなく投資として説明する。
自分の中での一番大きな学び
今回、自分の中で一番大きかった学びは、Frugal Architect が「クラウドエンジニア向けの最適化技法」ではなく、「設計責任の言語」だと感じられたことだった。
SIer は、顧客の業務、予算、リスク、運用体制、契約、将来変更をまとめて扱う立場にいる。
その意味では、Frugal Architect と相性がいい。
ただし、単に「AWSのコスト削減ができます」と言ってしまうと薄くなる。
本当に価値があるのは、顧客と一緒に次の問いを扱えることだと思う。
- どの品質に、いくら払うのか
- どのリスクに、いくら払うのか
- どの成長に、どう備えるのか
- どのコストは今すぐ下げるのか
- どのコストは将来の自由度のために残すのか
この問いを設計・見積・運用の共通言語にする。
それが、SIer 的な Frugal Architect の実践なのだと思う。
おわりに
AWS GameDay は、手を動かしながら設計思想を体感できる場だった。
ただし、その価値は「何をどう設定したか」よりも、「なぜその判断をするのか」を身体で理解できるところにある。
コストを非機能要件にする。
コストをビジネス価値に接続する。
コストを観測し、説明し、継続的に整える。
これはクラウドの小技ではなく、これからのSIに必要な設計態度なのだと思う。
cover image: unsplash