個人開発日誌 on モリサキブログ

Hugo移行後のデザイン調整地獄｜CSS1400行・Figma導入・スマホ対応の全記録

Wed, 08 Apr 2026 00:00:00 +0000

前回の記事では、WordPressからHugoへの移行を2日で完了させた話を書いた。

WordPressからHugoに移行した全記録｜90記事を2日で移行した方法と想定外の落とし穴

WordPressからHugoへの移行を実際にやってみた全記録。テーマ選定、デザインカスタマイズ、90記事の自動変換、画像移行、SEO対策まで。Claude Codeと二人三脚で進めた移行作業のリアルな記録です。

morisakiblog.com

90記事のMarkdown変換、画像ダウンロード、URL一致確認、GitHub Pagesへのデプロイ。技術的な移行作業は確かに2日で終わった。

だが、本当の地獄はここからだった。

テーマのCSSカスタマイズが終わらない

Hugoのテーマ「Mainroad」を選んだ。シンプルで2カラム対応、ブログ向きの構成。だがデフォルトのデザインは正直そっけない。WordPress時代に使っていたCocoonの見た目に慣れていた自分にとって、「なんか違う」の連続だった。

色を変える。余白を調整する。カードのデザインを変える。ヘッダーを全幅にする。フッターにリンクを並べる。1つ直すと別の場所が気になる。custom.cssに1行追加するたびに、「あ、ここも直さなきゃ」が発生する。

最終的にcustom.cssは1400行を超えた。

テーマのclearfixが-webkit-line-clampを殺す

一番ハマったのがこれ。リンクカードの説明文を3行で切って三点リーダー（…）を表示したかった。CSSの-webkit-line-clampを使えば簡単なはず。

ところが何をやっても効かない。!importantをつけても、セレクタの詳細度を上げても、インラインスタイルで直接指定しても。DevToolsで確認するとdisplay: -webkit-boxを指定しているのに、Computed Styleではflow-rootになっている。

原因を探るのに丸1日かかった。結論から言うと、Chromeが-webkit-boxを内部的にflow-rootとして報告しているだけで、実は動いていた。

DevToolsのConsoleで新しいdiv要素を作ってdisplay: -webkit-boxを設定し、getComputedStyleで確認してもflow-rootが返ってくる。clearfixとは無関係だった。

つまり「動いてないと思い込んで別の方法（max-height）に変えた」のが間違いで、最初から動いていた。CSSデバッグの教訓：推測でCSSを書くと沼る。DevToolsで実測値を見てからピンポイントで直す。

テーマを使う意味とは何か

custom.cssが1400行。テンプレートの上書きファイルも10個以上。ここまでカスタマイズすると「テーマ使ってる意味ある？」という疑問が湧く。

結論としては、まだある。テーマが担ってくれている部分:

カテゴリ・タグ一覧ページの生成
ページネーション
ハンバーガーメニューのJS
OGP・meta周りのテンプレート
レスポンシブの基本設計
CSSのベーススタイル（フォント、テーブル、コードブロック等）

これを全部自分で書くとなると相当な量になる。テーマの価値は「HTML構造とJSの土台を自分で書かなくていい」こと。見た目はCSSでいくらでも変えられる。

Figma導入で「なんとなくCSS調整」から脱却

CSSが終わらない根本原因に気づいた。デザインのゴールがないのだ。

「なんか違う」→「ここを直そう」→「あ、こっちも気になる」の無限ループ。ゴールがないからいつまでも終わらない。

そこでFigmaを導入した。PC・タブレット・スマホの3ブレイクポイントで完成形のデザインを先に作る。コンポーネント化してバリアント（device=PC/Mobile）で管理する。テキストスタイルでフォントサイズを一元管理する。

Figmaで決めてからCSSに落とす。この流れに変えたら、CSSの調整が驚くほど速くなった。「この要素は何px？」が明確だから迷わない。

FigmaもClaude Codeに作らせた

「わざわざブログのデザインにFigmaを使うのか」と思われそうだが、自分でFigmaをポチポチ操作したわけではない。

