Kindle出版の目次とは？論理目次の作り方と確認方法を徹底解説

Kindle出版を進めていると、多くの人が最初につまずくのが「目次がうまく機能しない」という問題です。

KDPに原稿をアップして動作確認すると、「目次から章に飛べない」「端末の目次欄に表示されない」などのトラブルが発生しやすいです。

この原因の多くは、論理目次（Navigation TOC）を正しく作れていないことにあります。

本記事では、初心者の方でも混乱しないように「論理目次とは何か」「なぜ必要なのか」「どうやって作ればよいのか」を、実体験も交えながら丁寧に解説します。

 

【結論】Kindle出版の目次は「論理目次」が必須（Amazon.co.jp前提）

 

論理目次とは、読者がKindle端末の「目次」メニューから章へワンタップで移動できる機能です。

KDPで販売する電子書籍では、この論理目次が設定されていないと、読者が途中で迷いやすくなり、使いづらい本として低評価につながることがあります。

特に初めて出版する方は、「本文の冒頭に自分で作った目次があれば大丈夫」と勘違いしがちです。

しかし、KDPが求めている目次は「論理目次」であり、HTMLで作られた自作の目次だけでは不足する場合があります。

 

検索意図の要点：Kindle出版＋目次で「タップで章に飛べる状態」を作る

 

「Kindle出版　目次」と検索する人の多くは、すでに原稿を整え始めており、「見出しは用意してあるけれど、KDPでどう扱われるのか不安」という段階にいます。

また、「KDPのプレビュー画面で目次が表示されない」「Amazonの端末で章に飛べない」といった経験をした人が、対処法を探すケースも少なくありません。

そのため、検索者が本当に知りたいのは「論理目次の正しい作り方」と「ジャンプできるかどうかの確認方法」です。

 

本記事でわかること：論理目次とHTML目次の作り方・確認・エラー対処

 

この記事では、以下の内容をわかりやすく整理します。

・論理目次とHTML目次の違い
・WordやGoogleドキュメントでの目次生成の基本
・Kindle Createを使う場合の注意点
・KDPプレビューで確認すべきポイント
・目次が反映されないときのよくある原因と修正方法

あくまで日本向け（Amazon.co.jp）での出版を前提とし、不確かな仕様については「公式ヘルプ要確認」と明示します。

この章を読んだ段階で、あなたは「何を目指すべき目次なのか」を明確に理解できるようになります。

 

Kindle出版の「論理目次」と「HTML目次」とは？違い・役割・表示場所

 

Kindle出版では「目次」とひとことで言っても、実際には2種類の目次が存在します。

それが「論理目次（ナビゲーション目次）」と「HTML目次（本文内目次）」です。

この2つを混同したまま制作を進めると、「プレビューでは目次が出ない」「章に飛べない」というトラブルにつながります。

私自身、初めて出版したときにHTML目次だけを作った結果、論理目次が認識されず慌てて修正した経験があります。

そのため、この段階で違いをきちんと理解しておくことが重要です。

 

論理目次（ナビゲーション／端末メニュー）とは：読者がどこからでも章移動できる目次

 

論理目次とは、Kindle端末やアプリの「目次」ボタンから表示される、章構造のことを指します。

読者は端末やアプリのメニューから「目次」を開き、章一覧にアクセスできます。端末ごとに表示位置は異なります。

ここに章タイトルが一覧表示されていると、どこからでも読みたい章にジャンプできます。

いわば、電子書籍としての操作性を支える「公式な章ナビゲーション」と言えます。

この論理目次は、WordやGoogleドキュメントで見出しスタイルを正しく設定した上で、KDPにアップロードすることで自動的に生成されるケースが多いです。

ただし、見出し設定が不適切だった場合や、EPUB化の段階で崩れた場合は正しく認識されないことがあります。

この点はKDP公式でも明示されていますが、実務上は「章ごとの見出し階層の整合性」が崩れているケースがよく見られます。

 

HTML目次（本文冒頭の目次）とは：章見出しへのハイパーリンク一覧

 

HTML目次とは、本文の冒頭に配置される、章タイトルとリンクを一覧にした部分のことです。

「はじめに」「第1章」「第2章」などのリンクをタップすると、本文内の該当箇所に飛べるように設定します。

このHTML目次は、あくまで「本文の一部」として存在しており、必須ではない場合もあります。

