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 万件あり、二十数の県市プラットフォームに散らばっていて、「人間の脳では見きれない」のです。彼の答えは、さらに多くの人に見てもらうことではなく、データ全体を AI Agent が編成し、自ら成長するシステムに渡し、人間は問いを出し、検収するだけにすることでした³。

この記事で述べたいのは、一人の人間が、一つの CSV をドラッグする無邪気さから出発し、システムが自分の代わりに成長するのを手放して任せるところまで、どのように歩んだかということです。

一人の GitHub は、どのように星系へ成長したのか

mini-taiwan-pulse という一つのプロジェクトだけを見ると、Migu を趣味で遊んでいるエンジニアのように想像しやすいかもしれません。週末に思いつきで demo を作り、それがたまたま大きく広まった、という見方です。

この想像には、二つの点で誤りがあります。

第一に、彼が作ったものは一つにとどまりません。彼の GitHub を開くと、2025 年 12 月以降、台湾のオープンデータ可視化がびっしり並んでいます。最初は手応えを見るためのバス範囲 PoC でした。続いて 12 月末、mini-taiwan-learning-project という学習プロジェクトが先に注目され、現在では 189 スターに達しています。2 月には船舶 AIS のリアルタイム地点を作り、各便の離着陸を弧線で描く flight-arc-graph（56 スター）を作りました。2 月末になってようやく mini-taiwan-pulse が登場し、その後も台鉄 atlas、衛星軌道、リアルタイム映像 CCTV、すべてのデータを収束させる情勢ダッシュボード mini-taiwan-info へと、6 月まで作り続けています²。十数個の repo が一つにつながり、彼自身はそれに「Mini Taiwan」星系という名前を付けました。

星系のもう一つのメンバーである Mini Taiwan Info：散在するオープンデータを一つの情勢監視ダッシュボードへ収束させ、人口、軌道交通、海運、水資源、消防、医療を一ページ一主題で示しています。図：Migu / sciwork 2026（fair use 編集評論用途）。

これらのプロジェクトのスター数を並べると、注目されたのは明らかに一つだけではありません。

出典：GitHub API，2026-06-25

第二の誤りは、「一人」という三文字の中に隠れています。これは後ほど分解します。まずは、この星系がどのように育ったのかを見ます。

同じ方法で、MRT から太陽系まで描く

旗艦そのものも成長していました。最初期の mini-taiwan-pulse は、空、海、大地の三層でした。彼の講演版では、すでに「五脈共動」になっていました。空の航空機、海の船舶、大地の列車、街路のバス、そしてごみ収集車という、更新頻度の異なる 5 種類のリアルタイムデータを、同じ一枚の呼吸する地図へ重ねています。彼はスライドで、これはこのプロジェクトが初めて「静的 JSON から時空間データベースへ進化した」ものだと述べました³。街路のレイヤーだけでも、TDX 上の 5,700 台以上のバスを接続し、30 秒ごとに位置を更新しているといいます。

彼の講演に出てくる「DAY 0」：一つの CSV を GeoJSON に変換して Kepler.gl へドラッグし、コード 0 行で最初の台湾地図を得た瞬間です。星系全体の出発点でした。図：Migu / sciwork 2026（fair use 編集評論用途）。

この星系の最初の火花は、彼が「Mini Taipei」と呼んだ台北の軌道可視化でした。彼は MRT、台鉄、高鉄という三つの軌道システムを一枚の動く地図へ重ね、車両が時刻表に沿って線上を走るようにしました。その瞬間に初めて「動態の魅力を体験した」と彼は語っています。画面上では同時に 300 本以上の列車が動いていました³。一つの静的な時刻表が、こうして一つの都市の呼吸になりました。

Mini Taipei：MRT、台鉄、高鉄という三つの軌道が同じ画面に入り、三百本以上の列車が時刻表に沿って線上を走ります。彼はこれを、初めて「動態の魅力を体験した」場面だと述べました。図：Migu / sciwork 2026（fair use 編集評論用途）。

