実績ゼロの状態でAIチャットボット開発に応募するとき、練習作は使えるのか

2026年3月28日

前田壮一

この記事のポイント

✓AIチャットボット開発に実績ゼロで応募するとき
✓練習作は評価されるのか
✓発注側が実績で見ている中身

AIチャットボット開発の案件に応募したいけれど、実績ゼロで出せるものが練習作しかない。この状態で手が止まっている方は多いと思います。まず、安心してください。練習作が使えないということはありません。ただし、発注側に届く練習作と、まったく読まれずに終わる練習作には、はっきりした違いがあります。この記事では、実績ゼロの応募者が置かれている市場の状況を確認したうえで、どういう練習作なら実務経験の代わりになるのか、その作り方と見せ方を順に整理していきます。

実績ゼロの応募者が増えている構造的な理由

AIチャットボットの案件そのものが、この数年で急激に裾野を広げました。以前は自然言語処理の研究に近い領域で、そもそも入口が限られていました。ところが大規模言語モデルをAPIで呼べるようになったことで、「社内マニュアルを読ませて答えさせる」「問い合わせフォームの一次受けをさせる」といった、業務寄りの小さな案件が大量に生まれています。

この変化には二つの側面があります。ひとつは、参入障壁が下がったこと。もうひとつは、参入障壁が下がったぶん応募者が一気に増え、発注側が選別に困っていることです。募集を出した側から見ると、応募文の文面だけでは技術力の差がほとんど読み取れません。誰もが同じようなツール名を並べ、同じような意欲を書いてくるからです。

つまり、実績ゼロの人が不利なのは「経験年数が短いから」ではなく、「他の応募者と区別がつかないから」です。ここを取り違えると、対策の方向がまるごとずれます。資格を増やしたり、学習時間を積み増したりしても、応募文の見た目は他と変わりません。区別をつけるための材料が要るのであって、その材料になり得るのが練習作です。

なお、AIチャットボット開発の周辺には、導入支援やプロンプト設計といった隣接領域の仕事もあります。どの領域にどんな依頼が集まっているかを俯瞰しておくと応募先の選び方が変わるので、AIコンサル・業務活用支援のお仕事で仕事の輪郭をつかんでおくと無駄打ちが減ります。

もうひとつ押さえておきたいのが、依頼側の温度差です。チャットボットを入れたい企業のすべてが、技術に詳しいわけではありません。むしろ「問い合わせ対応の人手が足りない」「同じ質問に何度も答えている」という業務の困りごとが先にあって、その解決手段としてチャットボットという言葉にたどり着いた企業のほうが多いのが実情です。この層に対しては、最新の技術名を並べるより、困りごとをどう減らすかを言葉にできるかどうかが効きます。実績ゼロの人にとって、ここは有利に働く余地がある部分です。

AIチャットボット開発の案件はどんな種類に分かれるか

一口にチャットボット開発といっても、依頼の中身はかなり幅があります。実績ゼロの段階では、この分類を把握しておくだけで応募先の精度が上がります。自分の練習作がどの種類に対応しているかを言えるようになるためです。

社内向けの問い合わせ対応

総務や情報システム部門に集まる社内質問を受け止めるタイプです。経費精算のやり方、休暇申請の手順、パソコンが繋がらないときの初動といった、社内規程やマニュアルに答えが存在する質問が対象になります。参照する資料が社内文書に限られるため、範囲を絞りやすく、練習作の題材としても扱いやすい領域です。ただし社内文書には機密が含まれるため、実案件では秘密保持の取り決めが必須になります。

顧客向けの一次対応

Webサイトに設置して、営業時間外の問い合わせを受けたり、有人窓口に回す前の切り分けをしたりするタイプです。社内向けと違って、質問してくる相手の前提知識がまちまちである点が難しさになります。想定していない聞き方をされる頻度が高いため、範囲外の質問をどう処理するかの設計が成否を分けます。

業務システムと連携するタイプ

在庫を照会する、予約状況を確認する、注文の進捗を返すといった、既存システムのデータを参照して答えるタイプです。この領域はAPIの設計や認証の扱いが絡むため、単価は上がりますが、実績ゼロで最初に狙う対象としては重すぎます。将来の目標として置いておき、まずは前の二つで実績を作るほうが現実的です。

既存ボットの改修と運用代行

