AIチャットボット開発のポートフォリオの作り方｜見る人が知りたいこと

AIチャットボット開発のポートフォリオで何を見せるべきか。結論から言うと、動くデモそのものではなく「なぜその作りにしたのかという判断の記録」です。チャットボットは、画面を見ただけでは作り手の力量が伝わりにくい成果物という特徴があります。どれだけ精度の高い応答を実装しても、画面上は吹き出しが並ぶだけ。だからこそ、見る人が知りたいのは結果ではなく過程になります。この記事では、実案件を担当したあとにポートフォリオを整える手順を、守秘義務の扱いから掲載の型まで具体的に整理します。

ポートフォリオを見ている人は誰で、何を確認しているのか

見る人は大きく3種類に分かれる

ポートフォリオの読み手は3種類に分類できます。技術がわかる人、技術はわからないが発注の決裁をする人、そして両者の間に立つ窓口の担当者です。この3者は、まったく違うものを見ています。

技術がわかる人は、実装の選択理由を見ます。なぜその構成にしたのか、代わりの案を検討したのか、失敗したときにどう戻すのかまで気にします。決裁をする人は、自社の課題と近いかどうかだけを見ています。技術的に高度かどうかは判断できないので、業種や業務の近さで判断します。窓口の担当者は、話が通じる相手かどうかを見ています。専門用語ばかりの記述だと、社内に説明できないという理由で候補から外れます。

正直なところ、多くのポートフォリオは技術がわかる人だけに向けて書かれています。これはどうかと思います。実務で声がかかるかどうかを左右するのは、残りの2者であることのほうが多いからです。同じ1件を、3つの読み方に耐える形で書くのが最初の設計になります。

最初に見られる時間は短い

ポートフォリオが最初に開かれてから、続きを読むかどうかが決まるまでの時間は非常に短いという傾向が見られます。ここで判断されるのは内容の深さではなく、探しているものがありそうかどうかです。

したがって、冒頭には作品の一覧ではなく、扱える領域の一覧を置きます。社内問い合わせの自動応答、ECの購入前相談、予約受付、社内文書の検索。この粒度で並べておくと、読み手は自分の課題と照合できます。制作物のタイトルだけを並べたページは、読み手に翻訳作業を強いる形になります。

動くデモは「あれば良い」であって必須ではない

デモを用意できれば有利ですが、必須ではありません。むしろ、雑に動くデモは逆効果になることがあります。想定外の質問に変な答えを返す様子を見せてしまうと、それが実力の印象として残ります。

デモを置く場合は、試せる範囲を明示します。「社内規程の問い合わせに答える想定で、こういう質問に答えられます」と例を並べ、範囲外については答えない設計にしておく。範囲を絞る判断そのものが、実務の理解を示す材料になります。何でも答えようとするデモより、答えない範囲を決めているデモのほうが評価されます。

実案件を守秘義務の範囲内で掲載する手順

出せるものと出せないものを分ける

受注した案件をそのまま載せることは、ほとんどの場合できません。ただ、載せられない部分と載せられる部分を分けて考えると、掲載できる情報は思ったより多く残ります。

出せないのは、発注者名、システムの内部構成の詳細、社内文書の実物、利用者の実データ、そして契約に関わる条件です。一方で、業種の分類、扱った業務の種類、設計上の課題、その課題にどう対処したか、振り返って何を変えるかという考察は、抽象化すれば出せます。契約書に守秘義務条項がある場合でも、対象は「業務上知り得た情報」であって、自分が考えた設計方針そのものではないのが一般的です。とはいえ、判断に迷ったら出さないのが原則です。

抽象化の具体的な手順

抽象化は感覚でやるとぶれます。次の順序で機械的に処理します。

まず固有名詞を業種の一般名に置き換えます。企業名は「従業員規模が中程度の製造業」のような形にします。次に、システム名や製品名を役割の記述に置き換えます。「特定の顧客管理システム」ではなく「営業部門が使っている顧客管理の仕組み」と書く。三番目に、数値を性質の記述に置き換えます。件数や金額を出さず、「想定質問の分類が細かく分かれていた」のように傾向で書きます。最後に、時系列を丸めます。特定の月や期間が特定につながることがあるためです。

