マガジン航[kɔː]

みなさまは青空文庫をご存知でしょうか？　青空文庫は、著作権の消滅した作品と、著作権者（著者ら）が「自由に読んでもらってかまわない」とした作品を、テキストファイルやHTMLファイルで提供しているサイトで、またそうしたテキスト化と配布を行っているプロジェクトです。青空文庫のサイトを訪れたことのない人でも、KindleストアやKoboストアの「無料本」として再配布されているものを見たり、もしかしたら読んだことがあるかもしれません。

青空文庫は1997年の「青空文庫の提案」からスタートし、多くのボランティアによって支えられてきています。2013年に呼びかけ人の一人であった富田倫生氏が逝去されましたが、活動は途絶えることなく、また富田氏の著書『本の未来』の書名を冠し、青空文庫の活動を将来にわたって支援するための基金「本の未来基金」が創設されました。

何よりも大切な多くのボランティア活動者と、それを支援する基金などからなる活動の仕組みは『青空文庫編 青空文庫のしくみ』にまとめられています。しかし、その活動の場であり、成果が並んで利用者に送り出される場でもあるサイト、それを構成するサーバーの仕組みは、外からは見えにくいものでした。2015年5月30日に開かれた「Code for 青空文庫 アイデアソン#1」で見えてきた、この「もう一つの青空文庫の仕組み」と今後の方向感をまとめてみたいと思います。

青空文庫が危ない？

青空文庫からのお知らせの役割も果たす「そらもよう」に、5月15日、「本の未来基金『Code for 青空文庫』アイデアソン実施のお知らせ」が掲載されました。このお知らせは、次のように始められていました。

青空文庫をサポートする「本の未来基金」は、青空文庫をテクノロジーで支え、発展させるための新たな取組として、「Code for 青空文庫」を立ち上げ、アイデアソンを下記の要領で実施いたします。

青空文庫は現在エンジニアなしで5台のサーバを運用しており、またそれに伴うサーバの老朽化も問題となっています。そこで青空文庫が今後も発展を続けることができるよう、本アイデアソンを通して、青空文庫に興味をもっていただけるエンジニアの方を探し、安定した青空文庫の運営と、将来を見据えた青空文庫の形を模索して参ります。

最初に書いたとおり、青空文庫は活動であるとともに、テキスト化された作品ファイル群とそれを配布するWebサイトのことでもあります。青空文庫を支えているものは、なによりも活動に従事するボランティアですが、彼らの成果であるファイル等のデータを格納してWeb経由で配布しているサーバーも欠くことのできない構成要素です。

開催概要と参加者募集が掲載された「『Code for 青空文庫』アイデアソン #1 : ATND」ページには、「本の未来基金」の香月啓佑氏がこの時点での認識をまとめた旧版「青空文庫サーバの今と今後」がリンクされていましたが、一読して青空文庫サーバが心配になる内容でした。Facebookに、このイベントページやスライドへのリンクと現状への心配をコメントする知人の投稿が続けて流れてきて、私もすぐに参加ボタンをクリックしました。

結論から言えば、当日までに関係者や協力者が調査を進めた結果は、もう少し安心できるものでした。サーバー群にはたしかに手当が必要なものの、当初心配されたような作品データ資産が失われる危機下や「どうしてよいかわからない」アンコントローラブルな状況下にあるわけではなく、老朽化対策についても当日までに現状調査が少し進められていました。

イベントはでこうした現状がまず説明された後、「2018年の青空文庫」というテーマが提示され、午後には4時間にわたるアイデアソンが行われました。イベント内容についてはすべての資料が公開されているほか、開催中にほぼリアルタイムに公開・更新されていた鷹野凌氏の「青空文庫を救え！『Code for 青空文庫』アイデアソン #1 レポート」をはじめとして、複数の参加者レポートが詳細を伝えています。これらへのリンクが「Code for 青空文庫」アイデアソン #1 まとめ」にまとめられています。

青空文庫のサーバーの仕組み

