AIチャットボット開発のもう一度頼まれる人｜次に繋がる終わり方

2026年5月9日

朝比奈蒼

この記事のポイント

✓AIチャットボット開発でリピートされる人は何が違うのかを
✓納品前後の実務から整理しました
✓次の依頼が生まれる場所の見つけ方まで

AIチャットボット開発でリピートされるかどうかは、納品の瞬間に決まるものではありません。結論から言うと、分かれ目は「終わり方」の設計にあります。作ったものを渡して終わりにする人と、渡したあと相手が自走できる状態まで見届ける人。この違いが、次の依頼の有無をほぼ決めています。

チャットボットは、公開してからが本番という性質を持つ仕組みです。答えられなかった質問が溜まり、参照させる資料が古くなり、想定していなかった聞かれ方が出てくる。この「動き続ける」性質が、他の受託開発よりリピートを生みやすい構造をつくっています。にもかかわらず、単発で終わる案件が多い。理由ははっきりしていて、終わり方の設計をしていないからです。

この記事では、納品前後にやること、公開直後の動き方、そして次の依頼が生まれる場所の見つけ方を扱います。

リピートされない人に共通する終わり方

まず、うまくいかない側から見ます。単発で終わる案件には、いくつかの共通した終わり方があります。

納品物を送って連絡が途切れるパターンです。成果物と請求書を送り、検収の連絡を受けて終わり。発注側から見ると、その時点で関係が切れます。次に何か起きたとき、連絡先として思い出してもらえるかどうかは運任せになります。

運用の説明をしないパターンです。管理画面の使い方も、資料の差し替え方も伝えないまま渡すと、発注側は触れなくなります。触れない仕組みは、数か月で使われなくなります。使われなくなった仕組みを作った人に、次を頼む理由はありません。

問題の芽を報告しないパターンです。開発中に「この部分は将来ここが問題になる」と気づいていながら、契約範囲外なので黙って納品する。その問題が半年後に表面化したとき、発注側は別の会社に相談します。気づいていたのに言わなかった、という事実が伝わると、信用の面でも損をします。

過剰に売り込むパターンです。納品直後に次の提案を並べると、売り込みだと受け取られます。まだ効果も出ていない段階で追加の話をされると、発注側は身構えます。タイミングを外した提案は、次の依頼を遠ざけます。

納品と引き渡しは別の工程

納品は成果物を渡すこと、引き渡しは相手が運用できる状態にすることです。この2つを分けて考えていない案件が、大半です。

手順書は「触る人」の目線で書く

運用手順書を作るとき、開発者目線の構成にすると読まれません。機能ごとに説明するのではなく、「やりたいこと」から引ける構成にします。資料を差し替えたい、答えを直したい、答えられなかった質問を確認したい、利用を一時的に止めたい。この4つが、実際に発注側がやりたくなることの大半です。

各項目は、画面の順番どおりに書きます。どこを開いて、何をクリックして、どうなったら成功か。専門用語には必ず言い換えを添えます。手順書の質は、そのまま問い合わせの件数に跳ね返ります。

引き継ぎの場を設ける

手順書を送るだけでは足りません。担当者に実際に操作してもらう場を設けます。こちらが操作して見せるのではなく、相手に触ってもらうのが要点です。触ってもらうと、手順書のどこが分かりにくいかがその場で分かります。

この場には、日常的に運用する担当者だけでなく、その上長も呼んでおくと後が楽になります。上長がどんな仕組みなのかを知っていると、追加の予算を取るときの話が早く進みます。

想定される変更を先に伝える

半年後、一年後に起きそうな変更を、あらかじめ伝えておきます。参照している規程が改訂されたらどうするか、利用者が増えたらどこに負荷がかかるか、モデルの提供条件が変わったら何を見直すか。

これを伝えておくと、実際にその状況になったときに「言われていたやつだ」となって連絡が来ます。予言が当たったから頼まれるのではなく、この人は先を見て設計していた、という評価が残るから頼まれます。

公開直後の期間をどう過ごすか

公開してから最初のひと月は、次の依頼が生まれるかどうかがほぼ決まる期間です。

