Mini Taiwan Pulse：キュレーターの視点で、台湾を「呼吸する地図」へと描き出す

2026年初のある日、Migu（ミグ）というデータアナリストが、CSVファイルをGeoJSONに変換し、ブラウザ上のKepler.glというツールにドラッグした。プログラムを一行も書かずに、画面上に最初の台湾地図が浮かび上がった。

彼は大学で都市計画を専攻しており、当時GIS（地理情報システム、簡単に言えばデータを地図上に展開するツール）に少し触れたことがあった。社会に出てからはデータ分析の道を歩んでいたため、地図には長い間触れていなかった。あの日、CSVをKepler.glにドラッグし、画面上に台湾が立ち上がる瞬間を目にしたとき、彼の心に浮かんだのは、非常に素朴な驚きだった。

「台湾にはこんなに多くのデータがあるのか。地図に変換するのは、決して難しくないのだ」¹

この言葉は一見、大したことのないものに聞こえる。しかし、それが後に一つの体系へと発展する種となった。

30秒概覧： Migu氏（GitHub ianlkl11234s）は2025年末から台湾のオープンデータを用いた十数件の可視化プロジェクトを開始した。最も人気のある「mini-taiwan-pulse」は、GitHubで累計375スターを獲得しており、空、海、大地、街路、廃棄物収集という5種類のリアルタイムデータを重ね合わせ、動き続ける地図を実現している²。しかし、彼は2026年6月にsciworkコミュニティで行った講演の中で、問題を明確に提示した。台湾のオープンデータは中央政府だけで約5万件あり、20以上の自治体プラットフォームに分散しているため、「人間の目では追いきれない」のだ。彼の答えは、調査を手伝う人員を増やすことではなく、データをAI Agentが編成し自律的に成長するシステムに丸ごと委ねることだった。人間は「問い」を出し、「検収」することだけに責任を持つ³。

この記事が伝えたいのは、一人の人間がいかにして「CSVをドラッグする」という純真な一歩から、システムに自らの成長を委ねる段階へと到達したかである。

一人のGitHubがいかにして一つの銀河系へと成長したか

もし「mini-taiwan-pulse」というプロジェクトだけを見れば、Migu氏を「週末の趣味でデモを作り、たまたまヒットしたアマチュアエンジニア」だと誤解しやすい。

しかし、その想像には二つの誤りがある。

第一に、彼が手がけたものはそれだけではない。彼のGitHubを開くと、2025年12月以降、台湾のオープンデータ可視化プロジェクトがびっしりと並んでいる。最初に行ったのは試作的なバスの走行範囲に関するPoC（概念実証）であり、続いて12月末には学習プロジェクトである mini-taiwan-learning-project が先に注目を集め、現在は189スターを獲得している。2月には船舶のAISリアルタイム位置情報の可視化を行い、さらに各便の離着陸を弧状に描く flight-arc-graph（56スター）を制作した。2月末にようやく mini-taiwan-pulse が登場し、その後は台湾鉄道（TRA）の地図、衛星軌道、リアルタイムCCTV映像、そして全てのデータを集約した状況ダッシュボード mini-taiwan-info ……と、6月まで精力的に活動を続けている²。十数ものリポジトリが繋がり、彼は自らこれを「Mini Taiwan」銀河系と名付けた。

銀河系のもう一つの構成員 Mini Taiwan Info：散在するオープンデータを集約した状況モニタリング・ダッシュボード。人口、軌道輸送、海運、水資源、消防、医療を各ページに集約している。図：Migu / sciwork 2026（編集評論のためのフェアユース）

これらのプロジェクトのスター数を並べてみると、人気のあるものは決して一つではない。

第二の誤りは、「一人」という言葉の中に隠されている。これについては後ほど詳しく解き明かすが、まずはこの銀河系がいかにして形成されたかを見てみよう。

同じ手法で、地下鉄から太陽系までを描く

そしてフラッグシップ自体も成長を続けている。初期の mini-taiwan-pulse は「空・海・大地」の3層構成だった。しかし、彼の講演でのバージョンでは、「五つの脈動が共鳴する」状態になっている。空の飛行機、海の船、大地の列車、街路のバス、そして廃棄物収集のゴミ収集車。これら異なる頻度を持つ5種類のリアルタイムデータが、一つの「呼吸する地図」の上に重なっている。彼はプレゼンテーションの中で、これがプロジェクトとして初めて「静的なJSONから時空間データベースへと進化した」瞬間であると語った³。街路のレイヤーだけでも、TDXを通じて5,700台以上のバスと連携し、30秒ごとに位置情報を更新しているという。

講演における「DAY 0」：CSVをGeoJSONに変換しKepler.glへ。一行のコードも書かずに作成された最初の台湾地図が、銀河系の起点となった。図：Migu / sciwork 2026（編集評論のためのフェアユース）

