連載

AI ネイティブなソフトウェア開発

SIer に頼まない ── 自分で立てて、自分で動かす

導入編 ── なぜ変わるのか

1-01

AI は、世界で最も難しいコーディング問題を解く — Codeforces 2700 帯から設計まで ── Mythos/Fable 時代、AI は月 3 千円で呼べる「最強の SIer」になった

AI のコード作成能力は、競技プログラミングの公開レーティング(Codeforces 2700 帯)で人間の最上層に並んだ。さらに、標的への攻撃工程の大半を自律的に遂行した事例が公表されている ── これは設計能力の証拠である。攻撃・設計・検証は、一つの力の三つの顔だ。Mythos/Fable 時代になって、AI は要件を読み、構造を決め、実装し、動かす「最強の SIer」になった。しかも月 3 千円で誰でも呼べる。この一点から、連載の議論がすべて導かれる。

1-02

保守フェーズの構造変化こそ本質 — コーディングコスト低下は氷山の一角 ── AI が文脈を理解するから、コードでの保守そのものが要らなくなる

AI がコードを書くようになったことの最も見落とされやすい帰結は、コーディングの高速化ではない。保守フェーズそのものの構造変化だ。保守はソフトウェアの費用の 4〜8 割、平均 6 割を食う(Glass, IEEE Software, 2001)。AI が文脈を理解するから、コードでの保守そのものが要らなくなり、保守の単位はコードから設計・仕様・文脈に移る。最大の単一コストだったレガシーコードの読解は消える。マニュアルを読んで自分の現実に合わせられる人なら、開発も保守もできる。

1-03

ソフトウェアエンジニアの仕事を AI がするようになる — コーダーは当然消える ── 設計までするソフトウェアエンジニアも、自分で設計しコードを書く役割ではなく、AI と対話する役割(ビルダー)に変わる

コードを書く役割であるコーダーは、当然消える。だがこの章の主題はその先だ。設計までするソフトウェアエンジニアの仕事も、AI がするようになる。コードを書く力と構造を決める力は、別々の AI が分担しているのではなく、一つの力の別の顔だ。だから設計もコードも AI が担う。人間に残るのは、自分で設計しコードを書く仕事ではない。AI と対話してシステムを作り動かす仕事、つまりビルダーだ。電卓が算盤を押し出したときと同じ分岐が、いま起きている。消えるのは役割定義であって、人ではない。

1-04

ビルダーという役割 — 何を作るかを計画して仕様に書き、AI と対話して作り、動かし、全体を統合する

ビルダーは、AI と対話してシステムを作り、動かす役割である。ソフトウェアエンジニアの後継ではない。ソフトウェアエンジニアは狭く閉じた課題を解く仕事で、そこは AI が引き受ける。ビルダーが扱うのは開いた課題、つまり現実から何を作るかを立ち上げる仕事だ。本章では、ビルダーの仕事を「計画する・AI と作る・確かめる・統合する」の四つのループとして定義する。そのうえで、狭く閉じた課題と開いた課題という軸から、なぜ判断を AI にまかせられないかを示す。

1-05

顧客が AI と協働して開発する時代 — 最初の一手は、コードではなく OSS ── 汎用は使い、個人はカスタマイズ(2-04・2-10・2-14)、組織は基盤から(自立編)。足りない固有だけ、AI と作る

顧客自身がビルダーになる時代である。だが最初の一手は、コードを書くことではない。実績ある OSS を使うことだ。汎用的なものは、まず OSS を使う。これがいちばん経済的で、セキュリティ対策としても有効だ。個人的なものは、OSS の上に AI と対話して自分に合わせる。その実例は自立編の 2-04・2-10・2-14 にある。組織は、Microsoft 365・Copilot・WordPress を代替する OSS で基盤を立てる。これが自立編だ。足りない自社固有のロジックだけを、AI と書く。AI にできないことは、SIer にもできない。

自立編 ── AI に読ませて、そのとおりに立てる

2-01

Microsoft と Google から自立する ── 全体像と対応表 — ビジネスの土台を、ベンダーの檻から自分の手元へ