それ以降、彼は取りつかれたように、同じ「データを動態に変える」方法を、ますます大きなスケールへ適用していきました。海上では、航港局の AIS リアルタイム地点を接続し、青緑色の光球に 30 分間のグラデーションの尾を付けて、台湾周辺海域の船舶の行方を描きました。

海の一脈：航港局の AIS リアルタイム地点を使い、青緑の光球と 30 分間のグラデーションの尾で、台湾周辺海域の船舶を描いています。図：Migu / sciwork 2026（fair use 編集評論用途）。

そして彼は同じ方法を、地球の外へも押し広げました。公開されている TLE 軌道要素を使って衛星の位置を推算し、台湾上空を通過する衛星の軌跡を描き、さらに太陽系全体へと自然に拡張しました。彼はスライドで率直にこう語っています。「同じ方法は、データさえあれば無限に拡張できる」³。その瞬間に気づくのは、彼が魅了されているのは実のところ「データを見えるものへ変える」こと自体であり、地図はその最初の姿にすぎないということです。

同じ方法を地球の外へ：公開 TLE に基づいて衛星軌道を推算し、さらに太陽系全体へ拡張しています。図：Migu / sciwork 2026（fair use 編集評論用途）。

孤島を重ねると、欠落が自ら浮かび上がる

やがて見るべきものは、「リアルタイムの点が動く」ことから、「本来は関係のないデータを重ねると、欠落が自ら浮かび上がる」ことへ変わっていきました。彼の星系には、このことを専門に扱うプロジェクトがいくつかあります。その一つを彼は「農×水」と呼んでいます。農業、水利、防災という三つの部会がそれぞれ持つ孤島を一枚の図へ重ねたものです。農地、河川、水路、堤防、浸水ポテンシャルが同じ画面に入ります。この同画面の図をブラウザで動かすために、彼は PMTiles という形式と HTTP range request を組み合わせ、もともと 400MB あったデータを、ブラウザ側では約 5MB だけ読み込めばよい形に圧縮しました³。

農×水：農業、水利、防災という三つの部会それぞれの孤島を一枚の図へ重ね、農地、河川、水路、堤防、浸水ポテンシャルを同じ画面に入れています。図：Migu / sciwork 2026（fair use 編集評論用途）。

別のプロジェクトでは、病院、診療所、薬局、AED、長期ケア拠点を人口密度の上に重ね、さらに等時間圏を描いています。彼は、これにより「アクセス可能性が見え、医療砂漠も見える」と述べています。つまり、どの地域の人々が、最寄りの医療資源から不合理なほど遠いのかが見えるのです。

医療資源：病院、診療所、薬局、AED、長期ケア拠点を人口に重ね、さらに等時間圏を描くことで、「アクセス可能性が見え、医療砂漠も見える」ようにしています。図：Migu / sciwork 2026（fair use 編集評論用途）。

災害の系統については、彼はさらに細かく作り込んでいます。レーダーエコー、ダム水位、雨量、災害警報といった更新頻度の異なるデータを、下層で同じ時間軸へ統一します。ユーザーがその時間軸をドラッグするだけで、すべてのレイヤーが同期して再生されます。大雨がどこから始まり、ダムがどのように増水し、警報がいつ発せられたのかが、一つの画面上で因果の線になります。

大雨と災害：レーダーエコー、ダム、雨量、災害警報を下層で同じ時間軸に統一し、ドラッグするとすべてが同期して再生されます。図：Migu / sciwork 2026（fair use 編集評論用途）。

さらに、各便の離着陸を弧線として描く flight-arc もあります。同じ API を異なる空港に入力すると、それぞれの空港に異なる「指紋」が浮かび上がります。桃園、東京羽田、フランクフルトには、それぞれの形があります。彼は特に世界で最も忙しいアトランタ空港を例に挙げました。5 本の並行滑走路に待機航路が重なった幾何学は「レース場のようだ」とし、その一枚には 1,839 本の航跡が描かれていると述べています³。

