アクセス急増への備えも不要、技術負債の堆積を防ぐ
第3はアクセス急増耐性とレイテンシーのバランスを取るために使うことだ。「国内向けサービスなら東京リージョンにサーバを置いておけばいいのでは」「アクセス数もそんなにない」とは言いつつも、エンジニアであれば日頃からアクセス急増への備えをし設計と実装を行い、それでもなおどこかで不安を抱えているもの。だがFastlyならそんな心配は不要で、開発の負担を減らしてくれる。「サーバレスにありがちなコールドスタート問題や同時並列性、スケーリングの設定など一切不要になります。それがエッジクラウドの特徴です」（澤田氏）
これはFastlyに限らず、エッジクラウドの特徴なので、是非活用し、開発を楽に進めてほしいという。例えば某新聞社では、自社で運用していたインフラの一部をFastly Computeに移行した。その結果メンテナンスも楽になり、インフラ自体のコスト低減にも成功、新しいソフトウェアのデプロイする時間も数時間のオーダーから分レベルのオーダーに短縮されたという。
第4はエッジの処理に対してテストを書くという使い方もできることだ。配信コストはミニマムになっていたとしても、技術スタックが古く脆弱性も放置されているなど、技術的負債が溜まっていることもあるという。
「健全な技術スタックを保っていくことは、将来的に運用しやすい体制を作ることになり、技術チームのコンディションも上がる。さらにはいろんな技術課題を解決しやすくなり、障害を減らしやすく出来るなどの効果がある」と澤田氏は指摘する。その一助になるのがテストを書くことだ。CDNは先述したように、プログラムをエッジ上で走らせることができる。「CDN上の処理についてもテストを書くことで、将来的により運用コストを下げられるような状態にしておくのは価値があると思う」（澤田氏）
第5は、egress無料のS3互換ストレージを活用することだ。昨年末、FastlyはS3互換でegress無料のFastly Object Storageをリリースした。同サービスを活用することで、トータルコストを下げることができるようになる。読み書きのオペレーションごとに回数に応じた従量課金があることに注意は必要だが、「Fastlyを使っているのであれば、確実に利用を検討した方が良い」と澤田氏は言い切る。（なお本稿が執筆されている2025年4月時点で、Fastly外のネットワークに向けた接続については～150Mbpsまでの速度制限と、100req/sec/bucketの制限がかかることに注意。Fastly内ネットワークへの接続についてはこの制限は適用されない）
第6は、Fastly Computeを利用することで自然と標準準拠のAPIを利用した開発が多くなるため、チームの競争力の強化にもつながることだ。その際に抑えておきたいポイントがある。「ベンダーロックインをどこまで許容するか、ポータビリティをどれだけ確保するかという観点を、必ず技術スタックを選定する際のディスカッションの項目に入れておくこと。そうすることで技術スタックの選択の幅が広がり、開発メンバーのやりくりのしやすさにもつながってくるからです」（澤田氏）
最後に第7は、セマンティックキャッシュでLLM利用の効率化が図れることを解説した。
「CDNは適切に使うと開発工数の低減にもつながる、セキュリティ対策にも効く。ぜひ、CDNのネットワークを活用して開発を楽に進めていってほしい」最後にこう語り、澤田氏はセッションを締めた。
