予算をかけずに始めるPoC

AI活用の相談で、最初に予算の話になることがあります。検証だけでも数十万円から、という前提で社内の稟議を準備している、という状況です。

開発会社としては受注したいところですが、正直に申し上げると、多くの場合その前にやるべきことがあります。その業務がAIに向いているかどうかは、開発せずに、既製のツールと手作業で相当のところまで確かめられるからです。そこで向いていないと分かれば、開発費はまるごと使わずに済みます。

本記事では、予算をかけずに検証する手順を整理します。

開発しないと分からないことは、実は少ない

AI活用の検証で確かめたいことを分解すると、次の三つに分かれます。

1. その業務の判断や作成を、AIが許容できる水準でこなせるか
2. 出力を人が確認する手間を含めても、現行より楽になるか
3. 実際の量と、既存システムとの接続に耐えるか

このうち1と2は、既製のツールに手でデータを入れて試せば確かめられます。開発が必要になるのは3だけです。そして3は、1と2がだめだった場合には確かめる必要がありません。

にもかかわらず、多くのPoCは最初から3を含めた形で設計されます。結果として、1の時点でだめだと分かるものに、システム開発の費用がかかることになります。順番を逆にしてください。

手順1: 対象業務を一つに絞り、現行を測る

まず、対象にする業務を一つ選びます。「問い合わせメールへの一次返信案の作成」「見積書の内容チェック」のように、始まりと終わりがはっきりした作業単位にします。

次に、現行のやり方で1件あたり何分かかっているかを測ります。これを先にやるのが重要です。後から測ると、AIを使った時間と比較する基準がなくなります。

測り方は簡単で構いません。担当者に10件分の作業時間を記録してもらえば十分です。このとき、簡単な件と手間のかかる件の両方を含めてください。平均だけでなく、ばらつきが分かります。

手順2: 検証用のデータを、整えずに集める

対象業務で実際に扱っているデータを、30件程度集めます。ここで最も大事なのは、整えないことです。

表記が揺れている、添付が抜けている、書式がばらばら。こうした状態こそが本番の姿です。整えたデータで良い結果が出ても、それは何も証明していません。

ただし、個人情報や取引先が特定できる情報が含まれる場合は、その部分だけを別の文字列に置き換えてください。汚れ方は保ったまま、識別できる情報だけを落とすのが原則です。

件数は多くなくて構いません。それより、例外的なケースを意図的に3割ほど混ぜてください。うまくいかない条件を早く見つけることが目的だからです。

手順3: 既製ツールに手で入れて試す

ChatGPT、Claude、Geminiといった一般向けのAIサービスに、集めたデータを手で入力して結果を見ます。専用の開発は一切しません。

このとき、次のことを守ってください。

• 指示文は毎回同じものを使う。 件ごとに指示を変えると、何が効いているのか分からなくなります
• 試すのは3回まで。 指示文の調整は数回で打ち切ります。何十回も調整して出た結果は、本番の水準ではありません
• 利用規約と学習利用の設定を確認する。 業務データを入力する前に、そのサービスの入力データの扱いを確認してください

業務の性質によっては、既存のSaaSに搭載されているAI機能で試すほうが実態に近い場合もあります。すでに契約しているツールにAI機能が付いていないか、先に確認してみてください。

手順4: 確認にかかった時間を記録する

ここが、この検証の中心です。AIの出力そのものではなく、その出力を担当者が確認して使える状態にするまでの時間を測ります。

記録するのは次の三つです。

三つ目が多い場合は、注意が必要です。AIの出力を読んで直すより自分で書くほうが速い業務は、AIに向いていません。この判定は、精度の数字を見ていても分かりません。担当者に実際にやってもらう必要があります。

手順1の時間と比較して、手間が減っていないなら、そこで検証は終わりです。開発費を使う前に結論が出ました。

手順5: うまくいかなかった入力を保存する

手順3と4で、期待通りにならなかった件を必ず保存してください。何が入力で、何が出力で、何が問題だったか。この記録が、この検証の最大の成果物です。

保存したものを眺めると、うまくいかない条件に傾向が見えてきます。特定の書式のときに崩れる、情報が不足している件で推測が入る、専門用語の解釈がずれる、といった形です。

この傾向が、次の判断を決めます。傾向が業務の一部に限られるなら、その部分だけ人が処理する運用で足りる可能性があります。傾向が全体に及ぶなら、開発しても解決しません。

手順6: 手作業では無理になる条件を書き出す

ここまでで有望だと分かった場合に、初めて開発の話になります。そのとき最初に書き出すのは、機能の一覧ではなく、手作業のままでは回らなくなる条件です。

• 一日に処理する件数が、手で入力できる量を超えている
• 複数人が同じ手順を実行する必要があり、品質がばらつく
• 既存システムからデータを取り出す作業に時間がかかっている
• 処理の記録を残す必要があり、手作業では追跡できない

このリストが、開発すべき範囲そのものになります。逆に、このリストに何も書けない場合は、開発せずに担当者の手元運用のまま続けるのが合理的です。これは実際に珍しくない結論で、業務量が少ない工程では手元運用のほうが費用対効果が高いことがあります。

開発が必要になるのは、有効性が分かったあと

弊社は開発を請け負う会社なので、「まず開発しない検証を」という提案は仕事を減らす方向の話です。それでもこの順番をおすすめするのは、有効性が分からないまま作ったシステムが、使われないまま止まる例を見てきたからです。

ここで挙げた手順は、外部に頼まなくても自社で実行できます。必要なのは、業務を知っている担当者が、週に数時間この検証に時間を割けることだけです。そこで手応えがあり、量と接続の問題で手作業が回らなくなったときが、開発を検討する段階です。詳しくはPoCを誰に頼むか、自社でやるかもあわせてご覧ください。

弊社はAI活用開発およびWebシステム開発として、既存のAIサービスを組み込んだ実装をお引き受けしています。この検証の結果をお持ちいただければ、どこから作るべきかのご相談から入れます。オンラインで全国対応しており、ご相談・お見積りは無料です。お問い合わせからご連絡ください。

本記事は一般的な情報であり、個人情報を含むデータの取り扱いについては、個別の事案を専門家にご確認ください。