この手順を通したあと、発注者本人が読んで自社だと特定できるかを自分で確認します。特定できるなら抽象化が足りていません。

掲載の許可を取るときの伝え方

可能であれば、許可を取るのが最も安全です。許可を求めるときは、掲載したい内容を先に文章にしてから見せます。「実績として載せてよいですか」という抽象的な依頼は、判断できないので断られやすい。掲載予定の文面をそのまま提示し、社名も具体的な仕様も出していないことを示すと、承諾されやすくなります。

断られた場合は、そこで止めます。粘るとその後の関係に影響します。断られた案件は、そこで得た知見だけを自主制作の題材として再現し、自主制作として掲載する道があります。

掲載する1件をどう書くか

5つの項目でそろえる

1件あたりの記述は、次の5項目でそろえると読み手が比較しやすくなります。課題、制約、判断、結果、振り返りです。

課題では、誰が何に困っていたかを書きます。制約では、使えるデータの状態、期限、社内の体制など、選択肢を狭めていた条件を書きます。判断では、複数あった選択肢のうちどれを選び、なぜ他を選ばなかったかを書きます。結果では、何が変わったかを書きます。振り返りでは、いま同じ案件を受けたら何を変えるかを書きます。

この中で最も読まれるのは判断と振り返りです。判断は再現性のある能力を示し、振り返りは学習の姿勢を示します。結果だけを並べたポートフォリオは、たまたま上手くいっただけの可能性を排除できません。

会話設計をどう見せるか

会話設計は、図で見せるのが最も速い。想定質問の分類、分岐の構造、答えない場合の逃がし方。この3つを1枚の図にまとめます。図が用意できない場合は、代表的な会話の流れを文章で再現します。

見せる価値が高いのは、うまくいった会話ではなく、想定外の質問に対する処理です。「わからないときに何と答えるか」「担当者につなぐ条件は何か」を決めていることは、業務を理解している証拠になります。ここを設計していないチャットボットは、公開後に必ず問題になります。

データ整備と評価の仕組みを見せる

社内文書を読み込ませる形の開発では、前処理の設計が品質を左右します。表記ゆれをどう統一したか、古い版をどう除外したか、矛盾する記述をどう扱ったか。この記述があると、実案件を経験しているかどうかが一目でわかります。

評価についても同様です。回答の正しさをどう判定したか、判定の基準を誰が決めたか、基準を下回ったときにどう直したか。評価の仕組みを持っている作り手は多くありません。ここを書けるだけで、他の候補と明確に差がつきます。AIの業務活用を支援する仕事が実際にどのような工程で構成されているかは、AIコンサル・業務活用支援のお仕事に職種としての整理があります。自分の担当範囲を説明する言葉を探すときの参考になります。

使った技術は列挙ではなく理由とセットで

技術の一覧をタグのように並べるだけの記述は、情報量がほとんどありません。「この用途にはこれを選んだ、理由はこうだ」という形にすると、同じ文字数で伝わる内容が大きく変わります。

たとえば、応答の生成に外部の仕組みを使うか自前で用意するかは、扱うデータの機密度と更新頻度で判断が分かれます。この判断過程を書くと、技術がわかる読み手には実力が伝わり、技術がわからない読み手にも「条件を考えて選んでいる人だ」という印象が残ります。

実案件がない段階で何を作るか

題材は自分の周辺から選ぶ

自主制作の題材選びで最も多い失敗は、汎用的で大きな題材を選ぶことです。何でも答える相談相手のようなものを作っても、評価の基準がないので出来を示せません。

良い題材の条件は3つあります。想定利用者が具体的であること、正解が確認できること、そして自分がその業務を理解していることです。所属していた業界の業務、家族が働いている職場の困りごと、自分が繰り返し調べている手続き。この範囲から選ぶと、想定質問がリアルになります。

制作の動機を素直に語ることにも価値があります。次のような記述は、作り手の姿勢を示す例として参考になります。

