移行ツール aiseed-migration-kit

aiseed-migration-kit は、 組織のIT——公開Web・文書・メール・業務——を、 git・SQL・メール・OnlyOffice・静的公開という開いた土台へ移すためのツール一式です。 amig というコマンドが移行の各段階を支援します。ライセンスは AGPL-3.0。

現在の実装範囲は移行の入口にあたる公開Web(脱CMS: 静的化と Cloudflare Pages 配信)と 問い合わせ(申込様式+メール受付)です。業務システム・文書・メール側の設計は リポジトリの DESIGN.md に、実装例は seminar-kit にあります。

設計の考え方 — 三つの閉じた世界を、開かれた世界に

組織の情報環境は、三つの閉じた世界に分かれてきました。

• Microsoft 365 — 文書・メール・会議に加え、認証やデータの置き場所まで。席数課金の外部クラウド
• 業務システム — 基幹・業務パッケージ。独自形式・独自APIとベンダー保守契約
• CMS/スマートフォン — 市民・顧客との接点。CMSのライセンス・保守・脆弱性対応と、 アプリ開発・ストア審査の負担

それぞれが独自形式と契約で閉じているため、データは外に出しにくく、 世界の境界をまたぐたびに転記と受け渡しが生じます。業務の分断と属人化の正体です。 まず、それぞれの世界のどこが問題なのかを具体的に見ます。

三つの世界の、どこが問題か

Microsoft 365

認証の縛り

• 認証(Entra ID)が開発技術まで縛る — 組織の認証を Entra ID に置くと、 業務システムは Entra ID 統合が前提になり、C# / .NET・SQL Server という Microsoft の開発技術一式が事実上の指定になります。認証を通すために、 プログラミング言語やデータベースという本来自由なはずの技術選定まで 奪われる構図です。それでいて、その一式で作った業務システムと Microsoft 365(文書・メール・共有)との連携が良いわけではなく、 システムの境界には結局、手作業の転記が残ります。 認証を握られているため、個々の部品だけを別の道具に替えることもできません
• Windows でも Microsoft アカウントの強制が進む — Windows 11 の初期設定は 原則として Microsoft アカウントとインターネット接続が必須になり、 ローカルアカウントで済ませる回避手段は更新のたびに塞がれてきました。 そしてアカウント側に問題が起きると——パスワードと二段階認証の喪失、 不審と判定されたロック——PC へのサインインに支障が出るだけでなく、 Microsoft アカウントに保管された BitLocker 回復キーを取り出せず、 手元の PC の中のデータごと失うことがあります。組織の Entra ID と同じ 「認証を外部に預ける」構図が、個人の PC でも既定になっています

自動化の袋小路

• 安全なローカルの選択肢がない — Office の自動化には VBA・JavaScript(Office Scripts)・Python(Python in Excel)が用意されていますが、 ローカルの Office で動くのは VBA だけ。Office Scripts と Python in Excel は Microsoft 365 のクラウド側でしか実行されません。これは技術的な制約ではありません—— JavaScript をサンドボックスで安全にローカル実行する技術は、ブラウザが毎日 何十億台で実証しているとおり確立しています。ローカル版が提供されないのは 技術の限界ではなく、提供側の選択です。そして肝心の VBA にはサンドボックスがありません—— 文書に埋め込まれたコードが、利用者の権限そのままでファイル・ネットワーク・OS を 操作できます。「ファイルを開く=コードが実行される」経路と合わさって マクロウイルスの温床となり、いまや使用禁止の推奨対象です。しかも VBA や Power Automate で作られた自動化は、作った担当者にしか直せず監査もしにくい—— 属人化の温床でもあります。安全に自動化したければクラウドへ、という誘導が ここにも働いています(本キットの様式設計が 「外部の Python+サンドボックス内の JavaScript」なのは、この袋小路への回答です)

組み込みAIのリスク

