株式会社ブレストストロークWebサイト

いろいろと「電子書籍をつくる方法」について説明してきましたが、「個人的には」という注釈つきで、おすすめするのがsigilです。
専用ソフトという安心感もありますが、ワープロ風の画面で入力・編集ができるというのは安心感がありますし、クリックひとつでソース表示になるので、中身を確認しながら修正できるというのも重要です。この「どちらもできる」というのがポイントです。ちゃんとした電子書籍をつくるには、どうしても中身（ソースコード）をいじらなければなりませんし。
前にも書いた通り、sigilは英語版です。ダウンロードページも英語です。これが最初の関門ですが、極端に難しい英語でもないので、ほとんどの人がダウンロードはできるんじゃないかと思います。
sigilのページで、[Doenloads]をクリック→「Sigil-0.7.2-Windows-Setup」または「Sigil-0.7.2-Mac-Package.dmg 」をクリックするだけですし。
メニューに関しても、最初は英語ですが、設定で日本語表示に変更できます。すべてのメニューが日本語化されているわけではありませんが。
ヘルプや説明書のたぐいもすべて英語ですが、これはsigilの解説ページがインターネットにたくさんあるので、検索すれば大きな問題にはならないと思います。少なくとも、基本的な使い方については、問題ありません。さすがに「索引のつくりかた」まで書いてあるページはないみたいですが……。
それよりもなによりも、sigilの一番のウィークポイントが「EPUB 2形式のファイルになる」という点でしょう。
これは、デメリットではあるのですが、使い方によってはメリットになります。
電子書籍をつくろうと思っている人にとって、AmazonのKindleは大きな存在です。実際、KDPで電子書籍を売りたいと考えている人が大半でしょう。
このKicdleのファイル、実はEPUB 2をベースにしているのです。つまり、sigilでつくったEPUBファイルは、KDPと相性がいいわけです。相性がよければ、無用なトラブルを回避することができます（目次とか、いろいろとトラブルの種があるのです）。
このKDPとの親和性は、sigil最大のメリットといえるかもしれません。

EPUB 2であることの、もうひとつの懸念が「日本語はどうなるのか？」という問題です。
前にも触れましたが、EPUBの規格が「EPUB 2」から「EPUB 3」になって、日本語の縦書きやルビなどに対応しました。これを受けて、日本でも電子書籍が普及し始めたという側面があるのです。解説書のたぐいも、「EPUB 3」のものが大半です。
こうした話を聞くと、「EPUB 2では日本語が使えない」と思い込んでしまうかもしれません。しかし、そんなことはないのです。EPUB 2でもちゃんと日本語は使えます。
EPUB 3は、EPUB 2の上位互換です。つまり、EPUB 3に対応したビュアーアプリ・端末なら、EPUB 2のファイルも表示できるのです。つまり、EPUB 2ファイルの中に、EPUB 3の命令が入ってても、実行できてしまう……と、そんな理由なんだと思います。
そういったわけで、EPUB 2のファイルの中に、本来EPUB 3から採用された「日本語の縦書き」もできてしまうのです（おそらく）。
実際、sigilで作成したEPUB 2形式のファイルでも、きちんと縦書きで表示できています。

英語のアプリを使ったことのない人にとって、sigilは少し、敷居が高いかもしれません。しかし、それに慣れていくことで、EPUBの中身に関する知識も自然と身についていきます。
将来的には、「EPUBの中身なんてまったく知らないけど、電子書籍がつくれる」のが理想ではあるのですが、まだまだそこまで到達するには、時間がかかりそうです。
それならば、少し努力は必要ですが、sigilで電子書籍をつくるのが、現時点でのベスト……そう思っています。

EPUBファイルをつくる手段が決まったら、さぁ電子書籍をつくりはじめましょう……といきたいところですが。確かに、EPUBファイル作成ツールがあれば、電子書籍はつくれないわけではないのですけど、それ以外にも「あった方がいいツール」があるので、まとめて紹介しておきましょう。

