SHEET FIG.1 — /work/ai-assistant-platform
CASE STUDY § 01-1
エンタープライズ向け AI アシスタント基盤
要件定義 〜 本番
SCOPE — 全レイヤを一人で
日〜週 単位
LEAD TIME — 機能単位の提供サイクル
本番グレード
DELIVERY — PoC 止まりにしない
課題
エンタープライズへの AI 導入では、PoC と「顧客が実際に使える環境」の間に大きなギャップがある — セキュリティ要件、既存の文書資産との接続、回答品質の保証。ここを越えられず PoC 止まりになる案件は多い。
設計判断
- 機能単位で UI・API・インフラの全レイヤーを通す体制を取り、レイヤー間の待ち時間をなくす
- 回答の根拠 (どの文書に基づくか) の可視化を要件の中心に置き、顧客側で検証可能な AI にする
- 顧客の文書資産と RAG 基盤の接続を自動化 — 元の構造が持つ意味を失わずに取り込む
- 回答品質の問題は、生成側の調整より先にデータ・検索の各層を個別に検証する手順を取る
ノードにカーソル・フォーカス・タップすると、各要素の設計判断が表示されます。
- UI — 回答根拠 (どの文書に基づくか) の可視化を要件の中心に。顧客側で検証可能な AI にする。
- API — 顧客のセキュリティ要件に適合させ、PoC の速度を保ったまま本番グレードに引き上げる。
- LLM — 顧客要件に応じたプロバイダ構成。生成品質の問題は層別診断で切り分けてから手を入れる。
- RAG store — 外部ストレージからの取込を自動化。元の構造が持つ意味を保ったまま検索対象にする。
進め方
- 機能単位で要件定義から本番提供までを日〜週単位のサイクルで回す。顧客のセキュリティ要件を満たした状態で提供する
- 品質の問題はレイヤごとに切り分けてから対処する。調整より先に検証
- 文書取込の自動化など周辺の仕組みも、設計から本番投入まで同じ進め方で扱う