Notes

しょぼい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）が段違いです。 とりあえず、長年の懸案事項だったサイト移行が完了してスッキリしました。シンプルで軽快、そして開発者フレンドリーな環境が整ったので、今度こそサボらずにコンテンツを充実させていこうと思います。