1. はじめに

しぴぴぴ!バーチャルストリーマーのしぴちゃんです。 今回はしぴブログを作ったときの話(めっちゃ前だな)をします。

詳細は展開できるようにしているので、簡単に読みたい人は詳細を閉じたまま読んで、詳細に知りたい部分だけ展開して読むといいと思います。 詳細部分はAI生成ベースなのでご了承ください。

ブログを始めたい。どうやるんだ

「ブログを開設したいけど、Webサイトの構築方法がわからない」という状況から始まりました。個人で開設できる無料のブログサービスはたくさんありますが、せっかくなのでしぴサイトに合体する形式にしようと思いました。

詳細の例

こんな感じで詳細を展開して読むことができます。しぴぴぴ!

AIを活用すれば、知識がなくても実装できる

Webサイト構築の経験がない状態でも、ChatGPTやClaudeなどのLLM(大規模言語モデル)に相談しながら進めることで、外部サービスを利用せず自分のブログを開設することができました。

この記事は、単なる「手順書」ではなく、以下の点に重点を置いています:

  • 問題解決のプロセス:何を考え、どう判断したのか
  • AIの使い方:「丸投げ」ではなく、実行→相談→実行のループを繰り返すスタイル

ブログを作る実装方法の入門記事ではなく、「こういう思考プロセスで進めれば、知識がなくてもソフトウェアを作成できる」という実例を示すことが目的です。


2. 前提:課題の整理

「ブログを開設したい」という漠然とした要件

最初は単に「ブログを開設したい」という要件しかありませんでした。

詳細:具体的な課題

例えば、以下のような課題がありました:

  • どんなWebサイト構成にするのか

    • 既存のメインサイト(www.cppp-cpchan.org)と、ブログをどう組み合わせるのか
    • ドメイン構成:サブドメイン(blog.cppp-cpchan.org)か、サブディレクトリ(www.cppp-cpchan.org/blog/)か
  • 技術スタックの選択

    • ブログを構築するツール:何を使う?
    • ホスティング:どこに置く?
    • コスト:無料で実現できるか?
  • 運用の工夫

    • ブログ記事をどう執筆・管理するのか
    • デプロイ(手元の記事をWebサイトとして見えるようにする)をどう自動化するのか

AIに相談する効果

実装前に大枠をAIに相談することで、以下のようなメリットが得られます:

  • 複数の選択肢:各方法のメリット・デメリットを示してくれる
  • 判断根拠:なぜその方法が適切なのかの理由が示される
  • 新しい気付き:自分では思いつかなかった観点が提示される

教訓:AIに相談する前に、自分で「何が問題なのか」「何を決めるべきか」を整理することが重要です。


3. 設計フェーズ:トレードオフの検討

ドメイン構成の選択

最初の大きな決定は、ブログをどの場所に配置するかでした。

詳細:サブドメイン vs サブディレクトリの検討

選択肢1:サブドメイン方式(blog.cppp-cpchan.org)

メリット:

  • ブログが独立したサイトとして管理できる
  • ブログ固有の設定やテーマを自由に選択可能
  • 別々のGitHubリポジトリで管理できるため、分離が明確
  • 別々のデプロイサイクルで運用可能

デメリット:

  • DNS設定でCNAMEレコードの追加が必要
  • SEO的にはメインドメインの権威性を分散させる可能性

選択肢2:サブディレクトリ方式(www.cppp-cpchan.org/blog/)

メリット:

  • メインサイトのドメイン権威性を活用できる(SEO的に有利)
  • 統一されたサイト構造
  • DNS設定の変更が不要

デメリット:

  • メインサイトと同じリポジトリまたは複雑なデプロイ設定が必要
  • Hugo設定でbaseURLやパスの調整が複雑になる可能性

最終判断:サブドメイン方式を選択した理由

サブドメイン方式(blog.cppp-cpchan.org) を選びました。

理由は以下の通りです:

  • 管理の簡単さ:Obsidian → Hugo のワークフローが独立して管理できる
  • 技術的な柔軟性:Hugo固有の設定やプラグインを自由に使用可能
  • 将来の拡張性:ブログが成長しても独立性を保てる

