Lantern-TECH Blog

Created: 2/15/2026 Updated: 4/3/2026 By 大渕凜

こんにちは。 tctcの大渕です。
今回私が作成したのは、Lantern-TECHの制作ブログサイトです。

Lantern-TECH Blog - JP

Lantern-TECH Blogトップページ

メインのツールとして、AIエージェントとの対話を通じて直感的に開発を進める「VibeCoding」を体現するGoogle Antigravityを使用。
これにより、従来の開発プロセスを大幅に短縮し、極めて短期間でのWebサイト構築を実現しました。

Lantern-TECH

Lantern-TECHは、2024年に私を含めたtctcメンバー3人で結成されたチームです。
通称lantech。

3人

大雑把に説明すると、大学の授業課題として、チームで作品を制作する必要があって、そのときに集まった3人がたまたま全員tctcメンバーだったのです。

制作ノート

この授業の小課題の一つに、制作ノートを執筆して公開するというものがありました。
これは、制作時の出来事や使ったツールなどを全て記録し、ポートフォリオの作成に役立ててほしいという意図で課されたものでした。

しかし、他のチームを見るとあんまり重視されていないように感じました。
というのは、ほとんどのチームがノートをGoogleスライドで作成し、制作にあたって書いたメモや見た作品などを雑多に貼っているだけで、整理整頓されていないのです。

そこで我々は、この制作ノート自体をそのままポートフォリオにしてしまえばいいと発案。
すなわち、制作チームや大学の教員のみが見る制作ノートを、作品の閲覧者全てが見ることのできる形式に整え、情報を豊富に掲載するということです。
これは実質的に課題が一つ増えるということになります。 非常に大変ではありますが、無駄にはならないと考えました。

Google Site

そこで使い始めたのがGoogle Sitesでした。
ノーコードツールで、Google Workspaceで簡単に共同編集でき、コンテンツの埋め込みも自由自在。 非常に使いやすく、課題制作の最後まで編集を続けました。

Google Sites版lantech blog

しかし、数ヶ月経ったある日、少し内容を加筆修正しようとして、ある問題に直面しました。 それは、レスポンスの遅延が顕著になったこと。 編集画面のレスポンスが著しく低下し、軽微な修正にも十数秒の待機を強いられます。
情報の蓄積を目的とするサイトにおいて、この更新コストの増大は致命的。 少しだけの編集なら良いですが、今後たくさんコンテンツを追加するのにこのような状態では不便極まりない状態です。

そこで、Google Sitesでなく、全て自分でコントロールできるWebサイト環境に移行することにしたのです。

Astro.js

白羽の矢が立ったのはAstroでした。 これは、ReactやVueのようなJavaScript UIフレームワークであり、Next.jsやNuxt.jsのような静的サイトジェネレーターでもあります。

最大の特徴は動作が軽量なこと。
Astro公式サイトによると、WebサイトのUX健全度を示す指標Core Web Vitalsで、WordPressが48%、Next.jsが30%のところ、Astroは66%のスコアを記録しています。

AstroのWeb Vital比較

Island Architecture

なぜAstroがそれほど軽快に動作するのかというと、徹底したJavaScriptの演算最適化にあります。
Next.jsやNuxt.jsは、ページ全体をJavaScriptで制御しようとするため、いちいち巨大なjsファイルをブラウザが読み込む必要がありました。

これに対し、AstroはIsland Architectureという仕組みを導入しています。 これは、静的なHTMLの海の中に、動的なJavaScriptが必要な部分だけを「島」として浮かべる構造です。
ブラウザ側でのハイドレーション(Hydration : 静的HTMLへのインタラクションの付与)を最小限に抑えることで、メインスレッドの占有を避け、CPUの処理負荷を劇的に軽減しています。
参考 : Island Architecture - Docs

競合フレームワークとの比較

AstroとNext.jsはそれぞれ適した用途が違います。
Next.jsは、システム管理画面やEコマースなどのように、ページ遷移が頻繁で、統一した状態情報参照が必要な場面に向いています。 Astroは、コンテンツを見せることに重きを置き、一部のインタラクションなどでUXを向上させたい場合に適しています。

lantechの場合

Lantern-TECH Blogで閲覧者に見せたい主体は文章と画像であり、まさに後者のユースケースに合致しています。 そのため、Astroが選ばれました。

VibeCoding

