白鳥之歌

WebサイトをAstroで構築した

#随想

はじめに

これまでWordPressを使っていたこのサイトだが、デザイン性を向上させるべく、この度Astroを使って作り直した。もともとWebサイトに関する知識がほぼなく、swansong.jpのドメインを最初に取った4年ほど前に一度HTMLやらCSSやらを自分で書いて構築しようとしたものの、断念してWordPressにしたという経験があるだけに果たしてできるのだろうかという気持ちもあったが、下のページを読んで「もしかしたら」と思い、やってみることにした。初心者視点で書かれた分かりやすい記事でたいへん助かった。

非エンジニアが個人サイトを公開するまでにやったこと

仕組み

  • 上記のサイトでは静的ホスティングサービスが使用されている。ただ自分の場合もともとレンタルサーバーを契約しており、そのサーバーを使ってWebサイトのみならずメールも運用していたことから、レンタルサーバーの使用を継続することを前提とした。

  • そこで、静的サイトジェネレータのAstroを使ってVS Code（Windows）で書く → GitHubにアップする → 自動的に変更した差分がレンタルサーバーのFTPにアップされるという仕組みを構築しようとした。せっかく静的サイトジェネレータを使う割にはだいぶ古めかしいスタイルのような気もするがしょうがない。

  • AstroのResumeというテーマを使用した。後述の通りもうこのWebサイト全体をGeminiに参照させることはできなくなったので、このテーマのGitHubレポジトリを参照させて操作方法を聞くとやりやすい。

  • 静的サイトジェネレータの強みである読み込みの速さを一切重視しておらず、ただ単に作りやすそうだからという理由でAstroを選んだだけであるため、トップページに短歌をランダムで表示したり、Webフォントをゴリゴリに使ったりと、過度に装飾的になっている。

  • 日本語フォントはAdobe Fontsを使用している。トップページに貂明朝、あとはタイトルに凸版文久ゴシック、見出しと本文に秀英角ゴシック銀を使っている。活版印刷の温かみを出したいという気持ちで選んだが、本当はモリサワを使いたかった。縦書きをトップページに採用することにもこだわった。

  • 自分でコーディングすることは至難の業なので、ひたすらにGeminiに相談する形をとった。キャンペーンで学生だけ無料になっていたGeminiのAI Proプランには、GitHubのレポジトリを直接渡してコーディングを支援してくれる機能があったので、これにかなり助けられた。

  • 従来のswansong.jpはWeb検索に引っかからないようにnoindexを設定していたが、それを引き継いでいる。テキストが（自分の意図しないところで）分析対象となることへの忌避感から個人サイトでものを書いている部分が大いにあるので、検索機能もつけていない。自分の思想がここまで染み込んだものにできるのは個人サイトの素晴らしい点だ。

踏んだ手順

  • WordPressのバックアップを取った。WordPress公式のバックアップ機能だと単にXMLファイルで出力されて画像のデータは保存されないため、「wordpress-export-to-markdown」を利用した。これは、Node.jsをPCにインストールしたうえで、ターミナルでWordPress公式からダウンロードしたフォルダを指定した状態で「wordpress-export-to-markdown」コマンドを選択し、画面に表示される質問に答えていくと、Markdownと画像が揃ったフォルダを作成してくれるという使い勝手のいい代物。下のサイトをかなり参考にさせてもらった。

WordPressの記事をMarkdown形式に一括出力する方法

  • WordPressを閉鎖した。レンタルサーバーの提供する下記サイトに従って削除した。

WordPress（ワードプレス）の削除方法

  • ひとまずAstroについて学習することにした。下記のチュートリアルの中でVS Codeをインストール。ターミナルで「npm run dev」を書いてプレビューを出す（Ctrl+Cで戻す）とか、そういった基本的な操作を理解した。
  • チュートリアルの中ではGitHubのレポジトリを開設するところもあり、名前だけ聞いたことはありつつよく分かっていなかったGitHubが何たるかを理解するに至った。チュートリアルに従ってメインブランチ？のようなものを作った。GitHubのレポジトリは非公開とした。