●テキストエディタ
テキストエディタと書きましたが、使い慣れているならワープロでもかまいません。要は文章を入力するための道具です。自分が気持ちよく入力できればそれでいいので、テキストエディタでもワープロでもかまわないわけですが、電子書籍の制作作業をすすめていく上で、テキスト形式であるほうがなにかと便利なので、テキストエディタをおすすめしておきます（これは、電子書籍に限らず、パソコンでの作業全般にいえることですが）。

●画像処理アプリ
Photoshopに代表される、画像ファイルをつくったり加工したりするためのアプリです。
電子書籍には、表紙が必要です。その表紙をつくるために、画像処理ソフトが必要になります。
ようは、JPEGファイルがつくれればいいので、そんなに高級なアプリは必要ありません。OSに付属しているものでもＯＫ。

●素材サイト
表紙などに写真を使いたいのなら、その元となる素材が必要です。
用意できるなら、自分で用意するのがベストです。が、すべて自分で用意できるものでもないでしょう。
インターネットで、画像検索をすれば、すぐにイメージ通りのものは出てくるでしょうが、それをあなたが使っていいのかどうかというのは、また別問題。いうまでもなく、著作権の問題です。
そのためにも、自分が使ってよい素材のあるサイトを確保しておくのは、大きなポイントといえるでしょう。詳しくはまたあとで。

●EPUBブラウザ
できあがったEPUBファイルを読むためには、専用のアプリが必要です。「Readium」のようなインターネットブラウザのプラグインになっているものや、「Adobe Digital Editions」のような単体のアプリがあります。
正直な話、パソコンでEPUBを読む環境は、まだ整っていません。できたEPUBファイルをチェックするためには必須の道具のハズなのですが……。
じゃあどうやってチェックしているかというと、おそらく次の「Kindle Previewer」を使っている人が多いんじゃないでしょうか。

●Kindle Previewer
Kindle Previewerは、パソコン上で「Kindleでの見え方」をチェックするためのツールです。EPUBファイルを指定すると、kindle用のmobi形式ファイルに変換してくれます。そのままプレビュー画面でも読めますし、できたmobiファイルをほかの端末にコピーして、その端末のKindleで読むこともできます。
Kindleでの販売を検討している人には、必須アプリです。

●端末
パソコンで電子書籍を読む人がいないわけではありませんが、やはり主戦場はスマホやタブレットなどの端末です。AmazonのKindle Paperwhite、楽天koboのkobo touchなど専用端末でもＯＫです。
もし、電子書籍の販売を考えているのならば、こうした端末で実際の見え方をチェックするというのは、とても大事な工程です。

●EpubCheck
EpubCheckは、その名の通りEPUBファイルの中身についてチェックするためのツールです。
EpubCheckそのものは、使い方が難しいので、http://validator.idpf.org/ を使うといいでしょう。
自分の端末ではちゃんと表示できているようでも、ほかの端末だとうまく表示されない……なんてことも考えられます。そんなことのないように、EpubCheckで中身を確認するというクセをつけましょう。

ちなみに、私が使っているのは、次のようなツールです。
・テキストエディタ：Mery http://www.haijin-boys.com/wiki/
・画像処理アプリ：Corel Paint Shop Pro Photo XI、Adebe InDesign CS5
・端末：Nexus 7、HTC J Butterfly、iPhone4（キャリア解約済）、Kindle Paperwhite
特殊なのは、InDesignでしょう。これは、私が使い慣れているアプリだから、という理由です。Illustratorもあるにはあるんですけれども、慣れてないのでイラつくんですよね。
なので、私の場合は、表紙などをつくるときに、InDesignを使っています。
「InDesignがおすすめ」というわけではなく、「使い慣れたアプリがあれば、それを使ってもいい」というサンプルだと思ってください。

「EPUBファイル」というと、なにか特別なもののように見えますが、実際の中身は、誰でも扱えるフツーのファイルです。
本文にあたるHTMLファイル、画像ファイル、スタイルシート（CSSファイル）、各種設定ファイルなどです。画像ファイル以外はテキストファイルなので、メモ帳でも見ることができます（ま、実際にはやらないでしょうけど）。
それらのファイルは、指定されたフォルダに分けておきます。そうしたフォルダやファイルをZIPでひとつにまとめて、拡張子を.epubに変更したものが、「epubファイル」なのです。
で、その問題なのはその中身です。単に「EPUBファイル」といっても、EPUB 2とEPUB 3では、かなり中身が違ってきます。フォルダはほぼ一緒なのですが、中に入れるファイルの形式が、微妙に異なっているのです（画像ファイルは一緒ですが）。
細かく書きはじめるとキリが無いですし、わかりにくいので、簡単に要点だけまとめます。

