将棋電王戦で活躍した“ロボット棋士”、 その超短期開発を可能にしたLabVIEWの威力

＜お話を伺った方＞
株式会社デンソーウェーブ　営業部　中部支店　係長　鈴木達也氏
株式会社マックシステムズ　営業部　SE課　課長　岡田泰尚氏
株式会社松浦電弘社　取締役設計部長　北野和男氏

最終戦前夜、セットアップ作業を終えて入念なリハーサルを行っている模様

将棋電王戦は、公益社団法人日本将棋連盟と、ニコニコ動画の開発・配信などで知られる株式会社ドワンゴの主催によって実施されているイベントである。プロ棋士とコンピュータ将棋ソフトとの戦いは高い関心を集めており、2012 年に開催された第1 回以降、年に1 回のペースで実施されている。ただ、指し手は確かに将棋ソフトが決定しているのだが、2013 年の第2 回までは駒の操作は人が代わりに行っていた。つまり、コンピュータを人が手助けしているという点で、「人類とコンピュータの戦い」が完全に実現されているわけではなかった。その基本コンセプトに沿おうとすれば、「駒の操作もコンピュータ制御にできないものか？」と考えるのは自然なことだ。そこで、2014 年の第3 回では、コンピュータ側の駒の操作をロボットによって行うというアイデアの具現化が模索された。その結果、ロボットを供給するメーカーとして選択されたのがデンソーウェーブである。しかし、デンソーウェーブにとって、打診を受けた時点では、この案件は戸惑いを禁じ得ない類のものだったようだ。そのときのことを、デンソーウェーブ 営業部 中部支店 係長の鈴木達也氏は次のように振り返っている。

「当初、開発すべきシステムについては仕様と呼べるようなものがまったく存在しなかった。通常、当社はシステムの自動化を実現するためのものとして、産業分野の顧客に対してロボットを供給している。それに対し、この案件の顧客であるドワンゴは、ネット向けコンテンツの配信を行っているエンターテインメント企業だ。『ロボットで駒の操作を実現したい』という思いは存在するわけだが、当然のことながら、その思いとエンジニアリング領域で必要になる仕様との間には大きな隔たりがある。そのため、どのようなかたちでその思いを具現化するのか、現実に即したイメージをしっかりと共有することから始める必要があった」。

認識の共有を進め、現実的な解を探っていった結果、図1 のようなかたちでシステムを構築することになった。その構成要素は、将棋ソフトが稼働するPC、サーバ、指し手の情報を受け取るPC、プロ棋戦専用ロボットアーム（以下、ロボットシステム）である。これら以外の要素としては、将棋盤、駒、棋士側の駒をとったときにその駒を置いておく置台、「成り」に対応して駒を裏返す操作に使用する反転台が存在する。

このなかで中核的な存在となるロボットシステムでは、次のような駒の操作を実現する必要があった。

• 駒を置く操作：将棋ソフトが指定したコンピュータ側の駒をピックアップし、将棋ソフトが指定したマスに配置する
• 棋士側の駒をとる操作：コンピュータ側の駒を置く前に、棋士側の駒をピックアップして置台に移動する
• 置台にある駒を置く操作：置台の上にある駒をピックアップし、将棋ソフトが指定したマスに打つ
• 「成り」の操作：将棋ソフトが決定した手が「成り」である場合には、将棋盤上の駒をピックアップし、それを反転台にいったん移動して裏返したうえで将棋ソフトが指定したマスに配置する

上記の機能を実現するうえで、駒の移動については産業用途向けのロボット（ロボットアームとロボットコントローラから成る）を使用することにした。また駒のピックアップ/ 配置には、バキューム装置（真空用コンプレッサ）を使用する。加えて、駒の種類を識別するためには画像認識技術を適用することにした。つまり、カメラを使用したビジョンシステムを構築するということである。画像認識を行ううえでは、対象物を光で照らすことが重要なので、照明装置も必要になる。さらに、棋士の安全を確保するため（詳細は後述）に、エリアセンサも使用することにした。ロボットのプログラミングはデンソーウェーブが行うが、このシステムには、PC からの制御やビジョンの制御といった要素も含まれている。そこで、PC による制御に長けており、デンソーウェーブのロボットの制御にもすぐに対応できる企業として、マックシステムズが参画した。さらに、主に画像処理を担当する協業企業として松浦電弘社も加わった。結果として、このプロジェクトは約10 名のメンバーで進められることになったという。

図1. システム全体の構成

求められる超短期開発、次々と発覚する想定外の課題

このようにして日を追うごとにアウトラインは明確になってきてはいたのだが、このプロジェクトには当初から1 つの大きな課題が存在していた。それは、仕様がまったく見えないところから始まるようなプロジェクトであったのにもかかわらず、非常に短い開発期間しか許されていなかったことである。

