本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏（日本CGサービス（JCGS）代表）が探っていく。第11回では、イラスト・マンガ・Webtoon・アニメーション制作アプリ「CLIP STUDIO PAINT」の開発・販売で知られるセルシスを取材。同社のテクニカル系スタッフの仕事を前後編にわたって深掘りする。

快適な描画体験を守るため、大容量データと向き合う設計

稲葉 遼氏（以下、稲葉）：CLIP STUDIO PAINTの開発において、常に向き合ってきた根本的な課題は「大きな画像をいかに扱うか」に尽きます。例えば、A4サイズを350dpiで描くと、キャンバスサイズはおおよそ4,000×3,000pixelに達します。そこに100枚以上のレイヤーを重ねるという使い方も珍しくありません。

稲葉：このような重いデータを、単純に1枚の画像としてメモリに載せてしまうと、すぐに容量が足りなくなってしまいます。そこで、画像全体を適切なサイズに分割し、必要な部分のみを保持する「タイル管理」のような構造でメモリ負荷を最適化しています。

CLIP STUDIO PAINTは、32bit OSが主流だった時代から存在しており、当時は実質3GB程度しかメモリが使えませんでした。その制約下で成立させるために、自社実装のスワップ機構、すなわち使用していないデータを一時的にファイルに退避させるしくみを構築してきた背景があります。

現在のPC環境では、OS側がある程度スワップ処理を担ってくれるため、自前のしくみが活躍する場面は限定的になっています。しかし、この設計があったからこそ、後のモバイルOS対応をスムーズに進められた側面が大きいと感じています。

モバイルでは、メモリ使用量がOSに厳しく監視されており、iOSの場合は一定の上限を超えると警告が発せられ、さらに超えるとアプリが強制終了されてしまいます。そうした特性をふまえて、搭載メモリに応じたメモリ使用上限を明示的に定め、アプリ側で制御を行う必要があるのです。

この考え方は、ある意味でかつての「32bit時代の壁」とよく似ています。当時培ったノウハウをベースに、「どの段階でそれ以上メモリを消費しないようにするか」をコントロールする現在の設計につながっています。もしこのスワップ基盤がなければ、モバイル対応にはもっと苦労していたと思いますね。

漫画原稿にも堪えうる「拡大・縮小」への徹底したこだわり

CGWORLD：CLIP STUDIO PAINTといえば、拡大・縮小時の動きが非常にスムーズで、どれだけズームしても絵が綺麗に見える印象があります。あの快適さは、何か特別な工夫によるものなのでしょうか？

稲葉：開発側の感覚としては、何かひとつの“特別な仕掛け”を入れているわけではないんですが、結果的にはかなり多くの最適化を重ねていると思います。

まず「スムーズに動く」という点では、SIMDのようなベクトル演算命令を活用して、計算処理の高速化を図っています。通常のCPU演算だけでは負荷が高くなってしまうので、あらかじめベクトル演算を前提とした処理にして、描画速度を確保しています。

一方で、「どんなズーム率でも絵が綺麗に見える」という部分は、かなり意識してつくり込んでいるポイントです。特に難しいのが、漫画原稿に多いモノクロ（二値）画像ですね。

モノクロ画像の場合、1ピクセル単位の端数処理が結果に直結します。拡大・縮小の際、わずかなズレで“1ピクセルの隙間”が出るかどうかが決まってしまう。例えば、グレースケールやアンチエイリアスが前提の画像であれば、多少の誤差は視覚的にあまりわかりませんが、二値画像では一発で“破綻”が見えてしまうんです。

「原稿に隙間が空いて見えるんだけど？」という指摘が出るような事態は、当然避けなければいけません。そのため、拡大・縮小時の端数の扱いには細心の注意を払っています。絵の内容が変わったように見えてしまうかもしれない処理は、極力排除するようにしています。

例えば、二値画像に対してはアンチエイリアス処理をかけないようにしています。二値で描いている人にとっては「二値として見ること」が重要なので、ズーム時に勝手にぼかされたような表示になると「なんでボケてるの？」と違和感を覚えられてしまう。そのため、見せ方としても破綻しないように、明確に二値表示をキープする工夫をしています。