新規開発ではなく、すでに動いているボットの回答を追加したり、答えられなかった質問を分析して改善したりする依頼も一定数あります。実績ゼロの段階では、この領域が最も入りやすい入口になり得ます。ゼロから設計する必要がなく、既存の設計に沿って手を動かせるかが問われるためです。練習作を作るときに運用と改善の工程まで通しておくと、この入口に手が届きます。

発注側が「実績」という言葉で本当に見ているもの

募集要項に「実務経験1年以上」と書いてあるとき、発注側が確認したいのは在籍期間ではありません。過去の案件で、次の三つが起きなかったかどうかです。

第一に、途中で音信不通にならなかったか。第二に、要件を聞き返さずに思い込みで作らなかったか。第三に、納品後に自分たちで直せる形で渡してくれたか。実務経験は、この三つが起きなかったことを推測するための代理指標にすぎません。代理指標である以上、他の材料で代替できます。

実際、募集要項の経験年数は、応募が殺到したときに機械的に絞るための線引きとして置かれていることも多くあります。応募文の冒頭で「経験年数は満たしていませんが、同種の問い合わせ対応を想定した成果物があります」と先に書いてしまえば、線引きの外側から読んでもらえる可能性が出てきます。条件を満たしていないことを隠して応募するより、満たしていない部分を先に開示して、代わりの材料を提示するほうが通りは良くなります。

だからこそ練習作が意味を持ちます。練習作は動く成果物であると同時に、「この人は何を考えて手を動かすのか」を可視化する資料でもあります。逆にいえば、動くだけで思考の跡が見えない練習作は、代理指標としてまったく機能しません。ここが、多くの人が取り違えているポイントです。

参考になるのが、チャットボット導入の実務で繰り返し指摘されてきた準備段階の重要性です。

AIチャットボットの開発を始める前に、準備段階でやっておくべきことがあります。この段階をおろそかにすると、開発後しても実際には使われない、期待した業務効率化につながらないというリスクを招きかねません。出典: chatplus.jp

発注側は、この「準備段階を飛ばさない人かどうか」を見ています。実装力そのものより先に、そこを見ています。練習作を作るときは、実装より前の工程を残すことが最優先だと考えてください。

通用しない練習作に共通する三つの特徴

現場でよく見かける、応募に添えても効果が薄い練習作には共通点があります。

誰の何を解決するのか決まっていない

チュートリアルをなぞって作った「何でも答えるボット」が、その典型です。技術的には動いていますが、発注側から見ると評価の軸がありません。何でも答えるということは、何も保証しないということでもあります。応対範囲が定義されていないボットは、業務に載せた瞬間に想定外の回答を出すため、実務では採用されません。

目的が曖昧なまま進むことのリスクは、導入現場でも繰り返し語られています。

目的が曖昧なまま進めてしまうと、完成したチャットボットが実際の業務課題を解決できなかったり、利用者にとって使いにくいシステムになったりする可能性があります。出典: chatplus.jp

使ったツール名しか説明されていない

「LangChainとベクトルデータベースを使いました」という説明は、発注側にとってほとんど情報量がありません。なぜそのツールを選んだのか、他に何を検討して落としたのか、その判断が書かれていないからです。技術選定の理由が書けないということは、発注側の要件が変わったときに選び直せないということでもあります。

動いた時点で止まっている

回答が返ってきた時点で完成扱いにしてしまう練習作も多いです。実務のチャットボットは、公開してからが本番です。想定外の質問がどれくらい来たか、回答できなかった質問をどう拾って改善したか。この運用の視点が抜けていると、発注側は「作れるが任せられない人」と判断します。

評価される練習作を作る五つのステップ

ここからは具体的な手順です。実績ゼロからでも、この順番で作れば応募材料として成立します。

想定発注者を実在の一社に絞る

架空の企業を設定するより、実在する企業の公開情報を使うほうが精度が上がります。地域の工務店でも、通販サイトでも構いません。公開されている問い合わせ先やよくある質問のページを読み、その会社が実際に受けていそうな質問を洗い出します。

ここで大事なのは、勝手に営業をかけないことです。あくまで練習作の題材として使い、公開する場合は社名を伏せる、あるいは事前に許可を取る。この配慮ができるかどうかも、応募文からにじみ出ます。

対応範囲を20件から30件に限定する

