Microsoft と Google を、
自前の道具に解く。

Microsoft 365 と Google Workspace の問題は、中身が閉じていること、そして鍵(認証)が一社の手元に集中していることだ。束は、その二つを全層に広げる増幅器である。

導入編で、組み込みのロジックを Python に外部化し、基幹ロジックを書けるようにした。自立編は、その手元の力を会社全体の土台に広げる。認証・文書・共有・メール・会議・Web・データ・AI が一社に束ねられた SaaS スイートを、契約から解いて、自分の側に置き直す。ここからは「コードを書く」ではなく「基盤を立てる」段になる。

やることは一つだ。閉じた束を、開いた道具に解いて、鍵を自分の手元に移す。その「開かせる」力が AI である。Office スイートも、業務システムも、同じやり方で開く。この章は地図だ。各層が何にどう対応し、どの章で立てるかを、最初に一望する。

ロックインの正体は、閉じていることと、他人の鍵だ

Microsoft 365 が便利なのは、ログイン(Entra ID)が文書(Office)に、文書が共有(SharePoint)に、共有がメール(Exchange)に、そして全部に AI(Copilot)が、同じアカウントで一直線に繋がっているからだ。

Google Workspace も同じ構造である。Google ID が Gmail に、Drive に、Meet に、Gemini に一直線に繋がる。名前が違うだけで、束ね方は同じだ。一つのアカウントで、文書も、メールも、会議も、AI も、すべてが一社の中で連結している。

ここで正確に切り分ける。束ねること自体は、罪ではない。道具は繋がっているから仕事になるのであり、この自立編が立てるスタックも、認証を一つの門に集め、道具同士を継いで使う。束が危険になるのは、束の中身が次の二つの性質を持つときだ。

第一に、閉じている。書式は独自形式、コードは読めず、データは向こうのクラウドにある。中で何が起きているかを検証できず、丸ごと持ち出すこともできない。開いた束なら、いつでも解ける。閉じた束は、出口が塞がれている。

第二に、鍵が他人の手元にある。全層が Entra ID や Google ID という一つの門にぶら下がる。文書に触るにも、メールを読むにも、まず他人の門を通る。鍵を握る者は、価格も、ポリシーも、アカウントの生殺与奪も握る。

この構造は、Office スイートだけのものではない。業務システム(基幹)も、同じ立ち方をしている。コードは読めず、仕様は文書化されていない。これが閉である。仕組みの理解と保守は SIer の手元にある。これが他人の鍵だ。会社の情報基盤は、事務と基幹の両側で、閉じたものが他人の鍵にぶら下がってきた。

そして束は、この二つを全層に増幅する。

• 値上げは全層まとめて効く。逃げ場が無い
• データポリシーの変更は全層まとめて効く
• 一社の障害は全層まとめて止まる。単一障害点が、全層に一つだけになる
• 門を閉じられれば、全層から同時に締め出される
• ベンダー AI(Copilot / Gemini)の判断基準は全層に浸透する

だから解き方も決まる。各層を開いた道具に分け、鍵を自分の手元に移す。開いていれば検証でき、持ち出せる。鍵が手元にあれば、締め出されない。そして解けた束は、一本ずつ置き換えられて、一本が倒れても他は動く。これは一人 + AI と同じ形で、自立した N は集中した 1 より強い、の会社版である。

閉じたものを開かせる ── それが AI の役割だ

なぜ、いまになって解けるのか。閉が防壁として機能してきたのは、開くコストが人間には高すぎたからだ。独自形式を解析する。読めないコードを読み解く。文書化されていない業務の仕組みを復元する。どれも数年・数億円の仕事だった。だから「動いているものに触るな」が正解であり続けた。

AI は、まさにこのコストを潰す。

• 独自形式を開く。Office / Docs の書式は、読む物は adoc、触る表は格子、刷る紙はテンプレートに分けて扱い(2-07)、埋め込まれたマクロやロジックは AI が Python に外部化する(導入編・2-04)
• 読めないコードを開く。レガシー基幹のコード・SQL・手順書を、ローカル LLM が読み解いて、Markdown の業務知識に取り出す(2-12・2-16)
• 閉じ込められた知識を開く。紙・画像・属人知を、OCR と対話で構造化された情報に変える(2-15)

