AIチャットボット開発の実績の見せ方｜出せない仕事をどう伝えるか

2026年5月6日

長谷川奈津

この記事のポイント

✓AIチャットボット開発の実績の見せ方を
✓守秘義務との兼ね合いから整理しました
✓社名も画面も出せない仕事を

AIチャットボット開発の実績の見せ方で最初にぶつかるのが、「作ったものを見せられない」という壁です。社内向けの仕組みは外から触れませんし、顧客向けでも社名を出せない契約になっていることが多い。結論から言うと、実績は「作ったもの」ではなく「解いた問題と、そこでの判断」を見せる形に組み替えれば、契約に触れずに伝えられます。

これ、知らない人が本当に多いのですが、発注者は完成品の画面をそれほど見ていません。見ているのは、似た状況で自分たちの案件を任せられるかどうかです。だから見せるべきは、状況の類似性と、判断の筋道です。

この記事では、何が出せて何が出せないのかを契約から整理する手順、出せない情報を出せる形に変える方法、そして発注者が実績のどこを見ているのかを扱います。なお、個別の契約の解釈が問題になる場面では、弁護士など専門家に相談してください。ここで扱うのは一般的な考え方の整理です。

出せない理由を、まず分類する

「出せない」と一言でまとめてしまうと、対処のしようがありません。理由ごとに、できることが違います。

契約で明確に禁じられている場合

秘密保持契約や業務委託契約の中に、成果物や取引の事実を第三者に開示してはならない旨の条項が入っているケースです。この場合、書かれている範囲は動かせません。動かすには、発注側から個別に許可をもらう必要があります。

ここで確認すべきは、禁じられている対象が何かです。契約書によって、範囲がかなり違います。取引があったこと自体を秘密とするもの、成果物の内容だけを秘密とするもの、開発中に知った発注側の内部情報だけを対象とするもの。つまり、契約書を読み直すと「社名は出せないが、どんな課題を解いたかは書ける」という判断ができる場合があるということです。

明文はないが、暗黙の了解がある場合

契約書に条項がなくても、業界の慣行や発注側の社風で出しにくいことがあります。金融や医療、公共の案件に多い形です。この場合は、聞けば許可が出る可能性があります。聞かずに諦めているケースが相当数あります。

公開前・検証中の場合

まだ公開されていない、あるいは限定公開の段階にある案件です。時期が来れば出せる可能性があるので、「いつなら出せるか」を確認しておきます。公開の時期にあわせて掲載する約束を取り付けておくと、あとで交渉し直す手間が省きます。

発注側が実績の公開を売りにしたくない場合

チャットボットを外部に作ってもらったことを、利用者に知られたくないという判断です。この場合、社名も内容も出せませんが、「ある業種で」という粒度なら許容されることがあります。

秘密保持契約のどこを読むか

実績の公開可否を判断するとき、見るべきなのは次の4点です。

秘密情報の定義です。何が秘密情報に当たるのかが書かれています。「開示された一切の情報」という広い書き方もあれば、「秘密である旨を明示して開示された情報」と限定している場合もあります。後者なら、明示されていない情報は対象外という読み方ができます。

例外事由です。公知の情報、独自に知得した情報、第三者から適法に取得した情報などが例外として並んでいるのが一般的です。発注側が自社サイトでチャットボットの導入を発表しているなら、その事実自体は公知になっている可能性があります。

存続期間です。契約終了後も一定期間は義務が続く、という書き方が普通です。期間が切れれば話が変わることもあります。

成果物の権利の帰属です。作った仕組みの権利が発注側に移っている場合、その画面を自分の宣伝素材に使うことは別途の許可が必要になります。権利の話と守秘の話は別の条項なので、両方を確認します。

※契約書の文言が曖昧で判断がつかない場合は、自己判断で公開せず、発注側に確認するか専門家に相談してください。掲載してしまってから撤回するのは、信用の面で大きな損失になります。

出せない情報を、出せる形に変える

ここからが本題です。禁じられているのは「特定できる情報」であって、「経験そのもの」ではありません。特定できないように書き換える手法が4つあります。

抽象化する

社名を業種と規模に置き換えます。「株式会社ABCの社内ヘルプデスク」を「従業員数が数百名規模の製造業の、総務部門向け社内問い合わせ対応」と書き換える。業種と規模と部門が分かれば、読む側は自分の状況と重ねられます。

