GitHubでブログ運用ログを管理｜31記事・314コミットで使った実例

2026年5月13日2026年7月22日

GitHubでブログ運用ログを管理してオンライン編集する方法を表すアイキャッチ画像

このブログの運用リポジトリは、2026年5月11日の初回コミットから始まりました。2026年7月22日時点では314コミット、公開記事31本まで増えています。

GitHubに置いているのは記事下書きだけではありません。data/articles.csvで記事を管理し、WordPress反映用データ、サイト監査結果、内部リンク、SNS投稿、次にやる作業まで、公開後に必要な情報を分けて記録しています。

続けて分かったのは、GitHubの価値はブラウザで編集できること以上に、いつ、何を、なぜ直し、どこまで確認したかを1作業単位で戻って確認できることでした。

この記事では、実際のblog-opsリポジトリ構成に加えて、2026年7月22日にAdSense関連記事3本を更新し、公開38URLと画像112点を確認して、関連6ファイルだけをコミットした例まで紹介します。

この記事でわかること

GitHubをブログ運用に使う理由
実際に管理しているファイル一覧
絶対に上げてはいけない情報
初心者が最初に覚えるべき5つの操作

31記事・314コミットで使った実際のGitHub運用

実際の運用では、記事1本の公開だけでなく、WordPressの変更、表示確認、Search Console、SNS、次回タスクを別ファイルへ残しています。2026年7月22日の更新では、別作業の未コミット変更を除外し、AdSense関連記事3本に関係する6ファイルだけをc54b95dとして記録しました。

実際に分けた3種類の運用記録

このリポジトリでは、data/articles.csvで36記事行を管理し、data/sns_posts.csvとdata/x_growth_metrics.csvでX投稿を分け、data/site_qa_snapshot_*.jsonで公開URL・画像・転送・内部リンクの監査結果を残しています。WordPressの管理画面だけでは追えない公開後の判断を、Gitの差分から確認できる形にしています。

記事タイトルと公開状況の一覧
狙っているキーワードのリスト
記事の下書きファイル
画像生成プロンプトの記録
スクリーンショットの保存ログ
公開前チェックリスト
次にやるタスク一覧
Search Console・Analyticsの確認メモ

これらをローカルフォルダだけで管理していると、PCを開かないと確認できません。ファイルが増えるほど「どれが最新か」も判断しにくくなります。

GitHubに置くと「いつでもどこでも」確認・編集できる

GitHubに置けば、ブラウザからMarkdownやCSVをいつでも確認できます。必要なときはオンラインで直接修正することも可能です。

また、このブログではCodexに作業を依頼することが多いため、GitHubに運用ファイルが集約されていると「今どこまで進んでいるか」をAIに伝えやすくなる、というメリットもあります。

GitHubで管理しているファイル一覧

AIブログ実験室では、GitHubを「記事本文の置き場」ではなく、ブログ運営全体の記録庫として活用しています。代表的なファイルは以下のとおりです。

ファイル	用途
`data/articles.csv`	記事タイトル・カテゴリ・公開状態・URLを管理
`data/keywords.csv`	狙うキーワードと検索意図を管理
`*_draft.md`	記事本文の下書きを保存
`*_result.md`	作業結果・公開後の記録
`assets/image_prompt_log.md`	画像生成プロンプトと使用状況の管理
`screenshot/screenshot_log.md`	スクリーンショットの保存状況を記録
`screenshot/redaction_queue.md`	マスク処理が必要な画像の管理
`AGENTS.md`	ブログ運用ルールをまとめたドキュメント

この一覧がGitHub上にあると、Codexに「次に作る記事を提案して」「公開済み記事のリンク矛盾を確認して」といった指示を出しやすくなります。

GitHubに絶対に上げてはいけない情報

GitHubは便利ですが、何でも上げてよいわけではありません。特にブログ運用では、作業ログやスクリーンショットに管理画面のURL・ユーザー名・測定IDなどが写り込みやすいため注意が必要です。

以下のものは、GitHubに上げないと決めています。

パスワード・APIキー・認証コード
DB情報・秘密鍵・決済情報
.env ファイル
rawスクリーンショット画像（管理画面が写り込む可能性があるため）
個人情報・高リスク情報が含まれる画像全般

重要： GitHubに上げる前に「公開しても問題ないか」を必ず確認しましょう。迷うものは上げないのが原則です。

AIブログ実験室では、作業証跡としてraw画像はローカルに保存していますが、Git管理からは除外しています。記事やSNSで使う場合は、個人情報部分をマスクした「redacted画像」のみを使います。

最初はPrivateリポジトリで始めるのが安全

ブログ運用ログには「公開してもよい情報」と「慎重に扱うべき情報」が混在します。そのため、最初はPrivateリポジトリで始めることを強くおすすめします。

