はじめに
これまでデータサイエンティストとして機械学習モデル開発や分析業務を中心に行ってきましたが、今回初めて、LLMを組み込んだ業務自動化システムの開発に携わりました。
Jupyter Notebook中心の分析業務と、実運用されるシステム開発では重視すべきポイントが大きく異なり、設計・実装・運用の各段階で多くの学びがありました。
本記事では、データサイエンティストがAIエージェント的な仕組みを含むシステム開発に挑戦する際、特に重要だと感じた点を整理して共有します。
※本記事は個人の技術的な学びの整理を目的としており、特定の業務内容・機密情報は含まれていません。
本記事でいう「AIエージェント」について
本記事では、LLMを組み込んだ業務自動化処理を便宜上「AIエージェント」と表現しています。
完全自律型の意思決定システムではなく、既存の業務ロジックやAPI連携に対し、自然言語処理による解析・判断補助を組み合わせた構成です。
対象読者
- データサイエンティスト・分析基盤担当の方
- LLMを業務システムに組み込むことを検討している方
- Notebook中心の開発からシステム開発へ広げたい方
データサイエンティストとシステム開発の違い
開発に携わる中で、データ分析と業務システム開発では
重視する観点が大きく異なると感じました。
| 観点 | データサイエンス | システム開発 |
|---|---|---|
| ゴール | 分析結果・モデル精度 | 安定稼働・業務効率化 |
| 環境 | Notebook中心 | 本番環境・API連携 |
| 成果物 | モデル・レポート | 継続運用されるシステム |
| 関心 | 精度・再現性 | 堅牢性・保守性 |
| 開発 | 試行錯誤中心 | 設計・運用重視 |
特に、
一度動くことより、継続して安定稼働すること
が最優先になる点は大きな違いでした。
システム概要
目的
自然言語形式の入力情報を解析し、
既存業務システムと連携して処理を実行する自動化支援システムの構築
技術構成
- Backend: FastAPI（Python）
- UI: Streamlit
- LLM: OpenAI API
- Storage: Azure Table Storage
- 外部連携: REST API（業務システム等）
処理イメージ
テキスト入力
↓
FastAPI（業務ロジック）
↓
LLM（内容解析・情報抽出）
↓
必要パラメータ整理
↓
外部システムAPI実行
↓
レスポンス整理・判定補助
↓
次処理の決定・実行
LLMの出力は補助情報として扱い、
最終的な処理分岐はシステム側ロジックで制御する構成としました。
LLMの主な利用用途
LLMは主に以下の用途で利用しました。
- 入力内容の分類・意図判定
- 必要パラメータの抽出
- 処理フロー分岐の補助
- APIレスポンス内容の整理・要約
LLMの出力をそのまま採用するのではなく、
以下の制御を組み合わせています。
- 出力フォーマット指定（JSON等）
- バリデーション処理
- 想定外出力時のフォールバック
- 条件分岐による最終判断
また、プロンプトはコードに直接記載せず、
調整・管理しやすい形で分離しました。
※実運用では送信対象データを制御し、機密情報・個人情報の取り扱いに配慮した設計としています。
開発で特に重要だったポイント
1. エラーハンドリング設計
分析環境ではエラー発生時に都度修正できますが、
システムでは事前対処が不可欠です。
実施内容：
- 外部API呼び出しの例外処理
- タイムアウト設定
- 入力バリデーション
- 詳細ログ出力
正常系だけでなく、異常系を前提に設計する必要がありました。
2. 非同期処理の理解
外部APIやLLM呼び出しを含む構成では、
非同期処理がパフォーマンスに大きく影響します。
対応：
- asyncio / awaitの利用
- 並列処理
- バックグラウンド実行
同期処理のままだと待機時間がボトルネックになりました。
3. データストア設計（NoSQL）
Azure Table Storageを利用したため、
RDBとは異なる設計思想が必要でした。
- アクセスパターンから設計
- PartitionKey設計
- 柔軟なスキーマ構成
正規化よりも、取得効率を優先した設計が重要でした。
4. UIによる状態可視化
処理が見えないとユーザーが不安になるため、
UIで状態を確認できるようにしました。
- 実行状況表示
- エラー内容表示
- 処理結果確認
ユーザー視点での可視化は想像以上に重要でした。
5. ワークフロー設計
単一処理ではなく、段階的な処理構成としました。
例：
- 入力解析
- パラメータ抽出
- 外部処理実行
- 結果整理
各フェーズを独立させ、
途中から再実行可能な構成としました。
6. 設定・シークレット管理
本番環境では設定外部化が不可欠です。
- 環境変数管理
- .env利用
- 設定クラス化
APIキー等はコードに直接記載しない運用としました。
7. ログ設計
障害時の原因特定にはログが不可欠でした。
- loggingモジュール利用
- ログレベル整理
- スタックトレース記録
早い段階で整備しておくべきと感じました。
8. テスト
システムの安定性確保のため、
ユニットテストと動作確認を実施しました。
- pytest利用
- 外部依存のモック化
- 正常系・異常系確認
テストがあることで安心して修正できます。
9. 運用視点
リリース後の運用も考慮した設計が必要でした。
- リトライ処理
- 状態確認手段
- ドキュメント整備
- ログ監視
開発段階から運用を意識することが重要でした。
新たに必要になったスキル
必須と感じたもの
- 非同期処理
- Web API設計
- ログ設計
- エラーハンドリング
- 環境変数管理
あると良いもの
- Docker
- pytest
- CI/CD
- 監視設計
- セキュリティ知識
まとめ
データサイエンティストとしてのスキルは、
AIエージェント的なシステム開発でも十分活かせます。
一方で、以下の意識転換が必要でした。
技術面
- 非同期処理の理解
- エラーハンドリングとログ設計
- システム設計と運用視点
マインド面
- 分析中心から運用中心へ
- 単発実行から継続稼働へ
- 個人利用からユーザー利用へ
同様にシステム開発へ踏み出す方の参考になれば幸いです。
※本記事は技術的な学びの整理を目的としたものであり、特定の業務内容・機密情報は含まれていません。