投稿者 投稿日: カテゴリー EC×AI活用
オンデバイスAIとは、クラウドに送らず手元の端末内でAIを動かす仕組みのことです。
問い合わせメールの要約をAIに頼もうとして、本文に書かれた購入者の氏名、住所、電話番号、注文番号をどう扱えばよいか分からず、手が止まった経験はないでしょうか。個人情報保護委員会は2023年6月2日の注意喚起で、事業者が本人の同意なく個人データを含むプロンプトを生成AIに入力し、それが応答以外の目的で扱われた場合、個人情報保護法に違反する可能性があると明示しました。この悩みに対する選択肢の1つが、データを外に出さずに手元のパソコンや社内サーバーでAIを動かすオンデバイスLLM（ローカルLLM）です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、オンデバイスで済ませるべき業務とクラウドでよい業務の分け方、法律上の確認点、すぐ使えるプロンプト5本を整理します。結論を先に言えば、オンデバイスは「個人データを含む下処理」に限定して使い、仮名化したデータだけをクラウドの高性能モデルに渡す二段構えが、2026年時点で最も現実的な設計です。
なぜ今、AIに渡すデータの置き場所が問われるのか
AIに渡すデータの置き場所が問われる理由は、AIの業務利用が個人の試用から組織の常用に変わり、個人データが日常的にプロンプトへ入るようになったからです。商品説明文の作成なら個人情報は含まれませんが、問い合わせ対応、レビュー返信、返品理由の分析、受注データの集計となると、購入者の情報が必ず関わります。
個人情報保護委員会の注意喚起は、個人情報取扱事業者に向けて2つの点を求めています。1つは、個人情報を含むプロンプトを入力する場合、特定した利用目的を達成するために必要な範囲内かを十分に確認すること。もう1つは、本人の同意なく個人データを含むプロンプトを入力する場合、そのデータが応答結果の出力以外の目的、たとえばAIの学習に使われないことを、サービス提供事業者の側で十分に確認することです。
個人情報保護法の条文に照らすと、関係するのは主に4つの規定です。第18条の利用目的による制限、第23条の安全管理措置、第27条の第三者提供の制限、そして第28条の外国にある第三者への提供の制限です。海外のAI事業者のAPIに個人データを送る場合、契約や設定によっては、外国にある第三者への提供として本人同意や移転先の体制確認が必要になる場面があります。一方、個人情報保護委員会のQ&Aでは、クラウドサービス事業者が契約上個人データを取り扱わず、適切なアクセス制御が行われている場合には「提供」に当たらないという考え方も示されています。どちらに当たるかはサービスの規約と設定で変わるため、一律には判断できません。
もう1つ押さえておきたいのが、業務の委託として整理できるかという論点です。第27条第5項第1号は、利用目的の達成に必要な範囲で個人データの取り扱いを委託する場合、委託先への提供は第三者提供に当たらないと定めています。ただし委託先は、預かった個人データを委託の範囲内でしか使えません。AI事業者が入力データを自社モデルの学習に使う設定のままだと、委託の範囲を超えた利用になりかねないため、注意喚起が「学習に利用しないことの確認」を求めているのは、この点ともつながっています。
この「判断の難しさ」こそが、現場の手を止める原因です。直近の支援案件で観測したのは、法務の確認待ちで問い合わせ対応へのAI導入が半年近く止まっていた店舗のケースでした。オンデバイスLLMは、データを外に出さないことで第三者提供や外国移転の論点そのものを小さくし、検討を前に進めるための現実的な手段になります。
日本のEC事業者に特有の事情もあります。楽天市場やAmazon、Yahoo!ショッピングで受けた注文の購入者情報は、各モールの規約やガイドラインのもとで店舗に預けられたものです。自社の判断だけで外部サービスに流してよいかは、個人情報保護法とは別に、出店規約の側でも確認が必要になります。社内で完結するオンデバイス処理は、この確認の手間も軽くします。
オンデバイスで済ませる業務、クラウドに任せる業務
業務の切り分けの基本は、「個人データを読む必要があるか」で決めることです。個人データを読む下処理はオンデバイス、個人データを含まない創作や分析はクラウドの高性能モデル、という分担にすると、性能と安全性の両方を取りにいけます。
オンデバイスで済ませたい業務の筆頭は、問い合わせやレビューの要約と仕分けです。問い合わせ本文から「配送遅延」「商品不良」「返品希望」などの論点だけを抜き出し、氏名や住所を除いた要約にする作業は、中規模のローカルモデルでも十分にこなせます。2026年8月にAlibabaが重みを公開したQwen3.8-27Bは、約17GBでノートパソコンでも動くと報じられました。この規模のモデルなら、1日数十件から数百件の問い合わせ要約は、手元の端末で処理できる範囲に入ってきています。
2つ目は、受注データからの個人情報の除去、つまり仮名化の下処理です。受注CSVの備考欄やギフトメッセージ欄には、氏名や電話番号が自由記述で紛れ込んでいることがあります。列ごと削除するだけでは取り切れないこうした情報を、ローカルモデルに検出させて置き換える使い方は効果が大きい領域です。
3つ目は、返品理由やクレーム内容の分類です。アパレルなら「サイズが合わない」「色が画像と違う」、食品ギフトなら「賞味期限が短い」「破損していた」といった分類を、個人を特定できる情報と切り離したうえで集計できます。
反対に、クラウドの高性能モデルに任せたほうがよい業務もあります。商品説明文やメルマガの作成、競合商品ページの分析、広告文の作成といった、個人データを含まない創作や分析です。こうした業務では、Claude Opus 5.5やGPT-6系、Gemini 4系のような上位モデルの文章力と推論力が効きます。オンデバイスのモデルは、上位モデルに比べると長文の構成力や複雑な推論で劣る場面が多く、無理に置き換える必要はありません。
ローカルでモデルを動かすには、モデルのダウンロードと実行を管理するソフト（OllamaやLM Studioなど）を使うのが一般的です。モデル選びでは、4つの点を確認してください。商用利用が認められたライセンスか、日本語の問い合わせ文を正しく読めるか、手元の端末のメモリで動くか、提供元が継続的に更新しているか、の4点です。とくにライセンスは、研究用途に限られたものや、利用者数に条件があるものも存在するため、導入前に必ず原文を確認します。日本語の性能は、自社の過去の問い合わせ20件程度を使って、要約の正確さを人が採点する簡単な試験で確かめるのが早道です。
ここで押さえておきたいのは、オンデバイスにすれば法律上の義務がすべて消えるわけではない点です。手元の端末で処理しても、利用目的の範囲内かという第18条の論点は残りますし、端末の紛失や不正アクセスに備える第23条の安全管理措置も必要です。オンデバイスは「論点を減らす手段」であって、「論点をなくす手段」ではありません。
二段構えの運用を作る手順とプロンプト5本
運用は、「データの棚卸し」「仮名化」「オンデバイスでの要約・分類」「目的の照合」「社内ルール化」の5段階で作ります。以下のプロンプトのうち、プロンプト2と3はローカルモデルで、それ以外はChatGPT、Claude、Geminiなどクラウドのモデルで使う想定です（プロンプト1、4、5には個人データを入れないでください）。
最初に、AIに渡したい業務データのどこに個人データが含まれるかを洗い出します。列名と記入例だけを渡し、実データは渡しません。
プロンプト1：業務データの個人データ棚卸し（クラウド用・実データは入れない）
あなたはEC事業者の個人情報管理担当です。以下は当社の業務データの列名と、架空の記入例です。
各列について次の3点を判定してください。
1. 個人情報に当たるか（当たる／単体では当たらないが照合で当たりうる／当たらない）
2. AIに渡す前の処理（削除／置き換え／そのまま）
3. 自由記述欄で個人情報が紛れ込むリスク（高／中／低）
出力は列ごとに1行で、最後に「オンデバイスで処理すべき列」を列挙してください。
列名と架空の記入例：{列名：例 を列挙}
2つ目は、ローカルモデルで個人情報を置き換えるプロンプトです。置き換えの対応表は別に保存し、AIの出力には含めない運用にします。
プロンプト2：自由記述からの個人情報の置き換え（ローカルモデル用）
以下の文章から、個人を特定できる情報を検出し、次の記号に置き換えてください。
氏名→［氏名］、住所→［住所］、電話番号→［電話］、メールアドレス→［メール］、注文番号→［注文番号］
条件：
1. 置き換え以外の文章は一字も変えない
2. 判断に迷う語は置き換えたうえで、文末に「確認が必要な語」として列挙する
3. 出力は置き換え後の文章のみ
文章：{問い合わせ本文やギフトメッセージ}
3つ目は、ローカルモデルで問い合わせを要約・分類するプロンプトです。プロンプト2で置き換えた後の文章を入力にします。
プロンプト3：問い合わせの要約と分類（ローカルモデル用）
以下の問い合わせ文（個人情報は置き換え済み）を読み、次の形式で出力してください。
・分類：{配送、商品不良、返品・交換、支払い、その他}のいずれか
・要約：60字以内
・緊急度：高（24時間以内の対応が必要）／中／低
・店舗が確認すべき事項：箇条書きで3つまで
推測で事実を補わず、文中に書かれていないことは「記載なし」としてください。
問い合わせ文：{本文}
4つ目は、AIの利用が利用目的の範囲内かを確かめるプロンプトです。自社のプライバシーポリシーに書いた利用目的と、AIでやりたいことを並べて点検します。
プロンプト4：利用目的との照合（クラウド用・個人データは入れない）
以下は当社のプライバシーポリシーに記載した個人情報の利用目的と、AIで行いたい業務の一覧です。
各業務について、記載された利用目的の範囲内と考えられるかを、根拠となる記載とともに示してください。
範囲外の可能性がある業務には、「利用目的の追加」「本人同意の取得」「個人情報を使わない方法への変更」のどれで対応するのが現実的か、理由を添えて提案してください。
最終判断は法務担当が行う前提で、論点の整理に徹してください。
利用目的：{ポリシーの該当箇所}
AIで行いたい業務：{業務一覧}
5つ目は、社内のAI利用ルールのたたき台を作るプロンプトです。ルールがないまま現場が使い始めると、担当者ごとに判断がばらつきます。
プロンプト5：社内AI利用ルールのたたき台（クラウド用）
EC事業者の社内向けに、生成AIの利用ルールのたたき台を作成してください。
含める項目：
1. クラウドのAIに入力してよい情報、してはいけない情報の具体例
2. オンデバイス（社内端末）で処理すべき業務の範囲
3. 学習に使われない設定の確認方法と、確認する担当者
4. 端末の紛失や盗難に備えた措置（暗号化、画面ロックなど）
5. 違反や漏えいの疑いがあったときの報告の流れ
従業員30名規模の会社を想定し、A4で2枚程度に収まる分量にしてください。
5本の中で最初に試すべきなのはプロンプト1です。どの列にどの程度の個人情報が含まれているかが分かれば、オンデバイスに回す業務の範囲が自然に決まります。
失敗例と回避策
オンデバイスLLMの導入で起きやすい失敗は3つあります。いずれも、技術選定より運用の詰めの甘さから起きるものです。
1つ目は、オンデバイスだから安全だと考えて、端末の管理を怠る失敗です。個人データを処理したノートパソコンを暗号化しないまま持ち出し、紛失すれば、クラウドに送った場合と同じかそれ以上の事故になります。2022年4月の改正法施行以降、一定の漏えいは個人情報保護委員会への報告と本人への通知が義務になっています。回避策は、AIを動かす端末を限定し、ディスクの暗号化と画面ロックを必須にすることです。
2つ目は、ローカルモデルの出力をそのまま顧客対応に使う失敗です。中規模のローカルモデルは、上位のクラウドモデルに比べて事実の取り違えが起きやすく、問い合わせの要約で配送日や商品名を誤ることがあります。アパレル系の単一店舗で試したケースでは、サイズ表記の「M」と「L」を要約時に取り違える例が見られました。要約は担当者が対応の方針を決めるための材料にとどめ、顧客への返信は人が原文を確認してから送る流れを残してください。
3つ目は、仮名化したつもりで個人を特定できる情報が残る失敗です。氏名を消しても、「〇〇市の△△小学校の近く」「先週の大口注文の件」といった記述から個人が分かることがあります。プロンプト2で「確認が必要な語」を出させ、初期は人が目で確かめる運用にするのが安全です。ある食品ジャンルの中規模店舗の事例では、ギフトメッセージ欄に贈り先の家族構成が書かれていることが多く、置き換えルールを追加して対応しました。
KPI設計と費用・工数の目安
KPIは、「個人データをクラウドに送った件数」をゼロに保つことを前提に、「問い合わせ1件あたりの一次対応時間」と「要約の修正率」で見るのが分かりやすい設計です。安全性の指標と効率の指標を分けて追うと、どちらかを犠牲にしていないかが見えます。
費用面では、オンデバイスLLMはソフトウェア自体を無料で使えるものが多い一方、端末への投資が必要です。Qwen3.8-27Bのような規模のモデルを快適に動かすには、メモリを多く積んだノートパソコンやデスクトップが前提になり、既存の事務用パソコンでは処理が遅くなるケースが多く見られます。新たに専用端末を1台用意する場合、構成次第で数十万円規模の投資を見込むのが目安です（価格は時期と構成で大きく変わるため要確認）。
クラウド側は、ChatGPT、Claude、Geminiの法人向けプランやAPIを使います。個人向けの有料プランは月額20米ドル前後が目安ですが、業務で使うなら、入力データを学習に使わない設定や契約が明示された法人向けプランを選ぶのが基本です（最新の料金と条件は各社公式で要確認）。
要約の修正率は、導入直後の2週間は全件を人が確認して記録し、その後は週に20件ほどを抜き取って確認する形に切り替えると、品質を保ちながら確認の手間を減らせます。修正率が上がり始めたら、問い合わせの傾向が変わった（新商品の発売やセール時期など）サインと受け止め、プロンプト3の分類項目を見直してください。仮名化については、置き換え漏れの件数を別の指標として持ち、1件でも見つかれば原因を記録して置き換えルールに反映する運用が望ましい形です。
工数の目安としては、プロンプト1による棚卸しと社内ルールの整備に2〜3週間、ローカルモデルの導入と試験運用に1か月程度を見込むと無理がありません。現場感覚では、問い合わせ件数が1日30件を超える店舗なら、一次対応の要約と分類だけでも担当者1人あたり1日1時間前後の削減につながることが多く、半年から1年で端末投資を回収できる計算になりやすいと見ています。
今後の展望と独自考察
今後、AIをどこで動かすかの選択肢はさらに広がります。パソコンやスマートフォンにAI処理用のチップが標準で載るようになり、OSやブラウザに小型のAIモデルが組み込まれる流れが進んでいます。オープンなモデルの性能も上がり続けており、1年前ならクラウドでしか動かなかった水準の処理が、手元の端末に降りてきています。
一方で、オープンなモデルを自社で運用する場合の安全面の課題も指摘されています。うるチカラでも取り上げたとおり、オープンウェイトのモデルは性能面で最上位に迫る一方、安全対策の面では差が残るという報告があります。オンデバイスで動かすモデルを選ぶときは、性能だけでなく、提供元、ライセンス、更新の頻度も確認しておくべきです。
制度面では、個人情報保護法はおおむね3年ごとに見直しが検討される仕組みになっており、AIの利用と個人データの関係は今後も議論の中心であり続けると見られます（見直しの具体的な内容と時期は個人情報保護委員会の公表資料で要確認）。編集部としての見立ては、法改正の行方を待つより、「個人データはオンデバイス、それ以外はクラウド」という分担を先に作っておくほうが、どの方向に制度が動いても対応しやすいというものです。仮名化の下処理を社内に持っておけば、クラウド側のモデルを入れ替えても、個人データの扱いは変わらずに済みます。
もう1つの変化は、顧客の側でAIエージェントが買い物を代行する場面が増えていることです。AIエージェント経由の注文や問い合わせでは、エージェントが顧客の情報を代わりに送ってくるため、店舗が受け取る個人データの経路が増えます。受け取ったデータをどこで処理し、どこに保存し、いつ消すかを決めておく必要性は、今後さらに高まると判断します。必要以上のデータを持たない、持ったデータは手元で処理する、という原則を早めに社内に根づかせておくことが、AIエージェント時代の顧客の信頼にもつながります。
よくある質問
オンデバイスAIとは何ですか？
オンデバイスAIとは、データをクラウドに送らず、手元のパソコンやスマートフォン、社内サーバーの中でAIを動かす仕組みのことです。ローカルLLMとも呼ばれます。処理するデータが外部に出ないため、個人情報の第三者提供や海外移転の論点を小さくできます。
オンデバイスで処理すれば個人情報保護法の対応は不要ですか？
いいえ、不要にはなりません。利用目的の範囲内かという確認や、端末の紛失・不正アクセスに備える安全管理措置は、オンデバイスでも必要です。オンデバイスは論点を減らす手段であり、法律上の義務がなくなるわけではありません。
ChatGPTやClaudeに顧客情報を入れるのは違法ですか？
一律に違法になるわけではありませんが、条件の確認が必要です。個人情報保護委員会は、利用目的の範囲内か、入力したデータが学習など応答以外の目的に使われないかを確認するよう求めています。法人向けプランの契約条件と設定を確認し、可能なら仮名化してから入力してください。
ローカルLLMの性能はクラウドのAIに比べてどうですか？
文章の構成力や複雑な推論では、クラウドの上位モデルに劣る場面が多いのが実情です。一方、問い合わせの要約や分類、個人情報の置き換えのような定型的な処理なら、中規模のローカルモデルでも十分に実用になります。用途を限定して使うのが現実的です。
楽天市場やAmazonの購入者情報をAIで分析してよいですか？
個人情報保護法に加えて、各モールの規約やガイドラインの確認が必要です。モールから預かった購入者情報は、モール側のルールのもとで扱う必要があります。個人を特定できる情報を除いて集計するか、社内で完結するオンデバイス処理にとどめる方法が安全です。
最初に何から始めればよいですか？
最初は、AIに渡したい業務データのどこに個人情報が含まれるかを洗い出すことです。本記事のプロンプト1を使えば、列ごとに処理方法を決められます。そのうえで、個人データを読む業務だけをオンデバイスに回す範囲を決めてください。
まとめ
個人情報保護委員会は、生成AIへの個人データの入力について、利用目的の範囲内かと、学習など応答以外の目的に使われないかの確認を求めています。オンデバイスLLMは、データを外に出さずに処理することで、こうした論点を小さくできる現実的な選択肢です。ただし、端末の管理や利用目的の確認といった義務は残ります。
おすすめの設計は、個人データを読む要約や仮名化はオンデバイス、個人データを含まない創作や分析はクラウドの上位モデル、という二段構えです。最初の一歩として、プロンプト1で業務データの棚卸しから始めてください。手元で動くモデルの具体例はQwen 3.8 27BのノートPC稼働の解説、自社ホストとデータ保護の考え方はDeepSeek V4の自社ホスト記事、オープンモデルの安全面はオープンウェイトモデルの安全性ギャップの記事もあわせて参考にしてください。
参考文献
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日、別添1）
- e-Gov法令検索「個人情報の保護に関する法律」
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
