1. はじめに：年末年始、Google AIを契約し、念願の個人開発のはじめの一歩を歩む
2025年末の決意
2025年の締めくくりに、私は一つの決意をしました。「見る側」から「作る側」へ。
Google AI（Gemini）のProプランを契約し、年末年始の休暇を利用して、必ず1つのプロダクトを完遂・リリースさせることを目標に掲げました。
テーマ選定：シンプルかつ「実験場」として最適なものを
最初の一歩として選んだのは、あえて規模を抑えた 「西暦・和暦の相互変換ツール」 です。
しかし、ただのツールではありません。Geminiと徹底的に壁打ちを行い、以下の3点を軸に据えました。
- 実用性： 年末年始の「年号」を意識するタイミングに合わせた需要の獲得
- 多言語展開： 日本独自の和暦を海外へどう伝えるか、i18nの実験
- SEOの実験場： シンプルなツール系サイトでどこまで検索上位を狙えるかの検証
こうして誕生したのが、爆速年号変換サービス 『Nengo Master』 です。
2. 技術スタック：Hono × Cloudflare Workers という最適解
なぜHonoか
Cloudflareのエッジランタイムで動かすことを前提に調査した結果、Honoにたどり着きました。
- コールドスタート実質0s： エッジで動作する軽量さ
- 圧倒的な開発体験： TypeScriptとの親和性が極めて高く、型安全な開発がノンストレス
- Middlewareの豊富さ： 今回のようなシンプルなツールでも、拡張性を維持したまま実装できる
エッジランタイムとは？
ユーザーに物理的に近いCDNノード（エッジサーバー）でコードを実行する、超高速・軽量なサーバーレス実行環境
Cloudflare Workers の破壊力
個人開発者にとって、Cloudflare Workersはまさに「聖杯」でした。
- コストパフォーマンス： 寛大な無料枠内で運用が可能
- グローバルなレスポンス： 世界中のエッジから数ミリ秒でレスポンスを返すパフォーマンス
- デプロイの速さ： wrangler deploy 一発、あるいはGitHub連携でPRをマージしたら、数秒後には世界中に公開されるスピード感と感動的な開発体験
DBを使わない（計算ロジックのみで完結させる）設計にすることで、インフラの複雑さを排除し、文字通り「爆速」なユーザー体験を追求しました。
SSR（Server Side Rendering）の採用：保守性とスピードの両立
今回のプロジェクトで技術的にこだわったのが、「あえてSSG（静的サイト生成）を避け、SSRを選択した」 点です。
ビルドの壁を突破：
西暦 × 和暦 × 多言語展開を掛け合わせると、生成すべきページ数は膨大になります。SSGではビルド時間の増大がボトルネックになりますが、SSRを採用することで、コード変更からデプロイ完了までを「数秒」で終わらせる俊敏性を手に入れました。
エッジでの動的生成：
Cloudflare Workersの計算資源を活用し、リクエストごとにエッジでHTMLを生成。SSGと遜色ない表示速度を維持しつつ、動的なコンテンツ更新にも強い設計にしています。
戦略的なSEO対策：
「動的なら検索に弱いのでは？」という懸念は、緻密に構成したサイトマップ（sitemap.xml） で解決。全ページを検索エンジンに正しくインデックスさせることで、ニッチな検索ワードも拾い上げる「ロングテールSEO」の基盤を構築しました。
3. 「引き算」の設計：D1を捨てて定数ハードコーディングへ
オーバーエンジニアリングへの戒め
「とりあえずDB」という思考へのアンチテーゼです。
当初は、Cloudflare D1（SQLite）を用いて西暦・和暦の変換データや年号にまつわる情報を管理するアーキテクチャで実装を進めていました。しかし、データ構造を冷静に精査した結果、すべて合わせても「1テーブルに余裕で収まる静的データのボリューム」であることに気づきます。
もしこれが技術力アピールを目的とした「ポートフォリオ」であれば、モダンなDBを組み合わせるのも一つの正解でしょう。しかし、今回作っているのは「実用的で最速なプロダクト」です。ユーザーへのメリットに直結しないDBの利用はオーバーエンジニアリングであると判断し、DBを完全に廃止して「定数ファイルへのハードコーディング」へと大きく舵を切りました。
かつては「手打ちの負担が大きい」と避けられがちだったハードコーディングですが、生成AIを活用すればデータ作成の労力は一瞬です。AIの力によって、この手法のコストは限りなくゼロになりました。
パフォーマンスの極致
この「引き算の決断」が、圧倒的なパフォーマンスを生み出します。
数十年分、数百行に及ぶ年号データとコラム（トリビア）をTypeScriptの定数ファイルとしてメモリ上に保持することで、DB接続にかかるネットワークのオーバーヘッドすら完全に排除しました。
- I/O待ち時間ゼロ：外部データベースへのアクセスが一切発生せず、純粋な計算処理のみで爆速のレスポンスを実現
- 強固な型安全： 静的データそのものがTypeScriptの恩恵を受け、予期せぬ実行時エラーを未然に防止
- Gitでの一元管理： アプリケーションのロジックとデータの変更履歴を、同じリポジトリ内でシームレスに追跡可能
「最新の技術を何を使うか」ではなく「何を捨てるか」。この引き算の選択こそが、スピードと保守性を両立させる、個人開発における「正解」の一つの形だと確信しています。
4. AIへの全面委任：コラム生成とデータ構造化の自動化
付加価値の創出：単なる「便利ツール」で終わらせない
年号変換ツールが抱える最大の課題、それは「直帰率の高さ」です。ユーザーは「1995年は平成何年？」という疑問が解決した瞬間に離脱してしまいます。
この課題をクリアするため、各変換結果のページに「その年の歴史的な出来事」や「豆知識」を載せるアプローチをとりました。結果として、単なる変換ツールに「読み物」としての付加価値が加わり、ユーザーの滞在時間を自然に延ばすことに成功しています。
コストゼロのコンテンツ制作と「CMSレス」な設計
この付加価値を生み出すための裏側こそ、AIの真骨頂です。
数十年にわたる歴史的出来事の調査から執筆までを人間が行えば、膨大な時間を奪われます。しかし、Geminiに適切なプロンプトを与え、明治から令和までの各年のトリビアを「構造化データ（JSON形式のTS定数）」として一気に生成させることで、この作業はわずか数分で完結しました。
さらに、WordPressなどの「CMS」を構築する手間も完全に排除しました。AIに直接HTMLのマークアップごと生成させ、それをそのまま定数として組み込むことで、1ページまるごとを即座に実装する圧倒的なスピード感を実現しています。人間の作業は、AIが出力したデータをコピペするだけです。
5. SEO戦略と多言語展開：ニッチな需要を確実にとらえる設計
ロングテールを刈り取るURL設計
SEOの基本であり極意でもある「URL設計」。今回は /en/year/2025 のような、言語プリフィックスと年号を組み合わせたシンプルな階層構造を採用しました。これにより、検索エンジンがサイトの構造を把握しやすくなります。
「1ページ1キーワード」の徹底
「2025年 西暦 和暦」といった日本語の検索はもちろん、「Year 2025 Japanese Era」のような英語での検索流入も網羅して狙います。SSRのダイナミックルーティングの強みを活かし、各年号・各言語ごとに独立したページを生成することで、細かな検索ニーズ（ロングテール）を確実に取りこぼさない設計にしました。
サイトマップによる確実なインデックス
大量のページを生成しても、検索エンジンに認識されなければ意味がありません。そこで、生成される全ページを網羅した sitemap.xml を出力する仕組みを構築。クローラーを適切に誘導し、漏れなくインデックスさせる工夫を施しています。
在日外国人へのアプローチとターゲット拡大
なぜ「多言語展開」にこだわったのか？それは、役所の手続きや書類記入などで「西暦と和暦の変換」に直面し、困っている在日外国人の方々が一定数いると考えたからです。単なる開発の興味（i18nの実装）にとどまらず、実際の課題解決にフォーカスすることで、サービスのターゲット層を大きく広げることができました。
6. マネタイズを見据えた「仕上げ」の12日間と、得られた大きな教訓
「動くツール」から「価値あるサイト」への昇華
コアとなる変換機能が完成したのは、言わばスタートラインに過ぎませんでした。次なるステップとして、Google AdSenseの審査通過によるマネタイズを見据え、ここから約12日間は「サイトとしての品質向上」に注力しました。
「オリジナルコンテンツ」の拡充：
AdSenseが強く求める「サイト独自の価値」を提示するため、AIを活用し、単なる変換結果だけでなくその年のコラムや歴史的背景などの「読み物コンテンツ」を拡充しました。
信頼性を担保する基盤作り：
プライバシーポリシーの設置や、問い合わせフォームの的確な整備。たとえ個人開発であっても、一つの「事業」としてユーザーに安心感を与え、誠実な運営をしていることを見せるための細部にこだわりました。
立ちはだかった壁と、本質的な気づき
しかし結論から言うと、今回のAdSense審査は不合格となり、一旦導入は断念することにしました。
昨今のAdSense審査のハードルが非常に高くなっていることを肌で感じると同時に、大きな教訓を得ました。それは「審査に通すためのサイト作り」に固執するのではなく、「まずはユーザーにとって本当に高い価値を生み出せるプロダクト作りに集中すべきである」 ということです。
この気づきを得られただけでも、この12日間には大きな意味がありました。決して諦めたわけではなく、まずは純粋なプロダクトの価値向上とブラッシュアップに集中し、時期を見て必ず再チャレンジするつもりです。
7. おわりに：AI時代の個人開発は「判断」の速さで決まる
爆速で駆け抜けた約3週間
思い立ったが吉日。2025年12月28日の初コミットから始まり、正月休みをフル活用して2026年1月7日にはCloudflareへのデプロイ（動く状態）を完遂しました。その後、AdSense審査への挑戦などの試行錯誤を経て、1月19日には自身の個人開発ブランドとなるドメイン「solooo.dev」を取得し、正式版として世に送り出すことができました。
「コーディング」から「ディレクション」の時代へ
今回、AI（Gemini）をフル活用してプロダクトを作り上げて痛感したのは、「技術的な実装スピードは、もはやエンジニアの差別化要因にはならない」 という現実です。
AIの進化により、人間がガリガリとコードを書く時間は限りなくゼロに近づいています。これからの開発者に求められるのは、プログラミング言語の文法を暗記することではなく、AIを効率的に操り、意図したコードを出力させる「ディレクション能力」にシフトしていくのだと肌で感じました。
個人開発者の「生存戦略」
実装のハードルが劇的に下がった今、私たち個人開発者の成否を分けるのは、以下の「戦略的判断」に尽きる気がしています。
- 何を作るか： ニッチでも確実な需要（年末年始の年号など）を見極める力
- 何を削るか： オーバーエンジニアリング（不必要なDBなど）を避け、引き算する勇気
- どう届けるか： 良いツールで終わらせず、市場（SEO・多言語展開）へ的確にアプローチする設計
『Nengo Master』の開発は、私にとってこの戦略を実践する最高の「はじめの一歩」となりました。
この記事が、これから個人開発を始めようとしている方、あるいはAIを活用した新しい開発フローに挑戦しようとしている方にとって、少しでも背中を押すきっかけになれば嬉しいです。
最後まで読んでいただき、ありがとうございました！
誰しもが、たまに使う時が来ると思うのでぜひブックマークしていってください
個人開発者として活動中の方はぜひフォローしてください。（フォローバックします！）