教訓:各選択肢のメリット・デメリットを理解したうえで、「自分の優先順位」を基準に判断することが大切です。


4. 実装フェーズ:段階的な構築

Obsidian + Hugo + GitHub Pagesというスタックの採用

技術スタックの選択は、以下の観点で検討しました:

詳細:スタック選択の過程

なぜOsidian?

Obsidianは「ナレッジベース管理ツール」です。ブログ記事の執筆だけでなく、思考の整理にも使えます。

さらに、obsidian-git というプラグインを使えば、Obsidian上での編集を自動的にGitHub上にcommit/pushできます。これにより、手動でGitコマンドを実行する手間が省けます。

なぜHugo?

Hugoは、markdownファイルからスタティックなHTMLサイトを生成するツールです。

  • 無料
  • 設定がシンプル
  • 豊富なテーマが用意されている
  • ビルドが高速
  • 学習曲線が緩やか

なぜGitHub Pages?

GitHub Pagesはホスティングが完全に無料です。

  • ドメイン指定が簡単
  • SSL/TLS証明書も自動で用意される
  • GitHub Actionsと組み合わせれば、自動デプロイが可能

他の選択肢との比較

他のツール/サービスとの比較
方法コスト難度カスタマイズ性
Hugo + GitHub Pages無料
Wordpress.com月額$
Ghost月額$
Next.js + Vercel無料〜非常に高

今回の優先順位(無料・シンプル・カスタマイズ可能)では、Hugo + GitHub Pagesが最適でした。

次のステップ:GitHub Pages の基本設定

詳細:GitHub Pages 設定の過程

既存のメインサイト構成

既にwww.cppp-cpchan.org用のGitHub Pagesサイトが運用されていました。

新しいブログサイトの追加

1つのGitHubアカウントで複数のPages サイトを運用する場合の構成:

  • メインサイト: リポジトリ username.github.io → 自動URL https://username.github.io → カスタムドメイン www.cppp-cpchan.org
  • ブログサイト: リポジトリ cppp-blog 等 → 自動URL https://username.github.io/cppp-blog → カスタムドメイン blog.cppp-cpchan.org

異なるリポジトリに異なるカスタムドメインを指定できるため、独立したサイト運用が可能です。

テーマ選択:PaperMod

複数のHugoテーマを検討した結果、PaperMod を選択しました。

詳細:テーマ選択の判断基準

主な候補

  1. PaperMod ← 選択

    • シンプルで高速
    • ブログに最適化
    • カスタマイズが容易
    • 日本語対応
  2. Hugo-theme-stack

    • モダンなカード型レイアウト
    • より洗練た見た目
    • ただしカスタマイズはやや複雑
  3. Anatole

    • 非常にミニマル
    • ただしカスタマイズ性がやや劣る

選択理由

メインサイトのデザイン(紫をベースとした落ち着いた色合い)との統一感を重視しました。PaperModはCSS変数を活用した柔軟なカスタマイズが可能で、既存のカラースキーム(#7b5db8, #c5b3e6など)を簡単に適用できます。

Obsidian Vaultの構造設計

ブログ記事やアセットの管理を想定したディレクトリ構造を設計しました:

1
2
3
4
5
6
7
ObsidianVault/
├── posts/              # ブログ記事
│   ├── 2024-01-01-first-post.md
│   └── 2024-01-02-second-post.md
├── assets/             # 画像ファイル
│   └── images/
└── templates/          # テンプレートファイル(任意)

教訓:実装前に「どうやって管理するのか」を考えることで、後々のメンテナンスが楽になります。


5. トラブルシューティング:予期しない問題への対応

問題:ビルドが成功しても、サイトが「Hello!」のままから進まない

セットアップが完了し、GitHub Actionsのビルドは成功していたのに、ブログサイトに記事が表示されませんでした。

原因の特定

AIに相談する際、以下の情報を提供しました:

  • ファイル構造content/posts/ にmarkdownファイルが配置されている
  • ビルドログ:GitHub Actionsは成功している
  • 実際の状況:サイトには「Hello!」というテキストのみ表示される
  • 最初の変更:何が変わったのか、何が変わっていないのか

このように「具体的な情報」を提供することで、AIはより正確な診断ができます。

詳細:トラブルの原因と解決方法

原因は複数あった

  1. index.htmlの存在

    • Hugoは動的にHTMLを生成するツールです
    • 手動で作成した index.html がHugoの出力を上書きしていました
  2. GitHub Actions の権限設定

    • GitHub Pagesへのデプロイに必要な権限がなかった
  3. ファイル構造の微妙なズレ

    • content/posts/ ではなく content/cp-blog/ に配置されていた

解決策

  1. index.html を削除

    1
    
    rm index.html
    
  2. GitHub Actionsの権限設定を修正

    • リポジトリの Settings → Actions → General → Workflow permissions
    • “Read and write permissions” に変更
  3. ディレクトリを正しい場所に移動

    1
    
    mv content/cp-blog content/posts
    

解決後の気付き

複数の原因が組み合わさっていました。1つずつ潰していくには、「何が起きているのか」を正確に伝えることが重要です。

重要な教訓

  • エラーログを見る:GitHub Actions や Hugo のビルドログには、問題の手がかりが含まれている
  • 具体的に報告する:「動きません」ではなく「こういうファイルがあって、こういう結果になっています」と伝える
  • 1つずつ試す:複数の原因がある場合、1つずつ修正して、どれが影響しているか確認する

6. 最適化フェーズ:新しい要件への対応

問題:デフォルトのデザインでは文字が読みにくい

最初の実装では、PaperModのデフォルトテーマを使用していました。しかし、実際にブログを見てみると、複数の改善点が見えました:

  • 文字が読みにくい
  • メインサイトとの統一感がない
  • プロフィール画像が表示されていない

改善方針の決定

詳細:デザイン改善の過程

なぜデザイン改善が後のフェーズなのか

最初から完璧なデザインを目指すのではなく、「とにかく動かす」を優先しました。理由は以下の通りです:

  • 学習サイクルが短い:動いた状態から、どう改善するかを判断できる
  • 優先順位が明確:「動く」「見やすい」「美しい」の順で対応
  • 無駄が少ない:完璧な設計に時間をかけるより、反復的に改善する方が効率的

改善内容

  1. カラースキームの変更

    • メインサイトの紫色(#7b5db8, #c5b3e6)を適用
    • ライトテーマに統一
  2. フォント・行間の調整

    • 日本語フォント対応
    • 行間を広げて読みやすくした
  3. ヘッダーへのプロフィール画像追加

    • メインサイトと同じしぴちゃんの画像を円形で表示
  4. ダークモード対応の見直し

    • ライトテーマを明示的に優先

実装方法:カスタムCSS

Hugo PaperModの特徴は、assets/css/extended/custom.css でスタイルをカスタマイズできることです。

詳細:カスタムCSS の活用

既存のCSS変数を活用

PaperModは以下のようなCSS変数をサポートしています:

1
2
3
4
5
6
7
8
9
:root {
  --main-color: #7b5db8;
  --accent-color: #c5b3e6;
  --bg-color: #f8f8f8;
  --text-color: #2c2c2c;
  --text-secondary: #666;
  --border-color: #e1e1e1;
  --card-bg: #ffffff;
}

これらを定義することで、ライト・ダークモード両対応のカスタマイズが可能です。

詳細記事を折りたたむ仕組みも実装

後述しますが、この記事では「読みたい人だけ読む」を実現するために、HTMLの<details>タグを活用しています。このタグもカスタムCSSでスタイリングしました。

教訓:反復的な改善の効果

最初から完璧を目指すのではなく、「動く状態」を作ってから改善することで:

  • 学習効率が上がる:実際に動いた状態で、何が必要かが明確になる
  • 判断がしやすい:「こうなったら、こう改善したい」と優先順位がつけやすい
  • 時間が短くなる:完璧な設計に時間をかけるより、反復の方が早い

7. 成功のポイント:AIとの効果的な付き合い方

この一連の過程を通じて、「AIを活用して知識がなくても実装する」ためのポイントが見えてきました。

ポイント1:課題を明確にしてから相談する

詳細:「課題の明確化」の重要性

AIに相談する際、「こんな結果が欲しいのですが」ではなく、「こういう背景があって、こういう制約の中で、こう実現したいのですが」と具体的に伝えることが重要です。

例:

  • ❌ 「ブログを作ってください」
  • ✅ 「既存のwww.cppp-cpchan.orgというサイトがあります。ブログを blog.cppp-cpchan.org というサブドメインで開設したいのですが、どういう方法がありますか」

具体的な背景情報があるほど、AIの回答精度が上がります。

ポイント2:複数の選択肢のメリット・デメリットを理解する

AIが提示した選択肢に対して、「なぜその方法が適切なのか」を理解することが大切です。その過程で:

  • 新しい視点が得られる
  • 次のプロジェクトでも応用できる知見が増える
  • 判断基準が明確になる

ポイント3:トラブルシューティングでは具体情報が命

ビルドに失敗したり、期待と異なる結果が出た場合、AIに相談する際は:

  • ファイル構造を示す
  • エラーログを貼り付ける
  • 「何をしたのか」「何が起きたのか」を時系列で説明する

このような具体的な情報があると、AIは診断がしやすくなります。

ポイント4:完璧な設計より反復的な改善

最初から完璧を目指すのではなく、「とにかく動かす」を優先し、その後改善していく方が効率的です。

詳細:段階的改善の流れ

ステップ1:MVP(最小限の実装)を作る

  • ブログが表示される状態を最優先
  • デザインは後で良い

ステップ2:問題点を抽出する

  • 実際に動いた状態で、「何が足りないか」「何が不便か」を見つける

ステップ3:優先順位をつけて改善する

  • 重要度・実装難度を勘案して、改善する順序を決める
  • 実装→確認→次の改善、というサイクルを回す

この流れによって、時間も効率も最適化されます。

ポイント5:「知識がない」を理由に判断を放棄しない

AIは強力なツールですが、最終的な判断は自分で行う必要があります。

  • 各選択肢のメリット・デメリットを理解したうえで判断する
  • 「AIが言ったから」ではなく、「自分の優先順位に合ったから」という理由で選ぶ
  • その過程で、新しい知識や判断軸が身につく

AIは「答えをくれるツール」ではなく「考える相手」として活用することが重要です。


8. おわりに

完成したブログ

知識ゼロの状態から、Obsidian + Hugo + GitHub Pagesのスタックを活用して、blog.cppp-cpchan.org というブログサイトを完成させることができました。

得られたもの

このプロセスを通じて得られたのは、単に「ブログサイトができた」というだけではなく:

  • 問題解決のプロセス:要件整理 → 設計 → 実装 → トラブル対応 → 改善という一連の流れ
  • 判断基準:複数の選択肢から、自分の優先順位に合った判断をする方法
  • AIとの付き合い方:知識がなくても、上手く相談すれば実現できるということ

無料で、かつ自由度高く

このスタックの大きなメリットは:

  • 完全無料:ドメイン以外のコストはゼロ
  • カスタマイズ性が高い:CSSやテーマをカスタマイズして、自分だけのサイトが作れる
  • 自動化されている:Obsidianでの更新が自動的にデプロイされる

次のステップへ

ブログサイトの基盤ができたので、今後は以下のような拡張が考えられます:

  • 記事の検索機能
  • カテゴリ・タグによる分類の充実
  • SNS連携
  • コメント機能

これらも、同じように「必要になった時点で、AIに相談しながら実装する」という方法が適用できます。

読者へのメッセージ

「技術的な知識がない」という理由で、自分のWebサイトを持つことを諦める必要はありません。

AIという強力なツール(Claude、ChatGPTなど)を上手く活用し、適切に相談すれば、知識がなくても十分なクオリティで実現できます。

重要なのは:

  1. 課題を明確にする
  2. 判断基準を持つ
  3. 具体的に相談する
  4. 反復的に改善する

この4点です。

あなたも、同じような道のりで、自分だけのWebサイトを立ち上げてみてはいかがでしょうか。