AIチャットボットとやり取りした買い物客のコンバージョン率は 12.3% で、やり取りしない買い物客の 3.1% と比べて高いことが、Amra & Elmaによるチャットボットのコンバージョン統計まとめで示されています。この差は、運用担当者が EC向けai chatbot をどう考えるべきかを変えます。チャット画面は、同じ会話の中で販売アシスタント、サービスデスク、マーチャンダイジング層を兼ねるためです。
EC向けAIチャットボット は、ストアデータに接続された会話型アシスタントです。実務上は、商品の質問への回答、商品の提案、注文状況の確認、ポリシーの説明、高価値な会話の適切な人的チームへのルーティングができます。
これは2026年に向かう中でさらに重要になります。購入者は、エージェントのキューを待たずに、即時の回答、商品選びのガイダンス、正確な注文情報を求めています。チャットがそれを提供できなければ、買い物客は離脱し、サポートコストは上がり、購入意欲が決まる瞬間にブランドへの信頼が失われます。
より難しい問題は、会話型AIを、利益率を改善し、顧客データを保護し、財務部門が信頼できるROIモデルを提示できる形で導入することです。多くの組織はそこで行き詰まります。
2026年にECストアがAIチャットボットを必要とする理由
チャットボットとやり取りした買い物客は、やり取りしない買い物客よりもはるかに高い率でコンバージョンします。記事の冒頭で示したこの差は、EC向けai chatbot を小さなサポートツールとして扱うのではなく、売上計画の中に置くべきである最も明確な理由です。
チャットボットで成果が出ないチームは、たいてい同じ運用上の誤りを犯します。ボットをヘルプウィジェットの中に埋め込み、薄いFAQを読み込ませ、成功をチケット削減だけで判断します。この設計では機会を十分に活かせません。大規模なカタログ、繰り返される購入前質問、検討度の高い商品を持つストアでは、チャットは購買ジャーニーの一部です。
市場も同じ方向へ進んでいます。業界予測では2026年までに広範な導入が見込まれており、その速度は重要です。十分な数の小売事業者が高速な会話型サポートを提供すると、顧客の期待値が変わるためです。社内で導入の根拠を構築する運用担当者には、このチャットボット導入のビジネスケースが有用な背景情報になります。
競争上のリスクは日々の運用に現れます
よくある失敗点は、壊れたストアフロントではありません。30秒ためらい、答えを得られず、離脱する買い物客です。
その摩擦は通常、いくつかの予測しやすい場所に現れます。
- 商品の不確実性: 買い物客は、どのサイズ、バリエーション、互換性オプション、セットが自分のニーズに合うか分かっていません。
- ポリシーへのためらい: 購入を決める前に、返品、配送時期、関税、在庫状況について明確な答えを求めています。
- 応答遅延: サポートが営業時間外、混雑中、またはメールに限定されており、購入に関する質問が未回答のままになります。
実務上のルール: エージェントが同じ購入前質問に毎日回答しているなら、そのワークフローは自動化の有力な候補です。
これはミッドマーケットのブランドではさらに重要です。多くのShopifyやMagentoの運用では、同じチームが、増えるチケット数、放棄されたカート、一貫しない商品ガイダンスから圧力を受けています。未解決の会話が1件あるだけで、サービス費用と失われた売上という2つのコストが同時に発生します。
本格的な導入で変わること
適切に運用されたチャットボットプログラムは、応答速度だけでなく多くを改善します。セッション中に買い物客へ回答し、コンバージョンを妨げている質問を収集し、サポート、マーチャンダイジング、営業の間により明確な経路を作ります。これにより、チャットボットは単なるフロントエンド機能ではなく、運用資産になります。
ビジネスケースもそのように測定すべきです。削減されたチケットによる人件費削減から始め、次に支援売上、回収されたカート、商品詳細トラフィックでの高いコンバージョンを加えます。それを実際の実装作業、つまり検索品質、注文およびカタログ連携、プライバシーレビュー、継続的なQAと照らし合わせます。ボットが最新のポリシーと商品データを取得できなければ、高コストなエスカレーションを生みます。取得できるなら、複数チームにわたって投資回収が始まります。
そのため、2026年の計画では、チャットボットをエンタープライズインフラとして扱うべきです。利点はサポートコストの低下だけではありません。より速い購入経路、より明確なROI、顧客データの利用方法に対するより厳密な管理です。
EC向けAIチャットボットの3つの中核業務
多くの組織は1つのチャットボットを購入し、それですべてを解決できると期待します。それは誤った運用モデルです。強力な EC向けAIチャットボット が機能するのは、いくつかの業務を明確かつ測定可能に実行し、それぞれが異なるKPIとデータセットに結び付いているためです。