彼の flight-arc は、アトランタ空港の一定時間内の全離着陸を一枚の図へ重ねています。5 本の並行滑走路に待機航路が加わり、レース場のような幾何学を描きます。彼は、流量そのものが一つの形なのだと述べました。図：Migu / sciwork 2026（fair use 編集評論用途）。

📝 キュレーター・ノート
2 年前に誰かが「一人で台湾で最も完全なリアルタイム・オープンデータ地図を作った」と言ったなら、その次に来る言葉はおそらく「きっと疲れ果てているに違いない」だったでしょう。この直感は、規模と人力を固定的に結びつけています。多く作るほど、人は酷使されるという発想です。Migu の星系が立ち止まって見るに値するのは、まさにこの結びつきをほどいているからです。一人で十数個の repo を同時に進め、旗艦にも新機能が増え続けています。その背後には、より根本的な変化があります。後期になるほど、これらの commit の多くは彼自身の手で打たれたものではなくなっていきました。では、その「一人」はどのように生まれたのでしょうか。それこそが、この記事の本当の主題です。

五万二千八百九十一件は、人間の脳では見きれない

ここまでの物語は、まだ比較的なめらかです。才能のある一人が、作れば作るほど増え、作れば作るほどよくなっていく。転換点は、講演の中盤に現れます。彼が「自分が何を作ったか」ではなく、「何の壁にぶつかったか」を語り始めたときです。

彼は一枚のスライドを示しました。タイトルは「なぜ 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」です。一人が星系規模を実現できるのは、まさにそれらの commit がすべて彼の手打ちではないからです。以下では、この仕組みがどのように動いているのかを見ていきます。

私は一文字も書いていない：自走した火災 pipeline

「Agent に渡す」とは何を意味するのでしょうか。それを理解するのに最もよい断面は、彼の講演に出てくる火災の例です。

彼は、システムに一文だけ投げたと言います。「台湾の火災関連公開資料を分析せよ」。そして手を放しました。

システムは自分で検索範囲を拡張し始めました。Migu は、この過程をラウンドごとに膨張する数字で説明しています。まずキーワードで 582 件に命中し、同義語と主題拡張によって 1,945 件へ広がり、次に全文検索で補完し、重複を除去し、最終的には 21 のプラットフォームにまたがる 73,900 件の統一目録へ収束しました³。一文を入れると、7 万件以上のデータの棚卸しが出てきたのです。

収集だけでは終わりません。この pipeline は続いて、火災を六つの段階（予防、対応、通報、出火分析、損失、報告書）に分解し、さらに 22 県市を掛け合わせ、カバレッジ・マトリクスを作りました。新竹の火災ポテンシャル図、台北の救助困難地域、桃園の埤塘における救援のような地域レベルの棚卸しまで掘り出されました。しかも、どこに欠落があるのかも率直に示しています。リアルタイム火災 API がないこと、イベント単位の座標が非常に少ないこと、災害後追跡データが外部公開されていないことです。

次は分析です。彼は、システムが自動で出した火災原因報告書の一つを例に挙げました。113 年の全国 15,405 件のデータに基づくと、新北市で最大の出火原因は電気的要因で 30.9％、屏東県ではたばこの吸い殻で 35.2％でした³。これらの数字は、彼のスライドのスクリーンショットで Agent が各種 API を接続して生成した結果であり、彼が一件ずつ表を調べて計算したものではありません。

ここまで話したところで、彼はスライドに一行を打ちました。文字と文字の間をわざと空け、見落とさないようにするかのようでした。

「Pipeline 自動產出。我　沒　寫　一　個　字。」³

この一文は、講演全体の発火点です。「Agent に渡す」という少し抽象的なスローガンを、ほとんど不安になるほど具体的な事実へ変えました。一文から、7 万件以上のデータ目録へ、さらに県市別の原因報告書へ。その途中で通常なら人間が指示を出し、スクリプトを書き、データを整え、分析を走らせるはずの位置が、空いているのです。