FigmaのMCPが編集に対応したので、Claude Codeに元サイトのURLを渡して「このデザインをFigmaに起こして」と指示した。各レスポンシブのページデザインが自動で生成される。そこからプロンプトで「ここの余白を24pxに」「この文字を15pxに」と微調整を繰り返した。

コンポーネント化、バリアント作成、テキストスタイル登録もClaude Code経由。Figmaの操作を覚える必要がなかった。

Figmaの達人でも何でもない。Claude Codeが達人なだけだ。

Figmaデザインファイルを公開します

今回作ったFigmaのデザインファイルを公開する。Hugo + Mainroadテーマのカスタマイズを考えている人の参考になれば。

Figmaデザインファイルはこちら

スマホ表示の改善が一番効果があった

デザイン調整の中で、最もインパクトが大きかったのがスマホ表示の改善だ。

横並びカード → 縦型カードで劇的に見やすく

最初のスマホ表示は、PCと同じ横並びカード（アイキャッチ左・テキスト右）を縮小しただけだった。85×48pxの小さいサムネイルに、11pxの文字。読めなくはないが、何の記事かパッと見でわかりにくい。

Figmaでスマホ専用の縦型カードをデザインした。アイキャッチ画像が上部に大きく表示され、その下にタイトル。これだけで印象が全然違う。

文字サイズ13px → 15pxで読みやすさが激変

最初はFigmaのデザインに忠実に13pxにしていた。だが実機で見ると小さすぎる。h2が16px、h3が14pxだと本文との差がほとんどない。

最終的にh3と本文を同じ15pxにした。見出しは装飾（背景色や左ボーダー）で十分区別できるので、サイズで差をつける必要がなかった。たった2pxの違いだが、スマホでの読みやすさが劇的に変わった。

ハンバーガーメニューをヘッダー画像にオーバーレイ

最初はカテゴリメニューをスマホでもそのまま折り返し表示していた。5カテゴリ程度なら収まるが、ヘッダーの下に別のバーとして領域を取るのがスマートじゃない。

Figmaでデザインした通り、ハンバーガーメニューをヘッダー画像の右上にオーバーレイ配置した。HTMLの構造上、メニューはヘッダー画像の外にあったので、header-wrapperで包んでposition: absoluteで重ねる形にした。

前後ナビをスマホでは非表示に

「前の投稿」「次の投稿」のナビゲーション。一般的にクリック率は1-3%と言われている。PCなら記事の最下部にあっても邪魔にならないが、スマホだとサイドバーの前に挟まって導線が切れる。関連記事があれば十分なので、タブレット・スマホでは非表示にした。

ロゴ画像をテキスト+SVGフィルターに置き換えた

ヘッダーのブログ名は、以前はネットのロゴ作成サイトで作った画像を使っていた。だが画像だとサイズ変更のたびに作り直しが必要で、レスポンシブ対応が面倒。

テキスト+CSSで再現できないか試した。

CSSのtext-shadowでは角がきれいに縁取りできない

最初はtext-shadowで4方向に影を重ねて縁取りを再現しようとした。だが文字の角や曲線部分に隙間ができる。-webkit-text-strokeは文字の内側にも線が入るので白が痩せる。

WordPressからHugoに移行した全記録｜90記事を2日で移行した方法と想定外の落とし穴

Wed, 25 Mar 2026 00:00:00 +0000

この記事は以下の記事の続編です。前回はWordPressでの運用の限界と、次の技術スタックとしてHugoを選んだ経緯を書きました。今回はその実際の移行作業の全記録です。

Claude CodeでWordPressブログを運用してわかった限界と、次に選ぶ技術スタック

このブログはWordPressで運営しています。そしてここ数週間、Claude Code（Anthropicが提供するAIコーディングツール）を使って、記事の作成・編集・SEO設定・品質監査まで、ブログ運用のほぼ全てをAIと一緒にやってきま...

morisakiblog.com

なぜWordPressをやめたのか

結論から言うと、WordPressの管理画面を一切開かなくなったからだ。

