• THE PERSONサイトのNext.js移行に向けてLP制作を本格始動 ── 藤井がPR #7をプッシュ済み、今週中に全サイトマップ分（70〜80ページ規模）を一通り作り上げる予定
• Claude Codeのpermissions設定（deny／ask／allow）を藤本が整備済み ── フォースプッシュ等は禁止、通常のコミット・プッシュはask扱い
• SEO負債（canonical未設定、OG不備、JSON-LD未実装など）は今回のリニューアルで解消する方針
• AIツールはGeminiへの移行を進めつつ、NotebookLMの活用も試す方向で合意

• 藤本がdeny／ask／allowの3段階でpermissionsを整備 ── フォースプッシュ等の破壊的操作はdeny、通常のコミット・プッシュはask、読み取り系のGit操作はallow
• コマンド単位での迂回は防げるが、リストにないコマンドで同等操作を試みる可能性は残るため完全ではないと藤本は認識
• Claudeがルールに弾かれた場合は「このルールで実行できませんでした」と明示する動作になっている

• 藤井が既存のATRIO DUE NEXT青葉台LPを参考に新デザインを再現 ── まず自然言語で大枠を指示し、セクションIDで個別パーツを差し替える流れ
• StudioのセクションIDが一部コピペ由来で重複している可能性があり、IDだけでなくブロック全体で判断させる必要があると藤本が指摘
• 意図的なデザイン差分（CompetitorAdvantageセクション追加など）と抜け漏れが混在し、チェックが難しいと藤井
• 1ページあたり1〜3時間の見込みで、AIに機械的に生成させて与田にパスする流れが望ましい

• 藤井がページ生成→与田にパス ── 精度は5割程度想定なので、与田が意図した修正かを確認しながらチェック
• セクションID重複時に意図しない箇所が変わるリスクがあるため、修正後は変更範囲を必ず確認
• 大変すぎる場合は都度連携する方針

• 公開ページの実体はapp/以下 ── app/page.tsxがトップ、各ルートはフォルダ内page.tsx。app/layout.tsxにメタ・GTM・OGP、robots.ts／sitemap.tsも同階層
• 現状はCloudflare Imagesで画像のみ管理 ── 動画はImages非対応のためR2等への切り替えが必要。トップ動画は容量が大きく、公開前に逃がし方法を藤本が調査
• 今回はCMS機能なしでコードベースのみで進める ── トレーナー／ジムページのCMS組み込みはリリースタイミング次第。ジムページは間に合わない可能性が高い

• Geminiへの移行方針は不変だが、藤井はまだ触れていないため触る時間の確保が必要
• 与田が紹介したNotebookLMをAIレビュー会のルール管理に使う案 ── Googleドキュメントをソースに更新を自動反映させる形で試す。Claude permissions（CLAUDE.md）を藤井・与田も試す
• MixiのAI活用事例として、情報整理ができている人ほどトークン消費が少なく成果が高いという知見を共有
• Vercelへのメンバー追加リクエストは誤作動の可能性が高く藤本はノータッチ。社内ドキュメントのCloudflareメール認証は構築中で、閲覧者が50人超でGCP移行を検討

• 5/21（木）14:00の本定例はスキップ ── 藤本が藤井へ「今日難しくて」（5/20 17:10、藤本→藤井DM）と連絡、振替なし
• 前日17:00に藤井DM宛にアジェンダは送信済み（slack_agenda_20260520.txt）
• 5/21アジェンダで挙げられていた7項目は 5/28 のアジェンダに持ち越し扱いで反映済み
• 5/26に藤本から「水曜13:30-14:00で新カレンダー設定、6/3スタート」の打診あり ── 5/28で開催曜日の再設計を議論

• 全スタッフの公式AIツールはGemini統一、会議メンバー5名（藤本・藤井・大石・庄司・与田）はChatGPT・Claude・Geminiの並走OK、Claude Codeは藤本作成のルール読み込みと承認を得た者のみという方針を確認
• セキュリティガイドラインは藤本が「危険コマンドのハードブロック（settings.json）」と「Gemini利用の背景周知」の2点に絞って整備し、2週間後（5/28目安）に共有
• AIツール経費は大石に承認を取るフローを作ることで合意、新サービスを試す際はSlackで共有する運用に
• LINE Harnessは優先度が低い状態で止まっており、KPIへの影響を試算した上で来週判断
• カルテUIのPRレビューを実施、細かい修正が複数確認され、藤本が今日中に対応して明日（5/15）リリースを目指す

• 全スタッフの公式ツールはGemini統一だが、会議メンバーはChatGPT・Claude・Geminiの並走OK
• Claude Codeは原則禁止で、藤本作成のclaude.mdルール読み込みと承認を得た者のみ利用可
• 非公式・コミュニティ製プラグインは完全禁止（マルウェアリスクのため）
• 「やりたいことがあれば自力で一度やってみる」ができるメンバーだけがClaude Codeを触る運用にしたい（藤井）