Office スイートも、業務システムも、同じ「閉じた束が他人の鍵にぶら下がる」構造で立っている。AI は、その両方の閉を同じ操作で開く。読む・抽出する・翻訳する。AI が最も得意な操作は、そのまま開錠の操作である。

鍵も同じだ。これまで鍵を自分の手元に移せなかったのは、門番(認証基盤)を自前で立てて運用する力が、普通の会社に無かったからだ。その運用も、AI が相棒になった(後述「一人 + AI」)。閉を開く力と、鍵を持つ力。二つとも、AI が自分の手に戻した。だから自立編は、いま書ける。

ベンダーは自分からは開かない ── だから、開いた道具を AI で育てる

もし Microsoft と Google が、スイートを開いた部品に分けて提供してくれたら、会社の IT は一気に簡単になる。書式を開き、鍵を返し、層ごとに差し替え可能にしてくれればいい。SIer が納品物を、読めるコードと文書で開いてくれても同じだ。

だが、それは起きない。閉じていることと、鍵を握っていることが、商売の本体だからだ。開くことは、自らの堀を埋めることと同義になる(ロックインが商品そのものである構造は 3-05 で詳述)。ベンダーの善意を待つ道は、構造的に閉じている。

だから、進む道は逆側にある。開いた道具を、AI の速度で育てる。AI の役割は「閉じたものを開かせる」だけではない。開いたものを育てるときにこそ、最も速く回る。OSS はコードも仕様も開いているから、あなたの連れてきた AI がそのまま開発者になれる。足りない機能は AI と書き足し、自社の業務に合わない癖は AI と直す。かつて OSS の弱点だった「痒いところは自分で書くしかない」は、AI が相棒になった瞬間、一番速い改善経路に変わった。

閉じた道具では、この経路が塞がっている。あなたが AI を連れて行っても、中身に触れない。要望を出して、ベンダーのロードマップを待つだけだ。開いた道具と閉じた道具の差は、AI の登場で縮まったのではない。AI の速度で、これから開き続ける。

ベンダーが開くのを待つ必要はない。開いた道具を、AI の速度で育てればいい。

AI は、束の中の一機能ではなく、独立したインフラだ

現実は、むしろ逆方向に動いている。ベンダーは AI を、開く道具としてではなく束を締め直す道具として組み込んでいる。ベンダー AI は束の最上層に座り、閉じた各層を AI ごしに縫い合わせ、解く理由をまた一つ消しにかかる。そして既存の IT 関係者の多くも、同じ方向に流れる。使い慣れた閉じたスタックの上にベンダー AI を載せる提案が、いちばん摩擦が少ないからだ。開く方向は、内側からは出てこない。

この動きの筋の悪さは、革命の見立てを一つ正すと、はっきり見える。AI はよく産業革命、つまり機械が労働を置き換えた話にたとえられる。だが、AI をどこに置くかを考えるときの正しい先例は、活版印刷と同じ「情報革命」のほうだ。活版印刷は、写本という既存の仕組みに足された便利な機能ではなかった。文字を扱う新しいインフラとして独立に立ち、既存の情報の流れのほうが、その上で組み直された。写本工房の隅に印刷機を据えて「写本が速くなった」と呼んだ者はいない。OS も Office スイートも、情報を置いて動かすインフラだ。そして AI は、情報を読み、変換し、作る別のインフラである。ベンダーの組み込み AI とは、別のインフラを既存インフラの一機能として埋め込むことだ。新しいインフラを、旧いインフラの付属品に格下げしている。独立したインフラは、独立に立てて、どの道具からも使えるようにする。自立編が AI を束の中ではなく外に、それも最後に(2-16)据えるのは、この見立ての帰結だ。

