📣

Resilire Tech News 2026/02/23 — PDF対応と運用改善

に公開
resilire
technews
tech

サマリー

こんにちは、Resilireの技術ダイジェストへようこそ。

今週は、エクスポート基盤にPDFをどのように追加するかについての議論が活発に行われました。あわせて、リリース手順への追記やヘルスチェックエンドポイントの標準化など、運用面の小さな改善も進めています。

実装方法と運用方法の両面から検討する中で、設計と現場運用のバランスが重要であると改めて認識しました。PDFは一見シンプルに見えるものの、帳票要件や運用コスト、コンテナサイズ、パフォーマンスといった課題が絡みやすいため、まずは小さなPoCを実施し、その結果を踏まえてDataExporter周りのリファクタリングを進めるのが現実的だと考えています。

注目ポイント

  • Export基盤にPDF出力を追加する設計検討の本格化
    • 現状はExcel専用実装が強く結合しているためフォーマット拡張のためのアーキテクチャ変更案の議論
  • フロントvsサーバーでのPDF生成に関する実運用でのトレードオフの議論
  • 運用プロセスの小改善
    • リリース作業に手作業が入る場合はAsanaの該当タスクへの手順追記のルール化（週次のテンプレ更新の想定）
  • ヘルスチェック用エンドポイントの全プロダクト統一
  • ローカライズやデザイン→実装のワークフロー自動化、AI活用への関心継続

社内MTGでの様子（雰囲気レポート）

ざっくばらんに技術の選択肢を出し合う場になりました。ポイントごとに要点を整理します。

Export基盤の現状と問題意識

現行のExport基盤は「Excel前提」で実装が強く結合しています。ドメイン層に汎用的なDataExporterインターフェースはあるものの実装はExcel専用（Excel向けのWritableを返す処理がハードコーディングされている状態）です。非同期ワークフロー（API→Export登録→バッチで生成→ストレージ保存）の流れ自体は良いですがフォーマット追加時に実装が肥大化しやすい構造です。

議論された設計案（要旨）：

  • ExportEntityに"format":"pdf"を追加する分岐案
  • もしくはExportTypeを増やして「何を・どの形式で」を明示化する案
  • DataExporter実装をフォーマット単位に分割してDIで切り替える案

簡単なイメージ：

type DataExporter interface {
    Execute(ctx context.Context, export *Export) (*DataExporterResult, error)
}

このインターフェースはフォーマット非依存です。ただし実装を分割してformatに応じた実装を返すファクトリを導入する方向が現実的です。

PDF生成の技術選択肢と運用上の注意

社内では次のような選択肢が話題になりました。

  • フロント側（ブラウザ印刷）で完結するケース
    • 小規模・単発かつユーザーが即座にPDFを得るケース向けの選択肢
  • サーバーサイドでレンダリング（推奨候補）
    • headless Chrome、Puppeteer、wkhtmltopdf等によるHTML→PDF変換
    • サーバー上でテンプレートレンダリングしてファイルを生成しStorage（GCS等）へアップロードする方式
    • 注意点：コンテナイメージ肥大化・メモリ/CPU負荷問題への軽量化やリソース設計の重要性
  • 既製サービス利用の検討（例：Acrobat Services等）
    • Word→PDFやExcel→PDF変換を外部APIで処理する場合の運用コストと精度のバランスの検討
  • Javaベースの帳票ツール／レポーティングエンジン
    • 帳票関連の要件（複雑なレイアウト、電子署名、タイムスタンプ）に強い候補だが技術スタックや運用コストの考慮必要

運用面では「バッチで事前生成しておく」方式（オンデマンド生成の代替）が有力だという経験談が多くリソースピーク分散の利点があります。

実装で気にすべきこと（現場の合意点）

  • 非同期ワークフロー維持：APIは即座にExportIDを返す設計と実生成をバッチで行う運用（可観測性を保つログ／ステータス設計）
  • フォーマット拡張はインターフェース設計で吸収（フォーマットごとの実装分離）
  • コンテナサイズやライブラリ依存への注意：PDFツールによるイメージ肥大やランタイム依存への軽量化・外部サービス比較検討

運用ルール周りの小アップデート

  • リリース手順に手作業（パッチ等）が入る場合の該当リリースAsanaタスクへの手順追記ルール化
    • 朝会での記載リマインド
  • ヘルスチェックエンドポイントを全プロダクトで統一（/health/live、/health/ready）
    • 監視やオーケストレーションとの親和性向上が狙い

その他の雑談トピック（技術好奇心の種）

  • thinreportsなど帳票ツールの歴史と運用経験の共有
  • ローカライズ（locale）ファイルのAI学習によるワーディング統一やCIで新語検知の自動化案

最後に

Resilireでは一緒にこうした技術的チャレンジに取り組むメンバーを募集しています。興味がある方は採用ページをご覧ください：
https://careers.resilire.jp/

来週も社内の技術的な「気づき」をゆるっとお届けします。お楽しみにしてください。

Discussion