青空文庫には「運営について」「作業の進み方」「財政基盤について」の三点をまとめた「青空文庫編 青空文庫のしくみ」というページがありますが、青空文庫を支えるサーバーの仕組みが本格的にまとめて説明されたのは、今回のアイデアソンでの資料が初めてではないかと思います。公開されイベント当日に説明された「青空文庫サーバの今と今後」から、まず現在の運用構成をまとめたスライドを見てみましょう。

青空文庫サイトと「図書館活動」を支えるWebサーバー

青空文庫には、現在DNSとメールサーバのほかに「Webサーバー」と、上スライド中では校正システムと記載されている「作業管理システムサーバー」の2台があります。以前にはWebサーバーには正・副の2台があったのですが、副にあたるミラーサーバーは2014年10月14日に運用停止しており、現在はありません。

Webサーバーは、青空文庫の「図書館活動」を支えるサーバーと言えそうです。まず「収録作品」と呼ばれるテキスト化された作品ファイル群が収められた、いわば蔵書庫であるファイルサーバーであり、それを配布する図書館と言えるWebサーバーです。青空文庫のサイトであるwww.aozora.gr.jpをブラウザで開いたとき、実際にアクセスしているのがこのサーバーです。

「電子化活動」を支える作業管理システムサーバー

「作業管理システムサーバー」は、資料中ではDBサーバー、校正システムサーバー、校正サーバー、校正管理サーバーなどの表記もありました。また当日も、発表者によってはアプリケーションサーバーと呼称されることがありましたが、実際には「作業管理システムサーバー」と呼ぶのが妥当なようです。以下では、この呼称を使うことにします。

作業管理システムサーバーは、青空文庫の「電子化活動」を支えるサーバーと言えそうです。アイデアソンで説明された役割と青空文庫工作員マニュアルを付き合わせると、「作業着手連絡システム」の実体がこの作業管理システムサーバーだと思われます。簡単に作品収録までの流れをまとめておきましょう。

1. 青空文庫に新しい作品を登録したい人は、入力受付システムで「着手報告」をします。
2. 入力し終えた電子ファイルを点検チーム宛にメールします。校正受付システムの作品一覧に載ります。
3. 誰かが校正を申し込むと、その校正者に電子ファイルがメールで送られます。
4. 校正し終えたファイルを点検チーム宛にメールします。
5. 点検チームで「加工」と呼ばれる作業をします。実際には、素読みや最終チェックと呼ばれる内容確認がされ、公開用のテキストファイルとXHTMLファイルが用意されます。

作業管理システムサーバーにはもう一つ大切な役割があります。作業管理システムサーバーには、青空文庫のWebサイトで配信されている作品ごとの「図書カード」や著者ごとのページなどの元データがあります。また、電子化の作業が済んで「収録待ち」になった作品の電子ファイルは、その日まで作業管理システムサーバーに保存されます。作業管理システムサーバーでは、「毎日午前3時に同期」システムが動いています。これが最新の図書カード等を生成し、著作権保護期間が切れ作業も完了した収録可能な作品があれば、それもあわせて、この同期作業内でWebサーバーに送り出しています。

作業管理システムサーバーの役割を整理すると、①書誌情報や著者情報の登録・管理システム、②青空文庫参加者情報の登録・管理システム、③作品ごとの作業状況の登録・管理システム、④作業済み・未収録作品の一時保管場所、⑤Webサーバーへの自動コンテンツ配信システムということになります。

青空文庫サーバーの問題点

次にこうした青空文庫サーバー群について、現在の問題点をまとめたスライドを見てみましょう。

サーバーの老朽化対策と二重化の必要

重要な点を整理してみます。まずセキュリティ面から見れば、各サーバーを構成するソフトウェアは常に更新され、適宜設定の見直しも行われることが必要でしょう。スライドでも挙げられているようにDNSサーバーやメールサーバーはとくに標的にされやすく、私見ですがDNSサーバーは踏み台として悪用されたときの社会的責任が、メールサーバーは同様の責任に加えてメールに含まれる個人情報の保護の責任も、大きな懸念事項となりそうです。

サービスの安定提供の面で言えば、どのサーバーも正・副を設ける「二重化」などはされておらず、故障が発生すると活動が一時停止しそうです。