抽象化のさじ加減は、特定可能性で決めます。その業種にその規模の会社が数社しかない地域なら、業種を一段広げます。「県内唯一の私立医科大学」と書けば特定されますが、「医療系の教育機関」なら特定されません。

数値の見せ方を変える

成果を数字で見せたいが、具体的な数字は出せないという場合があります。この場合、絶対値ではなく比率や相対的な変化で書きます。ただし、比率でも特定につながる場合や、そもそも公開が禁じられている場合があるので、確認は必要です。

参考になるのは、公開されている導入事例の書き方です。ツールの提供元が公開している事例では、次のような形で成果が示されています。

【成果】ユーザーの行動に応じた先回りのサポートにより、ボット満足度が83％（2025年7月時点）まで向上。問い合わせ対応の自動化だけでなく、データ活用による顧客体験（UX）の最適化を実現しています。出典: tayori.com

満足度という指標を、時点つきで示す書き方です。自分の実績でも、何を指標に置いたのか、いつ時点の数字なのかを添えると、読む側は信頼できます。数字そのものが出せないなら、「どういう指標で効果を測る設計にしたか」だけを書く手があります。指標の設計を語れること自体が、経験の証明になります。

工程で分解する

案件を丸ごと語れなくても、担当した工程ごとになら語れることがあります。要件の聞き取り、参照データの整備、回答生成の設計、評価の設計、公開後の改善。工程ごとに「どういう状況で、何を判断したか」を書けば、案件を特定せずに能力を示せます。

この形は、複数の案件から共通して言えることを抽出して書けるので、守秘の観点でも安全です。「複数の案件で共通して起きたのは、参照させる資料に旧版が混ざっている問題でした」という書き方なら、どの案件の話かは特定できません。

再現物を自分で作る

いちばん確実なのは、公開できるものを自分で作ることです。実案件と同じ構成のチャットボットを、公開されているデータを使って作り直します。参照させるデータは、官公庁が公開している資料や、自分で書いた文書を使えばよいので、権利の問題も起きません。

この再現物には、実案件では見せられない中身まで見せられるという利点があります。管理画面の構成、評価の仕組み、答えられない質問の逃がし方。実物では隠さざるをえない部分を全部開示できます。

発注者が実績で見ているもの

実績の作り方を考えるうえで、読む側の視点を押さえておきます。発注者が知りたいのは、次の3つです。

似た状況を経験しているか。業種や規模、扱う情報の性質が近いかどうかです。まったく同じである必要はなく、「社内規程を参照させる仕組み」という共通点があれば十分に伝わります。

困ったときにどう判断したか。うまくいった話より、うまくいかなかったときの対処の方が読まれます。データの形式が想定と違った、精度が上がらなかった、公開後に想定外の質問が来た。こうした場面で何を選んだかが、発注者にとっての判断材料になります。

一緒に進められそうか。文章の書き方、説明の丁寧さ、専門用語の扱い。実績の文章は、そのままコミュニケーションの見本として読まれます。専門用語を並べた実績は、打ち合わせでも同じように話す人だと受け取られます。

ポートフォリオの構成

上の3点を満たす書き方として、案件ごとに次の順で書く形が扱いやすくなります。

状況を書きます。業種、規模、対象となる業務、抱えていた問題。ここは抽象化した表現で構いません。

制約を書きます。使えるデータの状態、期間、社内の体制、セキュリティ上の縛り。制約が書かれていると、条件の厳しさが伝わります。制約のない案件はありません。

判断を書きます。制約の中で何を選び、何を諦めたか。既製のツールを使ったのか個別に作ったのか、その理由は何か。ここが実績の核心です。

工程を書きます。どの範囲を担当したか。全部を一人でやったのか、チームの一部を担ったのか。誇張せず、担当範囲を正確に書きます。

結果を書きます。出せる範囲で。数字が出せないなら、定性的な変化でも構いません。「担当者が問い合わせ対応に割いていた時間を、別の業務に振り向けられるようになった」という書き方でも伝わります。

振り返りを書きます。今なら別の選び方をする部分。ここを書ける人は、経験から学べる人だと判断されます。

