ここ最近、AIエージェントをかなり集中的に触っていた。 Codex の $100 プランを契約し、20日ほどがっつり使ってみた。 結論から言うと、来月からは $20 プランへ戻す予定である。 理由は単純で、$100 プランの容量を使いこなすほど、自分の指示が追いつかなかったからだ。 Codex が物足りなかったわけではない。 むしろ十分すぎた。 5日のコンテキスト上限を使いこなすほどの指示を、自分が出せなかった。 つまり、自分の処理能力が先に限界へ来た。 CLI型AIエージェントのすごさは「フィードバックループ」にある Codex に限らず、この手の CLI 型AIエージェントを導入してすごいと思ったのは、ローカルプロジェクトを理解してくれることだった。 これまで Web ブラウザ版の ChatGPT を使ってコード修正を相談する場合、修正したいファイルを毎回アップロードしたり、コードを貼り付けたりする必要があった。 しかし CLI 型AIエージェントでは、ローカルのプロジェクトをそのまま見てもらえる。 そのため、プロジェクト全体をまるで把握しているかのように、かなり的を射たコーディングをしてくれる。 ただ、改めて考えると、すごさはそれだけではない。 もっと大きいのは、AIエージェント自身がテストコードを実行できることだと思う。 AIがコードを改修する。 そのコードに対してテストを実行する。 テストが失敗したら、エラー内容を読んで、もう一度コードを直す。 そしてまたテストを実行する。 これは、単なるコード生成ではない。 入力に対して出力を返すだけではなく、その出力結果を観測し、フィードバックして、次の修正に反映する流れである。 制御工学っぽく言えば、開ループではなく、閉ループになった感じがある。 これまでのAIチャットは、どちらかといえば「コードを提案して終わり」だった。 しかし CLI 型AIエージェントでは、生成したコードを自分で実行し、結果を見て、自分で修正する。 このフィードバックループが入ったことで、AIによるコーディングはかなり実用的になった。 人間に例えれば当たり前の話だが、たったこれだけで、精度はぐんと上がった感がある。 （このことは、今後 AI をうまく使いこなすための大きなヒントになるかもしれない） もちろん、すべてが完璧になるわけではない。 テストが通っても、仕様として正しいとは限らない。 こちらの気持ちや意図まで理解するには程遠い場面も多々あり、最後は人間による判断が必要になる。 それでも、テスト結果という強いフィードバック信号をAI自身が扱えるようになったことは、かなり大きな変化だと思う。 Claude も契約してみた 一方で、Claude の $20 プランも契約してみた。 CLI AI エージェントは Claude が先駆者だと思うが、Codex を先に体験してしまったので、Claude を使うことに今更感があり少し足踏みしていた。 しかし、実際に使ってみると Codex との違いを比較できて、かなり面白かった。 ただし、契約時にはクレジットカード決済で少し苦労した。 なかなか決済が通らず、最終的には VISA の楽天カードについてサポートへ連絡し、ストップされていた件を説明して解除してもらうことで、ようやく決済できた。 ...

この記事で伝えたいこと Codex などの AI コーディングエージェントを使うと、コードを書く時間そのものは短くなる。一方で、実際に使い込むほど「エージェントへ指示を出す」「結果を確認する」「失敗したら再実行する」「別の作業をもう一つ投げる」といった運用に時間を取られるようになった。 気がつくと PC の前に張り付き、ターミナルを 4 窓から 8 窓くらい開き、どの作業がどこまで進んでいるのかを追い続けていた。これはこれで便利ではあるが、開発体験としてはまだ人間がかなり忙しい。 そこで、GitHub Issue をキューとして使い、VPS 上の agent runner が Codex CLI を非対話で動かす仕組みを作った。この記事ではプログラムの細部ではなく、なぜ作ったのか、GitHub Actions と何が違うのか、どんな構成で動かしているのか、そして何が変わったのかを整理する。 「agent runner」 はあくまで自作のプロダクト名であり、前回の記事 さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる をさらに進化させた形である。 想定読者 この記事は、すでに AI コーディングエージェントを使っている開発者に向けて書いている。 特に次のような人を想定する。 Codex CLI や Claude Code などのエージェントを日常的に使っている ターミナルを複数開いて並行作業している GitHub Issue や PR を開発の入口として使っている CI/CD とは別に、AI エージェントへの作業依頼をうまく管理したい 導入: AI 駆動開発は便利だが、人間が忙しい AI コーディングエージェントを使うと、実装、調査、テスト修正、ドキュメント作成などをかなり任せられる。 ただし、使えば使うほど別の課題が出てくる。 ターミナルをいくつも開いて、複数のエージェント作業を見張る必要がある どの作業に何を指示したか分からなくなりやすい 失敗した作業を再投入するたびに、文脈を思い出して指示し直す必要がある PC の前にいないと、次の指示を出しにくい エージェントは作業を進めてくれる。しかし、作業を投げる入口がターミナルに閉じていると、人間は結局ターミナルの前から離れにくい。 この状態を変えたかった。 なぜ Codex GitHub Action ではないのか 最初に考える選択肢は GitHub Actions だと思う。GitHub のイベントをトリガーにして処理を走らせるなら、Actions は自然な選択肢だ。 ...

