1. リード
バラバラだった接続が、ある日まとまって見えた。GA4、Search Console、Clarity、Metricool——それぞれ別の画面、別のスクリプト、別の「とりあえず動いた」記憶だった。朝の確認は、まだつらかった。だが connectors/ という一つの置き場に日次データが溜まり始めたとき、感覚が変わった。つながった、というより、同じ地図の上に乗った感じだった。
非エンジニアの私にとって、それは技術的な勝利というより、心理的な区切りだった。散らばっていたものが、名前と責務を持ち始めた。名前があると、会話が短くなる。短い会話は、判断が速くなる。速い判断は、朝の 10 分に近づく。
2. 背景
Vol.05 で SQLite を選んだ話を書いた。選んだ理由は「履歴を残すため」だった。選んだあとに残った課題は、誰がいつ何を入れるかだった。MCP でライブに見る方法は残した。だがライブだけでは、昨日との比較ができない。比較できないと、改善の方向が決められない。
接続は増えていた。WordPress、SEOPress、WP Rocket、Obsidian、GitHub、Canva、Make——それぞれに意味があった。だがデータを毎日溜める系と、対話しながら調べる系が混ざると、頭の中がごちゃごちゃになる。ごちゃごちゃは、AI の提案を受け入れやすくする。受け入れやすいと、また範囲が広がる。広がった範囲は、レビューで戻る。戻るコストは高い。
だから「全部を同じ型にする」誘惑が来た。来るたびに、一つだけ止めた。無理に同じ型にしない。型を揃えることと、全体を理解することは別だ。理解のために、Connector Platform という言葉を採った。
3. 今回のテーマ
テーマは、散らばっていた接続が Connector Platform として一つの運営地図になった日だ。
Connector Platform とは、派手な製品名というより、運営の整理術に近い。日次で SQLite に溜めるものは connectors/ に置く。取得、変換、保存、実行ログ——流れを共通化する。名前は {source}_{granularity}。例えば ga4_daily、gsc_daily、clarity_daily、metricool_daily。名前が揃うと、朝の確認が「どのコネクタが最後に動いたか」から始められる。
一方で、全部をバッチに押し込まない判断も同時にあった。Ubersuggest はその代表例だ。
4. 実際の出来事
Connector Framework の設計から始まった。Step25 では Python を書かず、仕様とテンプレートだけ置いた。命名、責務、エラー、ログ。地味な文書だが、地味な文書が後の実装の速度を決める。実装が始まると、GA4、Search Console、Clarity、Metricool の日次コネクタが順に増えた。
私が体感した変化は、ダッシュボードの数字ではなかった。 system_connector_runs に行が増える安心感だった。成功、部分成功、失敗、スキップ——状態に名前がある。名前がない失敗は、ただの「なんか動かない」になる。名前があると、次に何を直すかが分かる。
Metricool は OAuth の話も絡んだ。認証ファイルの有無でスキップする、という現実的な振る舞いができたとき、理想の自動化より信頼できる自動化に見えた。動かない日があっても、嘘をつかない仕組みの方が、運営には合う。
Ubersuggest は別ルートだった。調査の結果、Python の日次コネクタには入れないと決めた。Cursor 上の Interactive MCP として残す。Interactive MCP Connector——対話の中で参照し、履歴には無理に載せない。載せられないものを無理に載せると、壊れる。壊れた信頼は、直すのに時間がかかる。
失敗談もある。最初は「コネクタさえ増やせば全部解決」と思いかけた。増やすとテーブルは増える。増えたテーブルを誰が朝に見るか、が決まっていないと、ただの倉庫になる。倉庫は、データがあることを証明しない。使われることが証明だ。だから Dashboard の話へ自然に進んだ。Platform は、画面とセットで初めて意味を持つ。
もう一つの失敗は、用語のブレを放置したことだ。MCP、API、Abilities、Connector——全部つながった日だからこそ、言葉が揺れると地図が二枚になる。後の Architecture Review で用語を揃えることになるが、その前に私は何度も「これ MCP だよね？」と聞き返していた。聞き返す時間は、無駄ではない。ただ、早めに文書化した方が安い。
Platform 以前は、接続の成功が個別の祝杯だった。Platform 以後は、最後に動いたコネクタと SQLite の行数が、全体の健康診断になった。健康診断があると、改善の優先順位が付けられる。付けられると、AI への依頼が具体になる。「全部改善して」ではなく、「Metricool が skipped なので認証を見て」になる。具体は、暴走を止める。
GA4 と Search Console のコネクタを別々に動かしていた頃は、成功通知が来るたびに一安心していた。だが二つ成功しても、朝の判断は楽にならなかった。楽になるのは、同じ run ログの形式で昨日と今日が並ぶときだ。並ぶと、「どちらかだけ止まっている」が一目で分かる。片方だけ止まっている状態は、運営ではよくある。あるからこそ、見える化が要る。
Imagify や WP Rocket のような WordPress 周辺は、Abilities や MCP という別の入口も持つ。Platform 化は、それらを消すことではない。消すと現場が混乱する。混乱は、非エンジニアの負担になる。入口が複数あっても、日次の分析データは一本の川に流す——その約束だけ守れれば、地図は読める。
5. 考えたこと
全部つながった、という表現は少し大げさかもしれない。完璧に統一されたわけではない。Interactive MCP は別枠だし、WordPress 系は Abilities もある。だが、日次の分析データが一本の流れになったことは事実だ。事実があると、Version の話ができる。Version は、機能の数ではなく、運営者が説明できる単位だ。
また、Platform 化は「自動化の完成」ではない。むしろ逆だ。何を自動で回し、何を人が見るかの線引きが、はっきりし始めた。コネクタとレポートとバックアップは、原則として自動化の側に置ける。公開、削除、設定変更、SNS——そちらは別の話になる。別の話には、別の思想が要る。次の回で書く Human Approval が、その入口だ。
非エンジニアがここまで来られたのは、コードを書いたからではない。散らばりを認め、名前を付け、型を二つに分け、失敗をログに残したからだ。残せるようになったのは、AI が実装し、私が「これは同じ箱に入れない」と言えたからだ。
振り返ると、Version 0.3 の話は「実装が終わった」話ではなく、「散らばりに名前が付いた」話に近い。名前が付いた瞬間、README や CHANGELOG の更新も意味を持ち始めた。更新は地味だが、チームが二人——私と AI——でも、同じ過去を参照できる。参照できる過去は、暴走後の立ち直りを速くする。
また、全部つながったからといって、毎朝が魔法のように楽になるわけではない。楽になるのは、迷うポイントが減ったからだ。迷いが減ると、残った迷いに集中できる。集中は、非エンジニアの希少な資源を守る。Connector Platform は、そのための土台だった。
6. 学び
- 接続が増えても、日次蓄積と対話参照は分けた方が壊れにくい
-
connectors/と SQLite で、昨日との比較が可能になった - 実行ログに status があると、朝の判断が速くなる
- 全部を同じ型にしない判断（Interactive MCP）は、無理な自動化を避けた
- Platform は画面とセットで、はじめて運営地図になる
- 用語のブレは、つながった後にじわじわ効いてくる
7. 次回予告
次は、自動化と承認の境界——Human Approval という思想——を書く。つながったあとに、いよいよ「やってよい操作」の話が本題になる。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 06 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回予告
Vol.07「Human Approvalという思想」
AI は提案する。公開・削除・設定は人が承認する——その線引きを書きます。