初めてのAstroブログ

  • チュートリアル内はサイトをNetlifyというサービスにホスティングしてもらう想定のものになっていたので、ロリポップの場合はどうすればいいのかGeminiに聞き、GitHubのWorkflowを組んでもらった。

  • そのままチュートリアルを進め、ページ作成とスタイル設定の段まで終わった時点で飽きた。そこでそろそろ一気に進めたいということでテーマを物色。「Resume」を選択し、これまでチュートリアルの中で構築していた仮サイトのデータを全てこのテーマのファイルに置換しつつ、Workflow用の設定を再度行った。ここからはチュートリアルは一切参照せず、ひたすらにGeminiとのやり取りを繰り返すようになった。

AstroのMarkdownブログ用テンプレート(テーマ)で無料＋おすすめまとめ

  • 最初にGeminiにGitHubのリンクと共に投げた要求は以下の通りである。このようにかなり無茶な要求にも応えてくれた。

（私）
以下の形に変えたい。 やり方を懇切丁寧に教えて。

・Webページ全体の名前を「白鳥之歌」とし、ヘッダーのタイトルのそれに基づいて変えたい
・現状のトップページのレイアウトを導入した「about」ページを作りたい。
・「blog」と同様の投稿をたくさん並べられる機構をもう1つ作り、「reviews」としたい。
・「about」の直下に「works」と「milestone」と「tanka」を置きたい。「works」と「milestone」は投稿のようなシンプルなレイアウトにしたい。「tanka」は後述の通り他のページに表示できるような機能を意識してほしい。
・トップページを、ど真ん中に「tanka」ページに掲載した短歌がランダムで1個表示されるようにしたい。
・adobe fontsの日本語フォントを導入したい。
・フッターのコピーライトとSNSリンクを削除したい。

  • Geminiの指示に従って書き換え、エラーが起きたらそのエラーメッセージをそのままGeminiに伝えて修正案を求めて書き直すという作業を繰り返していくうちに、下のようにAstroの仕組みがなんとなく理解できてきた。どうやら「src/pages」のフォルダに固定的なページの情報をindex.astroのような形で入れて、「src/content」のフォルダに随時更新していく（ブログのような）タイプのページの情報をmdファイル（Markdown）で入れていくらしいということなど……。

（私）
これabout.astroはaboutという新しいフォルダを作ったほうがよかったりする？

（Gemini）
はい、その通りです！素晴らしい点に気づかれましたね。今後の拡張性を考えると、aboutというフォルダを作って、その中にindex.astroを置く方が断然良いです。

なぜフォルダを作る方が良いのか？ Astroのルーティング（URLの決定方法）の仕組みが関係しています。

src/pages/about.astro → あなたのサイト.com/about というURLになります。 src/pages/about/index.astro → これも あなたのサイト.com/about というURLになります。

一見同じですが、決定的な違いがあります。ご要望にあったように**「aboutの直下にworksやtankaを置きたい」**場合、aboutというフォルダが必要になるからです。 ファイルをsrc/pages/about.astroとして作ってしまうと、src/pages/about/works.astroのようなサブページを作ることができません。

  • このあたりで徐々にVS Codeの使い方の理解が進んできた。
    • 当然だが、VS Codeでいくら書き換えても、それをプッシュしてGitHubに反映していなければ、GitHubのリンクを渡したところで、その内容はGeminiに閲覧してもらえない。プッシュするクセをつけるまでに時間がかかった。
    • プッシュする前段階に「コミット」というVS Code内の段階があって、この時には変更した内容に関する何らかの説明をメッセージとして添えてから「コミット」ボタンを押す必要がある（添えないでコミットしようとするとやたら処理に時間がかかる）のだが、それを添えることを忘れてしまうことが多々あった。ただ、そのメッセージをいちいち書くのが面倒で、かなり雑なメッセージを付けてしまっている。けけけ健康第一。

  • GitHubも触っているうちになんとなく分かるようになってきた。
    • 明らかにこれはGeminiがハルシネーション気味というか、変な方向に話が進んでいってコードが壊れ始めているなと感じた時には、強制的にVS Code上でコードのバージョンをもとに戻す「git reset」というかなり強制的な方法をとった。本当はおそらくもっとましな方法があるはずだが。どの時点まで戻すかはコミットハッシュ（正確には短縮ハッシュでOK）というもので指定するが、このコミットハッシュはGitHubのActionタブで簡単に見返すことができる。当たり前すぎる話なのだが、ここでコミットハッシュを見分けるために、コミット時のメッセージはちゃんと真面目に書かないといけない。そして、「git reset」をすると、GitHubの最新データとVS Codeの最新データに競合が生じるので、今度はGitHub側に無理やりVS Codeの現状を叩きこむ必要がある。ここで強制プッシュ「git push —force-with-lease」を使った。絶対に何か間違っているとは思う。
    • Astroは途中までとはいえチュートリアルをやったのにGitHubはそういうのを全くやっていなかったため、「ブランチ」とか「プッシュ」とか「プル」とか「コミット」とか「ステージ」とか、まるで意味の分からない単語が大量に出てきて困った。いまだにPhotoshopの「ラスタライズ」の意味がよく分かっていないので、たぶんこれもずっと理解はできないのだろうと思う。この投稿自体、専門用語が多くて何やらすごいことをやっているように見えてしまうような気がする。
    • 先述した通り、エラーが起きたらそのエラーメッセージをそのままGeminiに伝えて修正案を求めて書き直すという作業を繰り返したのが、エラーが起きていることが分かる場所は複数ある。VS Codeの「問題」パネルと、GitHubのActionタブ、そして「npm run dev」で出したプレビュー画面である。VS Code内では拾いきれないエラーも、ビルド上のエラーとして後ろ2つが吐き出してくれるので、それをコピーしてGeminiに教えることがかなり有意義だった。