将棋電王戦は、5 人の現役プロ棋士と5 種のコンピュータ将棋ソフトの団体戦という形態で行われる。その第1 局が行われるのは2014 年3月15 日と決まっていた。ところが、デンソーウェーブがこの案件を受託すると決まったのは2013 年12 月末のことだった。マックシステムズや松浦電弘社との協業が決まったのはその後の話であり、仕様が定まってきたときには、すでに2014 年1 月末となっていた。実際の開発作業には、その後の1 ヶ月半しか残されていなかったのだ。

このような超短期開発に対応しなければならないことだけでも大きな問題である。しかし、実際のプロジェクトでは、産業用途向けの通常の案件ではありえないさまざまな条件が次々と発覚していくことになる。以下に、代表的な例を列挙する。

• 手作りの駒しか使用できない：コンピュータ側の駒の操作として、例えば「2 八のマスにある『銀』を移動する」場合には、「2八」のマスにある駒が確かに「銀」であるということを画像認識で確認する。ところが、駒はすべて手作業で作られているため、同じ「銀」でも、1 個1 個の寸法や各面の角度が異なっている。しかも、「銀」の文字も手書きなので、1 個1 個に微妙な違いがある。こうした条件に対応するために、パターンマッチング用に通常よりも複雑なアルゴリズムを考案しなければならなかった
  
• 棋士の駒は一定の位置に配置されない：棋士は各マスの中に駒を置く。しかし、具体的にマスの中のどこの位置に置かれるかは一定ではない。マスに対して駒がどのような角度で配置されるかも、その都度異なる。そのため、棋士が打った駒をとる際には、その位置や角度を画像で認識し、駒の中心を狙ってとりにいくという補正処理を行う必要がある
  
• 手作りの将棋盤しか使用できない：通常の産業用アプリケーションであれば、ロボットアームによる移動の対象物が置かれる平坦な台には厳密な寸法図面が存在し、それを基にして移動位置が厳密に決定される。しかし、将棋盤は手作りなので寸法図面は存在しない。しかも、表面は必ずしも平坦ではないし、まったく同じ寸法のものは1 つも存在しない。常に1 つの将棋盤を使い続けることが主催者側から認められたので問題は緩和されたが、このような条件は産業用途ではあり得ないものであった（なお、画像処理についても、同じ駒を使い続けることが認められたので、認識/ 補正が成り立っている）
  
• 設置場所が毎回異なる：ロボットシステム、将棋盤、置台、反転台の位置関係は、常に一定でなければ正確な操作を行うことができない。通常の産業用システムであれば、一度設置した場所から移動することはないため、この条件を満たすのは容易である。ところが、電王戦は第1 局から第5 局までがそれぞれ異なる会場で行われる。そのため、各会場のエレベータや通路などに収まる大きさに分割できるようシステムを設計し、現地で正確な位置関係が再現できるように組みなおさなければならなかった。しかも、畳、絨毯、表面が平坦ではないコンクリートなどの上に設置しても、まったく同じ動作が安定して行われるようにする必要があった
  
• 背景や照明の条件が画像認識に適していない：画像認識の成否は、照明と背景の条件に強く依存する。通常、対象物が白色系である場合には、背景には濃い色を使用するといったことが行われる。ところが、今回の背景は、駒と同じく木でできた将棋盤以外にありえなかった。しかも、実施会場が毎回異なることから、照明だけでなく、外乱光などの光の条件も一定ではない。こうしたことも、産業用途ではありえない条件だった
  
• 棋士の安全を確保しなければならない：本来、人とロボットが共存する状態は安全性の観点から許されるものではない。やむを得ず共存させる場合には、人はヘルメットを被り、いつでも非常停止ボタンを押せるようにしておく必要がある。しかし、対局の場をそのような環境にすることはできないので、このアプリケーションでは、エリアセンサで棋士を監視し、許容できないところまでロボットアームに近づいたらシステムが非常停止するようにした

このように、電王戦向けロボットシステムの開発は、非常に“トリッキー”な案件だった。産業用アプリケーションの開発に携わっている技術者にとっては想定外の課題が遍在しており、それらが次々と表面化するという状態だった。そのような状況のなか、1 ヶ月半のうちに開発を完了しなければならなかったのである。

LabVIEWが果たした役割

上述したさまざまな課題を解決するうえで鍵になったのが、グラフィカルシステム開発プラットフォームであるLabVIEW だ。電王戦向けのロボットシステムは、具体的には図2 のようなかたちで構築した。構成要素は先述したとおりだが、あらゆる制御の中核として、LabVIEW が稼働するWindows ベースのPC を使用している点がポイントである。

