IBM Watson Blog

Watson, 電話番号を教えてもらえますか?

記事をシェアする:

Watson Assistant と電話システムの橋渡しするためのパターン

 

古いものでも新しいものでも、テレフォニー・テクノロジーに携わっていると、途方もない数の理解困難な言葉に遭遇します。この投稿では、既存のテレフォニー・インフラストラクチャーを Watson Assistant と接続するためのさまざまなオプションについて説明します。クラウド・ベースの仮想アシスタント・プラットフォームを接続することの複雑さをわかりやすく解説し、いくつかのヒントを提供します。

ここで説明するパターンは、パブリッククラウド・バージョンの Watson Assistant への接続に重点を置いています。「持ち込み SIP トランク (Bring Your Own SIP Trunk)」は、ほとんどのベンダーが扱える統合パターンの広義のカテゴリーですが、そもそも SIP トランクとは一体何でしょうか。

Session Initiation Protocol (SIP) とは、インターネットやその他のあらゆる IP ベースのネットワークを介して電話および通信サービスを提供するために使用される Voice over Internet Protocol (VoIP) テクノロジーです。昔ながらの電話線で構成される旧式のテレフォニー・ネットワークである、公衆交換電話網 (Public Switched Telephone Network、PSTN) と比較して説明するのが最もわかりやすいでしょう。

PSTN ではアナログ・スイッチや電話線、つまりハードウェアを使用して通話をルーティングする一方で、SIP では仮想「トランク」、つまりソフトウェアを使用して複数の通話を同時に発着信します。SIP とは、異なるシステムがインターネットを介して音声トラフィックの通信を行えるようにするための標準です。

以下は、エンド・ユーザーから Watson への通話フローの基本的な部分のみを示した図です。

Watson Assistant の電話統合アーキテクチャー

Watson Assistant の電話統合アーキテクチャー

 

 

  1. ユーザーが PSTN を介して通話を発信します。どの携帯電話もこのような仕組みになっているため、ここでは他のオプションはあまりありません。
  2. Communication Platform as a Service (CPaaS) が、PSTN と SIP トランクとの橋渡しをし、デジタル・プラットフォームに接続します。
  3. CPaaS プロバイダーが Watson Assistant への SIP トランクを開き、ユーザーが会話をします。
  4. 必要に応じて、会話をパーソナライズするために Watson Assistant はバックエンド・システムと統合されます。
  5. また、Watson Assistant から SIP の転送指示を CPaaS プロバイダーに送信し、ライブ・エージェントのサービス・デスクとの SIP トランクを新たに開き、ユーザーをエージェントに接続することもできます。

電話にアシスタントをデプロイするにあたって適切な意思決定を行うのに役立つ価値のある情報は豊富にあります。ここではこれらの情報を 3 つのコア・セクションに分けました。

  1. パブリック・インターネット上の SIP トランキングに関する誤解 — 企業をデジタル化から遠ざけてきた誤解を解いていきます。
  2. PSTN を使用した Watson Assistant との統合 — 不可能ではありませんが、高いコストがかかります。これは最も簡単に開始できる方法の 1 つではあるものの、長期的に拡張していくにつれ、コストに価値が見合わなくなる理由について説明します。
  3. よく使用される統合パターン — ほとんどのお客様企業ではすでにインフラストラクチャーが確立されているため、大がかりな変更を回避するようにします。IBM は、多数の大規模なお客様を支援してきた実績と、お客様の既存資産を活用してお客様を成功に導くためのベスト・プラクティスを有しています。

 

最初の 2 つのセクションを読むことで、アシスタントをどのようにデプロイするかについて考え始める準備が整います。その次のセクションには、各パターンのメリット/デメリットについての説明があります。お客様企業における意思決定のプロセスに役立ててください。

 

パブリック・インターネット上の SIP トランキングに関する誤解

では、パブリック・インターネット上の SIP トランキングに関する誤解を解いていきましょう。

VoIP はリアルタイムの性質を持ちますが、かつては、このことが原因で、パブリック・インターネットを使用する SIP トランクには一定の品質上の限界がありました。これはもはや事実ではありません。この Netflix や Webex のようなリアルタイム・ストリーミング・サービスの時代において、ジッターや待ち時間の問題に対応するために高額な専用のプライベート回線の必要性が正当化されるというケースに遭遇することはめったにありません。