Claude Codeで記事を書き、REST APIで投稿し、SEO設定もAPIで済ませる。管理画面にログインする理由がない。なのにWordPressは毎月サーバー代を請求してくる。プラグインの更新通知が来る。セキュリティパッチを当てろと言ってくる。

使わない管理画面のために、管理コストだけ払っている状態。これが移行を決めた最大の理由だ。

テーマ選び：4つ試して全部微妙だった話

Hugoのテーマ選びは正直かなり苦労した。WordPressのCocoonが「インストールしたらそのまま使える」レベルだったのに対して、Hugoのテーマは「カスタマイズのベースにするもの」という思想の違いがある。

実際に試したテーマ:

Stack — 左サイドバーのモダンなデザイン。悪くないが、サイドバーがスマホで完全に消える仕様がCocoonと違いすぎた
Blowfish — 評判が良かったが、サイドバーがそもそもない。1カラムのミニマルデザインで、ブログとしてはちょっと物足りない
Congo — インストールしかけたが、Blowfishと似た方向性だったので途中でやめた
Mainroad — 最終的にこれに落ち着いた。Cocoonに近い2カラム構成で、サイドバーがスマホで下に回る伝統的なブログレイアウト

結局「モダンなデザイン」と「ブログとしての使いやすさ」は別物だった。見た目がおしゃれでも、読者が記事を読む導線が悪ければ意味がない。

CSSカスタマイズ：ここが一番時間かかった

テーマを選んだ後が本番だった。Mainroadのデフォルトデザインからcocoonの見た目に近づけるために、custom.cssが1100行を超えた。

やったこと:

ヘッダー画像の全幅表示
ナビバーのデザイン変更（紺背景→白背景+ホバーエフェクト）
記事カードのレイアウト（アイキャッチ+タイトル+説明文+メタ情報）
サイドバーのウィジェットデザイン
テーブルのスタイリング（Cocoon準拠の縞模様）
ページネーションの丸ボタン化
目次のデザイン
h2/h3の見出しスタイル
レスポンシブ対応

一つ一つは大した作業じゃないが、「ちょっと違う」の積み重ねが膨大だった。色が微妙に違う、余白が多い、ホバーが効かない、スマホで崩れる。毎回CSSを書いて、リロードして、「あ、ここも直さなきゃ」の繰り返し。

ただ、Hugoの良いところはテーマのファイルを直接いじらないこと。layouts/ に同名ファイルを置けば上書きされるし、CSSも custom.css で追記するだけ。テーマのアップデートに影響されない設計は素直に良いと思った。

90記事の移行：スクリプト一発…とはいかなかった

WordPress REST APIから全記事を取得して、HTMLをMarkdownに変換するスクリプトを書いた。これ自体は30分で完成。実行も1分で90記事が変換された。

問題はここからだった。

CocoonのSEOメタデータが取れない

CocoonのSEOタイトルとメタディスクリプションは、REST APIのmetaフィールドに露出しない。Cocoon独自のカスタムフィールドで、UIの $_POST 経由でしか保存されない設計だった。

結局、全90ページをスクレイピングしてHTMLの <title> タグと og:description から取得した。REST APIがあるのにスクレイピングするという本末転倒な解決策。

テーブルが全滅

WordPressのHTMLテーブルをMarkdownに変換する際、ヘッダー行の区切り（| --- | --- |）が正しく生成されないケースが大量に発生。28記事のテーブルが壊れていた。

Markdownのテーブルは厳密で、ヘッダーの次の行に必ず --- が必要。HTMLからの自動変換では列数の検出やネストの処理が不完全で、手動修正が必要だった。

DALL·Eファイル名のエンコーディング問題

WordPressの画像ファイル名に DALL·E の中黒（·）が含まれているものが10件あり、Pythonの urllib がASCIIエンコードエラーで落ちた。URLエンコーディングを正しく処理するように修正して解決。

気力ゼロから1ヶ月でApp Storeリリース｜AI×個人開発の全記録

Mon, 23 Mar 2026 00:00:00 +0000

「個人開発やりたい。でも気力がない。」

