最近、生成AIの案件をやっていて、今のところ一番成功率が高いと思っている進め方があります。
分かっているところは、さっさと形にする。不確実性が高いところだけを検証する。そこから評価しながら磨き込む。
結局これなんですよね。
うちは以前から、商談の段階で動くデモを持っていくことがありました。お客さんから話を聞いて、「こういうことですよね」とある程度理解できたら、実際に触れるものを作って見せます。
すると、「ここは違います」「この機能も欲しいです」「実際の業務ではこう使います」と、資料だけで話していたときには出てこなかった要件が普通に出てきます。
むしろ、早い段階で出てくれた方がいいですね。
今はPM on Railsで要求を整理して、実際の利用場面まで具体化し、そこからかなり短い時間でデモまで持っていけます。
これだけ聞くと、「生成AIを使って開発が速くなった」という話に見えます。でも、たぶん本質はそこではないと思っています。
確実な部分をすぐ形にすることで、本当に分からない部分だけを残せる。そこからすぐ評価と改善のサイクルに入れる。
今のところ、俺らはこれが生成AI開発で一番成功率が高いパターンだと思っています。
逆に、これをしないと普通に失敗します。
生成AI・DXの案件は、不確実性が高いです
生成AIを業務へ入れる案件は、普通のシステム開発よりも「実際にやってみないと分からないこと」が多いです。
例えばですが、社内の資料を読ませて、社員からの質問に答える仕組みを作るとします。
質問する画面を作る。資料を登録できるようにする。回答を画面に表示する。こうした部分は、そこまで不確実性が高くありません。過去の開発経験から、かなりの部分を普通に作れます。
一方で、お客さんが実際に持っている資料を入れたときに、本当に必要な情報を探せるのか。質問の言い方が変わっても正しく答えられるのか。答えがないときに、もっともらしい間違った回答をしないか。
このあたりは、実際にやってみないと分かりませんね。
帳票をAIで読み取る仕組みも同じです。
画面は作れますが、お客さんが実際に持っている何十種類もの帳票でちゃんと読めるかは、やってみないと分かりませんね。
数字の読み間違いがどこで起きるのか、レイアウトが変わるとどうなるのか、手書きが混ざったらどうなるのか。こういう部分が生成AI案件の不確実性です。
今は生成AI自体もまだ黎明期なので、この不確実性がかなり高いです。だから、最初から全部できる前提で大きく作り始めると、普通に爆発するリスクがあります。
しかも今は実装自体が速いので、間違った方向にもかなり速く進めてしまいます。そこは結構危ないと思っています。
必要ならNDAを巻いて、かなり早い段階で実物を見ます
生成AIの案件では、実際の資料やデータを見ないと判断できないことがかなりあります。
なので、社内資料や業務データを確認する必要がある場合は、秘密保持契約、いわゆるNDAを早い段階で締結します。
守秘の整理ができたら、実際の資料やデータを見ながら考えます。
もちろん、個人情報や機密情報を何でもそのまま生成AIへ入れるという意味ではありません。データの扱い方や利用する環境は先に整理します。
ただ、実際の業務ではどんな資料を使っているのか、どんなデータの揺れがあるのかを見ないまま、想像だけで何週間も仕様を考えても仕方ないんですよね。
例えば帳票なら、実物を見ればレイアウトが何種類くらいあるのか、手書きがあるのか、項目名が会社ごとに違うのかがすぐ分かります。
社内検索でも、資料がきれいに整理されているのか、同じ内容の古い版が大量にあるのかで難しさが全然違います。
なので、必要ならNDAを巻いて実物を見る。分かるところはそのままデモにする。この段階までかなり早く進めます。
確実なところは先にデモにします
全部に不確実性があるわけではないので、分かっているところまで検証する必要はありません。
確実な部分は、さっさと形にします。
うちではまず、PM on Railsでお客さんの要求を整理します。
単に「AIで社内検索をしたい」という話だけではなく、誰が、どんな状況で、何をして、どうなればいいのかまで具体化します。
例えばですが、営業担当者が商談前に顧客名を入力する。過去の関連資料を探す。閲覧権限のある資料だけを使って回答する。回答の根拠になった資料も確認できる。このくらいまで具体化します。
さらに、抜けている利用場面や要求同士の矛盾がないかをAIにもレビューさせます。
ここまで整理できれば、確実な部分はかなり早い段階でデモにできます。商談の段階で見せることもありますし、NDA締結後に実際の資料を確認して、そのままデモを作ることもあります。
実際に触ってもらうと、「ここは違う」「この情報も必要」「実際はこの順番では使わない」といった話が出てきます。
これは問題ではなくて、むしろ早い段階で出てくれた方がいいですね。
開発がかなり進んでから「思っていたものと違いました」となるより、圧倒的に安く直せます。
そこで出てきた内容をまた要求へ戻して、デモを直します。
最初から完璧な要件定義を作ってから開発するというより、動くものを使いながら要件の精度を上げていくという感じです。
すると、本当に検証しないと分からない部分だけが残ります
確実な部分をデモで確認すると、かなりの認識のズレを先に消せます。
そうすると、次に考えることがシンプルになります。
結局、まだ何が分からないのか。
例えばですが、社内検索なら、本当に検証したいのは検索画面を作れるかどうかではありません。実際の社内資料を入れたときに、必要な回答を十分な精度で返せるかです。
帳票の読み取りなら、画面が作れるかではなく、実際に使われている帳票で必要な項目を正しく取得できるかです。
そこだけを小さく検証します。
生成AIを使う案件だからといって、全部をPoCにする必要はないと思っています。
確実な部分は先に形にして、不確実性が高いところだけに検証の時間とお金を使う。この順番の方が、かなり合理的だと思っています。
ただ、試すだけではダメです
不確実性が高い部分が分かったら、小さく検証します。
ただ、ここでもう一つかなり重要なのが、先に何をもって成功とするか決めることです。
生成AIが回答できました。帳票を読み取れました。分類もできました。
それだけでは、本番に進んでいいのか分かりません。
例えばですが、100件中90件正解したとします。
でも、残り10件の中で請求金額を間違えていたら、本当に90％でいいのかという話になります。
商品説明の一部を間違えるのと、金額を間違えるのでは、同じ1件でも意味が違いますね。
なので、何を正解とするのか。どんな失敗は絶対に許容できないのか。どこまでなら人間が確認すれば使えるのか。どこまでできれば本番へ進めるのか。
このあたりを先に決めます。
生成AI開発では、作るものの設計だけではなくて、評価の設計がかなり重要だと思っています。
ここがないまま始めると、最後に「なんとなく良くなりました」で終わってしまいます。それだと次に進めません。
正解付きの評価用データを作ります
評価方法を決めたら、実際の業務に近い問題と、その正解を用意します。
いわゆるゴールデンセットと呼ばれるものですが、要するにAIに毎回解かせる正解付きの問題集ですね。
社内検索であれば、「この質問には、この内容が含まれていれば正解」と決めます。
答えが存在しない質問なら、無理に答えず「分からない」と返せれば正解にする。
帳票であれば、実際に使うものに近い帳票と、正しい会社名、金額、日付などを用意します。
これを持っておくと、何かを改善したあとに、毎回同じ条件で評価できます。
最初は100問中72問だった。検索方法を変えたら81問になった。ただ、契約条件に関する質問だけは前より悪くなった。
ここまで分かれば、次に何を直すべきかも分かります。
生成AIは、一つの部分を直したら別の部分が悪化することもあります。なので、一部だけを見て「改善しました」と判断せず、毎回同じ評価を通します。
これでようやく、感覚ではなく数字と失敗例を見ながら改善できるようになります。
生成AI開発は、ここから磨き込むのが大変です
デモを作るところまでは、かなり速くなりました。小さな検証である程度の精度を出すところまでも、以前よりかなり速いです。
でも、実際の業務で安心して使えるところまで持っていくのは、また別の話です。
例えばですが、本番に近いデータを増やしたら、この種類の質問だけ精度が落ちた。この帳票だけ読み間違える。この言い方をするとおかしな回答になる。回答自体は正しいけれど、参照している資料がおかしい。
こういうことは普通に出ます。
なので、ある程度形になったところから、さらに磨き込む必要があります。
評価する。悪いところを見る。直す。もう一度同じ条件で評価する。また問題が見つかったら直す。
これを繰り返します。
今はAIで実装自体がかなり速くなっているので、この改善サイクルも以前よりかなり速く回せます。
たぶん、俺らの強みはここだと思っています。
単純にデモを作るのが速いというより、商談から評価と改善のサイクルへ入るまでがかなり速いんですよね。
今は黎明期なので、磨き込みまで最初から固定するのは難しいです
生成AI自体がまだかなり速いペースで変わっています。モデルも変わりますし、使い方も変わります。
会社ごとに持っているデータも違えば、どこまでAIに任せていいかも違います。
なので、ある程度形にした後の磨き込みについては、最初からやることを全部固定するのが難しい案件も多いです。
次に直すべきなのがAIへの指示なのか、検索方法なのか、元の資料なのか、画面なのか。場合によっては、そもそもの業務フローを変えた方がいいこともあります。
これは実際に評価してみないと分からないことがありますね。
なのでBeekleでは、ある程度形にして、評価できる状態まで持っていった後は、一定期間一緒に改善を続ける準委任契約が合う案件が多いと考えています。
準委任というのは、最初に完成品をすべて固定して納品する契約ではなく、一定期間チームとして開発や改善を続ける契約です。
これは「何をやるか分からないから準委任にする」という意味ではありません。
評価結果を見て、次にどこを改善するのが一番効果的なのかを決めたいんですよね。
確実な部分は先に作る。不確実性が高い部分については、実際の結果を見ながら優先順位を決める。
今の生成AI開発では、この方が合っているケースが多いと思っています。
本番運用で出た失敗も、次の評価に戻します
本番に出した後も改善は続きます。
実際に利用されると、開発中には想定していなかった質問やデータが出てきます。
「こんな聞き方をするのか」とか、「ここで間違えるのか」というケースですね。
これをその場で直して終わりにはしません。
同じ失敗を次から見逃さないように、正解付きの評価用データへ追加します。
そうすると、次回からはその問題も毎回評価できます。新しい失敗が見つかったら、また追加する。
これを繰り返すと、運用するほど、その会社専用の評価用データが育っていきます。
うちは開発だけではなく運用もやってきているので、ここはかなり重要だと感じています。
生成AIは納品して終わりではなくて、実際に使った結果を次の開発へ戻せるかどうかが大事なんですよね。
結局、確実なところは早く作って、不確実なところだけ検証します
今のBeekleの生成AI開発をまとめると、かなりシンプルです。
- 商談で、今困っていることや実際の業務を聞く
- 必要なら早い段階でNDAを締結して、実際の資料やデータを見る
- PM on Railsで要求と具体的な利用場面を整理する
- 確実な部分はすぐデモにして、お客さんに触ってもらう
- そこで認識のズレを直す
- 残った不確実性が高い部分だけを切り出す
- 何をもって成功とするかを決める
- 正解付きの評価用データを作る
- 不確実な部分だけを小さく検証する
- 評価して、直して、また評価する
- 本番で出た失敗も評価用データへ追加する
確実なところはさっさと形にする。不確実なところだけ検証する。そこから評価しながら磨き込む。
今のところ、俺らはこのやり方が一番成功率が高いと思っています。
逆に、これをしないと生成AI開発はかなり失敗しやすいです。
不確実性が高いまま大きく作れば、間違った方向へ開発が膨らみます。
評価方法を決めずに試せば、成功したのか分かりません。
デモが動いたところで終われば、実際の業務で使えるところまで届きません。
本番で出た失敗を評価へ戻さなければ、同じ問題を繰り返します。
生成AIで開発が速くなったからこそ、どこまで分かっていて、どこから分からないのかを最初に切り分けることが重要になったと思っています。
一発で完成させようとするより、早い段階で形にして、早く問題を見つけて、評価しながら直していく。
今はこの進め方が一番いいですね。
まだ仕様が固まっていない段階でも相談できます
生成AIを業務に使いたいけれど、まだ何を作ればいいか決まっていない、という段階でも問題ありません。
最初から完璧な仕様書を用意する必要はないと思っています。
今何に困っているのか。誰が使うのか。今はどうやっているのか。どんな資料やデータがあるのか。どうなれば「導入して良かった」と言えるのか。
まずはそこから整理します。
必要ならNDAを締結したうえで実際の資料も確認して、分かっているところは早く形にする。実際に試さないと分からないところだけを検証する。そこから評価しながら磨き込む。
生成AI開発は、この順番で進めるのが今のところ一番失敗しにくいと思っています。
Beekleの生成AI受託開発 「何にAIを使うべきか」の整理から、動くプロトタイプでの検証、現場で使われる本番運用まで。発注前に実物で確かめるゼロスタート開発にも対応しています。 Beekleにご相談ください Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。