#06｜あなたはどのタイプの「Builder」でしょうか？
【この記事で学べること】
専門性や職種によって異なる、多様なBuilderのタイプと共通点
【1分でわかる、この記事のポイント】
・OpenAIのBuilderはAIの活用と定着を支え、Amazonの一部組織では職種を越えて問題を最後まで所有し、Google CloudのBuilderは顧客の現場でAIを本番稼働させている。
・同じBuilderという名称でも、仕事内容や必要な専門性は大きく異なり、世界共通の新しい職業として、まだ定義が固まっているわけではない。
・各社が求めるBuilderの姿は、その企業が解決したい課題によって変わり、Builderは一つの職種というより、複数の専門性にまたがる役割として現れ始めているが、それでも共通するのは、AIが出した答えを使うだけでなく、人や組織を巻き込み、実際に使われる状態まで形にしようとする動きであるというお話。
Builder ｜ Issue #06
第１章 ｜ Builderとは何者か
#003では、OpenAI、Amazon、Googleなど、世界のテック企業が「Builder」という言葉を使い始めていることを紹介しました。
ただ、各社の求人を詳しく読んでみると、少し不思議なことに気付きます。同じBuilderという言葉を使っているのに、求められている仕事内容がかなり違うのです。
OpenAIのBuilderは、企業へのAI導入と定着を支援します。Amazonの一部組織では、プロダクトマネージャーやエンジニアなど、異なる職種をBuilderという一つの呼び方にまとめています。Google Cloudの求人に登場するBuilderは、顧客の現場でコードを書き、AIを本番稼働させる技術者です。
これだけ違う仕事が、なぜ同じBuilderと呼ばれているのでしょうか。
今回は、無理に一つの定義へまとめるのではなく、まず三社が求めているBuilderの違いを、もう少し丁寧に見てみたいと思います。
OpenAIのBuilderは、AIを「導入した後」からが仕事になる
OpenAIが東京で募集している職種の名称は、「AI Deployment Manager（Builder）」です。
AI Deployment Managerと聞くと、企業へのAI導入を管理する仕事を想像するかもしれません。しかし、求人に書かれている役割は、製品を紹介して契約してもらうことや、導入作業を終えることだけではありません。
ChatGPT EnterpriseやAPIなどを導入した企業で、利用が一部の社員だけにとどまっていないか。業務の中で継続して使われているか。利用範囲が広がり、具体的な事業成果につながっているか。そうした状態まで責任を持つことが求められています。研修やワークショップの実施、社内で再利用できる活用方法の整理、利用状況の確認なども仕事に含まれます。
例えば、ある企業がChatGPT Enterpriseを導入したものの、実際に使っているのはAIに詳しい一部の社員だけだったとします。
この場合、製品としては導入されています。しかし、会社の仕事はほとんど変わっていません。
どの部門の、どの業務で使えば効果が出るのか。社員は何につまずいているのか。活用事例をどう社内へ広げるのか。さらに、利用が増えたことで、時間やコスト、顧客対応などがどう変わったのか。
OpenAIが東京でBuilderと呼んでいるのは、こうした問いに向き合いながら、AIが企業の中で継続して使われ、成果が確認できるところまで導く人だと読み取れます。
AIを開発する人というより、AIによって顧客の仕事が変わるところまで伴走する人。OpenAIにおけるBuilderには、そのような意味が込められているのではないでしょうか。
Amazonでは、Builderが一つの職種名を超え始めている
Amazonの事例は、OpenAIとはかなり異なります。
正確にはAmazon全社の話ではなく、Ring、Blink、Key、Sidewalkなどを扱う組織での取り組みです。この組織では、管理職ではない専門職・実務担当者、いわゆるindividual contributorの職種名称を、Builderという一つの名称にまとめる方針が求人情報に明記されています。
その理由として示されているのは、創業者のように考えること、問題を最初から最後まで自分ごととして捉えること、そしてAIを後から追加する道具ではなく、最初から仕事へ組み込むことです。
ここで興味深いのは、Builderが特定の仕事を示していない点です。
実際の求人には、プロダクトマネージャーとして働くBuilderもいれば、テクニカルプログラムマネージャーやソフトウェアエンジニアとして働くBuilderもいます。担当する専門領域は同じではありません。
プロダクトマネージャーであれば、顧客が抱える問題を捉え、どの製品を作るかを決め、データを見ながら試作と改善を進めます。テクニカルプログラムマネージャーであれば、複数の技術チームを横断し、曖昧な問題を整理しながら、実際の製品として世に出るまで進行を担うでしょう。
従来であれば、職種ごとに役割を細かく分ける方が、責任範囲は明確になります。一方で、新しいプロダクトを作る途中では、「これは誰の担当なのか」が決まらない問題が何度も出てきます。
Amazonのこの組織は、職種名よりも先に「自分の担当範囲だけで仕事を終わらせず、問題を最後まで所有する人であってほしい」という期待を置いたのではないでしょうか。
OpenAIが特定の導入職をBuilderと呼んでいるのに対し、Amazonの一部組織では、異なる専門職に共通して求める働き方を、Builderという名称で表そうとしている。ここには、かなり大きな違いがあります。
GoogleのBuilderは、顧客の現場で自ら作る
Google Cloudが募集するForward Deployed Engineerは、さらに技術寄りの役割です。
求人では、この人材を「embedded builder」と表現しています。最先端のAI製品と、顧客企業で本当に動くシステムとの間を埋める役割です。
一般的なアドバイザーのように、全体構想やシステム設計を提案して終わるのではありません。顧客の環境へ入り、コードを書き、デバッグを行い、その企業に合ったAIシステムを一緒に本番稼働させることまで求められています。
AIの試作品は、比較的短時間で作れるようになりました。しかし、社内のデータと接続し、情報漏えいを防ぎ、既存システムと連携し、現場の社員が日常的に使える状態へ持っていくのは簡単ではありません。
デモでは動いたものが、本番環境では動かないこともあります。技術的には正しくても、業務の手順に合わない場合もあるでしょう。現場から想定外の要望が出て、設計を大きく見直すことも珍しくありません。
そのような状況で、資料を渡して顧客側の作業を待つのではなく、顧客の中へ入り、自分でも手を動かしながら完成まで進める。Googleが使うBuilderには、助言する人ではなく、現場で一緒に作る人という意味が強く表れています。
OpenAIのBuilderがAIの活用と定着を支援する人だとすれば、GoogleのBuilderは、より技術の深い部分へ入り、AIを本番で動くシステムへ変える人と言えそうです。
三社は、同じ人材を探しているわけではない
三社の違いを整理すると、同じBuilderという言葉から、かなり異なる人物像が見えてきます。
OpenAIが東京で求めているのは、AIの利用を企業の中へ広げ、継続利用と事業成果につなげる人です。
Amazonの一部組織では、職種を問わず、創業者のように考え、担当の境界を越えて、問題を最後まで所有する人をBuilderと呼んでいます。
Google CloudのBuilderは、顧客の現場へ入り、自らコードを書きながら、AIを本番環境で動かす技術者です。
求められる専門知識も違います。
OpenAIでは、顧客の業務を理解し、AI活用を広げる力が重要になるでしょう。Amazonのプロダクト領域では、顧客課題、製品開発、組織横断の推進力が求められます。GoogleのForward Deployed Engineerには、顧客との対話力だけでなく、実際にシステムを作れる高度な技術力も欠かせません。
したがって、「Builderという新しい職業が世界で統一されつつある」と捉えるのは、現時点では正確ではありません。
むしろ、企業が解決したい課題によって、必要なBuilderの姿が変わっていると考えた方が自然です。
なぜ、それでも「Builder」なのでしょうか
ここまで三社の違いを見てきました。
仕事内容も違えば、必要な専門性も異なります。OpenAIのBuilderに適した人が、そのままGoogleのForward Deployed Engineerとして活躍できるとは限りません。AmazonのBuilderも、所属する職種によって日々の仕事は大きく変わります。
それでも、それぞれの企業が、あえてBuilderという言葉を使っています。
ここに、私は強い興味を持ちました。
各社が偶然、同じ響きのよい言葉を選んだだけなのでしょうか。それとも、AI時代に求められる人材には、仕事内容や専門性を越えた何かがあり、それをBuilderという言葉で表そうとしているのでしょうか。
当初の私は、その共通点を「仕事への向き合い方」ではないかと考えていました。
ただ、改めて調べていくと、それだけでは説明が浅いように感じます。主体的に仕事へ向き合うことや、担当範囲を越えて動くことは、AIが登場する以前から優秀な人材に求められてきたからです。
では、今の時代に、それまで以上に必要となったものは何なのでしょう。
AIによって短時間で多くの案を作れるようになったからこそ、その中から何を選ぶのか。
AIが出した答えを使うだけではなく、必要な情報をさらに引き出し、現場の反応を確かめながら、次の判断をどう更新するのか。
そして、専門家や関係者を巻き込みながら、実際に使われるところまで形にできるのか。
この問いは、「Builderとはどんな職業なのか」という話を超えて、AI時代に人は何を学ぶべきなのかという問題につながっていきます。
ここまでの事例を、自分の仕事に重ねるとどうでしょうか。新しい仕組みを人や組織が使えるようになるまで伴走する。部門をまたぐ課題を整理し、解決へ進める。自ら技術を使って、実際に動くものをつくる。これまでの経験や得意なことは、どの役割に生かせそうでしょうか。一つに絞る必要はありません。
次回は、AI研究や経営学、世界の企業事例も確認しながら、この問いをもう少し深く考えてみたいと思います。
同じではない三社のBuilderに、何が共通しているのか。
その答えを急いで決めるのではなく、客観的な根拠と私自身の経験を照らし合わせながら、一つずつ確かめていくつもりです。
※本記事の求人情報は、2026年7月時点の各社公式採用情報をもとにしています。Amazonの事例は、Amazon全社ではなく、Ring、Blink、Key、Sidewalkなどを扱う組織での取り組みです。
