▼ この記事の内容
RAGおすすめは、製品数や機能数ではなく、承認済みナレッジ、権限、更新責任、回答根拠、回答不可制御、評価セットで絞ります。導入前に運用条件と成果指標を固定すると、自社で説明できる候補を選びやすくなります。
RAGの精度は、デモ画面の印象だけでは判断できません。実問い合わせから30〜50問の評価セットを作り、正答、根拠、回答不可、人への引き継ぎを同じ条件で確認する必要があります。
おすすめ一覧を見ても、自社の文書が未承認のまま、権限や更新責任が曖昧だと候補を絞れません。古い資料や根拠のない回答を拾えば、導入後に現場確認と社内説明の負荷が戻ります。
この記事では、RAGを製品名ではなく、承認済みナレッジ、権限、更新、回答不可、評価セットで比較する道筋を整理します。読み終えるころには、自社に合う候補と導入前に聞くべき質問を説明できるはずです。 RAGを選ぶ前に、成果につながらない導入パターンを整理したい方は以下をご確認ください。
商談の質を変えて成果につなげる。営業マネージャーが見るべきポイントを、10項目のチェックリスト付きで解説！
＞＞無料で『チームの数字が動かない営業マネージャーが陥る3つの罠』をダウンロードする
RAGおすすめを選ぶ前に確認すべきこと
RAGのおすすめは、製品名や機能数だけで決まりません。承認済みナレッジが整備され、権限、更新責任、回答根拠、回答不可制御を先に確認できる場合は、導入後の誤回答リスクを下げやすくなります。
RAGは外部知識で回答を補強する
社内利用で候補を比べる場合、RAGは検索した外部知識をLLMの回答に反映させる仕組みです。おすすめ候補は、参照文書と回答根拠を管理できるかで選ぶ必要があります。
通常の生成AIは、学習済みの知識だけで回答する場面があります。RAGは質問に関係する文書を先に探し、その内容を回答文へ反映させます。
RAGの調査論文では、基本型、高度型、モジュール型という3種類の整理が示されています。つまり、RAGは単一機能ではなく、検索、生成、補強の設計全体で精度が変わります。
社内問い合わせで使う場合は、FAQ、議事録、営業資料、契約関連文書を同じ重みで扱うと危険です。正式に承認された文書だけを優先する設計が、回答品質の土台になります。
RAGを比較する最初の問いは、どの製品が有名かではありません。自社が回答に使わせたい情報を決められるかを確認すると、次の選定軸が明確になります。
参考：Retrieval-Augmented Generation for Large Language Models: A Survey｜arXiv
機能数より承認済みナレッジを見る
RAG選定では、多機能な候補より、承認済みナレッジだけを回答元にできる候補を優先すべきです。未承認資料を拾うと、便利な回答ほど社内説明が難しくなります。
よくある失敗は、社内ドライブ全体を対象にすれば回答範囲が広がると考えることです。実際には、古い提案書、個人メモ、未承認FAQまで混ざり、回答の根拠が曖昧になります。
営業やCSの現場では、最新資料より古い成功パターンが強く残る場合があります。弊社が支援した企業でも、暗黙知を共有する前に何を正式知識にするかを決めた組織ほど、運用が安定しやすくなりました。
承認済みナレッジを見るとは、文書を減らすことではありません。回答に使う情報の責任者、更新日、利用範囲を決めることで、候補比較の基準がそろいます。
権限と更新責任を先に決める
RAGを社内利用するなら、部署別の閲覧権限と更新責任を先に決めるのが有効です。ここが曖昧なまま選ぶと、性能ではなく運用事故で評価が崩れます。
権限管理は、単にログインできる人を分ける話ではありません。営業部の提案資料、CSの問い合わせ履歴、情シスの障害情報を、誰がどこまで見られるかを分ける設計です。
更新責任も同じくらい重要です。FAQの正解が変わったのに古い回答が残ると、RAGは古い文書を丁寧に要約してしまいます。
導入前には、対象文書、閲覧できる部門、更新責任者、廃止ルールを表にするのがおすすめです。CS部門なら、問い合わせFAQの更新者と承認者を分けるだけで確認漏れを減らせます。
権限と更新責任を決めると、製品比較で見るべき項目が変わります。検索精度だけでなく、部署別制御と更新ワークフローまで確認する流れに進めます。
回答不可と根拠提示を比較軸にする
RAGの比較では、正しく答える機能だけでなく、答えられない時に止まる機能を確認すべきです。根拠提示と回答不可制御が弱い候補は、社内利用で説明責任を果たしにくくなります。
回答不可制御とは、根拠が足りない質問に対して推測で答えない設計です。問い合わせ対応では、間違った即答より、確認が必要だと返すほうが安全な場面があります。
根拠提示も比較軸に入れる必要があります。回答文だけでなく、参照した文書名、更新日、該当箇所を確認できれば、担当者は回答の採否を判断しやすくなります。
費用や導入負荷を気にして、まず安い候補から試したいと感じる方は多いです。ただ、回答不可と根拠提示が弱い候補では、後から確認作業が増えて現場負荷が戻りやすくなります。
RAGのおすすめ候補は、回答できる範囲と答えない条件を明示できるものから絞るのが現実的です。この基準を置くと、次のタイプ別比較でも自社に合う候補を判断しやすくなります。
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
RAGツール・サービスのタイプ別比較表
RAG候補は、FAQ型、社内ナレッジAI型、個別開発型、既存SaaS連携型に分けると比較しやすくなります。自社の文書量、権限、更新責任、保守体制を先に置くと、製品名だけの比較から抜け出せます。
| タイプ | 向く組織 | 必要な準備 | 向かない条件 | 確認すべき権限・更新責任 |
|---|---|---|---|---|
| FAQ型 | 定型質問が多い組織 | 質問と回答の整備 | 例外対応が多い | FAQの承認者と更新者 |
| 社内ナレッジAI型 | 社内文書が多い組織 | 文書分類と権限整理 | 未承認資料が多い | 部署別閲覧範囲と廃止ルール |
| 個別開発型 | 独自業務が多い組織 | 評価セットと保守体制 | 運用担当が不在 | 仕様変更時の責任者 |
| 既存SaaS連携型 | 利用中ツールを活かしたい組織 | 連携範囲の確認 | 連携元の情報が古い | 同期範囲と更新頻度 |
表で見るべき中心は、機能の多さではなく運用責任の所在です。どのタイプでも、誰が正しい情報を維持するのかを決めない限り、回答品質は安定しません。
FAQ型は定型質問が多い組織に向く
FAQ型のRAGは、質問と回答の型がすでに固まっている組織に向きます。問い合わせ内容が繰り返される場合、回答候補を絞りやすくなります。
CS部門で返品条件、契約更新、操作手順の質問が多い場合は、FAQ型から始めると管理しやすくなります。回答元がFAQに限定されるため、未承認の社内メモを拾うリスクも下げられます。
一方で、例外対応や個別判断が多い組織ではFAQ型だけでは足りません。定型質問を処理する範囲と、人が確認する範囲を分けてから次の候補を検討すると、社内文書全体を扱う必要性が見えます。
FAQ型で足りる条件を先に見極めたい場合は、FAQシステム比較で定型質問と例外対応の分け方を確認できます。
社内ナレッジAI型は権限管理を見る
社内ナレッジAI型は、文書量が多い組織ほど権限管理を重く見るべきです。便利に検索できることより、見せてよい情報だけを回答に使えるかが選定軸になります。
営業資料、議事録、問い合わせ履歴、障害情報を横断検索する場合、部署ごとの閲覧範囲が混ざりやすくなります。情シスやCS責任者は、文書単位だけでなく、フォルダ、ユーザー、部署単位の制御を確認する必要があります。
社内文書が多い企業ほど、まず全社検索をしたくなります。しかし承認前の提案書や古い手順書まで拾うと、回答根拠の説明が難しくなるため、個別開発の前に権限と更新ルールを固めるのが現実的です。
個別開発型は評価と保守体制が要る
個別開発型は、既製品では扱いにくい業務ルールや独自データがある組織に向きます。導入前に評価セットと保守体制を決めないと、開発後の改善が止まりやすくなります。
たとえば、医療、金融、製造業の品質管理では、回答の正しさだけでなく、参照してよい情報と監査ログが問われます。既製品で足りない部分を補える反面、仕様変更や文書更新を誰が担うかまで決める必要があります。
弊社のAIツール設計支援でも、現場で使う画面と検証する画面を分けすぎると改善が遅れる場面がありました。個別開発を選ぶ場合は、作って終わりではなく、評価結果を次の修正へ戻す体制まで比較する必要があります。
既存SaaS連携型は運用負荷を確認する
既存SaaS連携型は、すでに使っているCRM、ヘルプデスク、社内Wikiを活かしたい組織に向きます。追加導入の負荷は下がりますが、連携元の情報が古いと回答も古くなります。
営業部門ならCRMの商談メモ、CS部門ならチケット履歴、情シスなら社内Wikiが回答元になりやすいです。候補を比べる際は、どの項目を同期するか、更新頻度はどの程度か、削除済み情報を拾わないかを確認します。
運用負荷を軽くしたい企業ほど、既存SaaS連携型は魅力的に見えます。ただし同期範囲と更新責任が曖昧なままでは、古い回答や権限漏れが起きるため、次のセクションでは導入失敗を避ける条件を整理します。
RAG導入で失敗しやすいパターン表
RAG導入の失敗は、AIの性能不足だけで起きるわけではありません。古い文書、未承認情報、権限漏れ、回答不可条件の不足を導入前に潰すことで、社内利用時の説明責任を果たしやすくなります。
| 失敗パターン | 起きる原因 | 導入前の確認質問 | 回避条件 |
|---|---|---|---|
| 古い文書を拾う | 更新日と廃止ルールがない | 旧版文書を回答元から外せますか | 承認日、更新者、廃止条件を管理する |
| 未承認情報を使う | 下書きや個人メモまで検索対象にする | 回答元を承認済み文書だけにできますか | 公開前資料と正式資料を分ける |
| 権限漏れが起きる | 部署別の閲覧範囲を反映しない | 部署や役職ごとに参照範囲を変えられますか | ユーザー、部署、文書単位で制御する |
| 根拠がない回答を返す | 回答不可条件と人への引き継ぎがない | 根拠不足の質問を止められますか | 根拠表示、回答不可、有人確認を設定する |
表の中心は、失敗後の対処ではなく導入前の除外条件です。候補比較の段階で質問に落とし込むと、営業資料の見栄えより運用事故の起きにくさを判断しやすくなります。
古い文書を拾うと回答品質が崩れる
古い文書を回答元にしたRAGは、正しい形式で間違った回答を返しやすくなります。更新日が不明な文書は、回答品質を上げる材料ではなく誤回答の発生源になります。
就業規則、価格表、営業提案書、FAQは、最新版と旧版が同じ場所に残りやすい情報です。CS担当者が旧版の返答をそのまま顧客へ送ると、訂正対応だけでなく社内説明の負荷も増えます。
更新頻度が高い領域では、検索対象を広げるより廃止ルールを先に決めるのが現実的です。文書の責任者、最終更新日、旧版の扱いを固定すると、未承認情報を拾う失敗も防ぎやすくなります。
未承認情報を回答元にしない
未承認情報は、RAGの回答元から外すべきです。下書き、個人メモ、検討中の営業資料まで拾うと、回答の根拠を説明できなくなります。
便利さを優先して社内ドライブ全体を検索対象にしたいと感じる方は多いです。ただ、未確認の議事録や提案途中の条件が混ざると、RAGはもっともらしい文章で未確定情報を返します。
弊社の設計思想では、確定前データをそのまま回答元にしない前提を重視します。承認済み文書だけを使うルールを置くと、次に確認すべき権限漏れの範囲も明確になります。
権限漏れは部署別に防ぐ
RAGの権限漏れは、ユーザー単位だけでなく部署別に防ぐ必要があります。営業、CS、情シス、経営層で見られる情報が違うなら、回答元の範囲も分けるべきです。
たとえば営業部だけが見られる契約条件を、全社員向けの社内検索で回答してしまうと問題になります。文書自体は正しくても、読む権限のない人へ表示されれば運用事故です。
部署別に防ぐには、文書、フォルダ、ユーザー、役職の単位で参照範囲を確認します。全社公開できる情報だけを扱う場合は簡略化できますが、部門限定情報があるなら根拠表示と回答停止の条件まで必要です。
根拠がない回答は止める
RAGは、根拠がない質問には自動回答しない設計が必要です。参照文書、回答不可条件、人への引き継ぎを比較すると、導入後の誤回答と説明不能のリスクを下げやすくなります。
社内説明で不安が大きいのは、AIが間違うこと自体より、なぜその回答になったのかを説明できない状態です。参照文書名、更新日、該当箇所が見えれば、担当者は回答を使うか確認できます。
誤回答対策をさらに細かく設計したい場合は、回答不可条件と人の確認を分けて考える必要があります。具体的なハルシネーション対策の考え方も確認すると、自社に合うRAG候補を次のチェックリストで絞りやすくなります。
自社に合うRAGを選ぶチェックリスト
自社に合うRAGは、問い合わせの種類、文書の承認状態、閲覧権限、更新頻度、人の確認、成果指標で判断します。おすすめ候補を比べる前にこの6点を固定すると、機能数だけの比較から外れにくくなります。
| 確認項目 | OK条件 | NG時の対応 | 社内説明で使う一文 |
|---|---|---|---|
| 問い合わせの種類 | 定型質問と例外質問を分けられる | 有人対応ログを先に集める | 自動化する範囲を質問単位で限定します |
| 文書の承認状態 | 正式文書と下書きを分けられる | 回答元を承認済み文書に絞る | 未承認情報は回答に使わせません |
| 閲覧権限 | 部署や役職ごとに参照範囲を変えられる | 全社公開できる文書から始める | 見せてよい情報だけを回答元にします |
| 更新頻度 | 更新者、承認者、廃止条件が決まっている | 旧版文書の除外ルールを作る | 古い文書を拾わない運用を先に決めます |
| 人の確認 | 例外質問と根拠不足を人へ戻せる | 回答不可条件を追加する | AI任せにせず確認が必要な場面を残します |
| 成果指標 | 削減したい工数や改善したい品質を置ける | 検証導入の仮指標を設定する | 導入目的を便利さではなく成果で説明します |
チェックリストの目的は、候補を増やすことではなく除外条件を明確にすることです。NG項目が多い場合は、RAG製品の比較より先に文書整備や運用設計を進めるほうが現実的です。
問い合わせ履歴から対象範囲を決める
RAGの対象範囲は、社内問い合わせ履歴から決めるのが有効です。質問の多い領域と例外判断が多い領域を分けると、自動回答に向く範囲が見えます。
CS部門なら返品条件、契約更新、操作手順の質問を分けます。情シスならアカウント発行、端末設定、障害対応のうち、定型化できる質問から候補にします。
履歴が少ない場合は、まず有人対応のログを集める必要があります。対象範囲を先に決めると、次に確認すべき文書の承認状態も判断しやすくなります。
承認済み文書だけを回答元にする
RAGの回答元は、承認済み文書だけに限定すべきです。下書きや個人メモを含めると、回答は増えても社内説明に使える根拠が弱くなります。
営業資料なら最新版の提案書、CSなら公開済みFAQ、情シスなら承認済み手順書を回答元にします。検討中の条件や古い資料は、検索対象から外すほうが安全です。
文書を減らすことに不安を感じる場合でも、最初から全社ドライブを対象にする必要はありません。正式に使える情報を絞ることで、人の確認を置く場所も明確になります。
人の確認と更新頻度を固定する
RAGを運用するには、人の確認と更新頻度を先に固定します。回答不可、文書更新、承認フローの責任者が曖昧なままでは、導入後に古い回答が残りやすくなります。
更新頻度は、文書の種類ごとに分けます。価格表や契約条件は変更時に確認し、FAQや手順書は月次で見直すなど、現場が続けられる単位に落とし込みます。
社内説明で詰まりやすい論点を整理したい場合は、成果につながらない導入パターンを先に把握すると判断しやすくなります。RAG専用資料ではなく、営業組織の課題整理の入口として活用できます。
成果指標を導入前に置く
RAGの成果指標は、導入後ではなく導入前に置くべきです。問い合わせ削減、一次回答時間、根拠確認の工数、有人対応への引き継ぎ率を候補にすると説明しやすくなります。
弊社が支援したフードサービス企業では、個人依存の営業をチーム化した結果、Bランク層がAランクの80%水準に近づき、42%改善しました。成果はツール名ではなく、行動と確認の仕組みで説明する必要があります。
検証導入では、最初からROIを確定値で約束する必要はありません。仮指標を置いて候補を比べると、ベンダーへ確認すべき質問も具体化できます。
商談の質を変えて成果につなげる。営業マネージャーが見るべきポイントを、10項目のチェックリスト付きで解説！
＞＞無料で『チームの数字が動かない営業マネージャーが陥る3つの罠』をダウンロードする
導入前に確認すべき質問
導入前質問は、精度の高さを聞くだけでは足りません。回答根拠、回答不可、権限、更新、ログ、有人対応への引き継ぎを確認すると、導入後の責任範囲を説明しやすくなります。
回答根拠をどこまで表示できるか聞く
最初に聞くべき質問は、回答根拠をどこまで表示できるかです。文書名だけでなく、該当箇所、更新日、参照権限まで見られるかを確認します。
根拠表示が弱い候補では、回答が合っているように見えても社内説明が難しくなります。CS責任者や情シスは、回答の正誤だけでなく、後から検証できる状態を求められます。
質問例は、回答に使った文書と該当箇所を利用者に表示できますか、です。低リスクなFAQ用途なら文書名だけで足りる場合もありますが、契約や規程では詳細表示が必要です。
回答不可の条件を確認する
回答不可の条件は、導入前に必ず確認します。RAG候補が分からない質問に無理に答える場合、利用者は根拠のない回答を正しいものとして扱いやすくなります。
自動化を進めたい担当者ほど、回答不可が多いと失敗に見えるかもしれません。実務では、答えてはいけない質問を止めることも品質の一部です。
質問例は、根拠文書がない場合や権限外の場合に回答を止められますか、です。FAQ型では選択肢制御で代替できる場合もあるため、用途に合わせて確認します。
権限とログの残し方を確認する
権限とログの残し方は、監査と改善のために確認します。誰が、いつ、どの質問をし、どの文書を参照したかが分かると、誤回答の原因を追いやすくなります。
個人情報や顧客情報を扱う場合は、ログの保存期間と閲覧者も確認します。ログを残せても、管理者以外が見られない設計でなければ運用リスクが残ります。
弊社が支援した医療機器領域では、見えなかったやり取りを可視化することで、品質管理の責任も明確になりました。見えること自体を目的にせず、改善と監査に使う前提で確認します。
有人対応へ渡す条件を決める
有人対応へ渡す条件は、完全自動化を前提にせず決めます。回答不可、低信頼、権限外、顧客個別条件の質問は、人へ戻す基準を先に置きます。
有人対応に戻す設計がないと、利用者はAIの回答に不安を感じても次の行動が分かりません。問い合わせ削減を狙う場合でも、人に渡す導線を残したほうが安心して使えます。
社内問い合わせの運用条件は、ヘルプデスク効率化の考え方ともつながります。次に、回答品質を体感ではなく評価セットで確認します。
質問リストは、ベンダーを詰めるためではなく、導入後の説明責任をそろえるために使います。回答が曖昧な項目は、評価セットで実際に試すのが次の判断になります。
RAGの精度を確認する評価セットの作り方
RAGの精度は、デモ画面の印象ではなく実問い合わせから作った評価セットで確認します。正答、根拠、回答不可、人への引き継ぎを同じ条件で採点すると、候補ごとの運用品質を比べやすくなります。
| 質問タイプ | 例 | 採点観点 | 不合格時の見直し箇所 |
|---|---|---|---|
| 定型質問 | 契約更新の手順を知りたい | 正しい手順と根拠文書を返せるか | FAQと手順書の整備 |
| 例外質問 | 個別契約の条件を確認したい | 人へ戻す判断ができるか | 有人対応の条件 |
| 旧版混在質問 | 古い価格表に関する質問 | 最新版だけを参照できるか | 廃止ルールと更新日 |
| 権限外質問 | 他部署の契約条件を知りたい | 回答を止められるか | 部署別権限 |
| 根拠不足質問 | 文書にない判断を求める質問 | 推測回答を避けられるか | 回答不可文と引き継ぎ先 |
評価表は、候補の優劣を感覚で語らないための共通条件です。質問タイプごとに不合格時の見直し箇所を決めると、製品の問題か社内データの問題かを切り分けられます。
実問い合わせから30〜50問を選ぶ
RAGの評価セットは、実問い合わせから30〜50問を目安に選びます。定型質問、例外質問、権限外質問、根拠不足質問を混ぜると、回答品質を現場条件で確認できます。
質問数は固定統計ではなく、初回検証で偏りを避けるための設計目安です。CS部門なら問い合わせ履歴、情シスなら社内ヘルプデスクのチケット、営業部門なら提案前後の質問を材料にします。
よくある質問だけで評価すると、RAG候補は実力以上によく見えます。旧版文書や部署限定情報を含む質問も混ぜることで、次に根拠表示の弱さを見抜きやすくなります。
正答だけでなく根拠を採点する
RAGの評価では、回答文が正しいかだけでなく根拠を採点します。文書名、該当箇所、更新日が分かる候補ほど、社内説明と修正対応に使いやすくなります。
回答が正しく見えても、根拠文書が古い場合や該当箇所が示されない場合は不合格にします。特に契約条件、価格、規程、顧客対応では、担当者が後から確認できる状態が必要です。
採点欄には、正答、根拠あり、最新版参照、権限適合の4項目を分けて置きます。こうすると、単なる精度比較ではなく、答えてはいけない質問を止められるかまで確認できます。
回答不可の精度も確認する
回答不可の精度は、RAG選定で必ず確認すべき項目です。根拠がない質問や権限外の質問に答えない候補は、社内利用での誤回答リスクを下げやすくなります。
自動回答率を上げたい担当者ほど、回答不可が多い候補を不安に感じる場合があります。しかし実務では、推測で答えないことが品質を守る場面もあります。
評価セットには、文書に答えがない質問と、回答してはいけない質問を入れます。ここで止まれる候補を残すと、評価結果を成果指標へ接続しやすくなります。
評価結果を成果指標へ接続する
評価結果は、正答率だけで終わらせず成果指標へ接続します。問い合わせ削減、一次回答時間、根拠確認の工数、有人対応への引き継ぎ率を置くと、社内説明に使いやすくなります。
弊社は200社超の営業チーム支援で、ツール導入より先に行動と確認の仕組みを設計する重要性を見てきました。RAGでも同じく、候補名より評価結果と改善運用を説明するほうが現場に定着しやすくなります。
稟議前に必要な評価観点を整理したい場合は、RAG単体の機能比較だけで判断しないことが大切です。営業改善の実行と定着まで含めて検討する材料として、弊社のサービス資料をご覧いただけます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
よくある質問
RAGとチャットボットの違いは何ですか
チャットボットは決めた質問と回答を返す設計が中心です。RAGは社内文書などを検索し、その内容を回答に反映するため、根拠表示や権限管理まで含めて比較する必要があります。
RAGはハルシネーションを防げますか
RAGだけでハルシネーションを完全に防ぐことはできません。承認済み文書、回答不可条件、根拠表示、人の確認を組み合わせると、根拠のない回答を減らしやすくなります。
RAG導入前に必要な準備は何ですか
問い合わせ履歴、承認済み文書、部署別権限、更新責任者、回答不可条件、評価セットを準備します。先に運用条件を決めると、候補比較と社内説明が進めやすくなります。具体的な進め方は組織の現状に応じて調整します。
まとめ
RAGのおすすめは、一覧の上位にある製品を選ぶことでは決まりません。承認済みナレッジ、権限、更新責任、回答根拠、回答不可制御、評価セットを先に置くことで、自社で運用できる候補を絞りやすくなります。
現状の文書や問い合わせ履歴を整理しないまま導入すると、古い情報、未承認情報、権限漏れ、説明できない回答が残ります。便利に見えるAIが現場確認を増やし、担当者が回答の根拠を毎回探す状態になりやすくなります。
まずは、問い合わせ範囲、回答元、権限、更新者、回答不可条件、評価セットを1枚に整理してください。RAG選定を運用定着まで含めて見直したい方は、社内説明に必要な論点を整理する材料として弊社の資料をご確認ください。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
※具体的な数値は導入企業の許可を得た範囲で一部加工しています