• 新しいAIサービスを試したい場合は大石に承認を取るフローを作ることで合意
• 藤本・藤井など複数プロジェクトで使う場合の会社負担の扱いは今後判断が必要（大石）
• 与田・庄司など社員の個人負担が重い場合は相談に乗る運用にしたい（藤井）
• Codexは藤本が試用中で、Claude Codeで作った後の最終点検に使うと精度が高い

• 藤本が担当する整備内容を2点に絞った：①危険コマンドのハードブロック（settings.json）、②Gemini利用の背景周知
• Geminiはワークスペース内で学習させない仕様が最大のガードレールになっているため、まずその背景をスタッフに周知することが優先（藤本）
• Geminiの周知・発信は藤井または庄司がボールを持つ
• 完成目標は今月中、2週間後に進捗確認

• 禁止事項だけ伝えても現場には伝わらないため、ユースケースに落とし込んだ設計が必要（大石）
• 大石が想定するユースケース例：最新キャンペーン情報をスプレッドシートで管理しNotebookLMに登録し、現場がGeminiで即座に参照できるオペレーション
• 庄司が現場に入りながらAI活用パターンを探し、リスクのない使い方と効率的な使い方を整理していく方向性で合意
• 藤井が今日立川店を訪問し、トレーナーが1時間前出勤で45分手持ち無沙汰になっている実態を確認、暇な時間の設計も必要と感じた

• Vercelはプレビューデプロイが使えてPRレビューの効率が大幅に上がるため継続必須（藤井）
• 社内ドキュメント共有はCloudflareのメール認証（stadiums.co.jpドメイン単位で許可可能）で当面運用し、人数上限に問題が出たら開発議題に上げて自前環境への移行を検討
• HTMLファイルをダウンロードして共有する現状の方法は非効率なため改善が必要

• LINE Harnessはリポジトリ作成済みだがCloudflareへの移行が未完了で、他タスクに押されて優先度が低い状態（与田）
• LINE HarnessはCloudflare Workersでないと動かない仕様のため、Vercelへの移行は不可（藤本・与田）
• 大石は「KPIに効くなら優先度を上げる」という判断軸を示し、与田が売上への影響を試算して来週判断することに
• グループ向けとシェアリング向けでどちらのKPIインパクトが大きいかも含めて検討が必要（大石）

• PR #66（カルテ一覧・マイページTOP統合レビュー用）をベースに画面を確認しながらレビューを実施
• 今日の予定ブロックにMTG・休憩が表示されない（タイムゾーンが7時間ずれている可能性）
• 女性アバターが男性アイコンで表示されている（性別データの確認が必要）
• お知らせ・かかりつけ顧客セクションが未表示（かかりつけ顧客はまだ制度として動いていないため一旦スコープ外）
• カルテ一覧のフィルタータブは「未記入」を最初に表示する順番に変更
• カルテ記入率のアイコンは骸骨マークをやめて黄色（80%以上）・赤（79%以下）の三角に統一
• セッション種別（カテゴリ）は変更不可にする方針で合意（予約枠の種別に固定）、並び順は逆順（直近が上）に変更
• トレーナープロフィールの名前・画像は本人からは変更不可で管理者（admin）から変更。個別ビューと一覧ビューの共通化は今回スコープ外

• 藤本が今日中に細かい修正を対応し、明日（5/15）リリースを目指す
• 週明けにリリースが出たらレビューを挟む運用にしたい（与田）
• 今回のレビューはチェック方法の不慣れによるミスが多かったため、次回は即チェックできる体制で進める（藤井）

• 5/7（木）14:00の本定例について、Circlebackにレコーディングおよびトランスクリプトの記録が見つかりませんでした
• 前日17:00に藤井DM宛にアジェンダは送信済み（slack_agenda_20260506.txt）
• 実開催の有無・スキップ理由・口頭での議論の有無は、5/14冒頭で参加者に確認
• 5/7アジェンダで挙げられていた全項目は 5/14 のアジェンダに持ち越し扱いで反映済み

• 藤井さんのアウトプット自動化（月曜だけで1日30〜40回デプロイ）でCloudflareの無料枠が上限に近づき、有料化が現実的なタイミングに
• Cloudflare無料枠はアクセス制限が50人までという制約があり、1枚構成での整理方針が当初から議論されていた経緯を再確認
• VercelとCloudflareの使い分け（どの場面で何をデプロイするか）のルール整理が必要 ── 来週藤井がドキュメント化して持参

• 藤井提案：藤本がシステム開発の最高権限者として、公開可否のレビュー・マージを全て担う ── 大石が同意
• 経営陣（大石・藤井・庄司・比江島ら）はAIで経営課題を解決するブレストを担い、リソースが溜まったタイミングでダッシュボードや社内ツールをローンチできる体制を目指す
• 大石が最重要課題として挙げたのは「セキュリティ事故が起きる前にHTML誤送信などのリスクを防ぐ体制づくり」 ── 4/23の「無許可使用 + パブリックURL外部共有」リスクと地続き
• 誰がどのツールに触れるべきか（例：Vercelプレビューは与田か、エリアマネージャーレベルか）を整理し、最終的にはGoogle Workspaceに絞り込む

