顧客自身が、AI と組んで作る時代になる。だが最初の一手は、コードを書くことではない ── まず、実績ある OSS を使う。
1-04で、ビルダーは社内の人間である必要がないと見た。AI と対話して作る側に立てるなら、顧客自身がビルダーになる。しかも顧客は、業務の文脈を最初から手元に持っている ── SIer が外から聞き取って翻訳していたものを、省ける。
では、何から始めるのか。作りたいものを三つに分けると、見通しがいい ── 汎用的なもの・個人的なもの・組織の基盤。順に見ていく。
(いちばん経済的)"] P --> PA["OSS + AI と対話して
自分に合わせる
(第6・7・8章)"] O --> OA["OSS で基盤を立てる
(M365・Copilot・WordPress 代替)
(自立編)"] classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 class GA,PA,OA good
まず、汎用は OSS ── これがいちばん経済的
認証、文書、データベース、ビデオ会議、Web ── こうした 汎用的な機能は、すでに OSS として世界で共有されている。誰かが作り、公開し、何万人もが鍛えてきた。これを、ゼロから書く必要も、ベンダーから買う必要もない。使えばいい。それが、いちばん経済的だ。
そして、経済的なだけではない ── セキュリティ対策としても有効だ。広く使われている OSS は、世界中の目に晒され、無数の脆弱性が見つかっては塞がれてきた。自分でゼロから書いたコードや、中身の見えないベンダー製品より、よほど鍛えられている。
ここに、見落とされがちな逆転がある。注目は AI に集まるが、汎用の大半を実際に担うのは、共有された OSS のほうだ ── AI の効果より、OSS の効果のほうが大きい。AI は、その上に載る固有の部分を速く作る道具にすぎない。
汎用的なものは、書かない・買わない ── OSS を使う。 AI が脚光を浴びるが、土台を支えているのは OSS だ。
個人なら ── OSS に、AI と対話して自分を足す
個人が自分のための道具を作るときは、OSS をそのまま使うだけでは足りないことがある。そこで、OSS を土台に、AI と対話して、自分に合った形にカスタマイズする。フレームワークを学ぶ必要はない ── やりたいことをふだんの言葉で伝え、返ってきたものを試し、また頼む。それだけだ。
これが可能になったのは、学習コストが桁違いに下がったからだ。かつては「半年〜1 年で初級者」だったのが、AI と組めば「数時間〜数日で動くものを持っている」になる。半年かかるなら諦めたものを、数日でできるなら自分でやる ── この境目を越えた。
その実例は、親シリーズの個人トラックが扱う:
- 親シリーズ第2章 ── 処理を Python で書く(Excel マクロも Python へ)
- 親シリーズ第6章 ── Web を、AI と対話して作る
- 親シリーズ第8章 ── 組み込みを作る
どれも、専門のプログラマーでない個人が、OSS と AI で自分の道具を作る話だ。
個人の道具は、OSS を土台に、AI と対話して自分に合わせる。学ぶのはフレームワークではなく、何が欲しいかを言葉にすることだけだ。
組織なら ── まず、汎用の基盤を OSS で立てる
組織の場合も、出発点は同じ ── まず、汎用的な基盤を OSS で立てる。会社のソフトウェアの大半は、もともと「作る」ものではなく「買う」ものだった。Microsoft 365、Copilot、WordPress、基幹のベンダーパッケージ。その置き換え先は、すでに世界中で動いている。
- 認証は PocketBase(Entra ID の代わり)
- 文書は OnlyOffice(Word・Excel・PowerPoint の代わり)
- 共有と版管理は Forgejo(GitHub の代わり)
- メールは Stalwart、会議は Jitsi、Web は Cloudflare Pages(WordPress の代わり)
- AI は手元の LLM + RAG(Copilot の代わり)
まず OSS でベンダーを外し、土台(認証・データ・文書・メール・Web・AI)を自分の側に置く。その上で、本当に自社固有のロジックだけを、AI と一緒に書く。コードを書くのは、土台を据えた後半だ ── しかも、書く量は自社固有の部分に縮む。
この基盤づくりが、本サブシリーズの 自立編(第二部)だ。一つずつ OSS を立てて、Microsoft 365・Copilot・WordPress・基幹システム・GitHub から自立していく。
組織のソフトウェアは、まず汎用の基盤を OSS で立てる。固有のロジックだけを AI と書く ── 自立編が、その手順だ。
AI にできないことは、SIer にもできない
ここまでをひっくり返すと、強い帰結が一つ出る。汎用は OSS、固有は AI と自分で作れるなら、SIer に丸ごと発注する理由は、どこにあるのか。
旧来、SIer に頼む理由は「自分には作れないから」だった。だが、AI ネイティブな世界では、SIer が使う AI と、顧客が使う AI は、同じ AI だ。 SIer 専用の Claude があるわけではない。だから ── 「AI にできないこと」は、SIer にもできない。AI が解けない問題は、SIer の中の人が同じ AI で解いても、同様に詰まる。
SIer の真の優位は、「AI が届かない領域での経験と判断」── 真に新しい技術、専門規制、組織横断の交渉、経験的にしか分からない落とし穴 ── に残る。だがそれは ごく一部で、助言の形で取り込めば足りる。弁護士や税理士に定常業務を丸投げしないのと同じだ(3-05)。多年契約の SIer 委託は、もう要らない。
SIer の独自能力は、AI の届かないごく一部にしかない。残りは、OSS と AI で、顧客自身が作れる。
次の章へ
顧客は、汎用を OSS で、固有を AI で作る。まずは個人の実例から見ていくのが分かりやすい ── 専門のプログラマーでない人が、OSS と AI で自分の道具を作る。
その実例は親シリーズの個人トラックが扱う ── Excel マクロを Python に(親シリーズ第2章)、Web を(親シリーズ第6章)、組み込みを(親シリーズ第8章)。