Microsoft 365 Copilot connectorsのWebhook更新とは？2026年10月予定と管理者の対応

Microsoft 365 Copilot connectorsでJiraやGitHubなどの外部データを検索できても、ステータス変更やドキュメント更新がインデックスに反映されるまで時間がかかれば、Copilotが古い情報を回答する可能性があります。

2026年7月10日時点のMicrosoft 365 Roadmapでは、この課題に対し、Webhookのイベント通知を利用して更新をより頻繁に同期する機能が示されています。対象はAzure DevOps、Jira Cloud、Confluence Cloud、Trello、Asana、Bitbucket、GitHub、GitLabです。現在のステータスは「In development」で、一般提供の目標は2026年10月です。(Microsoft)

ただし、今回の更新は「すべての変更が即時反映される」という意味ではありません。同期型コネクターのデータ境界は変わらず、アクセス権変更や削除がWebhookだけで即座に反映されるとも明記されていません。対象コネクターを利用している組織は、接続の作り直しを急ぐのではなく、データ範囲、権限マッピング、フルクロール、許容できる更新遅延を今のうちに確認することが重要です。

Microsoft 365 Copilot connectorsのロードマップ更新内容

今回のロードマップ項目は、新しいデータソースを追加するものではありません。既存のMicrosoft 365 Copilot connectorsにおける「データの鮮度」を改善する更新です。

項目	2026年7月10日時点の内容
ロードマップID	505441
機能	Webhookイベント通知を利用したコンテンツ鮮度の改善
期待される効果	更新をより頻繁に同期し、Copilotや検索で新しい情報を利用しやすくする
ステータス	In development
一般提供目標	2026年10月
対象環境	Worldwide（Standard Multi-Tenant）、Web
対象サービス	Azure DevOps、Jira Cloud、Confluence Cloud、Trello、Asana、Bitbucket、GitHub、GitLab

Microsoft 365 Roadmapは、変更前後の完全な履歴を表示する変更ログではありません。そのため、公式ページだけを根拠に「以前の予定日から何カ月延期された」と断定するのは避けるべきです。確実に判断できるのは、現行ロードマップでは一般提供目標が2026年10月に置かれ、まだ開発中であるという点です。

また、ロードマップの日付は確定日ではなく、Microsoft自身も予定や説明が変更される可能性を明記しています。社内計画では2026年10月を「全テナントで必ず利用できる日」ではなく、「現時点の提供目標」として扱う必要があります。(Microsoft)

Webhook-driven freshnessで何が変わるのか

Microsoft 365 Copilotの同期型コネクターは、外部サービスのコンテンツをMicrosoft Graphへ取り込み、検索用インデックスを作成します。

従来の更新確認は、設定された間隔で実行する増分クロールやフルクロールが中心です。Webhookイベント通知が加わると、外部サービスで変更が起きたことをコネクター側が早く検知し、更新対象の同期を開始しやすくなります。

概念的には、次の流れです。

Jiraの課題、GitHubのPull Request、Asanaのタスクなどが更新される
外部サービスから変更イベントが通知される
Copilot connectorが更新対象のコンテンツやメタデータを取得する
Microsoft Graph内のインデックスが更新される
Microsoft 365 CopilotやMicrosoft Searchが新しい情報を検索できるようになる

ロードマップで明記されているのは、「Webhookイベント通知を利用して、更新をより頻繁に同期する」という点までです。Webhookのペイロード、再試行方式、対象イベント、最大遅延、SLAなどは公開されていません。

したがって、Webhook対応後も「リアルタイム」「即時反映」「必ず数秒以内」といった前提で業務を設計するべきではありません。

同期型、Webhook対応、フェデレーション型の違い

方式	データの取得方法	Microsoft 365側への保存	鮮度の考え方	主な用途
従来の同期型コネクター	定期クロール	Microsoft Graphにインデックス	クロール間隔に依存	組織全体の検索、幅広いナレッジ活用
Webhook対応の同期型コネクター	イベント通知と同期処理	Microsoft Graphにインデックス	変更を早く検知できる可能性がある	課題、タスク、レビュー状況など更新頻度の高い情報
フェデレーション型コネクター	質問時に外部サービスへ問い合わせ	原則としてインデックスしない	実行時の情報を取得	動的、機密性が高い、保存を避けたいデータ

