ツール開発

実験開始：コードに触らない縛りプレイ 先日のサイトリニューアルに合わせて、ツール群を改めて構築し直している最中です。 元々は自作のツールたちでしたが、今回はあえて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撃 難易度：⭐️ 画像変換ツール ...

しょぼい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/