しかし、実用書や長めのコンテンツでは、読者が本の構造を一覧できるため、配置しておくほうが親切です。

編集経験上、実用系ジャンルではHTML目次がないと「内容がつかみにくい」と感じる読者も一定数いると実感しています。

 

両方を用意すべき理由：読者体験・要件・レビュー低下の回避

 

論理目次とHTML目次は用途が異なるため、それぞれ補完し合う関係にあります。

論理目次は「読者がどのページからでも呼び出せる公式のナビゲーション」であり、KDPの品質ガイドライン上でも推奨されています。

一方でHTML目次は「読者が冒頭で内容構成を把握するための案内板」のような存在です。

どちらか一方だけでは、読者の操作性や理解しやすさが不足する可能性があります。

また、論理目次が存在しない場合、読者が途中で不便を感じてレビュー評価が下がるリスクもあります。

特に実務経験上、「目次が使いづらい」といったレビューは意外と目立ちやすく、一度低評価が付くと修正しても巻き返しが難しくなります。

そのため、最初から2種類の目次を正しく整備しておくことが安全であり、読者からの信頼にもつながります。

 

このように、論理目次とHTML目次には役割の違いがあるため、両方を意図的に使い分ける意識が大切です。

次の章では、それぞれを「どう作るか」を具体的に説明していきます。

 

【作り方】論理目次の基本手順（Word／Googleドキュメント／Kindle Create）

 

論理目次を正しく生成するには、各ツールに応じた操作を行う必要があります。

とはいえ、実はその前に必ず押さえておくべき共通ポイントがあります。

まずは基礎である「見出しの構造化」をしっかり整えてから、各ツールで目次を作っていく流れになります。

私が初めて出版したときも、この基礎を軽視したことで論理目次がうまく出ず、すべての見出しを修正し直す羽目になりました。

 

共通準備：見出し階層（見出し1→2→3）を正しく設定する

 

論理目次は「見出しスタイル」をもとに自動生成されます。

そのため、章には「見出し1」、節には「見出し2」、小節には「見出し3」のように一貫した階層構造を設定します。

文字サイズや太字加工だけでは、論理目次が認識されません。

「装飾＝見出し」ではなく「スタイルとしての見出し」を設定することがポイントです。

見出しスタイルを設定することで、後の自動目次生成やEPUB変換時にも正しく認識されやすくなります。

この段階での整備を怠ると、後からKDPで目次が出ない原因になります。

 

Wordでの手順：自動目次→ハイパーリンク→フィールド更新→保存形式の注意

 

Wordでは以下の流れで論理目次につながる構造を作ります。

1．見出し1〜3のスタイルを設定
2．「参考資料」タブ →「目次」→「自動作成の目次」を挿入
3．必要があれば各章タイトルを簡素化・確認
4．目次の上で右クリックし「フィールドの更新」

論理目次はこの見出し構造から自動生成されるため、必ず更新して最新状態に保つことが重要です。

保存形式は「docx」のままでも読み込まれる場合がありますが、場合によっては「フィールド崩れ」が発生することもあります。

Kindle Previewerでプレビューし、リンクが正しく機能するか確認してください。変換手順や対応形式は<公式ヘルプ要確認>です。

Wordの場合、「目次は作れたがKDPでは反映されない」というケースがあるため、プレビュー確認は必須です。

 

Googleドキュメントでの手順：段落スタイル→目次挿入→EPUB出力時の留意点

 

Googleドキュメントを使う場合も、見出しスタイルの設定が基本となります。

1．「段落スタイル」から見出し1〜3を適用
2．本文冒頭にカーソルを置き、「挿入」→「目次」→「リンク付き」を選択
3．章タイトルが反映されているか確認
4．ダウンロード形式は「.docx」か「.epub」を選択

GoogleドキュメントのEPUB出力でも見出し設定が適切なら認識されますが、出力結果は個別検証が必要です。挙動差は端末・版によるため<公式ヘルプ要確認>。

そのため、KDPプレビューでリンクジャンプが問題なく機能するかは必ずチェックしてください。

実務上、「Google Docs→EPUB→KDP」という流れだと、節（見出し2以下）が飛ばされるケースもあります。

公式では「見出しスタイルを適切に使えば認識される」とされていますが、実際は念入りな確認が必要です。

 