今回のロードマップ項目は、同期型コネクターの鮮度改善です。外部データをMicrosoft 365側へ保存せず、質問時に取得するフェデレーション型コネクターへの移行ではありません。同期型ではコンテンツ、メタデータ、アクセス制御リストがMicrosoft Graphへ取り込まれます。一方、フェデレーション型ではデータをMicrosoft Graphに同期せず、実行時に取得します。(Microsoft Learn)

対象となる8サービスと業務での使いどころ

対象サービスはロードマップ上ではサービス単位で記載されています。ただし、実際の管理画面では、GitHubのIssues、Knowledge、Pull Requestsのように、コンテンツ種別ごとに別のコネクターが用意されている場合があります。

対象サービス	主に扱われる情報	鮮度改善が役立つ場面	導入前に確認すること
Azure DevOps	Work Items、Wiki	バグ、タスク、スプリント状況、運用手順の確認	Work ItemsとWikiのどちらを接続しているか
Jira Cloud	課題、チケット、ステータス、担当者	障害、ブロッカー、優先度、進捗の要約	Jira Cloudのみが対象で、ServerやData Centerとは別であること
Confluence Cloud	ページ、ブログ、添付コンテンツ	手順書、設計書、社内規程、リリース情報の検索	対象スペース、CQLフィルター、ページ制限
Trello	カード、期限、担当者、ラベル	アクションアイテムや計画の確認	コメントはインデックスされないこと
Asana	タスク、プロジェクト、コメント、添付ファイル	期限、担当者、遅延タスク、プロジェクト状況の把握	カスタムフィールド、Goals、Portfoliosは対象外
Bitbucket	Knowledge、Pull Requests	リポジトリ内文書、コードレビューの確認	KnowledgeとPull Requestsのどちらを使うか
GitHub	Issues、Knowledge、Pull Requests	Issue、仕様書、レビュー、リリース準備の確認	CloudかServerか、対象コンテンツ種別は何か
GitLab	Issues、Knowledge、Merge Requests	課題、技術文書、マージ状況の確認	CloudかServerか、対象コンテンツ種別は何か

Microsoftのコネクターギャラリーでは、Azure DevOps WikiとWork Items、GitHub CloudのIssues・Knowledge・Pull Requests、GitLabのIssues・Knowledge・Merge Requestsなどが個別に掲載されています。ロードマップはサービス名を広く記載しているため、すべての派生コネクターやイベントが同時に対応するとは限りません。展開時には、接続ごとのドキュメントとMicrosoft 365メッセージセンターを確認する必要があります。(Microsoft Learn)

また、各コネクターにはデータ範囲の制限があります。たとえば、Trelloはコメントをインデックスせず、AsanaはカスタムフィールドやGoals、Portfoliosを対象にしません。Confluence Cloudでは権限変更が増分同期ではなくフルクロールで反映されます。Webhookで鮮度が改善されても、コネクターが取得しない情報まで検索できるようになるわけではありません。(Microsoft Learn)

利用に必要なライセンスと管理者権限

同期型コネクターを設定する条件

Microsoft 365 Copilot connectorsをMicrosoft 365管理センターから展開するには、基本的に次の準備が必要です。

Microsoft 365管理センターのAI管理者ロール
Jira、Confluence、Asanaなど接続先サービスの管理権限
APIキー、サービスアカウント、アクセストークンなどの認証情報
インデックス対象コンテンツへアクセスできる権限
接続先URL、ワークスペース、組織、プロジェクトなどの設定情報

Microsoft 365管理センターでは、Copilot、Connectors、Galleryの順に進み、対象コネクターを選択します。Microsoftは、組織全体へ展開する前に、一部ユーザーを対象として検証する方法を案内しています。(Microsoft Learn)

ライセンスによって利用できる範囲が異なる

ライセンス構成	同期型コネクターをMicrosoft Searchで利用	Microsoft 365 Copilotのグラウンディング	フェデレーション型
Microsoft 365のみ	利用可能	利用不可	利用不可
Microsoft 365とMicrosoft 365 Copilotアドオン	利用可能	利用可能	利用可能
Microsoft 365 E7	利用可能	利用可能	利用可能
Microsoft 365とCopilot Studio	利用可能	エージェントのナレッジとして利用	利用不可
Microsoft 365 Copilot従量課金	利用可能	エージェントのナレッジとして利用	利用不可

