プロンプト設計のポートフォリオの作り方｜見る人が知りたいこと

2026年2月6日

丸山桃子

この記事のポイント

✓プロンプト設計ポートフォリオを
✓見る人の判断基準から逆算して作る手順をまとめました
✓1件分の構成テンプレート

プロンプト設計のポートフォリオで最初につまずくのは、「何を載せればいいのかわからない」という段階です。プロンプトそのものは短いテキストで、コードのように動くわけでも、デザインのように見た目で伝わるわけでもありません。結論から言うと、見る人が知りたいのはプロンプトの文面ではなく、そこに至るまでに何を決めたかです。この記事では、見る側の判断基準から逆算して、1件分の構成、載せる案件の選び方、置き場所の選択、作る順番までを整理します。

見る人が知りたいのは「作った物」ではなく「決めた理由」

ポートフォリオを開いた人が最初に探しているのは、この人に任せたときに何が起きるかという予測材料です。プロンプトの全文が並んでいても、その予測はできません。

最初に見られる場所

閲覧者の視線は、案件名、扱った課題、結果の順に動きます。プロンプト本体まで読み込まれるのは、そこまでの3点で興味を持たれた場合だけです。つまり、プロンプトの中身の質は、読まれる前に判断される要素によって左右されています。

この構造を知らずに作ると、プロンプトの推敲に時間を使い、案件名と課題の説明を一行で済ませてしまいます。順序としては逆で、課題の説明にこそ時間をかける必要があります。

プロンプト全文を並べても評価されない理由

プロンプトの文面だけを並べると、閲覧者は「これを他の用途にどう応用するのか」がわかりません。生成AIの出力は、同じプロンプトでも入力データやモデルの版によって変わります。文面が固定的な価値を持たないことは、実務経験のある閲覧者ほどよく知っています。

評価の対象になるのは、文面ではなくその文面にたどり着いた過程です。どんな出力を不合格としたのか、なぜその表現に変えたのか、変えた結果どう改善したのか。過程が書かれていれば、閲覧者は「別の課題でも同じように詰められる人だ」と判断できます。

見る人は3種類いる

閲覧者は大きく3種類に分かれ、それぞれ見る場所が違います。

企業の採用担当は、業務に耐えるかどうかを見ています。再現性、検証の有無、引き継ぎのしやすさが判断材料です。

発注側の実務担当は、自分の課題に近い事例があるかを探しています。業種や用途が一致する事例が1件でもあれば、それだけで問い合わせにつながります。

同業者は手法を見ています。直接の受注にはつながりにくいものの、紹介の経路になることがあります。

3種類すべてを1つの構成で満たそうとすると散漫になります。優先するのは、自分がこれから取りたい仕事の閲覧者です。実務案件を取りたいなら発注側の実務担当を、転職を考えているなら採用担当を軸に構成を決めます。

1件分の構成テンプレート

1件をどう書くかが決まれば、あとは横展開するだけです。構成は次の7項目に固定します。

課題と前提

最初に、誰の、どんな困りごとを扱ったかを書きます。「問い合わせ対応の一次返信に時間がかかっていた」「社内資料の要約の粒度が人によってばらついていた」といった具体性が必要です。

前提として、使えたデータの範囲、制約条件、期限も添えます。制約が書かれていると、閲覧者は「この条件下でここまでやったのか」と評価できます。制約を隠すと、成果が実力ではなく恵まれた環境の結果に見えてしまいます。

合格条件の定義

プロンプト設計で最も評価される項目がここです。何をもって「正しい出力」とするかを、着手前にどう定義したかを書きます。

たとえば「事実誤りがないこと」だけでは条件になりません。「参照した社内文書に書かれていない固有名詞を出力しないこと」「回答の末尾に参照元の見出し名を必ず含めること」というレベルまで落とし込んで、はじめて検証できる条件になります。この定義を書ける人は多くないため、ここが差別化の中心になります。

初版と改訂の差分

初版のプロンプトと、最終版の差分を示します。全文を並べる必要はなく、変更した箇所と変更の理由を対で書けば十分です。

差分の見せ方は、変更前、変更後、変更の理由、変更後に起きた変化、の4列の表が扱いやすい形です。表にすると閲覧者は数秒で改善の筋道を追えます。

テストの設計と結果

どんな入力パターンでテストしたか、何件試したか、合格率がどう推移したかを書きます。件数は自分が実際に実行した数字だけを書き、盛らないことが前提です。

テストケースの作り方そのものも見どころになります。想定内の入力だけでなく、空欄、極端に長い入力、指示に反する内容を含む入力など、崩しにいったケースを載せると評価が上がります。

失敗ケースと回避策

うまくいかなかったケースを載せるのは勇気が要りますが、載せたほうが信頼されます。実務では必ず失敗が出るため、失敗を書いていないポートフォリオは「検証していない」か「隠している」のどちらかに見えます。

書き方は、どんな入力で崩れたか、なぜ崩れたか、どう回避したか、回避しきれなかった限界は何か、の順です。最後の限界を明記できる人は、運用を任せても事故を起こしにくいと判断されます。

運用への引き渡し方

作って終わりではなく、依頼側が運用できる状態にどう渡したかを書きます。手順書を作った、担当者向けに調整の範囲を決めた、監視する指標を設定した、といった内容です。この項目があると、単発の作業者ではなく仕組みを渡せる人として読まれます。

再現できる形での提示

読んだ人が自分の環境で試せる形にしておくと、説得力が跳ね上がります。入力例、期待される出力例、実際の出力例の3点セットを置いておくのが最小構成です。

課題の書き方で読まれるかどうかが決まる

7項目のうち、最初の課題の書き方だけは特に丁寧に扱う価値があります。ここが弱いと、以降がどれだけ充実していても開かれません。

主語を業務側に置く

「ChatGPTを使って要約するプロンプトを作った」と書くと、主語が道具になります。読み手が知りたいのは道具ではなく業務です。「週次の議事録を役員向けに要約する工程が属人化していた」と書けば、同じ悩みを持つ人が反応します。

主語を業務側に置くだけで、検索から流入する語も変わります。道具名で探している人より、業務の困りごとで探している人のほうが、依頼に近い位置にいます。

数字を使うなら自分が測ったものだけにする

課題の説明に数字を入れると具体性が上がりますが、使ってよいのは自分が実際に測った値だけです。伝聞や推測を数字にすると、突っ込まれたときに答えられません。測っていないなら「毎回やり直しが発生していた」といった定性的な表現で構いません。

解決しなかった部分も書く

課題のすべてが解決することは、実務ではまずありません。どこまでを解決し、どこからは範囲外としたのかを書いておくと、判断の妥当性が伝わります。全部解決したと書かれている事例は、実務を知る人ほど疑って読みます。

載せる案件の選び方

件数を増やすことより、用途の幅を示すことが優先されます。

数より用途の幅

似た案件を並べても、閲覧者が得る情報は増えません。3件載せるなら、生成系、分類系、抽出系のように性質の違う用途をそろえたほうが、対応できる範囲が伝わります。

用途の幅が伝わると、閲覧者は自分の課題を当てはめて考えられます。逆に、同じ業種の同じ用途ばかりだと「これしかできない人」と読まれます。

守秘義務のある仕事の扱い

実務案件は多くの場合、内容を公開できません。ここで止まってしまう人が多いのですが、公開できないのは固有名詞と実データであって、手法と構造ではありません。

対処法は3つあります。第一に、依頼側に許可を取り、抽象化した形での掲載を認めてもらう。第二に、業種と規模だけを示し、具体名を伏せる。第三に、同じ構造を持つ架空の課題を自分で作り直して、そちらを公開する。3つ目は手間がかかりますが、権利関係の心配がなく、説明も自由にできます。

いずれの場合も、契約書の秘密保持条項を先に確認します。NDA（エヌディーエー）を結んでいる場合、抽象化しても掲載自体が禁止されていることがあります。

自主制作の扱い方

実務案件がない段階では、自主制作で構成します。ただし「試しに作ってみた」レベルだと評価されません。実在する困りごとを設定し、合格条件を定義し、テストを回すところまでやれば、実務案件と同じ構成で書けます。

題材の選び方は、自分が実際に困っていることが最も適しています。日々の作業のどこかで手間取っている工程を1つ選び、それを解決する形にすると、課題設定が具体的になります。

作る手順

順番を決めておくと、途中で止まりにくくなります。

手順1　棚卸しをする

これまでに触った生成AI関連の作業を、規模を問わず書き出します。仕事で使ったもの、趣味で試したもの、学習中に作ったもの、すべてを対象にします。この段階では取捨選択をせず、量を出すことに集中します。

手順2　1件だけを完成形まで書く

書き出した中から1件選び、前述の7項目をすべて埋めます。ここで妥協すると、以降の全件が同じ粒度で薄くなります。1件に時間をかけて型を作るのが結果的に最短です。

手順3　型を横展開する

型ができたら、残りは埋めるだけの作業になります。同じ見出し構成をコピーして、内容を差し替えていきます。この段階では新しい書き方を考えないことが重要で、構成が揃っていること自体が読みやすさになります。

手順4　入口を整える

最後に、一覧ページと自己紹介を整えます。一覧には、案件名、用途の種別、扱った課題を1行ずつ並べます。閲覧者が目当ての事例に 10秒以内でたどり着ける状態が目標です。

置き場所とツールの選び方

ツールは目的から決めます。凝った作りが評価を上げるわけではありません。

ドキュメント共有ツール

最も手早い方法です。文書作成ツールやノート系サービスで作り、公開リンクを渡します。更新が容易で、構成の試行錯誤がしやすい点が利点です。難点は、検索から見つけてもらいにくいことと、権限設定を誤ると非公開のまま気づかないことです。

独自のサイトを構築する

開発経験がある場合は、自分でサイトを組む選択肢があります。情報の管理と表示を分離した構成そのものが、技術力の証明になるという見方もあります。

ある程度開発経験がある場合は、Notionをデータベースとして使い、Next.jsという最新のWebフレームワークで独自のポートフォリオサイトを作ってみましょう。情報の管理と表示をシステムで分ける構成は、Web開発の基本が身についている証明になります。出典: job.tracks.run

ただし、開発経験がない状態でサイト構築から始めると、中身を書く前に力尽きます。優先順位は常に中身が先です。ツール選びに迷っている段階なら、まずドキュメント共有ツールで1件書き切ってください。

コード管理サービスを併用する

テストコードや実行スクリプトがある場合は、コード管理サービスに置いて、ポートフォリオ本体からリンクします。実行できる形で置いてあると、技術的な検証を重視する閲覧者には強く働きます。

初心者が最初の1件を作る順番

実績ゼロの状態からでも、1件は作れます。作業は次の流れです。

まず、身近な反復作業を1つ選びます。定型メールの下書き、会議メモの要約、商品説明文の草案作成など、毎回同じ手順で行っている作業が向いています。

次に、その作業の合格条件を書き出します。何が入っていれば合格で、何が入っていたら不合格か。この時点で、条件が曖昧にしか書けないことに気づくはずです。曖昧さを潰す作業が、そのままプロンプト設計の中身になります。

続いて、テスト用の入力を 10件ほど用意します。典型例だけでなく、崩れそうな例を混ぜるのが要点です。初版のプロンプトで実行し、不合格になったケースを分類します。

最後に、分類した失敗の原因ごとに改訂を加え、再テストします。改訂の履歴をそのまま記録しておけば、それが差分の資料になります。実務案件を持っていなくても、この過程を書けば1件分として成立します。

分野ごとの実務がどんな内容なのかを掴んでおくと、題材選びの精度が上がります。ChatGPT活用・プロンプト設計のお仕事には、実際に発注される作業の種類が整理されており、自主制作の題材を実務に寄せる際の参考になります。関連する分野をまとめて見たい場合は、AI・マーケティング・セキュリティのお仕事も併せて確認しておくとよいでしょう。

学習の途中経過も素材になる

実績が少ない段階では、学習の過程そのものを素材にできます。ただし、教材をなぞった記録を並べるだけでは意味がありません。

途中でつまずいた箇所と、それをどう解消したかを書けば、それは検証の記録になります。「指示を細かくするほど出力が安定すると考えていたが、条件を増やしすぎると無関係な制約に引きずられるようになった」といった気づきは、実際に手を動かした人にしか書けません。

日々の試行を残しておく習慣があると、後から素材に困りません。試したプロンプト、そのときの出力、うまくいかなかった点を1行ずつ残すだけで十分です。清書は後からできますが、そのときの判断は後からは復元できません。

今日、あなたがAIを使って解決した些細な悩み。それを「なぜ解決できたのか？」と言語化するところから始めてみましょう。小さな一歩の積み重ねが、最強のポートフォリオ、そして最高の内定へと繋がっています。応援しています！出典: job.tracks.run

言語化を後回しにすると、経験の量に対して書けることが極端に少なくなります。この差は、経験年数では埋まりません。

避けたほうがよい作り方

よく見かける失敗を挙げます。

生成結果の画像を並べるだけ

出力結果のスクリーンショットを大量に貼っただけの構成は、評価につながりません。閲覧者から見ると、それが1回目で出たのか、20回試して選んだのかが判別できないためです。過程の記述がないスクリーンショットは、証拠として機能しません。

秘密情報が混入している

抽象化したつもりでも、社内システムの名称、担当者名、独自の業務用語が残っていることがあります。公開前に、固有名詞を機械的に検索して確認してください。この確認を怠ると、能力の評価以前に取引先としての適格性を疑われます。

更新されないまま放置される

生成AIは仕様の変化が速く、古い記述は不利に働きます。特にモデル名や機能の記述は、時間が経つと事実と合わなくなります。四半期に一度は全体を読み返し、事実と異なる箇所を直す運用を決めておきます。

誇張した表現で埋める

「劇的に改善」「圧倒的な精度」といった形容は、検証の記録がある文章の中では浮きます。数字や事例で裏づけられない形容詞は、書けば書くほど全体の信頼を下げます。改善したなら、何がどう変わったかを書けば足ります。

分量を増やしすぎる

案件数を増やせば増やすほど良いわけではありません。閲覧者が全部読むことはなく、粒度の低い事例が混ざると全体の印象が下がります。厳選した数件のほうが、雑多な十数件より強く働きます。

一覧ページの設計で読まれる量が変わる

個々の事例を丁寧に書いても、一覧の設計が悪いと中まで読まれません。入口の作りは中身と同じくらい効きます。

1行で判別できる形にする

一覧に並べる1行には、用途の種別、対象の業種または場面、扱った困りごとの3要素を入れます。「分類｜問い合わせメールの一次振り分け｜担当者ごとに基準がばらついていた」という粒度です。

この形にしておくと、閲覧者は自分の課題に近い行だけを開きます。逆に、案件名だけを並べた一覧は、開くかどうかの判断材料がないため素通りされます。

並び順は新しい順にしない

作成日の新しい順に並べるのは、書き手の都合です。閲覧者にとっては、代表的な事例が先頭にあるほうが有益です。自分が最も取りたい種類の仕事に近い事例を先頭に固定し、残りを種別ごとにまとめます。

並び順を固定すると、更新のたびに順番が入れ替わらないため、以前見た人が再訪したときにも目的の事例を見つけやすくなります。

自己紹介は経歴ではなく守備範囲を書く

自己紹介の欄に経歴を時系列で書いても、閲覧者の判断は進みません。書くべきは、対応できる範囲と、対応できない範囲です。「業務文書の生成と要約を主に扱っている」「画像生成の分野は扱っていない」というように、境界を明示します。

できないことを書くと機会を逃すように思えますが、実際には逆で、範囲が明確な相手のほうが声をかけやすくなります。範囲が不明な相手には、そもそも問い合わせが来ません。

公開する前に他人に読んでもらう

自分で書いた文章は、前提が共有されている想定で読んでしまうため、抜けに気づけません。公開前に第三者に読んでもらう工程を挟みます。

読んでもらう相手を分けて選ぶ

同業者と、その分野を知らない人の両方に読んでもらうのが理想です。同業者は手法の妥当性を、門外漢は説明の飛躍を指摘してくれます。門外漢が読んで「何をした人なのかわからない」と言うなら、発注側の実務担当にも伝わっていません。

聞く質問を決めておく

漠然と「どうですか」と聞くと、感想しか返ってきません。聞く内容は3つに固定します。この人に何を頼めそうか、読んでいて詰まった箇所はどこか、信用できないと感じた記述はあるか。

3つ目が特に重要です。誇張と受け取られた記述は、書き手には見えません。指摘されたら、根拠を足すか、記述自体を削ります。

指摘の反映は取捨選択する

すべての指摘を反映すると、文章の軸がぶれます。反映するのは、複数の人から同じ指摘が出た箇所と、事実に関する指摘です。好みの問題については、自分の判断を優先して構いません。

更新を続けるための運用

ポートフォリオは作った時点が完成ではなく、そこから劣化していきます。劣化を止める運用を決めておきます。

案件が終わった週に書く

記憶が新しいうちに書くのが最も効率的です。案件が終わってから時間が経つほど、判断の理由を思い出せなくなります。終わった週のうちに、課題、合格条件、テスト結果、失敗ケースの4点だけでもメモに残しておけば、後から整形するだけで済みます。

記述の鮮度を定期的に確認する

生成AIの分野は仕様の変化が速く、モデル名や機能に関する記述はすぐ古くなります。3か月ごとに全体を読み返し、事実と異なる箇所を直す日を決めておきます。古い記述が残っていると、情報を追っていない人だと判断されます。

反応を見て構成を直す

問い合わせが来た場合、どの事例を見て連絡したのかを聞いておきます。反応のある事例と、まったく触れられない事例が見えてくれば、構成を組み替える材料になります。閲覧数の統計が取れるツールを使っているなら、滞在時間の長いページを先頭に寄せるのも有効です。

転職と案件応募で見せ方を変える

同じ素材でも、提出先によって強調する場所が変わります。

転職の選考では、チームでの働き方に関する記述が効きます。仕様をどう合意したか、レビューをどう受けたか、引き継ぎをどうしたか。組織の中で動けるかどうかが判断されるためです。

案件への応募では、課題と結果の対応関係が効きます。発注側は自分の課題に近い事例を探しているので、業種と用途を先頭に置いて、該当するかどうかを即座に判断できる形にします。

独立して仕事を取っていく形を検討している場合は、UI/UXデザインのフリーランスになるには？必要スキルと案件相場のような他職種の独立事例も参考になります。成果物の見せ方という課題は職種を超えて共通しており、隣接分野の作法から学べる部分は少なくありません。

スキルと資格をどう書くか

スキル欄は、扱えるツール名の列挙で終わらせないことが要点です。ツール名は誰でも書けるため、差がつきません。

書くべきは、どのツールで何ができるかの粒度です。「特定のモデルの出力揺れを抑える設定の勘所を把握している」「検証用のデータセットを自分で設計できる」といった記述のほうが、ツール名の羅列より情報量があります。

資格については、業務文書の作成能力を示すビジネス文書検定のように、仕事の進め方を裏づけるものが役立つ場面があります。ネットワークやインフラの理解を示すCCNA（シスコ技術者認定）のような技術系の資格も、システム連携を伴う案件では意味を持ちます。ただし、資格そのものが評価の中心になることは少なく、あくまで補助です。ポートフォリオの中身が薄い状態で資格だけ並べても、判断は変わりません。

独自データの考察：見せ方より、書ける仕事をしているかが先に出る

在宅ワークと業務委託の市場を20年見てきた立場から言えば、ポートフォリオの見栄えと受注のしやすさは、思われているほど強く結びついていません。凝ったサイトを持っている人が有利かというと、そうでもない。むしろ差が出るのは、書ける中身を持っているかどうかです。

仕事の進め方が場当たり的だと、後からポートフォリオにまとめようとしても書くことがありません。合格条件を決めずに作り、テストを記録せずに納品していれば、残るのは最終成果物だけです。逆に、日々の仕事で条件を定義し、テストを記録し、失敗を分類している人は、既にポートフォリオの素材を持っています。作る作業は転記に近くなります。

もうひとつ、額面と手取りの関係も触れておきます。仲介を挟む経路では、依頼側が支払った金額から一定割合が引かれてから受け手に届きます。手数料0%で直接やり取りできる場では、同じ予算で依頼側はより多くを頼め、受け手の手元に残る額も厚くなります。ポートフォリオを整える目的は、この直接の関係に入る入口を自分で作ることにあります。誰かの検索結果に自分が現れる状態を持っておくと、条件の話が最初から対等になります。

技術系の仕事がどのような労働市場に位置しているかは、ソフトウェア作成者の年収・単価相場のような統計から把握できます。プロンプト設計は職種としては新しいものの、評価の構造は既存の専門職と大きく変わりません。何を決めたかを説明できること、決めた結果を検証していること、他人が引き継げる形で残していること。この3つが揃っている記録は、形式がどうであれ読む人に伝わります。

よくある質問

Q. 実務案件がない状態でもポートフォリオは作れますか？

作れます。身近な反復作業を1つ選び、合格条件を書き出し、テスト用の入力を10件ほど用意して初版を実行し、不合格ケースを分類して改訂する。この過程を記録すれば実務案件と同じ構成で書けます。重要なのは案件の出所ではなく、条件を定義して検証した痕跡が残っているかどうかです。試しに作った程度の内容では評価されません。