画像処理技術エンジニアの緑川晃。ニックネームはmido。

イラスト一枚でグッズを作成することができるサービス「pixivFACTORY」の画像処理システムを開発している彼に、同技術を発展させることで今後何ができるのか、話を聞きました。

特化した技術は、世の中のプラットフォームへと変わる可能性を秘めている

── イラスト一枚でグッズを作れる「pixivFACTORY」は、画像処理技術を追求することが、サービスにとって重要な価値になっているんですけど。画像処理を扱っていく上で、今後どのような活動が求められているんでしょう。

うーん。その観点からいうと、ツールやライブラリは、これからもっと内製したらいいんじゃないかなって思っています。今よりもっと高い価値や機能を提供していくために。

たとえば、最近なんですけど、「pixiv FACTORY BOOKS」という同人誌を作れるサービスの改善をしていまして。JavaScriptを使ってPhotoshopのデータフォーマットであるpsdをパースして、条件を満たしていない場合は弾くような処理を作っています。

同人誌ぐらいの規模だと、何メガバイトとか何十メガバイトとか、そういう巨大なファイルを一気にアップロードしなくちゃいけないんですよ。通信状況がよくない環境だと、相当待たされますよね。

そんな環境で、ファイルをアップロードしてから「この原稿はダメです」みたいな警告をだされたら、ユーザーのモチベーションは一気に下がりますよね。面倒だから、もう他のところに頼もうかなって思ってしまいますよね。

── JavaScriptを使ったpsdのパースって、ヘッダーの部分を舐めるような簡単なものですよね？

うーん。ヘッダー以外にもパースしなきゃいけないところがあるんですよ。ファイル内のうち、上、真ん中、下と3つぐらいありまして。

→ 参考: File header, Image resources, Layer and mask information

── また嫌な場所をチェックさせますね。psdフォーマット怖いなぁ。

JavaScriptでpsdをパースできる有名なライブラリがあるんですけど、どれもサービスの要件に合わなかったんですよ。すべてのデータをメモリに乗せてからパースし始めるみたいな、そういう実装のライブラリなんです。

小さなファイルを触るぐらいだったら別にいいんですけど、pixivFACTORY BOOKSが扱うような、何十メガバイトもあるファイルを何十個もアップロードするような用途だと、メモリへのロードは遅いし、そもそもブラウザがそんなにメモリを食って大丈夫か？みたいな問題もありますし。

── 汎用的につくると、そういう実装になってしまうのは仕方無い気もしますけどね。OSSの画像処理ツールである「ImageMagick」もそうですし。

そうですね。画像データを全てメモリに展開するとフットプリントが大きくなり、問題が起こることがありますよね。ImageMagickにもそういった問題がありますし。そういう理由があって、pixivの画像変換システムでは使われませんでしたよね。

それをGoを使って内製で作ることで解決して、しかもそれがクラウドサービス「ImageFlux」として外向けに提供されて、他のサービスからも使っていただけたりして。特化したものを内製で作ったからこそ、そういうことができたと思うんです。

── 技術は特化を続けたら、結果として世の中のプラットフォームになると思いますよ。AWSも然り。ImageFluxも然り。

ええ、そういう意味でも、pixivFACTORYの開発チームは恵まれていると思ってます。サービスの特性に特化した実装を、求められているタイミングが頻繁にあるんです。画像ファイルにしてもそう。psdにしてもそう。あと、表にはでてないだけで、内部的にはPDFの解析処理がありまして、これもかなり独特で特化したものを作ることが求められています。

それで、世の中にあふれている既存のライブラリでも扱えない時は、諦めてしまうのではなく、その時その時で、最適なツールを作っていけるようなチームにしていくことが理想。

チームでそういうツールを作って、みんなで安定してメンテナンスしていけるようになると、それだけチームが持つ選択肢は広くなり、サービスが提供できる価値の可能性も広げていける。それって、プロダクトを良くしていくチームとしては、最強になれるんじゃないかって思うんです。

最終的には、そこで培われた技術をOSSとして公開したり、ImageFluxのようにクラウドサービスとして公開して、他のサービスでも使ってもらえたりできるようになれば、かっこいいですよね。