本記事は、Kagoshimaniax OS を Version 1.0.0-rc1 まで育てたあとに、当時の時系列で書き直した記録です。技術解説ではなく、非エンジニアの判断のメモです。
シリーズ Vol.1: コードを書けない私がAIと運営OSを作ることになった話
MCP という言葉を初めて見たとき、私はプロトコルの仕様書を読める人間ではなかった。JSON のスキーマを追うより先に、直感で理解したつもりになった。「AI が、いろいろなサービスに同じ作法で触れるための口」。
地域メディアの運営は、サービスが増えるほど管理画面が増える。ログインが増える。確認の順序が属人化する。そこに「同じ会話の中で触れる」という選択肢が現れた日の話を書く。出会いの興奮と、すぐに訪れた教義化の迷いを、当時の順番で残す。
背景
Vol.01 で書いた通り、起点は朝の確認コストだった。WordPress を中心に、分析や SNS、メモが周囲にある。AI（Cursor）はすでに日常にあったが、サイトの中身や分析の数字を、会話の文脈として安定して渡す手段が弱かった。毎回リンクを貼り、画面を説明し、前提を言い直す。その手間が、AI 活用の天井になっていた。
「またプラグインを入れる」「また別のダッシュボードを覚える」以外の道がないか。その問いの近くに、MCP があった。新しい画面を増やすのではなく、いま話している相手（AI）に、現場への手を渡す。そのイメージが、非エンジニアの私には刺さった。
Kagoshimaniax OS の最初の構想は、かなり素直だった。MCP を統合し、運営を効率化する。 WordPress を中心に、AI からサイトや分析、ツールへアクセスできる状態を作る。ただし、いきなり自動投稿はしない。読むことから始める。この「読むことから」は、興奮を抑えるための最初のルールでもあった。
今回のテーマ
テーマは、MCP という考え方に出会ったときの理解・期待・迷いだ。
技術的に正しい定義を講義するのが目的ではない。非エンジニアの私が、何を「便利」と感じ、どこで「全部 MCP にすればいいのか？」と迷い、最終的にどう位置づけを変えたか——その過程を書く。出会いの日の理解は、後から見ると粗い。粗いまま残す。洗練された後知恵で上書きしない。
実際の出来事
最初の具体的な一歩は、WordPress MCP の接続だった。サイトの文脈を AI から直接引ける。管理画面の往復が減る感覚があった。「つながった」という実感が、OS 構想を抽象から具体に引き下ろした。ここがなければ、たぶん大きな絵のまま終わっていた。小さな成功が、次の接続を正当化した。
Phase 1 は読み取り専用だった。記事を見る、検索する、状況を把握する。公開や削除は封印したまま。つながる快感は、すぐに「書ける」へ行きたくなる。だが地域メディアの公開はブランドと事実確認が絡む。出会いの興奮で権限を広げない——これは技術というより自制の設計だった。
その後、接続は増えていく。分析系、制作系、ナレッジ、コード。HTTP OAuth のもの、stdio のもの。Cursor の中では動くのに、CLI では認証が違う、という現象にも出会う。同じ「つながっている」でも、対話の中で使うのか、定期実行で使うのかで、体験がまるで違った。この違和感は、後の Interactive MCP という分類の伏線になる。当時はただ、「なんか別物だな」と思っていた。
ここで迷いが生まれた。MCP が中核なら、すべてを MCP 経由に揃えるべきなのか。一方で、GA4 や Search Console のような安定したバッチ取得は、公式 API の方が素直に見えた。AI との議論でも、「MCP だけに寄せる案」と「API も正式な接続として認める案」が並んだ。私は最初、MCP 中心の夢に引っ張られた。全部が会話で操作できる世界は魅力的だ。統一されている方が美しい。美しいものは正しい、と錯覚しやすい。
だが運営の現実は、毎日決まった数字を溜め、昨日と比較することでもある。対話に向くものと、定期実行に向くものは違う。美しさより、朝の再現性を取った。
方向修正の結論は、あとから ADR にもなるが、当時の言葉で言えばこうだった。
MCP は重要な統合レイヤーとして残す。ただし API や Abilities も否定しない。接続方式が違っても、運営上は「つながっているサービス」として扱う。
つまり MCP 否定ではない。MCP だけ教義にしない、という成熟だった。出会いの日の興奮を捨てるのではなく、興奮を役割に分解した。
接続の役割分担は、だんだん表に落ちた。
| 接続の種類 | 向いていた用途 | 当時の判断 |
|---|---|---|
| WordPress MCP | 記事・サイト文脈の対話的参照 | 最初の一歩。Phase 1 の中心 |
| GA4 / GSC API | 毎日の数字の安定取得 | MCP より API を正式採用 |
| 制作・ナレッジ MCP | 深掘り・調査・下書き | 対話向きとして残す |
| 定期バッチ全般 | 履歴の蓄積 | API 経由を優先 |
失敗談もある。接続が増えると、「何が繋がっているか」が見えなくなった。個別には成功しているのに、全体としては散らかる。パスワードや OAuth、設定ファイルの場所が頭の中で混線する。そこで Connected Services のような可視化が必要になった。MCP を増やせば増やすほど、ポートフォリオ管理が必要になる——これは出会いの日には見えていなかった。つなぐことが上手くなるほど、一覧する責任が増える。
もう一つの失敗は、接続成功を目的化してしまったことだ。「つながった」で満足し、その接続が朝の判断にどう効くかを後回しにした回がある。接続は手段だ。手段が目立つと、目的が霞む。霞んだ目的は、次の暴走の入口になる。WordPress MCP が動いた日、私は一瞬「もうできた」と思いかけた。だが朝の 10 分は、まだ生まれていなかった。
認証まわりでも迷った。OAuth は Cursor 上では通るのに、ターミナルからの定期実行では別の設定が要る、という場面があった。同じサービス名でも、対話用とバッチ用で設定が二重になる。二重になると、どちらが壊れているのか切り分けにくい。当時は「MCP が壊れたのか API が壊れたのか」と自分で混乱した。後から振り返ると、接続の種類を先に分類しておけばよかった、と分かる。分類は、増やす前にやる仕事だった。
Step 単位で進めたことも、この時期の防波堤になった。WordPress MCP、記事の保存、GA4 API——一度に一つ。全部つなぐ絵を先に描くと、どこまでが今週の成果かが曖昧になる。曖昧な成果は、レビューできない。レビューできない接続は、つながっているように見えて、運営には効いていない。
考えたこと
非エンジニアにとって、新しい技術語は二種類ある。自分の痛みに刺さる語と、刺さらない語だ。MCP は前者だった。だからこそ危険でもある。刺さった瞬間に、すべてをその語で説明したくなる。説明できると、分かった気になる。分かった気は、検証を遅らせる。
私は AI に何度も聞いた。「これは MCP でやるべき？ API でやるべき？」答えはケースバイケースだった。そのたびに、自分が欲しいのは教義ではなく、朝の判断が速くなることだと思い出した。判断基準を技術側に置かず、運営側に置く。この反復が、仕様オーナーシップの練習にもなった。
また、「読めるだけ」から始めた判断は正しかったと思う。つながる快感は、すぐに「書ける」へ行きたくなる。だが地域メディアの公開はブランドと事実確認が絡む。出会いの興奮で権限を広げすぎないこと。これは Vol.03 の暴走の話にも続く。興奮のピークで権限を広げない、は、技術というより自制の設計だ。
最後に、MCP を「魔法」にしないことも大事だった。つながっても、データは欠損する。認証は切れる。OAuth は環境で挙動が違う。魔法だと思うと、障害が裏切られた感じになる。道具だと思うと、障害は運用の一部になる。道具として扱えたから、GA4 を API で取る判断も、罪悪感なく採択できた。
出会いの日に学んだのは、統合の美しさより、朝の再現性の方が先だということだった。MCP はそのための有力な手段の一つ。手段を増やすほど、手段の管理も増える。管理を厭わないなら、接続は資産になる。管理を後回しにすると、接続は散らかったログイン情報の山になる。私は後者になりかけて、一覧と Step 記録で引き返した。
学び
- MCP は「管理画面の往復を減らす」感覚として理解できた
- 中核に据えてよいが、すべてを MCP に揃える必要はない
- 安定バッチは API、対話的深掘りは MCP、という役割分担が現実的だった
- 接続が増えるほど、一覧と状態の可視化が必須になる
- 接続成功を目的化すると、運営価値から離れる
- 技術の出会いより、「何のための接続か」を先に言語化した方が迷いにくい
次回予告
次は、便利さの裏側——AI がすぐ範囲を広げ、暴走に見える瞬間——を書く。止める側の技術ではなく、止める側の判断の話だ。
Vol.03「AIはすぐ暴走する」
便利さと危険が同時に来た日々の、ガードレールの話です。
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 02 |
| 現在の開発 Version | 1.0.0-rc1 |
| 前回 | Vol.01 |
| GitHub | docs/qiita |