• 内蔵された Copilot が新しい攻撃面になる — Copilot は利用者が読める 文書・メール全体を読みます。そのため、細工したメール1通で内部情報を外部へ 送り出させる攻撃が現実に成立しました (EchoLeak / CVE-2025-32711、 CVSS 9.3、ゼロクリック、2025年6月修正)。その後も Copilot の情報漏えい脆弱性は 継続的に見つかっています(2026年5〜6月にも CVE-2026-26129 / 26164 / 42824 など複数)。 「回答にリンクを出すな」と指示するだけで監査ログに痕跡を残さずファイルへ アクセスできた事例も報告されました。さらに、誤って「組織全体」に共有された ファイルを Copilot は正規の情報として回答に使うため、一つの設定ミスが AIで検索可能な漏えいに増幅されます。クラウド完結のサービスであるため、 修正のタイミングも検査の可否も提供側に委ねるほかありません
• Microsoft Graph — 全データに繋がる一本の窓口 — Graph はメール・ファイル・ 予定・利用者情報のすべてへ繋がる単一の API です。アプリに与える権限の粒度は粗く、 たとえばアプリ権限の Mail.Read は「全員の全メール」に届きます。 同意させたアプリ一つ、漏れたトークン一つが組織全体への窓口になり、 Graph を攻撃の指令経路(C2)に使うマルウェアも実際に報告されています
• Agent 365 — その窓口に AI エージェントを常駐させる — AI エージェントに Entra 上の身元(Agent ID)を与え、Graph 経由でデータへの常時アクセスを持たせる 仕組みです。Microsoft 自身が「エージェントの乱立(agent sprawl)」「過剰権限」 「持ち主不明のエージェント」を管理すべきリスクとして挙げています。 そしてその管理の答えは Entra・Defender・Purview の追加サービス—— 閉じた世界の中で生まれた問題を、閉じた世界の追加契約で抑える構図が一段深まります
• AIの中身と品質を選べない — AI の答えの質はモデルで決まりますが、 Copilot ではどのモデルに処理されるかを利用者は選べず、切り替えの時期も 提供側次第です。Microsoft の自社モデル(MAI)は、これまでのところ公開の 比較評価で先頭集団に入っていません。つまり組み込みAIの品質は 「その時点で最良のAI」ではなく「バンドルされたAI」の水準に固定されます。 AI を独立した道具として使う構成なら、モデルはいつでも最良のものに 差し替えられます——本キットが AI を製品への組み込みではなく 開発時の道具として使う理由の一つです

データの軽視

• 構造化データへの対応が弱い — Microsoft 365 の中心は文書(Word・Excel・ PowerPoint)で、スキーマを持つ構造化データの置き場所が標準にはありません。 現実には Excel が台帳・名簿・申込管理のデータベース代わりになりますが、 セルには型も制約もなく、列がずれても値が重複しても黙って壊れます。 SharePoint リストや Teams のやり取りも標準形式での取り出しが難しく、 決定や資料は流れて消えます。本格的に構造化しようとすると Dataverse や Power Platform という別課金の製品群が必要になり、データベースの基本である SQL は、この世界のどこにも標準では含まれていません。 そしてシステム間のデータ交換は、今でも CSV や固定長テキスト(txt)です—— スキーマも型も持たず、列の位置や桁の位置と暗黙の了解だけに頼る形式で、 Excel で開けば先頭の 0 が消え、番号が日付に化け、誰も気づかないまま壊れます。 Word の様式も同じです——見た目は整っていても、データとしては構造のない ただの文章(txt)で、受け取った側は人が読んで転記するほかありません。 本キットがデータを Markdown / YAML / Parquet(自己記述でスキーマを持つ形式)に置き、 蓄積を SQL にして、CSV を境界に使わないのは、この欠落の裏返しです

契約の構造

• やめられず、値上げを断れない — Exchange Online、SharePoint / OneDrive には ローカルの代替がなく、解約は認証・メール・共有を同時に移すことを意味します。 席数課金は何年払っても所有に至りません。しかも実際に、個人向けは Copilot の 組み込みとともに約43%の値上げ(2025年2月、年14,900円→21,300円)、法人向けも 「AI標準搭載」を理由に約12〜17%の値上げ(2026年7月、Business Basic $6→$7 等)が 行われました。サブスクリプションには「今の機能のまま今の価格で使い続ける」という 選択肢がなく、AI が不要でも、値上げに従うか移行するかの二択になります。 この値上げは一過性とは考えにくい構造があります——Microsoft は AI 向け データセンターに年間10兆円を超える規模の投資を公表しており、 その回収経路は製品の利用料以外にありません。投資が続く限り、 「AI搭載」を理由とする改定は繰り返されると見るのが自然です

業務システム

• 認証の選択を迫られる — 組織が Microsoft 365 にいると、業務システムが Entra ID を使わなければ連携は難しくなります——シングルサインオンが効かず、 アカウントは二重管理になり、利用者の追加・削除も別々の作業になる。 かといって Entra ID に合わせれば、上で述べた縛り(開発技術の事実上の指定)を 業務システムがそのまま引き受けます。どちらを選んでも、業務システムの認証が 自分たちの要件ではなくベンダーの構図で決まってしまいます
• 作らせれば高額になる — SIer への発注は人月単価の積み上げで、 小さな業務システムでも数百万円規模になりがちです。多重下請けの構造では、 実際に作る人と発注者の間に何層もの伝言と管理費が挟まり、 費用の多くが開発そのもの以外に消えます。納品後も年額の保守費が続きます。 そもそも「DXで業務を効率化しましょう」と勧める IT 産業自身が、 ソフトウェアを人月で数える手作りで生産しています。 作り手の生産性が変わらないまま、顧客の効率化だけが安く手に入ることはありません
• SaaS を借りても高額になりやすい — 一人あたり月額の課金は人数と年月に 比例して積み上がり、機能は上位プランに小出しにされ、値上げを断る手段は ありません。業務ごとに別の SaaS を契約していくと、一つずつは安くても 束では大きな固定費になります。そしてデータはサービスの中にあり、 やめるときに全部を持ち出せるとは限りません
• 人が入力装置になっている — それだけ費用をかけても、業務システムの多くは 結局「人が画面に手で打ち込む」ことで動いています。紙の書類を Excel に打ち直し、 メールの内容を業務システムへ転記し、システムAの画面を見ながらシステムBに入力する。 Office 365 の職場はその典型で、1日の大半を PC の画面を見て 入力作業に費やす人が珍しくありません。出力側も同じです——月次バッチのたびに 帳票が大量に紙へ印刷され、綴じられ、確認のために紙がめくられる。 データはシステムの中にあるのに、人が使う段になると紙へ戻すのです。 システム同士が繋がっていないため、 人間が接続装置の役割を担わされている——手書きが手打ちに変わっただけで、 それを「デジタル化」と呼んできたのです
• データが独自形式・独自APIの中にある — 取り出すにも他システムと繋ぐにも 個別開発が要り、システムの境界のたびに手作業の転記が生じます
• 変更のたびにベンダー保守契約 — 小さな画面や様式の変更にも見積り・発注・納期が要り、 業務の変化に追従できません
• 寿命をベンダーが握る — 製品の販売終了・サポート終了・撤退で、 業務ごと作り直しになります

CMS/スマートフォン