ITの現場でオフチョベットしたテフに遭遇した時の対処法

  • Geminiとやり取りを重ねていくうちに、現状のGeminiのコーディング支援機能のコツみたいなものも分かってきた。

    • 同じチャットの中で何度もリンクを投げ直しても、Geminiは少し前のバージョンを参照して返答してくることがある。少し「惰性」のようなものが文に現れ始めたらチャットを新しく立て直すのが良さそう。
    • また、チャットを立て直してGitHubのリンクを渡しているのに、ちゃんと見ておらず推測で返答してくる場合もある。そのため、こちらから該当コードの全文を送って、既存の機能を欠損しないよう注意せよという指示をつけると確実。機能を増やしたはずなのに不自然に行数が減っている場合には、推測で書き換える事案が起きている可能性が高いので注意するようにした。
    • とにかくコードが汚い。とりあえず書き足して解決しようとしてくるので、あまりにも行数が増えたコードを返してきたときには、「もっと根本的な問題はありませんか？」とか「こっちではなく、こっちのコードに原因があるのではないですか？」とか「こっちはできるだけいじらずに、こっちの書き方を変えるだけでなんとかできませんか？」などと、ある程度ガイドを引いてやる必要がある。
    • だんだんレイアウトなどが迷走しそうになったときは、テーマのGitHubレポジトリ（https://github.com/srleom/astro-theme-resume ）のリンクも一緒に送って、このレポジトリでいうこのページに寄せてほしいという指示の出し方をした。これがかなり重要だったので、将来テーマのレポジトリが削除される場合に備えて、自分のGoogleドライブにコピーして保存しておくようにした。

  • Geminiに指示されるがままコーディングとデバッグを繰り返す中で、Adobe Fontsを設定した。正直仕組みは理解できていないのだが、ちゃんと「文字セット」のところで「Opnetype機能」と「縦書き機能」というところにチェックを入れていなかったために、ちゃんと表示されずに手間取った。

  • ある程度サイトが構築できた時点で、WordPress時代の記事を移設することにした。「date」を「publishData」に変えるなど、「src/contents/config.ts」で指定した内容に沿って多少のメタデータの書き換えが必要だったが、VS Code内の置換を活用して個別のファイルを編集せずに済んだ。実際に移設してみると、かなりうまくいった。

  • そしてここからまたGeminiに仕上げを頼もうと思ったのだが、Geminiに共有できるGitHubのレポジトリのサイズの上限が100 MBになっていることを知った。そんな馬鹿な……と思ったものの、そもそもこんな画像モリモリのWebサイトのコーディング支援はあまり想定されていない用途だと思われるのでしょうがないのかもしれない。

  • そのため、ここからは個別のコードの全文だけGeminiに渡すしかなくなり、レポジトリ全体からどのファイルを操作すれば良いのかを選択する作業はほぼ自分の手で行うこととなった。具体的には、フォントサイズや色味に統一感を持たせるべく調整する段階をその形で行った。Geminiとやり取りをしてコーディングをしてきた直後であるためなんとか乗り切れたが、記憶が薄れていったらおそらくこれもできなくなるに違いない。それまでの間に、Geminiに共有できる容量の上限が上がることを切に祈るばかりである……。

  • とはいえ、Webサイト制作初心者でもせいぜい5日程度でサイトを作成できるのは本当に素晴らしい。特にありがたいのは、英語で検索しなくていいという点である。日本語の情報が多そうなサービスや仕組みをあえて選択しなくても全然対処できる。こうなってくると、結構な数の高校の文化祭レベルでも「Webサイトを作る」という選択肢が浮上してくるような気がする。