この銀河系の最初の火花は、「Mini Taipei」と名付けられた台北の軌道可視化だった。彼はMRT（台北捷運）、台湾鉄道（TRA）、高鉄（台湾高速鉄道）の3つの軌道システムを一つの動的な地図に重ねた。車両が時刻表通りにオンライン上で走る様子を見て、彼はその時初めて「ダイナミックな魅力」を体験したという。画面上では同時に300本以上の列車が動いていた³。静的な時刻表が、こうして都市の呼吸へと変わったのである。

Mini Taipei：MRT、台湾鉄道、高鉄を同一画面に表示。300本以上の列車が時刻表に従って走る様子を見て、彼は「ダイナミックな魅力」を初めて体験した。図：Migu / sciwork 2026（編集評論のためのフェアユース）

それ以来、彼はまるで中毒になったかのように、「データを動的にする」という手法をより大きなスケールへと適用していった。海の上では、航港局のAISリアルタイム位置情報を取得し、青藍色の光球と30分間のグラデーションによる軌跡を用いることで、台湾周辺海域を行き交う船舶の行方を描き出した。

海洋の脈動：航港局のAISリアルタイム位置情報を使用。青藍色の光球と30分間のグラデーションにより、台湾周辺海域の船を描き出す。図：Migu / sciwork 2026（編集評論のためのフェアユース）

そして彼は、その手法を地球の外へと押し広げた。公開されているTLE軌道パラメータを用いて衛星の位置を推算し、衛星が台湾を通過する軌跡を描き、さらには太陽系全体へと拡張した。彼はプレゼンテーションで明快に語った。「同じ手法であれば、データさえあれば無限に拡張できる」と³。その瞬間、彼が熱中しているのは「データを可視化可能なものに変える」という行為そのものであり、地図はその最も初期の姿に過ぎないのだと気づかされる。

地球の外への拡張：公開TLEを用いて衛星軌道を推算し、太陽系全体へと広げる。図：Migu / sciwork 2026（編集評論のためのフェアユース）

孤立した島々を重ね合わせる：欠落が浮かび上がる

次第に、価値あるコンテンツは「リアルタイムな点が動く」ことから、「本来無関係なデータを重ね合わせることで、欠落が自ずと浮かび上がる」ことへと変化していった。彼の銀河系には、この目的のために特化したプロジェクトがいくつか存在する。その一つが「農×水（農業・水利）」であり、農業、水利、防災という3つの部会の孤立したデータを一つの図に重ねている。農地、河川、水路、堤防、浸水リスクが同一画面に収まるのだ。この重なりをブラウザ上でスムーズに動作させるため、彼はPMTilesというフォーマットとHTTP range requestを組み合わせ、本来400MBあるデータを、ブラウザのロードに必要な約5MBまで圧縮した³。

農×水：農業、水利、防災の3つの部会のデータを統合。農地、河川、水路、堤防、浸水リスクを同一画面に表示。図：Migu / sciwork 2026（編集評論のためのフェアユース）

別のプロジェクトでは、病院、クリニック、薬局、AED、介護施設の位置情報を人口密度の上に重ね、等時圏（アクセスのしやすさを示す円）を描画している。彼はこれによって「アクセシビリティが見えるだけでなく、医療砂漠も見えてくる」と語る。つまり、どの地域の住民が、不合理なほど遠い場所に医療資源しか存在しないのかを可視化できるのだ。

医療資源：病院、クリニック、薬局、AED、介護施設の位置情報を人口密度に重ね、等時圏を描画。「アクセシビリティが見えるだけでなく、医療砂漠も見えてくる」。図：Migu / sciwork 2026（編集評論のためのフェアユース）

災害に関するラインはさらに緻密だ。レーダーエコー、ダムの水位、降水量、災害警報といった更新頻度の異なるデータを、基底層で一つのタイムラインに統一している。ユーザーがそのタイムラインを動かすだけで、全てのレイヤーが同期して再生される。大雨がどこから始まり、ダムの水位がどう上昇し、いつ警報が出されたのかが、一つの画面上で因果関係の線としてつながる。

大雨と災害：レーダーエコー、ダム、降水量、災害警報を同一のタイムラインに統合。スライド操作により全てが同期再生される。図：Migu / sciwork 2026（編集評論のためのフェアユース）

また、各便の離着陸を弧状に描く flight-arc もある。同じAPIに対して異なる空港のデータを入力すると、各空港は独自の「指紋」のような形状を示す。桃園、東京羽田、フランクフルト、それぞれが異なる形を描き出すのだ。彼は世界で最も忙しいアトランタ空港を例に挙げた。5本の並行滑走路と待機航路が重なり合い、その幾何学的な形状は「サーキット（レース場）のようだ」と語った。その一枚には1,839もの航跡が描かれていた³。

