11:30 - 13:14

AI、エージェント型プラットフォーム、広がるカスタマイズ問題

この章の問い

AIによって、コードや高度にカスタマイズできるソフトウェアを作りやすくなりました。では、すべてのAI企業がフォワード・デプロイド・エンジニアリング（Forward-Deployed Engineering、FDE）のチームを必要とするのでしょうか。

この章で話者が示すのは、単純な「AIならFDEが必要だ」という結論ではありません。話者の個人的な仮説では、ソフトウェアがより柔軟になり、顧客が自分で理解して実装する仕事が増えるほど、顧客の近くで実装を助けるエンジニアの価値が高まる可能性があります。

AIが変えるものは、開発速度だけではない

話者はまず、AIによってコードを書きやすくなったと説明します。その結果、以前より高度で、顧客ごとに変えられるソフトウェアも作りやすくなります。

ここで重要なのは、AIが単にエンジニアの作業を速くするだけではない、という見方です。ソフトウェアを作る側が、顧客ごとに多くの変更を加えられるようになります。すると、製品を買った顧客が、その機能を自社の仕事に合わせて理解し、設定し、実装する責任も重くなりやすいです。

これは、次のような因果関係です。

AIでコード生成が容易になります。
顧客ごとに大きく変えられるソフトウェアを作りやすくなります。
製品の使い方や実装方法が、顧客ごとに複雑になります。
顧客が自分だけで価値を実現することが難しくなります。
顧客の事情を理解しながら実装する、顧客向けエンジニアの役割が重要になる可能性があります。

この説明は、話者が明確に「個人的な仮説」として述べているものです。講演中の事実として証明された結論ではありません。また、「ほとんどすべてのプラットフォームがエージェント型になる」というような広い主張にも、この講演の中では根拠となるデータは示されていません。

エージェント型プラットフォームとは何か

この講演での「エージェント型（agentic）」は、外部の一般的な定義をそのまま指す言葉ではありません。ここでは、ソフトウェアが人間の一つの操作だけを待つのではなく、ある程度の仕事を進めたり、複数の処理を組み合わせたりできる方向を指しています。

話者の議論では、エージェント型のプラットフォームほど、顧客の仕事に合わせて変更できる余地が大きくなります。つまり、完成した一つの固定的なアプリケーションを使うだけではなく、顧客のデータ、業務、判断方法に合わせて、動作やワークフローを組み立てることになります。

ここで、設定可能なソフトウェアと開発可能なソフトウェアを区別する必要があります。

設定可能なソフトウェアは、用意された選択肢の範囲で項目やルールを変えます。
開発可能なプラットフォームは、部品やデータを使って、顧客に合わせたアプリケーションや処理の流れを作ります。

設定画面で通知の時間を変えることは、設定の一例です。一方、複数の社内システムから情報を集め、保険の審査手順に合わせて判断を進める仕組みを作るなら、より深い実装が必要になります。後者では、顧客が何を作るべきかを理解すること自体が難しい場合があります。

「顧客の実装に任せる」ことの限界

話者が問題にしているのは、製品の成功を顧客の実装だけに任せることです。顧客が技術に詳しく、十分な時間と人材を持っていれば、それでもうまくいくかもしれません。しかし、すべての顧客がその条件を持つわけではありません。

特に、企業向け市場へ上がる場合や、製品を別の業界・別の用途へ広げる場合には、顧客の背景が多様になります。製品の機能を知っていても、自社の業務にどう組み込むかを知っているとは限りません。製品の可能性が広がるほど、「何ができるか」だけでなく、「自社でどう使えば価値になるか」を説明し、実装する仕事が必要になります。

3種類の市場拡大

話者は、実装の問題が次のような市場拡大で現れると説明しています。

アップマーケット（upmarket）：より大きな企業や、より高い要求を持つ顧客へ進むことです。
水平展開（horizontal expansion）：同じような製品を、別の業界や多様な顧客へ広げることです。
垂直展開（vertical expansion）：特定の業界の深い業務に入り込むことです。

