AI時代の5つの開発者アーキタイプとは？
最近、このような話を聞きました。
エンジニアの分類は、これまでのバックエンド、フロントエンドといった区分ではなく、プロトタイパーを含む5つのアーキタイプで捉えられるようになるのではないか。
どういうことかと調べてみると、Claude Codeの開発を率いるBoris Cherny氏発で、エンジニアの5つのアーキタイプが提示されているとのことでした。
| アーキタイプ | 役割 |
|---|---|
| 1. プロトタイパー | 新しいアイデアを大量に試す。大半はリリースされない |
| 2. ビルダー | アイデアやプロトタイプを本番品質へ持っていく |
| 3. スイーパー | UI、コード、システムを整理し、削除・単純化・高速化する |
| 4. グロワー | 作られた製品を反復改善し、PMF（Product-Market Fit：プロダクトと市場の適合）を高める |
| 5. メンテナー | 成熟したシステムの安全性、信頼性、性能、効率を維持する |
本記事では、この分類の概要と、それに対する批判的な議論をまとめました。
考え方の背景
Anthropicが約40万件のClaude Codeセッションを分析した結果、以下のような分業が観測されています。
- 人間：約70%の「何をするか」に関する計画・方針判断
- Claude：約80%の「どう実装するか」に関する実装判断
また、同じ調査では、そのタスクに対する人間側の専門性が高いほど、セッションの成功率も高い傾向が確認されています（ここでいう専門性は、単なる職種や一般的なコーディング能力ではなく、そのタスクで何を実現すべきかを理解しているかという、タスク固有の専門性です）。
つまりAI時代においては、その領域の知識を持ち、「何をするか」「何をもって完了とするか」を定義し、AIの成果を検証できる能力の重要性が相対的に増しているようです。
「何ができる人か？」ではなく、問題を発見する、方向を決める、品質を判断する、プロダクトを育てる、責任を持つといった役割の違いが、相対的に重要になるのではないかということです。
元になった投稿
Cherny氏は、この5つのアーキタイプを「将来こうなるのではないか」という仮説として提示しています。
AnthropicのBoris Cherny氏がXに投稿していた内容がこちらです。
この記事の調査方法とAI利用について
この記事は、筆者の「5つのアーキタイプってなんだ？」という疑問をGPT-5.6に調査させたところ、想像していた以上に分かりやすい資料ができたため、その内容を記事向けに整理したものです。
AIを使えば誰でもこのような資料を作れるのかもしれませんが、こうした考え方に触れるきっかけとして記事に残す価値はあると思い、掲載しました。
各アーキタイプの評価と批判
各アーキタイプについて、概要と、それに対する批判的な意見を収集しました。
特に批判的な意見には、5分類を考えるうえで本質を突いているものも多く、参考になります。
① プロトタイパー
概要
たくさんのプロトタイプを素早く作成する、最もAIの恩恵を受けやすい役割の一つです。
Claude CodeのようなAIエージェントによって、試行1回にかかるコストが大きく下がりました。それによって、
アイデア → プロトタイプ → フィードバック → 廃棄
というサイクルを大量に回せます。
Anthropic社内でも、Claudeを複数並列に動かし、異なるアプローチを同時に探索する使い方が報告されています。
批判
逆説的に、プロトタイパーそのものの希少価値は下がる可能性があります。
2026年7月のこの分類へのある批評では、Claude Codeのようなツールによってプロトタイピングの参入障壁が下がるため、5分類の中でも特に競争の激しい役割になるのではないかと指摘されています。
つまり希少になるのは、単に「作れること」ではなく、
何を試すべきか
何を捨てるべきか
どの結果を信じるべきか
という、価値を見極めるセンスと判断力です。
試作のコストが下がることで、逆に「次々とプロトタイプを作るが、何一つ成熟しない」という状態にも陥りやすくなります。
したがって重要となるスキルの中心は、ただアイデアをたくさん実装することではなく、顧客の要求を感じ取る嗅覚と、複数の試作から価値ある仮説を選別できる選定眼と言えるかもしれません。
② ビルダー
概要
AIエージェントが得意なのは、ビルダーの「手を動かす部分」です。
Anthropicの約40万セッションの分析では、人間が計画・方針判断を握り、AIが実装判断を担うという構造がかなり明瞭に表れています。
また、人間側の対象領域に対する専門性が高いほど、Claudeへの指示が的確になり、正確に多くの仕事を実行できる傾向があります。
したがって、優秀なビルダーは、
自分で大量のコードを書く
人から、
仕様・受け入れ条件 → アーキテクチャ・制約 → テスト・検証基準 → AIエージェントへ実装を委譲 → レビュー
という開発ループを設計・監督する人へ変化していく可能性があります。
もちろん、アーキテクチャやテストの作成自体をAIに支援させることもできます。重要なのは、人間がすべてを手作業することではなく、何を作り、どの条件を満たせば正しいとするのかについて最終的な判断を持つことです。
批判
最大の問題は、
「動くソフトウェア」と「production-grade なソフトウェア」の距離は依然として大きい
ことです。
Anthropic自身の社員調査でも、Claudeが書いたコードを理解するための認知負荷や、後からデバッグ・整理する時間が増える場合があるという回答があります。
また、複雑で高リスクな仕事については、多くの社員が依然としてAIの成果を積極的に検証しています。
ExperiencedDevsなどでも、AI生成コードの増加によってレビュー側の負荷が高まったという個別報告が複数見られます。
これらはあくまでSNS上の個別事例ですが、AIによって実装速度が上がった結果、設計・レビュー・ガバナンス側が新しいボトルネックになるという方向性は、Anthropic社内の調査とも整合します。
つまり今後のビルダーに求められる能力は、
「速くコードを書く能力」ではなく、「AIを使って壊れにくいシステムを作る能力」
へ移っていく可能性があります。
③ スイーパー
この5分類の中でもAI時代に重要性が上がりそうな役割です。
AIは「追加する」作業を非常に低コストで行えるようにする一方、
- この機能はいらない
- この抽象化はいらない
- この画面をなくす
という「引き算」は、目的・UX・将来構想まで理解した判断を必要とします。
Anthropic社内でも、Claude Codeタスクの8.6%が、リファクタリングなどの「日々の小さな摩擦を減らす改善（papercut fixes）」に使われています。
批判
スイーパーを独立した「後工程」と捉えること自体への批判があります。
UIの洗練やシステムの単純化は、ビルダーが作ったものを後から掃除する作業ではなく、本来は設計・実装の段階から組み込まれるべきではないか、という指摘です。
また別の批評では、スイーパーは特定の製品フェーズに属するのではなく、プロトタイプから成熟したプロダクトまで、常に必要になる役割だとされています。
そう考えるとスイーパーは「掃除をする人」というより、何を残し、何を削り、どこまで単純化するかを判断する機能と捉えた方がよさそうです。このタスクは、そのまま商品戦略に直結するため、高度な商品・需要・マーケティング理解が必要となるでしょう。
④ グロワー
グロワーは、一度作られた製品を拡大させる役割です。
AIによって実装コストが大幅に下がるほど、**「何を改善するか」**がボトルネックになるため、相対的な重要性は高まります。
ある実務家は、5分類を自身の個人開発に当てはめた結果、プロトタイパー、ビルダー、スイーパー、メンテナーはかなりAI化できる一方、グロワーだけは実際のユーザーという「外部世界」を必要とするため、自動化しにくいと指摘しています。
批判
逆に、この分類で最も境界が曖昧なのもグロワーです。
文脈によってブレはありますが、グロワーのタスクを既存職種へ当てはめると、
- 顧客調査
- 市場選択
- ポジショニング
- プロダクト戦略
- 販売・獲得チャネル
- 価格設計
- 営業
まで関係しており、「グロワー」という一語の中に複数の能力を詰め込みすぎているとも考えられます。
また、局所的なKPI改善だけを繰り返すと、本当に必要なプロダクト戦略の変更を逃す危険もあります。
⑤ メンテナー
AI時代でも消えないどころか、プロダクト数と生成されるコードの量が増えるほど、仕事量そのものが増える可能性がある役割です。
セキュリティ、信頼性、可観測性、インシデント対応、コスト最適化、移行作業などが中心になります。
定型的な監視・テスト・セキュリティチェックについてはAIエージェントへ任せやすい一方、事故が起きたときの最終責任は依然として人間側に残ります。
Anthropic自身も、AIエージェントに強い権限を持たせるほど潜在的な被害範囲が拡大すると説明しており、AIエージェントの能力向上と同時に、封じ込めや監督を強化しています。
批判
最大の問題は評価されにくさです。
「新機能を10個作った」は可視化できますが、
「障害を起こさなかった」
「不要な複雑性を入れなかった」
「インシデントを防いだ」
という成果は見えにくいものです。
最近のこの分類への批評でも、メンテナーは「最も華がなく、評価されにくいが不可欠」であり、役割を固定すると「メンテナーはキャリアの行き止まり」と見なされるような序列化が起きる危険も指摘されています。
アーキタイプ5分類そのものへの主な批判
批判1：人自体を5種類に分類する危険性
元Meta／MicrosoftのKun Chen氏はCherny氏のX投稿に対し、アーキタイプを選択すると、その後、自分自身を問い直さなくなる危険があると批判しました。
Cherny氏自身もこれに同意し、「役割は時間やプロジェクトによって変わる」と回答しています。
これはとても重要です。
分類を、
Aさんはビルダー
Bさんはメンテナー
のような、人につける固定ラベルとして使うのは危険です。
むしろ、
今このプロジェクトにはビルダーが多すぎて、スイーパーとグロワーが足りない
のように、「今のチームにどの働きが不足しているか」を診断するためのフレームワークとして使う方が有用でしょう。
批判2：シリコンバレー型のプロダクト組織に偏っている
LinkedInでは、Vivek Bharadwaj氏が、この5分類はシリコンバレー型のプロダクト企業に寄りすぎていると批判しています。
彼の主張で興味深いのは、単に「5分類に足りない役割がある」と指摘しているだけではない点です。
多くの組織では、プロトタイパー、ビルダー、スイーパー、メンテナーは、それぞれ別の人が担当する仕事ではなく、1人のビルダーが得意・不得意を持ちながら製品のライフサイクル全体を担うことも多いのではないか、としています。
そこでBharadwaj氏は、この4つを広い意味での「ビルダー」にまとめ、グロワーは独立した役割として残したうえで、さらに次の2つを加える案を示しています。
- Handler：複雑な組織を実際に動かす人。Chief of Staff、営業・事業オペレーション、CX戦略などに現れる役割
- Grown Ups：加速する組織に必要なブレーキ役。法務、財務、リスク管理などを担う人
この批判から見えてくるのは、Cherny氏の5分類がプロダクトを作り、改善し、維持する仕事をかなりうまく説明している一方で、会社を実際に動かすための組織運営や、法務・財務・リスク管理といった統制の仕事までは十分に扱っていない、という点です。
確かに元の5分類には、組織運営、法務、財務、リスク管理、採用、顧客との契約、チームマネジメントなどがほぼ登場しません。
そのため、この分類を会社全体の職種モデルとして見るのではなく、あくまでプロダクト開発における5つのアーキタイプとして捉える方が自然でしょう。
まとめ
5つの「職種」ではなく、5つの「タスク憲章」と考えると非常に有用
現在までの情報を総合すると、次の理解が最も適切です。
| プロダクトの状態 | 重視されるアーキタイプ |
|---|---|
| PMF前 | プロトタイパー + ビルダー + スイーパー |
| PMFを見つけて成長中 | ビルダー + スイーパー + グロワー + 一部メンテナー |
| 強いPMFを確立 | スイーパー + グロワー + メンテナー + 一部ビルダー |
その結果、人間側で特に重要になる問いを、アーキタイプごとに整理すると次のようになります。
| アーキタイプ | 人間側に残る問い |
|---|---|
| プロトタイパー | 何を試すべきか？ |
| ビルダー | 何を、どの品質で本番に届けるべきか？ |
| スイーパー | 何を残し、何を削り、どう単純化すべきか？ |
| グロワー | ユーザーにとって何を改善すれば、PMFをさらに高められるか？ |
| メンテナー | 何を守り、どのリスクを許容し、異常をどう検知・復旧するか？ |
最終評価
| 観点 | 評価 |
|---|---|
| 「エンジニアという職種が消える」 | まだ言い過ぎ |
| 職種境界が薄くなる | かなり強い兆候あり |
| 1人が複数領域を担当する | Anthropic社内でも確認されている |
| 実装より判断力が重要になる | かなり有力 |
| 5分類をそのまま職種にする | 推奨しにくい |
| チーム／プロダクト分析のフレームとして使う | かなり有用 |
結局、この議論で最も価値があるのは、「今後エンジニアがプロトタイパーやビルダーという肩書きになる」という部分ではありません。
AIによって実装そのもののコストが下がるにつれ、人間側では問題設定・判断・検証・責任といった能力の価値が相対的に高まっている
という傾向です。
そして、ここから一段進めるなら、
「あなたはどのアーキタイプか？」ではなく、
「今のプロジェクトでどのアーキタイプが不足しているか？」
を問う使い方が合理的だと思います。
固定的な職種として使えば、役割の固定化や不要な序列化を招く可能性があります。
一方、チームの能力ポートフォリオを診断する5つの軸として使えば、AIネイティブな開発組織を考えるうえで、かなり実用性の高いフレームワークになりそうです。
最後に
5つのアーキタイプについて他の記事をいくつか見てみたのですが、この分類の前提をあまり疑わずに紹介している記事もあり、少し危うさも感じました。
今回はGPT-5.6に「批判的な意見も取り入れて」と指示して情報収集してもらいましたが、この一言を加えるだけで調査の見え方がかなり変わるのは面白いところです。
自分に「プロトタイパー」「ビルダー」と名前がつくと、その分類に納得してしまいたくなることもあります。
しかし、そのラベルが逆に「これは自分の仕事ではない」と考える理由になれば本末転倒です。Kun Chen氏の批判は、まさにこの点を指摘しているように思います。
一方、今回の調査から得た「1つのフレームワークとして使う」という結論はかなり腑に落ちました。
チームづくりの際に、この5つをホワイトボードの端に書き留めておけば、どの方向に進めばよいのか見えにくいAI時代でも、組織づくりの視界が少しクリアになりそうです。
このようなアーキタイプ自体も、AIの発展に伴って洗練されたり、前提そのものが覆ったりするはずです。
AI時代の組織や開発者の役割について、今後も定期的に見直しながら追っていきたいと思います。