今回の実装で効果的だったと考えられる AI プロンプトのまとめ
UiPath→Python 実装の過程で、意図どおりの実装や早期の原因特定につながった「聞き方・渡し方」をまとめた。同種の RPA/自動化実装や AI 支援開発で再利用できる。
1. 効果的だったプロンプトのパターン
1.1 「実物（DOM/HTML）を貼って、仕様を一文で言う」
パターン
- 該当する画面の HTML または DOM の一部をそのまま貼り付ける
- そのうえで「このボタンを押したい」「この入力欄に値を入れたい」など やりたいことを一文で書く
なぜ効いたか
- セレクタや属性が実装とずれていても、実物を見せたことで「絵文字付きボタン」「ラベルが『顧客名 *』」などが伝わり、正しいセレクタ（
filter(has_text="データを登録する")、get_by_label("顧客名 *")）に修正できた。 - 「こう動かしたい」だけだと、実装が「想定した HTML」で書いてしまい、本番 DOM と食い違うことが多い。
例（ユーザーがやったこと）
- トップの「データを登録する」ボタンの HTML と、データ登録ページのフォーム周りの HTML を貼り付け、「確認」「✅ 登録」の HTML も共有した。
- その結果、ボタンは
get_by_role("button").filter(has_text="データを登録する")、ラベルは「顧客名 *」形式で統一する修正ができた。
1.2 「まずどこで落ちているか分かるようにしてほしい」
パターン
- 「全部エラーになる」「1〜3行目は通るはずなのに通っていない」など 現象だけを伝える
- そのうえで 「どこで・なぜ」失敗しているか分かるようにしてほしい と依頼する
なぜ効いたか
- いきなり原因を当てるより、「失敗箇所を可視化する」ようにしてもらうと、次の一手（セレクトの絞り込み、選択肢の有無の確認など）が決めやすかった。
- ターミナルに「フィールド「営業担当」(値: "田中") で失敗」と出るようにしたことで、strict mode 違反（2 要素マッチ）に気づき、
stSelectboxVirtualDropdownで絞る修正にすぐつながった。
例（ユーザーがやったこと）
- 「1～3行目は登録できるはずなので、できていない理由を探したい」→ フィールド単位で try/except して失敗箇所を表示するようにした。
- 「結果はすべて登録エラーだった。どこでエラーになったかユーザーにわかりやすくしてほしい」→ ターミナル＋Excel の「動作結果」に詳細を出すようにした。
1.3 「仕様・ルールを先に伝え、そのうえで例外を言う」
パターン
- 普段のルール（例: 「ユーザーがブラウザを起動する」「設定は config で」）を最初に共有する。
- 今回だけの例外（例: 「デバッグなので Python から起動にしてほしい」）を、「〇〇というルールだったが、△△にしてほしい」と対比して書く。
なぜ効いたか
- 「デバッグなので Python 起動にしてください」と書いてあったため、config のポートを「接続用」ではなく「起動用」だけに使う変更が迷わずできた。
- 「待ち時間はハードコードせず config に」と伝えたことで、キー名と既定値の設計まで一括で提案できた。
1.4 「欲しい挙動を 1・2・3 のステップで書く」
パターン
- メッセージの文言、分岐、ファイルの扱いなどを 番号付きで順番に 書く。
- 「最初の確認で〇〇の場合は〜、△△の場合は〜」「次の確認で OK なら実行、NO なら停止」のように、条件と結果を対応させる。
なぜ効いたか
- 起動時フロー（インプット作成するか／既存か → この動作でいいか → はいなら取得→登録、いいえなら本日ファイル or ファイル選択）がそのまま実装の分岐と対応し、抜け漏れが減った。
- 「本日日付のファイルがない場合は『本日日付のファイルがないのでファイルを選んでください』と出してファイル選択」のように、文言まで含めると、そのままメッセージとコードに落とし込めた。
1.5 「負荷・待ち・環境の心配を具体的に書く」
パターン
- 「Web アプリに負荷をかけそう」「画面遷移で 1 秒くらい待ちたい」「登録ボタン押したあと 2 秒、次のページの読み込み時間を入れたい」など、数値や対象操作 を添えて書く。
- 「ローカルでも同じようにできるか」など、環境の前提 も一緒に書く。
なぜ効いたか
- 「確認クリック後 1 秒」「登録クリック後 2 秒」といった待ちを、そのまま定数→のちに config のキーに反映できた。
- 「ローカルでも実装可能か」と書いてあったため、「config でミリ秒を変えればローカル・本番どちらでも有効」と答えつつ、実装で反映できた。
1.6 「成果物の形を指定する」
パターン
- 「Zenn / Qiita に投稿するための記録をまとめてほしい」「記事はその記録をもとに自分でまとめる」のように、何に使うか・誰がどう使うか を短く書く。
なぜ効いたか
- 「記録」であることが分かったので、見出し・表・チェックリストを含む「記事のたたき台」形式でまとめ、コピーや編集しやすい構成にできた。
- 同じように「効果的だったプロンプトをまとめてほしい」と成果物の種類を指定してもらえたので、パターン＋具体例＋使うときのコツ、という構成でまとめられた。
2. 実際に効いたプロンプト例（要約）
| ユーザーの発言・依頼（要約） | 効果 |
|---|---|
| トップ・データ登録ページ・確認後登録ボタンの HTML を貼り付け、「これで分析できるか？」 | セレクタを実 DOM に合わせて修正（ボタン filter、ラベル「〇〇 *」、ドロップダウン内限定） |
| 「1～3行目は通るはず。できていない理由を探したい」 | フィールド・ボタンごとに例外をラップし、失敗箇所をターミナルに表示するようにした |
| 「登録完了後の画面に『データを登録する』ボタンはあるか？ ない場合はトップに戻る→クリックの 2 段にしたい」 | あると確認してもらい、現状の 1 クリックのままでよいと判断できた |
| 「会社ルールはユーザー起動だったが、デバッグなので Python 起動 にしてほしい」 | config のポートを「接続」に使わず、起動用のみに変更 |
| 「インプット作成するか／既存か」のメッセージと「この動作でいいか」の確認、はいなら最初から最後まで、いいえなら本日ファイル or ファイル選択、と ステップで指定 | メッセージ→分岐→取得フロー/登録フローの流れをそのまま実装 |
| 「待ち時間は config に書いたほうがよい？ 他にハードコードを避けたい箇所は？」 | 待ち時間を config 化し、他候補（networkidle タイムアウト、ブラウザなど）を一覧で提示 |
| 「エラーがあった場所がユーザーに分かるようにしたい」 | 「動作結果」に「登録エラー: （フィールド・値・理由）」を書き込むように変更 |
| 「Zenn / Qiita 投稿用の記録をまとめてほしい。記事はその記録をもとに自分でまとめる」 | 見出し・表・実行方法・ポイント・ハマりどころ・チェックリストを含む記録ドキュメントを作成 |
3. 使うときのコツ（前提の伝え方・情報の渡し方）
-
仕様書やルールがある場合は、最初に「〇〇という仕様/ルールで進めている」と一文で書く
→ 解釈のブレが減り、例外対応（デバッグ用に Python 起動、など）も伝わりやすい。 -
Web の不具合では、必ず「そのときの DOM や HTML」を貼る
→ セレクタ・属性・構造のずれを一発で合わせられる。 -
「全部失敗する」ではなく「本来通るはずの範囲」を書く
→ 「1～3行目は通るはず」のように書いてもらうと、原因を「その範囲で落ちている操作」に絞りやすい。 -
欲しい挙動は「条件 → 結果」を番号で書く
→ 分岐やメッセージの仕様がそのまま if/else や文言に落ちる。 -
成果物の種類を指定する（記録・チェックリスト・README 用など）
→ 構成や粒度を合わせやすく、書き直しが減る。
4. このまとめの使い方
- 自分用: 次に AI に依頼するときの「聞き方」のチェックリストとして使う。
- チーム用: オンボーディングやレビューで「こう依頼すると答えが使いやすい」という例として共有する。
- 記事用: Zenn/Qiita で「AI と進めたときのプロンプトのコツ」として、セクション 1 と 2 を要約して載せる。
必要に応じて、プロジェクト固有のルールやツール名を追記して使える。