一部の例外として、ナビゲータなどの補助表示では見やすさを重視して別の処理をしている箇所もありますが、メインの描画表示については、漫画原稿のようなシビアな用途でも破綻しないクオリティを守ることを大前提にしています。

ブラシ処理におけるGPU活用の、課題と可能性

稲葉：CLIP STUDIO PAINTにおいて、パフォーマンスは常に意識している重要なテーマです。特に筆圧や筆跡が繊細に反映されるブラシまわりの処理については、快適性を保つために多くの工夫を施しています。

よくユーザーの方から「CLIP STUDIO PAINTはGPUをあまり活用していないのでは」といった声をいただくのですが、実際にはGPUを使った高速化の研究や試作は、これまで何度もくり返してきました。

ただ、その度に最終的には「GPUを使っても劇的な高速化は実現しないし、CPUだけで処理した方がパフォーマンス面で安定する」という結論に落ち着いてきた、というのが現状です。

理由は大きく2つあります。ひとつは、CLIP STUDIO PAINTが長年にわたりCPUベースで進化してきたという背景です。内部のブラシ処理には複雑な分岐や処理の多様性があり、GPUに向いている処理と向かない処理が混在しています。CPU ではこのブラシは実装できるけど、GPU では同じ表現のブラシは実装できない、そういった処理が少なくありません。

もうひとつは、CLIP STUDIO PAINTの特徴である「大きなキャンバスサイズ」です。GPUに全画像を載せることができないので、結局はメインメモリとの間で頻繁なデータ転送が発生してしまう。この「転送コスト」が高いため、かえってCPUだけで処理した方が効率的になるという判断をくだすこともあります。

とはいえ、GPUが適している場面もあるのは確かですし、将来的にGPUのアーキテクチャやAPIが変化すれば、実装可能な選択肢も増えていくはずです。ですから、GPUの活用に関しては今後も継続的に検証しつつ、必要に応じて取り入れていくつもりです。

コードが蓄積する「技術知」と、段階的オンボーディング

稲葉：当社では、自社で開発した専用フレームワークの基、非常に大規模なプロジェクトを運用しています。そのため、何か新しい機能を実装する場合にも、まずは社内のソースコードの中から過去の実装例や似た機能のパターンを探し出して、それを手がかりに進めていくことが基本です。言い換えれば、社内コード自体が「ナレッジベース」として機能している感覚ですね。

このプロジェクトの規模感では、どの開発者もまずソースコードを読むところから始まります。中堅以上のエンジニアであれば、構造や慣習を把握した上でフレームワークに沿った実装ができるので、特段の指示がなくとも開発を進められます。

一方で、新卒メンバーなど経験の浅い開発者に対しては、オンボーディングを段階的に行なっています。まずはメンターの先輩社員が付き、「どこを見ればいいか」といったナビゲートをしつつ、書いたコードを丁寧にレビューします。

最初の1年間は、既存機能の不具合修正など比較的スコープの小さいタスクを中心に取り組んでもらい、徐々に局所的な機能開発へとステップアップしていきます。2年目に入る頃には、次期バージョン向けの機能開発を単独で任せられるほどの成長が見られるケースも多いです。

プロジェクトの規模と複雑さへの対応が求められることもあって、こうした段階的かつ実践的な育成方針が、セルシスにおける開発文化の特徴のひとつになっていると思います。

品質を支えるレビューとテスト文化

稲葉：私が入社した当初は、コードレビューのフローが明確に整備されていませんでした。しかし現在では、どんな小さな変更であっても、コードレビューとテストの実施は必須という運用になっています。

過去には「この程度ならレビューなしでも問題ないだろう」と判断するケースもありましたが、大規模なプロジェクトでは、ちょっとした変更が思わぬ副作用や挙動の変化を引き起こすことがあります。ときには、コンパイラ側の挙動が変わったことで、手元では問題なかったはずのコードが意図せず振る舞いを変えてしまう、といった事例もありました。

