決めるのは人間、
書くのはAI。

何を作るかを決め、AIに作らせ、出力を評価し、構造を統合する ── これがビルダーの仕事だ。

第3章で、コーダー(実行を中心に置く役割)が経済的に成立しなく なる、と書いた。残るのは判断側の役割で、これを本書ではビルダー と呼ぶ。本章はその定義 ── 何をする人か、どこがコーダーと違うか、 なぜ 1 人 + AI で動くか ── を、具体例とともに固定する。

具体例は、本記事が乗っているこのサイト ── aiseed.dev ── そのもの を使う。コード基盤(約 6,000 行) を 1 人 + AI で 24 時間で 立ち上げ、そこに約 150 本のバイリンガル記事が乗ったマルチ系列 サイトだ。記事側は別の時間軸 ── 1 サブシリーズあたり約 1 週間 ── で書かれている。後述する。再現用のソースとビルドスクリプトはすべて このリポジトリに入っている。

ビルダーは「何を作るかを決め、AIに作らせる」役割だ

ビルダーの仕事は、四つの連鎖で動く。

• 決める ── 顧客・現場・自分の文脈から、何を作るかとどう分ける かを判断する。仕様の骨格を書き出す。
• 委譲する ── AIに、意図と制約と受け入れ条件を渡す。コードは AIが書く。
• 評価する ── 返ってきた出力が、動くか、設計と整合するか、想定 した文脈で破綻しないかを判断する。
• 統合する ── 部分を全体に組み込み、整合を保つ。次の「決める」 に戻る。

この四つは線形ではなく ループ だ。一周まわす時間は、規模により 数分から数時間。一日に何十周も回す。コードを書く時間はその中で 最小化される ── 書くのは AI だからだ。

このループの全長を握っているのが、ビルダーだ。AIはループの中の 一辺にしか入らない。判断・委譲条件・評価基準・統合方針は、ビルダー の側にある。

この役割の最も近い既存職能は、映画監督 だ。監督はカメラを操作 しない、編集ソフトも触らない、衣装も作らない ── しかし「何を作るか」 「どう見せるか」「どこを切るか」「どの順で繋ぐか」を判断し、全体の 整合を保つ。技術スタッフは判断に応じて手を動かす。ビルダーと AI の 関係はこれに重なる ── 判断は人間、技術実行は AI、artifact は両者 の協同が生む。第11章で「アプリ作りは映画作りに似てくる」として この並列を改めて扱う。

コーダーとの構造的な違い

コーダーとビルダーは、似て見えて構造的に別の役割だ。

特に最後の二行が、本章の中心だ。コーダーは「人数 × 書く速度」で 出力が決まる。ビルダーは「判断の質 × ループの回転数」で出力が 決まる。AI が実行を取った世界では、後者の式が支配的になる。

コーダーの世界では「人を増やせば速くなる」が成立した (上限はあったが)。 ビルダーの世界では 人を増やしても速くならない ── 判断の 連鎖は、頭の数では分散できない。

スキルの中身も別物だ。ビルダーが磨くのは、こういう能力:

• 構造分解 ── 大きな塊を、AI に渡せる粒度に切り出す
• 言語化 ── 暗黙の意図を、AI が処理できる明示的な記述に変える
• 評価眼 ── 動くだけのコードと、設計に合うコードを区別する
• 統合判断 ── 部分が全体の整合を壊していないかを見る
• 取捨選択 ── AI が返した三つの案から「これでいく」を選ぶ

これらは、言語の文法を覚えれば身につくものではない。コードを 書いてきた経験は役立つが、それは判断の足場としてであって、書く 能力そのものではない。

ビルダーの基盤は、ソフトウェア工学ではなくリベラルアーツだ

コードを書いてきた経験は、ビルダーの仕事の 足場 として効く。 だが中心ではない。中心にあるのは、構造分解・言語化・評価眼・統合 判断・取捨選択 ── これらはすべて、伝統的に リベラルアーツ(自由 七科) と呼ばれてきた技芸だ。

AI が代わりに引き受けたのは、ソフトウェア工学の核心 ── アルゴ リズム、言語仕様、フレームワーク、設計パターン、テストの書き方。 残った仕事がリベラルアーツ的な能力にしか見えないのは、構造的な 必然だ。