VoIP および SIP の使用拡大を妨げていたもう 1 つの理由はセキュリティーです。実際には、SIP トランクの両エンドポイントがセキュアなトランキング (SIPS および SRTP) と SIP 認証をサポートしている限り、音声通話の保護について心配する必要はありません。

 

PSTN を使用した Watson Assistant との統合

 

「Watson Assistant は当社で使用しているベンダーのテレフォニー製品と統合できますか」と質問されることがよくあります。ベンダーは Genesys、NICE InContact といったものが挙げられます。こういった質問に対しては、いつも「そのベンダーの製品が SIP トランクを介して Watson Assistant に接続できさえすれば、統合できます」と回答しています。

Watson Assistant は、SIP トランクの終端エンドポイントであることを理解しておくことが重要です。SIP トランクは、パブリック・インターネットを介してアウトバウンド SIP トランクを確立することができるデバイスやクラウド・ベースのサービスであれば、どのようなものでも起点とすることが可能です。

パブリック・インターネットを介したダイレクト・ピアリングが不可能である場合は、PSTN を使用して Watson Assistant に到達する方法が多く用いられます。しかし、PSTN を介した方法ではデプロイメントのスピードとコストのトレードオフが必要になるため、万事解決というわけではありません。典型的な通話は、通話を完了させるために必要な複数のコールレッグ (中継接続) で成り立っています。例えば、発信者から PSTN を介して SIP トランキング・プロバイダーに到達するまでのレッグがあり、その他に対話式音声応答 (IVR) システムまでのレッグや、ライブ・エージェントまでのレッグがあるといった具合です。これらのレッグそれぞれで料金が発生するため、通話量が多ければコストはすぐに膨れ上がります。

というのも、一般的に、PSTN を使用する通話は、分ごとの料金が高額であるためです。しかも、アウトバウンドのコールレッグは、インバウンドのコールレッグよりも高額であり、方向ごとに個別に課金されます。したがって、1 つの通話が複数の PSTN レッグで構成される場合、コストが急激に増加する可能性があるのです。

さらに、並行性の問題もあります。PSTN は、概して 1 つの電話番号を使用した大量の通話処理に適していません。一般的に、個々の電話番号は限られた同時通話数しかサポートできません。多くの通話量を処理するためには、複数の番号をプロビジョニングし、通話の負荷を分散して、必要な並行性を達成する方が安全です。

もう 1 つの問題は、PSTN を介する通話では、メタデータ (コンテキスト) を交換する方法がないということです。そのような必要性をまったく想定していないプロトコルや標準を基に構築されているためです。このことから、Watson Assistant によって収集された情報をライブ・エージェントと共有しようとすると問題が発生する場合があります。

Watson Assistant への VoIP 通話に PSTN を使用する場合についての一般的な経験則は以下のとおりです。

  • PSTN をトラバースするコールレッグの数は必ず多くても 1 つに制限すること
  • 2 つ以上の PSTN コールレッグが必要になるとわかった場合には、可能な限り早く 1 つに減らすための計画を立てておくこと

 

よく使用される統合パターン

このセクションでは、Watson Assistant に接続するためにお客様に最もよく使用されている、持ち込み SIP トランクのネットワーク・パターンについて取り上げます。各パターンを分析し、さまざまなメリットやデメリットを説明します。ここで説明するすべてのパターンでは、発信者が PSTN を使用する番号で電話をかけること、また、すべてのパターンでライブ・エージェントがいるコンタクト・センターに通話を転送できることを前提としています。

一般的に、通話フロー完了までに 1 つの PSTN レッグのみを使用するパターンは、優れたパターンであると言えます。以下に示すパターンで回避すべきものは、最後の 2 つのみです。Watson Assistant との統合をサポートするために PSTN を過多に使用しているためです。

 

1. パブリック・インターネットを介した通話転送

Twilio や IntelePeer といった Communication Platforms as a Service (CPaaS) が、PSTN ネットワークと Watson Assistant の橋渡しをします。これにより、PSTN でプロビジョニングされた電話番号に電話をかけることで Watson Assistant に到達できます。お客様は新規の番号 (フリーダイヤル番号またはローカル Direct Inward Dial – DID) をプロビジョニングするか、または既存の番号を CPaaS に移植することができます。CPaaS プロバイダーは、Watson Assistant から送信される標準 SIP シグナリングまたは Watson Assistant Web フックから呼び出される API を介して、クラウド・ベースまたはオンプレミスのコンタクト・センターに通話を転送する機能もサポートしています。