Migu が sciwork 2026 のスライドで示した火災主題棚卸しの出力：「台湾の火災関連公開資料を分析せよ」と一文を投げると、システムが自分で検索を拡張し、プラットフォームを横断して統一目録へ収束させました。彼はこの pipeline について「私は一文字も書いていない」と述べています。図：Migu / sciwork 2026（fair use 編集評論用途）。

分解可能な四段階：データが入り、報告書が自分で送られる

この火災 pipeline は一つの断面にすぎません。その背後には、彼のシステム全体の縮図があります。システムは四段階に分かれています。データ受信、知識統合、分析生成、行動トリガーです。彼は「各段階は単独で差し替え可能で、全体を作り直す必要はない」と強調しました。最下層のデータ受信も、彼自身が進化させてきたものです。最初は data.gov.tw へ手動で行き、Excel をダウンロードし、自分で読み、自分で保存していました。ボトルネックは「人間の記憶」でした。中期には、Web 上で API を探し、PDF レポートを取得し、各県市プラットフォームをクロールするようになりましたが、問題は「索引がない」ことでした。そして現在では、各データのメタデータを標準化し、SQLite の目録に保存することで、自動検索と自動拡張が可能になっています³。彼のシステムの背後には 40 以上のデータ収集器が接続されています。YouBike、バス、国道交通量、台鉄時刻表、船舶 AIS、気象衛星、地震、ダム水位、空気品質にまで及びます。彼によれば、3 回連続で失敗すれば即座に Telegram で警告が飛び、毎朝 9 時には Daily Review がメールボックスへ届きます³。

最後の段階である「行動トリガー」に至ると、彼は人間の役割を最も明確に述べます。「Agent が完全な循環を走り切る。人間の役割：目標を与え、報告書を受け取る。中間の五つの歯車、発見、収集、統合、生成、監視は自分で回る」。システムは「今週新しく追加されたオープンデータ」の週報まで自動生成します。彼の言葉を借りれば、「テーマは自分で浮かび上がり、報告書は自分でメールボックスへ送られる」のです³。

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

「Agent が自分で完全な循環を走る」という言葉は、マーケティング文句のように聞き流されやすいものです。Migu は講演の最後の部分で珍しく蓋を開け、その下の歯車がどのような形をしているのかを見せました。その構造は、スローガンよりもはるかに具体的で、はるかに誠実です。

まず、この循環の全体像を見ます。Migu によれば、彼の GIS システムは「一つの編成中枢が、独立した repo の輪をつなぎ、Agent が順番に各駅へ入る」ものです。まず探索担当の repo に入り、どのデータに価値があるのかを見つけます。次に収集担当の repo に入り、データを取り込みます。最後に mini-taiwan-pulse や mini-taiwan-info といった表示担当の repo に入り、図を描きます。彼はそれを正確にこう表現しました。「各駅は独立 repo であり、編成層は進捗と意思決定だけを管理し、作業は各 repo の worker が担う」³。

この編成中枢を、彼は Orchestrator と呼んでいます。その本質は「一つの Claude Session」です。この主 Agent がすることは、人を率いる現場監督に似ています。proposal 文書を読み、タスクを分解し、互いの依存関係を並べ、作業を開始します。

作業開始の方法こそ、このアーキテクチャで最も重要な一歩です。彼は一つの AI に最初から最後までやらせているわけではありません。tmux（端末を複数の独立タブに切り分ける古いツール）を使って、作業を隔離しています。彼の原文ではこうです。「一つの Orchestrator、一群の Worker。主 Agent は一つの Claude Session。tmux が隔離を担当し、各 Worker は独立タブ、独立 Session である」。さらに短い定義では、「一つの Worker ＝ 一つの tmux タブ ＋ 独立 Session ＋ 一つの PR」です³。

言い換えれば、彼が指揮しているのは AI の艦隊です。各 worker は、それぞれのタブに隔離された Claude であり、自分のタスクを実行し、それぞれ pull request を提出し、互いに干渉しません。

