プロンプト設計の実績の見せ方｜出せない仕事をどう伝えるか

結論から書く。プロンプト設計の実績の見せ方で行き詰まる原因は、実績がないことではなく、出せない形のまま抱えていることにある。守秘義務のある案件は原文を出せない。社内での改善は成果物が外に出ない。練習で作ったものは実案件ではない。この3つの壁に共通する解き方は同じで、依頼者が見たいものが何かを理解したうえで、出せる部分だけを取り出して組み立て直すことだ。この記事では、その手順を具体的に整理する。

依頼者が実績を見るとき、確かめているもの

まず前提を揃える。依頼者は、応募者の過去の仕事に興味があるわけではない。自分の案件を任せて大丈夫かどうかを判断する材料が欲しいだけだ。この違いは大きい。

判断のために見ているのは、おおむね3点に集約される。第一に、業務を分解できるかどうか。AIに任せる部分と人が持つ部分を切り分けられる人かどうかを見ている。第二に、出力の良し悪しを言語化できるかどうか。「なんとなく良い」ではなく、どの観点でどう評価したのかを説明できるかを見ている。第三に、うまくいかなかったときに原因を切り分けられるかどうか。指示の不足なのか、入力データの問題なのか、モデルの限界なのかを分けて考えられる人かを見ている。

この3点は、実案件でなくても示せる。だからこそ、守秘義務で原文が出せない状況でも実績の提示は成り立つ。逆に言えば、有名企業の案件に関わったという事実だけを並べても、この3点が伝わらなければ判断材料にならない。

正直なところ、応募書類に「大手企業のAI導入プロジェクトに参画」とだけ書かれているものを見ても、何ができる人なのかは分からない。依頼側の立場に立てば、当然の反応だ。

出せない仕事を、出せる形に作り替える

守秘義務がかかった案件をそのまま出すことはできない。しかし、契約で守られているのは通常、依頼者の情報とその案件固有の内容であって、受け手が身につけた設計の手法そのものではない。この線引きを踏まえて、3つの作り替え方がある。

数字と固有名詞を外して、構造だけ残す

最も使いやすいのがこれだ。業種名を一般化し、社名を消し、扱ったデータの中身を架空のものに置き換える。残すのは、どういう業務で、何が難しくて、どう分解して、どの型を当てたかという構造だけにする。

たとえば「食品メーカーの商品説明文の生成で、対象商品、想定顧客、掲載する媒体、文字数、文体という5つの条件を指示に加える設計にした」という書き方なら、依頼者の情報は含まれない。それでいて、業務を分解する力と、指示の型を選ぶ判断は十分に伝わる。

ここで注意が要るのは、抽象化しすぎないことだ。「業務の効率化に貢献しました」まで薄めると、何も伝わらない書類になる。守るべきは固有名詞と数値であって、設計の考え方は残してよい。迷ったら、契約書の秘密保持条項を読み直し、何が守秘の対象なのかを確認する。判断が付かない場合は、依頼者に「この粒度で紹介してよいか」を直接聞くのが早い。断られることは、思っているより少ない。

同じ課題を、公開データで作り直す

案件そのものを出せないなら、似た課題を公開情報で再現する。官公庁が公開している統計資料、自治体の案内文、企業の採用ページ。こうした誰でも見られる素材を入力にして、実案件と同じ設計を当てて見せる。

この方法の利点は、依頼者が自分でも同じ入力を用意して確かめられることだ。事例として提示されたものを、相手が追試できる。追試できる事例は、できない事例よりはるかに信頼される。

作り直しの手間は、思うほど大きくない。設計の考え方は既に自分の中にあるので、素材を差し替えて走らせ直すだけで済む。むしろ時間がかかるのは、出力を評価して見せ方を整える部分になる。

手順そのものを成果物として見せる

3つ目は、成果物ではなく進め方を見せる方法だ。要件をどう聞き取り、評価データをどう作り、何案を比べ、どう改善したか。この工程を文書として整理して見せる。

プロンプト設計の価値は、最終的な文面よりも、そこに至る過程にある。依頼者が本当に知りたいのは、自分の案件でも同じ過程を踏んでくれるかどうかだ。工程を書いた資料は、どの案件にも共通して使えるため、一度作れば長く使える。

題材の決め方と、作りはじめるまでの手順

作り替えの方針が決まっても、題材が決まらないと手が止まる。ここは順番を決めておくと迷わない。

最初にやるのは、自分が説明できる業務の棚卸しだ。前職で担当していた作業、いま副業でやっている作業、家族や知人の仕事で内容を聞いたことがある作業。この中から、入力と出力がはっきりしているものを選ぶ。「問い合わせのメールを分類する」「議事録から決定事項だけを抜き出す」「商品の情報から説明文を作る」といった粒度がちょうどよい。

次に、その業務で扱うデータを、公開情報で代用できるかを確認する。代用できないものは題材から外す。自治体の公開文書、企業の採用ページ、統計資料の説明文など、誰でも取得できる素材に置き換えられる業務を選ぶと、後の作業が楽になる。

3つ目に、その業務の「難しさ」がどこにあるかを言葉にする。難しさが説明できない題材は、事例にしても読み手の印象に残らない。例外の判断が要る、表記の揺れが多い、出力の形式が厳密に決まっている。こうした難所がある題材ほど、設計の力を見せやすい。

ここまで決まったら、入力例を集める。典型的なもの、例外的なもの、判断に迷うものを混ぜる。件数は多くなくてよいが、例外を必ず入れる。典型例だけで作った事例は、運用を知らない人が作ったものだと読み手に伝わる。

最初の1本を作るまでの進め方

作業の順番は、入力例の準備、素直な指示での実行、出力の評価、指示の改善、再実行の繰り返しになる。ここで大事なのは、最初にわざと素直な指示で走らせることだ。改善前の出力が手元にないと、比較して見せる材料が作れない。

改善の過程は、その都度メモに残す。どの条件を足したら、どの出力がどう変わったか。この記録がそのまま事例の中身になる。後から思い出して書こうとすると、細部が曖昧になり、説得力が落ちる。

1本目にかける時間は、長く見積もっても数日で足りる。完璧を目指すと終わらないので、限界と運用の項目まで書けた時点で公開してよい。事例は後から追記できる。

事例1本を、5つのパートで組み立てる

事例を並べるとき、書き方が揃っていないと読みにくい。次の5つのパートで統一すると、読み手が比較しやすくなる。

前提

どういう業務で、誰が使うものか。入力に何が来て、出力をどこで使うのか。制約として何があったか。ここを最初に書かないと、以降の判断の妥当性が評価できない。

分量は短くてよい。ただし、業務の頻度や、対象となる文書の種類までは具体的に書く。「社内文書の要約」より「毎週の営業報告を、部門長向けの短い要約に変える」のほうが、読み手の頭に絵が浮かぶ。

設計の意図

なぜその書き方を選んだのか。役割を与えたのはなぜか、手順を分けたのはなぜか、出力形式を固定したのはなぜか。ここが事例の中心になる。

型の選択には理由がある。分類や抽出のように正解が一意に決まる業務では、条件を厳密に列挙する型が効く。文章生成のように正解が幅を持つ業務では、良い例と悪い例を示す型が効く。この判断を書けると、他の業務でも応用できる人だと伝わる。

実際の指示

抽象化した状態でよいので、実際に使った指示の骨格を見せる。全文を出せない場合は、構成の見出しだけでも意味がある。「役割の指定、入力の説明、手順の指示、出力形式の指定、禁止事項」といった組み立てが分かれば、読み手は水準を推し量れる。

出力の比較

改善前と改善後を並べる。ここが事例の説得力を決める部分で、条件を足すだけで結果がどう変わるかを目で見せる。実際、指示に不足があるだけで結果が大きく変わる例は、支援の現場でも繰り返し報告されている。

kotukotuが支援した食品製造業の中小企業では、最初「AIの回答が的外れで使い物にならない」という声があった。実際に使われていたプロンプトを確認すると「商品の説明文を作ってください」という1文のみだった。対象商品・ターゲット顧客・使用する媒体・文字数・トーンの5点を加えるだけで、修正不要な回答が出るようになり、1件あたりの作業時間が40分から5分に短縮された。 出典: kotukotu.co.jp

事例に載せる比較も、これと同じ構造で作る。何を足したら何が変わったのかが一目で分かる形にする。改善後だけを見せる事例は、成果を主張しているだけで、設計の力を示していない。

限界と運用

どこまでは安定して、どこからは人の確認が必要か。運用に乗せる際に決めたルールは何か。この記述があると、評価が一段上がる。

理由は単純で、限界を書ける人は、限界を測ったことがある人だからだ。良いところだけを並べた事例は、実際に運用したことがない印象を与える。正直なところ、この項目が抜けている事例集は、それだけで評価を下げていると考えたほうがよい。

何本作るか、どの順に作るか

事例は多ければよいというものではない。読み手は全部を読まない。3本から5本あれば十分で、それ以上は選ぶ手間を増やすだけになる。

順番には意味がある。最初の1本は、自分が最もよく知っている業務で作る。前職の実務でも、日常的にやっている作業でも構わない。知っている業務なら、例外の扱いや現場の事情まで書けるため、事例の密度が上がる。知らない業務で作った事例は、どこか薄くなる。

2本目は、1本目と違う型の業務を選ぶ。1本目が分類や抽出なら、2本目は文章生成にする。違う型を扱えることを示すのが目的だ。3本目以降は、狙っている案件の分野に寄せる。応募先の業種に近い題材があると、読み手の理解が早い。

作る順番を守ると、途中で止まっても形になる。全部を並行して進めると、どれも中途半端なまま時間だけが過ぎる。

どこに、どう置くか

置き場所は、読み手が到達しやすい場所を選ぶ。凝った作りは要らない。

文章として読ませる形なら、記事を公開できる場所に置く。検索から見つかる可能性があるのは利点だが、依頼者に直接見せるだけなら共有できる文書ファイルでも構わない。重要なのは、リンクひとつで全体が読める状態にしておくことだ。応募のたびに資料を添付し直す運用は、手間が増えるうえに版がずれる。

構成は、最初に一覧、その先に個別の事例という形にする。一覧には、業務の種類、使った型、扱った出力形式を1行でまとめる。読み手はここだけを見て、詳しく読む事例を選ぶ。

更新の日付も入れておく。生成AIの分野は動きが速く、古い事例は古いなりに読まれる。半年以上更新のない事例集は、それだけで現役感が薄れる。定期的に見直し、モデルの更新で挙動が変わった部分は追記する。この追記自体が、運用まで見ている人だという証明になる。

職務経歴書と事例集の役割を分ける

事例集を作ると、職務経歴書に何を書けばよいか分からなくなる人がいる。役割を分けて考えると整理しやすい。

職務経歴書は、経歴の事実を時系列で示す書類だ。どの期間に、どの立場で、どういう業務を担当したか。ここに設計の詳細を書き込むと読みにくくなるだけで、評価も上がらない。プロンプト設計に関わった期間があるなら、担当した業務の種類と規模の感覚を1行で書き、詳細は事例集に譲る。

事例集は、判断材料を示す書類だ。何ができるかを、実物で見せる。経歴の空白や職種の変遷を説明する場所ではない。両者を混ぜると、どちらの目的も達成できない中途半端な資料になる。

未経験からこの分野に入る場合、職務経歴書の見せ方には工夫が要る。前職の業務が、そのまま設計の対象になる知識であることを書く。事務職なら定型文書の構造を知っている。営業職なら顧客とのやり取りの型を知っている。この知識は、業務を分解する場面でそのまま効く。「未経験」と書いて終わらせず、どの業務知識を持ち込めるかを具体的に書く。

年齢や経歴の転換を気にする人もいるが、この分野では前職の業務知識のほうが効く場面が多い。長く同じ業務を担当してきた人は、その業務の例外や現場の事情を知っている。それは、外から入った設計者には見えない情報だ。

やってはいけない見せ方

失敗のパターンははっきりしている。

守秘義務のある内容を、そのまま載せてしまうのが最悪の失敗だ。社名を消しても、業務の内容と時期が分かれば特定できる場合がある。特定される可能性が少しでもあるなら、載せない。信用を失う速度は、実績を積む速度よりずっと速い。

次に多いのが、成果を数字で誇張する見せ方だ。効果を測った条件を書かずに結果だけを出すと、読み手はそこを疑う。測定の方法と条件を書けないなら、数字は出さないほうが信頼される。

3つ目は、AIが生成した文章をそのまま事例の解説に使うこと。プロンプト設計を仕事にする人の資料が、明らかに生成物そのままの文体だと、判断力を疑われる。生成を使うこと自体は問題ないが、自分の言葉に直す工程を挟む。

4つ目は、実案件でないものを実案件のように見せること。練習で作ったものは、練習だと明記して構わない。むしろ、題材の選び方と設計の意図が説明できていれば、練習であることは大きな不利にならない。偽って書いたことが後で分かるほうが、はるかに損失が大きい。

5つ目は、指示の全文をそのまま公開してしまうこと。守秘義務にかからない練習事例であっても、完成した指示をそのまま置くと、読み手はそれを持ち帰るだけで済んでしまう。見せるべきは、なぜその構成にしたのかという判断のほうだ。骨格と意図を示し、細部は面談で説明すると書いておけば、会話につながる。

6つ目は、他人の事例をなぞって自分のものとして出すこと。公開されている解説記事の構成をそのまま写した事例は、読み慣れた人にはすぐ分かる。参考にするのは構わないが、自分で走らせて自分の言葉で書いた部分がないと、面談で深掘りされた瞬間に答えられなくなる。

これらの失敗に共通するのは、見栄えを優先して判断の過程を省いていることだ。プロンプト設計の評価は、出来上がった文面ではなく、そこに至る考え方に対して行われる。

社内での改善を、実績として扱う場合

会社員として社内の業務にプロンプト設計を当てた経験は、外に出しにくい実績の代表格だ。成果物は社内システムの中にあり、数字も外に出せない。しかし、この経験はむしろ強い材料になる。理由は、業務を最初から最後まで知っている立場で設計したからだ。

外に出すときは、会社名と業種を伏せ、扱った業務の種類だけを書く。そのうえで、社内だからこそ踏めた工程を強調する。現場の担当者に直接聞き取りができたこと、実データで検証できたこと、運用に乗せた後の不具合まで見届けたこと。外部の受注では届きにくい部分に手が入っているのは、明確な差になる。

注意点は、勤務先の規程を確認することだ。副業の可否とは別に、業務で得た知見の公開について定めがある場合がある。公開の可否が不明なら、業務の具体を書かず、手法の説明だけにとどめる形が安全になる。設計の型の話であれば、特定の会社の情報にはあたらない。

社内の改善は成果を測りやすいという利点もある。担当者の作業時間がどう変わったか、確認の回数がどう減ったか。数字そのものを出せなくても、「どういう指標で効果を見たか」を書くだけで、測る習慣がある人だと伝わる。効果測定の考え方は、公開されている支援事例でも繰り返し扱われている。

生成AIのプロンプト設計は、特別なエンジニアリングスキルがなくても、中小企業の現場で今日から改善できる領域だ。「使えない」と感じているなら、まずプロンプトの書き方を見直すことが最短の改善ルートになる。 出典: kotukotu.co.jp

特別な技術がなくても改善できる領域だということは、裏を返せば、設計の質を説明できるかどうかで差が付く領域だということでもある。だから実績の見せ方が効いてくる。

応募や提案の文面に、事例をどう組み込むか

事例集を作っても、応募の文面でリンクを1行貼るだけでは読まれない。読み手は多くの応募を短時間でさばいているため、開いてもらう理由を文面の中に作る必要がある。

有効なのは、募集内容に近い事例を1つ名指しで示し、その事例のどの部分が今回の依頼と重なるかを2文で書くことだ。「今回の依頼と同じく、出力の形式を厳密に固定する必要がある業務を扱った事例があります。例外の入力が来たときの扱いも書いています」という形になる。全部を見てくださいではなく、この1本を見てくださいと言うほうが、実際に開かれる。

さらに一段強いのは、応募の時点でその案件向けの小さな検証を添えることだ。募集文から入力を想像して作り、素直な指示で走らせた結果を短く報告する。この一手間があると、事例集の説得力が実案件への適用力に変わる。他の応募者と並んだときに差が出るのは、たいていこの部分だ。

書類の分量には注意する。長い応募文は読まれない。事例集へのリンクを本体とし、文面は短く保つ。読み手が知りたいのは、任せて大丈夫かどうかの一点であり、経歴の網羅ではない。

面談で聞かれることに、先に答えを用意する

事例を見た依頼者は、面談でほぼ決まった質問をしてくる。答えを準備しておくと、話が早い。

「その設計はどうやって思いついたのか」。ここでは、複数案を比べたことを話す。1案で当たったのではなく、比較して選んだと説明できると、再現性がある人だと伝わる。

「うまくいかなかった場合はどうするのか」。原因を、指示の不足、入力データの欠け、モデルの限界の3つに切り分けて調べると答える。切り分けの手順を持っている人は、行き詰まりに強い。

「うちの業務でも同じようにできるか」。ここで安請け合いしない。業務を見てからでないと判断できないと正直に答え、確認したい項目を具体的に挙げる。挙げられる項目の質で、経験の有無が伝わる。

「守秘義務の扱いはどうしているか」。事例を抽象化した基準を説明する。依頼者は、自分の案件が将来どう扱われるかを気にしている。線引きの基準を持っている人は安心して任せられる。

実績が薄いうちに使える補助材料

事例が揃うまでの間、判断材料を補う手段はある。

ひとつは、業務知識の証明だ。プロンプト設計は対象業務を理解している人ほど速く成果を出せるため、前職の業務知識はそのまま強みになる。文書作成の型を体系的に押さえていることを示したいならビジネス文書検定の学習範囲が実務とそのまま重なり、報告書や依頼文の構造を扱う案件では話が通じる相手だという印象につながる。

資格は、それ単体で受注を決める材料にはならない。ただし、事例が少ない段階では「学習を継続できる人」であることの傍証にはなる。事例が揃ってきたら、資格の記載は後ろに下げ、事例を前に出す構成に変えていく。順番を入れ替えるだけで、書類の印象は変わる。

もうひとつは、募集の文面を読み込むこと。依頼側が何を成果物と考えているかは、実際の募集を見るのが早い。ChatGPT活用・プロンプト設計のお仕事には求められる業務の実例が並んでおり、どの題材で事例を作るべきかの当たりが付く。マーケティングや情報管理と組み合わさった募集も増えているため、AI・マーケティング・セキュリティのお仕事も併せて見ておくとよい。

学習にかける費用は、この分野では抑えやすい。高額な講座に頼らなくても、公開されている手法の解説と、自分で走らせて確かめる時間があれば水準は上がる。むしろ費用をかけるべきは、検証を回すための実行環境のほうだ。

事例を、続けて手入れするための現実的なペース

事例集は作って終わりではない。とはいえ、受注しながら維持するには、無理のない頻度を決めておく必要がある。

現実的なのは、案件が1つ終わるたびに1本追記する運用だ。抽象化の作業は、記憶が新しいうちのほうが速い。終わった直後に、業務の種類、使った型、難所、限界を数行で書き留めておく。清書は後でよい。この下書きがあるかないかで、後から事例に仕立てる手間が大きく変わる。

もうひとつ、季節ごとに全体を見直す時間を取る。モデルが更新されて挙動が変わっている事例がないかを確認し、変わっていれば追記する。古い記述をそのまま残すより、「この時点ではこう動いたが、現在は挙動が変わっている」と書いたほうが、観察を続けている人だと伝わる。

見直しの際に、読まれていない事例を減らす判断もする。事例が増えすぎると、どれを読めばよいか分からなくなる。分野の近いものを統合するか、一覧から外して個別に案内する形に変える。数を誇る場所ではないため、減らす判断を恐れる必要はない。

副業として活動している場合、この維持作業をいつやるかを先に決めておくと続く。案件の合間に思い出したときだけ手を入れる運用は、たいてい止まる。

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

プロンプト設計は職種として新しく、条件の目安が定まっていない。自分の立ち位置を説明するときは、隣接する職種の相場観を借りると伝わりやすい。開発の要素を含む案件ならソフトウェア作成者の年収・単価相場が、文章の設計や編集の比重が高い案件なら著述家，記者，編集者の年収・単価相場が近い。事例集をどちらの色に寄せて作るかも、この判断と連動する。

海外の依頼者を視野に入れるなら、事例の見せ方も変わる。英語で読める形の要約を添えるだけで、届く範囲が広がる。国境をまたぐ受注の流れはUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で確認できる。

事例を、実際の案件につなげるまでの流れ

事例集は、作った時点では単なる資料でしかない。案件につながるのは、応募や提案の中で使われたときだ。流れとして整理しておく。

第一段階は、募集を読んで題材の近さを判断すること。完全に一致する事例は普通ないので、どの部分が重なるかを探す。出力の形式が同じ、扱うデータの性質が近い、例外の処理が似ている。1点でも重なれば、その事例を提示できる。

第二段階は、その募集向けの短い検証を足すこと。事例集の中身を再利用しつつ、募集文に書かれている業務に合わせて入力を作り直す。時間をかけずに、結果を数行で報告する形にする。ここまでやる応募者は多くないため、差が出る。

第三段階は、面談での深掘りに備えること。事例の中で自分が判断した箇所を、なぜそう決めたかまで言えるようにしておく。書いた本人でも、時間が経つと理由を忘れる。面談の前に自分の事例を読み返す時間を取る。

第四段階は、受注後に事例を更新すること。実案件を経ると、事例に書いた前提が現実とずれていた部分が見えてくる。その差分を追記すると、事例の説得力が上がる。ここまで回すと、案件と事例が互いを強くする循環になる。

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

在宅と業務委託の市場を長く運営してきた立場から見ると、実績の見せ方が上手い人には共通点がある。豪華な事例を持っているのではなく、読み手が何を知りたいかを想像して書いている。同じ案件を扱っていても、書き方ひとつで受け取られ方が変わる。

もうひとつ、長く続いている人ほど、限界を書くことを恐れていない。できないことを先に書いた資料のほうが、結果として仕事につながっている。依頼者は完璧な人を探しているのではなく、任せたときに何が起きるかを予測できる人を探している。

取引の形も関係する。中間のマージンが乗らない直接の取引では、依頼者は同じ予算でより多くを頼め、受け手は同じ仕事で手取りが厚くなる。手数料0%の構造が効いてくるのは、この関係が続いたときだ。実績の見せ方に手間をかけることは、単発の受注ではなく、続く関係を作るための投資になる。

よくある質問

Q. 守秘義務のある案件は、実績としてまったく出せないのですか？

固有名詞と数値を外し、業務の構造と設計の意図だけを残せば提示できる場合が多くあります。契約で守られているのは依頼者の情報とその案件固有の内容であり、身につけた設計手法そのものではないためです。ただし、業務内容と時期から特定される可能性があるなら載せないでください。判断に迷うときは、依頼者に「この粒度で紹介してよいか」を直接確認するのが確実です。

Q. 実案件がない場合、練習で作った事例でも通用しますか？

題材の選び方と設計の意図が説明できていれば十分に機能します。依頼者が見ているのは、業務を分解できるか、出力の良し悪しを言語化できるか、うまくいかない原因を切り分けられるかの3点で、これらは練習事例でも示せます。ただし練習であることは明記してください。実案件のように見せて後から分かるほうが、損失がはるかに大きくなります。

Q. 事例は何本くらい用意すればよいですか？

3本から5本で十分です。読み手は全部を読まないため、それ以上は選ぶ手間を増やすだけになります。1本目は自分がよく知っている業務で作り、2本目は違う型の業務、3本目以降は狙っている分野に寄せてください。一覧で業務の種類と使った型を1行にまとめておくと、読み手が詳しく読む事例を選べます。

Q. 事例に成果の数字を書いたほうがよいですか？

測定の条件を一緒に書けるときだけ書いてください。条件のない数字は疑われ、かえって信頼を下げます。何件を対象に、どの基準で評価し、いつ測ったのかを添えられないなら、数字は出さずに改善前と改善後の出力を並べて見せるほうが説得力があります。読み手が自分で追試できる形になっていれば、数字がなくても評価されます。

Q. 事例集はどこに置くのがよいですか？

リンクひとつで全体が読める場所であれば形式は問いません。記事として公開できる場所でも、共有できる文書ファイルでも構いません。応募のたびに資料を添付し直す運用は版がずれるので避けてください。更新の日付を入れ、モデルの更新で挙動が変わった部分は追記していくと、運用まで見ている人だという証明になります。