コミックの電子化と出版の変遷

私はコンテンツビジネス開発グループに所属しており、電子書籍関係を担当している。また、共同印刷とソフトバンクグループと合弁で作ったデジタルカタパルトという会社の制作技術部にも兼務しており、両面からコンテンツビジネスを推進する立場にいる。

これまで、CTSの組版システム、チラシ・カタログのデータベース連携組版、まんがのフルデジタル制作システム（InDesignプラグイン、ComicPacker）の開発を担当した。その後、ガラケーのオーサリング部隊の立ち上げや、共同印刷の自社サービスの立ち上げなどを担当した。
最近は、出版社の電子出版の動きも加速しており、オーサリングに関わるところが多くなってきている。

デジタルカタパルトは「ソク読み」というまんがの配信サービスをやっており、制作を共同印刷が受け持っている。「ソク読み」サービスは、そこで配信して売るだけでなく、例えばYahooとか楽天等への取次業務も行っている。　

出版市場の動向

出版市場は1996年をピークに縮小傾向にある。矢野経済研究所の資料によると、右肩下がりが続き、毎年3％とか4％とかいう落ちを示している。

コミック誌もコミックスも2011年は4.6%減、3,900億円という話を聞いている。ピーク時は6,000億円あったそうだ。共同印刷は、『週刊少年ジャンプ』の印刷をやらせていただいているが、ピーク時は毎週630万部出ていたのが、今300万部前後というところになっている。それでもかなり力のあるトップの雑誌だが、そんな状況である。

ただ、この中でもジャンル的に伸びているものもある。小学館が2006、2007年頃から始めた、ライトノベルのガガガ文庫、ルルル文庫などはかなり伸びているようだ。角川系列もライトノベルが強い。

矢野経済研究所の予測では、2012年は1兆7,000億円くらい、2014年に1兆6,000億円、2015年に1兆5,000億円と、かなりのレベルで市場が縮小していくとなっている。その中で電子書籍の市場規模はどうなっているか。2010年度が670億円と、確実に伸びている。矢野総研の読みでは2015年度に1,500億円という形になっている。

タブレットリーダー向けのサービス、売上は、飛躍的に伸びていくだろうと予測している。タブレット端末は、最初にiPadが出て、その後なかなか追随せず、その後Androidタブレット系も出たが、いまひとつ普及しなかった。ここに来て、ソニーや楽天など、専用端末やマルチメディア端末も含めて広がってきている。最近電車の中でも、iPadやiPhoneでマンガを読んでいる光景を目にすることが増えた。

従来から電子書籍市場を阻む課題として、持ち歩いて読めない、長時間読むと目が疲れる、ダウンロードに通信コストと時間がかかるという3つの課題が挙げられていた。しかし、これらが端末やネットワークインフラの革新によって急速に解消されてきている。ユーザーが読める土壌が整ってきているということである。

コンテンツ別の予想

2010年度、コミックは88％を占めていた。この読みも、まんがのサービスをやっている我々としてはちょっと疑問だが、少子化と課金の仕方のハードルということで、クレジットカードだと子供が買えないといったことだと思うが、そういうところからコミックは今後伸び悩むのではないかということを矢野総研は言っている。

逆にタブレット系とか電子書籍専用端末の浸透に伴って、今度は書籍のほうが伸びるのではないかと言っている。しかし、正直なところ、ここも難しいところではないかと思っている。

ただ、アメリカではオライリーが、電子書籍販売比率のほうが紙の販売より大きくなっているという話をずいぶん前に聞いているので、もしかしたらこういう書籍などももっと伸びるのかもしれない。

雑誌は日本雑誌協会が今一生懸命やっているが、雑誌をどう電子化して売るか、どういうサービスにするかというところは、まだ不明である。
アメリカでは、ある雑誌出版5社が集まって、月額課金でその5社の雑誌をなんでも読み放題ということをやっていたりしている。私の個人的な感覚では、雑誌はそういう配信の仕方をしないと今後伸びていかないだろう。そういう配信をすれば広告も付いてくるかもしれないと考えている。