Publicリポジトリにすると、記事の下書きや作業ログだけでなく、過去のコミット履歴もすべて公開されます。後から情報を削除しても、履歴に残ってしまう場合があります。

まずPrivateで運用を始め、外に出してもよいテンプレートや情報だけを別途整理して公開する——この流れが現実的で安全です。

GitHubでオンライン編集する5つの基本操作

GitHubの画面は英語が中心ですが、ブログ運用で最初に使う操作はそれほど多くありません。次の5ステップを覚えるだけで十分です。

STEP 1：リポジトリを開く

GitHub上のブログ運用リポジトリにアクセスします。

STEP 2：編集したいファイルを開く

例えば、記事管理なら data/articles.csv、次のタスク確認なら next_tasks.md を開きます。

STEP 3：鉛筆アイコンをクリック

ファイル画面の右上にある鉛筆アイコンを押すと、ブラウザ上で直接編集できます。

STEP 4：内容を修正する

Markdownファイルなら文章を、CSVなら行を編集します。

STEP 5：「Commit changes」で保存する

GitHubでは保存のことを「Commit changes」と呼びます。最初は難しく考えず、「変更を確定するボタン」と覚えておけばOKです。

英語画面が苦手な場合の対処法

GitHubには日本語UIへの切り替え機能がありません。Chromeの翻訳機能を使うと画面の意味は把握しやすくなりますが、いくつか注意点があります。

ファイル名まで翻訳されて表示されることがある
コードやコマンドの表示が崩れることがある
Markdownの本文の見え方が変わることがある

ファイル名やコマンドをコピーするときは、翻訳をオフにした状態で操作する方が安全です。

また、以下の画面は最初のうちは触らなくて問題ありません。必要になったタイミングで確認すれば十分です。

Settings
Security
Deploy keys
Actions secrets
Branches

GitHubとCodexを組み合わせるとできること

GitHub上に運用ファイルが整っていると、Codexへの指示がぐっとスムーズになります。たとえば以下のような作業を任せられます。

data/articles.csv を参照して次に書くべき記事を提案する
公開済み記事と未公開記事の内部リンクの矛盾を確認する
タスクリストを整理して優先順位を整える
記事の下書きをMarkdown形式で作成する
公開後の作業ログを自動生成する
SNS投稿の案をCSVに追加する
変更内容をGitHubにコミットして履歴に残す

WordPressの管理画面だけを見ていると、作業の文脈がその場限りになりがちです。GitHubにログを残しておくことで、「前回なぜこう判断したか」を後から確認できるようになります。

AIブログ実験室で実際にやったこと

このブログでは、次の手順でGitHubとの連携を整えました。

まず、ローカルのブログ運用フォルダをGitリポジトリとして初期化し、GitHubに上げてはいけないファイルを .gitignore で除外しました。特に重要だったのがスクリーンショットの扱いで、raw画像はGit管理から外し、redacted画像のみ使う方針に統一しています。

その後、GitHubでPrivateリポジトリを作成し、ローカルの main ブランチを接続しました。

git remote add origin https://github.com/fukuroworksai01-stack/blog-ops.git
git push -u origin main

これで、記事の下書きや作業ログをGitHub上のブラウザから確認できる状態になりました。

初心者がよくやってしまう失敗と対策

GitHubは便利な反面、初心者がつまずきやすいポイントもあります。事前に把握しておくと安心です。

rawスクリーンショットをそのまま上げてしまう
.env や秘密鍵を誤ってコミットしてしまう
Publicリポジトリにしてから情報の写り込みに気づく
Chrome翻訳でファイル名やコードの表示が変わる
編集後に「Commit changes」を押し忘れて閉じてしまう
何を変更したかメモせずコミットしてしまう

対策の基本： 最初から完璧なGit運用を目指す必要はありません。「上げないものを決める」「記事下書きと作業ログを管理する」「変更したらコミットする」——この3つができれば十分なスタートです。

現在の活用状況

このブログでは、GitHubを記事の保管庫としてだけでなく、ブログ運営の実験ログとして利用しています。2026年7月15日時点で、以下の運用ファイルをリポジトリ内に作成し、更新しています。

月次レポートテンプレート
リライト候補リスト
内部リンク管理表
Search Console確認ログ
SNS投稿管理表
記事ごとの改善ログ

リポジトリの公開範囲を変更する場合は、GitHub公式の「リポジトリの可視性を設定する」を確認します。パスワードやトークンなどの機密情報を誤ってコミットした場合は、ファイルを削除するだけでなく、認証情報の無効化・再発行と履歴からの削除が必要です。手順は「リポジトリからの機密データの削除」を参照してください。

記事が増えるほど、WordPressの管理画面だけでは全体像が見えにくくなります。GitHubで運用ファイルを整理しておくことで、Codexにも「今どこまで進んでいるか」を正確に伝えやすくなります。