歴史的にも符号する。中世のリベラルアーツは「自由人(隷属していない 人)が学ぶべき技芸」と定義された ── 奴隷の技芸(mechanical arts) と対になる概念だ。ビルダーは「AI に判断を手放さない人」── つまり 自由人の技芸の現代版 である。

ビルダーの基盤は、ソフトウェア工学ではない。 AI 時代の自由人の技芸 ── リベラルアーツ だ。

念のために区別を一つ。AI が引き受けたのは ソフトウェア工学 (software engineering) ── 言語・フレームワーク・設計パターン・ テスト技法といった 実装の核心 だ。一方、コンピュータ サイエンス(CS) ── 計算理論・アルゴリズム・形式論理・離散数学 ── は別物で、もともと quadrivium(数学・論理)の延長線上にある リベラルアーツの内側にいる。歴史的にも CS は数学科から派生し、 Turing・Church・von Neumann は数学者・論理学者だった。CS は 捨てる必要も特別扱いする必要もない ── ビルダーの判断の足場 として、リベラルアーツの中に組み込まれている。

「コードを書ける人を採用する」から「判断できる人を採用する」 への転換は、表面的な人材論ではなく、技術職の基盤学問が変わる という根本的な構造転換だ。第9章で再びこの主題に戻る。

ビルダーの一日は、判断の密度で決まる

ビルダーの一日は、コーダーの一日と中身が違う。

• コーダーの一日: 多くの時間は書いている。途中で要件を確認し、 レビューを受け、修正を入れる。集中している間は、エディタの中。
• ビルダーの一日: 多くの時間は読んでいる、決めている、評価 している。AI が返してきた差分を読む、不変条件に違反していない か確かめる、次に何を頼むかを書く。エディタは中継地点だ。

エディタの操作量は減る。代わりに、1 時間あたりの判断の数が 何倍にもなる。AI が返すサイクルが短いほど、判断の密度は上がる。 これは脳に対する負荷が、書く仕事より重い ── ビルダーの疲れは、 肩や手ではなく、意思決定の容量に出る。

連続して何時間も動けるビルダーは、限られる。これが「ビルダーは 人を増やしても速くならない」の生理的な側面だ。

実証 ── 二つのアンカー: コード基盤 24 時間、1 サブシリーズ 1 週間

抽象論はここまで。具体例として、本記事が乗っているサイトそのものを 分解する。aiseed.dev は次の構成を持つ:

• 5 つの独立系列: Insights(構造分析)、Blog、Claude × Debian (技術書)、AIネイティブな仕事の作法(本シリーズ)、リン資源 枯渇と自然農法
• 約 150 本の章・記事(日英バイリンガル、ソース MD は計約 300 本)
• コード基盤 約 6,000 行(tools/build_article.py 約 1,800 行、 各系列のテンプレート約 2,400 行、ビルドユーティリティ、OG 画像生成、 サイトマップ・hreflang・robots、各系列固有のタイポグラフィ)
• バイリンガル(JA / EN、各記事に hreflang、ハードコーディング された言語スイッチャー)
• Mermaid・コードハイライト・OG 画像自動生成・サイトマップ

アンカー 1 ── コード基盤を 24 時間で立ち上げ

コード基盤の部分 ── ビルドツール、テンプレート、画像生成、 サイトマップ、bilingual の枠組み ── は、個人 1 人 + AI(主に Claude) が およそ 24 時間 で立ち上げた。コードの大半は AI が書き、ビルダー は設計判断・統合・評価を行った。同じスコープのコード基盤を従来の SIer 委託モデルに乗せると、提案と見積もりの段階だけで同等の時間が 消える(このプロセスのコスト構造は第6章で扱う)。

アンカー 2 ── 1 サブシリーズを 1 週間で書く

正直に書いておく必要がある。記事本文(コンテンツ)はこの 24 時間 の外で書かれている。具体的に言えば、本サブシリーズ(ソフトウェア 開発編・全 11 章)を書くのにかかっている時間は、およそ 1 週間 だ (現時点で 4 章、残りも同じペースで進める見込み)。この 1 週間には:

• 章立て案(docs/Ai-native-software-outline.md)を決める
• サブシリーズ機構をビルドツールに組み込む改修
• 執筆運用のスキル(building-ai-native-software-series ほか)を整備
• 章を日英バイリンガルで書く
• 校正・事実修正・スキル更新を繰り返す