そして、米国では2011年末にタブレットや電子書籍専用端末が拡大し、成人の3割が所有していると書かれている。

これがざっくり市場動向の話だが、実際、今後どう動いていくかは神のみぞ知るというところだろう。

コミックにおける共同印刷の取り組み

共同印刷は『週刊少年ジャンプ』をやっているということもあり、マンガには常に力を入れてきていた。マンガの製版は写植だった時代がずいぶん長く、数十年続いていた。原画に印画紙で出力したネームを糊で貼って、それをスキャンして集版するという流れである。
これを切り替えないと先がない、効率化しないといけないということで、共同印刷ではマンガのDTP化を推進した。

ComicPackerという名前のシステムを作ったのが2003年で、そこから2年くらい鳴かず飛ばずであった。社内生産システムなのでそんなに話題にもならなかったが、Yahooあたりから配信の話が出始めた2005、2006年くらいから、急にDTP化が注目されるようになってきた。これがコミック電子化のトリガーになったと思っている。

これがあった縁でソフトバンクグループとデジタルカタパルトという会社を作り、小学館とソク読みをやらせていただくようになった。これを他の出版社にも乗ってもらうサービスに変えたのが2009年である。

そこからAndroid、iOS対応を続けてきた。製版のDTP化で言うと一番遅かったのは集英社である。この辺もあとで話をしたい。

電子書籍へのトリガーはコミック製版のDTP化だということを何回か述べたが、なぜコミック製版のDTP化が遅れていたのかというと、特にマンガ雑誌を製版するスピードというのは尋常ではない。
例えば『週刊少年ジャンプ』は入稿して2～3時間で出稿まで持っていかなければいけない。集中して何本も入ってしまうとそうもいかないが、大体2時間半くらいで出している。そのスピードがDTPで保てるのか。

アナログ製版時代にそのスピードを保っていたのは、やはり職人技であった。この職人がずっと頑張っていたおかげで、ずっと週刊ベースで何百万部も出せていた。この職人技をDTPに移植するのは、非常に困難であった。

あとは、2009年か2010年頃、DTPではコミック特有の書体バリエーション（主流は、写研書体。イナクズレ、タンボインなど）に相当する書体をがなく、編集部がどうしても納得してくれなかった。この辺が、コミックのDTP化が遅れていた理由だと思う。

結果的には、フォントベンダーに働きかけをして、フォントワークスと一緒にまんが用の書体を作った。モリサワも追随して、出してきた。

しかし、DTP化したときのメリットはこんなにあるのだということが、既に共同印刷としてはわかっていた。例えば、職人技の標準化。職人じゃなくてもみんなできるような環境が整う。

また、DTPデータの印刷に向けた再加工性の向上というのは、雑誌を作ったときのデータを加工して、コミックス、単行本を作るとか、文庫サイズのものを作るとか、ああいったところのハンドリングが良くなる。ここの再加工性は飛躍的に伸びた。また、ハンドリングのいいデータなので電子書籍を作るのも楽である。

これらに伴う効率化、コストダウンという大きなメリットがあった。ただ、共同印刷としては、生産面の効率化だけではなく、デジタルカタパルトを使って配信、アグリゲートのところまでつなげていった。

ComicPacker

ComicPackerは2003年に開発したInDesignのプラグインで、今CS5.5まで対応している。6の対応も、それほどハードルは高くないのでやっていきたいと思っている。OSはSnowLeopardまでと書いてあるが、マウンテンライオンも多分大丈夫だと思う。

マンガの現場が最新の環境を整えていない、あるいは編集部や出版社のデザイナーと環境を合わせたりということもあって、最新が出たからすぐ最新に対応という流れにはなっていない。

InDesignのプラグインで、画稿、ページを作りながら流し込んで作っていく機能と、ネームを自動組版する機能を備えている。あとはマンガ特有の記号・外字類の入力とか、ふちの処理をおこなう。あふれ処理というのは、ふきだし枠からあふれるような指定が来ていても、それを収めてしまう機能である。こういう部分のルールや運用フロー、制作フローに関わることをComicPackerに組み込んである。

