生成AIのPoCが終わった後のことを考えていますか？顧客の既存システムへの導入を考えた際のベストなPoCの進め方
はじめに
1週間前に以下の記事を投稿したところ、Xで100以上のリツイート、700以上のいいね、noteでも300以上のいいねがつきました。生成AIは多くの需要があるため、案件を獲得することはできますが初期PoCで赤字になるケースが多いように見受けられました。
上の記事で伝えているのはPoCで赤字になるケースを避ける方法です。
まとめると以下です。
1. 顧客の期待値調整がより重要であり、精度を指標にするとなかなか終われない。
2. できるだけ受託で受けずに、チューニングは稼働時間請求とする。
チューニングといった終わりのない作業を受託で受けることによって赤字リスクが高まるといった内容です。
PoCが終わった後はどうなるか？
PoCは実験と言い換えることができます。しかし、100-1000万円の金額と数ヶ月の時間を使うと、失敗したのでここでやめましょうとはなかなかなりません。今回のPoCの結果を元に今の既存システムへの導入に進むケースが多くなります。
PoC段階では顧客からExcelなどでデータを連携してもらいましたが、そのデータは既存システムからエクスポートしたデータです。そのため、本開発では既存システムと今回のPoCのシステムを繋ぐ必要があります。
既存システムとの連携は現場への浸透を考慮すると必須
完全にシステムを分離させて、データのやり取りは人がやってくださいなどと伝えることもできますが、かなり渋られるはずです。現場のアルバイトまで含めた全メンバーに生成AIを使ってもらうためには既存システムとの連結がほぼ必須です。
チャットボットは生成AIのわかりやすいケースですが、チャットボットが社内で多く使われているケースを私の観測範囲ではありません。この記事を読んでいるあなたや顧客の生成AI担当者は、生成AIに非常に興味があるため、チャットボットを使うことができますが、9割以上の人は生成AIに興味はありません。運用が変わることがストレスであり、その運用に強制力がなければ使われません。
一番の理想は、現場のメンバーの運用を全く変えず生成AIが入っている状態です。具体的に使われるケースと使われないケースを用意しました。
1. 現場で使われるシステムのユースケース
今まではアルバイトがGoogleシートを開いて、A-Z列まで入力しないといけなかったが、生成AIによってA-Z列まで事前に入力されており、アルバイトはその内容確認をする。
2. 現場で使われないシステムのユースケース
今まではアルバイトがGoogleシートを開いて、A-Z列まで入力しないといけなかったが、アルバイトは生成AIのシステムに新しくログインして、チャットボットに情報を入力することで、A-Z列までの情報が出力され、それをGoogleシートにコピペしてその内容確認をする
既存システム統合を本実装を行う際に避けるべきケース
ある程度の規模の企業の場合、得意先ベンダーがいます。そしてほとんどAWSなどのインフラでシステムが動いています。ここまでが前提です。
本システム導入で避けるべきケースは以下です。
1. 顧客のAWSアカウントを発行してもらい、そこで設置する
一番避けるべきはこのケースです。まずあなたはAWSについて詳しいかもしれませんが、顧客のAWSの構成について学習することは非常に時間がかかります。また既存システムに何らかの悪影響を与えた場合、賠償請求までつながる可能性まであります。顧客のインフラに入ってPoCシステムを設置することはリスクが高すぎます。（もしこの選択をせざるを得ない場合は既存システムに絶対触れないIAMを発行してもらいましょう。）
2.顧客ベンダーにコードを提供して、インフラとシステムを熟知したベンダーに設置してもらう。
1よりはマシです。これがPoCコードです。実装はお願いします。何か不明点あれば聞いてください。サポートします！といった流れです。
ただ、これは顧客ベンダーにそれなりにコードを解析してもらう必要があったり、動作がおかしい場合にPoC側が問題なのか、ベンダーの設置ミスなのかが不明瞭になり、原因調査に時間がかかります。
既存システム連携において、現時点のベストな進め方
私は以下の条件がベストだと考えています。
APIとして提供する
APIは顧客のインフラに顧客のエンジニアが配置してもらう
顧客ベンダーはそのAPIを使うだけで処理が完結する。
さらに上記に加えて、生成AIのPoCの条件です。
4.チューニングが多く発生することに対応できる
ここまでの条件を合わせた場合、以下のn8nがおすすめです。
このサービスは生成AIをGUIワークフローで作ることができ、各種ツールとの連携が容易にできます。AWS Bedrockなどもサポートしています。
さらにセルフホストができることで、このドキュメントを見て顧客に設置してもらえます。そしてこのワークフローはAPIで実行ができます。
つまり、n8nのPoCを使えば以下の流れができます。
PoCではn8nで良い結果が出るワークフロー or AI Agentを作ることができました。本番では御社のインフラにセルフホストしていただき、ログイン情報をください。PoCで試したロジックを本番に移行し、APIで使えるようにします。APIのリクエストURLと引数は別途連携します！
このようにして顧客の既存システムを一切考慮することなく、PoCの生成AIシステムを顧客の既存システムに統合することができます。
チューニング回数が命
PoCと本番ではデータの差異が出ることがほとんどです。PoCは本番の全量データではなく一部データとなるため、本番のデータだからこそ発生するチューニングが必要になります。
コード実装をしていた場合は、修正したコードを再度顧客のエンジニアに依頼してデプロイしてもらう必要があります。これはスピードが遅くなります。しかし、顧客のインフラをよく知らない私たちが触る方がリスクが高いので仕方ありません。
今回の構成のように、チューニングはGUI / 用意した中で行う場合は、チューニングしてから本番反映までの時間がかかりません。顧客ベンダーの手を借りずにチューニングを進めることができ、より良い精度を出すことができます。
最後に
PoCは本番に繋げてこそ意味があります。またこの本番を見据えた提案はPoCの案件受注前に求められます。PoCだけで終わらそうとは顧客も考えていません。
今回のnote記事に書いた提案がPoCに興味あるレベルの顧客にできれば、本番での運用や現場メンバーへの浸透まで考慮されているため、それなりに刺さるはずです。ぜひ提案の参考にしていただければ嬉しいです！
コメント