同期型コネクターのインデックス作成自体は、Microsoft 365ライセンスを持つテナントでは追加料金がかからないと説明されています。ただし、取り込んだ外部データをMicrosoft 365 Copilotの回答に利用するには、対象ユーザーに適切なCopilotライセンスが必要です。ライセンス体系は変更される可能性があるため、実際の購入や展開前には契約中プランの条件を再確認してください。(Microsoft Learn)

プレビュー中の同期型コネクターを管理者が確認する場合は、管理者アカウントで対象指定リリースを有効にする必要がある場合があります。(Microsoft Learn)

データ境界は変わらない

Webhookという言葉から、外部サービスのデータを直接参照する仕組みに変わると誤解しやすいですが、今回の対象は同期型コネクターです。

同期型コネクターでは、外部データの次の情報がMicrosoft Graphのインデックスへ取り込まれます。

本文や説明などのコンテンツ
タイトル、URL、更新日時、担当者などのメタデータ
どのユーザーやグループが閲覧できるかを示すACL
検索やCopilotで使用するスキーマ情報

外部サービスは引き続き原本を管理するシステムですが、検索用のコピーはMicrosoft 365テナント内に保持されます。ユーザーが検索結果やCopilotの回答を閲覧できるかどうかは、取り込まれたACLとIDマッピングによって制御されます。(Microsoft Learn)

機密データをMicrosoft 365側へインデックスすること自体が社内ポリシーに適合しない場合、Webhook対応の有無より先に、同期型コネクターを採用できるかを確認する必要があります。保存を避けたいデータについては、対象サービスにフェデレーション型コネクターが提供されているか、別の連携方式を検討します。

コンテンツの鮮度とアクセス権の鮮度は分けて考える

今回の更新で最も注意したいのは、コンテンツの更新速度とアクセス権の更新速度が同じとは限らない点です。

Microsoftの現行ドキュメントでは、増分クロールは新規または変更されたアイテムを同期しますが、アクセス権の更新には対応しません。アクセス権変更を反映するには、フルクロールを定期的に実行する必要があります。削除されたアイテムについても、増分クロールだけでは処理されず、フルクロールが必要になる場合があります。(Microsoft Learn)

たとえば、次の状態が発生する可能性があります。

Confluenceページの本文変更はWebhookによって早く反映される
同じページからユーザーの閲覧権限を外す
ACL変更は次回フルクロールまでインデックスに反映されない
その間、Microsoft 365側の権限情報が更新前の状態となる

実際にユーザーが閲覧できるかは接続方式や権限構成によりますが、少なくともロードマップには「WebhookによってACL変更や削除も即時反映する」とは書かれていません。

そのため、検証では本文やステータスの更新だけでなく、次の3種類を分けて測定する必要があります。

変更の種類	代表例	確認すべきこと
コンテンツ変更	課題のステータス、担当者、本文の更新	検索やCopilotへ反映されるまでの時間
権限変更	ユーザー追加、閲覧権限の取り消し	ACL更新にフルクロールが必要か
削除・移動	課題削除、ページ削除、対象範囲外への移動	古い検索結果が残る時間

管理者が確認すべき制御項目

アクセス範囲は原則として「アクセス権を持つユーザーのみ」にする

コネクターの設定では、インデックスしたデータを次のどちらへ公開するか選択できる場合があります。

接続元でアクセス権を持つユーザーのみ
組織内の全ユーザー

「組織内の全ユーザー」は設定が簡単ですが、外部サービス側の細かな権限を無視して広く公開することになります。全社員向けに公開済みの情報など、明確な根拠がある場合を除き、「アクセス権を持つユーザーのみ」を選ぶのが基本です。(Microsoft Learn)

IDマッピングを確認する

外部サービスのメールアドレスとMicrosoft Entra IDのユーザープリンシパル名が一致しないと、正しいセキュリティトリミングが行われない可能性があります。

特に注意が必要なのは、次のような環境です。