1つ目の業務はサービス需要に対応します
最初の業務は、サポート責任者がすぐに認識するものです。TenUpSoftのEC向けAIチャットボットガイドで説明されているように、チャットボットは注文状況、返品、配送、商品詳細を含む Tier 1の顧客問い合わせの最大80% を自律的に解決できます。
これはコスト管理に有用ですが、運用上のより大きな利点は一貫性です。顧客にとって、「荷物はどこですか?」という質問が正午に来るか深夜に来るかは重要ではありません。毎回同じ品質の回答を求めています。ライブの注文データとポリシーデータにアクセスできるボットは、人的チームのキューに圧力を加えずにそれを提供できます。
失敗パターンも明らかです。ボットが注文システムやポリシー更新を読み取れなければ、古い情報の上に見栄えのよい層を重ねただけになります。その結果、エスカレーションは減るのではなく増えます。
2つ目の業務は買い物客を購入へ進めます
2つ目の業務は販売支援です。この機能では、多くの導入が価値あるものになるか、記憶に残らないもののままになるかが決まります。優れたボットは、サポートのプロンプトを待つだけではありません。買い物客が商品を比較し、選択肢を絞り、適切な商品をより速く見つけるのを支援します。
Master of Code Globalの会話型マーケティング事例によると、H&MのKikベースのチャットボットは 86%のエンゲージメント率 に達し、ユーザーは1セッションあたりおよそ4分を費やしました。メッセージングプラットフォーム自体よりも重要なのは、その行動です。会話によるガイダンスは、買い物客が何を閲覧し購入するかに影響を与えるのに十分な時間、注意を維持できます。
この役割は、フィルターだけではカタログを閲覧しにくい場合に最も効果を発揮します。アパレル、美容、電子機器、家具、専門小売はいずれもこのパターンに当てはまります。顧客はSKUを知らないかもしれませんが、求める結果を説明できます。チャットボットは、その曖昧な意図を実用的なレコメンドに変換します。
3つ目の業務は購入意欲の高い会話を適格化します
3つ目の業務は、多くのコマースチームが認識している以上に重要です。すべての会話がサポートチケットや単純な商品レコメンドであるわけではありません。高価値な購買シグナルである場合もあります。これには、卸売の問い合わせ、一括購入、カスタム注文、ギフト依頼、CRMや営業ワークフローへ移すべき複雑な商品質問が含まれます。
リード適格性評価を行うチャットボットは、人的チームが迅速に対応するために必要な詳細を収集すべきです。正しくルーティングするのに十分な質問を行いつつ、顧客が離脱するほど多く聞きすぎてはいけません。実務上は、意図、商品への関心、緊急度、連絡先情報を取得し、その会話を適切なシステムへ送ります。
| 役割 | 主な活動 | 主要KPI |
|---|---|---|
| サポートエージェント | 注文追跡、返品、配送に関する質問、ポリシー回答 | 封じ込め率と解決品質 |
| セールスアシスタント | 商品発見、比較、アップセル、プロモーション案内 | コンバージョン率とカート単価の拡大 |
| リード適格性評価 | 一括注文のトリアージ、高価値問い合わせ、CRMへの記録 | 営業へ引き渡された適格会話 |
3つの役割すべてで同じように振る舞うチャットボットは、それぞれで成果が低くなりがちです。そのため、運用担当者はどの業務を最初に優先するかを決めるべきです。あるブランドでは、反復的なサポート負荷の削減です。別のブランドでは、商品ページでの支援コンバージョンの改善です。さらに別のブランドでは、購入意欲の高いトラフィックがサイトを離れる前に捕捉することです。ボットは初日に3つすべてを行う必要はありません。ただし、明確な主要ミッションは必要です。
EC向けAIチャットボットに必要な機能
最も強力なプラットフォームは、モデル品質だけでなく運用適合性で競争します。ベンダーを比較する前に、基礎的なチャットボット機能と、ボットが実際に買い物客の購入を支援できるかを決めるコマース固有の機能を分けてください。
| 機能 | 重要な理由 |
|---|---|
| ライブの商品カタログと在庫へのアクセス | 入手不可商品のレコメンドを防ぎ、ボットがバリエーションに関する質問へ正確に回答できるようにします。 |
| 注文追跡と返品サポート | 顧客をエージェントのキューに入れずに、購入後の大量問い合わせを削減します。 |
| 商品レコメンドロジック | 曖昧な買い物客の意図を、有用な商品発見、セット、比較へ変換します。 |
| 会話履歴付きの有人引き継ぎ | 人間のエージェントが会話に加わる際に、複雑な問題が最初からやり直しになるのを防ぎます。 |
| 意図別および売上影響別の分析 | どの会話がサポート負荷を減らし、コンバージョンに影響し、コンテンツのギャップを明らかにするかを示します。 |
| プライバシー管理と監査証跡 | 法務、セキュリティ、サポートチームに、顧客データと回答がどう扱われるかの可視性を提供します。 |
Shopifyストアでは、このチェックリストはさらに具体的であるべきです。有用なチャットボットには、商品とバリエーションのメタデータ、在庫状況、注文状況、配送ルール、返品ロジック、複雑な会話を既存のサポートスタックへ引き継ぐ明確な方法が必要です。
最新のAIチャットボットが正確な回答を提供する仕組み
正確性は、本格的なECチームが懐疑的になる点であり、それは当然です。返品ポリシーをでっち上げたり、在庫切れ商品を約束したりするチャットボットは、チャットボットがないよりも悪い状態です。

