この記事で分かること
- AIシステム開発の範囲と通常のソフトウェア開発との違い
- 既存ツール・AI機能追加・新規開発を選ぶ基準
- 検証から運用まで発注側が決めること
AIシステム開発とは何を作ることか
AIシステムは、入力データを受け取り、AIの推論や生成を業務の判断材料として提示する仕組みです。文書検索、問い合わせ回答案、売上データの要約、不良品候補の抽出など、使い方は異なります。共通するのは、AIモデル単体では業務を完了できない点です。入力する人、データの更新、利用権限、出力の確認、既存システムへの反映まで組み合わせて初めて「システム」になります。
たとえば社内規程の質問へ回答する仕組みなら、文書を保存する場所、検索対象の版、部署ごとの閲覧制限、回答に添える出典、回答できない場合の連絡先が必要です。回答文を作るモデルだけを比較しても、旧版の規程を引用する問題は解消しません。AIが担当する処理と、通常のプログラムや人が担当する処理を分けることが、設計の出発点です。
通常のシステム開発では、入力と処理規則が定まれば、期待結果を厳密に決められる場面が多くあります。一方、AIの出力は入力の表現や参照データによって変わるため、「正解の文章と完全一致するか」だけでは評価しにくいことがあります。ただし、AIだから何も約束できないわけではありません。禁止すべき出力、必要な項目、根拠の提示、回答を保留する条件を定義し、実際の業務例で確かめられます。
業務・データ・AI・人を一つの仕組みとして見る
構成図を描くときは、利用者からデータ、AI、確認者、次のシステム操作まで矢印をつなぎます。どこで個人情報が流れ、どこにログが残り、誰が結果を修正できるかも書き込みます。この図があれば、開発会社との会話で「AI部分だけ完成して業務へつながらない」という認識のずれを減らせます。
最初に選ぶ三つの導入方式
AIの利用方法は、新規システムの開発だけではありません。すでに使っているサービスのAI機能を試す、既存システムへ必要な機能を追加する、業務に合わせて新規に構築する、という選択肢があります。比較するときは「どの方式が高度か」ではなく、必要なデータと操作を安全に扱え、維持できるかを見ます。
| 方式 | 向く状況 | 先に確認すること |
|---|---|---|
| 既存のAI機能を利用 | 汎用的な要約や下書きから試す | データの扱い、権限、利用料、出力の確認 |
| 既存システムに追加 | 今の画面やデータを生かしたい | 連携方法、改修範囲、障害時の影響 |
| 新規の業務システム | 複数の作業を一体で見直す | 開発・保守体制と継続費用 |
現在の業務システムに必要な情報がまとまっているなら、機能追加で利用者の操作を増やさずに済む可能性があります。一方、データの定義が部署ごとに異なる場合は、連携を急ぐほど手戻りが増えます。開発前診断・ロードマップで既存の仕組みを整理し、直す、つなぐ、AIを加える、新しく作る案を並べて比べると選択しやすくなります。
「自社専用のモデルを作る必要がある」と最初から決めるのも避けましょう。既存モデルと社内資料の検索を組み合わせる方法で目的を満たすこともあります。逆に、厳しい応答条件や専門的なデータがある場合は、方式ごとの限界を検証しなければなりません。方式は目的と制約から選び、開発手段を目的にしないことが大切です。
導入の手順：発注側が決める順番
対象業務を絞り、現状値を記録する
「全社の問い合わせをAIで処理する」より、社内の特定部署から始める方が成果と問題を測れます。候補業務について、件数、作業時間、差し戻し、繁忙期の偏りを確認してください。改善したい指標を決めると、検証時に従来の方法と比べられます。頻度が低く例外が多い仕事や、誤りの影響が大きい仕事を最初の対象にするなら、確認体制と停止条件をより厚く設計します。
業務の流れを紙に書き、AIへ渡す前後の作業も数えます。AIで回答案の作成が速くなっても、根拠確認や転記が増えれば総時間は減りません。最終的な成果はAIの処理速度ではなく、業務全体の時間、品質、負担の変化で判断します。初期の進め方は担当者のための最初の7ステップも参照できます。
データの管理者と利用条件を確認する
保存先が分かるだけではデータを利用できません。誰が更新し、どの部署が閲覧でき、いつまで保存するかを確認します。問い合わせ履歴なら、個人情報を含むか、回答の承諾範囲はどうか、古い回答を再利用してよいかを点検します。初期の試用でも本番と同じ条件で扱えない情報があるため、必要に応じて匿名化したサンプルから始めます。
データ品質は、欠損率の数字だけで判断しません。AIが参照する項目の意味が揃っているか、最新版を識別できるか、質問に対応する資料がそもそも存在するかを見ます。資料不足が原因なら、モデルを替えても正しい根拠は増えません。データ整備と評価例の作り方はAI開発に必要なデータの基本に整理されています。
人の確認と例外を要件に入れる
AIが作った結果を誰が確認し、どこまで修正してよいか決めます。社内向けの下書きでも、事実確認の責任者が曖昧だと誤った内容が広がります。顧客へ送る文章であれば、送信前の承認と根拠の確認を業務フローに入れます。確信の低い結果を空欄で返す、元資料へ誘導する、担当者へ回すなど、回答しない設計も選択肢です。
要件は機能の一覧だけで終わらせません。利用者数、応答時間、停止時の代替手順、権限の切り替え、ログを確認できる期間、費用の上限も記します。未確定項目を見積もりの前提から漏らすと、後から追加費用や納期の変更につながります。見積もり比較の前に「含むもの・含まないもの」を合わせておくことが重要です。
小さく検証し、本番化を判定する
PoCでは、きれいに整えたデモ用データだけでなく、実務で起こる揺れや不足を含むサンプルを使います。評価する項目は正答率一つに絞らず、必要な根拠を示せるか、誤りを人が見つけやすいか、処理時間と利用料が許容範囲かを並べます。誤回答の影響が大きい仕事ほど、正しい回答の割合だけでなく、危険な間違いをどう抑えるかを重視します。
検証に入る前に「採用」「条件付きで再検証」「見送り」の基準と判断者を決めます。結果を見てから目標を変えると、PoCだけが続きます。失敗例を収集し、入力、データ、検索、モデル、画面のどこに原因があるかを分析します。方式を変える余地があるのか、対象業務の選び直しが必要なのかも明記します。
本番開発で追加される仕事
検証用に作った処理をそのまま全員へ開放することはできません。本番には認証、部署別の権限、既存システムとのデータ交換、バックアップ、監視、障害対応が必要です。AIサービスの停止や仕様変更が起きたとき、業務をどう続けるかも決めます。ログはトラブル調査に役立ちますが、保存する情報と閲覧者を限定しなければ別のリスクになります。
受け入れテストでは、仕様通りに画面が動くかだけでなく、担当者が作業を最初から最後まで完了できるかを確かめます。代表的な案件、例外、データの更新直後、権限外の資料、曖昧な質問を試し、期待しない出力が出たときの操作も確認します。テストで見つかった課題は、修正が必要なものと運用手順で扱うものに分け、残るリスクを承認者へ示します。
開発会社へ依頼する場合、ソースコードや設定、評価用データ、運用手順の引き渡し範囲を契約と計画に含めます。担当者が変わっても維持できるよう、誰が資料を更新し、費用を監視し、問い合わせを受けるかを明文化します。技術的な完成と業務への移行を一つの納品日で済ませず、利用開始後の支援期間を設けると問題を拾いやすくなります。
本番化の前に見る三つの責任
業務責任者は使う目的と結果の承認、運用担当者は資料の更新と利用者対応、開発担当者はシステムの障害と変更を受け持ちます。小規模な組織では一人が複数の役割を兼ねても構いません。ただし役割そのものを空欄にしないでください。外部ベンダーへ運用を委ねる場合も、最終判断や情報の利用許可を誰が出すかは社内で決める必要があります。
運用開始後に測ることと、止める判断
導入直後は利用件数が伸びても、業務上の成果を示すとは限りません。利用者、対象案件、採用率、修正に要した時間、元資料の確認回数を見ます。企画時に記録した従来の作業時間や品質と比較し、AIを使うことで全体の仕事が改善したか評価します。利用が低いときは「社員が使わない」と結論づけず、画面の導線、対象業務、信頼できる根拠の不足を調べます。
出力の品質は導入時に固定されません。資料の改訂、商品名の変更、利用者の質問の変化に合わせて評価例を更新します。モデルやプロンプトを変更したら、良かった例だけでなく、以前に失敗した例も再測定します。費用については月額だけでなく、確認者の工数、資料の整備、保守対応を含めて見ます。費用が効果を上回る場合、対象の縮小や別方式への切り替えを検討します。
停止条件も運用設計の一部です。重大な誤回答、権限外データの表示、費用の急増、外部サービスの障害が起きたとき、機能を止める権限と連絡順を決めます。誰も止められない設計より、停止と再開の判断を明確にした仕組みの方が現場で安心して使えます。NISTのAIリスク管理フレームワークも、リスクの把握・測定・管理を継続的に行う考え方を示しています。
社内で合意しておく資料と意思決定
導入の途中で何度も説明し直さないために、最低限の資料をそろえます。一つ目は、対象業務の現在の手順と改善したい指標です。二つ目は、使用するデータの一覧と管理者、利用条件です。三つ目は、通常の案件と例外を含む評価例です。四つ目は、費用の前提と本番化の判定条件です。資料の名称や形式は自由ですが、関係者が同じ版を見られる場所に置きます。
発注側が決める事項を開発会社への質問に変えると、提案の比較がしやすくなります。「今回の対象外は何か」「誤回答をどう検出するか」「資料が更新されたとき誰が反映するか」「サービスが停止したとき業務はどう続くか」と尋ね、回答を要件や見積もりへ反映します。説明が異なる提案を価格だけで比較しないよう、同じ前提にそろえてから判断してください。
また、合意は一度きりではありません。検証でデータ不足が判明したら、対象業務や予算を見直します。現場の操作で確認負担が増えたら、画面や承認の設計を変えます。変更のたびに、目的と採用条件が維持されているかを確かめます。完成予定日だけを追うより、何を学んで何を決め直したかが分かる計画の方が、導入後の運用へつながります。
よくある質問
AIシステムを作るには独自モデルの学習が必要ですか？
必須ではありません。既存モデルの機能、社内文書の検索、通常のプログラムを組み合わせて実現できる場合があります。扱うデータ、品質、費用、運用負担から方式を比較します。
発注前に仕様をすべて決めなければいけませんか？
詳細をすべて固定する必要はありません。ただし、対象業務、現在の困りごと、使えるデータ、判断する人、予算や期限の前提は整理してください。未決定事項は決める時期と担当を明記します。
PoCが成功したらすぐ本番化できますか？
検証は一部の条件を確かめる工程です。本番では権限、連携、障害対応、利用者教育、費用管理が追加されます。PoCの結果と本番運用の準備を別々に確認して判断します。
まとめ：AIの処理と業務の仕組みを一緒に設計する
AIシステム開発では、まず改善する仕事を定め、既存ツール、機能追加、新規開発を比較します。データと人の確認を設計し、実務の例で検証してから本番へ進みます。運用中は品質、負担、費用を測り、必要なら範囲を変える。その一連の判断を担当者と成果物でつなぐことが、導入して終わらない仕組みにつながります。