• 社内で使っているツール（GitHub、Claude、Google Workspace、Vercel、Studio など）を一度全部可視化して、繋いだら問題になりそうなものを洗い出す
• 最終的にはGoogle Workspaceだけで回る状態（NotebookLM などを活用）を目指す
• Squarespace など不要なツールは置き換え、BookMe などのフォームも自前実装できれば削除して統合していく方針
• ドキュメント整備は会社方針として大石・藤井がまとめる形でもよいという認識（藤本単独依頼から方針転換）

• 藤井整理：この会議は「AI活用・クラウドインフラ・ドキュメント整備」に絞り、LPなど別テーマは別途会議を立てる
• 藤本が議事録を取りながら開発作業もこなしている状況を改善するため、与田にファシリ・メモ役を移管（与田了承）
• 藤井が来週役割定義のラフドキュメントを持参し、改めて全体構造を議論

• FigmaのMCPを使ってReactコンポーネント（セクション単位）を自然言語で生成・修正できる精度が上がっており、藤本がデモを実施
• LPはセクションを並べて1ページを構成する設計で、文言変更や店舗差し替えは自然言語で指示するだけで対応できる見込み
• Storybookは会員登録不要のローカルツール（NPMライブラリ）で、Reactコンポーネント単位のデザインチェックに使用
• 料金・通い放題の有無・住所・店名・駅名など変更頻度の高い箇所はHTMLで実装しておくことで、画像差し替えの手間をなくす

• 与田リソースは今日・明日を超えれば5/15頃まで確保見込み ── 5/7前後（GW中日）に進捗確認を入れる方向（無理なら無理でよい）
• 藤本が明日5/1 16:00–17:00頃、既存パーツの修正フローと新規ページ作成手順を藤井と整理する枠を設定
• ロゴ差し替え時に横幅の違いでレイアウトが崩れる問題（例：ルネサンス vs Tipness）は藤井が論理的なCSSで対応

• LPをコンポーネント（セクション単位）で管理する設計方針を藤本さんが説明
• 与田さんがLPマスターシートにブランド別・パターン別のバリエーションを追加していく流れに

• AIツール（特にGPT）の画像生成クオリティが大幅に向上しており、非エンジニア業務での活用が現実的になってきているという認識を共有

• 社内メンバーがAIツールを無許可で使用し、生成物をパブリックURLで外部共有するリスクが浮上
• セキュリティルール整備を藤本さんが主導する方向に

• 庄司さんがLINE APIを使った情報抽出機能を実装済み、次のステップとして自動送信機能のテスト環境での検証を進めることに
• LINEログインによる顧客ID紐付けは過去に開発優先度・コストの観点から見送られていたが、会員規模拡大に伴い改めて検討余地ありという認識に

• 社内AIドキュメント化は藤本さん単独への依頼から方針転換し、藤本さんは開発・Claude・GitHub関連をまとめ、残りは藤井・藤本・大石の3人で方針と全体感をテキストでまとめてドキュメント化していく形に
• LINE Harness × Cloudflare構築は再現確認まで完了、次はstadiumsアカウントへのリポジトリ移行が必要
• LP制作の自動化・効率化は優先度高め — 現状与田さん1人で約20店舗×3種LP（通常・リカバリー・女性用）を毎月キャンペーンごとに更新する状態が続いており、早急に解決が必要
• 4月20日（月）18:00〜20:30に藤井・与田・藤本の3人で作業セッションを設定、環境構築とFigmaフォーマット試作を進める

環境復旧

• 藤井さんが環境を一度落として立ち上げ直す作業を行い、/setupコマンドで解決した
• 庄司さんのPRは引き継いで編集できていたが、環境を落としてから触れていないため、進捗があれば改めて報告予定

ドキュメント化の進め方

• 全社向けドキュメントが目標で、早めに整備が必要という認識で一致
• 藤本さんの担当範囲はClaude Code・GitHub・セットアップなど開発者向けの内容に絞り、言語化してもらう形に
• 全体方針と概要は藤井・大石・藤本の3人でテキスト入力でまとめ、ドキュメントに追記していく進め方に
• ミーティング内で5〜10分使って「先週こういうことがあったのでこれを書いておく」レベルの更新を継続的にやっていく案も出た

利用範囲と活用事例共有

• Claude Codeは触れる人を限定する方向で整理が必要
• 藤井さんは交番表作成やプロジェクト作成はアプリケーション経由にしており、Claudeに直接依頼する形は取っていない
• Geminiにもスキルズ機能が出たことを受け、社内でAI活用のナレッジをスキルとして昇格できる仕組みを作りたいという意見が藤井さんから出た
• ブラウザ自動操作ツールを使うと24時間かかっていた作業が2分半で終わった事例のように、各自の活用事例をSlackなどで共有して判断できる機会を作りたい