ブログ記事の簡単なリライト作業を、手元のMacではなくサーバー側でも動かすようにしてみました。 やりたいことは、サーバーにブログ用リポジトリを clone して、その中で Codex CLI に記事リライト系の作業を任せ、さらにコミット・push・PR作成までを自動化することです。 実際には gh の権限、privateリポジトリのclone、Codexのログイン、sandbox など、細かいところでつまずいたことがいくつかありました。それらを中心に、備忘録として残しておきます。 やりたかったこと まずはサーバーにSSHでログインし、GitHubリポジトリを用意します。 仮に、clone先は以下とします。 /home/appuser/repos/private-blog ここにブログのprivateリポジトリをcloneして、記事リライト用のバッチ処理から Codex CLI を呼び出します。最終的には、このバッチ処理をcronで定期実行する想定です。 当然、git / gh / codex がシェルで使えるように、サーバー側へ各コマンドをインストールしておく必要があります。 本番サーバーでやるのが怖い場合は、もう1台サーバーを用意するのも現実的です。さくらVPSなら比較的安いですし、私も本格運用するなら別サーバーを用意する予定です。 もちろん、ラズパイなどを使って自鯖で処理させるのも十分ありだと思います。 サーバー側でCodexに作業させるので、本番公開ディレクトリとは必ず分けておきます。 /home/appuser/public-site # 公開用 /home/appuser/repos/private-blog # 作業用clone また、私の場合は、リポジトリのmainブランチも直接編集させず、worktreeを使った別ブランチで作業させるようにしています。 全体の関係は、次のようなイメージです。 今のところ、PRのレビューからbuild / deploy作業までは、人間が担当するようにしています。 そのためローカルMacの出番は、最初の初期設定とPR確認が中心です。そこまで整えば、毎回SSHでサーバーに入って手作業する必要はかなり減ります。 なぜGitHub Actionsではなくサーバー上のcloneで回したか ところで、この手の自動化をChatGPTへ相談すると、かなりの確率で GitHub Actions 案が出てきます。 MicrosoftはGitHubを買収済みで、OpenAIにも大きく投資しています。 Microsoft → GitHubを買収済み Microsoft → OpenAIへ大規模投資 だからActionsが推されるのでは、と邪推したくなるくらい毎回出てきます。もちろん半分冗談です。実際には、定期実行やPR作成までGitHub側で完結できるので、CI/CDの定番案として出てくるのだと思います。以前、VPSへのデプロイでは GitHub CI/CD で VPS へ自動デプロイするまで にまとめたように、Actionsの便利さも確認しています。 それでも今回は、サーバー上のcloneで動かす方を選びました。 理由は主に3つです。 1つ目は、すでにサーバー上で日次処理を動かす前提があったことです。記事リライトはサイト運用のローカルな作業に近く、実行ログや失敗時のworktreeをサーバー上に残せる方が追いやすいと考えました。 2つ目は、秘密情報を増やしたくなかったことです。GitHub Actionsに渡すsecretを増やすより、サーバー側のenvファイルに閉じた方が、今回の小さな運用では見通しがよくなります。 3つ目は、OpenAI API key を新しく使わずに進めたかったことです。Codex CLIはChatGPTログインでも使えるため、今回の確認ではAPI keyを新規発行せず、手元で使っているアカウントのログインで試しました。もちろん、公式にはAPI key認証もあり、CIや完全自動化ではAPI keyの方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...