範囲を絞ることは手抜きではなく、実務の定石です。よく寄せられる質問の上位だけを確実に返せるボットのほうが、全方位に曖昧な答えを返すボットより業務では役に立ちます。

たとえば、カスタマーサポートの工数削減が目的であれば、よく寄せられる問い合わせ上位20〜30件に対応させるだけでも大きな効果が見込めます。出典: chatplus.jp

対応範囲を決めたら、範囲外の質問をどう扱うかも先に決めます。「有人窓口の案内に切り替える」「わからないと明示して問い合わせフォームへ誘導する」といった逃げ道の設計は、実務で必ず求められる部分です。ここを設計してあるだけで、練習作の説得力は大きく変わります。

ツールを選び、選んだ理由を書き残す

実装の手段は大きく二つに分かれます。ノーコードの構築ツールを使う方法と、フレームワークやAPIを直接組み合わせて自前で作る方法です。どちらが正解ということはなく、案件の条件によって変わります。

比較軸	ノーコード構築ツール	自前開発
立ち上げの速さ	数日で形になる	設計を含めると数週間
カスタマイズの自由度	提供機能の範囲内	制約が少ない
既存システムとの連携	用意された連携先に依存	APIがあれば広く対応可能
月額の運用費	ツール利用料が継続的に発生	API従量課金とサーバ費用
発注側が引き継ぎやすいか	管理画面から社内で更新可能	保守できる人が必要
練習作としての見え方	設計力が伝わりにくい	技術判断の跡が残る

実績ゼロの段階では、この表そのものを練習作の資料に添えるのが有効です。選ばなかった側の欠点まで書けている人は、そう多くありません。

効果測定の指標を自分で置く

運用に載せる想定で、測る指標を先に決めます。よく使われるのは、回答できた質問の割合、有人対応へ引き継いだ割合、利用者が途中で離脱した割合の三つです。3つとも完璧に測れなくても構いません。練習作の段階では「何を測るつもりで作ったか」が書いてあることが重要です。

指標を置くと、改善のサイクルが回り始めます。回答できなかった質問のログを見て、想定していた20件の範囲を組み替える。この作業を一度でも通しておくと、応募文に書ける内容がまるごと変わります。

引き継ぎ資料まで作って完成とする

発注側が最後に不安に思うのは、納品後に自分たちで手入れできるかどうかです。参照するデータをどこに置いてあるか、回答を追加するときはどのファイルを触るか、料金が発生する箇所はどこか。この三点をまとめた短い手順書を添えるだけで、練習作は「作品」から「納品物」に変わります。

技術的な内容を相手に伝わる文章で書けることは、それ自体がスキルです。書類作成の基礎を体系的に押さえたい方は、ビジネス文書検定の出題範囲が実務の要件定義書や手順書の型と重なるため、学習の足場として使えます。

開発中にエラーが出たときにどう振る舞うか

練習作を作っていると、必ずどこかで詰まります。回答が返ってこない、参照した資料と違う内容を答える、動いていたものが翌日に動かなくなる。実績ゼロの人にとって、この場面は挫折のきっかけになりやすい部分ですが、同時に応募文で書ける材料が生まれる場面でもあります。

つまずきは、原因の層で切り分けると整理しやすくなります。第一の層は接続まわりです。APIの鍵が正しく読み込まれていない、利用上限に達している、通信が遮断されているといった原因は、コードの中身とは無関係に発生します。ここは、エラーメッセージをそのまま読めば大半が判別できます。

第二の層は、参照する資料の作り方です。マニュアルを丸ごと読み込ませたのに答えが的外れになる場合、資料の分割の仕方が粗すぎることが多くあります。長い文書を機械的に区切ると、ひとつの答えが複数の断片にまたがってしまい、必要な部分だけが取り出せなくなります。見出し単位で区切る、表は表として扱う、といった前処理の工夫が効いてきます。

第三の層は、指示の書き方です。範囲外の質問に対して「わかりません」と答えさせたいのに、無理に推測して答えてしまう場合、指示に逃げ道が書かれていないことがほとんどです。答えられないときの振る舞いを明文化していないと、モデルは何かしら答えようとします。