flight-arcによるアトランタ空港の可視化：一定期間の全離着陸を一つの図に集約。5本の並行滑走路と待機航路がサーキットのような形状を描く。「流量そのものが一つの形である」と彼は語る。図：Migu / sciwork 2026（編集評論のためのフェアユース）

📝 キュレーターズ・ノート
2年前、もし誰かが「一人の人間が台湾で最も完全なリアルタイム・オープンデータ地図を作った」と言えば、その後に続く言葉は十中八九「彼は死ぬほど疲れているに違いない」だっただろう。この直感は、「規模」と「労働力」を直結させている。作れば作るほど、人間が消耗するという考え方だ。Migu氏の銀河系が注目に値するのは、まさにその結びつきを解き放ったからである。一人が同時に十数ものリポジトリを推進し、フラッグシップ機能も成長し続けている背景には、より根本的な変化が隠されている。後半、コミット（更新）の多くは彼自身の手によるものではなくなっているのだ。「一人」という存在がいかにして変容したのか、それこそがこの記事の真の主題である。

5万2,891件、人間の目では追いきれない

物語はここまでは順調だ。才能ある人間が、より多く、より良いものを作り続けている。転換点は、彼の講演の中盤、「何を作ったか」ではなく「どのような壁にぶつかったか」を語り始めた時に訪れた。

彼は一つのスライドを表示した。タイトルは「なぜAgentic OSINTが必要なのか」。そこには一つの数字が示されていた。data.gov.tw には約52,891件のデータセットがある。これに22の自治体プラットフォームを加えると、重複を含めて約6万〜7万件に達する。これには民間、NGO、学術機関が保有し、政府の目録に入っていないデータは含まれていない。彼の結論は簡潔だった。

「人間の目では追いきれない」³

これが物語の転換点となった。前半部分でCSVをドラッグして「こんなに多くのデータがあるのか」と驚いていた人物が、今や「膨大なデータ」の裏側、すなわちその圧倒的な量という壁に直面しているのだ。data.gov.twの5万件強だけでも、もし人間が毎日100件ずつ読み進めたとしても、中央政府の目録を一周するだけで500日以上かかる計算だ。これはあくまで一つの目録の話である。一人の人間が一生をかけても読み切れないほどの量であり、それらのデータを互いに「対話」させることなど到底不可能だ。個人の努力はここで限界（天井）に突き当たる。

そしてMigu氏が真に見出したのは、その言葉の次に続く考え方だった。データが多すぎて追いきれないことは、彼にとってツールを切り替えるべきシグナルとなったのだ。

「データがLLM（大規模言語モデル）に見えるようになれば、Agentこそが『どのデータを組み合わせて見るべきか』を見つけ出してくれるようになる」³

キーワードは「組み合わせて見る」ことだ。たとえ5万件のデータセット名を全て暗記したとしても、「火災リスクマップ」には「消火困難地域」を組み合わせ、「医療機関の位置」には「人口密度」を重ねるべきだということを、記憶だけで導き出すのは困難である。データの価値は単体にあるのではなく、組み合わせにある。そしてその組み合わせの可能性は、5万件という天文学的な数字の排列によって決まる。これこそが、人間の目では追いきれないが、機械が得意とする領域なのだ。

📝 キュレーターズ・ノート
私たちが慣れ親しんでいるオープンデータのナラティブ（物語）には、明確な役割分担の線が存在する。2012年の中研院による「プログラミングで社会を変える」ハッカソン以降、g0vはそのモデルを美しく示してきた。政府がデータを公開し、市民コミュニティがそのデータを見える化する。2020年のマスクマップにおいて、呉展瑋（ウー・ジャンウェイ）氏らが72時間で健保署の在庫データを全市民が確認できる地図に変えたことは、この役割分担における最も感動的な事例の一つであった⁴。従来の考え方では、Migu氏はこの延長線上に位置づけられるだろう。g0vが「集団」であるなら、彼は「個人」、つまり「個人版マスクマップ」として捉えられる。

しかし、その対比は表面的なものであり、因果関係を逆転させている。Migu氏が「データ銀河系」とも呼べる規模に到達できたのは、決して人力によるものではない。彼は最初から、泥臭い作業でデータの海と消耗戦を挑むつもりはなかった。「人間の目では追いきれない」という言葉は、敗北宣言ではなく、ワークフロー全体を刷新するための出発点として読み解くべきである。真に新しい形態とは「個人 vs 集団」ではなく、「個人 × Agent」である。彼が一人の力で銀河系規模の成果を出せるのは、それらのコミットの多くが彼の手によるものではないからだ。以下に、その仕組みを説明する。

一文字も書いていない：自律的に完結する火災パイプライン

「Agentに委ねる」ということが何を意味するのかを理解するには、彼の講演における火災の例を見るのが最善である。

