ラピッドプロトタイプの次に何を作るのか──企業内問い合わせAIを本番システムへ育てる実装手順

🎥 YouTubeでも公開しています

生成AI時代のラピッドプロトタイピング―「速く作る」から「速く学び、確かに決める」へ

Books: 生成AI時代のラピッドプロトタイピング: Streamlitで学び、Dockerで育てる AI業務システム

“生成AI時代に、ラピッドプロトタイピングをどう再定義するか ― Vibe Codingとの違いは、「速さ」ではなく「学習と判断」にある“で述べたラピッドプロトタイピングの目的は、早く動く画面を作ることではない。いまあるデータと実際の業務を使って、不確かな問いを早く学び、次の意思決定を確かなものにすることである。

では、試作品によって「この業務には価値がある」「必要なデータと人の確認箇所が見えてきた」と分かった後、次に何をすればよいのか。

ここからは、プロトタイプをそのまま本番化してはいけない。試作品は学習装置であり、本番システムは業務を継続的かつ安全に動かすための基盤である。目的も、設計原則も、完成の定義も違う。

本稿では、社内規程、IT、人事、総務などへの問い合わせを支援する企業内問い合わせAIを具体例に、ラピッドプロトタイプで得た学びを、Kiro、Claude Code、CodexのようなAI開発環境・開発エージェントも活用しながら、本番システムの実装へつなげる手順を示す。

具体的なユースケース──企業内問い合わせAI

想定するのは、従業員から寄せられる社内問い合わせに対して、社内規程、手順書、FAQ、申請状況、組織ルールをもとに、一次回答と適切な案内を行う業務である。

問い合わせは、たとえば次のような領域にまたがる。

• 経費精算、出張、休暇、福利厚生などの人事・総務問い合わせ
• PC、アカウント、ソフトウェア、ネットワークなどのIT問い合わせ
• 購買申請、契約、情報管理、セキュリティなどの業務ルール問い合わせ
• 申請の方法、必要書類、担当窓口、処理状況の確認

試作品では、質問文、所属部門、利用者ロール、対象制度、最新版の規程やFAQ、申請状態などを用い、次のいずれかを提案する。

• Act：根拠が十分で、本人が手続きや次の行動へ進める
• Ask：回答に必要な情報が不足しており、利用者へ追加確認が必要
• Stop：権限外の情報、個人情報、労務・法務判断、緊急インシデントなどで、自動回答を止めて専門窓口へ引き継ぐ

ここでAIが担うのは、人事・法務・情報セキュリティの最終判断を代替することではない。根拠のある情報検索、回答候補の整理、必要情報の確認、正しい窓口への案内、問い合わせ記録の作成である。例外判断と責任は、権限を持つ担当者が担う。

この線引きを最初に置くことで、本番化の論点が明確になる。本番で必要なのは「回答をもっと自然にすること」だけではない。情報の鮮度、アクセス権、回答根拠、個人情報、エスカレーション、監査、誤案内時の停止条件までを含めて、従業員の行動を安全に支えることである。

試作品から本番へ移す前に、まず「通過条件」を決める

本番実装を始める前に、プロトタイプの感想を要件に変換する。ここで曖昧なまま「便利そうなので本番化する」と進むと、再びHowだけが先行する。

最初に、次の四つを一枚の導入判定シートとして合意する。

さらに、プロトタイプで得た発見を三つに分ける。

1. 本番へ持ち込むもの：有効だった回答画面、根拠表示、追加質問、Act／Ask／Stopの考え方
2. 実装前に整えるもの：規程の正本、文書の更新責任、アクセス権、問い合わせ分類、引継ぎ先とSLA
3. 今回やらないもの：すべての制度領域への展開、個人別の高度な人事判断、外部システムの自動更新

本番の第一リリースは、「何でも答える社内AI」ではなく、対象制度と対象利用者を限定した安全に使える問い合わせ支援機能として定義する。

フェーズ0：既存環境を調査し、回答してよいこと・いけないことを記述する

既存の社内ポータル、文書基盤、申請システムへ接続する場合、実装より前の調査が重要になる。ここでKiroの仕様駆動フローや、Claude Code・Codexによるリポジトリと連携仕様の調査を使う価値がある。

調査で作るべき成果物は、単なる文書一覧やコード一覧ではない。少なくとも次を残す。

• 規程、手順書、FAQ、申請システム、組織情報がどこにあるか
• 各文書の正本、所有部門、改定日、承認状態、更新責任者
• 文書ごとの閲覧権限と、利用者属性による表示制御
• 申請状況など個人別データを取得する場合の本人確認と権限
• 問い合わせを受ける現行窓口、担当分担、SLA、エスカレーション基準
• 既存の監査ログ、障害時の連絡手順、サービス停止時の代替手段
• 自動回答してはいけない領域と、必ず人へ渡す条件

この段階では、AIに「チャットボットを実装して」と依頼しない。まず、回答の根拠となる情報がどこにあり、誰が更新し、誰に見せてよいかという、知識・権限・責任の地図を作る。

