都市型コワーキング運営事業者の入居者ビジネスコミュニティ基盤を内製化支援

複数拠点を運営するコワーキング／シェアオフィス事業者にとって、入居者同士のつながりこそがサービスの売りである。一方でそれをアプリやWebで支えようとすると、中堅規模の事業者は共通の壁に突き当たる。

• 見える範囲の管理が難しい: 拠点・入居企業・個人会員という単位が重なり合い、「どの情報を誰に見せるか」を運営側で正しく分けるのが大変。出来合いのサービスでは拠点ごと・企業ごとの細かい線引きが効きにくい。
• 会員情報を守りきれるか不安: 入居企業の連絡先や商談情報など、漏れたら信頼を一気に失う情報を扱う。「うっかりミスで他社に見えてしまった」が起きない仕組みが必要。
• 運営の人手が足りない: お知らせ配信・掲示板の見回り・交流会の募集や出欠・新規入居者の案内・問い合わせ対応を担当者が手作業で回しており、拠点が増えるほど負担も増える。
• 外注だと自社で育てられない: すべて外部任せにすると中身がブラックボックスになり、機能を1つ足すたびに見積りと納期に縛られ、自社のスピードでサービスを磨けない。

これらは「便利な機能があるか」ではなく、「安全に運営し続けられるか・自社で育てていけるか」という、発注を決めるうえで一番気になる不安である。

AI-Path のエンジニア（FDE）が事業の現場に入り込み、AI を活用して速く・確かに作る進め方を採った。

• 自社の実績ある部品を持ち込んだ: ログイン・招待・権限管理・通知・AIチャット・ナレッジなど、すでに自社で運用している仕組みと画面部品をそのまま転用。ゼロから作り直さないことで立ち上げを短縮した。見た目のデザインも統一感を保ったまま移植している。
• 「誰に何が見えるか」を最初に固めた: 機能を増やす前に、情報の見える範囲をシステムの土台で保証する設計を先に決めた。後から機能を足しても土台が崩れない。
• 担当者の事務作業を AI で軽く: お知らせの下書き、掲示板のガイドライン違反チェック、拠点ごとの盛り上がり要約などを AI が支援し、繰り返し作業を肩代わりさせた。
• 品質チェックを開発と同時に回した: 自動テストと品質チェックを開発の流れに組み込み、機能を足すたびに不具合の混入をすぐ検知できる状態を保った。

体制は常駐エンジニアを中心に AI を活用した少人数。要件・データ構成・画面の流れ・運営機能・移植計画を事前に文書化したうえで、最小版から拡張機能まで段階的に作った。

入居者向けビジネスコミュニティを、会員（入居者）が使う面と、運営者（コミュニティ担当者・本部）が使う面の両方で構築した。入居企業同士の出会い・メッセージ・掲示板・ナレッジを1つにまとめ、会員も運営者も同じ場所で完結できるようにしている。

会員（入居者）向け

• ホーム画面: 注目の相談・注目の会員・交流会・必読のお知らせを1ページに集約
• 課題掲示板: 事業の相談を投稿・検索・閲覧。「協力できます」と提案すると、その場で相手との個別メッセージが自動で立ち上がり通知も飛ぶ
• 会員検索: 業種・拠点・タグで相手を探し、プロフィールを見てそのままメッセージを開始
• メッセージ: 相手と1対1でやり取り。届いたメッセージはその場でリアルタイムに表示され、既読も分かる
• 交流会: 一覧・詳細・申込・キャンセル
• お知らせ: 一覧・詳細（開けば自動で既読）。重要なお知らせは初回ログイン時に提示
• ナレッジ: 公開範囲ごとに記事を閲覧
• 通知センター: 一覧・まとめて既読
• AIアシスタント: 相談の下書きや提案文の作成、つながり方のコツを提案
• 設定: プロフィール編集・通知設定・写真アップロード

運営者（コミュニティ担当者・本部）向け

• 運営ダッシュボード、会員管理、掲示板の見回り、注目会員の設定、お知らせ作成・配信、交流会作成、招待発行、ナレッジ管理
• 拠点の管理、会員管理などの本部向け画面
• 運営者向け AIアシスタント: お知らせの下書き、ガイドライン違反チェック、拠点ごとの盛り上がり要約、歓迎メッセージ案、問い合わせ返信の下書きを支援

1. FDE（常駐エンジニア）による伴走開発
2. AI を活用した高速開発
3. 複数拠点・複数企業に対応したサービス基盤の設計・構築
4. 会員データ保護・権限設計の実装
5. AIアシスタントの組み込み
6. 内製化・運用引き継ぎ支援

複数の拠点に横展開しやすく、情報を取り違えない、リアルタイムにやり取りできる——この3点を最初から土台に組み込んだ。

• 複数拠点に横展開しやすい構成: 拠点・入居企業・会員という単位を整理して持たせており、新しい拠点が増えても土台を作り直さずに追加できる。
• 見える範囲が自動で分かれる: 拠点・企業・個人ごとに「見てよい情報」が自動で切り分かれる仕組みをデータの土台側に持たせ、アプリ側の作り込みに頼りきらない堅牢な構成にしている。
• メッセージはその場で届く: やり取りは画面を更新しなくてもリアルタイムに反映される。

採用した具体的な技術名は tech_stack を参照。

AI-Path のゴールは「納品して終わり」ではなく、運営事業者が自社のペースでサービスを育て続けられる状態を作ること。

• 同じ環境を誰でも再現できる: 開発・本番ともに同じ手順で立ち上げられるよう環境を整備し、品質チェックも1つのコマンドにまとめて引き渡せる。
• 文書で引き継げる: 要件・データ構成・画面の流れ・運営機能・移植計画を文書化。引き継ぎや自社運用の出発点になる。
• 後から積み増せる設計: 決済（サブスク）、スマホアプリ、検索の強化、お知らせのメール・プッシュ配信などを将来フェーズとして設計に織り込み済み。土台を壊さず機能を足せる。
• AI-Path の伴走モデル: エンジニアが事業の現場に入り、AI を活用して開発スピードを保ちつつ社内チームにノウハウを移し、外注丸投げによるブラックボックス化を避ける。