1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントに小さなPRを任せるなら、まず「どこで止まるか」を書く

1
Posted at

「送信後のエラーメッセージがフォームの下で見切れる」。Reactのコンポーネントを少し直せば済みそうな依頼です。でもエージェントに「直してPRを作って」とだけ渡すと、実装に加えてテストの書き換えや設定変更まで進んだとき、どこからが余計な作業か判定しづらい。

以下は架空のReact/TypeScriptリポジトリを使った手順例です。Copilotの新機能を手元で動かしたレポートではありません。焦点は、エージェントから返ってきたPRをどう引き取るかにあります。

まず変更できる範囲を決める

対象はフォームの表示部品と、それに対応するテストだけ。認証処理、.env、ロックファイル、デプロイ設定は対象外とします。実際にはファイル名を推測して決めず、最初にリポジトリを調べてからパスを記入してください。

目的: 送信失敗時のエラーメッセージが狭い画面でも読めること
対象: フォーム表示部品と関連テスト(調査後に具体的なパスを記入)
対象外: 認証、秘密情報、依存関係、デプロイ設定
停止: 対象外の編集が必要 / 権限追加が必要 / 既存テストが失敗する
提出: 変更ファイル、検査結果、画面の確認状況、未解決事項
最終確認: 担当レビュアー

この段階では実装を頼まず、「該当箇所とテストを探し、変更計画だけ返す」と依頼します。エラー表示の原因が認証API側にあると分かったら、フォーム修正の延長で勝手に触らせない。いったん止めて、依頼の範囲を人が決め直します。

GitHubが公開プレビューとして案内しているCopilotのdynamic workflowsには、工程をコードで定義し、構造化した結果を次の工程や人のチェックポイントへ渡す考え方があります。この記事の手順はその特定APIの実装例ではなく、どのエージェントでもPRの作業単位として切り出せる最小形です。

sandboxを設定しても、PRの合否は決まらない

Copilotのlocal sandboxingは、エージェントが起動するツールやコマンドに対してファイル、ネットワーク、認証情報へのアクセスを制限する仕組みとして一般提供が案内されています。利用できる環境なら、前述の対象外パスや外部通信を実行権限でも制限したい。ただし設定項目と実際の効き方は利用先で確認が必要です。ここに未確認のポリシー構文は載せません。

権限を狭めることと、直した画面が正しいことは別です。たとえば許可したコンポーネント内だけでも、エラー文を丸ごと消せば「見切れ」はなくなります。PRでは少なくとも次を別々に確認します。

  1. 差分は承認した範囲に収まっているか。
  2. リポジトリに実在するlint・型チェック・テストは通ったか。
  3. エラーメッセージは狭い画面で読めるか。失敗後に再送信できるか。

3番目はブラウザでの操作確認です。1番目と2番目が通っても代わりにはなりません。

検査コマンドはリポジトリから選ぶ

既存のnpm scriptsを見ずにnpm run typecheckを手順へ書くと、存在しないコマンドを「検査したこと」にしてしまいます。実際のリポジトリで、作業前後に次を確認します。

# npmプロジェクトの場合。まず定義済みの検査を読む
node -e 'console.log(require("./package.json").scripts)'

# 作業ツリーに残った変更を確認する
git status --short
git diff --name-only

# BASEには対象PRのベースコミットIDを事前に設定する
git diff --name-only "$BASE"...HEAD

BASEには実際のPRのベースコミットIDを設定してから実行します。未設定なら最後のコマンドは実行しません。上のgit diff --name-onlyは未コミットの差分だけを見るので、コミット済み変更の確認も省かないでください。出てきたscriptsから該当する検査を選び、失敗したらエラーを残して停止。テストを直す必要がある場合も、期待仕様の変更かどうかを人に返します。

画面は幅の違う表示で実際に操作し、送信失敗時の文言と再送信の導線を見る。スクリーンショットだけでなく、どの条件で確認したかもPRに残しておくと、レビュアーが追試できます。

止まったときの引き継ぎを、成功時と同じ書式にする

エージェントの最終メッセージが「完了しました」だけだと、レビューは最初からやり直しです。PR本文かコメントに、未記入のまま使える欄を先に用意します。

変更したファイル 実行した検査と結果 画面の確認状況 未実施・停止理由 次に確認する人
記入待ち 記入待ち 未確認 記入待ち 記入待ち

検査が失敗したら「失敗」と書く。画面を開けなかったら「未確認」のままにする。権限を追加しないと進めないなら、その理由と要求された操作を残して待つ。人が見るべき場所を小さく保つための欄です。

組織の設定でCopilot appのOpenTelemetryトレースを取得できる場合、セッション内のツール利用を調べる補助にはなります。ただ、トレースがあるだけで表示が正しいとか、全てのアクセスを防げたとは言えません。使えない環境でも、この引き継ぎ表と差分・検査結果は残せます。

小さなPRほど、エージェントを止める条件を省きがちです。先に範囲と受け渡しの書式を決めておけば、修正が一行で済んでも、途中で思わぬ依存が見つかっても、レビュアーが次の判断をできます。

参考

1
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?