ビルダーとは、何を作るかを計画して仕様に書き、AI と対話して作り、動かし、全体を統合する役割である。 1-03 では、コーダーとソフトウェアエンジニアの仕事を AI がするようになると書いた。その先にあるのは、自分で計画し、AI と対話してシステムを作り、動かす、もっと広い役割だ。この連載では、これをビルダーと呼ぶ。本章では、この役割の定義と、ソフトウェアエンジニアとの違いを固定する。
ビルダーの仕事は、四つの手順を回すことだ
ビルダーの仕事は、四つの手順でできている。
- 計画する ── 顧客と現場と自分の文脈から、何を作るかの案を立てる。どう分けるか、何を使い何を使わないか、どこに置き、どこまでを自分で持つかまで含めて、AI に渡せる仕様に書く。案を作るのも、仕様に書くのも、ビルダーの仕事だ。
- AI と作る ── 意図と制約と文脈を AI に渡す。AI はコードを書き、設計を提案する。一度の指示では終わらない。やり取りを重ねる。
- 確かめる ── 返ってきたものが動くかを見る。設計と合っているかを見る。想定した文脈で壊れないかを見る。
- 統合し、動かす ── 部分を全体に組み込み、整合を保って動かす。動かすとは、業務に載せて成果を出すことだ。企業が作った物なら、収益を上げるか、費用を下げるかしなければ、作った意味がない。動かして出た結果が、次の計画の材料になる。そして「計画する」に戻り、仕様を直す。
この四つは一方通行ではない。ループである。一周にかかる時間は、規模によって数分から数時間だ。一日に何十周も回す。コードを書く時間は、この中で最小になる。書くのは AI だからだ。
一つ目の「計画する」で書くものが、1-02 で言う AI に渡す最初の仕様 だ。後の三つは、その仕様を回す手順であり、一周するたびに仕様に戻って直す。保守の単位が仕様に移る(1-02)とは、このことだ。だから、ループの質は一つ目で決まる。
文脈"] subgraph Builder["ビルダーの仕事(AI と作るループ)"] direction TB D["計画する
(何を・どう分けるか・
仕様に書く)"] Hand["AI と作る
(意図・制約・文脈を渡す)"] Eval["確かめる
(動くか・整合するか)"] Int["統合し動かす
(業務に載せて成果を出す)"] D --> Hand --> Eval --> Int --> D end AI(("AI
コード・設計")) Out["動いて成果を出す
ソフトウェア"] Ctx -->|計画の材料はここから来る| D Hand <-->|意図を渡し、コードと設計案を受け取る| AI Int -->|全体の整合を保ったまま外へ出す| Out Out -.->|収益・費用の結果が次の計画に戻る| Ctx classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class Builder good class AI bad
このループ全体を握るのがビルダーだ。方向と責任も、ビルダーが負う。AI はコードを書き、設計を提案する。だが、何を作るか、現実と何をすり合わせるか、どう動かすかは、ビルダーの側にある。動かした結果 ── 収益が上がったか、費用が下がったか ── を負うのも、ビルダーだ。
この役割にいちばん近い既存の職能は、映画監督だ。監督はカメラを操作しない。編集ソフトも触らない。衣装も作らない。それでも、何を作るか、どう見せるか、どこを切るか、どの順で繋ぐかを決める。全体の整合も監督が保つ。スタッフは監督とやり取りしながら形にする。ビルダーと AI の関係は、これに重なる。方向と全体はビルダーが持つ。コードと設計の作り込みは、AI との対話で進む。出来上がるものは、両者の協同が生む。3-09 では「アプリ作りは映画作りに似てくる」として、この並びを改めて扱う。
ソフトウェアエンジニアとビルダーは、扱う課題が違う
ソフトウェアエンジニア(SE)とビルダーは、似て見える。だが、構造の違う役割だ。境目は一つである。SE は狭く閉じた課題を解き、ビルダーは開いた課題を扱う。
- 狭く閉じた課題 ── 何を作るかが定義済みで、正解の条件がはっきりしている。「この仕様を、この制約で実装せよ」がこれだ。設計も実装も、課題の内側で終わる。ルールが明確で答え合わせができる課題ほど、AI は強い(1-01)。だから、SE の仕事は AI がするようになる。
- 開いた課題 ── そもそも何を作るべきかが定まっていない。現実は矛盾する。関係者の利害は割れる。制約は動く。正解は課題の外、現実の側にある。これを現実とすり合わせ、狭く閉じた課題へ翻訳していくのが、ビルダーだ。
効いてくるのは、課題の難しさではない。閉じているか、開いているかだ。狭く閉じた課題なら、どれほど高度でも AI は解く。世界で最も難しいコーディング問題(1-01)が、そうだった。難易度は障害にならない。だが、開いた課題では事情が変わる。正解が課題の内側になく、しかも「誰にとっての正解か」まで含んでいるからだ。AI は過去の蓄積から学ぶ。前例のない現実にも、まだ誰も解いていない状況にも、学ぶ材料がない。だから、開いた課題は人間に残る。
なぜ人間にできるのか。理由は二つある。
- 利害がある ── 人間は、その現実の中で生きている。何が困り、何が助かるかを、自分の身で受ける。だから、何を優先するかを決められる。
- 責任を負える ── 決めた結果を引き受ける主体である。現状の制度で責任の宛先になれるのは、人間だけだ。
この二つがあるから、人間は何が大事かを判断できる。開いた課題の正解は、この判断から立ち上がる。何を作るべきか、何が現実にとって大事か、という正解である。
積み重ねも、ここに効く。生物としての歴史、人類としての歴史、そして個人として生まれてからの一生。それが体と文化と記憶に刻まれているから、判断には拠りどころがある。ただし決め手は、拠りどころの古さではない。いま現実の中で利害を負い、結果を引き受ける位置にいることだ。
判断は、人間が握り続ける
AI が持つのは、学習で得た重みだけだ。膨大な過去のデータを統計的に圧縮したパラメータである。それ以上でも以下でもない。生きてきた歴史はない。生きることへの利害もない。何が生きるに値するかは、重みの中にない。
だから、AI に判断をまかせることはできない。狭く閉じた課題は任せていい。そこは AI のほうが速く、正確だ。だが、何を作るか、何が大事か、何に責任を負うか。これは開いた課題の判断である。ここは人間が握り続ける。これが、ビルダーという役割の芯だ。
学習で得た重みは、開発者の手で簡単に変えられる。何を学ばせるか、どう振る舞わせるかは、訓練した側の裁量の中にある。だから、モデルを無条件に信用してはいけない。どの開発者のモデルを使うかを選ぶこと自体が、ビルダーの判断だ。信頼できる開発者のモデルを使う。
ソフトウェアエンジニアの典型は、ビッグテックの社員だ。巨大なシステムの、特定の一分野だけを深く受け持つ。検索の一機能、決済の一サービス、ある API の一層。問題は狭く、よく定義されている。だからこそ、AI が最も得意とする領域だ。その仕事から先に、AI がするようになる。
そして、それは最先端ですでに起きている。Anthropic は、2026 年 5 月に本番へマージしたコードの 8 割超が Claude 製だったと公表している(VentureBeat)。Claude が Claude を作っている。ここで問うべきは「人はまだ必要か」ではなく、「人は何をするか」だ。設計とコードは AI に移り、人は計画と運用に移る。最先端の会社で起きたのは、人がいなくなったことではなく、人の書くコードがほとんど無くなったことだ。
出力を決めるのは、判断の質とループの回転数だ
| 軸 | ソフトウェアエンジニア | ビルダー |
|---|---|---|
| 扱う問題 | 狭く閉じた課題(定義済み) | 開いた課題(現実・文脈) |
| 仕事の中心 | 設計してコードを書く | 計画して仕様を書く |
| 文脈 | 仕様として与えられる | 自分で現実から切り出す |
| スキルの中心 | 設計・実装・技術習熟 | 構造分解・評価眼・統合 |
| 一案件の人数 | チーム(複数人) | 1 人 + AI |
| スループット | 設計・実装の速度に比例 | 判断の質 × ループの回転数 |
特に最後の二行が、本章の中心だ。SE の出力は「人数 × 設計・実装の速度」で決まる。人を増やせば速くなる。上限はあったが、増やせば効いた。ビルダーの出力は「判断の質 × ループの回転数」で決まる。人を増やしても速くならない。判断の連鎖は、頭の数では分散できないからだ。AI が狭く閉じた課題、つまり設計とコードを引き受けた世界では、後者の式が支配的になる。人が要らないのではない。人数を決めるのは、回す計画の数だ。コードの量で人を数える時代が終わっただけである。
SE は、狭く閉じた課題を解く。そこは AI が強い。ビルダーは、開いた課題を扱う。現実とすり合わせ、何を作るかを計画して仕様に書く。だから、ここは人間の仕事だ。
スキルの中身も別物だ。ビルダーが磨くのは、次の能力である。
- 文脈を読む ── 顧客・現場・現実から、何が大事かを掴む
- 言語化 ── 暗黙の意図を、AI に渡せる明示的な言葉に変える
- 評価 ── 返ってきたものが、現実に合うか、目的を満たすかを見る
- 統合判断 ── 部分が全体の整合や狙いを壊していないかを見る
- 取捨選択と責任 ── 返ってきた案から「これでいく」を選び、その判断に責任を負う
これらは、言語の文法やフレームワークの習熟ではない。コードを読めなくてもよい。現実を読み、何が大事かを判断できる人なら、ビルダーになれる。1-03 で見たとおり、現場の人もそうだ。
ビルダーの基盤は、ソフトウェア工学ではなくリベラルアーツだ
ビルダーの中心にあるのは、文脈の読み、言語化、評価、統合判断、取捨選択、責任である。コードを書いてきた経験が足場になることはある。だが、中心ではない。中心にあるのは、リベラルアーツと呼ばれてきた技芸のほうだ。
ここで言葉を二つに分けておく。中世の 自由七科 は、trivium(文法・修辞・論理)と quadrivium(算術・幾何・音楽・天文)の七つだ。近代以降の リベラルアーツ は、人文学・社会科学・自然科学を含む教養の全体を指す。ビルダーの能力は、この両方に跨がる。
| ビルダーに求められる能力 | 自由七科(中世) | 近代のリベラルアーツ |
|---|---|---|
| 言語化(暗黙の意図を明示の言葉に) | 文法・修辞 | 言語学・作文 |
| 課題の分解(開いた課題を扱える形に) | 論理(弁証) | 論理学・分析 |
| 統合判断(全体の整合を見る) | 幾何・音楽(比と構成) | 体系的思考 |
| 文脈の読み(顧客・現場・現実から) | ── | 歴史学・社会科学・政治哲学 |
| 評価(現実・目的に合うかを見る) | ── | 美学・倫理学 |
| 取捨選択(案から「これでいく」を選ぶ) | ── | 倫理学・判断論 |
| 価値と責任(何が大事か・判断は手放さない) | ── | 倫理学 |
上の三つは七科にそのまま載る。下の四つは七科の外にあり、近代のリベラルアーツの側で育ってきた。七科に載る三つが言葉と構造の扱い方で、七科の外にある四つが何に向けて使うかの判断だ。ビルダーには、両方が要る。
AI が代わりに引き受けたのは、ソフトウェア工学の核心だ。アルゴリズム、言語仕様、フレームワーク、設計パターン、テストの書き方。残った仕事がリベラルアーツ的な能力にしか見えないのは、構造的な必然である。
歴史的にも符号する。自由七科は、自由人が学ぶべき技芸と定義された。自由人とは、隷属していない人のことだ。対になるのは artes mechanicae、手を使って働く者の技芸である。ビルダーは、AI に判断を手放さない人だ。つまり、自由人の技芸の現代版である。
ビルダーの基盤は、ソフトウェア工学ではない。 AI 時代の自由人の技芸、すなわちリベラルアーツだ。
まとめ
ビルダーは、計画する、AI と作る、確かめる、統合するの四つを回す。SE が解いてきた狭く閉じた課題は、AI が引き受ける。ビルダーが扱うのは、現実から何を作るかを立ち上げて仕様にする開いた課題だ。その基盤は、ソフトウェア工学ではなくリベラルアーツにある。
ビルダーは、AI と組めば、一人でも大きなスコープを担える。これは社内の話だけではない。顧客が直接ビルダーをやることも、同じ理屈で可能になる。
次の章では、顧客自身が AI と組んで開発する時代を扱う。SIer の仕事を AI がするなら、顧客は SIer を介さず、AI と直接組んで作ればいい。発注していた顧客が、作る側に回る。その移行を見ていく。