見立てには、続きがある。活版印刷にも前段があった。紙が普及し、写本が数世紀かけて文字を蓄えた。印刷機が爆発させたのは、その蓄積だ。同じ関係で、「IT 革命」と呼ばれた数十年は、AI 革命の前段だった(1-01 の「成就」を、AI 革命の側から言い直した読み方だ)。そして前段が遺した最大の資産は、閉じたスイートではなく、OSS という開いたコードと知識の共有財のほうだ。新しいインフラは、この開いた蓄積の上でこそ最も速く回る。だから「開いた道具を AI の速度で育てる」は、迂回路ではなく本流である。そう見れば、IT 業界が AI に与えている扱い、つまり写本工房の隅に印刷機を据えることも説明がつく。前段の担い手が、次の革命を自分の工房の一角に収めようとする、いつもの反応にすぎない。

土台に据えてから、差分だけを AI と書く

同じ見立てから、もう一つの無駄遣いも名指しできる。何もないところから、AI にその場その場でコードを書かせて積み上げるやり方だ。ライブコーディングだけでは、世の中の平均的なソフトウェアを、高い計算資源で再発明することにしかならない。AI の出力は、渡す構造が薄いほど平均に収束する。

積み上がる使い方は一つだ。実績ある開いた道具を土台に据え、足りない差分だけを AI と書く(1-05 の OSS ファースト)。インフラとして独立に立てた AI は、独立に立てた道具の上でこそ速く回る。この章の対応表が、その土台の一覧になる。

対応表 ── Microsoft と Google を、独立した OSS に解く

束を解くと、Microsoft 365 と Google Workspace の各層は、同じ独立した OSS に着地する。左の二列を、同じ右に置き換える。

表の右端に一つだけ、OSS でない行がある。Web を公開する側(2-11)の Cloudflare Pages だ。これは借りる窓で、自分で持つ道具ではない。同じ章で、2-02 の一台に Caddy を立てて自分の側で公開する道も置いてある。借りる所と自分で持つ所を、分けて決める ── それが 2-11 の中身だ。

表に出てこない章もある。2-14(電子工作から IoT)、2-15(情報の整備)、2-17(AI に任せる範囲)の三つで、どれもスイートに対応する層が無い。だが自立編の一部であり、解く順番には入る。

一番上の行が、新しく入った層である。会社の PC を一台 Debian にして AI に渡す。以降の道具は、この一台の上に立てる(自前の LLM だけは別のサーバー)。文書の層は、道具を一つ立てるのではなく、持ち方を決める。読む物は adoc で git に、触る表は格子のまま、刷る紙はテンプレートに値を流す。2-07 が受け持つ。

右側の道具は、別々の組織が作った、別々の開いた道具だ。中が読めて、形式が開いていて、データはどこへでも持ち出せる。だから、一本の方針変更が他に波及せず、一本を別のものに差し替えても、残りは何も変わらない。開いていて、鍵が自分の手元にある。これが核心で、束が解けているのはその帰結だ。

この章は地図だ。構築の手順は書かない。各層の入れ方や設定や移行は、それぞれの章にある。ここでは、どの層がどこに対応し、どの順で解けるかだけを押さえる。Microsoft でも Google でも、置き換わる先は同じだ。だから、どちらのスイートに縛られていても、進む道は一本に合流する。そして、各章が固定するのは方式であって、コマンドの網羅ではない。手順の細部は、作業のたびに AI に聞けばよい。Gmail や Google Drive 側の記述が薄く見えるのも同じ理由で、方式が同じなら、細部は AI が埋める。手順書を厚くすることこそ、旧常識である。

変わるのはコストではなく、主導権だ

自前に解くと、月額の構造が変わる。Microsoft 365 も Google Workspace も人数 × 月額である。公開価格でいうと、Microsoft 365 Business は一人あたり月 1,049 円(Basic)から 3,298 円(Premium)── 2026 年 7 月の改定後、税抜・年払いの月額換算だ。Google Workspace Business Standard は一人あたり月 1,600 円(年払い)で、Gemini は 2025 年 3 月から Business 以上に標準で入っている。Microsoft 側は Copilot が別売りで上に乗る。どれも、人が増えるほど線形に増える。

