エージェント型手動テスト

*[Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/) >* コーディングエージェントの定義的な特徴は、自身が作成したコードを*実行できる*点です。これが、単に検証手段もなしにコードを吐き出すだけの LLM（大規模言語モデル）よりも、コーディングエージェントがはるかに有用である理由となります。 LLM によって生成されたコードが動作するかどうかは、そのコードを実行するまで決して仮定してはいけません。 コーディングエージェントには、自身が作成したコードが意図通りに機能していることを確認したり、機能するようになるまでさらに反復して改良したりする能力があります。 エージェントに [ユニットテストの作成](https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/) を行わせることは、特にテストファースト型 TDD（テスト駆動開発）を活用することで、作成中のコードが適切に実行されていることを保証する強力な手段です。 しかし、それが唯一の有益なアプローチというわけではありません。 コードがテストを通過したからといって、意図通りに動作しているとは限りません。自動化されたテストに取り組んだ経験のある人なら誰でも、すべてのテストは合格しているにもかかわらず、コード自体には明らかな欠陥があるケースを目にしてきたはずです——起動時にサーバーをクラッシュさせたり、重要な UI 要素の表示に失敗したり、テストがカバーしきれなかった細部を見落としたりするといった問題です。 自動化されたテストは**手動テスト**の代わりにはなりません。私はリリースに組み込む前に、自分の目で機能が動作していることを確認するのが好きです。 エージェントにコードの手動テストを行わせることもまた価値があり、自動化されたテストでは見逃されていた問題を頻繁に発見することができます。 ## エージェントによる手動テストのためのメカニズム あるエージェントがコードを「手動」でテストする方法は、そのコードの内容によって異なります。 Python ライブラリの場合、有用なパターンとして `python -c "... code ..."` というものがあります。これは、他のモジュールをインポートするコードを含む Python コードの文字列（または複数行文字列）を、直接 Python インタープリタに渡すことができます。 コーディングエージェントはこのトリックにすべて慣れ親しんでおり、指示がなくても時折これを使用します。ただし、`python -c` を使用してテストするよう促すと、しばしば効果的です： `python -c` を使って、その新しい関数のいくつかのエッジケースを試してみてください。 他の言語にも同様のメカニズムがあるかもしれませんが、ない場合でも、エージェントがデモファイルを作成し、その後コンパイルして実行するのは迅速な作業です。私は時折、後で誤ってリポジトリにコミットされるのを防ぐために、`/tmp` を使用することを推奨しています。 その関数のエッジケースを試すために `/tmp` でコードを書き、その後コンパイルして実行してください。 私のプロジェクトの多くは、JSON API を備えた Web アプリケーションを構築するものです。これらについては、エージェントに `curl` を使用してテストさせるよう指示しています： 開発サーバーを実行し、`curl` を使ってその新しい JSON API を探索してください。 エージェントに「探索」するように指示すると、多くの場合、新しい API のさまざまな側面を試すことになり、これにより広範囲を素早くカバーできます。 もしエージェントが手動テストを通じて動作しないものを見つけたら、私は彼らに赤/緑の TDD（テスト駆動開発 (Test-Driven Development)）で修正するよう指示します。これにより、新しいケースが恒久的な自動テストによって確実にカバードされるようになります。 ## Web UI に対するブラウザ自動化の使用 プロジェクトにインタラクティブな Web UI が含まれている場合、手動テスト手順を確立しておくことはさらに価値が高まります。 歴史的にはコードからこれらの UI をテストすることは困難でしたが、過去 10 年間で実際の Web ブラウザを自動化するシステムにおいて目覚ましい進歩が見られました。アプリケーションに対して実際の Chrome や Firefox、Safari ブラウザを実行することで、現実的な環境においてあらゆる種類の興味深い問題を発見することができます。 コーディングエージェントはこれらのツールの使い方を非常によく知っています。 現在最も強力なものは **[Playwright](https://playwright.dev/)** です。これは Microsoft によって開発されたオープンソースライブラリです。Playwright は多様な人気プログラミング言語でのバインディングを備えたフル機能の API を提供し、あらゆる主要なブラウザエンジンを自動化できます。 エージェントに対して「Playwright でテストして」と指示するだけで十分な場合があります。エージェントは最も適切な言語バインディングを選択するか、Playwright のデフォルト CLI ツールを使用します。 コーディングエージェントは専用 CLI と非常に相性が良いです。Vercel による [agent-browser](https://github.com/vercel-labs/agent-browser) は、コーディングエージェントが使用するために特別に設計された Playwright を包む包括的な CLI ラッパーです。 私のプロジェクト [Rodney](https://github.com/simonw/rodney) も同様の目的を果たしますが、こちらは Chrome DevTools Protocol（Chrome 開発者ツールプロトコル）を使用して Chrome のインスタンスを直接制御します。 Rodney を使用してものをテストするために私が使用する例のプロンプトは以下の通りです： 開発サーバーを起動し、その後 `uvx rodney --help` を使用して新しいホームページをテストし、スクリーンショットを確認してメニューが正しい場所にあるか確認してください このプロンプトには3つのコツがあります: - 「use uvx rodney --help」と言うことで、エージェントは [uvx](https://docs.astral.sh/uv/guides/tools/) パッケージ管理ツールを介して `rodney --help` を実行します。これにより、Rodney は初回呼び出し時に自動的にインストールされます。 - `rodney --help` コマンドは、エージェントがツールの理解と使用に必要なすべての情報を得られるように特別に設計されています。こちらがそのヘルプテキストです [that help text](https://github.com/simonw/rodney/blob/main/help.txt)。 - 「look at screenshots」と言うことで、エージェントに対して rodney のスクリーンショットコマンドを使用するよう示唆し、生成された画像ファイルに対して自身のビジョン機能を活用してページの視覚的な外観を評価できることを思い出させます。 これは、短いプロンプトに組み込まれた相当量のマニュアルテストです！ Rodney や同様のツールは、読み込まれたサイトでの JavaScript 実行からスクロール、クリック、入力、さらにはページのアクセシビリティツリー（accessibility tree）の読み取りに至るまで、幅広い機能を提供します。 他の形式の手動テストと同様に、ブラウザ自動化によって発見され修正された問題は、恒久的な自動テストにも追加できます。 過去に多くの開発者が、ブラウザの自動テストが「フラッキィ（flakiness：不安定さ）」で知られているという評判から、過度な自動テストを避けてきました。ページの HTML に対する最小限の変更でも、テストの連鎖的な失敗という厄介な事態を引き起こす可能性があるからです。 コーディングエージェントにこれらのテストを長期的に維持させることで、Web インターフェースの設計変更に対しても、それらを最新の状態に保つ際に伴う摩擦を大幅に軽減できます。 ## Showboat でノートを取らせる エージェントに手動でコードを検証させることで追加の問題を発見できるほか、コードのドキュメント作成やテスト実施方法のデモンストレーションに役立つ成果物を作成するためにも利用可能です。 エージェントが「作業過程を見せる」ことへの挑戦に私は魅了されています。デモや文書化された実験を確認できることは、与えられた課題をエージェントが網羅的に解決したことを確認する非常に有用な手段です。 私は、アジェンティックな手動テストのフローを捉えたドキュメントを構築しやすくするために [Showboat](https://github.com/simonw/showboat) を開発しました。 私が頻繁に使用するプロンプトは以下の通りです: `uvx showboat --help` を実行し、その後 `notes/api-demo.md` という名前の Showboat ドキュメントを作成して、新しい API のテストとドキュメント作成に使用してください。 前述の Rodney と同様に、showboat --help コマンドはエージェントに対して Showboat が何であるか、およびその使用方法を教えます。以下が [そのヘルプテキスト全文](https://github.com/simonw/showboat/blob/main/help.txt) です。 Showboat の 3 つのコマンドは note, exec, image です。 note は Markdown 形式のノートを Showboat ドキュメントに追加します。exec はコマンドを記録し、その後そのコマンドを実行してその出力を記録します。image はドキュメントに画像を追加するもので、Rodney を使用して取得した Web アプリケーションのスクリーンショットなどに役立ちます。 exec コマンドはこれらの中で最も重要であり、実行されたコマンドとその結果の出力を記録するものです。これにより、エージェントが何を行い、どのような結果を得たかが明確になり、エージェントが「起こったと希望した内容」を文書に書き込むという不正行為を防ぐように設計されています。 私は、Showboat パターンが、エージェントセッション中に達成された作業を文書化するのに非常に効果的であることを発見しています。このパターンがより広範なツール群でも採用されるようになることを期待しています。 Tags: [playwright](https://simonwillison.net/tags/playwright), [testing](https://simonwillison.net/tags/testing), [agentic-engineering](https://simonwillison.net/tags/agentic-engineering), [ai](https://simonwillison.net/tags/ai), [llms](https://simonwillison.net/tags/llms), [coding-agents](https://simonwillison.net/tags/coding-agents), [ai-assisted-programming](https://simonwillison.net/tags/ai-assisted-programming), [rodney](https://simonwillison.net/tags/rodney), [showboat](https://simonwillison.net/tags/showboat)

エージェント型手動テスト

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト