電話に出るAIがゲートを開ける｜蘭ParkBeeの公表値

駐車場の入口でゲートが開かない。車は止まったままで、後ろには別の車が並んでいる。この状態でサポートに電話をかけた人が求めているのは、丁寧な説明ではなく通過です。

オランダの ParkBee は、この電話をAIに任せました。公式事例を読むと、工夫しているのは応答の文面ではありません。予約データと現地の設備にAIをつなぎ、予約を照合してからゲートを開けるところまで実行させたという点です。問い合わせへの回答ではなく、業務そのものを渡しています。

先に公表されている値を書きます。成果として並んでいるのは3つで、解決1件あたりの費用が約50%減、平均処理時間が72%減、そして有効な予約を持つ人からの電話は70%が人を介さずに終わる、というものです。ただし、どの値にも集計期間が書かれていません。前年比や推移としては読めません。

この記事では、事例ページに書かれている導入前の状態、AIに任せた処理の範囲、公表値の母数を一次情報だけで整理します。そのうえで、電話の窓口をAIに任せることを検討している日本の事業者が、先に決めておくべき項目を取り出します。確認日は2026年10月31日です。

電話の大半は「入口で止まっている人」だった

ParkBee は、使われていない民間の敷地やオフィスの駐車場、住宅の車庫を予約できる駐車枠に変えて提供しています。公式サイトはこれを、路外駐車場の密な digital network を作る事業だと説明しています。アプリから駐車場の予約、月額の契約、オランダ限定の路上駐車を扱う形です。事例ページによると、事業はオランダ、ベルギー、英国、ドイツの4か国にまたがっています。

問題は、その成長そのものから生まれていました。事例ページは、前年比40%で伸びるなかで電話の支援体制が限界に近づいていたと書いています。約20人のパート体制で、月10,000件の通話を受けていました。しかも需要は平らではありません。17時から19時と週末に集中します。人が駐車場を使う時間は、サポートの人員を厚くしにくい時間とほぼ重なります。

待ち時間が2分を超えた通話は、BPOのパートナーへ転送していました。この転送は通話ごとの課金です。通話が増えれば費用もそのまま増えます。それでも混み合う時間帯には、最大で7分待つ利用者がいたとされています。顧客体験のマネージャーである Marco Seeleman さんは、待たせる時間が1秒伸びるごとに顧客の信頼を失うと述べています。

そしてこの窓口にかかってくる電話の内容には、強い偏りがありました。事例ページは、通話の約70%が入口の遮断機の前で立ち往生したドライバーからのものだったと書いています。内容が偏っているということは、処理の手順も同じ形に偏っているということです。予約を確かめ、場所を特定し、ゲートを開ける。この3つが、通話のほとんどを占めていたことになります。

答えを返すのではなく、予約を照合して設備を動かす

ParkBee は、電話にAIを入れる前に chat で Fin を使っていました。Intercom のナレッジベースを使った形で、事例ページは結果が有望だったと書いています。そのうえで Seeleman さんは、強いストレスのかかった場面にいる顧客をすばやく助ける機会が電話にあると考えたと述べています。

実装の中心は、文章の調整ではなく接続でした。事例ページによると、ParkBee は Fin を自社のバックエンドに直接つなぎ、電話での解決が最後まで完結する形にしています。着信を受けると、その場で予約の有効性を確認し、場所の詳細を取り出し、該当する遮断機を動かし、通過できたことを確かめます。やりとりはすべて記録されます。

Seeleman さんは、外部のシステムを Fin につなぐと、それは質問に答えるものではなくなり、業務の一部になると述べています。この一文が、この事例の性格を決めています。同じ「AIで顧客対応を自動化した」という言い方でも、回答文を作る範囲にとどまるものと、現場の設備を動かす範囲まで届いているものは、設計も検証の必要量も別物です。

解決できないものは人へ渡します。事例ページが挙げているのは、設備の実際の故障と、期限が切れた予約です。引き継ぎのときにはそれまでの文脈を付けて渡す形になっています。また、Fin は24時間の多言語対応ができるため、欧州での展開にあわせて人を採用し続ける制約から外れる、とも書かれています。

製品側の説明もあわせて読むと、できることの範囲が分かります。Fin Voice の公式ページは、APIにつなぐことで返金の処理、記録の更新、アカウント情報の照会、情報の照合ができると書いています。電話の基盤としては Twilio、Genesys、RingCentral などの接続先が挙げられており、人への転送は、通話をそのまま渡す方法、折り返しの予約、ワークフローでの引き継ぎから選べるとされています。言語については 30-language support と表記されています。ParkBee の事例は、この機能の一部を駐車場の入場という1つの用途に絞って使った形です。

公表されている3つの値と、その母数

成果として並んでいる値は、読み方を間違えやすい形で並んでいます。順に確かめます。

1つ目は費用です。事例ページは、解決1件あたりの費用が約50%減ったとしています。本文には、以前なら直接BPOへ流れていた分量を今は Fin が受けており、費用はおおよそ半分だという記載もあります。比較の相手は自社の有人対応ではなく、通話ごとに課金される外部委託です。自社で対応していた分まで含めた全体の費用がどう動いたのかは書かれていません。

2つ目は処理の時間です。平均処理時間が72%減り、3分を超えていた通話が50秒未満になったとされています。Seeleman さんの発言としてこの値が引用されています。

