今あえてBloggerを選ぶ理由とは？ — 非エンジニアでもここまでできる、Bloggerという選択肢
WordPressでもはてなでもない。Googleが2003年から運営し続ける"最古"のブログサービス、Blogger。日本国内での利用者は決して多くないが、エンジニアの視点から見ると、あえて選ぶ理由が実はいくつもある。 本記事では、Bloggerを実際に自作テンプレートで運用している立場から、メリット・デメリットを客観的に整理する。さらに、Bloggerでは珍しいSPA構成・外部スクリプト非依存・動的ページレンダリングという設計思想についても紹介する。 --- 主要ブログサービスとの比較 | 項目 | Blogger | WordPress（セルフホスト） | はてなブログ | note | | ------------ | -------- | ----------------- | ---------- | ---- | | 月額費用 | 無料 | サーバー代 500〜2,000円〜 | 無料 / 600円〜 | 無料あり | | 独自ドメイン | 無料枠で可 | 別途取得が必要 | 有料プランのみ | 非対応 | | AdSense申請 | 独自ドメイン不要 | 独自ドメイン推奨 | 独自ドメイン推奨 | 非対応 | | テンプレートカスタマイズ | XMLを完全制御 | PHPテーマを完全制御 | デザインCSS | 不可 | | サーバー管理 | 不要 | 必要 | 不要 | 不要 | | セキュリティ管理 | 不要 | プラグイン更新等が必要 | 不要 | 不要 | | コミュニティ | ほぼなし | エコシステムが充実 | 国内充実 | 充実 | WordPress（セルフホスト）と比べると、カスタマイズ自由度は同等でありながら、維持コストとサーバー管理の手間がゼロという点がBloggerの最大の差別化ポイントになる。 --- Bloggerのいいところ 完全無料で広告なし 利用料がかからないのはもちろん、サービス側が強制的に広告を挿入してくることもない。AdSenseを導入すれば、収益はすべて自分のものになる。 サーバー管理が不要 レンタルサーバーの契約・更新・バックアップ・WordPress本体やプラグインのアップデート、こういった維持管理作業が一切発生しない。記事を書くことだけに集中できる。 独自ドメインなしでもAdSense申請できる 多くのブログサービスでは独自ドメインが事実上必須だが、Bloggerは blogspot.com サブドメインのままでもAdSense審査に通る実績がある。もちろん独自ドメインの設定も無料で可能。 Google製サービスとの親和性が高い Analytics、Search Console、AdSense、Google Photosとシームレスに連携できる。特にGoogle Photosの画像ホスティングは、URLパラメータだけでリサイズ・WebP変換が可能な実質CDNとして活用できる。 カスタマイズ範囲が広い XMLテンプレートを直接編集でき、HTML/CSS/JavaScript を自由に記述できる。テーマ構造の制約を受けるWordPressテーマと違い、ページの構造から描画ロジックまで完全にコントロールできる。 プラグイン依存ゼロ WordPressはプラグインの更新漏れがセキュリティリスクに直結するが、Bloggerにはそもそもプラグインという概念がない。自分が書いたコードだけが動く、という安心感がある。 --- Bloggerのよくないところ 日本国内の情報が極端に少ない 国内利用者が少ないため、日本語の有益な記事がほとんど見つからない。英語の公式ドキュメントとStack Overflowが主な情報源になる。 コミュニティがない はてなブログのような読者登録・ブックマーク文化、noteのようなフォロワー経由の流入は期待できない。流入はほぼSEOとSNS経由になる。 XMLベース構造の学習コストが高い テンプレートはXMLで記述され、Blogger固有のウィジェットタグ・条件分岐・データタグが存在する。この仕様を理解しないままカスタマイズしようとすると、意図しない挙動に悩まされる。 CSS/JS/HTMLがテンプレート1ファイルに集約される 構造・スタイル・スクリプトがすべて1つのXMLファイルに収まるため、規模が大きくなると冗長になりがちだ。ただし逆に言えば、外部依存ゼロの自己完結型テンプレートとして設計できるという利点でもある。 エディタのリッチテキストがHTMLを汚染しやすい 投稿エディタを「作成」モードで使うと、不要なspanタグやstyleが挿入されてHTMLが汚れる。HTMLモードで直接記述する習慣が必要になる。 --- 自作テンプレートの設計思想 — Bloggerの限界を破る ここからは、実際に運用している自作テンプレートの設計について紹介する。 このテンプレートの核となる思想は 「外部ライブラリに依存しない、完全自作のSPA構成」 だ。通常のBloggerテンプレートはページ遷移のたびにフルリロードが発生するが、History APIとBlogger JSON Feedを組み合わせることでDOM差分更新による動的ページレンダリングを実現している。 アーキテクチャの概要 | 項目 | 採用方針 | | ------- | -------------------------------- | | ページ遷移 | SPA（History API + DOM更新） | | 外部ライブラリ | 不使用（jQuery等に非依存） | | データ取得 | Blogger JSON Feed API | | 画像配信 | GoogleホストのURLパラメータ書き換えで最適化 | | アクセス解析 | Google Apps Script (GAS) に独自ログ送信 | 実装例① インフィード関連記事 外部ライブラリを一切使わず、Blogger標準のJSON-in-script feedからランダム関連記事を動的挿入している。 実装例② アクセスログをGASに送信して独自スコアリング 滞在時間とスクロール率を掛け合わせた独自のエンゲージメントスコアを算出し、Google Apps Script経由でSpreadsheetに蓄積している。外部アクセス解析ツール不要でページ価値を定量評価できる。 実装例③ 画像の自動最適化 Bloggerの画像URLパターンを正規表現で書き換えて、表示コンテキストに応じたサイズ配信を実現。WebP変換もURLパラメータ一つで対応できる。 --- こんな人に向いている Bloggerが合う人 HTML/CSS/JSの基礎知識があり、テンプレートを自作したいエンジニア 維持コストゼロで長期運用したい個人ブロガー AdSenseでの収益化をすぐに始めたい人 Google Workspaceエコシステムに統合したい人 プラグイン依存のないシンプルな構成を好む人 Bloggerが合わない人 読者コミュニティ形成を重視する人（はてな・noteが適切） プラグインで機能を拡張したい人（WordPressが適切） GUIだけでカスタマイズを完結させたい人 --- まとめ Bloggerは「枯れたプラットフォーム」だ。しかしそれは欠点ではなく、仕様が安定していて予測可能であることを意味する。XMLの学習コストを払い切れば、コストゼロで自由度の高いブログ基盤として十分機能する。 WordPressのセルフホストと比べると、カスタマイズの自由度は同等でありながら、サーバー管理・セキュリティ対応・維持費という三つの負担がまるごとなくなる。 「日本語情報が少ない」という欠点すら、英語ドキュメントとソースコードを読む習慣があるエンジニアにとっては差別化のチャンスになる。コストを抑えつつ技術的に攻めたい個人エンジニアにとって、Bloggerは2026年現在も十分に有力な選択肢だ。
β版リリースへのお祝い
Mintorさん、β版リリースおめでとうございます。 ここまで形にされたことを尊敬しています。 一点だけ たぶん。 ユーザーの声はすべてを真に受けなくて大丈夫です。 私を含めユーザーになってしまいます。 noteのクリエーターとクリエーターの関係が、 リリースした瞬間から「提供者とユーザー」になってしまいます。 初期は意見が散らばりやすいので、 課題と好みを分けると運営が安定します。 そういう私のお節介なところ 今後も気づいた点をお伝えしてしまうかもしれません。 なので、最終的にはご自身の方向性を大切にしてください。 応援しています。 この記事は数日後に消します。 むみま
svelteいいぞぉ
React全盛の個人開発で、あえてSvelteKitを選ぶ理由 個人開発のフレームワークといえば、いまは React（Next.js） が王道です。 それでも僕は、作ってきたプロダクトを全部 SvelteKit で作っています。 半デジ半農のスキマ時間で開発を続けるなかで、推せる理由は2つ。楽に始められることと、Cloudflareに載せればサーバー代がほぼ$0で済むことです。 ちなみに作ってきたのは、求人アグリゲーター（Chiinavi）、焙煎ログPWA（IriLog）、音声SNS（vovovo）、ブラウザゲーム（薪割りゲーム）。ジャンルはバラバラですが、土台はどれもSvelteKitです。 推しポイント1：とにかく楽に始められる Reactは「画面を描くライブラリ」で、ルーティングも状態管理もサーバー処理も自分で組み合わせます。SvelteKitはそれらを最初から内包した「全部入り」。npx sv create 一発で、書き始められる状態がそろいます。 書き味もHTMLに近く、CSSはコンポーネント単位でスコープが効く。そしてSvelte 5では状態が「ただの変数」で、let count = $state(0) と書いて count++ すれば画面が変わる。Reactの useState / useEffect と依存配列でハマる、あの個人開発あるあるが起きにくい。 書くコードが減ればバグも減る。朝30分でも、思い出しコストが低いからすぐ手が動きます。続けられることが最優先の個人開発で、これは効きます。 推しポイント2：Cloudflareで、サーバー代がほぼ$0 SvelteKitは公式の adapter-cloudflare でWorkers / Pagesにそのまま乗ります。そしてCloudflareの無料枠が、個人開発には過剰なくらい太い（2026年時点）。 Workers：1日10万リクエスト Pages：転送量が実質無制限 D1（SQLite DB）：5GB、1日あたり読み取り500万行・書き込み10万行 R2：10GB、しかも転送量(egress)課金ゼロ 僕のプロダクトはホスティングもDBもストレージも全部Cloudflareですが、月の請求は今のところ $0。Next.jsは事実上Vercel前提で、無料枠は商用制限があり規模で課金が跳ねやすい。SvelteKitは最初からCloudflareと素直に噛むぶん、財布にやさしいインフラとそのままつながります。 正直なトレードオフ（Reactが勝つところ） エコシステムはReactが圧倒的。使いたいUIライブラリが見つかりやすい。 AIアシスタントもReactの方が強い。Svelte 5のrunesは新しく、生成コードに古い書き方が混ざることがある。 日本語情報・求人もReactが多い。ただ公式ドキュメントの出来は良いです。 まとめ SvelteKitの価値は「速い・軽い」より、一人で、安く、作り続けられること。一発で始められて、Cloudflareに載せれば毎月$0。ジャンルの違う4プロダクトを同じ道具で回せている事実が、僕にとっての証拠です。Reactで消耗しているなら、次の一作の土台に試してみてください。
Blogger向けテンプレート「M-StruX」では配色設定サンプルを用意しています
M-StruXでは基本的なカラー設定をカスタムプロパティで管理しています。 手軽に配色を変更できるように M-StruX公式サイト で配色サンプル+カスタムプロパティのコードを公開しています。 現在 14パターン の配色を用意しており、随時追加していく予定です。 [Sage Denim] [Ash Rose]
Wanko-note（わんこのて）が進化！GIFアニメからも画像を一発抽出可能に！
GIFアニメから「最高の1コマ」を。 Wanko-noteに待望の新機能が追加！ note専用の画像最適化ツール「Wanko-note（わんこの手）」がさらに便利になりました。 今回のアップデートでは、「GIFフレーム抽出機能」を新たに搭載しました。 GIFアニメの「ここ！」を逃さない 動画の切り抜きやゲーム画面の録画など、アニメーションGIFの「一番いいシーン」をnoteの見出し画像にしたいと思ったことはありませんか？ 新しくなったWanko-noteなら、GIFファイルをドロップするだけで全フレームを瞬時に解析。専用のスライダーを動かすだけで、まるで動画編集ソフトのように自由自在にフレームを選択できます。 抽出からnoteサイズへの変換までをシームレスに フレームを選んだ後は、これまでの機能がそのまま使えます。 1.91:1の黄金比変換: 1920x1006の高解像度で出力。 精密なトリミング: 矢印ボタンと数値入力でミリ単位の調整が可能。 リッチなぼかし背景: 余白を自然なぼかし画像で埋めて、プロのような仕上がりに。 創作の「本質」に集中するために GIFのコマ送りをスクリーンショットで撮り、別のソフトで開き、手動でリサイズし、保存してアップロードする……。そんな面倒な工程はもう必要ありません。 「ドロップ ➔ 選ぶ ➔ コピー ➔ noteに貼り付け」 この驚くほど軽やかな体験を、ぜひ新しいWanko-noteで体験してください。
AIで動くおもちゃの作り方
※ かなえさんアドバイスで記事にしました。 AIでコードは書けるようになりましたが、その先に何をすればよいかがわからない人がいます。 なので、AIで制御できる何かを作ろうと思いましたが、大体高いし、なんか愛情が持てない。 おもちゃなら安いし、これをコントロール出来たら楽しいかと思って、「のんきちゃん」という犬のおもちゃと 有線ラジコンキットとスマホを組み合わせたものを作りました。 これをイベントで展示したら「これ、どうやってつくるんですか？」と何人かに聞かれてそこで「ああ、何かを動かしたい人は私以外にもいる！」ということがわかりました。 そこでこの作り方を教えるワークショップのためのドキュメントを作成中です。 実際のワークショップもやるつもりなので興味がある方は連絡いただければ、次回開催の予定などをお知らせします。 掲載しているURLにはクローラーよけのパスワードをかけているので、ご覧になりたい方はXでDMをいただければ個別にお知らせします。
Mintor開設！初回からStripe（スプライト）初期設定の「罠」に詰まった話
みなさん、こんにちは。 Mintorのβ版、開設おめでとうございます！ 開発者同士をつなぐ新しいプラットフォームということで、これから楽しみに活用していきたいと思います。 普段はnoteをメインに執筆しているのですが、今回はMintorの初回記事として、さっそく私が「初期設定（決済連携）で派手に詰まったポイント」を共有します。 これから登録する新人さんや、同じように困っている方の参考になれば幸いです。 何に詰まったのか？：Stripe（スプライト）の連携問題 Mintorの初期設定を進める中で、決済まわりの設定として「Stripe（スプライト）」の連携を求められます。 実は、私はすでにStripeの既存アカウント（ID）を持っています。 そのため、「既存アカウントをサクッと紐付けたいだけ」だったのですが、ここで迷子になってしまいました。 迷子になった3つの理由 全体像（フロー）が見えない：次に何が起こるのかのロードマップが見えない。 ドキュメントが見つからない：ヘルプや仕様が書かれたページがパッと見つからない。 「次へ」を押すと新規取得画面っぽいフェーズになる：既存ユーザー用のログイン導線が見当たらず、「次へ」「次へ」と進む一本道しか用意されていないように見える。 既存アカウントを持っている人のための「直接設定画面」や「既存アカウントでログイン」というボタンが手前にないため、「このまま新規作成のフローに進んでいいのだろうか…？」と手が止まってしまっている状態です。 開発者プラットフォームにこの「詰まり」を投げる理由 UI/UXの観点から見ても、最初のオンボーディング（登録導線）でユーザーが迷子になるのはよくあることです。私自身がまさに今リアルタイムで詰まっているので、ここを通過した先輩エンジニアの方や、運営の方に届くといいなと思い、あえて初回の記事としてこの「困りごと」を公開してみました。 もし、「そこは『次へ』で進んだ後に、Stripe側で既存ログインできるよ！」とか「ここにドキュメントあるよ！」という情報をご存知の方がいれば、ぜひコメントなどで教えていただけると助かります！ これからMintorを始めるみなさん、どうぞよろしくお願いします。
Stripe決済の練習用プラグインを体験してみる
例えば、何かを開発したくなるとき。 私なら一番不安がある部分に焦点をあてます。 チャンクダウンできないものか？とひたすら壁打ちします。 つまり、小さなテーマを探しては、バラバラに分解します。 そして、もっとも「できそうもない」部分を プロトタイプを作って！ とLLMにやってもらいます。 そんなとき、「Stripe決済の練習用プラグインを体験してみる」 これは効き目があり過ぎます。 WordPressのプラグインは、中級者の技術が必要です。 でも、いまならCopilotがあります。 私はLLMが無い時代からやってましたので中身も解ります。 相当丁寧にやってくれます。 どんな言語でも、OKなので「動くやつ」と頼むのです。 WordPressの場合は、PHPです。ちょっとだけ敷居があります。 もっと、簡単なやつかでも、OKです。 大体がPythonでやれます。 まとめ どんな言語、どんなデータベース。 そんな追求は不要です。 なんなら、全部Scratchで作れます。
親子で楽しむ絵合わせゲーム「ピクマ α版」リリースしました！
はじめまして。 ジョブホッパー宮崎と申します。 この度、初めての個人Webサービスを開発してα版をリリースしました。 リリースしたα版の「ピクマ」というサービスについてざっくりと内容をまとめた記事を書きましたので、もしよろしければご覧いただけますと嬉しいです。 ▼記事詳細は下記URL https://note.com/jhpw/n/n045707eb4e17 引き続き、よろしくお願い致します。
Reactに疲れたあなたへ。HTMX × FastAPIなら個人開発はもっと楽しくなる
Reactに疲れたあなたへ。HTMX × FastAPIなら個人開発はもっと楽しくなる 「個人開発でサービスを作りたいのに、フロントエンドとバックエンドの連携で心が折れた」 「ローカルでは動くのに、デプロイの設定が複雑すぎて本番公開できない」 もしあなたが今、ReactやNext.jsの複雑さに疲弊しているなら、HTMXとFastAPIという選択肢が、その悩みを解決する特効薬になるかもしれません。 今回は、なぜこの組み合わせが「個人開発における最強の解」なのか、その理由を解説します。 なぜReact（SPA）開発は「沼」なのか？ Reactでの開発が難しい最大の理由は、「実質2つのアプリを作る必要があるから」です。 フロントエンド（JS）とバックエンド（API）は完全に別物。それぞれで状態管理を行い、JSONで通信し、型定義を合わせる作業は、一人でやるにはあまりに負荷が高いのです。「APIの仕様を変えたら画面が真っ白になった」という経験は、誰にでもあるはずです。 HTMX × FastAPI という「原点回帰」 HTMXとFastAPIの組み合わせは、この複雑さを根底から覆します。アプローチは極めてシンプルです。 「サーバー（FastAPI）が完成品のHTMLを返し、ブラウザ（HTMX）はそれを表示するだけ」 JSONをこねくり回す必要も、複雑なJavaScriptの状態管理も必要ありません。HTMLの属にhx-postと書くだけで、モダンな非同期通信が実現できます。 メリット①：圧倒的な「エラーの少なさ」 このスタックの最大の利点は、開発がPython（サーバーサイド）だけで完結することです。 脳の切り替え不要: 「今はJS、次はPython」という頭の切り替えがなくなります。バリデーションもDB操作も、全て使い慣れたPythonファイル内で行えます。 通信エラーの激減: サーバーから返ってくるのは「HTMLそのもの」です。JSONのパースミスや、フロントとバックの型の不一致によるバグは物理的に発生しません。 メリット②：デプロイの悩みから解放 初心者が最も挫折する「デプロイ」も、驚くほど簡単になります。 React構成では、フロントとバックを別の場所にデプロイし、CORS（ドメイン間の通信許可）の設定や認証トークンの管理に頭を悩ませる必要があります。 しかし、HTMX × FastAPIなら、FastAPIのサーバーを1つ立ち上げるだけです。 ビルド不要: npm run buildで謎のエラーが出る恐怖とは無縁です。 CORS設定不要: HTMLもAPIも同じサーバーから配信されるため、複雑なセキュリティ設定に悩む必要がありません。 PaaS連携も一瞬: RenderやFly.ioなどに、Pythonコードを置くだけで本番環境が完成します。 実装スピードの違い 例えば「Todoリストへの追加機能」を作る場合： React: API作成、fetch処理の実装、Loading/Error状態の管理、再レンダリング制御…と多くの手順が必要です。 HTMX: PythonでDBに保存してHTML（<li>タグ）を返す処理を書き、HTML側にhx-postと書く。これだけで完了です。JavaScriptは0行です。 結論：まずは「完成」させよう 個人開発で最も大切なのは、技術的な高尚さではなく、「サービスを完成させて世に出すこと」です。 環境構築やエラー解決に時間を吸い取られ、アイデアを形にできないまま終わるのはあまりに勿体無い。Pythonが書けるなら、まずはFastAPIとHTMXを試してみてください。そのシンプルさと「爆速で動くモノができる」快感に、きっと驚くはずです。