はじめに
AIコーディングによって、ソフトウェアを「作る」ハードルはかなり下がりました。
以前なら実装を諦めていたような小さなアイデアでも、AIと対話しながら簡単に形にできます。
ただ、動くものができたところで、次の疑問が出てきます。
これを、どうやって他の人に使ってもらうのか。
コードが動くことと、社会で使われることは同じではありません。
デプロイ、データ保存、認証、セキュリティ、コスト、運用。
AIによって「作る」が簡単になるほど、その先にある社会に出すための仕組みが重要になってきます。
今回は「AIの社会実装」をこの視点から考え、そのための基盤としてVercel、AWS、Cloudflareを比較してみます。
AIの「社会実装」とは何だろう
「AIの社会実装」というと、大企業や自治体がAIシステムを導入するような話を想像するかもしれません。
もちろん、それも社会実装です。
ただ、AIによってソフトウェアを作るコストが下がるなら、社会実装の単位ももっと小さくなっていくはずです。
例えば、自分の業務を楽にするために作ったツールがあります。
最初は自分だけで使う。
便利だったのでチームでも使う。
そのうち社外の人にも使えると分かり、サービスとして公開する。
自分で使う
↓
チームで使う
↓
組織で使う
↓
外部の人が使う
↓
サービスになる
この間に、明確な境界があるわけではありません。
この記事では社会実装を、
作ったものが自分の環境を出て、自分以外の誰かに継続して使われる状態になること
くらいに捉えます。
この定義なら、SaaSだけでなく、社内ツールや地域向けの小さなサービスも社会実装に含まれます。
「作れる」と「社会に出せる」の間にあるもの
AIが大きく変えたのは、主に実装の部分です。
アイデア
↓
AIとの対話
↓
動くものができる
ここまでの距離はかなり短くなりました。
しかし、社会実装するならその先があります。
公開する
↓
データを保存する
↓
利用者を管理する
↓
安全に使えるようにする
↓
継続して運用する
コードを生成できても、URLは生まれません。
複数人で使えばデータの保存が必要になります。
利用者ごとに情報を分けるなら認証や認可が必要です。
ファイルを扱えばStorageが必要になり、利用が増えれば性能やコストも気になります。
AIによって実装コストが下がるほど、公開と運用の部分が相対的に大きな課題になるわけです。
「作れるようになった」の次に、「社会に出せるようになる」が必要になります。
AIによって、ソフトウェアを社会実装する人が変わる
もうひとつ変わるのが、「誰が作るのか」です。
これまでは、
業務を知っている人
↓
要求を伝える
↓
エンジニア
↓
ソフトウェア
という流れが一般的でした。
AIによって、ここに別の経路ができます。
業務を知っている人
↓
AIと対話する
↓
ソフトウェア
これは、「非エンジニアがプログラマーになる」という話ではありません。
業務を知る本人が、プログラミングという工程をすべて習得しなくても、ソフトウェアを作れるようになるということです。
重要なのは、
- 何に困っているのか
- どうなれば便利なのか
- 誰がどう使うのか
を知っていることです。
AIによって縮まるのは、課題を持つ人とソフトウェアを作る行為との距離です。
そうなれば当然、ソフトウェアを社会に出す主体も増えていきます。
社会実装の単位はもっと小さくなる
AIによって作るコストが下がれば、これまでなら作られなかったような小さなソフトウェアも増えていきます。
自分だけが使うツール。
チーム内の業務アプリ。
地域イベントで使う小さなサービス。
特定の業務だけを扱うMicro SaaS。
これらは別々の世界というより、かなり連続しています。
Personal
↓
Team
↓
Organization
↓
Community
↓
Micro SaaS
↓
Service
最初から商用サービスを目指すとは限りません。
自分の課題を解決するために作ったものが、結果として他の人にも使われることがあります。
AIによって増えていくのは、こうしたソフトウェアではないでしょうか。
「SaaSの民主化」という言葉でも一部は説明できます。
ただ、もう少し広く見るなら、
ソフトウェアを作り、誰かに届ける側への参入障壁が下がる
と考えた方が近そうです。
ここで重要なのが、作った後です。
ソフトウェアを作る人だけ増えても、それを公開するために従来と同じクラウド知識が必要なら、結局そこが次のボトルネックになります。
AI時代の社会実装基盤には何が必要なのか
「簡単にデプロイできる」ことは重要です。
ただ、それだけでは足りません。
社会実装を考えるなら、少なくとも三つの段階を連続して扱える必要があります。
まず公開できる
↓
使われ始めても対応できる
↓
そのまま育てられる
最初は静的なWebアプリかもしれません。
しかし使われ始めると、
APIが欲しい
データを保存したい
ファイルを扱いたい
定期処理をしたい
認証したい
AIを呼び出したい
と要求が増えていきます。
そのたびに別のプラットフォームへ移動するのであれば、「最初の公開が簡単」というだけでは社会実装基盤としては物足りない。
そこで、今回は次のような条件で考えます。
| 観点 | 求めたいこと |
|---|---|
| 入口 | 小さなアプリをすぐ公開できる |
| AIとの相性 | AIが生成しやすい一般的な技術で扱える |
| Git | ソースコードを中心に運用できる |
| バックエンド | API、DB、Storageなどへ自然に広げられる |
| 成長性 | 個人利用からサービスまで連続して扱える |
| コスト | 小規模でも始めやすい |
| 理解可能性 | インフラが完全なブラックボックスにならない |
| 独立性 | 特定のAIツールに強く依存しない |
ここで特に重要なのが、入口の低さと成長性を同時に満たすことです。
簡単なだけでは足りません。
高機能なだけでも足りません。
AIによって生まれた小さなソフトウェアを、そのまま社会実装へ持っていける必要があります。
この条件で、Vercel、AWS、Cloudflareを見てみます。
Vercelは「Shipする」までの距離が短い
Vercelの強さは、Webアプリケーションを公開するまでの距離の短さです。
GitへpushすればPreview環境が作られ、確認してProductionへ出せる。
Webプロダクトを高速に作り、公開する体験は非常によくできています。
AIとの親和性も高く、特にWebやAIアプリケーションを高速にShipするという目的では有力な選択肢です。
では、今回もVercelでよいのでしょうか。
ここで考えたいのは、今回の対象が「Webプロダクトを高速にリリースすること」だけではない点です。
AIによって増えていくと考えているのは、もっと雑多なソフトウェアです。
個人用ツールがチームで使われる。
データを持つ。
バックエンド処理が増える。
ファイルを扱う。
場合によっては非同期処理も必要になる。
Vercelでもこうした構成は作れます。
ただ、プラットフォームの中心にあるのは、あくまでWebアプリケーションを高速にShipする体験です。
今回探しているのは、その一歩先まで含め、
小さなソフトウェアを公開し、必要なインフラ能力を追加しながら育てていく
ための基盤です。
この点で、今回の評価軸とは少し中心がずれます。
AWSは「できないことがほとんどない」
反対側にいるのがAWSです。
社会実装されたシステムに必要なものは、ほぼ何でもあります。
Compute、Database、Storage、Network、Security、Monitoring、AI。
小さなサービスから大規模システムまで、そのまま伸ばしていけます。
将来的な要求への対応力という意味では非常に強力です。
ただ、その強さは選択肢の多さでもあります。
例えばWebアプリケーションを作るだけでも、構成によっては、
CloudFront
S3
API Gateway
Lambda
DynamoDB
Cognito
IAM
CloudWatch
といったサービスが登場します。
それぞれの役割を理解し、どう組み合わせるかを考える。
これは本格的なシステムを作るときにはむしろ強みです。
一方で、
AIと一緒に小さなツールを作ったので、まず誰かに使ってもらいたい
という段階では、少し要求される知識が多い。
もちろんAmplifyなど、AWSにも入口を軽くする仕組みはあります。
それでもAWSの最大の強みは、
必要なサービスを組み合わせて、ほぼどんな要求にも対応できること
にあります。
今回探しているのは、そこまで大きな自由度を最初から要求せず、もう少し小さく社会実装を始められる基盤です。
Cloudflareは「公開」と「インフラ」の距離が近い
ここでCloudflareを見てみます。
現在のCloudflare Developer Platformでは、Workersを中心に、
Workers
├─ D1
├─ KV
├─ R2
├─ Durable Objects
├─ Queues / Workflows
└─ Workers AI
といった機能が並んでいます。
最初はWorkerひとつでも始められます。
データベースが必要になればD1。
ファイルならR2。
Key-ValueならKV。
非同期処理ならQueuesやWorkflows。
AI推論が必要ならWorkers AI。
重要なのは、サービスの数ではありません。
公開するための基盤と、社会実装に必要になるインフラが近い場所にあることです。
まず公開する
↓
データを持つ
↓
APIを増やす
↓
ファイルを扱う
↓
非同期処理を追加する
↓
サービスとして育てる
この流れを、同じプラットフォームの中で比較的自然に進められます。
Vercelのように入口は軽い。
しかし、Compute、Database、Object Storage、Queueといったインフラの構成要素も見えている。
AWSのようにバックエンドへ成長できる。
しかし、最初から多数のクラウドサービスを組み合わせる必要はない。
この入口とインフラの距離の短さが、今回Cloudflareを評価している大きな理由です。
AI生成ソフトウェアとの方向性も一致している
もうひとつ、Cloudflareを選ぶ理由があります。
今回考えているのは、
AIによって大量の小さなソフトウェアが生まれ、それを誰かが社会に出していく
という世界です。
Cloudflare自身も、この方向へ明確に動いています。
Workers for Platformsでは、ユーザーが書いたコードだけではなく、AIによって生成されたコードを隔離された環境で実行するユースケースが想定されています。
つまり、
人間がすべてコードを書く
↓
クラウドへデプロイする
という従来のモデルだけではなく、
人間がAIへ要求する
↓
AIがコードを生成する
↓
そのコードが実行・公開される
というモデルまで、プラットフォーム側が見始めています。
もちろん、それだけでCloudflareを選ぶ理由にはなりません。
ただ、
- 小さく始められる
- バックエンドへ成長できる
- インフラ構成が見える
- AI生成コードを前提とした方向へ進んでいる
という条件が重なってくると、今回のテーマとの親和性はかなり高くなります。
3つのプラットフォームを社会実装の観点から見る
ここまでを整理すると、次のようになります。
| 観点 | Vercel | Cloudflare | AWS |
|---|---|---|---|
| 最初の公開 | ◎◎ | ◎ | ○ |
| WebアプリのDX | ◎◎ | ◎ | ○〜◎ |
| バックエンドへの成長 | ◎ | ◎◎ | ◎◎ |
| 小規模から始める | ◎◎ | ◎◎ | ○〜◎ |
| インフラ構成の見え方 | △〜○ | ◎ | ◎◎ |
| 最初に必要なクラウド知識 | 少ない | 少なめ | 多くなりやすい |
| 複雑な要件への対応 | ○〜◎ | ◎ | ◎◎ |
| AI生成ソフトウェアとの方向性 | ◎◎ | ◎◎ | ◎ |
| 個人利用からサービスへの連続性 | ◎ | ◎◎ | ◎ |
単純化するなら、
Vercel
Webプロダクトを素早くShipする
Cloudflare
小さく公開し、そのまま社会実装へ育てる
AWS
あらゆる要求に対応しながら大きく育てる
という違いが見えてきます。
もちろん、実際にはそれぞれの領域は重なっています。
ただ今回のテーマは、
AIで生まれた小さなソフトウェアを、できるだけ摩擦なく社会へ出すこと
です。
この条件を置くと、Cloudflareがかなり特徴的な位置にいることが分かります。
なぜCloudflare Firstなのか
今回Cloudflareを選ぶ理由は、「簡単だから」ではありません。
単に簡単なだけなら、他にも選択肢はあります。
重要なのは、
作る
↓
公開する
↓
使ってもらう
↓
データを持つ
↓
機能を増やす
↓
運用する
この流れを、できるだけ分断せずに扱えることです。
AIによってソフトウェアの作成コストが下がるほど、最初から巨大なシステムを作る必要はなくなります。
まず、小さく作る。
公開する。
誰かに使ってもらう。
必要になったら育てる。
その進め方に対して、
小さな入口と、十分な成長先が同じ場所にある
ことは大きな意味を持ちます。
さらに、CloudflareではWorkers、D1、R2、KVといった構成要素が完全に隠されているわけではありません。
最初は詳しく知らなくても始められる。
必要になれば、それぞれがCompute、Database、Object Storage、Key-Value Storeであることを理解していける。
簡単さのためにインフラを完全に隠すのでもない。
本格的なクラウド知識を最初から要求するのでもない。
この距離感が、AI時代の社会実装基盤としてCloudflareを選ぶ大きな理由です。
Cloudflare First, not Cloudflare Only
Cloudflareが万能という話ではありません。
Next.jsを中心にWebプロダクトを高速にShipしたいなら、Vercelが自然な場面があります。
企業システムとの複雑な連携、高度なネットワーク構成、多様なManaged Serviceが必要なら、AWSが適していることも多いでしょう。
重要なのは、先にプラットフォームを決めることではありません。
何を社会実装したいのか
↓
誰が使うのか
↓
どのくらい小さく始めたいのか
↓
どのように育つ可能性があるのか
↓
必要な基盤は何か
↓
プラットフォームを選ぶ
この順番です。
今回の条件では、その最初の選択肢としてCloudflareがかなりよく合います。
だから、
Cloudflare First, not Cloudflare Only
です。
まとめ
AIによって、「作れる」ことは急速に身近になっています。
しかし、AIの社会実装を考えるなら、それだけでは足りません。
作ったものを公開できる。
誰かが使える。
データを持てる。
継続して運用できる。
必要に応じて育てられる。
そこまでつながって、初めて「作れる」が「使われる」に変わります。
そして、AIによってソフトウェアを作る主体が増えるなら、クラウドに求められるものも少し変わります。
機能、性能、価格、可用性だけではなく、
社会実装までの距離がどれだけ短いか
という評価軸が重要になります。
その観点で見ると、Vercelは「Shipする」ことに強い。
AWSは、社会実装後の幅広い要求に対応できる。
Cloudflareは、その間で小さく始め、社会へ出し、そのまま育てることに強い。
AIによって「作れる」が民主化され始めた今、その次に必要なのは「社会に出せる」の民主化です。
その入口として、Cloudflareはかなり興味深い位置にいます。