将棋の海外伝播などについてのブログ

将棋所英語対応版がリリース

　10/13 付けで、英語対応版の Universal Shogi Interface プロトコル対応のGUI将棋所1.1.0がリリースされている。

将棋所をダウンロード

英語対応。日本語以外のOSで起動すると英語表示になります。

とあるので、筆者の日本語OS環境ではどういう英語対応されたかは確認できない。とにかく、このバージョンアップにより、海外からのコンピュータ将棋エンジン開発への参入障壁がひとつ取り除かれたことになるのであろう。ありがたいことだ。

USIプロトコルに対応した将棋GUIソフトが登場

　昨日(8/19)の当ブログへのアクセスログを見ていて、当ブログの今年の1月16日のエントリー「有力なコンピュータチェスのオープンソース開発者が将棋に参入を表明」で紹介したTord Romstad 氏の提案を受け、USI(Universal Shogi Interface)プロトコルに対応した将棋GUIソフト「将棋所」が公開されたのを知った。動作環境OSはWindowsXP/2000とのこと。とりあえず一報のみ。詳細は以下を。

将棋GUIソフト「将棋所」のページ

shogi-lとにおけるやりとり

　Tord Romstat 氏の、USI Draft に関する shogi-l におけるやりとりをまとめてみた。日本語は筆者による要約なので、できるだけ原文にあたられたい。

Re: First draft of the Universal Shogi Interface (USI) (by David J Bush, Jan 24, 2007 13:04 PST )　ーーー　Time Control をGUIがエンジンに通信できるかという質問。チェスにはない秒読みが将棋にはあることを念頭に置いている。

Re: First draft of the Universal Shogi Interface (USI) (by Fabien, Jan 24, 2007 23:44 PST) ーーー　秒読みについて持ち時間が０になったときに開始されるとの説明。

Re: First draft of the Universal Shogi Interface (USI) (by Schefer, Jan 25, 2007 02:25 PST) ーーー　Time Controlについての補足。チェスクロックを使わないプロ棋戦の１分未満の消費時間をカウントしないことの説明。

Re: First draft of the Universal Shogi Interface (USI) (by fbc, Jan 26, 2007 00:37 PST ) ーーー　Notation について。SFEN以外の２方法を紹介。

Re: First draft of the Universal Shogi Interface (USI) (by Tord, Jan 26, 2007 01:31 PST ) ーーー　Patrick 氏の採用している Notation だと、持ち駒の歩が９枚を超えたときに問題が生じることが懸念される点の指摘と、これまでのフィードバックのまとめ。エンジンと開発者の名前は翻訳ファイルへ送信されるべき点（ほとんどが日本語になりそうなため）、Go コマンドは、秒読みを含む Time Control をサポートする必要がある点、Notation が SFEN か CSA standard Kifu file formatかはこだわりが無い点、エンジンに終局時の結果を伝えるのは、エンジンがその結果による何らかの種類の自動学習を行う場合には、よい考えだという点、将棋バリアントもGUIがサポートすべきという点については、優先度は高くないと考えている点の指摘。

Re: First draft of the Universal Shogi Interface (USI)　(by fbc, Jan 26, 2007 03:13 PST ) ーーー　CSA standard Kifu file format の参照先の質問。

Re: First draft of the Universal Shogi Interface (USI)　（by Tord, Jan 26, 2007 03:43 PST )　 ーーー　CSA standard Kifu file format （以下 CSA format)の参照先の回答。氏は前言を翻し、SFEN 寄りの姿勢を示す。ただし、CSA format の強い希望がコミュニティにあるのなら柔軟に考える、とも。

