顧客自身が、AI と組んで作る時代になる。だが、最初の一手はコードを書くことではない。 1-04 では、ビルダーは社内の人間である必要がないと見た。 AI と対話して作る側に立てるなら、顧客自身がビルダーになる。しかも顧客は、業務の文脈を最初から手元に持っている。SIer が外から聞き取って翻訳していたものを、省ける。本章では、顧客が何から始めるのかを見ていく。
作りたいものは、三つに分かれる
作りたいものを三つに分けると、見通しがいい。汎用的なもの、個人的なもの、組織の基盤である。この三つで、最初の一手が変わる。順に見ていく。
(いちばん経済的)"] P --> PA["OSS + AI と対話して
自分に合わせる
(2-04・2-10・2-14)"] O --> OA["OSS で基盤を立てる
(M365・Copilot・WordPress 代替)
(自立編)"] classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class GA,PA,OA good
汎用は OSS を使う。それがいちばん経済的だ
認証、文書、データベース、ビデオ会議、Web。こうした汎用的な機能は、すでに OSS として世界で共有されている。誰かが作り、公開し、何万人もが鍛えてきた。これをゼロから書く必要はない。ベンダーから買う必要もない。使えばいい。それが、いちばん経済的だ。
経済的なだけではない。セキュリティ対策としても有効だ。広く使われている OSS は、世界中の目に晒されている。無数の脆弱性が見つかっては塞がれてきた。自分でゼロから書いたコードより、よほど鍛えられている。中身の見えないベンダー製品より、よほど鍛えられている。
ここに、見落とされがちな逆転がある。注目は AI に集まる。だが、汎用の大半を実際に担うのは、共有された OSS のほうだ。AI の効果より、OSS の効果のほうが大きい。AI は、その上に載る固有の部分を速く作る道具にすぎない。
汎用的なものは、書かない。買わない。OSS を使う。 AI が脚光を浴びるが、土台を支えているのは OSS だ。
個人は、OSS の上に AI との対話で自分を足す
個人が自分のための道具を作るとき、OSS をそのまま使うだけでは足りないことがある。そこで、OSS を土台にして、AI と対話しながら自分に合った形にカスタマイズする。フレームワークを学ぶ必要はない。やりたいことをふだんの言葉で伝え、返ってきたものを試し、また頼む。それだけだ。学ぶのは、何が欲しいかを言葉にすることだけである。
これが可能になったのは、学習コストが桁違いに下がったからだ。かつては、文法を覚え、フレームワークに慣れ、動くものを一つ作るまでに、何ヶ月もかかった。AI と組むと、動くものを持つまでが数時間から数日になる。かける時間が月の単位なら諦めたものを、日の単位ならやってみる。その境目を越えた。
その実例は、自立編が扱う。
どれも、専門のプログラマーでない個人が、OSS と AI で自分の道具を作る話だ。
組織は、まず汎用の基盤を OSS で立てる
組織の場合も、出発点は同じだ。まず、汎用的な基盤を OSS で立てる。会社のソフトウェアの大半は、もともと「作る」ものではなく「買う」ものだった。Microsoft 365、Copilot、WordPress、基幹のベンダーパッケージ。その置き換え先は、すでに世界中で動いている。
- 機械は Debian の一台(2-02)── AI に渡す場所
- 土台は SQLite・PostgreSQL・DuckDB・Polars(2-03)
- 認証は PocketBase(Entra ID の代わり、2-05)
- 共有と版管理は Forgejo(GitHub の代わり、2-06)
- 文書は読む物を adoc の文字で持ち、触る表は格子、刷る紙はテンプレート(2-07)
- メールは Stalwart(2-08)、会議は Jitsi(2-09)
- Web は焼いた HTML を自分の一台(Caddy)か Cloudflare Pages へ(WordPress の代わり、2-11)
- 基幹のロジックは FastAPI で API に出す(ベンダーパッケージの代わり、2-12)
- AI は手元の LLM + RAG(Copilot の代わり、2-16)
どれも、いまこの瞬間に全部そろっているという話ではない。文書は、道具を一つ立てるのではなく持ち方を決める話で、格子は Excel のままでもよい(2-07)。Web の公開は、自分の一台なら全部自分の側、Cloudflare Pages なら窓だけ借りる形になる。借りる所と自分で持つ所を、分けて決める ── それが土台づくりの中身である。
まず汎用をベンダーから外す。そして、認証・データ・文書・メール・Web・AI という土台を自分の側に置く。その上で、本当に自社固有のロジックだけを、AI と一緒に書く。コードを書くのは、土台を据えた後半だ。しかも、書く量は自社固有の部分に縮む。
この基盤づくりが、この連載の自立編(第二部)だ。一つずつ OSS を立てて、Microsoft 365・Copilot・WordPress・基幹システム・GitHub から自立していく。
組織のソフトウェアは、まず汎用の基盤を OSS で立てる。固有のロジックだけを AI と書く。自立編が、その手順だ。
AI にできないことは、SIer にもできない
ここまでをひっくり返すと、強い帰結が一つ出る。汎用は OSS で、固有は AI と自分で作れる。それなら、SIer に丸ごと発注する理由は、どこにあるのか。
旧来、SIer に頼む理由は「自分には作れないから」だった。だが、AI ネイティブな世界では、SIer が使う AI と、顧客が使う AI は、同じ AI だ。最上層のモデルは、誰にでも同じ値段で売られている(1-01)。SIer だけが使える、特別に強い AI は無い。だから、AI にできないことは、SIer にもできない。AI が解けない問題は、SIer の中の人が同じ AI で解いても、同様に詰まる。
SIer の真の優位は、AI が届かない領域での経験と判断に残る。真に新しい技術、専門規制、組織横断の交渉、経験的にしか分からない落とし穴である。だが、それはごく一部だ。助言の形で取り込めば足りる。弁護士や税理士に定常業務を丸投げしないのと同じである(3-06)。多年契約の SIer 委託は、もう要らない。
SIer の独自能力は、AI の届かないごく一部にしかない。残りは、OSS と AI で、顧客自身が作れる。
まとめ
顧客は、汎用を OSS で、固有を AI で作る。
- 汎用は OSS ── 書かない、買わない。いちばん経済的で、守りとしても鍛えられている
- 個人は OSS + AI ── 土台の上に、ふだんの言葉で自分を足す
- 組織は基盤から ── 機械・土台・認証・コード・文書・メール・会議・Web・API・AI を自分の側に置く
- 固有だけ AI と書く ── コードを書くのは、土台を据えた後半になる
- AI にできないことは、SIer にもできない ── 同じ AI を使っているからだ
ここで導入編は終わる。AI が最強の SIer になり(1-01)、保守の単位が文脈に移り(1-02)、設計とコードの役割がビルダーに移り(1-03・1-04)、作る側に顧客自身が立つ(1-05)。残るのは、では実際に何をどう立てるのか、という問いだけだ。
次章から自立編に入る。2-01: Microsoft と Google から自立する ── 全体像と対応表で、これから立てるものの全体像と対応表を置く。そこから一章ずつ、機械・土台・認証・コード・文書・メール・会議・Web・API・図・電子工作・AI を自分の側に立てていく。