▼ この記事の内容
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
RAGシステムは、検索した根拠を生成AIの回答に組み込む仕組みです。導入前は承認済みナレッジ、権限、更新運用、回答不可制御、評価指標を決め、PoCで誤案内しやすい質問への回答可否と根拠提示を確認します。
社内文書を読み込ませれば正確に答えると思って導入すると、古い手順、権限外情報、未承認の草案まで回答に混ざることがあります。現場が毎回確認する状態になると、自動化したはずの問い合わせ対応が別の確認業務に変わります。
この記事では、RAGシステムの仕組みを技術定義だけでなく、承認済みナレッジ、権限、更新運用、回答不可制御、評価指標まで含めて整理します。自社で使うべき場面と、導入前に確認すべき論点を判断できます。 読み終えるころには、RAGを入れるかどうかだけでなく、PoC前に社内で何を合意すべきかまで説明できるはずです。
RAG導入前に、回答根拠と更新運用を整理しておきましょう。
RAGシステムとは何か
RAGシステムは、取得した根拠を生成AIの回答に組み込む仕組みです。業務で使う場合は、承認済みナレッジ、権限、更新運用、回答不可条件まで含めて設計します。
RAGシステムは、社内文書や外部知識から必要な根拠を取得し、その内容を生成AIの回答に渡す仕組みです。LLMだけで答えさせず、業務利用では回答前に参照元を確認します。
通常のLLMは、学習済みの知識と入力文から回答を作ります。2020年に公開されたRAGの原典論文では、取得した文書を使う2種類の生成方式が示されています。
ただし、RAGを入れれば自動で正確になるわけではありません。対象文書が古い場合や、承認前の情報が混ざる場合は、もっともらしい誤回答が残ります。
社内FAQや顧客対応で使うなら、RAGは技術ではなく回答責任の設計として扱う必要があります。根拠、更新日、回答できない条件を先に決めると、次の比較も判断しやすくなります。
参考：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks｜arXiv
LLM、検索、チャットボットとの違い
LLM、検索、チャットボット、RAGは、同じ質問応答に見えても役割が違います。RAGは根拠を取得し、その内容を生成AIの回答に組み込む中間の仕組みです。
検索は、関連しそうな文書やページを一覧で返します。利用者が根拠を読み、どの情報を信じるかを自分で判断するため、回答文そのものは生成しません。
チャットボットは、対話UIで問い合わせを受け付ける入口です。シナリオ型なら固定回答へ誘導し、生成AI型でも根拠取得や権限制御がなければRAGとは言えません。
違いを整理すると、RAGの論点は画面ではなく回答の作り方にあります。社内導入では、どの仕組みを入れるかより、どの情報を根拠として使わせるかが判断軸になります。
表で見ると、RAGは単独の画面や製品名ではなく、取得と生成をつなぐ回答方式です。次に見るべき点は、その方式がなぜ社内ナレッジ活用で必要とされるかです。
社内ナレッジ活用で注目される理由
RAGが社内ナレッジ活用で注目される理由は、社内文書の量が増えるほど人だけで探し切れなくなるためです。各部門では、最新版の手順や回答根拠をすぐ確認する必要があります。
弊社が支援したフードサービス企業では、重要商談がエリアマネージャー個人に偏り、判断材料が共有されない状態から、チームで扱える情報へ整理したことで成果が42%改善（フードサービス企業での導入事例）しました。RAGでも、AIへ渡す前に、個人の経験や未承認メモを承認済みナレッジへ分ける工程が必要です。
【専門家の見解｜弊社支援現場】
AIや新しい管理手法を入れる場面では、現場が監視されると受け取ることがあります。最初から全員利用を求めず、使う目的と扱う情報を分けて説明するほうが定着しやすくなります。この不安は、RAGでも起きます。
社内文書を参照対象にするほど、誰の情報を、どの部署に、どの範囲で見せるのかという権限設計が避けられません。RAGシステムは、社内の知識をAIに読ませるだけの仕組みではありません。承認済み情報を整え、根拠を示し、人へ戻す条件を決めることで、回答生成の基本構成を検討できます。
関連する設計を整理する際は、セールステックの領域別整理も確認すると、本記事の論点を実務に落とし込みやすくなります。
回答が生成される基本構成
RAGの回答は、文書整備、分割、埋め込み、検索、再ランキング、生成、根拠提示、評価の連鎖で作られます。検索と生成だけを整えても、業務で使う回答品質は安定しません。
文書を分割して検索できる形にする
RAGの最初の工程は、文書を質問に対応しやすい単位へ分けることです。長い資料をそのまま渡さず、検索で取り出せる粒度に整えます。
営業資料なら、料金、導入条件、禁止表現、事例、FAQを同じ塊にしないほうが扱いやすくなります。内容が混ざるほど、質問に合う根拠だけを取り出しにくくなります。
分割後は、各文書にタイトル、版、更新日、承認者、閲覧権限を付けます。メタ情報がないと、最新版と古い草案をAIが区別しにくくなります。
文書整備は技術作業に見えて、実際には業務情報の棚卸しです。回答に使ってよい情報だけを残すほど、後工程の検索と生成が安定します。
関連する根拠を探して回答に渡す
RAGは、利用者の質問に近い文書片を検索し、LLMへ渡して回答を作ります。取得した根拠の質が低い場合、生成文だけを直しても誤回答は残ります。
検索では、キーワード一致だけでなく意味の近さも使われます。社内用語と質問文の表現が違っても、同じ概念を含む文書へ届く設計が必要です。
弊社の支援現場では、練習画面と本番画面を近づけたことで、使う場面の切り替え負荷が下がりました。RAGでも、検索と回答を業務画面から切り離しすぎない設計が有効です。
根拠を探す工程では、採用する文書だけでなく採用しない文書も決めます。権限外、期限切れ、未承認の情報を回答に渡さないことが、実務利用の前提になります。
根拠提示と評価までが構成に含まれる
RAGの構成は、回答を作るところで終わりません。根拠提示、回答不可、有人確認、評価指標まで含めると、業務で使う判断材料になります。
根拠URLや文書名が表示されない回答は、現場が確認できません。営業やCSが顧客対応で使うなら、回答文よりも根拠の追跡性が先に問われます。
構成要素は、次の観点で確認すると漏れを減らせます。生成AIの性能だけでなく、前後の運用責任まで同じ表で見ます。表の中で最初に固めるべきなのは、文書と評価です。
営業改善プログラム「FAZOM」では、この状態を『確認済みナレッジ設計』と呼びます。回答元にしてよい文書、見せてよい利用者、回答できない質問、改善に使う指標を先に分ける設計を指します。
回答前の根拠と回答後の採点がなければ、RAGの向き不向きも判断しにくくなります。ここまで整えると、RAGは単なる検索付きチャットではなくなります。次のセクションでは、どの業務に向き、どの業務では人の判断を残すべきかを分けます。
有効な業務と向かない業務
RAGは、承認済みナレッジを参照して回答する業務に向いています。最新判断、例外対応、責任判断が多い業務では、人の確認へ戻す条件が必要です。
社内FAQや手順回答には向いている
RAGは、社内FAQ、手順書、規程、商品説明など、回答元が決まっている質問に向いています。質問の言い回しが違っても、根拠文書に戻れるためです。
よくあるケースとして、CSが契約条件を確認したり、営業が提案前に禁止表現を確認したりします。回答の根拠と更新日が見えると、現場は確認してから使えます。
向く業務の条件は、正解が文書化されていることです。担当者の経験だけに依存する判断や、相手の状況で結論が変わる相談は、RAGだけで完結させないほうが堅実です。
例外判断や責任判断は人に戻す
RAGは例外判断や責任判断を代替する仕組みではありません。契約例外、顧客への謝罪、法務確認、値引き判断のような領域は、人に戻す条件を先に決めます。
導入担当者は、RAGで回答できる範囲を広げたいと感じることがあります。弊社の支援先でも、見えなかったリスクを可視化した後は、レビュー責任が新たに発生しました。
人に戻す条件があると、自動化の価値は下がりません。むしろ、AIが答える範囲と人が判断する範囲が分かれ、現場の責任不安を減らしやすくなります。
顧客対応では根拠と更新日が重要になる
顧客対応でRAGを使う場合は、回答文の自然さよりも根拠と更新日が重要になります。古い料金表や旧手順を参照すると、丁寧な誤案内になってしまいます。
営業やCSが商談中に参照するなら、出典、版、更新日、回答不可条件を画面上で確認できる必要があります。根拠が見えない回答は、担当者が責任を持って使いにくくなります。
顧客対応に向くかどうかは、業務名ではなく情報管理で決まります。FAQ、チャットボット、RAG、社内ナレッジAIの違いを整理すると、必要な運用責任が見えます。
FAQ・チャットボット・RAG・社内ナレッジAIの違い
FAQ、チャットボット、RAG、社内ナレッジAIは、同じ問い合わせ対応でも役割が違います。回答集、対話UI、検索生成の仕組み、社内知識の運用範囲を分けて考えます。
FAQは回答集、チャットボットは対話UI
FAQは、よくある質問と回答を固定して見せる回答集です。チャットボットは、利用者との対話画面を通じて、FAQやシナリオへ案内するUIになります。
FAQは回答数が少なく、更新責任者が明確な場合に扱いやすくなります。チャットボットは質問の入口を整理できますが、回答元の品質までは自動で保証しません。
4つの仕組みは、次のように分けると混同しにくくなります。
仕組み 主な役割 向く用途 運用責任 FAQ 回答を固定する 定型質問の自己解決 回答の作成と更新 チャットボット 対話UIで誘導する 問い合わせ導線の整理 シナリオと分岐の管理 RAG 検索根拠を回答に渡す 文書量が多い知識回答 文書品質と回答制御 社内ナレッジAI 社内知識の運用を設計する 部門横断の問い合わせ対応 権限、承認、更新、有人確認 表で見ると、RAGは画面ではなく検索生成の仕組みです。チャットボットの裏側にRAGを置くこともあり、両者は競合ではなく組み合わせる対象になります。
RAGは検索と生成を組み合わせる
RAGは、文書を検索してから生成AIに回答させる仕組みです。FAQのように回答を固定せず、質問に合わせて関連根拠を探す点が違います。
文書量が多い企業では、すべての質問に固定回答を用意するのは現実的ではありません。RAGなら、商品資料、議事録、手順書などを検索対象にし、回答候補を作れます。
ただし、検索した根拠が不適切なら生成結果も崩れます。RAGの導入判断では、LLMの性能だけでなく、根拠文書の整備状態を同時に確認します。
社内ナレッジAIは運用範囲まで含む
社内ナレッジAIは、RAGの技術だけでなく、社内知識を使う業務運用まで含めた考え方です。権限、承認、更新、有人確認を含めて設計します。
社内向けに使う場合、人事、営業、CS、情シスで参照できる情報が変わります。部署や役職で参照範囲を分けないと、便利さより情報統制リスクが目立ちます。
社内ナレッジAIとして考えると、次に確認すべき論点は誤回答の発生条件です。RAGでも、検索や運用の設計が崩れると、もっともらしい誤回答が残ります。
RAGでも誤回答が起きる失敗パターン
RAGシステムでも、検索漏れや古い情報があれば誤回答は残ります。LLMの性能だけでなく、根拠文書、権限、更新、回答不可制御を分けて確認することが導入判断の前提になります。
誤回答は6つの原因に分けて確認する
RAGシステムの誤回答は、検索漏れ、古い情報、権限違い、文脈誤読、未承認情報、回答不可制御なしの6つに分けると確認しやすくなります。原因別に見ると、導入前の点検対象が明確になります。
RAGは、根拠を検索してから回答を作るため、検索対象にない情報は回答に反映しにくくなります。Microsoft LearnのRAG解説では、10,000ページ規模の文書を扱う例で、関連度の高い断片を返す設計が品質に関わると説明されています。
失敗原因を1つにまとめると、改善策がLLMの調整だけに偏ります。業務で使う前に、次の6分類で質問、文書、権限、回答制御を点検します。
分類後に見るべき点は、原因が技術だけでなく運用にも分かれることです。検索品質を直す問題と、承認や更新の責任を決める問題を混ぜずに扱うと、再発を抑えやすくなります。
参考：Retrieval-augmented generation (RAG) in Azure AI Search｜Microsoft Learn
古い資料や未承認情報が混ざる
古い資料や未承認情報が混ざると、RAGシステムは最新運用と違う回答を作ります。回答元として使う文書は、版、更新日、承認者をそろえて管理し、検索対象を絞る必要があります。
社内FAQや手順書は、運用変更のたびに差し替えが必要です。最新版と旧版が同じ検索対象に残ると、RAGは質問に近い旧資料を根拠として選ぶ場合があり、確認工数が増えます。
更新責任が曖昧なまま導入すると、現場はAI回答を毎回目視確認することになります。承認済み文書だけを回答元にし、古い資料を検索対象から外す運用が必要になります。
権限外の情報を参照してしまう
権限外の情報を参照するRAGシステムは、便利さより情報統制リスクを大きくします。利用者の部署や役職に合わせて、検索できる文書と回答できる範囲を連動させる必要があります。
たとえば、営業担当が顧客別の契約条件まで参照できる設計では、誤送信時の影響が大きくなります。回答前に権限で検索対象を絞ると、不要な情報露出を抑えられます。
情シスや法務から見ると、RAGの導入不安は精度だけではありません。誰がどの文書を見られるかを先に固定すると、回答品質と情報統制を同時に確認できます。
回答できない質問に推測で答える
回答できない質問に推測で答える設計では、RAGシステムでも誤回答が残ります。根拠が不足する質問は、回答不可として人に戻す条件を先に決め、回答品質を保ちます。
顧客対応や社内問い合わせでは、分からないと返すほうが安全な場面があります。料金、契約、個別例外、最新障害などは、根拠が不足した時点で有人確認へ戻すほうが現実的です。
回答不可条件を決めないままRAG化すると、確認工数が残ります。社内AI活用を検討する段階では、回答根拠と人に戻す条件を先に整理すると、導入後の期待値を合わせやすくなります。
導入前に確認すべきチェックリスト
RAGシステムの導入前には、対象業務、根拠文書、承認者、更新責任者、権限、回答不可条件を先に決めます。技術選定より前に運用条件を固定すると、PoCで見るべき失敗点が明確になります。
対象業務と回答範囲を決める
RAGシステムの対象業務は、質問の種類と回答してよい範囲で決めます。最初から全社の問い合わせを対象にせず、根拠文書がそろう業務から始めるのが現実的です。
営業資料、社内手順、顧客対応FAQでは、回答に使える情報の粒度が違います。対象業務を絞ると、質問例、根拠文書、回答不可条件を同じ基準で評価できます。
導入前のチェックは、次の項目で抜け漏れを確認します。未整備の項目が多い場合は、RAG構築よりナレッジ整備を先に進める判断が必要になります。
確認項目 見るべき状態 未整備時のリスク 対象業務 RAGで回答する範囲が決まっている 何でも答える前提になる 根拠文書 回答元の文書、URL、版が特定できる 根拠なし回答が増える 承認者 公開情報として認めた人が分かる 未承認情報が混ざる 更新責任 最新版と旧版の扱いが決まっている 古い手順を回答する 権限 利用者ごとに参照範囲が制御される 権限外回答が出る 回答不可 人に戻す条件が決まっている 推測回答が残る 根拠文書と権限を確認する
根拠文書は、最新版、承認済み、参照権限の3点で確認します。RAGシステムは検索対象の文書に依存するため、使ってよい情報だけを回答元にする必要があります。
弊社が支援した企業でも、可視化によって初めてレビュー責任が生まれるケースがありました。見えなかった情報を扱う以上、権限と確認者を決めない導入は現場負荷を増やします。
権限設計では、部署、役職、顧客担当、契約情報の扱いを分けます。参照できない文書を回答根拠にしない状態を作ると、情報統制と回答品質を同時に確認できます。
承認者、更新者、確認者を決める
RAGシステムの運用責任は、承認者、更新者、確認者に分けて決めます。誰が正しい情報と認めるかを決めないと、導入後も現場が回答を毎回確認することになります。
承認者は回答元として使う文書を決め、更新者は最新版と旧版を管理します。確認者は、回答不可や例外対応の判断を担い、AIだけで答えない範囲を固定します。
ここまで決めると、次に必要なのは社内で合意する質問の整理です。PoCへ進む前に、誤回答テスト、承認、更新、権限、回答不可の確認項目を質問形式に落とし込みます。
導入前に社内で確認すべき質問リスト
RAG導入前には、誤回答テスト、承認者、更新者、権限、回答不可条件を質問形式で確認します。関係者が同じ答えを持つことで、PoCの評価基準がそろいます。
誤回答テストは30〜50問で設計する
RAGのPoC前には、誤案内につながりやすい質問を30〜50問に分け、回答可否と根拠提示を確認します。成功条件を先に固定できます。
質問は、正解しやすいものだけでなく、古い資料、権限外情報、曖昧な前提、例外判断を含めます。失敗しやすい質問を入れないPoCは、導入後の事故を見落とします。
質問リストは、次のカテゴリで作ると整理しやすくなります。
質問カテゴリ 代表質問 確認する理由 誤回答テスト 誤案内につながる質問を30〜50問用意できるか PoCの成功条件を曖昧にしないため 承認者 回答元として使ってよい文書を誰が承認するか 未承認情報の混入を避けるため 更新者 旧版と最新版の差し替えを誰が行うか 古い回答を残さないため 権限 部署や役職で参照範囲を分けるか 権限外情報の表示を避けるため 回答不可条件 分からない時にどの文言で人へ戻すか 推測回答を抑えるため 30〜50問は、網羅数ではなく失敗条件を確認するための目安です。対象業務が広い場合は、部門ごとに分けて小さく検証します。
承認者と更新者を質問で確認する
承認者と更新者は、会議で決めるより質問で確認するほうが抜け漏れを見つけやすくなります。誰が許可し、誰が古い情報を消すかを具体化します。
確認すべき質問は、回答元として使ってよい文書はどれか、旧版をいつ消すか、緊急更新時に誰が承認するかです。役割名だけでは、運用時の判断が止まります。
承認と更新が曖昧なままでも、PoCの画面は動きます。だからこそ、動くかどうかではなく、継続して正しい根拠を返せるかで判断します。
権限と回答不可条件を質問で固定する
権限と回答不可条件は、RAG導入時の責任不安を減らすために固定します。誰に何を見せないか、分からない時にどう戻すかを先に決めます。
社内説明で聞かれやすいのは、精度の高さよりも失敗時の扱いです。権限外の質問、根拠不足の質問、例外判断の質問をどう処理するかが説明材料になります。
社内提案に必要な論点を整えたい段階では、サービス資料を確認材料として使えます。RAG専用の成果保証ではなく、社内AI活用と運用条件を考える入口として参照できます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
RAGの精度とROIをどう測るか
RAGの成果は、正答率だけで判断しません。根拠提示率、回答不可率、有人確認率、再問い合わせ率、対応時間、解決状況まで見て、業務成果に接続します。
正答率だけで精度を判断しない
RAGの品質は、正答率だけでなく、根拠提示率、回答不可率、有人確認率、再問い合わせ率で見る必要があります。回答が正しくても、根拠が追えなければ現場で使いにくくなります。
正答率だけを見ると、AIが無理に答えた回答も高く評価される場合があります。業務では、分からない時に人へ戻せることも品質の一部です。
弊社は200社超の支援現場で、便利さより運用の定着が問われる場面を見てきました。RAGでも、使われ続ける条件は精度指標と改善責任を持つことです。
根拠提示率と回答不可率を見る
根拠提示率は、回答元を確認できる回答の割合を見る指標です。回答不可率は、根拠が足りない時に無理に答えず、人へ戻せているかを見ます。
社内説明では、精度を1つの数字で語るより、複数指標で改善箇所を分けるほうが伝わります。検索が悪いのか、文書が古いのか、回答不可条件が弱いのかを切り分けます。
測定指標は、次の表で整理できます。
指標 見る理由 改善に使う判断 正答率 回答が業務上正しいかを見る 誤回答の多い質問群を直します 根拠提示率 回答元を確認できるかを見る 根拠なし回答を減らします 回答不可率 無理に答えていないかを見る 人に戻す条件を調整します 有人確認率 自動回答後の確認工数を見る 確認対象を絞ります 再問い合わせ率 一次回答で解決したかを見る ナレッジや回答文を改善します 更新遅延 古い情報が残っていないかを見る 更新責任者と頻度を見直します 対応時間 確認を含む業務時間が減ったかを見る 自動化対象と有人確認範囲を見直します 解決状況 問い合わせが解決したかを見る 追加ナレッジや回答不可条件を見直します 表の指標は、導入前の合意にも使えます。正答率だけを約束せず、改善に使う判断まで決めると、ROIの説明が現実的になります。
問い合わせ削減ではなく業務成果まで見る
RAGのROIは、問い合わせ削減だけで測ると偏ります。回答確認の時間、再問い合わせ、有人確認、顧客対応の解決状況まで見て、業務成果に接続します。
問い合わせ件数が減っても、誤回答の確認や差し戻しが増えれば現場負荷は残ります。対応時間、解決状況、更新遅延を見れば、単なる自動化ではなく改善対象が分かります。
RAGを成果につなげるには、運用条件と測定項目を先にそろえます。社内提案に必要な論点を整える材料として、営業改善プログラム「FAZOM」の資料を確認できます。
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag とは 読み方も参考になります。
営業AI・営業DX RAGとは？読み方は「ラグ」｜検索拡張生成の意味と仕組みをわかりやすく解説
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag 作り方も参考になります。
営業AI・営業DX RAGの作り方を7ステップで解説｜社内文書AIを最短で構築する設計手順
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag 読み方も参考になります。
営業AI・営業DX RAGの読み方とは？正式名称・意味・使い方をわかりやすく解説
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag 開発も参考になります。
営業AI・営業DX RAG開発の進め方｜基本6ステップと失敗しない運用設計ガイド
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag サービスも参考になります。
営業AI・営業DX RAGサービスの選定条件｜導入失敗を防ぐチェックとKPI
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag チャットボットも参考になります。
営業AI・営業DX RAGチャットボットとは？｜FAQ活用・作り方・導入前チェック
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag チャンクも参考になります。
営業AI・営業DX RAGチャンク設計｜サイズ・分割方法と社内ナレッジAI評価手順
関連論点まで合わせて整理すると、次の判断に移りやすくなります。 rag ベクトル化も参考になります。
営業AI・営業DX RAGのベクトル化とは｜社内ナレッジAIの精度低下を防ぐ確認点
よくある質問
RAGシステムとチャットボットの違いは何ですか？
チャットボットは対話画面で質問を受け付けるUIです。RAGシステムは、検索した根拠を生成AIの回答に渡す仕組みで、画面ではなく回答の作り方に違いがあります。具体的な進め方は組織の現状に応じて調整します。
RAGを導入すればハルシネーションは防げますか？
RAGを導入しても、ハルシネーションを完全に防げるわけではありません。参照元の品質、検索評価、権限管理、回答不可制御をそろえることで、誤回答の発生条件を減らします。
RAGシステムの精度はどう評価しますか？
正答率だけでなく、根拠提示率、回答不可率、有人確認率、再問い合わせ率を見ます。回答が合っているかだけでなく、現場が根拠を追えるかまで評価します。まずは現状の課題を整理することから始めます。
まとめ：RAGは運用設計で決まる
RAGシステムは、検索と生成を組み合わせるだけでは業務利用に足りません。承認済みナレッジ、権限、更新責任、回答不可条件、評価指標までそろえて初めて、現場が根拠を確認しながら使える仕組みになります。
現状の文書整理や更新責任を曖昧にしたまま進めると、古い資料や権限外情報を確認する工数が残ります。担当者はAI回答を信用しきれず、商談中や顧客対応中に別の資料を探し直す不安を抱え続けます。
RAGを成果につなげるには、運用条件と測定項目を先にそろえます。社内提案に必要な論点を整える材料として、営業改善プログラム「FAZOM」の資料をご確認ください。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
※具体的な数値は導入企業の許可を得た範囲で一部加工しています