そこで、どうせやるのであれば、AIを取り入れたポートフォリオサイトを作りたいと思いました。 単なる静的な情報提供を超えて、AIが代わりに答えることで動的で面白い体験を提供したいと考えたからですね。まだ回答の正確性や充実性を向上させる課題はありますが、誰かにインスピレーションや楽しい体験を与えられるウェブサイトへと成長させたいと考えています。 出典: zenn.dev

課題が残っていることを書いている点が重要です。完成していると主張するより、現時点の限界を把握していると示すほうが、実務の読み手には信頼されます。

志望する領域に寄せすぎない

案件の傾向に合わせて作品を選ぶことは有効ですが、寄せすぎる必要はありません。次の指摘は、ポートフォリオの構成を考えるうえで参考になります。

これらを踏まえることで、企業が求める人材像や希望する技術と、ポートフォリオをマッチングできます。 ただし、ポートフォリオは自分のスキルや経験を掲載するものです。必ずしも志望企業によせすぎる必要はなく、自分の趣味で作った制作物なども掲載してよいです。 出典: career.levtech.jp

趣味で作ったものが効くのは、そこに熱量と継続の記録が出るからです。業務では選ばない題材に取り組んだ記録は、学習の速度を示す材料になります。

やりがちな失敗

自主制作でよく見る失敗を挙げます。ひとつ目は、作っただけで公開していないこと。動く形で触れないと、読み手は判断できません。ふたつ目は、想定利用者を決めずに作ること。誰のためのものかが書かれていないと、設計の良し悪しを評価できません。三つ目は、失敗した部分を消してしまうこと。うまくいかなかった実装と、その原因の分析は、成功例と同じくらい読まれます。

技術と学習の裏づけをどう並べるか

学び方の記録も掲載材料になる

技術をどう身につけたかという記録は、経験が浅い段階ほど効きます。何を読み、何を試し、どこでつまずいたか。この履歴があると、読み手は今後の伸び方を推測できます。次の指摘は、経験の段階によって見せ方を変える必要があることを示しています。

技術習得にはオンライン講座や書籍などを活用し、基礎から応用まで効率的に学ぶことをおすすめします。 経験者の場合、必ずしも技術を転職先の企業に合わせる必要はありません。自分のスキルをアピールできる作品があれば、積極的にポートフォリオに掲載しましょう。 出典: career.levtech.jp

経験が浅い段階では学習の道筋を、経験を積んだ段階では判断の記録を前に出す。この切り替えができていないポートフォリオは多く、経験を積んだあとも学習履歴だけが並んでいる例がよく見られます。

資格をどう位置づけるか

資格は、単独では判断材料になりません。ただし、社内システムとの連携を伴う案件では、基礎知識の裏づけとして機能する場面があります。発注側の情報システム部門と話すとき、共通の語彙があるかどうかで確認のやり取りの回数が変わるからです。ネットワークやインフラの基礎を扱うCCNA（シスコ技術者認定）のような領域は、社内ネットワークの内側で動かす前提の案件で話の速度に効いてきます。

掲載するときは、取得したという事実だけでなく、その知識が実務のどの場面で使えたかを1文添えます。この1文があるかないかで、読み手の受け取り方はまったく変わります。

提案の場でポートフォリオをどう使うか

全部を見せない

商談や応募の場で、ポートフォリオ全体を見せる必要はありません。相手の課題に近い1件から2件を選び、そこだけを開きます。全体を見せると、関係のない作品に目が行き、話の焦点がぼやけます。

そのためには、作品に検索しやすい見出しをつけておく必要があります。「社内規程の問い合わせに答える仕組み」「購入前の質問に答える仕組み」のように、業務の言葉で名前をつける。技術名で名前をつけると、相手の課題と結びつきません。

想定される質問を先回りする

提案の場でよく出る質問は決まっています。既存のシステムとつなげるか、社内のデータを外に出さずに動かせるか、公開後の運用を誰がやるか、間違った答えを返したときにどうするか。この4つには必ず備えます。

ポートフォリオの各作品に、この4項目への答えを1行ずつ添えておくと、その場で答えられます。答えられるかどうかは知識の量ではなく、準備の有無で決まります。AI関連の領域は業務の周辺分野との境目が曖昧で、AI・マーケティング・セキュリティのお仕事で扱われる範囲まで質問が及ぶこともあります。自分がどこまで見られてどこから外部に相談するかを、あらかじめ決めておくと会話が安定します。

断る材料としても使う

ポートフォリオは受注のためだけの道具ではありません。扱わない領域を明記しておくと、合わない依頼が減ります。「医療や法律の判断に関わる回答は扱わない」「個人情報を扱う設計は別途相談」といった記述を置く。断る手間が減るだけでなく、専門の範囲を決めている相手として信頼されます。

置き場所と見せ方を決める

どこに置くか

置き場所は、専用のページを作る方法と、記事や公開リポジトリを並べる方法があります。どちらでも構いませんが、URLが1つに定まっていることが重要です。複数の場所に散らばっていると、読み手はすべてを追いません。

専用ページを作る場合、構成は単純にします。扱える領域の一覧、掲載作品の一覧、1件ごとの詳細、連絡先。この4つで足ります。凝った演出は、内容を確認したい読み手にとって障害になります。文書としての読みやすさを整える力そのものが評価の対象になる場面もあります。見出しの立て方、1段落の長さ、専門用語に補足を添えるかどうか。こうした基本の作法は、そのまま納品する説明資料の品質として受け取られます。

画面の見せ方

画面の画像を載せる場合、全体像を1枚と、注目してほしい箇所を切り出した1枚を組にします。全体像だけだと細部が読めず、切り出しだけだと文脈がわかりません。画像には短い説明を必ず添えます。説明のない画像は、読み手にとって解読作業になります。

会話の流れを見せるときは、実際の画面ではなく文字起こしのほうが読みやすい場合があります。吹き出しの画像は縦に長くなり、比較しづらいためです。目的は見た目を伝えることではなく、設計の意図を伝えることだと考えると、形式の選び方が決まります。

デモを公開するときの現実的な注意

デモを常時公開する場合、利用のたびに費用が発生する構成であれば、上限を設けておく必要があります。悪意のある大量アクセスで想定外の請求が発生する事例があるためです。利用回数の制限、入力の長さの制限、公開範囲の限定。この3点は最低限の備えになります。

また、公開したデモに個人情報を入力される可能性も考えます。入力内容を保存しない設計にするか、保存する場合はその旨を明示します。この配慮を書いておくこと自体が、実務を理解している証明になります。

更新の頻度と履歴

ポートフォリオは作って終わりではありません。更新の履歴が残っていると、継続して手を動かしていることが伝わります。逆に、最終更新が何年も前のままだと、現在の状態が読めません。

更新は大がかりでなくてよい。1件の作品に振り返りを追記する、新しく試した仕組みの所感を追加する、この程度で十分です。開発の仕事がどのような広がりを持つのかはアプリケーション開発のお仕事にまとまっており、自分の掲載内容がどの領域に寄っているかを確認する材料になります。

記述でよく起きるずれを直す

主語が抜けて誰の判断かわからなくなる

複数人で進めた案件を書くとき、自分が担当した範囲が曖昧になりがちです。「構成を検討し、実装した」と書かれていても、検討に加わっただけなのか、方針を決めたのかで意味がまったく違います。担当範囲は必ず明記します。全体の設計は別の人が決め、自分は会話設計とデータ整備を担当した、と書いても評価は下がりません。むしろ、範囲を正確に書ける人のほうが信頼されます。

成果を大きく書きすぎる

効果を強調しすぎると、確認された瞬間に信頼を失います。測っていない数字は書かない。測った数字でも、測り方を添えられないものは書かない。この2つを守るだけで、記述の信頼度は安定します。効果が測れていない案件は、測れていないと書いたうえで、次はどう測るかを書けば十分に評価されます。

古い前提のまま放置する

AI関連の領域は前提が変わる速度が速く、1年前に妥当だった構成が現在では選ばれないこともあります。掲載した作品には、いつ時点の判断かを明記します。日付があれば、古い構成であっても当時の妥当な判断として読まれます。日付がないと、現在の判断力として読まれてしまいます。

読み手の環境を想定していない