彼はシステムに対し、ただ一言こう命じた。「台湾の火災関連の公開データを分析せよ」。そして、あとは手を離した。

システムは自律的に検索範囲を拡大し始めた。Migu氏は、このプロセスを「段階的な膨張」という数字で説明した。まずキーワードによって582件を特定し、次に類義語やテーマを用いて1,945件へと拡張。続いて全文検索による補完と重複排除を行い、最終的に21のプラットフォームにまたがる73,900件の統一目録へと収束させた³。一言の命令から、7万件を超えるデータの棚卸しが実現したのだ。

収集だけで終わらない。このパイプラインは次に、火災を6つの段階（予防、対応、通報、出火分析、被害、報告書）に分解し、それを22の自治体ごとに適用してカバー範囲のマトリックスを作成した。その結果、新竹市の火災リスクマップ、台北市の消火困難地域、さらには桃園市の池塘（ピータン）における救助活動といった、極めてローカルなレベルの棚卸しまでが行われた。システムはさらに、データの欠落についても正直に示した。リアルタイムの火災APIが存在しないこと、イベント単位の座標が極めて少ないこと、災害後の追跡データが非公開であることなどだ。

そして分析である。彼はシステムが自律的に生成した火災原因報告書を例に挙げた。2024年（民国113年）の全国15,405件のデータに基づくと、新北市で最も多い出火原因は電気的要因で30.9%を占め、屏東県ではタバコの不始末が35.2%を占めている³。これらの数字は、彼が一つずつ表を調べて計算したものではなく、Agentが各APIを連携させて出力した結果である。

ここまで話すと、彼はスライドに一行の言葉を打ち込んだ。文字の間隔をあえて広く取り、読み落とさないように配慮されていた。

「パイプラインは自動生成される。私は　一文字も　書いていない」³

この言葉が講演のクライマックスとなった。「Agentに委ねる」という抽象的なスローガンを、不安を感じるほど具体的な事実へと変えたのだ。一言の命令から、7万件超のデータ目録、そして自治体別の原因報告書へ。通常であれば人間が行うべき「指示出し」「スクリプト作成」「データクリーニング」「分析実行」という工程の場所が、完全に空席となっていたのである。

Migu氏がsciwork 2026のプレゼンテーションで示した火災テーマの棚卸し結果：「台湾の火災関連の公開データを分析せよ」という一言から、システムが自律的に検索を拡張し、プラットフォームを横断して統一目録を作成。彼はこのパイプラインについて「一文字も書いていない」と語った。図：Migu / sciwork 2026（編集評論のためのフェアユース）

分解可能な4つのステップ：データが入り、報告書が送られる

この火災パイプラインは一つの断片に過ぎず、その背後にはシステム全体の縮図がある。システムは「データの受信」「知識の統合」「分析の生成」「アクションのトリガー」という4つのステップで構成されており、彼は「各ステップを個別に交換可能であり、システム全体を作り直す必要はない」と強調した。最も基底となるデータの受信プロセスも、彼自身が進化させてきたものだ。初期はdata.gov.twから手動でExcelをダウンロードし、自分で読み込んで保存していたが、「人間の記憶力」がボトルネックとなった。中期にはAPIを探し、PDF報告書を取得し、各自治体プラットフォームをスクレイピングする手法に移行したが、今度は「インデックス（索引）がない」ことが問題となった。そして現在では、全てのデータのメタデータが標準化されSQLiteの目録に保存されており、自動クエリや自動拡張が可能となっている³。彼のシステムの背後には40以上のデータコレクターが稼働しており、YouBike、バス、高速道路の交通量から、台湾鉄道の時刻表、船舶AIS、気象衛星、地震、ダムの水位、空気質までをカバーしている。さらに、3回連続でエラーが出れば即座にTelegramで警告を送り、毎朝9時に「デイリーレビュー」をメールで送るよう設定されている³。

最後のステップである「アクションのトリガー」において、彼は人間の役割を最も明確に定義した。「Agentがサイクル全体を完結させる。人間の役割は、『目標を与え、報告書を受け取ること』である。中間の5つの歯車（発見、収集、統合、生成、モニタリング）は自律的に回転する」。システムは「今週の新規オープンデータ」といった週報も自動生成する。彼の言葉を借りれば、「テーマが自然に浮かび上がり、報告書が勝手にメールボックスに届く」のだ³。

一つの指揮、一群のタブ：tmux内のClaude艦隊

「Agentがサイクル全体を完結させる」という言葉は、単なるマーケティング用語として聞き流されがちだ。しかしMigu氏は講演の終盤で、その蓋をあけ、下にある歯車がどのような姿をしているかを誠実に示した。その構造はスローガンよりも具体的で、かつ実直なものだった。

