“2.1.1　Kindle Create”

　Kindle Createについての表記追加。.doc/.docx形式のファイルからKindleドキュメントを生成できるもの。ただし現状まだ日本語には未対応のよう。

“3　フォーマットの比較”

　「タイプセッティングの改善のコラムを追加」とある。ここでのコラムは表組みの「列」の意味と思われる。

“6.7　サポートされる文字とスペースの使用”

　「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください」とあるが、「Unicode 形式の文字」は英語版ドキュメントでは「Unicode format characters」とあり、「Unicodeの制御文字」と訳すべき箇所。
　おそらくU+0000 – U+001F（C0制御コード）、U+007F（削除文字）、U+0080-U+009F（C1制御コード）などを指していると思われるが（参考）、U+2028（LINE SEPARATOR）、U+2029（PARAGRAPH SEPARATOR）なども制御文字であるため注意が必要。また、U+0000〜U+001Fの制御文字のエリア内でもU+000A（LF）やU+000D（CR）などは改行コードであり、これを使うなというのは現実味がない。具体的に使うべきでないコードポイントを明示して欲しい。

“7.1　内部リンクに関するガイダンス”

　「意図しない脚注のポップアップが表示されないようにするには、脚注ではない内部リンクに双方向ハイパーリンク (A から B へのリンクと B から A へのリンク) を設定しないでください。」とある。作り方としては一般的だが、制作指針に縛りをかける要望ではある。
　また「現在、電子書籍端末の固定レイアウトの本では、内部ハイパーリンクはサポートされていません。」とあり、ここはずっと変わっていない。

“7.2　外部リンクのガイドライン”

　「本から外部Webサイトへのリンクは、読者体験とAmazonによって定められた本のコンテンツをより一層意義あるものにし、それらに直接関係のある場合に限ります。」とある。外部へのリンクは技術的に可能でも規約上の制約がかかるため注意が必要。
　「Amazonはリンクを独自の判断で削除する権利を有します。」ともある。

“9.1　メタデータのガイドライン”

　「<dc:language>」および「<dc:title>」が必須、ページめくりの方向が左から右ではない場合、メタデータまたは背表紙に「<meta name="primary-writing-mode" content="horizontal-rl"/>」のような形でページめくり方向を明示する必要がある、との記述。これはAmazon独自のメタデータなので注意が必要。従来これはフィックス型のEPUBでのみ必要な措置だったように記憶しているのだが、リフロー型でも必要になったようにも読める。だとすればメタデータの追記が必要になるだろう（ちなみにこの「horizontal-rl」という記述も以前からある罠で、「horizontal-lr」もしくは「vertical-rl」になると思われる。一度引っかかった）。なお、　「背表紙」は「Spine」をそのまま訳してしまったミス。OPFのSpine項目への記述のことと思われる。「<spine page-progression-direction="rtl">」の記述で代替できるということか？

“9.3.11　Real Page Number の有効化”

　実ページ番号のサポート。教科書など教育関係の本で要望がずっとあったもので、iBooksなどではかなり前からサポートされていた（参考）。
　「出版者は、電子書籍のReal Page Numberをその電子書籍と最も一致度の高い印刷版(ハードカバー、ペーパーバックなど)にマッピングし、ISBNをhttp://kb.daisy.org/publishing/docs/navigation/pagelist.html#descに従いメタデータに指定する必要があります。」とあり、紙版の書籍と電子版の双方を刊行する前提の本で使うことを想定したものであることがわかる。米国などでのKindleの教育市場へのニーズを伺わせる機能追加。おそらくは電子教科書用だろう。
　なお、「サイドロードでプレビューできませんが、電子書籍が出版されると表示され、詳細ページにも記載されます。」とあり、残念ながら実際の挙動を確認することはできなかった。

“9.3.12　脚注のガイドライン”

　「脚注のマーキングには HTML5 の aside 要素を epub:type 属性と組み合わせて使用することを強くお勧めします。その場合、アクセス可能な端末では指示が追加されていない限り脚注を無視することができます。」とある。脚注を通常の画面内では非表示にし、リンクを叩いた際にだけ表示させるという意味かと思う。
　脚注のポップアップ表示にも対応したとのこと。なお脚注のポップアップ自体はiBooksや楽天KoboのiOS版、Microsoft Edge（同一xhtmlファイル内に脚注のジャンプ先がある場合のみ）では既に対応済み（参考）。Kindleでは専用端末のKindle PaperWhiteなどで脚注表示の挙動は見られたが、これはepub:type 属性を無視して相互リンクを脚注と見なす極めて不完全な対応だった（参考）。
　KindleがEPUBの脚注の正式な規格であるaside要素およびepub:type属性への対応を謳ったのは今回が初である。どう変わったのか挙動を見てみたのだが、現状Kindle FireおよびKindle PaperWhiteでポップアップの挙動は見られなかった。また、Kindle PaperWhiteではリンク自体が動作しないという挙動があり、これは早急に修正して欲しいところ。