自前の道具一式は、サーバー一台分の固定費だ。2-02 の一台なら、電気代と回線で済む。人が増えても、ほぼ増えない。

しかし本質はコストではない。本質は、開いていて、鍵が自分の手元にあることだ。

• 入口(認証)の生殺与奪を、他人に握られない
• 一社が値上げしても、その一層だけ差し替えればいい
• 一社が障害を起こしても、他の層は動き続ける
• 一社がデータポリシーを変えても、影響はその層に閉じる
• AI の判断基準を、会社が選べる

束のままでは、この五つがどれも効かない。一層だけ替えたいと思っても、全層まとめて移行するしかなく、それは事実上できない。解けていれば、その一本だけを差し替えて、他は無傷で残る。

解く順番は、機械から始まる

一気にやらなくていい。束から外しやすい順に、一本ずつ進める。自立編は、その順番でそのまま章立ててある。

1. 機械(2-02)。会社の PC を一台 Debian にして、AI に渡す。以降の道具は、この一台の上に立てる(自前の LLM だけは別のサーバー)
2. データ基盤(2-03)。PostgreSQL・SQLite・DuckDB。分析も RAG も予約も基幹も、すべてこの上に乗る。だから最初に据える
3. 処理(2-04)。Python と Flet。Excel と Word に埋まったマクロとグラフを外に出し、画面が要るところに被せる
4. 認証(2-05)。PocketBase。全アプリ共通の門番。ここを自分の側に移すと、束の根が切れる
5. 共有と版管理(2-06)。Forgejo + Zed。SharePoint / Drive を畳む
6. 文書(2-07)。読む物は adoc の文字、触る表は格子、刷る紙はテンプレート。Office / Docs 形式は入口と出口で通過させる
7. メール(2-08)。Stalwart。通信の中身を手元に置く
8. 会議・カレンダー(2-09)。Jitsi・Radicale。会議と予定の共有を自前で。予約の受付は 2-12 で書く
9. Web を作る(2-10)。中身は AsciiDoc、外枠は HTML と CSS、繋ぐのは Python
10. Web を公開する(2-11)。自分の一台(Caddy)か Cloudflare Pages。借りる所と自分で持つ所を分ける
11. 基幹ロジック(2-12)。FastAPI。Power Apps / Apps Script を読めるコードに戻す
12. 図と資料(2-13)。Mermaid・Marp・CAD。図もスライドも筐体も、文字とコードから作る
13. 電子工作から IoT(2-14)。要る現場だけ。基板は Python で考え、受け口は FastAPI、保存は 2-03
14. 情報の整備(2-15)。OCR・分類・属人知の成文化。AI に載せる前に、載せるに値する情報を作る。整備こそ本体、AI は最後の一手
15. AI(2-16)。ローカル LLM + RAG。データを社外に出さず AI を持つ
16. AI に任せる範囲を決める(2-17)。自律で動かさず、決まったことはコードに凍結する

各ステップは、2-12 の並行稼働で進める。旧(Microsoft / Google)を止めず、横で新を動かし、同じ仕事が回ることを確かめてから、旧を解約する。契約更新の時期に間に合わせる。これも 2-12 どおりだ。一気に乗り換える必要はない。解けた分だけ、束が緩む。

運用は、一人 + AI で回る

ここで当然の疑問が出る。これだけ自前で抱えて、誰が面倒を見るのか。答えは一人 + AI だ。「一人 + AI」という新しい仕事の単位が、そのまま会社のインフラ運用に効く。

なぜ一人で回るのか。理由は三つある。

• どれも標準的なオープンな道具だ。Debian の apt か公式の単体ファイル一つで入り、systemd で動く。Docker は使わない(理由は 2-02)。AI が設定を書き、DNS と DKIM を整え、ログを読み、不調を切り分ける。運用の相棒が AI である
• 束が解けているから、障害が連鎖しない。スイートなら一社の不調が全部を巻き込むが、ここでは Forgejo が落ちてもメールは生き、AI が止まっても会議は続く。一個ずつ、独立に直せる
• 見える・読める・テストできる。設定もログも自分の手元にある。ブラックボックスのベンダー AI と違い、AI と一緒に中を読んで直せる

