Y's Software Atelierのブログ

2026/04/10

webアプリケーションのクラウドでの性能優先設計

宣伝です。

noteでマガジン「webアプリケーションのクラウドでの性能優先設計」を公開しました。↓こちらの写真が目印です。クラウドの記事なので雲が主役(?)の写真を見出しに使ってます。

2026/03/01から公開していましたが、noteのフォーロー中のトップから外れるとページビューが激減したので、ここでも宣伝してみることに。

内容はタイトルどおりですが、クラウドでwebアプリケーションを実装するにあたって網羅的に必要な知識・技術から書いています。特に運用コスト削減に関する内容が多くなっています。処理性能については良くするというより、必要な性能を確保するという内容になっています。

このブログでは散発的な記事しか書いていませんが、このブログに書いていない内容の方が多くなっています。

以下のような問題に遭遇した方は、ぜひ読んでいただきたいと思っています。解決策が見つかるはずです。

費用

クラウドを使っているけど運用費用が想定より高い。
クラウドに乗り替えたらオンプレミス／レンタルサーバより運用費用が増えた。

性能

スケーリングができない。
リクエストの処理に時間がかかる。
スケールアウトのたびにリクエストのレイテンシが増加してレスポンスが悪い。

その他

そもそもクラウドをどのように使えばいいのかわからない。
非同期処理／バッチ処理の効率的な実装方法がわからない。
非同期処理が意図せず中断する。

A4サイズでデザインしたところ全部で100ページ近い分量になりました。読みごたえがあります。noteでは 1記事=1ページなので、長い記事は読みにくくなります。それを回避するため複数の記事に分割し、まとめてマガジンとしています。

分量や、経験からしか得られないノウハウも掲載していますので、有料としています。今は試しに半額にしています。いつまで半額かは未定で気分次第ですので、興味のある方はお早めに。

2026/04/07

Cloud Runの料金体系についての疑問

Cloud Runサービスには2種類の料金体系があります。

リクエストベース（デフォルト）
インスタンスベース

デフォルトのリクエストベースの料金体系はおなじみです。webサーバを構成するCloud Runサービスの機能とも一致していて、わかりやすいのですね。

一方でインスタンスベースの料金体系はどういう状況で使うべきなのかずっと理解できませんでした。

インスタンスベースの料金体系

この疑問については偶然ですが、ブログ記事「新しい CPU 割り当てコントロールにより Cloud Run 上でさらに多様なワークロードを実行」を見つけて理解できました。

2021/09/28とちょっと古い記事なので、時期的にはCloud Runにはまだサービスしかありません。Jobsはまだリリースされていません。Cloud Functionsはまだ第1世代のみで、Cloud Runとは独立したプロダクトという位置づけでした。

結論ですが、ユースケースとしてはCloud Runサービスでサブスレッドを使って非同期処理を実行する場合を考慮したものでした。Cloud Runサービスではメインスレッドでリクエストを受信後、そのメインスレッドでレスポンスを返すと処理が終了したものと判断されます。そしてリクエストを処理していないインスタンスは、その後一定時間新たなリクエストが割り当てられないと、スケールインしてスピンダウンする対象となります。

ここでリクエスト開始～レスポンスを返すまでの間にサブスレッドを生成し、そのサブスレッドでメインスレッドよりも時間のかかる処理を行う実装を行っているとします。メインスレッドがレスポンスを返してしまった時点で、プラットフォーム（Cloud Runサービス）からは処理中のリクエスト数=0 と見えてしまい、インスタンスのスピンダウンが起きます。この時点でまだサブスレッドは実行中だと、完了前に強制終了させられることになります。

これを避けるために上記の記事にあるように、CPUの常時割り当ての機能が追加されたということです。最小インスタンス数の設定と組み合わせることで、インスタンスの強制終了によるサブスレッドの停止を回避できます。そしてそれに対応する料金体系がインスタンスベースということでした。

歴史は繰り返す?

App Engineでも同じ問題は起きていましたね。App Engineだけ使う場合はサブスレッドを諦めて、タスクキューで解決していました。

Cloud RunでもCloud Tasksと組み合わせれば同様の方法で回避可能です。

より新しいソリューション

