世界初の感情認識パーソナルロボットPepper。今月から開発者向けの販売が検討され、6月以降には一般販売も開始される予定だ。このロボットは、従来のロボットと何が違い、私たちの生活をどのように変えるのか？ Pepperの開発を率いた林要氏へのインタビューを、3回にわけてお届けする。初回は、Pepper開発の裏側を聞いた。
――林さんがプロジェクトに携わり始めたのは2012年春と聞きました。Pepper販売が公表された2014年6月までのおよそ2年間、どのように開発を進めてきたのか教えていただけますか？
Pepperの基本的なメカ設計は、フランスのアルデバラン社が行っています。NAOという小型ロボットの技術を土台に作っており、開発時間の短縮に繋がったと思います。
ですが、そこから店頭で使える製品にしていくハードルは極めて高かったです。Pepperの開発は、もしかすると従来のロボット開発と変わらないような印象を受けるかもしれません。しかし、実際に店頭にロボットだけを置き、転倒防止なども考慮した上で人間とコミュニケーションをとり自律的に行動できるように設計するには、ハード・ソフトともに、かなりの改善が必要でした。
――どういった点が難しかったのでしょうか？
ロボット開発の難しさは、ハードを扱うメカ屋さんとソフトウェア屋さん、その両者を一気通貫して見ることのできる人材が少ない点です。さらに、試行錯誤して設計通りにロボットが動いたとしても、人間側が想定通りに動かないことも往々にしてあります。今の段階ではどんな状況にも対応できるロボットの実現は技術的に難しいので、ある程度私たちの方でロボットとのコミュニケーションについて、人が理解しやすいルールを詰めていく必要がありました。
そこで難しいのは、人型ロボットとして価値を最大化できるユースケースと、サービスを考える側の人が今までの経験からロボットにやって欲しいと考えるものは別だということです。
例えばPepperに、ソフトバンクの店頭で受付業務のサポートをやらせることは難しくありません。「今日は新規購入ですか？ 機種変更ですか？ それでしたらこちらの書類が必要です」といった対応自体は実装することはできます。ただ、その機能に本当に価値があるのかどうかを考える必要があります。来店したお客様からしたら、ロボットよりも人にやってもらいたいことことはたくさんあると思うのです。
――Pepperの機能をコミュニケーションに特化させたことには、どのような背景があったのでしょうか？
ロボットに「感情認識をさせる」ということは、孫の発案でかなり初期の段階から決まっていました。
今までのロボットは、「人が必要とする、役に立つ機械」のイメージが強かったと思います。洗濯機であれば、洗濯板を自動化し、脱水機、今では乾燥機の機能まで付いています。この場合、機械は人の作業量を減らし、時間を稼ぐことには貢献していると思います。結果的に、それによって生まれた余暇で人々は幸せになったかもしれません。しかし、ロボット自体が直接人々を幸せにしているわけではないんですね。
昨今、重要性があがっているもののひとつに、ペットのような存在があると思います。ペットを飼えば、当然お金もかかり、面倒を見る時間も増えます。生活は何も効率化されていないわけです。それでも、「ペットに癒やされる」という感覚を持つのは、ペットが自分を必要としてくれるからかもしれません。
今までのロボットは、「人が必要とする」ものをイメージされる事が多かったかと思いますが、実は「人を必要とする」ロボットの方が潜在的には求められているかもしれないわけです。
そう考えると、人を幸せにするためのロボットとして必要な機能は、相手のことが分かって、感情を認識し、相手とコミュニケーションができることなのだと思います。
――とは言え、「役に立つ」機能ではなく、コミュニケーション機能に特化させる決定を下すまでには、社内でも議論があったのではないでしょうか？
おっしゃる通り、「せっかくお店に置くなら、少しは業務的なこともやらせよう」という意見はありました。こうした意見に対しては、「実際にやってみる」ことにしました。
――トライアンドエラーということでしょうか。
ロボット開発のもうひとつの難しさは、企画書が役に立たたない点です。企画書というのは、書く側も読む側もその紙を媒介に同じことがイメージできて初めて意味があるわけです。企画書を読んで想起されるイメージが人によって違ったら、企画書として成立しません。
ロボットの場合、ほとんどの場合誰も開発経験がないので、書いた人のイメージと受け取って読む人のイメージが一致しないんですね。例えば、Pepperに搭載するエンターテインメントの企画書を書いても、なかなか通らない。「こんなの面白くないだろ」って（笑）。
そうなると、もはや「実際に作ってやってみせる」しか、お互いが納得する方法はないのです。したがって開発のパターンも、全部の企画を詰めてから開発に取り掛かるウォーターフォール型ではなく、少し作っては試すアジャイル型にならざるをえない。最初の企画が間違っている可能性があるからです。
――非常に、時間と労力のかかる開発だったわけですね。
この問題は、プラットフォーム側の作りにも関係していきます。Pepperのミドルウェア部分には「NAOqi（ナオキ） OS」を採用していますが、その安定度をどれくらいに置くかという議論です。
例えば自動車の電子デバイスは、事故が起きたら困るので非常にロバスト性（システムの頑強さ）が強く、結果的に進歩が遅い。例えばメーカー純正カーナビの進歩がスマートフォンより遅いのは皆様も感じられているかと思います。
ただそれは、決して自動車会社の怠慢ではなく、そもそも要求される信頼性が全然違うわけです。スマートフォンのカーナビアプリを使用して、多少動かなくなったとしても文句をいう人は少ないですよね。でも車の場合は、必ず動くように設計しなければいけなくて、その基準に合わせてカーナビも設計するので、結果として開発に時間がかかってしまう。そういう意味では車開発の対極にあるのが、最近のコンシューマー向けIT企業のソフトウェア開発だと思います。
Pepperの安定度をどこに置くかを考える時も、ウォーターフォール型で時間をかけて検討して進めるのか、アジャイル型でトライアンドエラーを許容するのかで進め方が大きくかわります。
例えば、転倒防止機能です。当然、Pepperはロボットなので、コンピュータがクラッシュするすると転倒する可能性があります。これを防ぐひとつの方法は、車のようにソフトウェア側をロバストに作ることです。しかし、これではアップデートして機能を追加することが極めて難しくなくなってしまう。
試行錯誤の末、最終的にはハードウェア側に転倒防止用のブレーキを入れることにしました。量産直前のことです。開発の方向によって、柔軟にハードウェアの構成まで変えてしまうのは、アジャイル開発の進め方の良い例だと思います。
略歴
林要（はやし・かなめ）さん
ソフトバンクロボティクス株式会社プロダクト本部PMO室室長。大手自動車メーカーのエンジニアを経て、2012年4月ソフトバンクに入社。入社以降、Pepperの開発を専任で担っている。