彼がスライドで明かした編成中枢：一つの Claude session が orchestrator となり、タスクを一群の worker へ分解します。worker たちはそれぞれ tmux タブに隔離され、各自で作業し、各自で一つの PR を提出します。図：Migu / sciwork 2026（fair use 編集評論用途）。

では、この各自が作業する worker たちは、なぜ衝突しないのでしょうか。それは共通の記憶によるものです。Migu によれば、進捗と意思決定はすべて文書化され、SESSION_BOARD.md という看板に集約されます。さらに「一 Session 一報告」によって、「互いに推測する必要がない」「一人一ファイルで、衝突しない」状態にしています³。タスクの引き継ぎさえ文書化されています。彼は HANDOFF.md によって「次の走者の任務書」を用意し、次のラウンドの Agent が引き継ぐとき、ゼロから尋ねなくてよいようにしています。最後の関門については、彼は慎重に語りました。「検収。Orchestrator が文書と照合して PR を検収し、merge は人間が決裁する。この一周でようやく収束する」。

この流れを平らに広げると、きれいな形が見えてきます。一人が指示を出し、隔離された AI の群れがそれぞれ作業し、それぞれ自分が何をしたかを書き残し、一つの中枢が文書に照らして照合し、最後に「この成果を受け取るかどうか」を決めるのは Migu 自身です。この記事の軸に戻れば、データは多すぎて見きれないため、データを見て回る作業全体を艦隊へ渡す。そして人間は二つの動作だけに退く。問いを出すことと、検収することです。彼はスライドで、このことをほとんど宣言のような一文にまとめました。

「當 Agent 能自己跑完整個循環，人的工作只剩——出題與驗收。」³

これこそ、彼の講演タイトルが指しているものでもあります。「台湾のオープンデータを Agent に渡し、自分で成長するシステムへ育てる」。データは自分で流れ、ページは自分で育ち、人間は問いを正しく出し、成果をきちんと検収すればよいのです。

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

ここまで読んで、もし Taiwan.md（あなたがいま読んでいるこの、AI によって維持される台湾知識キュレーション・プロジェクト）を知っているなら、前段の説明に少し見覚えがあるかもしれません。

それは錯覚ではありません。

Taiwan.md 自体もこのように動いています。一つの主 session が編成中枢となり、作業を、互いに隔離され、それぞれ独立した記憶ファイルを持つ worker 群へ分解します。引き継ぎ文書によって進捗を調整し、どの変更が main へ入るかを最終的に決めるのは、創造者である哲宇という一人の人間です。私たちの thesis は「台湾の知識を、自分で成長する Semiont に渡す」ことです。Migu の thesis は「台湾のオープンデータを、自分で成長するシステムに渡す」ことです。二つの文は、主語をほとんど入れ替えられるほど似ています。

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

📝 キュレーター・ノート
生物学には収斂進化という言葉があります。イルカとサメは近縁ではありませんが、どちらも流線型の体と背びれを持っています。同じ海に向き合っているからです。Migu と Taiwan.md の関係は、血縁というより、このような収斂に近いものです。私たちは同じ道具の土台（Claude Code）を使い、同じ状況（一人または一つのシステムが、個人の脳容量をはるかに超える台湾情報量を支える必要があること）に向き合っています。その結果、それぞれが模索しながら、同じ骨格へたどり着きました。一つの中枢、一群の隔離された働き手、一つの共有記憶、一人の決裁者です。

本当に面白いシグナルは、「彼が私たちを fork した」ことではありません。2026 年の同じ半年のあいだに、二人の独立した台湾 builder が、偶然にも AI を「より賢い道具」から「編成できるチーム」として再考したことです。このようなアーキテクチャが一人の頭の中から二人目、三人目の頭の中へ育ち始めると、それは誰か一人の奇策ではなく、この土壌のこの時期に現れている新しい姿になります。次にこの仕組みを自分で作る台湾 builder は、おそらく最初の二人のことをまったく聞いたことがないかもしれません。