とはいえ、私はWebの開発経験はありません。 もっぱらGoogle Sitesなどのノーコードツールを使ってWebサイトを作っているだけでしたので、いきなりAstroを使うと言っても、どうしようもありませんでした。
もちろん、理想はAstro公式のチュートリアルをやってみて構造理解に務めるのが良いのでしょうが、一刻も速くWebサイトをGoogle Sitesから移行したい私にとって、学習コストを払うのは後回しにしたいという感じでした。

Google Antigravity

そこで、Google Antigravityを使います。
Google Antigravity

Antigravityは、MicrosoftのVS Codeをベースに、Googleの対話AIエージェントであるGeminiを搭載した統合開発環境(IDE)です。
VibeCodingは2026年現在、AIと人間が「フィーリング(Vibe)」で対話しながら爆速でプロジェクトを形にする、新しい開発手法として注目されています。 Antigravityは、VibeCodingを超えたAgentic-Coding(AI駆動開発)を強力にサポートするツールです。

Antigravity

馴染みのない方にはイメージしづらいかもしれません。
簡単に説明すると、AIエージェントに「こういうものをこういう仕様で作って」とチャットを送信すると、そのとおりのものを自動で作ってくれるという魔法のようなツールです。
もちろん、魔法のようなものであって魔法そのものではありません。 ちゃんとした完成形まで仕上げるには、人間の目で見て、人間の手で直す必要があります。 ただ、「ここがこうなっているから直して」と指示すれば直してくれます。
うまくいかないことも多いですが、人間が時間をかけて丁寧にレビューしていき、人間にもAIにもメンテナンスしやすい構造で進めていけば、ほぼ確実に完成します。

ありがたいのは、Gitの管理もやってくれることです。 予めCommitMessegeを生成するよう指示しておけば、何か変更を加えたときに毎回、変更内容の概要を出してくれますから、それをコピペしてCommitすれば楽です。
流石にCommitやMergeまで自動化させることはしませんが、かなり負担軽減になります。

Roadmap

チャット履歴やAIが作成した実装計画書(Implementation Planning Sheet)は、リポジトリの中ではなくPCのローカルに保存されてしまいます。 このままだと複数のPCを併用して作業するときに困ります。
そこで、全ての進捗状況や実装計画書、ToDoリストをmdファイルに書き出してリポジトリに含めるよう指示しました。
これにより、過去に何をさせようとしたのか、そもそもこのプロジェクトは何なのかが、別のPCでgit cloneするだけで参照できますし、AIにこのドキュメントを読ませれば引き継ぎも楽です。 mdファイルの命名規則も予め指示しておけば、エクスプローラーでソートするのも簡単になります。

これはあらゆるAIエージェントで応用できるはずです。
主要な対話型AIは、その前提情報をサプライヤーのデータベースからとLLMのコンテキストからという異なったデータソースから得ています。 そしてこれらは、情報の安定性に違いがあります。
重要な対話内容と前提情報を整理整頓して、mdやjsonといったLLMが読みやすい形式でアウトソースすることで、いくつかのサービスを併用したときのユーザー体験がより最適化されるはずです。 いわばオープンソース私!
私自身のI/OをAIが扱いやすく、でもAIではなく自分が主導権を握る、ということです。

多言語対応

新しいサイトに移行する上で、習作的にやりたかったことの一つが多言語対応です。
やり方はいくつかありますが、今回は全てのページの親に[ln]/を付与し、各言語のコンテンツをルーティングすることにしました。 日本語はdomain.com/jp/hogehoge、中国語はdomain.com/zh/hogehogeとなります。
Appleなどはそうしていますね。

言語は日本語、英語、中国語(簡体字)の3言語です。
全て私が(DeepLの力も借りていますが)翻訳して書き換えています。

中国のネット対応

多言語対応というのは、ただ複数の言語に増やせばいいわけではありません。
単なる翻訳に留まらず、各地域のネットワーク環境やインフラへの適応(ローカライゼーション)を内包する必要があります。

今回、中国語のページを追加しました。 これは中国大陸からの閲覧を想定しているということです。 実際に中国大陸からこのページにアクセスがあるのかはさておき、ファイアウォール対策をしないといけません。
中国はご存知の通り、結構たくさんのWebサイトを国内のWebから遮断しています。 代表的なのはGoogle、YouTube、Twitterなどですね。

画像ホスティングの代替

そして、ページに挿入する画像をホスティングするのに使っているImgurもその一つです。
Imgurにアップロードした画像は中国大陸からは見えません。 ですから代替サービスを使う必要があります。

