監修:アジアクエスト株式会社 AIアクセラレーション室
執筆:アジアクエスト編集部
FinOps(フィンオプス)とDevSecOps(デブセックオプス)は、特定の対象を運用するOpsではなく、コストとセキュリティという観点を、開発・運用のプロセス全体に横断的に組み込むOpsです。FinOpsはクラウドやAIの費用を可視化し、エンジニア・財務・経営が一体となって最適化する実践です。DevSecOpsは、セキュリティ対策を開発の最終段階ではなく初期段階から組み込む考え方です。
本記事では、FinOpsとDevSecOpsの基本と、生成AIの普及によって重要性が増している理由、導入の進め方を、経営層・IT部門責任者の視点で解説します。他のOpsとの関係は、関連記事「XOps(〇〇Ops)とは?DevOps・MLOps・AIOps・LLMOpsの違いと全体像」で整理しています。
この記事でわかること
- FinOpsとDevSecOpsの定義と、両者に共通する考え方
- AIの費用管理が急速に広がっている背景
- DevSecOpsの主な実践と、参考になる国際的な枠組み
- 両者を開発・運用のプロセスに組み込むための進め方と体制
1. FinOps・DevSecOpsとは?共通点は「後から」ではなく「最初から」
FinOpsとDevSecOpsは、扱う観点は異なりますが、「後から確認する」のではなく「最初から組み込む」という共通の考え方を持っています。
| 観点 | FinOps | DevSecOps |
|---|---|---|
| 組み込む観点 | コスト(費用対効果) | セキュリティ |
| 従来のやり方 | 月末の請求書を見て、財務部門が事後に費用を確認する | 開発の最終段階で、セキュリティ部門がまとめて検査する |
| 従来のやり方の問題 | 費用の超過に気づくのが遅れ、原因も特定しにくい | 問題の発見が遅れ、手戻りが大きくなる。リリースも遅れる |
| 新しいやり方 | 費用をリアルタイムに可視化し、エンジニアが日常的に意識する | 開発の初期段階から、自動化されたセキュリティチェックを組み込む |
| 主な担い手 | エンジニア、財務、経営、業務部門 | 開発チーム、セキュリティチーム、運用チーム |
どちらも、専門部門だけに任せるのではなく、開発や運用に関わる全員が当事者として取り組む点が重要です。
2. FinOpsとは?クラウドとAIの費用を「価値」で管理する
FinOpsは、クラウドの従量課金という特性に合わせて生まれた、費用管理の実践です。従来のオンプレミス(自社保有のサーバー)では、機器の購入時に予算を確定させていました。クラウドでは、エンジニアが必要なときに必要なだけ資源を使えるため、費用が日々変動し、気づかないうちに膨らむことがあります。
FinOpsの目的は、単に費用を削減することではなく、使った費用に見合う価値を得られているかを判断できる状態をつくることです。FinOpsの普及に取り組む非営利団体のFinOps Foundationは、FinOpsの取り組みを、費用の可視化と配分(Inform)、最適化(Optimize)、継続的な運用(Operate)という段階で繰り返し回していく考え方を示しています。
AIの費用管理が急速に広がっている
FinOps Foundationが公表した「State of FinOps 2026」(回答者1,192人)では、AIの費用管理がわずか2年でFinOpsの標準的な対象になった実態が示されています。
| 調査結果 | 数値 |
|---|---|
| AIの費用を管理していると回答した割合 | 98%(2025年は63%、2024年は31%) |
| SaaSの費用を管理している(予定を含む)と回答した割合 | 90% |
出典:FinOps Foundationをもとに編集部作成
同じ調査では、現在の最優先事項は引き続き「ワークロードの最適化と無駄の削減」である一方、今後の優先事項では「FinOps for AI(AIへのFinOpsの適用)」が最上位に挙げられています。また、FinOps Foundationは自らの使命を「クラウドの価値」から「テクノロジーの価値」を管理する人々の支援へと改めており、FinOpsの対象がクラウドからAIやSaaSを含むテクノロジー全体へ広がりつつあることがうかがえます。
生成AIのAPI利用料やGPU(AIの計算に使う高性能な処理装置)の費用は、利用量に応じて大きく変動します。「問い合わせ1件あたりのAI費用」のように、業務の単位あたりのコストを把握し、得られる効果と比べて判断することが、AI時代のFinOpsでは特に重要です。
3. DevSecOpsとは?セキュリティを開発の初期段階から組み込む
DevSecOpsは、DevOpsの開発・運用のプロセスに、セキュリティ(Security)を組み込む考え方です。開発の工程を左から右へ並べたとき、セキュリティ対策をより早い段階(左側)へ移すこの考え方は「シフトレフト」と呼ばれ、DevSecOpsの中核となる原則です。
リリース直前にまとめてセキュリティ検査を行うやり方では、問題が見つかったときの手戻りが大きく、リリースも遅れます。DevOpsでリリースの頻度が上がるほど、この問題は深刻になります。DevSecOpsでは、コードを書く段階から自動化されたチェックを繰り返し行うことで、問題を早く・小さいうちに見つけ、スピードと安全性の両立を目指します。
DevSecOpsの主な実践
| 実践 | 概要 |
|---|---|
| ソースコードの静的解析 | コードを実行せずに解析し、脆弱性(セキュリティ上の弱点)につながる書き方を検出する |
| 依存ライブラリの検査 | 利用しているオープンソースなどの外部ライブラリに、既知の脆弱性がないかを確認する |
| 機密情報の検出 | パスワードやAPIキーなどが、誤ってコードに含まれていないかを確認する |
| インフラ設定の検査 | IaC(インフラ構成をコードで管理する手法)の設定に、セキュリティ上の問題がないかを確認する |
| コンテナイメージの検査 | アプリケーションを動かすコンテナ(実行環境をまとめたもの)に脆弱性がないかを確認する |
| 動的解析(DAST) | 実行中のアプリケーションに外部から疑似的な攻撃を行い、脆弱性を検出する |
| SBOM(ソフトウェア部品表)の作成・管理 | ソフトウェアを構成するライブラリなどの一覧を作成・管理し、新たな脆弱性が見つかった際に影響範囲を素早く特定する |
| 本番環境の監視 | 本番環境での不審な挙動や設定の変更を検知し、迅速に対応する |
これらのチェックをCI/CD(継続的インテグレーション/継続的デリバリー)のパイプラインに組み込み、コードの変更のたびに自動で実行することが基本です。
参考になる国際的な枠組み:NISTのSSDF
安全なソフトウェア開発の実践を整理した枠組みとして、米国国立標準技術研究所(NIST)が2022年に公表した「SSDF(Secure Software Development Framework)」(SP 800-218)が広く参照されています。SSDFは、既存の開発プロセスに組み込める実践を、次の4つのグループに整理しています。
| グループ | 概要 |
|---|---|
| 組織の準備 | 安全な開発を支える人材・プロセス・技術を整える |
| ソフトウェアの保護 | ソースコードや開発環境を、不正なアクセスや改ざんから守る |
| 安全なソフトウェアの作成 | 脆弱性を最小限に抑えたソフトウェアを作り、検証する |
| 脆弱性への対応 | リリース後に見つかった脆弱性を特定・修正し、再発を防ぐ |
出典:NIST(2026年10月6日)をもとに編集部作成
NISTは、SSDFが共通の用語を提供することで、ソフトウェアを調達する側と提供する側のコミュニケーションにも役立つとしています。外部の開発会社にシステム開発を委託する場合にも、セキュリティ要件を伝える共通の物差しとして活用できます。なお、NISTは2025年12月に改訂版(SSDF バージョン1.2、SP 800-218 Rev.1)の初期公開ドラフトを公表しています。また、生成AIや基盤モデルの開発向けにSSDFを補う「SP 800-218A」も2024年7月に公開されており、AIを組み込んだシステムを開発する際の参考になります。
4. FinOps・DevSecOpsの導入ステップ
FinOpsとDevSecOpsは、いずれも一度に全社で完成させるものではなく、可視化から始めて段階的に組み込んでいくのが現実的です。
FinOpsの導入ステップ
-
費用を可視化する:クラウドやAIの費用を、サービス・部門・プロジェクトごとに把握できるようにします。リソースにタグ(分類用のラベル)を付けるルールを決めることが出発点です。
-
費用の責任者を決める:部門やプロジェクトごとに、費用に責任を持つ人を決め、定期的に費用を確認する場を設けます。
-
無駄を削減する:使われていないリソースの停止、利用量に合わせた規模の見直し、長期利用の割引制度の活用などを進めます。
-
予算とアラートを設定する:予算の上限と、超過しそうなときのアラートを設定し、想定外の費用増加を早期に検知します。
-
業務の単位あたりのコストで判断する:「顧客1人あたり」「問い合わせ1件あたり」などの単位でコストを把握し、得られる価値と比べて投資を判断します。
DevSecOpsの導入ステップ
-
現状のリスクを把握する:開発しているシステムと、扱うデータの重要度、現在のセキュリティ検査の方法を棚卸しします。
-
CI/CDに基本的なチェックを組み込む:依存ライブラリの検査や機密情報の検出など、導入しやすく効果の大きいチェックから自動化します。
-
検出結果への対応ルールを決める:検出された問題の重要度ごとに、リリースを止めるのか、期限を決めて修正するのかを定めます。すべてを止めると開発が進まなくなるため、優先度の設計が重要です。
-
検査の範囲を広げる:ソースコードの静的解析や動的解析、インフラ設定やコンテナの検査、SBOMの作成などへ範囲を広げます。
-
本番環境の監視と脆弱性への対応を定着させる:リリース後に見つかった脆弱性へ迅速に対応する体制を整え、振り返りを開発プロセスの改善につなげます。
5. ツールより先に決めるべき体制と役割
FinOpsもDevSecOpsも、ツールを導入しただけでは定着しません。専門部門だけの仕事にせず、開発や業務の当事者を巻き込む体制が欠かせません。
| 役割 | FinOpsでの主な責任 | DevSecOpsでの主な責任 |
|---|---|---|
| 開発・運用チーム | 日常的な費用の確認、リソースの最適化 | 自動チェックの結果への対応、安全なコードの作成 |
| 専門チーム | FinOpsの推進、費用の可視化と分析、ルールの整備 | セキュリティ基準の策定、チェックの仕組みづくり、高度なリスクの評価 |
| 財務部門 | 予算の策定、費用の予測と配分 | ― |
| 業務部門 | 費用に見合う価値が得られているかの判断 | 扱うデータの重要度の判断 |
| 経営層・責任者 | 投資の優先順位の決定 | セキュリティリスクの許容範囲の決定 |
DevSecOpsでは、開発チームの中にセキュリティの知識を持つ推進役(セキュリティチャンピオン)を置き、セキュリティチームとの橋渡しを担ってもらう方法もよく取られます。セキュリティの専門人材が限られる中で、開発チーム全体の意識と対応力を底上げする効果があります。
6. AWS・Azure・Databricks・SnowflakeでFinOps・DevSecOpsを実現するには
主要なクラウドやデータ基盤は、費用の管理とセキュリティの管理を支える機能を備えています。体制とルールを定めたうえで、既存環境に合った機能を活用することが重要です。
| 基盤 | FinOpsで活用できる主な機能 | DevSecOpsで活用できる主な機能 |
|---|---|---|
| AWS | AWS Cost Explorer(費用の分析)、AWS Budgets(予算とアラート) | AWS Security Hub(セキュリティ状況の一元管理。従来版はSecurity Hub CSPMに名称変更)、Amazon Inspector(脆弱性の検査) |
| Microsoft Azure | Microsoft Cost Management(費用の分析、予算とアラート) | Microsoft Defender for Cloud(セキュリティ状況の管理、脅威の検知) |
| Databricks | 利用状況のデータによる費用の可視化、予算の管理機能 | Unity Catalog(データとAIへのアクセス制御、監査) |
| Snowflake | リソースモニター(利用量の監視と上限の設定)、予算の管理機能 | アクセス制御、データの保護・監査などのガバナンス機能 |
DatabricksやSnowflakeは、利用量に応じて費用が変動するため、データ基盤の運用でもFinOpsの考え方が欠かせません。また、データ基盤には機密性の高いデータが集まるため、アクセス制御や監査の仕組みをDevSecOpsの一環として整えることも重要です。なお、各サービスの名称や機能は更新が頻繁なため、検討時には最新情報をご確認ください。
アジアクエストでは、FinOps・DevSecOpsの体制・ルール設計から、AWS、Microsoft Azure、データ基盤(Databricks・Snowflake)における費用管理・セキュリティ管理の仕組みの構築、運用、内製化支援までを一貫して支援しています。
7. よくある質問(Q&A)
Q1. FinOpsとは何ですか?
クラウドやAIの費用を可視化し、エンジニア・財務・経営・業務部門が一体となって最適化する実践です。単に費用を削減するのではなく、使った費用に見合う価値を得られているかを判断できる状態をつくることを目的とします。
Q2. DevSecOpsとは何ですか?
DevOpsの開発・運用のプロセスに、セキュリティを初期段階から組み込む考え方です。リリース直前にまとめて検査するのではなく、コードの変更のたびに自動化されたセキュリティチェックを行い、問題を早く・小さいうちに見つけることで、スピードと安全性の両立を目指します。
Q3. FinOpsとコスト削減は何が違うのですか?
コスト削減は費用を減らすこと自体が目的ですが、FinOpsは費用と価値のバランスを最適化することが目的です。売上に直結するサービスであれば、費用を増やしてでも性能を上げる判断もあり得ます。費用を可視化し、関係者が同じ情報をもとに判断できる状態をつくることがFinOpsの本質です。
Q4. 生成AIの費用は、どのように管理すればよいですか?
まずは利用者・部門・アプリケーションごとの利用量と費用を可視化し、予算の上限とアラートを設定します。そのうえで、「問い合わせ1件あたり」のような業務の単位あたりのコストを把握し、効果と比べて判断します。用途に応じて軽量なモデルを使い分けるなど、品質を保ちながら費用を抑える工夫も有効です。
Q5. シフトレフトとは何ですか?
セキュリティ対策やテストを、開発工程のより早い段階へ移す考え方です。工程を左から右へ並べたときに、左側(初期段階)へ移すことからこう呼ばれます。問題を早い段階で見つけるほど、修正の手間とコストが小さくなります。
Q6. DevSecOpsを導入すると、開発のスピードは落ちませんか?
導入直後は、検出された問題への対応で一時的に負担が増えることがあります。ただし、リリース直前の大きな手戻りや、リリース後のセキュリティ事故への対応が減るため、長期的にはスピードと安全性の両方が向上しやすくなります。検出結果の重要度に応じて対応ルールを設計し、すべてでリリースを止めないようにすることが重要です。
Q7. FinOps・DevSecOpsの導入には、どのくらいの期間がかかりますか?
対象の範囲と現状の整備状況によって大きく変わります。あくまで一般的な目安ですが、以下の期間を見込むケースが多く見られます。
-
FinOps:費用の可視化と予算・アラートの設定まで:1〜3か月程度
既存のクラウド環境があり、対象のアカウントやサービスが把握できていることが前提です。 -
DevSecOps:単一システムのCI/CDへの基本的なセキュリティチェックの組み込み:1〜3か月程度
CI/CDの仕組みがすでに整っていることが前提です。 -
全社的なルールの整備と、複数システム・部門への展開:6か月〜1年程度
【期間変動の主な要因】
-
タグ付けのルールやCI/CDが整っている場合:可視化やチェックの組み込みに集中でき、短期間での立ち上げが可能です。
-
クラウドのアカウントが部門ごとに乱立している、CI/CDがない場合:アカウントの整理やCI/CDの整備が先に必要となり、その分期間が延びます。
Q8. FinOps・DevSecOpsの導入費用はどのくらいですか?
前提条件によって大きく変動しますが、一般的な目安は以下のとおりです。
- FinOpsの費用可視化と予算管理の仕組みの構築(既存のクラウド環境あり):数百万円程度から
- DevSecOpsの基本的なセキュリティチェックの組み込み(単一システム、CI/CDあり):数百万円程度から
- 全社的なルールの整備と、複数システムへの展開:1,000万円前後から
これに加えて、費用管理やセキュリティのツールの利用料が発生する場合があります。FinOpsは無駄の削減による費用の低減、DevSecOpsはセキュリティ事故のリスク低減という効果が見込めるため、導入前後の費用や検出件数などを測り、効果を確認しながら進めることをお勧めします。
Q9. アジアクエストのFinOps・DevSecOps支援には、どのような特徴がありますか?
ツールの導入にとどまらず、費用の責任者やセキュリティ対応のルールといった体制づくりから支援する点が特徴です。AWS・Microsoft Azure・Databricks・Snowflakeを横断し、クラウドとデータ基盤の両方にまたがる費用管理とセキュリティ管理の仕組みを構築します。構築後は、お客様自身で運用・改善できる状態を目指す内製化支援まで一貫して伴走します。
Q10. クラウドや生成AIの費用が想定を超えています。何から相談すればよいですか?
まずは現在の費用の内訳と、利用しているサービスをお聞かせください。費用の可視化から始め、削減の余地がある箇所と、費用に見合う価値が出ているかを整理したうえで、進め方をご提案します。お問い合わせはサービスへのお問い合わせページから承っています。
8. まとめ:コストとセキュリティは「最初から」組み込む
FinOpsとDevSecOpsは、コストとセキュリティという観点を、開発・運用のプロセス全体に組み込むための取り組みです。AIの費用を管理するFinOps実務者の割合が2年で31%から98%へ急増したように、生成AIの普及によって、両者の重要性はさらに高まっています。
進め方の要点は3つです。第一に、専門部門だけに任せず、開発や業務の当事者を巻き込む体制をつくること。第二に、費用の可視化や基本的なセキュリティチェックなど、効果の大きいところから始めること。第三に、「後から確認する」のではなく「最初から組み込む」仕組みとして、日常の開発・運用に定着させることです。
アジアクエストでは、FinOps・DevSecOpsの現状診断から体制・ルール設計、AWS・Azure・Databricks・Snowflakeにおける仕組みの構築、内製化までを一貫して支援しています。「クラウドやAIの費用が膨らんでいる」「セキュリティ対策が開発の足かせになっている」といった段階から、お気軽にご相談ください。
あわせて読みたい記事
- XOps(〇〇Ops)とは?DevOps・MLOps・AIOps・LLMOpsの違いと全体像
- DevOpsとは?すべてのOpsの土台となる考え方
- LLMOpsとは?生成AIの本番運用で必要なこと
- プラットフォームエンジニアリングとは?「Ops疲れ」を解消する新潮流
参考ページ
参考文献
- FinOps Foundation「State of FinOps 2026 Report」
- NIST「NIST Updates the Secure Software Development Framework (SSDF)」(2022年2月4日)
- NIST「Secure Software Development Framework (SSDF) Version 1.2」(2025年12月17日)
- NIST「Secure Software Development Framework (SSDF)」(2026年10月6日)