利用のログを一緒に見る場を作ります。どんな質問が来ているか、どれに答えられていないか、利用者はどのくらい使っているか。この確認を発注側と一緒にやると、改善すべき点が自然に共有されます。こちらが一方的に報告するより、一緒に画面を見ながら気づいてもらう方が、次の相談に繋がります。

答えられなかった質問の一覧は、そのまま次の仕事の種です。想定していなかった聞かれ方が出てくるので、その対処が追加の作業になります。ここで大事なのは、対処の見積もりをすぐ出さないことです。まず一覧を整理して渡し、「この分類のうち、どれを優先しますか」と相手に選んでもらう。選ぶ過程で、発注側は自分たちの課題を再確認します。

利用者の使い方も観察します。会話が長く続いている質問は、設計を見直す合図です。

また、初めの質問から最終的な結論へ辿り着くまでには3〜5階層以内に収めることをおすすめします。チャットボットとの会話が6回以上続くと、顧客はストレスを感じるでしょう。出典: aisaas.pkshatech.com

やり取りの回数を指標として持っておくと、改善の必要な箇所を機械的に見つけられます。感覚で「使いにくそう」と言うより、「この経路は平均で往復が多く、途中で離脱しています」と数字で示す方が、発注側は動きやすくなります。

保守契約がない場合の関係の残し方

すべての案件で継続契約が取れるわけではありません。契約がなくても、関係を残す方法があります。

納品時に、次の確認の予定を決めておきます。「公開から3か月後に、ログの状況を一緒に確認する場を設けませんか」と提案し、その場は無償にする。この一回の場が、次の依頼の入口になります。無償にする理由は、有償の保守を提案すると断られる可能性があるからです。一回だけの確認なら、断る理由がありません。

定期的に情報を送るのも有効です。売り込みではなく、参考情報として。モデルの提供条件が変わった、同種の仕組みで新しいやり方が出てきた、といった内容を短く送ります。頻度は多くしません。数か月に一度で十分です。

送る内容で気をつけるのは、相手が読んで何かしたくなる書き方にしないことです。「これを導入すべきです」ではなく「こういう変化がありました」で止めます。判断は相手に委ねる。この距離感が保たれていると、必要になったときに連絡が来ます。

次の依頼が生まれる場所

チャットボットの案件で、追加の仕事が生まれやすい箇所は決まっています。

参照する資料の追加と更新です。最初は一部の資料だけで始めて、うまくいったら範囲を広げるという進み方が一般的です。範囲を広げるときに、最初に作った人に頼むのが自然な流れになります。

利用者向けの案内文の整備です。使い方が分からずに離脱している利用者がいる場合、入口の説明文や最初に表示する案内を直すだけで利用率が変わります。小さな作業ですが、効果が数字に出やすいため、次の相談に繋がりやすい領域です。

対応チャネルの追加です。社内向けで始めたものを顧客向けに展開する、Webサイトだけだったものを社内チャットツールにも繋ぐ。既存の仕組みを理解している人に頼む方が早いので、指名される確率が高くなります。

権限による出し分けです。使い始めると「この情報は特定部署だけに見せたい」という要望が出てきます。設計に手を入れる作業なので、作った人が有利です。

回答品質の継続的な改善です。ここは終わりがありません。定期的に評価をやり直し、参照データの分け方や指示文を調整する作業です。月次や四半期の作業として定義しやすい領域でもあります。

評価の仕組みそのものの整備です。公開後しばらくすると、発注側は「今どのくらいの精度なのか」を定期的に知りたくなります。テスト質問のセットを増やし、定期的に流して結果を出す仕組みを作る作業は、独立した依頼として成立します。この仕組みがあると、以降の改善も測れるようになります。

他部署への横展開です。ひとつの部署でうまくいくと、隣の部署が興味を持ちます。この展開は、発注側の担当者が社内で紹介してくれる形で起きます。担当者が紹介したくなるかどうかは、その担当者が社内で評価されたかどうかにかかっています。

改善の記録を残す

公開直後に手を入れた内容は、必ず記録に残します。いつ、何を、なぜ変えたか。この記録がないと、数か月後に「なぜこの設定になっているのか」が誰にも分からなくなります。

記録の残し方は、凝ったものである必要はありません。日付と変更内容と理由を一行ずつ並べた表で十分です。重要なのは、発注側が見られる場所に置くことです。こちら側だけで管理していると、担当者が変わったときに引き継がれません。

