ＡＩ時代の主役は、パッケージャーだ
AIがコードを書く時代に、事業オーナーの手元に残る仕事は何か。この3部作の第1話は、その問いに著者が名付けた〝パッケージャー〟という立ち位置を主題に、それがなぜTALLスタックと噛み合うのかを、AIに修正を頼む場面から掘り下げる。
先に言い切っておく。事業オーナーがAIにコードを書かせるなら、TALLスタックを選ぶべきだ。 AIが吐き出したコードが管理不全に陥らず、しかも本格的なアプリを理解しながら伴走できる——そのハードルが、今のところ一番低いのがTALLスタックだからだ。この3部作は、その理由を1つずつ剥がしていく話になる。
結論から言う。AI時代の主役は、もうプログラマではなく、パッケージャーだ。 そしてその主役の座には、ぼくら事業オーナーが座れる。
コードを一行ずつ書く人、というより、すでにある部品をどう選び、どう組み合わせるかを決める人。これが、これから3話にわたって語る話の出発点になる。
「書く」から「選ぶ」へ
昔は、画面を1つ作るのに、こんな感じで積み上げていた。
- HTMLで骨組みを書く
- CSSで見た目を整える
- JavaScriptで動きを付ける
- サーバー側のコードでデータを繋ぐ
これを全部自分の手で書いていた時代が長かった。だから「エンジニア＝手を動かして書く人」というイメージが強い。
でも今は違う。AIエージェントに頼めば、この4つのレイヤーはほぼ全部、それなりの精度で生成してくれる。ここで残る仕事は何かというと——
「どの部品を」「どういう理由で」「どう組み合わせるか」を判断すること
これはもう「プログラミング」というより、「パッケージング」と呼ぶ方がしっくりくる。
パッケージャーってつまり何なのか
たとえるなら、料理で言う盛り付け担当に近い。素材を育てる人（AIが下ごしらえしてくれる部分）と、それをどう皿に乗せるかを決める人（あなた）は別の仕事だ。素材の良し悪しを見極め、組み合わせを決め、味のバランスを取る——ここに判断力と経験が要る。
TALLスタックで言うと、パッケージャーが扱う「素材」はこんな感じになる。
| 素材 | 役割 | 誰が管理しているか |
|---|---|---|
| Tailwindのユーティリティクラス | 見た目（色・余白・配置） | Tailwind Labs |
| Blade / pinion-ui のコンポーネント | 部品（ボタン・カード・モーダル） | ライブラリの作者 |
| Alpine / Livewire のディレクティブ | 挙動（クリック・入力・状態） | それぞれの作者 |
自分で1から実装するものはほとんどない。すでに検証済みの部品を、正しい場所に、正しい組み合わせで置く——これがパッケージャーの仕事だ。
なぜこれがAI時代に「効く」のか
ここが今回いちばん言いたいこと。AIエージェントにコードを書かせる時、いちばん怖いのは「どこまで影響が広がるか分からない変更」だ。
- 密結合な自前コード（CSSがどこか別ファイルで上書きされている、JSがグローバル変数を触っている）は、AIに直してもらってもどこまで波及するか自分にも予測できない
- TALLスタックのように「見た目・部品・挙動」がその場所だけで完結する語彙（第2話で詳しく話す）で組まれていれば、AIの変更もその場所だけで収まる
つまりTALLスタックの「疎結合・局所完結」という性質は、人間にとって読みやすいだけでなく、AIに安心して仕事を任せられるという、もう一段実利的なメリットを持っている。
「所詮パッケージャーだろ」という声について
正直に言うと、この「パッケージャー」という立ち位置は、時々こう言われる。
「所詮、人が作った部品を並べてるだけでしょ。それって本当のエンジニアリングなの？」
この批判、分からなくはない。実際、何も考えずに部品を並べるだけなら、それは大したことじゃない。
でも、ちゃんと反論したい。「何を・どういう理由で組み合わせるか」の判断こそが、実は一番難しくて、一番価値が高い部分だ。
- どの部品が信頼できるか（メンテされているか、実績があるか）を見極める目
- 組み合わせた時に起きる副作用を予測する経験
- 事業として「今これが必要か」を判断する優先順位付け
これはAIが代わりにできない。AIは「言われた通りに部品を生成・接続する」のは得意だが、「そもそも何を作るべきか、どの部品を信頼すべきか」を決めるのは、あなたの仕事のまま残る。パッケージャーは、下請けではなく、意思決定者だ。
もう一段、狙いを絞って言いたい。「事業オーナーでありながら、自分でもAgentic Codingができる人」を目指すなら、TALLスタック一択だ。
一番大事なのは「そもそも何を作るべきか」であって、「何で作るか」ではない。だからこそ、出来合いのいい部品が揃ったTALLスタックで、まず戦ってみるべきだ。事業判断とコーディングを1人で背負うなら、覚える対象（PHP1つ・局所完結な部品群）は少ないほどいい。もし本当にTALLでは越えられない壁にぶつかったら、その時に別の言語へ進めばいい——それまでの戦いは決して無駄にならない。むしろ最初から別の技術を選ぶ方が、遠回りになる。
次回予告
「TALLスタックの部品が、なぜここまで安心して組み合わせられるのか」——その仕組みの核心には、実は「HTMLだけ見ていたい」というワガママな欲求が関わっている。
次の第2話「ブラックボックス化しないAI開発の条件とは」で、その仕組みの正体に踏み込む。