ロボットアームの動きの制御は、そのためのプログラムを搭載したロボットコントローラによって行う。このシステムでは、デンソーウェーブ製の垂直多関節ロボットアーム「VS-060」とロボットコントローラ「RC8」を採用した。このRC8 は、アプリケーションソフトウェア向けのプラットフォームとしてORiN（Open Robot/Resource Interface for the Network）を搭載している。そして、NI は、デンソーウェーブ製品で稼働するロボットプログラムとLabVIEWの連携を可能にするものとして、ORiN に対応するLabVIEW Robotics Library for DENSO を提供している。「これを利用することにより、LabVIEWとロボットコントローラの接続が非常にスムーズになり、シンプルな制御を実現することができた。このことから、開発時間を大幅に短縮することが可能になった」（鈴木氏）という。

図2. ロボットシステムの構成

また、図2 を見ると、ロボットコントローラはロボットアームのほかに、バキューム装置、エリアセンサにも接続されている。しかし、ロボットコントローラは、これらの制御の主体として機能するわけではない。「実際の制御を担っているのはLabVIEW ベースのプログラムで、ロボットコントローラはそのプログラムから送られてきた指示に従って動作しているだけだ」（鈴木氏）という。また、図に示したとおり、カメラと照明装置の制御もPC 上のLabVIEWベースのプログラムによって行う。つまり、ロボットアームの動き以外の制御は、LabVIEWベースのプログラムに集約されているということである。

さらに、画像認識に関連するあらゆる処理もLabVIEWによって実現している。この部分を担当した松浦電弘社 取締役設計部長の北野和男氏は、LabVIEW によるグラフィカルプログラミング手法の効果について、次のように語っている。

「テキストベースのプログラミング言語とは異なり、LabVIEW であれば熟練度が低い若年層の技術者でも十分に使いこなせる。基本操作としてはアイコンをワイヤーでつないでいくだけなので、テキストベースのプログラミング言語を使う場合にありがちな単純なコーディングミスは発生しない。また、デバッグを行う際にも、あらゆる情報が視覚的に示されるので、どこに問題があるのかを容易に理解できる。問題点を即座に修正して、すぐに再実行することも可能だ。このデバッグの容易さが、今回のプロジェクトでも有効に働いた」。

またデンソーウェーブの鈴木氏は、次のように述べている。

「今回の構成では、デバッグ作業をPC 上のLabVIEW 環境で完結させることができる。LabVIEW 環境に1 つのプログラムだけが存在する状態になるので、各構成要素間のハンドシェイクの確認作業などはほとんど行う必要がない。制御の主体としてPC を使用し、必要なソフトウェアをLabVIEW に集約することで、産業用途で使われている既存の技術をそのまま流用して短期開発を実現することができた。通常の産業アプリケーションと同じようなシステム構成では、納期までに開発を完了することは不可能だったであろう」。

写真1. 畳の下はこのような状態に

このようにして、基本的な開発作業は1 ヶ月ほどで完了することができた。その後、テストの段階になり、このアプリケーション特有の課題を半月間のうちに解消していった。手作りの将棋盤や駒に起因する画像処理の問題なども、このテストの段階で発覚して解消された。このテスト/ 改善のフェーズでも、LabVIEW が非常に有効に機能した。この点について、マックシステムズ 営業部 SE 課 課長の岡田泰尚氏は、次のように述べている。

「このアプリケーションの場合、設置場所が毎回異なることから、現場での微調整がその都度必要になると考えられた。例えば、照明の条件なども会場ごとに異なるので、現場にシステムを設置してから微調整を施さなければならない可能性があったのだ。そうした場合でも、現場での条件に応じ、フィルタ処理やエッジ処理など、LabVIEW にあらかじめ用意された膨大な関数の中から必要なものを選び、その場で適用することができる。つまり、LabVIEW をベースとしたシステム構成にしておけば、現場であらゆる条件に対応することが可能になるということだ。短期開発が求められていたことに加え、そうした臨機応変な対応も必要であったことから、PC 上のLabVIEW 環境ですべてを管理する方法でなければ、プロジェクトを成功に導くことはできなかったと言える」。

写真2. 対局前夜、最終的な動作確認を行う岡田氏

ロボットアプリケーションのさらなる可能性

例えば、PC を使って設備を制御したい、あるいは研究/ 開発で使用しているものをそのまま製造現場でも使いたいといったケースはよくある。そうした場合にも、今回のロボットシステムと同様に、PC とLabVIEW の組み合わせが有効に機能するはずだ。実際、デンソーウェーブやマックシステムズは、ロボット、ORiN、LabVIEW を組み合わせた製造ライン向けソリューションの提案を行っているところだという。マックシステムズの岡田氏は、「PC とLabVIEWを使ったロボットシステムを構築したことから、さまざまな可能性が見えてきた。NIのPXI 製品も組み合わせれば、ロボットによる操作に伴って発生する電波や振動などの情報を取得する計測アプリケーションなども容易に実現できるだろう」と述べている。

写真3. 開発担当者近影（左：松浦電弘社の北野氏　右：マックシステムズの岡田氏）