構築進捗

• 与田さんが内本さんとセッティングし、Cloudflare前提の公開リポジトリ通りの構成で再現確認まで完了
• 以前はVercelで噛み合わせていたが、ツール自体がCloudflare前提で作られているため今後の機能維持を考えてCloudflareに戻した
• stadiumsアカウントへのリポジトリ移行と、そこからCloudflareへの接続はまだ未対応

現状の課題

• 現状は約20店舗×3種LPで計60LP分を与田さん1人が毎月キャンペーンごとに更新する状態になりつつある
• サイト全体のページ数はLP本体21ページ、サブページ（サンクス・バリエーション含む）39ページ、キャンペーン5ページ、店内用20ページ程度で、フォーマット数自体はそれほど多くない

移行方針

• 大石さんはスタジオから脱却してBookMeをそのまま使いつつ、LPはサブドメイン（例：lp.）を切って別サーバーで運用する案を提示
• 現状はグループパーソナルのドメイン配下にスタジオのIPが組まれているため、配下の特定パスだけ別IPにするのは難しく、サブドメインを切る方が現実的という認識
• Figmaのデータは全ページ揃っており、コンポーネント化（メガロス・ルネサンス等のテンプレート）とチェックポイント形式でキャンペーン更新を効率化するアイデアも出た
• 会員データは別プロジェクトとして動かす必要があるという認識も共有された

セッション概要

• 4月20日（月）18:00〜20:30に藤井・与田・藤本の3人で作業セッションを設定
• セッションの内容はリポジトリ共有・ブランチ切り方の確認、FigmaをベースにしたLP1ページのコーディング試作
• 与田さんへの事前準備依頼：現在作業中のLPページ・Figmaファイル・素材フォルダの場所を一元化したシートかメモを用意しておく

• 退職者アカウントの残存リスク（Slack・共有アカウント等）を早急に整理する必要があると確認
• AIを使った開発調査フローとして、まずClaudeにできる・できないを確認させ、難しければ藤本さんに要件を渡す流れを整理
• 通知はノイズになっているものがあると認識しており、今後は通知の取捨選択フェーズが必要
• 継続率向上プロジェクトでは、ダッシュボードを作る前にオペレーションの運用設計を先に固める方針に
• GeminiのNotebook機能リリースにより過去会話の参照が可能になり、社内活用のハードルが下がった
• AIポリシーはリスク管理の話が中心だったが、今後はノウハウ共有もこのミーティングのアジェンダに加えたい
• 与田さん・藤井さんへの対応（LP・リリース関連）が社内チームとしての最優先事項

• 退職者のアドレスとアカウントを自動削除するスクリプトを庄司氏がすでに作成・稼働中
• Slackはシングルサインオン（SSO）が使えれば一括解除できるが、現在の人数規模ではビジネスプランのコストが現実的でないため、手動での個別対応が現実的
• 共有アカウントに退職者がログインしたままになっている可能性があり、スペース予約などの不正利用リスクがある
• トレーニングアカウントと管理者アカウントの両方を削除する必要があると確認
• 定期的にSlackでパスワード変更を通知する運用を暫定対応として検討

• Claudeにデータ構造を見せることで「できる・できない」の判断が先にできるようになっており、それを活用する流れを整理
• できないと判明した場合は、コードレベルの詳細は不要で「やりたいこと・現状できないこと」をまとめて藤本さんに渡す形が適切
• 要件定義の深さについては、まずClaudeで実現可能性を確認してから藤本さんに当てるという段階的なアプローチで合意
• サイト公開に関わる与田さん・藤井さんは特に操作内容のチェックが必要という認識

• リアルタイムでは取れないデータをSQLで1時間に1回更新して通知データとして活用している
• データのリアルタイム性がないことによる認識のズレが現場でコミュニケーションコストになる可能性があり、「このデータは1時間に1回更新」と明示する運用を実施中
• 通知はノイズになっているものがあると認識しており、今後は通知の取捨選択・フェーズ分けを検討する必要がある

• 木曜午前に継続率向上を目的としたプロジェクトとして、トレーナーメンバーが追うべきデータを整理する取り組みを粕野さんと庄司氏で進めている
• ダッシュボードを作るだけでは意味がないという指摘があり、「このダッシュボードを見てこうする」というオペレーション設計を先に決めてから開発に落とす方針に
• 現場での検証を経てからシステム・ダッシュボードに落とすというターンを踏む流れで合意

• GeminiがNotebook機能をリリースし、過去の会話を参照できるようになったことで、Claudeと同様の使い方ができるようになった
• スプレッドシートやBigQueryのデータを活用したアウトプット、ミーティングでの数値確認など、データ周りでの活用体制を整えたい
• 4月に整備を進め、5月〜6月で体制を整えるイメージで動いている

