OpenAI Codexのおかげで、数時間でPyTestのFixturesをRubyに持ち込めた

２年くらい前に、「PyTestのFixturesみたいなのがRubyにあったらいいんだけどなー」と思ってsmartestというテストランナーを試作してたのだけど、時間もなくまともなAIもなく、結局リポジトリを作って数ファイルコミットして中途半端に何も出来上がっていない状態になっていた。

そもそも当時なんで独自のテストランナーが欲しくなったかと言うと、きっかけはPlaywright Test Runnerの紹介動画だ。

自動文字起こしのトランスクリプトだとこのように説明されている。

the big question is why did we create another yet another testing framework and honestly we did not want to um we tried them all. We tried Mocha, we tried the jest and the but it turned out that none of them really worked for us. And I think that the reason is that historically JavaScript test frameworks were built for unit testing but end to end testing has this unique set of challenges and we actually built playright test to address these challenges. So what are these challenges? Things like for example out of the box cross browser support. You don't need to set up any plugins or do any mess with the configuration. It just works. Parallelization for example, well, [clears throat] we know how to run things and how to reuse things in browser efficiently. So, we can run things really fast and so do isolation. Like in unit tests, you usually do isolation on the NodeJS side. And we can and we have to isolate test inside the browser. And there are way better ways to isolate things in browser. And uh last but not least, we actually want to have a crazy level of flexibility for our end to end tests and we were really impressed by pytest fixtures and we didn't see anything like that in JavaScript world. So we implemented these ideas of uh fixtures in JavaScript and in form of playright test.

雑に要約すると、

  • Playwrightテストは、べつに作りたくて作ったわけではなく、既存の単体テスト用のテストランナーではまったくフィットしなかったのでE2Eテストに特化したものを作ることにした。
  • PyTestのフィクスチャに感銘を受けて、既存のJavaScriptテストランナーでそれを実装したものがなかったので取り入れた

と説明されている。ちなみに2026年現在においてはVitestのcontextがあるが、これはPlaywrightが由来っぽいことが明記されている。

Test Context | Guide | Vitest

Test Context Inspired by Playwright Fixtures, Vitest's test context allows you to define utils, states, and fixtures that can be used in your tests.

Railsを本業にテストを書いている人は、RSpecもしくはMinitest＋Capybaraで不安定なテストを書いている。これはおそらく10年くらい変わっていない。そうなると、このPlaywrightの取り組みはかなりゲームチェンジになるのでは？とおもってテストランナーを作ってみたいと思ったわけだ。

ChatGPTに雑に聞いてみた

2年くらい停滞していたテストランナー開発について、GPT-5.5が登場してさらに賢くなったなーという実感があったので、なんとなくChatGPTに聞いてみた。

  • Vitestのtest-contextやpytestのfixturesのようにブロック引数でフィクスチャを与えるような書き方ができる
  • describeやcontextを必須とせずトップレベルでテストを書ける

あたりの機能性のあるテストライブラリがほしいよーという内容を、具体的なサンプルコードや機能性を25行くらいインプットしたプロンプト

...

...

...

という感じで、５，６ターンしているうちに概要設計ができあがってきちゃったわけだ。↑の画像には書いていないが、1000行規模のコードで具体的な説明をかなり詳細に書いてくれていて、「あー、たしかにこれならできそうだなー」という実感が強烈に持てた。

ChatGPTに設計書を書かせてOpenAI Codexで実装する

これならできそうだーという実感を持てたところで、ChatGPTにその設計書をアウトプットさせてOpenAI Codex (gpt-5.5 xhigh)で一気に実装させた。

テストランナーが正しく動いていることを確認するテストもそのテストランナーベースで書かせて、ドキュメンテーションサイトもDocusaurusで作らせた。

smartest-rb.vercel.app

さらに、この内容が実現可能な説明になっていることもテストさせるようにした。(AIコーディングの品質担保もだんだん慣れてきたw)

そして、既存テストに影響をあたえずブラウザテストを簡単に書く方法もできあがってしまった

テストフォルダが testやspecだとMinitestやRSpecと衝突して、既存テストのconfigを変えないと導入できないので不都合だ。そうならないように、自動ロードされるテストフォルダは ライブラリ名と同じ smartest/ 配下に限定し、テストの実行コマンドも bundle exec smartest path/to/test.rb のようなコマンドを用意して、Playwright testくらいお手軽にブラウザテストを書けるテストランナーができてしまった!!

