検証できる/goal条件の作り方

ブラウザーゲームで対局するようエージェントに頼んだとします。何手か進めて盤面を説明すると、応答が止まりました。対局はまだ続いています。"続けて"と送ると、また駒を動かして、次のメッセージを待ちます。気づけば、いちばん単調な操作をしているのはあなたです。

Goalは、完了条件を付けてエージェントに与える目標です。/goalコマンドで設定します。たとえば"ページに対局終了と表示されるまで、両方の側を交互に指してください"のように伝えます。エージェントの作業ターンが終わるたびに、別のモデルが会話を読み、目標を達成したか確認します。未達成なら、"続けて"と伝えなくても作業が続きます。結果を待てるようになりますが、障害やエラーによって途中で止まることはあります。

まずゲーム用の条件を見てから、検索、フォーム、モバイルページの目標を作ります。それぞれに明確な結果と確認方法を用意します。エージェントに条件を書いてもらう方法や、本当に完了した状態と、結果が出ないまま停止した状態を見分ける方法も扱います。

/goalが作業を続ける仕組み

ゲームの例では、混同しやすい2つの仕組みが動いています。1つはブラウザー上でクリックしたり、手を入力したり、ページの表示を読んだりします。もう1つはクリックせず、会話全体を読んで作業を続けるかどうかを判断します。

前者はMCP経由であらかじめ接続したブラウザーツールのPlaywrightです。後者は/goalコマンドで起動します。Playwrightは駒を動かし、/goalは止めるタイミングを判断します。外から見ると同じ動きに見えても、役割は別です。

大切なのは、マウスをクリックするたびに評価するのではなく、エージェントの作業ターン、つまり応答全体が終わってから評価する点です。1つのターン内で、駒を動かし、結果を読み、その内容に反応するなど、複数の操作を続けて行うことがあります。評価できる情報がそろってから、/goalが動きます。

ゲームを実行できる状態にする

条件を設定する前に、例が動く状態であることを確認します。既知のアドレスでページが開くこと、ゲームを操作するツール（ここでもPlaywright）がすでに接続されていること、対局が終わったかどうか分かる目印がページにあることです。

この例ではdata属性を使います。対局中はdata-game-over="false"、終了後はdata-game-over="true"です。この仕様を決めるのはゲームページの作者です。エージェントが考案するのではなく、ページから読み取ります。

確認するには、ページを開いて属性値を読むようエージェントに頼みます。始まったばかりの対局ならfalseが返ります。それで問題ありません。開始時に期待される値です。

ページに属性がなければ、まだ目標を設定する段階ではありません。条件に使えるのは実際に読み取れる情報だけです。まず目印そのものを戻しましょう。その場で代わりを考え出すのは避けてください。例の準備ができたら、対局の途中で判定基準を変えたり、デモを早く終えるためだけにタイマーを追加したりしないでください。条件は最初から最後まで同じです。

目標を実行する

では、コマンドを使います。この例では、次のような条件を指定できます。

/goal ページのインターフェースから両方の側を交互に指してください。
手を指すたびにdata-game-overを読み取り、ページに見える内容を示してください。
data-game-overがtrueになったら、対局は終了です。
40手指しても終了しなければ、作業を止めて、どこで行き詰まったか説明してください。
ゲームのコードは変更しないでください。

この文を要素ごとに見てみましょう。自分のタスクにも同じ要素を使えます。

• "ページのインターフェースから指してください" -会話上で実際に示せる、測定可能な操作です。
• "data-game-overがtrueになったら対局終了" -ここで実際の成果として認める唯一の条件です。評価モデルは会話からこれを探します。
• "手を指すたびに読み取り、表示する" -評価モデルが確認できるようにする事実です。この指示がなければ、確認する材料がありません。
• "40手指しても終了しなければ止めて説明する" - trueにならない場合のための別の指示です。成功の一部ではなく、成功しないまま作業を終える手段です。目標の作業量に上限を設けますが、成果の代わりにはなりません。また、これは文中の指示であって、厳密なプログラム上のタイマーではありません。これも会話をもとに評価されます。
• "ゲームのコードは変更しない" -成果を目指す途中で起きてはいけないことです。

具体的な勝者や対局の長さ、対局が終わるかどうかは、前もって分かりません。その代わり、エージェントが示すべきものは明確です。読み取ったゲームの状態と、作業を続けるか止めるかの理由です。

条件を組み立てる

"タスクは、〜したら完了"と書き始めます。続きが"すべて良くなった"だと、エージェントが意図を推測することになります。評価ではなく、目で確認できる動作に置き換えましょう。"検索をクリアすると、すべてのカードが再び表示される"のようにします。1つの成果、たとえば検索の修正を確認するためなら、複数のチェックを含めてもかまいません。

• 成果を明示する。"検索を直す"では方向しか分かりません。"名前でカードを検索でき、検索をクリアすると一覧全体が戻る"なら完了地点が分かります。
• 確認方法を書く。何を開き、何を入力し、どんな応答を期待するのかを示します。評価モデルが読めるよう、実際の結果を会話に表示することも頼みましょう。
• 変更範囲を制限する。スタイルだけを直すなら、そう伝えます。完成したゲームを確認する場合は、望む結果を得るためにコードを変更しないよう指示します。
• 成功せずに止める条件も決める。たとえば、修正と再確認を3回繰り返しても問題が残るなら、残っている問題を説明するようにします。これは作業の上限であり、タスクを完了扱いにする条件ではありません。

実行前に、必要なページ、ファイル、ツールにエージェントがアクセスできるか確認してください。条件に書くアドレスや要素名は、あなたのプロジェクトのものにします。試行回数の上限は作業を管理する助けになりますが、時間や費用を技術的に制限するものではありません。

戻る矢印に注目してください。成果にまだ届いていなければ、エージェントは次のターンに進み、問題を直して再確認できます。ただし、このサイクルを抜けたからといって、必ず成功とは限りません。障害や合意した上限に達した場合は、別に明示する必要があります。図は条件に沿った作業の流れを示しています。試行回数の上限は、エージェントと評価モデルが会話をもとに確認します。

タスク別の例を3つ見る

以下は、すでにあるページを対象にした練習用の条件です。実行前に、アドレス、データ、期待する動作を自分のプロジェクトに合わせて置き換えてください。これらは条件の例であり、実際に作業した結果の報告ではありません。

カタログの検索を直す

ローカルのカタログに"Atlas"と"Orion"のカードがあるのに、検索をクリアすると一覧が空のままだとします。"検索をちゃんと動かして"では、望む動作が分かりません。次の3つのケースを具体的に指定しましょう。

/goal http://localhost:3000/catalogの検索を修正してください。
クエリ"atlas"で"Atlas"カードが見つかり、
"zzzz-no-match"では"結果が見つかりません"と表示され、
入力欄をクリアすると元のカードがすべて戻れば完了です。
Playwrightで3つすべてのケースを確認し、クエリ、期待する結果、
実際に見えるカードまたはメッセージを会話に示してください。
最後の修正後に、3つの確認をもう一度行ってください。
検索ロジックだけを変更し、カタログのデータとスタイルは変更しないでください。
修正と確認を3回行っても問題が残る場合は、
停止して、まだ動かないケースを列挙してください。

"すべて"が大切です。カードが1つ見つかっただけでは、検索が直ったとは言えません。カタログのデータは固定されているので、カード名を変えて結果を合わせることもできません。最後にもう一度確認するのは、入力欄をクリアする修正によって検索自体が壊れる可能性があるためです。

フォームを修正せずに確認する

目標の成果を、観察結果の一覧にしてもかまいません。完成した登録フォームを確認し、修正は別途相談したいとします。その場合、問題が見つかっても、すべてのケースを確認できれば目標は完了です。

/goal プロジェクトのファイルを変更せず、Playwrightで
http://localhost:3000/signupのフォームを確認してください。
次の2つのケースを、それぞれ空のフォームから試してください。
1. 入力欄を空のまま"登録"をクリックする。
必須項目の案内が表示され、登録されないことを確認します。
2. email欄に"alex"と入力し、ほかの必須項目には有効な練習用の値を入力してから、ボタンをクリックする。
メールアドレス形式のエラーが表示され、登録されないことを確認します。
両方について、入力した内容、期待した結果、ページの表示、差異の有無が会話に報告されたら完了です。
有効なemailでフォームを送信したり、アカウントを作成したりしないでください。
ページまたは要素を開けない場合は確認を止め、未確認のケースと理由を示してください。

"フォームを確認する"と"フォームが動くようにする"は別のタスクです。この例では、エージェントが両方のケースを確認し、結果を示せば、フォームに不具合があっても報告を完了できます。一方、ページにアクセスできなければ報告は完了できません。観察の代わりに推測しても、目標は達成できません。

スマートフォンにページを収める

"モバイルで見栄えよくして"では、エージェントの判断に任せる範囲が広すぎます。対象ページ、ウィンドウサイズ、利用可能な状態に保つ要素を指定しましょう。

/goal http://localhost:3000のページスタイルを、
390x844と1440x900のウィンドウサイズに合わせて修正してください。
両方のサイズで横スクロールがなく、
見出しと"開始"ボタンがすべて表示され、重ならず、
"開始"をクリックするとゲームセクションが引き続き開けば完了です。
最後の修正後に、Playwrightで両方のサイズを確認してください。
スクリーンショット、クリックの結果、ページのルート要素の
scrollWidthとclientWidthの計測値を示してください。
scrollWidthはclientWidthを超えてはいけません。
CSSだけを変更してください。スクロールをなくすために、内容を隠したり切り取ったりしないでください。
テキストとゲームの動作は維持してください。
修正と確認を3回行っても条件を満たさない場合は、
停止して、残っている差異を示してください。