そうした背景から、今は「全ての変更にテストを行う」ことが徹底されています。具体的には、ブランチを切る → 実装してコミットする → Pull Requestでレビューを受ける → チケットを作成してテストする、という一連のながれが定型化されており、これをまとめたものが先程お話した開発フローの手順書です（詳細は前編を参照）。

このようにしくみが整っているため、新卒メンバーであっても、先輩社員と一緒に手順を踏んでいくうちに、自然と当社の開発文化に馴染んでいけるようになっています。明確に「教育プログラム」として設計しているわけではありませんが、結果的にオンボーディングの役割も果たしていると感じています。

ゲームエンジンにも学ぶ、3Dレンダリング表現の進化

稲葉：外部の研究事例や他分野の技術を参照することは、私たちにとって日常的な開発スタイルの一部です。直近では、Ver.4.2のアップデートで、CLIP STUDIO PAINTにおける3D表示のレンダリングをよりリアルに強化しました。社内では“フォトリアル”と呼んでいる取り組みで、金属のような質感を含むマテリアル表現が、より自然に見えるようになったのが特長です。

稲葉：この実装を担当したエンジニアは、開発にあたりゲーム業界のレンダリング技術や、Unreal Engine関連の技術資料、関連学会で発表された論文などを参考にしながら、マテリアルやライティングのしくみを再設計していきました。

3D機能に関しては、CGWORLDが扱っている領域に近いところもあるとは思いますが、私たちが開発しているのはフル3Dの制作ツールではなく、あくまで「作画補助としての3D機能」です。ただ、それでも「金属部分がどう見えるべきか」や「反射がどう働くべきか」といったビジュアル表現は、作画の説得力に直結するため、実は意外と重要です。

これまでは金属的な質感が白っぽく表示されてしまい、どうしても説得力に欠けていましたが、今回のアップデートにより、色味や反射の質感がより正確に反映されるようになり、作画補助としての3Dの使い勝手も大きく向上したと感じています。

アルゴリズムにこだわった、自然な「パペット変形」

稲葉：CLIP STUDIO PAINTには「パペット変形」と呼ばれる変形機能があります。これは後から実装された比較的新しい機能で、他社のグラフィックアプリにも似たような機能が存在するため、ユーザー側にも明確な“操作感の基準”がある領域です。

稲葉：そのため、見た目だけそれっぽく見せれば良いというわけではなく、動作が直感的かつ破綻しないことが求められます。この実装にあたっては、既存の研究や論文を多数参照しながら、どういったアルゴリズムが適切かを検討しました。

特に注意したのは、ユーザーが動かしている場所以外が、勝手に不自然な動きをしないことです。内部的にはメッシュベースの変形処理を行なっているため、計算量とのバランスも考慮しながら、自然で滑らかな挙動を実現するための調整が必要でした。

実際、最初の実装段階では「悪くはないが、ユーザーの期待通りに動いていない」という評価で、2〜3回ほど実装を見直しています。担当エンジニアは他の業務とも兼務していたため、開発には半年以上を要しましたが、最終的には操作感・精度・パフォーマンスのバランスが取れた機能として実装を完了することができました。

“遅い”にも種類がある。動かして見えてくる課題

稲葉：ここまでのお話とも関係しますが、グラフィックアプリの開発においては「実際に動かしてみないとわからないこと」が本当に多いと感じています。だからこそ、テストメンバーには実機でしっかり触ってもらい、「描き心地」まで含めた体感レベルで確認してもらう必要があります。最終的には、描いて、動かして、確かめるしかないんです。

「動作が遅い」というフィードバックひとつとっても、要因は様々です。処理そのものが重いケースもあれば、入力への反応が遅れている、あるいは一瞬フリーズするような“引っかかり”がある、など、同じ「遅い」という言葉でも、実際に起きている現象はまったく異なります。ここを見誤ってしまうと、対策の方向性がズレてしまいます。