・DNSサーバーが故障すれば青空文庫サイト、作業着手連絡システムともアクセスできなくなり、「図書館」活動も「電子化」活動も一時停止することが予想できます。
・メールサーバーの故障時は各作業の節目のメール連絡をできなくしますし、作業管理システムサーバーが故障すると校正受付システムが働かず、どちらも「電子化」活動を止めてしまいそうです。
・作業管理システムサーバーの故障が続くと、その間は青空文庫のWebサイトでの新しい収録作品が公開されなくなり、「図書館」活動にも差し障ります。
・Webサーバーの故障時は、青空文庫のWebサイトにアクセスできなくなり、「図書館」活動を止めてしまいそうです。

作業管理システムサーバーについてはとくに物理的な老朽化が指摘されており、故障の発生確率は他のサーバーより高そうです。旧い世代のサーバーは、故障時に修理ができるか、部品等が手配できるかといった点も心配されます。加えて、サーバー構成が把握しきれていないため、故障すると復旧できるかわからないというのが現状です。全体として、故障したら再開するか、どれだけ時間がかかるかという問題があることになります。

データ喪失の心配はなし

最後にデータの保全性の面から見れば、DNSやメールサーバーには設定情報しかなく、データが失われる心配はありません。Webサーバーは、多くのコンテンツは作業管理システムサーバーから配信されてくるもので作り直しが利き、また収録作品は利用者が一括ダウンロードできるようにするために、海外のGitHubというサービス上にコピーが置かれています。

書籍情報、著者情報、作業者の情報、進行状況情報といったデータや、収録待ち作品のテキストファイルそのものが保管されている作業管理システムサーバーについては、データベースのバックアップが手作業でときどき行われています。未収録作品については、点検チームの各メンバーがメールの添付ファイルとしてもっているという、複製が複数個所でもたれている状態ということで是としているようです。ただこの仕組みでよいのか、またサーバー構成が把握しきれていない状態で、他に重要な情報がないかなどの懸念が残ります。

現時点での対策作業

青空文庫サーバーはどうなっていくのでしょうか。香月氏のスライドでは、いま考えるべきこととして、以下の二点が挙げられました。

1)  DBの保全という意味で現状のシステムの移管を行う
2) 将来に向けた「実験版青空文庫（仮称）」を立ち上げる。

2015年にはまず早急に「老朽化対策作業」の作業が行われることになるでしょう。

作業管理システムサーバーの調査状況

アイデアソンが呼びかけられた時点では「サービスの全貌を把握している人がいない」「DBサーバが飛ぶと青空文庫のデータ資産が失われる、とにもかくにもまずはバックアップを！」とまで書かれていた作業管理システムサーバーですが、開催当日までにはある程度まで調査が進められており、香月氏と近しく相談を受けて調査を中心的に進めてきた宇谷有史氏が「青空文庫構成管理サーバー現状報告」との題で調査状況を報告しています。

当初からバックアップが必要との認識はあったのですが、その時点ではバックアップ自体が困難でした。理由は二つあり、一つは「どこにデータがあるかわかっていないから何をバックアップしていいかわからない」ということです。宇谷氏はこれについて、データベースにあるものとないものを整理した調査結果を報告しており、主要なデータと言えるものはおそらくデータベース上のデータと収録前の作品本文ファイルである、とのあたりがつくところまできたことになります。

もう一つはデータベースのバックアップ方法で、何年も前の旧いデータベースソフトの機能でバックアップデータを書き出したところで、現在のデータベースソフトでこのバックアップデータを使うことができるだろうかということです。これについても宇谷氏は実際に一連の手順を実施してみており、バックアップデータから、ほぼ最新のデータベースソフト上にデータベースを作り直すことができたと報告しています。

バックアップができるかどうかもわからないと目されていた構成管理サーバーですが、これらの報告からすれば目鼻はついた、「何とかなりそう」な状態にはなってきたと言えそうです。

直近の「老朽化対策」作業

この調査状況を踏まえ、喫緊の課題は「現状のシステム」をできるだけそのまま、新しいサーバーに載せ換え、バックアップなどの体制を整えることになります。観点は「現在のデータとシステムを、老朽化するサーバーから移し変える」ことです。発表内容を踏まえ、現状をまとめてみます。