• 現状はClaudeのリスク管理（権限・データ漏洩等）の話が中心で、社内ノウハウの共有はできていない
• stadiumsのアカウント経由でのみAIを使うよう発信することを検討しているが、「それ以外は使うな」というメッセージになりかねないため慎重に対応が必要
• リスク管理とノウハウ共有の2軸があり、後者をこのミーティングのアジェンダに加えていきたい

• 与田さん・藤井さんへの対応（LP・リリース関連）は社内チームとして最優先で、Gemini活用などの内部整備は1〜2週遅れても大きな問題にはならないという認識
• 与田さん・藤井さんが関わるリリース内容のトラブルは外部影響があるため、このチームとして対応温度感を上げる必要がある

• AIツール利用はこの会議の参加メンバー（藤井・藤本・与田・大石・庄司）に限定し、それ以外はGeminiに統一する方針を決定
• Claude Codeの社内利用は基本禁止とし、藤本さんが作成するルール（claude.mdベース）を読み込んだ上で承認を得た人のみ使用可とする
• 非公式プラグインやコミュニティ製ツールの使用を明示的に禁止 — マルウェアリスクが高いため
• GitHubのリポジトリ管理権限は藤本・藤井の2名に絞り、大石・庄司・与田にはレクチャー会を設けて段階的に展開する
• ホスティングはVercelを継続利用しつつ、ユースケースごとにGCPとの使い分けを検討する
• 社内ドキュメント環境はGitHubリポジトリ＋GCS（Googleアカウント認証）で整備を開始する

• 基本方針として社内AIツールはGemini（Google Workspace）に統一する
• Geminiで対応できない高度な用途のみ、承認を得た上でClaudeを使用する
• 庄司さんがエリアマネージャーへのClaude利用を現在すべてストップしている背景として、要件定義ができないまま使うと中途半端なアウトプットが出て修正コストが増大するという問題がある
• 儀間さんが2週間自分でClaudeを試した結果、庄司さんのアウトプットに頼るようになった事例が、制限の有効性を裏付けている
• Anthropicのデータ流出事件やMercariのAIポリシー公開（4月1〜2日頃）も、今このタイミングでポリシーを整備する根拠として共有された
• 藤本さんが今日の議論をもとにルールを整理し、大石さんにレビューしてもらう流れで進める

• Claude（特にClaude Code）の利用は当面この会議の参加メンバーに限定する
• エリアマネージャーへの展開は、藤本さんのclaude.mdを必ず読み込ませ、用途・条件を明示した上で承認する「ディプロマ方式」を採用する方向
• 庄司さんの整理として、オペレーション・サービスの根幹に関わる用途は禁止、ブランドコミュニケーションや情報整理など現場の細かい作業への活用は推奨する
• データ分析用途については、藤本さんが管理するBigQueryのデータを正しく参照できる環境を整えてから解放する方針 — 手元のスプレッドシートを使った独自分析は品質担保ができないため
• 大石さんの考えとして、将来的にエリアマネージャーが増えた際に庄司さん1人に相談が集中しないよう、同じレベルで使えるメンバーを育てることが必要

• 非公式・コミュニティ製のプラグインや拡張機能は使用禁止 — 約20%にマルウェアが仕込まれていた事例があるため
• VS Codeの拡張機能など、「動かなかったから代替を拾ってくる」行為が特に危険
• APIキー（FigmaのPersonal API、LINEのアクセストークンなど）はSlackの公開チャンネルへの投稿・検索インデックスへの露出を禁止する
• 認証情報を扱えるのはClaude Codeを使うメンバーと同一と考え、このメンバー以外には触れさせない
• 不明な点は藤本さんに確認する運用とする

• 現在リポジトリの最高権限（Admin）は藤本さんと藤井さんの2名が保有
• 他メンバーはそれぞれの役割に応じた参照権限のみ
• 大石さん・庄司さん・与田さんを対象にGitHubのレクチャー会を設ける
• 社内ドキュメントのリポジトリを新設し、すべての更新フローをGitに乗せる方針
• 藤井さんはAdmin権限を自分も制限したい意向だが、リポジトリ作成の必要性もあり検討中

• 現在のtheperson.comはWordPressをレンタルサーバー（Lolipop/Nagiサーバー）で運用しており、Next.jsへの移行に伴いVercelへの切り替えを検討中
• Vercelのメリットはプレビューデプロイ（PRマージ前にビジュアル確認できる）とGitHubとの自動デプロイ連携の手軽さ
• Vercelの費用感：Proプランで月約$60、帯域は1TBまで無料でその後は$0.15/GBの従量課金
• グループパーソナルは月間2万〜5万PVあるため、Vercelに乗せた場合のコストをユースケースごとに試算する必要があるという認識で一致
• GCPは大規模・複雑なサービスには適しているが、Vercelほどの手軽さはなく移行コストも発生する
• 結論として、現時点ではVercelで走り出しながら規模が変わったタイミングでGCPへの移行を検討する方針
• Cloudflareは役割が不明確になってきており、不要になる可能性がある

