AIアプリ開発を依頼する前に、整理しておきたい5つのこと

AIアプリケーションの開発を相談するとき、完成した仕様書が最初から必要とは限りません。まずは「今の仕事のどこで困っているか」と「どう変えたいか」を言葉にすることが、開発内容を具体化する出発点になります。

この記事では、開発会社との打ち合わせに向けて整理したい項目を紹介します。以下は依頼内容を考えるための一般的な整理例です。

1. 解決したい仕事を一つ選ぶ

「AIで効率化したい」だけでは、開発する機能や評価方法を決めにくくなります。「見積もり前の資料確認に時間がかかる」「問い合わせの回答案を毎回書いている」など、作業の単位まで具体化しましょう。

最初から会社全体の業務をまとめて変えようとせず、一つの作業について、誰が、いつ、何をしているかを書き出します。作業の回数や所要時間が分かれば、導入前後の変化を考える材料にもなります。

2. 入力・出力・人の確認を決める

例えば、問い合わせへの回答案をつくるアプリなら、次のように整理できます。

出力の形は、チャットの文章だけとは限りません。項目別の一覧、書類の下書き、既存システムへ登録するデータなど、次の作業で使いやすい形を考えます。

3. 使えるデータと更新担当を確認する

社内資料を使う場合は、ファイルの置き場所、形式、更新頻度、閲覧できる人を確認します。同じ内容の古い版と新しい版が混在していないかも、見ておきたい点です。

資料を検索して生成に利用するRAGは、外部の情報を参照しながら回答をつくる設計の一つです。元になった研究では、検索と文章生成を組み合わせる方法が示されています。RAGの原論文

RAGを採用する場合も、古い資料をどう更新するか、アクセスできない資料をどう扱うかは、アプリケーション側で設計する必要があります。「資料を入れれば終わり」にせず、公開後の管理まで相談しましょう。

4. 使えるかどうかの判断基準をつくる

開発前に、実際の業務に近い入力例と、期待する出力を用意します。正解が一つに定まらない文章でも、必須項目の有無や、根拠を示せているかは確認できます。

• 必要な情報が出力に含まれているか。
• 資料にないことを断定していないか。
• 人が確認・修正しやすいか。
• 情報が足りない場合に、それを伝えられるか。

試用時は、うまくいった例と修正が必要だった例を残します。その記録が、改善する機能や、利用対象を広げるかどうかを判断する材料になります。

5. 開発費と運用費を分けて考える

費用には、最初の設計・開発に加え、クラウドやAIの利用、保守運用、追加改修などがあります。想定利用者数、利用頻度、扱うデータ量が分かる範囲で伝えましょう。

最初の相談では、予算を一つの確定額にするよりも、優先したい機能と後から追加できる機能を整理すると、開発範囲を話し合いやすくなります。

問い合わせ回答アプリの依頼メモを作る例

架空の部品販売会社で、営業担当者が商品仕様を調べてメールに回答しているとします。依頼するのは、問い合わせ本文と承認済みの商品資料から回答案を作るアプリです。価格交渉と納期の確約は営業担当者が引き続き行います。

相談前のメモは、次の程度まで具体化できれば十分です。これは記入例であり、実際の導入実績ではありません。

未決事項を隠して完成した仕様に見せる必要はありません。「資料の最新版を確認できていない」と書いてあれば、開発会社もデータ整理の工程を見積もれます。逆に、分からない項目を空欄のままにすると、双方が異なる前提で話を進めがちです。

入力例と期待する回答を一組用意する

入力例を「型番Aの屋外利用は可能ですか。屋根のない場所への設置を検討しています」とします。参照する仕様書には「屋内専用」とあり、代替品の情報はありません。

期待する出力は「型番Aは屋内専用のため、屋根のない屋外への設置には対応していません。代替品は担当者が確認します」という回答案です。あわせて資料名と該当ページを表示します。代替品の型番を推測で書いたり、「防水カバーがあれば利用できる」と条件を創作したりした場合は不合格にします。

