AIでアプリ長者になるつもりだったのに！：こうしす！ 蔵王光速電鉄を“DX”いたしますわよ＠IT支線（4）
技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。新シリーズ「蔵王光速電鉄を“DX”いたしますわよ＠IT支線」では、DXのよくある失敗を解説します。第4列車は「クラウド破産」。どのようなてんやわんやが起きるのやら……。※このマンガはフィクションです。
「ざおでんDX」とは
没落社長令嬢・左沢美咲（あてらざわ みさき）は、「デラックス」な生活を取り戻すために、DX推進を決意する。DX推進人材として採用した女鹿 梨（めが りん）を巻き込み大暴走。蔵王光速電鉄を“DX“いたしますわよ！
第4列車：バイブでコーディングしただけなのに
井二かけるの追い解説
「こうしす！」シリーズ新編「ざおでんDX」の第4回。テーマは「クラウド破産」です。
生成AIが急速に普及しているけれど……
この1年で生成AI（人工知能）を用いたコーディングエージェントが急速に普及しています。
当初はおばかなコード補完しかできない、ありがた迷惑な機能だったのに、今ではチャット形式で「○○を作って」というだけで、それなりのものを実装できるようになりました。ダルい作業もお任せで、もはや開発業務に欠かせない存在となりつつあります。そんな中、登場したのが「バイブ（雰囲気）コーディング」という、いわばノリで開発する開発スタイルです。
これまで「アプリを開発しちゃってるオレ♪」のような軽いノリで開発できるノーコード／ローコード開発ツールは多々ありました。バイブコーディングが興味深いのは、必ずしもそうした専門のツールを使う必要がないという点です。
技術者が使用する標準的な開発ツールを用いているにもかかわらず、チャット形式で指示するだけで開発できる。従って、ローコード／ノーコード開発ツールで必ずぶち当たる「こんな回りくどいことをするくらいなら、普通に開発した方が速いじゃん」というような制約を受けることなく、専門知識がなくても自由に開発できることがこれまでと全く異なる点です。
知識ゼロでも、AIに教えを請えば、標準的な開発ツールで開発し、クラウドにデプロイするところまで、1人で実行できるのです。
しかし、物事には当然リスクがあります。果たして私たちはこうしたリスクに向き合えているのでしょうか。
古今東西言われてきたことですが、「大いなる力には大いなる責任が伴う」という有名な格言があります。自由を得るということは、当然、危険なことにも手を出すことが可能になるということです。何が危険かを知らないまま自由を得てしまえば、知らぬうちに落とし穴に落ちてしまうことになるでしょう。
お金を失うというリスク
バイブコーディングのリスクとしてよく言われるのは、セキュリティや保守性などの「信頼性」に関わるものです。
「バイブコーディングでソリューションを作成する能力は有効だが、実際にビジネスで使えるセキュアでプライバシーが保護されたエンタープライズ規模のアプリケーションを構築することとは別の話である」と、ローコード開発ツール「FileMaker」を製造するClarisのCEOも言っています。
システムの信頼性には予算の範囲内でシステムが稼働することも含まれます。予算といえば、マンガの中で美咲さんが陥った「クラウド破産」も、リスクの一つです。
シャドーITがはやり始めたときからある古典的なリスクですが、バイブコーディングでも注意が必要です。クラウドサービスは基本的に従量課金であるが故に、思わぬ高額請求を受けることがあるからです。ツールの発展によって“開発民主化”のハードルは下がりましたが、インフラリソースなど開発に伴う各種サービスの利用状況やコストを監視・管理する視点や仕組みが不可欠です。
よくあるのが以下のパターンです。
- 無駄に高額なリソースを使って、何もアクセスがなくても高額課金される
- 忘れた頃に期間限定の無料枠が終わり、突然高額課金される
- アクセスが殺到し、高額課金される
- 不要なリソースを消し忘れて「ちりも積もれば」で年間合計すると課金が高額になる
クラウドサービスは、こうしたリスクに対して、どう対処するかをあらかじめ想定して使わなければなりません。
しかし、そうしたリスクを知らないまま「これで大もうけですわ〜」と、AIに大もうけできるアプリを作る方法を問い、AIに言われるがままに「Amazon Web Services（AWS）」を契約し、無駄にlargeインスタンスを使用し……となれば、それだけで毎月数万円以上の請求が発生します。
さらに、アクセスが殺到した場合に高額になりがちなのが、生成AIそのもののAPIを使って機能を提供する場合です。使用するモデルや読み込ませる文章のトークン数によっては、1人が使っていても一瞬で数千円分飛んで行くことになります。
対策
では青天井の課金でクラウド破産するリスクにはどのような対策が必要でしょうか？
リスク対策には、「回避」「低減」「転嫁」「受容」の4つの方法があります。本稿では、主に「回避」と「低減」について主に考えてみましょう。
回避
そもそもAWSのようなクラウドサービスを利用すべきかどうかという点を考える必要があります。
AIに「Webアプリを作るならWebサーバを構築し、データはパブリッククラウドに置きましょう。例えばAWSには以下のようなクラウドサービスがあります」と説明されたらバイブコーディングしている人は納得してしまうかもしれません。
しかし小規模Webアプリならば、Cloudflareの「Pages」「Workers」「D1」「R2」や「Vercel」の無料枠だけで十分なことがあります。もっといえば、Webアプリとして提供するのではなく、デスクトップやスマホで動作するアプリとして、PCやスマホ内で動作が完結するアプリを開発するのも一つの手と言えるでしょう。
低減
プリペイドチャージ式のクラウドサービスや、課金アラートを設定するという方法があります。
残念ながら、クラウドサービスはビジネスの継続が最重要課題であるため、基本的に「一定の課金額に達したらサービスを止める」という機能は用意されていません。しかし、一部にはプリペイドチャージ式のクラウドサービスがあり、そうしたサービスではチャージ額がゼロになると自動でサービスが停止されます。
例えば「Microsoft Azure」であれば、法人向けに「Azureインオープンプラン」というプリペイドプランや、開発用に「Visual Studio サブスクリプション」に付属する特典クレジットがあります。
OpenAIのAPIなども自動チャージを設定しない限り、チャージ額を超えたときに停止するようになっています（サービス停止までに多少タイムラグがあり、超過額を請求されることがあります）。
また、課金上限に達したときにサービスを停止するという機能として、Vercelにはハードキャップ機能があります。
AWSやAzure、「Google Cloud」には、一定金額に達したときにアラートメールを送る「課金（予算）アラート機能」が存在します。思わぬ高額課金となっていることに早めに気付き、手動で停止するためにもアラートを設定する必要があります。
そして、定期的なリソースの棚卸しを行い、不要なリソースを消していくことも地味に重要なポイントです。
ちなみに、「転嫁」については保険などが該当しますが、クラウド破産のリスクに対して有効なものはありません。「受容」については、上記の対策によっても予期せぬ課金が発生するリスクがあり、残存リスクを受け入れられるまで小さくするということが大切となるという意味であり、ノーガード戦法として積極的に取れる対策ではありません。
AIは責任を取ってくれないからこそ
SFの世界と違い、現代のAIは多くのミスを犯します。
AIをガン詰めしても、AIは責任を取ってくれません。もちろん今後法律や判例としてAI事業者の責任が認められていくかもしれませんが、現状では自分がリスクを負うしかありません。責任あるAIの使い方が求められています。今回取り上げた開発業務なら、アプリケーションを作り運用する「アプリケーション提供者」としての責任が求められます。
筆者はよく生成AIを「賢い鏡」に例えています。駄目なものが生まれるなら、それは企画、設計がダメだったということです。「鏡よ鏡」と全てAIに委ねてはいけません。企画、設計段階からそうしたリスクに向き合うという「セキュア・バイ・デザイン」の考え方が、今こそ大切になっているといえるでしょう。
編集部注
本連載では、経済産業省の資料の定義にのっとり、DXを「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」としています。
Copyright 2012-2025 OPAP-JP contributors.
本作品は特に注記がない限りCC-BY 4.0の下にご利用いただけます
筆者プロフィール
作画：るみあ
フリーイラストレーター。アニメ「こうしす！」ではキャラクターデザイン・キャラ作画担当をしています。
原作：井二かける
アニメ「こうしす！」監督、脚本。情報処理安全確保支援士。プログラマーの本業の傍ら、セキュリティ普及啓発活動を行う。
著書：「こうしす！社内SE 祝園アカネの情報セキュリティ事件簿」（翔泳社）、「ハックしないで監査役!! 小説こうしす!EEシリーズ 元社内SE祝園アカネ 監査役編 [1]」（京姫鉄道出版）
映画：「こうしす！EE 総集編映画版」
- X（Twitter）：@k_ibuta
解説：京姫鉄道
「物語の力でIT、セキュリティをもっと面白く」をモットーに、作品制作を行っています。
原作：OPAP-JP contributors
オープンソースなアニメを作ろうというプロジェクト。現在はアニメ「こうしす！」を制作中。
- X（Twitter）：@opap_jp、@kosys_pr
- 公式サイト：Open Process Animation Project Japan（OPAP-JP）
- 貢献者一覧：こうしす！/クレジット
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
近ごろはやりの「バイブコーディング」、概要を理解し課題や注意点も把握しておこう
IT用語の基礎の基礎を、初学者や非エンジニアにも分かりやすく解説する本連載、第33回は「バイブコーディング」です。ITエンジニアの学習、エンジニアと協業する業務部門の仲間や経営層への解説にご活用ください。
ローコード開発ツールの進化が示す、エンジニアの役割再定義とデータ駆動型オーケストレーション
AIの進化がソフトウェア開発者の役割とスキルを大きく変革する。エンジニアよ、データ理解と協調するマインドセットを武器に、未来の開発を切り開け。