• 社内ドキュメント（経営会議の議事録、ブランドガイドラインなど）はGCS（Google Cloud Storage）にホストし、Googleアカウント認証でアクセス制限する方式を採用する
• この方式により、Google Workspaceアカウントを持つ社内メンバーのみが閲覧可能になる
• Cloudflareは社内ドキュメント用途では不要と判断しつつある
• まず社内ドキュメントのGitHubリポジトリ新設から着手し、Cloudflare経由で最速でデプロイできる環境を先行リリースする
• 与田さんはLP・グループパーソナルのホームページなどフロントエンドを担当する方向で、Vercelのアカウントを持つ想定
• プレビュー確認（藤本さんまたは藤井さんがOKを出してからマージ）のフローを確立することで、単独でのデプロイミスを防ぐ

• 静的ページの公開環境をCloudflare（社内クローズ）とVercel（Next.jsアプリのみ）に整理する方針で合意
• THE PERSONサイトの移行は一筋縄ではいかないことが判明し、Squarespaceのエクスポートを与田が4月2日までに調査
• LPリニューアルは7月のルネサンス切替に向けて進める方向で、藤井・与田が要件をまとめて藤本に共有する形に
• 藤本が次回ミーティングまでに社内AIセキュリティガイドラインをMarkdownでまとめる
• LINE APIのユーザー向け自動送信はゼロを維持する方針で合意、社内向けはテスト環境を経てから進める
• SlackのDMが全メッセージの60%を占めており、庄司はオープンチャンネルへの移行と経営向けSlackレポートの仕組み化を目指している

• 社内クローズで見せたいページは自前環境（Cloudflare）で公開する方針に決定
• プレゼン用など外部公開してよいものはCloudflareの無料公開機能で対応
• VercelはNext.jsなど動的アプリが絡む場合のみ使用し、触れる人数を絞る前提
• 社内クローズ環境の整備は大石が主導し、来週あたりから開発整理に着手する予定

• 既存サービスからのデータ書き出しはスクレイピングが必要で、簡単にはいかないことが確認された
• Squarespaceにはエクスポートがあるため与田が4月2日までに検証する
• 初回のデータ取得は藤本にサポートしてもらう方が効率的という認識で一致

• 7月のルネサンスへの切替タイミングで一斉リニューアルが必要になる見込み
• マーケティング側からはそれより早めに着手したいという声もある
• 藤井と与田で時間を作り要件を整理した上で藤本に共有し、このミーティングで方向性を確認する進め方を提案
• THE PERSONはNext.js＋microCMSで構築済みで、コンテンツ更新は開発不要の運用体制になっている
• LPはABテストや料金プラン変更など誤操作リスクがあるため、CMSではなく別の設計が必要という認識

• 藤本が次回ミーティングまでにMarkdownで資料をまとめる
• カバーすべき内容として藤井が挙げた項目：
  • AIツールの集約方針（Gemini中心、Claudeを使う場合のルール）
  • GCP・GitHubなど権限の大きい環境へのアクセス注意点
  • Geminiに入れてよいデータとそうでないデータの線引き
  • 顧客の前でAIに相談する行為の是非など対外的なルール
  • 機密情報の取り扱い基準

• VercelにダッシュボードをのせるとURLが変わり管理画面から切り離されるため、まず検証環境でガチャガチャ試す方針
• SpreadsheetのデータをVercelに渡す方法として大石はBigQuery↔Vercel直接連携のイメージを持っており、自分で調べる
• 庄司はこの1週間、トレーナー1人の課題解決にAIを使い続けており、機能拡充の限界（本番へのpush権限がない等）に当たり始めている
• ユーザーのログイン履歴が現状取れていないため、開発要望として藤本に上げる
• データ定義の変遷（大会・セッション等）がAIを混乱させているケースが複数あり、大石はdocsを読ませるよう促した

• 庄司の構想：SpreadsheetにユーザーIDと定型文を持たせ、送信ボタン1クリックでGAS経由でLINE Messaging APIに送る仕組み（自動送信ではなく人が最終送信）
• 大石はGASの不安定さ（意図しない再実行、重複通知）をプロダクション運用に乗せることへの懸念を表明
• LINE Messaging APIのキーごとの権限設定はロールレベル（AdminかMemberか）のみで細かい機能制限はできないことを与田が確認
• 合意した方針：ユーザー向けの自動通知はゼロを維持、社内・トレーナー向けの検証は継続してよい、新機能は必ず藤本にレビューしてもらいテスト環境を経てから本番へ
• LINEのIDデータはSpreadsheetに蓄積しているが、理想は管理画面内で操作できる状態にすること（大石）

• SlackのDMが全メッセージの60%を占めていることが確認された
• 庄司はSlackをLINEのように使っているメンバーが多く、情報がサイロ化していると指摘
• 経営陣向けにSlackの数字（DM件数、チャンネル活動等）を自動レポートする仕組みを作りたいというのが庄司の意向
• オープンにできないやり取りはそもそもすべきでないという原則を庄司は持っており、DMを減らす方向に動きたい

