AI破産・クラウド破産を防ぐ！ 安全なシステムアーキテクチャ設計のポイント
AIやクラウドはユースケースによって想定外の費用がかかる場合があります。AI破産・クラウド破産を防ぐには、システムの規模やユースケースを踏まえたアーキテクチャ設計が重要です。
1. AI破産・クラウド破産とは？原因と事例
AI破産とは
AI破産とは、OpenAIやAnthropicなどの生成AI APIを利用する際、トークン利用料が想定以上に膨らみ、高額な請求が発生することを指します。このような事例はSNSやブログでもたびたび報告されています。
生成AIは大規模言語モデル（LLM: Large Language Models）を基盤とし、精度向上や長文コンテキスト対応のため、スケーリング則に基づく高コストなシステム基盤で運用されています。
そのため、ユーザーや開発者が安易に大容量のテキストや会話履歴を入力すると、処理トークン数が急増し、利用料が跳ね上がります。このような仕組みを理解せずに運用すると、予期せぬ請求につながり「AI破産」と呼ばれる事態に陥ります。
クラウド破産とは
AI破産と同様に、クラウド破産もたびたびSNSやブログで見かける話題です。クラウド破産とは、クラウドサービスの利用料が想定を大きく超過し、事業やプロジェクトの継続を困難にする状態を指します。
IaaSやPaaS、SaaSといったサービスは初期投資を抑えやすく、柔軟なスケーリングが可能な一方、利用量やリソース増加に比例して課金額が上昇します。
特に大量データの保存・転送、計算処理の負荷増、リージョン間通信などは見えにくいコスト要因となりがちです。設計段階でのリソース見積もり不足や、モニタリング・アラート設定の不備により、運用中に利用料が急増するケースも少なくありません。
2. アーキテクチャ設計と非機能要求の重要性
非機能要求は、アーキテクチャ設計＝システム方針設計につながります。
アーキテクチャ設計を決める非機能要求
AI破産やクラウド破産を防ぐには、利用状況の可視化、コスト上限の設定、アーキテクチャの最適化、不要リソースの定期削除といった運用管理が不可欠です。
なかでもアーキテクチャ設計は、システムの規模やユースケースによって最適解が変わるものです。スモールスタートでスケールさせていく場合でも、あらかじめ、またはサービスを運営しながらシステムの利用状況やユーザー数、データ量の拡大を予想しながら変えていく必要があります。
このアーキテクチャ設計の前提となるのが非機能要求（非機能要件）です。共通フレーム2013では機能要件がソフトウェア設計に、非機能要件がアーキテクチャ設計に対応していることが解説されています。
非機能要求の種類
要件定義では、要求側の分かりやすさから、機能や画面に焦点が当たりやすく、非機能要求を詰める作業はベンダー任せになりやすい領域です。要件定義の段階であってもシステム開発に対する知見が求められ、その必要十分を検討するのが難しいからです。
しかし、非機能要求がアーキテクチャ設計を左右し、運用コストだけでなく、セキュリティにも関わるため慎重な検討が必要です。セキュリティも難しい話題ですが、インシデント（事故）が発生すると損害賠償やシステムの見直しといったコストに直結する領域といえます。
大まかな非機能要求のカテゴリーは以下のとおりです。これらのカテゴリーごとに検討を進めます。
- 可用性
- 性能・拡張性
- 運用・保守性（クラウドの維持コストが含まれる）
- 移行性
- セキュリティ
- システム環境・エコロジー
非機能要求グレード
機能要件はどのような機能・画面が必要か検討するため発注側のイメージが付きやすいのですが、非機能要求はイメージが湧きづらく、要件定義が難しい領域です。そこで、非機能要求を検討するためのテンプレートを利用すると要件定義を進めやすくなります。ここで使えるのが非機能要求グレードです。
非機能要求グレードは、独立行政法人情報処理推進機構（IPA）が2015年に策定した、システム開発における非機能要求（性能、信頼性、運用・保守性、セキュリティなど）の明確化と合意形成を支援するための指標です。
非機能要求は機能要件と異なり定量化や優先度付けが難しく、曖昧なまま進めると性能不足や運用負荷増大、セキュリティ脆弱性などの重大な問題を招く恐れがあります。
IPAの非機能要求グレードは、各項目について複数のグレード（レベル）を設定し、プロジェクト規模や目的、利用環境に応じて適切な水準を選択できるようにしたものです。これにより、発注者と開発者間で品質目標を具体的に共有し、設計・テスト・運用計画に反映させやすくなります。
また、過剰品質によるコスト増や、逆に品質不足によるトラブルを防ぐ効果があり、公共システムや大規模開発だけでなく企業内システムにも活用可能です。
3. 非機能要求の劣化（デグレード）が招くリスク
非機能要求のデグレードの発生原因
要件定義のなかでも機能要件はどのような機能・画面が必要か検討するため発注側のイメージが付きやすいといえます。しかし、非機能要求はシステム開発の知見がないとイメージが湧きづらく、要件定義が難しい領域です。非機能要求として決めるべき領域も、様々なリスクやアーキテクチャに対する理解がないと、コスト増や運用の難しさが目立つため、できるだけ最小限にとどめようと考えてしまいがちです。そのため不十分な非機能要求にとどまってしまいがちです。
非機能要求グレードを利用することで非機能要求をまとめやすくなりますが、初期の構築コストだけでなく、維持運用や万一の場合のコストを考慮した検討が重要です。
不十分な非機能要求が招くリスク
非機能要求は要件定義で検討され、運用テストで検証されます。V字モデルを参考にすると、運用テストはプロジェクトの終盤になるため、運用テストで問題に気づいたとしても、その修正のためには大きく戻らないといけません。
また、要件定義が不足している場合は、運用テストでも検証できず、その次の投資効果・業務効果を測るフェーズ移行で問題になることがあります。本記事で話題にしている維持運用コストも、投資効果で議論される対象です。
開発したばかりのシステムでは、コスト試算が十分に行われず、この投資効果を測るフェーズも超えてしまうこともあります。特にAIやクラウドのような新しい分野では、どのように利用するとコストが増えてしまうのかが十分に認知されておらず、コスト試算自体が不十分になることがあります。
プロジェクトメンバーにAIやクラウドの非機能要求に知見のある人がいる場合は、要件定義で不足があったとしても設計や実装のなかで要件定義のの不足を指摘してもらえることもありますが、多くの場合は決まった要件定義をもとに粛々とプロジェクトが進みます。
システム開発における手戻りとコスト
プロジェクトの手戻りにかかるコストにも注意が必要です。初期に気づくことのできた課題は修正が軽微ですが、プロジェクトの終盤に気づいた課題は修正コストが非常に大きくなります。
AIやクラウドの運用コストの大きさが課題になるとき、プロジェクト自体が終盤になっていることも多く、維持運用コストの改善のためにできるだけ早く修正対応したいものの、修正コストも大きくなりがちです。
このような点からも、非機能要求グレードを利用した効果的な要件検討が重要といえます。
4. まとめ：AI破産やクラウド破産回避のために
AI破産やクラウド破産というキーワードをきっかけに、破産回避のためのアーキテクチャ設計と、その前提となる非機能要求の重要性について解説しました。また、非機能要求の不足によるコスト増には維持運用コストだけでなく、修正コストもあり、時間の経過とともにどちらも増えていくことになります。
非機能要求グレードのようなテンプレートによって必要十分な非機能要件を定義することが、最適なシステム開発につながります。また、ユーザー数やデータ量、システムのユースケースが変化していくなかでも、定期的に要件を見直していくことが、長期的なシステム運用に重要です。