Conveyorで質問票に答える4工程｜根拠と承認の線引き

「顧客から届くセキュリティ質問票が年々増え、営業が情報システム部門に頭を下げて回答を頼む状態が続いている」「AIで答えを下書きできる道具があると聞いたが、間違った答えを出したら誰の責任になるのか」——自社のサービスを企業に売る会社で、営業と情シスの双方から同じ時期に届く声です。米国の Conveyor は、こうした質問票やRFPへの回答を、AIが承認済みの文書から出典付きで下書きする製品で、2026年9月にはRFP向けの機能と回答の仕組みを作り直したと発表しました。ただ、質問票への回答は単なる事務作業ではなく、会社として顧客に出す説明であり、ときに約束として読まれる文書です。この記事では、Conveyor がどんな型の製品かを押さえたうえで、根拠文書の準備から提出までを4つの工程に分け、営業・情シス・法務がそれぞれどこで線を引くかを整理します。

Conveyor は、売る側が質問票とRFPに答えるための製品

Conveyor は、2021年に米国サンフランシスコで設立された会社の製品です。創業者は医療分野向けのクラウド基盤を手がける会社を共同で立ち上げた人物で、顧客企業のセキュリティ審査を通す作業を自動化する目的で事業を始めたと報じられています。2025年6月には2,000万ドルの資金調達を発表し、その時点で400社を超える顧客がいると説明しました。まず押さえておきたいのは、買う側が委託先を審査する道具ではなく、売る側が審査に答える道具だという性格です。

製品はいくつかの部品でできています。顧客から届いたセキュリティ質問票を取り込み、出典付きで回答を埋める機能。提案依頼書などへの回答を下書きする機能。自社のセキュリティ情報を顧客が自分で閲覧できる公開ページ、いわゆるトラストセンター。そして、回答の元になる知識の置き場を点検し、古い答えや矛盾する答えを知らせる管理の機能です。公式はこれらを動かす仕組みをまとめてエージェントと呼び、知識の手入れを担う部分を「司書」にたとえています。

隣接する記事では、生成AIの利用について質問票で何を聞かれ、どんな証跡を揃えておくかを扱いました。ここではその前提の上に立ち、答える作業そのものを Conveyor に任せるとき、どこまでを機械に任せ、どこからを人に残すかに絞ります。製品の画面の操作や料金プランの比較ではなく、社内に入れてよいかを判断するための論点を、工程の順に見ていきます。

2026年の動き：RFP機能の刷新と、回答の仕組みの作り直し

9月2日、Conveyor はRFP向けの機能を新しくしたと発表しました。提案依頼書・情報提供依頼書・見積依頼書を一つの仕組みで扱い、営業が用意した案件の概要や、Salesforce にある商談の資料を読み込んだうえで回答し、自社の訴求点として決めた内容を反映するといいます。回答の長さを調整する設定、回答の前に作業の計画を示して人がコメントで直せる工程、答えられない設問を Slack で担当の専門家に回す流れも加わりました。Slack 側の担当者は、製品にログインしなくても答えられると説明しています。

続く9月10日には、回答の仕組み自体を作り直したと公表しました。従来は文書を細かく分けて検索し、設問に近い断片を言語モデルに渡す方式でした。新しい方式では、質問票全体の計画を立て、設問ごとの小さな作業に分けて調べ、答えが足りなければやり直し、最後に一つの文書に組み上げます。どの資料をどう重み付けし、どこで迷ったかを利用者が見られるようにしたとも説明しています。ただし新方式は試験提供の段階で、RFPの利用者は設定で有効にでき、質問票の利用者は担当者に相談する形です。

公式ブログは10月に入っても更新が続いており、サービスの終了や新規受付の停止を告げる案内は見当たりません。開発が速いのは利点ですが、裏を返せば回答の作り方が数か月単位で変わるということでもあります。導入後も、仕組みの変更が告知されるたびに、承認の手順や確認の範囲が今のままでよいかを見直す前提で考えておきます。

AIが入る場所は三つ：回答の下書き、知識の手入れ、顧客の窓口

Conveyor でAIが関わる場所は、大きく三つあります。一つ目は回答の下書きです。公式は、質問票の回答に出典を付け、RFPの回答には出典に加えて確信度の段階を示すと説明しています。二つ目は知識の手入れで、古い答え・矛盾する答え・重複を見つけて知らせ、人が回答を直すとその修正を再利用できる知識として蓄えます。三つ目は顧客の窓口で、トラストセンターに置いたAIが、承認済みの答えの範囲で顧客の質問に応じ、質問票まるごとの記入も引き受けるとしています。

