2025年05月08日
なぜJamstackはセキュアと言われるのか?WordPressとの比較と対策

近年注目を集めるウェブサイト構築アーキテクチャ「Jamstack」。その特徴の一つとして、高いセキュリティ性が挙げられます。本記事では、Jamstackがセキュリティに優れる理由を解説し、広く利用されているWordPressと比較しながら、具体的な対策についても掘り下げていきます。
Jamstackがセキュリティに優れる理由
Jamstackが従来のアーキテクチャと比較してセキュリティが高いと言われる主な要因は、以下の点に集約されます。
- サーバーレスアーキテクチャ: 静的なファイルをCDN経由で配信し、動的な処理はAPIに依存するため、ウェブサーバー自体が攻撃対象となるリスクを大幅に低減できます。常時稼働するデータベースやサーバーサイドアプリケーションが存在しないため、侵入経路が減少します。
- 攻撃対象の縮小: WordPressのようなCMSは、データベース、PHP実行環境、CMS本体、プラグイン、テーマなど、多岐にわたる要素が攻撃対象となり得ます。一方、Jamstackサイトは静的なファイルが中心であり、これらの攻撃対象を大幅に削減できます。
- 機能の分離: 動的な機能は、認証、データベース、フォーム処理など、特定のタスクに特化した外部APIやサービスに委譲されます。これにより、単一の脆弱性がサイト全体に影響を及ぼすリスクを軽減できます。
- CDNによる配信: CDNは一般的にセキュリティ対策が施されたインフラストラクチャ上で動作し、DDoS攻撃などへの耐性が高い傾向があります。また、静的ファイル配信はサーバーサイド処理の必要がないため、サーバー側の脆弱性を利用した攻撃を防ぎます。
WordPressとのセキュリティ比較
WordPressは非常に普及しているCMSであるため、常に攻撃者の標的となりやすい状況にあります。プラグインやテーマの脆弱性、本体のアップデート遅延、サーバー設定の不備などがセキュリティインシデントの原因となる可能性があります。SQLインジェクションやPHPの脆弱性を利用した攻撃も懸念されます。
一方、Jamstackは静的ファイルが中心であるため、これらの攻撃経路は基本的に存在しません。動的な処理はAPIに依存しますが、適切に選定・管理されたAPIサービスを利用することで、ウェブサーバー自体の脆弱性リスクを低減できます。
ただし、Jamstackも完全に安全ではありません。利用するAPIサービスのセキュリティ、フロントエンドのJavaScriptコードの脆弱性、ビルドプロセスのセキュリティなどが新たなリスクとなる可能性があります。重要なのは、それぞれのアーキテクチャの特性を理解し、適切なセキュリティ対策を講じることです。
Jamstackサイトが改竄される可能性と対策
Jamstackアーキテクチャは、その特性から従来の動的なウェブサイトと比較してセキュリティが高いと考えられていますが、完全に改竄のリスクがないわけではありません。ここでは、Jamstackサイトが改竄される主な経路と、それに対する具体的な対策を掘り下げて解説します。
1. 利用するAPIサービスの脆弱性
Jamstackサイトでは、フォームの送信、認証、Eコマース機能、検索など、動的な処理を外部のAPIサービスに依存するケースが多くあります。これらのAPIサービスにセキュリティ上の脆弱性があった場合、そこを足がかりに不正アクセスが行われ、データが改竄されたり、悪意のあるコンテンツが挿入されたりする可能性があります。
改竄の例:
- フォームから送信されたデータが不正に操作され、意図しない情報がバックエンドに送られる。
- 認証APIの脆弱性を突かれ、不正なユーザーが管理者権限を奪取する。
- EコマースAPIの脆弱性を利用して、商品情報や価格が改竄される。
対策:
- 信頼できるAPIサービスの選定: 実績があり、セキュリティ対策に力を入れているAPIプロバイダーを選びましょう。提供しているサービスのセキュリティに関する情報を確認し、脆弱性への対応状況などを把握することが重要です。
- APIキーの適切な管理: APIキーは機密情報であり、ソースコードや公開リポジトリに直接埋め込むことは絶対に避けるべきです。環境変数やサーバーレス関数の環境設定などを利用して安全に管理し、不正なアクセスから保護しましょう。
- APIの利用範囲の制限: APIによっては、利用元のドメインやIPアドレスを制限できる場合があります。可能な限り設定し、不正なリクエストを遮断しましょう。
- APIのアップデートの適用: 利用しているAPIサービスのアップデート情報を常に把握し、セキュリティ関連のアップデートが提供された場合は速やかに適用しましょう。
- レート制限の実装: APIへの過剰なリクエストを防ぐために、レート制限を実装することを検討しましょう。DoS攻撃などのリスクを軽減できます。
2. フロントエンドのJavaScriptの脆弱性
Jamstackサイトのインタラクティブな要素は、主にJavaScriptによって実現されます。もしJavaScriptコードにセキュリティ上の欠陥(脆弱性)があった場合、クロスサイトスクリプティング(XSS)などの攻撃を受ける可能性があります。XSS攻撃を受けると、悪意のあるスクリプトがユーザーのブラウザ上で実行され、Cookieやセッション情報が盗まれたり、サイトの表示が改竄されたりする可能性があります。
改竄の例:
- 悪意のあるスクリプトが埋め込まれ、サイトの見た目が意図しないものに変更される。
- ユーザーが入力した情報が、攻撃者のサーバーに不正に送信される。
- Cookieが盗まれ、攻撃者がユーザーになりすましてサイトを操作する。
対策:
- ユーザー入力の適切なエスケープ処理: ユーザーからの入力(例えば、検索フォームのキーワード、コメントなど)をそのままHTMLに出力する前に、必ずエスケープ処理を行いましょう。これにより、悪意のあるスクリプトが実行されるのを防ぎます。
- Content Security Policy (CSP) の設定: CSPは、ブラウザが読み込むことを許可するリソース(スクリプト、スタイルシート、画像など)の配信元を制限する仕組みです。CSPヘッダーを適切に設定することで、XSS攻撃の影響を大幅に軽減できます。
- Subresource Integrity (SRI) の利用: SRIは、CDNなど外部の配信元から読み込むファイル(JavaScriptライブラリなど)の整合性を検証する仕組みです。
<script>タグや<link>タグにintegrity属性を追加することで、ファイルが改竄されていないことをブラウザが確認できます。 - 信頼できるライブラリの利用と定期的なアップデート: 利用するJavaScriptライブラリは、セキュリティに関する実績があり、活発にメンテナンスされているものを選びましょう。また、ライブラリに脆弱性が発見された場合は、速やかに最新バージョンにアップデートすることが重要です。
- セキュリティレビューの実施: コードレビューや静的解析ツールなどを活用して、JavaScriptコードに潜在的な脆弱性がないか定期的にチェックしましょう。
3. ビルドプロセスの侵害
Jamstackサイトは、通常、静的サイトジェネレーター(SSG)などを用いて、ソースコードから静的なファイルを生成するビルドプロセスを経ます。もしこのビルドプロセスが侵害された場合、生成された静的ファイルに悪意のあるコードが埋め込まれる可能性があります。
改竄の例:
- ビルドスクリプトが改竄され、意図しないJavaScriptコードが最終的なHTMLファイルに挿入される。
- 依存しているパッケージに脆弱性があり、ビルド時に悪意のあるコードが混入する。
- ビルドを実行するサーバーが侵害され、生成されたファイルが改竄される。
対策:
- ビルド環境のセキュリティ強化: ビルドを実行するサーバーのアクセス制御を厳格に行い、不正なアクセスを防ぎましょう。
- 依存関係の管理と監査:
package-lock.jsonやyarn.lockなどを利用して依存関係を正確に管理し、セキュリティスキャンツールなどで脆弱性を定期的にチェックしましょう。 - ビルドパイプラインの監視: CI/CDパイプラインの各ステップを監視し、不審なアクティビティがないかを確認しましょう。
- ビルド成果物の検証: ビルドされた静的ファイルの内容を定期的に確認し、意図しない変更がないかをチェックしましょう。
- 信頼できるツールの利用: ビルドプロセスで使用するツールは、信頼できる開発元が提供しているものを選びましょう。
4. CDNのアカウントの侵害
Jamstackサイトの静的ファイルは、通常CDN(コンテンツ配信ネットワーク)を通じて配信されます。もしCDNのアカウントが不正にアクセスされた場合、配信されている静的ファイルが改竄され、サイトの見た目が変わったり、悪意のあるコンテンツが表示されたりする可能性があります。
改竄の例:
- CDNに保存されているHTMLファイルが書き換えられ、偽のログインフォームが表示される。
- JavaScriptファイルが改竄され、ユーザーの行動を追跡するスクリプトが埋め込まれる。
- 画像ファイルが差し替えられ、不適切なコンテンツが表示される。
対策:
- 強力なパスワードと二段階認証の設定: CDNアカウントのパスワードは複雑なものを使用し、可能な限り二段階認証を設定しましょう。
- アクセス権限の適切な管理: 複数人でアカウントを共有する場合は、担当者ごとに必要な権限のみを付与し、不要なアクセス権限は削除しましょう。
- アクセスログの監視: CDNのアクセスログを定期的に監視し、不審なアクセスがないかを確認しましょう。
- HTTPSの強制: CDN経由での通信をHTTPSで暗号化し、中間者攻撃による改竄を防ぎましょう。
- WAF (Web Application Firewall) の導入: CDNによっては、WAF機能を提供している場合があります。WAFを導入することで、悪意のあるリクエストを遮断し、改竄のリスクを軽減できます。
5. 開発環境の侵害
開発者のPCや開発環境がマルウェアに感染した場合、意図しないコードがリポジトリにコミットされ、それがデプロイされてしまう可能性があります。
改竄の例:
- 開発者の意図しないバックドアがコードに仕込まれ、デプロイされてしまう。
- マルウェアによって、機密情報(APIキーなど)が盗まれ、悪用される。
対策:
- 開発者PCのセキュリティ対策: オペレーティングシステムやソフトウェアを常に最新の状態に保ち、信頼できるセキュリティソフトを導入しましょう。
- 不審なメールやファイルを開かない: フィッシング詐欺などに注意し、不審なメールやファイルは安易に開かないようにしましょう。
- バージョン管理の徹底: Gitなどのバージョン管理システムを利用し、変更履歴を適切に管理しましょう。不審なコミットを発見した場合、速やかにロールバックできるように備えておきましょう。
- リモートアクセスの制限: 開発環境へのリモートアクセスは必要最低限に留め、アクセスする場合は安全な接続方法(SSHなど)を利用しましょう。
これらの対策を講じることで、Jamstackサイトのセキュリティレベルを大幅に向上させ、改竄のリスクを低減することができます。Jamstackの特性を理解した上で、多角的なセキュリティ対策を実践していくことが重要です。
この記事をシェアする
最近の投稿

