AIアプリ開発の要件定義で決めること｜通常のシステム開発との違いと進め方

AIアプリの開発を始めるとき、最初の工程として行うのが要件定義です。要件定義とは、作るシステムが何をするのか、どこまでを対象にするのかを、発注する側と開発する側で決めて文書にする作業を指します。

要件定義は、一般的な業務システムの開発でも欠かせない工程です。ただ、AIを使うアプリには、通常のシステムとは違う決め方が必要な項目があります。AIの出力は、同じ入力でも毎回同じ文章になるとは限りません。そのため「正しく動いている」と判断する基準を、あらかじめ決めておく必要があるのです。

この記事では、AIアプリの要件定義で決めておきたい項目と、進めるときの注意点を説明します。開発会社に相談する前の整理については、AIアプリ開発を依頼する前に、整理しておきたい5つのこともあわせてご覧ください。

通常のシステム開発と何が違うのか

通常の業務システムでは、入力と処理と出力の関係が決まっています。たとえば、売上データを入れると集計表が出る機能であれば、計算が合っているかどうかで正しさを判断できます。

AIを使う機能の出力は、文章や要約のように幅のあるものが中心です。問い合わせへの回答案なら、同じ意味でも言い回しは毎回少しずつ変わるでしょう。どの言い回しなら合格かを一つに決めることはできません。

このため、AIアプリの要件定義では「何を満たしていれば良い出力とするか」を言葉と具体例で決めます。あわせて、AIが誤った出力をした場合に誰がどう気づくかも、最初から設計の対象に含めておくことが大切です。

業務の範囲と利用者を決める

最初に決めるのは、どの業務のどの作業をアプリの対象にするかです。「営業部門の業務を効率化する」では範囲が広すぎて、必要な機能を決められません。「見積もりの説明文の下書きを作る」のように、作業の単位まで絞り込みます。

次に決めるのは、アプリを使う人です。社内の担当者が使うのか、顧客が直接使うのかで、求められる確認の手順や画面の作りは変わってきます。利用者のおおよその人数や、使う場面も書き出しておくとよいでしょう。

対象外にする作業も、この段階で文書に残しておきます。開発の途中で「これもできないか」という要望が出るのはよくあることです。対象外を明記しておけば、追加の要望を次の段階に回すかどうかを落ち着いて判断できます。

決めておきたい項目の一覧

AIアプリの要件定義で決める主な項目を、表にまとめました。すべてを最初から確定させる必要はなく、未定の項目は未定と書いておけば十分です。

この表の中で、AIアプリに特有なのは「人の確認」と「品質の基準」です。以下の章で詳しく説明します。

AIに任せる範囲と人が判断する範囲

AIアプリでは、AIの出力をそのまま外部へ出すのか、人が確認してから使うのかを決めておく必要があります。社外の人に届く文章や、金額・契約条件に関わる内容は、人が確認してから使う設計にするのが一般的です。

人が確認する場合は、確認しやすい画面かどうかも要件の一つです。たとえば、AIが参照した資料を回答の横に表示すれば、担当者は根拠をすぐに確かめられます。修正した内容を記録しておけば、後からAIの改善に役立てることもできます。

AIが答えられない場合の動きも決めておきましょう。資料に情報がないときは「分からない」と返し、担当者に引き継ぐ流れにしておくと、誤った回答が外へ出ることを防ぎやすくなります。

品質の基準と評価の方法

品質の基準は、評価用の入力例と期待する出力の組を集めて決めるのが実務的な方法です。実際の業務で起きた問い合わせや書類から、よくある例と判断が難しい例の両方を選びます。

出力の評価では、正解の文章と一字一句同じかどうかは見ません。必要な情報が含まれているか、資料にない内容を断定していないか、言葉づかいが社内の方針に合っているかといった観点で確認します。観点を先に決めておけば、複数の人が評価しても判断がそろいやすくなるはずです。

この評価用の例は、開発中だけでなく公開後にも使います。AIのモデルを切り替えたときや、指示文を変更したときに同じ例で確かめれば、品質が下がっていないかを確認できます。

応答時間・費用・記録などの条件

機能以外の条件も、要件定義で話し合っておきたい項目です。回答が表示されるまでにどれくらい待てるか、利用者が同時に何人いるかは、構成の選び方に関わります。

