AI/LLM デリバリー — 要件整理から受入検証まで

課題

AI/LLM の PoC が動くことと、利用者が業務で検証できることは同じではない。曖昧な要求、認証・運用上の制約、回答根拠、承認の扱いを詰めないまま実装すると、デモから先へ進めない。

担当範囲

• 顧客ヒアリングで得た要求と環境制約を、技術要件・受入条件へ翻訳
• アプリ層を主担当として、フロントエンド、API、RAG、データ、IaC、デプロイを横断
• 顧客・プロダクト・基盤担当者の間で、認証、運用、障害対応の境界を調整
• 製品本体への機能統合と顧客検証環境へのデリバリーを、異なる受入条件として管理

設計・進め方

• 利用者が回答の出典を確認できることを、実装前の要件として定義する
• 人の入力、AI の下書き、検索結果、人による承認を分離し、確定前の情報が混ざらないデータ境界を置く
• 不具合は画面、API、データ、検索、生成、クラウドの層ごとに対照条件を作り、テストの成否だけで原因を決めない
• AI コーディングエージェントを使う場合も、実装者とレビュー役を分け、受入条件・テスト結果・画面証拠を残す
• 未検証事項と外部依存を明示し、自分の担当範囲を越えた成果を主張しない

実際にやったこと

• ヒアリングと承認の仕組み: AI が現場のベテランに質問して知見の下書きを作り、現場の責任者が承認したものだけを、版と承認状態を付けて社内検索の対象に書き戻した。未承認は検索から外し、差戻しの理由も記録する。本番の運用では、AI の一次の見立て（暗黙知か形式知か）と責任者の判断が承認件数の過半で分かれ、確定を人の承認に通す作りが必要だったことを自分のデータで確かめた
• 反応を見て直す速さ: 現場で初めて本格的に使ってもらった日に責任者から受けた指摘は、その夜に原因を特定し、翌未明には検証環境で大半の解消を確かめた。一方で、指摘の外にある挙動の変更を試行の直前に入れて混乱させたこともある。以後は「文言や表示はすぐ直す、挙動の変更は実データを見てから、顧客の試行前は挙動を変えない」と決めている
• 評価の前提を疑う: 回答品質の調整を頼まれた案件で、評価に使われたデータと、検索が実際に参照しているデータの中身を API で突き合わせ、両者が食い違っていることを突き止めた。プロンプトを直しても効かない状態だったので調整を止め、評価の前提を揃えるところからやり直した

進め方

• ヒアリング結果と環境制約を、技術要件・受入条件・未検証事項へ分解して実装へつなぐ
• フロントエンド、API、検索・生成、データ、クラウドを層別に検証し、問題の責任境界と根本原因を明確にする
• 回答根拠と人による承認状態をデータとして扱い、未承認の内容が確定知識として検索されない境界を設計する
• AI コーディングエージェントを調査・実装・レビュー・視覚 QA に分け、テストと差分証拠をリリース判断に使う
• 本番の設定やプロンプトは直接書き換えず、別環境で効き目を確かめてから反映する。外部ストレージ連携も、認証情報を渡すまで本番の定期実行を止めておき、段階を踏んで有効にする