例えば、変形ツールなどの負荷が高い処理では、ユーザーがドラッグ操作を行なっている間に毎フレーム変形を計算してしまうと、操作がガタついて非常にストレスフルになります。処理の重さが原因で、マウスカーソルの追従性が損なわれると、それだけで「使いづらい」と感じさせてしまいます。

そうしたケースでは、あえて処理の頻度を落とすことで体感を改善することもあります。例えば、ドラッグ中の更新頻度を間引いたり、操作の終了後にまとめて変形処理を走らせたり、あるいはタイマーで一定時間後に更新するなど、“見せ方の最適化”によって快適さを担保する工夫をしています。

これら3つの動画は、筆者が「遅さの種類のちがい」を可視化するために用意したもの。実際の使用環境では複数の要因が重なるため、ユーザーが感じている不満の“本質”を見極めるのは非常に難しい。

稲葉：ユーザー体験として重要なのは、「表示が完全にリアルタイムで更新されること」よりも、「自分の操作にポインタやハンドルが自然に追従してくること」です。結果の反映が多少遅れていても、入力と画面上の反応が気持ち良くリンクしていれば、ユーザーはそれを“遅い”とは感じにくい。私たちはそうした“感覚的な違和感”をなくす方向で、細かい表示の調整を行なっています。

もちろん理想は「処理そのものを高速化すること」ですが、技術的な限界がある場面も少なくありません。そうしたときには、「どう見せればストレスを軽減できるか」という視点で工夫を重ねています。

モバイル世代に向けた、UI/UXの次なるチャレンジ

稲葉：今後、さらに力を入れていきたいと考えているテーマのひとつがUI/UXの再設計です。現在のCLIP STUDIO PAINTのUIは、もともとPC向けに設計されたものであり、iPadやAndroidタブレットへの対応時には必要に応じた調整は行なってきたものの、基本的には「PCの設計をモバイルにもち込む」かたちになっています。

しかし、今後は「モバイルからこのアプリに触れ始める」ユーザーが、ますます増えていくでしょう。そうなると、最初からモバイルの使用体験を前提にしたUI設計が必要になってきます。

PC向けのUIと、現代のモバイルアプリにおけるUI/UXの設計思想は根本的に異なります。例えば、メニュー構造や操作導線の在り方、表示密度、指先での操作性など、どれも考慮すべきポイントです。CLIP STUDIO PAINTのような高機能アプリほど、この再設計は難題になります。

PC世代のユーザーにとっては、今のUIが“馴染みのある快適な操作環境”かもしれませんが、モバイルネイティブな世代、特に中高生などが初めてこのアプリに触れたとき、「なぜこんなに複雑なのか」と感じてしまう可能性もあります。ここを無視するわけにはいきません。

とはいえ、UIの抜本的な刷新は非常に難度が高い取り組みです。現在の操作体系に慣れているユーザーから「元に戻してほしい」といった声が上がるリスクもあるため、“新しさ”と“慣れ親しんだ使い心地”をいかに両立するかが大きなチャレンジになります。

自動テストは「これから」の領域。導入の難しさと現在地

稲葉：これまで「テスト」として紹介してきた工程は、基本的に手動での確認作業が中心です。自動テストのしくみも一応は用意しているのですが、現状では十分に整備されているとは言い難く、実際にカバーできている範囲はごく一部に留まっています。ユニットテストもフレームワークこそ導入しているものの、本格運用にいたるにはまだ道半ばといったところです。

というのも、自動テストやユニットテストは、開発の初期段階からそれを前提に設計されていないと、後から組み込むのが非常に難しいんです。現在は「書こうと思えば誰でも書ける」環境が整ってきたことで、徐々にではありますが運用が始まっています。フレームワークすら存在せず、そもそも書く術がなかった時代と比べれば、確実に前進しています。

とはいえ、CLIP STUDIO PAINTのようにUIの占める比重が非常に高いアプリケーションでは、自動テストで代替できない領域が多く、どうしても人の目と手に頼る工程が残ってしまいます。