smartest-rb.vercel.app

おそらくここまでの制作時間は通算4時間くらい。

image

我ながら、これは結構最高な使い勝手と言えそう。

Google検索で出るようにするのもChatGPTに頼るとよさそう

PyTestのRuby版として認知させようとしても "pytest fixtures ruby" などのGoogle検索で出るようにするにはコツがいる。

...

AI自身にも検索させて「出ませんねぇ」とわからせたうえで、今回のライブラリの存在をわからせて

最後に「これどうやったら検索結果に出るようになるん？」と聞けば、いろいろ対策を教えてくれた。

改善項目が12個出されてきたので、それをfeedback.mdっていうファイルに書き出させて、それをOpenAI Codexとともに解消していくと、1日後には検索結果にAI要約でsmartestが出るようになった!!

今は、 "smartest rubygems" で↓のサイトが出ないのに対応をしていたりもする。

rubygems.org

smarter_csvという別のGemが検索結果に出てきているし、もしかして "smarter_csv rubygems" と言われている。これが数日後にはどうなるかな...

キーワードの取り合い的な攻めたSEOだと専門家に頼む必要はあるのかもわからんけど、検索結果に出ないのを出るようにしたいだけならChatGPTに聞けば十分ということが改めてわかってしまったのであった...。

AIエージェントで言語の壁は崩せる

以前にデブサミ2025でこんな話をしたのだけど、

現在においてはAIエージェントのコーディングのおかげで、他言語のフレームワークのエッセンスを自分が使っている言語のフレームワークに取り入れることは非常に容易になった。

Ruby on Railsの代替フレームワークが出てきたとて既存のRailsで作っちゃった製品はそう簡単に移行できないので、他の言語のいいところをRubyに取り込むのは結構アリだなと改めて思ったのであった。

画面操作仕様をAIエージェントと一緒に考えるなら、FigmaよりもAstro+HTML+CSSが最高なのでは説

まえおき

最近、思い立ったスマホアプリのUI設計とか機能設計とかをClaude Codeでいろいろ試している。

ちょっと前までは、FigmaとかSketchとかで画面イメージを作ってからそれをAIエージェントになんとか読ませて実装する、という流れでやっていたわけだけど、なんかそろそろpencil.devみたいなイケイケツールも出てきたくらいだからAIエージェントと壁打ちしながらUI/UX設計をやりたいものだ。

FigmaのMCPを使うとできるのか？とかも考えていたが、なんかどうもしっくり来なかった。

AIに図を書かせるならHTMLが意外といいらしい

少し前に仕事でドキュメントをClaudeとChatGPTに書かせていたときの話。

Markdownベースで提案書を書いていく中で、

  • 業務フローの概要説明
  • メリットデメリットをいらすとやの絵も効果的に使って挿絵
  • GitHubフローの概念説明

みたいな図をラクして描けないかなぁと考えていたことがある。

GeminiのNano Bananaもだいぶ良くなってきたとはいえまだ「いかにもGeminiで作ったな」って感じの図なので微妙。SVGを生成させるか、Mermaidか、MCPで何かできるのか、 などいろいろ調べていたときに、たまたまこの記事を見つけた↓

tech-lab.sios.jp

そうか、iframeでHTML+CSSで図を描かせたらいいのか！と。確かにこの方法は速くて割と的確な図を描いてくれる。

言うなれば、 AIエージェントの思考回路をアウトプットするのに、HTML+CSSはとても素直な表現手段たりえる ということだ。

デザインシステムを食わせると、いい感じのドキュメント、いい感じの図になる

横道をさらにそれるが、Markdown形式でドキュメントを書かせていること自体にも疑問を持つようになった。AIエージェントが素直に表現できるのがHTMLなのであれば、それよりも表現能力の低いMarkdownをアウトプットしてPDFにする意味なくね？と。

そして、企画の提案書をAstro+HTMLで作らせてみると、意外とこれがいい感じだった。ただ、図のトーンや文書のトーンは、何も指示しないとBootstrapぽくなってみたり、謎の立体的な図がいっぱいになったりするので、流石にここはどうにかしたい。

◯◯のサイトみたいに、って指示を最初は使ってたけど、それはすなわちデザインシステムを指示してるわけなので、

note.com

こういうサイトから取ってきて、デザインシステムのコンポーネントのサイトURLをペタっとプロンプトに貼って、AIエージェントに指示すれば、だいぶ見た目がいい感じになる。

スマホアプリの画面操作仕様だって同じ

今回あらためて、

  • HTML+CSSでUIを書かせて, iframeでそれをそのまま埋め込む
  • 画面イメージの図はMaterial 3 webのコンポーネントで、ドキュメンテーション自体はAtlassianデザインシステムで、Astro製のドキュメンテーションサイトを作るように指示

ということを画面操作仕様でやってみると、これが思っていたよりだいぶ良かった。

何がよかったって、

画面操作を検討するときに、実際にUIがそのまま動くのだ。フロントエンド開発のStorybookみたいなもんではあるのだけど、コンポーネント単位ではなく画面操作単位でそういうことができる。

今までのやり方だと

  • Sketchで画面を作る
  • AIエージェント向けにドキュメントや長大なプロンプトを書く
  • AIエージェントに実装してもらう

だったので、画面を動かして試せるのは実装が終わった後になるので、実装指示が悪かったりすると全然UI議論に行き着かないというのが大きな問題としてあった。画面操作仕様をHTMLで書かせる今回のやり方なら、いわゆる前工程で画面のUIの壁打ちができるので、とても効率が良い。雰囲気だけで言うと、ProttってサービスがAIネイティブになった感じ。

UIの壁打ちのみならず、チューニングもできる

ちらっと書いた通り、このHTML+CSSで画面仕様を出すというのは、単なる利便性と言うよりは、 AIが考えていることを正確に効率よくアウトプット している側面が大きい。なので人間が考えることをより支援して、より正確にフィードバックが行える可能性を示唆している。

今回作ろうとしているアプリは、ドキュメントスキャナーのアプリなので、台形補正だったり画像の補正アルゴリズムあたりが大事だ。

いろんなパターンの画像でうまくできているかを、１こ１こ開くのはとても大変なので、こんな感じでサイトでそれぞれのstepの成果物を展示するようにしておくと、アプリの複雑な実装を入れる前に、macOSのOpenCVベースでどういう処理をするとどうなる、というのをいろんな画像パターンで見て、計画をかなり綿密にレビューすることができる。

ようするに、画面操作仕様をHTMLにしたことで起きた変化とは..

もともとなんでFigma MCPが微妙だなーと思ってたかというと、このあたりのAIが考えていることがより明確になるなどの実感が皆無だったことだろう。

MarkdownやConfluenceでドキュメントを書いているとき、 Claude Codeにいろいろ考えさせているはずなのに、 その思考の一部しかドキュメントにアウトプットされていない というのが意外と気づくのに時間がかかっていたわけだ。

もちろんMarkdownにも良いところはあって、「人間が読みやすい」というのは最大の利点だ。ただ、やはり百聞は一見にしかずで、テキストで全部を伝えるのはAIでも難しい。壁打ちをするにおいては、AIエージェントが自身の考えを正確に早くアウトプットできる＆人間が視覚的に簡単に理解できる方向に寄せたほうが、設計品質は上げることができるだろう。

繰り返しになるが、 AIが考えていることをほぼそのままdumpできる 手段こそ、HTML+CSSなわけだ。

このHTML+CSS / Astroという構成は、Markdownと同様にコンテンツはテキストベースなので、GitHubで同一のリポジトリで管理することは容易だ。仕様とUIが分離しないよう、ドキュメントと実装を行き来することも簡単にできるし、ドキュメンテーションサイトはVercelで簡単にデプロイできるので、他の人にこんなものを作ろうとしていると説明する材料としてもとても有用だ。

ところでこの文章はAIが書いてるの？

ChatGPTにXの投稿を要約させて書いてみました。でも全然だめだったので、結局 YusukeIwaki が手で書いていますw

AIに個人エンジニアブログを代行で書かせるのはまだ少し時代が追いついてないかなという感じする。

MateBook X (2017) に ChromeOS Flex を入れたら、わりと「AI時代の開発端末」になりそう

過去に12インチ MacBook (2017) を絶賛した記事を書いた。

yusukeiwaki.hatenablog.com

どこででもRSpecが書けてローカル環境でデバッグも不自由なくできて、SketchやKeynoteも使えて、キーボードが超低クオリティであることを除けばなかなかに良かった。

その後の時間の経過とともに、12インチMacbookはスペック不足となり、その後継も出ないまま今に至っていて、私もここ数年はMacbook Airを使っている。Airとは名ばかりで全然軽くはないのだが、他に選択肢がないので仕方ない。

