この記事で分かること
- AIシステム開発を9段階で進める全体像
- 各段階で曖昧にしてはいけない判断と成果物
- PoCだけで終わらせず、業務に定着させる運用・改善の考え方
AIシステム開発を9段階で捉える理由
AIを使う取り組みでは、技術の選定が注目されがちです。しかし実務で成果を左右するのは、「何を良くしたいのか」「誰がどの場面で使うのか」「どのような結果なら採用するのか」という設計です。企画、業務整理、データ、検証、実装、導入、運用を別々の仕事として切り離すと、前の判断が次の工程に伝わらず、手戻りが起きます。
そこで、開発を一本の流れとして管理します。9段階は直線的なチェックリストではなく、前段の仮説を後段の結果で見直すための地図です。たとえばPoCで精度が不足したとき、原因がモデルではなく、目的の置き方、ラベルの定義、入力データの不足にあることもあります。どの判断に戻るべきかを見失わないためにも、段階ごとの目的と出口を最初に共有しておくことが重要です。
この9段階は、NISTのAIリスク管理フレームワークや国内のAI事業者向け指針が定めた必須の工程数ではありません。NISTの枠組みはガバナンスを横断的に扱い、AIのライフサイクルを通じた継続的なリスク管理を示しています。国内の指針も、開発・提供・利用などの役割に応じた取り組みを整理しています。ここでは、実務担当者が企画から運用までの判断を引き継げるよう、作業を9段階に分けています。
段階ごとの成果物と次へ進む判断
各段階で残す資料は、規模やリスクに合わせて一つにまとめても構いません。大切なのは、作業の記録だけでなく、誰が何を根拠に次へ進めると判断したかが分かることです。
| 段階 | 主な成果物 | 次へ進む判断 |
|---|---|---|
| 企画 | 業務課題、現状値、目標指標 | 測定方法と責任者が決まり、改善効果を確かめられる |
| 業務整理 | 現行フロー、例外、対象外の一覧 | 適用範囲と人へ引き継ぐ条件を現場が確認している |
| 要件定義 | 入出力、利用者、評価基準、責任分担 | 許容できない誤りと、人が確認・判断する箇所が合意されている |
| データ準備 | データ台帳、利用条件、評価用データ | 必要なデータを適切に使え、代表的なケースで評価できる |
| PoC | 検証仮説、手順、結果、残る課題 | 採用・追加検証・範囲縮小・見送りの根拠がある |
| 本開発 | 構成、データ連携、権限、障害時の手順 | 運用条件と要件を満たす実装方針が定まっている |
| テスト | テスト結果、不具合、受入記録 | 重要な未解決事項への対応と回避策を確認している |
| 導入・定着 | 導入計画、利用手順、教育・問い合わせ先 | 利用者と現場責任者が開始条件と代替手順を把握している |
| 運用・改善 | 監視指標、変更・障害記録、改善計画 | 定期評価の担当・時期と、異常時の判断方法が決まっている |
段階1：企画で「AIを入れる理由」を言語化する
最初に決めるのは、AIを導入すること自体ではなく、改善したい業務成果です。「問い合わせ対応を速くする」「点検記録から見落としを減らす」「需要予測の判断材料を増やす」といったように、対象業務と変えたい状態を具体化します。このとき、利用者、業務の頻度、現在の処理時間、発生しているミスや待ち時間も整理すると、優先順位を付けやすくなります。
企画書には、解決したい課題、対象者、利用場面、期待する変化、実現しない場合の影響を記載します。数値目標を今すぐ確定できない場合でも、「誰が何を判断できるようになるか」を先に書くと、後の評価軸になります。AIに任せる範囲と、人が最終確認する範囲を分けることも、この時点での大切な論点です。
社内で課題の整理や優先順位付けが難しい場合は、技術要件の前に開発前診断・ロードマップで現状の仕組みと制約を確認する方法があります。既存の業務システム、帳票、データ保管場所を把握してから企画を固めると、実現性のない期待を早い段階で避けられます。
段階2：現行業務を観察し、対象範囲を決める
企画が決まったら、現場で実際に仕事がどの順番で進んでいるかを確認します。手順書だけでは、例外対応、確認のための電話、二重入力、担当者ごとの判断の違いまでは分かりません。入力は何か、途中で誰が確認するか、どこで情報が滞るか、最終的にどの記録が残るかを追いかけます。
対象範囲は、最初から全業務に広げないほうが安全です。判断が比較的定型で、入力データの所在が分かり、成果を確認しやすい業務から選ぶと、検証結果を次の展開へつなげられます。一方で、例外が多い業務や責任が重い判断では、AIの提案を補助情報として扱い、承認の流れを残す設計が必要です。
成果物としては、現行フロー、課題の発生箇所、対象としない範囲、例外の一覧を用意します。担当者への聞き取りで得た表現をそのまま残しておくと、開発側が言葉だけで業務を想像することを防げます。
段階3：要件定義で成果と責任範囲をそろえる
要件定義では、画面や機能の前に「何を入力し、何を出力し、誰が結果を使うか」を決めます。AIの出力が文章、分類、順位、数値予測のどれなのかによって、確認方法も運用の責任者も変わります。出力を見た人が次にどの行動を取るかまで決めると、便利なデモで終わることを防げます。
特に重要なのは、精度の意味を関係者でそろえることです。正解率だけでは、誤ってはいけないケースや、人が確認すれば許容できるケースを表せません。見逃し、誤検知、回答不能、判断保留をどう扱うかを具体例で定義し、業務上の許容範囲を決めます。個人情報や社外秘情報を扱う場合は、入力できる情報、保存期間、閲覧権限、ログの取り扱いも要件に含めます。
要件定義の観点は、AIシステム開発の要件定義｜精度・データ・責任範囲の決め方でも詳しく整理されています。成果物は、目的、対象業務、利用者、入出力、例外時の対応、評価方法、責任分担をまとめた合意資料です。後から仕様を追加したくなったときも、この資料に戻れば、目的に対して必要な変更かを判断できます。
要件を「機能の一覧」だけにしない
要件書に機能名だけが並ぶと、完成の判定が曖昧になります。「問い合わせを要約する」という機能なら、どの情報を残すか、どの長さにするか、誤要約を誰が修正するか、修正結果を次回に活かすかまでが要件です。利用者が操作を終えたあとに何が残るかを意識すると、画面、データ、権限、運用手順の抜け漏れを見つけやすくなります。
段階4：データを棚卸しし、使える状態に整える
AIの精度は、モデル名だけで決まりません。どのデータを使うか、データが現場の実態を表しているか、正解として扱う基準が一貫しているかが結果に影響します。まず、データの保管場所、形式、件数、更新頻度、欠損、重複、閲覧権限を一覧にします。Excel、基幹システム、PDF、メール、画像のように散在している場合は、収集方法そのものが開発範囲になることがあります。
次に、学習・評価に使うデータと、本番で入力されるデータの違いを確認します。過去の記録が整っていても、現在の入力様式が異なれば、同じようには使えません。また、担当者ごとに判断基準が異なるラベルをそのまま正解データにすると、AIに矛盾した判断を学習させるおそれがあります。データを増やす前に、何を正解とするかを業務側と決めることが先決です。
データの収集・整形・評価の考え方は、AIシステム開発に必要なデータとは？失敗しない整備・評価の基本を参照すると、準備の論点をより具体化できます。ここで残す成果物はデータ台帳、利用可否の判断、前処理のルール、評価用データの定義です。
段階5：PoCで仮説と実現性を検証する
PoC（概念実証）は、本開発の縮小版ではありません。限られたデータと範囲で、「この課題に対してAIを使う価値があるか」「必要な精度や処理時間に近づけるか」「現場が結果を使えるか」を確かめる工程です。検証する仮説を一つずつ明確にし、成功条件と中止条件を先に決めます。
たとえば分類業務なら、単に正答数を比べるのではなく、重要な誤りがどれだけ起きるか、保留に回す量は業務で処理可能か、判断理由を確認できるかを見ます。生成AIを使う場合は、同じ質問でも表現が変わること、参照してはいけない情報を含めないこと、根拠を確認できることも検証対象です。PoCの評価者を開発者だけにせず、実際に使う担当者に含めることが欠かせません。
PoCの最後には、採用・見送り・追加検証のいずれにするかを決めます。「精度が十分でない」だけでは次の行動が決まりません。どの入力で失敗したか、データを増やせば改善するのか、対象業務を狭めれば使えるのかを記録し、次の投資判断につなげます。AIシステム開発で費用対効果を出す｜PoC検証の実践チェックリストも、評価項目の整理に役立ちます。
PoCの成果物は「デモ」ではなく判断記録
見栄えのよい試作画面だけでは、本開発へ進む根拠になりません。検証条件、使用データ、評価手順、結果、想定外だった点、残るリスク、次に必要な費用と期間を一つの記録にまとめます。その記録があれば、関係者が変わっても「なぜ進めるのか」「何がまだ未解決なのか」を共有できます。
段階6：本開発で業務システムとして実装する
PoCで方向性を確認できたら、本開発では業務で継続利用できる仕組みにします。モデルやプロンプトの実装だけでなく、認証、権限、データ連携、入力チェック、エラー表示、処理の待ち時間、ログ、監視、バックアップを設計します。誰がいつ何を入力し、どの結果を受け取り、どのように修正したかを追えるようにしておくと、運用後の改善がしやすくなります。
要件を一度にすべて実装する必要はありません。利用頻度が高く、効果を確かめやすい機能を優先し、短い単位で確認を繰り返すほうが、現場とのずれを早く見つけられます。ただし、後から追加しづらい権限設計やデータ連携の基本方針は、最初に合意しておくべきです。
実装体制や、既存システムとのつなぎ方を含めて相談したい場合は、AI開発・AIシステム開発の支援のように、企画から実装までを一貫して検討できる窓口を活用すると、段階間の情報をつなぎやすくなります。
段階7：テストで「正しく動く」と「安全に使える」を確認する
テストでは、機能が動くかだけでなく、現場の条件で安全に使えるかを確かめます。正常な入力だけでなく、空欄、表記ゆれ、想定外の長文、古いデータ、権限のない利用者、連携先が停止した場合などを試します。AIの出力については、評価用データでの結果に加え、業務上重要なケースを個別に確認します。
受入テストは、要件定義で決めた成功条件に照らして行います。画面の見やすさ、処理時間、修正のしやすさ、出力を受け取った後の業務フローまで確認し、利用者が本番前に不安を言える場をつくります。障害時の連絡先、一次対応、復旧方法、手作業へ戻す手順もテスト対象です。
テスト結果は、発見した問題、重要度、対応方針、再確認の結果として残します。未解決の事項を隠したまま導入日を迎えるのではなく、業務への影響と回避策を関係者で共有して、導入可否を判断します。
段階8：導入・定着で現場の仕事に組み込む
システムが完成しても、現場が使わなければ成果にはなりません。導入時には、対象者、開始日、利用手順、問い合わせ先、従来手順との違いを明確にします。いきなり全社へ広げるより、対象部署や業務を限定した段階導入にすると、想定外の問題を小さく扱えます。
教育は操作説明だけで終わらせず、「AIの結果をそのまま採用してよい場面」「確認が必要な場面」「誤りを見つけたときの報告方法」を伝えます。AIが出した結果の責任を誰が持つのかが不明確だと、利用者は過信するか、逆に使わなくなります。利用ログ、問い合わせ、修正件数を確認し、定着を測る指標を用意します。
導入後に使われなくなる要因と定着支援のポイントは、AIシステム導入後に成果が出ない理由｜定着・運用を成功させる秘訣にもまとめられています。導入を完了ではなく、業務への適合を確認する開始点として扱うことが大切です。
段階9：運用・改善で価値を継続させる
運用が始まると、入力データ、業務ルール、利用者、期待される成果が変化します。最初に良い結果が出ていても、データの傾向が変われば精度が下がることがあります。そのため、処理件数、エラー、保留率、修正率、利用者の声、業務成果を定期的に見直し、改善の優先順位を付けます。
改善には、データの追加や整備、評価基準の見直し、画面の導線改善、対象業務の拡張、モデルやプロンプトの調整などがあります。どの変更も、本番へ反映する前に影響を確認し、いつ何を変更したかを記録します。とくに業務判断に近い用途では、変更前後の結果を比べられるようにしておくと、説明責任を果たしやすくなります。
運用会議で確認したい項目
定例の運用会議では、単に障害の有無を確認するだけでは足りません。利用されていない機能はないか、保留や修正が集中する入力はないか、現場が新たに困っていることはないかを確認します。そのうえで、改善候補を効果、緊急性、実装負荷、リスクで比べ、次に着手する項目を決めます。小さな改善を継続し、結果を共有することで、AIシステムは業務の変化に追随できます。
9段階を進める際のよくある失敗
よくある失敗の一つは、課題が曖昧なまま「AIを使うこと」を目的にしてしまうことです。この状態では、機能の追加やモデルの変更が続き、完成の基準が定まりません。もう一つは、PoCの成功をそのまま本番利用の成功とみなすことです。本番では、データ連携、権限、例外処理、教育、問い合わせ対応といった、試作では見えにくい仕事が必要になります。
また、精度を一つの数値だけで判断することも危険です。どの誤りが業務に影響するか、誰が確認するか、判断を保留できるかによって、許容できる結果は変わります。技術面と業務面の担当者が同じ評価記録を見る運用をつくると、問題を「AIの性能」だけに押し付けず、改善できる場所を見つけやすくなります。
AIシステム開発の流れに関するFAQ
AIシステム開発は、最初にどこまで決めればよいですか？
最初からすべての画面や仕様を決める必要はありません。少なくとも、改善したい業務、利用者、利用場面、期待する変化、AIに任せない判断、人が確認する方法は共有します。これらがあれば、調査やPoCで確認すべき論点を具体化できます。
PoCで十分な結果が出なかった場合、本開発は中止すべきですか？
直ちに中止と決める必要はありません。失敗した入力の種類、データの不足、正解基準の不一致、対象範囲の広さを確認します。改善に必要な追加作業と期待効果を比べ、対象を狭める、データを整える、別の仕組みにする、見送るという選択肢から判断します。
運用開始後、どのくらいの頻度で改善を検討すべきですか？
利用量や業務の変化に合わせて定例で確認します。開始直後は問い合わせや修正内容を短い間隔で確認し、安定後は利用状況、誤りの傾向、業務成果を定期的に見ます。大きな制度変更やデータ形式の変更があったときは、予定を待たずに影響を評価します。
まとめ：開発の成功は、運用までを設計できるかで決まる
AIシステム開発は、企画、業務整理、要件定義、データ準備、PoC、本開発、テスト、導入、運用・改善の9段階で進めると、判断の抜け漏れを減らせます。重要なのは、前工程で決めた目的と評価基準を、次工程へ引き継ぎ続けることです。特に、PoCの結果を本番の設計へつなぎ、導入後の利用状況から改善へ戻す循環をつくることで、AIを一時的な試みにせず、業務の価値へ結び付けられます。