閉じた本の試験ではなく、持ち込み可の試験として考えます
Retrieval-Augmented Generation、つまり RAG を説明する最も分かりやすい方法はこうです。記憶から回答する標準的な大規模言語モデルは、閉じた本で試験を受ける学生のようなものです。自信があるように聞こえるかもしれませんが、自信は正確性と同じではありません。RAGベースのシステムは、回答前に承認済みの会社資料を使う、持ち込み可の試験のようなものです。
このアーキテクチャが重要なのは、回答を自社データに基づかせるためです。Quickchat AIによるECチャットボットアーキテクチャの説明によると、RAGはモデルに、回答生成前に検証済みソースから情報を取得させます。これにより解決精度を 最大10% 向上させることができ、ポリシーをでっち上げる、入手不可商品を約束するなどのハルシネーションを防ぐのに役立ちます。運用担当者にとって、これはデモ用ボットと本番用ボットの違いです。
実務上の意味は単純です。買い物客が、商品に青色があるか、商品を返品できるか、プロモーションがまだ適用されるかを尋ねた場合、システムは即興で答えるべきではありません。カタログ、ポリシー文書、またはライブのバックエンドシステムから答えを取得すべきです。
検索レイヤーが接続すべきもの
RAGは、到達できるソースの品質に応じてしか機能しません。ECで最も重要な知識ソースは通常、次のものです。
- 商品カタログデータ: タイトル、属性、バリエーション、素材、互換性、マーチャンダイジングルール。
- 在庫と価格システム: 在庫状況、ライブの価格変更、プロモーション、セットロジック。
- 注文と配送データ: 追跡状況、出荷状態、配送予定枠、返品可否。
- ポリシーコンテンツ: 返品、交換、支払い方法、保証詳細、地域別ルール。
これらのソースが不完全であれば、ボットは曖昧または一般的な回答に追い込まれます。そのため、本番環境では RAGとファインチューニングの違い が重要になります。ファインチューニングはトーンや領域へのなじみを形成できますが、回答が変動する在庫、価格、運用ルールに依存する場合、リアルタイム検索の代替にはなりません。
根拠付けされていない言語モデルは、一見自信のある、しかし単に誤った回答を生成する可能性があります。これはコマースにおける具体的なリスクです。多くの失敗した導入は、モデル自体ではなく弱いソースデータに起因します。まばらな商品属性、一貫しないポリシーページ、不足したAPI接続によって、モデルには検証済みの文脈が少なすぎる状態になります。その後、チームは上流で始まった誤りをチャットボットのせいにします。
解決策は特殊なものではありません。カタログを整備します。FAQを構造化します。ライブの真実を保持するシステムを接続します。そのうえで、整ったサンプルプロンプトではなく、実際の顧客が使う扱いにくいクエリでテストします。
ECチャットボット実装ロードマップ
失敗した導入の多くは、モデルが弱かったために崩れるのではありません。ロールアウトが曖昧で、システムが接続されておらず、オーナーシップが多くのチームに分散していたために失敗します。