この三層のどこで詰まり、どう切り分けたかを記録しておいてください。応募文に「参照資料の分割単位を見出し単位に変えたところ、想定外の回答が減りました」と一行書けるだけで、他の応募者との差がはっきり出ます。発注側が知りたいのは、詰まらない人かどうかではなく、詰まったときに切り分けられる人かどうかだからです。

練習作から最初の受注につなげる進め方

練習作ができたら、いきなり大きな案件に応募するより、段階を踏むほうが結果的に早く進みます。

最初に狙うのは、規模の小さい追加作業です。既存ボットへの回答追加、答えられなかった質問の分類、シナリオの見直しといった依頼は、単価こそ低いものの、発注側にとってのリスクが小さいため実績ゼロでも通りやすい傾向があります。ここで一度でも納品を完了させると、応募文の内容が「練習作があります」から「納品した経験があります」に変わります。この差は大きいです。

次に意識したいのが、同じ相手からの二件目です。新規の相手を探し続けるより、一度取引した相手に次の提案をするほうが、必要な労力はずっと少なくなります。初回の納品時に「回答の追加は今後どなたが担当されますか」と一言確認しておくだけで、次の相談につながることがあります。売り込みではなく、運用の引き継ぎを気にかける質問として自然に置けるからです。

三件目以降は、対応した業種を軸に広げていくと積み上がりが早くなります。同じ業種の企業は、抱えている問い合わせの種類が似ています。一社分の対応範囲を設計した経験は、同業他社にほぼそのまま応用できます。実績ゼロの状態から抜けるとき、技術の幅を広げるより業種の深さを重ねるほうが、案件の獲得は安定します。

なお、成果物のまとめ方そのものは職種が違っても考え方が共通します。案件獲得につながる実績資料の構成を型として押さえたい方は、Webライターのポートフォリオの作り方｜案件獲得率が上がるテンプレート付き【2026年版】が参考になります。何をどの順で書くかという骨組みは、開発系の練習作にもそのまま応用できます。

応募文で練習作をどう提示するか

練習作ができても、渡し方を間違えると読まれません。応募文に長いURLだけを貼り付ける形は、最も反応が薄いパターンです。

順番は、結論、範囲、判断、運用の四つで組み立てます。最初に「どの業種のどの問い合わせを想定して作ったか」を一文で書く。次に、対応範囲と範囲外の扱いを書く。そのうえで、なぜその実装手段を選んだかを二行程度で書く。最後に、測るつもりだった指標と、改善の余地として残した部分を正直に書く。

弱点を先に書くことに抵抗があるかもしれませんが、実務では逆効果になりません。限界を把握している人のほうが、想定外の事態で報告を上げてくれるからです。逆に、欠点がひとつも書かれていない資料は、検証していないだけだと受け取られることがあります。

応募先の幅を広げたい場合は、チャットボット単体ではなく周辺の開発案件も視野に入れておくと機会が増えます。アプリケーション開発のお仕事には業務システム寄りの依頼が含まれ、チャットボットが既存業務のどこに接続されるのかを理解する助けになります。データ活用やセキュリティ要件が絡む依頼を知りたい場合は、AI・マーケティング・セキュリティのお仕事も併せて確認しておくとよいでしょう。

実績ゼロの段階で価格をどう決めるか

実績がない時期に最も判断が難しいのが金額です。安くしすぎると次の案件でも同じ水準を前提にされ、高くしすぎると土俵に上がれません。ここは感覚ではなく、作業の分解で決めるのが安全です。

チャットボット開発の作業は、大きく四つに分かれます。要件の聞き取りと対応範囲の確定、参照資料の整理と前処理、実装と調整、そして引き継ぎ資料の作成です。実績ゼロの人が見落としがちなのは二つ目の資料整理で、ここが全体の作業時間の中で大きな比重を占めることが少なくありません。既存のマニュアルが古い、複数のファイルに散らばっている、そもそも文書化されていないといった状況は珍しくないからです。

見積もりを出すときは、この四工程それぞれに時間を割り当てて積み上げます。総額だけを提示するより、工程ごとの内訳を添えたほうが、発注側は判断しやすくなります。内訳があると、予算が合わないときに「資料整理はこちらで行う」といった調整の余地が生まれるからです。値引き交渉ではなく範囲調整に持ち込めるので、金額を削らずに済む場面が増えます。

