Yadda 3.0.0: AIエージェント時代のBDD

Yadda 3.0.0がnpmに公開されました。YaddaはJavaScript向けのBDD（ビヘイビア駆動開発）ライブラリで、Cucumberと同様に自然言語の仕様を実行可能なコードに対応付けます。ただし、仕様の書き方については最初からもっと自由度が高くなるように設計されています。たとえば、「大学がコンピュータサイエンスの学位コースを提供している」「入学条件はABB」「SteveはAレベル卒業生で、物理と数学はD」「Steveがそのコースに応募すると、大学は申請を却下する」といった、より自然で読みやすい文章で実行可能な仕様を書くことができます。

Yadda 3.0の大部分は近代化作業です。CasperJS、PhantomJS、Bower、Componentなど、もはや歴史的な存在となった統合を削除し、Node専用にしました。テストスイートはnode:testに移行し、Biomeとlefthookを導入、ソースはES6構文に更新、TypeScript定義も追加されました。また、PlaywrightやPuppeteerを使った現在のサンプルも含まれています。

このリリースで特筆すべきなのは、近代化作業の大半をClaude Code（Opus 4.8）が担当したことです。Yadda 3.0のエピックはClaude自身が書き、作業を「旧機能の削除」「ツールチェーンの更新」「機械的な整形を振る舞いの変更と分離」「ソースの近代化」「API変更の調査」「サンプルとCIの更新」といった段階に細かく分けました。著者は各段階を計画した後は、基本的にClaudeに任せたそうです。ミスはごくわずかで、機械的な更新では見落としがちな微妙なエッジケースもいくつか見つけてくれました。重要な要因は、Yaddaに包括的なテストスイートがあったことと、本番コードとテストを同じステップで変更するよう依頼しなかったことです。両方を同時に変えてしまうと、グリーンなテストスイートは「正しさ」の定義ごと書き換えられる可能性があるからです。実装とテストの変更を分離することで、Claudeはより確実な外部制約を得られました。開始から公開までおよそ1日で、しかも他の作業と並行して進められました。

著者はさらに、コーディングはもはやボトルネックではないと述べます。単一の開発者が単一のエージェントと対話するのではなく、複数のエージェントを並行して動かすことを考えてみてください。すでに複数のClaude Codeセッションを走らせる、Git worktreeで隔離された作業コピーを使う、cmuxでセッション群を管理する、Claude Code Agent Viewで各セッションの状態を監視するといった方法があります。これらにより直列作業よりもはるかに速く構築できますが、著者はすぐに別の限界にぶつかりました。それは自分自身の並行作業の管理能力です。3つ、うまくいけば4つか5つのタスクを同時に進められますが、それを超えると各エージェントが何をしているのか、どの判断が下されたのか、何をレビューすべきなのかを見失い始めます。モデルもマシンも過負荷ではないのに、人間の調整が律速段階になるのです。このため、優れたオーケストレーションが次の重要なレイヤーだと著者は確信しています。同僚のMarco氏もほぼ同じ進化を経験しており、AIをオートコンプリートとして使い、次に監視付きエージェント、さらに並列エージェントへと進み、最終的に認知負荷が制約になると気づきました。そこで同氏はOttoというClaude Codeとworktree向けのオーケストレーションUIを構築し、実装・レビュー・フィードバック・ドキュメントを調整するエージェントパイプラインへと発展させています。

では、なぜ今BDDライブラリを更新するのでしょうか。著者はBDDの価値として、自然言語で要件を書くことでドメインの一貫した表現が促され、それがクラス名や関数名、API、スキーマ、UIにまで浸透する点、実行可能な仕様は従来のテストよりも製品担当者やドメイン専門家にとって理解しやすい点、機能テストの意図と実装詳細を分離する抽象レイヤーを提供する点を挙げます。従来はBDDの初期コストが高く、その見返りは後からやってくるため正当化しにくい面がありましたが、AIがその経済性を変えつつあります。会議の文字起こしをGitHubディスカッションに保存し、それを分析してwikiを更新し、wikiから要件とissueを抽出し、そのissueをコーディングエージェント群が実装・レビューするというワークフローを想像してください。wikiは「誰かがシステムがこうすべきだと考えたこと」や「以前はこうしていたこと」を教えてくれますが、システムが実際にそうしているかどうかは教えてくれません。実行可能な仕様ならそれが分かります。AIによって仕様の作成コストは劇的に下がり、人間は言語や振る舞いの正しさの確認に集中できます。一度受け入れられれば、その仕様は単なるドキュメントではなく契約になります。実装エージェントはその仕様から必要な振る舞いを理解し、テストエージェントは検証すべきことを判断し、レビューエージェントは実装を検証し、CIは継続的に確認します。BDDはもともと人間のために仕様を役立てる目的がありましたが、ソフトウェアの多くが機械によって書かれる時代には、実行可能な仕様はさらに価値を持つ可能性があります。

さらに、Yadda v3.1.0では、フィーチャー仕様をGitHub Flavored Markdownで書けるようになりました。これにより、リポジトリ内での読みやすさが向上し、プロジェクトのwikiやその他の知識成果物と自然に共存できます。同じ仕様を「# Feature」や「## Scenario」の見出しを付けたMarkdownとして書き、GitHub上では通常のドキュメントのように見せつつ、実行も可能です。Yadda 3はnpmで入手でき、ソース・ドキュメント・サンプルはGitHubで公開されています。