この記事の対象: Web制作の実務でAIを使いたい制作者と、AI活用を制作会社に相談したい発注者
読了時間: 約12分
「ChatGPTを制作に使っている」と言うと、たいてい次の質問が返ってきます。「何に使っているんですか」。この答えが曖昧なうちは、まだ実務に組み込めていないと考えたほうが安全です。コードを書かせる、文章を書かせる——それだけでは、レビューと手直しの時間が増えて結局トントンになります。
この記事では、Web制作の工程を要件整理・情報設計・原稿・実装・コードレビュー・検収に分け、それぞれで実際に使っているプロンプトの型をそのまま出します。あわせて、出力が期待どおりにならないときにプロンプトのどこを直すかも書きます。汎用の「使えるプロンプト100選」ではなく、制作会社の中で残った型だけを載せます。
ChatGPTをWeb制作の実務に乗せる前提
得意なところと、任せてはいけないところ
先に線を引いておきます。ここを曖昧にしたまま使うと、成果物の品質が読めなくなります。
AIが強いのは、すでにこちらの頭の中にある情報を、決まった形に組み替える作業です。ヒアリングメモを要件の一覧に整える、既存ページの文章構造を洗い出す、命名規則の揺れを見つける。ここは速いし、精度も高い。
逆に弱いのは、こちらが持っていない情報を埋める作業です。クライアントの業界事情、競合の実際の動き、法規制の最新状況。もっともらしい文章が返ってきますが、裏取りなしで納品物に入れると事故ります。制作会社としていちばん怖いのはここで、原稿に紛れ込んだ「それっぽい数字」を発見できずにクライアントへ出してしまうケースです。
投げてよい（組み替え）
- 議事録から要件一覧をつくる
- 既存サイトの見出し構造を書き出す
- コードの命名の揺れを指摘させる
- 原稿のトーンを揃える
投げてはいけない（穴埋め）
- 業界の相場・統計を書かせる
- 競合サイトの現状を推測させる
- 法規制・表示ルールの判断
- クライアント固有の事情の補完
右側に入れたものは「使えない」のではなく、必ず一次情報で裏を取るまで納品物に入れないという意味です。下書きの材料として使うぶんには構いません。
プロンプトが長くなるのは悪いことではない
現場でうまくいっているプロンプトは、だいたい長いです。「短く簡潔に指示する」というコツをよく見かけますが、実務では逆でした。短い指示で良い出力が出るのは、一般的なタスクだけです。案件固有の条件が入った瞬間、前提を全部書かないと使えないものが返ってきます。
型の骨格は共通です。
5つめの「不明時の扱い」を入れるかどうかで、実務での使い勝手が大きく変わります。これが無いと、AIは空欄を嫌って埋めてきます。埋まった空欄は、こちらが気づかない限りそのまま通ってしまいます。
モデルの版が変わったら、型は作り直さない。制約だけ見直す
AIのモデルは短い周期で入れ替わります。そのたびにプロンプトを一から書き直していると、いつまでも型が溜まりません。実務では、版が変わったときに見るのは制約ブロックだけにしています。
役割・入力・出力形式は、モデルが変わっても意味が変わりません。変わるのは「放っておくと何をしてくるか」の部分です。以前の版で必要だった禁止事項が不要になっていることもあれば、新しい癖が出ていることもあります。手元の型を2〜3本走らせて、出力の余計な部分を見てから制約を足し引きするだけで足ります。
なお、モデル名・料金・利用上限の類は変動が速いので、この記事では具体的な値を書きません。判断材料にする場合は提供元の公式ページを都度確認してください。記事や社内資料に転記した数字は、転記した時点で古くなり始めます。
要件整理の工程で使うプロンプトの型
ヒアリングメモを要件一覧に変換する
打ち合わせ直後、まだ記憶が新しいうちに走らせる型です。議事録の清書ではなく、要件として扱えるものと、まだ確認が必要なものを分離させるのが目的です。
あなたはWeb制作会社のディレクターです。
以下はクライアントとの初回打ち合わせのメモです。
このメモから「サイト制作の要件」を抽出し、表にしてください。
# 打ち合わせメモ
（ここにメモを丸ごと貼る。整形しなくてよい）
# 出力形式
以下の列を持つMarkdown表で出力:
| 項目 | 要件の内容 | 確度 | 未確認の点 |
# 確度の判定基準
- 確定 … メモに明示された発言がある
- 推定 … 文脈から読めるが明言されていない
- 不明 … 触れられていないが、制作上必ず必要になる項目
# 制約
- メモに書かれていないことを補完しない
- 一般論としてのベストプラクティスを混ぜない
- 「不明」の行を必ず含めること。1件も無い場合は
「不明な項目なし」と明記し、その判断理由を書く
実装のポイントは「確度」の列です。これが無いと、AIが推測で書いた行と、クライアントが実際に言った行が同じ見た目で並びます。この2つを混ぜたまま要件定義書に転記すると、後から「そんなこと言っていない」という揉め方をします。
つまずきやすい点は、メモを整形してから貼ってしまうことです。整形の段階でこちらの解釈が入り、AIはその解釈を前提に組み立てます。誤字だらけの生メモをそのまま貼ったほうが、拾えるものが増えます。
出力された表は、そのまま要件定義書にしません。「確定」の行だけを抜いて先方に送り返し、「推定」と「不明」は質問リストに変えて次の打ち合わせに持っていきます。この一往復を挟むと、要件定義書に載る行がすべて相手の言葉になります。
見積の前に「聞き漏らし」を洗い出す
見積を出す前に一度通す型です。制作会社としてこれがいちばん効きました。金額を出した後に条件が追加されるのは、たいてい聞き漏らしが原因です。
あなたはWeb制作の見積を作る立場の人間です。
以下の要件一覧を読み、「この情報だけでは見積を確定できない項目」を
すべて列挙してください。
# 要件一覧
（前のプロンプトで作った表を貼る）
# 出力形式
| 不足している情報 | なぜ見積に影響するか | 確認しないまま進めた場合のリスク |
# 制約
- 「あったほうが良い情報」ではなく
「無いと金額が変わる情報」だけを挙げる
- 影響額の目安は書かない（金額は自分で判断する）
- 優先度の高い順に並べる
「影響額の目安は書かない」と明記しているのは、書かせると具体的な金額を返してくるためです。その数字には根拠がありません。制約に入れておかないと、後で自分がその数字に引きずられます。
この型で拾える代表例は、原稿と写真を誰が用意するか、既存ドメイン・サーバーをそのまま使うか、多言語対応の有無、公開後の更新を誰がやるか——このあたりです。いずれも工数が大きく動くのに、初回の打ち合わせでは話題にならないまま終わりがちな項目です。
見積の前提そのものを整理したい場合は、支払い条件の設計もあわせて確認しておくと、条件の抜けが減ります。
うまくいかないときに直す場所
要件整理の工程で出力が使えないとき、原因はだいたい次のどれかです。
| 症状 | 原因 | 直す場所 |
|---|---|---|
| 一般論しか返ってこない | 入力の材料が薄い | メモを増やす。要約せず全部貼る |
| 言っていない要件が混ざる | 「補完しない」制約が無い | 制約ブロックに禁止事項を明記 |
| 表がふわっとして使えない | 出力形式の指定が曖昧 | 列名と判定基準を先に定義する |
| 毎回違う粒度で返る | 粒度の基準が無い | 「1行＝1つの実装判断」と定義する |
いちばん多いのは1行目です。「良いプロンプトを書けば良い答えが返る」と思われがちですが、実務では入力の材料量のほうが効きます。プロンプトを磨く前に、貼る材料を増やすほうが早いです。
原稿と情報設計の工程で使うプロンプトの型
既存サイトの構造を棚卸しする
リニューアル案件の初手です。既存ページのテキストを貼って、情報設計の現状を可視化させます。
以下は既存サイトの1ページ分のテキストです。
このページの情報構造を分析してください。
# ページのテキスト
（見出しを含めてそのまま貼る）
# 出力形式
1. 見出し階層のツリー（H1〜H3）
2. 各セクションが果たしている役割を1行で
3. 構造上の問題点（該当が無ければ「なし」）
# 制約
- 文章の良し悪しは評価しない。構造だけを見る
- 「もっと魅力的に」等の抽象的な改善案を出さない
- 問題点は「何が」「どう困るか」の形で書く
構造と文章表現を同時に見させないのがコツです。同時にやらせると、AIは文章表現のほうに引っ張られて「もっと訴求力のあるコピーに」といった使えない指摘を返してきます。
出力される「構造上の問題点」で頻出するのは、H2とH3の階層が飛んでいる、同じ役割のセクションが別ページに分散している、ページの目的が複数混ざっている——の3つです。いずれもサイトマップを引き直す判断につながる指摘なので、リニューアルの提案資料にそのまま材料として使えます。
原稿のたたきを作る（そのまま使わない前提で）
原稿生成は、いちばん期待されていて、いちばん誤解されている使い方です。AIが出した文章をそのまま納品することは、現場ではまずありません。使うのは「型の確認」と「抜けの発見」です。
あなたは制作会社のライターです。
以下の条件で、サービス紹介ページの原稿の「構成案」を作ってください。
本文は書かず、見出しと各セクションで書くべき内容の指示だけを出します。
# 前提
- 業種:（具体的に）
- 想定読者:（誰が、どんな状態でこのページに来るか）
- このページで起こしてほしい行動:（1つだけ）
- 使ってはいけない表現:（業界の表示ルール、NGワード）
# 出力形式
| 見出し案 | このセクションで書くこと | 読者がここで抱く疑問 |
# 制約
- 見出しは5〜7個
- 「私たちの想い」のような自社視点の見出しを入れない
- 事実・数字・実績は一切書かない（こちらで埋める）
- 各セクションは、前のセクションで生じた疑問に答える順で並べる
「事実・数字・実績は一切書かない」 が最重要の制約です。これを入れないと、AIは「創業◯年」「導入実績◯社」といった空欄を勝手に埋めてきます。構成案の段階でそれが入ると、後工程で誰かが本物だと思って残してしまいます。
3列目の「読者がここで抱く疑問」も外せません。ここが埋まっていると、次のセクションが答えになっているかを機械的に確認できます。答えになっていない並びが見つかったら、見出しの順を入れ替えます。構成案のレビューを、感覚ではなく手順にできるのがこの列の役目です。
つまずきやすい点は、「使ってはいけない表現」を書かずに走らせることです。業種によって表示のルールは変わります。医療・美容・食品・不動産あたりは、AIが平然と踏んではいけない表現を書いてきます。ここは毎回、案件ごとに書き換える必要があります。
トーンを揃えるときの型
複数人で書いた原稿のトーンを揃える作業は、AIがかなり得意な領域です。
以下の「基準テキスト」の文体を分析し、
その特徴を箇条書きで言語化してください。
その後、「対象テキスト」を基準の文体に合わせて書き直してください。
# 基準テキスト
（トーンの正解にしたい既存原稿）
# 対象テキスト
（揃えたい原稿）
# 制約
- 内容は変えない。事実を足さない、削らない
- 文末表現・一人称・漢字とひらがなの配分を合わせる
- 書き直し前後の対比表も出す
先に「文体の特徴を言語化させる」のがポイントです。いきなり書き直させると、AIの手癖の文体に寄ります。言語化を1ステップ挟むと、基準側に寄せる精度が上がります。
言語化させた文体の特徴は、その案件のトーン定義としてそのまま保存しておきます。次に別のライターが入るとき、基準テキストを読ませる代わりにこの箇条書きを渡せば済みます。案件が長引くほど効いてくる副産物です。
実装とコードレビューの工程で使うプロンプトの型
コードを書かせるより、レビューさせるほうが効く
実装工程でいちばん費用対効果が高かったのは、コード生成ではなくコードレビューでした。生成させたコードは結局こちらが全部読むので、時間はあまり減りません。一方でレビューは、自分では見落とす種類のミスを拾ってくれます。
以下のCSSをレビューしてください。
指摘は「実際に不具合が起きるもの」に限定します。
# コード
（該当箇所を貼る。関連する変数定義も一緒に）
# 前提
- 対応ブラウザ: 各ブラウザの最新2バージョン
- iOS Safariでの表示確認が必要
- ダークモード対応あり
# 見てほしい観点
1. 指定したブラウザで動かない、または挙動が異なる書き方
2. 意図せず子孫要素へ影響する指定
3. 同じ役割の値がハードコードされている箇所
4. アクセシビリティ上の問題（コントラスト比・フォーカス）
# 出力形式
| 行 | 問題 | 起きる不具合 | 修正案 |
# 制約
- 好みの問題は指摘しない
- 「一般的にはこう書きます」という指摘はしない
- 問題が無い観点は「問題なし」と明記する
「好みの問題は指摘しない」を入れないと、実害のない指摘が大量に混ざります。読み分ける時間で自分でレビューできてしまうので、ノイズを削る制約が要ります。
「前提」ブロックを省かないことも重要です。対応ブラウザを書かないと、AIは古い環境まで想定した保守的な指摘を返してきます。もう考慮しなくてよい環境の話で紙面が埋まると、本当に見てほしい指摘が埋もれます。
CSSの実例：レビューで実際に拾えたパターン
抽象的なので、実際に指摘が有効だった書き方を1つ載せます。カード内のテキストを2行で省略する定番の書き方です。
/* レビュー前：一見動くが、条件によって崩れる */
.card__text {
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
overflow: hidden;
}
これ自体は広く使われている書き方ですが、line-height が指定されていない状態で使うと、フォントによって2行目が半端に切れて見えることがあります。指摘を受けて次の形にしました。
/* レビュー後：行の高さを固定し、切れ方を安定させる */
.card__text {
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
overflow: hidden;
line-height: 1.6;
/* 行数 × line-height で高さを固定しておく */
max-block-size: calc(1.6em * 2);
}
/* line-clamp が使える環境では上記が優先される。
将来的に標準プロパティへ寄せるなら併記しておく */
@supports (line-clamp: 2) {
.card__text {
line-clamp: 2;
}
}
なぜこう書くのか：-webkit-line-clamp はベンダープレフィックス付きのまま各ブラウザで広く動いていますが、line-height に依存して切れ位置が決まります。明示しないと、フォント読み込み前後で見た目が変わります。max-block-size を併記しておくと、line-clamp が効かない環境でも高さの暴れを抑えられます。
対応ブラウザ：標準プロパティの line-clamp はサポート状況が変わりつつあるため、@supports で囲んで併記するのが安全です。実装時点で必ず最新の対応表を確認してください。ここに書いた対応状況も、読んだ時点では変わっている可能性があります。
つまずきやすい点：display: -webkit-box を指定すると、その要素の中でFlexboxやGridが期待どおりに効きません。テキスト専用の要素に閉じて使うこと。親要素にまとめてかけると、レイアウトが静かに壊れます。
この指摘がAIから出てきたのは、プロンプトの「見てほしい観点」に「意図せず子孫要素へ影響する指定」を入れていたからです。観点を書かずに「レビューして」とだけ投げると、命名規則や記述順の話が返ってきて、この種の指摘は出てきません。何を見てほしいかを列挙するかどうかで、返ってくるものの種類が変わります。
JavaScriptの挙動を説明させる型
他人が書いたコード、あるいは過去の自分が書いたコードを引き継ぐときの型です。
以下のJavaScriptについて、次の3点を説明してください。
# コード
（貼る）
# 説明してほしいこと
1. このコードが解決しようとしている問題は何か
2. 処理の流れ（条件分岐を漏らさず）
3. この書き方でないと成立しない理由があるか
# 制約
- コードに書かれていない意図を推測しない
- 推測が必要な箇所は「推測」と明示する
- 改善案は求めていないので出さない
- 読み取れない箇所は「読み取れない」と書く
3番目の質問が効きます。「この書き方でないと成立しない理由があるか」を聞くと、単に冗長なだけの箇所と、意図があって複雑になっている箇所が分かれます。前任者の実装を引き継ぐとき、これを飛ばして書き直すと本番で事故ります。
「改善案は出さない」を入れているのは、理解と改善を同時にやらせると、AIが改善案の側に寄って説明が雑になるためです。まず読み解き、書き換えるかどうかはその後で別途決めます。
CMSまわりの実装をAIに手伝わせる場合は、テーマ側の作法と衝突しないかを先に確認しておく必要があります。Shopifyのように、アップデートで上書きされる領域を持つ環境では特にそうです。
検収・引き継ぎの工程で使うプロンプトの型
チェックリストを案件ごとに生成する
公開前チェックは、汎用のチェックリストだと毎回同じ項目を流し読みして形骸化します。案件の要件から生成させると、見る気が戻ります。
以下の要件一覧をもとに、公開前チェックリストを作ってください。
# 要件一覧
（要件整理の工程で作った表を貼る）
# 出力形式
| カテゴリ | 確認項目 | 確認方法 | 見つかった場合の重大度 |
# カテゴリ
表示 / 遷移 / フォーム / 計測 / SEO / 権限・アカウント
# 制約
- 要件一覧に無い機能のチェック項目を作らない
- 「確認方法」は具体的な操作手順で書く
（例:「スマホで確認」ではなく
「iPhoneのSafariで◯◯ページを開き、△△をタップ」）
- 目視で判断できない項目には、何を見れば分かるかを書く
「確認方法を具体的な操作手順で」という制約が肝です。これが無いと「表示崩れがないか確認」のような、確認したことにできてしまう項目が並びます。
「重大度」の列は、公開日にトラブルが出たときの判断に使います。公開を止めるものと、公開後に直すものを事前に分けておかないと、当日その場で議論が始まります。
生成されたリストは、そのまま使わずに一度読んで削ります。要件から機械的に起こしているので、実際には確認しようがない項目も混ざります。削る作業自体が、公開前に何を見るかを頭に入れ直す時間になります。
計測まわりのチェックは、ツールの設定状況によって見るべき場所が変わります。
保守引き継ぎ資料の下書き
運用に渡す資料は、書く側が仕様を分かりすぎているせいで抜けが出ます。第三者の視点を借りるのに向いています。
以下の実装内容を、サイトの更新担当者（非エンジニア）向けに
説明する資料の構成案を作ってください。
# 実装内容
（機能の一覧と、それぞれの実装方針を箇条書きで）
# 読者の前提
- WordPressの管理画面は触れる
- HTML/CSSは読めない
- 更新は月に数回、ページの文章と画像の差し替えが中心
# 出力形式
見出しと、各項目で説明すべき内容の指示
# 制約
- 技術的な仕組みの説明は、更新作業に必要な範囲だけ
- 「触ってはいけない場所」を必ず独立した項目として立てる
- 専門用語を使う場合は、初出時の言い換えを併記する
「触ってはいけない場所」を独立項目にさせるのは、実務で何度も痛い目を見たからです。更新担当者が悪気なく触って表示が壊れるケースは、引き継ぎ資料に書いていなかったことが原因のほとんどです。
「読者の前提」の書き方で出力の質が決まります。「非エンジニア向け」とだけ書くと、専門用語を避けただけの説明になります。更新の頻度と、実際にやる作業まで書くと、その作業に必要な範囲へ説明が絞られます。
編集者が崩さずに更新できる仕組みそのものを実装側で作っておくと、資料の分量も減ります。
発注者側がAI活用を評価するときの見方
ここからは、制作会社に依頼する側の視点です。「AIを活用しています」と言う制作会社をどう見るか。
「AIで安くなる」を額面どおり受け取らない
工程のうちAIで短縮できるのは、整理・変換・下書きの部分です。要件を決める打ち合わせ、デザインの判断、実装した後の検証は短縮されません。むしろレビューの負荷は増えます。AIが出したものを人が確認する工程が新しく発生するためです。
したがって「AIを使っているから大幅に安い」という説明が成り立つとしたら、どこかの工程を実際に削っています。削られた工程が何かを聞いたほうが早いです。
削られやすいのは、テスト・検証まわりと、公開後の初期サポートです。制作中は差が見えず、公開してから効いてきます。見積書の項目に「テスト」「検証」「公開後サポート」が立っているかを見るだけでも、ある程度は判別できます。
工程が省かれる構造そのものについては、価格の理由を分解した記事があります。
聞くと実態が分かる質問
AI活用の実態を確認したいとき、次の3つを聞くと差が出ます。
| 質問 | 実務で使っている会社の答え方 |
|---|---|
| どの工程で使っていますか | 工程名で具体的に返る（要件整理、原稿のたたき、など） |
| AIが書いた文章はそのまま納品しますか | 「しない」と即答し、確認の手順を説明できる |
| 誤りが混ざったときの発見手順は | 誰が、何と照合するかを説明できる |
3つめが本題です。AIを実務で回している現場は、必ず間違いが混ざる前提で工程を組んでいます。「混ざらないように気をつけています」という答えが返ってきたら、まだ運用が固まっていないと考えたほうが安全です。
あわせて確認しておくとよいのが、原稿と画像の権利まわりの扱いです。AIが生成したものを納品物に含めるかどうか、含めるならその旨を伝えてくれるか。ここを契約前に確認しておくと、公開後に「この画像は何ですか」と社内で問題になる事態を避けられます。
制作会社とフリーランスで、この体制の作り方は変わります。
プロンプトが効かないときのチェック順
出力が使えないとき、プロンプトを一から書き直すのは効率が悪いです。次の順で見ていきます。
経験上、大半は1と2で解決します。3と4まで行くのは、複雑な変換をさせているときだけです。
4の「分割」は見落としやすい点です。「構造を分析して、改善案も出して」のように2つ頼むと、片方が雑になります。分析と提案は別のプロンプトに分けたほうが、合計の所要時間も短くなります。
分けたあとは、前のプロンプトの出力をそのまま次の入力に貼ります。要約して渡すと、そこで情報が落ちます。工程をまたいで型がつながるのは、この「貼り直し」があるからです。要件整理の表が見積の抜け出しに入り、その要件一覧が公開前チェックリストの元になる——この記事の型が同じ表を使い回しているのは、そのためです。
型を溜めるときの整理の仕方
プロンプトは、案件ごとに書き捨てるとノウハウが残りません。工程名でフォルダを切って溜めるのが、いちばん破綻しませんでした。
要件整理
- メモ→要件表
- 見積前の抜け出し
原稿・情報設計
- 既存サイト構造の棚卸し
- 構成案の生成
- トーン統一
実装
- コードレビュー
- 既存コードの読み解き
検収・引き継ぎ
- チェックリスト生成
- 更新マニュアル構成
「業種別」や「ツール別」で切ると、案件が増えたときに探せなくなります。工程は案件が変わっても同じなので、切り口として安定します。
型のファイルには、プロンプト本文と一緒に「この制約を入れた理由」を1行ずつ添えておきます。理由が書いていないと、他のメンバーが「要らなそう」と判断して消します。消された制約は、たいてい事故が起きてから必要だったと分かります。
よくある質問
ChatGPTが書いたコードをそのまま納品してもいいですか
そのままは避けたほうが安全です。動くコードが返ってくることは多いのですが、対応ブラウザの前提や、既存のCSS設計との整合は考慮されていません。書かせたコードは、自分で書いたコードと同じ基準でレビューしてから入れてください。実務では、生成よりレビューに使ったほうが効果が出ています。
AIが事実と違うことを書いたのに気づけません
プロンプトの制約に「事実・数字・実績は書かない」と明記するのが最も確実です。書かせなければ、混入を探す必要がありません。どうしても情報が必要な場合は、AIに聞くのではなく一次情報を自分で当たり、その内容を材料としてプロンプトに貼る形にします。
短いプロンプトでうまくいくコツはありますか
一般的なタスクなら短くても機能しますが、案件固有の条件が入ると難しくなります。実務で安定しているプロンプトは、役割・入力・制約・出力形式・不明時の扱いの5ブロックを持っていて、結果的に長くなります。短さより、貼る材料の量と禁止事項の明記が効きます。
モデルが新しくなったらプロンプトは書き直しですか
書き直しません。役割・入力・出力形式は版が変わっても意味が変わらないので、見直すのは制約ブロックだけで足ります。手元の型を2〜3本走らせ、出力に余計なものが混ざっていないかを見てから禁止事項を足し引きします。なお、モデル名・料金・利用上限は変動が速いので、判断に使うときは提供元の公式ページを都度確認してください。
制作会社に「AIを使っているか」を聞くべきですか
使っているかどうかより、誤りが混ざったときの発見手順を聞くほうが実態が分かります。AIを実務で回している現場は、間違いが混ざる前提で確認工程を組んでいます。「混ざらないよう気をつけている」という答えなら、運用がまだ固まっていない可能性があります。
AIを使えば制作費は安くなりますか
短縮されるのは整理・変換・下書きの工程だけで、要件を決める打ち合わせ、デザインの判断、公開前の検証は変わりません。確認工程はむしろ増えます。大幅に安くなる説明があった場合は、どの工程を削ったのかを確認したほうが判断しやすくなります。見積書に「テスト」「検証」「公開後サポート」の項目が立っているかを見ると、削られた場所の見当がつきます。
まとめ
工程ごとに型を決めておくと、AIは「便利そうな道具」から「毎回同じ品質で回るもの」に変わります。この記事で出した型に共通しているのは、次の3点です。
- 材料を要約せずに貼る。プロンプトの言い回しより入力量が効く
- やってほしくないことを書く。特に「事実・数字を書かない」は必須
- 不明を不明のまま出させる。空欄を埋めさせると気づけない誤りが残る
そして、AIを入れても短縮されない工程があることは、発注する側にも共有しておく価値があります。削れるのは整理と下書きで、判断と検証は残ります。ここを正直に説明できるかどうかが、制作会社を選ぶときの一つの見方になります。
まずは要件整理の1本から試してみてください。打ち合わせ直後にメモを貼るだけなので、導入のコストがほぼかかりません。効果が出れば、そのまま他の工程へ広げられます。
