KagoHubでAIよりデータ保存と整理を先にした理由

AIを使って地域の情報を扱う仕組みを作るなら、最初に要約や自動分類を入れたくなる。けれどKagoHubでは、v1.0の中心をAIではなく、情報の収集、保存、受信箱、下書きに置いている。

KagoHubは、鹿児島県内の公式・準公式情報を集めて整理し、公開と再利用につなげる情報ハブとして設計された。最初の利用者は運営者本人で、毎朝開けば何が更新されたかを把握できる状態を目指す。

この順番で作った v1.0.0 は2026年8月28日に正式リリースされた。その後も、v1.2.0では読取REST APIを追加し、現在のv1.3では安全な書込REST APIの統合が済んでいる。ただし、v1.3.0の実通信と正式リリースはまだで、公開を自動化する機能は追加していない。

先に作るのは「情報が残る流れ」

KagoHubの設計では、公式情報を集め、保存し、受信箱で確認し、記事候補からWordPress下書きへつなげる流れを先に置く。重要なのは、情報が来た事実、どこから来たか、どこまで確認したかを後から追えることだ。

AIの出力は便利でも、入力が曖昧なまま先に置くと、もっともらしい文章だけが増えやすい。先に情報源と保存先を固定しておけば、後からAIを使うときにも、何を根拠にしたかを確認できる。

v1.0でAIを後回しにした理由

KagoHubの設計判断では、AI要約、AIタグ付け、重要度判定はv1.0の対象外としている。AIモデルは変わり得る一方で、情報源、保存したデータ、受信箱、下書きという土台は残るためだ。

代わりに、RSSで取得した情報を保存し、受信箱で整理し、記事候補からWordPress下書きを作る流れを優先する。これはAIを使わないという意味ではない。AIを足しても判断の根拠が残る順番を選んだ、ということだ。

自動公開まで任せない

KagoHubは、取得した情報をそのまま公開しない。記事候補やWordPress下書きまでは仕組みで支援しても、公開するかは人間が確認して判断する。

地域情報では、文脈の不足、誤情報、著作権、不要な情報の大量公開を避ける必要がある。だから便利さを増やす前に、人が立ち止まれる場所を残した。

非エンジニアが持ち帰れること

• AIに任せる前に、どの情報を集め、どこへ残すかを決める
• 情報源、保存先、確認場所があれば、出力の根拠を追える
• 下書き作成と公開判断を分けると、便利さと責任を混ぜずに済む
• AI機能は、土台が安定してから足しても遅くない

この記事は、KagoHubの AI_CONTEXT.md、DECISIONS.md、CURRENT_STATUS.md、CHANGELOG.md とGitHub Issueの確認済み事実だけで構成している。v1.3の正式リリース前であることと、自動公開を対象外にしていることを混同しない。