MiiTelの通話をAIへ開く前の確認項目｜MCPでつなぐ範囲

「通話の記録を、普段使っている生成AIから直接聞けるようになるらしい」「顧客との会話を外のAIに渡して、本当に大丈夫なのか」。営業とマーケの現場からは、期待と不安の両方が聞こえてきます。どちらの声も、もっともです。2026年6月16日、レブコムは通話や会議の記録を生成AIから読めるようにする「MiiTelのMCPサーバー」のベータ版の提供を始めました。発表では、読み取り専用であること、MiiTelの利用者の権限をそのまま引き継ぐことが示されています。通話をAIへ開くかどうかは、つなぐ作業の問題ではありません。本当は、誰の記録を・何のために・どのAIへ渡すかを先に決める問題です。この記事では、つなぐ前に確かめる項目を、手順の順番に整理します。

MiiTelのMCPサーバーで何が開くのか

最初に、公式の発表で確かめられる範囲を押さえておきます。レブコムの2026年6月16日の発表によると、MiiTelのMCPサーバーは、MiiTelにたまった会話のデータを、利用者が業務で使っている生成AIから直接参照できるようにする仕組みです。設計は読み取り専用で、AIの側からMiiTelの記録を書き換えることは想定されていません。

読めるデータとして挙がっているのは、通話や会議の文字起こし、感情の分析、言いよどみを数えるフィラーの分析、話者ごとのテキスト、感情のスコアです。対象になるのは、電話の解析、コールセンター向け、ウェブ会議の解析、対面の会話の解析といった、MiiTelの各製品にたまったデータです。どの製品を契約しているかで、開く記録の中身も変わります。

つなぎ方は、業界で共通の取り決めであるMCPを使います。発表では、複雑な開発をしなくても、対応するAIの道具に専用の接続先のアドレスを登録するだけで使い始められると説明されています。動作を確かめたのはクロードのデスクトップアプリで、ほかのAIの道具で使えるかは、それぞれの道具の側の対応しだいとされています。

なお、この仕組みは2025年12月23日に一度発表され、そのときは2026年の第1四半期に社内と一部の協力会社向けに試験版を出す予定とされていました。6月の提供もベータ版という位置づけです。料金、対象の契約、申し込みの方法は、確かめた時点の発表には書かれていません。ここは契約の前に営業の担当者へ確かめる項目になります。

開く前に決めるのは「誰の・何を・どこへ」

確認の項目は細かく分かれますが、根っこは3つの問いにまとまります。誰の権限で読むのか、どの記録を読ませるのか、どのAIの画面へ写すのか。この3つが決まっていない状態で接続先を登録すると、あとから項目を足しても、すでに誰かが使い始めた状態を追いかけることになります。

「誰の」は、MiiTelの権限の設計にそのまま結びつきます。発表によれば権限は引き継がれるので、MiiTelの中で広く見えている人は、AIからも広く読めます。「何を」は、電話の記録か、会議か、対面の会話かといった製品の範囲と、文字起こしか感情の数値かといったデータの種類です。「どこへ」は、つなぐ先のAIの道具と、その契約の条件です。

この3つは、決める人も違います。権限は営業の管理者とMiiTelの管理者、データの種類は使う部署の責任者、つなぐ先は情シスが受け持つのが自然です。一人で全部を決めないことが、見落としを減らすいちばんの近道になります。

MCPでつなぐときの審査の一般的な項目、たとえば認証のかけ方や提供元の確かめ方は、別の記事で扱っている一般論に任せます。ここからは、MiiTelの通話という中身に固有の確認に絞って、順番に見ていきます。

確認項目1：読めるデータの種類を書き出す

最初の項目は、自社のMiiTelに実際に何がたまっているかを書き出すことです。発表に挙がっているデータの種類を並べ、そのうち自社で使っている製品に当てはまるものに印をつけます。電話だけを使っている会社と、ウェブ会議や対面の会話まで記録している会社では、開くものの重さがまったく違います。

文字起こしと、感情のスコアやフィラーの数は、同じ通話から作られていても性質が別物です。文字起こしには顧客の発言がそのまま残ります。一方、感情やフィラーの数値は、話し手の話しぶりを測ったものです。数値のほうは、営業担当者一人ひとりを測る材料として読まれやすいので、開くかどうかを別に判断します。