●EPUB 2フォルダ構造
・「Text」フォルダ…本文のHTMLファイルを収納
・「Style」フォルダ…スタイルシート（CSSファイル）を収納
・「Image」フォルダ…画像（JPEG）ファイルを収納
・content.opf…書籍の情報について書いてある設定ファイル
・toc.ncx…目次（ナビゲーション）ファイル

●EPUB 3フォルダ構造
・「Text」フォルダ…本文のHTMLファイル、および目次と表紙を収納
・「Style」フォルダ…スタイルシート（CSSファイル）を収納
・「Image」フォルダ…画像（JPEG）ファイルを収納
・content.opf…書籍の情報について書いてある設定ファイル
・toc.xhtml…目次（ナビゲーション）ファイル

●EPUB 2のファイル形式
・HTML…XHTML 1.1
・スタイルシート…CSS 2

●EPUB 3のファイル形式
・HTML…XHTML 5
・スタイルシート…CSS 3

上の「フォルダ構造」では、opf（設定）ファイルや目次ファイルは、フォルダの外（ルート）として書いていますが、拡張子さえ合っていれば、どこに配置しても問題無さそうです。
というのも、ここには書いてないのですが、EPUBには「container.xml」というファイルが必ずあり、そこでopfファイルを指定し、そのopfファイル中で目次ファイルなどを指定することになるからです。実際には、自分なりのルールを最初に決めておいた方がいいでしょう。

まず、フォルダ構造からみていきましょう。「Text」などのフォルダに、それぞれのコンテンツが収納されるのは一緒ですが、違うのは目次ファイルです。EPUB 2がncxファイルであるのに対し、EPUB 3ではxhtmlファイルになっています。
ファイル形式が変更になっただけ……のように見えますが、実はこれが大きなトラップになっているのです。これについてはのちほどじっくりと。
ファイル形式は、EPUB 2からEPUB 3に改定するにあたり、「使うファイル形式も新しいものにした」と理解しればよいと思います。XHTMLがHTML5に、CSS2がCSS3にバージョンアップしたのです。どちらも新しい方ができることは増えていますが、現在のところ電子書籍をつくるにあたっては、それほど気にすることではないと思います。
将来的にも、文字のみの電子書籍をつくるのであれば問題にならないと思いますが、インタラクティブな書籍、ビジュアル重視の雑誌を電子出版するようになったら、「新しい方じゃないとつくれない」ということになってくるでしょう。まぁ、その頃には、制作環境も読書環境も進化しているはずなので、必要になったときに新しいものに対応していけばよいと思います。

実用上は「大差ない」と表現してよいと思いますが、制作する際には、これらの小さな違いがトラブルにつながったりします。それぞれの違いについて、最初から学習しておく必要はありませんが、「EPUB 2とEPUB 3は、違うところがある」という点だけは、理解しておきましょう。

電子書籍をつくるにはどんな知識が必要なのでしょうか。絶対に必要というわけではありませんが、「あると便利」なものをまとめておきましょう。

●書籍の知識
「扉」や「奥付」「キャプション」などは、主に出版業界の人が使う用語です。電子書籍も出版物なので、出版業界の用語がでてくることがあります。

●HTML
くどいようですが、EPUBファイルの本文はHTMLです。文字を入力して並べるだけなら、HTMLの知識は無用ですが、その中身を直接いじる場合には、HTMLの基礎知識が必要です。
といっても、「なにかするときは、タグで囲む」程度でＯＫですが。
それぞれのタグの意味や、「こういうときは、どういうタグを使うのか」といったことは、その場で検索すれば充分です。

●CSS
CSSファイルは「スタイルシート」と呼ばれます。HTMLの文字などを、実際にどうやって表示するのかを、細かく指定するためのファイルです。それぞれの指定をHTMLの中に書くとHTMLがごちゃごちゃしてしまうので、外のファイルに追い出した……とイメージしてください。
CSSでの設定方法、HTML内での指定方法、適用範囲の設定などがわかればＯＫです。

