開発環境

せっかくの大型連休、ゴールデンウィークだというのに雨が続くらしい。 釣りへ出かける気分にもなれない。というより最近はCodexの衝撃とともに、Codexへの指示とレビューに時間を取られまくって消耗し切っている。 もはや私はAIの奴隷に成り下がっているのではないか。 AIが人間社会を楽にしてくれるなんて嘘っぱちじゃないか。人間作業だったら数週間かかるものを一瞬でAIが生成してくれるからといって、人間側はまったく楽にならないのだ。 なぜなら、AIの生成物のレビューに時間がかかる。イメージと違う成果物が出てきたら、当然、自分ではすぐ直せないほど高度なものなので、指示書を書き直して再度依頼する。そんなことを高速で繰り返すものだから、こちらは休みなく働かされ続ける。 少しでも時間にゆとりが出ようものなら、Codexの /status を見て「課金プランを使い切っていないともったいない」という感情が働き、次の指示を考えなければならない。ターミナルだって4窓をCodexに使い、各窓をさらに左右に分割し、人間側が操作できるCLIをなんとか確保している。 きっと私が間違っているのだろうが、最近はそんな日々を送っていたため、だいぶ病んでいる。 現実逃避すべくマイクラを再開したのは自然な流れだろう。 Note ただ、この状態はその後少しだけましになった。手元のMacに張り付いてCodexの様子を見続けるのではなく、さくらのサーバー上にリポジトリをcloneして、Codexに記事リライトを定期実行させる仕組み を作ったからだ。結局AIに仕事を増やされている気もするが、人間がずっとターミナルを監視し続ける時間は少し減った。 久しぶりに一から始めるマイクラ 久しぶりにMinecraftを一から始めた。雨の連休、釣りに行けない気持ちを抱えたまま、仮想世界の砂浜へ降り立つ。 画面を見ていると、これは小田原サーフだろうか、などと勝手に脳内補正が始まる。現実の海へ行けないなら、ブロックの海辺でよいではないか。 ただ、ゲームを始めてすぐ、マイクラそのものよりも「CodexにModをインストールさせてみよう」という気持ちが勝ってしまった。ここがもう病の深いところである。 以前にも手作業でModを入れたことはあったのだが、仕組みをちゃんと理解していないせいか、とても面倒な印象が残っていた。手動ではやりたくない。こういった作業こそCodexに任せるのが正解だろう。 そこで思い出したのが、座標を常に画面上へ表示したいという話だった。 デフォルトでもF3のデバッグ画面を開けば座標は確認できる。ただ、情報量が多すぎて見づらいし、普段のプレイ中にずっと出しておくには少し邪魔だ。必要なのは、座標だけを小さく常時表示してくれる仕組みである。 MiniHUDを見つける 調べてみると、まさに欲しかったものとして MiniHUD があった。 MiniHUDは、いわば小さなF3画面のように、座標などの情報を選んで表示できるクライアント側Modである。Modrinthの説明でも、MiniHUDは「mini F3」的なHUDや各種オーバーレイを提供するクライアントサイドModとして紹介されている。 また、MiniHUDを使うには共通ライブラリである MaLiLib も必要になる。MaLiLibは、設定画面、ホットキー、GUIまわりなど、masa氏系Modで共通利用される部品をまとめたライブラリという位置づけらしい。 こういう依存関係を自分で追いかけるのが面倒だったので、すぐにMinecraft用のプライベートリポジトリを作り、git clone で取り込み、Fork、IntelliJ IDEA、Codexあたりの初期化を済ませた。 GitHub Issuesには、次のような指示を追加した。 codex --search exec --full-auto で以下タスクを順番に自動で進めてください。 --- MiniHUDをインストールして、座標を表示できるようにしてください。 この実装を始める前に、まずは実行計画を立てて下さい。 それをTODOリストとしてMarkdownファイルに落とし込んでください。 このIssueのURLをCodexへ貼り付けて作業開始。数分でMod導入まで進んだ。 このスピード感は確かにすごい。人間が公式ページを読み、依存関係を確認し、バージョンを合わせ、ダウンロード先を探し、配置先を調べる。その一連の調査と作業を、Codexはかなりの速度で進めてくれる。 ただし、速いからといって楽になるとは限らない。ここから人間は、何が入ったのか、どこへ置かれたのか、バージョンは合っているのか、起動して本当に動くのかを確認し続けることになる。 今度はModの表示を変えたくなる 座標が表示できるようになると、さらに余計なことを思いつく。 MiniHUDの表示で WEST や EAST と出ている部分を、「西」「東」のように日本語化できないだろうか。 ただの表示文字列を変えるだけなら簡単そうに見える。だが、Modは普通のアプリではなく、Minecraft本体のバージョン、Modローダー、依存Mod、マッピング、ビルド設定が密接に絡む。ここを理解しないまま触ると、急に難しくなる。 調べるとMiniHUDはオープンソースだった。そこで速攻でforkして、ソースコードをcloneし、IntelliJ IDEAで開いて、表示文字列らしき箇所を変更してみた。 ところが結果として、この方法はうまくいかなかった。 ソースコードを直してもダメだった理由 今回つまずいたポイントは、ソースコードを直すこと自体ではなく、ビルドしたModが自分のMinecraft環境に合っていなかったことだった。 MinecraftのModは、単に「MiniHUDのソースをビルドすれば動く」というものではない。 Minecraft本体のバージョン Fabric、Forge、LiteLoader、OrnitheなどのModローダー MaLiLibなど依存Modのバージョン そのブランチが想定しているマッピングやビルド設定 これらが揃って初めて、入れ替え可能なJARになる。 ...