パブリック・インターネットを介した通話転送

1. パブリック・インターネットを介した通話転送

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号またはローカル DID に着信します。
  2. 通話が PSTN を介して CPaaS にルーティングされます。
  3. CPaaS がパブリック・インターネット上の SIP トランクを介して通話を Watson にルーティングします。
  4. Watson が SIP REFER を CPaaS に送信して、通話を転送します。
  5. CPaaS がパブリック・インターネット上の SIP トランクを介してお客様の電話番号 (転送ターゲット) に通話を転送します (CPaaS から Watson Assistant へのコールレッグはこの時点でドロップされます)。
  6. お客様のセッション・ボーダー・コントローラー (SBC) が通話をお客様のコンタクト・センターに転送します。
  7. 通話がキューに入った後、ライブ・エージェントが通話に応答します。

このパターンでは、CPaaS が通話をアンカーするため、通話終了まで通話パスに留まります。

メリット: このパターンは、PSTN のコールレッグが 1 つだけであるため、とてもコスト効果が高く、また、SIP シグナリングでメタデータを交換できるという点で柔軟性も非常に優れています。

デメリット: 残念なことに、このセットアップの主な問題点は、オンプレミス・コンタクト・センターの SBC のほとんどがパブリック・インターネットに接続されていないことです。さらに、番号を CPaaS に移植する必要がありますが、これが完了するまでに時間がかかる場合があります。

 

2. サード・パーティー Contact Center as a Service (CCaaS)

Watson Assistant との統合に使用される持ち込み SIP トランクのパターンのカテゴリーとして、サード・パーティー CCaaS プロバイダー (例: NICE InContact、Genesys Pure Cloud、Twilio Flex、Five9 など) が Watson Assistant へのアウトバウンド SIP トランクを開始するというものがあります。このパターンでは、CCaaS プロバイダーがお客様のインバウンド通話を PSTN から着信し、パブリック・インターネット上の SIP トランクを介してその通話を Watson に転送します。ライブ・エージェントが処理できるよう、Watson Assistant から CCaaS に通話が再度転送される場合もあります。転送が完了すると、Watson へのコールレッグはドロップされます。以下はこのパターンを図で表したものです。

2. サード・パーティー Contact Center as a Service (CCaaS)

2. サード・パーティー Contact Center as a Service (CCaaS)

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号に着信します。
  2. 通話が PSTN を介して CCaaS にルーティングされます (通常、CCaaS には PSTN 接続を扱うために連携している CSP がいます)。
  3. 通話がパブリック・インターネット上の SIP トランクを介して Watson Assistant に転送されます。
  4. Watson Assistant は転送を開始するために、SIP REFER を CCaaS に送信するか、または CCaaS API を使用して、通話を転送します。
  5. CCaaS がお客様の通話キューに通話をリダイレクトします。通話が最終的にライブ・エージェントによって処理されます。

 

メリット: 多くの Watson Assistant のお客様が利用しているこのフローは、とてもコスト効果が高いのみならず、SIP シグナリングで通話のコンテキスト (例: セッション履歴へのポインター) などのメタデータを交換することも可能です。

デメリット: CCaaS がすべてのテレフォニー・ルーティングを制御するため、柔軟性が低下することがあります。

 

 3. パブリック・インターネット上の SIP トランクを介したオンプレミス・コンタクト・センターのピアリング

 

CCaaS 統合のバリエーションとして、オンプレミス・コンタクト・センターを、パブリック・インターネット上の SIP トランクを介して直接 Watson Assistant に統合することも可能です。これもとてもコスト効果の高いパターンであり、コンテキストの交換もできます。しかし残念なことに、主にほとんどのオンプレミス・コンタクト・センターは、パブリック・インターネットを介して Watson Assistant のようなクラウド・ベースのソリューションに接続するようセットアップされていないという理由から、かなりまれなケースです。

3. パブリック・インターネット上の SIP トランクを介したオンプレミス・コンタクト・センターのピアリング

3. パブリック・インターネット上の SIP トランクを介したオンプレミス・コンタクト・センターのピアリング

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号または DID に着信します。
  2. 通話が PSTN を介して CSP にルーティングされ、CSP が通話をお客様の SBC に転送します。通常、これは何らかの専用のプライベート回線 (MPLS、TDM、ISDN など) を介して行われます。
  3. 通話がパブリック・インターネット上の SIP トランクを介して Watson Assistant に転送されます。この場合、お客様の SBC がパブリック・インターネットと接続されているため、SIP トランクを介してクラウド・ベースの SIP エンドポイントにトラフィックを転送できます。
  4. Watson Assistant は転送を開始するために SIP REFER をお客様の SBC に送信し、通話を転送します。お客様の SBC がオンプレミス・コンタクト・センターに通話を転送します。
  5. 通話が最終的にライブ・エージェントによって処理されます。