• 組織のITから完全に切り離された島 — WordPress に代表される CMS は、 Microsoft 365 とも業務システムとも繋がっていません。組織の認証(Entra ID)は 組織の内側のための仕組みで、不特定多数が訪れる公開Webへ晒す設計には なっておらず、インターネット側の負荷と攻撃には耐えられません。 境界の内側をあれほど強く縛る認証が、公開Webには届かない——結果として CMS は独自のアカウントと独自の編集画面を持つ三つ目の世界になり、 Word の文書も業務システムのデータも、人がコピーして貼り直すことでしか 公開Webに届きません。これは偶然ではありません——Microsoft 自身、 かつて SharePoint にあった公開Webサイト機能を2015年に廃止して以来、 この領域の製品を持っていません。スマートフォンからの撤退 (Windows Phone、2017年終息)は有名ですが、Web からの撤退は あまり意識されていません。組織を縛る世界が、市民や顧客が実際にいる場所 ——スマホと Web——を覆っていない。この落差が、閉じた世界の問題を いっそう大きくしています
• 公開サイトなのに常時攻撃対象 — 動的なCMSはサーバーとプログラムを常時稼働させるため、 脆弱性対応とバージョン更新が終わりません
• プラグインの積み木 — フォームも検索も後付けプラグイン頼みで、 本体更新のたびに壊れるリスクを抱えます
• 編集に版管理・承認がない — 「ログインして直す」だけでは、 誰がいつ何を変えたか辿れず、間違いを戻せません
• 扱えない業務が「仮の手段」に流れる — 申込・予約・依頼は担当PCの その場しのぎの Excel・紙・メールへ押し出され、分断と属人化を生みます

三つに共通するのは、データと業務の形を道具の側が決めてしまうこと。 そして、その世界の境界を埋めているのが人間の手作業だということです。

繋ぎ役の交代 — それが今

これまで、三つの世界を繋いできたのは人間でした——画面を見ながらの転記、 CSV の受け渡し、紙の帳票。繋ぐコードを書かせれば高額で、 書ける人も足りなかったからです。

それらを接続するコードを、AI が書けるようになった。それが今です。 AI は閉じた世界の独自形式を読み解き、開いた形式(Markdown / YAML / SQL)への 変換を書き、OSS の部品同士を繋ぐコードを書きます。三つの世界に欠けていた 「境界を越える力」が、初めて現実の道具になりました。 実例は既にあります——cf-publish は Python の世界と Cloudflare Pages を繋ぎ、CJKフレンドリー三部作 は 日本語と Markdown・組版・SVG 描画を繋ぐ。どれも AI と協働して書かれ、 実際の製品の中で毎日動いている「接続するコード」です。

こうして三つの世界は、一つの開いた土台(git・SQL・メール・OnlyOffice・静的公開)に 置き換わります——内容は Markdown+git で版管理・承認し、受付は様式(xlsx)を 唯一の定義とする機械可読な経路にし、必要な業務だけ認証・DBを備えたアプリにする。 AI が書いた接続は人が確認し、コードとして git に凍結するので、 日々の運用に AI は残りません(AI は道具として使い、成果物を残す)。 公開Web側から見れば「CMS移行キット」、文書・メール側から見れば 「Microsoft 365 移行キット」——同じ道具の、顔が違うだけです。

ただし全業務を無条件に移すのではなく、業務ごとに要否で水準を選びます。 単独・小規模のサイトなら「静的化まで」で十分な場合も多く、 その判断が移行のいちばん最初の仕事です。

閉じた世界をつくらない — 公開標準でつなぐ

移行の目的は、別の閉じた世界(自前スタックへの新しいロックイン)への 引っ越しではありません。部品は少数の公開標準で疎結合につなぎます。

• データ = Markdown / YAML / JSON / Parquet(自己記述でスキーマがある形式)
• 問い合わせ・蓄積 = SQL(実装は PostgreSQL・SQLite。製品ではなく SQL にコミット)
• 処理 = Python、体裁 = テンプレート(Jinja2)

自己記述で、AIが扱えて、多くの道具が読める形式だから、部品は差し替えられ、 データはツールより長生きし、この仕組み自体からも出られます。 檻から出ることと、出た先を檻にしないこと——その両方が「開放」です。

amig のパイプライン

