R.devのRSSフィード

Astro - rehypeプラグインを作って単体URLのリンクカード化を実現する

Thu, 04 Jun 2026 07:05:11 GMT

前回、remarkプラグインでGFMのアラート記法を実現しました。

Astro - remarkプラグインを作ってGFMのアラート記法を実現する | R.dev

Astro上でremarkプラグインを作ってGFMのアラート記法を実現しました。

r-dev95.netlify.app

今回は、rehypeプラグインで単体URLのリンクカード化を実現していきます。

ここでいう単体URLのリンクカード化とは、外部リンクのURLだけ貼ると、タイトルや説明、サムネイルを表示するリッチなリンクカードに変換してくれる機能のことです。

https://example.com

ZennやQiitaのようなプラットフォームでよく見かけるあれです。

上述のような機能は、Astroにはデフォルトではサポートされていません。

前回も言及しましたが、

既製のプラグインを使う方法もありますが、仕組みさえわかればそれほど難しい実装ではありません。自分で作ればHTML構造、クラス名、アイコン、タイトルなど自由にカスタマイズ可能です。

remark だけでなく、rehype でも同様のことが言えると思います。

この記事では、rehypeプラグインをゼロから自作する方法を解説します。

remarkとrehype、どちらでプラグインを作るか

前回の内容を再掲します。

AstroのMarkdown処理パイプラインは、unified というエコシステムの上に成り立っています。そのなかで主役となるのが remark と rehype の2つです。

remark はMarkdownを扱うプロセッサです。入力したMarkdownテキストを mdast（Markdown Abstract Syntax Tree）と呼ばれるツリー構造に変換し、プラグインはそのツリーを自由に操作できます。「Markdownのテキストを読んで構造を変えたい」場合はremarkプラグインが適しています。

rehype はHTMLを扱うプロセッサです。こちらは hast（Hypertext Abstract Syntax Tree）を操作します。mdastがhastに変換されたあとで動作するため、出力HTMLの構造を直接いじりたい場合に使います。

今回は rehype を選びます。リンクカードへの変換は「<p> タグの中に <a> タグだけがある」という状態を検出して置き換える処理です。この判定はHTMLのツリー上で行うほうが直感的で、タグ名や属性をそのまま条件に使えます。またOGPのフェッチという非同期処理も絡むため、HTMLが確定したあとのrehypeで一括処理するほうがシンプルです。

rehypeプラグインの作り方

remarkプラグインとほとんど同様ですが、rehypeプラグインの要点を整理すると次の通りです。

unist-util-visit で対象ノードをたどる
「対象ノードを置き換える」または「新たなノードを追加する」
tagName / properties で直接HTMLの構造を制御する

プラグインの基本構造

remarkと同様、rehypeプラグインもツリーを受け取る関数を返す関数です。

Root などの型定義を mdast ではなく hast からインポートする点がremarkプラグインとの違いです。

import type { Root } from 'hast';

export default function rehypeMyPlugin() {
  return (tree: Root) => {
    // treeを操作する
  };
}

ノードをたどる - unist-util-visit

unist-util-visit の使い方はremarkと同じです。

第2引数でノードタイプを指定します。ここでは 'element' を指定しているので、すべてのHTMLタグに対応するノードが対象になります。コールバックにはnode（対象ノード）、index（親の中での位置）、parent（親ノード）が渡されます。

import type { Element, Parent, Root } from 'hast';
import { visit } from 'unist-util-visit';

import { fetchOgp } from './fetch-ogp';