メリット: とてもコスト効果が高く、SIP シグナリングによりメタデータを交換できます。

デメリット: お客様のオンプレミスの SBC は、多くの場合お客様の通話サービス・プロバイダー (例: AT&T、Verizon など) によって管理されています。そのため、パブリック・インターネット上の SIP トランクを使用可能にすることが困難な場合があります。その場合には、この次に説明するパターンが検討されることがよくあります。

 

4. 専用のプライベート回線を介したオンプレミス・コンタクト・センターのピアリング

専用のプライベート回線とは、広義的には、SIP トランクを使用してオンプレミス・コンタクト・センターを Watson Assistant と統合するために、MPLS、専用ファイバー、Meet Me の場所、およびクロス・コネクトを利用するパターンのことです。これは長期的に最適な戦略であることが多いものの、セットアップに長い時間を要する場合があり、またコストも高額です。通常は、多数の同時通話をサポートしなければならないお客様が使用するパターンです。プロジェクト期間が限られていることを理由に、多くのお客様では最適とは言えない後述のパターンのいずれかを選ぶことがあります。素早く本番稼働を開始するために複数の PSTN コールレッグが含まれるパターンを使用したとしても、長期的なソリューションとして専用回線を使用するこのパターンを検討することが重要です。

このパターンにはいくつかの異なるフレーバーがありますが、一般的に通話サービス・プロバイダー (CSP) が、自社のパブリッククラウド・データセンターのいずれかに Watson Assistant に到達するための専用回線を設定します。以下は、一般的なセットアップを説明する図です。

4. 専用のプライベート回線を介したオンプレミス・コンタクト・センターのピアリング

4. 専用のプライベート回線を介したオンプレミス・コンタクト・センターのピアリング

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号またはローカル DID に着信します。
  2. 通話が PSTN を介して CSP にルーティングされます。
  3. CSP が専用のプライベート回線を介して Watson Assistant に通話を転送します。多くの場合、CSP は、Watson Assistant に転送する前に、シンプルな IVR を用いて、Watson で処理すべきインテントであるか、通話の適格性を事前に評価します。
  4. Watson Assistant は、お客様のコンタクト・センターへの転送を開始するために SIP REFER を CPaaS に送信し、通話を転送します。
  5. CSP がオンプレミス・コンタクト・センターに通話を転送します。
  6. 通話が最終的にライブ・エージェントによって処理されます。

 

メリット: このパターンの 2 つの最大のメリットは、サービス品質が保証されることと、セキュリティーが極めて高いことです。このパターンでは、通話シグナリングでメタデータを交換することも可能です。

デメリット: このパターンは、前述の、Over the Top のパブリック・インターネット上の SIP トランキングを利用するパターンよりもコストが高額になる場合があり、間違いなくセットアップにより長い時間がかかります。また、Watson Assistant から返される SIP REFER などを処理したり、通話シグナリングでセッション履歴へのポインターなどのメタデータを交換したりするために、CSP のサービス・フィーチャーを購入する必要があります。CSP で通話転送を行うためのフィーチャーなどが必要となる場合もあります。このような CSP のフィーチャーで提供される機能には十分な価値があり、複数のコールレッグが PSTN をトラバースするよりもはるかに低コストです。

このパターンのバリエーションとして、CSP のサービスを利用するのではなく、お客様の SBC を直接プライベート回線に接続して通話をアンカーし、Watson Assistant から返される SIP REFER を処理するという方法があります。自社で SBC を管理していて、SBC の構成を細かく制御できるお客様の場合は、この方が CSP に通話をアンカーしてもらうよりもコスト効果の高いアプローチとなるでしょう。

 

5. ハイブリッド・パターン: Voice Gateway を使用して Watson Assistant の通話をオンプレミスで終端させる

