Notes

実験開始：コードに触らない縛りプレイ 先日のサイトリニューアルに合わせて、ツール群を改めて構築し直している最中です。 元々は自作のツールたちでしたが、今回はあえてAIドリブンで再構築することにしました。理由は単純明快。「自分が用意したものより、UIが洗練されるから」です。 生成AIはClaude Codeを利用。そして、自分に課したルールはこれ： 生成されたコードは読むが、一切自分では手を加えない。プロンプトの指示のみで完成させる。 まさに縛りプレイです。果たしてどこまでいけるのか？ 第一印象：期待以上の洗練度 まず、UIについては期待以上でした。確かに洗練されます。 自分で作ったゴリゴリのユーティリティ系UIと比べると、Claude Codeが生成するインターフェースは明らかに今風で美しい。レスポンシブ対応も当たり前のように組み込まれているし、アクセシビリティへの配慮も見られます。 「おお、これは確かにすごいな」 初期の感動は確実にありました。 だんだん見えてくる「Claude感」 しかし、ツールを作れば作るほど、だんだん既視感が芽生えてきます。 どれも似たような「ガワ」になっていくのです。そして、なぜか青や紫のグラデーションっぽい雰囲気を好むようです。まあ、綺麗な色だから良いんですけどね。 この辺りは「Claude Codeで作った感」が思いっきり出てしまうので、見た目のアプローチはまだまだ改善の余地があるでしょう。 まるで、同じデザイナーがテンプレートを使い回しているような感覚です。 単機能ツールなら「ほぼ一撃」の威力 出来上がるものは大抵うまく動作するし、説明なども非常に的確。正直、アシスタントとしては超優秀です。 単機能のコンパクトなツールであれば、ほぼ一撃で期待値の90%くらいのものを上げてくるのではないでしょうか。本当に申し分ない。 「もう大抵のものはこれで良くね？」 そんな気持ちになります。これで満足いくものが完成すれば、それでOKでしょう。 しかし、こだわりの沼に足を踏み入れると… ただし、「さらに良くしたい」「機能を付けたい」「俺好みに味付けしたい」となると、話は全然変わってきます。 ここから先に行くとなると、覚悟を決めて改めてAIと向き合うことになります。 というか、まるで人を相手にしているのと変わらなくなるんですよね。 プロ vs プロの壁：伝える難しさ 思っていたことと違う時に、「こうして欲しい」ということを相手に伝えて、期待通りのアウトプットを出してもらうのは相当難しい。 自分が素人であれば、それほど精緻な良し悪しの判断はできないから、「すごいな〜」で終わります。 でも、なまじ分野に詳しかったり、こだわりが強くなっていくと、そうではなくなる。プロ vs プロになればなるほど、その溝、ギャップの大きさに気づくのです。 創造的な活動であればあるほど、それは顕著です。 建築家とAIの関係と同じかもしれない これは、建築、絵画や彫刻などのアート、音楽、文学、演劇、なんなら料理の世界などと、全く同じかもしれません。 一人でできていたものが、作り手が複数になった瞬間、正しく伝えないと形になっていかない瞬間が来るのです。 ゴールまで見えている力 そのプロセスの段取り力 AIとの一歩進んだ開発では、まさにここが試されます。 AIが全知全能の神様だったとしても、こちら側の伝える力が弱いと全く思い通りの結果が得られない。 人間のマネジメント業務との共通点 具体的な作法はさておき、所感としては人間相手に物事を伝えていくマネジメント業務と全く変わらない印象を強く抱きました。 相手の理解度を推測する 適切な粒度で情報を伝える フィードバックを受けて軌道修正する ゴールに向けて継続的にコミュニケーションを取る まさにプロジェクトマネジメントそのものです。 「仕事を奪われる」を超えた次元 AIによってプログラマーの仕事が奪われる、という話は、もはやそういう次元ではなくなってきています。 生成AIをマネジメントして成果を上げるには： もっと解像度を上げた理解が必要 先を見通す力が必要 明確なゴールをイメージする能力が必要 その精度の高さが良し悪しを決める つまり、より幅広い知識や経験が求められるという結論に至りました。 実戦データ：制作時間と難易度 実際の制作にかかった時間と体感難易度をまとめてみました。もちろん「一切コードに手を加えない縛り」はほぼ守っています。 難易度⭐️：ほぼ一撃の世界 Webフォント比較ツール 制作時間：約10分 指示回数：ほぼ1撃 難易度：⭐️ Favicon生成ツール 制作時間：約20分 指示回数：2〜3撃 難易度：⭐️ 画像変換ツール ...

AIへの素朴な疑問をぶつけてみた 生成AIの話題で持ちきりの昨今、「結局のところ、AIと人間は共存できるのか？」という疑問が頭を離れません。 世の中では「AIに仕事を奪われるのではないか」という不安に駆られる人も多いと思います。私自身は、AIツールを日々活用しながらその恩恵を実感していますが、確かにその辺りは実際どんなもんなのかな、せっかくなのでAIに直接意見を求めてみようと思いました。 そこで、ChatGPTに直球勝負で質問してみました。忖度なし、ガチ回答を求めて。 以下、その対話記録です。 第一ラウンド：職を失う可能性について 私: 生成AIの登場でプログラマーなど様々な業種が職を失う可能性を感じますが、実際のところどんな未来が予想されますか？忖度なく、ガチ回答お願いしまっす！！ ChatGPT: 了解しました。忖度ゼロで、現実的かつガチな視点からお答えします。 🔥結論：AIで「職を失う人」は確実に増える。ただし、淘汰されるのは"そのままで代替可能な人"だけ。 【1】なぜプログラマーは危ないと言われるのか？ 生成AI（ChatGPTやGitHub Copilotなど）の登場により、 コーディングの自動化 バグ修正・コード最適化の自動化 設計補助やテストの自動生成 ドキュメント作成まで代替可能 と、「指示に従って作るだけのエンジニア」の仕事はどんどん機械に置き換えられつつあります。 実際、単価の安い海外オフショア開発やジュニアレベルの業務は、AIの台頭で仕事の需要が下がり始めています。 【2】じゃあ全員ヤバいの？ → NO。生き残るのは"抽象化と思考ができる人"。 AIは"生成と模倣"は得意ですが、“意図の解釈"や"構造の発明"はまだまだ不得手。 これから求められるのは： 役割 必要スキル システムアーキテクト 要件を分解し、AIに命令できる能力 プロダクトマネージャ ユーザー価値を言語化し、AI＋人で実装可能な形に落とし込む力 テックリーダー AIではカバーできない品質・安全性・拡張性の担保力 AIプロンプトエンジニア 複雑な要求をAIに正しく伝え、出力を評価・修正できる能力 マルチスキルクリエイター 企画×設計×実装×表現まで横断できる人材 つまり、「自分の脳で考えて設計できる人間」はAIの力を使ってむしろ"生産力を100倍にできる存在"になります。 【3】予想される未来（2040年まで） 時期 状況 〜2030年 ジュニアレベルのコーディング職が大幅に減少。ミッドレベル以下はスキル再構築が必須。 2030年以降 「人×AI」の協働が当たり前に。プロンプト力・構成力が重要に。 2040年以降 一部の業種は完全自動化（経理、カスタマー対応、コーディング支援など） 創造と戦略、倫理判断ができる人に価値が集中。 【4】「逃げ切り」ではなく「進化」が唯一の生存戦略 「AIは補助だから」と安心してるとやられる 逆に「AIに置き換わるならチャンス」と捉えてスキルアップした人は跳ねる 💡 未来はAIに奪われるものではなく、AIを武器にできるかどうかで決まる ✅ まとめ 質問 回答 AIでプログラマーの仕事はなくなる？ 一部はなくなる。考えない人から消える。 何をすれば生き残れる？ 抽象化・設計・統合・表現のスキルを磨く。AIを使う側に回る。 どんな人が勝つ？ 「AI×人間」でシステムや価値を生み出せる"思考する人”。 生き残るには 「AIに使われる側」から「AIを使う側」に立場を変える こと。 そして「自分にしか作れない世界」を見つけることが、最高のリスクヘッジになります。 もっと具体的な分野や職種で分析したい場合は、その分野を教えてもらえれば深掘りしますよ。 第二ラウンド：新しい需要について この回答を受けて、ネガティブな側面だけでなく、新しく生まれる需要についても聞いてみました。 ...