Kindle Createの活用：章認識・目次生成・対応範囲（最新仕様は公式ヘルプ要確認）

 

Kindle Createを使うと、章ごとの構造を自動的に検出し、目次を生成できます。

WordやGoogleドキュメントで見出し1を章として設定していれば、Kindle Createが「章」として認識しやすくなります。

目次は「目次」パネルで自動生成され、章タイトル一覧として表示されます。

ただし、最新の対応言語や認識範囲には変動があるため、必ず公式ヘルプで確認してください。

実務経験では、「短文の章タイトル」「記号が多い見出し」などは認識されない例もあります。

Kindle Createで確認できる論理目次がそのままKDP側に反映されることが多いですが、最終判断はKDPプレビューで行うのが安全です。

 

このように、論理目次の生成手順はツールによって多少異なりますが、共通するのは「見出し設定を正しく行い、プレビュー確認を徹底する」ということです。

次の章では、KDPプレビューでのチェックポイントについて解説します。

 

【確認】KDPプレビューでのチェックリスト（反映・ジャンプ・階層）

 

論理目次を作成したら、必ずKDPプレビューで動作確認を行います。

作成直後は「ちゃんとできたはず」と思い込みがちですが、実際にプレビューすると想定どおりに動いていないことも珍しくありません。

私自身、見出し設定を誤って一部の章だけ論理目次に表示されなかったことがあり、アップロード後に気づいて修正に時間を取られました。

ここでは、最低限確認しておきたい3つのポイントを紹介します。

 

端末の「移動」メニューに論理目次が表示されるかを確認

 

まず、KDPプレビュー内の「目次」または「移動」ボタンを開いて、論理目次が表示されているか確認します。

ここに章タイトルが並んでいれば、見出し1などが正しく認識されている証拠です。

もし何も表示されない場合、見出しスタイルが未設定、または階層が誤っている可能性が高いです。

「目次が空白」「一部しか出ない」という場合は、見出し構造の再確認が必要です。

KDPでは論理目次の整備が推奨されています。必須要件の扱いは<公式ヘルプ要確認>とし、最新仕様を参照してください。

実務経験上、見落とされやすいポイントです。

 

各章にワンタップでジャンプし、前後移動が正しく動くか

 

論理目次が表示されていたとしても、それが正しくリンクされているとは限りません。

各章タイトルをタップして、本文の該当位置に飛ぶかどうかを必ず確認します。

章途中に飛んでしまう、または反応しない場合は、見出し位置やスタイルの設定にずれがある可能性があります。

さらに、プレビュー内で「前へ」「次へ」などの移動ボタンが章単位で機能するか確認しましょう。

私の経験では、章タイトルの前に不要な改行や空白があると、章の始まり位置がずれ、読みづらくなることもありました。

この確認は電子書籍の読みやすさに直結します。

 

目次階層の表示（部／章／節）が意図どおりか

 

論理目次が正しく動いていても、階層が崩れていると読者にとってわかりづらくなります。

「大見出し（見出し1）」「中見出し（見出し2）」「小見出し（見出し3）」が意図した通りの階層で表示されているか確認してください。

特に、見出し1だけが並んでいて構造が整理されていない場合、内容が整理されていない印象を与えることがあります。

論理目次は「読者が本の流れを理解するための地図」なので、階層は見やすさを左右します。

もし階層が崩れている場合は、原稿の見出しスタイルを修正し、再度KDPプレビューで確認しましょう。

 

これらの確認を行うことで、目次の精度が大きく向上し、読者がストレスなく章移動できるようになります。

次の章では、目次が反映されない・うまくジャンプできない場合のトラブルと解決法について解説します。

 

【トラブル解決】「目次が反映されない・飛べない」原因と直し方

 

論理目次を作ったつもりでも、KDPプレビューで「目次が空」「章に飛べない」という状況になることはよくあります。

私自身も、初期の頃は見出しスタイルを装飾だけで済ませてしまい、論理目次が一切表示されなかった経験があります。

ここでは、特によくある原因とその解決方法を順番に整理していきます。

 

見出しスタイル未設定・独自装飾のみ：正しい見出しに置き換える

 

もっとも多い原因が「太字・行間調整などの装飾だけで見出しと判断している」ケースです。

論理目次は「見出し1」などのスタイルが正しく設定されていないと認識されません。

したがって、装飾のみのタイトルに対しては、対象箇所を選択して「見出し1」または「見出し2」に変更してください。

見出しスタイルを使っていなければ、論理目次は生成されません。

この修正を行ったうえで、目次の更新またはファイル再出力を行うと反映されやすくなります。

 

リンク切れ・手入力目次：自動生成に変更し、リンクを再作成

 

手打ちで「第1章」などを入力し、「リンクを貼ったつもり」になっているケースも要注意です。

リンクが章タイトルと正しく紐づいていないと、ジャンプできなかったり章途中に飛んだりします。

この場合は、WordやGoogleドキュメントの自動目次機能を使ってHTML目次を再生成しましょう。

特に章タイトルを変更したあとにリンクを更新していない場合、古いリンクに飛んでしまうことがあります。

KDP側に任せられる構造に戻すことが、安定動作への近道です。

 

階層の不整合：見出し1の不足／過剰・順序崩れを修正

 

見出しレベルがバラバラだと、論理目次で階層が崩れる・一部章が無視されることがあります。

たとえば、突然見出し2から始まっている、見出し1が途中で消える、などはありがちな落とし穴です。

章の構造を整理し、「見出し1→見出し2→見出し3」の順序を守りましょう。

階層が乱れているとKDP側で論理的に解釈できなくなり、目次が飛ばされる可能性があります。

再度プレビューで階層表示をチェックすることが大切です。

 

ファイル変換時の不具合：書き出し形式・再アップロードで再生成

 

WordからEPUBへ変換する際にリンクが外れたり、GoogleドキュメントでEPUBに変換したときに階層が崩れたりすることがあります。

また、Kindle Createで自動生成したはずの章認識が、KDPアップロード後にずれる場合もあります。

この場合は、再度ファイル形式を見直し、「docx」「EPUB」など別形式で書き出し直す方法も有効です。

実務では、「一度Kindle Createで開いて再保存すると直る」というケースも経験しています。

余計な変換ミスを避けるためにも、アップロード前に端末プレビューで確認する癖をつけましょう。

 

仕様不明点は「公式ヘルプ要確認」で最新ルールを参照

 

KDPの仕様はアップデートされることがあり、以前は反映されていた方法が急に認識されなくなることもゼロではありません。

最新の推奨形式や変換ルールについては、Amazon公式ヘルプを確認することが安全です。

特に「目次の要件」「対応フォーマット」「サポート対象の変換方法」などは随時見直される可能性があります。

不安がある場合は、KDPの「ヘルプ・カスタマーサポート」や公式フォーラムで情報を収集することをおすすめします。

 

ここまでの内容を踏まえれば、多くの目次トラブルは原因別に修正できます。

次の章では、HTML目次の作り方や配置の工夫について解説します。

 

HTML目次（本文内）の作り方とコツ：読者が迷わない配置・文言・リンク設計

 

HTML目次は、論理目次とは異なり「本文の一部」として読者の理解を助ける役割を持っています。

特に実用書や長めの構成の電子書籍では、「この本にはどんな内容があるのか？」を冒頭で把握できることが、読み始める際の安心感につながります。

一方で、適当な位置に長すぎる目次を挿入してしまうと、かえって読者の離脱を招くこともあります。

ここからは、HTML目次を配置する位置や文言の調整、長編を意識した工夫について解説します。

 

目次の置き場所：表紙後／はじめにの後に簡潔な目次を配置

 

HTML目次を入れる場所は「表紙の直後」または「はじめに」の直後が一般的です。

多くのKindle書籍では、以下の流れが読みやすい構成とされています。

・表紙
・（奥付・著者情報がある場合）
・目次
・はじめに（または序文）

この順番にしておくと、読者は内容を把握した上で序文や導入に入りやすくなります。

ただし、ストーリー形式の小説や短編連作の場合、冒頭に目次を入れるとかえって読書体験を損ねることもあります。

そのような場合は、巻末に目次を配置するケースもありますが、その判断は本のジャンルによって変わります。

実務経験から言うと、実用書系・ビジネス書系は冒頭に目次があるほうがスムーズです。

 

リンク文言の最適化：章タイトルは短く具体的に、重複語を避ける

 

HTML目次は「読みやすさ」と「クリックしやすさ」を意識して文言を整えることが重要です。