Playwrightを触ってみて、これはかなり使えるのではないかと思いました。 UIテストの道具として便利なのはもちろんですが、AIにコードを書かせる機会が増えるほど、意図していない場所が壊れていないかを機械的に確認する仕組みが欲しくなります。 特に個人開発では、リリース前に毎回ブラウザを開いて、 トップページが開くか フォームを送信できるか 検索やフィルタが動くか 登録、編集、削除の主要な流れが壊れていないか AIに直してもらった場所以外が壊れていないか といった確認を手でやりがちです。最初は数分でも、画面や機能が増えると抜け漏れが出ます。 Playwrightは、この「毎回ブラウザでやっている確認」をコードにして、同じ条件で繰り返し実行できるE2Eテストの道具です。スクリーンショットや動画も残せるので、テストだけでなく、YouTubeや記事用に動作説明の素材を作る用途にも使えそうです。 この記事では、React + Viteで作った問い合わせフォーム を例に、Playwrightを入れてフォーム操作を自動確認するところまでを書きます。 全体像は、手動確認をテストコードに置き換え、ブラウザで自動実行し、失敗時はレポートやtraceで原因を追う流れです。 Playwrightとは Playwrightは、ブラウザを自動操作してWebアプリの動きを確認できるE2Eテストフレームワークです。 E2EはEnd to Endの略で、ユーザーが実際に画面を開いて操作する流れに近い形でテストします。たとえば、次のような操作をコードで書けます。 ページを開く 入力欄に文字を入れる ボタンを押す 検索結果が表示されることを確認する フォーム送信後のメッセージを確認する 単体テストが関数や部品単位の確認に向いているのに対して、Playwrightは「画面上で主要な操作が最後まで通るか」を確認する用途に向いています。 PlaywrightはChromium、Firefox、WebKitを扱えます。ただし、初めて導入する段階では、いきなり全ブラウザを対象にしなくても大丈夫です。まずはChromiumだけで、リリース前に毎回手で確認している重要な操作を1つ自動化するところから始めると進めやすいです。 触って便利だと感じたところ まだ深く使い込んでいるわけではありませんが、触ってすぐ便利だと感じたのは次のあたりです。 クリックや入力の前に、要素が操作可能になるまで待ってくれる expect を使って画面上の見出し、ボタン、メッセージを確認できる 失敗時のスクリーンショット、動画、trace、HTMLレポートを残せる UI Modeで、ブラウザの動きを見ながらテストを書ける 開発サーバーの起動を webServer でまとめられる Chromium、Firefox、WebKitを同じテストで確認できる AIにコードを直してもらったあと、「指示した箇所は直ったが、別のフォームが壊れた」ということは普通に起きます。Playwrightで主要フローだけでも自動確認しておけば、その手戻りに気づきやすくなります。 最初はフォーム送信だけでもよい Playwrightを入れると、つい全画面を自動化したくなります。ただ、最初から広げるとテストを書くこと自体が重くなります。 まずは、今回の問い合わせフォームのように、壊れると困る操作を1つだけ選ぶくらいでよさそうです。 ページが開ける フォームへ入力できる 送信後の結果が表示される これだけでも、リリース前に毎回手で確認していた作業を1つ減らせます。慣れてきたら、検索、登録、編集などに広げれば十分だと思います。 React + ViteフォームにPlaywrightを入れる 今回は、React + Viteで作った小さな問い合わせフォームを例にします。 以降のコマンドは、React + Viteフォームアプリのプロジェクト直下で実行する前提です。 まず、Playwright Testを開発依存として追加します。 npm install -D @playwright/test 初回はブラウザも入れます。まずはChromiumだけで十分です。 npx playwright install chromium 新規プロジェクトでひな形ごと作りたい場合は、公式の npm init playwright@latest から始めてもよいです。この記事では、既存のReact + Viteアプリへ手で追加する流れにします。 ...