生成AIツールの怒涛の進化 ChatGPTが登場した頃から、コード生成は「ちょいちょい利用」程度でした。 でも気がつけば、GitHub Copilot、Cline、Claude Codeと、開発者として期待している機能やサービスが次々と登場しています。まさに怒涛の勢いです。 しかも、それぞれが単なるコード補完を超えて、本格的な開発パートナーとして機能するレベルに到達している。 追いつけない現実 - 恩恵を受ける時間すら足りない 問題は、あまりに早い更新のため、恩恵を受けたいのにその時間すら足りなくなることです。 新しいツールが出たと思ったら、すぐに次のバージョンがリリースされる。機能を把握しようとしている間に、また新しい機能が追加される。 「これは便利そうだ、導入してみよう」と思った時には、もう次の波が来ている状態。まさに技術のインフレーションに追いつけない現実があります。 しかも、これはコード生成だけの話ではありません。画像生成AI（Midjourney、DALL-E、Stable Diffusion）、音楽生成AI（Suno、Udio）、動画生成AI（Runway、Pika Labs）…と、あらゆるクリエイティブ分野に波及している状況です。 開発者として「コード生成AIを使いこなそう」と思っていたら、今度は「画像も音楽も動画もAIで作れる時代だから、それも活用すべきかも」という新たな選択肢が次々と現れる。 どこかにフォーカスしないと完全に飲まれてしまうレベルの変化の嵐です。 特に個人開発者にとっては、新しいツールを試す時間と、実際にそれを使って開発する時間のバランスが大きな課題になっています。 仕事、家事、その他もろもろの日常をこなしながら、プライベートな時間を捻出して開発している身としては、好奇心がスパークし続けている状態で、常にあの懐かしいギラギラしている感覚が蘇ってきます。 「新しいAIツールが出た！」「これは試してみたい！」という興奮。まるで昔、新しいプログラミング言語やフレームワークに出会った時のような、あのワクワク感です。 でも現実問題、削れるものは睡眠時間くらいしかない。「今夜も夜更かしして新しいツールを触ってみよう」と思うものの、翌日のお肌に悪いのは明らか。 悩ましい選択ではあります。 生活に不可欠になった生成AI 生成AIについての話は尽きることはありませんが、もう昨今では無しでは生活できないようになってきています。特に開発者は。 コードの雛形生成 バグの原因特定 リファクタリングの提案 ドキュメント作成 設計の壁打ち相手 気がつくと、開発フローのあらゆる場面で生成AIが関わっています。 まるで「検索エンジンなしでは調べ物ができない」という状況になったのと同じように、生成AIなしでは開発が進まない状況になりつつあります。 BASIC・アセンブラ時代から見た天地の変化 私自身、BASICやアセンブラの頃からプログラミングやソフトウェア開発に勤しんできたし、幸いにもそれを仕事にして生業としてきました。 当時のプログラミング環境 昔のプログラミングといえば： エディタすらろくにない環境でのコーディング デバッガなんて贅沢品 ちょっとしたミスでシステム全体がハング リファレンスは紙の書籍のみ コピペすらできない（物理的にタイプするしかない） 今思えば、よくあんな環境で開発していたものです。 少年時代の無謀な挑戦 少年時代の私も「マリオやドラゴンクエストやFFのようなRPGを作りたい！」という夢を抱いていました。でも「どこから作ればいいんだ？」という状態。 今みたいに「スマホで写真を撮る」ような時代ではないから、ブラウン管の画面や借りたゲームの攻略本を紙に模写して設計していました。キャラクターのドット絵から、マップの構造から、すべて手作業で。 でも、それをどうしたらゲームのようにできるのか。手元にあるのはテキストエディタとBASIC（のちにFujitsu HighCコンパイラに昇格笑）だけ。 「やれるか。やってやる。」 「まずは道具作成からや！自分が一番使いやすいペイントエディタを作ったる！」 今から思えば少しぶっ飛んだ子供だったかもしれません。何にしろ生きてる世界そのものがifとfor文とgoto文で構成されているような感覚でした。 道を歩いていても「この標識バグってんな！」とか、「こっちの道は遠いけど確率で行くと早いだろうな」とか、完全にキモいやつだったかもしれません。 友達が「ゲーム買ってもらった」と言えば、「じゃあ俺は作る」。「YAMAHAシーケンサー（音源作る道具）買えんから、似たようなもん作るで！」。母親に「お手伝いして」と言われても「開発逆にデバック手伝ってくれん？」 完全にヤバい子供でした。 インターネットもないから、ひたすら誤植だらけの書籍と格闘しながら夜な夜な作ったものです。今思えば、あの頃の純粋な情熱と無謀さがあったからこそ、プログラミングの楽しさを知ることができたのかもしれません。 まさか30年後にPixnoteとしてオンラインで蘇らせることになるのは、知る由もないのでした。 段階的な進化を経験 その後、統合開発環境（IDE）の登場、インターネットでのドキュメント検索、Stack Overflowでの情報共有、GitHubでのコード管理…と、段階的な進化を肌で感じてきました。 でも、どれも既存の開発スタイルの延長線上にある進化でした。 天地がひっくり返るほどの革命 しかし、生成AIの登場は根本的に違います。 これまでの進化が「開発を楽にする」「効率を上げる」レベルだったのに対し、生成AIは「開発の本質を変える」レベルの変化です。 機械化革命から知能革命へ もっと俯瞰してみると、これまでの技術進化はあくまでも物理的な道具を作る機械化革命でした。 より速いプロセッサ（計算速度の向上） より大きなメモリ（記憶容量の拡大） より便利なエディタ（入力効率の改善） より高機能なIDE（作業環境の統合） すべて「人間の能力を物理的に補完・拡張する」ものでした。 ところが生成AIは違います。知能という人間が持ちうる特性を獲得してしまったため、これまでとは別世界に変わってしまったのです。 考える、判断する、創造する…これらは今まで「人間だけができること」だった領域。それをAIが担い始めた瞬間、開発という行為の前提そのものが変わってしまいました。 ...