コードの重要そうな部分

自分が後から見返せるようなメモ書きのようなもの。

  • 直下

    • frontmatter.json
    • fromtmatter CMSの設定ファイル。後述の「目下の課題」の通り迷走中。
    • tailwind.config.js
      • フォントの読み込みや基本色の設定をしている。src/stylesにある「app.css」と似ているが、役割はなんとなく分かれている。どう分かれているかはなんともいえない。
    • その他
      • よくわからない。たぶん考えなくていい。

  • .frontmatter

    • よくわからない。たぶん考えなくていい。

  • .github

    • Workflows
      • 「deploy.yml」で差分をロリポップのFTPの「public_html」というフォルダにアップする設定をしている。
      • 「public_html」を独自ドメイン（swansong.jp）に対応させる設定はロリポップ側で行っている。ロリポップのFTPには「public_html」のフォルダと同じ階層に「welcome.html」というのが入っているが、これが独自ドメイン内で表示されないのはこの設定をしているから。

  • .vscode

    • よくわからない。たぶん考えなくていい。

  • public

    • 直下
      • よくわからない。たぶん考えなくていい。
    • favicon
      • さまざまなサイズのfaviconを格納。各pngはイラレでジャストサイズを書き出した。icoファイルは変換サイトがあったのでそこで変換した。
    • fonts
      • よくわからない。たぶん考えなくていい。
    • images
      • よくわからない。たぶん考えなくていい。

  • src

    • 直下
      • site.config.tsでは、サイト名や、ページ名の表示のさせ方（「about｜白鳥之歌」）を設定している。あとはよく分からない。
    • assets
      • aboutページなどで使う画像を格納。自分の設計意図としては、固定ページ（src/pagesフォルダに「.astro」ファイルの形で格納するほう）で使う画像をここに格納していくつもり。
      • reviews用の各ジャンルのアイコンはアイソメトリックな画風でGeminiに作らせている。
    • components
      • ボタンなど、装飾パーツのデザインを決める場所。ここに書かれているデータを、下の「pages」内のastroファイルで参照して使っている。おおむね元々のテーマファイルをそのままにしてある。「layout」フォルダにヘッダー・フッターのデータが入っている。
    • content
      • 投稿ページ（後から随時ページを足していくタイプのページ）のデータを入れる場所。「.md」のマークダウンファイルを入れる。この集合をコレクションといい、そのコレクションの形式（＝mdファイルの冒頭に書く「メタデータ」の記載項目）は「config.ts」で指定する。現状、ブログ記事のコレクション「post」、作品レビューのコレクション「reviews」、過去の自分の作品のコレクション「works」、過去の自分の文集のコレクション「milestone」、好きな文章のコレクション「word」、自作短歌のコレクション「tanka」の6つを設けている。なお、具体的にどの項目がどのようにページで表示されるか（表示順とかも含め）はこのフォルダではなく、src/pages内のastroファイルで指定する。
      • コレクション6つのうち、画像を掲載しないつもりの「tanka」と「reviews」は記事別にフォルダを作成せず、「記事名.md」ファイルを「tanka」「reviews」フォルダ直下に配置していく形。一方他の4つは記事別にフォルダを作成し、記事本文は「index.md」としつつ、「images」フォルダを作成してそこに画像をまとめる。なお、念のためastroのルーティングの仕組みを書いておくと、「タイトル」という名前の記事を作成したい場合、「タイトル」フォルダを置いたうえで、その中に「index.md」を配置する方法もあるし、直接「タイトル.md」を配置する方法もある。
      • 動画を配置したい場合は「md」から「mdx」ファイルに拡張子を変えたうえで、「import myVideo1 from ’./images/◯◯.mp4’;」などと冒頭に書き、そのうえで該当箇所に「<video src={myVideo1} controls width="100%"></video>」などとするといいらしい。
    • icons
      • よくわからない。たぶん考えなくていい。
    • layouts
      • ページの基本的なレイアウトデザインを設定している。ここに書かれているデータを、下の「pages」内のastroファイルで参照して使っている。
    • pages
      • 各固定ページ（後からページを足すことを想定しないページ）のデータを入れる場所。「.astro」のファイルを入れる。先述の通り、ここで参照させる画像データは「assets」に入れたいと考えている。なお、「tags」フォルダ内ではブログ用のタグに関する表示を設定しているが、テーマファイルからコピーしたまま放置している「tools」フォルダはよくわからない。
      • reviewsのジャンル別ページや、blogの各記事ページ、各タグのページなど、src/contentsで管理されているコレクションの中身に大きく左右されるページについては、「[◯◯].astro」という特殊なastroファイルでレイアウトを記述している。
      • aboutページでたくさん使っているSVGアイコンは、主要なサービスのアイコンのHTMLのスクリプトを配布してくれているサイト（https://icons.getbootstrap.com/ とか）のものをコピーしてGeminiに成形してもらうとよさそう。
      • トップページに表示される短歌は、自分の評価が★★☆か★★★（★2つ以上）のものしか載せていない。数値的に処理すればカッコいいはずなのだが、そうではなく原始的に★★☆と★★★の文字列を指定している。
    • styles
      • ページ背景色など、基本的な色やフォントを「app.css」で設定している。
    • utils
      • よくわからない。たぶん考えなくていい。