“9.4.11　サポートされている SVG タグと要素を使用する”

　SVGの項目自体は以前からあったが、「タイプセッティングの改善」に関係する記述が追加されている。ここだけでなく影響はありそうなので注意が要りそうだ。

“9.5.2　シンプルな HTML の表を作る”

　ここにも「タイプセッティングの改善」に関する追加記述がある。

“9.6　MathML のサポート”

　数式のMathML表記をサポートしたとのこと。

“15.1　タイプセッティングの改善について”

　今回の更新内容の多くの項目が「タイプセッティングの改善」機能に絡むものだが、日本語はまだ対応言語に入っていないようなのでまだ考えなくてよい模様（15.5　
サポート対象の言語）。

“16　付録 B: タイプセッティングの改善でサポートされている属性とタグ”

　サポート対象のCSSプロパティ、HTMLタグが列挙されている。

“4.1 マーケティング用表紙画像は必須です”

Amazonの商品ページやアファリエイトリンクなどに表示される書影画像（マーケティングカバー画像）についての規定です。最低サイズ2700×1600px以上、解像度300ppi以上、サイズ5MB以下のJPEG画像が必要とあります。また、「価格やその他の一時的な販売促進の提供に言及する」表紙画像は使用できないとの文言があり、例えばオビに価格やキャンペーン情報を書いてあるケースに注意が必要そうです。

“4.2 内部コンテンツ表紙画像は必須です”

電子書籍の中に入れるカバー画像についての規定です。サイズに関してはここには特に指定はありません。なお、表紙画像のOPFでの指定方法に関しての記述がありますが、現状ではもう電書協ガイド準拠で大丈夫な模様です。過去には表紙画像が2回表示されたりしていました（Kindle側がEPUB3の標準的な記述に対応したために直ったと思われます）。

“5 ナビゲーションのガイドライン”

「すべての Kindle 本には、論理目次を含める必要があります」との記述があります。入っていないとリジェクトされる可能性があると捉えるべきでしょう。まあこれは電書協ガイドに最低限の論理目次は最初から入っていますので、それに沿ってデータを作っていれば問題はないです。

“5.1 HTML 目次のガイドライン”

コンテンツ内に通常のページとして表示される目次ページについての規定です。<table>タグを使ってのレイアウトはするな、元の本のページ番号は記述するなというような内容です。これはまあごく常識的と思います。

“5.2.1 toc nav 要素を使用して論理目次を作成する”

toc nav 要素を使用した論理目次の記述方法についてのガイダンスです。電書協ガイド含むEPUB3での一般的な論理目次はこのtoc navを使って作ることになっています。なお、リストのネストによる目次の階層表示のサンプルが載っていますが、これは以前チェックした時点では正常に表示できないRSが多数ありましたので、Kindle以外のストアでも販売することを前提としたEPUB3の中で使うのであれば、対象ストアのRSでの事前表示チェックは必要になるでしょう。

“5.2.2 NCX を使用して論理目次を作成する”

EPUB2の仕様であったNCX文書での論理目次の記述方法についてのガイダンスです。以前はKindleではこちらの方法で記述しないと論理目次が表示されませんでしたが、現在ではtoc nav 要素の記述だけで問題ありません。

“5.3 ガイド アイテム”

目次とは別に、コンテンツ内の論理的な構造を規定するためのガイドの記述方法です。Kindle内の目次（論理目次）に表示される「表紙」「目次」「最初のページ」などのリンクページ指定と思ってください。
今回新しく「読み始め開始位置は定義する必要なし」との記述が加わっています。また、以前にはあった読み始め開始位置の指定方法の項目が消えている模様です。おそらく以前にちょっと話題になっていたKindle Unlimitedでの読み始め開始位置を後ろに持って行き、読まれたとKindleに認識させることでKENPCを稼ぐ（アメリカでの）Kindle Unlimitedの悪質ハック対策としての対応でしょう。
つまり制作側での「最初のページ」指定の有無にかかわらず、販売時のAmazonサーバ側の処理で自動的に「最初のページ」の部分が決定されるようになったと思ってよいと思います。販売前に端末にサイドロードしてのチェックと表示結果が変わってくるケースもありそうですので、注意が必要です。

“6.3 スクリプトを避ける”

Javascript非対応。元ソースに含まれていても自動で削除されるとのこと。

“6.4 ファイル参照は、ソースのスペルと大文字と小文字の区別を一致させる”

大文字・小文字を区別するので注意との記述。ハマったことが一度あります。

“6.6 サポートされる文字とスペースの使用”