3つ目が解決率です。ここに条件が付いています。事例ページは、有効な予約を持つ人が電話をかけてきた場合、Fin が最後まで完結させるのは70%で、人の手は要らないと書いています。残る30%について引き継ぎが起きる理由は、設備の本当の故障か、系統の不具合だとされています。つまりこの70%は、全着信に対する比率ではありません。予約そのものに問題がある人や、別の用件でかけてきた人は、この母数の外にいます。

公表されている値	母数・条件
解決1件あたりの費用が約50%減	基準になった金額の記載はありません
平均処理時間が72%減	3分を超えていた通話が50秒未満になったという記載
70%が人を介さず完結	有効な予約を持つ人からの電話に限ります
残る30%の引き継ぎ	設備の故障、または系統の不具合
月10,000件の通話	導入前の件数です。現在の件数は記載がありません
集計期間	いずれの値も記載がありません
待ち時間と満足度の現在値	記載がありません
導入の時期・期間・費用	記載がありません

比率だけが並んでいて、金額と件数の現在値が公表されていないことに注意してください。「1件あたりが半分になった」ことと「支出が半分になった」ことは別です。件数が増えていれば、1件あたりが下がっても総額は増えます。この事例から取れるのは金額の見込みではなく、処理をどこまで渡したかという設計です。

「解決した」は何を数えた数字なのか

解決率は、定義を確かめずに自社の目標値に使えません。Intercom の公式ヘルプは、Fin の解決の数え方を2通りに分けて説明しています。ひとつは顧客が肯定の返答を入力して確認する形で、ヘルプには「Ok thanks」「That helped」といった返答が例として挙がっています。もうひとつは、Fin の回答を受けた顧客が、それ以上の助けを求めずに会話を離れた場合です。後者は確認を取っていない解決として数えられます。

この区別は重要です。「離脱したから解決した」と数える方式が含まれている以上、解決率という1つの数字の中には、確かめた解決と、確かめていない解決が混ざります。自社で同じ指標を見るなら、どちらがどれだけ含まれるのかを分けて見る必要があります。

ただし、ここで止まる点があります。このヘルプページは chat と email の文脈で書かれており、料金の説明も chat と email を対象にしたうえで、Fin Voice については営業へ問い合わせる案内になっています。電話の解決をどう判定しているのかは、今回確認した公式ページからは分かりません。ParkBee の事例ページは「最後まで完結し、人の手は要らない」と書いており、これは通話が人へ転送されなかったことを指しているとも読めますが、判定の方法そのものは公表されていません。

数値の性格が分かりにくいのは、この事例に限った話ではありません。AIエージェントの指標は、会話がAIに渡った比率、AIが解決した比率、自動化された比率が別々に使われており、同じ呼び方でも母数が違います。指標の食い違いについては無料会員の会話だけをAIへ｜GloboplayがWhatsAppに置いた窓口でも扱いました。比べる前に定義をそろえる手間は、どの事例でも省けません。

日本の実務者が持ち帰れる点

この事例の要点は、AIの応答が上手かったことではありません。解決率が上がった理由は、AIが業務システムに接続され、確認してから操作する権限を与えられていたことです。同じ仕組みを検討するなら、文章の品質より先に決めることがあります。

• 偏っている用件から先に渡す。ParkBee が最初に任せたのは、通話の約70%を占めていた1種類の用件です。幅広い質問に答えられるようにするより、同じ手順の繰り返しを1つ選ぶほうが、接続する範囲も検証の範囲も小さくなります
• 確認なしで実行させる操作を、明文化して決める。この事例では遮断機を開ける操作までが対象です。返金や契約の変更のように取り消しにくい操作を含めるかどうかは、業務の性質で変わります
• 引き継ぎの条件を、AIの能力ではなく事実で決める。ここでは設備の故障と期限切れの予約が条件になっています。「AIが答えられないとき」ではなく「状態がこうだったとき」で書くほうが、運用でぶれません
• 混み合う時間を基準に考える。待ち時間が伸びるのは特定の時間帯だけです。平均の待ち時間が許容範囲でも、集中する時間に人を置けないことが問題なら、見るべき数字は平均ではありません
• 数える指標を先に決める。解決1件あたりの費用、解決率、待ち時間のどれを主に見るかで、施策の良し悪しの判定が変わります。解約との関係を見る場合は解約率を改善する方法で整理した指標の分け方も確認してください

AIに任せる範囲を自社で作る場合、管理者が設定できる形にするのか、開発を伴う形にするのかという分かれ目もあります。前者の例は7週間で1 million回｜Zendeskが顧客に作らせたエージェントで扱いました。

効果の大きさは、用件の偏り方、接続できるシステム、通話の量によって変わります。この事例の数値が自社で再現されるという意味ではありません。再現できるのは数値ではなく、渡す範囲の決め方です。

この記事で確認できなかったこと

• 各値の集計期間。事例ページに記載がありません
• 導入の時期と期間、費用。Fin Voice の料金も公表されていません
• 解決を判定している方法。電話での判定方法は、今回確認した公式ページには記載がありません
• 導入後の通話件数、待ち時間、満足度の現在値
• BPOへの支払額と、全体の対応費用がどう動いたか
• 接続している個別のシステム名と、連携している項目の詳細
• 日本語での対応品質。公式ページの表記は 30-language support までで、言語ごとの精度は書かれていません
• ParkBee 自身による発表。今回の数値はいずれも Fin AI 側の公式事例に出ているものです

出典はいずれも2026年10月31日に確認したもので、半年ごとに見直す設定にしています。製品の機能と料金は改定されます。引用した機能の範囲を自社の判断に使う前に、同じURLで最新の記載を確かめてください。