この一組があれば、「正確なAIが欲しい」という要望を、開発者が確認できる条件へ変えられます。入力例を用意するときは、顧客名やメールアドレスなど、検討に不要な情報を架空の値へ置き換えてください。

最初の打ち合わせを進める順番

最初に、担当者が普段行っている作業を画面や帳票で説明します。次に、その中からAIに任せたい箇所を選び、入力と出力の見本を並べます。この段階で、AIを使わず検索画面を改善するだけで足りると分かることもあります。

その後、資料の利用権限と連携方法を確認します。販売管理システムへの接続がまだ分からないなら、最初は担当者が必要情報を入力する範囲で試す案もあります。連携の調査を待たずに、回答案が役立つかを先に確かめられるためです。

最後に、試験導入で確かめる項目と、試験後に決める項目を分けます。回答案の品質は試験で確認し、利用人数の拡大や自動送信は結果を見て判断する、といった進め方です。試験で何を判断するかは、AIの試験導入の進め方でも整理しています。

見積もりの金額を比較する前にそろえる条件

同じ「問い合わせAI」でも、資料を手動登録する構成と、社内システムから自動取得する構成では作業量が異なります。比較する際は、画面、資料の取込み、権限設定、評価、公開後の対応が、それぞれどこまで含まれるかを確認しましょう。

たとえば、一方の見積もりに「資料の初回登録」だけ、もう一方に「規程変更時の差し替え画面」まで含まれる場合、総額だけでは比較できません。初期費用、毎月発生する費用、追加変更の扱いを同じ表に並べると、差の理由が分かります。

納品物も、アプリ本体だけでなく、設定の管理方法、評価に使った例、資料更新の手順まで確認しておくと、担当者が変わっても運用を続けやすくなります。詳細な項目はAIアプリの要件定義を参考にできます。

開発を始めるか判断するための確認

試験で回答がきれいに生成されても、担当者が根拠確認に長い時間を使うなら、当初の困りごとが解消されているとは限りません。資料を探す時間、回答を直す時間、送信前の確認時間を合わせて比較します。

判断に迷う場合は、通常の問い合わせ、情報不足の問い合わせ、対象外の相談の三種類を同じ担当者に試してもらいます。通常の回答が使えることに加え、情報不足を伝えられること、対象外の判断を人へ戻せることまで確かめます。進める条件を満たさなければ、資料の整理や対象範囲の縮小から見直せます。

相談の準備が十分かを見分ける

資料がそろっていなくても、現在の作業を担当者が説明でき、実際に使った帳票や入力の見本があれば相談を始められます。逆に、機能の一覧だけが長く、誰が使うか分からない状態では、優先順位を決める打ち合わせが先に必要です。

開発会社へ渡す資料は、目的ごとに分けると確認しやすくなります。業務の説明、入力例、期待する結果、参考にする資料、未決事項を区別します。資料が多い場合も、まず代表的な一件を選び、その仕事が始まってから終わるまでを説明してください。

相談後は、決まった範囲と調査が必要な項目を双方で確認します。見積もりを待つ間に誰が何を調べるかを決めておけば、資料の権限や連携方法が分からないまま話が止まることを防げます。

費用や期間について確定した回答が出ない場合は、判断に不足している条件を聞きます。資料の件数が分からないのか、接続先の調査が必要なのかによって、次に用意する情報が変わります。最初から完全な仕様書を作ることより、判断に必要な材料を一つずつそろえることが、依頼を具体化する近道です。

相談時に持っていくもの

現在の業務の説明、利用者、入出力の例、使いたい資料、希望時期や予算感があれば、最初の打ち合わせを進められます。まだ決まっていない項目は、未定のまま共有してください。

e-Grantsでは、課題整理・要件定義から設計・開発、公開後の保守運用まで対応しています。AIアプリケーションの受託開発についてをご覧ください。