ところがどっこい、最近、謎の衝動買いで、12インチMacbook のコピー商品とも言えるMatebook Xを中古で入手した。そこにChromeOS Flexを入れてみると、割と良かったのでその話。

正直、「これ一台で何でもやるぞ」という期待で見ると粗は目立つが、AIコーディングのお供だと役割を絞れば、評価が一気に変わる。所詮は「12インチ MacBook のコピー製品」だったはずが、実はキーボードが本家よりご立派だし、キーピッチはほぼ完全にMacbookだし、むしろ本家よりも(OSがWindowsじゃなければ)格段に優れているではないか！！と最近気づいてしまったのであるw

AIコーディング専用機じゃなければ確かに価値はない

Matebookシリーズが全般的にそうみたいなのだけど、ChromeOS Flexをインストールして使おうとすると、まぁまぁ目立つ不具合がある

  • スピーカーが左半分しか鳴らない
  • 指紋認証は使えない
  • バッテリー持ちが1時間くらい
  • F1〜F12 + Fn の特殊キー（音量・輝度調整など）が効かない

あと、今となっては8年前くらい(大学１年生が、小学５年生のときのPCを使うくらい)の製品なので、Android Studioみたなゴツい統合開発環境を動かすにはやや不安のあるスペックだ。こんなPCで2026年にエンジニアリング活動しようと言ってもそれは完全に苦行で、まー気合いは入らないだろう。

AIコーディング専用機ならば一気に価値を取り戻す

昨今のAIコーディングでは、まともなLinuxシェルとブラウザが動けば、リッチな環境がなくても開発はできてしまう。先日紹介したPixel 8aなどはその典型だ。

yusukeiwaki.hatenablog.com

ただ、流石にスマホだけでアプリを一個書けるほど快適かというとそうではない。登山中や買い物中を除けば、基本的にはほどほどの画面で快適なキーボードで開発できたほうがいいに決まっている。

そのちょうどいいラインが、この12インチの軽い筐体、Macbookとほぼ同一のキーピッチのキーボード、Macbook 12インチよりも格段に快適な打鍵感のキーボードのMatebook Xだ。

別にスピーカーが半分鳴らなくてもGoogleアカウント同期されてるスマホでYouTube 見ればいいし、バッテリー持ちが必要ならPixel8aの方を使うしで、不具合は見過ごせる。

Windows よりも ChromeOS flex

yusukeiwaki.hatenablog.com

これは以前にも書いたが、好みの問題が大半だ。私は基本的にはマイクロソフト製品が嫌いで、とくにPowerShell は吐き気がするくらい嫌いだ。イマドキであればClaude CodeはWindowsで動くよと言われても、いざWindows機を前にするとそれだけで手が止まる。なので、中古で手に入れた瞬間にF12キーでBIOS 設定を少し変えてWindows 起動画面を一度も見ることなくChrome OSを入れたわけだが…

くだらない前置きはともかく、ChromeOS flexはAIコーディングを前提としても、非常に素晴らしい。OS自体がほとんどメモリなどのリソース食わないし、ブラウザ動作がとんでもなく軽いし、仮想マシンでDebian Linuxが素直に動く。素でDebianインストールするとよくハマる日本語フォントや日本語入力の問題も、特段何もしなくともまともに動く。もちろんDockerもLinuxネイティブで動く。

AIエージェントからみると自分はDebianの上で動かされてるだけなので、lsコマンドやsedコマンドが変な仕様だとかもなく動ける。もし仮にAIが暴れ回っても、仮想マシンの外には出られないので、ChromeOS全体がぶっ壊れるリスクはほぼない。この観点ではmacOSよりも優れた面があるかもしれない。

仕事用のAIコーディング用にしてみたら安心感が高まった

これまではMacbook一台でAIコーディングもオンライン会議も全部やってたのだが、会議中に生成AIが暴走して rm -rf / なんて打たれたら業務継続不能になる(ということはほぼないけど、不安だけは常にある)し、Zoomが調子悪くてOS再起動したいけど、裏で生成AIエージェント動いてるの止めたくない葛藤が生じるし、生成AIエージェント動かす環境は切り離したかった。

もちろんMatebook Xが軽いとはいえ1kgはあるので2台持ちのダルさは若干有る。けども、物理的に隔離したところでAIコーディングできるのはやはり安心感が大きい。

しばらくこれでやって行ってみようと思う。