SIP トランクを介してパブリッククラウドで Watson Assistant と統合するにあたって、他に合理的なオプションがどうしてもない場合に使用されるパターンです。このパターンでは、Watson Assistant Voice Gateway を、オンプレミスで、お客様のコンタクト・センターがあるデータセンター内に直接インストールすることができます。Watson Voice Gateway とは、アウトバウンド HTTP と Web ソケットの接続のみを使用して、片側で SIP トランクを終端させ、もう片方のパブリッククラウドで Watson Speech to Text、Watson Text to Speech、および Watson Assistant をオーケストレーションする VoIP デバイスです。このような接続は、通常、エンタープライズ・ネットワークからパブリッククラウド・サービスへ接続するほうがはるかに容易で、一般的に必要となるのは、アプリケーション (転送) プロキシーまたはファイアウォール構成の変更のみです。

5. ハイブリッド・パターン: Voice Gateway を使用して Watson Assistant の通話をオンプレミスで終端させる

5. ハイブリッド・パターン: Voice Gateway を使用して Watson Assistant の通話をオンプレミスで終端させる

 

メリット: 多く場合、お客様のテレフォニー・ネットワーク内で Watson Assistant への SIP トランクを終端させるという方法が唯一実現可能な統合オプションです。このパターンでは、オンプレミスのサービス・オーケストレーション・エンジンからバックエンド・システムに容易かつセキュアにアクセスすることも可能です。

デメリット: このアプローチの明らかなデメリットは、お客様は自社ネットワーク内に新たなデバイスをインストールして管理する必要があるということです。とはいうものの、Voice Gateway は非常に軽量で、多大な時間やコストを必要とすることなく、クラウドへのハイブリッド型の移行パスを提供します。これは、現在多くの Watson Assistant のお客様が本番で活用している、非常によく使用されるパターンです。

Watson Voice Gateway についての詳細は、こちらをご覧ください。

 

6. PSTN を介する Watson からの通話転送 (悪いパターン)

最初のパターンのように、CPaaS が新規の番号を提供するか、または番号を CPaaS に移植します。しかし、ここでは PSTN を介してのみしかオンプレミス・コンタクト・センターへ接続することができません。

6. PSTN を介する Watson からの通話転送

6. PSTN を介する Watson からの通話転送

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号またはローカル DID に着信します。
  2. 通話が PSTN を介して CPaaS にルーティングされます。
  3. CPaaS がパブリック・インターネット上の SIP トランクを介して通話を Watson にルーティングします。
  4. Watson が SIP REFER を CPaaS に送信して、通話を転送します。
  5. CPaaS が PSTN を介してお客様のフリーダイヤルまたはローカル電話番号に通話を転送します (CPaaS から Watson Assistant へのコールレッグはこの時点でドロップされます)。
  6. お客様の電話会社が通話をお客様のコンタクト・センターに転送します。
  7. 通話がキューに入った後、ライブ・エージェントが通話に応答します。

メリット: このパターンは比較的短期間で立ち上げることができます。

デメリット: このパターンにはさまざまな問題があります。1 つ目に、PSTN のコールレッグが 2 つあります。つまり、インバウンドとアウトバウンドの CPaaS レッグ、およびお客様の通話サービス・プロバイダーでのインバウンドのレッグに対し、3 つの異なる PSTN 料金が発生します。この通話のコストは、図 1 で説明した同じ通話に比べて大幅に増加します。2 つ目に、SIP シグナリングを通じて Watson Assistant によって収集されたメタデータをライブ・エージェントに渡すほうが望ましいですが、CPaaS からお客様のコンタクト・センターへのコールレッグが PSTN をトラバースする場合、これは不可能です。

 

7. PSTN を介する Watson への通話転送 (さらに悪いパターン)

このパターンは、通話サービス・プロバイダーを変更したり、既存のフリーダイヤルまたは DID 電話番号を CPaaS に移植したりする意思がないお客様向けのアプローチです。時間的な制約もかかわってくるため、この投稿で説明する全パターンのなかで、最も望ましくないパターンとなります。

7. PSTN を介する Watson への通話転送

7. PSTN を介する Watson への通話転送

この通話フローに関連する手順は以下のとおりです。

  1. 通話がフリーダイヤル番号またはローカル DID に着信します。
  2. 通話が PSTN を介してお客様の通話サービス・プロバイダー (CSP) にルーティングされます。
  3. 次に、お客様の CSP によって、通話が PSTN を介して CPaaS がプロビジョングした電話番号に転送されます。
  4. CPaaS が通話を Watson に転送します。
  5. Watson が SIP REFER を CPaaS に送信して、通話を転送します。
  6. CPaaS が、異なる DID を使用して、お客様の通話サービス・プロバイダーへの新しいコールレッグを開始します。これは、通話の「へアピニング」と呼ばれます。
  7. CSP が通話をお客様のコンタクト・センターに転送します。通話がキューに入った後、ライブ・エージェントが通話に応答します。

