AIプロンプトとスキルライブラリ

意味と情報密度はそのままに、言葉の面だけを整える

あなたは日本語のネイティブ編集者です。次の文章を読みやすく整えてください。条件：1）元の意味と情報密度を保つ；2）決まり文句、重複、中身のない形容詞は削る；3）私が書いていない内容は足さない；4）修正後、主にどこを変えたかを一文で示す。

［草稿を貼り付けてください］

「〜ではなく〜」という対句や「まず・次に・最後に」といった型通りの言い回しを削る

次の文章はAIが書いたように読めます。書き直してください：1）「〜ではなく〜」「〜だけでなく〜も」といった対句表現を削る；2）「まず／次に／最後に」「総じて」「注目すべきは」を削る；3）抽象名詞は具体的な動作に置き換える；4）文の長短を混ぜ、文になっていない断片も許容する。書き直した本文だけを出力してください。

［テキストを貼り付けてください］

半分に削っても情報を落とさない。鍵は本当の要点を見極めること

次の文章を［目標文字数］字以内に圧縮してください。ルール：1）事実、数字、結論はすべて残す；2）前置き、繰り返しの説明、修飾は削る；3）文を統合してよいが、因果関係は変えない。

［テキストを貼り付けてください］

断片的なメモを渡すと、そのまま使える構成案が返ってくる

以下は私の断片的なメモです。構成案に整理してください：1）まず主旨を一文で示す；2）論理的な階層で3〜5の部分に分け、各部分がどんな問いに答えるのかを一文で書く；3）各断片を該当する部分の下に振り分ける；4）実は重複している考え、または互いに矛盾する考えを2つ指摘する。

［メモを貼り付けてください］

断る、催促する、誤りを正す。卑屈にも居丈高にもならず

メールを書いてください。背景：［背景］。宛先：［関係性と立場］。達成したいこと：［目的］。譲れない線：［譲れない点］。条件：短く；結論を先に、理由は後に；謝罪は一度まで；最後に次のアクションと期日を明示する。

上司に読ませるものとエンジニアに読ませるものは、別の文書でなければならない

次の内容を2つのバージョンに書き分けてください：1）［マネージャー］向け——150字以内に収め、影響・リスク・必要な意思決定だけを書く；2）［実行する同僚］向け——技術的な詳細と手順をすべて残す。どちらのバージョンも重要な事実を落としてはいけません。

［原文を貼り付けてください］

同じ記事に、抑制の効いたものから誇張したものまでタイトルを付け、どこが一線を越えているかを示す

あなたはコンテンツ配信を長くやってきた編集者です。次の記事を読み、抑制の効いたものから誇張したものへ強度が上がる順に5つのタイトルを付けてください。各タイトルの後に、1）何を約束しているか；2）本文がそれを本当に果たしているか；3）クリックした読者が最も感じそうなこと（失望／不快／読む価値があった）を記す。最後に、すでに釣りタイトルになっているものを1つ挙げ、その理由を述べてください。クリック率のために正確さを犠牲にしないこと。

［記事を貼り付けてください］

強硬、緩和、自嘲。同じことを言う3つの方法と、それぞれの代償

次の段落を、内容は変えず語調だけを変えて3つに書き分けてください：1）断固版——交渉の余地は残さないが、理由は示す；2）緩和版——立場は保ちつつ、対立を最小にする；3）自嘲版——自分の窮状を認めることで相手の警戒をほどく。各バージョンの後に、その代償（どう読まれるか、何を失うか）を一文で添える。原文にない事実は加えないこと。

［段落を貼り付けてください］

検証できる問題だけを示す。記事の書き直しはしない

あなたはファクトチェック編集者です。次の記事を段落ごとに読み、検証だけを行ってください。書き直しはしないこと。3つの欄を出力します：1）記事中の数字、日付、人名、引用を一つずつ挙げ、「要確認」か「前後と矛盾」かを記す；2）前後の記述が食い違う箇所。原文の2文を引用する；3）出典のない強い断定（「すべて」「決して」「必ず」）。各項目について、最も手間の少ない確認方法を示してください。問題のない段落には触れないこと。

［記事を貼り付けてください］

話し手の語り口は残し、口ぐせの繰り返しや脱線は削る

以下はインタビューの文字起こしです。1500字ほどの記事に整理してください：1）時系列ではなくテーマで再構成する；2）最も情報量の多い文を5〜8つ、一字も変えずに引用として残す；3）口ぐせ、繰り返し、脱線は削るが、話し手の語り口と立場は変えない；4）私が聞き切れなかったが、聞くべきだった質問を3つ挙げる。

［文字起こしを貼り付けてください］

ユーザーが読んで理解でき、今回の更新が自分にとって何を意味するか分かる

次の変更リストから更新履歴を書いてください。読者はすでにプロダクトを使っている一般ユーザーです。構成：1）今回の更新で最も注目すべき変化を一文で；2）「新機能／改善／修正」に分け、各項目に「何が変わったか＋あなたにとって何を意味するか」を書く。社内用語は使わない；3）ユーザー自身がやる必要のあること（再ログイン、設定変更など）を別に列挙する；4）既知の問題。「ユーザー体験を最適化しました」のような中身のない表現は書かないこと。

［変更リストを貼り付けてください］

記事がどこで手放されるかを見つける。分かりやすいと褒めるのではない

あなたはせっかちな想定読者を演じてください：［読者の属性］。もともと流し読みするつもりでした。次の原稿を順に読み、答えてください：1）どの段落でタブを閉じるか、どの一文で我慢が切れたか；2）書き手が独り言を言っているだけで、読者の疑問に答えていない箇所を3つ；3）書き手自身も考え切れていないのではないかと思う論点；4）半分だけ残すならどの段落を削るか。文章のうまさには触れず、励ましも不要です。

［原稿を貼り付けてください］

長文を、それぞれ独立して成立する三枚のカードに圧縮する。短くした要約ではない

あなたは知識管理の編集者です。次の長文を、それぞれ独立した問いに答える三枚の要約カードにしてください。1）カード1：この記事の最も重要な結論を一文で。2）カード2：結論を支える根拠や仕組みを、信じるのに必要な情報だけ残して。3）カード3：読者が読後に取れる行動、または当てはまらない条件。各カードは80字以内、見出しは12字以内とし、原文にない内容は補わないでください。最後に、三枚のうち単独で共有されやすいのはどれか、理由とともに示してください。

［記事を貼り付けてください］

話題が実際に切り替わる位置を見つけ、見出しで構成を可視化する

あなたはノンフィクションの編集者です。次の記事に見出しを付けてください。1）まず通読し、話題が実際に切り替わる位置を示す。段落数で均等に切らない。2）各見出しは8〜14字で、流し読みする読者にもその節が何の問いに答えるか分かるようにする。3）見出しは文で書き、「〜について」「〜の考察」は使わない。4）名前を付けられる主題がない箇所は、統合するか削るべきだと指摘する。最後に、追加・変更した見出しを列挙してください。

［記事を貼り付けてください］

最も強い反論をまずきちんと述べ、そのうえで一つずつ応答する。わら人形を倒すのではない

あなたは弱点を見つける役割の論証コーチです。次の主張について四つの手順で進めてください。1）主張を一文で言い直し、それが成立するために前提としている暗黙の条件を示す。2）反論を三つ挙げる。いずれもその分野の賢明な人が本気で出す形にし、反論しやすいわら人形は使わない。3）それぞれに応答し、どこが成り立ち、どこが成り立たず、何の証拠があれば決着するかを示す。4）三つのうち一つが正しい場合、元の主張をどう修正すべきかを述べる。主張を最後まで守り抜こうとしないでください。

［主張を貼り付けてください］

口頭の繰り返しや飛躍を削り、実行でき引用できる決定として残す

あなたは会議録の編集者です。次の発言を文書に整えてください。1）冒頭に「何を決めたか」「誰が担当か」「いつまでか」の三行を置く。2）本文は「背景・議論・決定・未決事項」の順に構成し、発言順には沿わない。3）口癖、重複、言い終わっていない文は削るが、発言者の立場は変えない。4）「だいたい」「後でまた話す」といった曖昧な表現は印を付け、確認が必要な問いに置き換える。会議で話していないことは補わないでください。

［文字起こし、またはメモを貼り付けてください］

一文ごとに主張の強さと根拠の強さを照合する。指摘だけを行い、書き換えない