Re: First draft of the Universal Shogi Interface (USI) (by Tiggelman, Jan 26, 2007 13:25 PST ーーー　持ち歩が９枚超えの問題点に関して、二桁の数字（１０～１８）のかわりに（Ａ～Ｈ）を利用すれば解決との指摘。

Re: First draft of the Universal Shogi Interface (USI)　(by Tord, Jan 27, 2007 09:43 PST ーーー　その解決法もあるが、SFENにこだわりたい。また、日本勢の意見を待ちたい。

Re: First draft of the Universal Shogi Interface (USI) (by Eric, Jan 29, 2007 15:07 PST　ーーー　自作したmacshogi では、持ち歩９枚超えの問題に対しては、結局、数字だけを使うことにした事例の紹介。持ち歩が９枚を超える場合は、８桁の数字、超えない場合は７桁の数字ですべての持ち駒の枚数を表現する。

Re: First draft of the Universal Shogi Interface (USI)　(by Eric, Jan 29, 2007 15:19 PST ーーー　CSA Format は柿木氏の .kif format のことではないかという確認の質問。および、FEN notation を選好することの表明。

Re: First draft of the Universal Shogi Interface (USI)(byTakizawa,　Jan 29, 2007 22:19 PST ーーー　CSA Protocol について知ってほしいと主張。

Re: First draft of the Universal Shogi Interface (USI)　(by Tord, Jan 30, 2007 00:21 PST ）ーーー　CSAプロトコルは既知。CSAプロトコルとUSIは全く目的が異なる。CSAプロトコルは、複数のマシンで走るエンジンを一台の中央サーバーに繋いで自動対局させようというもの。USI は一台のマシンでエンジンと GUI との通信をする目的。CSAプロトコルを使って一台のマシン上で両者を通信させるは、４つの点であまり柔軟でなく、ユーザフレンドリーでもない。（４つの点についてはリンク先の原文を当たられたい）。

Re: First draft of the Universal Shogi Interface (USI)　(by Albrecht, Jan 30, 2007 03:02 PST)ーーー　Bonanzaは、CSA XT という CSA format を用いた GUI を使って一台のマシン上で動いているのでは、という質問。

Re: First draft of the Universal Shogi Interface (USI)　(by Tord, Jan 30, 2007 04:01 PST )ーーー　CSA XT は Windows でしか動かないので、自分は使えない。しかし、CSAプロトコルへの拡張がどう記述されているかは興味があることかもしれない。今までのところ、Linux ないしWindows 用のコンパチブルな GUI を書くことに興味のありそうな人は見当たらないようだ。

Re: First draft of the Universal Shogi Interface (USI)　（by 筆者, Jan 30, 2007 04:28 PST ーーー　世界コンピューター将棋選手権の歴史を考えて、USIの notation は、CSA ｆormat と同様にする余地は無いのかの質問。および、詰みの有り無しの情報がエンジンから GUI に返されるようにしてはというインプットがあった点の指摘、および、セクション３の記述の、黒の駒は持ち駒ではないかの確認。

Re: First draft of the Universal Shogi Interface (USI)　(by Tord, Jan 30, 2007 05:22 PST ーーー　既に示した通り、日本のプログラマーの多数が望むのならば、CSA format の Notation を採用してもいい。ただ、個人的には、CSA format ではある局面を１行だけで記述できないので、採用したくないとは思っている。詰みのあるなしの情報は、セクション5.3ですでに記述している。黒の駒は持ち駒が正しい。

Re: First draft of the Universal Shogi Interface (USI)　(by Takizawa,  Jan 30, 2007 20:14 PST ) ーーー　WCSC参加プログラムはCSA format での棋譜の出力が参加の条件になっていることの理解を求める。

Re: First draft of the Universal Shogi Interface (USI)　(by Tord, Jan 30, 2007 23:57 PST )　ーーー　CSA format での棋譜出力は、おさえるべき要求だが、エンジンからではなく、GUI から出力させたい。（２００８年か２００９年にはWCSCに参加したい）私の目的はもっとGUIをインテリジェントにして、エンジン開発者の負担を減らすことである。

Re: First draft of the Universal Shogi Interface (USI)　(by Takizawa, Jan 31, 2007 00:25 PST ) ーーー　WCSC参加を熱望する旨のと、USI合意形成への活動への謝意、および、日本語をしゃべらない者のコンピュータ将棋への参入が多数になることへの期待の表明。

5. Description of the universal shogi interfaceの日本語訳

（本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”5. Description of the universal shogi interface” のTakodori による日本語訳である）

5. ユニバーサル将棋インターフェースの説明

5.1. General rules
5.1 一般規定
* The specification is independent of the operating system. For Windows, the engine is a normal exe file, either a console or "real" windows application.
* その仕様は、OS から独立している。ウィンドウズでは、エンジンは、普通の実行形式のファイルか、ないしは、コンソールもしくは「リアルな」ウィンドウズアプリケーションである。

*All communication is done via standard input and output with text commands.
* あらゆる通信はテキストコマンドを使った標準の入出力で行われる。

* The engine should boot and wait for input from the GUI, the engine should wait for the isready or setoption command to set up its internal parameters as the boot process should be as quick as possible.
* エンジンは、GUI からの入力でブートとウェイトができなければならない。すなわち、エンジンは、ブートプロセスができるだけ早く起こるように、内部のパラメーターを設定する isreadyコマンドないしsetoptionコマンドを待たなければならない。

* The engine must always be able to process input from stdin, even while thinking.
* エンジンは、常に、たとえ思考中であっても、stdin からの入力を実行できるようになっていなければならない。

* All command strings the engine receives will end with '\n', also all commands the GUI receives should end with '\n'. Note: '\n' can be 0x0d or 0x0a0d or any combination depending on your OS. If you use the engine and GUI in the same OS this should be no problem if you communicate in text mode, but be aware of this when for example running a Linux engine in a Windows GUI.
* エンジンが受信するすべてのコマンドの string は、'\n',で終了し、また、GUI が受信するコマンドもすべて、'\n'で終了する。注意：'\n'はＯＳによって、0x0d だったり0x0a0dだったり、他のあらゆる組み合わせになりうる。同じＯＳ上でエンジンと GUI を利用するならこの点は問題にならないが、例えば、ウィンドウズ用の GUI でリナックスのエンジンを走らせるような場合には、このことに留意する必要がある。

* Arbitrary white space between tokens is allowed.
* トークン信号間に任意の空のスペースが入ることは容認される。

* The engine will always be in forced mode which means it should never start calculating or pondering without receiving a go command first.
* エンジンは、常に強制されたモードになっている。すなわち、それは、go コマンドを受信することなく計算したり、熟考したりし始めることが決して起こるべきではないことを意味する。

* Before the engine is asked to search on a position, there will always be a position command to tell the engine about the current position.
* エンジンがある局面について探索することを求められないうちに、現在の局面についてエンジンに伝えるための局面コマンドが常に存在する。

* By default all the opening book handling is done by the GUI, but there is an option for the engine to use its own book (USI_OwnBook option, see below).
* デフォルトでは、すべての序盤の棋譜の扱いは、GUI によってなされる。しかしながら、エンジンが自身の持つ棋譜を使うことも選択可能である（USI_OwnBookオプション、下部参照）

* If the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string in this line. Examples: joho debug on\n should switch the debug mode on given that joho is not defined, debug joho on\n will be undefined however.
* もし、エンジンないし GUI が未知のコマンドもしくはトークン信号を受信した場合には、それを単に無視し、残りの string を解析するようにせねばならない。例：" joho debug on\n"は、"joho"が定義されていないとき、デバッグモードを作動させなければならない。しかしながら、"debug joho on\n"が定義されることは無い。

* if the engine receives a command which is not supposed to come, for example stop when the engine is not calculating, it should also just ignore it.
* エンジンが想定していないコマンドが来たのを受信した場合、例えば、エンジンが計算を行っていないときの stop コマンドが来た場合、エンジンはそれをただ無視すべきである。

5.2. Move format
5.2 着手のフォーマット
*Normal (i.e. non-promoting, non-dropping moves) are written in English coordinate notation, using only the source and destination squares, without any piece letters or other characters (for instance 7g7f).
" 通常の着手（すなわち、成っていなく、持ち駒を打つでもない）は、（例えば 7g7f のように）元の升目と動かしたい升目を、駒の文字その他の文字を使うことなく、英語の座標記法で書かれることとなる。
" Promotion moves are written just like normal moves, except that an extra '+' character at the end of the move (for instance 4e3c+).
" 成りの着手は、指し手のサイトに'+'というキャラクターを付加すること以外は、通常の着手と同じようにして書かれることとなる。(例、4e3c+)
" Drops are written with the English piece letter in upper case followed by a star (*) and the destination square (for instance P*3d).
" 持ち駒を打つ着手は、英語の駒の大駒文字とそれに続く星印(*)と、動かしたい升目によって書かれることとなる（例は P*3d）

5.3. GUI to engine
5.3 GUI からエンジンへ
These are all the command the engine gets from the interface.
以下は、エンジンがインターフェースから得るすべてのコマンドである。

usi

Tell engine to use the USI (universal shogi interface). This will be sent once as a first command after program boot to tell the engine to switch to USI mode. After receiving the usi command the engine must identify itself with the id command and send the option commands to tell the GUI which engine settings the engine supports. After that, the engine should send usiok to acknowledge the USI mode. If no usiok is sent within a certain time period, the engine task will be killed by the GUI.
エンジンに USI(ユニバーサル将棋インターフェース)を使うよう伝える。これはプログラムがブートした後にエンジンに USI モードに切り替えるよう伝える最初のコマンドとして、一度送られることになる。usiコマンドを受信した後、エンジンは自身を id コマンドで識別し、GUI にエンジンがサポートするエンジン設定はどれなのかを伝えるオプションコマンドを送らなければならない。その後、エンジンは USI モードを肯定応答する usiok を送信せねばならない。もし、一定の時間内に usiok が送られない場合は、GUI によってエンジンのタスクは打ち切られる。

debug [ on | off ]

Switch the debug mode of the engine on and off. In debug mode the engine should send additional infos to the GUI, e.g. with the info string command, to help debugging, e.g. the commands that the engine has received etc. This mode should be switched off by default and this command can be sent any time, also when the engine is thinking.
エンジンのデバッグモードをオンにしたりオフにしたりする。デバッグモードにおいてエンジンは　ＧＵＩ　に追加情報を送らねばならない。例えばデバッグを助けるための info string コマンドであったり、エンジンが受信したコマンドであったりなどである。このモードはデフォルトではスイッチがオフでなければならず、また、エンジンが思考中も含めて、いつでもこのコマンドが送られるようになってなければならない。

isready

This is used to synchronize the engine with the GUI. When the GUI has sent a command or multiple commands that can take some time to complete, this command can be used to wait for the engine to be ready again or to ping the engine to find out if it is still alive. This command is also required once before the engine is asked to do any search to wait for the engine to finish initializing. This command must always be answered with readyok and can be sent also when the engine is calculating in which case the engine should also immediately answer with readyok without stopping the search.
これは、エンジンを GUI と同期させるために使われる。GUI が完了するのに時間のかかるコマンドをひとつないし複数送信したとき、このコマンドは、エンジンがもう一度準備ができるようになるのを待つためか、エンジンがまだ動いているかどうかを確かめるためにピングするために使われる。また、このコマンドは、エンジンが初期化を完了させるのを待つための探索を求められる前に、一度送られる必要がある。このコマンドは、常に、readyok で返信されねばならないし、エンジンが計算中で、探索を中断することなく redyok で即座に返信せねばならないような場合でも、送信されるようになってなければいけない。

setoption name <id> [value <x>]

This is sent to the engine when the user wants to change the internal parameters of the engine. For the button type no value is needed. One string will be sent for each parameter and this will only be sent when the engine is waiting. The name and value of the option in <id> should not be case sensitive and can not include spaces.
これは、ユーザーがエンジンの内部パラメーターを変更したいときにエンジンに送られる。ボタンタイプでは、値は必要ない。１string が、パラメーター毎に送られ、これは、エンジンが待機中のときにだけ送られる。<id>におけるオプションの名前と値は大文字と小文字を区別すべきではんく、また、スペースを含むことはできない。

register

This is the command to try to register an engine or to tell the engine that registration will be done later. This command should always be sent if the engine has sent registration error at program startup.
これは、エンジンを登録しようとする、ないし、エンジンに登録が後で行われると伝えるコマンドである。このコマンドは、エンジンがプログラム起動時に登録エラーを送るときは常に送信されねばならない。

The following tokens are allowed:
以下のようなトークン信号が許容されている。

later
The user doesn't want to register the engine now.
ユーザーは今エンジンを登録したくない。

name <x>
The engine should be registered with the name <x>
エンジンは<x>という名前で登録されねばならない。

code <y>
The engine should be registered with the code <y>
エンジンは、code <y>とともに登録されねばならない
Example: 例

"register later"
"register name Stefan MK code 4359874324"
   

usinewgame

This is sent to the engine when the next search (started with position and go) will be from a different game. This can be a new game the engine should play or a new game it should analyse but also the next position from a testsuite with positions only. As the engine's reaction to usinewgame can take some time the GUI should always send isready after usinewgame to wait for the engine to finish its operation.
これは、次の探索（started with position and go）が別の試合からになるときにエンジンに送られる。これは、エンジンが指さなければいけない新たな対局でありうるし、また、エンジンが分析しなければならない新たな試合でもありうる。のみならず、局面だけのテストスイートからの次なる局面でもありうる。エンジンの usinewgame への反応が時間をとることがあるので、GUI は、エンジンがその動作を終えるのをまつ usinewgame の後に必ず isready を送信せねばならない。

position [sfen <sfenstring> | startpos ] moves <move1> ... <movei>

Set up the position described in sfenstring on the internal board and play the moves on the internal board. If the game was played from the start position, the string startpos will be sent.
内部の盤面上に、sfenstring で記述された局面を設定し、内部の盤面上でプレーする。その試合が開始局面から指される場合は、startpos string が送信される。

Note: If this position is from a different game than the last position sent to the engine, the GUI should have sent a usinewgame inbetween.
注：もしこの局面が、すぐ前にエンジンに送られた局面でなく、別の試合からの局面となる場合は、GUI は usinewgame inbetween を送信し終わってなければならない。

go

Start calculating on the current position set up with the position command. There are a number of commands that can follow this command, all will be sent in the same string.
局面コマンドで設定された現在の局面に関して計算を開始する。このコマンドに続くコマンドがいくつかあり、すべてが同じ string で送信される。

If one command is not sent its value should be interpreted as if it would not influence the search.
もし、ひとつのコマンドが送信されなければ、その値は、あたかもそれが探索に影響をしないように解釈されなければならない。

searchmoves <move1> ... <movei>

Restrict search to this moves only
この指し手についてのみに探索を限定

Example: After position startpos and go infinite searchmoves 7g7f 2g2f, the engine should only search the two moves P-7f and P-2f in the initial position.
例：局面が startpos で go infinite searchmoves が7g7f 2g2fになると、エンジンは初形配置から7六歩　2六歩の2手しか探索しない

ponder

Start searching in pondering mode. Do not exit the search in ponder mode, even if it's mate! This means that the last move sent in in the position string is the ponder move. The engine can do what it wants to do, but after a ponderhit command it should execute the suggested move to ponder on. This means that the ponder move sent by the GUI can be interpreted as a recommendation about which move to ponder. However, if the engine decides to ponder on a different move, it should not display any mainlines as they are likely to be misinterpreted by the GUI because the GUI expects the engine to ponder on the suggested move.
熟考モードでの探索を開始する。熟考モードでは、探索から抜けてはならない。たとえ詰んでいてもだ。これは、局面 string で送信された着手が熟考された指し手であることを意味する。エンジンはそれがしたいことをできるが、ponderhit コマンドの後では、エンジンは示唆された差し手を実行して、熟考し続けなければならない。これは、GUI によって送信された熟考した手が、どの手について熟考すべきかについての推奨と解釈されることがあるのを意味する。しかしながら、もしエンジンが別の手を熟考すべきと判断した場合は、GUI はエンジンが示唆された指し手を熟考していると期待しているために、本線の手順が GUI よって誤って解釈されそうなため、エンジンは本線の手順を表示すべきではない。

btime <x>
Black has x milliseconds left on the clock
黒にはクロック上 x ミリ秒残っている

wtime <x>
White has x milliseconds left on the clock
白には、クロック上 X ミリ秒残っている

binc <x>
Black increment per move i milliseconds if x > 0.
x > 0 のとき、黒の一手ごとの増加するミリ秒
winc <x>
White increment per move i milliseconds if x > 0.
x > 0 のとき、白の一手ごとの増加するミリ秒

movestogo <x>
There are x moves to the next time control. This will only be sent if x > 0. If you don't get this and get the wtime and btime, it's sudden death.
次のタイムコントロールまで、ｘ　手である。これは、x > 0　のときだけ送信される。もし、これを受け取らずに、wtime と btime を受け取るなら、それは突然死である。
depth <x>
Search x plies only.
探索するのは x plies だけ。

nodes <x>
Search x nodes only.
探索するのは x ノードだけ。

mate <x>
Search for a mate in x moves. Programmers coming from computer chess should note that we follow the shogi convention for counting moves, i.e. we count what chess players usually describe as "plies" or "half moves". For instance, mate 5 means mate in 5 plies.
ｘ手の詰めを探索する。コンピュータチェス出身者は将棋式の手数の数え方に従うよう留意すべきである。すなわち、われわれはチェスプレーヤーが "plies"とか"half moves"とか通常呼んでいるものを数えているのである。例を出すと、mate 5 は、5 plies の詰めの意味のことである。

movetime <x>
Search exactly x milliseconds.
探索をぴったり x ミリ秒行う

infinite
Search until the stop command is received. Do not exit the search without being told so in this mode!
Stopコマンドが来るまで探索を続ける。このモードにいるときはそうしろと命じられるまでは探索から抜けてはいけない。

stop

Stop calculating as soon as possible. Don't forget the bestmove and possibly the ponder token when finishing the search.
計算を可及的速やかに停止する。探索を終了するときに、ベストムーブと、おそらく存在する熟考トークン信号を忘れてはならない。

ponderhit

The user has played the expected move. This will be sent if the engine was told to ponder on the same move the user has played. The engine should continue searching but switch from pondering to normal search.
ユーザーは期待した指し手を着手し終わった。これは、ユーザーが指した手と同じ手を熟考せよとエンジンが言われたときに送信される。エンジンは、探索を続けるが、熟考から抜けて通常探索に切り替えなければならない。

quit

Quit the program as soon as possible.
プログラムを可及的速やかに終了させねばならない。

5.3. Engine to GUI
5.3 エンジンから GUI へ (数字はママ、筆者註）

id

name <x>
This must be sent after receiving the usi command to identify the engine, e.g. id name Shredder X.Y\n
これは、usi コマンドを受信した後にエンジンを識別するために送信されなければならない。例：id name Shredder X.Y\n

author <x>
This must be sent after receiving the usi command to identify the engine, e.g. id author Stefan MK\n
これは、usi コマンドを受信した後にエンジンを識別するために送信されなければならない。例：id author Stefan MK\n

usiok

Must be sent after the id and optional options to tell the GUI that the engine has sent all infos and is ready in usi mode.
これは、id と optional options の後に、GUI にエンジンがすべての情報を送り、usi モードで準備ができていることを伝えるために送信されなければならない。

readyok

This must be sent when the engine has received an isready command and has processed all input and is ready to accept new commands now. It is usually sent after a command that can take some time to be able to wait for the engine, but it can be used anytime, even when the engine is searching, and must always be answered with readyok.
これは、エンジンが isready コマンドを受信して、すべての入力をプロセスし、新たなコマンドを受け入れ可能になったときに送信されなければならない。通常、エンジンを待つことができる時間が取れるコマンドの後に送信されるが、いつでも、たとえエンジンが探索中でも利用可能である。そして、常に readyok で返信されなければならない。

bestmove <move1> [ponder <move2>]

The engine has stopped searching and found the move <move> best in this position. The engine can send the move it likes to ponder on. The engine must not start pondering automatically. this command must always be sent if the engine stops searching, also in pondering mode if there is a stop command, so for every go command a bestmove command is needed! Directly before that the engine should send a final info command with the final search information, the the GUI has the complete statistics about the last search.
エンジンが探索を停止し、この局面における最善手<move>を発見した。エンジンは、エンジンが熟考したい指し手を送ることができる。エンジンは、自動的に熟考を開始してはならない。本コマンドが、エンジンが探索をやめた場合や、熟考モードで stop コマンドが来た場合には必ず送信されなければならない。したがって、すべての go コマンドに対して, bestmove コマンドが必要となる！ エンジンが最後の探索情報とともに最終の情報コマンドを送らねばならない直前にGUIは 直近の探索の完全な統計を持っていなければならない。

copyprotection

This is needed for copyprotected engines. After the usiok command the engine can tell the GUI, that it will check the copy protection now. This is done by copyprotection checking. If the check is ok the engine should send copyprotection ok, otherwise copyprotection error.
これは、コピープロテクトされたエンジンにとって必須である。Usiok コマンドの後に、エンジンは GUI に、エンジンがコピープロテクションをこれから行うことを伝えることができる。これは、コピープロテクションによってなされる。チェックがＯＫならばエンジンはコピープロテクションＯＫを送信しなければならない。でなければ、コピープロテクションエラーを送信しなければならない。

If there is an error the engine should not function properly but should not quit alone. If the engine reports copyprotection error the GUI should not use this engine and display an error message instead!
もし、エラーが発生したら、エンジンは適切に動いてないはずであるが、単独で停止してはならない。もしエンジンがコピープロテクションエラーをレポートしたら、GUIはこのエンジンを使ってはならず、そのかわりにエラーメッセージを表示しなければならない！

The code in the engine can look like this:
そのためのエンジンにおけるコードはは以下のようにできる。
TellGUI("copyprotection checking\n");
// ... check the copy protection here ...
if(ok)
   TellGUI("copyprotection ok\n");
else
          TellGUI("copyprotection error\n");
   

registration

This is needed for engines that need a username and/or a code to function with all features. Analogously to the copyprotection command the engine can send registration checking after the usiok command followed by either registration ok or registration error. Also after every attempt to register the engine it should answer with registration checking and then either registration ok or registration error.
これは、すべての機能を働かせるのに、ユーザーネーム、暗号を必要とするエンジンにとって必要なものである。

In contrast to the copyprotection command, the GUI can use the engine after the engine has reported an error, but should inform the user that the engine is not properly registered and might not use all its features.
コピープロテクションコマンドと対照的に、GUI はエンジンがエラーをレポートした後にエンジンを利用することができる。しかし、ユーザーにエンジンが適切に登録され、すべての機能を使える様になっていないかもしれないことを伝えなければいけない。

In addition the GUI should offer to open a dialog to enable registration of the engine. To try to register an engine the GUI can send the register command. The GUI has to always answer with the register command if the engine sends registration error at engine startup (this can also be done with register later) and tell the user somehow that the engine is not registered. This way the engine knows that the GUI can deal with the registration procedure and the user will be informed that the engine is not properly registered.
さらに、GUI は、エンジンの登録を可能にするためのダイアログを用意しなければならない。あるエンジンを登録しようとするために、GUIは register コマンドを送信できる。GUI は、エンジンがエンジン起動時に registration error を送信した場合は、常に register command で返信しなければならない（これは起動後も同様である）。そして、ユーザーにエンジンが登録されていないことをどうにかこうにかして伝えなければならない。このようにして、エンジンは、GUIが登録手続きを処理できることを知り、ユーザーはエンジンが適切に登録されていないことを知らされることになる。

info

The engine wants to send information to the GUI. This should be done whenever one of the info has changed.
エンジンは、GUI に　information を送りたい。これは、info がひとつでも変化したしたときはいつでも行われなければならない。

The engine can send only selected infos or multiple infos with one info command, e.g. info currmove 2g2f currmovenumber 1 or info depth 12 nodes 123456 nps 100000.
エンジンは、選ばれた info だけを送信することもできるし、複数の info をひとつの info コマンドを用いて送信することもできる。例：info currmove 2g2f currmovenumber 1 or info depth 12 nodes 123456 nps 100000.

Also all infos belonging to the pv should be sent together, e.g.
また、pv に属するすべての info　は一緒に送信されねばならない。例は以下

info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv 2g2f 8c8d 2f2e
   
I suggest to start sending currmove, currmovenumber, currline and refutation only after one second in order to avoid too much traffic.
私は、トラフィックが混みすぎるのを避けるために、1秒後に、currmove, currmovenumber, currline and refutation だけを送り始めることをすすめる。

Additional info:
追加的情報
depth <x>
Search depth in plies.
探索の深さ　<X>plies

seldepth <x>
Selective search depth in plies. If the engine sends seldepth there must also be a depth present in the same string.
選択可能な手の探索の深さ。もしエンジンが seldepth を送信したら、同じ string 内にも深さが存在していなければならない。

time <x>
The time searched in ms. This should be sent together with the pv.
探索の時間。これは pv とともに送信されねばならない。

nodes <x>
x nodes searched. The engine should send this info regularly.
探索されるノード数。エンジンはこの info を定期的に送らなければならない。

pv <move1> ... <movei>
The best line found.
発見された最善の手順

multipv <num>
This for the multi pv mode. For the best move/pv add multipv 1 in the string when you send the pv. In k-best mode, always send all k variants in k strings together.
これは、複数の pv モードのためのもの。The best move/pv 用には、pv を送信するときに、string 内に multipv 1を付け加える。

score
得点
cp <x>
The score from the engine's point of view, in centipawns.
エンジンの見地からの棋譜。In centipawns

mate <y>
Mate in y plies. If the engine is getting mated, use negative values for y.
ｙ手のメイト。エンジンがメイトされる場合は、y にはマイナスの値がはいる。

lowerbound
The score is just a lower bound.
得点が下限である。

upperbound
The score is just an upper bound.
得点が上限である

currmove <move>
Currently searching this move.
現在、この手の探索中

currmovenumber <x>
Currently searching move number x, for the first move x should be 1, not 0.
現在、ｘ　手目を探索中。初手は 1 で表され 0　ではない。

hashfull <x>
The hash is x permill full. The engine should send this info regularly.
ハッシュは、full の状態のx % 使っている。エンジンはこの info を定期的に送信せねばならない。

<x>
x nodes per second searched. the engine should send this info regularly.
探索される一秒あたりのノード数。エンジンはこの info を定期的に送信せねばならない。

cpuload <x>
The cpu usage of the engine is x permill.
エンジンのCPU利用は、x % である。

string <str>
Any string str which will be displayed be the engine. if there is a string command the rest of the line will be interpreted as <str>.
表示されるあらゆる string str は、エンジンである。もし、string コマンドがあれば、残りのラインは<str>と解釈される

refutation <move1> <move2> ... <movei>
Move <move1> is refuted by the line <move2> ... <movei>, where i can be any number >= 1. Example: after move 8h2b+ is searched, the engine can send info refutation 8h2b+ 1c2b if 1c2b is the best answer after 8h2b+ or if 1c2b refutes the move 8h2b+. If there is no refutation for 8h2b+ found, the engine should just send info refutation 8h2b+. The engine should only send this if the option USI_ShowRefutations is set to true.
着手<move1>は,<move2>. ... <movei>の手順によって、論破される。<i>nには、1以上の数字がはいる。例：8h2b+という手が探索された後、1c2bが8h2b+の後の最善手とされた場合、ないし、1c2bが8h2b+に勝る場合、エンジンは refutation 8h2b+ 1c2bという info を送信できる。エンジンは、USI_ShowRefutationsのオプションが true に設定されているときのみこれを送信せねばならない。

currline <cpunr> <move1> ... <movei>
This is the current line the engine is calculating. <cpunr> is the number of the cpu if the engine is running on more than one cpu. <cpunr> = 1,2,3.... If the engine is just using one cpu, <cpunr> can be omitted. If <cpunr> is greater than 1, always send all k lines in k strings together. The engine should only send this if the option USI_ShowCurrLine is set to true.
これは、現在エンジンが計算している手順である。<cpunr>は、エンジンが1つより多い CPU で動作している場合の CPU の数を表す。<cpunr>は正の整数である。もしエンジンがひとつのCPUしか使っていない場合は、<cpunr>は省略可能である。<cpunr>が１より大きな場合は、常に k string に あらゆる k 手順を載せて、共に送信する。この場合、USI_ShowCurrLineオプションが true に設定されていなければエンジンはこれを送信できない。

option

This command tells the GUI which parameters can be changed in the engine. This should be sent once at engine startup after the usi and the id commands if any parameter can be changed in the engine. The GUI should parse this and build a dialog for the user to change the settings. Note that not every option should appear in this dialog, as some options like USI_Ponder, USI_AnalyseMode, etc. are better handled elsewhere or are set automatically.
このコマンドは、GUI に、エンジンのどのパラメータが変更可能かを伝える。　これは、何らかのパラメータが変更可能である場合、起動時にusiと id コマンドに続いて一度送信されなければならない。GUI はこれを構文分析し、ユーザーが設定を変更できるようなダイアログを作らねばならない。注意すべきは、いくつかのオプション、すなわちUSI_Ponder, USI_AnalyseMode,などは別に扱われたほうがよいか、自動的に設定されるほうが良いように、あらゆるオプションがこのダイアログに現れるべきではないことである。

If the user wants to change some settings, the GUI will send a setoption command to the engine.
ユーザーが何らかの設定を変えたい場合は、GUI は setoption コマンドをエンジンに送信する。

Note that the GUI need not send the setoption command when starting the engine for every option if it doesn't want to change the default value. For all allowed combinations see the examples below, as some combinations of this tokens don't make sense.
GUI は、デフォルトの値を変更したくない場合は、エンジンを起動するときに setoption コマンドを送信する必要がないことに注意すべきである。許容されるあらゆる組み合わせを下部に例示する。トークン信号のいくつかの組み合わせはつじつまがあわなくなる。

One string will be sent for each parameter.
ひとつの string がそれぞれのパラメーターに送信される。

name <id>
The option has the name <id>. Whitespace is not allowed in an option name. Note that the name should normally not be displayed directly in the GUI: The GUI should look up the option name in the translation file, and present the translation into the users preferred language in the engine's option dialog.
このオプションは、名称 <id>を有する。空のスペースはオプションの名称として許されない。この名称が通常 GUI に直接表示されわけではないことに留意せよ。GUI は「翻訳ファイル」のオプション名称を参照し、ユーザーの好みの言語に翻訳されて、エンジンのオプションダイアログに表示される。

Certain options have a fixed value for <id>, which means that the semantics of this option is fixed. Usually those options should not be displayed in the normal engine options window of the GUI but get a special treatment. USI_Pondering for example should be set automatically when pondering is enabled or disabled in the GUI options. The same for USI_AnalyseMode which should also be set automatically by the GUI. All those certain options have the prefix USI_. If the GUI gets an unknown option with the prefix USI_, it should just ignore it and not display it in the engine's options dialog.
いくつかのオプションは、固定値<id>を持っている。すなわち、このオプションの動作は決まっていることを意味する。通常、これらのオプションは、GUIの普通のエンジンオプションのウィンドウには表示されるべきではないが、例外的に特別扱いすることもある。例えば、USI_Pondering は、GUIのオプションで熟考が可能になったり不可能になったりされたときに自動的に設定がされるべきである。同様に、USI_AnalyseModeについても GUI によって自動的に設定がされるべきである。これらのオプションに共通するのは、USI_という接頭子を持っていることである。もし、GUI 側でUSI_という接頭子つきの見知らぬオプションを見つけたら、それは単純に無視して、エンジンのオプションダイアログに表示させるべきではない。

The options with fixed semantics are:
定まった動作をするオプションは以下のようなものである。

<id> = USI_Hash, type spin
The value in MB for memory for hash tables can be changed, this should be answered with the first setoptions command at program boot if the engine has sent the appropriate option name Hash command, which should be supported by all engines! So the engine should use a very small hash first as default.
ハッシュテーブル用のメモリーのメガバイト値は、変更可能である。これは、エンジンが正確なオプション名称の Hash コマンドを送っていれば、プログラムブート時の最初の setoptions コマンドに対応して返信されるべきである。これはすべてのエンジンにあてはまる！

<id> = USI_Ponder, type check
This means that the engine is able to ponder (i.e. think during the opponent's time). The GUI will send this whenever pondering is possible or not. Note: The engine should not start pondering on its own if this is enabled, this option is only needed because the engine might change its time management algorithm when pondering is allowed.
これは、エンジンが熟考できることを意味する（例えば、相手の時間に考慮する、など）。GUI は、熟考が可能なときもそうでないときもこの信号を送信する。注意：エンジンはこれが可能に成っていても、自分の時間で熟考を始めてはいけない。このオプションは、エンジンが熟考が許されているとき、時間管理のアルゴリズムを変更できるかもしれないという理由でのみ、必要とされる。

<id> = USI_OwnBook, type check
This means that the engine has its own opening book which is accessed by the engine itself. If this is set, the engine takes care of the opening book and the GUI will never execute a move out of its book for the engine. If this is set to false by the GUI, the engine should not access its own book.
これは、エンジンが自分でアクセスできる自身の序盤用の棋譜を持っていることを意味する。これが規定されているのならば、エンジンはその序盤の棋譜に留意するし、GUIはそのエンジンの棋譜から離れた手は決して指さない。もしこれが false と GUI によって設定されているならば、エンジンは自身の持つ棋譜にアクセスできないはずである。

<id> = USI_MultiPV, type spin
The engine supports multi best line or k-best mode. The default value is 1.
エンジンは複数の最善手順、ないし k-best モードをサポートする。デフォルト値は１である。

<id> = USI_ShowCurrLine, type check
The engine can show the current line it is calculating. See info currline above. This option should be false by default.
エンジンは、自身が計算している現在の手順を表示する。丈夫の currline の info を参照のこと。このオプションはデフォルトでは false ｓであるべきである。

<id> = USI_ShowRefutations, type check
The engine can show a move and its refutation in a line. See info refutations above. This option should be false by default.
エンジンは着手と読み筋を手順として見せることができる。上記の info refutations を見よ。このオプションはデフォルトでは false でなければならない。

<id> = USI_LimitStrength, type check
The engine is able to limit its strength to a specific dan/kyu number. This should always be implemented together with USI_Strength. This option should be false by default.
エンジンは、自らの強さを特定の段級位に制限することができる。これは、USI_Strength　と共に常に実践されねばならない。このオプションもデフォルトでは false でなければならない。

<id> = USI_Strength, type spin
The engine can limit its strength within the given interval. Negative numbers are kyu levels, while positive numbers are amateur dan levels. If USI_LimitStrength is set to false, this value should be ignored. If USI_LimitStrength is set to true, the engine should play with this specific strength. This option should always be implemented together with USI_LimitStrength.
エンジンは、ある一定の間隔の間は、実力を制限することがでっきる。負の数字は級位である。一方、正の数字はアマの段位を表す。
もし、USI_LimitStrengthが false に設定されている場合、この値は無視されねばならない。もし、USI_LimitStrengthが true に設定されている場合、エンジンはある特定の実力で対局をせねばならない。このオプションは、常にUSI_LimitStrength.とともに実践されねばならない。

<id> = USI_AnalyseMode, type check
The engine wants to behave differently when analysing or playing a game. For example when playing it can use some kind of learning, or an asymetric evaluation function. The GUI should set this option to false if the engine is playing a game, and to true if the engine is analysing.
エンジンは、分析しているときと、対局しているときで違うように振舞いたいものである。例えば、対局中は、それがある種の学習ないし非対称の評価機能をを用いることができる。GUIはエンジンが対局している場合はこのオプションを false に、エンジンが分析しているときは true に設定されねばならない。

type <t>
The option has type t. There are 5 different types of options the engine can send:
このオプションは、type t を有する。エンジンが送信できる5種類の異なるオプションのタイプがある。

check
A checkbox that can either be true or false.
true もしくは false になりうるチェックボックスである。

spin
A spin wheel or slider that can be an integer in a certain range.
ある一定の範囲におさまる整数となりうる回転ハンドルまたはスライダーである。

combo
A combo box that can have different predefined strings as a value.
異なるあらかじめ定義された strings を値としてもてるコンボ・ボックスである。

button
A button that can be pressed to send a command to the engine
エンジンにコマンドを送信するために押されうるボタンである。

string
A text field that has a string as a value, an empty string has the value <empty>.
ひとつのstring を値として持てるテキストフィールドのことである。空の string は <empty>という値を持つ。

filename
Similar to string, but is presented as a file browser instead of a text field in the GUI.
string に似ているが、GUI　において、テキストフィールドではなく、ファイルブラウザとして示される。

default <x>
The default value of this parameter is x.
このオプションの」デフォルト値は x である。

min <x>
The minimum value of this parameter is x.
このパラメーターの最小値は x である

max <x>
The maximum value of this parameter is x.
このパラメーターの最大値は x である。

Here are some examples illustrating the different types of options:
以下は、異なるオプションのタイプを指し示したいくつかの例である。

"option name Nullmove type check default true\n"
"option name Selectivity type spin default 2 min 0 max 4\n"
"option name Style type combo default Normal var Solid var Normal var Risky\n"
"option name LearningFile type filename default /shogi/my-shogi-engine/learn.bin"
"option name ResetLearning type button\n"

   
5.4. Examples

This is how the communication when the engine boots can look like:
これは、エンジンをブートするときの通信がどのようになるかを示すものである。

GUI     engine
// tell the engine to switch to USI mode
// エンジンに USI モードへ切り替えるように伝える

usi

// engine identify 
// エンジンの識別

        id name Glaurung Shogi 0.1
        id author Tord Romstad

// engine sends the options it can change
// the engine can change the hash size from 8 to 1024 MB
// エンジンが、変えることのできるオプションを送信する。
// エンジンが、ハッシュサイズを8から1024MBに変更できる

        option name USI_Hash type spin default 16 min 8 max 1024

// the engine can switch off Nullmove and set the playing style
// エンジンが、Nullmove のスウィッチを切り、棋風を設定

        option name Nullmove type check default true
        option name Style type combo default Normal var Solid var Normal var Risky

// the engine has sent all parameters and is ready
// エンジンがすべてのパラメーターを送信して、準備ができている

        usiok

// Note: here the GUI can already send a "quit" command if it just
// wants to find out details about the engine, so the engine should
// not initialize its internal parameters before here.
// 注意：ここでは、GUI が、エンジンについての詳細を知ろうとする場合に
// は"quit"コマンドを送ることができる。従って、エンジンはこれ以上前に
// 内部パラメーターを初期化してはならない。

// now the GUI sets some values in the engine
// さて、GUI はエンジンのいくつかの値を設定している。

// set hash to 128 MB
// ハッシュを 128MB に設定。

setoption name USI_Hash value 128

// set play style to "Solid"
// 棋風を「手堅い」に設定

setoption name Style value Solid

// waiting for the engine to finish initializing
// エンジンが初期化を完了させるのを待っている

// this command and the answer is required here!
// このコマンドと返信はここで必要になる

isready

// engine has finished setting up the internal values
// エンジンは、内部パラメーターを設定完了。

        readyok

// now we are ready to go
// Go できる状態になった

// if the GUI is supporting it, tell the engine that is is
// searching on a game that it hasn't searched on before
// GUIがそれをサポートしているなら、エンジンに以前に探索した
// ことの無い試合を探索していることを伝える

usinewgame

// if the engine supports the "USI_AnalyseMode" option and the next
// search is supposed to be an analysis, the GUI should set
// "USI_AnalyseMode" to true if it is currently set to false with this
// engine.
// もし、エンジンが "USI_AnalyseMode" option をサポートしているのなら、
// 次の探索は分析になるはずである。GUI は、もしエンジンの値が falseに
// 設定されているのなら、"USI_AnalyseMode"の値を true に設定しなければ
// ならない。

setoption name USI_AnalyseMode value true

// tell the engine to search infinite from the start position after
// 1. P-7f 2. P-3d:
// 1手目7六歩2手目3四歩の後の開始局面から無限探索を行うように
// エンジンに伝える

position startpos moves 7g7f 3c3d
go infinite

// the engine starts sending infos about the search to the GUI
// エンジンが探索に関した info を GUI に送信し始める。

// (only some examples are given)
// (単にいくつかの例を並べてみる)

        info depth 1
        info score cp -2 depth 1 nodes 13 time 5 pv 8h2b+ 3a2b
        info depth 1
        info score cp 13 depth 1 nodes 24 time 11 pv 2g2f
        info depth 2
        info nps 15937
        info score cp 5 depth 2 nodes 255 time 90 pv 2g2f 4c4d
        info depth 3 seldepth 7
        info nps 26437
        info score cp 20  depth 3 nodes 1123 time 315 pv 2g2f 4c4d 2f2e
        ...

// here the user has seen enough and asks to stop the searching
// ここでは、ユーザーは十分であり、探索をやめる要求をだす。

stop

// the engine has finished searching and is sending the bestmove command
// which is needed for every "go" command sent to tell the GUI
// that the engine is ready again
// エンジンは、探索を完了し、bestmove コマンドを送信する。
// GUI にエンジンが再び準備ができていると伝えるために、go
// コマンドが毎回送信されることが必要

        bestmove 2g2f ponder 4c4d

4. Differences between the UCI and USI protocolsの日本語訳

（本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”4. Differences between the UCI and USI protocols” のTakodori による日本語訳である）

　（gg さんのコメントを参考にし、一部修正しました。 2007/1/30)

　（

4. UCIとUSIの違い

This section is intended for programmers who are already familiar with the UCI protocol. Those who do not know anything about UCI are adviced to skip to section 5.
　本セクションは、UCIプロトコルに既になじんでいるプログラマー向けに意図されたものである。UCI については知識がないという 何も知らない方はセクション５にスキップされたい。

The USI protocol is identical to the USI protocol apart from the following changes:
USI プロトコルは、以下に述べる変更点を除いて、USI と同等同一である。

* An UCI engine consists of only the executable file, but an USI engine should contain a separate "translation file", a Unicode text file containing translations of the engine and author names and all the parameter names into one or more languages. The format for the translation file is not yet decided.
* UCI エンジンは、実行形式のファイルだけから成る。しかし、USI エンジンは、別途「翻訳ファイル」を持つことになる。これは、エンジンおよび開発者の名前、すべてのパラメーターの名称をひとつないしそれ以上の言語に翻訳したものを収納している Unicode のテキストファイルである。翻訳ファイルのフォーマットは未定である。

* Spaces are not allowed in option names. This fixes a small defect in the UCI protocol: In a UCI chess engine, there are certain words (most notably "type") which cannot be used in option names because it would cause ambiguity. The only advantage of allowing spaces in option names is that it makes the names look cosmetically nicer in the GUI, and this advantage disappears in USI because the GUI will not display the option name, but the translation found for this option name in the translation file. For instance, if the engine has an option named "NULL_MOVE_R", the translation file can contain an English translation like "Null move reduction factor", and it is this translation that will be displayed in the GUI (assuming that the user has set English as her preferred language).
* オプション名称の中には、スペースを使うことはできない。これは、UCI プロトコルのある小さな欠点を手直しするものである。UCI を用いるチェスエンジンにおいては、あいまいさが生じるため、ある種の言葉は選択できる名称オプション名として使用できない（"type"が最もよく知られている例）。オプション名称中ににスペースを使える様にする唯一の利点は、そうすることで GUI の見映えが良くなることだけである。そして、その利点は USI においては消滅する。というのは、GUI は選択可能な名称を表示するのではなく、「翻訳ファイル」中にある、オｐ所ンオプション名称に対応した翻訳された言葉を表示するからである。例をあげよう。仮にエンジンが"NULL_MOVE_R"というオプション名称をもっていたとすると、「翻訳ファイル」は、"Null move reduction factor"　のような英語の訳語を持つことになり、まさしくその訳語が GUI 上に表示されることになる（これは、ユーザーが英語を好みの言語として設定したという前提での話である）

* A new option type, "filename", has been added. This is identical to the "string" option type, except for the way it is presented in the GUI. For "filename" options, the GUI will display a file browser, while for "string" options, it will let the user type a string. The new option type is intended to be used for selecting opening book files and similar tasks.
* "filename"というオプションタイプが追加されている。これは、"string"というオプションタイプと、GUI で表示のしかた以外の点で同等である同一である。"filename"オプション用に、GUI は、ファイルのブラウザを表示する。一方、"string"オプションの場合には、ユーザーが string 文字列をタイプできるようになる。この新しいオプションタイプは、棋譜ファイルを開いたり定跡ファイルを選んだり、似たようなタスクを行ったりするのに使われるように意図されてしている。

* Instead of FEN strings, SFEN strings (as described in section 3) are used. Where UCI uses position fen <fen>, USI uses position sfen <sfen>.
*(セクション３で述べたように）FEN string のかわりに、SFEN string（セクション3で記述）　が使われる。すなわち、UCI が"position fen <fen>"を用いるところで、USI は"position sfen <sfen>"を用いるのである。

* Moves are written in coordinate notation, using the standard English shogi coordinates with the upper right corner (white's left corner) as square 1a and the lower left corner (black's left corner) as square 9i. Normal moves are written exactly as in UCI, except for the different coordinates (e.g. 7g7f). Promotions are written with an extra '+' character at the end of the move (e.g. 4e3c+). Drops are written as a piece letter in upper case, followed by a star ('*'), and the destination square (e.g. P*3d).
* 着手は、座標記法で書かれる。右上の隅（白側の左隅）が1aという升目になり、左下の隅（黒側の左隅）が 9i という升目になる英語による標準的な将棋座標を使うことになります。使って書かれる。通常の指し手は、異なる座標表現（例、7g7f）を除いて、UCI と全く同様に書かれる。成りは、指し手の最後に '+'キャラクターを付加して書かれる（例、4e3c+）。持ち駒を打つのは、大文字の駒の一文字の後に、星印'*'と目的の駒を打つ升目をつける続けることによって書かれる（例, P*3d）.

* Mate scores are always sent using the shogi convention for move counting: We count plies, not full moves. Where you would send info score mate 3 in a UCI engine, you should send info score mate 5 in a USI engine.
* 詰みの記録は、常に将棋式の手数の数え方を用いて送信される。チェス式では Plies を数え、すべての動きを数えないｆull move ではなくply を数える。UCI エンジンにおいて3手詰め記録情報を送信するとき、USI エンジンでは、5手詰みの記録情報を送信しなければならない。　UCIエンジンが3手で詰んだというスコアを送信するような場合は、USIエンジンは5手で詰んだと送信しなければならない。

* All options with fixed semantics start with the prefix USI_. For instance, the option which is named Hash in UCI is named USI_Hash in USI.
* 一定のプログラム動作を伴うその意味が決まっているあらゆるオプション名称は、接頭子 USI_ で始まる。例えば、UCI において Hash と命名されているオプションは、USI においては USI_Hash と命名される。

3. Forsyth-Edwards notation for shogi の日本語訳

（本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”3, Forsyth-Edwards notation for shogi” のTakodori による日本語訳である）

　(gg さんのコメントを参考に一部修正。2007/1/30)

　(一部修正 2007/2/12)

3. 将棋用のForsyth-Edwards 記法
In computer chess, there is a standardized compact ASCII notation for chess positions, known as the Forsyth-Edwards notation (usually abbreviated as FEN). It was originally invented by David Forsyth more than 100 years ago, and was extended for use with chess software by Steven Edwards some time in the 1990s. For a precise definition of the FEN standard, consult section 16.1 of the PGN specification.
　コンピュータチェスでは、チェスの局面を表記するのに、通常FENと略記される、Forsyth-Edwards 記法として知られている、標準化されたコンパクトなアスキー記法が存在する。これは、100年以上前に David Forsyth によってもともとは考案され、1990年代の時期に Steven Edwards によってチェスソフトで利用できるように拡張されたものである。正確な FEN スタンダードの定義については、PGN specification の section 16.1 に当たられたい。

As far as I know, no equivalent standard exists for shogi (please correct me if I am wrong). This section describes a variant of FEN notation suitable for shogi.
　私の知る限り、同様な標準は将棋には存在していない（もし誤っていれば、正されたし）。本セクションでは、将棋に適用できるFEN記法の変形について記述を行う。

A Shogi FEN string (SFEN from now on) consists of a single line of ASCII text containing four data fields, separated by whitespace. These are:
将棋FEN string （以後、SFEN と略す）は、空スペースで区分された４つのデータフィールドを含む一行のアスキーテキストから成る。そこにはそれらは

1.    Board state. The placement of the pieces of the board is written rank by rank, with each rank separated by a slash ('/'). The ranks are ordered from the white side, beginning with rank 'a' and ending with rank 'i' (using the standard English shogi board coordinates). For each rank, the squares are specified from file 9 to file 1. The uppercase letters "PLNSGBRK" are used for the non-promoted black pieces, while the lowercase letters "plnsgbrk" are used for the non-promoted white pieces. A promoted piece is denoted by a '+' character immediately before the piece letter, e.g. +B for a black promoted bishop. One or more contiguous empty squares are represented by a digit counting the number of squares.

1. 盤上の状態. 盤上の駒の配置が、行ごとに、スラッシュ('/')でそれぞれの行を区分しながら、記述される。行は白側から、'a' 行から始まり、'i'行で終わるように定義される（標準の英語の将棋盤の 座標を用いている）。すべての行に対しては、升目が、9筋から1筋まで定義される。大文字の "PLNSGBRK"という英語文字は、成っていない黒の駒を表すのに使われる。一方、小文字の "plnsgbrk"は、白の成っていない駒を表すのに使われる。成り駒は、駒の文字の直前に '+'を denote することで表される。成り駒は、駒の文字の直前の '+'文字で示されるすなわち、+B は黒の成り角を表す。ひとつないしそれ以上の contiguous な連続した空の升目は、升目の数を数える桁によって表される。升目の個数の数字１文字で表される。（訳者註：Pないしpは「歩」(Pawnの頭文字）、Lないしlは「香」(Lance),Nないしnは「桂」（kNight)、Sないしsは「銀」(Silver)、Gないしgは「金」(Gold)、Bないしbは「角」(Bishop)、Rないしｒは「飛」(Rook)、Kないしkは「玉」(King)を表す）

2.    The side to move. This field contains of a single letter, "b" (for "black") or "w" (for "white"), depending on the current side to move.

2. 手番　このフィールドには "b"(黒)ないし"w"(白)のどちらか一文字が、実際の手番によって入ることになる。

3.    Pieces in hand. Again we use uppercase letters for black pieces, and lowercase letters for white's captured pieces. A digit before a letter means that there are several pieces of the given type in hand. The pieces are always listed in the order rook, bishop, gold, silver, knight, lance, pawn; and with all black pieces before all white pieces. As an example, in a position where black has one rook, one gold and four pawns in hand, while white has two bishops, two silvers and three pawns, the pieces in hand data field in the SFEN would look like "RG4P2b2s3p". If neither player has any pieces in hand, a single minus character ("-") is used for the pieces in hand field.

3. 持ち駒　再び、黒の駒は大文字、白の持ち駒には小文字を使う。文字の前の数字は、ある特定の持ち駒が数枚あることを意味する。持ち駒は常に、飛、角、金、銀、桂、香、歩の順番で並ぶように順でリストされ、あらゆる黒の持ち駒は、白の持ち駒の前にくるようにされる。例を出そう。黒が飛を一枚、金を一枚と歩を4枚持ち駒とし、白が角を2枚、銀を2枚、歩を3枚持ち駒としている局面は、SFEN の持ち駒フィールド上では、"RG4P2b2s3p"というようになる。双方とも持ち駒無しの場合は、マイナスキャラクター("-")ひとつが持ち駒フィールドに入ることとする。

4.    Move count. An integer representing the number of the current move in the game. We are using the shogi convention for move counting, which means that we count what international players would call "plies" or "half moves". For instance, after the moves 1. P7g-7f 2. P8c-8d, the move counter is 3. The "move count" data field is optional; a program should be able to read and understand an SFEN string even if this field is missing.

4.    手数のカウント　整数は競技における現在の指し手の手数を表す。われわれは、将棋式の手数の数え方を採用する。すなわち、インターナショナルチェスのプレーヤーが、”pilies””plies” ”ply”とか “half move” と呼ぶ方式である。例を出すと、1. P7g-7f 2. P8c-8dという指し手の後の手は、手数は3になる。move countは３になる。"move count" フィールドは選択項目であり、プログラムは、このフィールドに入力がなくても、SREN string を読み、理解できなければならない。

の４つがあるである。

As an example, the initial position in shogi is encoded like this:
　例を出そう。将棋の初形配置初期配置は以下のようにコード化される。

lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1B5R1/LNSGKGSNL b - 1

A more complicated example is the following position, taken from the 3rd game of the 19th Ryu-O match between Sato and Watanabe:
　より複雑な例は、以下のような局面である。これは、第19期竜王戦第3局、渡辺竜王対佐藤棋聖戦から取った。

  9    8    7    6    5    4    3    2    1
+----+----+----+----+----+----+----+----+----+
|    |    |    |    |    |    |    |    | Lw | a    1B 1G 1N 3P
+----+----+----+----+----+----+----+----+----+
|    | Lw |+Rb |    |    | Pb |    |    |    | b
+----+----+----+----+----+----+----+----+----+
| Pw |    |    | Pw | Bb | Gb |    | Pw | Pw | c
+----+----+----+----+----+----+----+----+----+
| Kw | Pw | Sw |    | Pw |    |    |    |    | d
+----+----+----+----+----+----+----+----+----+
| Nb | Nw |    | Pb |    |    | Gb |    |    | e
+----+----+----+----+----+----+----+----+----+
| Pb |    | Pb |    | Pb |    |    | Pb | Pb | f
+----+----+----+----+----+----+----+----+----+
|    | Pb | Sb |    |    |    |    |    |    | g
+----+----+----+----+----+----+----+----+----+
|    | Kb | Sb | Gb |    |    |    |+Rw |    | h
+----+----+----+----+----+----+----+----+----+
| Lb | Nb |    |    |+Pw |    |    |    | Lb | i    1S 
+----+----+----+----+----+----+----+----+----+

The SFEN for the position above is:
上図の局面は、SFEN 上では以下のように表現される。

8l/1l+R2P3/p2pBG1pp/kps1p4/Nn1P2G2/P1P1P2PP/1PS6/1KSG3+r1/LN2+p3L w Sbgn3p 124

The SFEN notation described above differs from the FEN notation forchess positions in a few ways. The castling and en passant fields have been removed, for the obvious reason that castling and en passant captures do not exist in shogi. The halfmove clock has been removed because shogi has no 50-move draw rule. Finally, because captured pieces can be dropped back on the board in shogi, the "pieces in hand" data field has been added.

　上記のように記述されたこれまで述べてきたSFEN 記法は、チェスの局面用の FEN 記法といくつかの点で違いがある。キャスリングとアンパッサンのフィールドは取り除かれている。なぜなら、将棋にキャスリングとアンパッサンによる駒取りが存在しないのは明らかだからである。なぜなら、将棋にキャスリングとアンパッサンによる駒取りが存在しないのは明らかだからである。これは自明だが、将棋にはキャスリングとアンパッサンは無いからである。ハーフムーブクロックは、将棋には50手到達による引き分けルールが無いので、取り除かれている。最後に、将棋では、とった駒を盤上に打って再使用できるので、「持ち駒」データフィールドが追加されている

2, Some notes about language の日本語訳

（本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”2, Some notes about language” のTakodori による日本語訳である）

( gg さんのコメントをもとに一部修正、2007/1/30)

2.　言語についてのいくつかの覚書

All communication between the engine and the GUI is done by 7-bit ASCII text, and the English language is used in the names of the various commands. English letters are used to denote the various piece types ("P" for pawn, "L" for lance, etc.). This may seem like a strange choice (at least to non-technical users), considering that the vast majority of users of shogi software are Japanese.
　エンジンとGUI間のあらゆる通信は、７ビットアスキーテキストで行われる。そして、英語が様々なコマンドの名前として用いられる。英語の文字が駒を意味するのに使われる（歩なら "P"、香なら "L"　というように）。これは、将棋ソフトのユーザーの大部分が日本人であることを考えると、奇妙な選択にみえるかもしれない（少なくとも技術にあかるくないユーザーにとっては）。

The justification for the use of 7-bit ASCII is to make the work easier for the engine programmer. Most shogi engines are written in low-level programming languages like C, where reading and writing Unicode is difficult, especially while trying to maintain portability. Translation of the move output from the engine into Japanese notation is assumed to be the responsibility of the GUI.
　７ビットアスキーを利用するのは、エンジンをプログラムする人の仕事を楽にできるという点で正当化される。ほとんどの将棋エンジンは C 言語のようなローレベルのプログラミング言語で書かれている。そこでは、Unicode を読み書きすること、とりわけ、移植性を維持しようとすることは難しい。 Unicode を読み書きすることは、特に移植性を維持しようとする場合は、難しい。 指し手の出力をエンジンから日本語の棋譜記法に変換するのは、GUI 側の責任であることが前提となる。エンジンから出力された手の日本の棋譜記法への変換はＧＵＩの責任とする。

A USI engine may also have several engine parameters which can be configured by the user (e.g. style of play, piece values for the various pieces, different kinds of search parameters, and so on). Each parameter has an internal name in 7-bit ASCII which is used in all communication between the engine and the GUI. An USI engine should, in addition to the executable file, be delivered with a Unicode text file containing Japanese translations (and optionally translations into other languages) of all option names. The GUI should use the translations in this file when displaying the options to the user.
　ある USI を用いたエンジンには、ユーザーによって規定し得る、そのエンジン固有のパラメータがいくつかあるかもしれない(例を出そう。棋風、様々な駒の価値、様々な種類の検索変数、などなど)。それぞれのパラメータは、エンジンと GUI 間の通信に使われる７ビットアスキーにおいて、内部的な名前を付されてなければならない。USI エンジンは、実行形式のファイルに加えて、すべての選択肢の名称の日本語への（場合によっては他言語への）翻訳を含んだ形の Unicode テキストファイルと共に、提供されねばならない。GUI は、ユーザーにそれらの選択肢を示すとき、このファイル内の翻訳を使わなければならない。

The format of the translations file is not yet decided, and will be described in a future version of this document.
この翻訳を入れておくファイル形式はいまのところ未定である。本ドキュメントの将来版で記述されることになるだろう。

1, Introduction の日本語訳

（本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”1, Introduction” のTakodori による日本語訳である）

　（2007/1/30, gg さんのコメントをもとに一部修正）

　（2007/2/12, ggさんのコメントをもとに一部修正）

1. 導入

This is a preliminary draft of the Universal Shogi Interface, a protocol for communication between a shogi engine and GUI. It is my belief that such a protocol, if widely adopted, would give several benefits for the computer shogi community:
　本文書は、将棋エンジンとＧＵＩ間の通信プロトコル、Universal Shogi Interface の下ごしらえのドラフトである。私は、このようなプロトコルが広く採用されれば、コンピューター将棋コミュニティにとって有益であることを信じるものである。

*For beginning shogi programmers, a standard protocol with supporting GUIs considerably reduces the amount of work required to write a shogi program. Instead of having to write a complete graphical application, they can write their shogi program as a simple console mode program, and plug this little program into an existing GUI.

　将棋プログラマーを始める際、複数の GUI をサポートしている複数の GUIからサポートされた標準プロトコルがあると、かなり将棋プログラムを書くのに必要な仕事量を減らすことができる。将棋ソフトのＧＵＩ部をいやいや書く代わりに，簡単なコンソールアプリとして書いてそれを既にあるＧＵＩに繋ぐことができる。

*If the majority of shogi programs support a standard protocol, it becomes easy to run automatic tournament and matches between shogi programs. This is very useful for programmers, because a big number of games is often necessary in order to decide whether some change to a shogi program improves the strength.

もし、多数の将棋プログラムがひとつの標準プロトコルをサポートするなら、将棋プログラム間の自動トーナメントや試合を行うことが簡単になる。これはプログラマーにとって大変有益である。というのは、将棋プログラムへのある変更が強さを改善するかどうかを判断するのには、数多くの対戦がしばしば必要となるからだ。

*Portability between different operating systems becomes much easier when the engine is separated from the GUI. Porting a graphical application from Windows to Linux or Mac OS X is usually a big programming task, but simple text-mode programs can often be ported almost without any work. If all platforms have at least one GUI conforming to the protocol, a shogi programmer can make her program run on all platforms without doing much more than recompiling for each platform.

　異なるＯＳ間の移植性は、エンジンが GUI と分離しているときのほうが、はるかに簡単である。ウィンドウズからリナックスやマックＯＳ Xにグラフィカルアプリケーションを移植するのはプログラミング上の大仕事である。対して、単純なテキストモードプログラムはしばしばほとんど労力をかけずに移植できる。もしすべてのプラットフォームに、少なくとも標準プロトコルに準拠したGUI が少なくともひとつあれば、将棋プログラマーは、自身のプログラムをそれぞれのプラットフォーム用にリコンパイルすること以上のことをすることなく以上のことをせずに、あらゆるプラットフォームで走らせることができるようになる。

*For users of shogi software, a standardized protocol would make it possible to run several shogi engines in a single graphical interface. Instead of having to switch from one GUI to another whenever they want to use a different shogi program, they can use their favorite shogi GUI all the time, and load individual engines into the GUI.

　将棋ソフトのユーザーにとっても、標準化されたプロトコルにより、いくつかの将棋エンジンをひとつのグラフィックインターフェースで走らせることができるようになる。異なる将棋プログラムを使いたいときに必ずあるＧＵＩから別のGUIへの変更を余儀なくされるのではなく、ユーザーは自身の好みの GUI を常に使うことができるし、また、それぞれのエンジンを自分のGUIに乗せることもできる。　ユーザーは常に自身の好みの GUI を使い、各エンジンをその上で走らせることができる。

The USI protocol, as well as the textual description on the protocol below, is based on the UCI protocol used in computer chess. Almost all the current top computer chess programs support the UCI protocol, and compatible GUIs exist for Windows, Linux and Mac OS X.
　USI プロトコルは、下記のプロトコル上のテキスト記述とともに、コンピュータチェスにおける UCI protocol に基づいている。ほとんどすべての現在のトップのチェスプログラムが、UCI プロトコルをサポートしており、互換性のあるGUI がウィンドウズ、リナックス、および、マックＯＳ　Ｘ用に存在している。

I am grateful to Stefan Meyer Kahlen, the author of the UCI protocol, for allowing me to use his work as the basis for my shogi protocol. Most of the text in section 5 below is copied verbatim from the official UCI protocol description.
　私は、UCI プロトコルの作者のStefan Meyer Kahlen が、彼の仕事を私の将棋プロトコル用に使うことを許してくれたことに感謝している。セクション５におけるほとんどのテキストは、公式のUCIプロトコルの説明から逐語的に複製をしたものである。

First draft of the Universal Shogi Interfaceの構成と翻訳

　本ブログのカテゴリーとして、「USI関連」というカテゴリーを作成、Tord Romstad 氏の提案の関連コンテンツは、全部、「USI 関連」にカテゴリーわけすることにして、一覧性を高めることにした。

　First draft of the Universal Shogi Interface, Draft 1　の構成は以下のようになっている。技術文書なので、かえってわかりにくくなってしまうかもしれないが、多くの方が読んだほうがよかろうと思うので、徐々に日本語にし、できたものから本ブログにアップしていくこととする。なお、相応の注意をもって翻訳をしたつもりであるが、間違いがある可能性は否定できない。できるだけ原文のほうも当たっていただきたい。

1, Introduction（翻訳済み）

2, Some notes about language(翻訳済み）

3, Forsyth-Edwards notation for shogi（翻訳済み）

4. Differences between the UCI and USI protocols（翻訳済み,2007/1/27)

5. Description of the universal shogi interface(翻訳済み,2007/1/27)

Tord Romstad 氏のFirst draft of the Universal Shogi Interface (USI) が公開

　Tord Romstad 氏のコンピュータ将棋用のUSIのドラフトが公開された。以下はドラフト原文。

First draft of the Universal Shogi Interface (USI)(英語）

　英語の将棋メーリングリストの Romstad 氏からの投稿と今までの反応が１件ある。

First draft of the Universal Shogi Interface (USI)（by Tord Romstad, 英語）

　全般的に意見を受け付けたいとのことだが、特に、Section 2 の言語問題の解決と、Section 3 の局面の ASCII 表示についてコメントを求めているとのこと。

Re: First draft of the Universal Shogi Interface (USI) (by David J Bush, 英語）

　とりあえず、ポインターのみにて。