プロンプト42選 — 貼って使える実例集

以下のスタックトレースを分解して教えてください。

```
（ここにエラーをそのまま貼る）
```

ほしい情報:
1. 一言で言うと何が起きたか
2. ユーザー由来のコード行（ライブラリ内部ではない）はどこか
3. ありがちな原因 TOP3
4. 再現するための最小コード（推測でOK）
5. 直すための具体的な手順

「たぶんこう」レベルの推測でも構いません。先に当たりをつけてから検証したいです。

@<対象ファイル> を見て、パフォーマンス改善の余地を分析してください。

手順:
1. ボトルネックになりそうな箇所を3つ挙げる（行番号付き）
2. 各箇所で「なぜ遅い可能性があるか」を1行で説明
3. 計測用のコード片（time.perf_counter や console.time）を追加する形で示す
4. 計測結果に応じた改善案を、軽い順に提示

注意: いきなりリファクタしないでください。まず計測の仕込みだけ、私が実行して数値を見てから判断します。

パッケージのインストールで競合が起きました。以下のエラーを読んで、何と何が衝突しているのか地図にしてください。

```
（npm/pip/uv のエラー出力をそのまま貼る）
```

整理してほしい内容:
1. 衝突しているパッケージのペア
2. 各々が要求しているバージョン範囲
3. なぜ満たせないのか（バージョン解決のロジック）
4. 取れる打ち手 (a) どちらかをダウングレード (b) どちらかをアップグレード (c) 一方を別のものに置き換え
5. 私のプロジェクトの状況に対する推奨

「とりあえず --force」は最後の手段にしてください。

このプロジェクトを <現在のバージョン> から <目標バージョン> に上げたいです。

調べてほしいこと:
1. その間に入った主な破壊的変更（言語仕様 + 標準ライブラリ）
2. プロジェクト内で実際に該当しそうなコードの箇所（grep して特定）
3. 依存パッケージ側で対応が必要そうなもの
4. アップグレード手順（最小ステップ）
5. ロールバック手順（うまくいかなかった時用）

楽観的な「たぶん大丈夫」ではなく、「ここは確認が必要」を漏れなく教えてください。

@<対象ファイル> を現代的な書き方に近代化したいです。

方針:
- 機能は変えない（テストがあれば全部 pass し続ける）
- 1コミット1観点で段階的に
- 変更前後の差分が読みやすいように

候補としてやってほしいこと（プロジェクトに合うものだけ採用してOK）:
- var → let/const
- 旧式の class.prototype → ES class
- callback hell → async/await
- % string format → f-string
- typing.List → list[X] (Python 3.9+)
- lodash で書ける処理を標準APIに

まず「変更候補リスト」を出してください。私が選んでから実装に入ります。

@<ファイル名> の <関数名> が長いので、単一責任原則で分割したいです。

やってほしいこと:
1. 関数内の「論理的なブロック」を識別（コメントで区切られているところなど）
2. 各ブロックを独立した小関数として抽出する案を提示
3. 関数名の候補を 3 つずつ（動詞+名詞の形式で）
4. 引数と戻り値の型を明示
5. 元の関数は新しい小関数を順番に呼ぶだけになるように

まず案だけ提示してください。私のレビュー後に実装します。テストがあれば、変更後も全部通ることを確認してください。

このプロジェクトのコードに散らばっているマジックナンバー / マジックストリングを抽出して、定数化してください。

手順:
1. プロジェクト全体を grep して、リテラル値を抽出（0, 1, "" などの自明なものは除外）
2. 用途を推測してグルーピング（タイムアウト系、リトライ回数、HTTPステータス、UI寸法など）
3. constants.py / constants.ts のようなファイルにまとめる
4. 元のコードは定数を参照する形に置換
5. 名前は SCREAMING_SNAKE_CASE で意味が分かるものに

不明なものは「不明: 確認お願いします」とマークしてください。憶測で命名しないでください。

プロジェクトの重複パターンを検出して共通化してください。

手順:
1. ほぼ同じ構造のコードブロックを 3箇所以上で見つける
2. 差分（変数部分）を引数として抽出
3. 共通関数を utils/ に新規作成
4. 元の各箇所を共通関数の呼び出しに置換
5. 動作が変わらないことを示す（テストか手動確認手順）

注意:
- 「似てるけど実は違う」を無理に合体させないでください
- 過剰抽象化は避ける。3箇所未満なら共通化しない

@<対象ファイル> にテストがありません。リファクタする前にセーフティネットとしてテストを追加したいです。

書いてほしいテスト:
1. ハッピーパス: 正常系の代表ケース 1〜2 個
2. 境界値: 空入力、最小値、最大値
3. エラー系: 想定される例外
4. 状態変化: 副作用がある関数なら状態確認

方針:
- 実装の内部詳細はテストしない（インターフェース重視）
- AAA パターン (Arrange / Act / Assert) で読みやすく
- それぞれのテストに 1 行コメントで「何を確認してるか」

実装を変えずに通るテストだけ書いてください。失敗するテストは別途報告。

@<対象ファイル> の関数すべてに docstring (Python) / JSDoc (TS) を追加してください。

書式:
- 1行目: 何をするか（動詞で始める）
- 空行
- Args/Params: 型と意味
- Returns: 型と意味
- Raises/Throws: 投げる例外
- Example: 1〜2行の使用例（複雑なものだけ）

注意:
- コードの実装を読んで「実際の挙動」を書いてください。型ヒントだけ見て憶測で書かない
- 自明なゲッター/セッターは省略可
- 既に docstring がある関数は触らない（あるならそれを尊重）