mdファイルのメタデータの書式設定

Geminiに聞いてみた。

（Gemini） はい、承知いたしました。 指定された config.ts の内容に基づき、src/content/ フォルダ内に作成する各コレクションのMarkdownファイルがどのような書式（frontmatter）を持つべきかを、それぞれ具体例と共に列挙します。

1. post コレクション

ブログ記事用の書式です。必須項目と、任意で追加できる豊富なオプションがあります。

フォルダ構成: src/content/post/記事ファイル名.md

◆必須項目

  • title: ‘これは記事のタイトルです’ # 60文字以内
  • publishDate: ‘2025-10-12’ # YYYY-MM-DD 形式

◆任意項目 (必要に応じて追加・削除)

  • description: ‘この記事は Astro Content Collections について解説するもので、50文字以上160文字以内で記述します。’
  • updatedDate: ‘2025-10-13’ # 更新日
  • coverImage:
    • src: ’./images/cover.png’ # 記事フォルダからの相対パスで画像を指定
    • alt: ‘カバー画像の代替テキスト’
  • draft: false # 下書きの場合は true にする (デフォルトは false)
  • tags: ‘Astro’
  • ogImage: ‘/og-images/my-og-image.png’ # OGP画像へのパス
  • readingTime: ‘5分’ # 読了時間など

ここから記事の本文が始まります。 Markdown形式で自由に記述できます。

2. reviews コレクション

映画、ドラマ、イベントなどのレビュー用の書式です。genre は決められた選択肢の中から選ぶ必要があります。

フォルダ構成: src/content/reviews/レビューファイル名.md

◆必須項目

  • genre: ‘Movies’ # ‘Movies’, ‘Dramas’, ‘Comics’, ‘TV Dramas’, ‘Concerts’, ‘Events’, ‘Exhibition’, ‘Etcetera’, ‘Not yet’ のいずれか
  • title: ‘レビュー対象の作品名やイベント名’
  • publishDate: ‘2025-10-12’
  • description: ‘このレビューの簡単な説明文’

◆任意項目

  • place: ‘会場名や場所など’ # イベントやコンサートの場合に利用

ここからレビューの本文が始まります。 ネタバレの有無などを最初に書いても良いでしょう。

3. works コレクション

制作実績やポートフォリオ用の書式です。画像やYouTube動画IDを指定できます。

フォルダ構成: src/content/works/作品ファイル名.md

◆必須項目

  • title: ‘制作物のタイトル’
  • description: ‘この制作物に関する説明’
  • publishDate: ‘2025-10-12’

◆任意項目

  • image: ’./images/work-thumbnail.jpg’ # 作品フォルダからの相対パスで画像を指定
  • youtubeId: ‘abcdef12345’ # YouTube動画のID

