• 社内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分で生成し、電話中に音声入力で全て入力し切るという流れで、ヒアリングのスピードが大幅に向上したと庄司君が説明した