A&A INSIGHTS
一人AI SaaSのサポート自動化：返信文より先に、失敗を再現できる文脈を添える
一人でAI SaaSを開発しサポートも兼ねる創業者向けに、問い合わせの受付時に添える五項目と添えない項目を、GumloopとAnthropicの一次資料を手がかりにA&Aが組み直して示します。
Read in English
この記事の要点
一人でAI SaaSを開発しサポートも兼ねる創業者が最初に自動化するのは、返信文の生成ではなく、問い合わせが届いた時点で「契約プラン」「直前の操作」「発生したエラー」を自動で添える受付です。長いのは返信を書く時間でなく、調査を始める前の聞き返しだからです。
返信文の自動化より先に、調査を始められる文脈を添える
A&Aの考え方
一人でAI SaaSを開発しながらサポートも兼ねているなら、最初に自動化するのは返信文の生成ではなく、問い合わせが届いた時点で「契約プラン」「直前の操作」「発生したエラー」を自動で添える受付です。文章を書く作業は、原因が分かってしまえば短い。長いのは、「動きません」という一行を受け取ってから、何を見ればよいか分かるまでの往復です。ここを埋めないと、回答を自動化しても、人が調査を始めるまでの時間は変わりません。
A&Aの考え方
問い合わせをAIで受けるという話は、通常「どれだけ自動で答えられたか」の話になります。しかし一人体制で現実に時間を取られているのは、答えの文面を作る工程ではなく、調査に入る前の質問と回答の往復です。「ご利用のプランを教えてください」「直前にどの画面で何を押しましたか」。この二往復で半日から一日が消えることもあり、その間問い合わせは未解決のまま残ります。この所要時間はA&Aが測定したものではなく、想定の目安です。だから最初の設計対象は、返信ではなく受付に添える情報の方だと考えます。
A&Aの考え方
この記事は、海外の二つの一次資料を使います。一つは自動化プラットフォームGumloopが自社のサポート業務を公開した記事で、チケットが開いた時点で何を添えているかが書かれています。もう一つはAnthropicのエンジニアリング記事で、道具が何を返すと判断が動くのかが書かれています。両方とも発行体自身の記述であり、独立した監査ではありません。出典の記述、A&Aの読み解き、架空の記入例は分けて示します。
Gumloopの事例：チケットが開いた時点で利用者の状況を添える
出典に基づく事実
Gumloopは自社のサポート業務を自社製品で組んだ経緯を2026年2月17日に公開しています（著者は同社Max Brodeur-Urbas）。記事はこのサポートチームが二人であること（「our support team has only two people」）を明示しています。その上で、利用者の状況を集める工程を独立した節として置き、その節の冒頭で「顧客の懸念に対応するには、サポート担当者は顧客の文脈を理解する必要がある」と述べ、続けて「この利用者は誰か。どのプランなのか。製品の中で何をしていたのか」（「Who is this user? What plan are they on? What have they been doing in the product?」）という三つの問を並べています。
出典に基づく事実
付与のタイミングは、担当者が読む前です。「サポートチケットが開くたびに、ワークフローが自動で内部データベースを照会し、完全な利用者調書をPylonへ直接送る」（「every time a support ticket opens, a workflow automatically queries internal databases and pushes a complete user dossier directly into Pylon」）とあります。添えられるのは「利用者のプロフィール、活動履歴、エラー件数についての最新情報」（「the most up-to-date info on the user's profile, activity history, and error counts」）で、「このデータは30分ごとに同期される」（「This data is synced every 30 minutes」）と記述されています。
出典に基づく事実
目的も記事の中で明示されています。記事の終盤には、この仕組みが一度に完成したのではなく「数か月の継続的な反復を通じて、一つずつワークフローを積み重ねて育った」（「it grew one workflow at a time, over months of continuous iteration」）ものだとしたうえで、そこから学んだことが三つ並んでいます。その二つ目が「文脈が王である。サポートにおいては速さが重要だ」（「Context is king : when it comes to support, speed matters.」）です。続けて、自社の利用者情報の仕組みが「人間が読む前に、完全な顧客プロフィールを自動で組み立て、すべてのチケットへ送り込む」（「automatically assembles a complete customer profile and pushes it into every ticket before a human even reads it」）と述べ、その結果「サポート担当者は、『どのプランをご利用ですか』といった質問で利用者の時間を無駄にすることがなくなるし、複数の管理画面を行き来することもなくなる」（「The support agent never has to waste the user’s time asking questions like "what plan are you on?" or tabbing between dashboards.」）と書いています。
出典に基づく事実
エラーから逆に辿る経路も別に書かれています。エラーが検知されるとSlackの監視チャンネルへ通知が飛び、それを契機にワークフローが「自動でエラーメッセージから利用者IDを抽出し、その利用者を特定し、直近の活動についての文脈を提供する」（「automatically extracts the user ID from the error message, identifies the user, and provides context on the user's recent activity」）とあります。さらに別のエージェントが30分ごとに「エラーと異常が最も多い特定の利用者」（「the specific users with the most errors and anomalies」）を見つけ、「利用者がチケットを出す前に、先回りで不具合を特定して連絡する」（「proactively identify bugs and reach out, before a user even files a ticket」）ことを可能にしていると説明されています。
A&Aの考え方
出典が前面に置いているのは速さです。ただ、ここで速さを生んでいるのは返信文を書く工程の短縮ではなく、聞き返しが一往復も発生しないことだ、というのがA&Aの読み方です。出典はその区別を述べていません。ここから取り出せるのは、三つの順序です。文脈の付与が、担当者がチケットを読むより前に置かれていること。添える項目が「プロフィール・活動履歴・エラー件数」と名前で指定されていること。そしてエラー側から利用者を特定できる経路も同じ情報を使っていること。ただし同期が30分ごとだということは、添えられた値が最大で30分古い可能性があるということでもあります。出典はこの古さを問題としては述べていませんが、添える項目を自分で選ぶ側になるなら、古い値でも判断を誤らない項目かどうかは先に見る必要があります。これはA&Aの読み方です。
A&Aの考え方
同時に、この事例をそのまま一人の会社へ持ち込もうとするのは無理があります。相手は自動化プラットフォームの二人チームで、内部データベース、BigQuery、Pylonがすでにある前提です。一人で開発している側にあるのは、自分のデータベースと、さまざまな形で残っているエラーログだけです。だから移すのは仕組みではなく、「担当者が読む前に、名前で指定した少数の項目を添えておく」という順序だけです。
| 添える項目 | それで動く次の判断 | 添えないこと |
|---|---|---|
| 契約プランと制限の残量 | 仕様上の上限か、不具合かを先に分ける | 課金履歴と支払手段の詳細 |
| 直前の操作三件（人が読める名前） | 利用者の言葉と履歴を照合し、再現手順を組む | 内部IDだけの列挙と全操作履歴 |
| 同時刻帯のエラーの種類と件数 | この人だけか、全体障害かを判定し順序を決める | スタックトレース全文と他の利用者の行 |
| 対象データの規模と形式 | 入力値の問題か処理側の問題かを分ける | ファイル本体と入力本文の中身 |
| 該当した場合分けの項目 | 直すのがコードか表示かを決める | 本番の設定値と認証情報 |
| 各値の取得時刻 | 添えられた値を信じてよいかを判断する | 古さを隠した上での断定 |
Anthropicの道具設計：全部渡すのでなく、次の判断が動く項目を返す
出典に基づく事実
Anthropicは2025年9月11日公開のエンジニアリング記事で、エージェントに渡す道具の設計指針を示しています。項目の選び方については、道具の実装は「信号の強い情報だけを返すよう注意すべきだ」（「take care to return only high signal information back to agents」）とし、「柔軟性より文脈上の関連性を優先し、低次の技術的識別子（例：uuid、256px_image_url、mime_type）は避けるべきだ」（「prioritize contextual relevance over flexibility, and eschew low-level technical identifiers」）と述べています。理由として、name、image_url、file_typeのような項目の方が「直接に下流の行動と応答を方向づける可能性がはるかに高い」と説明しています。
出典に基づく事実
まとめ方についても具体的です。同記事は「get_customer_by_id、list_transactions、list_notesといった道具を別々に実装するのでなく、顧客の直近かつ関連ある情報を一度にまとめるget_customer_contextを実装することを検討せよ」（「Instead of implementing get_customer_by_id , list_transactions , and list_notes tools, implement a get_customer_context tool which compiles all of a customer's recent & relevant information all at once.」）と書いています。ログについては、「read_logsを実装するのでなく、関連するログ行とその前後の文脈だけを返すsearch_logsを検討せよ」（「consider implementing a search_logs tool which only returns relevant log lines and some surrounding context」）とあります。
出典に基づく事実
識別子の書き方については、同社自身の所見が記されています。「任意の英数字UUIDを、より意味の通った解釈可能な言語（あるいは0始まりのID体系）へ解決するだけで、取得課題におけるClaudeの精度が、幻覚を減らすことによって大きく改善することが分かった」（「merely resolving arbitrary alphanumeric UUIDs to more semantically meaningful and interpretable language (or even a 0-indexed ID scheme) significantly improves Claude's precision in retrieval tasks by reducing hallucinations」）とあります。この「大きく」（原文では significantly）の内訳、つまり母数、測定日、測り方はこの記事には示されていません。同社の報告として扱い、数値に換えてはいけません。
出典に基づく事実
量の制御方法も示されています。同記事は道具にresponse_formatの列挙引数を置き、「concise」と「detailed」を選ばせる設計を提案し、掲載されたSlackの例について「この例ではconciseな道具応答によって約三分の一のトークン数で済んでいる」（「we use ~⅓ of the tokens with "concise" tool responses」）と記しています。またClaude Codeでは道具応答を「既定で25,000トークンに制限している」（「we restrict tool responses to 25,000 tokens by default」）とあります。
A&Aの考え方
この記事が語っているのは、人間の担当者でなく、道具がエージェントへ何を返すかです。それをサポートの受付票へ当てはめるのはA&Aの移し替えであり、出典はそう述べていません。トークン数の話は人が読む票にはそのまま移りません。ただし移る部分が三つあります。別の画面を見に行く代わりに一つにまとめること。ログ全文でなく該当行と前後に限ること。そして、内部IDだけでなく人が読める名前を並べることです。
A&Aの考え方
ここから、添える項目を選ぶ基準が一つ得られます。「取れるかどうか」でなく、「その値を見て次にすることが変わるかどうか」で選びます。取れるから添えた項目は、受付票を長くして読まれなくするだけです。逆に、値が一つ変わると見る場所が変わる項目なら、それは一行でも添える価値があります。
再現票：一人で用意できる五項目
A&Aの考え方
以下はA&Aの設計案です。問い合わせが届いた時点で自動的に添える項目を、五つに限ります。一、契約プランと制限の残量。二、直前の操作履歴を人が読める名前で三件。三、同じ時刻帯にこの利用者で発生したエラーの種類と件数。四、対象になっているデータの規模と形式。五、利用環境のうちこの製品で実際に場合分けしている項目。数を五に限るのは、一人で維持できる量だからです。
A&Aの考え方
二番目の「人が読める名前で」は省けません。操作履歴がUUIDとエンドポイント名だけで並んでいると、コードを書いた本人でさえ「これは利用者から見て何の操作なのか」を履歴から復元するのに時間がかかります。問い合わせは利用者の言葉で書かれてくるので、照合する側も利用者の言葉に寄せておく必要があります。
A&Aの考え方
エラーの項目は、本文全文でなく「種類と件数」にします。一件の問い合わせに対して知りたいのは、「この人だけに起きているのか、さっきから全体で起きているのか」だからです。この二択が先に分かると、後の調査が全く別の方向になります。全体で起きているなら返信より先に後始末です。
A&Aの考え方
五項目を添えたときの合否の基準を、一つだけ決めておきます。受付票を読んだ時点で、追加で聞く必要がある項目がゼロか一つになっているか。二つ以上聞く必要が毎回残るなら、項目の選び方が違っています。逐一件数を測る必要はありません。一週間分の問い合わせを並べて、それぞれ何を聞き返したかを一行で書くだけで、添える項目を入れ替える材料になります。なお、この五項目自体は状態を持つSaaSなら何にでも当てはまるもので、AI固有ではありません。AIの出力そのものへの苦情を扱うなら、モデルと版、再試行と打ち切りの有無、そして利用者が問題だと言っている出力の識別子を足す必要があります。出力本文ではなく識別子にするのは、次の節の「添えない項目」と両立させるためです。その場合も総数は増やさず、五項目のうち最も判断が動かないものと入れ替えます。
添えない項目を先に決める
A&Aの考え方
文脈を添える話は、放っておくと「念のために全部渡す」へ滑ります。そこで、添える五項目と同じ所に、添えない項目も書いておきます。利用者が入力した本文データの中身。付属ファイル。認証情報とトークン。他の利用者の行。この四つは、調査の途中で必要になってから、範囲と理由を決めて取りに行く側に置きます。受付票には「あるかないか」と規模だけが載れば十分です。
A&Aの考え方
もう一つ、古さの扱いを決めておきます。添えた値には取得時刻を並べ、問い合わせの到着時刻との差を見えるようにします。古さが分からない値は、無い値より危険です。無い値なら聞きますが、古い値はそのまま信じて調査の方向を決めてしまうからです。Gumloopの記述にある30分ごとの同期も、同じ問題を持ちます。出典はこれを問題としては述べていません。
A&Aの考え方
閲覧範囲も同じ表に入れます。一人のうちは全てを見られるので差が出ませんが、外部の協力者や最初の採用を入れた時点で、調査を始めるのに必要な項目と、その人に見せてよい項目は一致しなくなります。先に一枚にしておけば、その時に分けるのは行単位の作業で済みます。
架空の例：「保存できません」の一件が調査に入るまで
仮想例
以下は架空の例です。実際の顧客やA&Aの実績ではありません。一人で文書要約のAI SaaSを運用しているとします。火曜の10時15分に「保存できません」という一行が届きます。文脈を添えない場合、ここで聞くことになります。どのプランか。どの画面か。何を保存しようとしたのか。返信が夕方に届き、調査の開始は翌日になります。
仮想例
五項目を添えている場合、受付票にはこう並んでいます。プランは無料で、今月の処理可能数の残りはゼロ。直前の操作は「要約の作成」「要約の作成」「保存」の三件。エラーは「上限超過」が二件で、同じ時刻帯の他の利用者には発生なし。対象のファイルは12ページのPDF。場合分けの項目は「無料プランの上限処理」に該当。この五行を読んだ時点で、不具合でなく上限の説明不足だと分かります。
A&Aの考え方
この例で変わったのは、返信の文面ではなく、最初の一通で聞くことがゼロになったことです。そして同時に、この一件の行き先も決まります。上限の説明不足なら、直すのはコードでなく上限に近づいた時の表示です。この分岐自体の設計は、この記事ではなく「AIサービスの問い合わせを機能要望に直結させない：修正・説明・新機能を分ける」で扱っています。本稿はその手前、分けるための材料をどう揃えるかの話です。
この設計が向かない場合と、確かめ方
A&Aの考え方
問い合わせの大半が「どこからやるのか」という使い方の質問なら、再現の文脈を添えても得は小さいです。その場合の無駄は調査の前の往復ではなく、説明がないことにあります。また、利用者ごとの状態を持たない製品では、添える項目そのものがありません。この記事の話は、契約プランと操作履歴が自社のデータベースにある製品に限られます。
A&Aの考え方
添える項目が間違っているときの弊害も書いておきます。古い値や集計の違う値が添えられていると、聞き返しは消える代わりに、違う方向の調査を確信を持って始めてしまいます。項目を追加するときは、値の定義と取得元を一行で書き添え、自分で確かめられる形にしてから添えます。正確さの確認は、付与の仕組みとは別に一度やります。
A&Aの考え方
確かめ方は一週間で済みます。今週届いた問い合わせを並べ、それぞれについて「調査に入る前に聞いたこと」を一行で書き出します。同じ質問が三件以上並んだら、それが添える項目の候補です。並んだ質問が毎回違うなら、この設計の優先度は低いということです。途中で人へ戻す条件をどう決めるかは「問い合わせをAIで受ける前に、人に戻す条件を先に決める：回答率より誤った解決の負担を見る」で別に扱っています。全体の流れの中での位置は「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」を参照してください。
A&Aの考え方
減った往復を売上や解約率の改善に換算してはいけません。この設計が直接変えるのは、問い合わせ一件あたりの往復回数と、調査を始められるまでの時間だけです。その先に何が起きるかは、件数、内容、価格、製品の状態によります。この記事はA&Aの実施実績を示すものではなく、公開資料の記述と、そこから組み直した設計案です。
返信文の自動化より先に、問い合わせの受付時点で五項目（契約プランと残量、人が読める名前での直前の操作三件、同時刻帯のエラーの種類と件数、対象データの規模と形式、該当した場合分け）を自動で添え、同じ表に添えない項目と取得時刻を書いておきます。合否の基準は一つです。受付票を読んだ時点で、追加で聞く項目がゼロか一つになっているか。一週間分の問い合わせを並べ、調査の前に聞いたことを一行で書き出して、項目を入れ替えてください。同じ質問が三件以上並んだときだけ、この設計の優先度は高いと言えます。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Supporting the world's most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-09-28 - Writing effective tools for agents — with agents
Anthropic · 2025-09-11
確認日 2026-09-28
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-28