【要約】問い合わせから契約まで AI で一気通貫にする設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
多くのチームにおいて、問い合わせ対応は情報の転記や確認といった手作業が繰り返される非効率なフローとなっている。ツールが増えるほど情報の所在が不明確になる。また、LLMをシステムに組み込む際、以下の課題に直面する。
- ・出力の不安定性: プロンプトによるJSON生成では、キーの欠落やフォーマット崩れが頻発し、プログラムでの判定が困難になる。
- ・自動化のリスク: 全自動化は、AIの誤判断による致命的なミス（誤ったメール送信等）を招く恐れがある。
- ・情報の散逸: ツールが増えるほど、どこに情報が落ちているか把握できなくなる。
// Approach
開発者は、Claude APIのtool_useを活用し、業務プロセスを「分類」「収集」「生成」の3フェーズに分割して管理する設計を採用した。AIにすべてを任せず、制御可能な構造を構築している。
- ・構造化出力の強制: tool_useとtool_choiceを用い、LLMの回答形式を厳格に制御してパースエラーを防ぐ。
- ・人間による介入（Human-in-the-loop）: 質問生成と情報登録のステップに人間を介在させ、AIの暴走を防止する。
- ・状態管理の導入: SQLiteを用いて各フェーズの遷移とタイムスタンプを記録し、分析可能なログ設計とする。
// Result
この設計により、LLMの出力不備によるエラーを排除し、安定したパイプライン構築を実現した。単なる自動化に留まらず、業務改善のためのデータ基盤としても機能する。
- ・堅牢なデータ構造: tool_useにより、不足情報の有無などの判定が確実になった。
- ・分析基盤の構築: 問い合わせの種別や優先度、滞留時間をSQLで分析可能にした。
- ・リスク管理: 「止まる設計」により、法務確認や人間による内容確認をプロセスに確実に組み込めた。
Senior Engineer Insight
> 「AIに何をさせるか」ではなく「どこで止めるか」に焦点を当てた設計は、極めて実戦的である。全自動化の誘惑を断ち切り、人間による検証ステップを明示的に組み込んだ点は、信頼性が求められる業務システムにおいて高く評価できる。また、SQLiteを用いた状態管理により、単なる自動化ツールを「業務分析基盤」へと昇華させている点も、運用フェーズを見据えた優れた判断だ。