例えば、最初は技術部門だけが使う開発支援製品でも、大企業全体へ売るなら、導入する部署や業務は増えます。別の業界へ広げるなら、業界ごとの用語や手順も変わります。一つの業界で深く使うなら、その業界特有の判断や規則に合わせる必要があります。

これらは別々の方向の拡大です。ただし、どの場合でも、顧客が製品を自社の現実に合わせて実装する難しさが増える可能性があります。そこで、顧客と一緒に問題を理解し、プラットフォーム上に解決策を作るFDEのような役割が関係してきます。

AI時代にも、FDEの適用条件は残る

ここまでの話を聞くと、「AI製品なら、すぐにFDEチームを作るべきだ」と考えたくなります。しかし、これは講演の主張ではありません。

前の章までで示されたFDEの判断は、二つの条件から成ります。

技術的に複雑で、顧客ごとの実装が重要なものを、技術に詳しくない買い手へ売る必要があること。
エンジニアが顧客向けの解決策を作れる、共有プラットフォームと再利用可能な部品を持っていること、またはそれに投資する意思があること。

AIによってカスタマイズが簡単になっても、この二つの条件が自動的に満たされるわけではありません。たとえば、開発者が自分で使い、設定も実装も簡単に完了できるAIツールなら、開発者向けの関与（developer engagement）や通常のSaaSの販売モデルのほうが合うかもしれません。FDEは、流行しているから導入するものではありません。

例：AIエージェントの導入

ここからは、話者の主張を理解するための教師作成の例です。

ある会社が、保険会社向けに書類を調べるAIエージェントを提供するとします。製品は、書類の読み取り、社内データとの照合、担当者への質問、審査結果の記録までできます。しかし、保険会社ごとに書類の形式、承認者、例外処理、保存規則が違います。

この場合、AIがコードを作れることは助けになります。それでも、保険会社の業務を理解し、どのデータを使い、どの判断を人間に戻すかを決め、実際のワークフローとして組み立てる仕事は残ります。買い手がその実装を自社だけで進められないなら、顧客向けエンジニアが価値を提供できる可能性があります。

反対に、利用者が画面上で数個の項目を選ぶだけで導入でき、顧客ごとの深い開発が不要なら、FDEは必要ないかもしれません。この例は、AIの有無ではなく、製品の複雑さ、買い手と利用者の技術力、そして実装の深さが判断材料になることを示しています。

特定業界のエージェントと、一般的なプラットフォーム

話者は、保険や法律のような業界に特化したエージェントを考える場合にも、一般的なプラットフォームとの違いを意識するよう促しています。特定業界の業務をすぐに支援するエージェントを作ることと、さまざまな顧客が自分の用途に合わせて構築できる基盤を提供することは、同じではありません。

業界特化型の製品は、その業界の用語や手順を深く持つ代わりに、対象範囲が狭くなることがあります。一般的なプラットフォームは、より多くの用途に対応できますが、顧客が自分の業務に合わせて設計する仕事が増えるかもしれません。後者では、顧客の実装を支えるFDEの価値が高まりやすい、というのがこの章の仮説です。

歴史とのつながりと、この章の限界

話者は、Palantirが2004年または2005年ごろに市場へ入ったという趣旨にも触れています。ただし、これは正確な日付として断定されていません。ここでの歴史的な説明は、過去のFDEモデルをAI時代にそのままコピーするという意味ではありません。

話者が強調する変化は、カスタマイズ可能なソフトウェアが広がることです。製品の数が増えるだけではなく、顧客が実現できる形の幅も広がります。その幅を顧客自身が埋めるのか、製品会社が顧客向けエンジニアと一緒に埋めるのかが、事業上の問題になります。

ただし、この講演では、AI製品でFDEが成功する割合や、必要なチーム規模などのデータは示されていません。したがって、ここで学ぶべきなのは確定した業界法則ではなく、FDEを検討するときの見方です。つまり、AIがカスタマイズを増やすほど、顧客の理解と実装の差が大きくなっていないかを確認し、そのうえで共有プラットフォームを使って顧客の成果を届けられるかを考えます。

この章の終わりで、講演は質疑応答と拍手へ移ります。690秒から794秒付近の内容には、これ以上の具体的な回答はありません。

出典：講演「Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE」（この章の開始時点：11分30秒）