ここでのサイズは、ブラウザーウィンドウの幅と高さをピクセルで表しています。scrollWidthは端の外側も含めたコンテンツ幅、clientWidthは表示可能な幅です。比較すればはみ出しを見つけられますが、それだけではテキストが切れていないことやボタンが使えることまでは証明できません。そのため、条件にはスクリーンショットとクリック確認も含めています。2つのサイズだけで全端末での使いやすさを保証するわけではなく、このタスクの範囲を決めるものです。

エージェントにgoal案を作ってもらう

条件を一から書く必要はありません。Claude Code Best Practiceには、コミュニティからの助言が2つ紹介されています。プロジェクトの状況に応じた目標を提案してもらう方法と、会話やファイルを読んだうえで条件文を作ってもらう方法です。以下では小さなタスク向けに応用します。

長時間の作業に何を任せるべきかまだ分からない場合は、/goalを使わず、通常のメッセージから始めます。

現在の会話と、タスクに関係するプロジェクトファイルを読んでください。
検証可能な成果につながる、有用な目標を3つ提案してください。
それぞれについて成果、確認方法、変更範囲、実行前に不足している情報を挙げてください。
これまでの合意を踏まえてください。まだ目標は実行せず、
ファイルも変更しないでください。意図が不明なら質問してください。

目標を1つ選びます。作業が長いこと自体に価値はありません。曖昧な"改善"に何時間も費やすより、検索機能を直すほうが役立ちます。タスクがすでに明確なら、最初の依頼は省略して、条件案を直接作ってもらえます。

選んだタスクについて、会話、プロジェクトファイル、ドキュメントをもとに
/goalの文面を作成してください。まだ何も実行しないでください。
観察可能な成果、確認方法、会話に示す内容を書いてください。
変更範囲と、成功せずに停止する条件も加えてください。
アドレス、コマンド、完了の目印を創作しないでください。
プロジェクト内で見つけるか、私に確認してください。
完成した文面を1つ返し、不明点は別に列挙してください。

案を送る前に、内容を確認しましょう。望んでいた成果と合っていますか。指定したページは存在しますか。データ変更や機能追加まで許可していませんか。最後に不明点が残っているなら、先に解決してください。内容を確定してから実行します。/goalコマンドを使うと、すぐに作業が始まります。

状態を確認して作業を止める

目標が有効な間は、進行状況を確認できます。引数なしで/goalを実行すると、条件、経過時間とターン数、評価モデルが最後に返した理由が表示されます。

目標を途中で止めるには/goal clearを実行します。対局が終わっていなくても条件を解除できます。

ここで結果が確認されたと言えるのは1つだけです。条件が達成され、会話内の評価モデルの応答で確認できる場合です。/goal clearで目標を解除するのも分かりやすい終わり方ですが、それは止めるというあなたの判断であって、作業が終わった証拠ではありません。目標が自動で停止するほかの理由は、成果を裏付けるものではありません。

評価モデルに渡る情報

/goalの評価モデルが見るのはページそのものではなく、会話です。エージェントが書いた内容と、ブラウザーで観察した結果を会話にコピーしたものを読みます。評価モデル自身にはツールがないため、ページを開き直したり、コマンドを実行したりせず、会話に蓄積したテキストだけを確認します。

ここから簡単な結論が導けます。エージェントが"対局が終わりました"と言っただけでは、評価モデルにもあなたにも何も証明できません。証拠になるのは、エージェントがページから実際に読み取った結果、つまりdata-game-overの値です。前者は報告、後者は観察結果です。似た表現でも別物です。

この目印にも限界があります。data-game-overが示すのは、特定のアプリケーションの状態、つまりページの作者が設定した内容です。対局全体がチェスのルールどおり、一度も間違えずに進んだことまでは示しません。同様に、スクロールがないことだけではボタンが機能するとは限りません。得たい成果に合う目印を選び、そこから分からないことまで推測しないでください。

作業で変わること

自分のタスクでも、同じ手順を使えます。

• 明確な成果と、実際に利用できる確認方法を決める。
• /goalで、変更範囲と停止条件を含む条件を設定する。
• 引数なしの/goalで、いつでも状態を確認する。
• 観察結果と確認結果に基づいて結論を出す。
• 作業が行き詰まったり条件が適切でないと分かったりしたら、/goal clearで手動解除する。

作業を自動で続けることと、次に何をするか決めることは別です。前者は1つのセッション内で/goalに任せられます。実際に何ができたかを調べ、未完了の目標を解除し、次のタスクを設定するのは、引き続きあなたの役割です。

評価モデルの正確な動作や状態の形式は、Claude Codeのバージョンによって多少異なることがあります。ページへの直接アクセスではなく、会話に基づいて評価するという基本原則は変わりません。