AIに「検索結果カードを追加して」と頼むと、最初の画面は案外すぐ出てくる。困るのは次の人が同じ依頼をしたときだ。別のコンポーネントを作り、別のコマンドで「確認済み」と言われたら、プロンプトを保存していても再現できていない。
Google CloudのAI coding agent向けPluginは、スキル、MCP経由の資料参照、操作上のガードレールをひとまとまりにする方向を示している。Chrome DevTools MCPにも、エージェントからのJavaScript評価を制限する設定がある。ただ、これらを入れればUIの品質が保証される、という話ではない。自分ならまず、リポジトリで「何を読ませ、どこを直させ、何を実行させるか」を決める。
以下は架空のReact/TypeScript管理画面を使った作業設計例で、Pluginを組んで試したレポートではない。製品ごとの設定ファイルやコマンドも、ここでは標準形式として提示しない。
最初に、リポジトリにある道具を数える
題材は検索結果カードの追加。既存のカード部品があるか、Storybookやテストがあるかで依頼文は変わる。いきなり「Storybookで確認して」と書く前に、手元のリポジトリでこれを見ておく。
# 自分の作業ツリーと、変更前の基準を控える
git status --short
git rev-parse HEAD
# package.jsonがあるNode系リポジトリで、既存scriptを確認する
node -e "console.log(require('./package.json').scripts)"
# 既存コンポーネントとテストの配置を探す。結果はリポジトリ次第
git ls-files
git ls-filesには未追跡ファイルが出ないので、git status --shortも一緒に見る。ここで見つからないStorybookやテストを「実行済み」にしてはいけない。依存追加が必要なら、それは実装とは別に相談する。
作業規約、資料、実行権限を混ぜない
次は自分のrepoに置く依頼メモの例。docs/agent-ui-task.mdというファイル名も任意で、特定のエージェント用Plugin manifestではない。実際には、最初の確認で見つかったパスやscript名に書き換える。
# 検索結果カードの変更（作業メモ例）
- 変更対象: 既存の検索画面と、そこで使うカード部品。実パスを先に列挙する。
- 再利用: repo内に既存のUI部品があれば、それを優先する。
- 変更前: 対象ファイルと変更方針を示し、確認を待つ。
- 実行: package.jsonに存在する検証scriptだけを候補として示し、実行前に確認を取る。
- 対象外: 依存追加、認証情報の参照、外部送信、デプロイ。
- 完了条件: 空結果・長いタイトル・キーボード操作・権限エラーを確認し、未確認項目を残す。
資料参照も別枠だ。使っているデザインシステムの仕様と、必要な公式ドキュメントだけを渡す。生成UIのSDKやコンポーネントの実装例を探す段階なら、生成AI UIデザインのリソース集のような一覧も候補になる。ただし、そこで見つけた例は自分のrepoで安全に使える証明にはならない。採用するSDKは原典、ライセンス、依存と実装を改めて見る。
Google CloudのPluginが示す「スキルとドキュメント参照を束ねる」考え方は参考になる。一方で、読める資料とコマンド実行は同じ権限ではない。MCPをつないだ場合も、読み取りツールが外部サービスへクエリを送るなら、渡す入力に秘密がないか確認する。OpenAIのAgents APIにもツールや実行環境を選ぶ設計があるが、その設定をIDEの設定へそのまま移せるわけではない。
操作は段階を切って許可する
自分ならエージェントの仕事をこう区切る。
- 変更前に対象パス、利用する既存部品、検証scriptを報告してもらう。
- 差分を確認してからファイル変更へ進む。新しい依存や外部サービスが必要なら、その場で止める。
- 実行するscriptを確認してから動かす。ブラウザ経由の任意JavaScript評価や認証操作は、別の許可がない限り開けない。
- 実行ログと未実行項目を分けて報告してもらい、画面の合否は人が判断する。
Chrome DevTools MCPのJavaScript実行制御は、この区別が設定面にも現れている例だ。利用する版と接続方法を原典で確認してから設定する。ここでの手順は、異なるPluginやIDEを組み合わせた動作保証ではない。
「カードが出た」の先を確認する
検索結果があるときだけ綺麗なカードになる、という実装は通しやすい。依頼するときは次の入力も先に用意する。値はテスト用の例で、実アプリの実測ではない。
// アプリの実際のAPI型ではなく、受け入れ条件を整理するための例
const reviewCases = [
{ name: '空結果', items: [], permission: 'allowed' },
{ name: '長いタイトル', items: [{ title: '長い見出し'.repeat(12) }], permission: 'allowed' },
{ name: '権限なし', items: [], permission: 'denied' },
] as const
空結果で前回のカードが残らないか。長文でボタンが隠れないか。Tabキーで操作したときにフォーカスが見えるか。権限エラーを空結果と取り違えていないか。このへんはスクリーンショット一枚では判定しにくい。
# 差分の対象と空白エラーを見る。未追跡ファイルはstatusで別途確認する
git status --short
git diff --name-only
git diff --check
# lint / test / typecheck は、先に確認したpackage.jsonにあるものだけを実行する
| 確認する状態 | 画面で見ること | 結果 |
|---|---|---|
| 空結果 | 空状態と案内文、古いカードが残らないこと | 未確認 |
| 長いタイトル | 折り返し、操作ボタンの位置 | 未確認 |
| キーボード操作 | Tab順とフォーカス表示 | 未確認 |
| 権限エラー | 空結果とは違う表示、再試行導線の有無 | 未確認 |
検証用scriptがなければ、その項目は「未実行」。ブラウザを開けなかったら画面確認も「未確認」。エージェントがコードを生成したことと、作業を受け取れることは分けて記録したい。
プロンプトを長くする前に、既存の部品、許す操作、合格条件をrepoに残す。次の人が同じ作業を渡すとき、そこから始められる。
参考資料
- Google Cloud Developer Plugin for AI Coding Agents — スキル、ドキュメント参照、ガードレールの配布例
- Chrome DevToolsの更新情報 — Agent PluginsとJavaScript実行制御
- OpenAI Agents APIの紹介 — ツールと実行環境の分離を考えるための資料