会議や対面の会話の記録には、社内だけの打ち合わせが混ざっていることがあります。採用の面談、評価の面談、経営の会議まで同じ置き場に入っていないかを確かめます。入っているなら、それらはAIから読ませる範囲の外に置くか、MiiTelの側で見える人を絞ってからつなぎます。

書き出した一覧は、あとで使う確認表の最初の行になります。「電話の文字起こしは開く」「感情のスコアは当面開かない」「会議の記録は営業部の定例だけ」のように、製品とデータの種類の組み合わせで、開く・開かないを一行ずつ決めておくと、後の判断がぶれません。

確認項目2：誰の権限で読むのかを確かめる

発表では、アクセスの権限はMiiTelの利用者の権限をそのまま引き継ぐ設計とされています。つまり、AIから読める範囲は、その人がMiiTelの画面で見られる範囲と同じです。これは安心材料である一方、MiiTelの権限が広すぎれば、その広さがそのままAIに写るということでもあります。

導入してしばらくたったMiiTelでは、権限が当初の設計より広がっていることがよくあります。異動した人が前の部署の記録を見られたまま、応援で入った人が全員の通話を聞ける設定のまま、といった状態です。つなぐ前に、管理画面で役割ごとの見える範囲を一覧にし、今の組織に合っているかを見直します。

特に確かめたいのは、全員の通話を見られる管理者の権限を持つ人の数です。管理者がAIに「今月の全通話から、よく出る懸念を挙げて」と聞けば、部署をまたいだ記録が一度に要約されます。それが必要な役割の人だけに管理者の権限が残っているかを確かめます。

もう一つ、引き継がれるのが画面の権限だけなのか、ほかの制限も含むのかは、発表からは読み切れません。たとえば、見られる期間の制限や、特定の通話を非表示にする設定がAIからの参照にも効くかどうかです。ここは試しの利用者で実際に聞いてみて、見えないはずの記録が答えに出てこないかを確かめる項目にします。

確認項目3：つなぐ先のAIの契約条件を確かめる

発表では、入力された通話の内容や文字起こしのデータが、外部のAIの学習に使われることはないと説明されています。ただし、これはレブコムの側の説明です。読み出された記録は、つなぐ先のAIの画面に写り、そのAIの会話の履歴として残ります。その先の扱いは、つなぐ先のAIの契約で決まります。

確かめるのは、つなぐ先のAIが会話の内容を学習に使うかどうか、会話の履歴をどれだけの期間保存するか、管理者が履歴を消したり見たりできるか、の3点です。個人向けの契約と法人向けの契約で既定の扱いが違う道具も多いので、社員が使っている契約の種類まで確かめます。

動作を確かめたと発表されているのはクロードのデスクトップアプリですが、社員が個人の契約で使っているものと、会社で契約しているものが混ざっていることがあります。会社の契約のAIだけに接続先を登録させる、という線を先に引いておくと、学習や保存の条件がばらばらになるのを防げます。

学習させない設定の確かめ方そのものは、道具ごとに画面が違い、一般論としては別の記事で扱っています。ここで大事なのは、MiiTelの側の説明だけで安心しないことです。扉の手前と向こう側の両方の条件がそろって、はじめて通話を渡してよいと言えます。

確認項目4：接続先のアドレスを誰が登録するか

発表のとおり、つなぐ作業は、対応するAIの道具に専用の接続先のアドレスを登録するだけです。手軽なのは良いことですが、手軽だからこそ、社員が自分の判断でつなぎ始めることが起こり得ます。登録を誰ができるのか、管理者の許可が要るのかは、確かめた時点の発表には書かれていません。

そこで、契約の前に営業の担当者へ確かめる質問を用意しておきます。接続先のアドレスは利用者ごとに発行されるのか、会社で一つなのか。管理者が接続を許す人を絞れるのか。接続した人と日時の記録を管理者が見られるのか。つないだ接続を管理者の側から切れるのか。この4つの答えで、運用の組み立て方が変わります。

管理者の側で絞れない場合は、運用の決まりで補います。登録してよい人の一覧を作り、登録したら申告してもらう形です。完全には防げませんが、誰がつないでいるかを把握できるだけでも、問題が起きたときの初動が早くなります。

つなぐ先のAIの側にも、接続を許すかどうかを管理者が決める設定を持つ道具があります。MiiTelの側で絞れないなら、AIの側で絞れないかを情シスが確かめます。どちらの側で絞るかを決めて、その場所を確認表に書いておきます。

