- Published on
AI活用のシステム開発とは?進め方と開発会社の選び方を解説
要点 / TL;DR
AI活用のシステム開発は、AI機能を組み込んだシステムを作る場合と、開発プロセスにAIを取り入れる場合に分かれます。目的を先に定め、対象業務とデータの状態を確認してから、PoC、要件定義、開発、評価、保守運用の順に進めます。
この記事はAIの支援で作成し、人間が確認しています
- Authors

- Name
- MK1編集部

AI活用のシステム開発とは?
AI活用のシステム開発とは、AIの機能を業務や製品に組み込み、データをもとに判断や処理をする仕組みを作ることです。文章の検索や要約、画像の判定、問い合わせの振り分けなど、対象は幅広くなります。検討の出発点になるのは、技術の選定よりも「どの業務の、どの判断を支援するのか」を決める作業です。
AIを組み込む開発と、開発プロセスでAIを使う場合
この言葉には二つの意味があります。一つは、完成したシステムの中にAIの機能を持たせる開発です。もう一つは、設計・実装・テストといった工程そのものでAIツールを使う進め方です。
二つを混ぜたまま相談すると、見積もりの前提がずれます。前者はデータの準備と出力の評価が必要になり、後者は開発チームの作業の進め方の話になるためです。「何をAIで実現したいのか」と「誰がどの工程でAIを使うのか」を分けて伝えると、提案を同じ土俵で比べられます。
AI活用のシステム開発と従来の開発は何が違う?
違いが大きく出るのは、ゴールの決め方と品質の確かめ方です。従来の開発は仕様との一致で完了を判断しやすいのに対し、AIは出力が毎回同じにならない前提で、評価の基準を先に決める必要があります。
| 観点 | 従来の開発 | AI活用のシステム開発 |
|---|---|---|
| ゴールの決め方 | 機能一覧と画面・帳票で定義する | 支援する判断と、許容できる誤りの範囲まで定義する |
| 要件定義 | 仕様の網羅性を確認する | 入力データの状態と出力の評価基準をあわせて確認する |
| 品質の確かめ方 | テスト項目の合否で判断する | 正解データでの確認と、人の確認作業を含めて判断する |
| 運用後の見直し | 障害対応と改修が中心になる | 出力の傾向を見て、データや設定を見直す |
要件定義の難しさ
機能を書き切っただけでは、AIの開発は先に進みません。どの程度の精度を目指すのか、どの誤りなら業務上許容できるのかが決まらないと、実装の良し悪しを判断できないためです。
例えば、問い合わせメールを種類ごとに振り分ける場合を考えます。振り分け先を決めるだけでは足りず、判断に迷うメールの扱いや、誤った振り分けが業務に与える影響まで決めておく必要があります。
データと評価の扱い
出力の質は、入力するデータの状態に左右されます。対象の文書がどこに、どの形式で、どの程度そろっているかを早い段階で確認します。あわせて、評価に使う正解データを誰が用意するのかも決めておきます。
データの準備と評価の試行は、作業として見えにくい工程です。見積もりの前提に含まれているかを確認しておくと、後半での追加依頼を避けられます。
どんな業務から始めるとよい?
最初の対象には、判断の基準を言葉で説明でき、正解を人が確認できる業務が向いています。判断の根拠が担当者ごとに大きく変わる業務は、要件定義に時間がかかります。
業務自動化
決まった形式の入力作業、定型的な照合、一次対応の振り分けなどは、対象として切り出しやすい領域です。今の業務の流れを変えずに一部だけを置き換える進め方がとれます。
社内ナレッジの検索・活用
社内文書を検索し、回答の根拠となる箇所を示す形は、効果を確かめやすい用途です。RAG(検索した文書を踏まえて回答を生成する仕組み)とVector DB(文書をベクトル化して検索するデータベース)を組み合わせ、根拠を提示する構成が代表的です。
例えば、就業規則や社内手続きの問い合わせを探す時間を減らしたいという場合です。対象の文書が整備されているほど、検証の着手が早くなります。
AIプロダクト開発
自社の製品やサービスにAIの機能を持たせる場合は、利用者にどう見せるかの設計が加わります。出力をそのまま提示するのか、人が確認してから提示するのかで、必要な作りが変わります。
業務自動化や社内ナレッジ管理、AIプロダクト開発はAI BPOで、機械学習やコンピュータビジョン、自然言語処理、データ解析はAI/MLソリューションで扱っています。どこまでを内製し、どこを外部に委ねるかは、データの扱いと運用体制で決まります。
進め方は?
進め方は、目的の整理から小さな検証を経て本番化する流れが基本です。各段階で成果物を残し、次に進むかどうかを判断できる状態にします。
- 目的と対象業務の整理:支援する判断、対象の業務、使う人を書き出します。成果物は企画メモです。
- データと制約の確認:対象データの所在・形式・量、利用範囲、外部サービスの可否を確認します。成果物はデータ確認表です。
- 小さなPoC(概念検証):限られた範囲で出力を試します。成果物は評価結果です。
- 要件定義:機能、評価基準、誤りが起きたときの扱いを決めます。成果物は要件定義書と評価計画です。
- 開発と受け入れテスト:実装を進め、評価基準に沿って確認します。成果物は動作するシステムとテスト結果です。
- 保守運用と改善:出力の傾向を定期的に見て、データや設定を見直します。成果物は運用記録と改善計画です。
PoCから本番化まで
PoCでは、うまくいった例だけでなく、うまくいかなかった例も残します。どの入力で誤るのかが分かると、本番化の条件を具体的に決められます。本番化の判断は、精度の数字だけでなく、人の確認作業を含めた運用の負荷で見ます。
AIの機能は単体で動くものではなく、既存の業務システムと接続して使われます。WebシステムやAPIの設計とあわせて検討し、接続部分の仕様を先に固めておくと、AIの出力が良くても業務が回らない事態を避けられます。
評価と見直しの設計
評価の方法は、開発に入る前に合意しておきます。正解データの作り方、確認する件数、合格とみなす水準を文書にします。運用開始後も同じ方法で測れるようにしておくと、改善の効果を比べられます。
技術要素は目的から選びます。文章の検索と生成であればOpenAIやClaude API、LangChain、RAG、Vector DB、APIの実装にはPythonやFastAPI、定型処理の連携にはn8nやMakeといった選択肢があります。名称そのものより、その構成を保守できる体制があるかが判断の軸になります。
費用はどう決まる?
費用は単価と工数の組み合わせで決まるのが一般的です。単価は関わる人のスキルと契約形態、工数は要件定義の進め方、スコープ、非機能要件の影響を受けます。
単価と工数の分け方
受託開発(請負型)は成果物と範囲を決めて契約し、ラボ型開発(準委任契約)は一定期間の人員と稼働を契約します。AIの機能を含む場合、どちらの形でもデータ準備と評価の試行が工数に入るかどうかで総額が変わります。
見積もりで確認したい項目
- 要件定義に含まれる作業範囲(データの確認、評価基準の設計を含むか)
- PoCの回数と、本番化に進むかどうかの判断基準
- 学習・評価に使うデータの準備をどちらが担うか
- 利用する外部サービスの料金をどちらが負担するか
- 保守運用の範囲と、改善を行う頻度
- 追加の依頼が発生する条件と、そのときの単価
金額は対象業務とデータの状態によって変わります。前提を書面でそろえてから比較すると、見積もりの中身を読み解く手がかりになります。
開発会社はどう選ぶ?
選ぶときは、AIの実績の数よりも、進め方と確認の方法が自社の体制に合うかを見ます。比較の軸をそろえておくと、複数社の提案を同じ条件で判断できます。
比較のチェックリスト
- AIの用途経験:文章、画像、数値など、自社の対象に近い用途を扱ったことがあるか
- 要件定義の進め方:機能だけでなく、評価基準と誤りの扱いまで決める提案になっているか
- データの扱い:データの所在、利用範囲、学習に使うかどうかの方針が説明されているか
- 評価方法:精度の測り方と確認する件数を、開発前に合意できるか
- 品質保証(QA)体制:手動テストと自動化の分担、受け入れテストの進め方が明確か
- 保守運用:公開後の改善をどこまで担うか、問い合わせの窓口が決まっているか
- 見積もりの前提:単価と工数の内訳、追加依頼の条件が書面で示されているか
品質・情報セキュリティの面では、開発プロセスの記録が残るか、情報の取り扱いと権限の範囲が説明されるかも確認します。宣言だけでなく、運用の記録を見せてもらえると違いが分かります。
社内で比較するときの前提のそろえ方
複数社を比べるときは、同じ依頼内容を渡すことが前提になります。対象業務、データの状態、評価の方法、希望する時期を同じ資料で伝えます。提案の差が、会社の力量の差なのか前提の差なのかを切り分けられます。
まとめ
AI活用のシステム開発は、AIの機能を組み込む開発と、開発の工程でAIを使う進め方に分けて考えると見通しが立ちます。目的と対象業務を先に決め、データの状態と評価の方法を確認してから、PoC、要件定義、開発、保守運用の順に進みます。開発会社は、実績の数よりも要件定義と評価の進め方、見積もりの前提の開示で比べると判断しやすくなります。
自社の場合にどの進め方が合うか整理したい場合は、お問い合わせからご相談ください。
FAQ
AI活用のシステム開発は、どんな業務に向いていますか?
答えが人によって大きく変わらない業務は、要件を決めやすく検証も進めやすいです。文書検索や問い合わせの一次対応、定型的な入力作業などが候補になります。判断の根拠を言葉にしにくい業務は、対象業務の整理から始めることになります。
PoCだけを依頼することはできますか?
検証範囲を絞ってPoCだけを依頼する形は考えられます。本番化を前提にせず、評価の基準と判断材料を先に決めておくと、次へ進むかどうかを社内で説明しやすくなります。
開発会社を選ぶときは何を比べればよいですか?
AIの用途経験に加えて、要件定義の進め方、データの扱い、評価方法の合意形成、品質保証(QA)体制、保守運用の範囲を同じ基準で比べます。見積もりは単価と工数に分かれているか、前提が書面で示されているかを確認してください。
費用はどのように決まりますか?
契約形態と関わる人のスキルで単価が決まり、作業範囲の大きさで工数が変わります。AIの機能を含む場合は、データの準備と評価の試行にどれだけ時間をかけるかも総額に影響します。見積もりでは、何が前提に含まれているかを確認してください。