ここから制作物の詳細な説明文が始まります。 制作の背景や使用した技術などを記述します。

4. milestone コレクション

経歴や人生の出来事など、時系列のイベントを記録するためのシンプルな書式です。

フォルダ構成: src/content/milestone/出来事ファイル名.md

◆必須項目

  • title: ‘出来事のタイトル（例：株式会社〇〇 入社）’
  • publishDate: ‘2025-04-01’ # その出来事が発生した日付

ここには、その出来事に関する補足説明などを記述できます。 （本文が不要な場合は、このエリアは空でも問題ありません）

5. word コレクション

心に残った文章を記録するためのシンプルな書式です。

フォルダ構成: src/content/word/出来事ファイル名.md

◆必須項目

  • title: ‘出来事のタイトル（例：株式会社〇〇 入社）’
  • author: ‘著者’
  • source: ‘出典’
  • publishDate: ‘2025-04-01’ # その出来事が発生した日付

ここには、その出来事に関する補足説明などを記述できます。 （本文が不要な場合は、このエリアは空でも問題ありません）

6. tanka コレクション

短歌を記録するための専用の書式です。五七五七七をそれぞれの行に記述します。

フォルダ構成: src/content/tanka/短歌ファイル名.md

◆必須項目

  • line1: ‘ここに五文字’
  • line2: ‘ここに七文字’
  • line3: ‘ここに五文字’
  • line4: ‘ここに七文字’
  • line5: ‘ここに七文字’
  • publishDate: ‘2025-10-12’ # 詠んだ日付

ここには、この短歌に関する解説（歌評）や背景などを記述できます。 （本文が不要な場合は、このエリアは空でも問題ありません）

目下の課題

まだ移設できていない「tanka」「works」「reviews」「vote」データの移設

  • blogはもともと各記事がマークダウンファイルとして独立していたからよかったものの、移行にあたってマークダウンファイルを複数作る形に変更した「tanka」「works」「reviews」のデータの移行をやる必要がある。ある程度はaiを使えそうではある。

  • 直近の投票先をまとめたvoteページをそもそも作れていない。存在をつい先日まで忘れていたので、コレクションの設定からやらないといけない。

  • （追記2025.11.23）「tanka」は移設完了。

  • （追記2025.11.28）「vote」のページ作成・移設完了。以下のような書式になっている。

◆必須項目

  • candidate: ‘候補者名’
  • genre: ‘選挙ジャンル（国・都道府県・市区町村など）’
  • election: ‘選挙名’
  • publishDate: ‘2025-10-12’ # 選挙日
  • （追記2025.12.19）「reviews」のページ移設完了。新たに「wishlist」コレクションを作成して、未鑑賞のものをここに入れるようにした。
  • （追記2025.12.20）「works」のページ移設完了。これで完全に移設作業は終わった。

◆必須項目

  • genre: ‘Movies’ # ‘Movies’, ‘Dramas’, ‘Comics’, ‘TV Dramas’, ‘Concerts’, ‘Events’, ‘Exhibition’, ‘Etcetera’, ‘Not yet’ のいずれか
  • title: ‘レビュー対象の作品名やイベント名’

ファイル管理方法の変更

  • 現状WebサイトのフォルダはPCのローカルに保存しているが、これをGoogleドライブのフォルダに変更して、他のPCからもアップロードできる形には変更できないのかを検証したい。

  • （追記2025.12.20）Googleドライブに移設したが、仮想ドライブであることによる諸々の問題が発生したので取りやめた。ローカルにファイルを置いて、自動でGoogleドライブにバックアップされる仕組みにしようとしたが、それも余計なファイルがWebサイトのフォルダ内に生成されてめちゃくちゃになるので断念。

もくじの修正

  • 各ページに付けているもくじについて、それ単体でスクロールできないのが気になる。膨大な見出し量になってきたときに困るので修正したい。

  • （追記2025.11.29）src\components\TableOfContents.astroをいじって、スクロールできるようにした。スクロールバーは見栄えが良くないので見えなくした。

リンクカードの生成の整備

  • 以下のWebサイトを参考に、自分のページ内に外部サイトのURLを貼った際にカードとして表示されるようにする設定と、SNS等に自分のページのURLを貼った際にカードが表示されるようにする設定を施したい。