Jamstackサイトはどこから乗っ取られる?不正アクセスの経路と確認する場所
「JamstackはWordPressより安全」とよく言われます。ブラキオのブログでも、で、その理由を紹介しました。ただ、実際にサイトを運用していると、次のような疑問が出てきます。この記事では、弊社のサイトと同じ「microCMS × Next.js(静的書き出し)× Netlify」の構成を例に、これらの疑問に答えます。Next.jsで静的に書き出したサイトは、ビルドのときにHTMLを作り、Netlifyなどのホスティングサービスから配信します。アクセスのたびに動くプログラムも、公開側のデータベースもありません。CMSの管理画面は、サイトとは別のドメインにあります。そのため、WordPressで典型的な次のような攻撃は、構造上成り立ちません。 を探して回る自動スキャンが来ても、404が返るだけです。ただし、リスクがゼロになるわけではありません。、と考えるのが正確です。なお、Next.jsでもSSRやAPIルートを使ってサーバーを動かす構成では、話が変わります。2025年3月には、Next.jsのミドルウェアで行っている認可チェックを、特定のリクエストヘッダーを付けるだけで素通りできる脆弱性(CVE-2025-29927)が公表されました。同年12月には、React Server Componentsのサーバー関数に細工したリクエストを送ると、認証なしで任意のコードを実行できる脆弱性(CVE-2025-55182、通称「React2Shell」)が公表され、実際に悪用も確認されています。静的に書き出したサイトではミドルウェアもサーバー関数も動かないため、こうしたサーバー側の脆弱性の影響を受けません。Jamstackサイトで現実的な経路は、次の4つです。経路何が起きるか起きやすさアカウントの乗っ取りCMS・ホスティング・GitHubなどにログインされ、記事を書き換えられたり、偽のサイトをデプロイされたりする中npmパッケージのサプライチェーン攻撃ビルドのときに不正なコードが動き、APIキーなどを盗む。配信するJavaScriptに不正なコードが混ざる中CMSの本文に仕込まれたスクリプト記事を開いた訪問者のブラウザで、スクリプトが動く低〜中書き込み権限のあるAPIキーの漏洩APIから記事を書き換えられる低※「起きやすさ」は、弊社の運用経験からの目安です。いちばん起きやすい経路です。守るべきアカウントは、CMS・ホスティング・GitHubの3つだけではありません。手口は、フィッシングやパスワードの使い回しが中心です。最近は、PCに入り込んだマルウェア(インフォスティーラー)がログイン中のセッションを盗み、二段階認証をすり抜ける手口も増えています。自分たちのアカウントが無事でも起きる経路です。乗っ取られるのは、依存しているパッケージの作者のアカウントです。2025年9月8日には、chalkやdebugといった広く使われている18のパッケージに、不正なバージョンが公開されました。作者のnpmアカウントが、npm公式を装った偽ドメインからの「二段階認証の再設定」メールでフィッシングされたのが原因です。仕込まれたコードはブラウザ上で動き、暗号資産の送金先を攻撃者のものに書き換えるものでした。不正なバージョンは約2時間で取り下げられましたが、その間にビルドしたサイトには、配信するJavaScriptに不正なコードが紛れ込んだ可能性があります。同じ月には、インストール時に開発者のPCやCIからnpm・GitHub・クラウドの認証情報を盗み、盗んだnpmトークンで同じ作者の他のパッケージにも自動で感染を広げるワーム(Shai-Hulud)が見つかりました。11月には第2波(Shai-Hulud 2.0)が始まり、被害パッケージは数百から千以上に広がっています。このように、不正なコードはビルドのときに動いて環境変数に置いたAPIキーを盗むこともあれば、配信するJavaScriptに紛れ込んで訪問者のブラウザで動くこともあります。CMSの本文をHTMLとしてそのまま表示する作りだと、CMSに書き込める人は誰でもスクリプトや、画像タグのイベント属性に仕込んだコードを入れられます。乗っ取られたアカウントだけでなく、正規の編集者が外部サイトからコピーした埋め込みコードを貼ってしまうケースもあります。静的に書き出すサイトでは、本文がビルドのときにHTMLファイルへ書き込まれます。そのため、ページを開いた時点でスクリプトが実行されます。APIキーは、Gitの履歴やチャット、ビルドログ、メンバーのPCなどから漏れます。読み取り専用のキーなら書き換えはできませんが、書き込み権限があれば、APIから記事を書き換えられます。多くの場合、問い合わせてきた人の個人情報は盗まれません。お問い合わせフォームの入力は、Netlify Formsなどのフォームサービスに保存されることが多く、CMSには入っていないからです。CMSにあるのは、ブログ記事や会社情報など、もともとサイトで公開している内容が中心です。ただし、キーの権限によっては、公開していない情報も取れます。microCMSのAPIキーは、サービス全体に適用される「デフォルト権限」と、APIごとの「個別権限」で、GET / POST / PUT / PATCH / DELETE を個別に設定できます。作成・編集ができるのは管理者だけです。さらに、書き込み権限があるキーなら、前の章の「CMSの本文に仕込まれたスクリプト」を使って、これから訪問者が入力する情報を盗むこともできます。ビルドで使うAPIキーは、にしておきましょう。CMSに個人情報がないなら、書き換えられても大した被害はない。そう思われるかもしれません。しかし、被害はデータではなく、に出ます。企業サイトは「会社の顔」です。改ざんされたという事実だけで、問い合わせや採用への影響は小さくありません。静的なサイトには、侵入されるサーバーがありません。見るべきなのは、サイトのアクセスログよりも、です。Jamstackは、サイトそのものを外から突かれるリスクを大きく減らせる構成です。一方で、守る対象がなくなるわけではありません。攻撃の的は、とに移ります。裏を返せば、二段階認証やAPIキーの権限、依存パッケージの管理といった運用の基本を押さえれば、Jamstackの安全性をしっかり活かせます。ブラキオでは、Jamstackサイトの制作だけでなく、公開後の保守・運用もお手伝いしています。「今のサイトの設定が安全か確認したい」といったご相談も、お気軽にお問い合わせください。
2026.10.22

