【ITニュース解説】Using drones for FinOps with AWS Agentic AI - Part 2

最近のIT業界では、AI技術が急速に進展し、多くの企業がAI機能を搭載したアプリケーションを開発している。しかし、ただ「クールな」AIシステムを構築するだけでは、プロジェクトは成功しない。システムが稼働し始めると、次に直面するのが「運用とコスト」という重要な課題である。特に、AIワークロードと呼ばれる、AIを動かすためのシステムは、従来のアプリケーションとは異なる特性を持つため、そのコスト管理は非常に複雑になる。

システムエンジニアとしてアプリケーションを開発していると、多くの場合、目の前の技術的な課題解決に集中しがちである。かつては、コストや予算の話は「退屈な部分」と感じ、最新の技術ツールについて話すことの方が楽しいと思っていた開発者も少なくない。しかし、より責任のある立場になると、技術的な面白さだけでなく、コスト管理がいかに重要であるかを痛感するようになる。特に生成AIのブームが到来して以来、多くの組織でPoC（概念実証）段階でのAI関連コストが高騰し、それがなかなか実際の製品やサービスに繋がらず、投資対効果（ROI）が見えないという問題に直面している。

ここで重要になるのが「FinOps」という考え方だ。FinOpsとは、Finance（財務）とOperations（運用）を組み合わせた造語で、クラウドコストを最適化するための文化やプラクティスを指す。開発者、運用チーム、財務チームが協力し、クラウド利用状況を可視化し、コストを管理し、継続的に改善していくことを目指す。特にAIワークロードの場合、その複雑さからFinOpsの導入が不可欠となる。FinOps組織は、まず小さなユースケースからAIワークロードを定義し、そのコストを明確に可視化することから始めるよう提言している。

では、なぜAIワークロードのコスト管理はこれほど複雑なのだろうか。従来のアプリケーションであれば、主に計算リソース（CPUやメモリ）やストレージの使用量に応じて費用が発生し、これらは比較的シンプルに「使った分だけ支払う」という従量課金モデルだった。しかし、AIワークロードは、これらに加えて、大規模言語モデル（LLM）の利用にかかるトークン数や、専門的なAIサービス、さらには高度なデータ処理や転送など、多岐にわたる要素が絡み合うため、コストの全体像を把握するのが難しい。例えば、あるLLMサービスでは、入力した文字や出力された文字の量（トークン数）に応じて課金される。この特性を理解せずに利用すると、あっという間に予算を超過してしまうことがあるのだ。

具体的な例として、ドローンを使った予測メンテナンスのアプリケーションを考えてみよう。これは、ドローンで収集した画像を、AWSのAIエージェントがオーケストレーションする多モーダルLLMを使って分析し、設備の故障を予測するシステムである。このアプリケーションにFinOpsの機能を組み込む場合、まずそのコスト構造を明確にする必要がある。

アプリケーションにFinOps機能を追加する際、特定の標準を用いると、異なるクラウド環境やサービスをまたがるAIワークロードのコストを管理しやすくなる。例えば、「FOCUS v1.2」という標準は、AIワークロードが複数のクラウドプロバイダーやオンプレミス環境、SaaSサービスに分散している状況に対応できるよう設計されている。これは、従来の一般的なアプリケーションが、ある程度の範囲内で閉じていることが多いのとは対照的である。

実際にFinOps機能を実装する際、AWSのコード生成ツールである「Kiro」が役立つ。例えば、ダッシュボードにFinOps機能を追加しようとした場合、KiroはリアルタイムのAWSコストデータを取得しようとするが、そのままではうまくいかない場合がある。その際には、AWS Cost Explorerのようなコスト管理サービスとKiroを連携させることで、正確なコストデータをダッシュボードに表示できるようになる。これにより、AIワークロードのコストをタグ付けなどで適切に分類し、可視化することが可能となる。

こうして構築されたダッシュボードでは、全体の支出、投資対効果（ROI）、そして具体的なコスト削減額などが一目でわかるようになる。例えば、ドローンを使った予測メンテナンスアプリケーションの場合、AWS上でのAIワークロードにかかるコストは以下のような要素から構成される。 まず、生成AIやLLM、エージェント関連の費用として、Amazon Bedrockやそのエージェント、ClaudeやNovaモデルといったLLMのトークン使用量などが挙げられる。これらは入力と出力のトークン数に応じて課金されることが多い。次に、アプリケーションが扱う画像を保存するためのAmazon S3などのストレージ費用が発生する。さらに、データ処理や分析を行うためのAWS Lambda関数といったコンピューティング費用、データベースとしてはAmazon DynamoDBなどの費用も必要となる。その他にも、Amazon API GatewayやAmazon CloudFrontといったAWSマネージドサービスや、大量の画像データを扱うことによるデータ転送費などが加わる。

実際の運用においては、これらAWSサービスだけでなく、さらに多くの要素を考慮に入れる必要がある。例えば、他のクラウドプロバイダーが提供するLLMや、HuggingFace、Snowflake、DatabricksといったSaaSサービスの利用料やライセンス費用も含まれるだろう。AI/MLのワークフローを自動化するApache AirflowやKubeflowといったオーケストレーションツール、あるいはCI/CDパイプラインの費用も考慮に入れる必要がある。計算リソースについても、Amazon EKSやECSでコンテナを動かす費用や、バッチ処理に活用されるスポットインスタンスの費用も発生しうる。

さらに高度なAIサービス、例えば画像からテキストを抽出するAmazon Textractや、感情分析を行うAmazon Comprehendなどを組み込んだ場合、それらの利用料も加算される。また、RAG（Retrieval Augmented Generation）やCAG（Context Augmented Generation）といった技術を用いる場合、ベクトルデータベースのコストも考慮する必要がある。Amazon Bedrock Knowledge BasesやAmazon OpenSearch for Vector Databaseがこれに該当し、CAGであればAmazon ElastiCacheやAmazon API Gatewayが関連する可能性もある。LLMのファインチューニング（特定のデータセットでモデルをさらに学習させること）を行う場合、そのためのコンピューティング費用も高額になることがある。

加えて、データの冗長性や可用性を高めるために、Amazon S3などでデータを複数のAWSリージョンに複製したり、AIワークロード自体をアクティブ-アクティブ構成で運用したりする場合、そのための追加コストが発生する。予測できない使用量の急増、例えばトークン数が突然増えたり、コンテキストサイズが予期せず大きくなったりした場合、コストが大幅に膨らむ可能性もあるため、これに対する備えも必要である。

そして、多くの企業ではAIワークロードが単一のクラウド環境にとどまらず、複数のクラウドサービスやオンプレミス環境にまたがっている。例えば、企業のコアデータがオンプレミスにあり、その近くでAIの推論処理を行いたい場合、クラウドからオンプレミスへデータを転送する際のエグレスコスト（データ転送費）も無視できない要素となる。

これら多岐にわたるコスト要素は、システムエンジニア初心者にとって非常に圧倒されるものに聞こえるかもしれない。しかし、最初の一歩は、利用するユースケースを明確にし、その中でどのコンポーネントがAIワークロードのコストに寄与するかを関係者全員で合意することから始まる。FinOpsの考え方によれば、この「AIワークロード」の定義と、それに含まれるコストコンポーネントについて、ビジネスチーム、財務チーム、運用チームなど、様々な関係者との間で認識を一致させることが、技術的な課題を解決するよりも最も難しい部分であるとされている。つまり、単に技術を構築するだけでなく、組織内の連携と合意形成が、AI時代のクラウドコスト管理において最も重要な鍵となるのだ。