正直に、重いところも書く。運用負荷が集中するのは二つ、メールと講座(BigBlueButton)だ。メールは配送(DKIM / SPF / 評判)が繊細なので、送信だけ外部リレーに逃がす手もある。講座サーバーは重いので、講座の期間だけ立てて、終わったら畳む。残りは、立てたらほぼ放っておける。そして「残りの運用」、つまりバックアップ・監視・更新・障害を、旧来の運用手順書の常識で書く必要はない。ここでも前提が変わっている。

守るのは、データと仕様だけだ。実装と環境は、仕様と OSS から AI がいつでも立て直せる(2-12)。だから複製するのは、再生成できないものだけでいい。データベース・ファイル・メール・リポジトリ・業務ルールの Markdown を、毎日、別の箱へ(2-02)。それだけだ。復旧の試験も、儀式ではない。「まっさらな箱に、仕様とバックアップから全部立て直して」と AI に頼めば、それがそのまま復旧試験になる。

監視は、読めるログがあれば足りる。監視基盤を別に立てるのは旧常識だ。ログは全部手元にあり、死活確認と通知は AI が書く数十行で済み、ログの異常は AI に読ませる。更新も、意図した操作として行う。版を上げるときはリリースノートを AI に読ませ、2-12 の並行稼働の要領で横で確かめてから切り替える。勝手に上がるのではなく、上げる。秘密(パスワード・鍵)は環境ファイルに分離して、箱の外に出さない。これだけは一行の決まりとして最初に書いておく。

可用性は、冗長化ではなく、再構築の速さで受ける。箱が壊れたら、予備の箱に仕様とバックアップから立て直す。復旧が AI の速度なら、クラスタは要らない。1台に集中してよいのは、箱が使い捨てで、資産(データと仕様)が複製されているからだ。

箱そのもの、つまり会社の PC を一台 Debian にして AI に渡すところは、2-02 が受け持つ。その床にあたる OS の入れ方・SSH・守りの基本・データを守るは、「Claudeと一緒に学ぶDebian サーバー編」がそのまま仕様になる。ここでも、汎用は参照で済む。

ここで一人 + AI が成り立つ。縦割りの情報システム部門は要らない。業務を分かっている一人が、AI を相棒に、認証からメール、会議、AI、データベースまでを横断して持つ。個人の自立が、会社のインフラのレベルで成立する。これだけのオープンな道具を、一人 + AI が運用する。スイートを一社に預けるのと、手間は変わらない。主導権だけが、自分の側に移る。

この土台は、そのまま基幹システムの土台になる

ここまで組んだものは、そのまま基幹システムを書き換える土台になる。2-12「API を作る」で説く並行稼働の書き換えは、実は立つ場所(プラットフォーム)を前提にしていた。その場所が、自立編で全部そろう。

• 新しい基幹システムが動く DB。PostgreSQL + pgvector(2-03)
• 実行系。FastAPI / Python + Rust 下層(2-12)
• 版管理と CI。Forgejo(2-06)
• 認証。PocketBase が、新システムのログインを一手に引き受ける(2-05)
• 業務ロジックの抽出。レガシーのコード・SQL・手順書を、ローカル LLM + RAG(2-16)で読み解いて Markdown に出す。ソースを一歩も社外に出さずに

そもそも、これまで基幹システムと Microsoft / Google が共有していたのは、たった二つだけだった。認証(Entra ID / Google ID)と、文書共有(SharePoint / Drive)である。業務システムの世界とオフィスの世界は本来ほとんど別物で、この二つの継ぎ目だけで繋がっていた。

その二つは、自立編で PocketBase と Forgejo に置き換える。つまり継ぎ目は、もう自分の側にある。新しい基幹システムは、オフィス系と同じ PocketBase で認証し、同じ Forgejo で文書と版を共有する。ベンダーを介さずに、二つの世界が再び一点で出会う。

