【要約】SlackにExcelを投げたらAIが返ってこない。ログとxlsx2csvで直した話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、Slackアプリ「Party on Slack」において、ユーザーからExcelファイルが送られた際に、AIの回答が極端に遅延、あるいは応答が途絶える問題に直面した。原因はLLMの推論速度ではなく、その前段階の処理に集約されていた。
- ・Slackからのファイル取得処理にタイムアウトがなく、ネットワーク遅延時にプロセスが停滞する。
- ・Excelの全セルを文字列連結する非効率な読み込みにより、メモリとトークンを過剰に消費する。
- ・読み込み量に上限がなく、巨大なファイルによってシステムが不安定になる。
- ・ログが詳細かつ構造化されていないため、ボトルネックの特定が困難である。
// Approach
開発チームは、AIエージェントを活用してHerokuのログやRedisのキュー状態を分析し、ボトルネックを「ファイル取得」「パース」「LLM応答」の各フェーズに切り分けて解決を図った。
- ・Slack APIのファイル取得に接続および読み取り用のタイムアウトを設定した。
- ・xlsx2csvを採用し、openpyxl使用時もread_only=True等でメモリ消費を抑えた。
- ・最大文字数（3,000,000文字）や行数等の上限を設け、超過時は注記を付与する仕様とした。
- ・複数シートを識別できるよう、シート名を含めたテキスト形式に変換した。
- ・機密情報を除いたメタ情報中心の構造化ログを整備した。
// Result
約1.1MB・17シートのExcelファイルを用いた検証において、パース時間を約0.27〜0.29秒に抑えることに成功した。
- ・処理フェーズを分離したことで、遅延の原因がパースではなくLLM生成やSlack投稿にあることを特定可能にした。
- ・リソース消費を制御しつつ、業務利用に耐えうるデータ取得を実現した。
- ・構造化ログにより、AIエージェントを用いた迅速なトラブルシューティングの基盤を構築した。
Senior Engineer Insight
> LLM連携システムにおいて、モデルの性能以上に「前処理の堅牢性」がUXを左右する。本事例は、ファイルサイズではなく「展開後のトークン量とメモリ消費」に着目しており、極めて実践的だ。特に、上限設定時に「一部のみ読み込み」と明示する設計は、AIのハルシネーションを防ぐ観点からも重要である。また、ログをメタ情報に絞り、AIによる解析を前提とするアプローチは、運用コスト削減に直結する優れた戦略といえる。