AIエージェント開発における「雰囲気」の課題
長らくWeb開発コミュニティでは、技術選択が客観的な証拠ではなく「雰囲気」でなされる傾向がありました。フレームワークが「爆速」であるとか、ツールが「開発を劇的に加速させる」といった主張が、具体的な根拠なしに行われることが少なくありませんでした。これは、開発者体験(DX)への好みが背景にあったと考えられます。
「エージェント時代においても、フロントエンドは『エージェントにとってより良い』という理由だけで書き直されているが、その根拠は不明確なことが多い。」
Nolan Lawson氏の指摘では、AIエージェントがコードを生成する「エージェント時代」になっても、この「雰囲気ベース」の傾向は変わらないようです。エージェントが「より少ない間違いで、より速く」コードを生成するという主張が、依然としてベンチマークなしに行われている点に懸念を示しています。私自身もClaude Codeを使ってバイブコーディングを実践していますが、その裏付けとなるデータは常に意識しています。
Pokémonアプリを使ったベンチマークの実施
こうした状況に対し、Lawson氏はPokémon APIを利用した小規模ながらも非自明なアプリケーションを設計し、AIエージェントにJavaScriptフレームワーク(Next.js、Nuxt、SvelteKitなど)を使って開発させるベンチマークを実施しました。評価項目は多岐にわたり、以下の要素が含まれています。
- 開発時間
- 消費トークン数
- コード行数
- Lighthouseスコア(パフォーマンスおよびアクセシビリティ)
AIエージェントには、特定のCSS手法(Tailwind、Bootstrapなどのコンポーネントフレームワークは除く)や厳密なアーキテクチャ(SSR vs CSR)は指定せず、最新版のフレームワークを使用するよう指示されました。これは、フレームワーク間の公平な比較を目指すためです。
| 評価項目 | 測定対象 | 意図 |
|---|---|---|
| 開発時間 | エージェントがタスクを完了するまでの時間 | 人間による開発との比較可能性 |
| 消費トークン数 | エージェントが生成に要したトークン量 | コスト効率、生成の複雑さ |
| コード行数 | 生成されたコードの総行数 | コードの簡潔さ、保守性 |
| Lighthouseスコア | パフォーマンス、アクセシビリティ | ユーザー体験、SEO、Web標準準拠 |
この実験を通じて、Lawson氏はLLMの生成結果が「非常に確率的(stochastic)」であるという重要な知見を得たと述べています。これは、AIエージェントによる開発成果が毎回同じになるとは限らないという現実を示唆しています。
AIの信頼性と倫理的な課題
AIエージェントの確率的な性質は、その信頼性や倫理的な側面に深く関わってきます。例えば、AIが生成したコードやコンテンツが常に期待通りであるとは限りません。
意図しない脆弱性が生まれたり、予期せぬ挙動を引き起こしたりするリスクも考えられます。Lawson氏のベンチマークは、こうした潜在的な「AIコスト」を具体的に示す試みと言えるでしょう。
「ブラジルの労働裁判所は、裁判書類に意図的に隠されたプロンプトインジェクションコマンドを埋め込んだ弁護士2名に制裁金を科した。」 (Hacker News (API))
参考記事では、AIの倫理とリスクに関する具体的な事例が紹介されています。ブラジルでは、AIシステムが審査する裁判書類に弁護士がプロンプトインジェクションを仕込み、制裁を受けたケースも報告されています(Hacker News (API))。
また、Theranosの内部告発者であるTyler Shultz氏は、「AIブームは人々を欺く絶好の機会だ」と警鐘を鳴らしています(TechCrunch – AI)。AIが社会に深く浸透する中で、その不確実性や悪用リスクへの対策は、技術開発と並行して喫緊の課題となっています。
エンジニア目線で見ると:エージェント生成コードの「品質」を見極める視点
今回のベンチマーク結果はまだ公開されていませんが、Nolan Lawson氏が提唱する「エージェント時代の『雰囲気ベース』開発からの脱却」は非常に共感できます。普段Claude Codeを使いこなしている私から見ても、AIが生成するコードの品質は、プロンプトの出し方や使用するライブラリ・フレームワークによって大きく変動すると感じます。特に、今回のベンチマークで示されているLighthouseスコアは、実際にユーザーが体験する品質を客観的に示す指標として非常に重要です。
AIエージェントが生成したコードをそのままプロダクションに投入する際には、単に「動くか」だけでなく、「パフォーマンスは十分か」「アクセシビリティは確保されているか」「セキュリティ上の脆弱性はないか」といった多角的な評価が不可欠です。生成されたコードの「品質」を数値として可視化するベンチマークは、これまでの開発者が手作業で行っていた品質保証プロセスをAI時代に最適化する上で、非常に有効なアプローチではないでしょうか。
自分の個人プロダクトでも、AI生成コードの品質管理にこうしたベンチマークを組み込むことを試してみたいと考えます。特に、GCPのCloud Runで運用しているサービスであれば、Lighthouseを用いた定期的なパフォーマンステストを自動化する仕組みも検討しやすいかもしれません。