移行は一発変換ではなく、人が確認・修正できる段階に分かれています。

amig new sites/mysite            # 1. サイトの雛形を作る(site.yaml を編集)
amig ingest sites/mysite ~/data  # 2. 元データ(CMSの書き出しHTML等)を取り込む
amig classify sites/mysite       # 3. 記事/一覧に分類 — 結果は人が直せる
amig convert sites/mysite        # 4. 記事を content/*.md へ機械変換(下書き)
amig build sites/mysite          # 5. dist/ に静的サイトを生成
amig publish sites/mysite        # 6. Cloudflare Pages へ配信(運用判断で実行)

要点は3つあります。

1. 内容の正は content/ の Markdown+frontmatter — CMS のデータベースではなく、 git で版管理できるテキストがサイトの本体になります
2. convert は既存の .md を上書きしない — 機械変換はあくまで下書きで、 人が仕上げた原稿を壊しません(--force を明示したときだけ上書き)
3. publish は自動では走らない — 公開はいつも運用側の判断で実行します

配信は cf-publish、日本語Markdownの解釈は mdit-py-cjk-friendly と、同じ思想の小さな部品を組み合わせています。

問い合わせ設計 — 様式(xlsx)+メール受付

本キットは Webフォームを作りません。サーバー側に受付処理を持つと、 それ自体が保守と攻撃面になるからです。かわりに、昔ながらの「様式」を 機械可読にして使います。

amig forms sites/mysite            # 様式 xlsx を生成(公開サイトに載る)
amig mailin sites/mysite --once    # 受付メールを担当フォルダへ振り分け

• 様式が唯一のフォーム定義 — site.yaml に書いた一つの定義から様式を生成し、 「Webからダウンロード」「印刷して手書き」「メール添付で提出」「機械読み取り」の 全チャネルを同じ様式が兼ねます
• VBA を使わない — 処理は外部の Python、入力補助は OnlyOffice の サンドボックス内 JavaScript に分離し、「ファイルを開く=コードが実行される」 という経路を設計から無くしています
• 受付アドレスはページ本文に書かず、様式の中にだけ置きます(ボット収集対策)。 様式由来でないメールには自動返信しないので、スパムへの逆流も起きません
• 受付の状態管理は IMAP フォルダそのもの(INBOX=未着手 / staff/担当 / pending=未処理)。 専用の管理画面を作らず、普段のメールソフトで運用できます

なお、WordPressを当面使い続けながら問い合わせデータだけを先に引き取る緊急措置は FormRescue にまとめています。フォームは素のHTML+Turnstileになるため、 のちに本キットで静的化しても、データの引き取りは一日も途切れません。

共同編集と認証

• 内容の共同編集は Forgejo(git) を土台に、エディタは Zed などを想定。 提案→レビュー→承認という本格の編集プロセスが、公開Webにもそのまま使えます
• 認証は層で分けます — 編集層は Forgejo の内蔵認証、業務アプリ層は PocketBase で職員・会員を role 分離。一つの巨大な認証基盤に集約しません

どこまで移すかは選べる

運用形態が構成を決めます。公開Webの静的化だけなら、サーバーの常時運用は不要で Cloudflare Pages の無料枠に収まります。問い合わせを足すならメールの受け口、 業務アプリまで移すなら機関内サーバー——と、引き受けられる運用の水準に合わせて 段階的に選べる構成です。

動かす場所 — Linux の自宅サーバー

移行した道具を動かし続ける場所には、Linux の自宅サーバーという選択肢があります。 AI を使えば構築も運用ももう難しくなく、常時稼働のコストは 自宅サーバー ＜ VPS・クラウド ＜ 大手クラウド の順です。 「AIをどう使うか」から始まるこの話は、自宅AIサーバーのページ にまとめています。

他のパッケージとの関係は OSSパッケージ紹介 へ。

→ GitHub: aiseed-dev/aiseed-migration-kit