この記事で分かること
- 要件定義から保守まで、開発会社へ依頼できる作業の範囲
- 発注側が決める事項と、工程ごとに受け取る成果物
- 試作で終わらせず、本番運用へ進むための確認点
- 見積もりや保守の範囲を具体化する相談の進め方
AIシステム開発で任せられる範囲を最初に整理する
「AIシステム」という言葉には、社内文書の検索、問い合わせへの回答支援、帳票からの情報抽出、需要予測など、性質の異なる仕組みが含まれます。生成AIを使う場合でも、画面やデータベース、ログイン、承認処理までAIが担当するとは限りません。既存のソフトウェアと組み合わせ、業務の一部分にAIを使う形もあります。最初の相談では技術名よりも、利用者が行う作業と、その前後の流れを説明すると依頼範囲を具体化できます。
開発会社には、現状の聞き取り、方式の比較、設計書の作成、実装、テスト、運用手順の整備を依頼できます。一方で、現場の例外処理を説明する人や、回答の正しさを判断する人、予算と利用範囲を決める人は、自社で用意する必要があります。担当者が一人で兼務する場合も、どの判断をどの立場で行うかを明確にしておくと、打ち合わせの結論がぶれにくくなります。
| 工程 | 開発側へ依頼する作業 | 発注側が主に決める事項 | 確認する成果物 |
|---|---|---|---|
| 業務整理・要件定義 | 業務の可視化、対象機能と方式の提案 | 改善対象、優先順位、承認者 | 業務フロー、対象範囲、受入条件 |
| データ準備・試作 | 資料の整理支援、検証用の仕組みの構築 | 利用を認める資料、正解例の確認 | データ一覧、検証結果、残課題 |
| 設計・本番開発 | 画面、権限、外部連携、例外処理の実装 | 操作権限、業務への反映方法 | 設計資料、テスト結果、操作手順 |
| 導入・保守 | 移行支援、監視、障害調査、改善提案 | 利用開始の判断、運用責任者 | 引継ぎ資料、連絡手順、保守範囲 |
この表は役割分担のたたき台です。会社によって支援範囲は異なるため、提案書の「一式」という表現だけで判断せず、成果物と担当者を照合してください。マクティズムのAI受託開発・生成AI導入支援では、業務への適用検討から本番開発、運用保守までの相談内容を紹介しています。自社がどの段階にいるのかを伝えると、最初に必要な支援を絞りやすくなります。
要件定義では「AIにさせたいこと」を業務の条件へ変える
要件定義で大切なのは、希望する機能を並べるだけで終わらせないことです。例えば「問い合わせを自動化したい」という希望には、メールの分類、回答に必要な資料の検索、回答案の作成、担当者による確認、顧客への送信という複数の作業が含まれます。このうち何を今回の対象にするかで、必要な画面も、データも、検証の方法も変わります。
対象業務と人の承認範囲を先に決めます。初期導入では回答案の提示までに限定し、担当者が確認して送信する運用から始める方法があります。自動送信まで含める場合は、対象外の問い合わせや判断できない内容をどう扱うか、誰に引き継ぐかまで決めてください。担当者が確認する画面に根拠資料を表示できるかも、使いやすさを左右する検討点です。
聞き取りには管理者だけでなく、実際に作業する担当者も参加すると、手順書に書かれていない判断を拾いやすくなります。いつもは同じ手順でも、急ぎの依頼、資料不足、取引先ごとのルールなどで作業が変わることがあります。開発側には通常処理と例外処理を分けた業務フローを作ってもらい、担当者が実例と照らして確認する進め方が考えられます。
受入条件は「精度が高い」「使いやすい」といった表現から一歩進めて書きます。問い合わせ分類であれば、どの分類を間違えると困るか、判断不能を返してよいか、修正にどのくらい手間がかかるかを整理します。社内検索であれば、回答に参照資料が付くことや、閲覧権限のない文書が表示されないことも確認項目になります。数字の目標は現状の作業を測ってから合意し、根拠のない達成率を先に置かないことが重要です。
データの整理は依頼できるが、利用範囲の判断は必要になる
AIへ渡す資料が散らばっている場合、ファイルの収集方法や形式の統一、重複の整理、検索しやすい単位への分割は開発側へ相談できます。ただし、どの版が正式なのか、退職者の資料を残してよいのか、部門外へ見せてよいのかといった判断は、資料を管理する側の確認が必要です。データの所在だけでなく、管理者、更新日、利用対象者を一覧にしておくと、後の運用にも使えます。
例えば社内規程を検索する仕組みでは、旧版と新版が同時に残っていると、古い記載が参照候補になる可能性があります。最新版の置き場所を決める、旧版には識別情報を付ける、公開終了した資料を検索対象から外すなど、更新の流れを設計しておきます。開発完了時に正しい資料を入れただけでは、翌月以降も正しい情報が維持されるとは限りません。
試作に使うデータを選ぶときは、開発のしやすさだけでなく、実業務の違いを含めることを意識してください。読みやすいPDFだけでなく、表を含む資料、記載が欠けた帳票、表現が揺れる問い合わせなど、想定される種類を確認します。取り扱いを判断できない情報は、そのまま渡さず管理担当者へ確認し、必要に応じて検証用に置き換えます。外部サービスを利用するなら、送信先、保持の設定、アクセス範囲を確認する作業も依頼範囲に含めます。
PoCでは実現可能性と、続ける条件を確かめる
PoCは、想定した業務で技術が使えそうかを小さく確かめる検証です。画面が動いたことだけを成果にせず、何を判断するための試作なのかを先に決めます。文章の分類が課題なら分類の誤りを調べ、資料検索が課題なら必要な文書に到達できるかを調べます。本番と同じ画面を作り込むよりも、不確実な部分を早く確認する構成が適している場合があります。
評価用データと成功条件を先に決めます。開発中の調整に使う例と、最後に評価する例を分けると、見慣れた問題だけに合わせてしまう状況を見つけやすくなります。評価結果には正解・不正解だけでなく、誤りの種類、根拠の有無、担当者が修正できたかも残します。具体的な件数や合格ラインは、扱う業務の影響と利用できる資料に合わせて決めるものです。
評価では平均的な出来に加えて、少数でも見逃したくない失敗を別に確認します。回答できない質問に答えを作ってしまう、異なる取引先の情報を混ぜる、金額の桁を読み違える、といった問題は同じ扱いにできません。システム側で検知できるもの、画面で注意を示すもの、人が必ず確認するものを分ければ、本番化に必要な対策が見えてきます。
試作の報告書には、使用したデータの範囲、方式、評価方法、得意な条件、苦手な条件、残る課題を含めてもらいます。そのうえで、本番へ進む、用途を狭めて再検証する、別の方式を試す、今回は導入しないという判断を行います。PoCを実施したこと自体を導入理由にせず、最初に置いた業務上の目的に戻って検討してください。
本番開発ではAI以外の仕組みが利用品質を支える
試作から本番へ進むと、AIの出力以外にも作るものが増えます。利用者のログイン、部署ごとの閲覧権限、処理状況の表示、履歴、管理画面、入力の確認、障害時の動作などです。試作では開発者が手で準備していたデータ投入も、本番では担当者が無理なく実行できる手順に変える必要があります。試作費用と本番費用を比べる際は、この違いを確認します。
既存システムと連携する場合は、取得する情報と更新する情報を分けて整理してください。参照だけの連携と、在庫や受注情報を書き換える連携では、確認すべき動作が異なります。更新を行うなら、操作した人、処理の対象、変更内容を追えるようにし、通信が途中で切れた場合に同じ更新が繰り返されないかを検証します。取り消しや手作業への切り替え方法も、業務担当者が理解できる形にします。
また、AIの回答が返らない場合に画面が待ち続けないことや、利用が集中したときにどの処理を優先するかも検討事項です。テストでは正常な入力だけでなく、空欄、長い文章、不正な形式、接続先の停止といった条件を確認します。開発側へ技術的な検証を任せつつ、業務として困る状態を発注側から伝えると、試験項目に現場の事情を反映できます。
既存の仕組みが複雑で、AIを追加する前に改修範囲を整理したい場合は、開発前診断・刷新ロードマップのような現状確認から相談する方法があります。現在のシステムをどこまで残すかが曖昧なまま新機能だけを見積もると、連携部分の作業が後から増えることがあります。接続方法や運用制約を早めに共有することが、依頼範囲を安定させる助けになります。
受入テストは「動く」と「業務で使える」を確かめる場にする
受入テストでは、自社の担当者が実際の手順で操作し、要件定義で決めた条件を満たすかを確認します。開発側のテスト結果を受け取るだけでなく、入力から出力の確認、修正、次の担当者への引継ぎまでを通して試してください。AIが回答案を作る時間が短くても、根拠を探し直す手間が増えていれば、作業全体としての改善は別に判断する必要があります。
確認結果は画面名、操作、入力条件、期待した結果、実際の結果をセットで残します。「回答がおかしい」だけでは再現が難しいため、検証に使った資料の版や対象データも分かるようにします。ただし、記録に業務情報を必要以上に複製しないよう、保管場所と閲覧範囲を決めます。再現に必要な情報を何にするかは、開発側と運用担当者で擦り合わせるとよいでしょう。
指摘事項は、本番開始前に修正するもの、運用で対応できるもの、今後の改善候補に分けます。このとき、対応しない項目を誰が認めたのかを残しておくと、後から「聞いていない」という食い違いを減らせます。機能が多い場合は対象部門や利用者を絞って開始し、問い合わせを受け止められる体制を整えてから対象を広げる進め方も考えられます。
運用保守は障害対応と回答品質の改善を分けて確認する
導入後に任せられる仕事には、サーバーや連携処理の監視、障害の調査、ソフトウェアの更新、利用状況の確認、回答品質の改善などがあります。ただし、保守契約にすべて含まれるとは限りません。「月額保守」の中に何が入り、どこから追加の開発として扱うのかを、具体的な作業で確認してください。資料の追加を自社で行うのか、開発側へ依頼するのかも決めておきます。
障害対応と精度改善を分けて管理します。システムに接続できない問題と、接続はできるが回答が業務に合わない問題では、調査する対象も対応の進め方も異なります。連絡先を一本化する場合でも、申告時に何を伝えるとよいか、誰が業務上の優先順位を決めるかを整理します。緊急時にAI機能だけを止めて通常の業務へ戻せるかも、導入前に確認したい点です。
監視では、接続エラーだけでなく、担当者が修正した回答や、根拠が見つからなかった質問を改善の材料として扱えます。NISTの導入後監視に関する資料も、事前評価は管理された環境で行われることが多く、実運用で期待どおりに動くかを継続して確かめる重要性を説明しています。詳細はNISTの導入後監視に関する資料を参照してください。監視項目は導入する業務に合わせて選びます。
モデルや検索対象の資料を更新したときは、以前の検証例で結果を確認し直す流れを作ります。更新すれば必ず改善するとは決めつけず、重要な質問への回答や処理時間に望ましくない変化がないかを確かめます。更新の内容、確認結果、実施日を残し、問題が出た場合に戻せる範囲を整理しておくと、運用担当者が判断しやすくなります。
見積もりは成果物と役割分担を同じ表で比較する
見積書を見るときは、総額に加えて、要件定義、データ整備、PoC、本番開発、連携、テスト、教育、運用保守に何が含まれるかを確認します。例えば同じ「文書検索」でも、利用者ごとの権限や資料更新の画面を含む提案と、限定された資料を検索するだけの提案では範囲が違います。価格だけを並べる前に、対象機能と利用条件をそろえることが必要です。
発注側の作業も見積もりの前提に含めます。資料の整理、正解例の作成、受入テスト、利用者への説明を自社が担当する場合、その時間を確保できるかを確認してください。開発側の予定だけが決まっていても、必要な資料や判断が届かなければ先へ進めません。提出物、提出予定日、確認担当者を決めると、双方の作業を合わせやすくなります。
追加費用が発生する条件としては、対象データの増加、接続先の追加、承認フローの変更、利用部門の拡大などを具体例で確認できます。使用量に応じて変わる外部サービス費用と、開発会社への保守費用も分けて整理します。費用の工程別の見方は、AIシステム開発の費用相場を整理した関連記事も比較の補助になります。個別案件の金額は、対象業務と開発範囲を示した見積もりで確認してください。
引継ぎまでを依頼範囲に含めておく
納品時には操作手順だけでなく、システムの構成、外部サービスの契約主体、アカウント管理者、ソースコードや設定の保管先、資料の更新方法を確認します。開発会社しか分からない状態を避けるには、日常運用を別の担当者が実行できるかを引継ぎの場で試す方法が有効です。資料があることと、その資料で作業できることは分けて確認します。
保守の終了や担当会社の変更も想定し、必要な情報をどの形式で受け取れるかを相談しておきます。データの取り出し方、利用中の設定、未解決の課題、過去の変更記録が分かれば、次の担当者が状況を把握しやすくなります。契約上の扱いは個別条件によるため、曖昧な事項は契約担当者を交えて確認し、口頭の説明だけに頼らず合意した内容を記録してください。
相談相手を選ぶ際には、開発実績の件数だけでなく、今回の業務に近い課題をどう整理するか、説明や引継ぎをどこまで行うかを聞くと比較しやすくなります。候補会社への質問を準備する場合は、AIシステム開発会社の選び方も参考にしてください。担当者の説明を社内へ持ち帰り、現場と管理部門で同じ理解になっているかを確認する時間も大切です。
AIシステム開発を依頼するときのよくある質問
仕様書がなくても相談できますか？
支援範囲に業務整理や要件定義が含まれていれば、仕様書を作る前から相談できます。困っている作業、利用者、現在使っている資料や画面、改善したい理由を伝えてください。開発側には、最初の調査で何を整理し、どの成果物を受け取れるのかを確認します。要件が未整理のまま開発全体の範囲を確定しようとせず、調査後に見直す項目を残す進め方もあります。
AIの回答を人が確認しなくてもよくなりますか？
確認を外せるかどうかは、用途、誤りの影響、検証結果、例外を検知する仕組みによって判断します。導入しただけで確認が不要になるとは考えず、初めは確認する箇所を明示してください。自動処理を増やす場合も、対象業務を限定し、判断できないケースの引継ぎ先を用意したうえで検討します。
PoCの仕組みをそのまま本番で使えますか？
そのまま使えるかは、試作時に何を作ったかによります。限定されたデータや開発者の操作を前提にしている場合は、権限、画面、監視、更新手順などを追加する必要があります。試作で使い続ける部分と作り直す部分を報告書で分けてもらい、本番に進む前に追加作業を確認してください。
保守を依頼すれば新機能も追加してもらえますか？
新機能の追加が保守に含まれるかは契約の範囲によります。不具合調査、軽微な調整、資料の更新、機能追加を分けて確認すると認識を合わせやすくなります。定例会で改善候補を相談できる場合も、実装の作業量や費用をどの時点で合意するかを決めておきます。
自社の判断を残しながら、工程ごとに任せる範囲を決める
AIシステム開発を要件定義から保守まで依頼するときは、各工程で受け取る成果物と、自社が確認する事項を一組で整理してください。開発の実務を任せながら、業務の目的、データの利用範囲、受入条件、運用上の判断は自社で把握できる状態を作ることが大切です。相談前には、対象にしたい作業の流れ、困っている具体例、使っている資料、社内の確認担当者をまとめるところから始められます。
最初からすべてを自動化する必要はありません。一つの業務で役割分担と評価方法を確かめ、得られた結果をもとに範囲を広げる進め方があります。何を依頼すべきか決まっていない段階でも、現状を共有し、調査・検証・本番化のどこから始めるかを相談することで、次に必要な作業を具体化できます。
