この記事で分かること
- AIシステム開発の工程と、戻って見直すべき分岐点
- 企画・要件定義・検証・導入で必要な成果物と担当
- 運用を始めてから精度と費用を見直す方法
まず全体像をつかむ：工程は一方向に進むだけではない
開発を「企画→要件定義→データ準備→小規模検証→本番設計・開発→受け入れ→運用」と並べると、必要な会議や成果物を整理しやすくなります。ただし、これは各工程を一度で通過するという意味ではありません。検証で期待した結果が出なければ、データの範囲や業務の選び方へ戻ります。本番テストで確認負担が大きいと判明したら、画面や承認フローを見直します。戻ることを失敗と見なさず、判断の記録を残すことが肝心です。
次の表は、一枚の図として社内で共有できるよう、工程の入口と出口を対応させたものです。左から右へ作業を進めつつ、出口の条件を満たせない場合は原因のある工程へ矢印を戻す、と読んでください。リスクや利用人数が大きい案件ほど確認内容は増えますが、何を解決し、使えるかを確かめる基本の流れは共通です。
| 流れ | 決めること | 残すもの | 次へ進む目安 |
|---|---|---|---|
| 企画 | 対象業務と改善目標 | 課題整理シート | 現状値と責任者が明確 |
| 要件定義 | 入力・出力・人の確認範囲 | 業務フローと受け入れ条件 | 例外と停止条件を説明できる |
| データ準備 | 使用可否と品質 | データ台帳と評価用サンプル | 権限と欠損を確認済み |
| 小規模検証 | 採用する方式と判定基準 | 検証結果・費用試算 | 本番化の条件に照らして判断 |
| 開発・受け入れ | 連携・画面・監視・教育 | 仕様・試験記録・運用手順 | 現場と管理者が利用を承認 |
| 運用・改善 | 効果と不具合の見直し | 利用ログ・改善記録 | 継続・縮小・停止を判断 |
図の読み方：最初に業務の入口と出口を描く
たとえば問い合わせ回答を支援するなら、入口は「担当者が質問を受け取る」、出口は「確認済みの回答を送る」です。AIがどこで文書を探し、どこで回答案を作り、誰が確認して送信するかを一本の線にします。この線が描けないうちは、モデルの比較だけをしても必要な画面やデータが決まりません。
既存の手順にAIを足せば済むとは限りません。質問の振り分け、文書の更新、担当者への引き継ぎに詰まりがある場合、業務整理や既存システムの改修が先に効くこともあります。開発前診断・ロードマップのように現状を整理する工程を設けると、AIを使う範囲を無理なく絞れます。
企画：AIに任せる作業ではなく、改善したい結果を定める
企画書の最初に書くのは「生成AIを導入する」ではなく、現在の仕事に生じている時間、品質、引き継ぎの問題です。「月末の集計に時間がかかる」だけでは、どの工程に手間が集中するか分かりません。入力データの収集、表記の揺れの修正、集計、説明資料の作成に分け、現状の所要時間と発生頻度を確認します。改善対象を一つ選ぶことで、検証の結果を比べられます。
利用する人、承認する人、予算を持つ人も分けて記します。担当者には使いやすく見えても、管理者が監査に必要な履歴を取得できなければ採用できません。逆に、管理画面を充実させても、現場が別画面へ何度も転記する構成なら定着しません。企画の段階で関係者に実際の作業を見せてもらい、判断が変わる場面を拾います。
企画の出口は、対象業務、改善指標、対象外、予算と期限、責任者を一枚で説明できる状態です。ここでAI以外の選択肢も比較します。ルールが明確な処理は通常のプログラムや既存機能、定型入力は自動化ツールで十分かもしれません。比較表を作るときは初期費用だけでなく、例外処理、確認作業、継続的な利用料まで含めます。検討の入口はAI受託開発・生成AI導入支援の対象業務例も参考になります。
要件定義：精度の数字より先に、判断と責任の境界を引く
要件定義では「高精度に回答する」と書くだけでは不足します。どの情報を入力し、どの資料を根拠に使い、回答できないときに何を表示し、誰が最終判断するかを定めます。社内文書検索なら、検索対象の更新頻度や部署別の閲覧権限も要件です。古い版を優先して引用したり、権限外の資料を回答に混ぜたりすれば、文章が自然でも業務上は不合格です。
期待する出力は、正しい例だけでなく、断るべき例、確認へ回す例でも示します。実際の質問を匿名化して、通常ケース、曖昧な質問、資料に答えがない質問、誤字を含む質問を揃えましょう。正解の文章が一つでない場合は、「必要な項目を含む」「根拠文書を示す」「推測を断定しない」などの観点で評価します。判断基準の具体化はAIシステム開発の要件定義でも詳しく整理しています。
ここで非機能要件も忘れずに扱います。応答時間、同時利用者、障害時の代替手順、ログの保存、個人情報の扱い、利用料の上限です。すべてを最初から厳密な数値に固定する必要はありませんが、未決定の項目は誰がいつ決めるか記録します。要件定義の出口は、現場・管理者・開発側が同じサンプルを見て「何なら使えるか」を説明できる状態です。
要件を一枚に落とすときの配置
一枚の要件シートには、左に業務の入力と使うデータ、中央にAIの処理、右に人の確認と次の操作を置くと流れが見えます。下段に失敗時の挙動と評価条件を記すと、通常ケースだけで仕様を決めてしまうことを防げます。個別の詳細仕様は後から追加できますが、最初の一枚で関係者の認識が合うかを確認してください。
データ準備と小規模検証：使える条件を実データで確かめる
AIの検証前に、資料やデータの所在、管理者、利用許可、更新時期を調べます。販売データの項目名が店舗ごとに違う場合、まず定義を合わせなければ、分析結果を比較できません。社内文書でも、同じ規程の旧版が複数残っていれば、検索対象の選定が必要です。個人情報や契約上の制約があるデータは、利用目的と取り扱いを確認してから検証へ進めます。
PoCでは、成功しやすい例だけを並べないようにします。普段の入力に近いサンプルを用意し、難しい例と例外も混ぜます。採点者が結果を見ながら基準を変更すると、見かけの精度だけが上がります。事前に合格条件と検証件数の考え方を決め、出力の品質、確認にかかった時間、処理費用を記録します。判断は「使えそう」という印象ではなく、対象業務で許容できる負担かどうかで行います。
検証結果が悪い場合は、モデルの変更だけを急がないでください。入力の欠落、文書の版管理、質問の分類、期待する回答の曖昧さを順に切り分けます。原因によってはデータ整備に戻り、対象業務を狭め、あるいはAIを使わない案へ切り替える方が合理的です。検証の出口は「本番化」「条件付きで再検証」「見送り」のいずれかを、根拠と費用とともに決めた記録です。
本番開発と受け入れ：現場の仕事として使えるかを試す
検証用の画面が動くことと、日々の仕事で使えることは別です。本番ではログイン、権限、既存システムとの連携、データ更新、障害時の通知が加わります。AIの回答を人が確認する設計なら、元資料に戻れる導線、修正しやすい画面、保留や差し戻しの操作も必要です。システム全体で何が起きたか追えるよう、入力、参照したデータ、出力、承認の履歴を用途に応じて記録します。
受け入れテストには開発側だけでなく、実際の利用者と管理者が参加します。正常な例に加え、資料が見つからない、権限がない、AIが曖昧な回答を返す、外部サービスが停止する、といった場面を試します。停止時に誰へ連絡し、従来の手順へどう戻すかまで確認できれば、本番初日の混乱を減らせます。テストの結果は「不具合件数」だけでなく、日常業務を最後まで完了できたかで判断します。
導入時は対象部署を限定し、使い方と禁止事項を短い手順書にします。初期利用の問い合わせを受ける窓口を決め、誤回答や使いにくさを集めます。研修を一度行って終えるより、実際の案件で困った点を修正しながら対象を広げる方が、必要な改善を見つけやすくなります。
運用へ渡すときに欠かせない三つの記録
運用担当へは、利用状況、回答品質、費用の三つを引き継ぎます。利用件数だけでは成果を測れません。確認後の修正率や処理時間を合わせて見れば、利用が増えても負担が増えていないか分かります。APIの利用量や保守作業も含めた費用を追うと、対象業務を広げる判断に使えます。指標は企画時の現状値と比べ、季節要因や案件の難易度も考慮してください。
運用・改善：導入後に変わる条件へ対応する
社内規程、商品、業務手順が変われば、同じ仕組みでも回答の適切さは変わります。資料更新の担当と頻度を決め、品質が落ちたときにどの入力、どの版の文書、どのモデル設定が使われたか確認できるようにします。改善要望は「回答が悪い」とまとめず、検索対象、画面、確認手順、権限、費用に分類します。分類すると、モデル調整以外で直せる問題を見逃しません。
定期的な見直しでは、利用が続いているか、目標にした作業時間や品質が改善したか、リスクと費用が許容範囲かを確認します。効果が薄いなら、使う部署を絞る、機能を簡単にする、通常のシステム処理へ戻す選択もあります。AIを維持すること自体を成果にしない姿勢が、投資判断を健全にします。
NISTのAIリスク管理フレームワークは、リスクの把握、測定、管理と、それを支える組織的な統治を継続的な活動として示しています。この図の工程も、運用を終点とするより、得られた結果を企画や要件へ戻す循環として扱うと実務に合います。工程の名称より、判断と改善の責任が途切れないことを重視しましょう。
工程の間で情報を落とさない引き継ぎ方
各段階を別の担当者が受け持つ場合、会議の結論だけを伝えると判断の前提が失われます。企画から要件定義へは、改善対象を選んだ理由と見送った業務を渡します。要件定義から検証へは、正常例だけでなく、回答を保留する例とその理由を渡します。検証から開発へは、平均的な結果だけでなく、失敗した入力と原因の仮説を渡します。運用へは、残る課題と再評価の方法を引き継ぎます。
引き継ぎに使う資料は大部の報告書である必要はありません。一枚の判断記録に、決めたこと、根拠、未決定のこと、次に確認する人を記します。たとえばPoCで「回答案は使えるが、根拠の確認に時間がかかる」と分かったなら、本番開発の課題はモデルを替えることだけではなく、根拠を示す画面を作ることです。結果と次の設計課題を対にして残すと、同じ検証を繰り返す無駄を減らせます。
工程を戻す判断にも期限を設けます。資料の版が揃っていなければデータ準備へ戻り、管理者を決めて整える。目標とする削減時間に届かなければ、対象業務の切り方や確認手順を見直す。戻った先で何を変え、同じ評価例でどう確かめるかまで決めれば、工程表が単なるスケジュールではなく改善の記録になります。
よくある質問
PoCは必ず実施しなければなりませんか？
すべての案件で独立した大規模なPoCが必要なわけではありません。ただし、実データに近い条件で品質、確認負担、費用を確かめる作業は必要です。既存サービスの試用で足りるか、専用の検証が必要かは、業務の重要度とデータの制約で決めます。
開発会社へ相談する前に何を用意すればよいですか？
対象業務の現在の手順、困っている場面、使えるデータの種類、利用者、目指す改善を用意してください。すべての仕様が固まっていなくても相談できます。未決定の事項を隠さず、いつ誰が決めるか整理すると見積もりの前提がそろいます。
運用後の精度低下にはどう対応しますか？
失敗した入力を記録し、資料の更新漏れ、検索の不一致、出力形式の問題、モデルの挙動を切り分けます。原因に応じて資料、設定、画面、確認手順を直し、修正前と同じ評価例で再測定します。
まとめ：工程ごとに判断の出口を置く
AIシステム開発の流れを図として使うときは、作業名だけでなく、各工程から次へ進む条件と戻り先を書き込みます。企画で改善対象を絞り、要件定義で人の判断を残す場所を決め、実データで検証してから本番へ移す。導入後は利用、品質、費用を見て改善する。このつながりがあれば、技術面の検証と業務上の成果を同じ会話で判断できます。