A is for Astronaut

  • （追記2025.12.20）リンクカードを設定した。mdファイルにURLをそのまま打ち込んで上下の行を空けておくと、下のように綺麗に表示される。
STARTO ENTERTAINMENT
STARTO ENTERTAINMENT 公式サイト｜アーティストの最新情報、関連サービス情報を掲載しています。
starto.jp
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
youtu.be

  • これは、astro.config.mjsでリンク先から情報を取得する設定をしたうえで、src/styles/app.cssで表示方法の設定をしている。なお、リンク先のOG画像はコピーせずに、リンク先の画像をそのまま参照させている。

  • これを修正していくときに、一回ターミナルで「npm run dev」を書いてプレビューを出してから、ブラウザで開発者ツールを表示して該当部分のスクリプトをAIとのやり取りで教えてあげると、実際にどう表示されているかがAIもすぐ理解できるのでやりやすいということを知った。もともとスクショを貼っていたが、AIも結局なぜそうなっているかがよく分からないまま直そうとするのでそれほど意味がなかったということをようやく理解した。

  • （追記2025.12.20）自ページのOG画像も設定した。下のような感じ。これは見出ゴにしているが、それはサイトで使っている筑紫ゴシックや凸版文久ゴシックのotfやttfのファイルを持っていないため。

  • これはどうやらビルド時にその都度生成されて表示されるらしく、ローカルのフォルダには残らないらしい（例外的にローカル環境でnpm run devを実行するとdistフォルダ（＝GitHubにアップロードされない）の中に画像ができるらしい）。どうやらAstroでは一時ファイル的な感じでindex.astro等からビルド時にHTMLが作られているらしく、それと同時に画像も格納されるみたいな仕組みらしい。npm run buildを実行するとローカルのdistフォルダ（Gitにアップされないフォルダ）でこれがなされていることが分かる。
  • この設定はsrc\pages\og-image[…slug].png.tsで書式を含め行っている。また、src\components\BaseHead.astroで、各ページと特定のOG画像が紐づけられていなかった場合に、代替でトップページのOG画像を表示させる設定をしている。そのうえで、src\layouts\BlogPost.astroやその他index.astroでこの画像をOG画像として読み込むように指定してあげている。結構設定している数は多い。フォルダ内を「/og-image」で検索すると沢山出て来るはず。
  • この修正作業の中でURLのクレンジングという概念を知った。当初の設定だと、OG画像のパスが全角括弧などを使った（元の記事名と完全一致した）ものになっており、記事側で指定している全角括弧などを使ってない綺麗なURLとの整合性がとれなくなる事案が発生した。AstroのURL生成はクレンジングを経ているらしい。そうした事情を鑑みて、ページのURLをそのまま画像のURLとして採用するようにした。
  • （例）「blog/2025-10-14-webサイトをastroで構築した」という記事に対して、「og-image/blog/2025-10-14-webサイトをastroで構築した.png」という画像URLを作成する。前後にog-imageとpngをつけるだけ。
  • OG画像は下のようなシミュレーションサイトでちゃんと出ているか確認できる。本当は正方形で表示される場合とかも考えたほうがいいのだが、デザインが思いつかず長細い長方形の形だけを想定している。
ogp.buta3.net
ogp.buta3.net
  • また、画像に入っているテキストについては、「King & Prince」のような文字列だと「King & amp; Prince」のように書かれてしまうことがある。エンティティ化というらしい。これを直す設定もしてある。
  • 意味が分からないエラーが出たときは、詳細にデバッグしたいのでそういうコードに一時的に書き換えてくださいと指示を出して出力してもらい、それを貼って戻ってきたログを全部貼ると結構良い。
  • Geminiも、現状は高速モード、思考モード、Proモードがあるが、Proモードじゃないとちょっとおかしな挙動になる時がある。
  • （既に定めているコレクションの追加の枠を超えて、特に動的な）ページを増やしたり、コレクションを増やす場合は、src\pages\og-image\ [ …slug].png.tsをいじる必要あり。また、メタデータのところにちゃんとOG画像を書いてあげる必要あり。要確認。

（やるなら）テキストの改善

  • ルビを使う
    • 以下のWebサイトを参考に、マーウダウンファイルでもルビを振れるように設定したい。

