Structural Analysis

AIネイティブな仕事の作法 — ソフトウェア開発編

ソフトウェア工学から、リベラルアーツへ ── 技術職の基盤転換

導入編 ── なぜ作り、どう始めるか

01

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

AI のコード作成能力は、競技プログラミングの公開レーティング(Codeforces 2700 帯)で人間トップクラスに並んだ。さらに、自律的にサイバー攻撃を組み立てられること ── これは設計能力の証拠だ。Mythos/Fable 時代になって、AI は要件から設計・実装までこなす「最強の SIer」になり、しかも月 3 万円で誰でも呼べる。この事実から、ソフトウェア開発編の議論が始まる。

02

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

AIがコードを書くようになったことの最も見落とされやすい帰結は、コーディングの高速化ではなく保守フェーズそのものの構造変化だ。AIが文脈を理解するから、コードでの保守そのものが要らなくなり、保守の単位はコードから設計・仕様・文脈に移る。レガシーコード読解のコストは消える。ただし設計・仕様・文脈を明示に保ち、現実とすり合わせ続けることが条件で、それを失うと AI 生成の技術的負債が急速に積み上がる。

03

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

コーダー(コードを書く役割)は当然消える。だが本章の主題はその先 ── 設計までするソフトウェアエンジニアの仕事も、AI がするようになる。Opus はコーダー、Fable/Mythos はソフトウェアエンジニアで、設計もコードも AI が担う。人間に残るのは、自分で設計しコードを書く仕事ではなく、AI と対話してシステムを作り動かす仕事 ── つまりビルダーだ。消えるのは役割定義であって、人ではない。

04

ビルダーという役割 — 何を作るかを決め、AIと対話して作り、動かし、全体を統合する

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

05

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

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

自立編 ── Microsoft 365・Copilot・WordPress・基幹システム・GitHub から自立する

01

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

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

02

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

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

03

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

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

04

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

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

05

文書を取り戻す ── OnlyOffice Docs を PocketBase に組み込む — Office は「通過させる」道具だ ── 中身を取り戻し、編集エンジンだけを門番に組み込む

Word・Excel・PowerPoint は、人が書き人が読む入出力の道具だ ── 中身を置く場所ではない。Office の中にいる限り AI は同僚にならず、自分は「処理する人」のまま。だから docx・xlsx・pptx は「使う」のではなく「通過させる」形式と捉え、中身の主導権を自分の側に取り戻す。Nextcloud のような別の保管アプリは足さず、文書はファイルのまま自分のストレージに置き、認証は2-03の PocketBase、権限(アクセス制御)は問い合わせられる構造化ストア(PostgreSQL か門番の PocketBase、依存最小なら xattr)に持たせ、OnlyOffice Docs を編集エンジンだけ組み込む ── 独自の、薄い文書アプリ。高互換の OOXML だから上司にも同僚にも `.docx` のまま渡せる。完成品の DocSpace は Active Directory を呼び戻すので使わない。実装は公開リポジトリ kura。形式は変えず、主導権だけ取り戻す。

06

メールを自分の側に ── Stalwart と Thunderbird — Exchange と Outlook の外へ ── 受信は自分で、送信は正直に

メールは事業の記録そのものだ。Stalwart は Rust 製の単一サーバで、SMTP・IMAP・JMAP・スパム対策・DKIM 署名を一つに備え、Exchange を置き換える。2-02の PostgreSQL に乗せ、Thunderbird など任意のクライアントで読む。ただし送信の到達性は難しい ── そこは認証付き中継に頼り、メールボックスの主導権だけ自分が持つ、という正直な設計を示す。

07

会議と予約を自分の側に ── Jitsi と Cal.com — Teams の会議も、Calendly の予約も、講座のウェビナーも ── 自分のドメインで

ビデオ会議は Jitsi、予約は Cal.com、講座・ウェビナーは BigBlueButton。Teams・Zoom・Calendly・Microsoft Bookings を、自分のドメインと自分のサーバに置き換える。予約は2-02の PostgreSQL に乗り、2-06のメールで確認を送る。人数・分課金から降り、会議のリンクも記録も自分の側に持つ。

08

Webを公開する ── Cloudflare Pages(WordPress 代替) — 動的な WordPress をやめ、静的サイトをサーバ無しで公開する ── ビルド・確認・デプロイを分けて

導入編で AI と作った静的サイトを、自分の側から公開する。動的な WordPress をやめ、焼いた HTML を Cloudflare Pages に置く ── サーバは持たない。CDN と自動 HTTPS は Cloudflare に任せ、ソースとビルドは自分の手元に残す。肝は「ビルド → 確認 → デプロイ」を分けること。確認した HTML と本番に上げる HTML を同じにする。内部の道具は門番の内側に残す ── 窓は借り、金庫は自分に。

09

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

「壊すな・触るな」はもう古い。AI で基幹システムの書き換えコストは 10 分の 1 になった。新しい AI ネイティブなシステムを FastAPI で作り、旧システムと並行稼働させ、出力を実測で突き合わせる。差分が消えたら旧を殺す。業務知識は一気に Markdown に出し、現場がテストを書き、委託は止める。新しいロジックは2-02の PostgreSQL を読み書きし、2-03の門番のトークンで本人確認する。参考実装は kura。

10

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

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

11

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

自立編の最後に、全ての上に AI を乗せる。2-02で有効化した pgvector が、ここで効く。まず Cohere のオープンウェイト・コーディングモデル North Mini Code を Ollama で手元に置き(データを外に出さない)、RAG 用に汎用モデルと埋め込みを並べる。社内文書・コード・メールを pgvector に埋め込んで RAG を組み、Open WebUI で使う。機密と常時処理は自前、難しい判断は Claude に借りる ── 主導権は自分、能力は借りる。Copilot 依存を断ち、汎用は OSS で立てる自立編を締める。

転換編 ── 産業構造の帰結

01

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

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

02

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

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

03

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

外注しても、上流の判断 ── 事務処理そのものの改善とシステムの理解 ── は顧客に残る。それは直線ではなくループで、AI を使えば社内で高速に回せる。そして委託の最も深い問題は、責任と技術の空洞化だ ── 任せた瞬間、誰も結果の全体を引き受けなくなる。同じ手間で、自分で作れる。

04

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

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

05

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

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

06

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

日本の SIer 多重下請け構造は転換を阻害すると思われがちだが、構造を解剖すると逆 ── コーダー需要を契約で外部化している構造は、雇用調整を伴わずに縮小できる。元請けは下請け契約解消で対応可能、下請けの優秀な人材は元請けや独立に流れる。雇用流動性は時間とともに高まる方向にあり、長期業務委託・出向・社内ベンチャーといった中間形態が緩衝として効く。

07

もう戻らない構造転換 — 変化の連鎖、近い将来という見通し、そして不可逆性 ── 前提が逆転したから、戻らない。ただしソフトウェア開発に限った話だ

AI 能力到達からコーダー消滅、ビルダー需要、SIer 縮小までの変化は連鎖して、近い将来に主要部分が起きる。そして、経済と安全保障の前提がすでに逆転した以上、動いた構造は元に戻らない。ただしこの「完全置換」が起きるのはソフトウェア開発のような検証可能な領域に限られ、デスクワーク・自動運転・ロボットのような領域では last 1% に阻まれて完全置換は起きない ── そこは生産性向上の話だ。本サブシリーズの執筆過程そのものが、その証拠でもある。

道具を AI 時代に合わせれば、自分は AI 時代の自由人になる。
浮いた時間は、文化・科学・現実に向かう。

第1章から読み始める

AI は、世界で最も難しいコーディング問題を解く