しょぼいQuickQRからの脱却 QuickQR Enhanced、ついに完成しました。 元のQuickQRといえば、見た目はしょぼいし、機能はテキストをQRコードに変換するだけという、まさに「動けばいいや」精神の権化みたいなツールでした。 でも今回、サイトリニューアルの流れで「せっかくなら見た目をキレイにして、機能も拡張してみよう」と軽い気持ちで手を付けたのが運の尽き。 結果、WiFi設定・連絡先・イベント・位置情報・バッチ処理・プリセット管理・履歴管理・カメラ読取・印刷機能まで搭載した、当初の想定を遥かに超える高機能ツールになってしまいました。 AIとの壁打ちで機能が増殖 「WiFi設定のQRコードも作れたら便利かも」 「連絡先のvCardも対応したい」 「位置情報QRがあると面白そう」 「バッチ処理できたら効率的だよね」 AIとの壁打ちをしていると、どんどんアイデアが湧いてきて、気がつくと機能が増殖していました。 生成AIが「こんな機能はいかがですか？」とガシガシ提案してくれるものだから、ついつい「それもいいね！」と言ってしまう。まさに機能のインフレーション状態です。 1000行の壁 - AIの限界を感じた瞬間 最初の500行くらいまでは順調でした。AIが出力するコードもほぼ一発で動くし、「これは楽勝だな」と思っていました。 ところが1000行を超えたあたりから様相が一変。 コード出力に異様に時間がかかる（カップラーメンができるレベル） 出力されたコードが動かない 微修正を依頼しても違う部分が壊れる やり取りが増えて、修正の修正の修正… 「あ、これAIの限界だな」と感じた瞬間でした。 大規模なコードベースになると、AIも全体を把握しきれなくなるんですね。まるで人間と同じように、複雑さの壁にぶつかってしまう。 AI時代の設計フェーズ革命 - 見えてきた新しい方法論 この経験で改めて感じたのは、設計フェーズの重要性です。いや、重要性どころの話ではありません。生死を分けるレベルです。 従来の開発なら「とりあえず動くものを作って、後でリファクタリング」というアプローチもアリでした。でもAI相手だとそうはいかない。 段取り八分、AI一分二分？ 昔から「段取り八分」という言葉がありますが、AI開発時代はもはや**「段取り九分」**かもしれません。 今回の経験から見えてきたのは、開発完了のゴールに向けての筋書きを、より解像度高く描いていく必要性です。 具体的には： ❌ 悪い例：「WiFi機能を追加する」 ⭕ 良い例：「WiFiFormクラスでSSID/パスワード/セキュリティ設定を管理し、 QRGeneratorクラスに文字列を渡してWIFI:T:WPA;S:...形式で生成」 AIに「WiFi機能を追加して」と言うと、既存のコードのどこにどう組み込むかで迷走します。でも事前にインターフェースと責任範囲を明確にしておくと、AIも迷わずに実装してくれる。 依存関係の可視化が生命線 特に疎結合な作り。機能やコードの依存を少なくして、一つの変更が他に影響しないような構造にする必要があります。 今回痛感したのは、AIは依存関係を把握するのが苦手だということ。人間なら「あ、ここを変えたらあっちに影響するな」と直感的に分かることが、AIには見えていない。 結局、ファイル分割して確実に動く部分を固めていく戦略に切り替えました： core_utils.js - 基本ユーティリティ（他に依存しない） ui_manager.js - UI関連（core_utilsのみ依存） data_manager.js - データ管理（core_utilsのみ依存） qr_generator.js - QR生成ロジック（全部から独立） たとえばこんな具合です。 それぞれが独立して動くようにして、インターフェースを明確にする。まさに疎結合的なアプローチです。 AIとの共存における新しい方法論 この辺りは今回の経験からうっすら見えてきたものはありますが、今後よい方法を確立していく必要があります。 おそらく、これがコード生成AIとの共存において新しく生まれていく方法論になっていくでしょう。 従来の設計手法に加えて： AIが理解しやすいモジュール境界の設計 コンテキスト量を意識した機能分割 AIの出力品質が保てるコードサイズの把握 人間が最後に品質保証できる粒度での設計 まだ手探り状態ですが、確実に言えるのは 「AIが賢くなったから設計はテキトーでいい」は大間違い だということ。 むしろ逆で、AIと協働するからこそ、より精密な設計が必要なんです。 1000行の教訓 - AIのコンテキスト限界との付き合い方 「AIは万能じゃない」というのは頭では分かっていましたが、1000行の壁で体感しました。 ...

