コードを書けない。正確に言うと、趣味で少し触ったことはあっても、プロダクトを設計して実装し、テストしてリリースする、という意味では書けない。ターミナルの黒い画面は、まだ少し緊張する。エラーメッセージを見ても、どこが本質でどこが副作用か、すぐには分からない。
それでも私は、地域メディアの運営を支える「OS」を作り始めた。相棒は Cursor 上の AI。現場は kagoshimaniax.com。朝の確認がつらい、というごく実務的な不満が起点だった。かっこいい技術デモが欲しかったわけではない。昨日何が起きて、今日何を優先すべきかが、もっと短時間で分かる状態が欲しかった。
この連載は、その過程を技術解説ではなく判断の記録として残す。成功談だけは書かない。迷ったこと、失敗、方向修正、レビュー、Version、AI との議論を、当時の時系列で書く。未来の機能の話はしない。当時見えていた範囲だけを書く。
背景
鹿児島の地域メディアを運営していると、情報は最初から分散している。WordPress の管理画面、アクセス解析、検索パフォーマンス、SNS の反応、取材メモ、画像ツール。どれも必要なのに、どれも別の場所にある。朝、ブラウザのタブが増える。ログインが増える。「どこから見るのが正解か」が、その日の気分に左右される。
「なんとなく PV が落ちている気がする」は、誰の頭の中にもある。だが根拠が画面をまたいで散らばっていると、判断が遅くなる。朝の確認だけで 30 分以上かかる日もある。ツールが増えるほど、接続とログインだけで疲れる。疲れていると判断は雑になる。雑な判断は、あとで高くつく。
AI に聞けば何かわかる、という期待もあった。実際、文章の下書きや調べ物ではすでに助けになっていた。ただ、文脈のない AI は便利な雑談相手に留まりやすい。サイトの記事、昨日の数字、いま繋がっているサービス——それらが同じ場所にないと、提案の質が上がらない。「一般論としてはこうです」は、地域メディアの朝の優先順位には直結しない。
もう一つ、属人化の問題があった。自分の頭の中にある「最近の感触」は、他人に渡せない。将来、編集の手伝いが増えたとき、同じ確認手順を共有できない。散らばったツールは、散らばった手順を生む。手順が散らばると、ミスの形も散らばる。
今回のテーマ
テーマは単純だ。コードを書けない人間が、なぜ「運営 OS」を作ろうとしたのか。
ここで言う OS は、OS カーネルの話ではない。毎日の判断を支える基盤——接続、蓄積、画面、提案、そして責任の境界——をひとまとめにしたもの、という意味だ。アプリを一つ増やす話でも、自動投稿ボットを作る話でもない。「便利なボタン」を増やすより、「同じ文脈で考える場所」を作りたかった。
非エンジニアの私にできることは、実装そのものより先にある。何がつらいかを言語化する。何を先にやるかを決める。何をやらないかを決める。AI に任せる範囲と、自分が責任を持つ範囲を分ける。そして、後から再現できるように記録する。コードが読めなくても、これらの問いに答えられないプロジェクトは、たぶん続かない。
実際の出来事
最初に決めたのは、「いきなり自動投稿しない」ことだった。Phase 1 は読み取り専用。WordPress に AI から触れても、まずは見る・調べる・整理する。公開や削除は後回し。これは技術的な制約というより、運営者としての自制だった。つながる快感は、すぐに「書ける」へ行きたくなる。だが公開はブランドと事実確認が絡む。興奮で権限を広げない。
次に決めたのは、場所だった。Cursor 上でサイトの文脈に触れたい。管理画面を往復する回数を減らしたい。そのとき MCP という考え方が候補に上がった（詳細は次回）。私はプロトコルの細部より、「同じ会話の中でサイトに触れる」感覚に惹かれた。新しい管理画面を覚えるより、いま使っている AI の会話に現場を持ち込みたかった。
AI との最初のやり取りは、期待と不安が混ざっていた。提案は速い。ファイル構成、手順、用語、次にやるべきこと。一方で、私の「朝の確認がつらい」が、すぐに大きなアーキテクチャ図に膨らむこともあった。便利さと、広がりすぎる勢いが同時に来た。すごい、と思った直後に、怖い、と思った。
そこで自分の役割をはっきりさせた。
| 私（人間） | AI |
|---|---|
| 目的と優先順位 | 調査と下書き |
| やる／やらないの境界 | 実装案と文書案 |
| 本番への責任 | 差分の説明 |
| 記録の要求 | ログ・CHANGELOG の整形 |
| 採択／却下 | 選択肢の列挙 |
コードが書けなくても、採択する人にはなれる。むしろ、採択しないとプロジェクトが漂流する。AI は止まらないことがある。止めるのは人間側の仕事だ、とこの時点で薄く理解し始めていた。
実際の開発は、あとから振り返ると Step という単位で進んだ。一度に一つ。WordPress 接続、記事の保存、画面、分析接続——と、小さく積む。当時の私はまだ「Version」という言葉の重みを十分には理解していなかった。それでも、「全部まとめて作ろう」としない選択だけは、最初から意識していた。一度に多くを頼むと、レビューできない。レビューできないものは、自分のものにならない。
失敗もあった。用語が揺れた。同じものを別の呼び方で呼んで、後で自分で混乱した。AI が親切に先回りして、まだ決めていない未来の機能まで書き始めた。私は「今はそこまで書かないで」と何度も戻した。戻すのが仕事だと、だんだん分かってきた。戻すたびに少し申し訳なくなり、それでも戻した。申し訳なさより、翌日の自分が理解できることの方が大事だった。
もう一つの失敗は、「作っている感」に満足した瞬間だ。ファイルが増えると進んだ気がする。接続が成功すると完成した気がする。だが朝の 10 分は、まだ生まれていないことが多かった。運営価値と、開発の進捗表示は、別のメーターだ。この区別は、あとで何度も自分に言い聞かせることになる。
考えたこと
非エンジニアが AI と作るとき、いちばん危険なのは「自分が分かっていないまま進むこと」だと思う。コードが読めなくても、次の問いは自分の言葉で答えられる必要がある。
- これは誰の朝を楽にするのか
- 今日の完成は何か
- 触ってはいけないものは何か
- なぜ今それが必要なのか
- うまくいかなかったら誰が引き受けるのか
答えられないなら、実装を急がせない。AI は止まらないことがある。止めるのは人間側の仕事だ。止め方を知らないと、便利な助手は、範囲の広い迷子案内になる。
もう一つ考えたのは、「技術より運営価値」という優先順位だ。最新の仕組みに飛びつくより、昨日の数字が今日見えることの方が先だった。かっこいい構成図より、朝 10 分で方針が立つことの方が先だった。この感覚は、あとで Constitution（原則）や Philosophy（哲学）として文書になるが、原点はもっと泥臭い不満だった。泥臭い不満の方が、仕様の芯になる。
また、自分で使ってから外に出す、という順番も、最初からぼんやりあった。デモで見せるための OS ではなく、自分が毎朝触る OS。自分が楽になっていないものを、誰かに勧める資格はない。この感覚は、後に Dogfood Before Deploy という言葉になるが、当時はもっと単純に「自分が使えないなら意味がない」だった。
学び
- コードが書けなくても、目的・境界・採択・記録は担える
- 運営 OS の起点は「便利な AI」より「散らばった判断コスト」だった
- 最初から書き込み（公開・削除）を封印したことが、後の安全設計の芽になった
- AI の速さは資産だが、範囲の制御なしでは負債になる
- 「作っている感」と「運営が楽になった感」は別物として測る
- 連載の主題は技術そのものではなく、人と AI の役割分担の成熟である
次回予告
次は、最初の大きな出会い——MCP——の話をする。ツールをまたぐ「共通の口」を知った日の期待と、すぐに訪れた迷いを書く。
Vol.02「MCPという考え方に出会った日」
「管理画面をまた覚える」以外の道が見えた日の話です。
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 01 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | docs/qiita |