この記録は、次の提案の根拠にもなります。「この3か月で、参照資料の追加が5回発生しています。都度対応より、月次でまとめて更新する形にした方が手戻りが減ります」という提案は、記録があるから出せます。感覚で「運用を契約しませんか」と言うより、はるかに通ります。

担当者の立場を理解する

リピートを考えるうえで見落とされがちなのが、発注側の担当者の事情です。

担当者は、社内でこの案件を通した人です。うまくいけば評価され、失敗すれば責任を問われます。だから担当者にとっての成功は、仕組みが動くことではなく、社内で「やってよかった」と言われることです。

この視点に立つと、やるべきことが変わります。担当者が社内報告に使える材料を渡すことが、直接的な価値になります。利用状況の推移、答えられた質問の割合、削減できた対応時間の推計。報告に使える形で渡すと、担当者はそのまま資料に組み込めます。

外部の支援がある状態は、担当者にとっても安心材料になります。

提供企業からのサポート体制が万全なら、導入や運用のアドバイスがもらえる場合があるため安心です。体験版を提供している作成ツールがあれば、なるべく利用して使用感を確かめることをおすすめします。出典: aisaas.pkshatech.com

ツールの話として書かれていますが、個人で受託する場合も同じ構図です。困ったときに聞ける相手がいる、という状態そのものが価値になります。契約が切れた後も質問には答える、という姿勢を示しておくと、次に予算が付いたときに真っ先に声がかかります。

正直なところ、ここを軽視している人は多いです。技術的に良いものを作れば次も来ると考えがちですが、担当者の立場から見た成功と、開発者から見た成功はずれています。

提案のタイミングと出し方

次の仕事の提案は、出すタイミングを間違えると逆効果になります。

納品直後は避けます。効果が出ていない段階での提案は、売り込みにしか見えません。

適切なのは、公開してから一定期間が過ぎ、データが溜まってからです。データを一緒に見る場で、事実として課題が見えたときに、その場で提案するのが自然な流れになります。提案の主語は「こちらがやりたいこと」ではなく「データから見えた課題」に置きます。

提案の形も工夫します。ひとつの案を押すより、範囲の異なる複数の案を並べる方が通ります。最小限の対処、標準的な対処、根本的な対処。それぞれで何が変わるかを書けば、発注側は予算に合わせて選べます。選択肢がひとつだと、やるかやらないかの判断になり、やらないが選ばれやすくなります。

急ぎでない提案は、あえて期限を切らないでおきます。「予算が付いたタイミングでご相談ください」と添えておくと、翌年度の予算編成のときに思い出してもらえます。

提案書は短くまとめる

継続の提案書は、枚数を増やさない方が通ります。読むのは担当者と、その上長です。上長は詳細を読みません。

先頭に、何を提案しているかを一行で書きます。次に、なぜそれが必要かをデータで示します。そのあとに、実施する内容と期間、費用の考え方を並べます。技術的な説明は末尾に回すか、別紙にします。

担当者が社内で説明するとき、この提案書をそのまま使えるかどうかが基準です。使えない体裁で出すと、担当者は自分で作り直すことになり、その手間が発注の障害になります。

続けない方がよい継続もある

すべての継続が良いわけではありません。

要求が広がり続けるのに予算が変わらない案件は、続けるほど条件が悪くなります。範囲の再定義を提案し、応じてもらえないなら区切りをつける判断も必要です。

担当者が頻繁に変わり、そのたびに前提の説明からやり直しになる案件も、実質的な負担が大きくなります。この場合は、文書での引き継ぎ資料を整備してもらう提案をします。それも難しいなら、都度対応の形に切り替えます。

技術的に袋小路に入っている案件も同様です。土台の設計に無理があり、要望に応えるほど不安定になる状況では、続けることが双方の損失になります。作り直しの提案を出し、それが通らないなら引き継ぎに徹する方が、長い目で見て信用を保てます。

引き渡し後に届く問い合わせの扱い

契約が終わっても、発注側から連絡が来ます。この扱い方が、リピートの分かれ目になっている場面をよく見ます。

来る問い合わせは3種類に分かれます。手順書を読めば分かること、契約範囲内の不具合、範囲外の新しい要望。この分類を自分の中で持っておくと、迷わず返せます。