あなたは原稿編集者です。「主張」と「根拠」が同じ強さで対応しているかだけを点検し、文章は書き換えません。段落ごとに、判断を含む文をすべて拾ってください。1）主張を事実・傾向・因果・予測に分類する。2）その根拠がデータ、事例、引用、常識、なしのどれかを示す。3）一つの事例で「すべて」を支えている、相関を因果として示している、といった強さの不一致を指摘する。4）不一致ごとに、表現を弱めるか根拠を足すか、最小限の修正案を示す。文章の良し悪しには触れないでください。

［記事を貼り付けてください］

制約と失敗時の挙動は残し、実装の詳細を読者が対応づけられる結果に置き換える

あなたは技術コミュニケーションの編集者です。次の技術文書を、非技術者の読者向けに書き直してください。読者は［役割：プロダクトマネージャー、顧客、経営層など］です。条件：1）冒頭に、その読者にとって何を意味するかを一文で示す。2）技術的な概念が初めて出る箇所では、日常の経験に置き換えて説明し、新しい用語は持ち込まない。3）制約条件、失敗時の挙動、数値は残す。分かりやすくするためにリスクを削らない。4）原文で曖昧な点や欠けている情報は別に列挙し、「要確認」と記す。仕組みを比喩で置き換えないでください。

［技術文書を貼り付けてください］

形容詞を禁じ、検証できる詳細と利用場面だけで書く

あなたはプロダクトコピーの編集者です。［製品］について、［想定読者］向けに200字以内の紹介文を書いてください。厳守事項：1）「強力」「効率的」「シームレス」「スマート」「オールインワン」などの形容詞と、その言い換えは使わない。2）訴求点はすべて具体的な行動か場面に落とし、誰がどの状況で何をするかを書く。3）検証できる詳細（数値、制限、利用条件）を少なくとも一つ入れる。4）機能軸、場面軸、比較軸の三版を出す。検証できない評価より、地味でも事実を書くほうがよい。

［製品情報を貼り付けてください］

コメント、チケット、インタビューの断片を、行動につながる少数の主題にまとめる

あなたはユーザーリサーチのアナリストです。次の散らばったフィードバックを主題ごとにまとめてください。1）まず全体を読み、「利用者が何を達成しようとしていたか」で分類する。キーワードや感情では分類しない。2）各主題について、要約一文、支持件数、代表的な原文二つ（一字も変えない）、反例一つを示す。3）「影響人数×深刻度」で順位を付け、その根拠を述べる。4）どこにも入らない項目と、誤読していそうな点を別に挙げる。表現を丸めず、利用者の論理を補完しないでください。

［コメント、チケット、インタビューメモを貼り付けてください］

バグ、セキュリティ、性能の問題につながる箇所だけを挙げる

あなたはシニアエンジニアです。次のコードをレビューし、バグ、セキュリティ問題、性能問題につながる箇所だけを重大度順に指摘してください。各項目について：1）何が問題か；2）どんな条件で発現するか；3）具体的な修正方法。コードスタイルには触れず、「コメントを追加してはどうか」といった指摘も不要です。

```
［コードを貼り付けてください］
```

可能性を順位づけし、それぞれの確かめ方を示す

［技術スタックとバージョン］でこのエラーが出ました。［すでに試したこと］。次をお願いします：1）可能性の高い順に原因を挙げる；2）それぞれに確認方法（コマンド1つ、または最小の再現コード）を示す；3）すでに試したことは繰り返さない；4）判断するのに情報が足りなければ、何を追加すべきかをそのまま伝える。

```
［エラーとスタックトレースを貼り付けてください］
```

このクエリ固有の話。一般的な推奨事項はいらない

あなたはデータベースの専門家です。このSQLは［テーブル名、約X万行］で実行に［所要時間］かかります。次をお願いします：1）最も疑わしいボトルネックを指摘する（実行計画を見る）；2）最適化後のSQLを示す；3）必要なインデックスと、追加した場合の副作用（書き込みの遅化、容量）を説明する。「SELECT * を避けましょう」のような一般論は不要です。

```sql
［SQLを貼り付けてください］
```

1行ずつ訳すのではなく、データの流れで説明する

次のコードを説明してください。条件：1）まず全体として何をしているかを一文で；2）次にデータの流れに沿って、入力がどこから来て、どんな変換を経て、出力がどこへ行くかを述べる；3）最も読み間違えやすい箇所を2〜3つ示す；4）不要に見える箇所、怪しい箇所を指摘する。文法を1行ずつ訳さないこと。

```
［コードを貼り付けてください］
```

コードを書く前に、設計の穴を見つける

これが私のAPI設計です：［設計を貼り付けてください］。レビュアーの立場で突いてください：1）実装時に問題になりやすい点を5つ挙げる；2）冗長なフィールドはどれか、欠けているためにクライアントが二度目のリクエストを強いられるのはどこか；3）後方互換を保った修正案を示す；4）明らかにもっと単純な代替案があるなら、はっきり指摘する。

境界ケースと反例も一緒に出す

次の条件に一致する正規表現を書いてください：［要件を説明］。条件：1）正規表現を示す；2）各部分の意味を1つずつ説明する；3）一致すべき例を3つ、一致すべきでない例を3つ挙げる；4）どんな極端な入力でバックトラックが爆発するか、またそれをどう避けるかを示す。

まず否決できると仮定し、そのうえでやる価値があるかを決める

あなたはこのマイグレーションのレビューのために呼ばれたシニアエンジニアで、否決できる十分な理由を見つけるのが役目です。次をお願いします：1）このマイグレーションが失敗する具体的な条件（データ量、停止可能な時間、ロールバック、関係チームの協力）を挙げる；2）計画の中で「そのとき考える」と先送りされている問題を指摘する；3）より小さな代替案（一部だけ移行する、まず二重書きする、読み取りだけ移行する）を示す；4）最後にだけ：否決できない場合、必ず補うべき2点は何か。

［マイグレーション計画を貼り付けてください］

changelogから、実際に踏む破壊的変更を掘り出す

［依存名］を［現在のバージョン］から［目標バージョン］に上げたい。プロジェクト内の呼び出しは約［N］箇所です。次をお願いします：1）2つのバージョン間の破壊的変更のうち、私に影響しうるものをすべて挙げ、実際に呼び出しているものだけに絞る；2）「必ず変更／変更したほうがよい／変更しなくてよい」に分け、それぞれ修正方法を示す；3）更新の順序を示す（どれを先に上げるか、2回に分けるべきか）；4）更新後に実行時になって初めて出やすい問題と、ローカルで事前に確かめる方法を示す。

［changelogと依存設定を貼り付けてください］

カバーされていない分岐を、本番障害の起こりやすさ順に挙げる

以下は私の実装と既存のテストです。テストが届いていない箇所を見つけてください：1）すべての分岐と境界を挙げ、ケースがないものを示す；2）「誤ったときに本番で最も影響が大きい」順に並べ、追加すべき上位5件のケースを示す（入力、期待結果、なぜ漏れやすいか）；3）既存のケースのうち、重複していて削っても信頼感が落ちないものを指摘する；4）振る舞いではなく実装の詳細を検証しているテストがあれば指摘する。

```
［コードとテストを貼り付けてください］
```

エンティティ、関連、状態機械。そして、いずれ必ず変わるフィールド

この要件をデータモデルに落としてください。コードはまだ書きません。出力：1）エンティティ一覧。それぞれが現実の何を表すかを一文で；2）エンティティ間の関連と多重度。多対多で中間テーブルが要るものを示す；3）中核オブジェクトの状態機械（状態、遷移のトリガー、不可逆な遷移）；4）今は足りて見えるが半年以内に変わりそうなフィールド（価格、権限、多言語、論理削除）；5）要件が不明確で、先にプロダクトに確認すべき点を3つ。

［要件を貼り付けてください］

握りつぶされた例外と、原因を追えないエラーを見つける

次のコードのエラー処理をレビューしてください。失敗経路だけに注目します：1）握りつぶされた例外、既定値に落とされている例外はどれか。障害が起きたとき静かに失敗しないか；2）エラーメッセージだけで原因を特定できるか（重要なid、入力値、上流の状態が含まれているか）；3）安全でないリトライはどれか（非冪等で、二重課金や二重書き込みになる）；4）失敗すべきなのに動き続けている箇所、続けるべきなのに全体を止めている箇所はどこか；5）修正後の主要な断片を示す。