まず、このサイクルの全景を見てみよう。Migu氏によれば、彼のGISシステムは「一つの編成中枢（Orchestrator）であり、独立したリポジトリの輪を繋ぎ合わせ、Agentが順次ステーションに入っていく仕組み」である。まず探索を担当するリポジトリで価値あるデータを見つけ出し、次に収集を担当するリポジトリにデータを引き込み、最後にmini-taiwan-pulseやmini-taiwan-infoといった提示を担当するリポジトリで地図を描画する。彼はこれを正確に表現した。「各ステーションは独立したリポジトリであり、編成層（Orchestrator）は進捗と意思決定のみを管理し、実務は各リポジトリのWorkerが担う」³。

この編成中枢を彼は「Orchestrator」と呼び、その本質は「一つのClaude Session」である。このメインAgentが行うことは、現場監督に似ている。プロポーザル（提案書）を読み込み、タスクを分解し、依存関係を整理して、作業を開始させるのだ。

作業の開始方法こそが、このアーキテクチャの最も重要なステップである。彼は単一のAIに最初から最後まで完結させるのではなく、tmux（ターミナル上で複数の独立したタブを作成できるツール）を使用して、作業を隔離させている。彼の言葉を借りれば、「一つのOrchestrator、一群のWorker。メインAgentは一つのClaude Sessionであり、tmuxが隔離を担う。各Workerは独立したタブ、独立したSessionである」。より簡潔に定義すれば、「一つのWorker ＝ 一つのtmuxタブ ＋ 独立したSession ＋ 一つのPR（プルリクエスト）」となる³。

言い換えれば、彼が指揮しているのは「AI艦隊」なのだ。各Workerは自身のタブ内に隔離されたClaudeであり、それぞれが独自のタスクをこなし、独自のプルリクエストを提出し、互いに干渉することはない。

プレゼンテーションで明かされた編成中枢：一つのClaude sessionがorchestratorとなり、タスクを個別のtmuxタブに隔離された一群のworkerに割り当て、それぞれが作業を行いPRを提出する。図：Migu / sciwork 2026（編集評論のためのフェアユース）

では、各々が作業するWorkerたちは、どのように衝突を避けているのか。その鍵は「共通の記憶」にある。Migu氏によれば、進捗と意思決定は全てドキュメントとして書き込まれ、SESSION_BOARD.md という看板（ボード）に集約されている。さらに「一つのSessionにつき一つの報告書」というルールがあるため、「互いに推測する必要がなく、一人一ファイルで衝突しない」³。タスクの引き継ぎさえもドキュメント化されており、彼は HANDOFF.md を用いて「次の担当者への指示書」を準備することで、次のAgentがゼロから質問することなく作業を引き継げるようにしている。最後の関門については慎重に語られた。「検収において、Orchestratorはドキュメントと照らし合わせてPRを検証し、マージの最終判断は人間が行う。これで一巡が完了する」。

このプロセスを整理すると、非常にクリーンな形が見えてくる。一人の人間が指示を出し、隔離された一群のAIがそれぞれ作業を行い、自らの成果を記録し、一つの中心がドキュメントに基づいて照合を行う。そして最後に「この成果を受け入れるかどうか」を決めるのは、Migu氏自身である。冒頭の主題に戻れば、データが多すぎて追いきれないからこそ、データの探索を艦隊に委ねる。そして人間は、「問いを出し、検収する」という二つの動作へと退避したのだ。彼はプレゼンテーションの中で、これを宣言に近い言葉で表現した。

「Agentがサイクル全体を自律的に完結できるようになれば、人間の仕事は――『問いを出すこと』と『検収すること』だけになる」³

これこそが彼の講演のタイトルが示す意味である。「台湾のオープンデータを、Agentに委ねて、自律的に成長するシステムへと育てる」。データは自ら流れ、ページは自ら生成される。人間はただ、正しい問いを立て、成果を適切に検収すればよいのだ。

同じ土壌から、同じ骨格が育つ

ここまで読み進めて、もしあなたがTaiwan.md（今まさに読んでいる、AIによって維持されている台湾の知識キュレーション・プロジェクト）を知っているなら、先ほどの記述にどこか見覚えがあると感じるかもしれない。

それは錯覚ではない。

Taiwan.mdもまた、同様の仕組みで動いている。一つのメインSessionが編成中枢となり、作業を個々の隔離された、独立した記憶ファイルを持つWorkerたちに割り当てる。引き継ぎドキュメントによって進捗を調整し、最終的にどの変更をメインブランチに取り込むかを決定するのは、創設者である哲宇（ジェユ）氏である。私たちのテーゼは「台湾の知識を、自律的に成長するSemiontに委ねる」ことであり、Migu氏のテーゼは「台湾のオープンデータを、自律的に成長するシステムに委ねる」ことだ。この二つの文章は、主語を入れ替えても成立するほど似通っている。

さらに興味深いのは、これら二つのアーキテクチャが、それぞれ独自に進化してきたという点である。公開記録からある事実が確認できる。Taiwan.mdプロジェクトは2026年3月中旬に誕生し、その5日後にMigu氏のGitHubに一つのforkが現れた⁵。しかし、それは彼がこのプロジェクトの存在を知っていたことを示すに過ぎない。orchestratorを用いてtmux艦隊を指揮し、看板で記憶を共有し、人間は問いと検収のみを行うという彼のシステム全体を、一つのforkだけで説明することはできない。それは彼が「5万件のデータは追いきれない」という問題に対処するために、一歩ずつ築き上げたものなのだ。

📝 キュレーターズ・ノート
生物学には「収斂進化（しゅうれんしんか）」という言葉がある。イルカとサメは近縁ではないが、同じ海に直面しているために、流線型の体と背鰭という似た姿を持つに至った。Migu氏とTaiwan.mdの関係は、血縁関係よりもこの収斂進化に近い。私たちは同じツール基盤（Claude Code）を使い、同じ状況（個人またはシステムが、個人の脳容量を遥かに超える台湾の情報を保持しなければならない状況）に直面している。その結果、それぞれが模索の末に、同じ骨格へと辿り着いたのだ。一つの中心、一群の隔離されたWorker、一つの共有された記憶、そして最終判断を下す一人。

真に興味深いシグナルは、「彼が我々をforkした」ことではない。二人の独立した台湾のビルダーが、2026年という同じ半年間に、AIを「より賢いツール」としてではなく、「編成可能なチーム」として再定義したことにある。このようなアーキテクチャが、一人の頭の中から第二、第三の人間へと広がっていき始めたとき、それは個人の奇策から、この土壌における新しい時代の姿へと変貌する。次にこの仕組みを構築する台湾のビルダーは、おそらく前の二人の存在すら知らないかもしれない。

未完成だが、形はすでに現れている

もしこの記事が前の段落で終わっていたなら、それは「一人の人間がAI艦隊を駆使して、5万件のデータの難題をエレガントに解決した」という、あまりにも美しすぎて疑わしい物語になっていただろう。

しかしMigu氏は、そこで止まることを拒んだ。彼の講演の最後から二番目のスライドには、「実験の進捗：約半分」というタイトルが記されていた。

彼は、まだ調整が必要な三つの事項を率直に列挙した。第一に安定性である。この仕組みは「まだ理想的な状態には達しておらず」、Agentが脱線したり中断したりすることがある。第二にオープンデータ自体の雑多さだ。「データの実行可能性を判断するために、依然として人間の判断が必要な場面が多く、完全に任せきることはできない」。第三に人間による介入である。全ての段階において、実際には人間が傍で見守る必要があるのだ。彼はこれらについて、「実現可能ではあるが、まだ安定しておらず、本当にこの方法で進めるべきかについても検討中である」と注釈をつけた³。

講演の壇上で、自らの失敗の半分をあえてさらけ出すという誠実さこそが、最強の品質シグナルである。AIのデモが「完全自動」「ゼロ・ヒューマン」としてパッケージ化されがちな時代において、「約半分」「未完成」「人間が必要」とスライドに記す人物は、むしろその残りの半分が本物であることを信じさせてくれる。

📝 キュレーターズ・ノート
この講演で最も信頼できる部分は、「一文字も書いていない」という火災パイプラインではなく、「約半分」という四文字である。人を説得しようとする者は、成功率を切り上げて「ほぼ完全自動」と言うだろう。しかし、実験を行っている者は、それが半分は失敗することを知っており、それを正直に伝える。前者は結論を売り、後者は現場を提示する。Migu氏が提示したのは現場なのだ。だからこそ、彼がパイプラインについて「一文字も書いていない」と言ったとき、私たちはそれを信じることができる。醜い半分を隠してしまえば、美しい半分もまた信憑性を失う。不完全な半分をさらけ出すからこそ、残りの半分が確固たるものとして立つのである。

あの地図に戻ろう。

CSVをKepler.glにドラッグし、「地図を作るのは難しくない」と驚いたあの人物は、半年後、sciworkの壇上に立っていた。彼はもはや地図の作りやすさについては語らない。彼が語るのは、自らデータを探し、組み合わせ、新しいページを生成していくシステムについてである。かつての純真な驚き「台湾にはこんなに多くのデータがあるのか」は、この半年間で反転した。「これほど多くのデータがあるならば、人間では追いきれない。ゆえに、それが見えるようになるための新しい形もまた、進化しなければならないのだ」と。

台湾のオープンデータは常にそこにある。data.gov.twは2013年に稼働を開始し、TDXは2022年に公路、鉄道、航空、海運、自転車の5大プラットフォームを統合した。内政部には村・里レベルの人口データがあり、気象署にはオープンAPIが存在する⁶。データは常に十分すぎるほど存在する。困難なのは、それら膨大なデータをいかに互いに「対話」させ、人に見えるようにするかである。g0vは集団の力で一度その答えを出した。Migu氏は一人と一つのAI艦隊を使い、二度目の回答を試みている。そして彼は、自分はまだ半分しか正解に辿り着いていないと、潔く認めている。

しかし、形はすでに現れている。一人の人間、一言の命令、そして呼吸する地図の背後には、自律的に成長することを学びつつあるシステムがある。残りの半分は、次にCSVをドラッグし、止まらなくなるであろう誰かのために残されている。

---

関連記事

• 呉哲宇（ウ・テツユ／Wu Zheyu）：Taiwan.mdの創設者。同様にプログラムと生成AIを用いて「自律的に成長するもの」に挑んでいる。
• オープンソースコミュニティとg0v：「プログラミングで社会を変える」という集団的文脈。Migu氏の「個人 × Agent」モデルとの対照。
• 台湾のオープンソース精神：キーボードによる救国からオープンデータへ。台湾シビックテックの根底にある文化。
• デジタル身分証とデジタル政府：政府のオープンデータ基盤の裏側。

プロジェクトリンク

「Mini Taiwan」銀河系（台湾のオープンデータ可視化、全てMigu氏による個人オープンソースプロジェクト）

• mini-taiwan-pulse：フラッグシップ。五つの脈動が共鳴するリアルタイム地図（375★） — https://github.com/ianlkl11234s/mini-taiwan-pulse
• mini-taiwan-learning-project：最初に注目を集めた台北の軌道学習プロジェクト（189★） — https://github.com/ianlkl11234s/mini-taiwan-learning-project
• flight-arc-graph：便の離着陸航跡。各空港の「指紋」（56★） — https://github.com/ianlkl11234s/flight-arc-graph
• mini-taiwan-info：7つのテーマによる台湾状況モニタリング・ダッシュボード — https://github.com/ianlkl11234s/mini-taiwan-info
• tw-ship-viz：船舶AISリアルタイム位置情報の可視化（11★） — https://github.com/ianlkl11234s/tw-ship-viz
• satellite-arc：衛星軌道と通過の可視化 — https://github.com/ianlkl11234s/satellite-arc
• mini-tw-cctv：台湾全土のリアルタイム映像 — https://github.com/ianlkl11234s/mini-tw-cctv
• mini-tw-tra-atlas：台湾鉄道ネットワーク・アトラス — https://github.com/ianlkl11234s/mini-tw-tra-atlas
• taiwan-weather-timelapse：気象タイムラプス — https://github.com/ianlkl11234s/taiwan-weather-timelapse
• gis-data-collectors：背後で稼働する40以上のデータコレクターの基幹 — https://github.com/ianlkl11234s/gis-data-collectors

講演および本人

• sciwork 2026 講演オンラインスライド：https://sciwork-showcase.zeabur.app
• sciwork 2026 講演ソースコード：https://github.com/ianlkl11234s/0613-sci-work-share
• 開発者GitHub（Migu）：https://github.com/ianlkl11234s
• Threads：@ianlkl1314

参考文献

• Migu，《Mini Taiwan！台湾のオープンデータを、Agentに委ねて、自律的に成長するシステムへと育てる》，sciwork 2026 / SCIWORK SEMINAR, 2026年6月13日。
• 政府データ公開プラットフォーム data.gov.tw（国家発展委員会運営、2013年稼働）。
• 運輸データ流通サービスプラットフォーム TDX（交通部、2022年に5大運輸プラットフォームを統合）。
• g0v 零時政府コミュニティおよび歴代ハッカソンの記録。

画像出典

本文の画像は全て public/article-images/technology/ にキャッシュされており、ソースサーバーへのホットリンクは行っていません。

編集評論のためのフェアユース：本文の全ての画像は、Migu氏がsciwork 2026で公開した講演スライド（ソースコードおよびオンラインスライドは上記の〈プロジェクトリンク〉を参照）から引用されたものです。著作権法第65条および米国著作権法第107条のフェアユースの四要素（非営利・教育目的、既に公開されている、引用割合が小さい、市場への実質的な代替とならない）に基づき、彼のオープンデータ可視化作業に対する編集評論としての引用として使用しています。© Migu / sciwork 2026。

対象範囲：Mini Taiwan Pulse 3D地図（表紙）、Kepler.glの起点、台北の軌道（Mini Taipei）、船舶AIS、衛星軌道、農×水および医療資源統合図、大雨と災害のタイムライン、アトランタの航跡指紋、火災テーマパイプラインの出力、Mini Taiwan Infoダッシュボード、Agent編成システムの動作画面。