指定フォルダ内のファイル名を以下のルールで一括変換するスクリプトを作ってください。

変換ルール:
- 全角スペース → 半角アンダースコア
- 大文字 → 小文字
- 連続するアンダースコア → 単一に
- 日付らしき文字列を YYYY-MM-DD 形式に正規化（できる範囲で）

要件:
- まず dry-run（変更前後を一覧表示するだけ）
- --execute フラグを付けたときだけ実際にリネーム
- 衝突（リネーム先が既に存在）したらスキップしてログ出力
- バックアップとして元ファイル名のリストを CSV で保存

言語: Python（標準ライブラリのみ）。OSは macOS / Linux 両対応で。

CSV と JSON を相互変換する小さな CLI ツールを作ってください。

仕様:
- `convert.py input.csv output.json` で CSV → JSON（配列のオブジェクト形式）
- `convert.py input.json output.csv` で JSON → CSV
- 拡張子から自動判別
- ヘッダー行ありを前提（CSV側）
- 文字コード: 入力は UTF-8 / Shift_JIS 自動判別、出力は UTF-8 BOM付き
- ネストJSONの場合はドット記法でフラット化（user.name → user.name 列）
- エラー時は分かりやすいメッセージ

依存: 標準ライブラリ + pandas（あれば使う、なくても動く）。
最後に実行例を3つ提示してください。

~/Documents/<対象フォルダ> を毎日バックアップする仕組みを作ってください。

要件:
- バックアップ先: ~/Backups/<対象フォルダ>/YYYY-MM-DD/
- 形式: tar.gz （タイムスタンプ付き）
- 古い世代は 7 日分だけ残して削除（rotation）
- 失敗時は ~/Backups/.errors.log に追記
- 成功時は標準出力に1行だけサマリ

実装:
1. シェルスクリプト backup.sh
2. macOS の launchd plist （毎日 03:00 実行）
3. cron 版（Linux 用、おまけ）

注意:
- 削除処理は dry-run オプション付きで
- 元データには絶対に触らない

公開ページ  から記事タイトルと公開日を取得するスクリプトの雛形を作ってください。

合法・倫理ガードレール（必ず守る）:
- robots.txt を最初に取得して尊重
- User-Agent に連絡先メールを含める
- リクエスト間隔: 最低 2 秒
- 1セッション最大 50 リクエスト
- HTML キャッシュをローカルに残し、再実行で再取得しない

実装:
- requests + BeautifulSoup
- 取得結果は data.csv に追記
- 既に取得済みURL（.cache/seen.txt）はスキップ

私の用途は個人の学習目的です。robots.txt が禁じている場合はその旨を表示して中止する設計にしてください。

外部APIへのリクエストにキャッシュ層を追加してください。

要件:
- キャッシュキー: URL + クエリ + メソッド のハッシュ
- 保存先: ~/.cache/<アプリ名>/ にJSON で
- TTL: デフォルト 24時間（オプションで変更可）
- 期限切れは自動で再取得
- `--no-cache` フラグで一時的にバイパス

実装:
- Python なら functools.lru_cache では不十分なので、ファイルベースで作る
- TS なら同等のラッパー関数

ボーナス:
- キャッシュヒット率を最後にレポートする CLI コマンド
- キャッシュ全削除コマンド

このプロジェクトに pre-commit フックを設定してください。

チェック内容:
- console.log / print(*) の残存（言語に応じて）
- TODO/FIXME を含むコミットなら警告（ブロックはしない）
- ファイルサイズ 1MB 超を検出
- 機密情報パターン（API_KEY=、AWS_SECRET 等）を検出（これだけはブロック）

実装:
- pre-commit フレームワーク（pip でインストール可能）を使う
- .pre-commit-config.yaml を作成
- 既存のフォーマッタ/リンタがあれば統合
- README に「セットアップ手順」を追記

最初は警告中心でゆるめに。慣れてきたら厳しくする方針で。

<ライブラリ名> を初めて学ぶための学習プランを作ってください。

私の前提:
- 既に知っている関連技術: <例: Python, FastAPI>
- 学習に使える時間: 平日30分 / 週末2時間
- 目的: <例: 個人プロジェクトで使えるレベルになる>

ほしい構成:
1. **3日プラン**: 「とにかく Hello World が動く」まで
2. **7日プラン**: 「自分のミニアプリが書ける」まで
3. **30日プラン**: 「実務で使える」まで

各日の目標 + 推奨教材（公式ドキュメントの該当章 / 動画 / 書籍）+ 終わったらできるはずのこと、を 3 行以内で。

 の公式ドキュメントを、私の用途に合わせて要約してください。

私の用途: <例: REST API のキャッシュレイヤーとして使いたい>

要約の構成:
1. このライブラリの「核」を 3 文で
2. 主要コンセプト（5個まで）
3. 私の用途に直接関係する章（番号順 + 読む優先度）
4. 関係なさそうで実は重要な章（落とし穴）
5. 「最初に試す Hello World」コード例

WebFetch を使ってもいいですが、推測で書く時は「（推測）」を明示してください。間違ってる方が無いより害があります。

 vs  vs  を比較表にしてください。

評価軸:
- 学習コスト
- パフォーマンス（おおよそで OK）
- コミュニティの活発さ（GitHub stars / 最終更新）
- ドキュメントの質
- TypeScript / 型サポート
- 私の用途への向き不向き

私の用途: <ここに具体的に書く>

最後に「私だったらどれを選ぶか + その理由」を 3 行で。
ただし「どれも一長一短です」みたいな両論併記は禁止。立場を明確に。