Microsoft 365では[email protected]を使用している
JiraやGitHubでは[email protected]を使用している
買収や組織再編により複数のメールドメインが混在している
外部委託者が外部サービスにだけ登録されている
共有アカウントやサービスアカウントがコンテンツ所有者になっている

標準のUPNまたはメールアドレスによるマッピングで一致しない場合は、カスタムマッピングを設定します。Webhookによる更新頻度が高くなっても、IDマッピングの誤りは自動的には解消されません。

インデックス対象を絞る

接続できるデータをすべて取り込むのではなく、業務目的に必要な範囲へ限定します。

たとえば、Confluenceでは対象スペースやCQL、Jiraでは対象プロジェクト、GitHubやGitLabでは対象リポジトリ、Asanaでは対象ワークスペースを明確にします。

絞り込みには次の効果があります。

機密データを誤って検索対象にするリスクを下げる
古いプロジェクトや重複文書による回答品質の低下を防ぐ
クロール量を減らし、検証しやすくする
回答に使われる情報の所有者を明確にする

フルクロールをなくさない

Webhook対応後も、フルクロールを不要と判断するのは危険です。現行ドキュメントでは、フルクロールが削除、ACL、スキーマなどの整合性を保つ役割を持っています。

管理者は、少なくとも次を記録しておく必要があります。

管理項目	記録する内容
増分同期	現在の実行間隔、平均反映時間
フルクロール	実行頻度、所要時間、権限反映時間
接続アカウント	所有者、認証方式、トークン更新方法
対象範囲	ワークスペース、プロジェクト、リポジトリ、スペース
IDマッピング	標準マッピングかカスタムマッピングか
障害時の連絡先	Microsoft 365管理者、接続先サービス管理者、業務責任者

自社で対応が必要かを判断する基準

状況	対応優先度	推奨する対応
対象8サービスのコネクターを本番利用している	高	現在の接続、同期時間、権限設定を棚卸しする
障害対応やリリース判断にCopilotの回答を使う	高	更新遅延の許容値を決め、Webhook対応後に再検証する
Jira、GitHub、GitLabなどで状態変更が多い	高	ステータス、担当者、レビュー状態の反映時間を計測する
ユーザーやグループの権限変更が多い	高	フルクロールとACL反映を重点的に検証する
Confluenceなど静的なナレッジが中心	中	一般提供時期を監視し、既存の同期遅延を記録する
Microsoft Searchでのみ利用している	中	検索結果の鮮度が業務に与える影響を確認する
対象サービスを使っていない	低	直ちに設定を変更する必要はない
独自開発のカスタムコネクターだけを使っている	低	今回の対象に含まれると仮定せず、追加情報を待つ
Governmentなど標準マルチテナント以外を利用している	要確認	本項目の日程をそのまま適用せず、対象クラウドの情報を確認する

特に対応優先度が高いのは、「古い情報が回答に混ざると業務判断を誤る」環境です。単に検索が少し遅いという問題ではなく、障害の解決状況、脆弱性対応、承認済みPull Request、出荷可否などの判断に使う場合は、鮮度を品質要件として管理する必要があります。

一般提供までに行う実務的な準備

接続を棚卸しする

まず、Microsoft 365管理センターで対象8サービスの接続を一覧化します。

接続ごとに次を記録します。

コネクター名と種類
接続先サービス
Cloud、Serverなどの環境
対象プロジェクト、リポジトリ、ワークスペース
接続に使うアカウント
利用部門と業務責任者
コンテンツの公開範囲
増分同期とフルクロールの設定
Copilot、Copilot Search、Microsoft Searchのどこで利用しているか

GitHubやGitLabでは、Issues、Knowledge、Pull RequestsまたはMerge Requestsを別々に確認します。「GitHubを接続済み」という記録だけでは、ロードマップ更新の影響範囲を判断できません。

現在の反映時間を測る

Webhook対応後の改善度を判断するには、導入前の基準値が必要です。

たとえば、Jira Cloudで次の時刻を記録します。

記録項目	例
課題を更新した時刻	10:00
Microsoft Searchで更新を確認できた時刻	10:18
Copilotの回答に更新内容が反映された時刻	10:24
権限変更を行った時刻	11:00
権限変更が反映された時刻	翌日のフルクロール後

この計測を数回行い、平均値だけでなく最大値も把握します。一度だけ速く反映された結果を基準にすると、実運用で遅延したときに問題になります。