```
［コードを貼り付けてください］
```

2つのリクエストが同時に届くと仮定し、共有状態を1つずつ辿る

次のコードの並行安全性をレビューしてください。方法：2つのリクエストが同じミリ秒に届くと仮定し、共有状態を順に辿ります。次をお願いします：1）共有される可変状態をすべて挙げる（メモリ上の変数、キャッシュ、データベースの行、ファイル）；2）確認と使用のあいだに隙間がある箇所（読んでから書く）を示す；3）どの程度の並行数で表面化するか、表面化したときに何が起きるかを述べる；4）最小の修正方法（ロック、一意制約、アトミック操作、冪等化）と、それぞれの代償を示す。

```
［コードを貼り付けてください］
```

移行・ロールバック・検証を一度にそろえ、少量データで先に確かめる

あなたは本番データ移行を担当するバックエンドエンジニアです。以下のテーブル定義と変更目的をもとに、三つを出力してください：1）移行スクリプト——分割実行でき、再実行可能で、1 バッチあたりの件数に上限を設けて長時間のロックを避ける；2）ロールバックスクリプト——取り消せない操作と、戻した後の確認方法を明記する；3）検証 SQL——各チェックポイント（バックフィル後、切り替え前、ロールバック前）で実行し、期待結果と合格条件を示す。スクリプトより先に、データを失う可能性が最も高い手順を指摘してください。停止時間がある前提にはしないでください。

［テーブル定義／変更目的／データ量］

散らばったログを一本の時系列にまとめ、証拠と推測を分ける

あなたは本番障害を調査するエンジニアです。以下は、複数のサービスが混ざっている可能性のあるログの一部です。次の四つを行ってください：1）出来事を時系列に並べ、最初の異常を特定する；2）ログが直接示していることと推測を二列に分ける；3）原因を確定するために足りないログ行を挙げる；4）次に実行する最小の検証を示す。最初の ERROR 行から話を始めず、その前に何が起きたかを探してください。

［ログ抜粋／時間範囲／対象サービス］

テスト一式ではなく、最小の入力で安定して再現する

あなたは境界条件の切り分けが得意なエンジニアです。次のバグに対して、最小の再現テストを一つ書いてください：1）再現に必要な入力と状態だけを残し、それ以外は削る；2）「例外が出ないこと」ではなく、期待値と実際値を具体的に検証する；3）修正前は失敗し、修正後は通ることを明記する；4）安定して再現できない場合は、足りない環境条件を挙げ、推測で埋めない。既存のテストフレームワークを使い、1 ファイルで完結させてください。

［バグの説明／関連コード／実行環境］

設定は必ず事故る前提で、既定値・秘密情報・環境差の罠を探す

あなたはリリースを承認する SRE です。役割は確認ではなく、問題を見つけることです。以下の設定ファイルと環境変数をレビューしてください：1）既定値に頼っている項目をすべて挙げ、その既定値を明記する；2）秘密情報、接続文字列、タイムアウト、リトライ、同時実行数のいずれかが環境間でずれると障害になる箇所を洗い出す；3）ローカルでは動き、本番では落ちる具体的な経路を示す；4）リスク順に、項目ごとにチェック欄のあるリリース前チェックリストを出す。書式には触れず、プラットフォームが補ってくれる前提も置かないでください。

［設定ファイル／環境変数一覧／デプロイ環境］

「監視を強化する」ではなく、時系列・仕組みの原因・検証可能な改善で書く

あなたは障害振り返りの進行役です。以下の時系列と対応記録から、振り返りを書いてください：1）システムの状態や判断を変えた地点だけを残し、タイムゾーンを明記する；2）原因は「どの仕組みが欠けていたか、どの前提が崩れたか」まで掘り下げ、「人為ミス」で止めない；3）改善項目を「実施済み／未実施」に分け、担当ロール、期限、検証方法を付ける；4）「今回は運が良かった点」を独立した節にする。「監視を強化する」「意識を高める」など、検証できない項目は書かないでください。

［障害の時系列／影響範囲／対応記録］

実際のクエリと突き合わせ、重複・無効・書き込みコストを指摘する

あなたはデータベース性能のレビュアーです。以下のテーブル定義、データ量、スロークエリをもとに、インデックスを一つずつ評価してください：1）各インデックスがどのクエリに使われるのか、WHERE / ORDER BY の該当部分を示す；2）最左プレフィックスが重複している索引、どのクエリにも使えない索引、索引が効かなくなる書き方（関数、暗黙の型変換、前方一致ワイルドカード）を指摘する；3）追加による書き込みとストレージへの影響を見積もる；4）最後に「残す／削除／追加」の三列で結論を出す。カラム名からクエリを推測しないでください。

［テーブル定義／インデックス／スロークエリ／行数］

インターフェース契約で切り、互いを待たずに着手できるようにする

あなたはテックリードです。以下の要件を、並行して進められるタスクに分解してください：1）まず並行にできない順序制約（データモデル、インターフェース契約、移行）を特定する；2）それ以外を「1 人が 1 週間で独立して届けられる」単位に切り、入力・出力・受け入れ条件を書く；3）依存の向きと着手可能日を示す；4）共有ファイルやモジュールの衝突しやすい箇所と、その避け方を挙げる。フロントエンド／バックエンドのような粗い分け方ではなく、独立して検証できる成果物で分けてください。

［要件／現行システム／チーム規模］

誰が傷つくのか、どの経路が最も脆いのか、失敗時にどう戻すのかを洗い出す

あなたは今回の変更に反対する立場です。任務は、この変更が誰を傷つけうるかを見つけることです。以下の変更内容とシステム依存関係から、次を出力してください：1）影響を受ける呼び出し元、データ、定期ジョブ、下流をすべて挙げ、それぞれどう壊れるかを示す；2）「影響を受ける人数 × 復旧の難しさ」で上位三つのリスクを並べる；3）この変更が前提にしているが、まだ検証されていない仮定を挙げる；4）リリース順序とロールバック手順を、戻す判断となる指標のしきい値付きで示す。「影響は限定的です」で締めず、具体的な根拠を出してください。

［変更 diff／依存関係／トラフィック量］

決定事項・担当者・期限だけを残す

以下の会議メモを議事録に整理してください。形式：1）この会議で決めるべきことを一文で；2）決定済みの事項（決定＋担当者＋期限の形で）；3）未決定で意見が割れている事項（双方の理由を明記）；4）次回会議までに終えること。雑談と重複はすべて削除してください。

[メモを貼り付け]

上司向け。結果とリスクを中心に

以下の断片的なメモから週報を書いてください。構成：1）今週出した結果（「進めた」ではなく検証できる事実で）；2）起きた問題と自分の対応；3）来週の予定（最大 3 項目、優先度付き）；4）あなたに決めてほしいこと・調整してほしいこと。全体 300 字以内。

[メモを貼り付け]

結論を先に、根拠とリスクを後に

私は [相手] に [案件] を報告します。ピラミッド構造で書いてください：1）最初の一文で結論を示す；2）結論を支える根拠 3 つ（各 1 文＋データか事実 1 つ）；3）リスクと私の対応；4）相手に決めてほしいこと。私が明示的に求めない限り、背景の前置きは書かないでください。

[背景資料]

相手の反応を事前に練習しておく

私は [相手] と [案件] について話します。目標は [目標]、一番怖いのは [懸念] です。次をお願いします：1）相手の反応として最もありそうな 3 つと、その背後にある本当の関心；2）それぞれに対する最初の一言；3）私の言い方のうち、最もこじれやすい箇所；4）「決裂した場合」の退路。

長い文書を、チェックできる手順に変える

以下の文書を読み、実行チェックリストを作ってください。要件：1）各手順はそのまま実行でき、動詞で始まる；2）依存関係（どの手順の後に来るか）を明記；3）最も抜けやすい手順 3 つに印をつける；4）人が判断する必要がある分岐は別に列挙。

[文書を貼り付け]

まず問い返し、次に復唱する。作ってから間違いに気づかないために

あなたは経験豊富なプロジェクトリーダーで、いまは私の要件整理の相棒です。曖昧な依頼を受け取りました：「[上司や顧客の原文]」。まだ解決策は出さないでください。次をお願いします：1）着手に必要だが、その一文には書かれていない情報を重要度順に最大 6 件；2）各項目について、あなたが推測する既定の答えと、その推測が外れた場合に起きる問題；3）私の理解した依頼を 100 字で復唱し、どこが私の原文でどこがあなたの補足かを明示。