メリット: 立ち上げが最も速いソリューションです。

デメリット: 通話の完了までに 5 つの PSTN コールレッグが必要になります。これは紛れもなく最悪のシナリオです。まず、この通話には極めて高額なコストがかかります。そして、Watson とコンタクト・センターとの間のシグナリングで、通話に関するメタデータを交換することは一切不可能です。このような通話は、問題が発生したときにデバッグするのが困難となる場合もあります。言うまでもなく、このパターンは可能な限り回避すべきです。

ただし、このパターンを使用する場合には、通話のへアピニングを回避する方法があります。一部の CSP は、DTMF トーンを使用して通話転送を開始できるようにするサービスをサポートしています。この DTMF トーンは、Watson Assistant に接続する最初の PSTN コールレッグを介して Watson Assistant から CSP へ送信されます。これらの DTMF トーンにより CSP が Watson へのコールレッグをドロップし、お客様のコンタクト・センターへの新しいコールレッグを開始します。AT&T では、このサービスを Transfer Connect と呼んでいます。残念ながら、これは少々高額なサービスであり、追加の PSTN コールレッグのコストよりは安価であるものの、投稿で説明した他のパターンを採用することで、このようなサービスを使用しなくてすみます。

 

まとめ

ここまで読めば、VoIP ネットワーク接続は、膨大な数のネットワーク構成が可能な、複雑なトピックであることがおわかりになったのではないでしょうか。この投稿では、最もよく使用されるパターンをいくつか紹介しました。これらはどれも現在 Watson Assistant と統合するために実際に使用されているものですが、ありとあらゆるパターンを完全に網羅しているわけでは決してありません。また、これらすべてのパターンの細かい部分を正しく整備するには、分野の専門家との詳細なネットワーク・プランニングが多くの場合に必要となります。

実装の判断を行うために、お客様企業で使用可能な各パターンの長所と短所を理解することが非常に重要です。最初に選択したパターンを通過点として、よりコスト効果が高く、より多くの機能がもたらされる他のパターンに移行することも多くあります。前もって理想的なネットワーク・パターンにたどり着く方法を計画しておくことで、長期的に時間とコストを節約することができるため、計画作業をしっかりと行うことをお勧めします。IBM は、お客様が可能な限り最善のパターンを見つけられるよう、オプションを探索するお手伝いをします。ぜひ Watson Assistant に登録し、新しい電話統合の実際の動作を見てみてください。詳細については、IBM 担当員にご連絡いただくか、IBM Watson Apps Community (英語)にご参加いただき、最新情報を入手してください。

 

原文:Hey Watson, Can I Have Your Number? (https://medium.com/ibm-watson/hey-watson-can-i-have-your-number-7de8fc7621ed)

 

More IBM Watson Blog stories

第2回『KubeCon Europe 2021 サクッとふりかえる』

IBM Cloud Blog, IBM Partner Ecosystem

こんにちは。IBMテクノロジー事業本部IBM Automation テクニカル・セールス 岩品です。 ちょっと遅くなってしまいましたが、GW後半に行われた KubeCon EU 2021 に参加しましたので、このブログで ...続きを読む


IBM Cloud がTop Rated Awardsを受賞

IBM Cloud Blog, IBM Cloud News, IBM Cloud 市場の声・市場評価

IBMは、TrustRadiusから2年連続でTop Rated Awardsを受賞したことを発表しました。TrustRadiusでは、カテゴリーの上位に位置する製品にのみトップレートバッジを付与しています。このバッジを獲得するためには、製品に新しいレビューがあること、高いスコア(trScore)を維持していること、指定されたカテゴリーで大きなトラフィックを獲得していることが必要で、これらはすべて顧客満足度と消費者の関心を示す指標です。この栄誉を与えられた製品をご紹介します。 ...続きを読む


「公平かつ信頼できる AI 」で AI 活用を次のフェーズへ

IBM Data and AI, データサイエンス

NTT データ 信頼できるAIの実現に向け、IBMと技術検証を実施 現在 AI や IoT、ビッグデータを活用することにより起こる「第四次産業革命」が注目されています。その中でも特に AI 技術の発達は凄まじく、深層学習 ...続きを読む