ビジネス課題から始めます
ベンダーデモから始めないでください。キューとファネルから始めます。最も問い合わせ量を生む、または最も商業的な足かせになる顧客の質問を確認します。あるストアでは、それが注文追跡と返品です。別のストアでは、コンバージョンを妨げる商品適合性の質問です。
初期スコープは平易な言葉で書きます。例:「定型的な注文質問に対応し、主要なポリシー質問に回答し、検討度の高い商品のバリエーション選択を買い物客に支援する」。第1フェーズにすべてを含めると、たいてい何も十分に機能しない状態でローンチされます。
優れた初回ロールアウトには、狭い目的、1人のエグゼクティブオーナー、正確性に必要なシステムの短いリストがあります。
データとシステムのレイヤーを構築します
リアルタイムAPIによる深い連携は、有用なボットと高価なウィジェットを分ける境界線です。これらの接続がなければ、ボットは在庫、プロモーション、ポリシーについて矛盾した回答をします。CleffexのECチャットボット分析では、AIチャットボットを利用するストアで 平均18%のコンバージョン向上 が報告されており、やり取りした買い物客は、そうでない買い物客のおよそ 4倍の率 でコンバージョンしています。この差は、ボットがライブの商品、価格、配送データを実際に問い合わせられる場合にのみ現れます。
実装チェックリストには次を含めるべきです。
- コマースプラットフォーム接続: Shopify、WooCommerce、Magento、またはカスタムストア層。
- カタログの準備状況: 構造化された属性、整理されたバリエーション、一貫した命名、完全な商品メタデータ。
- 運用API: 在庫、価格、注文状況、返品ワークフロー。
- 知識ソース: ヘルプセンター記事、ポリシー文書、配送ルール、社内マクロ。
- エスカレーションロジック: ボットがいつ引き継ぐべきか、どの会話履歴が渡されるか、次のステップの担当者は誰か。
このカテゴリにおける実用的な選択肢の1つが Quickchat AI です。APIベースの接続、サポートや販売支援などのECユースケース、接続された知識ソースに回答を根拠付けるよう設計されたRAG設定をサポートしています。
Shopify固有の実装メモ
Shopifyがコマースプラットフォームである場合、チームが毎日扱うワークフローに照らしてチャットボットを評価してください。商品発見では、ライブの商品データとバリエーションデータを使用すべきです。サポート回答には、現在の配送、返品、交換ルールを反映すべきです。購入後の会話では、いつ注文状況を取得し、いつ引き継ぐべきかを把握している必要があります。
専用の AI Agent for Shopify は、汎用的なWebサイトボットよりも運用化しやすいです。Shopifyカタログ、ポリシー、注文データを直接読み取れるためです。評価では、ボットがそのデータを使って、購入を妨げる質問や反復的なチケットを生む質問に回答できるかに集中すべきです。この時点では、基本的なチャット機能は当然の要件です。
狭くローンチし、その後拡張します
社内の信頼を最も早く失う方法は、主要な経路が安定する前にサイト全体へローンチすることです。高頻度のジャーニーを1つか2つ選んで始めます。実際のトラフィックでテストします。初期フェーズでは失敗ケースを毎日確認します。
シンプルなロールアウトのリズムを使います。
- 1週目の焦点: 主要な意図に対する回答品質を検証します。
- 次のステップ: 実際の会話履歴に基づいて、プロンプト、検索ソース、エスカレーションルールを調整します。
- 拡張ポイント: サポート基盤が信頼できる状態になってから、販売ガイダンス、プロモーションロジック、リード獲得を追加します。
チャットボットは、ローンチ時にすべてのユースケースを与えられるのではなく、測定された回答品質に基づいて、時間をかけてより広い適用範囲を獲得すべきです。
ここではガバナンスも重要です。誰かが商品データ品質を所有しなければなりません。誰かがポリシー更新を所有しなければなりません。誰かが会話レビューを所有しなければなりません。これらの責任が曖昧なままだと、ボットは数週間でビジネスと同期しなくなります。
AIチャットボットの真のROIを測定する
コスト削減は実在しますが、それだけではエンタープライズ予算の議論に勝つには不十分です。

