最終更新: 2026年8月27日
メール処理のオープンソース vs 商用 API: コストベネフィット分析 大規模に受信メールを処理することは、紙面上では見た目ほど簡単に思えます。メールはSMTPで届き、バックエンドがヘッダーと本文を読み取り、添付ファイルを抽出し、JSONペイロードやフォームデータを解析し、コンテンツをアプリケーションデータベースにルーティングします。
しかし、セルフホストの受信メールインフラを維持してきたエンジニアリングチームは現実を知っています: メールは現代のインターネット上で最も混沌としており、断片的で、エッジケースが多いプロトコルの一つです。
非標準のMIMEエンコーディングやマルチパート境界エラーからスパム対策、TLSハンドシェイク、文字セット検出、添付ファイルのサニタイズ、IPレピュテーション管理まで、受信メール処理はエンジニアリング時間を数百時間も迅速に消費し得ます。メール取り込みパイプラインを設計する際、ソフトウェアエンジニアリングリーダーは古典的なジレンマに直面します: オープンソースツール（Postfix、Haraka、Mailparserライブラリなど）を使用してカスタムパイプラインを構築・維持すべきか、あるいは商用API（SendGrid Inbound Parse、Postmark、Mailgun、AWS SESなど）に解析を委託すべきか？
このガイドでは、アーキテクチャ、インフラストラクチャのオーバーヘッド、隠れたエンジニアリングコスト、セキュリティコンプライアンス、そして長期的な総所有コスト（TCO）にわたって、両方のアプローチを分解して説明します。
1. アーキテクチャ概要: 両パラダイムの動作方法 トレードオフを理解するには、まず両方のパラダイムが要求するアーキテクチャを理解することから始めます。
+-------------------------------------------------------------------------------+ | 評価項目 | +-------------------------------------------------------------------------------+ [Sender] ---> (SMTP Port 25) ---> [MX Record / Ingestion Gateway] | **初期設定時間** | +----------------------------------------+------------------------------------+ | **直接現金コスト** | v v [ Open Source Pipeline ] [ Commercial Email API ] - **Mail Transfer Agent (MTA):** Postfix、Exim、Haraka、または Stalwart を使用して、ポート 25 の生の受信 SMTP 接続を処理します。 - **Security & Filtering Daemon:** Rspamd または SpamAssassin を使用したヒューリスティックなスパムフィルタリング、SPF/DKIM/DMARC 認証検証、そして添付ファイルスキャンのための ClamAV。 - **Parsing Library:** Node.最終更新: 2026年8月24日
ロスレスオーディオエンジニアリング：WAV と FLAC のデコード、パース、システム最適化 オーディオパイプライン、音声認識（STT）取り込みサービス、ゲームエンジン、または高忠実度ストリーミングプラットフォームを構築する際、適切なロスレスオーディオフォーマットを選択することは、CPUサイクル、メモリ帯域幅、ネットワーク転送コスト、そしてストレージインフラに直接影響します。
オーディオ愛好家はしばしば WAV と FLAC の音質（実際には同一で、どちらも非圧縮PCMサンプルをビット単位で再現）について議論しますが、ソフトウェアエンジニアやシステムアーキテクトは技術的観点から評価しなければなりません：コンテナのオーバーヘッド、バイトレベルの構造、圧縮・解凍の複雑さ、シークの使いやすさ、そしてデコード遅延。
この詳細な分析では、WAV と FLAC の内部アーキテクチャを検証し、計算上のトレードオフをベンチマークし、バイナリレイアウトを調査し、バックエンド、ネイティブ、組み込み実装向けの実用的なガイドラインを提供します。
1. アーキテクチャ概要とバイナリ内部 WAV と FLAC がシステム負荷下で異なる挙動を示す理由を理解するためには、両フォーマットがディスク上およびメモリ内で PCM（パルスコード変調）データをどのように構造化しているかを検証する必要があります。
+-----------------------------------------------------------------------+ | 技術的特徴 | +-----------------------------------------------------------------------+ | **圧縮率** | +-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+ | **エンコーディングコスト（CPU）** | +-----------------------------------------------------------------------+ | **デコードコスト（CPU）** | | **シーク時間** | | **HTTP上のストリーミング** | +-----------------------------------------------------------------------+ WAV: 標準的な非圧縮RIFFコンテナ WAV（Waveform Audio File Format）は、Microsoft と IBM の Resource Interchange File Format（RIFF）の応用です。これは、4 バイトの FourCC 識別子と 32 ビットのチャンク長ヘッダーを持つタグ付きバイトチャンクにデータを整理するコンテナです。
最も標準的な形態では、WAV ファイルは生の非圧縮 Linear PCM（LPCM）サンプルを含みます：
RIFF チャンクヘッダー: ファイルサイズと WAVE フォーマットタイプを宣言します。 fmt サブチャンク: サンプルレート（例：44100 Hz、48000 Hz）、ビット深度（16 ビット、24 ビット、32 ビット浮動小数点）、チャンネル数、バイトレート、ブロックアラインメントを定義します。 data サブチャンク: 圧縮やフレーミングオーバーヘッドなしで、生のインタリーブされたサンプル配列を含みます。 標準LPCM WAVヘッダーのバイナリレイアウト struct WAVHeader { // RIFF Chunk Descriptor uint8_t riff_header[4]; // "RIFF" uint32_t chunk_size; // Overall file size - 8 bytes uint8_t wave_header[4]; // "WAVE" // fmt Subchunk uint8_t fmt_header[4]; // "fmt " uint32_t subchunk1_size; // 16 for PCM uint16_t audio_format; // 1 for PCM, 3 for IEEE Float uint16_t num_channels; // 1 for Mono, 2 for Stereo uint32_t sample_rate; // e.最終更新日: 2026年8月20日
Web とモバイル向け PowerPoint (PPTX) の最適化 現代のプレゼンテーションは、もはや会議室のプロジェクターだけで行われるものではありません。現在、ピッチデック、トレーニングモジュール、営業資料、教育用スライドデックは、セルラーネットワークを介して共有され、スマートフォンで閲覧され、ウェブポータルに埋め込まれ、分散チーム間でストリーミングされます。
しかし、Microsoft PowerPoint、Apple Keynote、Google Slides などのデスクトップソフトウェアで作成された標準的な .pptx ファイルは、ウェブ向けに作られることはほとんどありません。最適化されていないプレゼンテーションは、圧縮されていない 4K 写真、埋め込まれた生音声、未使用のスライドレイアウトが多数、完全にパッケージ化されたフォントファミリーなどにより、簡単に 100 メガバイトを超えるサイズに膨れ上がります。ウェブ上で配信されたりモバイルデバイスで開かれたりすると、これらの重いファイルは次の問題を引き起こします：
遅い読み込み時間と過剰なモバイルデータ消費 壊れたタイポグラフィと不自然なテキストの再配置 遅延したタッチナビゲーションとモバイルブラウザでのレンダリングクラッシュ アクセシビリティの低さとエンゲージメント率の低下 この包括的なガイドでは、PPTX ファイルをシームレスなウェブおよびモバイル配信向けに最適化するための実践的な技術戦略と UX のベストプラクティスを概説しています。
1. アセットとメディアの最適化：無駄な重量を削減 メディアファイルは PPTX ファイル全体の肥大化の 85% 以上を占めています。PowerPoint は特に指示がない限り元のアセットサイズを保持するため、24 メガピクセルのカメラ写真をスライドに貼り付けると、サムネイルに縮小しても背景に 15 MB 全体のファイルが保存されます。
A. インテリジェントな画像圧縮 目標解像度 (DPI/PPI): モバイルおよび標準デスクトップ画面では、画像は 300 DPI（印刷標準）を必要としません。目標は 96 から 150 PPI。1920×1080 のスライドキャンバスは、画面上で占める最大寸法に合わせて画像をスケーリングするだけで済みます。 モダンフォーマット: 大容量の非圧縮 PNG や BMP を、写真用の最適化 JPEG またはアイコンや線画用の SVG/ベクターシェイプに変換します。 ネイティブ PowerPoint 圧縮: デッキ内の任意の画像を選択します。 Picture Format > Compress Pictures に移動します。 プレゼンテーション全体を処理するには、“Apply only to this picture” のチェックを外します。 Web (150 ppi) または Email (96 ppi) を選択します。 隠れた未使用の画像データを永久に削除するには、“Delete cropped areas of pictures” にチェックを入れます。 B.最終更新: 2026年8月20日
HEIC vs JPEG の解説：iPhoneがデフォルトでJPEGで撮影しない本当の理由 iPhoneからWindows PCへ写真を転送したことがある、または最近のスナップショットを古いウェブプラットフォームにアップロードしようとしたことがあるなら、奇妙なファイル拡張子「.heic」に出くわしたことがあるでしょう。
20年以上にわたり、JPEG（Joint Photographic Experts Group） はデジタル画像の普遍的な標準として君臨してきました。初期のデジタルカメラから最新のモバイルウェブまで、あらゆるものを支えてきました。しかし、2017年に iOS 11 と macOS High Sierra がリリースされたとき、Apple は大胆で業界を揺るがす決断を下しました。JPEG を格下げし、HEIC をすべての iOS デバイスのデフォルト撮影フォーマットに据えたのです。
なぜ Apple は地球上で最も汎用性の高い画像フォーマットを放棄したのでしょうか？HEIC は本当に優れているのか、それとも別の壁の中の頭痛の種に過ぎないのか？
技術的な違い、実用的な利点、互換性の壁、そして両方のフォーマットをシームレスに扱う方法を分かりやすく解説しましょう。
JPEGとは何か？JPEG ユニバーサルベテラン 1992年に導入された JPEG（主に .jpg や .jpeg として保存されます）は、重要な課題を解決するために設計されました。デジタル画像ファイルは当時のコンピュータストレージや初期のインターネット回線に対して非常に大きすぎたのです。
JPEGは非可逆圧縮を使用し、人間の目が容易に認識できない微妙な視覚データを破棄します。その時代において、ファイルサイズと視覚的忠実度の理想的なバランスを実現しました。
JPEGの強み ユニバーサル互換性: すべてのオペレーティングシステム、ブラウザ、スマートテレビ、フォトプリンター、そしてソーシャルメディアプラットフォームは、JPEGをネイティブにデコードできます。 低い処理オーバーヘッド: JPEGのエンコードとデコードには最小限の計算リソースしか必要としません。 予測可能なパフォーマンス: JPEGのハードウェアアクセラレーションは、過去25年間に製造された事実上すべてのシリコンチップに組み込まれています。 JPEGの制限 時代遅れの圧縮アルゴリズム: ファイルを過度に圧縮すると、圧縮アーティファクト（ブロックノイズや色バンディング）がすぐに現れます。 限定された色深度: JPEGは8ビットカラーのみをサポートし、パレットは約1670万色に制限されます。 高度なデータへのネイティブサポートなし: JPEGは画像バースト、深度マップ、透過性、または補助音声を単一のファイルコンテナに保存できません。 HEICとは何ですか？ 現代の重量級 HEIC は 高効率画像コンテナ の略です。これは Apple が実装した、Moving Picture Experts Group (MPEG) が開発した広範な HEIF（High Efficiency Image File Format） 標準の実装です。MP4 や AVC などの最新ビデオ規格の背後にいるコンソーシアムと同じです。最終更新: 2026年8月11日
2026年の開発者向けトップオープンソース CAD API とライブラリ コンピュータ支援設計（CAD）は、もはや従来のデスクトップアプリケーションに限定されません。開発者はオープンソースのCAD APIやライブラリを使用して、カスタム設計ツールの作成、エンジニアリングワークフローの自動化、2Dおよび3Dモデルの生成、CADファイルの処理、そしてジオメトリ機能をウェブやデスクトップアプリケーションに統合できます。
多くのソフトウェアプロジェクトにとって、ゼロから完全なCADエンジンを構築することは実用的ではありません。CADは複雑な数式演算、幾何計算、トポロジー、サーフェス、曲線、メッシュ、ファイルフォーマット、そして可視化を伴います。オープンソースのCADライブラリは、開発者に再利用可能な部品を提供し、開発時間を大幅に短縮できます。
2026年には、開発者は選択できる成熟したオープンソースオプションがいくつかあります。あるプロジェクトはスクリプト機能を備えた完全なCADアプリケーションを提供し、他のプロジェクトはジオメトリカーネル、計算幾何学ライブラリ、またはCAD-as-codeフレームワークとして機能します。
人気のプロジェクトには Open CASCADE Technology、FreeCAD、CadQuery、build123d、OpenSCAD、CGAL、LibreCAD、BRL-CAD、SolveSpace などがあります。各プロジェクトは目的やプログラミングモデルが異なります。産業向けの 3D モデリングに適したものもあれば、2D 製図、パラメトリック設計、CAD 自動化、計算幾何学、3D プリントにより適したものもあります。本ガイドでは、2026 年に開発者が検討すべきトップのオープンソース CAD API とライブラリ、その主な機能、対応プログラミング言語、ユースケース、利点、制限について解説します。
オープンソース CAD API とライブラリは何ですか？ オープンソースの CAD API またはライブラリは、開発者が自分のアプリケーションに組み込んでコンピュータ支援設計データを扱える、再利用可能なプログラミングコンポーネントの集合です。プロジェクトによっては、CAD ライブラリが以下の機能を提供することがあります：
2D 図面作成と製図 3D ソリッドモデリング パラメトリックモデリング 境界表現 (B-Rep) 構成的ソリッドジオメトリ (CSG) サーフェスモデリング 曲線処理 ブール演算 メッシュ生成 ジオメトリ解析 CADファイル変換 CAD可視化 STEP処理 IGES処理 DXF 処理 STL 生成 エンジニアリング自動化 計算幾何学 この機能をすべて独自に開発する代わりに、プログラマーは既存のオープンソースプロジェクトをアプリケーションの基盤として利用できます。
例えば、開発者はユーザーが機械部品の寸法を入力できるウェブアプリケーションを作成できます。そのアプリケーションはこれらのパラメータを CAD ライブラリに送信し、3D モデルを生成し、STEP または STL としてエクスポートできます。この種のワークフローは、プログラム可能な CAD が現代のソフトウェア開発でますます有用になっている理由を示しています。
なぜオープンソース CAD ライブラリを使用するのか？ 開発者がジオメトリ機能を自分で実装する代わりにオープンソース CAD API を選択する理由はいくつかあります。最終更新日: 2026年8月11日
CADファイル形式の比較：DWG、DXF、DGN、そしてDWF Computer-Aided Design (CAD) は、エンジニア、建築家、製造業者、デザイナーが技術図面や 3D モデルを作成する方法を変革しました。超高層ビル、機械部品、道路網、電気システムの設計であっても、選択するファイル形式は、コラボレーション、互換性、長期的なプロジェクト管理において重要な役割を果たします。
現在利用可能な数百の CAD フォーマットの中で、DWG、DXF、DGN、DWF は業界全体で最も広く使用されています。各フォーマットは異なる目的で作成されており、特定のワークフローに適しています。
本ガイドでは、これら4つの人気 CAD ファイルフォーマットを検討し、その強みを比較し、理想的な使用ケースを議論し、ソフトウェア開発者が最新のオープンソースライブラリや API を使用してそれらと連携する方法を解説します。
CADファイル形式が重要な理由 適切な CAD ファイルフォーマットを選択することは、単に図面を保存する以上の影響があります。
適切なフォーマットはチームを支援します：
異なる CAD アプリケーション間で図面を交換する 設計精度を保つ 互換性の問題を減らす 長期アーカイブを可能にする エンジニアリングチーム間の協力を改善する 製造および建設ワークフローをサポートする クライアントとの文書共有を簡素化する これらのフォーマット間の違いを理解することで、専門家は情報に基づいた判断ができ、生産性の向上につながります。
DWGとは？ DWGは最も古く、最も認知されたCADファイルフォーマットの一つです。もともとAutoCAD向けに開発され、2D図面と3Dモデルの両方を保存する業界標準となっています。
テキストベースのフォーマットとは異なり、DWG は情報をコンパクトなバイナリ構造で保存し、詳細なジオメトリとメタデータを保持しながらファイルサイズを比較的小さくします。
主な特徴 2D と 3D の両方の設計をサポート レイヤー、寸法、注釈、レイアウトを保存 効率的なバイナリストレージ ブロックと再利用可能なコンポーネントをサポート 多くの商用 CAD アプリケーションと互換性があります 利点 優れたパフォーマンス 高度に詳細なモデル 業界標準 リッチオブジェクトのサポート 建築家やエンジニアに広く受け入れられている 制限事項 独自フォーマット リバースエンジニアリングは歴史的に困難でした 互換性はソフトウェアのバージョン間で異なる場合があります 一般的な使用例 建築図面 機械工学 土木工学 製造業 製品設計 DXFとは何ですか？ DXF（Drawing Exchange Format）は、主要な問題の一つである、異なるソフトウェア間でCAD図面を交換することを解決するために作成されました。
DWGとは異なり、DXFはASCIIテキストとして保存できるため、開発者やサードパーティのアプリケーションが読み取りや生成を行いやすくなります。
バイナリDXFバージョンも存在しますが、相互運用性のためにASCII DXFは依然として非常に人気があります。最終更新: 11 Aug, 2026
ブラウザが画像をデコードする方法：PNG、JPEG、WebP の舞台裏 画像は現代のウェブサイトで最も重要な要素のひとつです。製品写真、ソーシャルメディアの投稿、ダッシュボード、インタラクティブなアプリケーションを閲覧する際、ブラウザは常に背後で画像をダウンロード、デコード、レンダリングしています。
多くの開発者は PNG、JPEG、WebP が品質と圧縮率で異なることは知っていますが、画像がブラウザに届いた後に実際に何が起こるかを理解している人ははるかに少ないです。
この記事では、画像デコードの全ライフサイクルを探り、ブラウザがさまざまな画像フォーマットをどのように処理するかを説明し、ウェブサイトの速度とユーザー体験を向上させる実践的な最適化ヒントを共有します。
画像デコードが重要な理由 画像デコードとは、圧縮された画像データを GPU やディスプレイが描画できる生のピクセルに変換するプロセスです。
ウェブページに表示されるすべての画像は、いくつかの段階を経ます：
ダウンロード ファイルの解析 画像データの解凍 ピクセルのデコード カラープロファイルの適用 ピクセルをGPUにアップロード 画面へのレンダリング これらのステップはミリ秒単位で実行されますが、非効率的な画像はページ読み込み時間、CPU使用率、バッテリー消費、メモリ使用量を大幅に増加させる可能性があります。
最新のウェブサイトでは、画像デコードの最適化は画像ファイルサイズの削減と同様に重要です。
ブラウザの画像パイプライン 簡略化されたブラウザの画像パイプラインは次のようになります：
Server │ ▼ Download Image │ ▼ Read Image Header │ ▼ Choose Decoder │ ▼ Decompress Data │ ▼ Decode Pixels │ ▼ Color Correction │ ▼ GPU Upload │ ▼ Render to Screen Chrome、Firefox、Safari、Edge を含むすべてのブラウザは、内部の画像ライブラリは異なるものの、類似したワークフローに従います。
ステップ 1: 画像のダウンロード HTML に画像が含まれている場合：
8月 3, 2026 · 2 分 · Sher Azam最終更新: 2026年7月30日
TL;DR – CBZ（Comic Book Zip）は、連続画像用のシンプルなオープンスタンダードコンテナです。作成は簡単（zipして名前を変えるだけ）で、すべてのOSで動作します。最適なワークフローは、高速で機能豊富なリーダー（CDisplayEx、Perfect Viewer、YACReader など）と軽量な作成ツール（Krita、ImageMagick、ComicTagger、Calibre）を組み合わせることです。メタデータ用に ComicInfo.xml ファイルを追加し、画像は賢く圧縮し、クラウドまたはセルフホストの PWA でライブラリを同期すれば、どのデバイスでもシームレスに読めます。
1. CBZとは何か、そしてなぜ今でも優位にあるのか 定義 – CBZ は、一連の画像ファイル（JPG、PNG、GIF、WebP…）を保持する ZIP アーカイブです。「.cbz」拡張子は、コミック閲覧ソフトに ZIP を単一の書籍として扱うよう指示します。 オープンスタンダードの利点 DRM も独自コーデックも不要 – 解凍できる OS ならどれでも読めます。 手動で簡単に作成可能: zip -r MyComic.cbz *.jpg で完了です。 他のコンテナ（CBR = RAR、CBT = TAR、CB7 = 7‑ZIP）でも動作します – ほとんどのリーダーがすべてサポートしています。 ファイルサイズのコツ – ラインアートのパネルにはロスレスPNG、写真ページにはJPEG/WebPを使用します。jpegoptim、pngquant、または ImageMagick の -quality フラグを実行して、可読性を損なうことなくモバイルダウンロードを約10 MB 未満に保ちます。 メタデータは重要です – ほとんどのリーダーは ComicInfo.xml ファイル（ComicRack 標準）を探します。このファイルはタイトル、作者、シリーズ、号数、タグ、さらにはページレベルのノートを保存します。適切なメタデータにより、Calibre や YACReader などのライブラリ管理ツールが自動的にコレクションをソートおよび検索できるようになります。 法的注意 – CBZ は単なるコンテナであり、画像の著作権は残ります。常に合法的に入手したコミックを使用し、クリエイターの権利を尊重してください。 2. CBZの閲覧: プラットフォーム別おすすめツール プラットフォーム ツール 際立つ理由 価格 Windows CDisplayEx 超高速ロード、オートフィット、見開きページ、完全な ComicInfo.最終更新: 2026年7月29日
TL;DR – CBZ は ZIP ベースのコミックコンテナで、普遍的にサポートされ、無料で高速です。CBR は RAR ベースのコンテナで、専有コーデックとやや遅い抽出の代償として、各号から数メガバイトをさらに圧縮します。ほとんどの読者とクリエイターにとって、CBZ は安全で将来性のある選択肢です。すべてのバイトを節約したい場合や、すでにすべての対象デバイスに RAR デコーダがある場合にのみ CBR を選んでください。
1. CBZ と CBR とは何ですか？（“コンテナ” の基本） CBZ（Comic Book ZIP）と CBR（Comic Book RAR）はどちらも コンテナ であり、単に画像ファイルのシリーズ（通常は JPEG または PNG）を読むべき順序でまとめただけです。
CBZ = .cbz 拡張子にリネームされた通常の .zip アーカイブです。 CBR = .cbr 拡張子にリネームされた通常の .rar アーカイブです。 これらは単なるアーカイブであるため、どちらの形式にも DRM は含まれていません；コピー保護はコンテナ自体ではなく配布者によって追加されます。ページ順序に関係する唯一の要素は命名規則です（例：001.jpg、002.jpg、…）。
機能 CBZ CBR 基礎アーカイブ ZIP（オープンソース） RAR（プロプライエタリ） 圧縮アルゴリズム Deflate（ロスレス） LZMA/LZ77（高圧縮率） 典型的な号サイズ 30‑120 MB 25‑100 MB (≈ 5‑15 % smaller) プラットフォームのサポート Windows/macOS/Linux に組み込まれています WinRAR/UnRAR または互換デコーダが必要です 法的・ロイヤリティ状況 100 % 無料 商用コーデック、ライセンスが必要になる場合があります 2.最終更新日: 2026年7月28日
TL;DR CBZ（Comic Book Zip）は、連続した画像ファイルのシリーズとオプションのメタデータを単一のDRMフリーのコミックコンテナにまとめた、標準的なZIPアーカイブにすぎません。広く使われているZIP形式に依存しているため、任意のアーカイブツールで開くことができ、リーダーは画像をアルファベット順に並べてページを順番に表示します。最新のCBZはしばしばリッチなライブラリデータのために ComicInfo.xml を含み、WebPやAVIFといった効率的な画像コーデックを使用し、さらにはインタラクティブな「拡張」コミックのためにHTMLを埋め込むことさえあります。
CBZとは正確には何ですか？ 名前: Comic Book Zip – .cbz 拡張子を持つZIPファイルです。 MIMEタイプ: application/vnd.comicbook+zip（2012年にIANAに登録）。 起源: ComicRackコミュニティ（2005‑2008）によって普及し、CBRやPDFといった独自フォーマットのオープンソース代替として広まりました。 クロスプラットフォーム: 任意のZIP対応ユーティリティ（7‑Zip、WinRAR、macOS Archive Utility、Linux の unzip）で開くことができます。内容を確認するために特別なソフトウェアは必要ありません。 実際には、CBZ は画像（JPEG、PNG、WebP、など）を圧縮して名前を変更しただけです。そのシンプルさが、PC、タブレット、スマートフォンでデジタルコミックの事実上の標準となっている理由です。
CBZの内部：ファイル構造 適切に作成された CBZ はフラットな階層構造に従います—余分な入れ子はありません—ので、リーダーはページを瞬時に見つけられます。以下は典型的なツリービューです：
MyComic.cbz │ ├─ 001.jpg ← first page (front cover) ├─ 002.jpg ├─ 003.jpg │ … ├─ 050.jpg ← last page (back cover) ├─ ComicInfo.xml ← optional rich metadata └─ cover.jpg ← optional thumbnail for library views 主要な要素 要素 内容 重要性 連続画像ファイル アルファベット順に並ぶように名前が付けられています（001.