例えば、休暇制度の案内に古い規程と新しい規程が混在している場合、検索精度を上げても誤案内は防げない。この問題はモデル選定の問題ではなく、情報の正本と更新責任の問題である。

フェーズ1：本番仕様を、受入条件から書く

次に、チャット画面や技術構成より先に、利用者と担当者が確認できる受入条件を書く。KiroであればRequirements→Design→Tasksの順に仕様として残せる。Claude CodeやCodexを使う場合も、同じ内容をIssue、Markdown仕様書、PRテンプレート、テストケースとしてリポジトリに置く。

企業内問い合わせAIの第一リリースなら、受入条件は例えば次のようになる。

機能受入条件

• 従業員は、認証後に自分の所属・権限に応じた規程と手順だけを検索・参照できる。
• 回答には、根拠文書のタイトル、改定日、該当箇所へのリンクを表示する。
• 根拠が十分でない場合、AIは推測で回答を完結させず、Askとして追加質問または窓口案内を行う。
• 個人の申請状況を扱う場合、本人または権限を持つ管理者だけが参照できる。
• 利用者は、回答が役に立ったか、解決しなかったかを記録でき、必要なら担当窓口へ引き継げる。
• 引継ぎ時には、質問、確認済み情報、参照文書、AIの回答候補を担当者へ渡す。

非機能・統制受入条件

• 全ての質問、参照文書、回答、追加質問、エスカレーション、担当者の最終回答を監査ログへ残す。
• 権限のない利用者は、他者の申請情報、限定文書、個人情報を参照できない。
• 文書連携が失敗した場合、AIは最新情報であると断定せず、利用者に状況を示す。
• 緊急の情報セキュリティ事案や安全に関わる問い合わせは、自動回答を止め、緊急窓口を案内する。
• 障害時にも、従業員が既存の問い合わせ窓口と手続きへ戻れる。

この形式なら、実装の完了を「会話できる画面ができた」ではなく、「根拠、権限、引継ぎ、停止条件を含む受入条件を満たした」と定義できる。

フェーズ2：本番アーキテクチャを、知識と責任の流れとして設計する

本番システムは、チャット画面、LLM、ベクトル検索を並べただけの構成ではない。企業内問い合わせAIの場合、どの情報が入り、誰が見られ、何を根拠に回答し、どの条件で人へ渡され、何が記録されるかを設計する必要がある。

最小の本番構成は、次の六層で考えると整理しやすい。

AIの役割は検索・回答層に閉じ込める。AIが作った文章を、そのまま人事・法務判断や個人データ開示へつなげない。判断・権限層を必ず通し、条件に応じてAct、Ask、Stopを決める。この分離が、本番運用における安全性と説明可能性を作る。

フェーズ3：実装を小さなマイルストーンへ分割する

本番化を一括で進めると、完成間際に統合問題が集中する。そこで、各マイルストーンが独立して価値を持ち、かつテスト可能になるよう分割する。

マイルストーン1：認証、権限、根拠文書の閲覧

最初に作るのは会話機能ではなく、誰がどの文書と情報を見られるかという土台である。

• SSOまたは既存認証との連携
• 一般従業員、部門管理者、担当者、管理者のロール定義
• 文書・組織・個人データ単位のアクセス制御
• 監査ログの基盤
• 正本となる規程・FAQの一覧と閲覧画面

この段階の完了条件は、正しい利用者が正しい情報だけを見られ、権限外アクセスがテストで拒否されることである。

マイルストーン2：知識連携と鮮度・正本の可視化

次に、規程、手順書、FAQを取り込む。ただし、検索できることを成功としない。

• 文書の所有部門、版、改定日、承認状態を保存する
• 失効文書と重複文書を検出する
• 権限メタデータを検索結果へ反映する
• 取り込み失敗や古い情報をフラグ化する
• 画面で「この回答の根拠として使えない理由」を確認できるようにする

この段階で、「資料はあったが、誰が正しいと保証するか決まっていなかった」と気づけること自体が重要な成果になる。

マイルストーン3：根拠付きの検索・回答

最初の回答は、生成AIに自由回答をさせない。認証済み利用者が参照可能な承認済み文書を検索し、その範囲で根拠付きの回答を作るところから始める。

• 回答ごとに根拠文書と該当箇所を表示する
• 根拠が足りない場合は、回答を断定しない
• 改定日が古い場合、注意表示またはAskにする
• 回答テンプレートに「できること」「確認が必要なこと」「次の手続き」を分けて表示する
• 代表質問、言い換え、該当なし、矛盾する規程でテストする

例えば、出張規程に国内出張の情報しかないのに海外出張の質問を受けた場合、もっともらしい一般論を出すのではなく、Askとして対象制度の確認か担当窓口への引継ぎを行うべきである。

マイルストーン4：追加確認と人へのエスカレーション

企業内問い合わせで価値が出るのは、答えられる質問に答えることだけではない。答えられない質問を正しく扱うことにもある。

