この記事で分かること
- AIシステム開発の工程ごとに依頼できる作業と発注側の役割
- 要件定義から設計、AI実装、既存システム連携までの確認項目
- テスト、導入、教育、運用・保守を契約前に決める方法
- 外注範囲を段階的に決めるための相談資料と判断基準
AIシステム開発は工程ごとに任せられる範囲が違う
AIシステム開発を「AIのモデルを作る作業」とだけ考えると、実際に必要な仕事を見落とします。業務で使うには、誰が何のために使うかを整理し、入力データを準備し、権限や画面を設計し、結果を確認する仕組みを用意しなければなりません。既存のExcel、Access、販売管理、CRMなどと接続する場合は、AI以外のシステム開発も範囲に入ります。
依頼先へ相談するときは、「全部お任せ」と伝えるより、業務の開始から完了までを一つの流れで説明します。例えば、担当者がExcelを登録し、AIが内容を分類し、管理者が結果を承認し、販売管理へ反映する流れです。この説明から、画面、データ連携、AI処理、承認、ログ、障害時の対応へ分解できます。
| 工程 | 開発会社へ依頼しやすい作業 | 発注側が決めること |
|---|---|---|
| 課題整理 | 現行業務のヒアリング、課題と対象範囲の整理 | 困っている作業、優先順位、関係者 |
| 要件定義 | 機能、データ、権限、評価条件の文書化 | 業務ルール、許容できる結果、承認者 |
| 設計・開発 | 画面、連携、AI処理、管理機能の実装 | 利用環境、既存システムの制約 |
| テスト・導入 | テスト計画、移行、操作説明、初期設定 | 業務上の合否、利用者、開始時期 |
| 保守・改善 | 障害対応、精度確認、機能改善、監視 | 問い合わせ窓口、改善の優先順位、予算 |
この表の区分は相談時の整理方法です。契約上の役務や成果物は会社ごとに異なるため、見積書と契約書で範囲を確認してください。
最初に任せたいのは課題整理と要件定義
AIを使う業務と使わない業務を切り分ける
開発の入口で、AIを使うことを前提にしすぎないことが大切です。単純な入力チェックなら既存システムの改修で解決できる場合があります。帳票の転記なら連携や自動化の設計が中心になるかもしれません。検索や分類、文章の下書き、データからの傾向把握など、判断を補助する部分にAIが向いていることがあります。
開発会社には、候補を複数示してもらいましょう。AI導入、既存機能の改修、ExcelやAccessの改善、SaaSの利用、段階的なWeb化を比較すると、費用と業務効果の関係を検討しやすくなります。マクティズムのAI活用・AI開発サービスでも、業務内容や既存運用を踏まえて活用方法を整理する案内が掲載されています。
要件定義で決める五つの軸
要件定義では、機能一覧だけでなく、次の五つを一緒に決めます。第一は対象業務です。業務の開始条件、入力、判断、完了条件を整理します。第二は利用者です。一般利用者、承認者、管理者で見られる情報や操作を分けます。第三はデータです。形式、保存場所、更新頻度、版の扱い、個人情報の有無を確認します。
第四はAIの出力です。回答、分類結果、要約、予測、コメント案など、何が表示されれば業務に使えるのかを決めます。第五は評価です。正しさ、根拠、処理時間、利用率、削減時間など、導入前後で確認できる指標を置きます。曖昧な「高精度」という表現を、受け入れテストで判定できる条件へ変換することが要件定義の役割です。
成果物と会議の進め方を先に確認する
要件定義を依頼する場合は、何回会議をするかだけでなく、何が残るのかを確認します。業務フロー、課題一覧、画面ラフ、データ項目表、権限表、システム構成案、評価計画、未決事項一覧などが考えられます。成果物があれば、社内の承認や他社との比較に使えます。
未決事項を無理に消す必要はありません。情報が不足している項目に担当者と期限を付け、要件定義の最後に残課題として記録します。未確定のまま開発へ進むと、画面やデータの作り直しにつながる可能性があります。
設計・開発で任せられる範囲を具体化する
AI処理の前後にある仕組みも依頼対象にする
AIへ送る前にデータを整え、AIの結果を受けた後に人が判断できるようにする必要があります。文書検索なら、文書を取り込み、分割し、検索し、根拠を表示し、回答できない場合のメッセージを出す流れが必要です。問い合わせ対応なら、質問の分類、回答候補、担当者の編集、承認、送信、履歴保存まで考えます。
AIだけを範囲にした見積もりでは、ログイン、権限、管理画面、ファイル登録、エラー表示、バックアップなどが別作業になることがあります。見積書の「AI機能」に何が含まれるのか、周辺機能を誰が担当するのかを質問してください。
既存システム連携は方式と責任分担を確認する
ExcelやCSVの取り込みでも、ファイル名、列名、文字コード、重複、更新タイミング、失敗時の再処理を決める必要があります。API連携なら認証方式、接続先の制限、データ項目、エラー時の扱いを確認します。データベースへ接続する場合は、読み取りだけか書き込みも行うのか、性能や権限の影響も検討します。
連携先を管理する別会社や社内担当者がいる場合、調査・調整の責任者を明確にします。開発会社が接続できない理由が、技術不足ではなく、仕様書や接続権限の未準備であることもあります。必要なアカウントやサンプルデータの準備時期を工程表へ入れましょう。
セキュリティと権限を設計に含める
利用データに個人情報、顧客情報、営業秘密が含まれるなら、保存場所、閲覧範囲、外部サービスへの送信、ログの保存期間、削除手順を確認します。誰でも同じ回答を見られる仕組みが適切とは限りません。部署や役職、案件、文書の公開範囲に応じて、検索対象を制限する設計が必要です。
AIの出力を自動で確定するか、人が確認してから利用するかも重要です。顧客への返信、発注、在庫更新、評価など影響が大きい処理では、承認や差し戻しを設ける構成を検討します。操作ログに誰が何を実行したかを残すことで、問題発生時に原因を調べやすくなります。
テスト・導入・教育まで任せられるか
AIシステムのテストは、画面が表示されるかだけでは足りません。代表的な入力に対して正しい結果が出るか、誤字や不足データでどう動くか、権限のない情報が表示されないか、外部サービスが停止した場合に業務を続けられるかを確認します。発注側の担当者が業務上の合否を判断し、開発会社が技術面のテストを担当する形が分かりやすいでしょう。
導入工程では、初期データの移行、アカウント登録、操作手順、問い合わせ窓口、利用開始日の支援を確認します。研修を一度行うだけでなく、よくある質問や初期トラブルへの対応手順を残せると、現場の不安を減らせます。利用しない人が多い場合は、機能不足ではなく業務フローに組み込まれていない可能性も検討します。
| 確認場面 | 確認する例 | 合格条件の例 |
|---|---|---|
| 通常入力 | 正しい形式の質問やファイル | 必要な結果が許容時間内に出る |
| 例外入力 | 誤字、空欄、古い版、長文 | エラー内容と次の操作が分かる |
| 権限 | 部署外の文書や管理機能 | 許可されない情報を取得できない |
| 業務テスト | 担当者が結果を確認して完了する流れ | 現行業務の完了条件を満たす |
| 障害時 | API停止、連携失敗、通信切断 | 再実行や手作業への切り替えができる |
運用・保守は契約前に役割を決める
AIシステムは公開して終わりではありません。参照資料の更新、モデルやAPIの変更、利用量の増加、質問傾向の変化、業務ルールの改定に応じて見直しが必要です。保守契約に障害対応だけが含まれるのか、定期点検や精度改善、機能追加の相談まで含むのかを分けて確認してください。
運用担当者を発注側にも置きます。データを追加する人、回答を評価する人、利用者から要望を集める人、障害を連絡する人を決めます。開発会社へ丸投げすると、社内の業務変更や判断基準が伝わらず、改善の優先順位が定まりにくくなります。
保守費用を比較するときは、対応時間、受付方法、対象環境、月の作業量、追加料金、契約終了時の引き継ぎを確認します。ソースコード、設計書、設定情報、データ、クラウドアカウントの管理者を誰にするかも、将来の会社変更や内製化に関わる重要な項目です。
一括依頼と段階依頼を比較する
要件が明確で、既存システムやデータの状態も把握できているなら、設計から導入まで一括で依頼する方法があります。窓口が一つになり、工程間の引き継ぎを減らせる点が利点です。一方、課題やデータの確認から始めたい場合は、課題整理や小規模なPoCを先に依頼し、その結果を見て本開発へ進む方法が考えられます。
段階依頼では、各段階の終了条件と次へ進む判断を明記します。PoCが成功したら何を本番開発へ引き継ぐのか、成功しなかった場合にどの資料が残るのかを確認します。小さく始める場合でも、本番で必要な権限、ログ、連携を完全に無視すると、後から大きな作り直しになるため、将来条件は初期設計で共有します。
相談前にそろえる資料と質問
詳細な仕様書がなくても相談できます。現在の業務フロー、使っているExcelや帳票のサンプル、既存システムの概要、困っている件数や時間、利用者、希望時期、セキュリティ上の制約を準備します。機密情報はそのまま渡さず、必要なら匿名化したサンプルを作ります。
- 課題整理と要件定義で残る成果物は何か
- AI機能以外の画面、権限、ログ、連携をどこまで含むか
- 発注側が準備するデータ、アカウント、判断者は何か
- PoC、本番開発、テスト、導入をどう分けるか
- 運用開始後の保守、改善、費用、問い合わせ方法はどうなるか
- 契約終了時にデータや設定をどう引き継ぐか
AIシステム開発の依頼範囲に関するFAQ
仕様が決まっていなくても相談できますか？
相談できます。現状の業務、困っている作業、使えるデータ、利用者を伝えると、要件整理や小規模検証から進める方法を検討できます。
AIの部分だけを依頼することはできますか？
可能な場合があります。ただし、画面、権限、データ連携、ログ、エラー処理を別の担当者が実装できる体制が必要です。境界と責任分担を文書にしてください。
既存のExcelやAccessを残したままAIを追加できますか？
データ形式や運用方法を確認したうえで、取り込み、コメント生成、入力チェックなど段階的な追加を検討できます。連携方式と更新失敗時の処理を先に決めます。
AIの回答を自動で顧客へ送信できますか？
技術的な可否だけでなく、誤回答時の影響と業務ルールを確認します。最初は人が確認して送信する運用にし、評価後に自動化の範囲を広げる方法もあります。
保守契約は必ず必要ですか？
必要性は稼働条件や社内体制で変わります。障害時に誰が復旧するか、AIや外部サービスの変更へ誰が対応するかを決め、内製できない範囲だけ保守を依頼する方法もあります。
AIシステムの要件整理から保守まで相談する
マクティズムのAI開発サービスでは、業務課題の整理、必要な機能やデータの検討、AI実装、既存のExcelや業務システムとの連携、導入後の改善・保守までを相談できます。公開情報では、社内文書検索、問い合わせ対応、文書作成、既存システム連携などの活用例が紹介されています。自社に必要な範囲は、現状を確認して個別に決めます。
相談時には、完成した仕様書よりも、現在の業務と「どこを減らしたいか」を共有してください。要件定義から依頼するのか、まず一部業務を検証するのか、既存資産を活かして機能を追加するのかを比較し、社内で説明できる進め方に整理します。
まとめ｜任せる範囲を工程と成果物で決める
AIシステム開発は、AI機能だけで完結しません。課題整理、要件定義、データ、画面、権限、既存システム連携、テスト、導入、保守を一つの業務の流れとして確認する必要があります。開発会社へ依頼するときは、工程ごとの作業、成果物、発注側の役割、追加費用の条件をそろえて比較してください。
仕様が未確定なら、要件整理や小規模検証から始めても構いません。各段階の終了条件と本番化の判断基準を決めておけば、過剰な開発やPoC止まりを避けやすくなります。自社の課題と運用体制に合う範囲から、現実的なAIシステム開発を計画しましょう。