サイト移行の副産物 先日のサイト移行が完了して、新しい環境でいろいろ整理していたら、長年蓄積されていた「オレオレツール」群が大量に発掘されました。 どれも「ちょっとこういうのがあれば便利なんだけどな」という思いつきで作って、そのまま自分だけがひっそりと使い続けていたものばかり。ほとんどがCUI（コマンドライン）ツールで、UIなんて概念すらありません。コードは汚いし、使い方も自分しか分からない、まさに「動けばいいや」精神の塊です。 体裁を整えるという苦行 せっかくなので公開してみようと思ったのですが、これが想像以上に大変でした。 何しろ、CUIツールをWebツールにするには、UIを一から作る必要があります。「引数で設定を渡す」から「フォームで入力を受け取る」に変更し、「標準出力に結果を出力」から「きれいに整形して表示」に変更し… 一番困ったのが、自分にはまともなデザインセンスがないこと。機能は作れても、「人が使いたくなるUI」を作るのは別のスキルです。 生成AIに助けられた話 ここで救世主として登場したのが生成AIでした。 「こういう機能のツールで、こんな感じのUIにしたい」と指示すると、ほぼノーコードでそれっぽいものを作ってくれます。CSS Gridの使い方から、レスポンシブ対応、果てはアニメーションまで。 特に驚いたのは、「ファイルをドラッグ&ドロップで受け取って、処理結果をダウンロードできるツール」みたいな複雑な要求でも、一発で動くコードを生成してくれること。 正直、これまで何時間もかけてStack Overflowを漁り、MDNを読み漁り、試行錯誤しながら作ってきた機能が、指示一つで完成してしまうのを見て、心の中で「あの苦労はなんだったんだ…」と嘆きました。 いや、本当にすごい時代になったものです。 （この辺りの話は、また別の機会にじっくりと書きたいと思います） こだわりポイント 整理するにあたって、いくつか譲れない部分がありました。 軽量であること 読み込み時間にイライラするツールほど使わなくなるものはありません。必要最小限の依存関係で、サクッと開いてサクッと使える。これ重要。 使いやすくあること UIの美しさより操作の分かりやすさ優先。説明書を読まなくても直感的に使える、というのを目指しました。（達成できているかは別として） ローカル環境で動くこと これは昔からのこだわりです。 一般的には画像変換やデータ処理はサーバーサイドで行うのが主流でしたが、私はインターネットが普及し始めた頃からJavaScriptでなんとかしようと頑張ってきました。 もちろん、当時は今ほどJavaScriptが強力ではありませんでした。ブラウザの「JavaScriptを無効にする」設定と延々と戦い続けた記憶があります。「スクリプトが無効になっています」のメッセージを何度表示したことか… でも、「データを外部に送信しない」というのは、プライバシーとセキュリティの観点から非常に重要だと思っていました。特に画像系のツールなんて、機密性の高いデータを扱うことも多いですからね。 今では、JavaScriptの進化とブラウザAPIの充実で、昔は不可能だった処理もクライアント側で完結できるようになりました。長年のこだわりが、ようやく技術的に報われた感じです。 レスポンシブ対応は当たり前 もはや言うまでもありませんが、スマホからでも使えることは前提。 技術的な面白ポイント せっかくなので、技術的に面白かった部分もいくつか。 Web Workers でのバックグラウンド処理 重い処理はWeb Workersに投げて、UIをブロックしないようにしています。プログレスバーもリアルタイムで更新されるので、「固まった？」という不安がありません。 OffscreenCanvas for 画像処理 Canvas操作をメインスレッドから分離できるOffscreenCanvasも活用。大量の画像を処理する際のパフォーマンス向上に効果的でした。 そういえば、もうリリース後8年目に突入したPixnoteでも、Canvasを使った画像変換や座標変換、圧縮処理などをバリバリやってきているのですが、今回の作業を振り返りながら改めてその面白さを噛み締めているところです。 当時は「ブラウザでこんなことができるなんて」と驚きながら実装していた機能が、今では当たり前のように使えるようになっている。技術の積み重ねって、本当に面白いものですね。 Pixnoteといえば、YouTube動画での説明もやらなければと思いつつ、説明しなければならない内容もいっぱいあって、未だ3本で終わってしまっています。まさに三日坊主… 動画制作ってまとまった時間が必要で、なかなか腰を上げられないのが現実です。でも、それまではここで記事にしていこうと思います。なぜならば、サイトリニューアルで記事が書けるようになったから！ 文章なら隙間時間でも書けるし、技術的な詳細も丁寧に説明できる。動画の準備ができるまでは、こちらで情報発信を続けていく予定です。 JavaScriptとの長い付き合い 今回のツール群整理を通じて、改めて「JavaScriptとの長い付き合い」を振り返りました。 最初の頃は「おもちゃ言語」扱いされていたJavaScriptが、今では本格的なアプリケーション開発言語になっています。ブラウザ上で動画編集ができて、3Dレンダリングができて、機械学習まで動く。 昔、「JavaScriptでファイル操作なんて無理」と言われていた時代に、無理やりData URIやBlob APIで頑張っていたのが懐かしいです。今では File API や FileReader API が当たり前のように使えて、ドラッグ&ドロップも簡単。 技術の進歩を肌で感じられるのは、エンジニアの特権ですね。 今後の展開 とりあえず、手持ちの中で人様に見せられる状態になったものから順次公開していく予定です。まだまだ「発掘作業」が必要な状態ですが、気長にお付き合いください。 新しいツールを一から作るよりも、既存のCUIツールをWeb化する方が、場合によっては大変だということを改めて実感しました。でも、自分が実際に使っているものなので、少なくとも「机上の空論」ではないはず。 まとめ 新しいサイト環境で、ようやくこういった実験的なコンテンツも気軽に公開できるようになりました。「作って終わり」ではなく、実際に使い続けて改善していく、そんなLiveなプロジェクトにしていきたいと思います。 長年のJavaScript愛と、「ローカル処理へのこだわり」を貫きながら、役に立つツール群を育てていければと思います。 リクエストやバグ報告もお気軽にどうぞ。ただし、「すみません、まだ発掘中です」という返事が返ってくる可能性は相変わらず大ですが。 Lab: https://aoiroinc.com/ja/lab/