二つの継ぎ目は、同じ重さではない。共有は「置き場所」、認証は「鍵」だ。文書の置き場所は後からいくらでも動かせる。だが認証は、両方の世界のすべてのアプリ・ログイン・権限がぶら下がる一点である。ここを握られている限り、何を自前にしても入口は他人のものだ。

だから、自立編で本当に効く一手は、認証 → PocketBase(2-05)だ。識別の継ぎ目を自分の側に移した瞬間、基幹もオフィスも自分の門番に対して認証する。Microsoft も Google も最も深く食い込ませようとするのは、ここである。ID 基盤こそ、束の根だからだ。ここを押さえれば、残りは時間の問題になる。

念のため言えば、PocketBase もまた、認証を一点に集める。集中そのものは消せない。全アプリが同じ門を使うから便利なのであり、それは自前でも変わらない。違いは二つだけだ。鍵が自分の手元にあること。そして開いているから、いつでも差し替えられること。冒頭の解剖に戻れば、集中が問題なのではない。閉じた集中が、他人の手元にあることが問題だったのだ。

AI ネイティブの時代には、作り直しが当然になる

最後に、一段引いて見る。Microsoft や Google のスイートを書き換えるのは、特別な決断ではない。AI ネイティブの時代には、作り直しのほうが当然になる。

理由は二つが噛み合っている。

一つ目。スイートの作りは、構造的に「反 AI ネイティブ」だ。中身を Office / Docs の書式に閉じ込め、データをクラウドに幽閉し、ベンダー AI を検証層なしで業務に直結する。これらは偶然ではない。AI が触れる場所、つまり素のテキスト・開いた形式・手元実行・読めるコードから、中身を遠ざける設計である。AI を同僚にしようとするほど、この壁にぶつかる。

二つ目。書き換えのコストが、桁で下がった(2-12)。AI が業務ロジックを抽出し、Python に翻訳し、テストを書く。かつて年単位でしか考えられなかった書き換えが、現場の一人 + AI で回る規模になった。

古い構造が AI ネイティブと噛み合わず、しかも作り直しが安い。この二つが重なれば、結論は一つだ。残すほうが不自然になる。かつて「動いているものに触るな」が正解だったのは、書き換えが高すぎたからにすぎない。その前提が消えた今、作り直さない理由のほうが、説明を要する。

これは Microsoft や Google への敵意ではない。IT 革命が積み上げたものを、AI 革命が作り直して引き継ぐ。その自然な一巡だ(導入編)。問われているのは「やるか」ではなく「いつ、誰が主導でやるか」。ベンダーに預けたままにするか、自分の側で作り直すか。それだけだ。

この解き方は、公開リポジトリで確かめられる

この解き方を道具一式にしたのが、公開リポジトリ aiseed-migration-kit(aiseed-dev/aiseed-migration-kit)だ。公開 Web の静的化(取り込み → 分類 → Markdown 化 → 生成 → 配信)と、問い合わせの様式方式(Web フォームを作らず、xlsx 様式とメール受付で機械可読に受ける)を、CLI 一式と設計書で持つ。設計書(DESIGN.md)には本章の対応表が、認証・境界・配置の理由づけごと書いてある。読んでから、自分の組織に当てはめられる。文書側の参考実装は kura(2-07)、業務システム側の実例は seminar-kit(2-12)。章で言葉にした設計は、どれもコードで確かめられる。

確かめ方

この章は、次の四つができていれば済みだ。手を動かすのは紙か画面の上だけで、サーバーはまだ立てない。

1. 自分の会社がいま使っている道具を、対応表の左の二列に書き出せている。機械・認証・文書・共有・メール・会議・Web・データ・基幹・AI の各層について、Microsoft 365 側か Google Workspace 側かを埋める
2. その一行ずつに、右の列(自前の OSS)と、立てる章の番号を書けている。使っていない層は、空のまま残してよい
3. 層ごとの契約更新日を書き出せている。並行稼働は、この日付に間に合わせる
4. 解く順番を、先頭から順に自分の言葉で並べられている。先頭は機械(2-02)で、そこから先は自分の会社の事情で入れ替えてよい