導入事例の書き方としては、対応範囲を具体的に列挙する形が参考になります。

【成果】トレンドを反映したコーディネートの提案から、注文後の配送状況確認、返品・交換の手続き案内まで、24時間365日一括で対応。購買体験の包括的サポートを実現しています。出典: tayori.com

何から何までを担ったのかが列挙されていると、範囲が具体的に伝わります。自分の実績でも、担当した機能を並べる形は使えます。

公開の許可を取る手順

出せるかどうか分からない案件は、聞くのが早いです。聞き方には作法があります。

まず、何を公開したいのかを具体的に示します。「実績として掲載してよいですか」という漠然とした聞き方では、判断できないので断られます。「業種を『製造業』とだけ書き、社名と画面は出さず、担当した工程と技術的な判断のみを記載したい」と、掲載する文面の案まで添えて聞きます。

次に、掲載する場所を示します。自分のサイトなのか、提案資料の中だけなのか。提案資料の中だけであれば、許可が出やすくなります。

そして、掲載前に内容の確認をしてもらう約束をします。文面を事前に見せることで、発注側は安心して判断できます。

依頼の文面は次のような形になります。

「〇〇株式会社 △△様。先日納品いたしました案件について、当方の実績紹介への掲載可否をご相談させてください。掲載を希望する内容は別紙のとおりで、貴社名および画面のスクリーンショットは含めず、業種と担当工程のみを記載する形を想定しております。掲載前に文面をご確認いただき、修正のご指示をいただければそのとおりに直します。ご検討のほどよろしくお願いいたします。」

断られた場合も、記録として残しておきます。「この案件は掲載不可」と自分のメモに書いておけば、次に提案資料を作るときに迷いません。

提案や面談の場で、口頭ではどこまで話せるか

書面に載せるのと、口頭で説明するのとでは、扱いが違うと思われがちです。ここは誤解が多いところで、守秘義務は媒体を問いません。書けないことは、話せません。

ただし、口頭には「相手の質問に応じて範囲を調整できる」という利点があります。書面では特定を避けるために広く書いた部分を、相手が知りたがっている軸に沿って具体化できます。たとえば「参照させる資料の量が多い案件」という書き方を、相手が量の話に関心を示したら「文書の点数はさほど多くないが、一点あたりが規程集で、章立てをどう分割するかで悩んだ」と深めていく。案件は特定されないまま、経験の実在は伝わります。

避けたいのは、盛り上がった勢いで社名を口にすることです。面談の相手が業界内の人だと、そのまま話が回ります。「守秘の都合で社名は控えます」と最初に言っておくと、後で言いにくくなる場面を防げます。この一言は、マイナスにはなりません。むしろ、自分たちの情報も同じように守ってもらえると受け取られます。

もうひとつ、口頭で気をつけるのが、前の発注側への評価です。「あそこは資料がぐちゃぐちゃで大変だった」といった言い方は、内容としては守秘に触れなくても、印象を大きく損ないます。困難は事実として述べ、相手の落ち度としては述べない。この使い分けは、そのまま「この人は自分たちのことも外で悪く言わない」という判断につながります。

実績を置く場所ごとの書き分け

同じ実績でも、置く場所によって適した長さと粒度が変わります。

自分のサイトに載せる場合は、検索から読まれることを前提にします。誰が読むか分からないので、いちばん保守的な粒度にします。社名なし、画面なし、業種と工程と判断のみ。長さは案件ごとに数百字程度で、一覧できる形が読まれやすくなります。

提案資料に載せる場合は、相手が限定されるので、もう少し踏み込めます。ただし、提案資料は社内で回覧され、コピーされることを想定してください。「この資料は貴社内での検討のみにご利用ください」と表紙に書いても、流出しないという保証はありません。結局のところ、サイトに載せられない粒度は提案資料にも載せない、という運用が安全です。

応募や提案の文面に書く場合は、相手の募集内容に合わせて選びます。全部の実績を並べるより、募集内容と重なる一件を厚く書く方が効きます。読む側は多くの応募を見ているので、関係のない実績は読み飛ばされます。

面談用に手元で用意する資料は、また別です。口頭で説明する際の骨組みとして、案件ごとに状況、制約、判断、結果を一枚にまとめておくと、聞かれたことに順番に答えられます。この資料は相手に渡さない前提で作ります。