確認項目5：ベータ版を業務で使う条件

MiiTelのMCPサーバーは、2026年6月の提供の時点でベータ版です。ベータ版は、仕様が変わったり、提供の形が変わったりすることを前提に使うものです。業務に組み込む前に、ベータ版のうちは何に使ってよく、何には使わないかを決めておきます。

目安になるのは、止まっても業務が回るかどうかです。たとえば、月に一度、よく出る質問を洗い出して記事の題材を探す使い方なら、止まっても手作業に戻せます。一方、毎日の顧客への連絡の前に必ずAIで通話を要約する、という流れに組み込むと、止まった日に業務が詰まります。

ベータ版の利用条件そのものも確かめます。ベータ版の間の料金の扱い、正式版に移ったときの条件、ベータ版の間に起きた不具合の扱いなどです。これらは発表には書かれていないので、契約の前に書面で確かめ、答えを確認表に残します。

正式版に移るときは、改めて確認表の全行を見直します。ベータ版の間に決めた例外や仮の運用を、そのまま正式版に持ち込まないためです。とくに料金の条件が変わると、使う人の範囲を広げるか絞るかの判断が変わります。移行の案内が出たら、試しで使っていた人の意見と検収の手間の記録を持ち寄り、続けるかどうかを改めて決めます。

• 料金・対象の契約・申し込み方法は、確かめた時点（2026年9月）の公式の発表に記載がありません。契約の前に確認してください
• ほかのAIの道具で使えるかは、道具の側の対応しだいと発表されています。社内で使う道具で動くかを試しで確かめます
• ベータ版の仕様は変わることがあります。お知らせの確認を担当する人を決めておきます

確認項目6：通話に出てくる顧客の情報の扱い

通話の記録には、顧客の担当者の名前、役職、話した内容がそのまま入っています。つまり、通話をAIから読めるようにすることは、顧客の個人の情報を新しい使い方に回すことでもあります。録音したときに顧客へ伝えた利用の目的の範囲に、今回の使い方が入っているかを確かめます。

たとえば、録音の目的を「応対の品質の向上のため」とだけ伝えている場合、よく出る質問を集めて記事や資料を作る使い方が、その範囲に入るかは判断が分かれます。自社のプライバシーポリシーと、録音の告知の文言を並べて読み、法務と一緒に確かめます。録音の同意そのものの考え方は、商談の録音を扱った別の記事に譲ります。

顧客との秘密保持の取り決めも見落とせません。商談の中で相手が話した未公表の計画や社内の事情は、秘密保持の対象になっていることがあります。そうした記録を外のAIに写すことが取り決めに反しないかを、主要な取引先ごとに確かめます。

確かめた結果、特定の顧客や特定の種類の商談を外すと決めたなら、その外し方も決めます。MiiTelの側で見える人を絞るのか、AIに聞くときに対象を外すのか。後者は聞く人の注意に頼ることになるので、できるだけ前者で外すほうが確実です。

確認項目7：AIに聞かせる問いを先に決める

権限と契約が整ったら、何を聞かせるかを決めます。発表では、営業での失注の兆しの検知や、話し方の分析、コールセンターでの応対の品質の管理、経営での商談の分析といった使い方が例に挙がっています。自社でどれを使うかを、目的から選びます。

マーケの側から見て使いやすいのは、顧客がよく口にする質問や懸念を拾い、記事や資料の題材の候補を出させる使い方です。「この3か月の初回の商談で、料金以外に多く出た懸念を5つ、発言の日付つきで挙げて」のように、期間と場面と数と根拠を決めて聞きます。

問いを決めておく理由は、聞く人ごとに問いがばらばらだと、答えもばらばらになり、どれを信じてよいか分からなくなるからです。部署でよく使う問いを5つほど書き出し、共通の雛形にしておきます。雛形には必ず「元の通話の日付と話者を添えて」と入れ、根拠を書かせます。

受注と失注の束を比べて勝ち筋を探すような分析の組み立ては、商談解析の手順として別の記事で扱っています。この記事で決めておきたいのは、通話を開いたあとに、最初にどの問いから始めるか、という入口の範囲です。

聞かせない問いと、使わせない用途

聞かせる問いと同じくらい大事なのが、聞かせない問いを決めることです。AIに判断させないことを、つなぐ前に文字で書いておきます。判断を任せてしまう使い方は、答えがもっともらしいほど気づかれにくいからです。

• 「この担当者は成績が悪い理由を挙げて」と、個人の評価をAIの要約で決める
• 感情のスコアの高低で、担当者の順位を作って配る
• 「この顧客に次に何を約束すればよいか」と聞き、答えをそのまま顧客に伝える
• 失注の兆しがあると出た商談を、人が記録を読まずに打ち切る
• 要約だけを社外向けの資料に貼り、発言の元を確かめない

個人の評価については特に慎重に扱います。話しぶりの数値や要約は、担当者の働きぶりの一部しか写していません。評価に使うかどうかは人事の決まりの話で、AIとつなぐかどうかとは別に、社内で合意してから決めるべきことです。当面は評価に使わない、と明記しておくのが無難です。

顧客への対応も同じです。AIが「値引きを提案すべき」と答えたとしても、それは記録から作った一つの候補にすぎません。何を約束するか、どう返事をするかは、担当者と上長が記録と状況を見て決めます。

もう一つ、通話の記録を読ませた会話の中で、ほかの道具を動かす指示を重ねないことも決めておきます。文字起こしには、顧客が話した言葉がそのまま入っています。読み込んだ記録の中の言葉を、AIが指示と取り違える可能性もゼロではありません。通話を読ませる会話は要約と傾向の候補出しだけに使い、メールの送信や記録の更新のような作業とは分けます。

答えを検収する：発言の元に戻る

AIが出した傾向や要約は、そのまま使わず、元の通話に戻って確かめます。文字起こしには聞き違いが残ることがあり、AIの要約はその聞き違いをもっともらしく整えてしまうことがあるからです。人が確認する範囲を先に決めておくことで、検収の手間が読めるようになります。

目安としては、社内のメモで終わるものは要約を読むだけ、記事や資料に使うものは元の発言を必ず読む、顧客に関わる判断に使うものは録音まで聞く、の3段階に分けます。どの段階の使い方かを、答えを使う前に決めておきます。

検収のときに見るのは、挙がった懸念が本当にその数だけ出ているか、日付と話者が合っているか、特定の一社や一人の発言に偏っていないか、の3点です。5件の懸念のうち3件が同じ顧客の発言だった、ということは珍しくありません。偏りがあれば、傾向ではなく一社の事情として扱います。

記事や資料に反映するときは、顧客が特定される言い回しを外します。業種や規模の言い方をぼかし、発言そのものを引用しない形に書き直します。反映するかどうかと、どこまで書くかは人が決めます。AIには下書きまでを任せます。

開く前の確認項目一覧

ここまでの確認項目を、1枚の表にまとめます。つなぐ前にこの表を埋め、埋まらない行が残っている間は、試しの範囲を超えて広げないようにします。

確認項目	確かめること	確かめる相手・場所	決める人
読めるデータ	契約している製品と、開くデータの種類（文字起こし・感情・フィラー）	自社のMiiTelの契約と管理画面	使う部署の責任者
誰の権限か	役割ごとの見える範囲、管理者の権限を持つ人の数	MiiTelの管理画面	営業の管理者
つなぐ先のAI	学習に使うか、履歴の保存期間、管理者が履歴を扱えるか	つなぐ先のAIの契約と管理画面	情シス
登録する人	接続先の発行単位、許可の要否、接続の記録、管理者側から切れるか	レブコムの営業の担当者（契約前）	情シス
ベータ版の条件	料金、正式版への移行、止まったときの代わり	レブコムの営業の担当者（書面）	導入の責任者
顧客の情報	利用の目的の範囲、秘密保持の取り決め、外す顧客	プライバシーポリシー・取引の契約	法務
聞く問い	部署で使う問いの雛形と、聞かせない問い	部署の運用の決まり	使う部署の責任者
検収	用途ごとの確かめる深さ（要約・発言・録音）	部署の運用の決まり	使う部署の責任者

表の「決める人」の列は、会社ごとに置き換えてかまいません。大事なのは、どの行にも名前が入っていることです。名前の入らない行は、誰も確かめないまま残ります。

表は一度埋めて終わりではありません。ベータ版の仕様が変わったとき、つなぐ先のAIの契約を変えたとき、組織が変わったときに、該当する行を見直します。見直した日付を表の端に書いておくと、いつの判断かが後から分かります。