●パソコンと端末の関係
電子書籍自体は、パソコンで制作することになりますが、実際にその電子書籍を表示するのは、ほとんどの場合端末です。なので、パソコンと端末の関係については、知っておいた方がいいでしょう。
たとえば、パソコンでつくった電子書籍を端末で表示する場合、端末のどこにコピーするかは、大事な問題です。間違ったところにコピーしてしまうと、まったく表示できません。

●著作権
電子書籍という著作物をつくるならば、著作権については知っておいた方がいいと思います。
電子書籍をつくったら、自分にはどんな権利があってどこまでできるのか。
他人の著作物をどこまでつかっていいのか、どんなことはしちゃいけないのか。
販売を依頼したら、相手にはどんな権利があって、自分と相手にできること・できないことはなんなのか。
著作権は、とても難しい話です。一気に理解する必要はないですが、少しずつでも理解を深める努力は必要です。

パソコンとインターネットが、なんとなく使えていれば、どうにかこうにか電子書籍はつくれてしまうものです。本人が納得していればそれでいいのですが、ちゃんとした電子書籍をつくりたいというのであれば、これらについて知っておくことは、マイナスにはならないでしょう。

EPUB2形式でEPUBファイルをつくるとき（実質、sigilを使う時）は、まず目次に注意しなければなれません。
EPUB2で使う目次ファイルは、「toc.ncx」です。
もともとこのファイルは、メニューから目次を呼び出したときに、ジャンプ先を表示するためのファイルです（おそらく）。
以下、予想ですが。
紙の書籍では、表紙のあと・本文の前に目次が入っています（たいていの場合）。しかし、EPUB2が策定されたころの想定としては、「目次は、本文と一連に配置せず、メニューからだけ呼び出せればいい」というものだったんじゃないでしょうか。
確かに、電子書籍の特性を考えるならば、表紙をめくってその次に目次が入らない方が、スマートです。
しかし、読む方としては、本文を読み始める前に、目次で全体像を把握しておきたい、という気持ちもあるわけで……。
それはともかく、そうした「電子書籍ならではの使い方」をイメージしていたために、目次を「ページの一部」ではなく、「必要に応じて呼び出すファイル」として既定していたと考えられます。
そんなわけで、sigilでフツーに電子書籍をつくると、ページとしての（本文とひと続きになった）目次は、作成されません。
では、どうするか。
sigilでは、そのために「HTMLの目次を作成」というメニューが用意されています。[ツール]メニュー→[目次]→[HTMLの目次を作成]です。
そのメニューを実行すると、目次（toc.ncx）を元に、「TOC.xhtml」というファイルが作成されます。これは、本文のHTMLファイルと同じ扱いなので、中身を編集したり、好きなところに配置したりできます。
こうすれば、EPUB2形式でも「表紙→目次→本文」といった流れにすることができます。

もうひとつの問題が、「日本語表記」です。
何度も書いてる気がしますが、ルール上はEPUB3になって日本語の縦書きや左開きに対応したことになっています。それをそのまま受け取ると、EPUB2では日本語を縦書きで表示できないことになります。
しかしEPUB2でも、いくつかコードを追加するだけで、きちんと縦書き・左開きの電子書籍をつくることができます。CSSとの組み合わせで「縦中横」も可能です。具体的な方法については、のちほどじっくりと。
ただし、ルビや圏点などには、対応していないようです。
ここでいう「対応していない」というのは、「EpubCheckで、エラーになるかならないか」で判断しています。ひょっとしたら、 EpubCheckではエラーになるものの、端末上では表示できてしまうかもしれません。おそらくできてしまうかもしれませんが、それは自己責任でお願いします。

