背景
2025年、ついにFirefoxがCDPで自動操作できなくなり、WebDriver BiDiへの対応がどうしても必要になった。
以前から作っていたpuppeteer-rubyというライブラリでも、そのようなissueは立っていたものの、趣味の時間でpuppeteer-rubyをFirefoxだけBiDiプロトコルを使うように変えるなんてのは大変だ。
いっぽうで、Kaigi on Rails 2024の準備をしていたときから、BiDiでFirefoxを自動操作する実験的なコード自体は作っていた。
今年はコーディングエージェントが大幅に進化した１年でもあり、そろそろAI主導で何か作れるんじゃなかろうかと思い立って、10月ごろから実はPuppeteerをベースとしつつ WebDriver BiDiを実装する取り組みをしていた。また、従来のpuppeteer-rubyではスレッドベースのconcurrent-rubyを使って並列処理をしているのだけど、こいつがやっぱり時々落ちるテストの原因にもなっていることから、次つくるとしたら Fiberベースの socketry/async を使ってみたいと思っていたので、AI主導でやらせるならいけるだろうとおもって、これも採用した。また、型補完が効きやすいようにRBSとかsteepとかもどうせなら使ってやろう、ということでrbs-inlineとsteepも採用した。
できたのがこちら
puppeteer-rubyの時よりも、コードを書くのが楽なライブラリになったと思う。
Rubymineでもばっちり動くには動いた。 pic.twitter.com/KqQZjZEuqb
— Yusuke Iwaki (@yi01imagination) 2025年12月23日
で、自慢がしたいというわけでもなく、これを作るまでにあった苦労や発見を一応書き留めておきたいというのがこの記事の趣旨。
Claude CodeかCodex CLIかGemini CLIか
まずは、コーディングエージェントの選定の話から。
だいたいのAI比較記事で書かれていることもあるが、 TODOアプリやブロック崩しゲームを作らせたくらいだと本当の実力はわからない んじゃないのか？というのが実際使ってみての最初の感想。まず圧倒的にClaude Codeが優れている。そして、Codex CLIはClaude Codeではどうしてもうまくいかない部分やコードレビュー専用と割り切ればいいかんじ、といった印象を受けた。自分だけでなく、Kickflowの人 も最近似たようなことは書いてたし、他にもそのような話は聞いたこともあるので、おそらくシニアエンジニアだと概ね Claude Codeメイン + Codex CLIで細かいところを詰める、というのが2025年現在の平均的な使い方なんだろう。
ちなみに、Codexが普段遣いしづらいのは実物を見てもらえたらわかると思うが、
- docs: add Node Puppeteer API coverage doc by YusukeIwaki · Pull Request #27 · YusukeIwaki/puppeteer-bidi · GitHub
- docs: tighten README and add development guide by YusukeIwaki · Pull Request #30 · YusukeIwaki/puppeteer-bidi · GitHub
↑こういうプルリクを作ってくるのがCodex。
- Fix Page.close to properly wait for closed state by YusukeIwaki · Pull Request #24 · YusukeIwaki/puppeteer-bidi · GitHub
- feat: implement Locator API for robust element interactions by YusukeIwaki · Pull Request #40 · YusukeIwaki/puppeteer-bidi · GitHub
↑こういうプルリクを作ってくるのがClaude Code。
エンジニアとしてどちらが嬉しいかは、10人いたら10人がClaude Codeのプルリクを好むはずだ。
コードの修正をした際にも、Claude Codeは高確率で単体試験を実行してリグレッション確認をしてくれるが、Codexのほうは言わないと単体試験のリグレッション確認はしてくれない。このような挙動から、おそらく大半のエンジニアに好まれるのはClaude Codeの方だろう。
丸投げでは何も出来上がらない
これは最近Qiitaの記事でも書いた話。
人間でも、「Puppeteerのコードみて、WebDriver BiDiでFirefoxを自動操作するコードをRubyに移植して」なんて指示で完遂できるエンジニアは存在しない。
- 作業計画
- 実行
- 単体試験＆レビュー
基本的にはこの３点セットを機能ごとに繰り返しやっていけばAIを活用したコーディングはできるのだけど、特にAIコーディングで重要なのは事前レビューと、単体試験による確認だ。
普段から規模の大きなプルリクを見ているエンジニアにとっては何でもないのだが、「300行を超えるプルリクになった場合には分割をしよう」なんてルールがあるような良い環境で育ったエンジニアにとっては、おそらく1000行単位の変更のあるプルリクを繰り返し見ることは容易ではない。
いっぽうで、AIコーディングで恩恵を得ようとするならば、1000~3000行くらいの差分のプルリクでも普通にこなしていく必要がある。（あくまで私個人の感覚）
ただ、コードを突きつけられてそれをレビューするというのは基本的に苦行だ。なので、その作業負荷を減らすのがポイント。
たとえば、
- 作業方針が間違っているとどこで何やっているのか把握が難しくなるので、AI自身が把握している作業内容を語らせて、事前に作業内容のレビューをする
- 3000行のコードにバグが潜んでいてもほぼ気付けないので、壊れたら困る部分は単体テストで不具合が出ないようにガードする
などだ。
「オフショア開発」のディレクション経験とAIコーディングエージェントの扱いは似ている
ちなみに、少し横道それた話になるが、オフショア開発をしたことがあるかどうか、はAIコーディングにおいては割と重要なファクターになるかもしれない。
日本における開発委託は、よほど質の悪い会社じゃない限り、多くの場合は１から１０まで言わなくても通じる人がどこかしらにいて、そういう人が引っ張っていくので、委託する側が多少はタスク分解できていなくてもどうにかなることが多い。
一方で、オフショア開発となると話は結構違っていて、10いっても1動くかどうかという意思疎通が難しい人をなんとか使わないといけないこともあるし、そうでなくても10言って7くらい動けば御の字くらいに思っておかないといけない。どちらのケースにおいても、多少の支離滅裂でもいいから10言う努力をまず必然的にさせられるということだ。
あとは、オフショア開発では、あまりにも意思疎通が難しい人がいた場合には、別のメンバーに変えてもらうことも成功の鍵だ。当たり前の事のように思えるが、実際にそれがされず、能力に満たない初学者をひたすら使おうと頑張っている現場は意外と多い。"別のメンバーに変えてもらう"というのは、メンバーのアサインメントを変更する権限をもつ上長を特定し、あらかじめ「我々の仕事をするための能力・要件を満たしてない場合にはあなたにフィードバックしますよ」と握っておくということ。より本質的にいうと、どこかで見切りをつけて仕切り直す、そういう勘所が必要だということだ。
AIコーディングにおいても、 多少の支離滅裂でもいいから、思考に必要な情報はとにかく与える ことと、 うまくいかないときには一度セッションを作り直す という態度は非常に重要で、それをやっていないと変な推測が走ったりハルシネーションを起こしたりする。過去にオフショア開発をやっていると、これらの勘は必然的に鍛えられるので、割とすんなりAIコーディングエージェントにも順応できそうだ。
趣味のコーディングと、本当に使えるものを作るコーディングは別
AIでコーディングをすると、どうしても生産性が高まることを期待してしまう。そして、単位時間あたりのコード生成量の大きさに感動してしまう。ここまではいいのだが、 その大量生産されたコードが正しく動くことはどうやって確認できる だろう？
趣味のコーディングであれば、思いつくいくつかのユースケースを動かしてみてなんとなく動けば良いだろう。ただ、そんな精度のツールを世の中で使ってもらうことはできない。
puppeteer-bidiも初期は本家Puppeteerとは多少違ったプロトコルで動いてそうなのを許していたが、waitForNavigationを実装するときに限界が来たので、その時点から「動けばヨシ」を諦めて、忠実に移植して本家と同様のテストも全passする、テストが通らない場合には本家との動作の差分がないかを調べる、ということで真面目なソフトウェア開発をやらざるを得なくなった。
そうなると、生産性向上のためにAIを使うといった感覚はほぼなく、オフショア開発よりは思い通りに動いてくれるやつがそこにいるから便利に使わせてもらう、くらいの感覚だ。もはや趣味というか仕事をしている気分。
GPT-5.2という超人的なやつ
Claude Codeはそんなに深く考えてはくれない。良く言えば。要領がいい、効率がいい。だけど、しっかり考えて解決しないといけない問題に向き合ってくれず、テストを一旦スキップさせて終わらせようとしたり、テストをスキップさせようとしたり、テストをスキップさせようとしたり、...そんなふうに最適化されているのがClaudeだ。仕事をほどほどに早く終わらせようとすること自体はいいんだけどね。感覚的には、平均的なミドルクラスのエンジニアができなさそうなことを任せると、テストをスキップさせるなどおかしな方向に動き出すことが多い。
従来もGitHub Copilot + GPT-5を併用することでそのあたりは解決できていたのだけど、現時点においてはGPT-5.2-codexがそこに対する最適解だ。
Claude Codeは深く考えてくれないだけではなく、人間の言うことがとりあえず正しいみたいなスタンスがあるが、Codexは真実はいつも一つ！という感じなので、コードレビューの強い味方である。
たぶん、こんなかんじで質問の問いに的確に答えられる人類は、世の中に100人いるかどうかな気がするんだけど、GPT-5.2すんごい賢いぞ。 pic.twitter.com/2bMCiaxlHW
— Yusuke Iwaki (@yi01imagination) 2025年12月20日
コードレビューをさせるととても鋭い指摘がされ、自分で直してくれるため、大規模なコードでも品質高く仕上げることができる。reasoning については、 xhigh だと30分くらい考え込んでしまうこともあるので、自分の場合には high にしている。
ミドルクラスのエンジニアができなさそうな問題を与えても、勝手にテストをスキップさせたりはしないで、Puppeteerのコードを片っ端から読みに行って原因追求を深く考えるというのがCodex。15分くらいかかることもあるが、その正確性にはClaude Codeとは比じゃなく信頼ができる。
生成AIのコーディングエージェントを使うために今必要なことは...
みんなに使ってもらうようなシステムやライブラリは相変わらず時間をかけて作る必要がある。そして「経験と勘」はコーディングエージェントでもさらに必要とされている印象がある。
DDDがほどほどにわかって、テストコードを書けるような設計ができて、おかしな動きをしてるなーこれじゃ終わらんなーと思ったらセッションを一旦切って仕切り直して、管理しやすいように進捗管理させて、...
趣味で開発してたはずなのに、なんだよこれはもう仕事じゃねーか！！そんな時代になってきています、はい。
趣味で楽しくコードを書く時間、というのは今後本格的になくなっていくのかもしれない。
おまけ
なんとなく Gemini 3.0 の画像生成で、このブログ記事のアイキャッチ画像を作らせてみたら、こんな感じになった。
本採用するにはちょっと合ってないかなー、見送りで!!w
