第1回|構想から自治体向けご提案資料までの記録
はじめに
このシリーズは、現在開発を進めているBtoB(対自治体)向け新サービス「地方活性化ローカルエクスチェンジ」の開発プロセスを、経営論・事業設計の視点から記録していくものです。
完成したサービスの紹介ではなく、まだ検証段階にある構想が、どのような意思決定を経て一つの提案資料という形になったかを残すことに意味があると考えています。新規事業は、完成形よりもむしろ「なぜその設計を選んだか」という判断の連続にこそ再現性のある知見が宿るからです。
第1回である本稿では、構想の出発点から、自治体向けの初期ご提案資料が完成するまでの経緯をまとめます。

1. 出発点にあった問い
地方が抱える少子化、税収不足、産業空洞化、高齢化といった課題は、それぞれ個別の政策テーマとして語られることが多い構造にあります。人口対策は人口対策、企業誘致は企業誘致、観光振興は観光振興という具合に、担当部署も予算も縦割りで動いています。
しかし、これらを俯瞰すると一つの共通構造が見えてきます。地域の「ヒト・モノ・カネ」が、域外――とりわけ首都圏――へ吸い上げられていく流れが止まっていない、という事実です。個別の対症療法をいくら積み重ねても、この流出構造そのものにアプローチしない限り、地域経済の縮小は止まりません。
ここが、このプロジェクトの出発点にある問いでした。「個別施策ではなく、構造そのものを可視化し、動かす方法はないか」。
2. 指標設計という経営判断:「鎖国指数100」
構造を動かすには、まず構造を測れる形にする必要があります。ここで採用したのが、自地域だけで経済が完結する状態(鎖国状態)を指数100と定義し、そこからの超過・不足で地域経済の収支を一つの数値に集約するという設計です。
これは単なる比喩ではなく、経営論的には「複雑な多変量の現実を、意思決定者が扱える単一の意思決定変数に圧縮する」という指標設計の典型的な作法です。売上や利益率が経営の意思決定変数であるのと同じように、自治体には「自分たちが域外に対して稼いでいるのか、奪われているのか」を一目で判断できる変数がありませんでした。この指数は、その空白を埋めることを狙っています。
指数が100を下回れば流出超過、上回れば流入超過。この単純な二値化が、後述する「AIによる施策提案」を機能させるための前提条件になります。指標がなければ、AIが何を最適化すべきかも定義できないためです。
3. 資本を3つに分解する思考法(ヒト・モノ・カネ)
一つの指数に集約する一方で、それだけでは「では何をすればいいのか」に答えられません。そこで指数の内部を、ヒト(人口動態・就労・移住)、モノ(域内調達率・産業出荷・観光消費)、カネ(税収・補助金・資本投資)という3つの資本フローに分解する設計にしました。
この分解には二つの狙いがあります。一つは、自治体ごとに「どの資本で流出が起きているか」が異なるため、診断の粒度を上げること。人口は流出していないが資金は流出している地域と、その逆の地域では、打つべき施策がまったく異なります。もう一つは、既存の統計データ(人口動態調査、産業連関表、税収データなど)とマッピングしやすくすることです。抽象的な指標を作っても、それを算出するデータ源が存在しなければ絵に描いた餅になります。
経営論の言葉で言えば、これはKPIツリーの設計にあたります。トップの指標(鎖国指数)を、意思決定可能な下位指標に分解し、それぞれに対応するデータソースと打ち手を紐づける。事業計画やOKR設計と同じ思考の型を、自治体経営という別領域に転用した形です。
4. AIをどこに配置するか
このプロジェクトで意識したのは、「AIを使うこと」自体を目的にしないという点です。AIの役割は、次の3段階に限定しています。
- データ統合:人口動態・産業統計・税収・観光データ等を統合し、鎖国指数を算出する
- 優位性の特定:他地域との比較から、その地域固有の強み(産業集積、観光資源、立地条件など)を抽出する
- 施策の自動提案:ふるさと納税の最適化、企業誘致のターゲティング、起業支援マッチングなど、優先順位付きの打ち手を提示する
重要なのは、AIが「データを見せる」のではなく「意思決定の候補を提示する」役割を担っている点です。自治体職員がダッシュボードを眺めて自分で解釈するのではなく、次に何をすべきかという打ち手のレベルまでAIが降りてくることで、初めて政策実行のスピードが上がります。ここは、AIツールを設計する上で最も時間をかけて議論した部分です。
5. 最初のアウトプットをご提案資料にした理由
サービスの技術構成やAIエンジンの詳細設計より先に、自治体向けの営業提案資料(プレゼンテーション資料)を最初のアウトプットとして選びました。
これは、BtoB、特に対行政のサービス開発において、「機能を作ってから売り先を探す」のではなく、「意思決定者が納得する説明の順序を先に固めてから機能に落とし込む」方が手戻りが少ないという経験則によるものです。提案資料を先に作ると、以下が強制的に言語化されます。
- 誰の、どの課題に、なぜ効くのか
- 既存の対症療法と何が違うのか
- 導入から効果測定までのプロセスはどうなるのか
- 何を成果指標として約束できるのか(そして、何をまだ約束できないのか)
実際、資料を組み立てる過程で「現状の対症療法」と「あるべき姿」を対比させるスライドを作ったことで、サービスの価値提案そのものがより明確になりました。これは、資料作成が単なる営業ツールの制作ではなく、事業設計そのものの検証プロセスになっていたことを意味します。
6. 現在地と次のステップ
現時点でできているのは以下の状態です。
- サービスコンセプト(鎖国指数100/3資本フロー分解/AI施策提案エンジン)の言語化
- 自治体向け初期ご提案資料(全10ページ)の作成
次のステップとして想定しているのは、次の3つです。
- サービス設計書・事業計画書:AIエンジンの技術構成、データ取得元、算出ロジックの精緻化
- 料金体系・マネタイズ設計:自治体予算のサイクル(単年度予算、補正予算など)に合わせた課金モデルの検討
- パイロット自治体の選定基準:初期の実証実験先として、どのような規模・課題特性の自治体が適しているかの仮説設計
おわりに
新規事業、特に行政という意思決定プロセスが独特な相手に向けたサービスは、機能の完成度よりも「なぜこの構造で課題が解けるのか」という説明の一貫性が先に問われます。今回は、指標設計(鎖国指数100)→ 構造分解(ヒト・モノ・カネ)→ AIの役割定義(意思決定支援)→ 提案資料という順序で組み立てたことで、この一貫性を早い段階で検証できました。
次回は、サービス設計書・技術構成の検討過程について記録する予定です。
本稿は開発途上の構想に関する記録であり、記載されている指標・成果イメージは設計段階のものです。実際の効果は導入先の自治体データに基づき個別に検証されます。