これが正直な出発点だった。フリーランスエンジニアとして働く中で、会社の非効率なやり方、無駄な会議、気まぐれな要件変更、聞こえの良いだけのビジョンを掲げて、中身のない退屈な仕事。そういうものに飽きていた。もっと自分で責任を取って、自分で考えて、収益に天井がない代わりにリスクも大きい仕事がしたかった。

でも、いざ自分でアプリを作ろうとすると、やることが多すぎる。コーディングだけじゃない。デザイン、要件定義、インフラ構築、バックエンド実装。一つずつやれば形にできる自信はあったけど、それをやる気力がなかった。大きなことを言うくせに何もしない人間になりかけていた。

そんな時にAIが来た。Claude Code、Figma Make、Notion MCP。コーディングは一瞬で終わるし、自分で書くより速い。インフラやバックエンドの知識もAIに聞けばすぐ分かる。これなら気力のない自分でも、個人開発ができるかもしれない。

同時に懸念もあった。AIで簡単に作れるなら、他の人間も同じことができる。差別化できるのか？正直、AI開発はもう先行者たちが市場を取っていて、今から始めても手遅れだと思っていた。でもSNSを見ると、AIに対する文句記事がバズっている現状があった。「AIが書いたコードのレビューが大変」「リファクタリングさせられて迷惑」。こういう記事がバズるということは、まだまだAIに対する偏見や誤解が多い。今のうちに使いこなす側に回れば、先行者利益はまだ十分取れる。やるなら今しかないと思った。

この記事では、AIをフル活用して約1ヶ月でクイズSNSアプリ「QuizBuzz」をApp Storeにリリースするまでの全工程を振り返る。各フェーズの詳細は別記事で深掘りする予定なので、ここでは全体像と、理想と現実のギャップを正直に書く。

なぜクイズSNSアプリなのか

正直に言うと、大した理由はない。

以前Firebaseで作ったAndroidのクイズアプリがあったが、放置していたらストアからリジェクトされていた。じゃあそれをベースにAWSに載せ替えて、Figma Makeでデザインをちゃんと作り直せばいいだろう、という軽い動機だ。

俺にとって重要だったのは「何を作るか」ではなく「AIでどう作るか」だった。将来的には複数プロダクトをAIで回す予定で、そうしないと周りもAIで開発している以上、差別化できない。だからまずAIで開発を進めること自体に慣れる必要があった。アイデアにこだわるより、開発プロセスの確立が先だった。

技術選定：全部AIとの相性で決めた

バックエンド：Firebase → AWS

元々Firebase + Algoliaで開発していたが、インフラ管理が手動寄りで面倒だった。AWSならCDK（Cloud Development Kit）で完全にコード管理できるし、どうせAIが書くならコードベースの方がAIとの親和性が高い。詳しい経緯は以前の記事で書いている。

Firebase + Algoliaの限界：個人開発でAWS移行した2理由と体験談

Firebase + Algoliaの限界を実体験で解説！複雑検索の制約と運用コスト増でAWS RDS移行した2理由。個人開発の適材適所とハマりポイントも。

morisakiblog.com

ちなみにAWSに移行したらしたで地獄があった。

DynamoDBは地雷原だった｜Firebase→AWS移行の理想と現実

Firebase→AWS移行でDynamoDBを選んだ個人開発者の体験談。GSI変更は1回1デプロイ制約で10回デプロイ、FilterExpressionはlimit後に動く罠、シングルテーブル設計の落とし穴を正直に書きます。

morisakiblog.com

フロントエンド：Flutter

元のAndroidアプリがFlutterで開発されていて、クリーンアーキテクチャを採用していた。設計原則をAIに説明すればいい感じにコーディングしてくれそうだった。元モバイルエンジニアとして、Flutter自体の知識はあるから、AIとの協業がしやすいと判断した。

デザイン：Figma Make

デザインはそれなりに勉強したし、Figmaの使い方もある程度は分かる。でも頑張る気力が続かなかった。Figma MakeでAIがデザインを生成してくれると知って試したら、いい感じだった。デザインは完全にAIに任せようと決めた。

使ったAIツール一覧

