あるAIコンサルティング企業は、技術的なディスカバリーの過程で、自社のソフトウェアが戦争における自律的な殺傷判断に使われることが明らかになり、高額な契約を辞退しました。この辞退によって、すべてのAI企業がどこに線を引くべきかが決まったわけではありません。示しているのは、掲げていた原則が、特定の仕事を受けるかどうかを経営陣とエンジニアが判断しなければならない場面で、実際の重みを持ち得るということです。

案件の範囲が明らかになったとき

見込み客は自動化されたハードウェアシステムを開発しており、遠隔操作機器や自律型機器向けのソフトウェア設計への協力を求めていました。コンサルティング企業が技術要件を精査するにつれ、想定される用途がはっきりしてきました。そのソフトウェアは、戦争において人間の標的に関する判断を下すというものでした。報酬はこの案件の大きな要素であり続けましたが、チームは想定される用途のほうが重要だと判断しました。

経営陣とエンジニアリングチームは、いずれもこの案件を断ることで一致しました。判断が下されたのは技術的なディスカバリーの終盤、つまりサービス企業が仕事を引き受ける前に顧客のニーズを見極める段階でした。このタイミングには意味があります。案件の倫理的な重さは、技術的な目的が理解されて初めて明らかになることがあるからです。

抽象的な重なり合う図形の流れのそばで、匿名の手が無地の企画書類を確認する様子

▲ 提案された案件の技術的な検討

このコンサルティング企業の創業者兼CEOは、他者に害を与えないことを自身の中心的な原則として語っています。今回、その原則は責任あるテクノロジーについての一般論にとどまりませんでした。チームはそれを、「このプロジェクトを進めた場合、自社のソフトウェアは何を判断することになるのか」という具体的な問いに当てはめたのです。

コンサルティングのプロセスが判断をどう形づくったか

同社は、創業者がAmazon Web Services（AWS）で5年間働いた後、2022年6月に設立されました。クラウド移行、データ分析、そして人工知能と機械学習を手がけています。機械学習とは、データからパターンを見つけるよう学習させたソフトウェアを指します。同社は個々の契約人材を提供するのではなく、自社のエンジニアでチームを組み、あらかじめ定めた成果を軸とするプロジェクトに配置しています。

顧客のディスカバリーには、People, Process, Technology（PPT）を用います。関わる人、仕事の進め方、プロジェクトに必要なツールを検討するためのフレームワークです。このアプローチは、エンジニアが実装に取りかかる前に、顧客の根本的なビジネス上のニーズを見極めることを目的としています。同時に、技術的に実現できるかどうかを超えた問い、つまり「完成したシステムは実際に何をするのか」を考える余地も生み出します。

今回の辞退は、その問いが「自動化」のような大まかな案件名だけでは必ずしも答えられない理由を示しています。チームは、提案されたソフトウェアが顧客のより大きなシステムの中でどのような役割を担うのかを考える必要がありました。契約がもたらす収益の可能性にもかかわらず、経営陣とエンジニアは同じ結論に達しました。

創業者は、企業とは掲げたアイデンティティだけでなく、そこで働く人々の日々の選択を映すものだと考えています。これは倫理的な主張であり、あらゆる契約を評価するための測定可能なルールではありません。ここでは、線を引いていると口にすることと、その線を守るための金銭的なコストを受け入れることとの隔たりを表しています。

制限したのは一つの用途であり、すべての用途ではない

創業者は、テクノロジーそのものを拒むのではなく、AIの導入を積極的に方向づけることを重視しています。同社は、緊急ロードサービスを提供する企業向けにAIシステムを導入した実績もあります。このシステムは入電を振り分け、緊急時に支援をより早く手配できるようにするもので、対応要員がドライバーのもとへより早く到着する助けになる可能性があります。

柔らかな日差しが入る静かな会議室で、空いた椅子のそばに置かれた無地の閉じたフォルダー

▲ 辞退という全員の判断

この二つのプロジェクトは目的が異なります。一方はAIを使って支援の要請を振り分けるものであり、提案された兵器プロジェクトは殺傷に関わる判断にソフトウェアを使うはずのものでした。この対比は同社の選択を説明するものの、業界共通の基準を確立するものではありません。ほかの用途では間接的な影響をめぐってより難しい問いが生じるかもしれず、善意だけではシステムの使われ方がどこへ向かうのかを見通せない場合もあります。

原則を契約審査に落とし込む

この事例からは、AI関連の仕事を選ぶ組織のための審査手順が見えてきます。ただし、すべての企業がすでに従っている文書化された方針と取り違えるべきではありません。

  1. 目指す成果を定める。 案件をエンジニアリングの作業として扱う前に、完成したシステムで顧客が何を実現したいのかを確認する。
  2. システムが担う判断の役割を検証する。 より大きなプロセスの中で使われる場合も含め、ソフトウェアが何を判断し、誰が影響を受け得るのかを問う。
  3. 技術面とビジネス面の判断を合わせる。 エンジニアは何を作るよう求められているのかを明確にでき、経営陣はそれを作る責任を会社として負うべきかを判断しなければならない。
  4. 金銭的な圧力の下でも線引きを意味あるものにする。 契約が大きな収益をもたらす場合でも、想定される用途をそれ自体として評価する。

このアプローチでは、依頼内容を理解できるだけの時間をかけることが求められます。予測が難しいAIの波及的な影響のすべてについて、確信を持っていると主張する必要はありません。

この辞退が読者に残すもの

このコンサルティング企業は、提案されたソフトウェアが殺傷を伴う標的判断に関わると見極めた後、金銭的なトレードオフを受け入れました。より広い教訓は意思決定に関するものであり、AIプロジェクト全般への普遍的な評価ではありません。倫理的な線引きが実効性を持つのは、チームが想定される用途を調べ、その線を越える仕事を断る覚悟があるときです。AI関連の契約を検討する組織は、まずシステムが何を判断するのかを問い、その仕組みを理解している人々を巻き込み、それらの問いに明確な答えが出てから受注するかどうかを決めることから始められます。