手順書を読めば分かることには、手順書の該当箇所を示して答えます。「手順書をご覧ください」と突き放すのではなく、該当ページと要点を書いて返す。数分で済む作業です。ここで冷たく返すと、次に相談してもらえなくなります。逆に丁寧に返すと、手順書の分かりにくい箇所が判明するので、こちらにも利益があります。

契約範囲内の不具合は、当然対応します。対応したあとに、なぜ起きたかと再発を防ぐために何をしたかを短く伝えます。原因の説明があると、相手は安心します。

範囲外の新しい要望は、その場で断らず、まず内容を整理して返します。「ご要望を整理すると、次の3点になります。このうち1点目は現在の仕組みの設定変更で対応でき、2点目と3点目は追加の開発が必要です」という形です。整理して返すだけで、相手は自分の要望の輪郭をつかめます。そのうえで、追加が必要な部分は改めて相談させてくださいと伝えれば、押し売りにならずに次の話に入れます。

無償で対応する範囲を、自分の中で決めておくことも必要です。目安として、数分で済む質問への回答は無償、作業が発生するものは相談、と線を引いておくと迷いません。この線がないと、無限に対応することになるか、逆に全部を有償扱いして関係を冷やすかのどちらかになります。

検収でもめない終わり方

終わり方の話をするうえで、検収を避けて通れません。ここがこじれると、どれだけ丁寧に運用支援をしても関係は壊れます。

検収の基準は、着手前に文書で合意しておきます。合意した基準に沿って確認してもらい、指摘があれば是正する。この流れが決まっていれば、感覚的な「まだ納得できない」に引きずられません。生成AIを使った仕組みは、回答の良し悪しが主観に寄りやすいので、事前に決めたテスト質問のセットで判定する形にしておくのが実務的です。

検収を依頼するときは、確認してほしい項目を一覧にして渡します。「ご確認ください」とだけ送ると、相手は何を見ればよいか分からず、そのまま止まります。項目を並べ、それぞれに合否の欄を作っておけば、確認作業が具体的になります。

指摘が来たときは、是正の対象かどうかを分類してから返します。合意した基準に対する不足なら是正、基準の外にある新しい要望なら追加の相談。この分類を最初の返信で示しておくと、後で説明し直す手間がなくなります。分類を曖昧にしたまま全部引き受けると、その案件だけでなく、次の案件の前提まで崩れます。

検収が終わったら、完了の記録を文書で残します。いつ、どの基準で、誰が承認したか。この記録は、後から「あの機能は納品されていない」と言われたときの根拠になります。

請求と支払いまでを含めて終わりと考える

納品と検収が終わっても、支払いが済むまでは案件は終わっていません。

請求のタイミングは、契約で決めた区切りに合わせます。承認と請求がずれていると、承認されていない工程の代金を請求する形になり、話がこじれます。

報酬の支払期日については、フリーランス保護の制度で発注側に義務が課されています。受領日から起算して60日以内のできる限り短い期間内に支払期日を定めることとされており、制度の内容は公正取引委員会の案内で確認できます。契約段階でこの条件を確認しておけば、支払いの遅れが起きたときに落ち着いて対応できます。

支払いが遅れたときの連絡は、感情を挟まず事実だけを書きます。請求書の番号、金額、期日、現在の状況。相手の担当者が悪意で止めているケースは少なく、社内の処理が滞っているだけということが多い。淡々と確認すれば、たいてい動きます。ここで関係を荒らすと、それまでの仕事が全部無駄になります。

記録を残して次に備える

案件が終わったら、自分のために記録を残します。この作業をやっているかどうかで、二件目以降の効率が変わります。

残すのは、要件を聞き出す過程で有効だった質問、実際にかかった工数と見積もりとの差、途中で発生した想定外の作業、その原因、次に同じ状況になったらどうするか。特に工数の差は必ず記録します。どの工程が想定より膨らんだのかが分かると、次の見積もりの精度が上がります。

参照データの整備にかかった時間、評価の反復回数、確認待ちで止まった日数。この3つは案件ごとにばらつきが大きく、記録を積むほど読めるようになります。読めるようになると、前提条件の欄に書く内容が具体的になり、結果として案件が荒れなくなります。

発注側の情報も整理しておきます。担当者の名前と役割、決裁の流れ、社内の関係部署、確認の返答にかかった日数。次の依頼が来たときに、この記録があれば説明のやり直しが不要になります。相手にとっての「話が早い」は、この記録から生まれます。

最初から継続を前提に組む

終わり方の設計は、実は着手前から始まっています。

契約を組むとき、開発と運用を別の契約として並べて提示する方法があります。開発だけを請けて、運用は別途相談という形にすると、運用の話が立ち消えになりやすい。最初から2本を並べて出し、運用は開発の完了後に開始する、という形にしておけば、自然に継続に入ります。

運用の内容は、具体的な作業として定義します。答えられなかった質問の確認、参照資料の更新、回答の調整、月次の報告。曖昧に「保守」とだけ書くと、何をやるのか分からないので予算が付きません。作業を並べると、発注側は必要性を判断できます。

開発の範囲を意図的に絞る、という考え方もあります。全部を一度に作るのではなく、効果が出やすい部分から始めて、結果を見て広げる。段階を分けると、最初の投資が小さくて済むため決裁が通りやすく、結果が出れば次の段階が自然に発注されます。単発で大きく取るより、続く形にする方が、双方にとって無理がありません。

案件の広げ方と、市場の見方

継続案件を増やすには、自分が担える範囲を広げるのが直接的です。業務の整理から入る相談型の仕事は、開発の前段にあたるため、そこから受けると後工程まで繋がります。仕事の内容はAIコンサル・業務活用支援のお仕事にまとまっています。

実装から保守までを一貫して担う場合の工程はアプリケーション開発のお仕事で確認できます。保守の工程まで見積もりに入れられるかどうかが、単発で終わるか継続になるかの分かれ目です。個人情報や規程の扱いが絡む案件はAI・マーケティング・セキュリティのお仕事の領域と重なります。この領域は継続的な確認が必要になるため、構造的にリピートが生まれやすい性質があります。

チャットボット開発の仕事に必要なスキルの全体像はAIチャットボット開発のフリーランス案件｜必要スキルと単価で整理しています。継続案件で求められる範囲を把握する材料になります。この職種が市場でどう扱われているかはソフトウェア作成者の年収・単価相場にデータがまとまっています。

継続的な関係では、報告や提案の文書を書く機会が増えます。読み手が判断できる文書を書けるかどうかは、そのまま次の依頼に影響します。文書の基本を確認したい場合はビジネス文書検定の出題範囲が参考になります。

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

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、長く続く人ほど、単発の作業ではなく「この人に任せると楽だ」という関係づくりに時間を使っています。技術の高さで選ばれ続ける人は、実は少数派です。多数派は、連絡が速い、説明が分かりやすい、困ったときに相談できる、という理由で選ばれ続けています。

運営者として見てきた限りでは、二件目以降の依頼が来る人には共通の癖があります。作業が終わったあと、頼まれていないのに一言添える。「この部分は次の改訂で影響を受けるので、そのときにご連絡ください」といった、短い添え書きです。売り込みではなく、相手が困る場面を先に見ているだけ。これが積み重なると、相手の頭の中で「困ったらこの人」という位置に収まります。

中間マージンが乗らない直接取引の場では、この積み重ねが素直に効きます。仲介が入ると、次の依頼も仲介経由になり、そのたびに条件が組み直されます。直接の関係が続いていれば、前回の前提がそのまま引き継がれるので、双方の手間が減る。同じ予算でも依頼側はより多くを頼めますし、受け手は手数料0%のぶん手取りが厚くなります。継続とは、毎回ゼロから説明し直さなくてよい関係のことです。

もうひとつ、長く見ていて確かなのは、リピートは相手の記憶の中で起きるということです。半年前に一度やり取りしただけの相手の名前は、普通は出てきません。出てくるのは、手順書が手元にあって、その表紙に名前が書いてある場合や、数か月に一度の短い連絡が届いている場合です。関係を維持する仕組みを持っている人が、結果として指名されています。才能の差ではなく、仕組みの差です。

終わり方を設計するのは、次を取るための営業行為ではありません。作ったものが使われ続けるための、当然の工程です。結果として次が来る、という順番を間違えないことが、いちばん確実な近道になります。