ロックインの正体は、機能の弱さではない。中身が閉じていること、そして鍵(認証)が他人の手元に集中していることだ。Office スイートも業務システム(基幹)も、同じ構造で立っている。閉じたものを開かせること、それが AI の役割だ。独自形式を解き、読めないコードを読み、閉じ込められた業務知識を取り出す。自立編は、AI と一緒にこの閉じた束を一層ずつ開いた OSS に解き、鍵を自分の手元に移す。機械は Debian の PC 一台、処理は Python と Flet、認証は PocketBase、文書は adoc と git、コードと共有は Forgejo、メールは Stalwart、会議とカレンダーは Jitsi と Radicale、Web は自分の一台か Cloudflare Pages、データは PostgreSQL と SQLite と DuckDB、基幹は FastAPI、AI はローカル LLM + RAG。この章はその全体像と対応表であり、続く各章が一本ずつ実際に立てる。

2-02

AI に PC を一台渡す ── 自立編を動かす機械 — 会社の PC を一台 Debian にして、root ごと AI に渡す。初期化で戻らない物だけ、人が持つ

自立編で立てるものは、全部どこかで動く。その置き場をここで決める。会社の PC を一台 Debian にして、AI に渡す。公開の Web、社内の道具、AI の作業を同じ一台に載せ(自前の LLM だけは別のサーバー)、画面(GNOME)も入れて動かしたままにする。サービスは Docker を使わず、apt で入れて systemd で動かす。設定は全部 AI がやるので root を渡す。設定を git に入れ、データを機械の外に写しておけば、壊れても初期化で戻せるからだ。それでも戻らない三つ(鍵と認証、外でやる操作、データの写し)だけを人が持つ。AI は別の会社のものも入れ、作った物と確かめる基準だけを渡して相互に見張らせる。費用は作るあいだ月約 120 ドル、運用に入れば月約 40 ドル。稟議も、サーバーの契約も、人数分のライセンスも要らない。

2-03

土台を据える ── SQLite・PostgreSQL・pgvector・DuckDB・Polars — すべてが乗るデータ基盤を、最初に自分の側に立てる

自立編で最初に立てるのは、すべてが乗るデータ基盤。普通は SQLite で十分 ── サーバ不要の単一ファイルだ。共有して複数人で書くときだけ PostgreSQL に上げる。pgvector で意味検索、DuckDB と Polars で列指向分析 ── Excel は人の入出力に残し、その裏のデータは機械が捌く。Power BI の人数課金から離れる。立て方は apt と systemd。汎用は OSS で共有されている ── 書くのではなく、立てる。立てる先は、2-02 で AI に渡した一台だ。

2-04

処理を書く ── Python と Flet で、自分の道具を持つ — マクロ・グラフ・ピボットを Python に出し、画面は Flet で被せる

Excel と Word に埋まったマクロ・VBA・グラフ・ピボットを、Python に外部化する。要るのは書く能力ではなく、使う能力だ。JupyterLab をブラウザで開き、Polars でピボットと VLOOKUP をコードにし、matplotlib と Altair でグラフを描く。そして人のための入出力 ── 帳票・ダッシュボード・請求書 ── を基幹から剥がして手元に降ろす。月末の帳票実行で営業システムが固まる事故は、この分離で消える。画面が要るところには Flet を被せる。同じ Python のコードが Mac・Windows・Linux・Web・モバイルで動き、flet-mcp が入っている版の書き方を AI に渡す。

2-05

門番を立てる ── PocketBase で認証を一つに — 共有するのは身元(認証)だけ ── アクセス制御は各サーバーが持つ。中央は最小限、守りは多層で

認証は、各アプリが個別に作るものではない。一度立てて皆で共有する門番だ。だが門番が持つのは最小限の共通=身元だけ。「何ができるか」=アクセス制御は、各アプリ・各サーバーが自分で持つ(多層防御)。「通った者は中ではどこでも通す」境界防御には頼らない。PocketBase は単一バイナリに、メール認証・OAuth2・ワンタイム・MFA・管理画面・REST API を備える。身元は門番が持ち、業務データは PostgreSQL に置く。Microsoft Entra ID への月額・人数課金から降りる。

2-06

コードを手元に ── Forgejo と Zed — ビルダーの仕事場を、自分の側に ── リポジトリも CI も、Microsoft の外へ