RSSはもう死んだものだと思っていた。 でも、そうではなかった。 海外の主要ニュースサイトから見出しを集めて、CLIでニューストピックを表示するアプリケーションを作ろうとしたことがきっかけだった。AIによる成果物を動かしてみて、裏側ではスクレイピングをしているのだろうと思っていた。ところが、実際にはRSSフィードから更新情報を取っていた。 つまり、RSSは死んでいなかった。 死んでいたように見えたのは、RSSそのものではなく、普通の人がRSSを意識して使う入口だったのだと思う。 Google Readerが終わっただけだった RSSが終わったように感じられた象徴的な出来事は、Google Readerの終了だった。 Googleは2013年3月13日の公式ブログ記事「A second spring of cleaning 」で、Google Readerを2013年7月1日に終了すると案内している。公式ブログでは、熱心なユーザーはいたものの、利用が減少していたことが理由として説明されていた。 Google Readerを使っていたわけではないが、そんな私でも記憶しているほど当時は驚きのニュースだった。 RSSを読むための代表的なツールの一つが終了となったことで、一般ユーザーの視界からRSSは急速に消えていったように見える。その後はSNSのタイムライン、ニュースアプリ、レコメンド、今ならAIによる要約やおすすめが、情報を受け取る入口になった。 だから、Google Readerが終わったことと、RSSという仕組みが終わったことは別の話である。 きっかけは海外ニュースをCLIで眺めるツールだった 今回作ろうとしたのは、海外ニュースの見出しをCLIでざっと確認するための小さなツールだった。 リポジトリはこちら。 aragig/shell-toolbox の news-topics 実行すると、複数の海外ニュースサイトから見出しを集めて、ターミナルに一覧表示してくれる。 以下は news コマンドを実行した出力イメージだ。 海外ニュースの見出しをnewsコマンドで表示しているターミナル画面 % news News Topics 12 items | balanced by source cap (2/source) 01. 原油価格が2022年以来の最高値に急騰 [BBC] 2026-04-30 06:55 UTC EN Oil jumps to highest price since 2022 URL [https://www.bbc.com/...](https://www.bbc.com/) 02. ジェット燃料価格の高騰が山火事の消火費用を押し上げている [NPR] 2026-04-30 07:00 UTC EN How rising jet fuel prices are driving up the cost of fighting wildfires URL [https://www.npr.org/...](https://www.npr.org/) BBC / Reuters / NPR / DW / France 24 / Al Jazeera など、複数のニュースサイトから取得する。ソースごとの上限とラウンドロビンでひとつのサイトに偏らないように表示している。 ...

せっかくの大型連休、ゴールデンウィークだというのに雨が続くらしい。 釣りへ出かける気分にもなれない。というより最近は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になる。 ...

ナスオモリの重さや素材を変えると、底につくまでの時間はどれくらい変わるのでしょうか。 釣り場では、なんとなく「重い方が速い」「タングステンは小さいから沈みやすそう」と考えています。ただ、その差を数字や動きで見比べようとすると、頭の中だけでは整理しにくいです。 そこで、ナスオモリの沈み方を見比べるための小さなWebアプリを作りました。 ナスオモリ沈下シミュレーター 重さ・金属・水深で着底時間を比較 開く アプリ： ナスオモリ沈下シミュレーター 計算根拠： ナスオモリの沈み方をどう計算しているか この記事では、アプリでできることと、釣り場でどう使うとよさそうかをまとめます。 作った理由 最近、ゴロタ浜やサーフで底を探る釣りをすることが増えました。 底の石に当たる感触、根掛かりしにくさ、アタリの出方。こういうものは、シンカーの形や浮力でかなり変わります。フロートシンカーは根掛かりには強いですが、底からの情報は少なくなります。逆に普通のオモリは底の情報が出やすいものの、場所によっては根掛かりが怖いです。 その中で、ふと気になったのが「沈む時間」でした。 同じ1oz前後でも、鉛、タングステン、ブラス、鉄では体積が違います。重くすれば速く沈みますが、体積も大きくなって水の抵抗も増えます。仕掛けやラインまで含めると、さらに単純な話ではなくなります。 もちろん、実際の海では潮流、糸ふけ、エサ、仕掛けの姿勢で結果が変わります。ですから、このアプリは正解を出すためのものではありません。条件を変えたときに、沈み方の傾向を見比べるための道具として作りました。 このアプリでできること アプリでは、4つのナスオモリを同時に並べて沈められます。 それぞれのオモリについて、素材と重さを変えられます。素材は鉛、タングステン、ブラス、鉄です。重さは1gから120gまでの範囲で指定できます。 鉛 タングステン ブラス 鉄 水の条件も変えられます。 水深：1mから100m 水質：真水、海水 水の抵抗：0.10から4.00 画面には、代表オモリの着底時間、終端速度、水の密度、実際に沈む距離が表示されます。アニメーションを止めたり、タイムラインを動かしたりしながら、同じ条件で沈み方の差を見られるようにしました。 たとえば、鉛の10g、14g、21g、28gを並べれば、一般的な号数違いの感覚へ近づきます。素材だけを変えれば、同じ30gでもタングステンの方が小さく、ブラスや鉄の方が大きくなることも見えやすいです。 まずは基本条件で見比べる 最初は、初期値のまま眺めるのが分かりやすいです。 初期状態では、海水、水深5m、水の抵抗2.00で、鉛の10g、14g、21g、28gを並べています。アプリ上の沈下距離は、オモリの見た目サイズを考慮して、水深より少し短くなります。 オモリ 素材 沈下距離の目安 終端速度の目安 着底時間の目安 10g 鉛 4.37m 0.88m/s 5.0秒 14g 鉛 4.30m 0.94m/s 4.7秒 21g 鉛 4.19m 1.00m/s 4.3秒 28g 鉛 4.11m 1.05m/s 4.0秒 このくらいの浅い水深では、違いは数秒単位ではなく小数秒として出ます。釣りをしている最中に正確に感じ分けるのは難しいかもしれませんが、「重さを上げるほど速くなる。ただし倍の重さでも半分の時間にはならない」という傾向は見えます。 もう少し差を見たいときは、水深を20mや50mへ上げると分かりやすいです。水深が深くなるほど、終端速度に近い状態で進む時間が長くなり、素材や抵抗の違いが表に出やすくなります。 同じ30g、水深20m、海水、水の抵抗2.00で素材だけを変えると、おおよそ次のようになります。 素材 終端速度の目安 着底時間の目安 鉛 1.06m/s 18.1秒 タングステン 1.29m/s 14.9秒 ブラス 0.95m/s 20.2秒 鉄 0.92m/s 20.8秒 同じ重さなら、密度が高いタングステンは体積が小さくなり、水の抵抗を受ける面積も小さくなります。そのため、このモデルでは鉛より速く沈みます。ブラスや鉄は鉛より体積が大きくなり、少し遅く沈みます。 ...

準備中のサイトを、URLでは共有したい。でも、検索や一般ユーザーにはまだ見せたくない。 Hugoで作っているサイトの公開前チェック、WordPressのリニューアル確認、ローカルで動かしている検証アプリの共有では、この状態がよくあります。自分だけで見るならlocalhostで足りますが、確認相手に見てもらうには外から開けるURLが必要です。 そこで使いやすいのが、Cloudflare Zero TrustのAccessです。 この記事では、preview.araisun.comのような確認用ホスト名にCloudflare Accessをかけ、許可したメールアドレスだけOne-time PINで通す流れを整理します。Cloudflare Tunnelは「previewを外へ出す道」として短く扱い、Tunnel自体の作り方はローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel に任せます。 主役は、Cloudflare Accessのapplication、policy、One-time PIN、動作確認です。 先に結論 Cloudflare配下のドメインで準備中サイトを共有するなら、Basic認証だけでなくCloudflare Accessも候補になります。 Accessを使うと、originへリクエストを通す前にCloudflare側で認証できます。確認してほしい人のメールアドレスをAccess policyに入れ、その人だけOne-time PINでログインできるようにします。共有するのは共通パスワードではなくURLとメール認証の案内です。 今回の例では、preview.araisun.comを準備中サイトの確認用URLにします。Access applicationでこのホスト名を保護し、policyで許可メールを指定し、許可メール、未許可メール、別ブラウザ、スマホ回線、Access logsを順番に確認します。 Tunnelを使う場合でも、この記事ではTunnelの細かい手順には入りません。Tunnelは公開URLへつなぐ道、Accessはその手前で誰を通すかを決める関門、と分けて考えます。 Cloudflare Accessで守れるもの Cloudflare Accessは、Cloudflareを通るリクエストの前段に認証レイヤーを置く機能です。self-hosted applicationとしてpreview.araisun.comのような公開ホスト名を登録し、Access policyに一致したユーザーだけをoriginへ通します。 準備中サイトで使うなら、守る対象は次のような入口です。 preview.araisun.comのホスト名全体 /adminのような特定path stagingやpreview用のサブドメイン この記事では、準備中サイト全体を見せるか見せないかを制御したいので、preview.araisun.com全体を保護対象にします。/adminだけを守る設定にはしません。 Access applicationは、作っただけで全員を通すものではありません。基本は「許可条件に一致した人だけ通す」という考え方です。だから、applicationを作ったあとに、誰を通すかをAccess policyで決めるところが重要になります。 ただし、Accessが守れるのはCloudflare経由の入口です。VPSやnginxのorigin IP、別ホスト名、直アクセス用の経路が残っている場合は、そこから迂回される可能性があります。この点は後半で分けて確認します。 Basic認証とAccessの使い分け Basic認証は、origin側でIDとパスワードを確認する方法です。nginxやApacheで設定でき、Cloudflareを使わない環境でも動きます。短期間の簡単な保護や、自分だけが見るページなら今でも選択肢になります。 一方で、確認相手へ見せる運用になると、Basic認証には少し面倒なところがあります。 IDとパスワードを相手へ送る必要がある 複数人へ同じパスワードを共有しがち 確認が終わった人だけ外す運用がやりにくい ブラウザ標準の認証ダイアログが確認用として少し硬い Cloudflare Accessなら、確認してほしい人のメールアドレスをpolicyに追加します。確認が終わったら、そのメールアドレスを外します。共通パスワードを配って後から変更するよりも、人単位の出し入れがしやすくなります。 もちろん、AccessがBasic認証を常に置き換えるわけではありません。Cloudflareを使っていない環境、サーバー内だけで完結したい環境、単純な一時保護ならBasic認証の方が早いこともあります。 すでにCloudflareをCDN / proxyとして使っていて、メールアドレス単位で少人数に見せたい。そういう準備中サイトでは、Accessの方が自然に扱える場面があります。 Tunnelは道、Accessは認証の関門 Cloudflare TunnelとCloudflare Accessは、役割を分けて考えると混乱しにくくなります。 Cloudflare Tunnelは、ローカルサーバーやprivateなoriginをCloudflareへつなぐ道です。たとえばローカルでHugo previewを動かしているなら、Tunnel側では次のような対応を作ります。 preview.araisun.com -> http://localhost:1313 この設定を作ると、preview.araisun.comからローカルのHugo previewへ届く道ができます。Tunnelの作成、public hostname、DNS、cloudflaredの常駐化などはCloudflare Tunnelの記事 で扱っているので、ここでは広げません。 Accessは、その道の手前に置く認証の関門です。preview.araisun.comに来た人をCloudflare側で止め、メールアドレスとOne-time PINで確認します。許可した人だけをTunnelの先へ通し、Hugo previewを見せます。 ...

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 対話形式で進める場合は、次のように選びます。 ...

AIコーディングエージェントに複数の作業を同時に任せたい場面があります。 たとえば、片方ではUIを直し、もう片方ではテストを直す。あるいは、A案とB案を別々に試す。こういうとき、同じ作業ディレクトリで同時に編集させると、未コミット変更やブランチ切り替え、同じファイルの編集が絡んでかなり危なっかしくなります。 そこで使えるのが git worktree です。 この記事では、1つのローカルリポジトリから複数の作業ディレクトリを作り、feature/new-feature-a と feature/new-feature-b を別々に進める流れを、実際のコマンドと結果で確認します。 git worktree とは git worktree は、1つのGitリポジトリに複数の作業ディレクトリを紐づける機能です。 普通は1つのリポジトリに1つの作業ディレクトリがあり、その中で git switch や git checkout を使ってブランチを切り替えます。 一方、git worktree を使うと、ブランチごとに作業ディレクトリそのものを分けられます。 /tmp/worktree-demo は main /tmp/worktree-demo-a は feature/new-feature-a /tmp/worktree-demo-b は feature/new-feature-b というように、別々の場所で別々のブランチを同時に開けます。 git checkout との違い git checkout や git switch は、今いる作業ディレクトリの中身を別ブランチへ切り替える操作です。 作業途中の変更があると、切り替え時に止められたり、stashやコミットが必要になったりします。 git worktree は、ブランチを切り替えるのではなく、作業ディレクトリを増やします。なので、main の作業場所を残したまま、A用、B用の作業場所を別に用意できます。 AIエージェントに並列で頼む場合は、この差がかなり大きいです。 検証用リポジトリを作る 今回はブログ本体のリポジトリではなく、/tmp に捨てリポジトリを作って試します。 cd /tmp mkdir worktree-demo cd worktree-demo git init -b main printf '# worktree demo\n' > README.md git add README.md git -c user.name='Demo User' -c user.email='[email protected]' commit -m 'initial commit' ここまでで main ブランチに最初のコミットが1つある状態になります。 ...