ターンキーの AI プロジェクト:固定価格が成り立つのはどんなときか、そしてパイロットを本番に持っていく会社をどう雇うか

停滞した AI パイロットは、最後に動くシステムを引き渡してもらうターンキーの仕事として仕上げられる。まず、自社の文書でパイロットを測り、到達すべきスコアを定める短いアセスメントを、固定価格で発注する。スコアをその目標まで引き上げる作業には、誰も事前に値段を付けられない。だから、タイム・アンド・マテリアル（T&M）、つまり総額に上限を設けた時間単価で買う。紙の上で記述できる残りの作業は、フェーズごとに価格を固定する。

AI システムにとって「ターンキー」とは何を意味するのか

AI システムの場合、ターンキーとは、会社がすぐに使える状態のシステムを引き渡すことであり、何をもって「すぐに使える」とするかは契約に書く。たとえば、システムは自社の境界の内側、つまり自社が管理するサーバーやクラウドアカウントの上で動く。自社の文書で目標スコアに達し、確信の持てないケースは人に回す。会社が去ったあとも、自社の社員が運用できる。

建設の分野では、ターンキーの請負者が施設全体を設計・建設し、すぐに使える状態で引き渡す。国際コンサルティング・エンジニア連盟（FIDIC）は、こうしたプロジェクトのための標準契約約款を発行しており、それはシルバーブック（Silver Book）の名で知られている。

FIDIC は2017年版のページで、シルバーブックが合わないケースを三つ挙げている:

• 入札者に、発注者の要求事項を確かめ、自ら設計とリスクの検討を行い、費用を見積もるだけの時間や情報がない
• 工事の多くが地下など、入札者が調べられない場所で行われる。ただし、誰も予見できなかった状況を契約がカバーしている場合は除く
• 発注者が、請負者の作業を細かく監督または管理するつもりでいる。あるいは、図面の大半をレビューするつもりでいる

こうしたケースについて、FIDIC は別の標準契約約款であるイエローブック（Yellow Book）を勧めている。停滞した AI パイロットは、会社が自社の文書を実際に流してみるまで、最初の二つのケースに当てはまる。まだ誰も地盤を調べていないからだ。以下で説明するフェーズ分けの契約は、三つ目のケースに当てはまる。自社が仕事を細かく管理し続ける形になるからである。だから「ターンキー」は動くシステムの引き渡しと読み、仕事の価格はフェーズごとに付ける。

AI の仕事で固定価格が難しいのはなぜか

ソフトウェアプロジェクトの多くの部分は、作り始める前に記述できる。レポートやほかのシステムとの接続なら紙の上に書き表せるし、書かれたものになら会社は値段を付けられる。

言語モデルで文書を読むシステムには、事前に誰も記述できない部分が一つある:自社の文書で、各フィールドをどれだけの頻度で正しく読めるかである。フィールドとは、日付や金額のような一つ一つのデータのことだ。その答えは、自社のスキャン画像とテンプレート、そして実際に現れるまで誰も思い出さないケースによって決まる。目標スコアにどれだけの作業が要るのかは、誰かが自社の文書でシステムを測るまで、誰にも分からない。

米国政府の調達ルールも、同じ区別をしている。連邦調達規則（FAR）の第16部は、契約の種類を扱う。そこではタイム・アンド・マテリアル契約を、作業した時間に対して固定の時間単価で支払い、これに資材の実費を加える契約として説明している。そして、契約の時点で作業を正確に見積もることも、その費用を「合理的な程度の確信をもって」予測することもできない場合に限って、こうした契約を認めている。

FAR のもとでは、固定価格の契約が合うのは、仕様が明確で、最初に適正な価格を設定できる仕事である。第16部はさらに、経験によってより確かな価格設定の根拠が得られたら、タイム・アンド・マテリアルを長く使い続けないよう、契約担当官に求めている。

だから、誰も自社の文書を流してみないうちに提示される仕事全体の固定価格には、未知の部分に備えた大きな上乗せが含まれがちだ。そうでなければ、除外事項、つまりその価格がカバーしないものの一覧が付いてくる。その一つ一つが、リスクを自社に押し戻す。提案書の中で、その両方を探す。

固定価格が合うのはどの段階で、タイム・アンド・マテリアルが合うのはどの段階か

これは法的助言ではない。契約書を書くのは弁護士であり、この記事は、契約がカバーすべきことを挙げる。仕事を分け、それぞれの部分には、それが始まる時点で分かっていることに応じて価格を付ける:

• 最初に、固定価格でアセスメントを行う。会社はパイロットのコードを読み、自社の境界の内側で、実際の文書のサンプルを使ってパイロットを動かし、なぜ停滞したのかを書面にまとめる。受け取るものは二つある。受け入れセットの草案、つまり自社の実際の文書にそれぞれ正しい答えを付けたものの集まりと、次のフェーズの価格付きの計画だ。続けるかどうかにかかわらず、どちらも自社のものになる
• 不確実なのは、スコアを引き上げる中間のフェーズだ。ここには上限付きのタイム・アンド・マテリアルが合う。上限とは、会社が請求できる総額に設けた天井である。会社は、さまざまなプロンプト（モデルが従う書面の指示）やモデルを受け入れセットに照らして試し、毎週スコアを見せる。改善が頭打ちになったら、そこでやめられる
• 目標スコアに達したら、残りは普通のエンジニアリングで、固定価格のフェーズとして価格を付ける。その中身は、自社の境界の内側へのシステムの導入、品質が落ちたときのアラート、確信の持てないケースを社員が確認するレビューキュー、そして自社のチームの新しいシステムへの移行だ。固定価格の各フェーズは、受け入れテストで締めくくる。受け入れセットでシステムを採点し、そのフェーズに支払うかどうかを決めるテストである
• ローンチ後のシステムの運用には、何が含まれるかを書面で列挙した月額料金が合う。誰かが品質を見守り、モデルのアップグレードに対応しなければならないからだ

FAR はさらに、タイム・アンド・マテリアル契約に「請負者が自らの危険負担において超える上限価格」を含めるよう求めている。自社の契約にも上限を入れる。上限を設ければ支払額はそこで頭打ちになるが、FAR 自身の支払条項のもとでは、上限に達した時点で、発注者が引き上げない限り、会社は作業を続ける義務を負わない。そのときどうするかを、前もって取り決めておく。止めるのか、上限を引き上げるのか、仕事を計画し直すのか。

会社が、この一連の流れ全体を一つの契約として提示し、それをターンキーと呼ぶこともある。それでもうまくいくのは、すべてのフェーズにそれぞれの価格と受け入れテストがあり、フェーズとフェーズのあいだで止められる場合だ。

契約では「完了」を何と定めるべきか

完了とは、システムが受け入れテストに合格することであり、採点は、価格を固定する前に合意した合格ラインに照らして行う。契約には次のことを明記する:

• 受け入れセットにどの文書が入っていて、種類ごとに何件あり、正しい答えを誰が書いたのか。フェーズの価格が決まったら、セットは固定して変えない
• フィールドごと、文書の種類ごとの合格ライン（これらが合わさって目標スコアになる）と、スコアにかかわらず必ず人に回すフィールド
• 受け入れテストをどこで、誰が行うのか。場所は自社の境界の内側で、対象は会社が引き渡すのとまったく同じバージョンである。自社の社員が実施するか、会社が実施するのに立ち会う
• システムが受け入れテストに不合格だった場合にどうなるのか。会社には、自らの費用で修正するための決められた期間が与えられる。それを過ぎたら、自社は仕事を止め、それまでに作られたものを手元に残すことができる

受け入れセットの一部は、受け入れテストまで会社に見せずにおく。テスト用の文書をすべて見ていれば、会社はシステムをまさにその文書に合わせ込めるので、スコアは、新しい文書をどれだけうまく読めるかを実際よりよく見せてしまう。セットの作り方は、上でリンクした、本番にたどり着かなかった AI パイロットについての記事が説明している。

あとになって固定価格の AI 契約を崩しかねないものは何か

次のような出来事で価格がどう変わるのかを、前もって取り決めておく:

• 受け入れセットに入っていない、新しい文書の種類やテンプレート。これらは変更として扱い、フェーズと同じやり方で価格を付ける
• システムが使っているモデルの、プロバイダーによる提供終了。たとえば OpenAI の非推奨化（deprecations）のページは、一般提供されているモデルについては少なくとも6か月前、その特化型バージョンについては少なくとも3か月前の通知を定めている。プレビューモデルはそれよりはるかに短い通知で提供終了になることがあり、安全性やコンプライアンス上の懸念があれば、どの期間も短縮されうる。後継モデルを受け入れセットで試し、それに切り替える費用を誰が払うのかを決めておく
• 自社の側の遅れ。たとえば、自社のシステムへのアクセスを会社に認める承認が遅れることや、会社が必要とする文書と正しい答えを渡すのが遅れることだ。固定価格は自社の担当分が期限どおりに届くことを前提にしているので、自社の側が何を、いつまでに渡すべきかを列挙しておく
• 自社のルールの変更。たとえば、ある区分の文書はもう外部のモデルに送ってはならないと、リスク管理チームが決めた場合だ。そうなれば、その文書は自社の境界の内側で処理しなければならず、仕事の中身も価格も変わる

