PDチームのAI駆動開発環境をつくる。ルール・Skills・検証の最小構成

AIで画面は作れる。でも、担当者が替わると説明をやり直し、前に直した問題がまた出てくる。PD（プロダクトデザイナー）チームがAI駆動開発の環境を整えるなら、まず一つの画面改善について「参照する資料・進め方・操作の制限・確かめ方・結果の置き場所」をつなぎます。最初の目標は、次の担当者も同じ問題を再現し、改善を確かめられることです。

一つの失敗を、環境づくりの出発点にする

設定画面の保存に失敗すると、入力した文章まで消えてしまう。これを説明用の仮想例にします。

AIへ「失敗時に入力を残して」と頼めば、その場の修正は進むかもしれません。しかし、次の画面でも同じ問題が起きたら、どこを変えればよいでしょうか。

ルールには「失敗時にユーザーの入力を失わせない」と残す。作業手順には「正常時に加えて、保存失敗を再現する」と入れる。検証環境には、保存を意図的に失敗させる模擬応答を用意する。結果には、実際に入力が残ったかを記録する。

同じ一つの指摘から、必要な仕組みが決まります。ルールだけがあっても失敗を再現できなければ、守れているか分かりません。検証できても結果を残さなければ、次の担当者は確認をやり直します。

このように、AIが作業する道具、文脈、状態管理、検証を含む周辺の仕組みを、ここではハーネスと呼びます。Claude Codeなどの既存環境を使い、チームに必要な部分を設定・追加するところから始められます。

ルール、Skills、ガードレールを同じ文書に詰め込まない

最小構成では、それぞれに異なる仕事を持たせます。

Claude Codeでは、CLAUDE.md や .claude/rules/ に方針を、.claude/skills/ に作業手順を置けます。ただし、CLAUDE.md は文脈として読まれる指示であり、操作を強制的に禁止する設定ではありません。ルールの公式説明／Skillsの公式説明

「本番を変更しない」と書くことに加え、接続先の権限、認証情報、実行環境を分けます。必要に応じて権限設定やHooksを使い、対象の操作を制御します。ファイル編集の禁止だけでは、別のツールやコマンドからの変更まで防げるとは限りません。権限設定／Hooks

ガードレールで操作を制限することと、できあがったUXを評価することも別です。指定の範囲で変更できたとしても、利用者が迷わず再試行できるかは確かめる必要があります。

最初のファイル構成は、一つの画面が回る大きさにする

以下は、Claude Codeを使う場合の説明用の構成です。すでに動くローカルの試作環境がある前提で、そこに追加するものを示しています。

このほかに、利用環境での権限・接続先の設定が必要です。表のファイルを並べただけで、アクセス制限や自動テストが有効になるわけではありません。design/、checks/、runs/ はこの記事の整理例です。Skillから参照先と使うタイミングを明示します。

図1：説明用の最小構成。資料の置き場所と、実行権限の設定を区別する。

最初に大量のSkillsを用意するより、save-ui 一つで作業を通します。既存の部品資料や検証環境があれば、それを参照して使います。テストを増やすときも、実際に見逃した状態から足します。

見えるプレビューと、同じ失敗を起こせる仕掛け

Webデザイナー・開発者のBrad Frostは、共同でAIを使って制作するための条件として、UIの基盤、ライブプレビュー、目的や制約の文脈、人の判断を挙げています。本人の実践記事／本人のYouTube

“But the point is to actually SEE what you're collectively creating.”
「大事なのは、一緒に作っているものを実際に見ることです。」（HAVU訳）

2026年9月の本人の発信でも、環境構築、監査・改善用のSkills、チームへの導入を一続きに扱っています。講座の内部手順を確認したわけではありませんが、仕組みづくりを考える参照になります。公開されている構成紹介

今回の例では、プレビューに保存失敗を起こせる模擬応答を加えます。実APIを壊す必要はありません。次の3状態を同じ条件で呼び出せるようにします。

AIには操作結果と画面を記録させ、人は「入力が消えない」だけで十分かを見ます。エラー表示が目立たず、保存できたと思わせていないか。再試行で何が起きるか分かるか。自動チェックに通った後にも、PDの判断が残ります。

Anthropicの長時間エージェントの検証でも、コード上の確認だけで機能を完了扱いしてしまう問題が報告され、ブラウザーを使った一連の操作の検証が組み込まれています。この記事の保存画面は、その考えを応用した仮想例です。Anthropicの実践報告

AIで試すなら、まず「検証できない箇所」を見つける

手元の環境がどこまで揃っているかを調べるだけでも、最初の一歩になります。次の入力と指示を、テキストを扱えるAIへ渡してみてください。

現状：設定画面の保存に失敗すると、入力内容が消える。
環境：ローカルで起動でき、対象のコードと仕様を参照できる。
不足：保存失敗を意図的に起こす方法がまだない。
範囲：保存APIの仕様は変えず、画面側を改善する。
完了条件：入力保持、失敗の表示、保持した内容での再試行。

この作業に必要な「参照資料・ルール・Skillの手順・
実行上の制約・検証方法」を整理してください。
すでにあるものと、先に用意するものを分けてください。
存在しないファイルやコマンドは作り足して断定しないでください。
まだ確かめられない条件を、完了扱いにしないでください。

この入力なら、想定される答えは「保存失敗を再現する方法が不足している。実装後の検証を完了するには、模擬応答などの再現方法を先に用意する」です。ルールやSkillを増やすことよりも、まず確認できない状態をなくします。これは外部AIで実行した結果ではなく、回答を照合するための想定例です。

人は、その指摘を実際の環境と照合します。すでに失敗を再現する仕組みがあれば、新しく作らず参照先を渡せば済みます。

図2：今回試す小課題。確認手段がない状態を、合格や完了へ読み替えない。

次の担当者が、同じところから再開できるか

環境づくりの最初の確認は、別の担当者や新しいセッションで、この作業を再開できるかです。起動方法を探し直さず、同じ失敗を再現し、前の結果と比べられるか。残った問題が、どこを見れば分かるかを確かめます。

PDは、どの状態を見て何を良しとするかを具体化する。エンジニアとは、状態の再現方法、実装の変更範囲、権限の設定を一緒に決める。検証結果が足りないときに、文書・道具・設計のどこへ戻るかを共有します。

一度だけのラフなアイデア出しなら、この構成を全部作る必要はありません。繰り返す改善があり、担当者をまたいで品質を保ちたいチームで、一つの作業から育てていく方法です。

HAVUでは、AIワークフローやチーム運用まで含めて設計しています。 いま使っているAI環境と、毎回説明し直している作業を一つ持ち寄っていただければ、資料を残す部分、実行を制限する部分、検証を仕組みにする部分を整理できます。PDチームのAI駆動開発環境について相談する