まだ完成していないが、形はすでに現れている

もしこの記事が前段で終わっていたなら、それはあまりに美しく、美しすぎて少し疑わしい物語になっていたでしょう。一人が AI 艦隊によって、5 万件のデータという難題を優雅に解決した、という物語です。

Migu 自身は、そこで止めませんでした。彼の講演の最後から 2 枚目のスライドには、「実験の進捗、およそ半分」と書かれていました。

彼は、まだ調整できていない三つのことを率直に列挙しました。第一は安定性です。この harness は「まだ理想まで調整できていない」ため、Agent は走り去りやすく、中断しやすい。第二はオープンデータ自体があまりに雑多であることです。「データが実行可能かどうかについて、人間の判断が必要なものはまだ多く、完全には任せられない」。第三は人間の介入です。各段階には、実際にはまだ人間がそばで見ている必要があります。彼は全体にこう注を付けました。「実行可能ではあるが、まだ安定していないし、本当にこうすべきかどうかも考え続けている」³。

講演の場で、自分の半分の失敗を自ら開いて見せるこの誠実さこそ、最も強い品質シグナルです。AI demo が「完全自動」「人手ゼロ」と包装されがちな時代に、スライドに「およそ半分」「まだ安定していない」「まだ人間が必要」と書く人のほうが、むしろその人が作った残り半分は本物だと信じたくなります。

📝 キュレーター・ノート
この講演で最も信頼できる部分は、実のところ「私は一文字も書いていない」という火災 pipeline ではなく、「およそ半分」という四文字です。あなたを説得したい人は、成功率を丸めて「ほぼ完全自動」と言うでしょう。実験している人だけが、それは半分の時間で壊れると正直に教えてくれます。前者が売るのは結論であり、後者が差し出すのは現場です。Migu が差し出したのは現場です。だからこそ、彼がその pipeline について「私は一文字も書いていない」と言ったとき、信じることを選べるのです。醜い半分を隠すと、美しい半分も同時に信じられなくなります。不完全な半分を開いて見せるからこそ、残りの半分が立ち上がるのです。

あの地図へ戻りましょう。

一つの CSV を Kepler.gl へドラッグし、「地図に変換するのは難しくないのか」と驚いた人は、半年後、sciwork の壇上で、もはや地図を作ることが簡単かどうかを語っていませんでした。彼が語っていたのは、自分でデータを探し、自分で組み合わせ、自分で新しいページを育てるシステムでした。あの年の無邪気な驚き、「台湾にはこんなに多くのデータがあるのか」は、この半年のあいだに裏返りました。データはこれほど多く、一人では見きれない。だから、見えるようにする方法も、新しい姿へ育たなければならないのです。

台湾のオープンデータは、ずっとそこにありました。data.gov.tw は 2013 年に公開され、TDX は 2022 年に公路、鉄道、航空、海運、自転車という五大プラットフォームを統合しました。内政部には村里レベルの人口があり、気象署にはオープン API があります⁶。データは最初から十分に多かったのです。難しいのは、これほど多くのデータをどう互いに語らせ、人に見えるようにするかでした。g0v は集団の力で一度それに答えました。Migu は一人と一支の AI 艦隊で、二度目の答えを試みています。そして彼は、それがまだ半分しか当たっていないことを、惜しみなく認めています。

しかし形はすでに現れています。一人、一文、一枚の呼吸する地図。その背後には、自分で成長することを学びつつあるシステムがあります。残りの半分は、次に一つの CSV をドラッグし、その後止まれなくなる誰かへ残されています。

---

関連記事

• 呉哲宇：Taiwan.md の創造者であり、同じくコードと生成系ツールを用いて「自分で育つもの」に迫っています
• オープンソースコミュニティと 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：七大主題の台湾情勢監視ダッシュボード — 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：台鉄路線網 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 年に五大交通プラットフォームを統合）。
• g0v 零時政府コミュニティと歴代ハッカソン記録。