EPUB3でつくるときも、EPUB2同様、目次がネックになることがあります。ただ、問題になるのは、AmazonのKindleだけのようなのですが。
Kindleは、EPUB2をベースにしたファイル形式を採用しています。ということは、目次ファイルに「toc.ncx」を使うわけです。
ところが、EPUB3では、目次ファイルがtoc.ncxからtoc.xhtmlに変更になりました。つまり、フツーにEPUB3形式で電子書籍をつくると、toc.ncxが作成されません。
実は、その状態でKindleに登録すると……できないことはないようです。
Kindlegen（EPUBをKindle用のファイルに変換するツール）が2.8へバージョンアップしたときに、toc.ncxがなくてもOKになりました。
とはいえ、「じゃあ、なくてもいいや」とはならないのが、難しいところ。ソフトウェアは、どこにバグがひそんでいるかわかりません。ひょっとしたら、いまでもどこかにtoc.ncxを参照するようになっている部分があるかもしれないのです。
というわけで、いまでも自衛策としてtoc.ncxを用意している人が多いようです。

EPUB3になって、HTML5とCSS3が採用になり、表現の幅が広くなりました。が、それらを全部使えるわけではありません。
EPUB3は、表記法としてHTML5とCSS3を「借りている」だけで、まったく同じことができるわけではないのです。さらにいうと、EPUB3で「使える」と規定されているものでも、その機能をビュアー側が用意していなければ、使えません。
この「宝の持ち腐れ」状態は、もうしばらく続きそうです。

中休み的に、Kindleの話などを。
AmazonのKindleは、電子書籍を販売するストア、電子書籍を読むためのアプリ、そしてAmazonが販売する専用端末の名前です。サービス全体の総称……という言い方もできますが、単に「Kindle」と書いたときに、どれを指すのかわかりにくい、という側面があります。なので、書く方としては、普段「Kindle」と言ってしまっているところでも、わざわざ「ストアのKindle」みたいな言い換えをしなくてはいけないので、なかなか面倒です。このブログだと、ちょっとサボっちゃってますが（笑）

さて。
ここでお話するのは、アプリのKindleと、専用端末のKindleについてです。
フツーに考えると、同じ会社が販売している同じ名前のモノなのだから、どれも一緒だろうと思うわけですが、これが結構違ったりするから、困ったものなのです。多少の差なら「まぁ、しょうがないか」とも思いますが、「どうしてそうなるの？」と不思議になるくらいの差が存在したりするのです。

まず、目次。EPUB2とEPUB3の違いのところでも話しましたが、KindleはEPUB2ベースのファイル形式のため、toc.ncxがあったほうがいいのです。しかし、そのtoc.ncx、一部のKindleでしか使われていないのです。
Kindle PaperwhiteとKindle Fireでは、使っているらしいことはわかりました。しかし、Kindle for AndroidとKindle for iOSでは、どうやら使っていないようなのです。こちらでは、メニューから「目次」を選択すると、本文前の目次ページへジャンプするのです。
ところがKindle PaperwhiteとKindle Fireだと、メニューから「目次」を選択した場合、toc.ncxからピックアップした（らしい）目次項目が、リスト表示されるのです。
同じ「Kindle」でありながら、この違いはなんなんでしょうか。
さらに言うと、Kindle FireはOSとしてAndroidを採用しています。なのに、「Kindle for Android」とは別のアプリが入っているわけです。
理不尽……というか、不可解です。OSが同じAndroidなんだから、同じアプリの方が楽なんじゃないか、と。

それから。
自分で制作したEPUBファイルを端末に転送して表示チェックをするわけですが、ほかの端末だと「左開き」でページ送りができるのに、Kindle for iOSだけ、どうしても右開きになってしまうことがありました。
原因を調べてもわからないし、そのままKDPにアップしましたが、販売されたデータをダウンロードしてみると、ちゃんと左開きになってました。
おそらく、KDPの中の人が修正してくれたのでしょうが、そうやって対応できるのならば、アプリの方も修正できるんじゃないかと思うのですけどねぇ……。