実績は納品直後に書き留める

実務でいちばん効くのは、この習慣です。納品が終わった直後、記憶が新しいうちに、次の項目をメモに残します。

案件の状況（業種、規模、対象業務）、制約（データの状態、期間、体制）、途中で起きた問題、その対処、最終的にどう落ち着いたか、今なら別の選び方をする部分。この6項目を、公開を前提としない自分用のメモとして書きます。

半年後に思い出そうとしても、細部は出てきません。特に「途中で起きた問題とその対処」は、日が経つと丸まってしまい、「大変だったが乗り切った」程度の記憶しか残りません。実績として価値があるのは、その丸まる前の細部です。

このメモから、公開用の文面を作ります。メモの段階では社名も具体的な数字も入れておいて構いません。公開用に書き起こすときに、特定できる情報を落とします。二段構えにしておくと、後から公開の許可が出たときに、厚い内容をすぐ出せます。

あわせて、公開の可否も記録します。契約書のどの条項が根拠か、いつまで有効か、掲載の許可を求めたか、その回答は何だったか。この記録があると、次に提案資料を作るときに、どの案件を使えるか一目で分かります。

業種によって注意点が変わる

扱う情報の性質で、気をつける度合いが変わります。

金融や保険の案件では、監督官庁への届出や社内規程の縛りが強く、外部への言及そのものが制限されていることがあります。この領域では、業種を明示せず「規制の厳しい業界」という書き方に留めるのが無難です。

医療や介護の案件では、患者や利用者の情報を扱った可能性が読み取れる書き方を避けます。実際には規程の文書しか扱っていなくても、書き方によっては誤解を招きます。「診療に関する情報は一切扱わず、院内の事務手続きに関する規程のみを対象とした」のように、扱わなかった範囲を明記する方が安全です。

公共の案件では、入札や契約の情報が公開されていることがあります。公開されている情報については、その公開元を根拠として示せる場合があります。ただし、公開されているのは契約の事実だけで、成果物の内容は別、という切り分けが必要です。

一般の事業会社であっても、上場企業なら開示規制との関係を意識します。業績に関わる数字を扱った場合、その数字が未公表であれば、いっそう慎重に扱う必要があります。

やってはいけないこと

実績づくりで一線を越えると、取り返しがつきません。

守秘義務の対象を、抽象化したつもりで載せないでください。業種と地域と規模を並べれば、特定できてしまうことがあります。判断に迷ったら載せない、が原則です。

担当していない工程を、担当したように書かないでください。話が具体的になった段階で必ず露見します。チームで関わった案件は、自分の担当範囲を明記します。

成果の数字を、確認せずに書かないでください。発注側が公表していない数字を、聞いた記憶だけで書くのは危険です。出典と時点を確認できない数字は載せません。

他社の事例を、自分の実績のように見せないでください。参考として紹介するなら、出典を明記して、自分の担当ではないことを明確にします。

「実績を見せてください」と言われたときの返し方

提案の場で、画面や納品物そのものを見せてほしいと言われることがあります。ここで慌てて断ると、隠しているような印象になります。返し方を用意しておきます。

最初に、見せられない理由を短く述べます。「守秘義務の関係で、納品物そのものはお見せできません」。理由を言わずに断ると、実績がないのではないかと疑われます。理由を言えば、同じ扱いを自分たちも受けられると分かるので、納得されます。

次に、代わりに見せられるものを即座に出します。ここで沈黙すると空気が悪くなるので、あらかじめ用意しておきます。公開できるデータで作った再現物、担当した工程と判断を書いた資料、扱った課題の類型の一覧。このいずれかを出せる状態にしておけば、話は前に進みます。

そして、相手が本当に知りたいことを確認します。「どの部分をご確認になりたいですか」と聞くと、たいてい「自社と似た規模で経験があるか」「精度をどう担保しているか」といった具体的な関心が返ってきます。その関心に対しては、案件を特定せずに答えられることが多い。画面を見たいのではなく、安心したいだけ、というケースがほとんどです。

それでも納品物の提示を条件にされる場合は、無理に応じないでください。守秘義務に反して見せた実績は、その場では評価されても、「この人は自社の情報も外で見せる」という判断につながります。長期的には確実に損をします。