商談の場では、スマートフォンで開かれることがあります。図が読めない、表が横に切れる、デモが動かない。この状態だと、内容以前に話が止まります。公開したら、必ず小さい画面で自分で開いて確認します。これは5分で終わる作業ですが、実施していない例が非常に多い部分です。

ポートフォリオを整えることの利点と負担

得られるもの

最も大きな利点は、案件の説明が速くなることです。商談の場で口頭で説明する代わりに、該当する1件を見てもらえば済むようになります。話が早く進むだけでなく、認識の食い違いも減ります。

もうひとつ、自分の判断を言語化する訓練になります。判断の理由を書く作業を繰り返すと、次の案件で選択肢を検討する精度が上がります。ポートフォリオは対外的な資料であると同時に、自分の作業記録でもあります。

負担になる部分

デメリットも見ておきます。作成と維持には時間がかかります。特に、実案件の抽象化には手間がかかり、許可を取る場合は相手の時間も使います。また、公開したデモを維持する場合、費用と保守の手間が継続的に発生します。

したがって、掲載する作品は絞ります。数を増やすより、1件あたりの記述を厚くするほうが結果につながる傾向があります。多数の作品を薄く並べたページは、どれも印象に残りません。

掲載を始める前に手元の材料を棚卸しする

ポートフォリオが進まない理由の多くは、書く材料がないことではなく、材料が散らばっていて見えていないことです。書き始める前に、手元にあるものを一度並べます。

過去のやり取りから判断の記録を拾う

担当した案件のやり取りには、判断の記録が残っています。仕様を決めた際のメッセージ、質問への回答、変更を相談した文面。ここに、なぜその作りにしたのかという理由が書かれています。記憶から書き起こすと理由が単純化されますが、当時のやり取りを見ると、実際には複数の条件を天秤にかけていたことが分かります。

拾うときは、日付と、そのとき決めたこと、決めた理由の3つをメモに落とします。この段階では抽象化しません。抽象化は掲載する文面を作るときに行い、手元のメモは事実のまま持っておきます。抽象化した文面だけを残すと、後から掲載の許可が取れたときに元の情報に戻れません。

途中で捨てた実装も材料になる

方針を変えて捨てた実装は、掲載の材料になります。なぜ捨てたかを書けるからです。捨てた理由は、そのまま判断の基準の説明になります。

ただし、捨てたものを作品として並べるのではありません。採用した1件の記述の中に、「この方式も検討したが、この条件で外した」という形で入れます。並べると数だけ増えて、どれが本命か分からなくなります。

掲載の優先順位をつける

材料が並んだら、掲載する順番を決めます。優先されるのは、想定する読み手の課題に近い案件、判断の記録が厚く残っている案件、公開の許可が取れる見込みがある案件です。この3つを満たすものから着手すると、1件目が早く仕上がります。

すべてを同時に進めると、どれも中途半端なまま止まります。1件を完成させてから次に移るほうが、結果として掲載できる数は増えます。1件目が完成すると、2件目以降は同じ5項目に当てはめるだけになるので、作業の速度が上がります。

応募文とポートフォリオの役割を分ける

応募や商談の場では、応募文とポートフォリオの両方を出すことになります。この2つの役割を混ぜると、どちらも中途半端になります。

応募文に書くのは、相手の募集内容に対して自分がどう合致するかです。ポートフォリオに書くのは、自分が何をどう判断してきたかです。応募文で作品の説明を長々と書くと、ポートフォリオを開く理由がなくなります。逆に、応募文で何も説明せずにURLだけを貼ると、開かれません。

実務的な形は、応募文で該当する1件を名指しして、そこで何を担当したかを2文で書き、詳細はポートフォリオの該当箇所を見てもらう構成です。URLは作品ごとの位置に直接飛べる形にしておきます。入口のページに飛ばすと、相手が探す作業をすることになり、そこで離脱します。

募集内容に自分の経験が完全には合わない場合、合わない部分を隠さずに書きます。「この業種の経験はありませんが、扱う質問の性質が近い案件を担当しています」という形です。隠したまま進めると、着手後に食い違いが出ます。合わない部分を書いたうえで声がかかった案件は、前提が揃っているので進行が安定します。

市場を見てきた立場からの観察