一時期はテストエンジニアの採用にも取り組みましたが、いわゆる「開発周辺」を担うエンジニアは採用市場でも非常に少なく、思うように人材確保ができなかった経緯があります。技術的にも人材的にも、簡単に解決できる課題ではないというのが現実です。

求めるのは「支える人」。CI/CDと画像処理に強い人材を募集

稲葉：採用面で長年感じているのは、CI/CDやDevOpsに特化した人材が慢性的に不足しているということです。当社の開発はマルチプラットフォームで展開しているため、ビルドから配布までのパイプラインは非常に複雑になりがちです。

ところが、このパイプライン全体を安定して回せる人材が社内には数人しかおらず、専任の担当者がいない状態です。本来であれば、こうしたインフラを支える専門人材がいてこそ、プロダクトの品質や開発スピードも向上していくはずなのですが、現実には他の業務との兼務で回しているのが実情です。

先程お話したテスト自動化が「しくみはあるが、本格運用にいたっていない」という状況も、こうした人材不足が一因です。私たちは今後もCI/CDの基盤整備を推進していく予定なので、DevOpsやインフラ寄りの領域に強いエンジニアは、今まさに求めている人材像です。

また、特に学生や若手エンジニアに向けて伝えたいのは、3D領域に強い人材も歓迎しているという点です。当社には研究開発を担うチームがあり、レンダリング処理などを自前で実装できるスキルをもったエンジニアも活躍しています。

プロダクト全体から見ると3D機能は限定的ですが、実装難度は高く、商用レベルで成立させるには高度な知見が求められます。CGやリアルタイムレンダリングに興味のある方にとって、挑戦しがいのあるテーマは豊富にあります。

さらに、画像処理の知識をもつ方も歓迎です。2D/3Dを問わず、拡大・縮小や輝度補正といった基礎的な処理に対する理解があると、実装上の判断や設計の精度が格段に上がります。

市販のアプリケーションであれば既存ライブラリで済むような処理でも、当社では独自の実装が必要になる場面が多く、アルゴリズムの選定から実装までを自ら行える人材は非常に貴重です。基礎体力のある画像処理エンジニアが活躍できるフィールドが、ここにはあります。

“受け身”から“発信”へ。必要な人材に届く採用

稲葉：ここ数年、採用活動の進め方そのものも大きく見直しています。以前は比較的“受け身”の姿勢でも応募が集まる状況がありましたが、それだけでは十分ではないという認識に変わりました。現在は「セルシスがエンジニア採用を強化している」という事実を、しっかり外部に伝えていく発信型のスタンスへとシフトしています。

具体的な取り組みとしては、採用サイトにエンジニア向けの特設ページを開設。中途・新卒を問わず、セルシスの開発文化や取り組みを明確に伝えるコンテンツを用意しています。

また新卒向けには、エンジニア志望の学生を対象とした説明会も実施。プロダクトの裏側や、エンジニアとして関わることのできる領域など、実際の開発現場をリアルに伝える場を設けています。こうした発信を強化することで、必要な人材にしっかり情報が届く採用活動を目指しています。

筆者まとめ

今回は、CLIP STUDIO PAINTの開発現場を通じて、セルシスという企業がいかにプロダクトと真摯に向き合ってきたかを垣間見ることができました。

2012年のリリース以降、同アプリは世界中のアーティストに支持され続け、PC（Windows／Mac）世代からモバイル（iOS／Android）世代へと対応プラットフォームを拡張しつつも、長期運用と進化を両立してきました。その裏側には、ビルドやCI/CD、メモリ管理、UI/UX設計など多岐にわたる技術的な試行錯誤と、地道な改善の積み重ねがありました。

特に印象的だったのは、「社内ユーザー」とも言える開発メンバー自身が、描き心地や違和感といった“数値化しづらい品質”を組織的に拾い上げる体制が整っていることです。単なる動作検証に留まらず、「気持ちよく描けるか」という体験そのものをプロダクトの中核に据えている姿勢こそが、CLIP STUDIO PAINTを世界的なアプリケーションへと育ててきたのだと感じました。