- 澁川喜規
- 約 4,300 文字
秋のブログ週間2026 の1本目です。
これまで業務系のシステムをずっと作ってて、いつも後手に回って(実際のプロジェクトだとプラスアルファで共通部品化する余裕がなくて)根本解決できてなかったなー、という領域がいくつかあるんですが、AIのおかげでそういうのも雑に電車の中でぽちぽちスマホで指示するだけでできちゃったりします。
その1つが、ファイルのプレビューやサムネイルです。アップロード機能を持つ業務システムを作ることは、そこそこまれによくある、ぐらいの頻度ですが、例えばオフィスファイルのプレビューというと、たいていはLibreOfficeでPDFにしてから、Popplerで画像にして・・・という具合です。環境を作ろうとすると巨大なDockerイメージをぶん回すとかなります。また、ExcelをPDFにする場合、カラム数が多いと（たいてい多い）、いまいちなPDFになります。いっそのことOffice Fileを直接SVGにしちゃったりできないのか？テキスト選択もできないし・・・みたいなことをずっとモヤモヤ思っていました。
先週ぐらいにワッと作ってもらったら思いの外良いのができたのできちんと色々整理してブラッシュアップして仕上げたのが以下のリポジトリです。
macOSの仕組みを使って計測したところ、Office系ファイルの変換は消費電力は1/15、変換速度も1桁-2桁速く、メモリ消費量も少なく見積もって1/4です。実装はGoですが、変換サーバーを作ってもだいぶ小さいですし、WASM化したりサブプロセス化して簡単に組み込めます。DockerでLibreOfficeとかを入れるのと比べるとイメージサイズは1/50とかで済むはず。変換した結果の表示自体もだいぶ高速です。ミリ秒単位。思った以上に効率の良いライブラリができました。
GitHub pagesのデモはWASMで動かしているのでこの数字よりはだいぶ遅いですが、サーバーで動かすと早いです。
高速なプレビューの仕組み
PDFはPostScriptをベースにした「印刷しやすい」ポータブルなドキュメントですが、今回作ったのはブラウザ描画のCanvas命令にそのまま置き換えられるようなフォーマットにしています。Browser-specificなDocument FormatでBDFという名前にしました。ブラウザがネイティブで持っているCompressionStream、画像ファイル、ウェブフォントなどを活かすことでランタイムを小さくしました。
また、これらのファイルから目で見える画像に形式変換するのはウェブワーカーに切り離すことでUI側に負荷を掛けない仕組みとしています。
BDFは中間形式でしかないのですが、変換ロジックはWASMでブラウザで動かすこともできるし(GitHub Pagesはそれ)、事前にサーバー側で変換しておくこともできます。
なお、透明テキストなりをきちんと出すことで、テキスト選択もできるし、検索もできるようにしていてアクセシビリティにも配慮しています。ExcelとかはExcelのようなセル単位の選択コピーができるようにしています。
その他の工夫
アーキテクチャの中で遅くならないように、無駄なデータフローが発生しないようにする、というのは最初から考えていましたが、それ以外にもいくつか工夫したところがありました。
Excelのファイルの読み込みをGoでやると遅い、というのは12年ぐらい前にGoを実践で使ってみたときから思っていました。属性とかも含めて小さなヒープメモリを大量に確保することになるという原因はつかめていました。しかし、なかなか自分でXMLパーサを新規で作るのは面倒でやれていなかったのですが、今回その部分も作ってもらい、だいぶ高速にパースできるようになりました。
サーバー側で変換する場合は、オプションで許されているのであれば埋め込みフォントで必要なグリフだけを取り出して小さくする、よりサイズの小さい可逆・不可逆のWebPに画像を変換しておく(AVIFは遅すぎてやめた)などして転送速度が小さくなるようにしています。ブラウザでも変換できるようにしていて、TinyGoでビルドしたサイズの小さなWASMファイルで変換できるようにしています。TinyGoはGo本体よりも小さなWASMができますが、一部標準ライブラリが動かないということがあります。最近はTinyGoでも不自由なくアプリが書けるように上記のリポジトリのいろんな部品がそろってきたのでだいぶ素早く作れるようになりました。
なお、雑に「速くして」とか指示を投げても小さな改善しか得られませんが「このぐらいまでメモリ減らせるはず」とかゴールを提示するとか「ページをまたいでも過去のメモリを保持し続けるところをやめて欲しい」とか具体的に指示したほうが最適化は進みますね。
また、お仕事の方で電子帳票のPDFが欲しいね、という話をしていたので、昔のブログを思い出してBDFを生成するテンプレートも作ってみました。PDF/A対応のBDF→PDF変換も作ったので長期保存もばっちり。
AI slopとはなんなのか
大体何かやりながらの作業ですが、だいたいこんな感じです。AI開発はだいたいこんなイメージというか1-2日ぐらいでコア部分は完成しますが、ただ実際にそれを使ったアプリを作らせてみたり、ドキュメントを作らせてから触ったりするとイマイチで・・・そこを直して性能を見てみたらちょっと思ったより遅い？パッケージ構成整理して・・・みたいなことをやると、だいたいのべ10日以上はかかる印象です。以下は実際にこれを作った記録です。
- 9/25に、ちょっと仕事で電車にのったときに、ふと思いついてClaudeのiPhoneアプリ上でクラウド開発を開始しました。その日のうちに、PDFとOfficeのビューアはだいたい完了
- 9/27あたりまでにCAD, Photoshop, Illustrator, CSV/Parquetなど主要なフォーマットに対応
- 9/28あたりは堅牢性の強化、セキュリティの強化、Webサイト作成
- 9/29からはLibreOffice変換との比較で、性能改善、メモリ消費削減などを開始, TinyGoによるWASM化
- 9/30はnpmパッケージ配布準備(v0.1.0)
- 10/4はebitengine用に数式レンダリングを独立して使えるようにパッケージ再構成やレンダラー追加
- 10/5はメモリ使用量と性能の劇的改善
- 10/7はサイトの完成とパッケージの更新(v0.1.2)
- 10/8は再度CPU使用率とメモリ使用量の大幅改善、音声ファイル対応追加
- 10/9に整理完了(v0.1.3)
- 10/10に文字列選択位置ずれ修正、検索の強化、コード整理(v0.1.4, v0.1.5)
AI slopという言葉を最近よくみます。生成AIを使って雑に作られたプロトタイプで品質などが低いもの、という扱いです。社長や企画の人がわっと作って「これリリースしてよ」みたいな話をXでは見かけます。
自分でやってみて思うのは、AIでさっと作ったものはまだ1合目。きちんと使い方を説明する文章を作ったり、その過程で「やっぱりこれもうちょっと直した方がいいや」みたいに思って直したり、実用的な品質までに高めるには10倍ぐらい見積もる必要がありますね。セキュリティとかも問題ないか調べさせたり・・・
セキュリティも性能もトークンが余りそうな時に、ClaudeのFable 5.1の強め設定や、Codex GPT-6 Astraの強めのやつでざっと数回依頼してやりました。AIで作らせるにしても、何度もやって「このぐらいは時間かかるよね」というスケジュール感を掴んでおくと良さそうですし、機能数勝負とかではなく、1回だけでいいので、しっかりと「自分が考える限りの最高品質」で作るチャレンジをしてみるのをお勧めします。
このぐらい何度もブラッシュアップをしていくと、だんだん「これも自分の作ったものだ」という感覚が出てきます。
実はAIがなかった時代もこのぐらいかかっていたのかもしれない、というのは最近思うところです。アジャイルとかでさっと動くコードを作る。パッケージ構成とかは事前にしっかり考えないと手を動かし始められないのでそこが後からブレることは少ない（なくはない）ので、20%ぐらいの手間で動くものができる。PRを出して相互レビューやセルフレビューで+10%。マージ後にステークホルダーのフィードバックで+10%。リリース後に新しいニーズが生まれてそれに対応するために+10%・・・みたいな。ウォーターフォールだとまず要件定義で「あったらいいな」みたいなのが徹底的に削られてゴールラインが-50%された上で最初の状態が30%。結合テストで+10%、システムテストで+10%みたいな。
一方で、AIはポン出しで10%スタート。それを100%に持っていくにはそれなりにエンジニアリングの知識が必要だったりするところを、その10%でよしとしてしまうところがAI slopの正体なのでは、と思ったりします。
まとめ
Officeファイルの表示など、「もっと効率よくできるはず！」とずっともやもやしていた過去の気持ちを整理するために始めたのですが、思った以上に成果が出て驚きました。勢いあまって、以前のプロジェクトで要望されていた、Illustratorファイルの表示、Photoshopのファイルの表示も含めて、CAD情報とか、今後利用が増えていくだろうdraw.ioとかいろんなファイルに対応してみました。フォーマット追加なんかはAIで並列に一気にできるし、だいぶ良いですね。数式もそれっぽく表示されるなど互換性もだいぶ高いと思います。
最初の一歩こそ10%程度でだいぶ荒削りかもしれないが、その後のブラッシュアップまで高速に自分の中だけで徹底的に行えたりするので、きちんとAIベースの開発プロセスを作ると、今までよりも圧倒的に良いものが出力できる素養はあるかと思います。一方でオーバーエンジニアリングのリスクもある気がしますが、そこは一度徹底的にやりこんでみないと限界ラインもわからないし、「これで十分」と言うラインも出てこない気がします。過去の案件の「今ならこうしたのに」という後悔駆動開発/反省駆動開発を元にした徹底的なAI駆動開発、みなさんもやってみてはどうでしょうか？