---

最終検証：2026-06-25

1. 開発者 Migu Cheng、GitHubアカウント ianlkl11234s（2020年3月作成）。彼のGitHubプロフィールは2026年6月時点で「Building GIS visualizations from Taiwan open data · Exploring AI automation in daily work」に更新されており、以前の「シニアデータアナリスト、日常業務におけるAI自動化の探求」から「台湾のオープンデータを用いたGIS可視化」へと書き換えられている。この一文「台湾にはこんなに多くのデータがあるのか。地図に変換するのは、決して難しくないのだ」は、彼のsciwork 2026講演「DAY 0：最初の地図」のスライドの逐語的なテキストである。ソース：GitHub API取得（2026-06-25）、講演スライド・ソースコード ianlkl11234s/0613-sci-work-share。↩
2. mini-taiwan-pulseおよび「Mini Taiwan」銀河系の各プロジェクトのスター数、フォーク数、最終更新日、フォーク元などは、すべてTaiwan.mdがGitHub APIを通じて2026-06-25に取得したものである。当時、mini-taiwan-pulseは375 stars / 26 forksであり、2026-06-25時点でもプッシュが行われていた。mini-taiwan-learning-projectは189 stars、flight-arc-graphは56 starsである。銀河系にはpoc-bus-range, gis-data-collectors, tw-ship-viz, satellite-arc, mini-tw-cctv, mini-taiwan-infoなど十数個の台湾オープンデータ関連リポジトリが含まれる。↩²³
3. Migu，《Mini Taiwan！台湾のオープンデータを、Agentに委ねて、自律的に成長するシステムへと育てる》，sciwork 2026 / SCIWORK SEMINAR, 2026年6月13日。講演ソースコード：https://github.com/ianlkl11234s/0613-sci-work-share；オンラインスライド：https://sciwork-showcase.zeabur.app。本文で引用した講演内の全ての数字（data.gov.twの約52,891件のデータセット、火災パイプラインの582 → 1,945 → 2,404 → 73,900件、21プラットフォーム、民国113年の全国火災15,405件、新北市の電気的要因30.9%、屏東県のタバコの不始末35.2%、5,700台以上のバス、40以上のコレクター、300本以上の列車、アトランタ空港の1,839の航跡、農×水の400MB → 約5MBなど）および全ての引用句（「人間の目では追いきれない」「データがLLMに見えるようになれば、Agentこそが『どのデータを組み合わせて見るべきか』を見つけ出してくれるようになる」「パイプラインは自動生成される。私は　一文字も　書いていない」「目標を与え、報告書を受け取る」「Agentがサイクル全体を自律的に完結できるようになれば、人間の仕事は――問いを出すことと検収することだけになる」「一つのWorker ＝ 一つのtmuxタブ ＋ 独立したSession ＋ 一つのPR」「各ステーションは独立したリポジトリであり、編成層は進捗と意思決定のみを管理し、実務は各リポジトリのWorkerが担う」「実験の進捗は大体半分」など）は、すべてMigu氏本人が当該講演で行った陳述およびスライドの逐語的なテキストであり、講演者の個人的な主張およびそのシステムによる出力であって、Taiwan.mdが独立して検証した政府統計ではない。↩^{234567891011121314151617181920}
4. g0v 零時政府コミュニティ。2012年の中央研究院によるハッカソン「プログラミングで社会を変える」の精神に由来する。2020年のパンデミック期間中、呉展瑋（ウー・ジャンウェイ）氏らが健保署から公開されたマスク在庫データを用いて、数十時間以内に「マスク需給リアルタイムマップ」を作成したことは、台湾シビックテックにおける「キーボードによる救国」の代表的な事例である。↩
5. GitHub API（2026-06-25取得）によれば、ianlkl11234s/taiwan-md は frank890417/taiwan-md（Taiwan.md本体）のフォークであり、2026年3月22日に作成された。Taiwan.mdプロジェクトは2026年3月中旬に誕生している。Migu氏の協働システムはClaude Codeをツール基盤としており（講演ソースコードにはCLAUDE.mdが含まれ、orchestratorは「一つのClaude Session」である）、これはTaiwan.mdと同様である。↩
6. 政府データ公開プラットフォーム data.gov.tw は国家発展委員会によって運営され、2013年に稼働を開始した。運輸データ流通サービスプラットフォーム TDX は交通部により2022年に公路、鉄道、航空、海運、自転車の5大運輸プラットフォームを統合して構築された。内政部の社会経済データサービスプラットフォーム（SEGIS）は村・里レベルの人口データを提供し、交通部中央気象署はオープンAPIを提供している。data.gov.tw のリアルタイムデータセット総数は本稿では独立したAPI検証を行っておらず、本文で採用した「約5万件」はMigu氏の講演スライドに示された数値である。↩