AstroでMarkdown記事をGit管理する運用

「記事をどう管理すればいい？」と迷ったら、まずは Markdown + Git がおすすめです。専門用語が多い分野ですが、流れ自体はシンプルです。この記事では、公開までの手順と、つまずきやすいポイントを初心者向けにまとめます。

この記事の前提環境

手順は次の構成を前提に書いています。別の構成でも考え方は同じですが、画面名やコマンドは読み替えてください。

• サイト生成: Astro（Markdown / MDX をコンテンツコレクションとして読み込む構成）
• 実行環境: Node.js 22.12 以上と npm
• 記事の保管先: GitHub のリポジトリ1つ（プライベートでも可）
• 公開先: Netlify の Free プラン（GitHub 連携による自動デプロイ）
• エディタ: Markdown が書ければ何でも可。Git 操作はコマンドライン前提で説明します

サーバーへのファイル転送（FTP）や、管理画面からの投稿は使いません。「ローカルで書く → GitHub へ Push → Netlify が公開する」の一方向だけを覚えれば足ります。

使う道具をひとことで

• Markdown … 普通の文章に見出しやリンクを書くための書き方
• Git / GitHub … 変更履歴を残しながらファイルを保管する仕組み
• Netlify … GitHub に送った内容をサイトとして公開するサービス（Free でも商用可）
• Astro … Markdown をWebページに変換する道具

つまり、「書いて送れば、自動で公開される」状態を作るのがゴールです。広告ブログのような商用用途でも、まずは Free プランで始められます。ただし Free は月のクレジットに上限があり、使い切るとその月は一時停止します。サイトが複数あったり、本番ブランチへの公開デプロイが多いときは Personal や Pro を検討してください（Deploy Preview のデプロイ自体はクレジットを消費しませんが、プレビュー閲覧時の帯域・リクエストなどは別途消費し得ます。詳しくは ほぼ0円で始める広告収益ブログの設計と検証手順）。

公開までの6ステップ

1. パソコンで Markdown 記事を書く
2. 先頭の設定（タイトルや日付）を入れる
3. 品質チェックを実行する（短すぎないか確認）
4. GitHub に送る（Push）
5. Netlify が自動で公開する
6. Search Console で検索登録を確認する

途中で失敗しても大丈夫です。前の版に戻せるのが Git の強みです。広告収益の実験は何度も直すので、この安心感が役立ちます。本番デプロイのたびにクレジットが減るので（1回あたり15）、Usage 画面もときどき見ておくと安心です。

frontmatter（記事の先頭設定）の例

---
title: "タイトル"
description: "概要"
date: 2026-08-01
tags:
  - AI
  - React
thumbnail: /images/example.svg
monetization: adsense
---

ここは「記事カードのラベル」だと思ってください。タイトルや説明文は、検索結果やSNSでも見られます。短すぎず、長すぎない長さを意識するとよいです。

monetization は収益手段の分類用で、adsense / affiliate / both / none を取ります。当サイトの実装では広告の出し分けには使っていません。実際にこの値を見ているのは記事ページのアフィリエイト表記だけで、affiliate か both のときにステマ規制向けの明示を出します（src/utils/affiliate.ts）。AdSense のスクリプトや広告枠はどの値でも出力しません。広告の有無を frontmatter で切り替えたい場合は、自分で分岐を書く必要があります。

よくあるミス

ミス	起きやすいこと	直し方
description が短すぎる	SNSや検索での説明が薄い	60字以上を目安に書き直す
本文先頭に # を書く	タイトルが二重表示になる	H1は frontmatter の title に任せる
内部リンクがない	回遊しにくい	関連記事へ1本以上リンクする
thumbnail 未指定	一覧の見た目が欠ける	/images/... を指定する

品質チェックを習慣にする

公開前に機械チェックを挟むと、薄い記事のまま出してしまう事故が減ります。Webaff では次を Push 前の定番にしています。

npm run check:content -- --strict
npm run og:generate

--strict は警告もエラー扱いにします。タイトル長・本文量・H2・内部リンク・サムネなどをまとめて確認できるので、初心者ほど先に入れておく価値があります。

公開後にやること（最短）

1. 本番URLで記事を開き、見出し・表・コードが崩れていないか見る
2. スマホ幅でも読めるか確認する
3. Search Console で URL 検査（または sitemap 経由の登録）を確認する
4. GA4 リアルタイムでヒットが届くか見る

「書いたら終わり」にせず、公開→計測→修正の短いループに乗せると、サイトが育ちやすくなります。指標の見方は GA4とSearch Consoleで毎月追う指標と実測例 も参照してください。

この記事の実測値（2026-09 追記）

そのループを回した結果として、この記事自体の Search Console の数値を出します。

月	クリック	表示	平均掲載順位
2026-08	1	8	6.63位
2026-09	0	0	—

8月は平均6.63位で、当サイトの記事のなかでは一番高い順位でした。それでも表示は8回しかなく、9月は0回です。順位が上がっても、そのキーワード自体の検索回数が少なければ表示は増えません。「順位を上げる」より前に「人が探している言葉で書く」ほうが効く、という当たり前の話がそのまま数字に出ています。当サイト全体の数値は検証データのページで公開しています。

手元で学びたいときの参考書

画面操作だけだと用語が飛び飛びになりがちです。Git / GitHub の流れを本で一度整理したい場合は、次が入門向きです。

Amazon: いちばんやさしいGitとGitHubの教本 第3版

楽天ブックス: いちばんやさしいGitとGitHubの教本 第3版（楽天）

必須ではありません。記事の手順だけで公開まで進められます。用語やコマンドで止まったときだけ、手元の説明を足す程度で十分です。

まとめ

最初は機能を増やしすぎないこと。書いて送って公開し、数字を見る。この繰り返しが、初心者でも続けやすい運用です。frontmatter と品質チェックを型にしておけば、記事が増えても崩れにくくなります。