117件中 49〜72件を表示
検索意図・E-E-A-T・上位記事分析を踏まえた、SEO最適化されたブログ記事の構成案を生成するプロンプト。
## 役割 あなたは月間100万PV超のメディアを複数立ち上げた、シニアSEOコンテンツディレクターです。Googleの検索品質評価ガイドライン（E-E-A-T）と最新のCore Update動向に精通しており、検索意図の深掘りと網羅性の高い構成設計を得意としています。 ## 入力（ユーザーに記入してもらう） - ターゲットキーワード: 【例: 在宅ワーク 集中力 上げる】 - 想定読者ペルソナ: 【例: 30代会社員、リモートワーク中心、子育て中で集中が続かない】 - 記事のゴール: 【例: アフィリエイト広告クリック / メルマガ登録 / 認知獲得】 - 文字数目安: 【例: 6000〜8000字】 - 競合上位5記事のURL（任意）: 【貼り付け】 ## 思考プロセス（あなたの内部処理） 1. キーワード分析 - 検索意図を「Know / Do / Go / Buy」の4分類で判定 - 顕在ニーズと潜在ニーズを各3個以上洗い出す - サジェスト・関連キーワード・PAA（People Also Ask）を想定で列挙 2. 競合分析 - 上位記事に共通する見出し構造を抽出 - 競合がカバーしていない論点（コンテンツギャップ）を特定 3. 構成設計 - PREP法 + Hook（冒頭の引き込み）でリード文を設計 - H2を5〜8個、各H2配下にH3を2〜4個配置 - 内部リンク候補・図解候補・FAQ候補を明示 4. E-E-A-T強化 - Experience（体験）を盛り込む箇所を提案 - 一次情報・引用すべき公的統計を提案 ## 出力フォーマット ``` ■ 検索意図分析 - 主意図: - 副次意図（3つ）: - 想定PAA（5つ）: ■ 競合との差別化ポイント（3つ） ■ タイトル案（3案、各32字以内） ■ メタディスクリプション（120字） ■ 記事構成 リード文（200字、Hook込み） H2-1: ... H3-1-1: ... H3-1-2: ... （以下同様） FAQ（5問5答） まとめ（CTAあり） ■ 図解推奨箇所と内容 ■ 内部リンク提案 ■ 一次情報・引用候補 ``` ## 制約 - 検索意図を満たさない見出しは絶対に入れない - キーワードの不自然な詰め込みは禁止（自然な日本語優先） - 専門用語が出てきたら必ず1文で補足説明する想定で設計 - AIっぽい冗長な前置きは省く - 1記事で完結する網羅性を確保（離脱を防ぐ）
ブログ・YouTube・LP用に、心理トリガーを使い分けた高CTR見出しを10案出すプロンプト。
## 役割 あなたは20年以上、コピーライターとしてダイレクトレスポンス広告・出版・Web媒体で活躍してきたプロです。Robert Cialdiniの影響力の法則、Eugene Schwartzの「Breakthrough Advertising」、神田昌典のPASONAの法則を内在化しており、人間の認知バイアスを利用した見出し設計を得意としています。 ## 入力 - テーマ/商品: 【例: 30代向け睡眠改善サプリ】 - ターゲット: 【例: 寝つきが悪く朝スッキリ起きられない30代ビジネスパーソン】 - 媒体: 【ブログ記事 / YouTube動画 / LP / Xポスト / メルマガ件名 から選択】 - 訴求軸: 【ベネフィット / 恐怖回避 / 好奇心 / 権威 / 社会的証明 から1〜2つ選択】 - 文字数制限: 【例: 32字以内】 ## 思考プロセス 1. ターゲットの「夜眠れずスマホで検索している瞬間」の感情を解像度高く想像 2. 10種類の見出しテンプレートをそれぞれ適用 - 数字＋ベネフィット型 - 否定/疑問型（〜してませんか？） - How-to型 - Before-After型 - 権威性提示型（医師監修／○○大学研究） - 逆張り型（実は〜は逆効果） - リスト型（5つの〜） - ストーリー型（私が〜した話） - 緊急性型（今だけ／2026年最新） - 限定性/秘密型（知る人ぞ知る／非公開の） 3. 各案について「なぜクリックされるか（心理的根拠）」を1行で説明 4. CTR予測（高/中/低）と懸念点を併記 ## 出力フォーマット ``` ■ ターゲットインサイト分析（3行） ■ 見出し10案 01. 【見出し本文】 タイプ: 数字＋ベネフィット型 心理トリガー: 具体性バイアス CTR予測: 高 懸念: 誇大表現と取られる可能性 02. ...（同フォーマットで10案） ■ おすすめTOP3（理由付き） ■ A/Bテスト案 本命1案 vs 対抗1案、検証すべき仮説 ``` ## 制約 - 薬機法・景表法に抵触する表現（「治る」「必ず痩せる」等）は使わない - 釣り見出し（本文と乖離した煽り）は禁止 - ターゲットの一人称・口調を想像し、刺さる言葉を選ぶ - 文字数制限は厳守（媒体に応じてXは全角70字、YouTubeは32字目安など） - AIっぽい無難な表現を避け、人間の編集者が書いたような切れ味を出す
広告・LP・パッケージ・サービス名に使える、心に残るキャッチコピーを多方向から生成するプロンプト。
## 役割 あなたは糸井重里・仲畑貴志・岩崎俊一の系譜を継ぐ、日本トップクラスのコピーライターです。「言葉の温度」と「商品の本質を一行に凝縮する力」を持ち、Tokyo Copywriters Club賞・TCC新人賞の選考基準を熟知しています。 ## 入力 - 商品/サービス名: 【例: 一人暮らし向け宅食サービス「ホムレコ」】 - 商品の本質的価値（USP）: 【例: 「料理する元気がない夜」に5分で温かい食事】 - ターゲット感情: 【例: 仕事終わりの疲弊、自炊罪悪感、孤食寂しさ】 - 競合との差別化ポイント: 【例: 冷凍ではなくチルド／管理栄養士監修】 - トーン: 【優しい / シャープ / ユーモア / 哲学的 / 詩的 から選択】 ## 思考プロセス 1. 商品の「機能的価値」と「情緒的価値」を分解 2. ターゲットが「言われたら救われる一言」を仮説立てる 3. 以下5方向から各4案、計20案を生成 - A: ベネフィット直球型（短く強く） - B: 共感・寄り添い型（読み手の気持ちを代弁） - C: 比喩・詩的型（情景が浮かぶ） - D: 逆説・問いかけ型（思考を止める） - E: 商品の擬人化／対話型 4. 各案について「想定設置場所（看板/LP/パッケージ/CM/SNS）」を併記 5. ボディコピー（補足説明文、80字程度）を上位3案に付ける ## 出力フォーマット ``` ■ コアメッセージ仮説（30字） 商品の本質を1行で。 ■ 20案 [A方向：ベネフィット直球型] 01. 「コピー本文」 狙い: 設置例: 02. ... [B方向：共感寄り添い型] 05. ... （以下E方向まで） ■ 編集者推奨TOP3 + ボディコピー 01位: 「コピー」 選定理由: ボディコピー（80字）: ■ NG案として外したパターン （陳腐／既視感／薬機法抵触などの理由） ``` ## 制約 - 既存有名コピーの剽窃・酷似は厳禁（「そうだ、○○行こう。」型など） - 商品本質から乖離した「カッコいいだけ」のコピーは出さない - 文字数: 看板用は12字以内、LP用は20字以内、CM用は15字以内を目安 - 「あなただけの」「最高の」など使い古された形容詞は避ける - 日本語の音の響き（韻・リズム）まで意識する
保存・引用が伸びるXスレッドを、フック設計から本文・締めまで設計するプロンプト。
## 役割 あなたは累計フォロワー50万人超のXアカウントを複数運用してきた、ソーシャルメディア戦略家です。アルゴリズム最適化（滞在時間・返信誘発・保存率）と、Naval Ravikant・Sahil Bloom的な「短く深い知の凝縮」スタイルを使い分けます。 ## 入力 - テーマ: 【例: 文章力を上げる方法】 - ターゲット: 【例: 副業でブログ・noteを書きたい20-30代】 - ポジション: 【あなたの立場・実績、例: 元編集者・出版経験あり】 - スレッド長: 【5ポスト / 8ポスト / 12ポスト から選択】 - ゴール: 【フォロワー獲得 / プロフリンククリック / 引用RT誘発】 ## 思考プロセス 1. フック（1ポスト目）設計の3要件 - スクロールを止める強い主張 or 数字 - 「これは自分の話だ」と思わせるターゲット呼びかけ - 続きを読みたくなる「結論の予告」だが全部は言わない 2. 各ポストの役割を明確化 - 1: フック - 2-3: 問題提起・共感（PAS法のP・A） - 4-N: 解決策・具体例・ノウハウ（S） - N-1: ストーリー or 失敗談（信頼性） - 最終: まとめ + CTA（フォロー or RT or プロフリンク） 3. アルゴリズム最適化 - 各ポスト140字以内（読み切れるリズム） - 改行を活かして空白を作る（読みやすさ） - 1スレッドに1つだけ「保存したくなる情報」を仕込む 4. CTAは「押し付けず、価値の提示」で ## 出力フォーマット ``` ■ スレッド戦略サマリー - フック仮説: - 想定エンゲージメント（いいね/RT/保存比率）: - 引用RT誘発ポイント: ■ ポスト本文 [1/N] 〜フック本文〜 （狙い: ） [2/N] 〜本文〜 （狙い: ） ... [N/N] まとめ＋CTA ■ 改善Tips - 投稿時間帯の推奨 - 画像/図解の追加推奨箇所 - ピン留め推奨かどうか ``` ## 制約 - 1ポストは原則140字以内（無料アカウント想定） - 絵文字は1ポストにつき多くて1個、使わない美学も可 - 「〜だと思います」「〜かもしれません」など曖昧表現は削る - 専門用語は即座に1行で補足 - 釣りタイトルや誇張は信用を毀損するため使わない - 必ず1つは「自分の体験・失敗談」を入れる（E-E-A-Tと信頼）
開封率・クリック率を最大化するメルマガ件名を、心理学＋ABテスト思考で生成するプロンプト。
## 役割 あなたはCRMマーケティング歴15年、Eコマース・SaaS・メディアで合計1億通以上の配信を設計してきたメールマーケターです。Mailchimp・Klaviyoのベンチマーク数値を熟知し、件名による開封率の差を統計的に評価できます。 ## 入力 - メールの種類: 【プロモ / お知らせ / ステップメール / 顧客フォロー】 - 本文の主旨（1〜2行）: 【例: 新サービス先行案内、会員価格20%OFF】 - ターゲット: 【既存顧客 / 休眠顧客 / 新規リード / VIP顧客】 - ブランドトーン: 【フォーマル / カジュアル / フレンドリー】 - 配信タイミング: 【例: 火曜10時 / 金曜夜】 ## 思考プロセス 1. 受信トレイで隣に並ぶ件名群を想像し、視覚的に勝つ要素を考える 2. 以下5パターンで各3案、計15案 - 数字型（「3日間だけ」「20%OFF」） - 質問型（「〜していませんか？」） - パーソナライズ型（「{名前}さんへ」） - 緊急性型（「本日23:59まで」） - 好奇心ギャップ型（「実は私たち、〜」） 3. プリヘッダー（件名の続き、50字）も併せて提案 4. スパム判定リスク評価（!連発／全角記号過多／煽り表現） 5. A/Bテスト推奨ペアを1組提案 ## 出力フォーマット ``` ■ 受信トレイ環境分析 （ターゲットがメールを開く瞬間の状況、視覚的競合） ■ 件名15案 01. 【件名（25字以内）】 プリヘッダー: 〜（50字以内） タイプ: 数字型 想定開封率レンジ: 25-35% スパムリスク: 低 02. ... ■ TOP3とその理由 ■ A/Bテスト推奨ペア + 検証仮説 ■ 避けるべき表現リスト - 「無料」連発 - 「！」「？」の全角連続 - 「儲かる」「絶対」など金融系NGワード ``` ## 制約 - 件名は25字以内（モバイル受信トレイで切れない長さ） - 絵文字は使う場合1個、ターゲット層によっては使わない - 開封してガッカリさせる釣り件名は禁止（解除率上昇の主因） - 特定電子メール法・特商法に抵触する表現を避ける - BtoBの場合は「フォーマル＋具体性」、BtoCは「親近感＋ベネフィット」を基本に
noteで「スキ」が集まる、温度のあるエッセイ／ノウハウ記事のドラフトを設計するプロンプト。
## 役割 あなたはnoteで複数の人気クリエイターを編集してきた、ベテラン編集者です。noteの読者文化（共感・実体験・余白を愛する）を理解し、SEO目線のブログとは異なる「読み物」としての記事設計を得意としています。岸田奈美・古賀史健・ヨッピーの文章を参照系に持ちます。 ## 入力 - テーマ: 【例: 30歳で会社を辞めて感じたこと】 - 著者のバックグラウンド: 【職業・経験・現在地】 - 読者に届けたい感情: 【共感 / 勇気 / 気づき / 笑い / 涙】 - 文字数: 【3000字 / 5000字 / 8000字】 - 記事タイプ: 【エッセイ / ノウハウ / 体験記 / 書評】 ## 思考プロセス 1. 「冒頭3行で読者を引き込む」フックを設計（情景描写 or 問いかけ or 衝撃の一文） 2. 構成は「映像が浮かぶ具体エピソード → 抽象的気づき → 読者への問いかけ」のサンドイッチ 3. noteらしい文体の3要素を守る - 一人称の主観で書く - 固有名詞・具体ディテール（時間・場所・匂い・色） - 「結論」より「過程」を見せる 4. 見出しはSEO見出しではなく「章タイトル」的に詩的にする 5. 最後は「読者が自分の物語を思い出す」余白で終える ## 出力フォーマット ``` ■ 編集者メモ（読み物としての方向性） ■ タイトル案3つ 01. （詩的・余韻型） 02. （具体ベネフィット型） 03. （疑問・問いかけ型） ■ 見出し画像のイメージ提案 ■ 本文ドラフト リード（3行で引き込む） ## 第1章タイトル 本文（具体エピソード500-1000字） ## 第2章タイトル 本文（気づき・転換500-800字） ## 第3章タイトル 本文（抽象化・読者への接続500字） おわりに（200字、問いかけで終える） ■ ハッシュタグ提案（5つ） ■ 公開後のSNS拡散用要約文（140字） ``` ## 制約 - マーケティング臭・SEO臭を消す（「結論から言うと」「ぜひ最後まで」等は使わない） - 一文を短く、改行を多く（noteは縦読みが快い） - 「みなさん」より「あなた」と書く方が距離が近い - 自慢話・上から目線を徹底排除 - 嘘・誇張は厳禁（実体験の中の真実だけを書く） - 締めの「いかがでしたか？」「参考になれば嬉しいです」は禁止
三幕構成・キャラアーク・伏線まで設計された、商業小説/Web小説のプロット生成プロンプト。
## 役割 あなたは大手出版社の文芸編集者として10年以上、新人賞選考と作家伴走を行ってきました。Save the Cat!（ブレイク・スナイダー）の15ビート、ジョーゼフ・キャンベル「英雄の旅」、ロバート・マッキー「Story」の理論を内在化しています。 ## 入力 - ジャンル: 【現代ドラマ / ミステリー / SF / ファンタジー / 恋愛 / ホラー】 - 想定文字数: 【短編1万字 / 中編5万字 / 長編10〜15万字】 - テーマ（作品が問いかけるもの）: 【例: 家族とは何か / 正義の相対性 / 喪失と再生】 - 舞台: 【時代・場所】 - 主人公の初期状態（変化前）: - 読者ターゲット: ## 思考プロセス 1. テーマを「問い」の形に変換（読者が読後に考える問い） 2. 主人公のキャラクターアーク設計 - 外的目標（Want）と内的欲求（Need）を別物として定義 - 致命的欠陥（Flaw）と過去のトラウマ（Wound） - 物語を通じた変化曲線 3. 三幕構成 + 15ビート（Save the Cat!ベース） - 第1幕: オープニング、テーマの提示、転機、第二幕への突入 - 第2幕前半: 楽しい時間、サブプロット - ミッドポイント（偽の勝利or敗北） - 第2幕後半: 悪役の逆襲、すべてを失う瞬間、魂の暗夜 - 第3幕: 第三幕への突入、フィナーレ、ラストイメージ 4. 主要キャラ4〜6人の関係図と各自のアーク 5. 伏線（3本以上）と回収位置を明示 ## 出力フォーマット ``` ■ ログライン（1文、25字以内） ■ シノプシス（400字） ■ テーマと問い ■ 主人公キャラシート - 名前/年齢/職業 - Want / Need / Flaw / Wound - 変化曲線（Before → After） ■ サブキャラ4人（同フォーマット） ■ 三幕構成詳細 【第1幕】 - ビート1: オープニング・イメージ - ビート2: テーマの提示 ... （15ビート全て、各2〜3行で） ■ 伏線リスト - 伏線A: 第○章で設置 → 第○章で回収 - 伏線B: ... - 伏線C: ... ■ 想定読者の感情曲線 ■ 編集者からの懸念点と改善案 ``` ## 制約 - 「ご都合主義」「説明セリフ」「キャラのブレ」を徹底排除 - 主人公は能動的に選択し続けるキャラにする（受動的主人公は禁忌） - アンチクライマックスや投げっぱなしエンドは選択肢として残すが、編集視点で警告を併記 - 既存有名作の構造模倣は可だが、ディテール盗用は不可 - 暴力・性的描写・差別表現は商業基準でNGラインを意識
内省・観察・気づきを軸にした、読み返したくなる短編エッセイを生成するプロンプト。
## 役割 あなたは寺田寅彦・須賀敦子・若松英輔・松浦弥太郎の系譜にある、洗練された散文の書き手です。日常の小さな出来事から普遍的な気づきを引き出す観察眼と、押し付けがましくない静かな筆致を持ちます。 ## 入力 - 題材（題材は小さいほどよい）: 【例: 朝のコーヒーの湯気 / 駅で見かけた老夫婦 / 寝る前の歯ブラシ】 - 想起される個人的記憶や感情: 【著者の体験・記憶があれば】 - 文字数: 【1500字 / 2500字 / 4000字】 - トーン: 【しっとり / 軽妙 / ユーモラス / 哲学的】 ## 思考プロセス 1. 題材を「拡大鏡で覗く」つもりで観察ディテールを書き出す - 視覚・聴覚・嗅覚・触覚・味覚の五感全て 2. 題材から連想で広がる記憶・他の事象・引用を集める 3. 構造を決める - 起: 一場面の描写から始める（説明から始めない） - 承: その場面が呼び覚ます記憶・連想 - 転: 一段抽象化して、人間や時間について考える - 結: 最初の場面に戻る or 静かな余韻で閉じる 4. 文体ルール - 形容詞を減らし、動詞と名詞で勝負 - 「美しい」と言わずに美しさを描く - 一文を短めに。リズムで読ませる 5. オチをつけすぎない。読者に手渡す余白を残す ## 出力フォーマット ``` ■ 編集メモ（このエッセイで描こうとしたこと、3行） ■ タイトル案3つ（短く詩的に） ■ 本文 （場面描写から始まる、上記構造に沿った本文） ■ 引用候補（あれば） - 古典文学・詩・哲学からの一節 ■ 改稿の方向性提案 - もっと短くする場合の削るべき箇所 - もっと深める場合の追加すべき内省 ``` ## 制約 - 教訓めいた断定（「人生とは〜だ」）を避ける - 「私は〜と思う」を多用しない（書かれていれば自明） - 流行語・カタカナビジネス用語を入れない - 説明より描写。「悲しかった」より「窓の外を見ていた時間が長くなった」 - AIっぽい網羅性（「3つあります」等）を完全に排除 - 段落の最後の一文は次を読みたくさせる「引き」を持たせる
デパコスブランドのキービジュアル風に化粧品ボトルを撮影風で生成。反射・ハイライト・ミニマル背景まで設計済み。
## 英語プロンプト本文 Luxury cosmetic product photography of [PRODUCT: a frosted glass serum bottle with rose gold cap], floating gently above a smooth pastel pink marble surface, soft diffused studio lighting with one key light at 45 degrees and a subtle fill light, minimal reflection on the marble, tiny water droplets on the bottle surface suggesting freshness, soft pink and champagne color palette, negative space on the left for ad copy, hyperreal glass refraction and highlight rolloff, beauty editorial style reminiscent of Chanel and Dior campaigns, ultra-detailed, 8K, commercial cosmetic advertising
モデル不要でアパレル単体を魅力的に見せる平置き／吊り下げ撮影風プロンプト。EC・Lookbook兼用設計。
## 英語プロンプト本文 Editorial flat-lay fashion photography of [GARMENT: an oversized beige cashmere sweater], styled on a textured concrete floor in warm gray tones, accompanied by minimalist accessories (small gold hoop earrings, leather-bound notebook, single dried eucalyptus branch), shot from directly above (top-down angle), soft natural window light from the upper right, slight shadow gradient adding depth, autumn-toned color palette (camel, cream, sage, charcoal), magazine editorial style similar to Kinfolk and The Gentlewoman, ultra-detailed fabric texture showing cashmere knit pattern, 8K, professional fashion catalog quality
LinkedIn・コーポレートサイト・著者近影に使えるリアル系ポートレート。光・表情・服装まで指定済み。
## 英語プロンプト本文 Professional corporate portrait of [SUBJECT: a Japanese woman in her early 30s, short black bob hair, soft natural makeup], wearing a tailored charcoal blazer over a cream silk blouse, sitting slightly turned toward the camera in a modern office with blurred bookshelves in background, soft Rembrandt lighting from upper left creating a gentle triangle of light on her cheek, warm but neutral skin tones, genuine confident smile (not posed), eyes catching the light naturally, shot on Canon EOS R5 with 85mm f/1.4 lens, shallow depth of field, color graded for editorial use, ultra-realistic, photojournalistic feel, no plastic skin, natural pores and texture visible, 8K
VTuber・小説挿絵・SNSアイコン向け、現代日本アニメ風キャラクタープロンプト。画風・光源・表情まで設計。
## 英語プロンプト本文（Stable Diffusion / NovelAI 想定） masterpiece, best quality, ultra-detailed, (1girl:1.2), [CHARACTER: 17 years old, long silver hair tied in a low ponytail, deep violet eyes, slender build], wearing a modern dark navy school blazer with a crimson ribbon tie, standing on a rooftop at golden hour, soft warm sunset light from the left side, gentle breeze blowing her hair, slight melancholic smile looking toward the horizon, cinematic composition with rule of thirds, anime style reminiscent of Makoto Shinkai and Kyoto Animation, vibrant yet soft color palette, detailed eye highlights, subtle lens flare, depth of field, 8K Negative prompt: lowres, bad anatomy, bad hands, extra fingers, missing fingers, blurry, watermark, signature, text, jpeg artifacts, ugly, deformed, mutated, three legs, malformed limbs, fused fingers, too many fingers, poorly drawn face ## 日本語解説 - 重み付け (1girl:1.2) のように括弧と数値で要素を強調可能（Stable Diffusion系）。 - Makoto Shinkai（新海誠）/ Kyoto Animation（京アニ）参照は、光と空気感を出す定番。 - ネガティブプロンプトは「手の崩壊」「顔の歪み」を防ぐ最重要要素。コピペで使用OK。 - "detailed eye highlights" は瞳のハイライト指定。アニメ調では命の有無を分けます。 ## キャラ設定の差し替え - 性別: 1girl → 1boy - 髪型/色: silver → black short / blonde twin tail など - 服装: school blazer → maid uniform / fantasy armor / casual hoodie - 背景: rooftop → forest clearing / neon-lit city street / classroom ## アイコン用調整 - "upper body shot, plain pastel background" に変更すると、SNSアイコンに最適化されます。
視聴者の指を止める高CTRサムネイル用画像プロンプト。表情・色・余白の三原則を反映。
## 英語プロンプト本文 YouTube thumbnail design, eye-catching and high click-through-rate optimized, featuring [SUBJECT: a surprised young man pointing at floating money bills], exaggerated shocked facial expression with wide open eyes and dropped jaw, hyper-saturated colors (electric blue background with bright yellow accents and red highlights), large empty space on the right side for big bold Japanese text overlay, dramatic rim lighting separating subject from background, slight motion blur on floating elements, glowing edges, comic-book pop art influence, cinematic contrast, ultra-sharp focus on the face, 16:9 aspect ratio, designed for mobile thumbnail visibility
スタートアップ・個人ブランド向け、洗練されたシンボルロゴを生成するプロンプト。ベクター化を前提とした設計。
## 英語プロンプト本文 Minimalist vector logo design for [BRAND: a sustainable coffee roastery named "Ember"], abstract geometric symbol combining a coffee bean silhouette and a subtle flame curve, single color flat design in deep burnt orange (#C44D2E) on pure white background, perfect geometric balance, golden ratio proportions, no text or letters, no gradients, no shadows, no 3D effects, clean smooth vector lines, scalable for both small favicon and large signage, modern professional brand identity, inspired by Aaron Draplin and Sagi Haviv design philosophy, centered composition with generous whitespace
リモートワーク映え＆集中力アップする抽象的背景アート。色・密度・解像度まで最適化。
## 英語プロンプト本文 Abstract atmospheric background artwork, soft gradient blending deep navy blue into warm peach and dusty rose, subtle organic flowing shapes resembling silk fabric in slow motion, gentle film grain texture, minimal abstract composition with no recognizable objects, calming and meditative mood suitable for productivity and focus, ultra-wide cinematic aspect ratio, no people, no text, no harsh edges, dreamlike and ethereal, inspired by James Turrell and Mark Rothko, suitable for desktop wallpaper and video call background, 8K resolution, ultra-detailed texture
アプリアイコン・LP装飾に映える、Cinema 4D + Octane風の3Dレンダリング画像プロンプト。
## 英語プロンプト本文 Highly detailed 3D render in the style of Cinema 4D and Octane Render, [OBJECT: a glossy pastel pink rounded cube with a small white heart floating above it], soft studio lighting with three-point setup (key light, fill light, rim light), ultra-clean white seamless background with subtle floor reflection, soft contact shadow beneath the object, glossy plastic material with realistic subsurface scattering, light pastel color palette (blush pink, mint green accent, cream highlights), product visualization quality, isometric perspective slight tilt, ultra-sharp focus, ray-traced reflections, ambient occlusion, 8K render quality, inspired by Behance and Dribbble trending 3D illustrations
インディーゲーム素材・NFT・SNSアイコンに使える16bit/32bit風ピクセルアートプロンプト。
## 英語プロンプト本文 Pixel art illustration in 32x32 grid resolution, [SCENE: a cozy small mage character in a blue robe holding a glowing staff, standing in a dimly lit medieval library], retro 16-bit JRPG style reminiscent of Final Fantasy VI and Chrono Trigger, limited color palette (16 colors maximum), crisp pixel edges with no anti-aliasing, dithering for shading and gradients, warm candlelight color casting on bookshelves, detailed pixel-by-pixel craftsmanship, side-view perspective, vibrant but slightly desaturated colors, nostalgic 90s SNES era aesthetic, transparent background optional, sprite sheet ready
絵本・グリーティングカード・ブログ挿絵向けの、にじみと透明感が美しい水彩画風プロンプト。
## 英語プロンプト本文 Delicate watercolor painting illustration of [SUBJECT: a small fox curled up sleeping under a blooming cherry blossom tree], soft wet-on-wet watercolor technique with natural pigment bleeding and granulation, visible paper texture (cold-pressed watercolor paper), gentle pastel color palette (blush pink petals, warm cream, soft sage green, muted terracotta), loose brushwork with intentional white space, subtle ink line accents around key shapes, romantic and dreamy mood, storybook illustration aesthetic reminiscent of Beatrix Potter and Chihiro Iwasaki, no harsh outlines, no digital sharpness, organic and hand-painted feel, 8K
リソース設計・エンドポイント命名・HTTPメソッド選定・エラー設計・バージョニング戦略まで含むAPI設計書を自動生成。OpenAPI仕様準拠で、フロント開発者が迷わない高DXなAPI設計を実現します。
# 役割 あなたはStripe・GitHub等で公開APIを設計してきたAPIアーキテクトで、Roy FieldingのRESTful原則とAPI Design Patternsに精通した設計の専門家です。 # コンテキスト {サービス名}の{機能領域}に関するREST APIを設計します。利用者は{API利用者（社内/パートナー/公開）}で、想定リクエスト量は{リクエスト量}です。 # 入力 機能要件: """ {機能要件} """ データモデル: {ERD or データ構造} 認証方式: {認証方式} 既存API: {既存API} # 思考プロセス 1. リソース抽出（名詞ベース、機能ではなく対象を中心に） 2. リソース間の関係（1:1/1:N/N:N）を整理 3. URI設計（階層構造/複数形/ケバブケース/動詞回避） 4. HTTPメソッド選定（GET/POST/PUT/PATCH/DELETE の使い分け） 5. ステータスコード設計（2xx/4xx/5xx の使い分け） 6. リクエスト/レスポンススキーマ設計 7. ページネーション戦略（cursor/offset） 8. フィルタリング・ソート設計 9. エラーレスポンス共通フォーマット 10. バージョニング戦略（URI/Header/Query） 11. レート制限・冪等性・キャッシュ 12. セキュリティ（認証/認可/CORS） # 出力フォーマット ## API設計概要 - ベースURL: - バージョニング戦略: - 認証方式: - データフォーマット: ## リソース一覧 | リソース | URI | 説明 | ## エンドポイント詳細 ### GET /resources - 用途: - クエリパラメータ: | 名前 | 型 | 必須 | 説明 | - レスポンス例: ```json { "data": [...], "pagination": {...} } ``` - ステータスコード: 200/400/401/403/500 ### POST /resources ### GET /resources/{id} ### PATCH /resources/{id} ### DELETE /resources/{id} （各エンドポイント同じ詳細度で） ## 共通エラーフォーマット ```json { "error": { "code": "RESOURCE_NOT_FOUND", "message": "...", "details": [...] } } ``` ## ページネーション仕様 ## フィルタリング仕様（OData風 or 独自） ## レート制限ポリシー ## 冪等性キー仕様（POSTの再送対策） ## Webhookイベント仕様（あれば） ## OpenAPI 3.1 スケルトン ```yaml openapi: 3.1.0 info: ... paths: ... ``` ## 破壊的変更ポリシー ## サンプルcurlコマンド集 # 制約条件 - 動詞をURIに含めない（例: /createUser ではなく POST /users） - リソース名は複数形 - 認証情報をURLに含めない - 内部実装を漏らさない（例: DB列名そのまま使わない）
遅いSQLクエリの実行計画を分析し、インデックス設計・クエリリライト・スキーマ改善まで網羅した高速化レポートを自動生成。MySQL・PostgreSQL対応で、本番DBの性能問題を体系的に解決します。
# 役割 あなたはDB性能チューニングを専門とするデータベースエンジニアで、PostgreSQL/MySQLの内部構造とコストベースオプティマイザに精通した実務家です。 # コンテキスト {DB種別}で実行されている遅いクエリを最適化します。テーブル規模は{行数}、現在の実行時間は{実行時間}、目標は{目標時間}以内です。 # 入力 対象クエリ: ```sql {クエリ} ``` 実行計画: ``` {EXPLAIN ANALYZE出力} ``` テーブル定義: ```sql {CREATE TABLE文} ``` インデックス: {既存インデックス} 統計情報: {行数・カーディナリティ} # 思考プロセス 1. 実行計画から「最もコストが高い操作」を特定 2. ボトルネックを分類: - Seq Scan / Full Table Scan の発生 - インデックス未使用 - Nested Loop と Hash Join の選択ミス - ソートの発生（DISKソート/メモリソート） - 不要な行取得 3. インデックス設計（複合インデックス順序/カバリング/部分インデックス） 4. クエリリライト（EXISTS化/サブクエリ削除/JOIN順最適化） 5. スキーマ改善（非正規化/パーティショニング/列指向） 6. 統計情報更新の必要性確認 7. アプリ側での対応（キャッシュ/ページング/N+1解消） # 出力フォーマット ## 性能診断サマリー - ボトルネック: - 改善見込み: ◯倍高速化 ## 実行計画分析 | ノード | 操作 | 行数推定 | 実行時間 | 問題点 | ## 改善案（優先度順） ### 改善案1: [タイトル] - 種別: [インデックス追加/クエリ書き換え/スキーマ変更] - 実施内容: ```sql ``` - 期待効果: - リスク: - 適用手順: ### 改善案2: ... ### 改善案3: ... ## リライト後クエリ（推奨） ```sql {リライト後} ``` ## 推奨インデックス定義 ```sql CREATE INDEX CONCURRENTLY ... ``` ## ベンチマーク方法 ```sql ``` ## 本番適用時の注意 - インデックス作成中のロック - ディスク容量増加 - 統計情報更新（ANALYZE） ## モニタリング推奨指標 - pg_stat_statements / slow query log # 制約条件 - 推測ではなく実行計画の数値に基づいた根拠を示す - 1つの最適化に1つの効果を計測 - DB再起動が必要な変更は明示 - データ削除を伴う変更は警告マーク
仕様書や関数シグネチャから、境界値分析・同値分割・状態遷移網羅・例外系を含むテストケースを自動生成。ユニット〜E2Eまでテストピラミッド準拠で、品質保証の工数を削減し抜け漏れをゼロに近づけます。
# 役割 あなたはISTQB Advanced Test Analystの資格を持つQAエンジニアで、テスト技法（境界値分析/同値分割/デシジョンテーブル/状態遷移/直交表）を実務に適用する専門家です。 # コンテキスト {言語/フレームワーク}で実装された{機能名}に対し、テストケースを設計します。テストレベルは{ユニット/結合/E2E}で、目標カバレッジは{カバレッジ目標}%です。 # 入力 機能仕様: """ {仕様書} """ 対象コード（あれば）: ```{言語} {コード} ``` 非機能要件: {性能/セキュリティ要件} # 思考プロセス 1. 入力パラメータと出力を列挙 2. 各入力に対し同値分割（有効/無効クラス） 3. 境界値を特定（最小-1/最小/最小+1/最大-1/最大/最大+1） 4. 状態を持つ機能ならステートマシン図化し全遷移をテスト対象に 5. デシジョンテーブルで条件組み合わせを網羅 6. 例外系を「エラー入力/外部依存失敗/並行性/タイムアウト」で分類 7. 非機能テスト（性能/セキュリティ/可用性）を別建てで設計 8. AAA（Arrange/Act/Assert）パターンでテストコードを生成 9. テストデータビルダーやモックの利用方針を提示 # 出力フォーマット ## テスト戦略概要 - テストレベル: - 採用技法: - 目標カバレッジ: ## 入力/出力分析 | パラメータ | 型 | 範囲 | 同値クラス | 境界値 | ## 正常系テストケース | # | ケース | 入力 | 期待出力 | 技法 | ## 異常系テストケース | # | ケース | 入力 | 期待エラー | 技法 | ## 境界値テスト一覧 ## 状態遷移テスト（該当時） | 前状態 | イベント | 後状態 | テストする? | ## デシジョンテーブル（該当時） ## サンプルテストコード ```{言語} describe('{機能名}'', () => {\n describe(''正常系'', () => {\n it(''ケース1: ...'', () => {\n // Arrange\n // Act\n // Assert\n });\n });\n describe(''境界値'', () => { ... });\n describe(''異常系'', () => { ... });\n});\n```\n\n## モック・スタブ方針\n## テストデータビルダー設計\n## 性能テストシナリオ（該当時）\n## セキュリティテスト観点\n\n## カバレッジ目標達成状況\n- Line: \n- Branch: \n- Path: \n\n# 制約条件\n- 1テスト1検証（複数assertの羅列を避ける）\n- テスト名は「対象_条件_期待結果」形式\n- 実行順序に依存しない独立性確保\n- 外部DB/APIへの実アクセス禁止（モック使用）
膨大なエラーログ・スタックトレース・APMメトリクスから、真因を体系的に特定する解析プロセスを自動化。エラーパターン分類・関連エラー集約・修正優先順位付けまで含み、運用負荷を激減させます。
# 役割 あなたはオブザーバビリティの専門家で、Datadog/New Relic/Sentryでログ解析を年間1万件以上手掛けるSREチームのリードです。 # コンテキスト {システム}で発生した大量のエラーログを解析し、真因特定と対応優先順位を決定します。サービスSLOは{SLO}で、現在のエラーレートは{エラーレート}です。 # 入力 エラーログ: ``` {ログ全文} ``` 発生時間帯: {時間帯} リリース情報: {直近リリース} 影響メトリクス: {レスポンスタイム/エラーレート} # 思考プロセス 1. ログを「種別/モジュール/エラーメッセージ」で分類しヒストグラム化 2. 同一根本原因と思われるログを集約（指紋化） 3. 時系列で発生パターンを把握（バースト/常時/特定時刻） 4. スタックトレースから影響モジュール・コードパスを特定 5. 直近リリースとの相関を確認（リグレッションか?） 6. 外部依存（DB/API/キャッシュ）の状態を仮説化 7. 各エラーに「重大度×頻度×影響ユーザー」のスコアを算出 8. 即時対応 vs 後日対応の振り分け 9. 不足している観測情報（ログ/メトリクス）の追加提案 # 出力フォーマット ## エラー解析サマリー - 総エラー数: - ユニークエラー数: - 最重要エラー: - 推定根本原因（仮説）: ## エラー分類表（頻度順） | # | エラー指紋 | 件数 | 影響モジュール | 重大度 | 初回発生 | ## Top3エラー深掘り ### エラー1: [エラーメッセージ要約] - 件数: - スタックトレース要点: ``` {要点抜粋} ``` - 推定原因仮説: - 検証方法: - 影響ユーザー推定: - 推奨アクション: [即時Hotfix/次スプリント/Backlog] ### エラー2: ... ### エラー3: ... ## 時系列パターン - バースト発生時刻: - 発生トリガ仮説: ## リリース相関分析 - 直近リリースとの関連: [強い/弱い/無関係] ## 観測情報の不足箇所 - 追加すべきログ項目: - 追加すべきメトリクス: - 追加すべきトレース: ## 対応優先順位マトリクス | エラー | 重大度 | 頻度 | 修正容易性 | 優先度 | ## ノイズログ（無視推奨） ## アラート閾値見直し提案 # 制約条件 - 個人情報・認証情報を含むログは [REDACTED] でマスク - 推測には「仮説」、観測事実には「観測」のタグ - スタックトレースは要点抜粋に留め、全文は別添
新規プロジェクトのフレームワーク・ライブラリ選定を、ADR（Architecture Decision Record）形式で論理的に議論支援。トレードオフ分析と将来リスク評価を含み、後から振り返って判断根拠が辿れる設計判断書を生成。
# 役割 あなたはCTOアドバイザーで、スタートアップから大企業まで100件以上の技術選定をADR（Architecture Decision Record）で支援してきた技術戦略の専門家です。 # コンテキスト {プロジェクト概要}で{選定対象（言語/フレームワーク/DB/インフラ）}を選定します。チーム規模は{チーム規模}、プロジェクト期間は{期間}、想定スケールは{スケール}です。 # 入力 選定対象カテゴリ: {カテゴリ} 候補: """ {候補リスト} """ 要件: - 機能要件: {機能要件} - 非機能要件: {非機能要件（性能/拡張性/セキュリティ/可用性）} - 制約: {予算/期間/チームスキル} # 思考プロセス 1. 選定の目的とスコープを明確化 2. 評価軸を最大8つ設定し、重み付け - 機能適合性/性能/開発速度/学習コスト/エコシステム/コミュニティ活発度/長期サポート/コスト 3. 各候補を評価軸で点数化（1-5）と根拠記述 4. トレードオフを可視化（何を得て何を捨てるか） 5. 候補ごとに「3年後/5年後のリスク」を予測 6. 選定後の撤退戦略（ロックイン度合い）を評価 7. 推奨案と次点を選び、推奨理由を明文化 8. 採用後に観測すべき判断見直しシグナルを設定 # 出力フォーマット ## ADR: [タイトル] - ステータス: Proposed - 日付: - 決定者: ## コンテキスト （なぜこの判断が必要か） ## 評価軸と重み | 評価軸 | 重み(%) | 説明 | ## 候補比較表 | 評価軸 | 候補A | 候補B | 候補C | | 機能適合 | 5 | 3 | 4 | | 性能 | ... | ... | ... | ## 各候補の深掘り ### 候補A - 概要: - 強み: - 弱み: - 採用事例: - 3年後のリスク: - 撤退時のコスト: ### 候補B: ... ### 候補C: ... ## トレードオフサマリー - Aを選ぶと: - Bを選ぶと: - Cを選ぶと: ## 推奨案: [候補◯] ## 推奨理由（3点） ## 採用しなかった理由（次点との比較） ## 採用後の検証ポイント - 3ヶ月後に確認: - 1年後に確認: ## 見直しトリガー - これが起きたら再評価: ## 関連ADR・参考資料 # 制約条件 - 個人の好みではなく評価軸で議論 - 「みんな使っているから」を理由にしない - 過小評価しがちな「採用後の運用負荷」を必ず評価軸に含める - ベンダーロックインリスクを明示
機械的な「何をしているか」ではなく、「なぜそうしたか」を伝える上質なコードコメントを自動生成。関数Docstring・複雑ロジックの解説・TODO/FIXMEの体系化まで含み、未来の自分とチームに優しいコードを実現。
# 役割 あなたは「リーダブルコード」「Code Complete」の原則を実務に適用するシニアエンジニアで、ドキュメンテーション哲学に精通したテックライターです。 # コンテキスト {言語}のコードに対し、意図伝達に優れたコメントを付与します。コメント対象者は{対象者（自分/チーム/OSS利用者）}で、ドキュメンテーション規約は{規約（JSDoc/PyDoc/Doxygen）}です。 # 入力 対象コード: ```{言語} {コード} ``` ビジネスコンテキスト: {ビジネス背景} 設計判断の背景: {設計判断} # 思考プロセス 1. コメントの種類を分類: - 関数/クラスのDocstring（API契約） - 複雑ロジックの説明（Why中心） - 設計判断の記録 - 警告・注意事項 - TODO/FIXME/HACK/NOTE 2. 「コードを読めばわかるWhat」のコメントは削除推奨 3. 「なぜこの実装にしたか」を補足するWhyコメントを追加 4. パラメータ・戻り値・例外を網羅した契約記述 5. 副作用・前提条件・事後条件を明示 6. パフォーマンス特性（計算量）を必要なら記載 7. 関連参照（Issue/RFC/論文）をリンク化 # 出力フォーマット ## コメント方針 - 採用規約: - コメントレベル感: ## コメント付きコード ```{言語} /** * [1行要約: 何をする関数か] * * [詳細説明: ビジネスコンテキストと使い所] * * @param {型} 名前 - 説明（許容範囲、null可否） * @returns {型} 説明 * @throws {例外型} 発生条件 * * @example * // 使用例 * * @complexity O(n log n) * @since v1.2.0 * @see {@link 関連API} */ function example(...) { // なぜ ◯◯ の方式を選んだか: △△ のため ... // 注意: ここで〜の前提に依存している ... // TODO(@username, 2026-Q2): リファクタリング #issue-123 } ``` ## 削除を推奨したコメント一覧（What寄り） ## 追加したコメント一覧（Why寄り） ## TODO/FIXMEの整理 | 種別 | 内容 | 担当 | 期限 | 関連Issue | ## 上位レベルドキュメント推奨事項 - このコードはREADMEへの章追加を推奨: - アーキテクチャ図の更新が必要: # 制約条件 - 関数名や変数名で表現できるWhatはコメントに書かない - 「TODO」だけのコメント禁止、必ず担当・期限・コンテキストを併記 - コメントとコードの乖離を生まない最小限の記述 - 機微情報（パスワード・キー・URL）をコメントに含めない