DNSやメールについては、セキュリティ面の懸念などもあり、外部のサービスを利用する方向が検討されていました。青空文庫はシステムの管理にリソースをかけないという考え方にも合う方向でしょう。これはすでに切替に向けて動き始めているようでした。Webサーバーについては現状維持の方向です。

現在老朽化が指摘されている作業管理システムサーバーを別のサーバーに移しかえること。これが次の大きな課題です。移しかえにあたっては、まずその構成も把握できていないことが問題でした。データについてはすでに解析が進められ、移し替えのめどが立っています。しかし「作業受付システム」と総称される入力受付システムや校正受付システム、あるいは「午前3時の同期」処理などのプログラムは、総体も詳細もまだ把握できていないところです。

作業管理システムサーバーについては、急ピッチで調査を進め、新しいハードウェア、またはVPSやクラウド上の仮想マシンに移していくことが期待されます。一方で個人情報である作業者情報などがあり、大勢にアクセス可能にして調査をコミュニティの力で、というアプローチが取りにくいようです。これについては、データベースの調査を先行していた宇谷氏や、アイデアソンでインフラ分科会をモデレートした日本Rubyの会の高橋征義氏らが作業にあたっていくようです。

そして2018年に向けたアイデアソン

ここまで主としてアイデアソン当日の説明内容を元に、青空文庫サーバーの仕組みと現状、そして「現状のシステムの維持」に向けた取り組みをまとめました。懇親会やその後で確認したこともありますが、当日の参加者にも午前の報告会が終わった時点で「おおむね危機は脱しつつある」という認識ができあがっていました。そこで今回のアイデアソンは「2018年の青空文庫」をテーマに、開催されました。

アイデアソンの流れ

アイデアソンは「インフラ分科会」「アプリケーション分科会」「マネジメント・広報分科会」に分かれて行われました。分科会ごとにまず個々人でのアイデア出し、その後全員のアイデアを列記し議論したいアイデア数件を選択しました。その後アイデアごとに数名の小グループに分かれてディスカッションという流れで行われました。なお、参加各人から出たアイデアはすべてこちらにまとめられています。

アイデアソンからの提案

今後、青空文庫のインフラに求められることは何か。青空文庫を活用したアプリケーションとしてどんなことが考えられるか。青空文庫のシステム管理や技術者コネクションを維持していくための運用課題は何か。こうした観点で行われたアイデアソンでの各グループからの発表を振り返ってみます。

インフラの改善

直近の青空文庫サーバー老朽化対策活動とは別に、その先のインフラとその運用の改善は、参加者にとって一つの関心事であり懸念事項だったようです。

インフラに関しては、次のステップとしてインフラ分科会の「クラウド化」グループから、クラウド化に関する提言があがりました。午前中のセッションで「青空文庫はおそらく今後もIT専任担当はおかない」「IT運用の負荷はできる限り低く保ちたい」という方向感が示されたことを受け、「運用の手間を減らす」ためにクラウド化をめざすという提言になっています。具体的には、可能なものは外部サービス/SaaS利用や、PaaSに載せるといった提案が出されました。これらの目的はできるだけサービス提供業者にITの運用を任せようという意図ですが、その一方で「できるだけ特定のサービス提供事業者に依存しないかたちにする」という提言もあり、バランスも意識された提言と感じられました。

同時に、今回「サーバー構成が把握しきれていない」という現状が明かされたことは、とくにインフラ分科会参加者には重く受け止められたようです。「ドキュメンテーション」のグループからは、工作員向けマニュアルは充実しているがエンジニア向けマニュアルは有無すら不明との指摘があり、これからエンジニアの参加を募るためにもドキュメントは整備していくべきとの提言がありました。ドキュメンテーショングループからの「次に移行が必要になったときにまたこんな大騒ぎを繰返すようでいいのでしょうか？」という問いかけは、会場全体にこの課題の大切さを再認識させました。

APIとオープンデータ化

青空文庫を利便性や機能性の面で拡張する「API」「オープンデータ」への関心も大きかったようです。

インフラ分科会とアプリケーション分科会でそれぞれこのテーマの検討があり、青空文庫が提供すべきもの、青空文庫だから提供できるものとして以下のようなものが挙げられました。