ビルダーの仕事は、AI にコードを書かせ、評価し、統合すること。その置き場 ── リポジトリ ── を自分の側に立てる。Forgejo は GitHub・Azure DevOps を置き換える単一の Git フォージで、Actions で CI/CD まで賄う。2-03の PostgreSQL に乗せ、2-05の門番の内側に。動くのは 2-02 で AI に渡した一台の上だ。手元の道具は Zed と、その中から呼ぶ AI。コードは資産であり、置き場の主導権は自分が持つ。

2-07

文書を取り戻す ── 読む物は adoc、触る表は格子、刷る紙はテンプレート — 中身は文字で持って git に入れる。Excel も Word も Claude Docs も、入口と出口を通過させる道具にする

Word と Excel で作っていた物は一つではない。読む物、触る表、刷る紙の三つで、持ち方が違う。読む物は AsciiDoc の文字で書き、2-06 の Forgejo に置いて Zed で直す。デザインは入れず、ビルドで PDF と HTML に刷る。触る表は格子のまま ── Excel でも Euro-Office でも LibreOffice でもよく、データは格子の外(2-03)に置く。どこまで Python に寄せるかは人による。刷る紙(公表する統計表、様式、帳票)は、形をテンプレートで、値を文字で持ち、流し込んで出す。頁割りの再現は追わない。Office も Claude Docs も、入口と出口を通過させる道具になる。縮むのは手で作っていた所で、統計表は大きく縮み、決算はそれほど縮まない。

2-08

メールを自分の側に ── Stalwart と Thunderbird — Exchange と Outlook の外へ ── 受信箱は自分の側に、送信は条件が揃えば自分で

メールは事業の記録そのものだ。Stalwart は Rust 製の単一サーバで、SMTP・IMAP・JMAP・スパム対策・DKIM 署名を一つに備え、Exchange を置き換える。2-03 の PostgreSQL に乗せ、2-02 で AI に渡した一台の上に立て、Thunderbird など IMAP のクライアントで読む。送信は、固定 IP・逆引き・SPF/DKIM/DMARC・25 番が通る回線の四つが揃えば自分で送り、届かない相手が出たときだけ中継を借りる。立て方は公式の導入スクリプトと systemd。DNS(MX・SPF・DKIM・DMARC)と外へのメール送信は、人が通す。

2-09

会議とカレンダーを自分の側に ── Jitsi と CalDAV — Teams の会議も、カレンダーの共有も ── 自分のドメインで。予約は 2-12 で書く

ビデオ会議は Jitsi Meet、予定の共有は Radicale(CalDAV)。Teams・Zoom とカレンダーの共有を、自分のドメインと 2-02 で AI に渡した一台に置き換える。どちらも Debian の apt で入れ、Caddy の後ろに置く。予約の受付(Calendly・Bookings の代わり)は、自前で立てられる OSS が無くなったので、2-12 で FastAPI の小さなアプリとして書く。BigBlueButton は Ubuntu の専用機が要るので、本格的な授業のときだけ別の一台に。人が持つのは、ドメインと DNS、会議を開ける人の一覧、移す未来の予定だ。

2-10

Web を作る ── HTML と CSS と JavaScript に戻る — 中身は AsciiDoc と Mermaid、外枠は最小限の HTML と CSS

Web サイトを二層に分けて組み立てる。中身は AsciiDoc(Markdown でも同じ)と Mermaid、外枠は HTML と CSS と最小限の JavaScript、両者を Python が繋ぐ。フレームワークとビルドツールの列から素の Web 標準に戻ると、依存は一桁に収まり、全部読み通せる。WordPress に入っている中身は、七つの手順で文字に移せる。作り直す時間が無ければ、Playwright で今あるサイトを丸ごと静的に写し取る手もある。npm を離れるもう一つの理由はサプライチェーンにあり、動く部分は FastAPI を一つ選んで最小限に保つ。

2-11

Web を公開する ── 自分の一台か、Cloudflare Pages か — 焼いた HTML を、二つの置き場のどちらにも、同じ手順で出す