「サポートされているスペースは、通常のスペース、改行なしスペース (&nbsp;)、ゼロ幅の非結合子 (&zwnj;)です」という記述があります。英語コンテンツなどで使われることのある4分スペースなどは保証外なので注意が必要そうです。
また、「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください。」という一見意味のわからない記述があります。
直前に「文字を書き表すときは、プレーンテキストの UTF-8 の文字を使用します」との記述もあるわけなのですが、Unicodeは本来符号化文字集合の国際規格で、UTF-8はUnicodeをコンピュータで使うための符号化方式のひとつですので、文字通りに取ると使える文字がひとつもなくなります。誤訳を疑って原文も見てみたのですが、「Do NOT use Unicode format characters, as they may cause problems.」とあり、原文の時点で意味が通りません。
おそらくここで「Unicode」と呼んでいるのはWindowsのメモ帳などで保存する際に出てくる（MSの呼称としての）「Unicode」形式の話ではないかと思います。つまり実際に指しているのはUTF-16エンコーディング非対応ということでしょう。となるとEPUB3は仕様上UTF-16も文字コードとして認めているようなので、AmazonとしてはUTF-8のみを用いるということで話はわからなくもないです。ただ、これは技術仕様文書なので技術用語は正確に扱って欲しいです。ちょっとこれを思い出してしまいました。
（誤訳の模様。文末の注記参照。）

“6.7 電子書籍での読みやすさを重視する」を追加”

見出しの意味がちょっとわからないのですが（混入しているカギ括弧もママ）、原文は「6.7 Design for a Good eBook Experience」なので、まあ電子書籍制作の一般的注意として、原本のレイアウト再現にこだわりすぎるなという文言かと思います。レイアウトにこだわってフィックスで出すのではなくてリフローで出しましょう、と。

“7 外部リンクのガイドライン”

外部Webページへのリンクに関する規定です。「性的コンテンツへのリンク」「顧客情報の入力を要求する Web フォームへのリンク」「違法、有害、不正、不快なコンテンツへのリンク」はまあわかります。注意すべきは「Amazon 以外の電子書籍ストアへのリンク」でしょうか。これに引っかかるとリジェクトの対象になります。

“8.1 Kindle 本のテスト”

出版前の品質チェック方法に関しての記述です。まあ特に問題はないんですが、iOS版のKindleアプリでのチェックには.azk形式に変換してからiTunesで同期しないとダメ、みたいな話は書いておいて欲しいです。

“9.3.1 本文では必ずデフォルトを使用する”

リフロー型書籍の本文全体に対して文字サイズ（font-size）や行高（line-height）、文字色（color）は指定するなという規定です。部分的にはもちろんOKです。本文全体に対する地色（background-color）の指定もNG。まあこれはKindleに限らずダメですが。
要注意なのは、この規約に沿っていなかった場合、アップロード時にサーバ側で強制変換されるとの記述が追加されていることです。サイドロードしての表示チェックではOKだったものが、実際に販売されると内容が変わってしまう可能性があるため、注意が必要そうです。以下該当部分をそのまま引用します。

• コンテンツの大部分に使用されているフォントサイズは 1em に正規化されます。
• コンテンツの大部分に使用されている font-family はルートタグ (本文) に変更されます。
• 本文に使用されている強制フォントカラーが削除され、テキストの色を変更できるようになります。

“9.3.3 大半の要素に固定値を使用しない”

ピクセル数指定などの相対値で値を記述せよとの規定です。Webサイトと同じ感覚で電子書籍を作るとハマりかねない落とし穴ですので注意は必要ですが、一般的な話です。なお、「改ページを確実にするために、Kindle ソフトウェアでは 1.2 em または 120% 以下の line-height 値の使用はお勧めしません。」との記述があり、ここは注意が必要そうです。

“9.3.7 埋め込みフォントを使用する”

埋め込みフォントの使用規定です。対応形式としてOpenType (OTF) およびTrueType (TTF) の形式が挙げられています。ただ、埋め込みフォントに関しては以前にOTFを埋め込んで作成したコンテンツが、販売時にはサーバ側処理でフォントが削除されて表示されていなかったという経験があり、現在まだ調査中です。日本語フォントはTrueTypeのみという話なのかも知れません。その場合、EPUB3の仕様での標準Core Media TypeにTrueTypeは含まれていないとの話（参考）もあり、いろいろと問題が出てくる可能性が捨てきれません。
また、等幅フォントのサポートについての記述があります。<pre>、<code>、<samp>、<kbd>、<tt>、<font face="courier">、<font face="monospace">のタグで記述すれば等幅で表示するとのこと。コンピュータ技術書などでは必要になりそうです。

“9.3.10 脚注のガイドライン”