現在では非同期処理を実装するためには、BatchやCloud Run Jobsが用意されています。これらはスレッドだけでなくタスクでも並列処理を実装できます。タスクの方がCPU・メモリリソースを分け合わないので、実装やパフォーマンスチューニングは簡単です。起動に時間がかかりますが。

2026/02/09

生成AIに対する既視感

Oh, deja vu!

現在AIが絶賛大人気、話題の中心となっています。会話が出来て、プロンプトさえ書けば絵が描けて動画も作ってくれて。もう何でもやってくれそう... という意見さえ、あったような、なかったような。

しかし話題になり始めたころから、過剰に期待しすぎているようにしか感じない、この盛り上がりに既視感を感じていました。1980年前後のSF映画には「コンピュータ様がなんとかしてくださる」みたいなシーンが登場することがあります。それに似ているような感覚があります。

でも進化? も

以前との違いは、これまでの現実感がなくて絵空事で終わっていたAIと違って、今の生成AIはやる気になれば自分で使うことができますし、そうでなくてもチャットによるサポート（しかし期待する答えが返ってきたことは1度もない）などの形で一般の生活の中でも目にするようになっています。

私がかかわっているIT業界では、もっともAIが身近ではないかと思います。調べ物に使ったり、ドキュメントを書かせる人もいたり（私は自分で書くのでやってませんが）、コーディングでのコード補完やレビューと、私でもそれなりに使っています。

今の生成AIはバブル疑惑

しかし調べれば調べるほど、今話題の生成AIも、バブルで終わりそうな気配しか感じません。根拠は私が読んだものの一部のみ紹介、過去読んだものは探し出せなくなったものも数多くあります。

成果
実際にAIに関わっているプロジェクトで利益を出せたのはごくわずかでしかなく、ほとんどは利益につながっていない。少し前の調査では70%というものもありましたが、最新の調査では母数が増えたからかより厳しい数値が出ています。

生成AI自身の限界
大規模言語モデル（LLM）の学習規模を拡大することで性能を向上してきましたが、すでにこれ以上規模を拡大しても性能に変化がないところまで来ています。さらなる性能向上には別のアイデアが必要ですが、そこはまだ手探り状態。

データセンター建設への障害
将来のAI需要を満たすための新たなデータセンター建設に対して、予定地の周辺住民が反対活動に至る例も。日本でも世界でも。

DRAM需要逼迫
データセンターの増強・新設によりHBMの需要が急増、それに伴い生産ラインHBMにシフトしたためPC・スマホ・家電・自動車など他分野製品向けDRAMの生産が減少して価格上昇。これは大方の予測どおりパニック買いと思われますが、すでに価格は3倍以上に跳ね上がっています。半導体の生産ラインを増やすのは簡単ではなく、なんやかんやで3年程度はかかります。DRAMを作っているメーカーはすでに世界で3社しかないこともあり、解決はしばらく先。このままデータセンターの増設が続けば本当に「DRAMが手に入らない」事態が現実に。その影響がまわりまわって、AIとは無関係な製品・サービスの値上がりが起きそうな予感も。

その他にも「経験の浅い技術者がAIでクソコードを量産してレビューが地獄」等など「使えない」事例や、将来性に疑問があることの根拠は、きりがないくらい出てきます。

半端なAIならいらなくない?

巷の反応を見ていると、現在の生成AIと、まだ実現されていない汎用AI（AGI）を混同している人も少なくない気がします。現在の生成AIは、目的特化で実現されたものであって、汎用ではありません。向かないことをさせれば、ボロを出します。

現在の生成AIは、出来ることが限られていることや、ハルシネーションの影響、期待する結果に近づけるためにはユーザの努力が要求されるなど、期待させている割に性能的には中途半端と判断しています。正直、この程度ならなくてもそんなに困りません。

現在の生成AIに限ってですが、最も上手く使いこなした例はこちらのような動画ではないでしょうか（でも詩を作ったのはAIじゃなさそう）。おもちゃにするにはいいのですが、実用品として例えるならその実力は、手間・実用性などからT型フォードあたりがふさわしい気がします。

今後はおそらく、有効な使い方が判明するにつれて特定の分野・使い方で限定的に残っていくものと思われます。その結論が出始めると、バブルも終わるでしょう。