▼ この記事の内容
AI搭載FAQシステムは、定型質問への回答候補を出す仕組みです。ただし、FAQ、RAG、チャットボット、有人確認の役割を分け、回答根拠・回答不可条件・更新責任を先に決めないと運用で失敗します。
実務上の課題を考えると、導入前の誤回答テストでは、既存FAQと問い合わせ履歴から30問程度を選ぶと確認しやすくなります。AI搭載FAQシステムは便利ですが、最初に試すべきなのは機能数ではなく、答えさせてよい質問と止める質問の切り分けです。
判断の背景を示す例として、FAQ、チャットボット、RAG、社内ナレッジAIの違いが曖昧なまま比較すると、製品資料を見ても判断が止まります。古いFAQや未承認メモまでAIが参照すると、自然な文章の誤回答が現場の確認負荷を増やします。
この記事では、AI搭載FAQシステムの仕組みと、RAG・チャットボット・有人対応との違いを整理します。読み終えると、答えさせる質問と止める質問を分けるための確認項目が分かります。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
AI搭載FAQシステムとは何か
AI搭載FAQシステムは、登録済みのFAQや関連ナレッジをもとに、利用者の質問へ回答候補を返す仕組みです。導入判断では、回答精度だけでなく、回答根拠、更新責任、回答できない質問の扱いまで確認する必要があります。
AI搭載FAQシステムの定義
AI搭載FAQシステムとは、承認済みFAQや社内ナレッジを参照し、質問文のゆれを読み取って回答候補を返す仕組みです。 従来のFAQは、利用者がカテゴリやキーワードから回答を探す設計が中心でした。AIを組み込むと、表現が少し違う質問でも近い回答を候補として提示します。
導入効果を考えるときは、問い合わせを減らす道具としてだけ見ないほうがよいです。CSや情シスでは、誰が承認した回答なのか、いつ更新された情報なのかを確認できる設計が欠かせません。
営業改善プログラム「FAZOM」で重視するAI FAQの判断軸は、回答候補を出す力だけではありません。承認済みナレッジ、回答根拠、回答不可制御を分けて設計すると、現場が安心して使える範囲を決めやすくなります。
AI搭載FAQシステムの定義では、判断条件、関係者、確認データ、運用会議で見る指標をそろえると、自社で再現しやすい改善項目へ落とし込めます。
AI搭載FAQシステムの定義を運用へ落とし込む際は、判断条件、関係者、確認データ、会議で見る指標をそろえます。確認結果を担当者と期限に結び付け、次回会議で更新状況を見直すと、改善を継続しやすくなります。
従来FAQとの違いは回答候補の出し方にある
従来FAQとAI搭載FAQシステムの違いは、登録された回答を探すだけか、質問意図に近い回答候補まで提示するかにあります。 従来FAQでは、表記ゆれや言い換えに弱く、利用者が正しいキーワードを知らないと回答に届きにくくなります。AI搭載FAQでは、質問文の意味を読み取り、近いFAQや関連文書を候補として返します。
一方で、AIが回答候補を出すほど、根拠の見えにくさも問題になります。営業支援や社内問い合わせでは、古い規程や未承認メモを根拠にした回答が出ると、現場の判断を誤らせます。
この違いを整理するには、回答の出し方を3つに分けると判断しやすくなります。固定FAQで返す回答、AIが候補提示する回答、人が確認する回答を分けると、任せる範囲を説明しやすくなります。
従来FAQとの違いは回答候補の出し方にあるでは、判断条件、関係者、確認データ、運用会議で見る指標をそろえると、自社で再現しやすい改善項目へ落とし込めます。
従来FAQとの違いは回答候補の出し方にあるを運用へ落とし込む際は、判断条件、関係者、確認データ、会議で見る指標をそろえます。確認結果を担当者と期限に結び付け、次回会議で更新状況を見直すと、改善を継続しやすくなります。
AI FAQでできることと任せすぎてはいけないこと
AI FAQでできることは、定型質問の検索負荷を下げ、表現ゆれのある質問から近い回答候補へ案内することです。 よくある問い合わせでは、利用者が正式な用語を知らないまま質問します。AI搭載FAQシステムは、質問文と登録済みナレッジの近さを見て、該当しそうな回答を提示します。
任せすぎてはいけないのは、契約条件、料金判断、権限変更、クレーム対応のように責任が重い回答です。こうした質問は、AIが候補を出す場合でも、回答不可や有人確認に回す条件を先に決める必要があります。
GoogleのAI機能に関する公式説明でも、AI向けの特別な最適化より、Search Essentialsなど既存要件を満たすことが前提とされています。AI FAQも同じで、特別な機能名より、根拠が追える1つの回答設計を先に整えるべきです。
参考：AI features and your website｜Google Search Central
AI FAQでできることと任せすぎてはいけないことでは、判断条件、関係者、確認データ、運用会議で見る指標をそろえると、自社で再現しやすい改善項目へ落とし込めます。
関連する設計を整理する際は、セールステックの領域別整理も確認すると、本記事の論点を実務に落とし込みやすくなります。
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
FAQ・チャットボット・RAG・社内ナレッジAIの違い
FAQ、チャットボット、RAG、社内ナレッジAIは、同じ問い合わせ対応に見えても回答責任が異なります。比較するときは、機能名ではなく、誰が承認した情報を、どの根拠で、どこまで自動回答するかで分ける必要があります。
FAQは承認済み回答を固定して返す仕組み
FAQは、事前に承認した質問と回答を固定して返す仕組みです。回答内容が変わりにくい手続き、料金条件、利用ルールなどに向いています。
CSや営業支援の現場では、同じ質問に毎回違う説明をすると、顧客対応の品質がぶれます。FAQに固定する回答は、担当者の判断ではなく、組織として承認した内容にそろえる必要があります。
よくあるケースとして、契約更新の手順や問い合わせ窓口の案内はFAQに向いています。個別契約の例外や値引き判断までFAQで返すと、現場確認が必要な領域まで自動化してしまいます。
FAQをAI化する場合も、固定すべき回答を曖昧にしないことが前提です。承認済み回答の範囲を先に決めると、次に会話導線や文書参照をどこまで任せるかを判断しやすくなります。
チャットボットは会話導線と受付の役割が強い
チャットボットは、利用者の質問を会話形式で受け取り、適切な案内先へ振り分ける仕組みです。回答そのものより、入力補助、受付、一次切り分けの役割が強くなります。
FAQが承認済み回答の保管場所だとすれば、チャットボットは利用者を回答へ案内する窓口です。質問文が曖昧な場合でも、選択肢や追加質問で意図を絞り込めます。
社内問い合わせでは、情シス、総務、人事への質問が混在しがちです。チャットボットでカテゴリを先に分けると、回答できる質問と担当者へ回す質問を切り分けやすくなります。
一方で、チャットボットに回答責任まで持たせると、古いFAQや未承認情報を案内するリスクが残ります。受付導線と回答根拠を分けて設計すると、RAGや社内ナレッジAIとの違いが明確になります。
RAGは社内文書から回答を補完する仕組み
RAGは、社内文書やFAQを検索し、その情報をもとにAIが回答を補完する仕組みです。検索と生成の2つの処理を組み合わせるため、参照元の整備が回答品質を左右します。
FAQだけでは拾えない質問でも、マニュアル、議事録、仕様書に答えが残っている場合があります。RAGはその情報を探して回答に反映しますが、文書が古ければ古い情報を拾います。
営業チームでは、顧客別の提案条件や契約条件が資料ごとに分かれていることがあります。RAGで補完する場合は、参照してよい文書、権限、更新日を確認しないと、回答の根拠を説明しにくくなります。
RAGはFAQの代替ではなく、FAQで固定できない情報を補う選択肢です。変更頻度が高い情報を扱うほど、回答前に根拠を表示し、人が確認する条件を決める必要があります。
参考：Retrieval Augmented Generation in Azure AI Search｜Microsoft Learn
社内ナレッジAIは根拠・権限・更新運用まで含めて考える
社内ナレッジAIは、FAQ、文書、問い合わせ履歴などを横断し、業務に必要な回答を支援する仕組みです。回答文だけでなく、根拠、閲覧権限、更新責任まで設計します。
営業やCSの現場では、同じ質問でも顧客種別や契約条件によって回答が変わります。社内ナレッジAIを使う場合は、誰に見せてよい情報かを先に分ける必要があります。
支援先の一例では、FAQと営業資料を同じ検索対象に入れる前に、承認済み情報と下書き情報を分けて整理しました。現場担当者は回答案をそのまま送らず、根拠リンクを確認してから顧客へ案内する運用にしました。
営業改善プログラム「FAZOM」では、確認済みナレッジを前提に、回答根拠と回答不可条件を設計します。方式ごとの詳しい違いは、回答責任で分ける比較軸を確認すると整理しやすくなります。
社内ナレッジAIを検討するときは、機能数よりも運用条件を見ます。次の判断では、FAQで固定する回答、RAGで補完する回答、人が確認すべき回答を分けることが必要になります。
FAQで固定する回答とRAGで補完する回答を分ける
AI搭載FAQシステムの導入では、すべての質問をAIに任せるのではなく、回答の変わりやすさと責任の重さで扱いを分けます。FAQで固定する回答、RAGで補完する回答、有人確認へ回す回答を分けると、誤回答リスクを説明しやすくなります。
変更が少ない定型質問はFAQで固定する
変更が少ない定型質問は、AIに自由回答させず、承認済みFAQとして固定するのが適しています。窓口案内、手続き順、基本ルールなどは回答を統一すべき領域です。
FAQで固定する利点は、回答内容の責任者を明確にできることです。CSや情シスでは、誰が承認した回答なのかを追えるだけで、現場の確認負荷が下がります。
判断に迷う場合は、変更頻度、個別条件、誤回答時の影響で分けます。固定FAQは、回答を速くするためだけでなく、組織として同じ説明を返すために使います。
営業やCSでよくある問い合わせでも、基本手続きはFAQ化し、個別条件は別扱いにします。固定できる回答を先に固めるほど、RAGや有人確認へ回す範囲も明確になります。
部署や契約条件で変わる質問はRAGだけに任せない
部署や契約条件で回答が変わる質問は、RAGだけに任せると判断の責任が曖昧になります。RAGは文書を探して回答を補いますが、正しい判断者までは自動で決めません。
社内ナレッジには、古い提案書、下書き、担当者メモが混在することがあります。参照してよい文書を分けないままRAGを使うと、未承認情報を根拠にした回答が出る可能性があります。
支援先の営業現場でも、顧客別の契約条件と標準ルールが同じ検索対象に入ると、回答確認に時間がかかります。RAGで補う場合は、文書の更新日、閲覧権限、承認状態を先に分ける必要があります。
責任が重い回答は有人確認へ回す
返金、契約変更、法務確認、クレーム対応のような責任が重い回答は、有人確認へ回すべきです。AI FAQは回答候補を出せても、最終判断の責任までは引き受けられません。
導入時に失敗しやすいのは、回答できない質問までAIに答えさせる設計です。利用者にとって自然な文章でも、根拠が弱い回答や例外条件を含む回答は現場リスクになります。
有人確認へ回す条件は、曖昧な不安ではなく業務ルールとして決めます。金額、契約、個人情報、法務、クレーム、権限変更に関わる質問は、自動回答を止める候補になります。
このリストは、AIを止めるためではなく、安心して任せる範囲を決めるために使います。自動回答と有人確認の境界を先に決めると、次のセクションで扱う誤回答対策も設計しやすくなります。
AI FAQで失敗しやすいパターン
AI FAQの失敗は、AIの性能不足だけで起きるものではありません。古いFAQ、根拠不明回答、回答不可条件の未設計、更新責任の空白が重なると、現場で使われない仕組みになります。
導入前は、回答精度を約束するよりも、誤回答が起きる条件を先に洗い出す必要があります。特にCS、情シス、営業支援の部門では、回答の正しさを誰が保証するかまで決めることが欠かせません。
| 失敗パターン | 起きる原因 | 導入前の確認項目 |
|---|---|---|
| 古いFAQを参照する | 更新日や承認状態を見ずに回答候補へ使う | 利用可能なFAQを承認済み情報に限定する |
| 回答根拠が見えない | 参照元や判断理由を現場が確認できない | 回答ごとに根拠資料を確認できる設計にする |
| 不確かな回答を出す | 回答不可条件と有人確認の分岐がない | 答えない質問と人へ回す条件を決める |
| FAQが育たない | 更新責任者とレビュー周期が決まっていない | 未解決質問と更新リードタイムを追う |
失敗パターンを分けると、見るべき機能は検索精度だけではなくなります。回答根拠、回答不可制御、更新運用の3点を確認すると、導入後の責任範囲を説明しやすくなります。
古いFAQをAIが参照して誤回答する
古いFAQを参照したAI回答は、利用者にとって自然に見えても業務判断を誤らせます。料金、契約条件、手続き名が変わる領域では、更新日と承認状態を見ない回答設計は避けるべきです。
FAQは一度作ると残り続けるため、棚卸しをしないままAIの回答候補に入れると危険です。特にCSでは、過去のキャンペーン条件や旧プラン名が残るだけで、顧客への案内が食い違います。
導入前には、既存FAQを有効、要修正、廃止の3区分で整理します。廃止候補をAIの参照範囲から外すだけでも、古い情報を根拠にした回答を減らしやすくなります。
回答根拠が見えず現場が確認できない
回答根拠が見えないAI FAQは、現場担当者が顧客や社内利用者へ説明できません。自然な回答文だけでは、正しい資料に基づく回答かどうかを判断できないためです。
自然な回答文は便利ですが、根拠がなければ担当者は別の資料を探し直します。これでは問い合わせ対応の時間は短くならず、AI回答を信用してよいかを毎回確認する運用になります。
回答根拠を残すには、FAQ本文、参照資料、更新日、承認者をひもづけておく必要があります。AIの誤回答リスクを深掘りしたい場合は、ハルシネーション対策で見るべき回答根拠の設計も確認すると、社内説明の論点を整理できます。
回答不可にできず不確かな回答を出す
AI FAQは、答える条件だけでなく答えない条件を決めないと誤回答を広げます。個別契約、例外対応、未承認情報に関わる質問は、人が確認する分岐を先に設計すべきです。
利用者は、AIが丁寧な文章で返すと正しい回答だと受け取りやすくなります。だからこそ、情報が足りない質問では回答を作らず、確認先を示す動きが必要になります。
よくある失敗は、不明な質問にも近いFAQを無理に当てる設計です。営業部門なら個別値引き、CSなら契約例外、情シスなら権限変更のように、回答責任が重い質問を分けます。
導入前の誤回答テストでは、既存FAQと問い合わせ履歴から30問程度を選ぶと確認しやすくなります。回答できる質問、回答不可にする質問、有人確認へ回す質問を分けると、運用条件が明確になります。
更新責任者が決まらずFAQが育たない
更新責任者が決まっていないAI FAQは、導入直後だけ使われても継続利用されません。問い合わせ内容、商品仕様、社内ルールが変わるたびに、回答候補を見直す担当が必要です。
FAQは公開して終わる情報ではありません。未解決質問、低評価回答、有人対応へ回った質問を定期的に見直し、FAQ本文や回答不可条件へ反映することで精度を保ちます。
責任者を決めるときは、情シスだけに任せず、回答内容を持つ部門を巻き込みます。CSならサポート責任者、営業なら営業企画、社内FAQなら人事や総務が承認に関わる形が現実的です。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
AI FAQシステムを選ぶ前のチェックリスト
AI FAQシステムを選ぶ前に確認すべき対象は、機能数ではなく運用条件です。既存FAQ、問い合わせ履歴、承認済みナレッジ、更新責任、成果指標を先に整理すると、導入後の誤回答リスクを下げやすくなります。
製品比較に進む前の棚卸しが弱いと、AIに任せる範囲と人が確認する範囲が曖昧になります。CS、情シス、営業支援の現場では、回答の速さだけでなく、誰が根拠を確認するかまで決める必要があります。
既存FAQと問い合わせ履歴を棚卸しする
既存FAQと問い合わせ履歴の棚卸しは、AI FAQシステム選定の最初に行う作業です。AIに読ませる情報を決める前に、残すFAQ、直すFAQ、外すFAQを分けます。
FAQは公開後も残りやすく、旧料金、旧手続き、終了したキャンペーン条件が混ざることがあります。問い合わせ履歴と照合すると、今も聞かれる質問と、過去だけの質問を分けられます。
棚卸しでは、質問文、回答本文、更新日、承認者、問い合わせ件数を確認します。比較検討が進んでいる場合は、FAQシステム比較で見るべき選定軸も合わせて整理すると、製品ごとの確認項目をそろえやすくなります。
承認済みナレッジと未承認情報を分ける
AI FAQに使う情報は、承認済みナレッジと未承認情報に分ける必要があります。下書き、担当者メモ、古い提案資料を同じ検索対象に入れると、回答責任が曖昧になります。
営業やCSでは、顧客別の例外対応や一時的な運用メモが残りがちです。便利そうに見える情報でも、承認されていない内容をAI回答に使うと、現場が根拠を説明できません。
確認項目は、承認者、公開範囲、最終更新日、利用してよい部署の4つです。特に社内FAQでは、人事、総務、情シスのように回答責任を持つ部門ごとに承認ルールを分けます。
未承認情報を完全に捨てる必要はありません。まずはAI回答に使わない領域へ分け、正式承認後にFAQへ戻す流れを決めると運用が止まりにくくなります。
回答責任者・更新頻度・権限を決める
回答責任者、更新頻度、閲覧権限は、AI FAQシステムの導入前に決めるべき運用条件です。担当が曖昧なまま始めると、FAQは更新されず、古い回答が残ります。
情シスだけに運用を寄せると、回答内容の正しさを判断できない場面があります。CSならサポート責任者、営業なら営業企画、社内FAQなら各制度の所管部門が承認に関わる形が現実的です。
導入前チェックでは、次の項目を最小限そろえます。誰が直すか、いつ見直すか、誰に見せるかを決めると、AI回答の責任範囲が明確になります。
チェックリストは、運用を重くするためのものではありません。自動回答できる領域を安心して広げるために、回答責任と権限を先に固定します。
自己解決率だけでなく未解決質問と更新リードタイムを見る
AI FAQの成果指標は、自己解決率だけで判断しないことが必要です。未解決質問率、回答根拠率、更新リードタイムを合わせて見ると、運用改善につながる課題を見つけやすくなります。
自己解決率だけを追うと、利用者が本当に解決したのか、諦めて離脱したのかを見誤る場合があります。未解決質問や有人対応へ回った質問を見れば、FAQに追加すべき内容が分かります。
成果指標は、問い合わせ削減率の約束ではなく、改善すべき場所を特定するために使います。問い合わせ対応全体の効率化を考える場合は、ヘルプデスク効率化で見るKPI設計も確認すると、測定範囲を広げやすくなります。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
導入前に確認すべき質問
AI FAQシステムの導入前には、製品名や料金より先に、自社の回答運用を質問で点検する必要があります。既存FAQ、回答不可条件、更新責任者、成果指標が曖昧なままでは、AIに任せる範囲を説明できません。
確認質問は、社内稟議やサービス資料の比較にも使えます。CS、情シス、営業支援の関係者が同じ質問に答えられる状態を作ると、導入後の手戻りを減らしやすくなります。
既存FAQは承認済み情報だけで構成されているか
既存FAQが承認済み情報だけで構成されているかは、AI FAQ導入前の最初の確認質問です。未承認メモや古い回答が混ざると、AIの回答候補にも誤りが入り込みます。
FAQの量が多いほど安心とは限りません。旧料金、終了したキャンペーン、担当者だけが知る例外対応が残っていると、利用者には自然でも現場では使えない回答になります。
確認する項目は、回答本文、最終更新日、承認者、公開範囲の4つです。顧客向けFAQならCS責任者、社内FAQなら制度を持つ部門が承認しているかを見ます。
承認済みか判断できないFAQは、すぐにAIへ読ませないほうがよいです。まずは保留領域へ分け、問い合わせ履歴と照合してから修正対象に戻すと、回答根拠を説明しやすくなります。
回答不可にする条件は決まっているか
回答不可にする条件が決まっていないAI FAQは、不確かな質問にも近い回答を返しやすくなります。個別契約、例外対応、権限変更、未承認情報は、人へ回す条件を先に決めます。
利用者は、AIが丁寧に返した文章を正しい回答として受け取りがちです。だからこそ、情報が足りない質問では回答を作らず、確認先や有人対応へつなぐ設計が必要です。
導入前には、既存FAQと問い合わせ履歴から30問程度を選び、誤回答テストに使います。回答できる質問、回答不可にする質問、担当者確認へ回す質問を分けると、運用条件が見えます。
更新責任者とKPIは決まっているか
更新責任者とKPIが決まっていないAI FAQは、導入直後だけ使われても改善が続きません。未解決質問、回答根拠率、更新リードタイムを見ながら、FAQを育てる担当が必要です。
自己解決率だけを見ると、利用者が解決したのか、諦めて離脱したのかを判断しにくくなります。有人対応へ回った質問や低評価回答を見れば、直すべきFAQを見つけやすくなります。
KPIは、削減率を約束するためではなく、改善の順番を決めるために使います。CSなら未解決質問率、情シスなら権限関連の再問い合わせ、営業支援なら回答根拠率を確認します。
更新責任者は、ツール管理者だけに置かないほうがよいです。回答内容を持つ部門と運用担当が一緒にレビューすると、古いFAQを放置しにくくなります。
サービス資料で運用条件を確認する
サービス資料を見る前に、既存FAQ、回答不可条件、更新責任者、KPIを自社の言葉で整理しておく必要があります。確認項目がそろうと、機能比較ではなく運用条件の比較ができます。
比較検討の場では、AIが何を返せるかだけに注目しやすくなります。実際には、どの情報を読ませるか、どこで止めるか、誰が直すかまで確認しないと導入判断は固まりません。
営業改善プログラム「FAZOM」では、確認済みナレッジを前提に、回答根拠や回答不可条件を設計します。精度を保証する表現ではなく、現場が説明できる運用条件として整理するのが前提です。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
よくある質問
AI搭載FAQシステムとチャットボットの違いは何ですか
FAQは承認済み回答を固定して返す仕組みです。チャットボットは会話形式で質問を受け、案内先や受付を切り分ける役割が強くなります。具体的な進め方は組織の現状に応じて調整します。
FAQシステムにAIを入れると誤回答はなくなりますか
誤回答が完全になくなるとは言えません。回答根拠、承認済みナレッジ、回答不可条件、有人確認の分岐を設計すると、運用上のリスクを下げやすくなります。まずは現状の課題を整理することから始めます。
AI FAQを導入する前に何を準備すべきですか
既存FAQ、問い合わせ履歴、承認済み情報、更新責任者、成果指標を準備します。特に、AIに読ませる情報と人が確認する質問を分けることが重要です。定着には週次での振り返りが効果的です。
まとめ
AI搭載FAQシステムは、問い合わせ対応を速くするだけの道具ではありません。承認済みFAQ、RAGで補う文書、有人確認へ回す質問を分けることで、現場が説明できる回答運用に近づきます。
比較時は、機能数や回答の自然さだけで判断しないことが重要です。回答根拠、回答不可制御、更新責任者、未解決質問や更新リードタイムまで確認すると、導入後に改善すべき場所が見えます。 製品比較を進める場合は、FAQシステム比較で見るべき選定軸も合わせて確認すると、AI FAQの運用条件と機能比較を分けて整理できます。
回答範囲を決めないままAI FAQを導入すると、古いFAQの参照、根拠不明回答、回答不可条件の抜けが後から問題になります。担当者は、便利なはずのAI回答を毎回確認し直し、結局は問い合わせ対応の手戻りを抱えることになります。
既存FAQや問い合わせ履歴から、AIに任せる回答と人が確認すべき回答を分けたい方は、営業改善プログラム「FAZOM」の資料をご確認ください。回答根拠と更新運用の論点を先にそろえることで、社内説明の準備を進めやすくなります。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