• AI制作物の棚卸しと運用整備、セキュリティルール策定を中心に確認した
• LPのVSCode化は与田担当で4月10日までに1ページ完全再現をゴールに設定
• Claude設定のセキュリティは settings.json でハードブロックする方針に決定、藤本が整備を担当
• Vercel・Cloudflare・Google Cloudの住み分けを整理し、本番運用はGoogle Cloudに統一する方向性を確認
• 与田がGoogle CloudでAPIキーを個人作成していた件は内容をまとめてAIプロジェクト管理チャンネルに共有することに

• 与田の制作物はLINE CRMなど個人開発止まりで、一部コードを庄司の運用に提供している程度
• 与田が定期的に使っているのはGoogle Mapsの口コミ返信を生成するGPTs/GEMの2つ程度
• 大石はダッシュボードを作ったが現場に渡した状態で、自分では進んでいない
• 大石はダッシュボードをチームで触れる状態にするには、デザイン観点のフィードバックを経て再度進める必要があると考えている
• 藤本はコードベースの制作物だけでなく、AI活用全般を管理・記録・ウォッチできる状態にしたい
• 与田がGEMについて共有し、藤本・藤井ともに未使用のため今後情報共有する流れに

• 現状20〜30店舗分のLPをStudioでポチポチ編集しており、ABテストや更新に時間がかかりヒューマンエラーも発生している
• VSCode化することで運用コスト削減とミス防止が見込めると藤井が説明
• 藤井が主導し与田が担当、まず既存サイトからのデータエクスポート方法を調査することが最初のステップ
• 4月10日（3週間後）までに1ページ完全再現をゴールに設定し、そこから工数見積もりとリリース日を判断する
• コード管理方法（GitHub等）は継続議論

• 藤井がBeThePerson的サイトでWordPress→MicroCMSの移行を完了、来週公開予定
• VSCodeでMicroCMSのAPIを繋ぎ、WordPressからダンプしたファイルと画像ファイルを取り込む形で移行した
• APIスキーマに要素名を定義しておけば全記事が自動で入るため、人手がほぼ不要だった
• 同じ構造でTHE PERSON本体サイトにも展開できる確信を得た

• 藤井が店舗イベント用バナー生成ツールを作成済み（「からだの保健室」フォーマットを参照して生成）
• ランニングイベントやパーソナルストレッチのバナーをAIで出力している
• 運用に乗せる方法を与田と相談したい
• HTML資料化（マンスリー資料をHTMLベースで作る）も進行中で、うまくいったら次回ミーティングで運用相談予定

• 藤本がMarpを紹介 — マークダウンで書いたコードをHTMLスライドとして出力できるVSCode経由のツール
• Claudeに「Marpで作って」と指示するだけでスライドが生成される
• 藤井が作っているHTML資料化と近い仕組みで、印刷・スライドショー両対応
• ClaudeがコードをHTMLとして吐き出してウェブ化する流れが機能している

• CLAUDE.md は確率的な制御にすぎず、「いいからやって」と言えば無視される可能性がある
• ハードブロックには settings.json に定義するのが最も確実で、使ってはいけないコマンドはここで決める
• CLAUDE.md は運用プロンプトを省力化するためのまとめ用途に留める
• mainへの直接プッシュ禁止などのルールを settings.json で設定することを大石が要望、藤本が整備を担当
• APIキーを扱う際のルールも決めておく必要があるが、現状APIキーを使っているメンバーはほぼいない

• VercelはNext.jsベースのフロント・サーバー・DBまで一貫して作れるサービスで、現在は藤本・藤井のアカウントで運用中（大石は個人アカウント）
• VercelにあげたURLはデフォルトで外部から見られる状態になるため、公開物には必ずパスワードをかけるルールが必要
• Cloudflareはデータ配信特化で、DBを使わないページであれば無料枠で公開可能（50人まで）
• 50人を超える場合はGoogle Cloudに自前で仕組みを構築する方向
• 住み分け案：試作・内部共有はVercel（藤本・藤井のみ閲覧）またはCloudflare、本番運用はGoogle Cloudに統一
• Google Cloudに統一すればstadiumsアカウントを持つ人だけがアクセスできる認証を一元管理できる
• 大石はダッシュボードなど社内情報を含むものをURLだけで見られる状態にしたくないと考えており、認証整備を優先したい意向

• 与田がstadiumsアカウントでGoogle Cloudプロジェクトを個人作成し、APIキーを使っていたことが判明
• 内容はGoogle Businessプロフィール情報取得用のAPIと、画数ボット程度と与田が説明
• 詳細をまとめてAIプロジェクト管理チャンネルに共有することに
• 組織として運用するプロジェクトはGoogle Cloudに統一し、APIキーの管理ルールを整備する方向