lantechに掲載している画像はかなり枚数が多く、無料で使えるサービス(検討したのはPICUI图床など)では容量が足りません。 有料サービス(阿里云盘など)なら余裕がありますが、このサイトをいつ公開終了するかもわからないのに、たとえ数十元でも毎月課金し続けるのは難しいです。
結局、画像ホスティングには、中国国内からのアクセス性に定評のあるz4aを採用しました。 知乎などでも紹介されていたので、割と安定していそうな感じでした。

Bilibiliで動画を公開

YouTubeがブロックされているということは、iframeで埋め込んでいるプロモーション動画も再生できないということです。
そのため、字幕を中国語に差し替えたバージョンの動画をBilibiliにアップロードし、そちらを埋め込みました。 これにより、当該ページで言語を切り替えると、日本語と英語版ではYouTubeが、中国語版ではBilibiliが表示されます。

なお、参考作品のYouTube動画の埋め込みは、中国語版では削除しています。 そのかわり、GIFアニメーションをz4aでホスティングし、掲載しています。

Webサイト公開

静的サイトを公開するのに使えるサービスはいくつかあります。 最初に検討したのは以下の3つ。

参考:極力無料主義! Netlify・Vercel・GitHub Pages 比較(使用量上限・制限超過時や商用利用可否などの特徴まとめ) - Zenn

どれも有名なホスティングサービスですが、組織依存の引き継ぎという面でGitHub Pages(というかGitHub Organizationのリポジトリベースの管理)が良いだろうという方向で進んでいました。

Cloudflare Pages

新しく見つけたのがCloudflare Pagesでした。
もともとtctcではドメインの管理をCloudflareでやっており、使うのにあたって特に障壁とかは無いです。
GitHub Pagesとの最大の違いは、商用利用が可能なことと、Privateリポジトリも公開できるということです。 無料枠は、GitHub Pagesがビルド10回/h、Cloudflare Pagesがビルド500回/月です。 GitHub Pagesが10倍以上使えますが、まあどちらも無料枠にしては緩いですね。

商用でもないしPublicですのでどっちでも良かったのですが、今後のことを考えてCloudflare Pagesを使いました。

実際に移行してみて

Google Sitesを使っていたときの編集作業の流れとしては、まずブラウザでGoogleドライブを開き、当該プロジェクトの編集画面を開いて内容を変更していました。
これが非常に重かった。。。 マシンスペック不足かと思ってラップトップからデスクトップに変えてみてもだめでした。
Astro移行後は、GitHubからローカルにgit cloneしたリポジトリにorigin/devブランチを発行し、Antigravityで編集して、commitしてpush、origin/mainにmergeする、という流れになっています。
編集作業時にネットワークトラフィックが発生しないため、純粋にPCスペックに依存した編集環境になりました。 そしてIDEでテキストを書き換える処理負荷なんてたかが知れています。 結果的には非常に快適になりました。

表示速度

正確に計測したわけではありませんが、Google Sitesを使っていたときよりも明確にWebサイトにアクセスしたときのレスポンスが速くなったと感じます。

その他の変化

Google Sitesではフォントや画面レイアウトなど、Googleが定めた範囲でしかカスタマイズできませんでした。
今回、メインフォントにLINE Seed JP、モノスペースフォントにFiraCode、簡体字フォントにNoto Sans CJK SCを使い、要素によって適宜切り替えるようにしています。 より自然な文章表示になりました。

また、Google Sitesで作ったサイトに独自ドメインを設定できなかったのが、今回nid-techtech.comドメインで公開できるようになったのもポイントです。

Google Siteのその後

カスタムドメインにできなかった弊害として、Google Sitesを閉鎖してしまうと、展示資料などに埋め込んだQRコードが軒並みリンク切れになってしまうという問題が発生します。
Google Sitesの方には、サイトが移転した旨と新しいサイトのURLを載せて、その他のコンテンツは全て削除しました。

移転のお知らせ

終わりに

Lantern-TECH Blogを書き上げて公開したことにより、その後tctc公式サイト(このサイトです)を作るのに役に立ちました。
しかし現状、ノリと勢いのみで進めている節があります。 今後、Agentic-Codingが主流になってきたとしても、AIが書いたコードをちゃんと理解したうえでレビューしたほうがいいですから、人間がプログラミング言語を覚える必要性は失われていないどころか、より高まっているはずです。
私は今後、JavaScriptとTypeScriptを練習したいと考えるなどしています。

おまけ

小さいこだわりは、lantechメンバー3人のプロフィール画像をグラサンかけてる画像で統一したことです。

メンバー紹介