デザイン支給でWeb実装を依頼するときに整理しておきたいこと
「デザインはFigmaで完成しているので、あとは実装だけお願いしたい」Web制作のご相談では、こうしたケースもよくあります。見た目のデザインが決まっていれば、制作はすぐ始められそうに見えます。ただ、実際にWebサイトとして動かすためには、デザインデータだけでは判断できないことも少なくありません。たとえば、次のような内容です。こうした情報が最初にある程度整理されていると、見積もりの精度が上がり、実装開始後の確認や手戻りも減らしやすくなります。この記事では、デザイン支給でWeb実装を依頼するときに、事前に整理しておくと進めやすいポイントを紹介します。最初に確認したいのは、今回の依頼範囲です。たとえばコーポレートサイトであれば、次のように必要なページを一覧にしておくと分かりやすくなります。Figma上にすべてのページが並んでいる場合でも、「このページは今回の対象」「これは既存ページを流用する」といった区別があると、見積もり時の認識差を減らせます。また、似たページが複数ある場合は、共通レイアウトなのか、それぞれ個別に作る必要があるのかも実装工数に関わります。まずは細かな技術仕様よりも、 を明確にすることが大切です。PC版のデザインは完成していても、スマートフォン版が用意されていないケースがあります。その場合、実装側である程度判断してレスポンシブ対応することもできますが、次のような判断が必要になる部分があります。スマートフォン用デザインがあるのが理想ですが、すべての画面サイズを細かくデザインする必要はありません。「スマホではこの順番にしたい」「この画像は見切れても問題ない」など、特にこだわりたい部分だけでも共有しておくとスムーズです。静止画のデザインからは分からないのが、Webサイト上での動きです。動きまでFigmaで細かく作り込まれている必要はありません。「ここはふわっと表示したい」「このエリアは横にスライドする」といったコメントや参考サイトがあるだけでも、実装側は意図を理解しやすくなります。逆に指定がない場合は、実装側で一般的な挙動を提案してもらう方法もあります。デザイン上では仮の文章や画像が入っていることがあります。実装を始める前に、次の素材が揃っているか確認しておくと安心です。お問い合わせフォームがある場合は、見た目だけでなく次の仕様も決める必要があります。デザイン上にフォームが描かれていても、これらの仕様までは分からないことが多いため、実装担当者と早めに確認しておくのがおすすめです。サイト制作では、公開後の運用方法によって実装方法が変わることがあります。たとえば次のような情報を社内で更新したい場合、CMSを使えるようにしておくと運用しやすくなります。一方で、ほとんど変更しないページまで管理画面から編集できるようにすると、必要以上に仕組みが複雑になることもあります。「どの情報を、誰が、どのくらいの頻度で更新するのか」を整理したうえで、更新が必要な範囲だけCMS化するのも一つの方法です。公開時の見た目だけでなく、公開後の運用まで含めて考えると、使いやすいサイトになりやすくなります。新規サイトではなく、既存サイトのリニューアルや一部改修の場合は、現在の環境についても確認が必要です。特に、既存のドメインやメールを継続利用する場合は、Webサイトだけを切り替えるつもりでも周辺設定への影響を確認する必要があります。すべてを依頼側で調査する必要はありませんが、「どのサービスを使っているか分からない」という状態も含めて最初に共有しておくと、実装側が必要な確認項目を整理しやすくなります。実装が終わったあと、どこまでを依頼するのかも確認しておきたいポイントです。制作会社や案件によって、範囲は異なります。「実装だけ」という言葉が、コード納品までを意味するのか、本番公開までを意味するのかで認識がずれることもあります。最終的にどの状態まで完成させてほしいのかを共有しておくと安心です。ここまでいろいろな項目を紹介しましたが、依頼前にすべてを完璧に決める必要はありません。むしろ、Web制作に慣れていなければ「何を決めればよいのか分からない」のが普通です。重要なのは、次の3つを分けて共有することです。ブラキオでも、デザインを確認したうえで、実装に必要な仕様や確認事項を整理しながら進めることがあります。「デザインはあるけれど、実装するために何を決めればいいか分からない」という段階でも、まずは相談いただければ、必要な項目を一緒に整理できます。デザイン支給でWeb実装を依頼するときは、Figmaなどのデザインデータに加えて、次のような情報があると制作を進めやすくなります。最初からすべて決まっていなくても問題ありません。未確定の部分を含めて共有し、実装担当者と確認しながら整理していくことで、手戻りを減らし、スムーズに制作を進めやすくなります。ブラキオでは、デザイン支給でのWeb実装や、既存サイトの改修、CMSを含む企業サイト制作にも対応しています。実装範囲の整理から相談したい場合も、お気軽に株式会社ブラキオへお問い合わせください。
2026.10.19

Vercel Proのデプロイ保存期間が30日へ。Webサイト保守で確認したいこと
Webサイトは、公開して終わりではありません。お知らせの追加、デザインの調整、ライブラリの更新、フォームの修正など、公開後も小さな変更を重ねていきます。最近はAIによる実装支援が広がり、コードの変更やプレビュー環境の作成を短いサイクルで繰り返しやすくなりました。変更を素早く確認できる一方で、デプロイ履歴も増えていきます。そうした中、Vercelは、Proプランのデプロイ保存期間とストレージ課金について変更を発表しました。この記事では、何が変わるのかを整理したうえで、企業サイトやJamstackサイトの保守運用で確認したいポイントを考えます。公式発表によると、新しく作成するProチームでは、デプロイ履歴の保存期間が標準で30日になりました。必要に応じて、チーム設定からより長い保存期間を選ぶこともできます。既存のProチームについても、保存期間は30日に変更されます。です。長い履歴を残したい場合は、それまでに保存ポリシーの設定で変更を適用しない(オプトアウトする)必要があります。すでに30日以下の設定を使っている場合、その設定は変わりません。なお、これは「すべてのデプロイが一律30日で必ず消える」という意味ではありません。保存ポリシーはProduction、Preview、Canceled、Erroredごとに設定でき、直近の本番デプロイや現在公開中のデプロイのように保護される対象もあります。実際の保持状況は、チーム・プロジェクトの設定と公式ドキュメントで確認してください。あわせて、Proチームのとについて、それぞれの課金が案内されています。既存Proチームの課金開始日は、各チームに届く案内メールで確認するよう説明されています。10月23日は古いデプロイの削除開始予定日であり、すべてのチームの課金開始日と同じとは限りません。保守費用を考えるときは、月々の基本料金だけでなく、何をどれだけ保存しているかも把握しておきたいところです。本番公開後に表示崩れや不具合が見つかった場合、以前のデプロイに切り戻す方法があります。Vercelにも、過去の本番デプロイへ戻すInstant Rollbackの仕組みがあります。ただし、。必要な履歴が残っていなければ、Gitの過去コミットから再ビルドするなど、別の復旧手段が必要になります。ここで注意したいのは、Gitの履歴が残っていることと、当時のデプロイをそのまま復元できることは同じではない点です。依存パッケージ、環境変数、外部API、CMSのデータなどが変わっていれば、同じコードをビルドしても完全に同じ状態になるとは限りません。制作中は、確認用のプレビューURLをクライアントに共有することがあります。しかし、そのURLが何か月後も必ず見られるとは限りません。「半年前のデザインと比較したい」「以前の確認画面を見直したい」という要望が想定されるなら、プレビュー環境とは別に、承認済みの画面キャプチャ、デザインデータ、変更履歴などを保管しておくと安心です。プレビューURLは確認のための手段であり、恒久的な成果物の保管庫とは分けて考えたいところです。まずはVercelのチーム設定・プロジェクト設定で、Production、Preview、Canceled、Erroredそれぞれのデプロイ保存期間を確認します。既存Proチームなら、課金開始日の案内メールも確認しておきましょう。必要な履歴を何日分残したいかは、障害対応やクライアントの確認サイクルから決めます。単純に長くすればよいわけではなく、保存コストとのバランスが必要です。障害が起きてから復旧手順を調べるのではなく、通常時に「誰が判断し、何を確認して、どう戻すか」を整理しておきます。直前の本番デプロイへのロールバックで済むのか。CMSで公開した内容も戻す必要があるのか。外部サービスの設定変更を伴うのか。これらは別の問題です。少なくとも、本番公開後の動作確認、ロールバックの担当者、復旧後の再確認項目は決めておきたいところです。AIで実装が速くなると、小さな修正を何度もデプロイしやすくなります。しかし、デプロイ回数が増えること自体が品質向上を意味するわけではありません。型チェック、Lint、テスト、必要に応じたVRT(画面差分の検証)などをCIに組み込み、公開前に検出できる問題を減らすことが重要です。人が確認すべき仕様や使い勝手と、機械で検出できる不具合を分ける。これは、ブラキオが重視するFrontend Opsの考え方にもつながります。Vercelの公式案内では、不要なビルドファイルの削減、大きなアセットの保管場所の見直し、Functionバンドルの縮小などが、ストレージ使用量を抑える方法として挙げられています。使用量はプロジェクトごとにUsageページで確認できます。ただし、必要な復旧履歴まで削ってしまっては本末転倒です。先に保守要件を決め、そのうえで削減できるものを整理する順番がよいでしょう。Next.jsとヘッドレスCMSを使った企業サイトでは、静的にページを生成する構成を選ぶことがあります。静的配信は運用上の利点がありますが、まで自動的に解決するわけではありません。とくに企業サイトでは、制作担当者が変わったあとも運用が続きます。担当者が交代しても復旧できるように、リポジトリ、公開手順、権限、監視、バックアップ対象を整理しておくことが大切です。今回のVercel Proの変更は、料金だけを見て終わらせる話ではありません。確認したいのは、という点です。AIを使って制作を速くできる時代だからこそ、公開後の運用まで含めた設計が重要になります。サイトを安全に更新し続けるために、デプロイの保存設定と復旧手順を一度見直してみてはいかがでしょうか。「自社サイトのVercel設定がどうなっているか分からない」「障害時の戻し方を整理したい」といったお悩みがあれば、株式会社ブラキオにご相談ください。公開後の運用・保守まで含めてサポートします。※記事内の仕様・料金は2026年10月13日時点の公式発表に基づきます。最新の内容はVercel公式ドキュメントをご確認ください。
2026.10.14

Next.jsとAstro、どちらで作る?Webサイトの目的から考えるフレームワークの選び方
Jamstack構成でWebサイトを作るとき、フロントエンドのフレームワークとしてよく候補に挙がるのが と です。どちらもmicroCMSなどのヘッドレスCMSと組み合わせて、速くて安全なサイトを作れます。では、実際にはどう選べばよいのでしょうか。ブラキオでは「どちらが優れているか」ではなく、 から選ぶようにしています。今回は、その考え方をご紹介します。Next.jsは、ログイン機能や会員ページ、検索、管理画面のような「動きのある機能」が増えても対応しやすいのが強みです。Astroは、基本的にHTMLとして配信し、動きが必要な部分だけJavaScriptを読み込む設計(アイランドアーキテクチャ)のため、何もしなくても軽いページになりやすいのが強みです。こうしたサイトは「情報をきちんと、速く届けること」が一番の目的です。ページごとに読み込むJavaScriptが少ないほど表示は速くなり、Core Web Vitalsのスコアも出しやすくなります。最初は小さなサイトでも、公開後に機能を足していく計画があるなら、最初から拡張しやすいNext.jsで作っておくほうが、結果的に作り直しのコストを抑えられます。「フレームワークが違うと、更新作業も変わるのでは?」と心配される方もいますが、その心配はありません。記事やお知らせの更新はmicroCMSなどのヘッドレスCMSの管理画面で行うため、 です。フレームワークの選択は、あくまで「サイトをどう作り、どう育てるか」という制作側の判断です。運用する方の使い勝手を犠牲にすることはありません。新しい技術が出るたびに「今はこれが流行っている」という話が出てきます。しかし大切なのは、流行っているかどうかではなく、 です。ブラキオでは、ヒアリングの段階でサイトの目的や今後の計画を伺い、そのうえでNext.jsとAstroのどちらが合っているかをご提案しています。「自社のサイトにはどちらが合うのか知りたい」「今のサイトが重くて困っている」といったお悩みがあれば、ぜひ株式会社ブラキオにご相談ください。目的に合った技術選定から、公開後の改善まで一緒に進めていきます。
2026.10.10

