OpenAIが語るFDE、AIのデモを日々の業務につなぐ仕事

AIモデルは、渡された情報から文章や判断を作る部分です。「丁寧に返信して」といった指示がプロンプトです。ただし店の仕事には、注文記録、返品のルール、代金を返す権限も必要です。文章が上手なだけでは、誰が購入したのか、すでに返金した注文なのかは分かりません。

ここからは架空のネットショップ「そら商店」を例にします。お客さんから「昨日買った服を返品したい」と連絡が来ました。AIは「返品のお手伝いをします」と書けますが、処理を終えるには次の点を確かめなければなりません。

そら商店は、まずAIに注文を読ませ、返信の下書きだけを作らせることにしました。スタッフが内容を確認して返金を承認すると、決済システムが処理します。ここでいう「ツール」は、注文照会など、AIから呼び出せるようにつないだ機能です。AIが利用を提案しても、実行できるかどうかはシステムの権限と手順で判断する必要があります。

注文システムに接続できない場合や購入者を特定できない場合は、この例では処理中のふりをせず、スタッフに引き継ぎます。返金ボタンを押した後に通信が切れても、同じ注文に再び返金しないよう、処理記録を確かめる手順が必要です。失敗する場面も業務の一部です。

AIの評価、つまりevalは、任せたい仕事に沿った課題で結果を比べる試験です。OpenAIの評価ガイドも、業務に合った事例と人の判断を使い、変更後も継続して試すよう勧めています。評価設計ガイド

そら商店の練習用データを考えます。通常の返品20件と、注文番号の記載がない、すでに返金済みといった例外10件、合計30件です。以下は計算を説明するための架空の値で、製品を実行して測った結果ではありません。

合計はAが (19 + 4) ÷ 30、Bが (18 + 9) ÷ 30 です。Bは全体の割合が上がった一方、通常の問い合わせでは正解が1件減りました。全体の点数と、悪くなった仕事の両方を見る必要があります。特に他人の情報の表示や二重返金は、平均点が高くても運用を止める条件として別に定められます。

最初の店で流れを作ったら、次の店ではどこまで作り直すのでしょうか。注文を読む接続、権限の確認、処理記録は共通で使えても、返品期限や例外ルールは店ごとに違うかもしれません。共通で使う部分と、現場で再確認する部分を分ければ、2店舗目の出発点が変わります。

OpenAIが紹介した実例には、半導体チームのテスト生成や不具合の原因分析があります。チップの設計が意図どおりに動くかを試すコードなどを作る仕事です。同社は、個別の実装をCodex中心の共通基盤へ移したと説明しています。現場の事例

その成果を別の会社の削減率の予測に使うのは難しいでしょう。そら商店のような小さなチームなら、まず既存の道具で一つの業務を解決できるかを見るのが現実的です。