実績が育つ順序

最初から公開できる実績が揃っている人はいません。順序を意識して積むと、早く形になります。

第一段階は、自分で作った再現物です。誰の許可も要らず、中身を全部見せられます。ここで、状況、制約、判断、結果という書き方の型も練習できます。

第二段階は、公開可能な案件を意識的に選ぶことです。受注の段階で、実績として公開してよいかを条件のひとつとして確認しておきます。「実績への掲載可否」を最初の打ち合わせで聞いておくと、後から交渉するより通りやすくなります。断られても案件そのものは受けられますし、聞いたこと自体が不利になることはありません。

第三段階は、公開できない案件を、抽象化と工程分解で語れる形に変換して積むことです。ここまで来ると、公開の可否にかかわらず実績が増えていきます。

多くの人が第一段階を飛ばして第三段階に行こうとして、書けるものがなくて止まります。順序を守れば、最初の一件は自分の手で作れます。

案件の性質を知るための材料

実績をどう見せるかは、狙う案件の性質によって変わります。業務にAIを組み込む相談型の仕事では、技術の実装歴より、業務を整理した経験の方が評価されます。この領域の仕事の中身はAIコンサル・業務活用支援のお仕事にまとまっているので、実績の書き方を寄せる先の参考になります。

実装まで担う案件では、担当した工程の広さが見られます。アプリケーション開発のお仕事には設計から保守までの工程が並んでいるので、自分の実績でどの工程を語れるかを整理する用途に使えます。個人情報や社内規程を扱った経験は、AI・マーケティング・セキュリティのお仕事の領域で強い材料になります。守秘の制約が厳しい案件ほど、扱った経験そのものが評価されるという逆転が起きます。

チャットボット開発の仕事に必要なスキルの全体像はAIチャットボット開発のフリーランス案件｜必要スキルと単価で整理しています。実績として語れる項目の一覧としても読めます。この職種が市場でどう位置づけられているかはソフトウェア作成者の年収・単価相場にデータがあります。

実績紹介の文章そのものの書き方も、評価の対象です。何を先に書き、どこまでを事実として書くか。文書の基本的な作法を確認したい場合はビジネス文書検定の出題範囲が指針になります。

実績の更新をやめない

作った実績のページを、一度作って放置している人が多いです。時間が経つと、内容そのものが古くなります。

技術の前提が変わると、当時の判断が理解されにくくなります。数年前に選んだ構成が、今なら別の選択になっている場合、その差を書き添えるだけで価値が変わります。「当時はこの制約があったためこの構成を選んだが、現在なら別の方法が使える」という一文があると、技術の変化を追い続けている人だと伝わります。

新しい案件が終わるたびに、古い実績を見直します。似た内容が並んでいるなら統合し、担当範囲が広がったなら書き換える。並べる順番も、狙いたい案件に近いものを上に置きます。

公開の可否も、時間で変わります。掲載を断られた案件でも、契約の存続期間が過ぎていたり、発注側が自社サイトで導入を公表していたりすることがあります。年に一度、公開可否の記録を見直すと、出せる実績が増えていることがあります。

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

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、実績が薄いことを理由に選ばれなかった人より、実績の書き方で損をしている人の方が圧倒的に多いです。書かれているのが使った技術の名前だけで、どんな状況で何に困り、どう判断したかが一行もない。これでは、読む側は自分の案件と重ねようがありません。

運営者として見てきた限りでは、指名で仕事が続く人は、出せない案件の話を「出せないなりに」語るのが上手いです。社名も画面も出さないまま、「参照させる資料に旧版が混ざっていて、まずその選別から始めた」という一文を書く。それだけで、経験の実在は伝わります。中間に仲介が入らない直接取引の場では、この伝わり方の差がそのまま次の依頼に繋がります。仲介経由だと実績の要約が担当者の手で作られるため、判断の筋道は落ちてしまう。直接やり取りできる関係では、書いた文章がそのまま相手に届き、手数料0%のぶん手取りも厚くなります。

法律はあなたの味方です。守秘義務は、あなたの実績を封じるためのものではなく、発注側の情報を守るためのものです。守るべき線を正確に把握すれば、その手前まではきちんと語れます。線がどこにあるか分からないまま全部黙るのは、いちばんもったいない選択です。