いまAIを載せるか、待つか

AI機能をプロダクトに載せるかどうかの相談で、最も多い論点は「いま作るべきか」です。作れば競合に先行できそうに見え、待てば投資が無駄にならずに済みそうにも見えます。

判断を難しくしているのは、モデルの性能が短い周期で上がり続けていることです。いま苦労して作り込んだ精度改善の工夫が、次のモデル更新で不要になることは珍しくありません。本記事では、どの課題を待ち、どの課題にいま着手するかの見分け方を整理します。

「性能が上がれば消える課題」を見分ける

最初にすべきは、解決したい課題が、モデルの性能向上によって自然に消えるものかどうかの判別です。

性能向上で消えやすいのは、モデルの一般的な能力の限界に起因する課題です。長い文章を扱いきれない、指示の細かい条件を守りきれない、専門用語の扱いが雑、複雑な手順を最後まで実行できない、といったものが該当します。これらを補うために工夫を積み上げても、その工夫は次の世代のモデルでは不要になります。

一方、性能向上では消えない課題もあります。

• そのデータを自社が持っていない、または使える形になっていない
• 既存の業務システムとつながっていないため、出力を使う場所がない
• 誰が結果に責任を持つか、業務上のルールが決まっていない
• 利用者が現在の業務手順を変える動機を持っていない

これらはモデルの能力とは無関係で、どれだけ性能が上がっても自動的には解決しません。逆に言えば、ここに手をつける作業はいま始めても無駄になりません。

判別の簡単な目安として、「この課題は、いまより格段に賢いモデルが無料で使えるようになったら解決するか」と自問してください。解決するなら待つ、解決しないならいま着手する、という切り分けができます。

いま作ったほうがよい場合

待つことが常に正しいわけではありません。次のいずれかに当てはまるなら、いま着手する意味があります。

データが時間とともにしか溜まらない場合。 利用の記録、業務の履歴、修正の履歴といったデータは、後から一気に買ってくることができません。着手が遅れた分だけ、そのまま差になります。

業務への食い込みに時間がかかる場合。 利用者の業務手順に組み込まれるまでには、導入、慣れ、社内の合意といった過程が必要です。この時間は技術の進歩では短縮されません。

いまの性能でも十分に使える課題の場合。 要約、分類、下書きの生成、形式の変換といった用途は、現在のモデルで実用に足りることが多く、性能向上を待つ理由がありません。待っても得られるものは、費用が下がることくらいです。

課題の検証自体が目的の場合。 利用者がその機能を欲しがるかどうかを確かめたいなら、精度が完璧である必要はありません。小さく作って反応を見る投資は、モデルの世代とは別の価値があります。

待つと決めたときにやっておくこと

「待つ」は「何もしない」ではありません。待つ判断をしたら、次の二つを先に決めておきます。

着手の条件を書き出す

「そのうち検討する」で止めると、判断が先送りされ続けます。何が起きたら着手するかを具体的に書いてください。たとえば、「特定の作業を手作業でこなす時間が月にどれくらいを超えたら」「利用者からの要望が繰り返し届くようになったら」「いま試して精度が足りなかった処理が、次に試したときに実用水準に達したら」といった形です。

条件を書いておけば、定期的に確認するだけで済み、感覚的な判断を避けられます。四半期に一度、同じ処理を最新のモデルで試し直す、という運用を入れておくと確実です。

いまから溜められるデータを決める

着手したときに使えるデータを、いまのうちから残しておきます。手作業で処理している業務なら、入力と出力の組を記録しておくだけでも、後の検証に使えます。個人情報を含む場合は、匿名化の方針を先に決めておきます。

想定例として、問い合わせ対応を人手でこなしている企業を考えます。いまAIで自動回答を作るのは早いと判断した場合でも、実際の問い合わせ文と担当者が返した回答の組を整理して残しておけば、着手時に「本当にこの品質で答えられるか」を即座に検証できます。この蓄積があるかどうかで、着手後の立ち上がりが大きく変わります。

作る場合に、無駄になりにくい作り方

いま作ると決めた場合でも、モデルの更新で壊れにくい作り方があります。

• モデルは差し替えられる部品として扱い、特定のモデルの癖に依存した作り込みを避ける
• 精度を補うための工夫と、業務の要件に由来する処理を、コード上で分けておく
• 出力の良し悪しを人が判断した記録を残し、モデルを替えたときに比較できるようにする
• 費用と応答速度の上限を先に決め、モデルを替えても運用条件が崩れないようにする

この分け方をしておくと、次のモデルが出たときに「モデルの弱点を補う部分」だけを削れます。分けずに書くと、どこを消してよいか分からなくなり、技術的負債（後回しにした設計上の問題が積み上がった状態）として残ります。詳しくは技術的負債との付き合い方もあわせてご覧ください。

弊社は既製のAIサービスを組み込む立場なので、モデルの性能そのものを改善する手段は持ちません。だからこそ、モデルに任せるべき部分と、こちらで作り込むべき部分を分ける設計を重視しています。

「競合が出したから」は着手理由にならない

最後に、判断を誤らせやすい動機について触れます。競合がAI機能を発表したという理由だけで着手を決めると、自社の課題と無関係な機能に資源を使うことになります。

確認したいのは次の点です。その機能は競合の利用者に実際に使われているのか。発表されただけで、利用は限定的ではないか。自社の利用者は同じものを求めているのか。求めているとして、いまの自社の体制で運用まで回せるのか。

発表と定着は別のものです。焦って載せた機能が使われず、保守の負担だけが残る状況は避けたいところです。

判断を先送りせず、条件で決める

いまAIを載せるかどうかは、モデルの性能向上で消える課題かどうかで切り分けられます。消える課題は待ち、消えない課題（データ、業務への接続、責任の所在）にはいま着手する。待つと決めたら、着手の条件と、いまから溜めるデータを決めておく。作ると決めたら、モデルに依存した作り込みを分離しておく。この四つで、判断の質はかなり上がります。

自社の課題がどちらに当てはまるか整理したい方は、お問い合わせからご相談ください。オンラインで状況を伺い、待つ判断も含めてお伝えします。ご相談・お見積りは無料です。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。