コスト削減は1つの項目にすぎません
多くのチームはチャットボットのROIをサポート削減として提示し、そこで止めます。人件費への影響が即時かつ目に見えるものでない限り、財務部門がそれを説得力があると見ることはまれです。Gartnerは特に、カスタマーサービスのリーダーが生成AIの 総所有コスト を過小評価しがちであると警告しています。Gartnerは、2030年までに生成AIの解決1件あたりコストが$3を超え、多くのオフショアの人間エージェントより高くなると予測しています。つまり、ROIモデルは孤立したサポート指標だけでなく、顧客ライフサイクル全体を考慮する必要があります。
これは正しい枠組みです。チャットボットは、サービスコスト、コンバージョン、マーチャンダイジング、リード対応に関わります。モデルが売上への影響を除外すれば、プログラムを過小評価します。実装オーバーヘッドを除外すれば、過大に売り込むことになります。
より明確な方法は、ROIを4つの区分に分けることです。
- サポート効率: エージェントが対応する定型チケットの減少と、時間外カバレッジの改善。
- 売上向上: より速い回答と購入ガイダンスによって影響を受ける購入の増加。
- カート単価の拡大: 会話中のアップセルとクロスセルの受け入れ増加。
- 運用インサイト: 顧客の摩擦、意図、コンテンツギャップに対する可視性の改善。
運用担当者が使える実用的なROIモデル
チームがすでに信頼している現状指標からモデルを構築します。財務チームが自社のベースラインを確認できるなら、業界ベンチマークから始めないでください。
次の順序を使います。
-
現在のコストを定義する プラットフォーム費用、反復的な問い合わせに関連するサポート人件費、コンテンツ保守、実装作業、社内管理時間を含めます。
-
回収可能なサポート負荷を見積もる フェーズ1でボットが信頼性高く処理できると考える問い合わせタイプのみをモデル化します。
-
支援売上を見積もる 買い物客の商品選択、比較、購入完了を支援する会話に価値を割り当てます。
-
引き継ぎ品質を考慮する 部分的な自動化モデルでも、エージェントへの引き継ぎがより明確で速ければ、強いROIを生む可能性があります。
シンプルなワークシートは次のようになります。
| ROI領域 | 測定するもの | 重要な理由 |
|---|---|---|
| サポート | 解決された定型問い合わせと解放されたエージェント時間 | 運用効率を示します |
| コマース | チャットボット支援セッションのコンバージョン | 直接的な売上影響を示します |
| マーチャンダイジング | 提案商品の受け入れとセット販売 | カート成長を示します |
| オペレーション | 取得された意図と課題テーマの品質 | サイトとサポートの意思決定を改善します |
エグゼクティブ向けの短い要約が必要な場合は、チャットボットの活動ではなくビジネス成果から始めます。「ボットがX件の質問に回答した」は弱い表現です。「ボットが反復的な問い合わせ負荷を減らしながら、支援付き購入ジャーニーを改善した」の方が強いです。システムを人件費と売上の両方に同時に結び付けるためです。
リーダーが確認すべき点についての有用な解説は以下です。
セキュリティ、プライバシー、コンプライアンスへの対応
プライバシーレビューは、すでに特定のベンダーが有力になった後ではなく、チャットボット調達の開始時に行うべきです。ECではこの順序が重要です。顧客との会話には、名前、住所、注文番号、配送上の問題、法務およびセキュリティチームが保護責任を負うその他のデータが含まれることが多いためです。
弱いプライバシーレビューは、直接的な運用コストを生みます。法務が承認を遅らせます。セキュリティが是正作業を追加します。調達が停滞します。最悪の場合、技術作業がすでに始まった後で、連携の選択を取り消さなければならなくなります。
どのベンダーにも早期に回答を求めるべき質問が2つあります。自社の顧客データでモデルを訓練しますか? そして データレジデンシーの選択肢は何ですか? 1つ目に対する明確な「いいえ」は、そのベンダーが営業会話でプライバシーを掲げているだけでなく、プロダクトに組み込んでいることを示します。GDPR、UK GDPR、または米国の州レベルのプライバシー法の下で運用するチームは、調達を進める前に書面での回答を要求すべきです。
EU、英国、米国にまたがって運用するチームでは、レビューをさらに進めるべきです。保管場所、アクセス制御、監査証跡、削除ワークフローについて、平易な言葉で回答を得ます。ベンダーがこれらを明確に説明できない場合、法務とセキュリティが関与した時点で遅延が発生すると考えてください。
重要なベンダー質問
EC向けai chatbot のプライバシーおよびコンプライアンスレビューは、具体的であるべきです。システムが本番データをどう扱うか、検索がどう機能するか、チームが顧客会話で何が起きたかをどう確認できるかを質問します。
短いデューデリジェンスリストを使います。
- モデル訓練ポリシー: 顧客との会話が、共有モデルまたは第三者モデルの訓練に使われることはありますか?
- データレジデンシー: ビジネスが要求する地域内にデータを保持できますか?
- 監査可能性: チームは、ボットが何を回答し、RAGを通じてどのソースが取得されたかを確認できますか?
- アクセス制御: どのユーザーが会話履歴を閲覧でき、権限はどのように管理されますか?
- 保持と削除: 会話データはどのくらい保存され、削除プロセスはどのようになっていますか?
- 第三者への露出: データ経路上にどのサブプロセッサがいますか?
- PIIの取り扱い: データがモデルに到達する前に、何がマスキング、暗号化、または除外されますか?
これは法務レビューだけではありません。回答品質と運用規律にも影響します。ボットがソースを示せなければ、サポートチームは機微な回答を検証できません。会話履歴へのアクセスが広すぎると、社内リスクが高まります。保持ルールが曖昧であれば、コンプライアンスチームは正当な理由でロールアウトを遅らせます。
最も強力な導入は、プライバシー、ガバナンス、信頼性を1つの運用システムとして扱っています。ボットに入るデータに明確なルールを設け、RAGを使って承認済みコンテンツに回答を根拠付け、役割ごとに会話履歴アクセスを制限し、ローンチ前に削除と監査プロセスを文書化します。このアプローチは承認時の摩擦を減らし、ROIを説明しやすくします。チャットボットが軽量なWebサイトウィジェットではなく、エンタープライズ資産として管理されているためです。
EC向けAIチャットボットを評価しており、根拠付けされた回答、APIベースの連携、ROIの可視性、プライバシー管理を一か所で確認したい場合は、Quickchat AIをご覧ください。トレーサビリティやデータ管理を手放さずに、カスタマーサポート自動化、販売支援、リード適格性評価を必要とするチーム向けに構築されています。
FAQ
EC向けAIチャットボットとは何ですか?
EC向けAIチャットボットは、ストアデータ、商品カタログ、注文システム、サポートポリシーに接続された会話型アシスタントです。買い物客が回答を得る、商品を比較する、注文を追跡する、複雑な問題をエスカレーションするのを支援します。
AIチャットボットはShopifyに接続できますか?
はい。Shopify AIチャットボットは、商品、在庫、ポリシー、注文データに接続し、購入前と購入後の質問に最新情報で回答できる必要があります。専用の実装パスについては、Quickchat AIの Shopify向けAIエージェント をご覧ください。Shopifyマーチャントは、Shopify App Storeから Shopping Agent by Quickchat AI を直接インストールすることもできます。
EC向けAIチャットボットは注文追跡に対応できますか?
はい、連携またはAPIを通じて注文データと配送データにアクセスできる場合は可能です。その接続がなければ、一般的な案内しか提供できず、不要な引き継ぎは引き続き発生します。Quickchat AIの Shopify注文追跡用AIチャットボット は、買い物客が提供した注文番号とメールアドレスから注文を検索します。
AIチャットボットは商品レコメンドをどのように改善しますか?
会話上の意図を、商品フィルター、比較、レコメンドに変換します。買い物客に正確なSKUやカテゴリを知っていることを求めるのではなく、チャットボットが確認質問を行い、関連する商品に買い物客をマッチングできます。
ECチームはローンチ後に何を測定すべきですか?
解決された定型問い合わせ、チャットボット支援によるコンバージョン、平均注文額への影響、エスカレーション品質、繰り返し現れる会話テーマを測定します。これらの指標は、サポートへの影響と売上への影響の両方を示します。