• 問い合わせ分類ごとの追加質問
• 労務、法務、個人情報、セキュリティのStop条件
• 担当部門、優先度、SLAを持つチケット起票
• 利用者がすでに伝えた情報と参照文書を引継ぎデータへ添付
• 緊急案件では、AIの会話を続けずに緊急連絡先を表示

人への引継ぎを「AIの失敗」として隠さない。どの質問でAskやStopが多いかを分析すれば、FAQ不足、制度の曖昧さ、手続き上の摩擦を次の改善へつなげられる。

マイルストーン5：個人別照会と手続き支援

制度案内が安定してから、個人の申請状況や手続き支援を限定的に追加する。

• 本人確認済みの利用者による申請状況照会
• 権限に応じた承認待ち案件の確認
• 手続きへのリンク、必要書類、期限の提示
• 個別状況を含む回答のマスキングと監査
• 変更や承認を伴う操作は、既存業務システムの権限・確認画面へ委譲

AIには、申請内容を勝手に変更・承認させない。AIは案内と確認を支援し、実際の変更は明示的な本人操作と既存の承認フローを通す。

マイルストーン6：監査、監視、復旧

本番システムは、正常時の回答画面だけで完成ではない。

• 誰が、いつ、何を質問し、どの文書を参照したか
• どの検索設定・モデル・プロンプト版を使ったか
• どの回答が解決、再質問、引継ぎ、停止になったか
• 文書連携やAI呼び出しが失敗したか
• 失敗時に何を再取込し、どの状態から復旧するか

これらをログ、メトリクス、アラート、運用手順として整える。障害時にAI機能を止めても、従業員が社内ポータル、手順書、既存窓口へ戻れる設計にしておくことが重要である。

Kiro、Claude Code、Codexをどう使い分けるか

本番実装では、ツールごとに役割を置くとよい。

重要なのは、ツールに完了判定を丸投げしないことだ。各マイルストーンに、少なくとも次のハードゲートを置く。

1. 型検査が通る
2. ユニットテスト、統合テスト、権限テストが通る
3. ビルドが通る
4. 入力、出力、文書アクセス、個人情報を対象にしたセキュリティ検査を通る
5. 実ブラウザで主要導線、引継ぎ、エラー時の案内を確認する
6. 受入条件に対する検証結果を記録する

Kiroはこの工程を一貫した仕様駆動フローとして作りやすい。Claude CodeとCodexでは、リポジトリのルール、CI、テスト、PRテンプレート、別エージェントのレビューとして同じ構造を構成できる。

本番前の検証は、回答品質だけで終わらせない

企業内問い合わせAIの検証は、「正答率が何％か」だけでは足りない。少なくとも以下を確認する。

この検証は、テスト用の理想的なFAQだけで終えない。実際の匿名化・マスキング済み問い合わせ、解決しにくい例外、規程改定直後のケースも用いて、ユーザー受入テストを行う。利用者の「便利だった」という感想だけでなく、どの質問でAskが多いか、どの理由で担当者が回答を修正したか、どこで引継ぎが滞留したかを観測する。

段階導入──最初から全社・全制度へ広げない

本番化は、全社展開ではなく限定運用から始める。

最初は一つの制度領域、一つの部門、公開済みの規程・FAQ、一つの問い合わせシナリオに限定する。おすすめの順序は次の通りである。

1. Shadow Mode：AIは回答候補と根拠を出すが、利用者へは直接回答せず、担当者が評価する。
2. Advisory Mode：公開FAQ・手順案内に限って利用者が使う。解決・未解決と引継ぎ理由を記録する。
3. Controlled Action：本人確認済みの低リスク照会や、既存申請画面への案内を支援する。
4. Scale：担当者の修正、誤案内、引継ぎ、監査結果をレビューし、対象制度を少しずつ広げる。

この順番なら、回答品質だけでなく、知識の更新責任、権限、現場の受容性、エスカレーション、運用負荷を確認しながら進められる。

結論──本番化とは、試作品を大きくすることではない

ラピッドプロトタイプの後に作るべき本番システムは、試作品の機能を増やしたものではない。

それは、従業員の問い合わせと行動を支援するために、知識の正本、情報の鮮度、AIの根拠、人の引継ぎ、権限、記録、停止、復旧を接続した仕組みである。

Kiroのような仕様駆動環境は、要件・設計・タスク・品質ゲートを揃え、計画的に実装する場面で力を発揮する。Claude CodeやCodexは、既存システムを調べ、横断的な変更を実行し、問題を解決していく場面で強い。

しかし、どのAI開発ツールを使うとしても、本番化の中心に置くべき問いは変わらない。

このシステムは、どの情報を根拠に、誰のどの行動を支援し、どの条件で追加確認を求め、どの条件で人へ引き継ぎ、止まるのか。

この問いを仕様、テスト、運用、監査のすべてに落とし込めたとき、ラピッドプロトタイプは初めて、企業で信頼して使える本番システムへ育っていく。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance