静的サイトジェネレーターは、スケーラビリティという 1 つの重要な理由で、依然として LLM に勝っています。

Posted on 3 4月 11:54 pm

プログラミングを始めたばかりの場合は、2026 年に利用可能になり、すべての面倒な作業を省略できる強力なツールに興奮するかもしれません。しかし、LLM の素晴らしさにもかかわらず、LLM は静的 Web サイトを生成するためのクラス最高のツールではないと言ったらどうなるでしょうか?

LLM はほとんどの職業にとってクラス最高のツールではなく、Web 開発も例外ではありません。すべてのトークンにはお金がかかり、ちょっとしたギャンブルです。結果はさまざまです。これに対して、静的サイトジェネレーター (SSG) は、スケーラビリティという非常に特殊な問題を解決する、古くからあるソリューションです。

基本的な違い

静的サイトジェネレーターと LLM は正反対です

SSG は、一連のテンプレートを多数の HTML ファイルにコンパイルするプログラムです。テンプレートは、ドメイン固有の構文 (中括弧など)、プレースホルダー変数、および HTML で構成されます。HTML はマークアップとコードの組み合わせです。通常、テキストコンテンツを別のマークアップ形式 (Markdown など) で記述し、テンプレートを設定すると、SSG がコンテンツを HTML にコンパイルします。したがって、出力は非常に決定的 (予測可能) であり、内容を除いて出力間に違いはありません。

LLM は、ベクトル、数学、そしてちょっとした魔法を組み合わせたものです。全範囲については私にはわかりませんが、それらが非決定的であると言うことには自信を持っています。これらは、次のトークンを統計的に予測する人間の言語のモデルです。それらを多くのコンテキストとブレンドすると、出力が変化し、それは回答ごとに異なります。

決定論的と非決定論的の間のこの対比は、明らかな矛盾を表しています。しかし、静的 Web サイトを構築するにはどれを選択しますか?またその理由は何でしょうか?

スケーラビリティ

静的 Web サイトが成長すると LLM が折れる

オレンジ色のお手玉の上でくつろぐリラックスした男性は、フレンドリーな黄色のロボットがラップトップで作業するのを眺めており、その周りには複数の赤い感嘆符の警告アイコンが浮かんでいます。

小さなランディングページを作成している場合は、単純な HTML ドキュメントで十分な場合があります。情報の表示やリードの生成にはコードの再利用はあまり必要ありませんが、コンテンツの公開にはコードの再利用が必要です。一般的なブログには数百の投稿があり、大規模な組織では数万の投稿が含まれる場合があります。コードの再利用は、プログラマーとして最初に学ぶ基本的なレッスンの 1 つですが、(初心者の) バイブプログラマーの中にはこれを理解していない人もいると思います。 LLM は、コードを信じられないほど安価に大量に生産したり、単に忘れたりすることによって、コードの使い捨てを奨励します。正確な結果を判断するのは困難です。

クライアントはシンプルなランディングページを受け入れ、あなたにとってはうまくいくかもしれませんが、それが必ずしも最も責任ある選択であるとは限りません。たとえば、単純なランディングページからビジネス固有のコンテンツを含めたり、連絡先/概要ページを追加したりするように拡張したい場合があります。小さな Web サイトがすぐに数十の Web ページに成長する可能性があるため、ジレンマが生じます。どのようなアプローチをとりますか?複数の個別のページをコード化していますか? それとも、よりスケーラブルなソリューションを見つけていますか?

スケーラブルとは、増加するワークロードに対処できるシステムを設計することを意味します。たとえば、クライアントのために作成した新しい Web サイトを考えてみましょう。十数ページあります。ここでクライアントは、すべてのページのサイドバーに行動喚起を表示したいと考えています。 LLM は確実に 12 ページすべてを更新できますが、次の変更、またはその後の変更はどうなるでしょうか?ここから Web サイトが存在しなくなるまで、すべての作品を 12 回複製しますか?

Web サイトは数百ページまたは数千ページに拡大する可能性もあります。当然のことながら、ワークロードがどのように積み重なり始めるかがわかります。あらゆる小さな変更には多くのページにわたるレプリケーションが必要であり、LLM のような非決定性ツールを使用すると、微妙なバグが忍び込みます。 LLM が理由もなく、または私が完全には理解できない理由でコードのブロック全体を削除するのを見たことがあります。いずれにしても、この変更は私の理解の範囲内ではありません。変更をすべて確認しますか?自動テストも書いていないと思うので、各ファイルを手動でテストしますか?

プログラマーでなくてもスクリプトを学ぶべき理由

コンピュータをあなたのために機能させてください。その逆ではありません。

SSG

一人に効果があることは全員にも効果がある

Hugo を使用すると、静的サイトジェネレーターを使用して簡単な Web サイトをセットアップするのに 20 ～ 30 分かかる場合があります。得られるのは、すべてのページにわたってコードを複製することを保証する決定論的なツールです。ある特定のページで機能するものはすべてのページでも機能します。大幅な変更を加える場合は、1 つのテンプレートファイルを更新して再コンパイルするだけで済み、所要時間はわずか 2 秒です。 LLM を使用して変更を行うこともできるため、選択は相互に排他的ではなく、LLM をワークフローの一部にすることができます。

SSG は、特定の問題を解決するツールです。 LLM の出現によって、この問題の存在が変わるわけではありません。ただし、LLM はこの仕事に適したツールではありません。適切なツールを使用せずに複数ページの Web サイトを Vibe コーディングすることは、リソースの大幅な無駄です。静的な Web サイトを構築するつもりなら、SSG より良い方法はありません。

SSG と LLM は、スペクトルの対極にあるツールです。これらが連携できない理由はありませんが、LLM を使用して静的 Web サイトを構築することには反対する強力な理由があります。それを行っていて、それが数ページを超える場合は、立ち止まってアプローチを再評価する必要があります。それは主観的だという人もいるかもしれないが、車に四角いホイールを付けるのも同様だ。誰かがそうしたいなら、私は誰に言えばいいでしょうか？それをスクラッチしてください。それはばかげています。角砥石と同様に、作業に適したツールを使用してください。