ボールを返されず、協力してもらう

あなたは部署をまたいで物事を進めるのが得意なプロジェクトリーダーです。[部署] に [具体的な作業] を [期限] までに終えてもらうメールを書いてください。背景：[必要な理由、すでに誰と話したか]。要件：1）冒頭の一文で、相手に何をいつまでにやるかを明示；2）私の予定だけでなく、相手への影響を書く；3）相手の負担感を下げるため、私が済ませた事前作業を列挙；4）日付を特定したフォローの仕方；5）200 字以内、冒頭に「お忙しいところ恐縮ですが」的な定型は使わない。

「なんでも少しできる」を、選別できる条件に分解する

あなたは採用責任者です。[職種名] の JD を書いてください。入力：チームの状況 [一文]、この人が解決すべきこと [1〜2 件]、予算 [レンジ]。要件：1）最初の段落はこの職種が存在する理由。会社紹介は書かない；2）職務は実際に行う具体的な行動として 4〜6 項目；3）必須条件は 5 つ以内、すべて面接で検証可能に。歓迎条件は別に記載；4）採らない人物像を明記；5）「プレッシャーに強い」「責任感がある」など検証できない言葉は使わない。

「なんとなく良さそう」ではなく、根拠で語る

私の面接メモから候補者の評価を書いてください。職種の重要要件：[JD の要件を貼り付け]。面接メモ：[質疑応答を貼り付け]。要件：1）要件ごとに「上回る／満たす／満たさない」を付け、各評価には候補者の発言そのものか具体的な行動を根拠として引用；2）判断に迷う点と追加で確認すべき質問を別の段落で；3）結論を明示（進める／もう一巡／不採用）；4）「コミュニケーション力が高い」「ポテンシャルがある」など根拠のない形容詞は使わない。

一度に全部聞く。3 往復しても価格の前提が分からない事態を避ける

あなたは購買責任者です。[サプライヤーの種類] 宛ての見積依頼メールを書いてください。購入対象 [物品／サービス]、数量 [数量]、希望納期 [時期]。要件：1）要件はリストで提示：仕様、数量、納品場所、検収基準；2）同一フォーマットでの見積を依頼：単価、税、送料、支払条件、見積有効期限、最小ロット；3）後から値上がりしやすい 3 点を明確に：仕様変更の費用、納期遅延の補償、保証範囲；4）末尾に、複数社を比較中であることと回答期限を明記。

まず反対者の立場を取り、リスクを追跡できる表にする

あなたは穴を探すために呼ばれたプロジェクト監査役で、このプロジェクトは遅れる前提で考えます。プロジェクト情報：[目標、締切、人員、依存先]。リスク表を出力してください。列は：リスク／兆候／影響（時間・コスト・品質）／発生確率／こちらで打てる緩和策／担当者。要件：1）最低 8 行、人員・外部依存・要件変更・技術的不確実性を網羅；2）発生確率×影響で並べる；3）いま介入できるものだけ。すでに起きたものは別枠；4）緩和策は実行可能なものにする。「コミュニケーションを強化する」は不可。

数百件のメッセージから、誰がいつ何をするかを拾い出す

以下のグループチャットのログをアクション項目に整理してください。要件：1）明確な行動か結論があるメッセージだけを残す。雑談・絵文字・重複した確認は削除；2）表で出力：項目／担当／期限／現状／発言の要約；3）誰も担当していない項目は「未割当」として別セクションに；4）互いに矛盾する発言は別セクションにまとめ、誰が何を言ったかを明記；5）最後に、今日中に回答が必要な質問を 3 つ。

[チャットログを貼り付け]

コストを示し、選択肢を出して断る

以下の急な依頼を、そのまま返信文に書き換えてください。まず相手が本当に必要としている成果と最終期限を確認し、この作業を割り込ませるとどの約束済みの納品がずれるのか（プロジェクト名と日付まで）を書きます。そのうえで A/B の二案を示し、それぞれのコスト（どの約束がずれるか、範囲をどれだけ削るか、人を足すか）を明記します。今日中にどちらかを選んでもらい、返信がなければ B 案で進める旨を添えてください。「できるだけ」「時間が空いたら」は使わず、謝罪は一度までにします。

[依頼文]
[現在のスケジュール]

事実と代替案で、角を立てずに伝える

以下の状況を、上司への反対意見として書いてください。構成：1）自分が理解している目標を先に復唱し、議論の対象が同じであることを確認する；2）懸念の根拠になる検証可能な事実かデータを一つだけ示す；3）上司の案が成立する条件を認める；4）代替案とそのコストを示す；5）いつまでに決めてほしいかを明記する。人ではなく案について書き、300字以内、「私はこう思う」「問題かもしれない」で始めないこと。

[背景]
[上司の案]
[根拠]

能力ごとに、掘り下げられる質問を一つ

以下のJDと等級をもとに、45分の面接を設計してください。まずこの職種で本当に検証すべき能力を4〜5項目、それぞれ8文字以内で挙げます。各項目に主質問1つと追質問2つを付け、主質問は過去に実際にやったことを聞く形にします。質問ごとに「合格の答え方／不合格の答え方」を書きます。最後に候補者からの質問用に5分残します。なぞなぞ、星座、結婚・出産の予定は聞かないこと。

[JDを貼り付け]
[等級]

影響と復旧を先に、原因はその後に

以下の事故情報から、顧客向けの通知文を書いてください。構成：1）いつ、どの機能が、誰に影響したか；2）現在は復旧したか、何をしたか；3）確認できた原因だけを書き、未確認は「調査中」と明記する；4）今後72時間の再発防止策と担当者；5）補償と次回の更新時刻。責任転嫁や「一部のユーザー」「システムの一時的な変動」のような曖昧な表現は使わず、400字以内に収めます。

[時系列]
[影響範囲]
[確認済みの原因]

なぜやるか、何を出し、どう成功を測るか

以下の背景を、1枚のプロジェクト企画書に整理してください。順序：1）課題（誰が、どんな場面で、いくらの損失か。数字で示す）；2）やらない場合に何が起きるか；3）目標と非目標（各3つ以内）；4）進め方（5ステップ以内）と最大のリスク；5）成功指標（ベースライン→目標→測定時期）；6）必要なリソースと意思決定ポイント。1枚に収め、ビジョンや形容詞は削り、「体験を向上させる」のような検証できない目標は書かないこと。

[背景]
[リソース制約]

繰り返し出る「放置案件」に担当を付ける

以下の議事メモを読み、繰り返し出ているのに誰も明確に担当していない事項を抽出してください。表の列は：1）事項（何を納品するかを一文で）；2）出た回数と実際の発言；3）誰も引き受けなかった理由（権限がない／余力がない／責任範囲が不明／単なる懸念）；4）具体的な役割への割り当て案（「関係者」ではなく職務名）；5）放置した場合、いつ問題になるか。最後に、その場で決めるべき事項を一つだけ挙げます。

[メモを貼り付け]

「他の人が引き継げるか」で作る

私の職種と現在の業務から、退職時の引き継ぎチェックリストを作ってください。四つの区分：1）進行中の業務（現状、次の一手、期限、窓口）；2）自分しか知らないこと（アカウント、集計定義、過去の判断、外部連絡先）；3）文書と権限（Notion ページ、保管場所、移管方法、承認者）；4）引き継ぎ後の対応範囲（最終出社日、いつまで質問に答えるか）。各項目に受取人と「引き継げたことをどう確認するか」を書き、「引き継ぎ済み」のような検証できない状態は書かないこと。

[職種]
[現在の業務]
[最終出社日]

曖昧なフィードバックを検証可能な作業に

以下の曖昧なフィードバックを、実行できる作業に翻訳してください。まず、それが指しうる具体的な問題を3つ挙げ、それぞれに観測できるシグナルを添えます。次に、私が答えるべき3つの質問（目標、現状、合格基準）を投げかけてください。そのうえで既定案として、変えるもの・変えないもの・検証方法・作業量の目安を示します。すぐに作り直さず、「最適化」を「作り直し」と解釈しないこと。

[曖昧なフィードバック]
[現在の版／データ]

たとえ → 定義 → よくある誤解 → セルフチェック