Grok：最初の壁打ち。寝転がってスマホでアイデアを話しながら要件を詰めた
Claude（チャット）：Grokとの会話をまとめて要件定義書に整理
Notion MCP：Claude Codeから直接Notionに要件定義書を書かせた
Figma Make：UIデザインの生成
Claude Code：CDK実装、Flutter実装、テスト、CI構築

各フェーズの所要時間と感想

Phase 1：要件定義（AI壁打ち × Notion）— 約1〜2時間

正直、最初は「作る」と思っていなかった。寝転がりながらGrokに「こんなアプリ作ろうと思ってるんだけど」と話しかけて、遊びで要件を詰めていった。

でもこの「遊び」が想像以上に生産的だった。DBの設計をどうするか、AWSの認証はCognitoでいいのか、バックエンドはAppSyncかLambdaか、テーブル構造は、Web APIのリクエスト・レスポンスの形は、各機能のUIを文章にするとどうなるか。めちゃくちゃGrokと話し合った。

ある程度固まったらClaudeにGrokとの会話を渡してまとめさせ、Notion MCPで直接Notionに要件定義書を書かせた。最初はClaudeのチャットで管理していたが、「間違って削除したら怖いな」と思ってNotionに移行した。

結果、ざっくりとした全体の仕様は1〜2時間で固まった。細かい仕様はデザインやCDKの実装中に不備に気づくたびにアップデートしていった。

Phase 2：デザイン（Figma Make）— 生成2〜3時間、沼3〜4日

Figma Makeに要件定義書の各機能の説明文を貼り付けて、「Material Design 3で作って」と指示。ホーム画面から順にガンガン生成させた。ダークモードも対応させた。

DynamoDBは地雷原だった｜Firebase→AWS移行の理想と現実

Fri, 20 Mar 2026 00:00:00 +0000

以前、こんな記事を書きました。

Firebase + Algoliaの限界：個人開発でAWS移行した2理由と体験談

Firebase + Algoliaの限界を実体験で解説！複雑検索の制約と運用コスト増でAWS RDS移行した2理由。個人開発の適材適所とハマりポイントも。

morisakiblog.com

「Firebase + Algoliaは限界！AWSに移行すればCDKでインフラをコード管理できて快適！」と意気揚々と書いた人間です。

あれから実際にAWS（DynamoDB + CDK + AppSync）でクイズSNSアプリのバックエンドを開発してきました。その結果どうなったか。

DynamoDBは地雷原でした。

今回は、DynamoDBのシングルテーブル設計で実際にハマった罠と、「正直Firebaseで良かったんじゃないか」という気持ちが再浮上してきた話を正直に書きます。

NoSQLは「ポストRDB」だと思っていた

DynamoDBを選んだ時、僕はNoSQLをこう理解していました。

「RDBは堅牢だけど堅い。NoSQLはその堅牢さを柔軟性で和らげた、進化系のデータベースだ」と。

完全に間違っていました。

DynamoDBは確かに柔軟です。スキーマレスで、とりあえずデータを突っ込める。でも「開発しやすい土壌」がない。

ここで言う土壌とは、テーブル結合（JOIN）、複合クエリ、「WHEREで絞ってからLIMITする」みたいな当たり前の動作のことです。RDBなら何も考えずにできることが、DynamoDBでは「そもそもできない」か「やり方を根本から変える必要がある」。

RDBは厳しいけどレールがある。DynamoDBは自由だけど荒野。自由って聞こえはいいけど、道がないだけでした。

DynamoDB GSI変更の地獄

前の記事で「CDKでインデックスをコード管理できる！Firestoreみたいにコンソールで手動作成しなくていい！」って書きました。

それは事実です。コードで管理できます。ただし、デプロイが地獄です。

「1回のデプロイでGSI変更は1つだけ」制約

DynamoDBには「1回のUpdateTableでGSIの追加・削除は1つだけ」というサービスレベルの制約があります。追加1つと削除1つを同時にやることすらできません。

つまり、GSIを1つ作り替えるだけでこうなります。