ComicPackerによる制作フローも、実はかなり頭をひねったところである。アナログ製版時代と大きくフローが変わると、編集部が付いてこられない。本当に短納期なので、「できない」と言われた瞬間にまずいことになる。
したがってあまり変えないで、感覚的に編集部の負荷が変わらないように、あるいは負荷を軽減するような形で提案させてもらい、採用された。

指定紙、画稿、柱類の3本を入稿してもらえれば、あとはComicPackerでがんがん作るというフローである。初校を見てからの流れというのは、通常のDTPの流れと同じである。

そして、校了後のデータをとっておく。これは、コミックス、単行本を作るときに使うためである。当然、加筆修正の画稿が入ってくるが、それは別処理をする。コミックスを作るとき、最初に0校というデータを出す。コミックス判型にしたものをまず出して、それに赤字を入れて組み上げていくという形をとる。論理的には、どんな判型のコミックスでも作れるように設計されている。

ここで校了済みのデータを、今度は配信用データのアーカイブデータとして保持しておき、それを今度は電子書籍の制作をするときに使う。配信用データの仕様は、詳細に決められている。

それと既存コミック、例えば20年前のマンガを電子化したいというような話があると、スキャンすることがある。この底本スキャンの仕様から保存の仕方まで、詳細に決めている。スキャンデータなので曲がり補正をしなければいけないとか、ゴミ取りとか、ノドの補正をしなければいけない。あとはTIFF、LZW圧縮をかけたり、解像度はこれで2値にしようといったことをやっている。

これらを電子書籍用に、大体サイズ的には10分の1くらいに画像縮小して、そのときになるべくモアレが出ないような処理をする。これもどういう仕様で作るようにというルールがある。

それ以外に、最近多いのが、過去にドットブックで作ったものからEPUBを作ってほしいとか、そんな話もあって、他社が制作した電子書籍データが入稿されることが、多くなっている。これらからEPUBとかドットブックとか、例えばソク読みは独自仕様のファイルフォーマットなので、それに合わせたオーサリングをして各サービスに配信供給していくということをやっている。

配信用の画像加工

大量の画像加工をすることを前提にしているため、自動化を進めている。社内で画像加工用のツールを開発し、PDFでもTIFFやJPEGでも自動処理できる方式にしている。
必要な設定をしておくと、例えば朝には500冊終わっているというような流れである。

2007年頃問題になったのが、コミックスタジオのようなツールで作画する作家が、デジタルトーンやグレースケールも貼ってきて、印刷上の問題になったりしていた。デジタルトーンは形状が歪んでおり、ピッチがかなり小さかったり、ヘアラインに当たるような小さいドットで飛んでしまったり、モアレが出てしまったり、品質に影響を与えることが多かった。
この辺を回避するためのオプションとか、文字だけをくっきりさせる加工処理を入れてみたり、工夫している。

ComicPackerはもともと、ネームのレイヤー、画稿のレイヤーが分けられたInDesignデータで作られる。レイヤー分けしたPDFを吐き出して、そこから各レイヤーごとの処理を別個でかけるということをやっている。そうすることによって文字は眠くならないし、絵は絵だけの処理をする。最後にそのレイヤーを統合して、きれいなデータにしようという自動化ツールである。

Photoshopで言うと50くらいの工程を処理していかないといけないので、1冊80分くらいかかる処理になっている。このような加工をしながら、電子配信用の素材を作っている。

EPUB仕様（固定レイアウト）の現状

ドットブックでもそうだが、各出版社ごとに「ドットブックはこういうふうに書いてほしい」という仕様がある。
固定レイアウトのEPUBに関しては、電書協が取り仕切って、仕様、ガイドラインを固めていて、これで一本化するのかと思っていたが、実はそうではなかった。

そもそも電書協の仕様がどんな感じで出てきたのかというと、いろいろ憶測も含まれるが、まずソニーのEPUBの仕様はSVGラッピングが絶対だという仕様である。楽天コボなどはEPUB3だったらいいということで、画像直リンクというEPUBが多かった。