これだけの作業を 1 人 + AI で 1 週間に収めるのは、コードの 24 時間 とは構造が違う。コードと違い、記事の AI 委譲度は低い。

• 主張は人間が決める ── 何を言うか、何を言わないか
• 構成は人間が決める ── どの順序で、どの濃度で
• 事実関係は人間が検証する ── 数字・年代・引用、すべて一行ずつ
• 文体と語感は人間が握る ── 読者を想定した呼吸
• 主張の責任は人間に残る ── これは第3章の「判断の境界線」と同じ

AI に下書きを書かせることはあるが、その下書きは 全文を読み、修正 し、書き直す ことが前提だ。事実誤認、論旨の飛び、語感のずれ ── そのまま通すと信頼を失う種類の問題が含まれる。「1 週間」という数字 は、記事の判断密度の高さを織り込んだうえでの 1 人 + AI のスループッ トの実測値 だ。

二つのアンカーが意味するもの

この対比そのものが、本章の主張を固める:

• コード: AI 委譲可能な比率が高い。一回限りの基盤構築は 24 時間。 ビルダーは設計と評価を握る。
• 記事: AI 委譲可能な比率が低い。1 サブシリーズあたり 1 週間の 判断密度。ビルダーは下書き以外のすべてを握る。

委譲可能な比率が低いほど、ビルダーの判断密度は上がる。判断こそが ビルダーの中心であることは、出力の種類が違っても変わらない。

再現性のために、すべてのソース・テンプレート・ビルドスクリプトはこの リポジトリにコミットされている。make 一発で同じサイトが立ち上がる (設計原則は親シリーズの章ごとの example-N/ と同じだ)。

ビルダーがやったこと ── コード基盤: 設計を決め、AI に書かせ、評価 し、統合した(約 24 時間)。記事: 主張・構成・事実検証・語感を握り、 AI の下書きは全文を読み直した(1 サブシリーズ ≈ 1 週間)。 書く能力ではなく判断する能力が中心である点は、両方で共通している。

1 人 + AI が、なぜ 10 人のコーダーチームより速いか

「同じスコープを 1 人 + AI で 24 時間」を、コーダーチームでやろうと すると、何が起きるか:

• 仕様の同期会議 ── 何時間か
• タスク分割と割り当て ── 半日
• 各コーダーが書く ── 数日〜数週間
• 統合フェーズ ── 数日〜数週間(統合のコストは人数の二乗で増える、 これも Brooks の指摘)
• レビューと修正のラウンド ── 数週間
• ドキュメント整備 ── 後回し、たいてい乖離する

スコープが同じでも、チーム化のコストが工程の半分以上を食う。 ビルダー + AI には、このコストがほぼゼロだ:

• 仕様の同期会議 ── ビルダーの頭の中で完結
• タスク分割と割り当て ── ビルダーが AI に直接渡す
• コードを書く ── AI が並列で書く
• 統合フェーズ ── ビルダーが直接統合(他人の頭との同期が不要)
• レビューと修正 ── 同じループの中で回る
• ドキュメント ── AI が設計から再生成(第2章)

人数を増やすと統合コストが二乗で増えるのは旧来の話。1 人 + AI では、判断は分割不能だが、実行は AI 内部で並列化される ── 統合 コストの二乗成長を回避できる。これが「1 人 + AI が 10 人を超える」 の構造的な理由だ。

ただし、この優位は ビルダーが判断を握り続ける限りでしか成立 しない。第2章で見た「vibe coding」の罠 ── AI に丸投げして判断を 手放す ── に落ちると、ループは崩れて 1 人 + AI は何も生まないチーム に劣化する。

1 人 + AI が強いのは、判断と実行の境界が一人の中で閉じるから だ。境界を増やすと、コストはチームと同じになる。

次の章へ

ビルダーは、コーダーチームより少ない人数で、より大きなスコープを 出力できる。これは社内の話だけではない ── 顧客が直接ビルダーを やることも、同じ理屈で可能になる。

次の章では、顧客自身が AI と組んで開発する時代を扱う。これまで SIer に発注していた顧客の何割が、自分で作るほうに流れるのか。

関連記事

• 第1章: AI は、世界で最も難しいコーディング問題を解く
• 第2章: 保守フェーズの構造変化こそ本質
• 第3章: コーダーの仕事はなくなる
• 構造分析08: 企業ITの税を引く
• 構造分析12: AIと個人事業