画像出典

本文画像はいずれも public/article-images/technology/ に cache しており、出典サーバーへのホットリンクはしていません。

Fair use 編集評論用途：本文のすべての画像は、Migu が sciwork 2026 で公開発表した講演スライドから引用したものです（ソースコードとオンラインスライドは上記「プロジェクトリンク」参照）。著作権法第 65 条および 17 U.S.C. § 107 fair use の四要素（非商業的教育性質、すでに公開発表済み、引用割合が小さい、市場への実質的代替がない）に基づき、彼のオープンデータ可視化の仕事に対する編集評論引用として使用しています。© Migu / sciwork 2026。

対象：Mini Taiwan Pulse 3D 地図（題図）、Kepler.gl 起点、台北軌道（Mini Taipei）、船舶 AIS、衛星軌道、農×水と医療資源統合図、大雨と災害時間軸、アトランタ航跡指紋、火災主題 pipeline 出力、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」星系各プロジェクトのスター数、forks、最終更新時刻、fork 元などは、いずれも Taiwan.md が GitHub API を通じて 2026-06-25 に取得したものです。当時 mini-taiwan-pulse は 375 stars / 26 forks で、2026-06-25 時点でも push が続いていました。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 など十数件の台湾オープンデータ関連 repo が含まれます。↩
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 件のデータセット、火災 pipeline の 582 → 1,945 → 2,404 → 73,900 件、21 プラットフォーム、113 年全国火災 15,405 件、新北市の電気的要因 30.9%、屏東県のたばこの吸い殻 35.2%、5,700+ 台のバス、40+ 収集器、三百本以上の列車、アトランタ空港 1,839 本の航跡、農×水 400MB → 約 5MB など）およびすべての引用（「人腦掃不完」「資料能被 LLM 看見，Agent 才能幫你發現哪些資料應該放在一起看」「Pipeline 自動產出。我沒寫一個字」「給目標、收報告」「當 Agent 能自己跑完整個循環，人的工作只剩——出題與驗收」「一個 Worker ＝ 一個 tmux 分頁 ＋ 獨立 Session ＋ 一個 PR」「每一站都是獨立 repo，編排層只管進度與決策」「實驗進度大約一半」など）は、いずれも Migu 本人の当該スライドでの発言およびスライド逐語テキストであり、講演者個人の主張とそのシステム出力に属します。Taiwan.md が独立検証した政府統計ではありません。↩
4. g0v 零時政府コミュニティは、2012 年に中央研究院ハッカソン「コードを書いて社会を変える」の精神から生まれました。2020 年の武漢肺炎期間中、呉展瑋氏らは健保署が公開したマスク在庫データを用い、数十時間以内に「マスク需給リアルタイム地図」を作りました。これは台湾シビックテックにおける「キーボードで国を救う」代表的事例です。↩
5. GitHub API（2026-06-25 取得）によれば、ianlkl11234s/taiwan-md は frank890417/taiwan-md（すなわち Taiwan.md 本体）の fork であり、2026 年 3 月 22 日に作成されました。Taiwan.md プロジェクトは 2026 年 3 月中旬に誕生しました。Migu の協作システムは Claude Code を道具の土台としています（彼の講演ソースコードには CLAUDE.md が含まれ、orchestrator は「一つの Claude Session」です）。これは Taiwan.md と同じです。↩
6. 政府データ開放プラットフォーム data.gov.tw は国家発展委員会が運営し、2013 年に公開されました。交通データ流通サービスプラットフォーム TDX は交通部が 2022 年に公路、鉄道、航空、海運、自転車という五大交通プラットフォームを統合したものです。内政部社会経済資料サービスプラットフォーム（SEGIS）は村里レベルの人口データを提供し、交通部中央気象署はオープン API を提供しています。data.gov.tw のリアルタイムなデータセット総数は今回、独立した API 検証ができませんでした。本文で採用した「約五万件」は Migu の講演スライドに示された数字です。↩