もうひとつ。
Kindleシステムの特徴として、複数の端末で読んでいる位置が同期できるというものがあります。自宅のタブレットで本を読んでいたとします。通勤電車のスマホでその本を開くと、タブレットで読んでいた位置から読書を再開できる、という機能です。
これはこれで便利なのですが……これがトラブルの原因になったりもするのです。
自作のEPUBファイルをタブレットなどのKindleに送ってチェックしていたとき、表示が乱れたりしたことがありました。
あれこれ調べた結果、どうも読書位置の同期機能あたりがあやしいことに気づきました。
Kindleで本を読んでいると、クラウド（Amazonのサーバー）に「ここまで読んだ」というデータを送って、必要なときにそのデータを引き出しているわけです。
ところが、自作のEPUBファイルの場合、クラウドにはそのEPUBファイルを買ったという記録がありません。買ってないのだから、当然です。そのあたりで、データがおかしくなって、表示が乱れたりしたのでは……というのが、私の考察。実際、読了位置を記録して、端末に保存しているであろうファイルを削除してみたら、挙動が元に戻りました（ひょつとしたら、危険な操作かもしれないので、やるときは自己責任でお願いします）。

……とまぁ、Kindleには不思議なところがいろいろあります。
最終的には解決する問題ですし、致命的な欠点というわけでもなので、「じゃあ、Kindle使うのやめよう」ということにはならないのですが、こうした問題があるということくらいは、把握しておいてもマイナスにはならないんじゃないでしょうか。

電子書籍をつくるときに、まずはじめに考えなければいけないのは「構造」です。
構造というのは、EPUBファイルの中に、どんなファイルを入れるか、ということです。
EPUBの本文はHTMLファイルという話はしましたが、なにも考えずに1つのHTMLファイルに本文を詰め込むのは、あまりスマートではありません。EPUB作成サイトだったら、突然「容量をオーバーしました」なんて表示されて、すべて消えてしまうかもしれません（あくまでも可能性の話ですが）。
表紙（EPUB2ならJPEG、EPUB3ならXHTML）と本文のHTMLファイルの２つだけで構成できればわかりやすいのですが、ちゃんとした書籍にしようと思うと、それだけで収まらなくなってしまうのです。

ところで。書籍の構成について、改めて確認しておきましょう。ほとんどの書籍は、次のような構成になっています。

(1) 表紙
(2) 中表紙
(3) まえがき
(4) 目次
(5) 本文（1章、2章、3章…）
(6) あとがき
(7) 索引
(8) 奥付

表紙の次に「謝辞」が入ったり、奥付の前後に広告が入ったりするものもありますが、ややこしくなるので、ここでは割愛します。
これらのウチ、表紙は別ファイルになるのがルールなので、それ以外のものをどうするかという問題になります。ただし、本文はともかく、ほかのパーツについては、入れる・入れないというのは、制作者の自由でもあるのですけど……。
結論からいうと、すべてのパーツは、それぞれ独立したHTMLファイルにした方がいいでしょう。その方が、なにかと作業がしやすいからです。
別のHTMLファイルにしたからといって、別の電子書籍になるわけではありません。最終的に、1冊の電子書籍の中に収納されます。
ただし、次のHTMLファイルに移動するときは、強制的に「改ページ」扱いになります。そのHTMLファイルの最後まできたら、画面上の最後の行から下（縦書きの場合は左）部分は、空白になります。で、フリックなどでページをめくると、次のHTMLファイルが表示される、というわけです。
ちなみに、本文も章ごとにひとつのHTMLファイルにした方がいいでしょう。ただ、どこまでファイルをわけた方がいいのかは、ケースバイケースです。
長編小説なら章ごとでしょうし、短編小説集なら1話ごとでしょう。エッセイやプログなど、細切れのものは悩むところです。ひとつひとつを独立したHTMLファイルにするとファイル数が増えすぎて、逆に扱いづらくなってしまいますし、全体をひとつのHTMLファイルにしても、トラブルの種になったりしますし。個人的には、ファイルが100くらいで収まりそうならそれぞれ独立したHTMLファイルでもいい気がしますし、それ以上なら適当にブロック分けをして、ブロックごとにHTMLファイルにした方がいいんじゃないかと思います。

ここで、sigilの基本的な使い方について、さらっと紹介しておきましょう。
このブログでは、sigilをおすすめしていることもあり、操作方法もsigil中心になります。なので、あらかじめsigilの操作方法について解説しておきます。

sigilは、3ペインで構成されています。
左がフォルダ構成、右が目次。中央には、文章や画像、コードが表示されます。ほとんどの作業は、中央のペインを使って作業することになります。