この章で動かすものは無い。確かめるコマンドも無い。表が一枚できていれば、次の章に進める。

人が持つ物

人が渡す値

• いま契約している SaaS の一覧。Microsoft 365 か Google Workspace か、そのうちどの層を実際に使っているか
• 層ごとの契約更新日と、一人あたりの月額
• 解く順番の決定。どの層から手を付けるかは、会社の事情で人が決める

AI が「やる前に言う」操作

• 旧スイートの解約。並行稼働で同じ仕事が回ることを確かめる前に、解約してはいけない
• 旧スイートからのデータの書き出しと、書き出し元の削除。消す側は、写しが手元で開けることを確かめてからにする

確かめた版と日付

• この章で版を決める道具は無い。対応表に載るのは製品名だけで、版はそれぞれを立てる章で決める。PocketBase、Forgejo、Zed、Stalwart、Jitsi、Radicale、Cloudflare Pages、PostgreSQL、SQLite、DuckDB、Polars、FastAPI、ローカル LLM
• 手順を書いたのは 2026.07.01
• 版が上がっていたら、AI に公式の手順を確かめさせてから進める

まとめ

ビジネス用の Microsoft 365 と Google Workspace は、閉じた層を一社に束ね、その全部を一つの鍵(認証)にぶら下げた SaaS スイートだ。業務システムも、同じ構造で立ってきた。危険なのは束ねられていることではない。閉じた束が、他人の鍵にぶら下がっていることだ。そして、その閉を開かせることが AI の役割である。自立編は、AI と一緒にこの束を一層ずつ開いた OSS に解き、鍵を自分の手元に移す。二つのスイートが、同じ右側に着地する。

• 機械:ベンダーのクラウド → Debian の PC 一台(2-02)
• 認証:Entra ID / Google ID → PocketBase(2-05)
• 文書:Office / Docs → adoc + git、格子、テンプレート(2-07)
• 共有・版管理:SharePoint+GitHub / Drive → Forgejo + Zed(2-06)
• メール:Exchange / Gmail → Stalwart(2-08)
• 会議・カレンダー:Teams / Meet → Jitsi・Radicale(2-09)。予約の受付は 2-12
• Web を作る:Power Pages / Sites → AsciiDoc + HTML・CSS を Python で焼く(2-10)
• Web を公開する:Power Pages / Sites → 自分の一台(Caddy)か Cloudflare Pages(2-11)
• データ基盤:Azure SQL / Cloud SQL → PostgreSQL・SQLite(2-03)
• データ分析:Power BI / Looker → DuckDB + Polars(2-03)
• 処理:Excel マクロ / VBA → Python(画面は Flet)(2-04)
• 基幹ロジック:Power Apps → FastAPI(2-12)
• 図と資料:Visio / Drawings → Mermaid・Marp・CAD(2-13)
• AI:Copilot / Gemini → ローカル LLM + RAG、別のサーバーに(2-16)

一対一で、左を右に置き換える。右の道具は別々の組織が作った別々の開いた道具だから、中が読めて、持ち出せて、一本の方針変更が他に波及しない。これは効率化の話ではない。一人 + AI を、会社の土台の高さで言い直したものだ。集中した 1 より、自立した N が強い。

閉じた束を、開いた道具に解く。鍵を、自分の手元に。開かせる力(AI)は、もう手元にある。一本ずつ、自分のペースで。解けた分だけ、会社はベンダーの人質ではなくなり、自分たちの判断で動けるようになる。次の章では、その一本目を立てる。会社の PC を一台 Debian にして、AI に渡す。以降のすべては、その一台の上に乗る。

関連記事

• 2-02: AI に PC を一台渡す ── 自立編を動かす機械
• 2-03: 土台を据える ── SQLite・PostgreSQL・pgvector・DuckDB・Polars
• 2-07: 文書を取り戻す
• 2-12: API を作る ── FastAPI で基幹のロジックを出す
• 構造分析08: 企業ITの税を引く
• それでも Windows と Office を使い続けますか?