プロンプト設計の最初の打ち合わせで聞くこと｜後戻りを防ぐ

プロンプト設計の初回の打ち合わせは、その案件が最後まで穏やかに進むかどうかをほぼ決めてしまう。ここで聞き漏らした一つの条件が、納品直前になって「そもそも前提が違った」という形で戻ってくる。しかも多くの場合、戻ってきた時点では受け手の側に説明の材料がない。この記事では、初回の打ち合わせで何を、どういう順番で聞くのかを、業務の理解、実行環境、合格の基準、進め方の体制という4つのかたまりに分けて整理する。在宅で進める案件を前提に、記録の残し方と契約前の確認事項まで扱う。

初回の打ち合わせが、後戻りの量を決めている

プロンプト設計の依頼は、募集の文面が短い。「社内の問い合わせ対応にAIを使いたい」「レポートの下書きを自動化したい」。この一文から想像を膨らませて作業に入ると、ほぼ確実にずれる。ずれに気づくのは、たいてい最初の成果物を見せた後だ。

この職種でずれが起きやすいのは、依頼者側にも完成形が見えていないことが多いからだ。既存の制作物なら、参考にしたいサイトや過去の資料を出してもらえる。プロンプト設計にはそれがない。だから初回の打ち合わせは、相手の頭の中にある期待を言葉にして、両者が同じ絵を見ている状態を作る作業になる。

もうひとつ、この職種特有の事情がある。プロンプトは短時間で書けてしまうため、依頼者から見ると作業量が見えにくい。実際の作業は書くことではなく、試して比べて直す往復にあるのだが、その工程が想像されない。だから初回の打ち合わせでは、何をどう進めるのかという工程の説明も同時に行う必要がある。

生成AIから望む出力を引き出す技術そのものは、業務ごとの型として整理が進んでいる。

プロンプトエンジニアリングとは、生成AIから望む出力を引き出すための指示設計技術です。本記事では、営業・マーケティング・カスタマーサポートの各部門で実際に成果を出すプロンプト設計パターンを解説します。AI活用完全ガイドで、AI活用の全体像を把握できます。 出典: start-link.jp

型が整理されているということは、初回の打ち合わせで確かめるべきは技術の話ではなく、その型のどれを当てはめるかを決めるための業務情報だということでもある。

打ち合わせの前に済ませておく3つの準備

初回の場で聞き出す量を増やすには、事前の準備で場の時間を節約するしかない。オンラインで30分から1時間という枠が一般的な中で、雑談と自己紹介に時間を使うと、肝心の確認が半分も終わらない。

依頼文から読み取れることを先に整理する

募集文や問い合わせのメールを読み、分かっていることと分かっていないことを二列に書き出す。分かっていることは打ち合わせで確認するだけにとどめ、時間は分かっていないことに使う。この整理をしておくと、相手が説明済みの内容をもう一度聞いてしまう事故を防げる。既に答えをもらった項目を繰り返し聞くのは、相手の時間を奪ううえ、話を聞いていない印象を与える。

短い検証をひとつ用意する

依頼文に書かれている業務について、代表的な入力を自分で想像して作り、素直な指示で一度走らせてみる。結果を打ち合わせに持っていくと、話の解像度が一段上がる。「試したところ、この形式までは安定しましたが、判断の根拠を書かせる部分は指示の作り込みが必要そうです」と言えると、相手は自分の依頼の難所を初めて具体的に理解する。

準備にかける時間は30分程度で足りる。作り込む必要はない。目的は、話す材料を用意することだ。

質問票を先に送る

聞きたいことをまとめた短い質問票を、打ち合わせの前日までに送っておく。相手が社内で確認しないと答えられない項目があるからだ。とくに実行環境と、データの持ち出し可否は、担当者一人では判断できないことが多い。当日に持ち帰りになると、次の打ち合わせまで進行が止まる。

質問票は多くても10項目までに絞る。長いと読まれない。当日に深掘りする前提で、確認だけが必要なものを先に送る。

業務そのものについて聞くこと

