Think Visual — 2026.08.21
Otakeさんと PM 2名が、同じ Markdown を読み書きする形にする。オーベルジュを最初の一件にした場合の設計です。
調べたところ、オーベルジュの正本はもう出来ていて、社内配信も動いていました。無いのは「他の2人が書き込む入口」だけです。
作るのは新しい共有フォルダではなく、Markdown だけを置いた共有リポジトリを1つ。既存の正本をそこへ引っ越します。git の操作は Claude Code が代行するので、2人が新しく覚えることはありません。Slack 連携は第2段階。オーベルジュ1件で2週間走らせ、動いたら広げます。
設計はこちらで決めます。ここだけは「関係者への態度」なので判断が要ります。
川久の team_board.md が既に引いている線（価格・販売方針・法務グレーは配布面に載せない）をそのまま適用します。
契約・融資の実務に必要な2本だけ開けます。決定ボードは検討の途中なので出しません。
線を引くコスト自体をなくす形。ただし後から戻せません。
お返事がなければ A で進めます。A なら後から広げられますが、逆向きには戻せないためです。
「一つ共有のフォルダを作って、そこに Markdown で Source of Truth を置いて、3人でやり取りしていきましょう、というような形にしたい」
facilities/kawakyu_auberge/_sot/ に14ファイル・3,221行。ロードマップ1,200行、チームボード507行、決定ボード200行、関係者ロスター、許認可、研修計画、VIPサービス設計。すべて Markdown です。
yamato-auberge-team.pages.dev（現地チーム向け・社内認証つき）と yamato-lauberge-roadmap-internal.pages.dev（8ワークストリーム × 月・共有メモ機能つき）が動いています。配信元は上の Markdown です。
2人は読めますが、直す手段がありません。気づいたことは各自の資料やチャットに溜まり、Otakeさん経由でしか正本に入らない。正本が1本足りないのではなく、正本への入口が1つしかない。
だから作るのは「新しい共有フォルダ」ではなく、既にある正本に2人が手を入れられる状態です。新しいフォルダを別に立てると川久の _sot/ と二重管理になり、どちらが本当か分からなくなります。
推奨は GitHub のプライベートリポジトリを1つ新設（仮に yamato-sot）。中身はご希望どおり Markdown だけにします。Google ドライブの共有フォルダは、Markdown を3人で書く用途では同時編集で壊れるため採りません。既存の Claude_tmk をそのまま共有しないのは、全19施設のデータ・オーナー情報・価格・API キーまで入っていて、丸ごと渡せる中身ではないからです。
Otakeさん側は設定に1行足すだけで、Claude Code が個人リポジトリと共有リポジトリを1セッションで扱えます。既存のビルドやデプロイの手順は変えずに済みます。
「Markdown ファイルは何個かあっていい。トピックごとに分かれて。あまり分類しすぎるとあれなので、どうでしょうね」
この引っかかりは正しくて、「トピック」で分けると必ず破綻します。トピックは無限に増えるので、分類表のメンテが仕事になり、やがて誰も書かなくなります。分ける軸は 「誰が書く面か・どこへ配る面か」。これは既に川久で発明されている考え方です — team_board.md（現地に配る確定事項）と decision_board.md（Otakeさんの壁打ち）が、同じ話題でも役割で切り分けられています。
yamato-sot/ README.md ← 3人が最初に読む。運用ルールはここだけ CLAUDE.md ← 3人の Claude Code が同じ前提で動くための共通指示 auberge/ ← 最初はこの1件だけ。他は作らない 決まったこと.md 確定した事実だけ。3人とも書ける 宿題.md 誰が・何を・いつまでに 関係者.md 誰が何をする人か 論点.md まだ決まっていないこと 議事録/ 日付ごとに1枚 _inbox/ ← 迷ったものは全部ここへ放り込む
肝は _inbox/ です。「どこに書けばいいか分からないものは、とりあえずここに1行置く」を運用ルールに明記します。分類を先に完璧にしようとすると人は書かなくなるので、迷いの逃げ場を先に用意して、仕分けは後から Claude にやらせます。ファイル名が日本語なのも、2人が開いた瞬間に迷わないためです。
| できること | 条件 |
|---|---|
| Claude Tag チャンネルに1体の @Claude が住み、全員から見える。チャンネルの文脈を覚え、誰の依頼も引き継げる |
Team / Enterprise プランのみ。個人プラン（Pro・Max）では使えません。2026年8月3日に従来版と入れ替わりました |
| Claude in Slack（従来版） @Claude と書くと Claude Code のセッションが立ち、GitHub に PR まで作る |
Pro / Max で使えますが、各自のアカウント・各自の GitHub 接続・各自の利用枠で動きます。つまり3人がそれぞれ Claude Code の席を持つ必要があります |
Slack は第2段階にします。Slack は議論が流れていく場所であって、正本ではありません。正本が無いまま Slack をつなぐと、「決定がスレッドのどこかに埋もれる」という今の問題が、形を変えて残るだけになります。
ただし Slack が効く場面ははっきりしています。オーベルジュは関係者が多く、社長・佐藤さん・柏崎さん・岡田さん松葉さん・現地の福谷さん・大美さん・外部パートナーまで話が散ります。散った会話を正本へ吸い上げる導線としては Slack 連携が効きます — スレッドで @Claude に「今の話を宿題に足しといて」と言えば済むので。正本が2週間動いて「書く場所がある」状態になってから、その入口として足すのが自然です。
コピーではなく引っ越しにします。二重管理を作らないためです。Otakeさんの手元からは、移した分へのポインタ1行だけ残します。
各自の PC にリポジトリを1つ置き、そのフォルダで Claude Code を起動してもらうだけです。git の操作は Claude が代行するので、コマンドは教えません。
既存の yamato-auberge-team ポータルの配信元を新リポジトリに向けます。2人が書いた内容が、そのまま現地チームの見る画面へ流れる状態にします。
見るのは1つだけ — 2人がそれぞれ何回書き込んだか。0回なら仕組みではなく導線の問題なので、Slack か別の入口を足す判断に進みます。
引っ越す対象の内訳です。上段はそのまま共有、下段が冒頭の判断待ちです。
| ファイル | 中身 | |
|---|---|---|
team_board.md ／ project_roster.md | 確定事項・座組・宿題 | 共有 |
roadmap.md ／ install_plan.md ／ training_plan.md | 計画・オペ設計・研修 | 共有 |
permits.md | 許認可の進捗 | 共有 |
decision_board.md | 価格・原価率・会員権の販売方針・検討中の案 | 要判断 |
finance_ops.md ／ contract_risks.md | 収支・契約リスク | 要判断 |
資料作成という仕事が誰のものか、という問い。SoT/people/org_doctrine.md（人・AI・外注に何を割り振るか）が seed のまま止まっていて、ちょうどこの問いの置き場です。BM の議題に育てる価値があります。
3人の Claude Code が同じ正本を読む状態になると、同じ記憶を共有した3体になります。AI社員の設計（SoT/agents/）は「AIに何をやらせるか」で組まれていますが、これは「AIに何を共通で覚えさせるか」という別の入口です。
関係者ロスターの外部パートナー欄に未登録が残っています — Atirom（浜村シェフ・森田さん／確度△）、山本さん（器の可否・所属不明）、行政書士（事務所名が記録に無い）、窯元・作家（訪問先未特定）。2人に見せる面へ載せる以上、確度△のまま出すか、埋めてから出すかを決める必要があります。