初回だけ低めに設定する場合も、その理由を明示してください。「初回のため相場より抑えた金額です」と書いておけば、二件目で通常価格に戻すときの説明が不要になります。何も言わずに安く受けると、その金額が基準として固定されます。単価を段階的に引き上げていく考え方そのものは職種を問わず共通するので、Webライターが文字単価を上げる方法｜1円→5円にステップアップする戦略【2026年版】の進め方が思考の整理に役立ちます。

実績ゼロの時期に踏みやすい落とし穴

単価の相場を知らないまま応募する

相場を知らないと、極端に安い金額で受けてしまい、次の案件でも同じ水準を提示されるという流れに入りがちです。開発系の報酬水準を把握しておくために、ソフトウェア作成者の年収・単価相場のような統計をひととおり見ておくことをおすすめします。設計や実装だけでなくドキュメント作成まで担う場合は、著述家，記者，編集者の年収・単価相場の水準も参考になります。

練習作に他人の資産を混ぜる

学習教材のサンプルコードや、他社のFAQをそのまま流用した練習作を提出してしまう例があります。実務ではライセンスと権利の確認が必ず入るため、ここが曖昧だと契約段階で止まります。使ったデータの出どころは、練習作の時点から記録しておいてください。

ネットワークやインフラの基礎を飛ばす

チャットボットは単体で完結せず、既存のWebサイトや社内ネットワークに載ります。接続が通らない、社内から見えないといったトラブルは、AIの知識では解決できません。基礎的なネットワーク知識を体系的に補いたい場合は、CCNA（シスコ技術者認定）の学習範囲が実務でつまずく箇所と重なっています。

学ぶ範囲を広げすぎる

実績ゼロの時期は不安から手を広げがちですが、複数の技術を浅く触った状態は、応募文で最も差がつきにくい状態でもあります。ひとつの練習作を、範囲を絞って最後まで運用視点で仕上げるほうが、結果的に早く次につながります。

運用にかかる費用を伝え忘れる

チャットボットは納品して終わりではなく、稼働している間ずっと費用が発生します。モデルの利用料、構築ツールの月額、サーバの維持費といった項目は、発注側が想定していないことがよくあります。見積もりの段階で継続費用の目安を伝えていないと、公開後に「話が違う」となり、初回で関係が終わってしまいます。練習作の引き継ぎ資料に費用の発生箇所を書く習慣をつけておくと、実案件でも自然に伝えられるようになります。

秘密保持の取り決めを後回しにする

社内文書を扱う案件では、資料を受け取る前にNDAを交わすのが原則です。実績ゼロの時期は「まず信頼を得たいから」と手続きを省こうとしがちですが、逆効果になります。書面の取り決めを先に求める応募者のほうが、情報の扱いを理解していると評価されるためです。受け取ったデータをどこに保存し、案件終了後にどう扱うかまで先に決めておくと、相手の判断がぐっと早くなります。

運営者の視点から見た、実績ゼロという言葉の実態

フリーランスと在宅ワークの市場を20年見てきた立場から言えば、実績ゼロで止まってしまう人と、そこを抜ける人の差は、技術の習熟度ではないことがほとんどです。差が出るのは、成果物を「相手の業務のどこに置くか」まで考えて渡せるかどうかという一点に集約されます。

長く仕事が続いている人ほど、単発の作業を上手にこなすことよりも、「この人に任せると自分たちの手間が減る」という状態を作ることに時間を使っています。チャットボット開発でいえば、実装の巧拙より、運用を引き取れる形で渡すことがそれに当たります。実績ゼロの段階でも、この振る舞いは練習作の中に埋め込めます。

もうひとつ、運営者として見てきた限りでは、報酬の額面だけを比べて仕事を選ぶ人は、伸びが早く止まる傾向があります。同じ予算でも、仲介の手数料が差し引かれる経路と、手数料0%で直接やり取りする経路では、受け手に残る額がまるごと変わります。依頼する側から見ても、中間コストがない分だけ同じ予算でより多くを頼めるため、関係が長く続きやすい。額面ではなく手取りと関係の継続で見たときに、どこで仕事をするかの意味が変わってきます。

実績ゼロという言葉は、実務経験の欄が空白であることを指しているだけです。空白を埋める材料は、経験年数以外にもあります。範囲を決め、判断の理由を残し、運用まで想定した練習作は、その材料として十分に機能します。焦って手を広げる前に、まずは一本、最後まで仕上げてみてください。