章タイトルが長すぎると、Kindle端末の表示領域で折り返され、視認性が落ちます。

また、「第1章：第1章〇〇とは？〜〜の基本」のように重複語が多いと読みにくくなります。

目次の文言は「短く」「先頭で内容がわかる」ようにするのがポイントです。

例：
× 第1章：初心者でもできるKindle出版で収益を得るための基本ステップとは？
◎ 第1章：Kindle出版の基本ステップ

さらに、節レベル（見出し2）を目次に含める場合は、本の長さによって取捨選択が必要です。

節まで入れると長くなりすぎる場合は、章タイトルのみで構成し、章内リンクは論理目次に任せるのも有効です。

 

長編・実用書の工夫：章内アンカー・戻るリンクの最小実装

 

長編の実用系コンテンツでは、章が長くなると読者が途中で「どこにいるか」を見失いやすくなります。

このような場合、章の冒頭に「この章の要点」や小目次（見出し2・3の一覧）を配置する方法があります。

また、章末に「目次に戻る」リンクを入れることで、読者がワンタップで冒頭に戻れます。

ただし、戻るリンクを多用すると視覚的なノイズになるため、節が多い長章など必要な箇所だけに限定するのがおすすめです。

個人的な経験としては、技術解説系や用語系の電子書籍では、小節ごとに戻るリンクがあると親切だと感じました。

一方、小説や体験記などでは不要なケースがほとんどです。

ジャンルや読者層に応じて適度な実装を検討しましょう。

 

HTML目次は「読み始めのストレスを減らし、本の構造を理解しやすくする」ための存在です。

次の章では、実例を交えながら、よくあるミスと改善例を紹介します。

 

事例で学ぶ：よくある失敗パターンと修正例（Kindle出版＋目次）

 

具体的な失敗例を知っておくことで、「自分の原稿のどこを見直すべきか」が明確になります。

私がこれまでにサポートしてきた著者の方々からも、「目次があるのに反映されない」「読みにくいと言われた」といった相談は繰り返し寄せられました。

ここでは、代表的な3つのパターンと修正方法を紹介します。

 

目次だけ本文にあるが端末メニューに出ない→論理目次未生成の改善

 

よくあるケースが「本文の冒頭に目次を作っているものの、Kindle端末のメニューでは表示されない」というパターンです。

この場合、原因はほぼ確実に「論理目次が生成されていない」「見出しスタイルが使われていない」のどちらかです。

HTML目次だけ作って安心してしまうと、KDP側が章構造を認識できず、結果的に読者が端末メニューから移動できなくなります。

改善するには、見出しスタイル（見出し1・見出し2など）を正しく設定し直し、論理目次が自動生成される状態に戻す必要があります。

「本文に目次がある＝論理目次もある」ではないことを理解しておくことが大切です。

 

章が並ぶだけで階層がない→見出し1／2の再設計で階層表示を回復

 

次によくあるのが「すべての見出しを見出し1にしてしまい、階層が平坦になっている」というパターンです。

この状態だと、論理目次には章がすべて同列で並び、部や節といった構造がまったく伝わりません。

読者は「どこが大きな章で、どこがその中の項目なのか」を理解できなくなります。

修正するには、内容のまとまりを考慮し、章には見出し1、節には見出し2、小節には見出し3を適用し直します。

構造が整理されることで、論理目次の表示も自然な階層になります。

また、Kindle端末でも章ごとの流れが把握しやすくなり、読みやすさが格段に向上します。

 

長い章タイトルで折り返す→短文化と先頭キーワードで可読性を改善

 

章タイトルが長すぎると、論理目次やHTML目次で折り返しが発生し、視認性が悪くなります。

特に、スマホ読みが中心の読者にとっては、冒頭数語で内容が把握できないタイトルはストレスにつながります。

たとえば「Kindle出版をまったくやったことがない初心者が最初に理解するべき超基本ステップ」といった長文タイトルは避けましょう。

ポイントは「章タイトルの先頭にキーワードを置き、簡潔にまとめる」ことです。

例：
× Chapter 1：Kindle出版を始める前に知っておくべき初心者向けの原稿準備ステップについての解説
◎ 第1章：Kindle出版の原稿準備

このように整理することで、論理目次でも一覧しやすくなり、読者の理解も深まります。

 