Reactと合わせてよく見かける、Viteって何だろう。Next.jsとは何が違うんだろう。 そんなところで少し疑問に思ったので、さらっと学習してみました。 AIによって生成されたアーキテクチャやソースコードで意味が分からないままだと、あとで自分で直したいときに困ったことになります。 AIに改修を任せる場合でも、レビューは必要ですから、最低限の知識は入れておきたいですよね。 さて今回は、React + Viteで小さな問い合わせフォームを作りながら、React、Vite、Next.jsの役割を整理してみました。 まずReact、Vite、Next.jsの役割を整理 最初に混乱しやすいのは、React、Vite、Next.jsがどの部分を扱っているのかよく分からないこと。 実際には、担当している範囲が違います。 ざっくり分けると、次のようになります。 名前 役割 この記事での見方 React UIを作るライブラリ 画面をコンポーネントとして作る Vite 開発サーバーとビルドの道具 Reactアプリを快適に開発し、公開用ファイルへまとめる Next.js Reactベースのフレームワーク ルーティング、SSR / SSG、サーバー側処理なども含めてアプリを作る なるほど、Next.jsはReactを元に増強したフレームワークなのですね。一方でViteはビルドなどやりやすいようにしてくれる、開発支援ツールといったところでしょうか？ もちろんReactは、画面を部品として組み立てるためのライブラリです。コンポーネント、JSX、state、イベント処理といった考え方が中心になります。 Viteは、Reactアプリを開発するときの開発サーバーや、本番公開用のビルドを担当する道具です。ちなみに Vite は「ヴィート」と読みます。保存した変更を素早くブラウザに反映するHMR (ホット・モジュール・リプレイスメント)も、Viteのありがたさを感じやすい部分です。とはいえ、今時この手のツールは当たり前すぎて、あまり意識していなかったようです。 Next.jsは、Reactを土台にしたフレームワークです。ファイルベースのルーティング、SSR、SSG、Route Handlersなど、アプリ全体を作るための機能をまとめて持っています。SSR、つまりサーバーサイドレンダリングですが、ここら辺が Next.js の魅力といったところでしょうか。 さて今回は、学習用に小さなフォームアプリをReact + Viteで作ってみます。SPA（シングルページアプリケーション）ですが、ペラ１のめちゃ簡単なUIのみで、メールサーバーも何もないのであしからず。 React + Viteプロジェクトを作る それではプロジェクトを作成して実装していきましょう。 Vite公式のGetting Startedでは、npm create vite@latest からプロジェクトを作れます。 Vite 8系ではNode.js 20.19+ または 22.12+ が必要です。古いNode.jsを使っている場合は、先に更新しておきます。 まずはNode.jsのバージョンを確認します。 node -v 次に、Reactテンプレートでプロジェクトを作ります。 npm create vite@latest react-vite-form-app -- --template react cd react-vite-form-app npm install npm run dev 対話形式で進める場合は、次のように選びます。 ...