脚注の相互リンクが推奨から要件に変わっています。これは影響が大きそうです。電子書籍では確かに現状リンクを貼らないと注が参照しにくいのですが、全ての本での対応となると工数がかなり増えそうな点が心配です。また、Kindle専用端末での脚注ポップアップ仕様は以前にテストした際にはだいぶ不安定でしたので、ちゃんとepubの標準仕様に沿った形で仕様改訂して欲しいところです。

“9.4.1 サポートされている入力形式を使用する”

対応画像形式についての規定です。、「GIF、BMP、JPEG、不透過 PNG、SVG 画像」とあります。透過PNGに相変わらず非対応なのは残念ですが、SVGに対応を公式に謳っているのですね。
なお、注記に「画像ファイルのカラープロファイルには RGB を指定してください。 Kindle は sRGB と CMYK をサポートしていません。」との表記があります。「sRGBをサポートしない」という文言はだいぶ意味がわかりません。CMYKカラーモデル非サポートの話とRGBカラーモデル内規格であるsRGBの対応の話を併記されても困ります。RGB色空間に関する規格にはsRGBの他にAdobeRGBがありますが、これはカメラマンが撮影した画像をきっちりカラーキャリブレーションを取ったモニタ環境で色補正する際などに使うもので、この場合に出てくる話とも思えません。タブレットやスマートフォンなど一般的な機器向けのコンテンツなら画像のカラーは通常sRGBになるはず。
詳しい方に確認を取った感じでは「カラープロファイル指定に非対応なので付けられてもそのままパススルーで出力するよ」くらいの意味だろうという話なのですが、それであればそういう表記が欲しいところです。

“9.4.2 画像のサイズおよび品質の基準”

画像のサイズに関しての規定です。なおここはリフロー型電子書籍内の画像に関しての記述なので、hon.jpのこの記事は誤報です。通常写真集はフィックス型で作ると考えられますので。どうも元記事内に「写真集」という記述も見当たらないようで、どこから出てきたのか謎です。あとこれはそもそもKDPのガイドラインではなくて、KDP以外の出版社からのコンテンツにも影響が及ぶ「Amazon Kindle パブリッシング・ガイドライン」の改訂ですしね。元記事にはしっかり “Amazon Kindle Publishing Guidelines” の表記があります。
肝心の画像サイズに関しては、全ページに表示する場合で「300 ppi で 1200 x 1800 ピクセル以上」との記述があり、この数値自体にそう無理はないと思います。ただ、「9.4.5 写真は高解像度の端末用に最適化する」に「端末の画面いっぱいに表示する画像ならば、画像の幅を 3,200 ピクセル (最高解像度の端末である Kindle Fire HDX 8.9" の画面幅の 2 倍) にします。」との記述があり、これは相当な高解像度です。素直にこれに従って作ってしまいますと、Appleのガイドライン文書、iBooks Asset Guideの「画像のサイズは400万画素以下」という規約を簡単に超過し、iBookStoreでは販売できないEPUBが出来上がりそうです。注意が必要でしょう。上記の数値はあくまでAmazonの推奨に過ぎないので、現実的には現状では長辺2000px程度に止めた方が良いと思います。

“9.4.3 レスポンシブ レイアウトの画像サイズ”

「width スタイル属性でパーセンテージの値を使用して、ブロック画像とフロート画像をスタイル化することをお勧めします。 これにより、端末の解像度に関係なく、画像が画面の大きさに対して同じパーセンテージで表示されます。」との文言があります。こちらでテストした限りでは、現状まだKindle iOS版ではサイズの％指定が効きません。仕様として推奨するのであれば、RSの改訂もそれに準じて進めて欲しいところです。

“9.5.1 大きな表を避ける”

「表形式のコンテンツには、表を画像として表示するのではなく、HTML の <table> レイアウトを使用することをお勧めします」との文言があります。アクセシビリティの観点からテキスト検索できる形で表を挿入すべきという話はわかりますが、iOS版Kindleでセル幅の％指定が効かないという問題が現状ありますので、そこは直して欲しいところです。
また、「すべてのサイズの端末に最適となるように、表の大きさを 100 行 x10 列以内にすることをお勧めします。」との文言もあるのですが、元データにある列の数を勝手に弄れるなら苦労はありません。

“9.5.3 必要に応じて表を分割する”

画像としての表を分割する場合のガイドラインです。ヘッダを両方の表につけるようにという記述があります。ちょっと手間はかかりそうです。

“9.5.4 タイプセッティングの改善による表機能”

これはKindle専用端末のアップデート 5.8.2で追加された「タイプセッティングの改善」機能に準じてのテーブル作成ガイドライン文書のようです。<thead><tbody><tfoot>タグで論理構造をしっかり書くようにとの記述があります。この機能はまだちゃんと試していないのですが、iBooksでのテーブル組みの表ポップアップ表示的な機能かと思います。