業務ごとの鮮度目標を決める

Microsoftが反映時間を保証していない段階では、自社側で許容時間を定義する必要があります。

利用シーン	社内目標の例
重大インシデントやセキュリティ課題	5～15分以内
Pull RequestやMerge Requestの承認状況	15～30分以内
タスク、担当者、期限の変更	30～60分以内
手順書、設計書、社内ナレッジ	当日中
規程やコンプライアンス文書	更新確認後に管理者が検証して公開

これらはMicrosoftの保証値ではなく、業務要件を整理するための例です。目標を満たせない場合は、Copilotだけで判断せず、接続元サービスを確認する運用を残します。

コンテンツと権限を別々にテストする

一般提供後の受け入れテストには、最低でも次を含めます。

テスト	操作	合格条件
新規作成	新しい課題やカードを作る	許容時間内に検索できる
本文更新	説明、タイトル、ステータスを変更する	古い内容ではなく更新後の内容が表示される
担当者変更	担当者を別ユーザーへ変更する	新しい担当者で検索できる
権限付与	ユーザーへ閲覧権限を与える	権限反映後に対象ユーザーだけが閲覧できる
権限取り消し	ユーザーの閲覧権限を外す	許容時間内に検索結果と回答から除外される
削除	課題やページを削除する	古い検索結果が残り続けない
大量更新	複数アイテムを一括変更する	遅延や欠落の有無を確認できる
接続障害	認証切れやAPI停止を想定する	障害検知と復旧手順が機能する

権限取り消しと削除は、本文更新よりも重要です。情報が新しくならない問題は業務効率を下げますが、権限を失った情報が検索できる状態はセキュリティ問題につながります。

一部ユーザーから展開する

最初から全社員を対象にせず、利用部門と管理者を含む小規模なグループで検証します。

パイロット利用者には、次のルールを明示します。

回答内の参照元リンクを確認する
更新日時が取得できる場合は確認する
重要な判断では接続元サービスを原本として扱う
古い情報や権限上の問題を報告する窓口を使う
Copilotの回答を業務イベントの確定通知として扱わない

開発者とエージェント作成者への影響

Microsoft 365 Copilot connectorsは、Copilot Studio、Microsoft 365 CopilotのAgent Builder、Microsoft 365 Agents Toolkitなどで作成するエージェントのナレッジソースとして利用できます。

Webhookによってインデックスの鮮度が改善されれば、次のようなエージェントで効果が期待できます。

インシデント対応エージェント

JiraやAzure DevOpsの障害チケットと、Confluenceの対応手順を組み合わせて、現在の影響、担当者、実施済み対応を要約します。

この用途では、チケットの状態更新は頻繁ですが、手順書の変更頻度は低いため、情報源ごとに鮮度要件を分けます。

スプリント・リリース確認エージェント

Azure DevOps、Jira、GitHub、GitLabの課題やレビュー情報を利用し、未解決のブロッカー、未承認の変更、期限超過タスクを整理します。

ただし、「すべてのPull Requestが承認済み」といった出荷判断をCopilotの回答だけで確定させるべきではありません。インデックスが最新である保証がない場合は、元のリポジトリやCI/CDシステムを確認します。

ナレッジ検索エージェント

Confluence、GitHub Knowledge、GitLab Knowledgeなどを横断し、設計判断、運用手順、オンボーディング資料を提示します。

回答品質を上げるには、エージェントの指示に次を含めると効果的です。

回答には参照元リンクを付ける
複数の情報が矛盾する場合は更新日時を比較する
更新日時が不明な場合は、その旨を回答する
手順書とチケットの内容を混同しない
削除済みまたは古い文書の可能性がある場合は原本確認を促す

業務自動化のWebhookとは分けて設計する

今回のWebhook対応は、Copilotや検索で使うインデックスの鮮度を改善するものです。確実なイベント配信、順序保証、トランザクション処理を提供する業務イベント基盤ではありません。

たとえば、「重大チケットが作成されたら担当者へ通知する」「Pull Requestが承認されたらデプロイを開始する」といった処理は、Jira、GitHub、GitLabなどのネイティブWebhook、Power Automate、Azure Functions、CI/CDパイプラインを使用します。