契約に別段の定めがない限り、運用コストは構築の価格に含まれない。モデルの利用料や、モデルを動かすサーバーの費用は、文書の数とともに増える。構築中とローンチ後にそれを誰が払うのか、そして価格が月に何件の文書を前提にしているのかを取り決めておく。

支払いを成果にどう結びつけるか

固定価格の支払いはどれも、システムが自社の境界の内側で受け入れテストに合格することに結びつけ、日付が来ただけで支払期限になる支払いは一つも設けない。タイム・アンド・マテリアルのフェーズでは、上限までの時間に対して支払い、続けるかどうかは毎週のスコアを見て判断する。

最終支払いの一部は、システムが合意した期間、目標スコアを下回ることなく本番で動くまで留保する。その割合と期間は、署名の前に取り決めておく。

どのフェーズのあとでも止められ、コード、プロンプト、受け入れセット、それで採点するスクリプトを含め、それまでに作られたものすべてを引き取れる権利を確保しておく。契約の中でコードの所有権がどう扱われるかは、下でリンクしている記事が扱っている。

パイロットの仕上げを申し出る会社を、どう見極めればよいか

パイロットが何をするのか、どの文書を1日に何件読むのか、データをどこに出してよいのか、そして必要なスコアを書いた1ページの要件書を作る。それを、同じ質問を添えて、候補リストのすべての会社に送る:

• 価格を固定する前に、何を見る必要があるのか。そして、どのフェーズなら価格を固定するのか
• 似た仕事の過去の契約がどう組み立てられていたかを、価格とクライアントの名前を取り除いたうえで見せてほしい
• フェーズの終わりに受け入れテストで不合格になったら、どうなるのか
• そちらのチームで AI システムを本番に導入したことがあるのは誰か。その人は当社のプロジェクトに携わるのか
• そちらのエンジニアは、当社のアクセスルールのもとで、当社の境界の内側で作業できるのか

最後の質問は、上でリンクした、データを外に出さずに AI 開発を外部に委託することについての記事が詳しく扱っている。

提案書のどんな点に警戒すべきか

• 会社が自社の文書を一つも見ないうちに、仕事全体の価格が出てくる
• 提案書が正答率を約束しているのに、それをどの文書で測るのかが書かれていない
• 「ターンキー」という言葉が使われているのに、受け入れテストも、フェーズのあいだで止める権利もない
• 運用コストが抜けているか、「別途協議」としか書かれていない
• 契約書の草案が、プロンプトや受け入れセットをその会社の財産として挙げている

amBrain はどこに位置づけられるか

amBrain が公に説明している言語モデルのプロジェクトは、次の一件だ:「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではない。上のプロジェクトが、別のチームのもとで停滞したパイロットから始まったとは述べていない。ターンキーや固定価格を含め、上で挙げた支払いの方式は一般的な助言であり、amBrain がそのいずれかを提供しているかどうかについて、この記事は何も述べていない。amBrain の価格や期間も示さない。

amBrain は、別のチームのもとで停滞したプロジェクトを引き継ぎ、本番稼働まで持っていく。

amBrain は2019年からソフトウェアを作っている。所有権についての amBrain の一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」ほかのどの会社にもそうするように、署名の前に、amBrain にもそのコンポーネントを名前で列挙した一覧を求めること。

パイロットが停滞しているなら、ほかのすべての会社に送るのと同じ要件書と質問を amBrain にも送り、答えを並べて比べる。

よくある質問

• パイロットにはすでに精度の数字がある。なぜアセスメントにお金を払うのか。パイロットが架空のデータや、誰かが手作業で整えた文書でテストされていたなら、その数字は自社の実際の文書についてほとんど何も語らない。アセスメントは、自社の境界の内側で、実際の文書のサンプルを使ってパイロットを測る。そこで作られる受け入れセットの草案は、いずれにしても自社のものになる
• 代わりに自社の ML チームを雇うべきか。AI が自社の売るプロダクトそのものなら、おそらく雇うべきだ。その選択については、上でリンクした ML チームの採用についての記事が扱っている。システムが業務の中の道具であるなら、自社がそれを運用する人を雇うあいだに、会社にパイロットを仕上げてもらえる
• 候補リストのすべての会社に、自社の文書を見せなければならないのか。その必要はない。要件書は、文書そのものを含めずに自社の文書を説明する。実際の文書を見るのは、アセスメントのために選んだ会社だけで、その会社は自社の境界の内側で作業する