前章で焼いた静的サイトを、外に出す。置き場は二つある。2-02 で立てた自分の一台に Caddy で載せるか、Cloudflare Pages に置くか。どちらも「ビルド → 確認 → デプロイ」を分ける同じ手順で出せて、後から入れ替えられる。自分の一台なら、公開の Web も内部の道具も動く部分も同じ機械に並び、証明書は Caddy が自動で取る。Cloudflare Pages なら、CDN と防御を借りて機械の面倒を持たない。動く部分は FastAPI 一つにまとめ、公開の側からはその一点だけを通す。人が持つのは、ドメインと鍵と、本番へ出す判断の三つだ。

2-12

API を作る ── FastAPI で基幹のロジックを出す — 基幹システムを並行稼働で書き換え、自社固有のロジックを一箇所の API にまとめる

「壊すな・触るな」はもう古い。AI で基幹システムの書き換えコストは桁で下がった。新しいシステムを FastAPI で作り、旧システムと並行で動かし、出力を実測で突き合わせる。差分が消えたら旧を止める。業務知識は一気に Markdown に出し、現場がテストを書き、委託は止める。書き換えた基幹ロジックは、2-03 の PostgreSQL を読み書きし、2-05 の門番のトークンで本人確認する一本の API として着地する。最初の一本は、予約の受け口でよい。

2-13

図と資料を作る ── Mermaid・Marp・そのほかの道具 — 図もスライドも 3D も、テキストとコードから出す

図も、スライドも、配布する資料も、テキストとコードから出す。構造図は Mermaid、画面の下書きは AI に HTML で、スライドは Markdown と Marp(単体のバイナリ)か pandoc。ここまでが日常の道具で、その先に D3.js、Blender(bpy)、ComfyUI、CadQuery / Build123d / OpenSCAD / FreeCAD がある。どれもスクリプトやコードで動かせるから、AI に書かせて、出てきたものを見て、調整する。商品写真の白背景化、工場のセンサ筐体、観光プロモの動画素材、地方紙の人口データの図 ── これまで制作会社に発注していた仕事が、手元で回る。業務資料は中身とデザインを分けて持ち、一箇所を直せば、すべての出力に反映される。

2-14

電子工作から IoT まで ── Python で考え、AI に翻訳させる — 部品を組み、基板を動かし、測った値を手元に流す ── 思考は Python の側に置く

部品を買ってブレッドボードに組み、センサを繋ぎ、測った値をネットワークで手元に流すところまでを一つの章にする。マイコンは最終的に C や C++、軽くても Rust や MicroPython で動くが、設計と検証は PC の Python でできる。動くと確かめてから、必要な部分だけ AI に翻訳させる。言語は開発フェーズで決め、Python から MicroPython、必要なら Rust へ進む。C と C++ は既存資産を扱うときに使う。筐体は 2-13 の CAD で刷り、集めた値は 2-03 の置き場に積み、2-12 の API で出し、2-04 の Flet で画面にする。農家の畑センサネットワークと、二十年物の PLC ラダーを Python にした例を置く。

2-15

社内情報を整える ── 整備こそ本体、AI は最後の一手 — OCR・分類・属人知の成文化 ── 散らばった・書かれていない知を、書かれた・構造化された状態へ。AI を載せなくても回収できる no-regret 投資

AI を載せる前に、載せるに値する情報を作る。散らばったファイル、紙・スキャン PDF、人の頭の中だけにある属人知 ── これを OCR・分類・成文化で、書かれた・構造化された状態へ移す。整備こそ本体で、AI は最後の一手だ。何を残し、どう構造化するかは人にしかできない判断であり、AI を載せなくても属人化の解消として回収できる no-regret 投資。整えた情報を 2-07 のファイルと 2-03 の pgvector に置き、次章で RAG に載せる。

2-16

自前の AI を据える ── LLM と RAG — 全ての上に AI を乗せる ── 自社データに通じた答えを、自分の側で

立ててきたもの全ての上に、AI を乗せる。2-03 で有効化した pgvector が、ここで効く。まず Cohere のオープンウェイトのコーディングモデル North Mini Code を Ollama で手元に置き、データを外に出さない。RAG 用に汎用モデルと埋め込みを並べ、社内文書・コード・メールを pgvector に入れて出典つきで答えさせ、Open WebUI で使う。検索は門番を迂回しない。機密と常時処理は自前、難しい判断は最前線のモデルに借りる ── 主導権は自分、能力は借りる。Copilot から離れ、自立編を締める。

2-17

