2026年に複数の業務ツールを連携させる方法
まずワークフローを整理し、適切な連携方式を選び、データ項目を標準化し、自動化を安全に検証し、失敗を監視し、信頼できる情報源を 1 つに保って、複数の業務ツールを連携させましょう。
複数の業務ツールの連携は、単なる接続機能の作業ではありません。まずワークフローから始め、データの対象ごとに信頼できる情報源を決め、どのイベントが動作を起こすべきかを決め、確実に動く最も軽い連携方式を選びます。単純なワークフローには標準の接続機能と自動化プラットフォームが最適です。顧客、注文、商品、セグメント、同意、キャンペーンのデータをネットショップ、CRM、マーケティング、サポート、分析にわたって一致させる必要があるなら、API、Webhook、管理された同期層のほうが向いています。難しいのが Shopify、Brevo、その他の運用基盤をまたいで顧客データを同期し使える状態に保つことである場合、Tajo が役立ちます。
複数の業務ツールを連携させることは簡単に見えますが、最初の重複顧客が生まれた瞬間、誤ったライフサイクル段階が CRM に戻ってきた瞬間、テスト用レコードが本物に見えてマーケティングのワークフローが動いてしまった瞬間に、そうではないと気づきます。
難しいのは接続機能そのものではありません。難しいのは、どのツールがどのデータを所有するか、どのイベントが後続の動作を起こすべきか、どの項目の移動を許すか、顧客が気づく前に失敗をどう検知するかを決めることです。
現在の検索行動は、アプリの連携プラットフォーム、ワークフローの自動化、標準の接続機能、ネットショップの自動化、CRM 連携、AI を活用した業務運営に集まっています。Zapier、Make、n8n、Workato、Tray.ai、Microsoft Power Automate、Shopify Flow、Brevo はいずれも、きっかけ、動作、接続機能、ワークフロー、自動化の論理を軸に連携を位置づけています。これは実務的な意図を裏づけています。各チームに必要なのは連携の抽象的な定義ではありません。データを乱さずにツールをつなぐ確実な方法です。
このガイドでは、中小規模のチームが実際に運用できるかたちで業務ツールを連携させる方法を説明します。
結論を先に
複数の業務ツールを連携させる手順です。
- ツールを選ぶ前に業務のワークフローを整理します。
- 関わるアプリと、それぞれが所有するデータを一覧にします。
- 連絡先、企業、注文、商品、継続課金、同意、サポートの問い合わせ、キャンペーンの状態について、信頼できる情報源を決めます。
- 各連携を一方向、双方向、リアルタイム、定期実行、手動のどれにするか決めます。
- 連携方式を選びます。標準の接続機能、ワークフローの自動化プラットフォーム、Webhook、API、データ同期ツール、独自の連携のいずれかです。
- 項目名、必須の値、識別子、担当、ライフサイクル段階を標準化します。
- 実際の顧客に触れる前に、管理されたサンプルレコードで検証します。
- エラー通知、再試行のルール、ログ、切り戻し手順を追加します。
- 1 つのワークフローずつ稼働させます。
- 毎月、連携の健全性を確認します。
利用できるアプリをすべてつなぐことから始めないでください。ツールの分断が時間、売上、顧客の信頼を損なっているワークフローから始めましょう。
接続機能ではなくワークフローから始める
多くの連携の失敗は、問いの立て方から始まっています。
弱い問い、ツール A はツール B とつながりますか。
良い問い、実際の業務イベントが起きたとき、何が起きるべきですか。
例です。
| 業務イベント | 関わるツール | 望ましい結果 |
|---|---|---|
| Shopify の顧客が初回注文をする | Shopify、CRM、メール基盤 | 連絡先を作成または更新し、初回購入のタグを付け、ウェルカムまたは購入後の配信を開始する |
| 見込み客がデモ申込フォームを送る | サイトのフォーム、CRM、カレンダー、メール | リードを作成し、担当を割り当て、確認メールを送り、フォローのタスクを作る |
| サポートの問い合わせに解約の話が出る | サポート窓口、CRM、顧客データ基盤 | 解約リスクを指摘し、担当者に通知し、追加販売の配信を止める |
| 顧客がロイヤルティ区分に到達する | ロイヤルティツール、ネットショップ、メール、SMS | セグメントを更新し、区分に応じたメッセージを開始する |
| 商品が再入荷する | ネットショップ基盤、メール、SMS | 登録した顧客に通知し、商品セグメントを更新する |
何をつなぐ必要があるかはワークフローが教えてくれます。接続機能はその方法を示すだけです。
構築の前に、次を書き出しましょう。
- 正確なきっかけとなるイベント。
- そのイベントが作られるシステム。
- 影響を受けるレコードの種類。
- 後続で必要になる項目。
- 次に起きるべき動作。
- そのワークフローを所有する人またはチーム。
- 最も損害が大きい失敗。
そのワークフローを平易な言葉で説明できないなら、まだ構築する段階ではありません。
業務ツールを棚卸しする
稼働中のワークフローを変更する前に、連携の棚卸し表を作りましょう。
顧客データや業務データを作成、保存、更新、利用するツールをすべて含めます。
| ツールの種類 | よくある例 | 関わるデータ |
|---|---|---|
| ネットショップ | Shopify、WooCommerce、BigCommerce | 顧客、注文、商品、割引、出荷 |
| CRM | HubSpot、Salesforce、Pipedrive、Zoho | 連絡先、企業、商談、担当、ライフサイクル段階 |
| マーケティング自動化 | Brevo、Mailchimp、Klaviyo、ActiveCampaign | 連絡先、同意、セグメント、キャンペーンへの反応 |
| サポート | Zendesk、Intercom、Help Scout、Freshdesk | 問い合わせ、会話、満足度、種別のタグ |
| 経理 | Stripe、QuickBooks、Xero | 決済、請求、返金、継続課金 |
| プロジェクト管理 | Asana、Trello、Monday、ClickUp | タスク、担当、期日、進捗 |
| データと分析 | GA4、Looker Studio、BigQuery、表計算 | イベント、レポート、ダッシュボード、書き出し |
| コミュニケーション | Slack、Microsoft Teams、メール | 通知、承認、引き継ぎ |
ツールごとに、次を記録します。
- 担当、誰がそのツールを管理していますか。
- 業務上の目的、なぜチームはそれを使っていますか。
- 主なレコード、どのデータがそこにありますか。
- データの所有権、このツールはどの項目を更新してよいですか。
- 現在の連携、すでにどのアプリとつながっていますか。
- 失敗時の影響、連携が止まると何が壊れますか。
- 書き出しの可否、復旧が必要なときデータを書き出せますか。
この棚卸しは隠れた依存関係を防ぎます。また、新しい連携を CRM、ネットショップ基盤、マーケティングツール、自動化プラットフォーム、専用の同期層のどこに作るべきかも判断しやすくなります。
データの対象ごとに信頼できる情報源を決める
連携作業が危険になるのは、2 つのツールが同じ項目を所有していると考えているときです。
重要な対象ごとに、信頼できる情報源を決めましょう。
| 対象または項目 | よくある信頼できる情報源 | 補足 |
|---|---|---|
| 顧客の同一性 | ネットショップ、CRM、顧客データ層 | 安定した識別子を使い、メールアドレスは突き合わせの手がかり程度に留める |
| 連絡先の同意 | マーケティング自動化または同意管理基盤 | 同意に関係しないワークフローに配信停止の状態を上書きさせない |
| 注文 | ネットショップ基盤 | 経理とサポートは注文データを参照できるが、所有すべきではない |
| 商品 | ネットショップまたは商品情報管理システム | 商品名、商品コード、在庫状況には一貫した識別子が必要 |
| 商談 | CRM | マーケティングはスコアに影響を与えてよいが、段階は営業が所有する |
| サポートの問い合わせ | サポート窓口 | CRM は状態を写してよいが、解決はサポートが所有する |
| キャンペーンへの反応 | マーケティング基盤 | CRM は要約を使い、生のイベントは所有しない |
| ロイヤルティ状態 | ロイヤルティ基盤または顧客データ層 | 区分の変更は制御可能で監査できるようにする |
そのうえで、更新の方向を定義します。
| 方向 | 使う場面 | リスク |
|---|---|---|
| 一方向の同期 | 1 つのツールが明確にそのデータを所有している | 対応付けが正しければ低い |
| 双方向の同期 | 2 つのチームが正当に同じ対象を更新する | 競合ルールが必要なため高い |
| イベントによる起動 | 業務イベントが動作を引き起こすべき場合 | 自動化に向くが、再試行と重複排除が必要 |
| 定期的な一括処理 | 1 時間ごとや 1 日ごとの更新で足りる場合 | 費用は低いがリアルタイム性は下がる |
| 手動承認 | リスクの高い処理に人の確認が必要な場合 | 安全だが遅い |
双方向の同期は有用ですが、既定にすべきではありません。競合ルール、時刻のルール、権限、古いデータが最新データを上書きしないための仕組みが必要です。
適切な連携方式を選ぶ
現在の連携ツールは幅広く存在します。Zapier は非常に多くのアプリを対象としたノーコードの自動化を重視します。Make は視覚的な自動化と用意されたアプリ連携を重視します。n8n は柔軟なワークフロー設計と連携テンプレートを重視します。Workato と Tray.ai は企業向けの連携、統合制御、幅広い接続機能に注力しています。Microsoft Power Automate は大規模な接続機能の体系を文書化しており、Shopify Flow と Brevo Automations は基盤標準のワークフローがネットショップとマーケティングのイベントをどう扱うかを示しています。
適切な選択はワークフローによって変わります。
標準の接続機能
ワークフローが単純で、ツールが直接対応している場合は標準の接続機能を使いましょう。
向いている用途です。
- フォームの送信内容を CRM に送る。
- ネットショップの顧客をメール基盤に同期する。
- 既知のイベントからサポートの問い合わせを作成する。
- キャンペーンへの反応を CRM に送る。
- 標準的なかご落ちやウェルカムの配信を開始する。
利点です。
- 設定が速い。
- たいてい提供元のサポートがある。
- 構成要素が少ない。
- 一般的なワークフローには十分。
制約です。
- 項目の対応付けが限られる場合がある。
- エラー報告が薄いことがある。
- 複雑な分岐ができないことがある。
- 再試行の挙動を制御できないことがある。
- 提供元の変更が動作に影響することがある。
標準の接続機能は良い出発点です。ただし、常に最終的な構成になるとは限りません。
ワークフローの自動化プラットフォーム
きっかけ、条件、分岐、待機、承認、動作を多くのアプリにまたがって使いたい場合は、ワークフローの自動化プラットフォームを使いましょう。
Zapier、Make、n8n、Power Automate、Workato、Tray.ai の系統がこれにあたります。
向いている用途です。
- 問い合わせフォームの送信が CRM レコードを作り、担当を割り当て、Slack に通知し、メール配信を開始する場合。
- Shopify の注文が CRM の連絡先を更新し、ロイヤルティのタグを付け、高額注文ならサポートに通知する場合。
- サポートの問い合わせが顧客の健全性スコアを更新し、販促メッセージを停止する場合。
- 表計算の行が複数の業務タスクを起動する場合。
利点です。
- 独自開発より速い。
- 業務チームが内容を確認しやすい。
- きっかけと動作によるワークフローに適している。
- 対応するアプリが非常に多い。
制約です。
- 処理量に応じて費用が増える。
- 複雑なワークフローは保守が難しくなる。
- レート制限は依然として適用される。
- 機微なデータには統制が必要。
- 誰でも自動化を編集できると担当が曖昧になる。
命名規則、フォルダ、担当者、変更履歴を使いましょう。担当のいないノーコードのワークフローも、本番稼働のソフトウェアであることに変わりはありません。
Webhook
あるアプリがイベント直後に別のシステムへ通知する必要がある場合は Webhook を使いましょう。
向いている用途です。
- 注文の作成。
- 決済の失敗。
- フォームの送信。
- 問い合わせの作成。
- 継続課金の解約。
- 在庫の変動。
利点です。
- 速い。
- イベント駆動である。
- リアルタイムのワークフローに効率的。
制約です。
- 受信側の窓口が必要。
- 署名の検証など信頼の仕組みが必要。
- 再試行と重複排除が必要。
- ログの記録が必要。
Webhook の配信を保証されたものとして扱わないでください。イベントの識別子を保存し、重複を無視し、失敗した配信を監視しましょう。
API
独自の処理、より細かい項目制御、接続機能では実現できないワークフローが必要な場合は API を使いましょう。
向いている用途です。
- 独自の顧客プロフィール同期。
- 複雑な商品カタログの処理。
- 高度なセグメント設計。
- 同意を考慮したマーケティング同期。
- 社内ダッシュボード。
- 独自の管理ツール。
利点です。
- 柔軟である。
- 項目を細かく制御できる。
- 自社の業務ロジックに正確に合わせられる。
制約です。
- 開発と保守が必要。
- API のバージョンが変わることがある。
- 認証情報を安全に管理する必要がある。
- レート制限とページ分割への対応が必要。
- 監視は自社の責任になる。
API は強力ですが、テスト、ログ、担当、ドキュメントを備えるべきです。稼働中の顧客レコードを静かに更新する小さなスクリプトは、安全な連携の方針とは言えません。
管理されたデータ同期または顧客データ層
多くのツールが一貫した顧客、注文、商品、同意、セグメント、キャンペーンの文脈を必要とする場合は、管理された同期層を使いましょう。
向いている用途です。
- ネットショップ、CRM、マーケティング、サポート、分析のすべてが顧客の文脈を必要とする。
- どのシステムの顧客レコードが正しいかでチームが議論している。
- セグメントに購買行動、商品の嗜好、キャンペーンへの反応、サポートの文脈が必要。
- 同意と配信停止のルールをチャネル横断で守る必要がある。
- イベント通知だけでなく、整った運用データが必要。
利点です。
- 個別接続の重複を減らせる。
- 対応付けのルールを一元化できる。
- 顧客の文脈を再利用できる。
- データの所有権と統制を守りやすい。
制約です。
- 丁寧なデータモデリングが必要。
- 信頼できる情報源の決定は依然として必要。
- 旧来のワークフローからの移行が必要になることがある。
ここが Tajo の最も得意な領域です。連携の課題が「この 2 つのアプリはつながるか」ではなく「顧客、注文、商品、ロイヤルティ、同意、セグメント、キャンペーンのデータを、事業を回せるだけ一貫させるにはどうするか」である場合に Tajo は役立ちます。
項目の対応付けより先にデータモデルを設計する
きれいな連携計画がしばしば崩れるのは、項目の対応付けの段階です。
項目を対応付ける前に、対象と識別子を定義しましょう。
| 対象 | 必要な識別子 | よくある項目 |
|---|---|---|
| 連絡先 | 社内の識別子、メールアドレス、各基盤の識別子 | 氏名、メールアドレス、電話番号、国、同意、ライフサイクル段階 |
| 企業 | 企業の識別子、ドメイン、CRM の識別子 | 名称、規模、担当、取引区分 |
| 注文 | 注文の識別子、顧客の識別子、ネットショップの識別子 | 合計金額、通貨、明細、状態、日付 |
| 商品 | 商品コード、商品の識別子、バリエーションの識別子 | 名称、カテゴリ、価格、在庫状況 |
| 継続課金 | 契約の識別子、顧客の識別子 | プラン、更新日、状態、支払い状況 |
| サポートの問い合わせ | 問い合わせの識別子、顧客の識別子 | 状態、優先度、内容、満足度 |
| キャンペーンのイベント | 連絡先の識別子、キャンペーンの識別子 | 送信、開封、クリック、不達、配信停止 |
そのうえでルールを定めます。
- どの項目が必須ですか。
- どの項目が任意ですか。
- どの値が許容されますか。
- どの項目を上書きしてよいですか。
- どの項目が追記のみですか。
- どの項目が機微ですか。
- どの項目は送信元システムから出すべきではないですか。
できる限り安定した識別子を使いましょう。メールアドレスは変わり、電話番号も変わり、氏名は一意ではありません。識別子は重複レコードと結合の破綻を防ぎます。
まず小さな連携を作る
連携の全体像を一度に作ろうとしないでください。
価値が明確なワークフローを 1 つ選びます。
- 新規顧客のウェルカムワークフロー。
- デモ申込の振り分け。
- 高額注文の通知。
- かご落ちの回復。
- サポートから CRM へのエスカレーション。
- 購入後のレビュー依頼。
- 解約リスクの通知。
- 再入荷の通知。
そのワークフローについて、次を文書化します。
| 要件 | 例 |
|---|---|
| きっかけ | Shopify の注文が支払い完了 |
| 条件 | 初回注文で、マーケティングへの同意が有効 |
| 送信元の項目 | 顧客の識別子、メールアドレス、名、注文合計、商品カテゴリ |
| 送信先 | Brevo の連絡先とセグメント |
| 動作 | 初回購入の配信に追加する |
| 除外 | 配信停止、返金済み、すでに配信中の場合は登録しない |
| 担当 | ライフサイクルマーケティング責任者 |
| 失敗通知 | Slack への通知と日次のエラーレポート |
これで管理された稼働ができます。うまく動いたら、次のワークフローを追加しましょう。
サンプルレコードで検証する
連携が実際の顧客に触れる前に検証しましょう。
次のサンプルレコードを作ります。
- 新規顧客。
- 既存顧客。
- 重複したメールアドレス。
- メールアドレスの欠落。
- 配信停止済みの連絡先。
- 高額顧客。
- 返金された注文。
- 海外の顧客。
- 複数回の注文。
- 削除または保管済みの商品。
- サポートのエスカレーション。
- 決済の失敗。
サンプルごとに、次を確認します。
- 正しいレコードが作成または更新されましたか。
- 連携は正しい顧客を突き合わせましたか。
- 必須項目は埋まりましたか。
- 同意と配信停止のルールは守られましたか。
- ワークフローは重複した動作を避けましたか。
- 後続の動作は 1 回だけ実行されましたか。
- 失敗したときエラーは見えましたか。
完璧なレコード 1 件だけを使う検証は、本当の検証ではありません。
監視と失敗時の処理を追加する
どの連携もいずれ失敗します。
よくある原因です。
- API の認証情報の期限切れ。
- 提供元による項目名の変更。
- 利用者による必須項目の削除。
- レート制限への到達。
- ワークフローの担当者による条件の変更。
- ツールの一時的な停止。
- レコードに必須値がない。
- 重複による競合。
- Webhook の二重配信。
次の仕組みを追加しましょう。
| 仕組み | 重要な理由 |
|---|---|
| エラー通知 | ワークフローが壊れたことを誰かが知る必要がある |
| 再試行のルール | 一時的な失敗を恒久的なデータ欠落にしない |
| 重複排除 | 再送されたイベントが重複したタスクやメッセージを作らない |
| ログ | 何が起きたかをチームが追跡できる |
| エラー用のキューまたは一覧 | 失敗したレコードを確認できる |
| 担当の割り当て | すべての連携に人の担当者が必要 |
| 月次の点検 | 静かな失敗は珍しくない |
顧客に向けたワークフローには切り戻し計画を用意しましょう。誤ったセグメントがキャンペーンに流れ込んだ場合、配信を止め、レコードを外し、データを修復する方法を知っておく必要があります。
同意、セキュリティ、アクセスを守る
業務ツールの連携は、しばしば個人データを移動させます。本番の基盤として扱いましょう。
最低限のルールです。
- 最小権限の API トークンを使う。
- 認証情報は資料や表計算ではなく、秘密情報の管理機能または安全な環境変数に保管する。
- 担当者が離任したらトークンを入れ替える。
- 本番ワークフローを編集できる人を制限する。
- 検証用と本番用の認証情報を分ける。
- 必要でない限り機微な項目を同期しない。
- 同意、配信解除、配信停止の項目を保護する。
- 連携の変更を記録する。
- 提供元のアクセス権を四半期ごとに見直す。
同意の項目は特別な扱いが必要です。営業のワークフロー、サポートのワークフロー、表計算の取り込みが、配信停止した人を誤って再登録することがあってはなりません。
Tajo が役立つ場面
Tajo は、連携が共有された顧客の文脈に依存するときに最も役立ちます。
たとえば次のような構成です。
- Shopify が注文、商品、購入履歴を持っています。
- Brevo がメール、SMS、マーケティング自動化を担っています。
- CRM が担当、段階、取引先のメモを持っています。
- サポートツールが問い合わせと解約の兆候を持っています。
- 分析ツールが売上、継続率、キャンペーンの成果を報告します。
個別接続の連携は 2 つのツール間でデータを移動できますが、対応付けのルールが重複して増えがちです。構成が広がるにつれ、同じ顧客の版がいくつも生まれてしまいます。
Tajo は、顧客、注文、商品、ロイヤルティ、同意、セグメント、キャンペーンの文脈を整理し、業務ツールが同じデータに基づいて動けるようにします。これは、1 つの自動化を動かすことではなく、ネットショップ、マーケティング、CRM、サポートのワークフローを互いに一致させることが目的の場合に重要です。
次のような場合に Tajo を使いましょう。
- Shopify のデータを CRM とマーケティングのワークフローに流す必要がある。
- Brevo のセグメントに、より整った顧客と注文の文脈が必要。
- キャンペーンで購買行動、ロイヤルティ状態、商品の嗜好を使いたい。
- 同意と配信停止のルールを一貫させる必要がある。
- 壊れやすい表計算の書き出しを減らしたい。
- 顧客のワークフローがネットショップ、マーケティング、サポートにまたがる。
Tajo はすべての接続機能を置き換えるものではありません。その接続機能が扱うデータを、より信頼できるものにします。
連携チェックリスト
新しい業務ツールの連携を稼働させる前に、このチェックリストを使いましょう。
- ワークフローが平易な言葉で書かれている。
- きっかけとなるイベントが定義されている。
- 送信元システムが明記されている。
- 送信先システムが明記されている。
- 項目ごとに信頼できる情報源が定義されている。
- 同期の方向が文書化されている。
- 必須項目が対応付けられている。
- 同意と配信停止のルールが守られている。
- 重複の突き合わせルールが文書化されている。
- エラー処理が設定されている。
- 再試行の挙動が把握されている。
- ワークフローの担当者が割り当てられている。
- サンプルレコードでの検証に合格している。
- 本番稼働はまず 1 つのワークフローに限定している。
- 稼働後に監視状況を確認する。
いずれかが欠けている場合、技術的には動くかもしれませんが、運用上の準備は整っていません。
よくある失敗
データの所有権を決める前にアプリをつなぐ
これはレコードの矛盾と予測できない上書きを生みます。まず所有権を決めましょう。
すべての項目を同期する
項目が増えるほど失敗する箇所も増えます。そのワークフローに必要な項目だけを同期しましょう。
競合ルールなしで双方向同期を使う
双方向の同期には、時刻のルール、権限のルール、項目単位の所有権が必要です。
エラーログを無視する
静かに失敗する連携は、チームが動いていると思い込む分、手作業のワークフローより悪い状態です。
誰でも本番の自動化を編集できるようにする
ノーコードのワークフローでも、顧客、売上、コンプライアンスに影響します。編集権限を制限しましょう。
処理量を忘れる
20 件で動くワークフローが 20,000 件では、レート制限、費用、待ち行列の遅延で失敗することがあります。
連携を一度きりのプロジェクトと考える
提供元は API を変更し、チームは項目を増やし、業務プロセスも変わります。連携には保守が必要です。
現実的な展開計画
次の順序を使いましょう。
| 週 | 作業 |
|---|---|
| 1 | ツール、担当、データの対象、現在の連携を棚卸しする |
| 2 | ワークフローを 1 つ選び、信頼できる情報源、きっかけ、送信先、失敗時の影響を定義する |
| 3 | 検証環境またはサンプルレコードで構築する |
| 4 | 同意、重複、項目の対応付け、エラー通知を検証する |
| 5 | 限定した実データの範囲で稼働する |
| 6 | ログを確認し、例外を直し、ワークフローを文書化する |
| 7 以降 | 最初のワークフローが安定してから次を追加する |
この慎重な進め方は、後から不正確なデータを片付けずに済むため、結果的に速いことがほとんどです。
最後に
複数の業務ツールの連携は、事業を運営しやすくするためのものであって、理解しにくくするためのものではありません。
最良の連携の方針は単純です。
- データの対象ごとに信頼できる情報源を 1 つ保ちます。
- 標準で対応している単純なワークフローには標準の接続機能を使います。
- アプリをまたぐきっかけと動作の処理には自動化プラットフォームを使います。
- 独自の制御が必要なときは API と Webhook を使います。
- 多くのツールが同じ運用上の文脈を必要とするときは、顧客データまたは同期の層を使います。
- 本番システムと同じように失敗を監視します。
ネットショップ、CRM、マーケティング自動化、カスタマーサポートを複数のツールで運営しているチームにとって、Tajo は他の仕組みが機能するだけの一貫した顧客データを保つ助けになります。まず 1 つのワークフローから始め、有効性を確かめ、文書化し、そこから広げていきましょう。