新GSIを追加してデプロイ（1回目）
アプリ側のクエリを新GSIに切り替えてデプロイ
旧GSIを削除してデプロイ（2回目）

不要なGSIを3つ消したい時は？3回に分けてデプロイです。

実際に僕がやらかしたのは、PRを2つ同時にマージしてデプロイ失敗。コンフリクト解消のミスで削除したはずのGSIが復活。dev環境とprod環境でGSIの状態がズレる。結局、合計約10回のデプロイを実行して復旧しました。

対策：CIでGSI変更数をブロックする

この経験から、GitHub Actionsでcdk diffを実行して、GSIの追加・削除が2つ以上含まれていたらマージをブロックするCIの導入を予定しています。dev環境はローカルからcdk deployで復旧できるからまだいいけど、prod環境で同じ事故が起きたら目も当てられません。

DynamoDBを使うなら、「1回1GSI」を人間が覚えておくのではなく、仕組みで防ぐ必要があります。

Firestoreのインデックスにはこんな制約なかった

ここで思い出してほしいんですが、Firestoreの複合インデックスは個別に追加・削除できます。「1回に1つだけ」なんて制約はありません。単一フィールドインデックスに至っては自動作成です。

「Firestoreのインデックス管理が面倒でAWSに来たのに、DynamoDBのGSI管理の方がよっぽど地獄だった」という、見事なオチがつきました。

FilterExpressionとlimitの罠

App Storeの審査提出直後に発見したバグです。言語指定でフィードを取得すると、8件あるはずの投稿が2件しか表示されない。

原因：FilterExpressionはlimitの「後」に動く

DynamoDBのGSI（LanguageIndex）のパーティションキーがlanguageだけだったため、language="ja"で検索するとUSER・QUIZ・FEED・ROUNDなど全種類のレコードが返ってきます。シングルテーブル設計なので当然です。

FEEDだけ欲しいので、FilterExpressionでbegins_with(PK, "FEED#")を指定していました。ここに罠があります。

// DynamoDBの動作
limit: 20で20件取得 → その中にFEEDレコードが2件しかない → 結果2件

// RDB（SQL）なら当然こう
WHERE type = 'FEED' AND language = 'ja' LIMIT 20 → FEEDが20件返る

DynamoDBのFilterExpressionは、limitで取得した後にフィルタする。RDBのWHERE句とは根本的に動作が違います。

Claude CodeでWordPressブログを運用してわかった限界と、次に選ぶ技術スタック

Wed, 18 Mar 2026 00:00:00 +0000

このブログはWordPressで運営しています。そしてここ数週間、Claude Code（Anthropicが提供するAIコーディングツール）を使って、記事の作成・編集・SEO設定・品質監査まで、ブログ運用のほぼ全てをAIと一緒にやってきました。

結論から言うと、「できることは多い。でも限界もはっきり見えた」。

この記事では、Claude Code × WordPressで実際にやったこと、ぶつかった壁、そして次に専門ブログを立てるなら何を選ぶかを、全て体験ベースでお話しします。

Claude Code × WordPressでできたこと

WordPress REST APIを使えば、Claude Codeから記事の作成・編集・公開が直接できます。実際にやったことを挙げると：

記事のCRUD操作：新規作成、本文の編集、ステータス変更（下書き→公開）、カテゴリ・タグの変更まで全てAPIで完結
80記事の品質監査：全記事をAPIで取得して、文字数・構造・内容を分析。AdSense審査に不利になりそうな低品質記事を特定し、約10記事にnoindexを設定
SEOメタ情報の設定：CocoonテーマのカスタムフィールドにREST API経由でSEOタイトル・メタディスクリプションを書き込み
カテゴリの一括整理：「フリーランス」カテゴリを廃止して、該当記事を「ビジネス考察」に移行
GSC・GA4のデータ分析：検索パフォーマンスを確認しながら、タイトル変更やリライトの判断をAIと壁打ち

WordPress REST APIでの記事自動化について、詳しくはこちらの記事でも書いています。

Claude Code × WordPress REST APIで記事の投稿・編集を自動化してみた