契約の前であれば、この表はそのまま営業の担当者への質問票として使えます。答えが書面で返ってこない行は、分からないまま進めない、と決めておくと、ベータ版の手軽さに押されて判断を先送りすることを防げます。口頭の答えしか得られなかった行は、その旨を表に書き、試しの範囲で実際に確かめる項目に回します。

小さく始める手順

表が埋まったら、いきなり全員に開かず、小さな範囲で試します。次の手順は、営業とマーケの数人で始める場合の一例です。

試しの期間に大事なのは、うまくいったかどうかよりも、想定と違ったことを書き残すことです。見えないはずの記録が出てきた、問いによって答えの質が大きく変わった、といった気づきが、広げるときの決まりの材料になります。

試しの記録は、1回の問いにつき1行で残します。聞いた問い、答えの要点、元の発言で確かめた結果、かかった時間の4つです。1か月で数十行たまれば、どの問いが役に立ち、どの問いは検収の手間ばかりかかるのかが見えてきます。この記録が、部署の問いの雛形を育てる材料になります。

試しに加わる人には、始める前に確認表と入れてはいけない問いの一覧を渡し、終わったら感想を一言ずつ書いてもらいます。現場の感想は、数字の記録では拾えない使いにくさを教えてくれます。

やりがちな失敗

通話をAIへ開くときにつまずきやすい形を、並べておきます。どれも、つなぐ作業の手軽さに対して、決めごとが追いつかないことから起きます。

• 読み取り専用と聞いて安心し、MiiTelの権限の見直しをしないままつなぐ
• MiiTelの側の学習の説明だけを見て、つなぐ先のAIの契約を確かめない
• 社員が個人の契約のAIに接続先を登録し、会社が把握していない
• ベータ版のまま、毎日の顧客への連絡の流れに組み込む
• AIの要約を元の発言に戻らずに記事や資料に使い、聞き違いがそのまま外に出る

2つ目と3つ目は、組み合わさると見えにくくなります。会社の契約では学習に使わない設定でも、社員が個人の契約で同じAIを使っていれば、条件は別です。接続先を登録してよいのは会社の契約の道具だけ、という線を、案内の最初に書いておきます。

失敗に気づくのは、たいてい現場の人です。気づいたら誰に知らせればよいか、どの時点で接続を止めるかを、案内の最後に一行添えておくと、問題が小さいうちに手を打てます。

失敗が起きたときは、責める材料ではなく、決まりを直す材料として扱います。誰が悪いかより、どの確認項目が抜けていたかを確認表に書き戻します。同じ失敗が二度起きないように、案内の文面や試しの手順を直し、直した日付を残しておきます。

止め方と、見直しのきっかけ

開く前に、止め方も決めておきます。問題が起きたときに、誰が、どこで、どの順番で接続を切るのかです。MiiTelの側で切れるのか、つなぐ先のAIの側で切るのか、両方なのかは、確認項目4で確かめた答えによって変わります。

止めるきっかけの例としては、見えないはずの記録が答えに出てきたとき、顧客から録音の使い方について問い合わせがあったとき、つなぐ先のAIの契約の条件が変わったとき、が挙げられます。こうしたときは、原因を調べる前に、まず接続を止めてから確かめる順番にします。

定期の見直しは、日付で決めるより、出来事で起こすほうが漏れにくくなります。ベータ版から正式版に移ったとき、MiiTelの契約の製品を増やしたとき、組織の改編で権限を変えたとき、の3つを見直しのきっかけにして、確認表を見直します。

止め方を決めてあると、開く判断そのものも軽くなります。いつでも止められる形で、狭く始めて、確かめながら広げる。通話という重い記録を扱うからこそ、この順番を守ることが、現場の安心と使い道の両方を守ります。

まとめ

MiiTelのMCPサーバーは、2026年6月16日に提供が始まったベータ版で、通話や会議の文字起こし、感情やフィラーの分析を、読み取り専用で生成AIから参照できるようにします。権限はMiiTelの利用者の権限を引き継ぐので、つなぐ前にMiiTelの権限を見直し、つなぐ先のAIの学習と保存の条件を確かめ、登録してよい人と道具を決めます。料金や対象の契約は発表に無いため、契約の前に確かめます。AIに任せるのは傾向の候補出しと要約までにし、個人の評価や顧客への対応はAIに判断させません。答えは発言の元に戻って人が検収し、いつでも止められる形で狭く始めましょう。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。