export default function rehypeMyPlugin() {
  return (tree: Root) => {
    visit(tree, 'element', (node: Element, index: number | undefined, parent: Parent | undefined) => {
    // elementノードが見つかるたびに呼ばれる
  });
};

ノードを置き換える / 子ノードに独自ノードを追加する

remarkと同様に parent.children[index] に新しいノードを代入します。

hastでは type: 'element' を使い、tagName でHTMLタグを指定します。またremarkと違い、 data.hName / data.hProperties は不要です。tagName と properties が直接HTMLに対応します。

(parent.children as ElementContent[])[index] = {
  type: 'element',
  tagName: 'a',
  properties: {
    href,
    className: ['link-card'],
  },
  children: [
    {
      type: 'element',
      tagName: 'div',
      properties: { className: ['link-card-body'] },
      children: [
        {
          type: 'element',
          tagName: 'h2',
          properties: {},
          children: [{ type: 'text', value: 'タイトル' }],
        },
      ],
    },
  ],
};

非同期処理との組み合わせ

visit のコールバックは同期関数として呼ばれます。コールバック内で await することはできません。

そのため、タスクをPromiseの配列に貯めてから、visitが終わったあとに Promise.all で一括処理するパターンを使います。

visit が走り終わった時点では tasks にPromiseが積まれているだけです。await Promise.all(tasks) で全件完了を待ってから処理を終えます。Astroのビルド時にプラグインが呼ばれる際も、このPromiseが解決されるまで待ってくれます。

return async (tree: Root) => {
  const tasks: Promise<void>[] = [];

  visit(tree, 'element', (node, index, parent) => {
    // 非同期処理が必要なら tasks に積む
    tasks.push(
      someAsyncOperation().then((result) => {
        // ノードを書き換える
      })
    );
  });

  // すべての非同期処理が終わるまで待つ
  await Promise.all(tasks);
};

実装したプラグイン

実装したプラグインと実際に使った場合の表示は次の通りです。

実装

OGPのフェッチ処理については詳しく言及しませんが、`cheerio` を使っています。

import type { Element, ElementContent, Parent, Root } from 'hast';
import { visit } from 'unist-util-visit';

import { fetchOgp } from './fetch-ogp';

export default function rehypeLinkCard() {
  return async (tree: Root) => {
    const tasks: Promise<void>[] = [];

    visit(tree, 'element', (node: Element, index: number | undefined, parent: Parent | undefined) => {
      if (!parent || index === undefined) return;
      if (node.tagName !== 'p') return;
      if (node.children.length !== 1) return;

      const firstChild = node.children[0];
      if (firstChild.type !== 'element' || firstChild.tagName !== 'a') return;

      const href = firstChild.properties?.href;
      if (typeof href !== 'string') return;

      tasks.push(
        fetchOgp(href).then((ogp) => {
          (parent.children as ElementContent[])[index] = {
            type: 'element',
            tagName: 'a',
            properties: {
              href,
              target: '_blank',
              rel: 'noopener noreferrer',
              className: ['link-card', 'anim-card-link'],
            },
            children: [
              ...(ogp.image
                ? [
                    {
                      type: 'element' as const,
                      tagName: 'figure',
                      properties: {},
                      children: [
                        {
                          type: 'element' as const,
                          tagName: 'img',
                          properties: { src: ogp.image, alt: ogp.title },
                          children: [],
                        },
                      ],
                    },
                  ]
                : []),
              {
                type: 'element',
                tagName: 'div',
                properties: { className: ['link-card-body'] },
                children: [
                  {
                    type: 'element',
                    tagName: 'div',
                    properties: { className: ['link-card-title'] },
                    children: [{ type: 'text', value: ogp.title }],
                  },
                  {
                    type: 'element',
                    tagName: 'p',
                    properties: { className: ['link-card-description'] },
                    children: [{ type: 'text', value: ogp.description }],
                  },
                  {
                    type: 'element',
                    tagName: 'p',
                    properties: { className: ['link-card-site'] },
                    children: [{ type: 'text', value: ogp.siteName }],
                  },
                ],
              },
            ],
          };
        }),
      );
    });

    await Promise.all(tasks);
  };
}

マークダウン

https://example.com

https://r-dev95.netlify.app/

実際の表示：

OGP画像なし：

Example Domain

example.com

OGP画像あり：

R.dev

R.devの個人サイトです。ブログ記事と作品URLを載せていきます。

r-dev95.netlify.app

【補足】 Astroへの組み込み

作成したプラグインは、astro.config.mjs に次の通り実装すると使えるようになります。

astro.config.mjs

import { unified } from '@astrojs/markdown-remark';
import remarkLinkCard from './path/to/directory/rehype-link-card';

export default defineConfig({
  markdown: {
    processor: unified({
      rehypePlugins: [rehypeLinkCard],
    }),
  },
});

まとめ

remarkプラグインと同様にrehypeプラグインも仕組みを理解してしまえば、アラートの種類の追加やHTML構造の変更も自由自在です。既製プラグインをそのまま使うより、一度自分で実装してみることをおすすめします。

Astro - remarkプラグインを作ってGFMのアラート記法を実現する

Thu, 04 Jun 2026 04:13:08 GMT

私はこのサイトを Astro で構築していて、ブログ記事をマークダウン（.md, .mdx）で記述しています。

例えば、GitHub Flavored Markdown（GFM）には、ノートや警告を視覚的に目立たせるアラート記法があります。

> [!NOTE]
> ここに補足情報を書きます。

> [!WARNING]
> 注意が必要な内容はこちら。

GitHubのREADMEでよく見かけるあの色付きブロックです。

しかし、AstroはMarkdownをHTMLに変換する際、このアラート記法をデフォルトではサポートしていません。変換後は通常の <blockquote> になってしまいます。

既製のプラグインを使う方法もありますが、仕組みさえわかればそれほど難しい実装ではありません。自分で作ればHTML構造、クラス名、アイコン、タイトルなど自由にカスタマイズ可能です。

この記事では、remarkプラグインをゼロから自作する方法を解説します。

remark vs rehype - どちらでプラグインを作るか

AstroのMarkdown処理パイプラインは、unified というエコシステムの上に成り立っています。そのなかで主役となるのが remark と rehype の2つです。

remark はMarkdownを扱うプロセッサです。入力したMarkdownテキストを mdast（Markdown Abstract Syntax Tree）と呼ばれるツリー構造に変換し、プラグインはそのツリーを自由に操作できます。「Markdownのテキストを読んで構造を変えたい」場合はremarkプラグインが適しています。
rehype はHTMLを扱うプロセッサです。こちらは hast（Hypertext Abstract Syntax Tree）を操作します。mdastがhastに変換されたあとで動作するため、出力HTMLの構造を直接いじりたい場合に使います。

unified

Content as structured data: unified compiles content and provides hundreds of packages to work with content

unified

アラート記法の実装には、どちらも使えます。ただし今回は remark を選びました。理由はシンプルで、判定と変換をMarkdownのツリー上で完結させられるからです。blockquoteノードを見つけて別のノードに置き換えるだけなので、remarkのほうが直感的に書けます。

remarkプラグインの作り方

remarkプラグインの要点を整理すると次の通りです。

unist-util-visit で対象ノードをたどる
「対象ノードを置き換える」または「新たなノードを追加する」
data.hName / data.hProperties でHTML変換後の構造を制御する

プラグインの基本構造

remarkプラグインは、ツリーを受け取って何もreturnしない関数を返す関数です。

関数を返す理由は、オプションを受け取れるようにするためです。今回はオプションなしですが、同じ形に従います。

import type { Root } from 'mdast';

export default function remarkMyPlugin() {
  return (tree: Root) => {
    // treeを操作する
  };
}

ノードをたどる - unist-util-visit

ツリーの特定ノードを探すには unist-util-visit を使います。

第2引数でノードタイプを指定します。ここでは 'blockquote' を指定しているので、Markdownの > から始まるブロックが対象になります。コールバックにはnode（対象ノード）、index（親の中での位置）、parent（親ノード）が渡されます。

import type { Blockquote, Parent, Root } from 'mdast';
import { visit } from 'unist-util-visit';

export default function remarkMyPlugin() {
  return (tree: Root) => {
    visit(tree, 'blockquote', (node: Blockquote, index: number | undefined, parent: Parent | undefined) => {
    // blockquoteノードが見つかるたびに呼ばれる
  });
};

ノードを置き換える

visit のコールバック内で parent.children[index] を書き換えると、そのノードを別のノードに置き換えられます。

data.hName と data.hProperties は、rehypeがこのノードをHTMLに変換するときに使うメタ情報です。hName でタグ名を、hProperties でHTML属性を指定できます。className を配列で渡すと class 属性になります。

TypeScriptでは mdast の型と合わなくなるので、as unknown as が必要になる場面があります。

visit(tree, 'blockquote', (node: Blockquote, index: number | undefined, parent: Parent | undefined) => {
  if (!parent || index === undefined) return;

  // ここで parent.children[index] に新しいノードを代入する
  parent.children[index] = {
    type: 'myCustomNode',
    data: {
      hName: 'div',                 // HTMLに変換されたときのタグ名
      hProperties: {
        className: ['my-class'],    // HTMLに変換された時のクラス名
      },
    },
    children: node.children,    // 元のblockquoteの子ノードを引き継ぐ
  } as unknown as Blockquote;
});

子ノードに独自ノードを追加する

children 配列に好きなノードを追加できます。たとえばタイトル用のdivとコンテンツ用のdivに分けたい場合は次のようにします。

type の文字列（'alertCard', 'alertTitle' など）は自由に決められます。これらはmdastの世界だけで使われる識別子で、最終的なHTMLには影響しません。HTMLの構造は hName と hProperties が決めます。

parent.children[index] = {
  type: 'alertCard',
  data: {
    hName: 'div',
    hProperties: { className: ['alert-card', 'alert-note'] },
  },
  children: [
    {
      type: 'alertTitle',
      data: {
        hName: 'div',
        hProperties: { className: ['alert-title'] },
      },
      children: [{ type: 'text', value: 'Note' }],
    },
    {
      type: 'alertContent',
      data: {
        hName: 'div',
        hProperties: { className: ['alert-content'] },
      },
      children: node.children,
    },
  ],
} as unknown as Blockquote;

画像ノードを埋め込む

mdastには image ノードがあるため、HTMLの <img> をツリー上で表現できます。

{
  type: 'image',
  url: '/icons/alert-note.svg',
  alt: '',
  data: {
    hProperties: { className: ['alert-icon'] },
  },
}

実装したプラグイン

実装したプラグインと実際に使った場合の表示は次の通りです。

この実装ではタイトルを付与できるようにしました。

実装

import type { BlockContent, Blockquote, Parent, Root } from 'mdast';
import { visit } from 'unist-util-visit';

const ALERT_TYPES = {
  NOTE: 'note',
  TIP: 'tip',
  IMPORTANT: 'important',
  WARNING: 'warning',
  CAUTION: 'caution',
} as const;

export default function remarkAlert() {
  return (tree: Root) => {
    visit(tree, 'blockquote', (node: Blockquote, index: number | undefined, parent: Parent | undefined) => {
      if (!parent || index === undefined) return;

      const firstParagraph = node.children[0];
      if (!firstParagraph || firstParagraph.type !== 'paragraph') return;

      const firstChild = firstParagraph.children[0];
      if (!firstChild || firstChild.type !== 'text') return;

      // アラート宣言行を判定
      const lines = firstChild.value.split('\n');
      const match = lines[0].match(/^\[!(NOTE|TIP|IMPORTANT|WARNING|CAUTION)\](?:\s+title=(.+))?$/);
      if (!match) return;

      // アラートのタイプとタイトルを取得
      const type = match[1] as keyof typeof ALERT_TYPES;
      const className = ALERT_TYPES[type];
      const customTitle = match[2]?.trim() ?? '';

      // アラート宣言行を除去
      lines.shift();
      const remaining = lines.join('\n');
      if (remaining.trim()) {
        firstChild.value = remaining;
      } else {
        firstParagraph.children.shift();
      }
      if (firstParagraph.children.length === 0) {
        node.children.shift();
      }

      parent.children[index] = {
        type: 'alertCard',
        data: {
          hName: 'div',
          hProperties: {
            className: ['alert-card', `alert-${className}`],
          },
        },
        children: [
          {
            type: 'alertTitle',
            data: {
              hName: 'div',
              hProperties: {
                className: ['alert-title'],
              },
            },
            children: [
              {
                type: 'image',
                url: `/icons/alert-${className}.svg`,
                alt: '',
                data: {
                  hProperties: {
                    className: ['alert-icon'],
                  },
                },
              },
              {
                type: 'text',
                value: customTitle,
              },
            ],
          } as unknown as BlockContent,
          {
            type: 'alertContent',
            data: {
              hName: 'div',
              hProperties: {
                className: ['alert-content'],
              },
            },
            children: node.children,
          } as unknown as BlockContent,
        ],
      } as unknown as Blockquote;
    });
  };
}

マークダウン

> [!NOTE]
> note を記述します。
> タイトルなしです。

> [!TIP] title=tip title
> tip を記述します。
> 英語タイトルありです。

> [!IMPORTANT] title=重要です
>
> important を記述します。
>
> 日本語タイトルありです。

> [!WARNING] title=警告です
>
> warning を記述します。
>
> > blockquote を含みます。

> [!CAUTION] title=危険です
>
> caution を記述します。
>
> > [!NOTE] title=note title
> > アラート記法のNOTEを含みます。

実際の表示：

note を記述します。タイトルなしです。

tip title

tip を記述します。英語タイトルありです。

重要です

important を記述します。

日本語タイトルありです。

警告です

warning を記述します。

blockquote を含みます。

危険です

caution を記述します。

note title

アラート記法のNOTEを含みます。

【補足】 Astroへの組み込み

作成したプラグインは、astro.config.mjs に次の通り実装すると使えるようになります。

astro.config.mjs

import { unified } from '@astrojs/markdown-remark';
import remarkAlert from './path/to/directory/remark-alert';

export default defineConfig({
  markdown: {
    processor: unified({
      remarkPlugins: [remarkAlert],
    }),
  },
});

まとめ

仕組みを理解してしまえば、アラートの種類の追加やHTML構造の変更も自由自在です。既製プラグインをそのまま使うより、一度自分で実装してみることをおすすめします。

このサイトを純粋なCSSからTailwindCSS + DaisyUIへ移行した

Thu, 28 May 2026 23:28:31 GMT

このサイトのスタイルを、純粋なCSS運用からTailwindCSS + DaisyUIベースへ移行しました。

結論、ブログサイトとして視認性のいいシンプルな見た目になって満足しています。

比較画像

ホーム

旧

新

ブログ一覧

旧

新

ブログ詳細

旧

新

純粋なCSSは設計することが多すぎる

純粋なCSSを真面目に運用していくと、結局CSSフレームワークを自作しているのと変わらなくなる。

最初は普通にCSSを書いていました。

.card {
  padding: 16px;
  border-radius: 12px;
  border: 1px solid #000;
  background: white;
}

もちろん最初はこれで十分です。

しかし、画面数やコンポーネントが増えていくと、徐々に「ルール」が欲しくなってきます。

例えば、

トークン設計
- spacing（margin / padding基準）
- color（テーマ・ダークモード含む）
- radius / shadow / typography
コンポーネント設計
- variants（button, card等のバリエーション定義）
- state（hover, focus, disabledの統一）
レイアウト設計
- レスポンシブの方針（breakpoint・単位の統一）
CSS設計ルール
- 命名規則
- 責務分離（何をどこに書くか）

など。

やればやるほど考えることが増えていって、無限に増え続ける設計を前に絶望します。

その結果、「TailwindCSSやDaisyUIでいいや」となります。

個人開発でやるにはコストが高すぎる

もちろん、「自前CSSフレームワークを作る」こと自体は悪くないです。

設計コストや開発コストを払ってでも、そのほうが長期的に得ならやればよいと思います。

ただ、個人開発の範疇だと、かなり割に合わないと感じました。

新しいUIを作るたびに、

ユーティリティを追加するか？
コンポーネント化するか？
variantを増やすか？
例外CSSで逃げるか？

みたいな判断が発生して、かなり消耗します。

移行してよかったこと

意思決定が減った

フレームワークのユーティリティクラスを使えば、追加も削除も躊躇する必要がありません。デザイントークン設計を自分でやる必要がなく、p-4やtext-base-contentのような既存の語彙に乗れるのが楽です。

最低限の見た目が担保される

DaisyUIではbtnやcardといったクラス一つで、それなりに整ったUIが出来上がります。ゼロからhover状態やfocus-visibleを書かなくていいのは、地味に大きいです。

気になった点・注意すること

クラス名が長くなる

TailwindCSSの宿命として、HTMLにクラスが並ぶため実装が長くなります。気になる人はすごい気にするやつですね。

私もはじめは気になっていましたが、だんだんと慣れてきたのとあまりに実装が楽になるので気にならなくなってきました。

フレームワークっぽさが残る

当然ながら、そのまま使うとかなり「DaisyUIっぽさ」が出ます。

細かいカスタマイズをしようとすると、DaisyUIのデフォルトを上書きする必要があり、完全にコントロールしたい箇所は、素のTailwindCSSで書いたほうがいいこともあるかもしれません。

まとめ

個人ブログを純粋なCSSからTailwindCSS + DaisyUIへ移行して、デザインを刷新しました。

個人的にはシンプルで見やすいサイトに生まれ変わったなと思っています。

純粋なCSSを突き詰めるのも面白いですが、個人開発では、

「いい感じの見た目を、ほどほどのコストで得る」

ことの価値はかなり大きいと思いました。

Windows 向けの画面録画アプリ OpRec を開発しました

Sat, 25 Apr 2026 00:35:18 GMT

操作説明の動画を作りたいとき、こんな悩みはありませんか？

「クリックした場所がわかりにくい」
「どのキーを押したか視聴者に伝えにくい」
「注目ポイントをズームして見せたい」

そんな課題を解消するために、Windows 向けの画面録画アプリ OpRec を開発しました。

GitHub - r-dev95/OpRec

Contribute to r-dev95/OpRec development by creating an account on GitHub.

GitHub

OpRec とは

OpRec は、クリックハイライト・キー表示・ズーム機能を備えた Windows 向け画面録画アプリです。C# / .NET 8 / WinUI 3 で構築されており、操作説明動画の作成に特化した機能を揃えています。

主な機能

📹 画面録画：

任意の範囲をドラッグで選択して録画できます。システム音声・マイク音声の同時録音にも対応しています。

🖱️ クリックハイライト（録画用オーバーレイ）：

マウスクリックした位置をビジュアルでハイライト表示します。視聴者がどこを操作しているかが一目でわかります。

⌨️ キー表示（録画用オーバーレイ）：

押下したキー入力をオーバーレイで表示します。ショートカットキーの説明動画などで重宝します。

🔍 ズーム表示（録画用オーバーレイ）：

録画中に特定箇所をズームして見せることができます。細かいUIの操作説明に便利です。

🗺️ ミニマップ（ガイド用オーバーレイ）：

ズーム位置を示す枠線とミニマップを、録画対象外のオーバーレイ画面に表示します。録画者自身が現在のズーム位置を把握できます。

⚙️ 設定の保存と管理：

ホットキー・映像品質・FPS・音声キャプチャモードなどの設定を保存・管理できます。

デモ

操作イメージ：

録画イメージ：

使い方

アプリを起動する
設定画面でホットキーや品質を調整する
録画範囲をドラッグして選択する
ホットキーまたは操作ボタンで録画開始 / 停止する

アーキテクチャ

クリーンアーキテクチャをベースに、以下の4層で設計しています。

レイヤー	役割
Presentation	UI（WinUI 3）と ViewModel（MVVM）
Application	ユースケース・セッション状態管理・ポート定義
Infrastructure	録画・入力・設定の実装
Domain	ドメインモデル・設定値

依存の方向は常に内側（Domain）に向かい、Application と Infrastructure の境界はインターフェースで分離しています。詳細は architecture.md をご参照ください。

技術スタック

種別	内容
言語	C#
フレームワーク	.NET 8 / WinUI 3 (Windows App SDK)
アーキテクチャ	クリーンアーキテクチャ, MVVM
音声処理	Windows.Media, NAudio
DI	Microsoft.Extensions.DependencyInjection / Hosting
ログ	Microsoft.Extensions.Logging, NLog
UI部品	CommunityToolkit.WinUI, WinUIEx

おわりに

既存ツールでは痒いところに手が届かないと感じたことが開発のきっかけです。ちょっとした操作説明動画を作る際にあったらいいなって思った機能を詰め込んでみました。

フィードバックや Issue・PR など歓迎しています！

GitHub - r-dev95/OpRec

Contribute to r-dev95/OpRec development by creating an account on GitHub.

GitHub

このサイトを Vite + Vanilla JS から Astro に移行した話

Tue, 14 Apr 2026 13:14:55 GMT

このサイトを Vite + Vanilla JS から Astro に移行しました。

併せて、ホスティング先を Github Pages から Netlify に変更したので、旧サイト は、まだ存在しますが今後、運用しません。

はじめに

今回、Vite + Vanilla JS で構築していた個人ブログサイトを Astro に移行してみました。

私は Web 開発初心者で HTML / CSS / JavaScript の基礎を学習するために、旧サイトでは Vite + Vanilla JS を選択しました。

詳細：

はじめまして。静的な個人ブログサイトを作りました | R.dev

Web初心者が静的な個人ブログサイトをVite + vanilla JSで構築した話です。

r-dev95.netlify.app

そして当初から「基礎を学んだらモダンな技術を使って実装しなおそう」と思っていました。

そこで個人のブログサイトを開発するのに一番よさそうなフレームワークとして Astro を選択しました。

「Astroを選ぶ理由」の冒頭：

Astroは、ブログやマーケティング、eコマースなど、コンテンツ駆動のウェブサイトを作成するためのウェブフレームワークです。Astroは、新しいフロントエンドアーキテクチャを開拓し、他のフレームワークと比較してJavaScriptのオーバーヘッドと複雑さを低減することで知られています。高速でSEOに優れたウェブサイトが必要なら、Astroが最適です。

Next.js などの選択肢も考えられましたが、私が開発したいサイトには機能が過剰かなと思い選択しませんでした。

移行前後の構成

項目	旧サイト	新サイト
ビルドツール	`Vite`	`Astro` (内部で `Vite` を使用)
フロントエンド	`Vanilla JS`	`Astro`
記事管理	`Markdown`	`Markdown`
Markdown処理	`gray-matter` / `remark` / `rehype`	`Astro` (内部で `remark` / `rehype` を使用)
コードハイライト	`Shiki`	`Shiki`
OGP画像生成	`sharp`	`sharp`
テスト	`Vitest` + `jsdom`	-
ホスティング	`GitHub Pages`	`Netlify`

移行してみた感想

フレームワークなしとの比較になるので、当たり前かもしれませんが、Astro での実装は圧倒的に開発体験が良かったです。

特によかった点としては、次が挙げられます。

コンポーネント化・レイアウト化が容易
マークダウン記事のページ生成が容易

さらに Netlify でのデプロイもかなり容易でした。

コンポーネント化・レイアウト化が容易

旧サイトでは、ビルドスクリプトでコンポーネントごとに HTML を文字列として作成していました。そのため、ビルドスクリプトの HTML 部分に対して、リントやフォーマット、シンタックスハイライトが効きません。さらにいちいちビルドしないと HTML が生成されないので npm run dev で開発サーバを立ち上げた状態での開発が意味を成しません。ちょっとした変更でも開発体験が悪く大変でした。

旧サイトのビルドスクリプトのイメージ

function renderBaseHead(title, description) {
  return `
<head>
  <title>${title}</title>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <meta name="description" content="${description}" />
</head>`
}

これを Astro では .astro という形式のファイルに React の JSX ライクな実装ができます。

フロントマター部分にはサーバ側で処理されるスクリプトが書けます。その下には、ほとんど生の HTML が書けます。style タグや script タグももちろん使えます。

components/BaseHead.astro

---
const { title, description } = Astro.props;
---
<head>
  <title>{title}</title>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <meta name="description" content={description} />
</head>

また使い方も通常の HTML タグのように非常に直感的に扱えると思います。

---
import BaseHead from '@/components/BaseHead.astro';

const title = 'ポストページ';
const description = 'ポストページです。'
---
<html lang="ja">
  <BaseHead title={title} description={description} />
  ...
</html>

さらに slot タグを使用するとレイアウトコンポーネントが簡単に実装できます。

layouts/Layout.astro

---
import BaseHead from '@/components/BaseHead.astro';
import Header from '@/components/Header.astro';
import Footer from '@/components/Footer.astro';

const { title, description } = Astro.props;
---
<html lang="ja">
  <BaseHead title={title} description={description} />
  <body>
    <Header />
    <slot />
    <Footer />
  </body>
</html>

こちらも非常に簡単に使えて、Layout タグで囲った子コンポーネントが slot タグ部分に挿入されます。

---
import Layout from '@/layouts/Layout.astro';

const title = 'ポストページ';
const description = 'ポストページです。'
---
<Layout title={title} description={description}>
  <main>
  ...
  </main>
</Layout>

このようにコンポーネントやレイアウトを簡単に切り分けられたり、フロントマター内で処理した結果を HTML に組み込めるのは、可読性、保守性、拡張性が上がって開発が楽だなと思いました。

マークダウン記事のページ生成が容易

旧サイトでは、マークダウン記事のページは次の通り生成していました。

マークダウンを読み込む
gray-matter でマークダウンのフロントマターと本文を分割する
本文を remark と rehype で HTML 化、Shiki でシンタックスハイライトする
記事のデータを文字列で構築した HTML に組み込み生成する

Astro にはコンテンツコレクションという概念が存在します。

コンテンツコレクションでは、各記事に共通する構造を定義するスキーマを設定できて、Zod (TypeScript向けのスキーマ宣言・検証ライブラリ) で構造を検証してくれます。

src/content.config.ts

import { glob } from 'astro/loaders';
import { defineCollection } from 'astro:content';
import { z } from 'astro/zod';

const posts = defineCollection({
  loader: glob({ pattern: `**/[^_]*.md`, base: './src/posts' }),
  schema: z.object({
    title: z.string(),
    summary: z.string(),
    tags: z.array(z.string()),
    createdAt: z.date(),
  }),
});

export const collections = { posts };

Astro ではファイルベースルーティングを採用していて、動的ルーティングでパラメータを持たせることで、1つのファイルから複数のページを生成できます。

getCollection() でコンテンツデータを取得し、getStaticPaths() で動的ルーティングで持たせるパラメータ (ここでいうと slug)を設定することで各ページを生成します。[slug] ではなく [...slug] とすることで多階層に対応できます。

render() でマークダウンの HTML 変換とコードブロックのシンタックスハイライトなどのプラグイン処理が行われ、Astro コンポーネントが返されます。

HTML 変換関連には remark と rehype が、シンタックスハイライトには Shiki または Prism (選択式) が採用されています。この構成は旧サイトと同じだったのでレンダリング結果も特に違和感なく使用できました。

src/pages/posts/[...slug].astro

---
import { getCollection, render } from 'astro:content';
import PostLayout from '@/layouts/PostLayout.astro';

export async function getStaticPaths() {
  const posts = await getCollection('posts');
  return posts.map((post, index) => {
      params: { slug: post.id },
      props: { post },
  });
}

const { post } = Astro.props;
const { Content } = await render(post);
---
<PostLayout post={post}>
  <Content />
</PostLayout>

Netlify でのホスティングが容易

旧サイトでは、Github Pages にホスティングしていましたが、フリー枠ではプライベートリポジトリでのホスティングができません。そのため Github Actions を利用して、プライベートリポジトリでソースコードを管理して、パブリックリポジトリにビルド結果のみをプッシュして、サイトを公開する形をとりました。

一方、Netlify では Github のリポジトリを連携するだけで、公開ができました。プライベートリポジトリでも連携可能です。さらにリポジトリにプッシュすれば、Netlify のビルド処理が走り、レビュー用のサイトURLが提供されるため、マージ前の確認が容易にできます。

旧サイトのデプロイでも特に難しいことがあったわけではないですが、Netlify でのデプロイがあまりにも簡単で驚きました。

おわりに

今回、ブログサイトを Vite + Vanilla JS から Astro へ移行してみて、フレームワークありでの開発があまりにも体験がいいということを改めて感じさせられました。

まずは「移行を完了させる」ことを優先したため、CSSはほとんど以前のものを持ってきています。そのため Astro の特徴に合わせたコンポーネント単位のスタイル整理はできていません。

今後は次を進めていけたらと思います。

コンポーネントごとのスタイル責務の整理
CSS 構成の見直し
Tailwind CSS 導入

このサイトのUIとOGP画像を修正しました

Thu, 09 Apr 2026 05:15:55 GMT

この記事は本サイトへの移行に当たって、旧サイトの記事をそのまま持ってきたものになります。

旧サイト：

R.dev

R.dev の個人ブログサイトです。

r-dev95.github.io

このサイトの UI と OGP 画像について、気になっていた部分を修正したので、作業内容とあわせて反省点もまとめておきます。

UIの修正

記事リンクカードのタイトル表示

記事リンクカードは、タイトルが長くなると折り返さず省略するようにしていました。そのため視聴端末によっては幅が狭く、タイトルの半分も見えないような状態でした。

そこで、長いタイトルが入っても2行分は見られるように表示を調整しました。

ページ移動ボタンの見た目

記事詳細ページの前後移動ボタンも、最初は状態の違いが少し分かりにくい見た目になっていました。

特に、移動できないときのボタンが通常時とあまり変わらず、押せるのか押せないのかが伝わりにくかったため、disabled 相当の状態が見た目でも分かるように調整しました。

OGP画像の修正

ブログ詳細ページ用の OGP 画像はローカルでは問題なく生成できていたのですが、GitHub Actions を使って Ubuntu 上でビルドしたときに文字化けしてしまう問題がありました。

調べてみると、原因はビルド環境ごとのフォント差分でした。Windows では表示できていても、Ubuntu 側では同じフォントが使えず、日本語の描画が崩れていました。

そのため、Ubuntu 上でも利用できる日本語フォントを使うように見直し、GitHub Actions 側でもフォントをインストールするよう修正しました。

まとめ

今回の修正を通して、いくつか反省点がありました。

短いタイトルや限られた表示パターンだけで確認すると、実際の運用で崩れるポイントを見落としやすい
ボタンやリンクは、動くだけでなく状態が見た目で伝わることも大事
ローカルで問題がなくても、CI や本番に近い環境では別の問題が起きることがある
見た目に関する機能でも、環境依存やフォント差分まで考える必要がある

UI を整える作業は見た目の微調整に見えますが、実際には使いやすさや保守性にも関わる部分だとあらためて感じました。

今後は、作ったあとにすぐ公開するのではなく、

長いタイトルや例外的なデータでも確認する
状態違いを含めて UI を見る
ローカルだけでなく CI 環境でも確認する

といった流れを、最初から意識して進めていきたいです。

はじめまして。静的な個人ブログサイトを作りました

Wed, 08 Apr 2026 14:26:36 GMT

この記事は本サイトへの移行に当たって、旧サイトの記事をそのまま持ってきたものになります。

旧サイト：

R.dev

R.dev の個人ブログサイトです。

r-dev95.github.io

はじめまして。 Web技術を学ぶために、静的な個人ブログサイトを作りました。

これまでに TypeScript、React、Next.js、Tailwind CSS、shadcn など、いわゆるモダンで流行りの技術に触れたことはありました。実際、見た目が整ったものや、ひとまず動くものを作ること自体はできていました。

ただ、その一方で「自分はいま何をフレームワークに助けられていて、何がWebの基礎そのものなのか」をきちんと理解できているかというと、あまり自信がありませんでした。

特に、JavaScript、HTML、CSS の理解が浅いままだと、

どこまでがモダンな技術の独自要素なのか
その技術が何を楽にしてくれているのか
そもそも何がうれしいのか

が、感覚としてつかみにくいと感じました。

そこで今回は、いったん基礎から学習しなおすつもりで、最初から大きな仕組みを入れすぎず、まずは自分で理解しながら作れる構成にしたいと考えました。そこで今回は、Vite + Vanilla JS を使って、できるだけシンプルに、でも実際の運用まで見据えたブログサイトを組み立てています。

この記事では、最初の投稿として

なぜ静的サイトにしたのか
どんな機能を実装したのか
どんな技術構成にしたのか
作ってみて感じたこと
今後どんな形で作り直してみたいか

をまとめてみます。

なぜ静的サイトにしたのか

今回、まず大事にしたかったのは「自分で把握できる範囲で安全に作ること」でした。

Webアプリにはログイン、データベース、フォーム送信、API通信など、学ぶと面白そうな要素がたくさんあります。ただ、初心者の段階でそれらを一気に扱うと、仕組みを理解する前に複雑さだけが増えてしまいそうだと感じました。

そこで最初のブログは、サーバーサイドの処理を持たない静的サイトとして構築しました。静的サイトであれば、攻撃対象になりやすい要素をかなり減らせますし、配信もシンプルになります。もちろん静的サイトだから絶対安全というわけではありませんが、少なくとも最初の学習対象としてはとても扱いやすい選択だったと思っています。

また、HTML・CSS・JavaScript の基本を自分の手で触って理解したかったので、あえてフレームワークに頼りすぎず、Vanilla JS で組んでみました。

今回のサイトで実装したこと

見た目はシンプルなブログですが、中ではいくつかの機能を自作しています。

1. トップページ

トップページには、自己紹介用の About セクションと、最新記事を表示する Post セクションを用意しました。

Post セクションには新しい記事を最大3件表示するようにしていて、一覧ページへの導線も置いています。個人サイトらしく、SNS へのリンクもヘッダーやトップページからたどれるようにしています。

2. 記事一覧ページ

記事一覧ページでは、投稿済みの記事をまとめて確認できます。

実装としては、ビルド時に生成した記事データをもとに一覧を表示していて、タグによる絞り込みもできるようにしました。タグの切り替えはクライアントサイドの JavaScript で動かしていて、静的サイトのままでも少しインタラクティブな操作ができるようになっています。

3. 記事詳細ページ

各記事には個別ページを用意しています。

記事詳細ページでは、以下のような情報を表示しています。

タイトル
投稿日
タグ
本文
前後の記事への移動リンク
X 共有リンク

単に Markdown を表示するだけでなく、ブログとして最低限使いやすい導線も意識しました。

4. Markdown から記事ページを生成

記事は Markdown で書けるようにしています。

各記事は content/posts/<slug>/index.md のような構成で管理し、ビルド時に

トップページ
記事一覧ページ
各記事の詳細ページ
記事一覧用の JSON データ

をまとめて生成する仕組みにしています。

記事本文の変換には gray-matter、remark、rehype を使っていて、Markdown の frontmatter からタイトルや概要、タグ、投稿日などを扱えるようにしています。さらに、コードブロックには Shiki を使ってシンタックスハイライトも入れました。

5. 記事ごとの OGP 画像生成

各記事ページごとに、記事タイトルを使ったOGP画像を自動生成する仕組みを入れています。テンプレート画像にタイトル文字を合成して、SNS 共有時に記事ごとの見た目が変わるようにしました。

技術構成

今回の主な構成は次のようになっています。

項目	内容
ビルドツール	`Vite`
フロントエンド	`Vanilla JS`
記事管理	`Markdown`
Markdown処理	`gray-matter` / `remark` / `rehype`
コードハイライト	`Shiki`
OGP画像生成	`sharp`
テスト	`Vitest` + `jsdom`
ホスティング	`GitHub Pages`

フロントエンドはかなり素朴な構成ですが、そのぶん「何がどこで動いているのか」を追いやすいのがよかったです。

CSS も分割して管理していて、全体の土台、レイアウト、共通コンポーネント、記事一覧、記事詳細、本文表示というように役割ごとに整理しています。大きなライブラリに頼らず、少しずつ積み上げていく練習にもなりました。

公開フローと運用

今回、個人的にこだわったポイントのひとつが公開フローです。

ソースコード本体はプライベートリポジトリで管理し、実際に公開するビルド結果はパブリックリポジトリで管理するようにしました。GitHub Pages で公開したかったので、GitHub Actions を使って CI/CD も組んでいます。

流れとしては、プライベートリポジトリの main に push すると、

依存関係をインストール
記事ページや OGP 画像を生成
サイト全体をビルド
パブリックリポジトリへ成果物を同期
GitHub Pages 側に公開

という形でデプロイされます。

「ソースは公開しすぎたくないけれど、成果物は公開したい」という形を自分で組んでみたかったので、ここはかなり勉強になりました。

テストも入れてみた

まだ学習中ではありますが、今回はテストもなるべく書くようにしてみました。

具体的には、

Markdown の変換処理
記事一覧の描画
記事詳細ページの描画
タグ絞り込み
OGP 画像生成まわり
補助的なユーティリティ処理

などに対して、Vitest と jsdom を使ったテストを用意しています。

個人開発でここまでやる必要があるかは人それぞれだと思いますが、今回は「あとで安心して触れる状態を作ること」も学習の一部だと考えました。実際、ちょっとした修正でもテストがあると気持ちがかなり楽になります。

作ってみて感じたこと

今回いちばん大きかったのは、シンプルな技術だけでも、思っていたよりちゃんとブログらしいものが作れると実感できたことです。

最初は「Vanilla JS だけだとかなり大変なのでは」と思っていましたが、

自分で理解しながら進めやすい
どこでHTMLを作っているかが見えやすい
ビルド処理の流れを学びやすい
後から設計を見直しやすい

という点で、初心者の自分にはかなり合っていました。

一方で、作っていく中で「ここはもっとモダンな技術を使うと楽になりそう」と感じる場面もたくさんありました。テンプレート管理、コンポーネントの再利用、スタイル設計、記事周りの構成などは、今後さらに学んでいきたい部分です。

今後やってみたいこと

次のステップとしては、Astro や Tailwind CSS を使ってブログを再構築してみたいと思っています。

Astro はコンテンツサイトとの相性が良さそうですし、コンポーネントベースで整理しやすそうなので、今回自作した仕組みと比べながら学べそうだと感じています。Tailwind CSS についても、ユーティリティファーストな書き方を一度しっかり触ってみたいです。

今回のブログは、完成版というよりも「自分が次に進むための土台」だと思っています。

まずは Vite + Vanilla JS で、静的サイトの構成、Markdown からのページ生成、デプロイ、自動化、テストまで一通り体験できました。次はそこから一歩進んで、より保守しやすく、より表現しやすい構成に挑戦していきたいです。

おわりに

Web初心者の自分にとって、今回のブログ制作は「ページを作る」だけでなく、

構成を考える
安全性を意識する
公開方法を設計する
自動化する
継続しやすい形を考える

ところまで含めて、とても良い学習になりました。

まだまだ改善したいところはたくさんありますが、まずは自分の手でここまで形にできたことを素直にうれしく思っています。

これからこのブログでは、Web 技術の学習メモや制作記録、試したこと、つまずいたことなどを少しずつ残していく予定です。

もし同じように「まずはシンプルな静的サイトから始めてみたい」と考えている方がいたら、この記録が少しでも参考になればうれしいです。

OpRec - Windows向け画面録画アプリ

Fri, 29 May 2026 04:25:40 GMT

チュートリアル動画作成に特化したクリックハイライト・キー字幕・ズーム機能を持つ録画アプリです。

ZennとQiitaの記事のクロスポスト用Github Actions

Fri, 29 May 2026 04:09:29 GMT

ZennとQiitaの記事を同期して、クロスポストを実現します。