場所	AIがすること（公式の説明）	人が決めること
回答の下書き	承認済みの文書から設問に合わせて回答を作り、出典を付ける	どの文書を正とするか、出す前に誰が確かめるか
知識の手入れ	古い答え・矛盾する答えを見つけて知らせ、人の修正を蓄える	知らせを受けて、どちらを残し、何を標準にするか
顧客の窓口	トラストセンターで、承認済みの答えの範囲で質問に応じる	窓口で答えてよい話題、資料を渡す相手の条件
他の道具からの呼び出し	Claude などから MCP を通じて回答を引き出す	社内の誰が、どの道具から引いてよいか

表のうち、とくに気をつけたいのが二つ目の知識の手入れです。人の修正が自動で知識に積み上がるのは便利ですが、特定の顧客向けに例外として書いた答えが、次の顧客への標準の答えとして再利用されるおそれがあります。公式はRFPの機能について、顧客を特定できる情報は自動で取り除くと説明していますが、例外として約束した内容そのものは残ります。どの修正を標準の答えに昇格させるかは、人が決める運用にしておく必要があります。

前提：質問票への回答は、会社の表明として読まれる

セキュリティ質問票は、買う側が委託先の安全性を確かめるための書類です。回答は審査の判断材料になり、一部は契約書の添付資料や、契約の前提として引用されることもあります。つまり回答は営業資料ではなく、会社の表明として扱われうるということを、導入の前に関係者で共有しておく必要があります。ここを共有しないまま道具を入れると、営業は速さを、情シスは正確さを、法務は言葉の強さをそれぞれ別々に気にすることになり、承認の流れが固まりません。

この性格から、誰の資格で答えるかが問題になります。AIが下書きし、営業が顧客に提出する流れでは、内容の正しさを確かめた人が誰なのかが曖昧になりがちです。提出の名義は営業でも、内容の責任は分野ごとの承認者が持つという整理にしておかないと、誤りが見つかったときに誰が顧客に説明し、誰が訂正を出すかが決まりません。

数字の読み方にも注意が要ります。公式は、回答の正確さが95%を超える顧客が多いとし、料金のページでは誤った内容を作り出す割合を1%未満と示しています。いずれも提供元の数字で、正確さの定義は公表されていません。仮に95%が正しくても、300問の質問票なら15問前後は人の手直しが要る計算になります。どの5%が誤るかは事前に分からないため、確かめる範囲を設問の重さで決めておくことが、この製品を使う前提になります。

4つの工程の全体像

ここからは、Conveyor を使って質問票に答える流れを、4つの工程に分けて見ていきます。工程の区切りは製品の画面の区切りではなく、誰が何を決め、どこで人の確認を挟むかで分けています。製品の機能が変わっても、この区切りは変わりません。

4つの工程のうち、AIが主に働くのは二つ目だけです。一つ目と三つ目と四つ目は、道具を入れる前から本来必要だった仕事で、道具を入れたことで、その仕事の抜けが目立つようになると考えたほうが実態に近いでしょう。逆に言えば、この三つの工程が回っていない会社では、AIの下書きの速さが、そのまま誤りの広がる速さになります。

工程1：根拠文書を集め、版と持ち主を決める

最初の工程は、AIに読ませる文書を集めることです。公式は、承認済みの問答集、文書（PDFや表計算のファイルなど）、過去の回答、外部の情報源の4種類を回答の元にすると説明し、問答集以外は案件ごとに使う・使わないを切り替えられるとしています。必要な問答の数は従来の製品より少なく、400組に満たない数で足りるとも主張しています。

ここで決めるのは、文書ごとの持ち主と、見直しの期限です。情報セキュリティ方針は情シス、個人情報の取り扱いは法務、障害時の対応は運用の担当、という具合に、文書ごとに更新の責任者を一人置きます。公式は情報源どうしが矛盾したときは新しいほうを優先すると説明していますが、新しい文書が正しいとは限りません。たとえば、下書きのまま共有フォルダに置かれた改訂案が、承認済みの旧版より新しい日付を持っていることがあります。

そのため、読ませる場所は承認済みの文書だけを置いた専用の場所に限ります。公式は Google Drive、SharePoint、Confluence、Notion などとの連携を案内していますが、部署の共有フォルダをまるごとつなぐのは避けます。過去の回答を元にするかどうかも慎重に決めます。過去に例外として約束した内容が、次の顧客への答えに混ざるおそれがあるからです。

• 文書ごとに、持ち主・最終承認日・次の見直し日を記録する
• 第三者認証の報告書は対象期間を確かめ、古い期間のものを最新の状態のように書かない
• 下書きや改訂案は連携先に置かない。承認と同時に専用の場所へ移す
• 自社サイトなど外部の情報源を使うなら、公開している内容と内部の文書が食い違わないか確かめる

工程2：AIに下書きさせ、出典と確信度で振り分ける

質問票やRFPを取り込むと、AIが設問を読み取り、回答を下書きします。公式は、複数のシートや結合したセルを含む表計算のファイル、文書ファイル、PDFに対応し、元の書式のまま書き出せると説明しています。RFPでは回答の前に計画を示す工程があり、ここで人が「この設問群は法務に回す」「この設問には回答しない」といった指示を入れられます。

下書きが出たら、出典と確信度で振り分けます。出典が承認済みの文書で、確信度が高い設問は抜き取りで確認します。出典が過去の回答や外部の情報源になっている設問、確信度が低い設問は、全件を担当者が確かめます。出典のない回答は、その時点では使いません。AIが出典を示していても、出典の文書に本当にそう書いてあるかを、人が開いて確かめるところまでが確認です。出典の付け方が正しくても、文書の一部だけを切り取って言い切っていることがあるためです。

公式は、話題ごとに扱い方を事前に決めておく設定を用意しており、例として情報漏えい、賠償責任、データの保管場所を挙げています。この設定を使って、重い話題の設問はAIに答えさせず、担当者に回すよう決めておけば、AIに判断させない範囲を仕組みの側で守れます。公式は人の手を介さずに回答を仕上げる運用も目指すとしていますが、導入の当初は全件確認から始め、記録を見ながら抜き取りに移すほうが安全です。

工程3：分野ごとの承認者が確かめる

振り分けた設問を、分野ごとの承認者が確かめます。Conveyor は、答えられない設問を Slack で担当者に回し、担当者はログインせずに答えられると説明しています。便利な反面、Slack のやり取りが、そのまま知識として蓄えられる点には注意が要ります。公式は、スレッドに決まった絵文字で反応すると、AIがやり取りを読んで最大10組の問答を取り出し、既存の知識と矛盾がないかを確かめて承認を求める流れを示しています。承認する人を決めておかないと、雑談の中の推測が正式な答えになりかねません。

担当	持つこと	持たないこと
営業・プリセールス	受付、期限の管理、顧客との窓口、最終版の提出	技術的な内容の正否の判断
情報システム・セキュリティ	技術的な管理策、認証、障害対応にかかわる設問の承認	契約条件や責任範囲の判断
法務	賠償、責任の範囲、個人データの扱い、契約に引用されうる表現の承認	技術的な設定値の判断
AI導入担当・知識の管理者	文書の置き場、話題ごとの設定、修正を標準に昇格させる承認	個別の設問の中身の判断

実務で揉めやすいのは期限です。営業は顧客の期限を守りたく、承認者は確認の時間がほしい。この食い違いを放っておくと、期限の直前に営業がAIの下書きをそのまま出すことになります。承認が期限に間に合わない設問は、推測で埋めずに「確認中」として出すという取り決めを、営業と承認者の間で先に結んでおきます。顧客の側も、空欄より、確認中と書かれた回答のほうが審査を進めやすいものです。

工程4：提出し、出した版を残す

承認が済んだら、元の書式で書き出して提出します。ここで必ず残すのは、どの顧客に、いつ、どの版の回答を出したかの記録です。根拠の文書が後で改訂されても、提出の時点で何を根拠に答えたかをたどれるようにしておきます。

記録が要る場面は二つあります。一つは、顧客から回答の内容について問い合わせが来たとき。もう一つは、社内の管理策が変わり、過去に出した回答が事実と合わなくなったときです。後者では、影響する顧客を洗い出し、訂正を出すかどうかを法務と判断します。訂正の要否を判断できるのは、出した版を残している会社だけです。

製品の分析機能や履歴が、提出の記録をどこまで、どれだけの期間保持するかは、契約の前に確かめます。製品の中だけに履歴を置くと、解約したときに失われるおそれがあるため、提出した最終版は社内の文書管理にも保存しておきます。営業の顧客管理の記録に、提出した日と版の番号を残しておくと、次に同じ顧客から更新版を求められたときにも差分を示しやすくなります。

約束にならない書き方を、先に決めておく

AIの下書きは、問われた設問に対して「はい」と言い切る方向に寄りがちです。Conveyor は自社の訴求点を回答に反映させる機能を前面に出しており、RFPではそれが説得力につながります。しかしセキュリティの回答では、この傾向が裏目に出ることがあります。次のような書き方は、AIの下書きでも人の手直しでも起きやすい失敗です。

• 「常に」「すべての」「例外なく」など、例外を許さない言い切り
• 予定している対策を、すでに実施しているように書く
• 認証の対象範囲に入っていないサービスや拠点まで、認証済みのように書く
• 障害時の連絡の期限を、契約で決めていない時間で約束する
• 一般論や他社の事例を、自社の実績のように書く

書き方の基準は、事実・範囲・時点の三つを必ず書くことです。何を実施しているか、どのサービスと拠点が対象か、いつ時点の状態か。この基準を問答集の書き方の決まりとして文書にし、AIの下書きにも反映させます。公式は、人の修正から文体も学ぶとしているため、導入して最初の数十件の修正の質が、その後の下書きの質を左右します。

判断が分かれやすい表現は、法務が承認した言い回しの一覧にまとめて問答集に入れておきます。そうすれば、営業が顧客ごとに言い回しを変える余地が減り、同じ問いに顧客ごとに違う強さで答えてしまう事態を防げます。

顧客に見せる窓口は、答えてよい範囲を先に絞る

トラストセンターは、自社のセキュリティ情報を顧客が自分で読めるようにする公開ページです。Conveyor はここにAIを置き、顧客が文書を探す手伝い、承認済みの質問への回答、質問票まるごとの記入までを担うとしています。質問票が届く前に顧客が自分で答えを見つけられれば、営業と情シスの往復が減り、審査の期間も短くなります。

一方で、顧客がAIに自由に質問できる窓口は、社内の誰も確かめていない答えが、そのまま社外に出る仕組みでもあります。公式は承認済みの質問に答えるとしていますが、言い回しを変えた質問にどこまで同じ答えを返すかは、試してみないと分かりません。導入の当初は、窓口で答える話題を限り、それ以外は営業への問い合わせに誘導する設定から始めます。

第三者認証の報告書や侵入試験の要約など、秘密保持契約を結んだ相手にだけ渡す資料の扱いも決めておきます。誰が閲覧を承認するか、承認の記録を残すか、閲覧の期限を付けるか。資料を渡すかどうかの判断は、AIではなく人が持つことを、窓口の運用規程に明記しておきます。

何が社外に出るか：回答の元になる文書の流れ

Conveyor が公開しているセキュリティ情報によると、問答集・文書・質問票の内容は、同社が契約する言語モデルの提供会社と、文書を検索するためのデータベースの提供会社で処理されます。言語モデルの提供会社としては、OpenAI、Anthropic、Google の3社が委託先に挙がっています。顧客のデータは米国に保管され、推論の処理は提供会社の世界中の通信網を一時的に通ることがあるものの、米国の外で保管されることはないと説明しています。

ここで考えるべきは、回答の元になる文書そのものが機密だという点です。情報セキュリティの規程、ネットワーク構成の説明、事故対応の手順書は、攻撃する側にとって価値のある情報です。どの文書まで読ませるかを決め、構成図や管理画面の設定値などは読ませないか、伏せた版を用意します。質問票そのものにも顧客の社名や取引の情報が含まれることがあるため、取り込む前に、顧客との秘密保持契約で第三者の道具に入れてよいかを確かめます。

同社は第三者評価の報告書（SOC2 タイプ2）を公開ページで示し、データ処理の契約を結ぶ用意があり、求めに応じてデータを削除するとしています。導入の前には、言語モデルの提供会社が入力を学習に使わない取り決めになっているかを契約書類で確かめ、社内の委託先の管理台帳に載せます。質問票に答える道具そのものが、自社の委託先として質問票の対象になる、という点も忘れないでおきます。

費用の増え方と、やめ方

公式の料金ページは、利用者の人数ではなく利用量で課金すると説明しています。人数ごとの料金、連携の追加料金、追加機能の料金はないとし、無料の枠ではトラストセンター用のクレジットが月10回分付く一方、質問票の自動回答と連携は含まれません。企業向けは個別の見積もりで、使った分だけ払い、量に応じた割引があるとしています。何が利用量として数えられるかの詳細は、公開ページからは読み取れませんでした。

利用量で増える型では、質問票が増えるほど費用も増えることになります。営業の案件が伸びた年に費用が想定を超えないよう、年間の質問票とRFPの件数、トラストセンターの利用の見込みを、営業の計画から見積もっておきます。人数で増えない分、承認者を広く招きやすいのは利点です。公式は、過去の質問票や見本の文書を送って精度を試す試用の流れも用意しているため、見積もりと合わせて試用で効果を確かめるのが順当です。

やめ方も先に決めます。蓄えた問答集、修正の履歴、提出の記録を、どの形式で取り出せるか。トラストセンターを閉じるとき、顧客に案内していた公開ページの住所をどうするか。知識の蓄積が製品の中にしかない状態を作らないために、問答集の正本は社内にも置いておきます。

日本の会社が使うときに確かめること

公式は50を超える言語に対応すると説明していますが、日本語の質問票での精度は公表されていません。日本の質問票は、表計算のシートに独自の様式で設問が並び、記号や備考欄で答える形式が多く見られます。自社に届いた過去の質問票を数件使い、試用で読み取りと回答の質を確かめるのが確実です。

根拠の文書が日本語で回答が英語、あるいはその逆という組み合わせも起こりえます。翻訳を挟んだ回答は、言い回しの強さが変わることがあります。日本語の「努めています」が英語で断定に近い表現になる、といったずれです。海外の顧客向けの回答は、英語を読める承認者が確かめる体制にしておきます。

国内では、経済産業省がサプライチェーンのセキュリティ対策を段階で評価する制度づくりを進めており、取引先から求められる回答の形が今後そろっていく可能性があります。制度の詳細は隣接する記事に譲りますが、回答の根拠文書を制度の項目に沿って整理しておけば、道具を変えても使い回せます。また、調べた範囲では Conveyor の国内の取扱会社は確認できませんでした。契約・請求・問い合わせは英語で米国の会社と行う前提で、障害時の連絡の時間帯も含めて確かめておきます。

よくある質問

届く質問票が月に数件でも、入れる意味はありますか

件数が少ないうちは、道具より先に、根拠文書の置き場と承認者を決めるほうが効果があります。工程1と工程3が回っていれば、件数が増えた時点で道具を入れても混乱しません。無料の枠でトラストセンターだけを先に試し、質問票の前に顧客が自分で答えを見つけられるかを見る使い方もあります。

AIの下書きをそのまま出してよい設問はありますか

導入の当初はありません。全件を確かめ、記録を見ながら、承認済みの文書が出典で誤りのなかった設問の種類から抜き取りの確認に移します。情報漏えい、賠償、データの保管場所のような重い話題は、慣れてからも人が確かめる対象に残します。

ほかのAIから MCP で回答を引けるのは便利ですか

公式は、Claude の中から MCP を通じて回答を引けると説明しています。営業が手元のAIで答えを探せる反面、承認の流れの外で回答が使われるおそれがあります。引ける人と用途を限り、引いた回答を顧客に出す場合も工程3を通す決まりにします。

買う側の審査にも使えますか

同社は委託先を審査する側の製品も別に示していますが、この記事で扱った機能は答える側のものです。買う側の審査に使う場合は、相手の回答をAIで要約して判断を任せないこと、適用範囲と日付を人が読むことが前提になります。

まとめ

Conveyor は、売る側がセキュリティ質問票やRFPに答えるための製品で、承認済みの文書から出典付きで下書きし、確信度の低い設問は担当者に回す作りです。2026年9月にはRFPの機能と回答の仕組みを作り直し、開発は活発に続いています。ただし、回答は会社の表明として読まれる文書です。根拠文書の持ち主と見直しの期限を決め、出典と確信度で振り分け、分野ごとの承認者が確かめ、出した版を残す。この4つの工程のうちAIが主に働くのは一つだけで、残りは人が決める仕事です。重い話題はAIに答えさせず、約束にならない書き方を先に決め、社外に出る文書の範囲と費用の増え方、やめ方まで確かめてから、社内に入れるかを判断してください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。