代表的なトラブルと修正例を押さえておくことで、自分の原稿の改善ポイントにも気づきやすくなります。

次の章では、ペーパーバックにおける目次の扱いについて簡単に触れておきます。

 

【補足最小】ペーパーバックの目次：ページ番号付き目次の作法と注意

 

Kindle出版を電子書籍として行う場合は「論理目次」と「HTML目次」が中心になりますが、ペーパーバック（紙版）を同時に出版する場合は、目次の扱いが異なります。

ここでは、電子出版を主軸としながら、紙版を出す予定がある方のために最小限のポイントのみを補足します。

 

紙はページ番号中心。電子とは要件が異なる（詳細は公式要確認）

 

ペーパーバックでは、読者は「ページ番号」を基準に読み進めます。

そのため、目次は「ページ番号付き」で作成することが一般的です。

電子書籍のようにタップで章に飛ぶ仕組みはないため、「章タイトル」と「ページ番号」を明確に記載する必要があります。

たとえば以下のような形式になります。

例）
第１章　Kindle出版の流れ …… ５
第２章　目次の作り方 …… １５

また、KDPのペーパーバックでは、最低ページ数（24ページ以上）が存在し、目次の有無が構成全体の可読性に大きく影響します。

私の経験では、電子版では問題なくても、紙版で「ページ番号がずれている」「章の位置が曖昧」といった理由で修正を求められるケースもありました。

電子と紙版の目次は同一データで自動的に流用されるわけではなく、別途ページ番号を確認する必要があります。

さらに、ペーパーバックではページレイアウトの崩れや空白ページへの章タイトル配置などが問題になることがあるため、KDP公式ヘルプでレイアウトルールを確認しておくと安心です。

ハードカバーの対応状況は地域や時期で変わるため、現時点の取扱いは<公式ヘルプ要確認>としてください。

 

電子と紙を両方制作する場合は、「電子版用（論理目次＋HTML目次）」「紙版用（ページ番号付き目次）」というように、それぞれの仕様に合わせた調整を行うことが大切です。

次の章では、ここまでの内容をまとめとして整理していきます。

 

まとめ：論理目次を整備し、KDPプレビューで最終確認する

 

ここまで解説してきたとおり、Kindle出版で目次を正しく機能させるためには「論理目次の構造を整えること」が最重要ポイントです。

さらに、読者の理解と利便性を考えるなら、HTML目次も適切に設置しておくと安心です。

私自身も、初期の頃に「目次の作り込み」が甘く、レビューで「どこに何が書いてあるかわかりづらい」と指摘された経験があります。

その反省から、以降は「論理目次＋HTML目次」の両軸で構成するようにし、読者満足度が明らかに変わりました。

 

「論理目次＋HTML目次」の両立が最短ルート

 

論理目次は、Kindle端末やアプリの「目次メニュー」から呼び出せるナビゲーション機能であり、読者がどこからでも章に移動できる重要な要素です。

HTML目次は本文冒頭で構成を視覚的に整理し、読み始めの不安を和らげてくれます。

どちらか一方ではなく、両方を整えることで「電子書籍として読まれる本」の完成度が高まります。

また、HTML目次があることで、章タイトルの長さや構造の見直しにも気づきやすくなります。

電子書籍の品質を高める上で、論理目次とHTML目次はセットで考えるのがベストです。

 

最終チェックは「表示・ジャンプ・階層」の三点

 

目次の整備が済んだら、KDPプレビューで以下の3点を確認します。

1．論理目次が「移動」メニューに表示されているか
2．章タイトルをタップして正しくジャンプできるか
3．階層構造（見出し1→2→3）が崩れていないか

この「表示・ジャンプ・階層」を満たしていれば、読者が迷わない目次になっていると判断できます。

KDPの仕様は今後もアップデートされる可能性があるため、不安がある場合は公式ヘルプも確認しておきましょう。

特に初出版ではプレビュー確認を軽視しがちですが、ここを丁寧に行うかどうかで、完成度は大きく変わります。

 

目次がしっかり整ったKindle本は、それだけで読みやすく、信頼感のある作品になります。

読者がスムーズに章へ移動できる構造を整えることは、「伝えたい内容をきちんと届ける」ための第一歩です。

引き続き、次のステップとして本文デザインや読者導線の見直しも行うことで、さらに完成度の高い出版につながります。