Claude CodeからWordPress REST APIを使って記事の投稿・編集を自動化する方法を解説。Application Passwordsのセットアップ手順、公開記事の編集ワークフロー、SiteGuardとの相性問題、セキュリティ対策まで実体験ベースでまとめました。

morisakiblog.com

率直に言って、かなりのことができます。Claude Codeにブログの運用方針やルールをメモリファイルとして渡しておけば、文脈を理解した上で記事の執筆・編集をしてくれます。「この記事のSEOタイトル設定して」「この記事公開して」と言えば数秒で完了です。

GSC・GA4との連携についてはこちらも参考にどうぞ。

Claude Code × GSC × GA4でSEO改善｜「芽キーワード」発掘から記事リライトまでの全手順

Claude CodeにGSCとGA4のMCPを接続し、表示されているのにクリックされない「芽キーワード」を発掘。キーワードクラスタ分析から記事リライト、効果検証まで、AIとデータで回すSEO改善ワークフローの全手順を実データで解説します。

morisakiblog.com

Google Analyticsが使いづらい？Claude Code × MCPで全部解決した話

GA4のUIが使いづらい？Claude CodeにGA4・Search ConsoleのMCPサーバーを接続すれば、PVや検索キーワードを自然言語で取得できます。セットアップ手順と活用例を解説。

morisakiblog.com

ここが限界だった

しかし、使い込むほどに「WordPressとAIの相性の悪さ」が見えてきました。

CocoonのカスタムフィールドがAPIで完全制御できない

一番痛かったのがこれです。Cocoonテーマには「noindex設定」「SEOタイトル」「メタディスクリプション」などのカスタムフィールドがあります。REST APIから値を書き込むことはできるのですが、削除が効かない。

Firebase + Algoliaの限界：個人開発でAWS移行した2理由と体験談

Mon, 22 Sep 2025 00:00:00 +0000

クイズ共有アプリを個人開発してGoogle Playでリリースしている者です。最初はFirebase + Algoliaの組み合わせで快適に開発していましたが、機能を拡張していく中で「なんか辛いな…」と感じることが増えてきました。

今回は実際に感じた問題点と、AWS移行を決断した理由について、実体験を交えて書いてみます。

📱 対象アプリ

GitHub: share_quiz

最初は快適だったFirebase

個人開発を始めた当初、Firebaseは本当に素晴らしいサービスでした。

// 認証も簡単
await FirebaseAuth.instance.signInWithGoogle();

// データベースも直感的
await FirebaseFirestore.instance
 .collection('quiz')
 .add(quizData);

セットアップが簡単で、インフラを意識せずに開発に集中できる。個人開発者にとって理想的な環境でした。

特に以下の機能は本当に素晴らしく、開発初期は「Firebase最高！」と思っていました。

リアルタイム更新: 他のユーザーの投稿が即座に反映
簡単な認証: Google/Apple/メール認証が数行で実装
自動スケーリング: インフラ管理不要
豊富なSDK: Flutter/React/iOS/Android対応

// リアルタイムでデータが同期される
FirebaseFirestore.instance
 .collection('quiz')
 .snapshots()
 .listen((snapshot) {
 // 他のユーザーが投稿したクイズが即座に反映
 updateUI(snapshot.docs);
 });

このリアルタイム機能により、ユーザー同士のインタラクションが活発になり、アプリの魅力が大幅に向上しました。

問題1: Firestoreの限界に直面

アプリの機能を拡張していく中で、Firestoreの制約が徐々に見えてきました。

複雑な検索ができない

ユーザーから「タイトルに”歴史”を含み、難易度が中級以上で、作成日が1週間以内のクイズを検索したい」という要望が来ました。

// やりたいこと（SQLなら簡単）
SELECT * FROM quiz 
WHERE title LIKE '%歴史%' 
 AND difficulty >= 'intermediate'
 AND created_at >= DATE_SUB(NOW(), INTERVAL 1 WEEK);

// Firestoreでは...無理！
// 複数の不等号条件は使えない
// LIKE検索もできない

結果的に、複数のクエリに分割してアプリ側で結合する必要がありました。