ここが技術的な歩み寄りを見せて、SVGラッピングを主にしようということになった。出版社もそれが望みであった。ただ、画像直リンクもフォールバックという形で許そうという形でやっと仕様がまとまったのが2012年11月22日で、デジタルコミック協議会が出してきた。

そういう基本的な技術の調整というのはソニーなどがやってきたが、実際の仕様のひな形になったのは、これは私の憶測だが、どうも角川の仕様がベースになったのではないかと思っている。これが緊デジ、あるいはデジコミ協の仕様のガイドラインとなって、出てきた。

ガイドラインという言葉を強調したのは、自由度が大きく、仕様書とは言えないためである。各出版社の裁量によるところが結構大きく、制作側では、結局、各出版社向けに作らざるを得ないのが現状である。

ただ、リーディングシステム側が、基本的には電書協、デジコミ協の仕様に則っているので、これらをちゃんと作ってちゃんと表示できるというビュワーができてくれば、それはそれで出版社仕様があっても仕方ないと思っている。

例えばデジコミ協のEPUBの主な特徴としては、SVGラッピング、フォールバックで画像直リンクというところ、あとフォルダ名、ファイル名の規定もされている。また、ページ画像の縦横サイズを固定しなさいという規定がある。

それから、クリッカブル目次はないと言いながら、ここは出版社の自由裁量になっていたりするので、この辺で工数の増減があるという形である。これが今のEPUBの、国内の固定レイアウトの現状だと思う。多分、各社苦労されているだろう。

EPUBのオーサリングフローを簡単に書いておいた。ドットブックでも大差ない。オーサリングするには、各社の書誌データと素材としての画像が必要になる。テンプレートというのは共同印刷側で用意するが、この3点をオーサリングツールに入れるとEPUBが生成される。
共同印刷のツールでは、まちまちの仕様で来る各社の書誌データを共通化して、制作用のCSVを作っている。
入稿画像は、JPEGやTIFF、PDF、またはその他のデータで来ることもあるため、加工する場合としない場合がある。テンプレートは、各出版社や配信会社の仕様に基づいたテンプレートを共同印刷で用意してセットする。そしてボタンを押すとオーサリングがおこなわれるという形である。

できたEPUBに対すして、EPUBチェック・構造チェックをする工程がある。これもコマンドを打てばいいが、時間がかかるし面倒なので、これもツールに組み込んでいる。

修正があった場合、手で細かい修正をすることがある。そうしたときに再パッケージということで、これも別に手でコマンドを打てばいいが、面倒なので、この辺もツール化している。

制作上の課題

使用するIDが、例えばJDCLだったりISBNだったり、JPEコードで作りなさいとか、UUIDだとか、ここが出版社によって、あるいは配信会社によって固定していない。ここが固定してくると楽になる。

また、画像の縦横サイズを1冊内で揃えるようにということで、リーディングシステム側は縦がなりゆきでも対応できるようになっていると思う。ただ、これが電書協あるいはデジコミ協の仕様では固定化しろという話になっているため、例えば横が足りないページは小口側に背景色を足すとか、カバーページはやや大きくなりがちなのでトリミングするとか、そういう工程が発生している。

また、書誌データの項目について、雑協は今、雑誌の書誌データを固定しようというプロジェクトが動いている。雑誌だけでなく書籍類、コミックス、みんなデータを一律の項目で管理できるようになると、非常に楽になると思っている。

制作の仕様についても、例えばEPUBの仕様が各社仕様になるというのは正直つらいところである。
また、目次の処理をやったり、やらなかったり。マンガは特になくてもいいことが多いが、絶対入れてもらいたいというところもあって、それで工数がぐーんと上がったりする。

容量制限と画質のバランスが難しい。通常の200ページのまんがだとEPUBを作っても50メガ前後だが、300ページ超えとか、多くなってくると100メガを超える場合がある。100メガを超えるとキャリア側の制限とか配信システム側の制限があり、もっと抑えてほしいということで画質を下げることがある。
そのような場合の調整ルールが整理されてくると、効率もよくなる。

配信サービス「ソク読み」

ソク読みは2007年から始めている。最初は小学館の専用電子コミックサイトとして立ち上がった。これを2009年にオープン化して、現在30社の出版社が参加している。講談社、秋田書店といった大手にも入っていただいている。