費用も確認しておきたい点です。AIの利用料は、使った量に応じてかかる仕組みが多く、利用者や入力する文章の量が増えると費用も増えます。月ごとの上限の考え方や、使いすぎを防ぐ仕組みが必要かどうかを、早めに相談しておくと安心です。

入力された内容やAIの出力をどこまで記録するかも決めます。記録があれば誤りの原因を調べやすくなる一方で、個人情報や機密情報の扱いには注意が必要です。保存する期間や、記録を見られる人の範囲も要件に含めてください。

決めきれない項目は試験導入で確かめる

要件定義の段階では、AIがどの程度の品質で出力できるかを正確に見通すことは困難です。すべてを机上で決めようとすると、時間がかかるわりに確かな結論が出ません。

そこで、品質や使い勝手のように実際に試さないと分からない項目は、小さな範囲で試験導入して確かめる前提にします。試験導入の結果をもとに要件を見直し、本格的な開発の範囲を決める進め方です。試験導入の進め方は、AIの試験導入（PoC）の進め方で説明しています。

問い合わせ回答の受け入れ条件を書く例

架空の設備会社が、保守受付のメールから担当者向けの回答案を作るとします。入力は顧客が書いた状況と、公開済みの操作マニュアルです。AIの役割は状況の整理と確認事項の提示で、訪問日や費用の確定は受付担当者が行う想定です。

「親切に回答する」という要件では、誰が合否を判断しても同じ結果になるとは限りません。代わりに、回答に含める項目を「症状の要約」「不足する情報」「資料に記載された確認方法」「担当者への引き継ぎ」に分けます。顧客へ伝える文章と社内向けのメモは、画面でも区別します。

この表は期待する動作の例です。実際の保守業務でどの確認方法を案内してよいかは、業務の責任者が資料と照合して決めます。AIの出力だけを見て、案内可能な範囲を広げないようにします。

画面の要件も作業単位で書く

担当者が回答案を確認する画面には、問い合わせ本文、回答案、根拠となる資料を同時に表示する案が考えられます。「便利な確認画面」と書くより、「回答案の横から該当ページを開ける」と書いたほうが、完成後に確かめられます。

回答を修正した場合は、その修正版を送信対象にすることも要件です。表示中の文章を直しても、裏側で修正前の文章が送られる作りでは困ります。送信前の確認、送信した内容の記録、取り消せない操作の扱いまで、一連の作業として確認しましょう。

異常時の動作を別の表で決める

AIが回答しない場合と、アプリ自体が動かない場合は分けて考えます。資料に根拠がないときは情報不足として返し、通信障害なら再実行や通常の受付手順を案内します。同じ「エラー」と表示するだけでは、担当者が次に何をすればよいか分かりません。

たとえば「資料への接続が失敗した場合、根拠のない回答を作らず、元の問い合わせを保存して担当者へ通知する」という要件を置きます。再実行してよい回数と、同じ問い合わせを二重に処理しない方法も確認します。

要件定義の打ち合わせで残す三つの文書

一つ目は、対象業務と対象外の業務を書いた一覧です。二つ目は、通常・例外・失敗を含む入力と期待結果の一覧です。三つ目は、未決事項と確認担当、判断する時期の一覧です。この三つがそろうと、決まっていることと調査が必要なことを共有できます。

たとえば「資料の自動更新が可能か」を未決事項に置き、システム管理者が接続方法を確認する、と記録します。試験中は手動更新で進める場合、その暫定運用も明記します。後から自動連携が当然に含まれると思われないよう、開発範囲と運用上の対応を分けて残してください。

まとめ

AIアプリの要件定義でも、業務範囲や入力・出力を決める点は通常のシステムと変わりません。それに加えて、良い出力の基準、人が確認する範囲、AIが答えられない場合の動きを決めておくことが重要になります。決めきれない項目は無理に確定させず、試験導入で確かめる計画にしておけば、要件定義を長引かせずに済むでしょう。

e-Grantsでは、AIアプリケーションの開発を、課題の整理と要件定義から設計・開発、公開後の保守運用まで一貫して支援しています。要件の整理から相談したい方は、AIアプリケーション受託開発のページをご覧ください。