掲載済み (2026-01-06号)
#099 515文字 • 3分

## やってみたら思った以上にエンジニアだった公務員の奮闘記― 区職員×都庁ICT職が挑む、生成AIプロジェクト(後編)

日本語

掲載情報

概要

https://zenn.dev/govtechtokyo/articles/f86d033408b007

詳細内容

## やってみたら思った以上にエンジニアだった公務員の奮闘記― 区職員×都庁ICT職が挑む、生成AIプロジェクト(後編) https://zenn.dev/govtechtokyo/articles/f86d033408b007 Difyで構築した法令検索チャットボットのボトルネックを特定し、モデルの使い分けとプロンプトの最適化によって品質を維持したままコスト削減と高速化を実現する具体的な改善フローを提示する。 **Content Type**: 📖 Tutorial & Guide **Language**: ja **Scores**: Signal:5/5 | Depth:4/5 | Unique:3/5 | Practical:5/5 | Anti-Hype:4/5 **Main Journal**: 88/100 | **Annex Potential**: 82/100 | **Overall**: 84/100 **Topics**: [[Dify, LLM最適化, 行政DX, LLM-as-a-Judge, トークン管理]] Difyを用いた生成AI開発において、プロトタイプから実運用レベルへ昇華させるための具体的な最適化プロセスが公開された。著者はまず、構築した法令検索チャットボットをAPI経由でテストした際、レスポンスに1分以上かかり、コストも想定外に膨らんでいる現実に直面した。そこでAPIレスポンスに含まれる`usage`メタデータを詳細に分析し、原因が「法令全文をそのままプロンプトに注入していたこと」による入力トークンの肥大化にあることを突き止めた。 本記事の白眉は、単にモデルを安価なものに変えるのではなく、品質とコストのトレードオフをどう管理したかという点にある。筆者は以下の3つのエンジニアリングアプローチを実践している。 第一に、モデルの役割分担だ。前処理や要約などの補助的タスクには軽量な`gpt-4o-mini`を割り当て、法令の最終解釈のみに高精度モデルを使用する。 第二に、Difyのコードブロック(Python)を活用した「情報の節約」だ。知識ベースから取得した情報をそのままLLMに渡さず、必要な情報のみをプログラムで抽出・整形することで入力トークンを劇的に削減した。 第三に、ワークフローの並列化だ。前工程の依存関係を見直し、並列実行可能なノードを整理することでレイテンシを改善した。 さらに重要なのが、評価手法に「LLM-as-a-Judge」を導入している点だ。高精度モデルの回答を正解(基準)とし、最適化後の回答を別のLLMに定量評価させることで、品質を維持したまま調整を繰り返すサイクルを確立している。この結果、回答品質をほぼ維持したまま、コスト4割削減と応答待ち時間の半減を達成した。 Webエンジニアにとって、Difyのようなプラットフォームは「誰でも作れる」利点がある。しかし、本事例が示すように、実運用におけるボトルネックの特定や、トークン管理、定量的評価といった領域には、依然としてエンジニアリングの深い知見が不可欠だ。行政DXという高い信頼性が求められる現場で、ドメイン知識を持つ区職員と技術を担う都庁ICT職が協働し、この「実装の壁」を突破したプロセスは、あらゆるAIアプリケーション開発の参考になるだろう。