AI に任せる範囲を決める ── 自律で動かさず、コードに凍結する — 提案は AI、実行は人が通す。繰り返す仕事は、コードとコマンドに凍結する

自前の AI を据えたら、次に決まるのは運用だ。エージェントを自律で動かさない ── 誤りが連鎖する、責任の所在が消える、検証が届かなくなる、外のデータが指示に化ける。自律で回してよいのは四条件が揃うときだけだ。Office に AI を入れる道は、判断のハードルが最も低く、影響範囲が最も広く、能力侵食が最も深い。AI はサンドボックスの中で使い、渡す物は人が選ぶ。繰り返す仕事は Python と Linux のコマンドに凍結する ── AI は生成器であって、動作環境ではない。費用は、毎回の利用料から、最初の一回だけになる。

転換編 ── なぜ産業構造が変わるのか

3-01

企業は自分でコードを書かない ── 事務と基幹、二つの世界の並立 — 自前で書くのは非効率だった ── だから事務は買い、基幹は外注し、二つの世界が並立した

企業は自分でコードを書いてこなかった ── そしてそれは合理的だった。自前開発は非効率で、一社では抱えきれない大人数の専門人員を要したからだ。だから汎用の事務はパッケージで買い(Microsoft)、固有の基幹は外注した(SIer)── 別々にロックインされた、二つの並立する世界だ。両者は薄い継ぎ目(認証と文書共有)だけで繋がっていた。この並立が、長らく効率的な均衡だった。AI はその効率を反転させる。一人+AI が、同じ OSS の土台の上に二つの世界をまとめて立てるからだ。前提が消え、二つのベンダー構造は同時に崩れる。本章は転換編の前提を据える。

3-02

物語を確かめる ── ベンダーの語りを一次情報で検算する — AI も語りに引かれる。だから、確かめ方のほうを設計する

ベンダーの語りは、そのままでは判断の材料にならない。一次情報で検算してから使う。この章は、その手順を置く。AI 自身も語りに引かれる ── 訓練データは英語と大企業の公式文書に厚く、権威と多数派に重みが寄る。しかも AI が学ぶ情報源(GitHub、npm、LinkedIn、技術ブログ)を所有するのは、語る当事者でもある。だから確かめ方を設計する ── 手法の違う AI を組み合わせ、複数のベンダーに当たり、批判的な仮説を立て、最後は一次情報に当たる。事例は四つ。WordPress、Node.js、Linux ディストリビューション、Microsoft のネイティブアプリ回帰である。Gemini Pro が EF Core の AOT 対応を「ほぼ完璧」と要約し、Microsoft 公式が "recommend against" と書いていた対比も置く。Debian のガバナンス検証は、2-02 が Debian を土台に据える根拠そのものだ。転換編の 3-03 と 3-04 の結論は、この手順で得たものである。

3-03

デジタル主権 ── Microsoft 問題と Trump 問題 — OSS とソブリン AI のほうが、いまや経済でも安全保障でも有利になった

つい最近まで、Microsoft 365 は経済的でも安全でもある既定値だった ── だからこそ誰もが買った。その前提が反転した。OSS + ソブリン(自己ホスト・ローカル重み)AI のほうが、いまやコストでも安全保障でも有利だ。Microsoft 問題 ── 上がり続ける人数課金、CLOUD Act の下にある米国企業のクラウド上のデータ、不透明なテレメトリ、Copilot を経由して Microsoft のモデルに流れる内容。便利さこそが依存だ。Trump 問題 ── 米国ビッグテックに依存することは米国政府の善意に依存することであり、トランプ政権はその依存を武器化しないと信頼できない(制裁・遮断)。だから Microsoft から離れることは、もはやイデオロギーではない ── 新しい経済かつ安全保障の合理だ。転換編の事務(Microsoft)側の前提を据える。

3-04

SIer委託モデルの構造的不経済 — 外注しても残る上流の判断と、委託が生む無責任化・空洞化 ── 同じ手間で、自分で作れる

外注しても、上流の判断 ── 事務処理そのものの改善とシステムの理解 ── は顧客に残る。それは直線ではなくループで、AI を使えば社内で高速に回せる。SIer にループは回せない。一周ごとに予算の承認と契約が要り、普通は年単位になるからだ。そして委託の最も深い問題は、責任と技術の空洞化だ ── 任せた瞬間、誰も結果の全体を引き受けなくなる。その最も高価な実例が GitHub Copilot であり、失敗の責任は CEO にある。同じ手間で、自分で作れる。SIer 委託モデルの消滅は必然だ。