最初は「ブックビュー」という状態になっています。ワープロなどと同じように、実際の見た目通りに画面に表示されます。
もうひとつが、「コードビュー」です。ツールバーの[コードビュー]をクリックすると、中身（コード）が表示されます。
sigil上で文章を入力する人は少数派でしょうから、コードビューを使う時間の方が長くなるんじゃないでしょうか。ただ、簡易的に「実際にはどう表示されるのか」を確認することもあるので、このコードビューとブックビューの切り替えは、よく使うことになるでしょう。

大半のメニューは、ツールバーにアイコンで表示されています。ファイルの保存や画像の挿入、見出しの指定など、大半のことはツールバーで済んでしまいます。それぞれのアイコンがどんな機能なのかは、マウスカーソルを上に乗せるとツールチップが表示されるので、参考にしましょう。このブログでは、アイコン名をそのツールチップで表示される内容で表記していきます。

意外とよく使うのが、左側のフォルダ構成（ブックブラウザ）です。
たとえば、本文用のファイルを新たにつくると、sigilは「Section0001.xhtml」といったファイル名をつけます。その名前でもいいよ、という人はそれでも構わないのですが、多くの人にとっては、わかりにくいハズ。なので、「tobira.xhtml」「main01.xhtml」「Chapter-1.xhtml」といった、自分のわかりやすいファイル名の方が、なにかと便利でしょう。
ファイル名の変更は、左側のペインからの方がやりやすいです。ファィル名を右クリックして[名前の変更]をクリックすればOK。よく使われる[F2]は、ファイル名の変更ではないので、注意しましょう。
ファイルの順番の変更も、このペインで行います。ファイル名をドラッグ＆ドロップすればＯＫ。opfファイル内に記録される読書の順番も、それに合わせて変更されます。

sigilの基本操作は、以上です。
それほど難しいアプリというわけでもないので、大きな問題はないと思います。逆に言うと、「上に書いてあることがさっぱりわからない」という方は、この先もっとわからなくなるので、電子書籍を自力でつくるのは、あきらめた方が早いかもしれません。「それでもやる」という人まで止める気はありませんが、かなり苦労することは覚悟しておいてください。
といっても、ほとんどの場合、難しいのはsigilの操作方法ではなくて、HTMLやCSSの知識です。「こうしたいときは、どう指定すればいいのか」が難しいのです。

電子書籍をつくるときに、まずはじめにするのは、書名や著者名など電子書籍に関する情報を入力しておくことです。
とりあえず必要なのは、

・書名（タイトル）
・著者名（作者名）
・言語

の３つです。sigilだと、ツールバーの[i]ボタン（メタデータエディター）をクリックします。これらのデータは、「content.opf」の中に記録されます。
ほかにも、「出版社」とか「訳者」などのデータも追加可能です。
これらの情報を「書誌情報」と呼びます。
で、この書誌情報ですが……設定したからといって、どこかに表示されるということもありません。直接読者の目に触れることはなくとも、「誰の著作物なのか」を記しておくことは、とても大切なことです。

さて。
ルールとしては、
・個別識別子（dc:identifier）
・書名（dc:title）
・言語（dc:language）
・更新日（dcterms:modified）
　が必須とされています。
　個別識別子（ID）というのは、その本だけに与えられた文字列です。アルファベットと数字で表記されます。アプリ（やサイト）を使っている場合、アプリ側が自動的にIDを決めてくれるハズなので、通常は気にする必要はないでしょう。
「勝手に決められるのはイヤ」というのであれば、サイト名やハンドルネームと制作開始日やシリーズ名など、自分でつけてもOK。
言語は、日本語の書籍なら「ja」と指定します。更新日は、そのEPUBファイルの最終更新日です。どちらも、ID同様通常はアプリやサイトが、保存するごとに自動更新してくれます。
ということで、実質的にどうしても自分で書いておかなければならないのは、「書名」のみということになります。
この４つのデータ以外のものがなくても、EPUBファイルとしてのルール違反にはなりませんが、著者や出版社は書籍として必要な情報じゃないでしょうか。
結局のところ、なにを書誌情報として記録しておくかは、つくる人の自由でもあるわけですが、飾りとではなく貴重な資料・情報なわけですから、丁寧につくっておいて損はないハズです。