打ち合わせの本体は、AIの話ではなく業務の話だ。ここに時間の半分以上を使う。

その業務は、今どういう手順で行われているか

現在の手順を、開始から終了まで順に話してもらう。誰が、どのデータを見て、何を判断し、どこに書き出しているか。手順書があれば見せてもらうが、実際の運用は手順書と食い違っていることが多いので、口頭での説明を優先する。

聞きながら、どの部分をAIに任せられそうかを頭の中で切り分ける。全部を任せる前提で話が進んでいる場合は、この場で分割を提案する。判断の難しい部分は人が残し、定型的な変換や抽出をAIに寄せる形が現実的だと伝える。

誰が最終的に品質を判断しているか

これは必ず聞く。氏名か役職まで特定する。ここが曖昧なまま進むと、改善の往復が終わらない。判定する人が複数いて意見が割れる状態は、構造として合格が出ない。

相手が「関係者みんなで見ます」と答えた場合は、代表して判断する人を1人決めてもらうことを提案する。全員の意見を集めるのは構わないが、最終的に合格を出す人は1人にする。この確認を初回で済ませておくと、後半の進行が驚くほど楽になる。

例外はどれくらいの頻度で出るか

典型的な入力だけを見て設計すると、運用に乗せた瞬間に崩れる。過去の実データの中で、扱いに困ったもの、判断が割れたものを見せてもらう。この例外の量が、設計の難度をほぼ決める。

例外が多い業務なら、AIで処理する対象を絞り、例外は人に回す設計にする。この振り分けの仕組みまで含めるかどうかも、この場で決める。

出力はどこへ流れるか

生成された文章や抽出結果が、その後どう使われるかを聞く。人がそのまま読むのか、別のシステムに取り込まれるのか、社外に出るのか。社外に出るものなら、確認の工程が必ず必要になる。システムに取り込むなら、出力の形式を厳密に固定する設計が要る。

今の困りごとは、時間なのか品質なのか

同じ「効率化したい」でも、時間を減らしたいのか、担当者によるばらつきを減らしたいのかで、設計の方向は変わる。時間が目的なら、多少の粗さを許容して人が直す前提の出力にしてよい。ばらつきが目的なら、形式と観点を厳密に指定して、誰が使っても同じ形になることを優先する。

この違いは、合格の基準にもそのまま効く。時間が目的の案件では、人が直す手間がどれだけ減ったかで評価される。全部が完璧でなくても、下書きとして使えれば合格になる。ばらつきが目的の案件では、たとえ一つひとつの出来が地味でも、揺れないことが価値になる。どちらを求めているかを取り違えると、良い仕事をしたつもりで評価されない結果になる。

聞き方としては、「今の困りごとで、いちばん困っているのはどちらですか」と二択で尋ねるのが早い。両方と答えられた場合は、どちらを先に改善したいかを重ねて聞く。優先順位を決めておくと、改善の往復で判断に迷わなくなる。

実行環境について聞くこと

業務の話が終わったら、動かす場所の話に移る。ここは技術的な確認だが、答えによって書き方が変わるので省略できない。

モデルと呼び出し方

どのモデルを使うのか。契約はすでにあるのか、これから決めるのか。ブラウザの画面から人が貼り付けて使うのか、APIから自動で呼ぶのか。会話の履歴を引き継ぐ形か、1回ごとに独立した呼び出しか。

同じ文面を別のモデルに移すと、出力の形式が崩れることは珍しくない。だから納品後にモデルを変える可能性があるかどうかも、この場で聞いておく。変える予定があるなら、その際の再調整をどう扱うかを見積もりに書く必要がある。

データの持ち出しと保管の可否

業務データを受け手の手元で扱ってよいのか。社内の環境でしか動かせないのか。個人情報や取引先の情報が含まれるのか。この確認を怠ると、作業を始めてから「そのデータは外に出せません」と言われて止まる。