・書誌情報、著者情報
・著作権存続情報
・書籍内の任意の本文一部分
・作業状況情報

振り返ってみると、すでに青空文庫がWebページのかたちでは提供しているものも少なからず含まれます。しかしそれが機械にも扱いやすいかたちで提供されることで、書誌情報を集約・共創する「書籍版CDDB」、作品全体ではなく引用箇所へのリファレンスを提供できるようになる「引用のインフラ」、そして細かい粒度でできる作業は小さなボランティアを募ることのできる「青空文庫のマイクロボランティア」などの可能性が見えるというのが両チームの意見でした。

またインフラ分科会グループからは、一方で「青空文庫はエンジニアを抱えない」ことに立ち戻り、青空文庫がすべきことはデータの提供で、さまざまなAPIの実現や提供は外部に委ねるほうがよいという提言がありました。おそらくこの提言は、今イベント開催の目的であった「青空文庫活動への技術者の参加」を促す上でも、有効に働くと思います。

電子化活動を支えるツールとフィードバック

青空文庫の「電子化活動」で作業待ちが溜まっているといった報告があったことからか、作業者のモチベーションに着目し、なかでも利用者からのフィードバックを活かすための提言も複数のチームから挙がりました。

インフラ分科会「自動校正システム＋入力支援」グループからは、OCRの活用などとともに、GitHubライクなシステムでの電子化作業の提案がありました。参考として示されているのは、ソフトウェア開発以外でのGitHubの活用事例として話題になった『GitHubで雑誌・書籍を作る』ですが、この本の著者である伊藤直也氏、編集者である稲尾尚徳氏が作業サイクルが細やかになる点とコミュニケーションを挙げています。これに加えて、このグループでは貢献の可視化と応報でモチベーション向上に活かそうと提案していた点が印象に残りました。

アプリ分科会「校正支援アプリケーション」グループからは、やはり協働作業環境の提案がありました。「ユーザーのフィードバックを可能にする」グループからも、作品情報のWiki化が挙がっています。構成支援アプリケーショングループが指摘している通り、「著作権が有効な期間内は、本文はサーバーにおけない」点はこうしたアイデアに対する制約となっており、「メールベースでの作業フロー」に変更を加えることができないまま、現在に至っているという実情があります。言い換えれば、この制約のためにもっとも工夫が進められていない部分であり、ここにはやはり多くの提言が寄せられていました。

「青空文庫 校正を楽しくするプロジェクト」と「ユーザーのフィードバックを可能にする」グループからは、収録作品や、入力や校正などの電子化の進捗に対してTweet、Facebookの「いいね」などで応援し、作業者のモチベーションにできるようにするといった提案がされました。同時に青空文庫の掲示板「みずたまり」の前例から、自由度の高すぎるものは「荒れ」る可能性も高まると、デザインは慎重にするよう提言がありました。

私見ですが利用者からのフィードバックが見えるようになると、工作員が次に作業する作品を選んだり、また青空文庫が校正待ちの滞留対策として取り入れた有償校正について、どの作品から適用するかを判断する際にも役立つのではないかと思います。

青空のコミュニティ

このアイデアソンのテーマの一つは「青空文庫に興味をもっていただけるエンジニアの方を探す」こと、エンジニアコミュニティ形成の端緒とすることでしたが、アイデアソンでは非エンジニアコミュニティに関する提言もありました。これも電子化活動の滞留増を、活動の裾野を広げることで解消するといった思いがあるのかもしれません。

マネジメント・広報分科会「青空文庫のオープン化」グループからは、オープン化の対象として、①入力・校正方法、②点検チームと点検作業方法のオープン化、③「中の人」のオープン化（中の人の声ブログ、工作員ページからFacebook/Twitterアカウント等にリンク等）が挙がりました。発表者の野口英司さんは呼びかけ人でもある、いわば「中の人」で、「私たちは気質としてこもりがちなきらいはあった」と発言されていたり、「野口さんがこう発表されるならすぐにもオープン化されそうですね」といった声が飛んで笑いを誘ったりもしていました。