Next.jsでブログをつくった

  • 自然な折り返し
    • 以下のWebサイトを参考に、日本語折り返し処理を導入するか調べたい。ただこの折り返しを設定すると、スマホではかなり少ない文字数で改行されてしまい、かえって読みづらくなるリスクもあることから、一定以上の画面幅でしか折り返し設定が適用されないという方向性で検討したい。

AstroでBudouXによる日本語の自然な折り返しを実装する

（やるなら）Frontmatter CMSの設定修正

  • 記事を管理しやすくするためヘッドレスCMSを使うのがよさそうということで、Frontmatter CMSを導入しようと考えた。そこで「frontmatter.json」をGeminiの指示通り編集してみたのだが、一部うまく作動していない。
    • 本来は、6種類あるコレクションについて、それぞれ違う挙動をしてほしい。①記事別にサブフォルダ（＋画像用のimagesフォルダ）を作るか否か、②メタデータにどんな項目を設けているかの2点が、コレクションによって大きく異なるからだ。
    • ダッシュボードで記事の一覧はきちんと表示されている。また、記事の新規作成ボタンを押したときにどのコレクションの記事を書くかを選択する画面を出させることには成功している。しかし、いざ編集画面に移ると、どのコレクションで設けているメタデータ項目とも違う、（おそらくデフォルトの）メタデータが勝手に書き込まれた状態でmdファイルが作成されてしまうという致命的な問題が発生している。当初は複数のコレクションに対応していない説も考えたが、じゃあ最初に選択させる画面が出てこないはずなので、それは違うと考えられる。一体どうすればいいのだろうか……。
    • また、設定中には、「frontmatter.json」を書き込んでいると、ダッシュボードが表示されなくなり、初期設定画面が表示され、なぜか記事ファイルが登録されていないことを示す表示などが出てしまうことがあった。これがかなりストレスフルだった。ただ、その場合も、設定画面下部の「gitに同期する」のチェックボックスを入れてやることで「ダッシュボードを開く」のボタンを押せるようになったりはした（この方法が良かったのか、認識するときとしない時があるという調子の問題なのかは不明）。これがもう嫌になったので、VS Code起動時にダッシュボードを表示させてウェルカム画面を表示させないという設定を無理やり施した。

（Gemini） Front Matter CMSでウェルカムページを強制的に表示させず、VS Codeの起動時やプロジェクトを開いた際に必ずダッシュボードを開くようにするための設定について解説します。これには、VS Codeのsettings.jsonファイルに2つの設定を記述するのが最も確実です。

◆設定方法
VS Codeの設定ファイル（settings.json）に、以下の2つの項目を追加または編集してください。

①ウェルカムページを非表示にする設定 frontMatter.global.showWelcome: false

②起動時にダッシュボードを開く設定 frontMatter.dashboard.openOnStart: true

settings.jsonへの記述例 JSON { // …（ここに他のVS Codeの設定が記述されています）

“frontMatter.global.showWelcome”: false, “frontMatter.dashboard.openOnStart”: true // … }

◆設定ファイル(settings.json)を開く手順
settings.jsonを直接編集するには、以下の手順で行います。

①VS Codeでコマンドパレットを開きます。 Windows/Linux: Ctrl + Shift + P Mac: Cmd + Shift + P

②検索バーに「settings.json」と入力します。

③候補の中から「基本設定: ユーザー設定を開く (JSON)」（Preferences: Open User Settings (JSON)）を選択します。

④開かれたsettings.jsonファイルに上記の設定を追記し、ファイルを保存します。

◆GUI（設定画面）での設定方法
JSONファイルを直接編集するのに抵抗がある場合は、VS CodeのGUIからも設定できます。

①VS Codeの 設定 を開きます。 Windows/Linux: ファイル > ユーザー設定 > 設定 (ショートカット: Ctrl + ,) Mac: Code > 基本設定 > 設定 (ショートカット: Cmd + ,)

②検索バーに「Front Matter」と入力して、Front Matter CMS関連の設定を絞り込みます。

③以下の2つの項目を見つけて設定します。 Front Matter › Global: Show Welcome のチェックを外します。 Front Matter › Dashboard: Open On Start にチェックを入れます。

これらの設定を行うことで、次回以降VS Codeでプロジェクトを開いた際には、ウェルカムページが表示されることなく、直接Front Matter CMSのダッシュボードが開かれるようになります。