技術的負債の清算、再び ポータルサイトを放置して早数年。「そういえばあっちのサイト、全然メンテしてないじゃん」という開発者あるあるの状況でした。サイドプロジェクトで作ったツールやライブラリの公開場所も欲しかったし、重い腰を上げてリニューアルに着手することに。 なぜHugoなのか（再び） 実はGoベースの静的サイトジェネレーターとしてHugoには以前から馴染みがありました。Jekyll、Gatsby、Next.js（SSG）など選択肢は山ほどありますが、結局はビルド速度とテンプレートのシンプルさでHugoに軍配が上がります。何より hugo server でライブリロードしながらサクサク書けるのが気持ちいい。 実は移行準備は数年前から整っていたのですが、例の「いつかやろう」病が発症していました。エンジニアなら誰でも経験のある、あの感覚ですね。 WordPressという技術的負債との決別 従来のWordPressサイトは、まさに「動く技術的負債」状態でした。管理画面にログインするたびに「プラグインを更新してください」の嵐。セキュリティパッチ、PHP バージョン依存、MySQL の面倒見…もう勘弁してくれという感じです。 開発者的には git add . → git commit → git push のワークフローの方が圧倒的に自然。マークダウンで書いてGitHub Pagesでも Netlify でもデプロイできる身軽さは、一度味わうと戻れません。差分管理もブランチ戦略も思いのまま。これぞ Infrastructure as Code の真髄です。 テーマ選択という名の沼 Hugoのテーマ選びは、npmパッケージ選びと同じくらい時間を食う作業でした。Academic、Hermit、Terminal…どれも魅力的で迷いましたが、最終的にはPaperModの洗練されたデザインとパフォーマンスに落ち着きました。 「完璧を目指すより、まず動くものを」というアジャイル的発想で、カスタマイズは後回し。MVPならぬMVS（Minimum Viable Site）でスタートです。 実装フェーズ：準備が8割 技術選定と要件定義で散々悩んだおかげで、実際のコーディングは数時間でした。既存コンテンツのマイグレーション、設定ファイルの調整、CSSのちょっとしたカスタマイズ程度。やっぱり設計フェーズが一番重要ですね。 移行後の所感：静的サイトの勝利 WordPressからの解放感は想像以上でした。サーバーリソースを気にする必要もなし、（そのうち）CDNで爆速配信、SEOも良好。何より開発者体験（DX）が段違いです。 とりあえず、長年の懸案事項だったサイト移行が完了してスッキリしました。シンプルで軽快、そして開発者フレンドリーな環境が整ったので、今度こそサボらずにコンテンツを充実させていこうと思います。