【レポート】NTTドコモの AI エージェントを支える基盤の作り方 #AWSSummit

まいど、大阪の市田です。

本記事は、現在開催中のAWS Summit 2018 Tokyoで行われた事例セッション「NTTドコモの AI エージェントを支える基盤の作り方」のレポートです。

セッション概要

NTTドコモでは 2017 年から今後のサービスの要として ” AI エージェント” を皆様にお届けすることをお約束してきました。本セッションでは AI エージェント計画のご紹介と、AI エージェントを実現するにあたって AWS のサービスをどのように活用しているのかについてご紹介したいと思います。

株式会社NTTドコモ イノベーション統括部課長：秋永 和計 氏

セッション内容

なぜ今はAI時代なのか

クラウドは市民革命

• 計算機がクレカ1枚で5分で準備できる時代
  • クラウドが出てきたら計算機が必要なときに5分でサーバができる時代
• これを市民革命と位置づけている

機械学習は産業革命と捉えている

• 馬車があったときは馬車ののビジネスがあり、車が出てきたらそのビジネスが登場した。
• 機械学習は昔からあり1960年代で使えないと言われてた
  • 膨大なマシンリソースが必要
• クラウドと機械学習の補完関係があったからこその今の状況がある。

これまでの遷移

• 2011年
• Apple Siriが出た
  • 社内では・・
  • R&D部門に話が出てきた。当時はiPhoneを唯一売ってなかった
  • 翌年Siriが日本語対応するという噂があった。危機感
  • NTTグループで音声補正は研究していたのでやろうという話になった
  • NTTドコモでは「VOICE IT!」という先行したサービスがあった
  • それをもとにiコンシェルをちゃんと喋るようにした。
• 計画から4ヶ月でローンチ
  • 当初はサーバ用意などで時間がかかると言われていた。
  • 東京リージョンは2011年。震災の直後で色んなサーバがダウンするようなことがあった。
  • 最初はカリフォルニアでローンチした。
• サービスインしてからリージョン移行したり様々な改善を行ってきた。

コスト削減、初期投資削減、時間削減

• 出来なかったことをできるようにした
  • 削ったコストで新しいことに挑戦
• サービスインと撤退を従来にない速さで
• 常識を変える運用方法など
• クラウド利用コスト
  • ユーザ数の増加に伴いコストは当社比で平均50%以下にできた
  • 運用して1年半くらいで。

不安要素

• オンプレミスDCにあるスパゲッティ状態のようなケーブル配線をなんとかしたい、クラウドにしたいと考えていた
• クラウド化は当初はまったく話にならなかった
  • クラウドは見えないから不安という意見
• 非常に高いセキュリティが必要な案件
  • 実現するために行った数々の施策
  • 内部犯行すら不可能なデータの漏洩防止作の実装
  • 徹底的に分離したアカウント権限の配置などを行っていった

2016年〜

• AIエージェント基盤をAWS上に構築
• 様々なエージェント
  • スマホエージェント、ロボット、店頭ご案内、冷蔵庫エージェント、カーエージェントなど
• AIエージェントの基盤
  • 多目的対話エンジンSpeak
  • 行動先読みエンジン
  • IoTアクセス制御エンジン
  • IoTデバイスをコントロール、情報を集めることができるもの
  • 多目的対話エンジン
  • 各種デバイス、アンドロイド、iOS、web ラズパイなど多様なデバイに対応するSDK
• 言語仕様をオープン化して誰でもコンテンツを作成可能に
• デバイスとサービスハンドラをストリーミングによるリアルタイム音声処理をしているちおころがが大きな特徴
  • AWSのサービスを活用している

汎用的な構造

• [デバイス] → [AIエージェント基盤] → [EC2/ECSもしくはLamba+APIGW] → [APIサービス・Web Services]

先読みエンジンの例

• お客様のことを深く理解。色んな情報を集める必要がある
  • 集めた情報にたいするトリガー。
  • 自宅に帰ってきたらアクションをする、という感じでサービスを実行できる基盤
  • スマホ上の位置や予定、メールなどから次の行動を先読みして、最適なタイミングで必要な情報を提供
  • 例：荷物が届いても、普段自宅にいないときは「配送時間の変更をしますか？」と確認が来て配送時間を変更するだけでよい。
  • 一回の変更だけでできる

アーキテクチャ

• [スマホ] → [kinesis(位置登録)] → [Aurura（一時保存）] → [EC2（ユーザ単位でシャードを分割してユーザ蔵に対応）] + [RDS(EC2/RDSの組み合わせた多数)]
  • EC2は分析指示のキューイング(SQS)
  • 処理結果をS3に保存
• とにかく早く構築した
• 実はスケールアウトを考慮していないソフトウェアを短時間でスケールアウトさせる方法を取っている
  • これは改善が必要な構成という認識

利用規模

• AWSアカウント数：400以上
• AWS利用目的：Web経から業務系まで様々
• EC２インスタンス数：12,000台以上
• RDSデータベース：2000台以上
• S3利用料 ：5PB以上
• データ転送量：1PB以上
• 利用料：ご想像におまかせします(非公開)

結果

• エンジニアがエンジニアリングできる会社になった
  • 新入社員でもアカウント持てる自由にシステム施策できる
• 勉強会を毎週開催
  • 最新サービスに関する情報が入手できる
• 社内で事例が豊富になって実績あるパートナーが多数存在
• 注意点も
  • 新入社員が遠慮なしに使う「クラウドゆとり世代」
  • 高いインスタンスを立ち上げっぱなし
  • とりあえず一番早いインスタンスにしておけば大丈夫

社内の体制

• ドコモCCoEチーム
  • Cloud Center of Excellence
• 情報セキュリティ部、ガイドライン、テンプレート作成
  • ガイドラインをガンガン作ってる
• 共通基盤開発運用
  • AWSのへの問い合わせを一元化

Cost Visualizer

• クラウドコストの把握

Scan Monster

• AWS上に構築したシステムの「自動アセスメントツール」
• ベストプラクティスやセキュリティ対策の準拠性を自動的かつ継続的に確認、間違った使い方を早期に検知・防止
• Truster Adviserに似ているが、会社独自のチェックをしている
• Serverlessのみで実装
  • Cognito User pool,API Gateway, Lambda,DynamoDB,CLoudwatch logs, AWS WAF ,CDN,など
  • コストが異常に低い
• 全400以上のアカウント合計しても$10行かないだろう
• Cost VisualizerやScan Monsterなどは販売しているので、利用希望があればお問い合わせください。

最後に

最後のメッセージは「クラウドは不可能を可能に変える道具」というものでした。 試行錯誤を通してクラウド最適化を行いつつ、新しいことへの挑戦という内容が具体的に紹介されていて参考にしたい点も多いセッションでした。