Microsoft 365 Copilot connectorのインデックスを監視して業務処理を開始する設計は避けるべきです。検索用インデックスは、原本データベースやイベントキューの代替ではありません。

また、Copilot Chatから外部システムへの書き込みは標準では行われません。Microsoftの説明では、コネクターコンテンツの利用は読み取り専用が基本であり、外部システムを更新するにはアクションコネクターやプラグインなどを別途設計します。(Microsoft Learn)

現時点で避けるべき対応

既存接続をすぐに作り直す

ロードマップには、既存の接続を削除して再作成する必要があるとは記載されていません。再作成すると、インデックスの再構築、設定漏れ、検索結果の一時的な欠落が発生する可能性があります。

コネクター固有の展開手順が公開されるまでは、現在の接続設定と基準値を保存することを優先します。

独自にWebhook受信URLを用意する

現時点の公式情報には、管理者がWebhook URL、シークレット、証明書を手動で登録する手順は示されていません。Microsoft管理のコネクターでサービス側に実装される可能性がありますが、ネットワーク要件や認証方式が公開されるまでは推測で設定を変更しない方が安全です。

特に、根拠なくファイアウォールへ受信許可を追加したり、外部公開エンドポイントを作成したりする必要はありません。

カスタムコネクターにも自動適用されると考える

ロードマップに挙げられているのは8つのサービスです。Microsoft Graph connectors APIやSDKで作成した独自の同期型コネクターが対象になるとは明記されていません。

独自コネクターでWebhook同期を実現したい場合は、外部サービスのイベントを受け取り、変更されたアイテムをMicrosoft Graphへ更新する現在の設計を継続します。公式APIやSDKの変更が発表されるまでは、今回のロードマップを開発仕様として扱わないことが重要です。

よくある疑問

2026年10月になれば、すべてのテナントですぐ利用できますか

保証されていません。ロードマップの日付は提供目標であり、段階的に展開される可能性があります。利用可否はMicrosoft 365管理センター、メッセージセンター、対象コネクターのドキュメントで確認します。

Copilotの回答がリアルタイムになりますか

リアルタイムになるとは明記されていません。Webhookにより更新を早く検知できるようになりますが、その後のデータ取得、インデックス処理、検索反映には時間がかかる可能性があります。

権限を外した情報もすぐに見えなくなりますか

今回のロードマップだけでは判断できません。現行ドキュメントでは、権限更新は増分クロールでは処理されず、フルクロールが必要です。一般提供後も、アクセス権取り消しの反映時間を必ずテストしてください。

すべてのGitHub、GitLab、Bitbucketコネクターが対象ですか

サービス名は対象として記載されていますが、Issues、Knowledge、Pull Requests、Merge Requests、Cloud、Serverなどの詳細な対象範囲は示されていません。接続単位の対応状況を確認する必要があります。

Webhook対応後はフルクロールを停止できますか

停止すべきではありません。フルクロールは、権限変更、削除、インデックス全体の整合性を保つために必要です。Microsoftから明確な変更案内が出るまでは、現在のフルクロール設定を維持します。

まとめ：今行うべきことは再構築ではなく、棚卸しと基準作り

Microsoft 365 Copilot connectorsのWebhook対応は、Jira、GitHub、Azure DevOpsなど更新頻度の高い外部データをCopilotで活用する組織にとって重要な改善です。2026年7月10日時点では開発中で、一般提供の目標は2026年10月とされています。

一方で、Webhook対応はフェデレーション型への移行ではなく、同期型コネクターのインデックス更新を高速化するものです。リアルタイム性、アクセス権変更、削除、すべてのコンテンツ種別への対応が保証されたわけではありません。

対象コネクターを利用している組織は、次の順序で準備を進めてください。

対象8サービスの接続とコンテンツ種別を棚卸しする
現在の更新、権限変更、削除の反映時間を測る
業務ごとに許容できる鮮度を決める
IDマッピングとアクセス範囲を見直す
フルクロールを含む受け入れテストを作成する
一部ユーザーで検証してから展開する

Copilotの回答を速くすることだけでなく、「誰が、どの情報を、どの時点の状態で閲覧できるか」まで確認することが、今回の更新を安全に活用するための判断基準になります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。