• 社内AI活用の方針を整理する定例会議を新設し、ツール・セキュリティ・データ管理の基本方針を合意した
• 全スタッフの公式AIツールは Google Workspace / Gemini に統一、Claude Codeは経営層以上のみ利用可とし、藤本さんがセキュリティルールを整備する
• 生データや顧客情報をAIに入力することは禁止、データはダッシュボード経由で参照する方針に決定

• 各自がバラバラにAIツールを試している状態を整理し、活用方針・セキュリティ・プロジェクト管理を定期的にレビューする場として本会議を立ち上げた
• 藤本さんが課題感として挙げたのは、個別に作ったものが最終的に活用されるかどうか曖昧なまま進んでしまうこと、および与田さんのLINE連携ツールなどセキュリティ上注意が必要なものが混在していること

• 藤井さんが参照した他社事例（大規模フィットネス企業）から、AI活用を阻む壁として「ルールの壁」「ワークフローの壁」「カルチャーの壁」の3つを整理した
• ルールの壁として最優先で対処すべきなのは、BigQueryのデータをAIに直接食わせないこと、顧客の個人情報は絶対に入力しないこと
• 大石さんが出力しているデータは全て機密情報であることを庄司君が確認した
• 大石さんは、リテラシーが不十分なままClaude Codeを使うとドライブの上書き・削除などの重大なリスクがあると指摘した

• stadiumsのメールアカウントを持つスタッフは Gemini（Google Workspace） を公式ツールとして使う方針に決定した
• GPTは個人アカウントだとブラウザに履歴が残るためNG、エンタープライズ契約がない現状ではGemini一択という結論になった
• Claude（個人プラン）は量オーバーで追加課金できないケースもあり、業務利用には不向きと判断した
• 単純な資料まとめ等はClaude CodeではなくチャットベースのツールやGeminiで十分という認識を共有した

• Claude Codeは破壊力が最も高いツールであるため、経営層以上のみ利用可とする方針を大石さんが示した
• 藤本さんが .claude 設定ファイル（.claude/settings.local 等）でコマンドの deny ルールを設定する仕組みを説明した
  • 例：Gitの自動コミット禁止、.env ファイルの読み取り禁止
• CLAUDE.md に方針を書くだけでは確率的にしか守られないが、設定ファイルのdenyルールはより確実に機能すると藤本さんが説明した
• 環境変数（APIキー等）の漏洩リスクについても言及し、GASを使う場合はスクリプトプロパティに入れる庄司君の現行運用は適切と確認した
• Slack WebhookURLはBotトークンより漏洩リスクは低めだが、Botトークン系は厳重に扱う必要があると藤本さんが整理した
• Claude Codeを使う人向けの最低限のセキュリティルールを藤本さんが整備する

• 庄司君はSQLファイルでBigQueryに接続し最新データをスプレッドシートに出力しているが、どのデータが正式運用中かの管理が曖昧になっているという課題を藤本さんが指摘した
• 生データをスプレッドシートで個別に見るのではなく、ダッシュボードに集約してみんなが参照できる状態にするのがゴールと大石さんが方向性を示した
• 藤井さんが大石さんのダッシュボードをリポジトリ化し、修正できる状態まで整備したいと提案した
• 藤井さんはWebプロジェクトはGitHubで管理できているが、データ系プロジェクトも同様にGitHubで最新版を一元管理したいと考えている

• 大石さんはGeminiのGem機能を使えば、ブランドガイドラインを読み込ませたスキル（Gem）を作れると提案した
• トレーナーが顧客情報をまとめる、メール・LINEの文章を考える、資料を見やすくするといった用途にGemが有効と大石さんが説明した
• 藤井さんはブランドガイドラインを毎回読み込ませるのが手間だと感じていたが、Gemにすれば解決できると気づいた
• Geminiはまだ誰もあまり掘り下げていない状態で、活用Tipsとオペレーションルールの整備が必要と大石さんが指摘した
• stadiumsメールを持つ副店舗責任者レベルまでのメンバー全員にGeminiを浸透させることを会社としてのミッションとして持つ方向性を確認した
• 庄司君はGemini活用の意識づけとして、週次でSlackに「このプロンプトを使っていますか」と通知する仕組みも提案した

• バイブコーディングで開発が進んでいる現状に対し、大石さんが「何を解決したいか」を定義したPRDを事前に用意すべきと提案した
• 藤井さんが、経営層がClaude等で新しいプロジェクトを始める際にPRDを自動生成するシステムを組む案を提案し、大石さんが賛同した
• 「数字を見えるようにしたい」「評価ログを取りたい」「ダッシュボードでチームごとの数字を見たい」はそれぞれ全く異なるタスクであり、PRDで目的を明確にしないと複合的なタスクになって迷走するという認識を共有した

• 庄司君がクライアントとの電話中にTypress（音声入力ツール）を起動し、ヒアリング内容をリアルタイムで文字起こしするワークフローを共有した
• 事前にAIでヒアリング項目を5分で生成し、電話中に音声入力で全て入力し切るという流れで、ヒアリングのスピードが大幅に向上したと庄司君が説明した