秘密保持の取り決めをいつ結ぶかも、この流れで決める。NDA（エヌディーエー）を先に交わしてから詳細を聞く進め方が安全な案件もある。相手がこの話題を避ける場合は、その時点で警戒したほうがよい。

利用のルールと、責任の所在

社内で生成AIの利用ルールが定められているかを聞く。出力をそのまま外部に出してよいか、必ず人の確認を挟むことになっているか。ルールがある場合、設計はそれに従う必要がある。人の確認を必須とする運用なら、確認しやすい形の出力を設計するべきで、これは書き方そのものを変える条件になる。

出力に誤りがあった場合の責任をどう考えているかも、遠回しでよいので確認しておく。相手が「AIが間違えたら作った人の責任」と考えているのか、「確認するのは使う側」と考えているのかで、必要な作り込みの水準が変わる。ここは契約の話にもつながるので、初回では認識を聞くだけにとどめ、条件は書面で詰める。

すでに社内にある資産

過去に誰かが作ったプロンプト、社内の用語集、マニュアル、テンプレート。これらがあるなら見せてもらう。ゼロから作るより、既存のものを直すほうが速い場合が多い。また、社内で使われている言葉を出力に反映させると、受け入れられ方が変わる。

ツールの選定に口を出せる立場なのかも聞いておく。決裁が済んでいて変えられない場合と、こちらの推奨で決められる場合とでは、提案の幅が違う。

合格の基準を、その場で決めきる

初回の打ち合わせで最も重要な合意がこれだ。何をもって完成とするかを、言葉で固定する。

評価用のデータを誰が用意するか

入力例と、望ましい出力例の対を揃える作業を、どちらが担うのか。依頼者が持っている実データから作るのが理想だが、実務では「あとで出します」と言われたまま止まることが多い。

だから、いつまでに、何件を、どういう形で提供してもらうかを、その場で日付入りで決める。提供が遅れた場合は納期が後ろにずれるという合意も、ここで取る。受け手が作る場合は、独立した作業として工数に数えることを説明する。

判定の方法を具体的に決める

全件を見るのか、抜き取りで見るのか。何件を見て、どれだけ通れば合格なのか。定量的に測れる業務なら数値で線を引く。測りにくい業務なら、合格とする出力例と不合格とする出力例を数件ずつ用意し、それを基準として共有する。

この作業は打ち合わせの中で完結しないこともある。その場合は、後日の宿題として担当者と期日を決める。曖昧なまま作業に入ると、後で必ず戻ってくる。

進め方と体制について聞くこと

在宅で進める案件では、進行の設計そのものが成果に影響する。

窓口と決裁の経路

日々のやり取りをする担当者と、金額や契約を決める人が違う場合、その両方を把握しておく。担当者が良いと言っても、上長の一言で方針が変わることがある。決裁の経路を知っていれば、途中で必要な承認を先回りして取れる。

連絡の手段も決める。メールか、チャットか、相手の社内ツールに招かれるのか。反応が返るまでの目安時間も聞いておくと、進行の計画が立てやすい。

期限の理由

いつまでという日付だけでなく、なぜその日なのかを聞く。社内の発表に合わせているのか、他のシステムの切り替えに連動しているのか、単に早いほうがよいというだけなのか。理由が分かれば、間に合わないときの調整のしかたが見える。全部を間に合わせるのが無理でも、発表に必要な部分だけ先に出すという提案ができる。

打ち合わせの回数と、在宅での進め方

初回のあと、何回の打ち合わせを想定しているか。毎週の定例が必要なのか、節目だけでよいのか。プロンプト設計は在宅で完結しやすい仕事だが、業務の聞き取りと合格判定の場面だけは同期のやり取りが要る。逆に言えば、その2か所さえ押さえれば、残りは文面でのやり取りに寄せられる。

副業として受ける場合は、この2か所をどう本業の時間と調整するかが現実的な論点になる。初回の打ち合わせで「聞き取りと判定の回だけは日中に時間を取りたい」と伝えておくと、後で無理な調整をしなくて済む。相手も、それが分かっていれば予定を組みやすい。

事前に送る質問票の中身

