ブログに蓄積されるのは、記事だけではありません。問題を解決した過程、新しいことを学んだ瞬間、あるテーマに対する視点も一緒に残されます。時が経てば、その記録は、自分が何を悩み、どのように変わったかを示してくれる資産となります。
では、この資産はどこに残すべきでしょうか？記事を書いていたサービスが変わったり消えたりしても、自分が引き続き保管・運営できるべきではないでしょうか？
Gitblogは、自分のGitHubリポジトリに公開記事やブログのコードを保管し、ウェブやAIエージェントを使って記事を執筆し、自分のブログに配信できるサービスです。 記事を自ら所有・管理するという基盤の上に、便利な執筆機能や読者とつながる機能を追加しました。
Gitblogを作った理由は、5つの考えから始まっています。
1. 自分が書いた記事は、自分が所有し、管理できるべきです
記事を長く書き続ける上で重要なのは、その記事をいつでも取り出して見返せるという確信です。私たちは、執筆者が自身の記録を直接保管し、修正し、必要に応じて別の場所に移せるべきだと考えています。
Gitblogの一般公開記事は、自分のGitHubリポジトリにMarkdownファイルとして保存されます。画像をはじめとするブログファイルやコードも一緒に管理できます。リポジトリを自分のPCにダウンロードすれば、ローカルで記事を閲覧・修正・バックアップでき、Gitの変更履歴から以前の内容を確認することも可能です。
Gitblogのサービスが終了しても、自分のアカウントのリポジトリやローカルに保存した記事、ブログのコードは残ります。 ホスティングとドメインを維持すれば、デプロイされた静的ブログを継続して提供でき、必要に応じてファイルを別のホスティングに移すことも可能です。ただし、Gitblogが提供する閲覧・購読といった連携機能は、サービスの運営に依存します。
私たちがGitHubを基盤として選んだ理由もここにあります。すでに多くの人が利用しており、公開リポジトリやGitHub Pagesを通じてブログを始めるための基盤を提供しています。GitHub Freeでも、公開リポジトリのPagesホスティングを利用できます。提供範囲と利用制限はGitHubのポリシーに従います。
どこで記事を書こうとも、公開記事のオリジナルを自分の手元に置いておけるようにすること。これがGitblogの第一の原則です。
2. AIも活用できるブログでなければなりません
AIと一緒に記事を書くことが、ますます当たり前になってきています。メモから下書きを作成し、複雑な内容を整理し、文章を推敲し、他の言語に翻訳します。コーディングエージェントがプロジェクトのファイルを読み込んで修正するように、執筆を支援するエージェントも、ブログのファイルを直接扱えるべきだと考えています。
Gitblogのブログリポジトリには、AIエージェントが参照する執筆・翻訳・検証のガイドラインやコマンドが含まれています。ローカルファイルを読み込んで修正し、コマンドを実行できるエージェントに自分のブログリポジトリを作業対象として指定すれば、その環境で下書きを作成し、公開の準備を進めることができます。必要な認証と権限が与えられている場合は、デプロイまで進めることも可能です。
例えば、次のようにリクエストできます。
このブログリポジトリのAGENTS.mdを読み、執筆ガイドラインに従ってほしい。私が残したメモをもとに記事を作成し、確認できるように下書きとして保存してほしい。
レビューが終わった後は、翻訳、検証、デプロイを続けて依頼できます。使用するエージェントのファイルアクセス範囲やコマンド実行権限によって、可能な作業は異なります。具体的な流れはブログ作成・翻訳ガイドにまとめられています。
Gitblogは、特定のAIモデルに記事の作成を強制することはありません。ウェブ上で直接執筆したり、使い慣れたエディタを使用したり、AIと共同で作業したりすることができます。執筆者が自分のスタイルに合ったツールを選べるようにすることが目標です。
3. 優れた記事は、言語やツールの枠を超えて発見されるべきです
記事を公開した後は、誰かがその記事を見つけ、読んでくれる必要があります。検索エンジンで答えを探す人もいれば、AIサービスに質問して関連資料を見つける人もいます。自分が使っている言語とは異なる言語で読む読者もいます。
Gitblogは、こうした読者にリーチできるよう、多言語での公開や検索・AIによるアクセスを可能にする仕組みを提供しています。
まず、自分が書きやすい言語で書いた原文を、選択した言語に翻訳して公開することができます。DeepL APIを連携させて自動翻訳を行うほか、人間またはLLMが作成した翻訳文をレビューして登録する方式もサポートしています。DeepLの自動翻訳には別途APIキーが必要です。自分で翻訳を管理する場合は、原文が変更された際に翻訳も最新の内容に合致しているかを確認する手順が用意されています。
また、検索エンジンやAIツールが記事の内容や出典を把握できるよう、テンプレートに次のような基盤を整備しました。
- 検索のためのページ情報： タイトルと説明、原文のURL、サイトマップ、言語別ページへのリンクを提供します。
- 記事の文脈を説明する構造： 作成者や公開日などの構造化データを提供し、必要に応じて核心となる回答・出典・質問と回答を追加できます。
- テキストに直接アクセスする経路： 設定に応じて、公開記事のMarkdownバージョンと記事一覧である
llms.txtを提供します。
これは、一般的にSEO、AEO、GEOと呼ばれる、検索・回答・生成型AI環境における発見可能性を考慮した設計です。その目的は、記事の本文と文脈を読みやすく提供することにあります。検索結果の順位やAI回答での引用は各サービスが決定するものであり、翻訳や技術的な設定だけで保証されるものではありません。 検索とAIへのアクセス案内。
Gitblog内でも記事を見つけることができます。フィードに参加しているブログの記事は、収集を経て、最新記事・人気記事・トレンドなどの探索画面に反映されます。読者は興味のある記事を見つけ、著者のブログに移動して読むことができます。
私たちが望むのは、自分が残した記録が、その内容を必要としている人に届く可能性を広げることです。
4. 記事への共感が、GitHubでのつながりへとつながります
良い記事を読めば、著者の次の記事も気になります。どのようなプロジェクトを作っている人なのか、またどのような考えを記録しているのか、調べてみたくなります。
Gitblogでは、こうした関心がGitHub上のつながりにもつながります。ブログの購読は、そのリポジトリのGitHubスターと、著者のフォローはGitHubアカウントのフォローに連動します。 読者は興味のあるブログや著者の記事をまとめて閲覧でき、著者は自身の記録を通じてGitHub上でも読者とつながることができます。
些細なことのように思えるかもしれませんが、私たちはこのつながりに意味があると考えています。コードやプロジェクトを通じて表れる姿に、文章や考えが加わるからです。プロジェクトでの決定、問題を解決した過程、学んだ内容を説明する記事は、その人の仕事を理解するためのもう一つの窓口となります。
スターやフォロワー数が記事の価値を決めるわけではありません。ただ、自分の記事に共感してくれた読者が次の投稿を待ち望む関係へとつながり得るという点こそが、継続して執筆する理由となり得ます。
5. AI時代においても、文章を書くことは重要です
私たちはAIに質問する際、文章を書きます。望む結果を説明し、条件を整理し、回答を読みながら再び質問します。AIがプロンプトや下書きを作成してくれる場合でも、何を依頼し、どのような結果を受け入れるかを判断する過程は残ります。
文章を書くことは、自分の考えを整理する過程でもあります。説明しようと文章を書いていると、分かっていると思っていた部分の抜け穴が見えてきます。根拠を探し、矛盾する主張を修正し、他人が理解できるよう文脈をつなげていくことになります。
AIがより多くの仕事を担うようになっても、私たちは何を重要視し、どのような行動を取るかを決定する「人」としての役割を忘れません。AIと共に書いた文章においても、自分の考えと判断を見失わないこと、それが私たちが目指す文章作成です。
Gitblogが、そうした練習を続けていける場になればと思います。学んだことを自分の言葉で説明し、経験を文脈のある記録として残し、時が経ってから読み返して考えを深めていく場です。
良い記事を積み重ねていくことが、自身の知性を磨く過程となることを願っています。
Gitblogを始める
Gitblogは、Web版のStudioから始めることも、GitHubで直接ブログのリポジトリを作成してローカルPCで運用することもできます。まずはStudioを使う方法から見ていきましょう。
1. GitHubアカウントで登録する
Gitblogにアクセスし、GitHubアカウントで登録・ログインします。ログイン後は、自分のブログを作成・管理するスペースであるStudioに移動します。
2. GitHub Appを連携してブログを作成する
Studioの案内に従って、GitHubでGitblog Appをインストールし、ブログを管理するためのリポジトリへのアクセスを許可します。テンプレートをプレビューして選択した後、ブログのタイトルとリポジトリ名を決定します。
英語版 Studio のテンプレート選択画面。2026年11月3日時点。
ブログファイルは自分のGitHubリポジトリに作成されます。ホスティングにはGitHub Pagesを使用するか、自分のCloudflareアカウントを連携させてCloudflare Pagesを使用できます。選択した方法のデプロイ設定を完了すると、記事を投稿する準備が整います。
3. Markdownで記事を作成して公開する
Studioの記事作成画面で、タイトルと説明、Markdown形式の本文を作成します。記事を代表するサムネイル用のカバー画像や本文内の画像もアップロードできます。
作成中は下書きとして保存し、内容を確認した後、公開状態として保存します。保存後、ビルドとデプロイの進捗状況を確認し、デプロイが完了すれば自分のブログで記事を読むことができます。翻訳が必要な場合は、ブログの翻訳言語と使用方法を設定して併せて運用すればよいです。
GitHubとローカルPCから始める
ローカルのエディタやAIエージェントで作業したい場合は、GitHubから希望するGitblog公式テンプレートを選んで、直接開始できます。
- テンプレートを使って自分のブログリポジトリを作成します。 希望する公式テンプレートのGitHubページから、テンプレートを使用して自分のアカウントに新しい公開リポジトリを作成します。元のテンプレートとは別に、自分が管理するブログリポジトリが作成されます。
- 自分のリポジトリをローカルPCにクローンします。 作成したリポジトリのURLで
git cloneを実行し、ダウンロードされたフォルダをエディタやAIエージェントの作業対象として開きます。テンプレートの案内に従って必要な開発ツールと依存関係をインストールし、ブログのURL・言語・ホスティングなどの初期設定を完了します。 - ローカルで記事を作成し、確認します。
content/posts/にMarkdown形式の文章を作成し、画像を追加します。直接編集するか、エージェントにAGENTS.mdを読み込ませて、作成ガイドラインに従うよう依頼することもできます。下書きを確認した後、公開ステータスに変更し、テンプレートが提供する検証手順を実行します。 - 変更内容をGitHubにアップロードしてデプロイします。 記事と画像をコミットし、デプロイ先のブランチにpushすると、設定されたGitHub Actionsワークフローがブログをビルドし、選択したホスティングにデプロイします。Actionsの実行結果と、実際のブログページに反映されているかを確認します。
最初の1回は、選択したテンプレートの初期設定ガイドに従ってデプロイ環境を準備する必要があります。その後は、ローカルでの作成 → レビューと検証 → コミットとプッシュ → デプロイの確認という流れで記事を執筆し続けることができます。
GitHubで直接作成したブログも、Gitblog Appにそのリポジトリへのアクセスを許可し、Studioの既存ブログ連携機能を通じて管理できます。Web上で作成する方法とローカルで作成する方法のうち、作業に適した方法を選択してください。
自分の記事が残る場所から始めましょう
Gitblogは、記事を自分のアカウントに保存し、使い慣れたツールで執筆し、さまざまな言語や経路を通じて読者と出会えるブログを志向しています。その根底には、記事を通じて自分の考えをより深く理解できるという信念があります。
最初から完璧な記事を書く必要はありません。今日新たに知った事実、長い間悩んできた疑問、自分で解決した問題の一つを記録してみてください。その記録に文脈を加え、改めて推敲する過程が、次の記事へとつながっていきます。
自分が所有し運営するブログで、自分の考えを積み重ねていきましょう。
CONVERSATION
Join the conversation