ファインマン・テクニックで [概念] を説明してください。順序：1）10 歳でも分かるたとえ；2）正確な定義と、そのたとえが成り立たない箇所；3）最もよくある誤解と、それがなぜ誤りか；4）セルフチェック問題 2 問（基本 1 問、間違えやすいもの 1 問）。

一度に 1 問だけ。答えに詰まるまで続ける

あなたはソクラテス式の導師です。[テーマ] について、一度に 1 つだけ質問し、私が答えてから次の層へ進んでください。ルール：1）答えを教えない；2）私の答えが曖昧なら具体例を求めさせる；3）私が間違えたら反例を示し、矛盾を自分で気づかせる；4）最大 8 往復、最後に私がどこで詰まったかをまとめる。

定義を並べるのではなく、境界がどこかを示す

[概念 A] と [概念 B] を比較してください。要件：1）それぞれ一文で何かを示す；2）重要な差異 3 つ（軸は自分で選び、なぜ重要かを説明）；3）「A に見えて実は B」の例を 1 つ；4）この区別がまったく重要でないのはどんな場合か。

まず何を証明したのかを問い、それから細部へ

以下の論文の抜粋を読むのを手伝ってください。出力：1）解こうとしている問題；2）手法の核心を平易な言葉で；3）実験が証明したこと、証明していないこと；4）著者自身が認めている限界；5）再現するとしたら最も難しい工程。要旨の言い換えはしないでください。

[論文の抜粋を貼り付け]

最も混同しやすいところだけを問う

以下の教材から 8 問作ってください：単一選択 4 問、複数選択 2 問、短答 2 問。要件：1）混同しやすい細部、見落としやすい細部だけを問う。暗記ものの数字は出さない；2）各問に答えと一文の解説；3）各問が問う能力（記憶／理解／応用）を明記。

[教材を貼り付け]

まず骨格を掴み、どの章を精読するか決める

私は [解決したいこと] のために『[書名]』を読みます。次をお願いします：1）全書の主張を 5 文で説明し、主張同士の依存関係も示す；2）章マップを作り、各章がその筋で何を担うかを一文で；3）中核となる 2〜3 章と、飛ばせる部分を理由付きで示す；4）著者が証明せずに断定している箇所；5）読み終えたときに答えられるべき質問 3 つ。

どの塊があり、何が何に依存するかを見てから学ぶ順を決める

私は [目的] のために [分野／スキル] を学びます。まず知識マップだけを示してください。解説はまだ不要です：1）4〜7 のモジュールに分解し、各々が解く問題を一文で；2）モジュール間の依存を表で示す（B の前に A が必要）；3）成果の 80% を決める 20% はどこか、後回しでよいものはどれか；4）私の目的に沿った最短ルートと、そのルートが捨てるものを示す。

反対側に回らせ、間違いだけを指摘させる

これが私の [概念] の理解です：[私の説明]。反対側に立って、1 つだけやってください：私が間違っている箇所を探す。要件：1）文ごとに「正確／不正確／曖昧」を判定し、不正確なものはどこが誤りか示す；2）私が混同している 2 つの概念を指摘し、違いを一文で；3）私の理解どおりだと誤った結論になる具体例；4）聞いていない知識を足さない。まず肯定しない。

逆に説明してみて、どこが本当の穴か知る

これから [概念] を説明します。あなたは厳しい聞き手です。ルール：1）私が話し終えたら、3 点だけ指摘する——言い間違えた箇所、重要な手順を飛ばした箇所、定義を暗唱しただけで説明になっていない箇所；2）それぞれに「なぜ」を 1 つ問い返す。答えられなければ記録する；3）私の代わりに答えを補わない。私が求めるまで待つ；4）最後に、最も曖昧だった 2 箇所を次回復習の重点として挙げる。

では始めます：[私の説明]

専門用語・略語・業界の言い回しを一度に片付ける

以下の [分野] の資料には業界用語が多く含まれています。対照表を作ってください：用語／字義／この文脈での実際の意味／知らないと何を見落とすか。要件：1）私が知らなさそうな語だけを載せる。常識語は不要；2）混同しやすい類義語は別の行に分けて違いを説明；3）業界で複数の使われ方がある語は、どれに当たるかを明示；4）最後に、予備知識なしで読めるよう全体を 100 字で書き換える。

[資料を貼り付け]

細部ではなく、境界と入出力から始める

[システム名]（例：[具体例]）の分解を手伝ってください。順番に：1）まず境界を引く——中にあるもの、外にあるもの；2）入力・出力・維持すべき目標を列挙；3）3〜6 のサブシステムに分け、それぞれの責務と相互のインターフェースを示す；4）ボトルネックや単一障害点はどこか；5）具体的なシナリオを 1 つ流し、私が見落としがちな工程に印をつける。情報が足りない箇所は「不明」と書き、作らないこと。

週ごとの目標と、検証できる成果物を必ず 1 つ

30 日で [スキル] を学びます。1 日に使える時間は [X] 時間、現在のレベルは [レベル] です。計画を作ってください：1）4 週に分け、週ごとに明確な能力目標を 1 つ；2）各週に練習課題と、検証できる成果物を 1 つ（人に見せられるもの）；3）最も挫折しやすいのは何日目か、そのとき何をすべきか；4）20% の余白を残す；5）「本当に身についたか」の判定基準を示す。「習熟している」のような言葉は使わない。

症状から仕組みまで下りる。「不注意」で止めない

次の問題を「なぜ」の五回で根本原因まで追ってください：[問題の症状を記述]。ルール：1）各層で最も可能性の高い原因を一つだけ、「X だから Y」の一文で書く；2）各層のあとに根拠の強さ（データあり／推測のみ）を明記する；3）根拠が足りない層では無理に進めず、一週間以内に実行できる確認作業を示す；4）五層で止め、因果の連鎖を出力し、実際に手を打てる層を明示する。

前提→推論→結論。書かれていない一段を補う

以下の文章を読み、その議論の構造を描いてください：[記事または節を貼り付け]。出力：1）中心となる結論を一文で；2）前提を番号付きで挙げ、事実の記述か価値判断かを区別する；3）前提から結論への導き方を書き、著者が省略した暗黙の前提を補う；4）議論が飛んでいる箇所（結論が前提より多くを主張している点）を示す；5）反論するとしたら、どの前提を攻めるのが最も安上がりか。

定義は簡単。境界は反例でしか見えない

[概念] を学んでいます。定義と典型的な例は二つ知っています。三つの反例を、それぞれ次のケースとして挙げてください：1）定義に当てはまりそうで、実は当てはまらないもの；2）ある条件が成り立つときだけ該当し、条件が変わると該当しなくなるもの；3）よく教科書的な例として使われるが、実際は境界事例であるもの。各反例について、定義のどの要素から外れるのか、誤って分類すると何が起きるのかを書いてください。

間違えたとき、どの段階でずれたかを教える

以下の教材で診断型のクイズを作ってください：[教材を貼り付け]。要件：1）まずこの主題を理解する 4〜6 の段階（例：変数を特定する→適切な式を選ぶ→単位をそろえる→結果を解釈する）を示す；2）各段階に 1〜2 問、数は少なくてもその段階に照準を合わせる；3）私が答えたら、まずどの段階でつまずいたかを判定し、その段階がなぜ間違えやすいかを説明する；4）同じ段階で二問続けて間違えたら、いったん止めてその段階を説明し直してから進む。

各転換点は、前の段階の詰まりを解いたもの

[領域] の発展を年表として整理してください。要件：1）4〜6 の段階に分け、それぞれおおよその年代と一行のテーマを付ける；2）各転換点について、前の段階がどこで詰まっていたか、何がそれを解いたか、代償は何だったかを書く；3）初期の方法で今も使われているものと、生き残った理由；4）現在の段階で次に覆されそうな前提。

よいたとえを一つ、そして自分で壊す

[概念] をたとえで説明し、そのたとえがどこで崩れるかまで書いてください。要件：1）主となるたとえを一つ、概念のどの要素に対応するかを示す；2）崩れる箇所を二つ以上、それぞれどんな誤った推論を生むかを含めて示す；3）別の角度からより正確な代替のたとえを一つ；4）主のたとえに従うと、どこで判断を誤るかを短い例で示す。

すぐ使えるものから逆算し、それ以外は削る

[期間] 以内に [スキルやツール] を使って [具体的なタスク] を仕上げる必要があります。最小限の学習パスを示してください：1）そのタスクの最低限の完成基準を先に定義する；2）基準を満たすのに必要な知識だけを依存順に並べる；3）各項目に 15 分以内で終わる練習を一つ；4）「今は学ばなくてよい」項目とその理由を明示する；5）学ぶのをやめて手を動かし始めてよい判定方法。

「研究によると」を、検証できる形に分解する

次の主張を検証してください：[主張を貼り付け]。1）データで反証できる具体的な命題に分解する；2）裏づけに必要なデータ（サンプル、期間、対照群）と、主張に欠けている項目を示す；3）相関と因果を分け、代わりの説明を一つ以上挙げる；4）出所の強さを評価する（一次研究／二次報道／事業者の資料／出所なし）；5）数字をどこで確認できるかのチェックリストを出す。

中国語の描写 → 構造化された英語プロンプト

以下の中国語の描写を、英語の画像生成プロンプトに展開してください。構成：被写体と動作 → 素材と環境 → スタイル → ライティング → 構図とカメラ → アスペクト比の指定（--ar）。要件：実際に描けるレベルまで具体化し、「きれい」「高級感」といった語は使わないこと。

[中国語の描写]

「きれいかどうか」ではなく、使いやすさの観点で問題を挙げる

以下は私の UI デザインの説明です：[説明]。ユーザビリティの観点でレビューし、問題を挙げてください：1）情報の階層は明確か、ユーザーが最初に目にするのは何か；2）主要な操作はすぐ見つけられるか；3）どこでユーザーが思い出す・推測する必要があるか；4）空状態・エラー状態・ローディング状態をそれぞれどう設計するか。配色が美しいかどうかは評価しないこと。

引き継いだ開発者が、あなたに聞かずに実装できるように

以下の要件をデザイン仕様書にしてください（コードは不要）。含めるもの：1）ユーザーが完了すべき操作を手順順に；2）各手順の UI 要素と状態；3）例外と境界ケース；4）やらないこと（明確な除外項目）；5）受け入れ基準。

[要件]

「高級感がほしい」を実行できる要件に翻訳する

[作るもの] を作りたいのですが、デザイン用語が分からないままデザイナーに依頼する必要があります。ビジュアル要件書を書いてください：1）このデザインの用途と対象者；2）伝えたい印象（形容詞 3 つ＋具体的な参照物）；3）必ず入れる要素；4）絶対に入れない要素；5）成果物リストとサイズ。

好きな画像をリンクで保存するだけでなく、再現できるプロンプトに分解する

これは私が見つけた参照画像です：[画像の説明、または画像を添付]。このスタイルを再現できるプロンプトを逆算してください：1）画面の構成を分解——被写体と素材、光源の方向と色温度、レンズと被写界深度、構図の重心がどこにあるか；2）スタイルの手がかりを抽出——筆致や質感、近い流派とメディア、後処理の痕跡；3）「被写体→環境→スタイル→ライティング→カメラ→パラメータ」の順で 1 つの英語プロンプトにまとめる；4）最も崩れやすい特徴を 3 つ挙げ、対応するネガティブプロンプトを添える；5）受け入れチェックリスト：生成結果にどの特徴が出ていれば再現成功とみなすか。形容詞を並べるだけにしないこと。

色番号ではなく、導出できて調整もできる配色ルールを出す

[プロダクト/ページ] の配色を決めたいのですが、色番号をいくつか渡されるだけでは困ります。導出できる配色ルールをください：1）まずこの色が果たす目標を順位づけ（可読性、情緒、ブランド認知）し、その理由を説明；2）主色がなぜその色相なのか、根拠を示す；3）ニュートラルカラーの階層ロジック——背景・カード・区切り線・副次テキストがそれぞれ明度でどれだけ差をつけるか；4）アクセントカラーの使用量を規定——1 画面で最大何回まで、どの要素にだけ使うか；5）ダークモードに切り替えるときの調整ルール。実行できない「高級グレー」のような言葉は使わないこと。

データがないとき、読み込みに失敗したとき、画面は何を言うべきか

[ページ/機能] の空状態とエラー状態のコピーを、5 つの場面について書いてください：1）初回利用でまだデータがない；2）絞り込み後に結果がない；3）失敗したが再試行できる；4）権限がない；5）ネットワークが切れた。各場面で 3 つずつ：メインコピー（12 語以内で何が起きたかを言う）、補足説明（なぜか、次に何をするか）、ボタン文言（動詞で始める）。ルール：責任をユーザーに押しつけない、「エラーが発生しました」のような情報のない言い方をしない、媚びない、感嘆符を使わない。最後に、同じコピーを使い回せる場面を指摘すること。

1 枚のフォームで、ユーザーが覚えて決めることを数える

これは私のフォーム設計です：[フィールド一覧とグループ]。認知負荷の観点でレビューしてください：1）ユーザーが同時に覚えておく必要がある情報が何項目あるか数え、3 項目を超える箇所を指摘；2）後回し・統合・システム側で補完できるフィールドはどれか；3）他の場所で調べないと選べない選択肢はどれか；4）エラーはどのタイミングで出るか、入力済みの内容が消えないか；5）フィールドを「必須／後から追加可／削除可」に分類し直す。最後に、削ったフィールド順の版と、削除した各フィールドを何で代替するかを示すこと。

「若い、専門的、温度がある」を、取捨選択できる一文にする

私たちのブランドの調性は：[形容詞 3 つ＋短い説明]。これを 4 つのデザイン原則に変換してください。各原則は必ず：1）取捨選択に使える一文にする（例：「入り口を 1 つ減らしても、主要操作を探させない」）；2）良い例と悪い例を 1 つずつ、UI 要素のレベルまで具体化；3）他のどの原則と衝突するか、衝突時にどちらを優先するかを示す；4）最も誤用されやすい形を説明する。形容詞のリストを出すだけにせず、「ユーザー中心」のようなどの製品にも当てはまる言葉は書かないこと。

線幅・角丸・視覚的な重さが揃っていないものを特定する

これは私の画面で使っているアイコンです：[アイコン一覧またはスクリーンショット]。一貫性をチェックしてください：1）線幅は統一されているか、同じサイズに換算して何 px 違うか；2）角丸と端点の処理は揃っているか；3）視覚的な重さは均衡しているか、同サイズで重すぎ・軽すぎに見えるのはどれか；4）メタファーは統一されているか、同じ概念を 2 通りで描いていないか；5）必ず描き直すべき 2〜3 個を挙げ、描き直しの仕様（キャンバス、線幅、角丸、余白）を示す。アイコンの良し悪しは評価しないこと。

間隔・文字サイズ・階層を、開発が推測しない仕様にする

このデザインを、開発がそのまま使える仕様にしてください：[デザインの説明またはスクリーンショット]。要件：1）スペーシングのスケールを定義し（例：4/8/12/16/24/32）、このページが実際に使っている段だけを示す；2）ブロックごとに、外側マージン、ブロック間隔、要素の内側パディング、テキストとアイコンの間隔を列挙；3）文字サイズ・行高・字重の階層関係、および折り返し可能なテキストと折り返し後の揃え方を明示；4）正確に固定すべき箇所と柔軟でよい箇所を指定；5）狭い画面での値の変化を示す。「間隔は統一して」だけで終わらせないこと。

不満の山から、直すべきことと直さなくてよいことを見極める

以下はユーザーフィードバックの原文です：[フィードバックを貼付]。デザイン変更リストに変換してください：1）まず 6 カテゴリ以内の問題に統合し、各カテゴリの出現回数を記す；2）ユーザーが言ったことと実際に遭遇したことを分け、表現の問題かフローの問題かを示す；3）各項目に変更アクションを 1 つ、UI・フロー・コピーのどれを変えるか明記；4）「影響人数 × 修正コスト」で並べる；5）従うべきでない提案を挙げ、理由を述べる。フィードバックをそのまま要件にせず、声が大きいという理由で上位に置かないこと。

「この画像がいい」を、グリッド・階層・密度のルールに落とす

