片手で身の回りのことを便利にしていく

Agentic Codingによってすごい勢いで身の回りが便利になっていく。Web 2.0のときにも似たような経験をした記憶があったのでいくつかのことがらを書いておく。

自分の身の回りのことが改善しやすい状況になった。昔は牧歌的な時代でAjaxによってあらゆることが便利になっていった。ブラウザ拡張を書きまくっていたし、スクレイピングも簡単なHTMLをパースするだけで済んでいた。

翻って今は技術スタックが複雑になっていて、単純にHTMLだけを取得しても必要なコンテンツは非同期で取得してからビルドされることがある。その場合はHTMLだけをパースしてもうまくいかない。Puppeteerでリクエストを読み取って画面が完全にレンダリングされるまで待つか、呼び出しているAPIを調べてそのレスポンスをパースする必要があったりする。

もう一つは簡単にアプリケーションをつくることができるようになったこと。粗製乱造のような世界は20年前にもあったと思うけど、Agentic Codingによって個人でもかなり実用的なものがつくれるようになった点は進化だなぁと思っている。

ここからは僕自身の話。元々DTMが趣味で、DAWless DTMの環境を組んだり、DAWlessで使うためにソフトウェアで楽器をつくったりしていた。DAWlessに没入した理由としては子育ての隙間時間をいい感じに消費するためだった。Digitakt IIでボタンをポチポチするだけ、OXI Oneでループをつくって KORG multi/polyのノブをいじるだけで曲をつくれるというのは、子どものミルクをあげているとき、抱っこで寝かしつけをしているとき、そういう隙間の時間を過ごすのにちょうどよかった。もちろんAudibleやPodcastを聴くということもできるし、TwitterやRSSフィードを消費するということもあるが、そういう受動的な消費行動じゃない方向で子育ての隙間時間を満たしたかった。

Agentic Codingでも同じようなことができるのではないかと思って、最近は自宅サーバーにClaude Code（個人でMax 20xを契約してる）とHappyを導入して、スマホからポチポチ操作することでいろいろなことを改善している。

表に出せる具体例としては「ぽこピーのゆめうつつのあの回」というサービスを公開している。ぽこピーのゆめうつつはランダムな話題が多くてタイトルだけでは何を話しているのかわからないという問題があった。また、JAPAN PODCAST AWARDSへのリスナー投票があり、具体的にどのエピソードがよかったかなと思い返すのにこのサービスが欲しくなってつくった。最初のデプロイ環境を整えるところだけはPCでやって、それ以降の画面の改善はすべて片手でスマホをポチポチするだけでやっている。

人によっては自宅サーバーにSSHしてClaude Codeをそのまま起動することもあるのだろうし、多くの場合はそのほうが便利なことも多いと思う。HappyもClaude Codeをラップしているので、Claude Codeに新しい機能が増えたときにリレーサーバーが新しいレスポンスに対応していなくて変なことになることもある。ただ僕としてはSSHしてtmuxでセッションを復帰してスマホをタップするよりも、もう少しアバウトに操作したかったのでHappyを選択することにした。

Happyを使ったスマホ片手の開発を円滑に進めるために、いくつものルールを徹底している。

まず、実行するタスクをすべてmiseのタスクとして定義すること。利用するCLIなどを同じコマンドで常に実行できるようにしておくことで、同じタスクを実行すれば常に同じ結果が返ってくるようになる。これはかなり便利。MCPを使うこともあるが、やることを明確にするとMCPよりもタスクランナーの定義のほうが少ない記述で済むことがある。MCPがよい場面もあるがそれはまた今度...。

次に、特にE2EテストとVRTのテストをたくさん書くこと。基本的には複数のセッションでどんどんコードを書かせてデプロイしていくので、リグレッションしたときにgit bisectを使って原因を特定できるのが便利。テストが充実していれば、どのコミットで問題が入り込んだのかをすぐに突き止められる。

そして、ドキュメントを維持すること。自分の開発の仕方をドキュメントに落とし込んでおくことと、普段実行しているコマンドをタスクランナーに定義しておくことで、AIに対して「こうしてって言ったじゃん」が発生しなくなるのがよい。

テストとは少し違う話だが、以前あったこととしては、デプロイやテストをすべてAIが自律的に行えるようにしておいたおかげで、ワーカーとWebアプリケーションの疎通ができないインシデントが発生したときにAI自身がログを読み取り、原因のリビジョンを特定して、mainからhotfixの修正を加えてpushしてデプロイ、デプロイ後の外形からのリビジョンチェック（ヘルスチェック用のエンドポイントに今動いているリビジョンのハッシュを返すようにしている）をして、サービスがそれぞれ疎通できるようになってサービスが復旧するところまでできた。AIが自律的にサービスを復旧させることができる体験は本当にもう一人の自分がいる感覚になる。

ドキュメントを維持することの重要さは当たり前のように聞こえるが、とにかく古いドキュメントは削除したり更新したりしていくのが大事。テストについても同様で、古くなったり何度も実行されて安定している機能のテストはどんどん削除していく。これを僕は「賞味期限切れのテスト」と呼んでいるが、役目を終えたテストを残しておくとかえってノイズになる。テストもまたドキュメントの一種であるというのを今あらためて噛み締めている。

E2EやVRTもかなりよい。サービスの更新をするたびにサーバーを立ち上げて人間が動作確認をするのは手間がかかりすぎるので、ここもある程度は自動化するのがよいと思う。

それでも、開発中の機能の動作や画面がどうなっているのかを自分の目で確認したいことはある。この課題に対してIrisというiOSアプリケーションをリリースした。IrisはE2Eで暗号化された状態で画像の送受信ができるアプリケーション。たとえば先ほどの自宅サーバーで作業している変更について、AIにサーバーを起動させてPlaywrightでアクセスさせ、スクリーンショットを取らせて画像を送信するというようなことができる。スマホを片手で操作している身としてはこういう仕組みはいるよなぁと思って、これもスマホ片手でつくった。さすがにiOSビルドの設定のところだけはmacOSが必要だったけど、Xcode Cloudのワークフローの設定やリレーサーバーの設定ができてからは、ほぼスマホ片手でアプリケーションを仕上げた。知らない間にXcode CloudとTestFlightが便利になっていてこれは大変ありがたい。スマホで修正してコミットしてpushすると勝手にTestFlightで配信されてくるので、お風呂前にやっておいた指示が、子どもをお風呂に入れてあがってくると新しいバージョンとして配信されているみたいなことが起きる。すごく便利。

このアプリケーションのおかげで、リモートでサーバーを起動してそこにアクセスするまでもなく、簡単に画面の結果を確認できる。ガッツリ仕事で使うとなると少し機能が足りないところもあるが、個人で開発をしていてアジリティが高い状態なら問題なく使えると思う。もし興味があったら使ってみてほしい（買い切りの有料だけど）。