AIを使ったWeb制作で、変わること・変わらないこと
AIを使えば、Webサイトは以前より速く作れるようになりました。デザイン案を考える。コードを書く。テストのたたき台を作る。レビューを補助する。文章の下書きを作る。こうした作業の多くで、AIを使える場面が増えています。では、Web制作会社の仕事は、その分だけ減っていくのでしょうか。ブラキオでは、そうは考えていません。コードを書く時間や、毎回同じような設定をする時間を短くする。その分、人が判断しなければならない部分に時間を使う。Webサイトを作るとき、実装を始める前に考えることはたくさんあります。ここを間違えると、どれだけ速く、きれいに実装できても、会社にとって使いにくいWebサイトになってしまいます。ここを人間が担当してクライアントにヒアリングをして、情報を整理し、必要なページやコンテンツを決める。問い合わせまでの導線を考える。運用方法を確認する。そのうえで、実装や確認作業の一部にAIを使います。AI活用というと、「人件費を減らして安く作る」という話になりがちです。もちろん、制作工数を減らせれば、制作費を抑えやすくなる面はあります。ただ、ブラキオがそれ以上に重要だと考えているのは、です。たとえば、これまで実装に多く使っていた時間を短縮できれば、その分を、といった部分に使えます。ブラキオがAIを使う理由は、制作工程を雑にするためではありません。Web制作でAIを使う場合、重要なのがレビューです。AIはコードを書くスピードを上げてくれますが、そのコードが、まで、自動的に保証してくれるわけではありません。そのためブラキオでは、AIに実装を任せる場合でも、人によるレビューを前提にしています。また、自動で確認できる部分は、型チェックやLint、テスト、CIに加えて、VRT(Visual Regression Testing)などの仕組みを使ってチェックします。コード上の問題だけでなく、画面の見た目に意図しない変更や崩れがないかも自動で確認し、検出できるミスはできるだけ仕組みで見つけます。そのうえで、最後は人が実際の画面を見ながら最終確認を行います。ブラキオの基本的な考え方は、です。AIに全部を任せるのではなく、速く作れるところはAIに任せ、最後に「これで本当に問題ないか」を人が判断します。制作スピードを上げるために、ブラキオではNext.jsを使った標準テンプレートの整備も進めています。Next.jsはReactをベースにWebアプリケーションを構築するためのフレームワークで、ルーティングやレンダリング、ビルドなどWeb制作に必要な仕組みをまとめて扱えます。テンプレートで共通化したいのは、たとえば、といった、サイトごとに毎回ゼロから考える必要のない部分です。一方で、は、それぞれの会社に合わせて考えます。これが、制作を速くしながら、その会社に合ったサイトを作るために重要だと考えています。ブラキオでは、Next.jsとヘッドレスCMSを組み合わせた構成を採用することがあります。ただし、特定の技術を使うこと自体が目的ではありません。重要なのは、です。案件によって必要なものは違うため、「新しい技術だから使う」のではなく、公開後まで含めて扱いやすい構成を選びます。Webサイトは、公開した瞬間に完成するものではありません。実際に公開してみると、といったことが見えてきます。公開前に考えることは大切ですが、すべてを最初から完璧に当てることはできません。だからこそ、公開後のデータを見ながら、必要に応じてページや導線を改善することが重要です。ブラキオでは、制作だけでなく、保守・SEO・改善まで継続して相談できる関係を重視しています。Webサイトを作る工程は、これからさらに自動化されていくと思います。コードを書くことも、デザインのたたき台を作ることも、今よりもっと速くなるはずです。だからこそ、制作会社に求められるものも変わります。「コードを書けます」「デザインできます」だけではなく、こうした仕事の重要性は、むしろ大きくなると考えています。ブラキオでは、AIやテンプレートを積極的に使います。でも、それは人の仕事をなくすためではありません。制作にかかる無駄を減らし、その分を、Webサイトを使う会社にとって本当に価値のある部分へ使うためです。Webサイトを「作って終わり」にせず、公開後も一緒に育てていく。それが、これからのブラキオのWeb制作です。
2026.10.10