3-05

ロックイン問題 — 独自フレーム・独自抽象層・人的依存 ── Palantir FDE を典型例として

ロックインとは、移行コストが高くて動けない状態だ。SIer 委託モデルは三つの層 ── 独自フレームワーク、独自抽象層と Ontology、人的依存 ── で顧客を固定する。Palantir の FDE モデルはその極致で、三層すべてを最大化することで数十億円規模のプレミアム価格を成立させている。対して AI ネイティブ開発は、AI が標準ライブラリと標準形式を選ぶ性質から、構造的にロックインを生みにくい。別の AI、別のビルダー、顧客自身が引き継げる。さらに、ベンダー AI と Microsoft の後方互換性という、もう一つのロックインも扱う。

3-06

各社がビルダーを雇用する時代 — 上級ビルダーは経営陣 ── CIO(最高情報責任者)の位置へ、責任は今より重くなる

専門職の仕事(弁護士・医師レベルの判断を含む)は AI がする。だから人間の上級ビルダーは判断を売る専門職ではなく、経営判断を下す経営陣 ── CIO(最高情報責任者)に位置づく。IT 判断=業務判断=経営判断であり、IT が業務の中核になるぶん、責任は今の CIO より重い。一般社員の枠では処遇できない。コーポレートサイトの内製化を例に、コストと構造の両方の変化を示す。さらに、ビルダーの供給源がコーダー出身者だけではないことを示す。

3-07

日本の SIer 業界の転換と雇用流動性 — 多重下請け構造は、逆説的に転換を容易にする

日本の SIer の多重下請け構造は転換を阻害すると思われがちだが、構造を解剖すると逆になる。コーダー需要を契約で外部化している構造は、雇用調整を伴わずに縮小できる。元請けは下請け契約の非更新で対応でき、下請けの優秀な人材は元請け・顧客企業・独立に流れる。雇用流動性は時間とともに高まる方向にあり、長期業務委託・出向・社内ベンチャーといった中間形態が緩衝として効く。同じ数年で、AI 物理インフラ・製造業リショアリング・自然農法シフトが業界外の労働需要を開く。

3-08

AI 革命は下から起きる — 上からの導入は必ず失敗する。回線と月 100 ドル台で始められる所から始まる

AI 革命は、経営の決定でも大きな予算でも始まらない。始まるのは、稟議なしでできる所からだ。中小企業、個人事業主、大企業の裁量のある部署、大企業の周辺部。要るのはインターネットの回線と、月 100 ドルの利用料だけ。上から入れると、情シスと SIer を通り、人を減らす話になり、現場は隠れて使い、会社には何も残らない。下から始めれば、六つが残る。コード、業務の知識が言葉になった物、答え合わせの仕組み、詰まった所と直し方の記録、作れる人、データ。経営者には細かな問題を見る時間が無く、AI が解けるのはその細かな問題だ。だから AI は現場が持つ。中心が持てば監視と検閲に使い、下が持てば問題が解ける。始まる場所が無数にあり、止める手が無い。

3-09

もう戻らない構造転換 — 変化は連鎖し、主要な部分は近い将来に起きる。前提が逆転したから、戻らない

AI が実行能力で人間トップに到達したところから、コーダーの消滅、ビルダーの出現、顧客の内製、SIer 委託モデルの縮小までが連鎖する。主要な部分は近い将来に起きる。そして経済と安全保障の前提がすでに逆転した以上、動いた構造は元に戻らない。ただし完全置換が起きるのは、ルールが明確で、正解が機械で検証できる領域 ── ソフトウェア開発の中のコーディング ── に限られる。デスクワーク、自動運転、ロボットは最後の 1% で詰まり、完全置換には至らない。そこは生産性向上の話だ。そのうえでこの転換は、第二次ルネサンスの一断面である。

方向性の決定は人間、実現はAI。
実現力の上限は上がった。方向性を決める仕事は、むしろ重くなった。

第1回から読み始める

まずは「Fable 5 とは何か、何が得意か」から。得意でないことも、そこで分かる。