生成AI・AIAgentのPoCの泥沼化を避けるには？[受託開発会社向け]
はじめに
私は生成AIの様々な案件を現在行っています。生成AIは経営層ほど危機感を持っているため、顧客の経営層から担当者に自社の業務改善を生成AIで進めるように！と依頼が降りてきます。
しかし、従来のシステム開発と違い生成AIはどこまでできるかが不明瞭です。そのため、PoC(本当に生産性アップするか実験)として始められることが99%です。そのPoCでうまくいけば小規模開発・本格開発しましょうといった流れになります。
私は案件を受ける側なので、今回は生成AIの案件を受ける側が気をつけるポイントを全て実体験ベースで書きます。
前提：PoC = 低予算
PoCはお試しです。開発会社からすればドアノック商品とも言えます。そのため受託開発会社からすると顧客に提案できる金額は低くなります。PoCであれば最大でも500万円程度です。
では、生成AI・PoC・低予算の条件が揃った時に何を気をつけるべきかを書いていきます。
1.生成AI PoCの対象は、毎日発生する社内の単純作業にすべき
まず領域の選定です。一番重要なことはそもそも、生成AIは2025年3月現在ではまだ人のサポートなしで業務に入れることはできません。そのため、生成AIの出力は社外にそのまま出すべきではありません。
逆に避けるべきは、1週間に1,2回しか発生しない低頻度のものです。これは2のポイントにつながりますが、生成AIの精度を求められて泥沼化につながりやすいです。
2. 顧客と握る指標は精度以外にすべき(重要！)。
生成AIは従来のシステム開発と違い、100,0のルールベースで定義できるものではありません。そのため、どこまでできるか初めて見ないとわかりません。しかし、生成AIの出力精度を報告基準とするとそのPoCは泥沼化します。
なぜなら精度は100に近づけば近づくほど、かかる工数がどんどん大きくなっていく性質があるためです。さらにこれはPoCです。工数をかける余裕はありません。
また精度を出すには客観的な指標が必要であり、この客観指標は非常に作成に時間がかかります。
[Point]
生成AIを用いて作業時間の短縮を指標にしましょう。従来は10時間かかっていましたが、1時間になりました。これを組織で導入すれば1000時間が10時間になります。
この伝え方、合意を取ることが非常に重要です。結局精度を追い求めても作業時間が短縮できなければコスト削減できないですよね？と顧客にきちんと言いましょう。
作業時間であれば、担当者1,2名を集めて実際に作業してもらうことで証跡とできます。
ポイントの1と繋がります。毎日発生する業務であれば作業時間を精度に持っていきやすいですが、1週間に数回だと作業短縮が見えにくく精度を指標にされる可能性があり、泥沼化のリスクが高まります。
3.PoCは受託で受けずに、稼働時間で受けるべき
精度との合わせ技で泥沼化しますが、精度は上げればあげるほど工数の割に上がっていきません。さらに顧客はドメインの理解があるので、こうすればもっと上がると改善アイデアはたくさん出てきます。
ここで問題は受託で受けてしまうと、顧客の改善アイデアを泣き寝入りでやらないといけません。しかし、精度が上がるほど工数と見合わなくなってきます。そのため、辞めどころが難しくなります。
しかし、稼働時間で請求できれば、精度が上がらなくても工数を請求できますし、あまり上がらないと思うので辞めた方が…などといった提案もしやすくなります。
4.PoCを受託で受ける場合は、チューニングは範囲外とすべき
とはいえ、受託でないと顧客側が予算や稟議の問題でダメと言われる可能性もあります。その場合は、初期レポートまでを受託で受けて、そこからのチューニングは稼働時間で請求しましょう。
※最初に受託で受けません！と伝えるのは、チューニングを稼働時間請求の落とし所に持っていくための交渉テクニックです（チューニング含めて受託で受けると赤字の可能性が跳ね上がります）。
この精度チューニングが失敗の大部分を占めます。重複しますが、顧客はドメインの理解があるので改善アイデアはたくさん出てきます。そしてそのアイデアはそれなりに確からしいです。だからやるしかないのですが、PoCの少ない金額とどんどん見合わなくなっていきます。
5.PoCは2フェーズに分けて、初期開発・チューニングで分けるべき。
4とほぼ同じ意味ですが、重要なのでMECE無視で何度でも書きます。PoCの開発とチューニングは明確に分けるべきです。このチューニングは工数で請求すること。とりあえずこれだけ覚えてください。PoCはチューニングが終わらずに泥沼化します。
6.PoCはプログラムコードで書かない。生成AIのGUIで作るべき
ここまではプロジェクトが赤字にならない守る方法ばかりでしたが、攻めについて書きます。PoCはできる限り成功に結びつける必要があります。そのためには生成AIが業務で使えるようにチューニングは必要です。そして精度を上げるにはチューニング回数を増やすことが重要です。
現在はChatGPTもAPI1本で呼び出すことができます。また、Cursor,Windsurfをはじめとするエディタを使うことでパッとデモを作ることができることは確かです。しかし、それであってもDifyやFlowiseなどのGUIで作る方がチューニング回数は増やせます。
またコードで書くが故に発生するバグも起こりません。慣れれば新入社員や営業マンなどエンジニア以外でもチューニングできます。
PoCで満足してもらうには、チューニング回数を増やすこと。チューニングを増やすにはGUIの生成AIツールで作るべきです。
7.PoCの納品物・成果物はパワポ・エクセルレポートにすべき
改めて今回は受託開発目線です。受託開発会社としては、PoCはその後の本開発に繋げることが目的です。そのため、顧客との空気感、関係値次第ですがコードの納品はなしに持っていきたいです。
さらに顧客が触れるシステムを用意することは避けたいです。なぜなら顧客が触れるインフラを作り、その精度がPoCで十分上がったとなれば、本開発に進むインセンティブがほぼなくなるからです。
この辺りは契約書にきちんと記載しましょう。PoCだけで終わってはシステム会社としても疲弊していくだけです。
8.これはPoCか改めて顧客に確認する
例えば7のポイントを参考に、今回の成果物はエクセルとパワポだけにしますと伝えた際に、顧客側にインフラも設定して自社でも触れるようにしてほしいと言われたとします。それはすでにMVP開発といえます。
つまりPoCではありません。その場合はインフラ構築費用や手順書・サポート費用を請求しましょう。逆にここの費用を渋られると泥沼の予兆です。そのPoCは魅力的な大企業からの発注であっても案件単体で見れば赤字になる可能性が高いです。
私の定義です。
PoC：担当者が次のMVP、本開発に進むか判断する情報を提供
MVP：顧客の担当者と関係者が使えるシステムを構築。さらに展開するかを検証
本開発：組織の多くが利用、さらにはプロダクトとして自社以外のユーザーも利用
PoC→MVP→本開発
最後にこの記事の一番重要な部分です。
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
PoCはチューニングを稼働時間請求にすべき
ゲシュタルト崩壊するかもしれませんが、後悔の叫びを書いておきます。生成AIのPoCはチューニングに気をつけてください。チューニングを稼働時間請求にしないと赤字の確率が跳ね上がります。きちんと利益を出さないと、持続性がありません。
生成AI、AI Agentのブームだからこそ、PoCの進め方に注意してください。