これは私が好きな参考画像です：［添付または説明］。この画像を再現したいのではなく、他のページにも使えるルールに分解したいです。次の 6 層で抽出してください：1）グリッドと版面幅；2）余白のリズム（4 または 8 の倍数で数値を明記）；3）文字サイズの階層と行間；4）色の役割（背景・面・文字・アクセントがそれぞれ占める面積）；5）角丸・罫線・影の値；6）情報密度（1 画面に視覚ブロックがいくつ乗るか）。各ルールは数値か検証できる条件文にしてください。あわせて、この画像に固有の偶然（写真の内容、文言の長さ）でルールにできないものを指摘してください。最後に、内容がまったく違うページをこのルールで記述してください。

ユーザーが来た唯一の目的から、最初の画面の優先順位を組み直す

これは私のページです：［スクリーンショットまたは要素の一覧］。ファーストビューの情報の優先順位をレビューしてください：1）実際に見えている要素を列挙し、面積とコントラストから現在の視覚的重みを順位づける；2）ユーザーがこのページに来た唯一の目的は何かを判断し、最初に目が行くべき要素を 1 つだけ挙げる；3）注意を奪っているのに不要なもの（装飾、重複した導線、販促枠）を指摘する；4）サイズ・コントラスト・位置・余白の 4 つのレバーで並べ替えた案を示し、変更点を注記する；5）遮蔽テスト：3 要素しか残せないならどれを残すか、理由つきで答える。「分かりやすく」といった言葉は使わないでください。

グリッド・線幅・角丸を数値で決め、次の 20 個で議論しないようにする

［プロダクト］のアイコン規格を決めます。今後 20 個以上を描き、外部に依頼する可能性もあります。そのまま実行できる仕様を書いてください：1）キャンバスとライブエリア（例：24×24 のキャンバス、20 のライブエリア、四方に 2 の余白）；2）線幅の値と、拡大縮小したときに一緒に変えるか；3）角丸と端点の処理；4）視覚的な重さの補正（同じサイズで円・四角・三角をどう調整するか）；5）命名と書き出し（サイズ、形式、ダークモード用の版）；6）チェックできる項目 5 つ。最後に「正しい例」「誤った例」をそれぞれ言葉で示し、最も間違えやすい点を添えてください。「シンプルで統一された」といった形容詞は使わないでください。

「新規作成」を押した後の 400ms に何を起こすか

想定：一覧ページが初回で空の状態です。ユーザーが「新規作成」を押して送信し、最初の 1 件が作られます。空の状態から内容が現れるまでの遷移を設計してください：1）状態の並び（空、送信中、スケルトン、部分表示、完了）；2）各段階の時間とイージング。全体は 400ms 以内に収める；3）レイアウトのずれを防ぐ方法（高さの確保、スケルトンと実コンテンツの寸法を一致させる）；4）フォーカスとスクロール位置の扱い；5）アクセシビリティ（prefers-reduced-motion のときに何に変えるか、aria-live が必要か）；6）この遷移でユーザーに確認させる 3 つのこと。最後に、各段階でユーザーに何が見えるかを時系列の表にしてください。

言われたところではなく、実際に起きたところを直す

ユーザーの言葉そのままです：［クレームを貼り付け］。言われたとおりに実装しないでください。次のように分解します：1）「言ったこと / 実際にしたこと / 実際に起きたこと」の 3 列で書く；2）考えられる画面側の原因を 3 つ、可能性の高い順に根拠つきで挙げる；3）最も可能性の高いものに最小の変更を提案し、文言・部品・導線のどれを変えるか明記する；4）文字どおりに直すとどんな新しい問題が起きるか指摘する；5）検証方法を示す（どの指標を、どれくらい見れば直ったと言えるか）；6）ユーザーへの返信を一文で書く。できない約束はしないでください。

コントラスト・にじみ・階層を、目視ではなく数値で測る

これは私のダークモードの配色です：［色値またはスクリーンショット］。可読性のリスクを、項目ごとに数値で評価してください：1）本文・補助テキスト・プレースホルダー・無効状態と、それぞれの背景とのコントラスト比（4.5:1 を下回るものを指摘する）；2）背景を純黒にするか #121212 のような浮いた面にするか、トレードオフつきで理由を示す；3）暗い背景で振動して見える高彩度色はどれか、彩度を下げるか明度を上げる必要がある；4）影はダークモードではほぼ見えないため、階層を何で表すか；5）画像、白背景のイラスト、1px の区切りの扱い；6）10 分以上読み続けたときの疲労点。最後に修正後のパレットを示してください。

フォームを詰めるのではなく、項目ごとに削除の審査をする

これは私のフォームの項目です：［項目一覧と用途］。各項目を削除の審査にかけ、それぞれ 4 つ答えてください：1）それが無くてもユーザーは目的を達成できるか；2）その情報は他の場所から得られないか（アカウント、前回の入力、端末、第三者）；3）後で聞けないか（設定、2 回目のログイン、結果画面）；4）何と引き換えか（法令対応、不正対策、パーソナライズ、販促）。離脱 1 回分の価値があるか。そのうえで「必ず削除・統合可・後回し可・必ず残す」の 4 列で結論を出してください。最後に削減後の項目数と順序、完了率がどう動くかの見積もりを添えてください。減らすための減らし方はしないでください。

コントラスト・タップ領域・競合要素・位置の 4 つに分解する

［ページ］の主ボタンに「目立たない」という指摘がありました。測定できる項目に分解してください：1）ボタンの文字と地の色のコントラスト、ボタンとページ背景のコントラスト（それぞれ現状値と目標値を示す）；2）タップ領域のサイズ。44×44 に達しているか；3）同じ画面で、より明るい・大きい・彩度が高い要素はいくつあるか。列挙する；4）ユーザーの走査線上で何番目の視覚的な停留点か；5）この画面の主操作は 1 つだけか。そのうえで改善案を 3 つ示し、それぞれ「変える変数は 1 つだけ」と明記し、想定効果と検証方法（最初のクリックまでの時間、タスク完了率）を添えてください。「大きく太くする」だけで済ませないでください。

最も間違っていそうな点だけを探し、長所は補わない

以下は私の判断です：[私の結論]。やることは 1 つだけ：この判断で最も間違っていそうな点を指摘してください。要件：1）反例または反証データを少なくとも 1 つ；2）私が見落としている変数を指摘；3）この判断が誤っていた場合、いつ最初に露見するかを示す。慰めないこと、長所を補わないこと。

比較軸、最悪のケース、それぞれが適する条件を出す

[案 A] と [案 B] のどちらかを選びたい。要件：1）比較軸を 4 つ挙げ、なぜその 4 つが重要かを説明；2）それぞれの最悪のケースと、それが耐えられるか；3）どういう条件なら A、どういう条件なら B か；4）私の制約 [私の制約] を踏まえ、明確な提案を 1 つ出す。「どちらにも長所がある」で終わらせないこと。

すでに失敗したと仮定して、原因を逆算する

[プロジェクト/計画] が半年後に完全に失敗したと仮定してください。事後振り返りを書いてください：1）失敗した最も可能性の高い理由 5 つを確率順に；2）各理由について、今の早期シグナルは何か；3）今から予防できる原因はどれか；4）失敗確率を下げるために 1 つだけできるなら何か。

結論に書かれていない前提を洗い出す

以下は私の推論です：[推論過程]。次を行ってください：1）この推論に含まれる暗黙の前提（明言されていないが成立していなければならない前提）をすべて列挙；2）最も脆い前提を指摘；3）その前提が成立しない場合、結論はどう変わるか；4）より確信を持つために必要な情報は何か。

同じ数字も、定義が変われば別の話になる

私が見た主張はこれです：[結論＋データ]。やることは 1 つだけ：その集計の定義を分解してください。1）指標の分子と分母はそれぞれ何か、本来含めるべきでないものが混ざっていないか；2）時間軸はどう選ばれたか、別の時間軸でも結論は成り立つか；3）サンプルは誰か、誰が除外されているか；4）平均値・中央値・百分率のどれか、別の指標にするとどうなるか；5）生存者バイアス、または分母が縮んだことによる見かけの成長はないか。最後に一文：この数字が最も誤読されやすいのはどの点か。結論の正誤は評価しないこと。

二つが一緒に動いても、片方が他方を動かしたとは限らない

私は [A] が [B] を引き起こすと考えています。根拠は：[観測された相関またはデータ]。この因果判断を反証してください：1）A と B の両方を説明できる第三の変数を少なくとも 3 つ；2）逆の因果、つまり B が A を引き起こす経路の可能性；3）この相関が消える条件；4）因果と相関を区別できる検証方法と、必要なデータ；5）今あるデータだけで言えるのはどこまでか。私の判断を先に肯定しないこと。

始める前に、どうなったら止めるかを決めておく

[計画] を始めようと思っており、[時間/資金/人員] を投じる予定です。開始前に退出条件を決めてください：1）方向が違うと分かる観測可能なシグナルを 3〜5 個；2）各シグナルに確認の時点、閾値、判定者を設定；3）「一時的な不調」と「方向の誤り」を区別し、それぞれ具体例を 1 つ；4）退出時に投じた分をどう守るか；5）「止めないが規模を縮める」中間案。励ましは不要で、私が実行すると仮定しないこと。

データがなくても桁を出し、どこが最も怪しいかを言う

[問い、例：この街で 1 日に何杯のコーヒーが売れるか] を推定してください。要件：1）単独で推定できる 3〜5 の因子に分解し、積または和の関係で書く；2）各因子に値・根拠・上下限を与える；3）結果を計算し、精密な数ではなく桁の範囲で示す；4）結果への影響が最大で最も信頼できない因子を指摘；5）誤差を半分にするために先に調べるべき数値を示す。1 の位まで正確な偽の答えを出さず、導出も省略しないこと。

取り消せる決定と取り消せない決定を分ける

これは私の計画です：[計画内容]。その中で最も高くつく不可逆部分を見つけてください：1）各決定を可逆・コスト付きで可逆・不可逆に分類；2）不可逆な項目について、撤回の代償が具体的に何か——金、時間、関係、機会；3）実は 2 段階に分けられる決定を指摘し、まず小規模で可逆な版を行う；4）実行順序の提案：先にやるもの、できるだけ後ろに回すもの；5）どれか 1 つの判断ミスで計画全体が続行不能になるのはどれか。

聞こうとも思わなかった問いを列挙する

私は [やること] をします。現在の理解と情報は：[現状の説明]。私が「知らないと知らない」ことだけを挙げてください：1）この領域で素人が見落としがちな重要な変数 5 つ；2）私が思いつかなかったが、聞けば計画が変わる質問；3）私の説明の中で曖昧で、解釈が分かれうる言葉；4）これをやったことがある人が私の計画を見たら、最初に聞く 3 つの質問；5）「計画を覆すか」で並べる。すでに述べた内容の要約はしないこと。

藁人形ではなく、相手の最良版を書く

私の立場は：[立場]。反対側の最強版を書いてください。私が反論に困るくらい強く：1）まず相手の語彙で私の立場を言い直し、歪みがないか確認；2）最も効く反対理由を 3 つ、態度ではなく証拠かメカニズムを添えて；3）私の立場が確かに成立する条件と、その条件が崩れうる理由；4）反対側の最も弱い環を指摘し、私が応答できるようにする；5）この対立が事実・価値・利害のどれかを判断する。

混ざった一段落を 3 つの成分に分ける

以下の文章は事実・推論・嗜好が混ざっています：[テキストを貼付]。文ごとに分けてラベルを付けてください：1）事実——第三者が独立に検証できる；2）推論——事実から導かれるが誤りうる、推論の連鎖を書く；3）嗜好——価値判断や立場で、それ自体に正誤はない。そのうえで：4）事実として使われているが実は推論か嗜好な文はどれか；5）データを 1 つ足せば検証できる推論はどれか；6）事実だけを残し、修飾を削った版を示す。

最も安い検証で、結論を先に崩す

私の結論は：[結論]。やることは 1 つだけ：これが成り立たないことを示す最短ルートを探してください。要件：1）最も安く済む検証を 1〜3 個、それぞれ [時間／予算] 内で終わる形で示す；2）各検証について「どんな結果が出たら結論は不成立か」を明記する；3）「コストが最低で、一発で否定できる」順に並べる；4）その検証を 1 つ終えれば残りは不要になるものを指摘する；5）1 つしかできない場合、どれをやるか。成立する理由は論じないこと。

はい／いいえ、または数字 1 つで答えられるところまで

私の大きな問いは：[問い]。独立して検証できる小問のセットに分解してください。要件：1）4〜6 個に分け、それぞれ「はい／いいえ」か数字 1 つで答えられる形にする；2）各小問について、必要なデータ、入手先、おおよその所要時間を書く；3）「いいえ」なら大きな問いが決着するものを示す；4）「得られる情報 ÷ コスト」の順に並べ、先に調べる 3 つを挙げる；5）私が混ぜている 2 種類の問い、事実の問いと選択の問いを切り分け、どちらに属するか示す。大きな問いには答えないこと。

同じ言葉が、2 つの文で同じ意味ではない

次の論証です：[論証原文]。この中の概念のすり替えを見つけてください。要件：1）繰り返し出てくるキーワードを挙げ、文ごとの実際の意味を書き出す；2）どこで意味 A から意味 B に滑ったかを、2 つの文を並べて引用して示す；3）その滑りによって、どの結論が成り立つように見えるかを説明する；4）概念を 1 つの意味に固定して、論証を書き直す；5）書き直しても成立するか、しないなら欠けている段はどこか。文章の巧拙は評価しないこと。

安く見積もっている部分だけを調べ、やる価値は評価しない

この計画の見積もりは：[総コスト／工期]。調べてほしいのは 1 点だけ：この見積もりが体系的に低く出ていないかです。1）見落とされがちな費目を挙げる（コミュニケーション、移行、手戻り、研修、コンプライアンス、保守、機会費用）；2）各費目に規模と根拠を示す。「あるかもしれない」で終わらせない；3）同種のプロジェクトで最もよく超過する費目と、その超過幅を示す；4）単発コストと継続コストを分け、継続分は年換算する；5）保守的な値と最悪値を出し、差がどの工程から来るかを示す。この計画にやる価値があるかは評価しないこと。

まず変動幅を見て、それから傾向を語る

私は [指標] が最近 [変化] したのを見て、[傾向] だと判断しています。答えてほしいのは 1 つだけ：これはノイズかシグナルかです。1）この指標の平常時の変動幅はどれくらいで、今回の変化は標準偏差いくつ分か；2）データは何期分あり、傾向を判断するのに足りるか；3）一時的な出来事、集計口径の変更、季節性が効いていないか；4）ノイズだとしたら、通常どれくらいで自然に戻るか；5）シグナルと確認するには、最低あと何の証拠がいつ必要か。最後に「今の時点で言えること」を 1 文で示してください。

「間違えたときに戻せるか」で並べ、順番を決める

私が決めようとしているのは：[決定]。まず不可逆な部分を切り出して順番を付けてください。要件：1）一度やったら戻せない動作を挙げ、戻すコストが具体的に何かを書く；2）それぞれが将来のどんな選択肢を閉じるか；3）それを実行する前に取れる最も安い情報は何か（試験運用、試し発注、見積、小範囲の段階公開）；4）順番を示す。今すぐ実行すべきもの、情報が増えるまで待てるもの、それぞれの期限；5）どれか 1 つを間違えると決定全体が成立しなくなるのはどれか。この決定をすべきかどうかは評価しないこと。

まず間違え方を書き、次に発覚後 24 時間の行動を書く

私の判断は：[判断] で、すでに [使った金額／時間／約束] を投じています。「自分が間違っていたら」の備えを書いてください。1）ありうる間違え方を 3 つ挙げ、「確率 × 損失」で並べる；2）それぞれ、最も早く観測できるシグナルと、それが現れるまでの期間；3）発覚後 24 時間、1 週間、1 か月にそれぞれ何をするか；4）今のうちに用意しておくもの（退路、予算、対外説明の言い方）；5）ある時点を過ぎると取り返せなくなる工程と、その日付。慰めも「たぶん大丈夫」も不要です。

自分の理由を分解し、好みを除いて何が残るか見る

私は [選択肢] を選びたいと考えており、理由は：[私の理由]。この理由を「事実」と「好み」の 2 列に分けてください。1）1 つずつ分類する。事実は第三者が独立に検証できるもの、好みは価値の順序付けや立場；2）どの「事実」が実は好みの包装かを指摘する（「自分のほうが詳しい」を「こちらのほうが安定している」と言い換えるなど）；3）好みをすべて除いても、事実はその選択を支えるか；4）私の好み同士は矛盾していないか（速さと安定を同時に求めるなど）；5）好みが変われば結論が反転する 1 条を示す。私の代わりに選ばないこと。