質問票は、相手が社内で確認しないと答えられない項目に絞る。当日その場で答えられる質問は、票に入れずに打ち合わせで聞くほうが会話が続く。実務で使いやすい項目を並べる。

対象となる業務の名前と、月にどれくらいの頻度で発生するか。現在その業務にかかっている時間の感覚。担当している人数。この3つは、投資に見合うかどうかを相手が社内で説明するときの材料になるので、聞かれる前にこちらから確認しておくと信頼される。

使う予定のモデルと、その契約状況。ブラウザから使うのか、システムに組み込むのか。社内で利用が禁止されているサービスがあるか。この項目は情報システムの部署に確認が必要なことが多い。

扱うデータに個人情報や取引先の情報が含まれるか。データを受け手の環境に持ち出してよいか。持ち出せない場合、どういう形なら共有できるか。ここは法務や情報管理の部署の判断が要る。

過去に社内で作られたプロンプトや、AIの利用ルールがあるか。あるなら共有してもらえるか。既存の資産があると工程が短くなるので、必ず聞く。

出力の合格を判断する人の氏名か役職。判断の基準になる「良い例」を数件用意してもらえるか。この2つは初回で答えが出なくても、質問票に入れておくこと自体に意味がある。相手に「これは決めないといけない項目だ」と認識してもらえる。

希望する開始時期と完了時期、そしてその日付の理由。理由まで聞く欄を作っておくと、後で調整するときに交渉の余地が見える。

打ち合わせ中に出てくる、注意すべきサイン

会話の中に、後で問題になる予兆が混ざっていることがある。気づいた時点でその場で確認しておくと、後戻りを減らせる。

「とりあえず作ってみてもらって、見てから考えます」という言い方。これは合格の基準が存在しない状態を意味する。悪意はなく、相手も本当に決めかねているだけのことが多い。この場合は、こちらから評価の方法を提案する。少数の入力例で試作を見てもらい、そこで基準を一緒に作るという進め方を提示すると、話が前に進む。

「他の会社にも見積もりを出してもらっています」という言葉自体は普通のことだが、比較の軸が金額だけになっている場合は注意が要る。プロンプト設計は成果物の輪郭が見えにくいため、範囲の書き方次第で総額はいくらでも安く見せられる。含まれる工程を細かく分けて示し、何が入っていて何が入っていないかで比べてもらうよう促す。

「精度100%を目指したい」という表現が出たら、その場で丁寧に訂正する。生成AIの出力は入力によって揺れるため、全件の正しさを約束できる仕事ではない。約束できるのは、合意した評価データに対して基準を満たすことまでだ。ここを曖昧にしたまま進むと、納品後に責任の所在が争点になる。

担当者が業務の現場を知らない場合も、進行に影響する。企画部門の人が窓口で、実際に作業しているのは別の部署というケースだ。この場合は、現場の担当者に一度同席してもらえないか依頼する。同席が難しければ、現場の人に確認してほしい項目を箇条書きで渡す。

ツールと記録の環境を、初回のうちに揃える

在宅で進める案件では、やり取りの置き場所を早い段階で決めておくと、後の手戻りが減る。

まず、ファイルの共有方法。評価データや試作したプロンプトをどこに置くか。相手の社内ストレージに招いてもらえるのか、こちらが用意した場所を使うのか。データの持ち出し制限がある案件では、この選択が制約を受けるので、実行環境の確認と同時に決める。

次に、やり取りの履歴が残る手段を選ぶこと。電話や口頭だけで進めた条件は、後から確認できない。チャットでもメールでも構わないが、決定事項は必ず文字で残す形にする。相手が電話でのやり取りを好む場合は、通話のあとに要点を文面で送る運用にする。

試作したプロンプトと、その結果の記録も残す。どの版でどう指示を変えたら、出力がどう変わったか。この記録は、改善が止まったときに「これ以上は指示では解けない」と根拠を持って説明する材料になる。表計算のシートで十分で、凝った仕組みは要らない。

実際にプロンプトを組み立てるときは、いくつかの型を試して比べる進め方が定着している。

実際に、プロンプトテクニックを利用して生成AIに問いかけてみましょう。ここでは、先に挙げた8つのテクニックから抜粋して実践的なプロンプトを3つ紹介します。 出典: directcloud.jp

複数の型を並べて比べるという進め方を初回に説明しておくと、後で「案を1つしか見ていない」という不満が出ない。比較の過程を見せること自体が、作業量の説明にもなる。

打ち合わせの中で、こちらから必ず伝えること

聞くだけでなく、伝えるべきこともある。伝え漏らすと、期待だけが膨らむ。

ひとつは、プロンプトの工夫で解ける範囲と、データや業務フローを変えないと解けない範囲があるということ。この線を初回に説明しておかないと、改善を重ねても納得されない。事前に用意した検証の結果を見せながら話すと伝わりやすい。

もうひとつは、出力の完全な正しさは約束できないということ。生成AIの出力は入力によって揺れる。約束できるのは、合意した評価データに対して基準を満たすことまでで、あらゆる入力に対する保証ではない。この説明を避けて契約すると、後で責任の所在が争点になる。

3つ目は、進め方の工程。要件の聞き取り、評価データの作成、試作と比較、改善の反復、資料作成、引き渡し。この流れを口頭で説明し、どこに時間がかかるかを伝える。作業量が見えにくい職種だからこそ、工程の説明が信頼につながる。

議事録の残し方

打ち合わせの内容は、その日のうちに文面にして送る。記憶が新しいうちに書き、相手にも確認してもらう。

書く項目は決まっている。確認した業務の内容、決まったこと、決まらなかったこと、次に誰が何をいつまでにやるか。とくに「決まらなかったこと」を書くのが重要で、宿題を明示しておかないと、双方が相手の作業待ちだと思って止まる。

前提条件になる情報は、議事録の中で見出しを立てて並べる。モデル名、実行方式、データの提供元と提供時期、判定者の氏名、合格の基準。この部分がそのまま見積書の前提条件欄になる。

送った議事録に相手から訂正が入ったら、それも記録に残す。口頭の合意だけで進めた条件は、後から確認する手段がない。文面で残っていれば、前提が変わったときに「これは前提条件の変更にあたる」と穏やかに切り出せる。

議事録を送るときの文面にも、少し気を配る価値がある。決まったことを列挙するだけでなく、次に相手にお願いする作業を冒頭に書く。担当者は複数の案件を抱えていることが多く、長い文面の途中に埋もれた依頼は見落とされる。期日を添えて先頭に置くだけで、宿題が返ってくる速度が変わる。

相手から返信が来ない場合の扱いも決めておくとよい。議事録に「この内容で相違があればご連絡ください。連絡がなければこの前提で進めます」と一文添えておけば、無反応のまま止まることを避けられる。期限を短く区切りすぎると押し付けがましくなるので、数日程度の余裕を持たせる。

初回で決まらなかったときの進め方

一度の打ち合わせで全部が決まるとは限らない。むしろ、実行環境やデータの扱いは持ち帰りになるのが普通だ。

このとき、決まっていない項目を抱えたまま見積もりを出すのは避ける。どうしても概算を求められる場合は、前提を明記したうえで幅を持たせ、前提が確定した時点で正式な見積もりを出すと伝える。前提が変われば金額も変わるという条件が文面に残っていれば、後から調整できる。

決まらない項目が多すぎる場合は、要件を整理する作業そのものを独立した依頼として提案する方法もある。業務の分解と評価基準の設計までを1つの成果物とし、そこから先の設計は別途見積もるという分け方だ。相手にとっても、いきなり全体を発注するより判断しやすい。

2回目以降の打ち合わせを、初回のうちに設計しておく

初回で全部を決めきれない以上、次にいつ何を話すのかを、初回の終わりに合意しておく。これをしないと、次の打ち合わせが「進捗の報告会」になり、決めるべきことが先送りされ続ける。

現実的なのは、節目ごとに3回の同期のやり取りを置く形だ。1回目が業務の聞き取りと基準の合意。2回目が試作の確認で、少数の入力例に対する出力を一緒に見て、基準を具体化する。3回目が引き渡しで、担当者に実際に触ってもらい、その場で出た疑問に答える。この3回さえ押さえれば、残りは文面のやり取りで進められる。

2回目の試作確認は、早い段階に置くほど効果が大きい。完成度が低い状態で見せるのは気が引けるが、方向がずれていた場合に修正できる範囲が広い。完成間際に初めて見せると、ずれていたときの手戻りが全工程に及ぶ。初回の打ち合わせで「早い段階で一度お見せします」と伝えておくと、粗い状態で出しても不安を与えずに済む。

定例の打ち合わせを毎週入れる提案を受けたら、頻度を下げられないか相談する。プロンプト設計の作業は、まとまった時間を確保して試行を重ねるほうが進む。細かく分断されると、同じ作業を何度も思い出し直すことになる。文面での報告に置き換えられる回は、そう提案してよい。

打ち合わせの後に相手が社内で説明する場面も想定しておく。担当者は上長に進捗を報告する立場にあることが多い。報告に使える形の資料を、こちらから短くまとめて渡しておくと、相手の負担が減り、次の依頼につながりやすくなる。凝ったものは不要で、決まったことと次の予定を数行にまとめるだけでよい。

契約の前に固めておく取引条件

打ち合わせで業務の話が固まったら、条件の話に移る。ここを飛ばして作業に入ると、揉めたときに守るものがない。

確認するのは、報酬の金額と支払いの時期、成果物の権利の扱い、秘密保持、修正の回数、契約を解除する場合の条件だ。とくに支払いの時期は、発注の書面に明記してもらう。業務委託の取引では、発注者が支払いの期日を明確にすることが求められており、口頭のやり取りだけで進めるのは双方にとって不利になる。取引条件の書面化についてはe-Govから関連する法令の条文を確認できる。

書類の作法そのものに不安があるなら、体系的に学べる資格の学習範囲が実務の型として役に立つ。ビジネス文書検定で扱う範囲は、見積書や議事録の書き方の基礎とそのまま重なる。

なお、契約書の条項について具体的な判断が必要な場面では、弁護士など専門家への相談を挟むほうが確実だ。この記事で扱っているのは、打ち合わせの段階で確認しておく項目の整理までになる。

初回で降りる判断をしてよい場面

すべての依頼を受ける必要はない。打ち合わせの中で次の条件が重なったら、丁重に辞退するほうが双方のためになる。

対象業務がまったく特定されておらず、「社内のAI活用を全般的に見てほしい」という粒度で止まっている場合。これは設計の対象が存在しない状態で、まず対象を決める作業から始まる。その整理そのものを有償の依頼として切り出せるなら受けてよいが、無償の提案として求められているなら、応えても消耗するだけになる。

合格を判断する人を決められない、決める気がない場合。改善の往復が構造として収束しないため、どれだけ丁寧に作っても終わらない。1人に絞ってもらうことを条件として提示し、応じてもらえないなら、往復の上限を厳しく設定するか、時間で精算する形に切り替える。

秘密保持の話題を避ける相手も避ける。業務データを預かる仕事で取り決めがないのは、双方にとって危険な状態だ。相手が慣れていないだけの場合もあるので、こちらから簡単な書式を提案してみて、それでも進まないなら辞退の判断材料にする。

断るときは、理由を業務の条件に置いて短く伝える。「合格の判断者が定まらない状態では、責任を持って納品できないため」と書けば角が立たない。断った案件の記録を一行残しておくと、似た依頼が来たときの判断が速くなる。

市場の中での位置づけと、隣の職種から読む

プロンプト設計は職種として新しく、募集の文面もまだ形が定まっていない。どんな業務で求められているかを知るには、実際の募集を読むのが早い。ChatGPT活用・プロンプト設計のお仕事には依頼側が何を成果物と考えているかの実例が並んでおり、初回の打ち合わせで確認すべき項目の当たりを付けるのに使える。マーケティングや情報管理と組み合わさった募集も増えているので、AI・マーケティング・セキュリティのお仕事も併せて見ておくとよい。

年収や条件の目安は、隣接する職種から読むほうが実態に近い。開発の要素を含む案件ならソフトウェア作成者の年収・単価相場が、文章の設計や編集の比重が高い案件なら著述家，記者，編集者の年収・単価相場が参考になる。どちらに寄せて自分を説明するかで、相手の理解も変わる。

在宅で長く続けている人の働き方を知りたいなら、Webマーケティング フリーランスで海外ノマド！年収、スキル、成功への道のような事例が、打ち合わせの持ち方や時間の使い方の参考になる。

20年この市場を見てきた立場から

在宅と業務委託の市場を長く運営してきた立場から見ると、初回の打ち合わせが上手い人には共通点がある。話がうまいのではなく、聞く順番が決まっている。業務、環境、基準、体制。この順で聞くと、相手も答えやすい。逆に、いきなり技術の話や金額の話から入る人は、必要な情報を取り逃す。

もうひとつ、長く続いている人ほど、初回の場で「できないこと」を先に言っている。期待を下げる話は言いにくいが、ここを飛ばした案件は後半で必ず揉める。先に言った人のほうが、結果として同じ依頼者から次を頼まれている。

取引の形も効いてくる。中間のマージンが乗らない直接の取引では、依頼者は同じ予算でより多くを頼め、受け手は同じ仕事で手取りが厚くなる。手数料0%の構造が意味を持つのは、金額の多寡そのものより、丁寧に前提を詰めた相手と長く組める関係が続きやすいという点にある。初回の打ち合わせに時間をかけることは、その関係への投資になる。

よくある質問

Q. プロンプト設計の初回の打ち合わせは、どれくらいの時間を確保すべきですか？

30分から1時間の枠が一般的ですが、業務の聞き取りに半分以上を使う前提で組んでください。時間が足りない場合は、実行環境やデータの扱いを事前の質問票で確認しておき、当日は業務の手順と合格の基準に集中します。1回で決まりきらない項目は宿題として期日を決め、後日の短い回で埋めるほうが、無理に詰め込むより結果的に速く進みます。

Q. 相手が完成形をイメージできていない場合、どう進めればよいですか？

事前に短い検証をひとつ用意して持ち込むのが有効です。想像した入力で一度走らせた結果を見せると、相手は自分の依頼の難所を具体的に理解できます。そのうえで、プロンプトの工夫で解ける範囲と、業務フローを変えないと解けない範囲を線引きして説明します。要件の整理そのものを独立した依頼として提案する方法もあります。

Q. 合格の基準は初回で決めきる必要がありますか？

決めきるのが理想ですが、その場で固まらないことも多いです。最低限、最終的に合格を出す人を1人特定してください。ここが曖昧だと改善の往復が収束しません。判定の方法や評価データの提供時期は、後日の宿題として担当者と期日を決めます。曖昧なまま作業に入ると、納品直前に前提が違うという形で戻ってきます。

Q. 副業で受ける場合、打ち合わせの時間はどう調整しますか？

同期のやり取りが必要なのは、業務の聞き取りと合格の判定の場面だけです。この2か所を日中に確保したいと初回で伝えておけば、相手も予定を組みやすくなります。残りの工程は文面のやり取りに寄せられるため、在宅で完結させやすい仕事です。定例の打ち合わせを毎週入れる前提になっている場合は、頻度を下げられないか相談してください。

Q. 打ち合わせの内容は、どこまで記録に残すべきですか？

その日のうちに文面にして送り、相手に確認してもらってください。書くのは、確認した業務の内容、決まったこと、決まらなかったこと、次に誰が何をいつまでにやるかの4点です。とくに決まらなかった項目を明示しないと、双方が相手の作業待ちだと思って止まります。前提条件として並べた部分は、そのまま見積書の前提条件欄に使えます。