エージェントに「確かめた証拠」を出させる　画面を撮らせて確認させるやり方

コーディングエージェントに画面の修正を頼むと、「直しました」という返事が返ってくる。だが本当に直ったのかどうかは、結局こちらがブラウザを開いて確かめることになる。この確認の手間をエージェント自身に任せてしまおう、という考え方がある。米国のコーディングエージェント「Amp」の開発陣が公開している資料に、そのやり方が具体的に書かれている。Claude CodeやCodexを使っている人でも、そのまま真似できる話だ。

公式ドキュメントが勧める確かめ方

Ampの公式ドキュメントにある「プロンプトの書き方」のページには、こんな一文がある。エージェントに、自分の作業をどう確かめればいいかを伝えよ。どのコマンドやテストを走らせるのか、どのURLを開くのか、どのログを読むのか。フィードバックは人間にとってと同じくらい、エージェントにとっても役に立つ、というわけだ。

同じページには、実際のプロンプトの例も並んでいる。その一つが、あるUIコンポーネントを見て、もっとミニマルな見た目に変えてほしい、そしてURLのスクリーンショットを撮って頻繁に自分の作業を確かめてほしい、という頼み方だ。作業の指示と、確かめ方の指示がセットになっている。今のドキュメントで公式に勧められているのは、ここまでだ。

Claude Codeでの登録と頼み方

エージェントに画面を撮らせるには、ブラウザを動かす道具が要る。その一つが、マイクロソフトがGitHubでmicrosoft/playwright-mcpとして公開しているPlaywright MCPサーバーだ。公式の説明によると、Claude Codeならターミナルでclaude mcp add playwright npx @playwright/mcp@latestと打てば登録できる。

あとはプロンプトの書き方だ。たとえば「このボタンの余白を詰めて。終わったら http://localhost:3000 を開いてスクリーンショットを撮り、崩れていないか確かめてから報告して」と頼む。作業と確かめ方を一緒に渡すのがポイントになる。

頼み方のコツもAmpのドキュメントにまとまっている。「Xしてもらえますか」ではなく「Xして」とはっきり書くこと。エージェントに当てさせないこと。どのファイルを見ればいいか、どのコマンドを走らせればいいかを知っているなら書くこと。テストやビルドの走らせ方はAGENTS.mdというファイルに書いておけば、毎回説明しなくて済む。スレッドは1つの作業に1つにし、関係のないページのCSSを直させたのと同じスレッドでデータベースのマイグレーションを書かせるな、とも書いてある。

開発者ノートの「自分で直させる」

ここから先は、Ampの開発者Thorsten Ball氏のノート「Amp is now available. Here's how I use it.」の話になる。2025年5月に書かれたもので、冒頭に、かなり古いバージョンのAmpを前提にしており今の本人の使い方とは違うが記録として残す、という断り書きがある。今の公式ドキュメントで裏が取れる話ではなく、一人の開発者の当時のやり方として読んでほしい。

同氏はこのノートで、エージェントに自分の作業の結果を目で見させることを「いちばん気に入っていることの一つ」と書いている。チームではUIコンポーネントを並べたストーリーブックをローカルで常に動かしており、コンポーネントを変えたいときは、そのストーリーブックを見に行ってスクリーンショットで作業を確かめるようにエージェントに伝える。設定にPlaywright MCPサーバーを足せばできる、という。

あるときストーリーブックの既存のストーリーを更新させたところ、エージェントはスクリーンショットを撮ったあとで「変更がちゃんと表示されるようになった」と報告してきたという。ただ同氏が強調するのは、うまくいかなかったときの話だ。変更が動いていなければ、エージェントはスクリーンショットやブラウザのコンソールでエラーを見つけ、動くまでやり直す。人間がいちいち「まだ崩れてるよ」と言わなくても済む。

同氏は、確かめさせる手段を画面以外にも広げている。エージェントが書いたコードを、別の誰かが書いたものとして扱わせ、git diffを走らせて徹底的にレビューさせる。逆に、こちらが撮った画面を貼ってエージェントに読ませることもある。バグ報告のメッセージやコピーしにくいエラー文、UIの不具合の画面などだ。印を付けた二つのボタンを入れ替えて、という頼みもこなしたそうだ。Ampのドキュメントによると、CLIではCtrl+Vで画像を貼り付けられる。

安全網はgitだ。同氏は、エージェントに作業させ、良ければステージし、だめなら未ステージの変更を捨てる、という使い方をしている。

最後に責任を持つのは人間

Ampの利用規約には、出力されたコードには誤りや脆弱性が含まれうるので、本番などで使う前のレビューやテストは利用者の責任だ、という条項がある。エージェントの「できました」をそのまま信じず、確かめた証拠を出させる。それでも最後に見るのは人間だ。画面を撮らせて確かめさせるやり方は、その手間をかなり減らしてくれる。

編集部の見方

エージェントに作業を頼むとき、私たちは「何をするか」は書いても「どう確かめるか」はあまり書かない。Ampの資料が教えてくれるのは、確かめ方を一緒に渡すだけで、人が見る前にエージェント自身が崩れに気づける余地が生まれるという点だ。道具はPlaywright MCPのように公開されたもので足り、Claude CodeでもCodexでも考え方は変わらない。一方で、エージェントが自分で直す使い方は一人の開発者の古いノートが根拠で、今も同じように動くかは試して確かめたい。証拠を出させても、最後に差分を読むのは人間の仕事として残る。