在宅ワークと業務委託の市場を20年運営してきた立場から言えば、仕事が続く人のポートフォリオには共通点があります。作品の数ではなく、振り返りの記述が厚いことです。うまくいかなかった点を書ける人は、発注側から見て予測しやすい相手になります。予測しやすい相手には、次の依頼が出しやすい。

もうひとつの観察として、長く続く関係を作っている人は、成果物を売る書き方をしていません。「この業務を預けると社内が楽になる」という状態を示す書き方をしています。AIチャットボット開発でいえば、ボットを作れることではなく、問い合わせ対応という業務全体を引き受けられることを示す。読み手が想像するのは、納品物ではなく預けたあとの自社の姿です。

中間の仲介が入らない直接取引では、発注側が払った金額と受け手が受け取る金額の差が小さくなります。同じ予算で発注側はより多く頼め、受け手の手取りは厚くなる。手数料0%という条件は、金額の大小ではなく手取りの質の話です。運営者として見てきた限りでは、この差が効くのは単発ではなく、運用のように長く続く契約のときで、そうした継続案件を得る入口になるのがポートフォリオの記述の質です。

掲載内容を業務の言葉に翻訳する

職種のデータを見ていくと、AIチャットボット開発は開発技術だけで完結しない仕事だとわかります。会話の言い回しを決める作業は文章を扱う仕事であり、社内向けの説明資料を作る作業も含まれます。実際、著述家，記者，編集者の年収・単価相場が扱う領域の技能は、回答文の設計や掲載記述の組み立てに直結します。ポートフォリオに載せる項目を考えるとき、この視点があると開発以外の貢献を言語化できます。

案件そのものがどのような技能の組み合わせで成立しているかは、AIチャットボット開発のフリーランス案件｜必要スキルと単価で領域ごとに整理されています。自分の掲載作品がどの領域を示せているか、抜けている領域はどこかを照合してみてください。抜けている領域が見つかれば、それが次に作る自主制作の題材になります。ポートフォリオは実力の証明書ではなく、次に何を学ぶかを決めるための地図として使うほうが、結果的に中身が濃くなります。

よくある質問

Q. 実案件を守秘義務の範囲内で載せるにはどうすればよいですか？

固有名詞を業種の一般名に置き換え、システム名を役割の記述に変え、件数や金額を性質の記述に置き換え、時期を丸めます。この4段階を機械的に通したあと、発注者本人が読んで自社だと特定できるかを確認してください。特定できるなら抽象化が不足しています。可能であれば掲載予定の文面を先に作り、発注者に見せて許可を取るのが最も安全です。

Q. 動くデモは必ず用意すべきですか？

必須ではありません。むしろ、想定外の質問に不自然な答えを返すデモは印象を損ないます。用意する場合は、試せる範囲を明示し、範囲外には答えない設計にしてください。答えない範囲を決めている判断そのものが、業務理解を示す材料になります。デモがない場合は、代表的な会話の流れと設計意図を文章と図で示せば十分です。

Q. 1件あたり何を書けばよいですか？

課題、制約、判断、結果、振り返りの5項目でそろえます。最も読まれるのは判断と振り返りです。判断は再現性のある能力を示し、振り返りは学習の姿勢を示します。結果だけを並べると、たまたま成功した可能性を排除できません。うまくいかなかった部分と、その原因の分析も必ず残してください。

Q. 実案件の経験がない段階では何を作ればよいですか？

想定利用者が具体的で、正解を確認でき、自分がその業務を理解している題材を選びます。前職の業務、家族の職場の困りごと、自分が繰り返し調べている手続きなどが適しています。何でも答える汎用的なものは評価の基準がなく、出来を示せません。範囲を狭く取るほど、設計の良し悪しを説明しやすくなります。

Q. 作品はいくつ載せるのが適切ですか？

数を増やすより1件あたりの記述を厚くするほうが結果につながります。薄い記述の作品を多数並べたページは、どれも印象に残りません。扱える領域の一覧を冒頭に置き、それを裏づける代表的な作品を絞って掲載する形が読みやすくなります。更新の履歴を残し、振り返りの追記を続けることのほうが、点数を増やすより効果があります。