ソク読みのAndroidアプリをリリースしたのが去年である。Androidは、OSの不安定性、機種依存が非常に大きくて、アプリを作ってもちゃんと動くか、その動作検証に時間とコストがかかったが、なんとか安定して動いている。

それに対してiOSのアプリは非常に作りやすくて安定感もある。しかしアップルのリジェクトにひっかかる確率が結構高く、デジタルカタパルトとしてはアプリをやめた。HTML5ビュワーでサービスを実現している。

現在31,000冊を超える配信をしている。80％が女性客である。配信形式はすべてストリーミング配信である。AndroidのアプリでもiOSのHTML5でもストリーミング配信している。デバイスはこれらが対応している。フォーマットは独自フォーマットである。

ビュワーアプリからHTML5ビュワーへ移行した理由をもう少し話すと、アップルのリジェクトリスクが大きくて、開発費をかけたのにビジネスにたどりつけないことが結構ある。

ソク読みはレンタル商品で、いわゆる18禁のエロは取り扱っていないが、きわどいものもある。そういうコンテンツ単位レベルでも落とされたりということがあるので、ちょっと事業に向かないというところがあった。
それに、アプリを出したからといって、それが使われるかというと、ランキング外になってしまえば結局埋もれてしまう。それならWebサービスにしてしまったほうがいいということで、HTML5のビュワーを選択した。

ホーム設定しておけばアプリっぽく使えるので、ホーム設定を促したりしている。また、どうしてもHTML5になるとコンテンツセキュリティが甘くなるので、中に持っている素材の暗号化というかパターン化というか、そんなこともやっている。通信側での制御も当然やっている。

苦労したのは端末スペック対応である。例えばiPhone 3GSとiPhone4はチップは一緒だが、解像度がiPhone4は縦横倍になっている。そうなると、チップが一緒なのに取り扱う解像度が大きくなるので、重くなる。パフォーマンスが悪くなる。それに合わせた画像サイズ、画像容量というのはどんなだろうというので、非常に苦労して作っている。

今後の課題

リーディングシステムが、例えばEPUBにおいては電書協が決めたガイドラインに沿った内容のものはすべて表示できるようにしていく、そういう方向になってくれればと思っている。
例えば、ナビゲーションドキュメントXHTMLというメタ目次のHTMLが、EPUB3.0はこちらだが2.0のリーディングシステムにも対応するために、NCXというファイルを、これまでは通常、両方混在させて作っていた。
ただ、電書協の仕様からそれがなくなったので、ナビゲーションドキュメントXHTMLを読み込めないリーダーは、目次が表示されない状況がある。

リーディアムはできるので、検証用にリーディアムを使おうと思ったが、読み込みに非常に時間がかかる。1冊読み込むのに3分くらいかかったりするので、制作業務においては検証用には使えないというところで実は苦労している。

端末の解像度も、いろいろなタブレットが出てきて、テレビもスマートテレビ化すると言われていて、どこまでのサービスにまで広げるかというのもあるが、端末解像度とそれに伴う制作側の画像の画質、画像サイズ等のバランスが難しくなってくる。

それから、書誌データが統一されてくると、制作の効率化やコスト軽減が図れるだろう。他にコンテンツセキュリティ対策がかなり必要になる。配信サイドから見ると金を生まない部分なので、コストをかけたくないが、そうも言ってられない。
Androidに多いところだが、OS、ブラウザ、端末依存、iOSについては3GSとiPhone4の話とか、端末が増えてくると、問題が増えてくる。
今はダウンロード型が多いが、配信の形として、ダウンロード型なのか、ストリーミング型なのか、どちらがいいのか。我々はストリーミング型でやっているので、今後が気になる。

また、制作仕様を統一してくれると非常に助かる。制作ツールの充実も、期待している。
画像サイズの再検討というのは先ほどの端末解像度の話。それからIDの整理といったところが今後のポイントになってくると思う。

2012年12月14日TG研究会「本格化する電子コミックとデジタル化技術」より（文責編集）