同じく「イベント開催計画（青空文学部）」からは「2017年武道館貸切イベントへ向け、年次イベントで練習」という突然のビッグドリーム提示があり、会場が呑まれたところへ工作員イベント、シャッカソン（写経＝入力イベント）、啓蒙イベント（工作員になりたい人向け、エンジニア向け）などの提案がありました。こうしたオフラインでのイベントは、裾野を広げる意味合いだけではなく、著作権等の関係でオンラインでの協働作業化などが難しい現状下で入力者や校正者のモチベーション向上にも有効かもしれないと思いました。たとえばウィキペディアタウン活動、OpenStreetMapsのマッピングパーティーなどはその両面を担っているでしょう。ぜひできるときにできるものから開催されていってほしいものです。

2018年へ向かう青空文庫の足取り

最後に、青空文庫のサーバーまわりの当面の動きをまとめておきましょう。「アイデアソン #1 まとめ」で、末尾に次のようにまとめられています。

現在GitHub上で具体的な作業に向けた検討が進んでいます。またコミュニケーション用にSlackに「aozorahack」チームを作りました。参加希望の方はGitHubをご覧ください。

また校正管理サーバ（※作業管理システムサーバーのこと）の移転については、サーバの現状について調査を続行中です。メールアドレスなどの個人情報が含まれているため、作業状況の公開まではもうしばらくお待ちください。

そして今回の動きに関してもう少しわかりやすい形で現在青空文庫で活動中の皆さんに資料を作成し、説明の準備を進めています。そちらももうしばらくお時間をください。

直近の作業管理システムサーバーの移転については、前述のとおり少人数での調査が進められています。今回の移行では構成変更や機能追加などは考えられていないことから、移行自体はマンパワーをかける大規模作業ではなく、小規模ながらも迅速さが求められるものと思われます。調査者らには負担をかけることになりそうですが、調査完了後はそのままの顔ぶれに移行までをお任せできるとよいのかもしれません。

アイデアソンで出たアイデア、またそのほかの「2018年の青空文庫」をめざす活動と議論の場としては、上に書かれているとおりgithubリポジトリが作成されています。「Issues」がいわば「懸案」リストになっています。さっそく技術者ならではの情報交換になっているものもありますが、「アイデアソン#1の反省点」や「工作員作業マニュアルをaozorahackに」などの議論がされているほか、「青空文庫フォーマットのAST（抽象構文木）」のような技術的な情報交換も始まっているようです。ここがエンジニアを結びつけるハブにもなって、コミュニティをかたちづくっていくのでしょう。

結果的に言えば、今回のアイデアソンを経て青空文庫はサーバーまわりに抱えた膿を吐き出し、それを取り除いた上で、より大きな「青空文庫活動」へ向かうことが示されたように思います。青空文庫は、サーバーまわりに老朽化、専任者不在、その他の問題を抱えていましたし、それはアイデアソンの呼びかけと実際の内容の齟齬などのドタバタにも現れています。しかし今回のアイデアソンを経て、すっきりしたかたちで新しいシステムに向かってもらえればそれに越したことはありません。

同時に今回のアイデアソンは、青空文庫に興味をもつ外部のエンジニアと緩やかなコミュニティを立ち上げるという目的をもって開催され、その後の動きを見ればそのきっかけ作りを何とか果たしていたように思います。またアイデアソンでは、工作員や利用者に向けてオープンになっていくこと、イベント等を通じてつながりを増やすことの提言もありました。そもそも、青空文庫には外部に「読者」としての参加者がいて、その中にはエンジニアも、工作員活動に協力できる人もいます。今回のアイデアソンは、振り返ってみるとそうした読者向けの催しとしても「初めてだった」ようですが、これがさまざまなかたちで2度目、3度目につながってほしいものです。

青空文庫の「図書館活動」「電子化活動」はそうして、これまでと同様に着々と進められ広がっていくでしょう。その上でまた、書誌の電子流通のスタンダードを作る、直接リンクを含むオンライン引用のスタンダードを作る、そうした利活用に向けたIT基盤の先駆け、リファレンスになっていってくれればというのが、アイデアソンに参加してみて浮かんできた私の期待です。

■関連記事
・青空文庫がインターネット・アーカイブに収録
・インターネット電子図書館の夢
・新年にパブリック・ドメインについて考える