LP・バナー・スライド・ブランドブックなど、ビジュアルを伴う成果物の制作。
- LP / ランディングページ（STUDIO → 移行検討中）
- セミナースライド・バナー
- ブランドガイドライン
- メルマガデザイン
庄司くんが進めているようなカスタマーサクセス系から、UIで可視化されたダッシュボードまで。
- カスタマーサクセス系システム（庄司くん担当）
- ダッシュボード UI（Crisp / サラダワークス参考）
- ウェビナー申込管理・会員DB
接客マニュアルやプログラム解説を映像化・音声化し、再現性のある教育コンテンツに。
- 接客マニュアルの動画化
- プログラムのボイス付き解説
- Insta360 等ウェアラブルカメラ活用
メルマガ・セミナー・バナーなど、繰り返し発生するアウトプットをテンプレート化・標準化する。
- メルマガ作成テンプレート
- セミナースライド・バナー標準化
- 品質標準化ガイドライン整備
| プロジェクト種別 | Google Drive | Claude | GitHub | Vercel | Figma | Draw.io |
|---|---|---|---|---|---|---|
| A サービス・ システム系 |
企画書・議事録
|
PRD・要件整理
コード支援 |
ソースコード管理（必須）
|
本番・プレビュー
デプロイ（必須） |
UI設計・
デザインカンプ |
システム構成図
（必要に応じて） |
| B シンプルな ウェブサイト |
コンテンツ原稿
更新フロー管理 |
コピー生成
コード修正支援 |
ソースコード管理（必須）
|
デプロイ（必須）
|
必要に応じて
|
基本不要
|
| C 企画書・ ドキュメント |
メイン管理（必須）
共同編集・共有 |
下書き・構成整理
要約・翻訳 |
Markdownドキュメント
（必要に応じて） |
不要
|
必要に応じて
|
フロー図・
ブループリント |
VS Code で Claude を使いコードを書き → GitHub に上げて藤本さんにレビュー（PR）してもらい → 問題なければ本番（Vercel）に反映。この流れをチーム共通の基本ワークフローとして確認する。
- 基本フロー：VS Code + Claude → GitHub PR → レビュー → Vercel 自動デプロイ
- 分業の可能性：フロントのビジュアル面は自分たちが作り、システム連携はエンジニアに依頼
- 「アンケート画面だけやっておいて」といった部分担当が可能になる
- 実証済み：THE PERSON クローンを完全再現し、エンジニアコストをかけずに修正できた
GitHub でのバージョン管理・ブランチ運用はエンジニア寄りで複雑。プロジェクト規模・性質によってフローを分ける。
- 大規模プラットフォーム（大石さんのマッチングなど）→ GitHub 管理必須・上書きミスを防ぐ
- LP 等シングルページ → 最終的な「公開ボタン」を自分が押すことがレビューを兼ねるシンプルフロー
- 資料・バナー・スライド・メルマガ → Google Drive 完結（最新版がフォルダにある状態が重要）
- ツールごとのフローを整理し、誰が何をどこで管理するかを決める
AI で生成すると、最終的にすべてを管理できるのが藤本さんだけになりがち。「こういう観点でチェックする」マニュアルを作り、エラーが出た際もメンバーがある程度対応できる体制を作る。
- 「AI藤本チェッカー」：エラー対応・検品チェックリストを整備し、自分たちでも対応できる状態に
- メンバー間の知識差があっても全体の設計を崩さずに進められる方法を議論する
- レビュー用ナレッジ（裏側の知識）を蓄積しておく仕組み
知り合いのエンジニアの家では Mac mini を8台動かしてエージェントを走らせている。VS Code を立ち上げなくても、スマホから Discord や Slack で指示するだけで AI が裏で作業を続けてくれる。
- 常時稼働サーバー：オフィスに1台置き、何を担当させるかを決める
- 自動リサーチ：「月曜朝にAI・健康・ジムのニュースを配信」などのタスクを自動化
- 創造的な行為はチェックが必要だが、リサーチ・クローン作成なら任せられる
- APIコスト最適化：Opus → Sonnet に変えることで現実的な運用コストに
現状はGAS（Google Apps Script）を使う場面が多い。アンチグラビティ（Google製）はGASの構築まで自動化できる可能性があり、VS Code に入れて Claude と両方使い分ける体制を検討したい。ただし、連携を増やしすぎるとリスクも増大するため、ガイドラインが先に必要。
- アンチグラビティ：GAS側だけで完結させ、GAS構築まで自動化できる可能性（Google製なので親和性が高い）
- VS Code にアンチグラビティを入れて、Claude との使い分けを設計（やりたいことに応じて得意な方に任せる）
- Slack通知まで含めた全オペレーション自動化の可能性（名前が出たらメンションを飛ばすなど）
- ⚠️ リスク：連携を増やすほどリスクも増大 → つなぎ込みのガイドラインを先に整備する
- Google Drive を繋いだままでいいのかなど、3〜4人の意識を揃えておく必要がある
現状は募集・アンケートがバラバラに来ている状態。THE PERSON のサロン・会員システムとして、申込フォーム → 決済 → 会員DB → 配信連携を一本化する。
- 申込フォーム（入口）の統一
- 会員データベースの設計（誰がどのウェビナーに参加したか）
- メール / LINE 通知との連携
- 将来的にサロン会員システムへ拡張
現在 STUDIO で運用しているLPは、画像を貼るだけの構造でSEO・読み込み速度・alt属性に課題がある。テキストが正しくHTMLとして構造化された状態に移行し、Claude Codeで量産できる体制を整える。このまま放置して工数が削られるのはもったいない。
- 現状のSTUDIO LP棚卸し・移行優先度の整理
- HTML構造化・alt属性・読み込み速度の設計
- Claude Codeで量産できるテンプレート化
- AIクローリング許可 / 拒否設定と SEO への影響確認
シェアリング向けウェブサイト制作と、スポルタ / 福永さん案件のトレーナー向けコンテンツ一覧。コンテンツが可視化されれば登録者数の増加が期待できる。
- シェアリング 表（おもて）サイトの設計・制作
- トレーナー向けコンテンツ一覧ページ（スポルタ / 福永さん）
- プラットフォームの表層として実装するか専用ページとして作るかを検討
フロントエンド・バックエンドの基礎理解を深めながら、チームで共有できる開発ルールを整備する。
- 「このアタックにはこう対応する」セキュリティルールの文書化
- リンク切れ・エラー対応の標準フロー
- LLM / SEO を意識したページ構成ガイドライン
以前、連携を強めすぎた際にGitHubリポジトリが勝手にパブリック設定になる事案が発生。読み取り専用のつもりでもツール側が気を利かせて権限を上げてしまう可能性がある。役割ごとに権限を明確に分け、アカウント制限をしっかりかけておく。
- 庄司くん：オペレーション・データ担当 → 書き込み権限不要・読み取り専用でローカル作業
- 内部オペレーション：読み取り専用でデータを並べ替え・社内コミュニケーションに活用
- ユーザー向け公開（藤井さん・青井さん）：内部オペレーションとは線引きを徹底
- BigQuery にはメアド・電話番号が出ないためAI活用時のリスクは低い
- robots.txt / WAF 等によるAIスクレイピング対策・SEOへの影響バランスも検討
- 「理解がなくても安全に動ける」状態の設計
参考サービスをリサーチし、表層だけでなく裏側の機能構成まで推測してGitHubに蓄積。再利用できるノウハウとして整理する。
- 参考サイト・サービスのリサーチリポジトリを GitHub に作成
- UI / UX パターン分析と機能構成の推測ドキュメント化
- Claude Code で実装してクローン的なプロトタイプを蓄積
藤本さんの開発ノウハウを学習した「エージェント藤本」、藤井さんの過去リファレンス・意思決定パターンを読み込んだ「エージェント藤井」を構築。壁打ち相手・ゲートキーパーとして機能させる（「それやる意味あるの？」と突っ込んでくれる存在）。ノウハウの公開範囲と信頼できるメンバーへのアクセス制限の設計は慎重に。
- 藤本さんのノウハウ → CLAUDE.md / ドキュメントへの言語化
- 藤井さんの過去リファレンス・資料をフォルダに集約してコンテキストとして読み込み
- ノウハウの公開範囲・信頼できるメンバーへのアクセス制限の設計
YAMLブランドガイドラインや動画マニュアルなど、更新のたびにSlack通知+URLダウンロードを求めても誰もダウンロードしない。解決策は「常に最新版を返す参照URL」を用意し、全員がそこを起点とするルールにすること。更新を知らないメンバーも常に最新版で作業でき、通知が来るだけで「これが最新だ」と視覚的に伝わる。
- Google DriveのHTMLをソースURLとして参照 → そのURLが常に最新版を返す
- スラッシュコマンド（/resource/path）でClaudeやAIツールが参照先を引っ張ってくる仕組み
- 「まずここをベースに」という最初のコミュニケーションをそのURLに集約するルールにする
- ローカル開発との使い分け：Google Drive上のリソースをVS Codeで直接読み込むとエラーや遅延が出るため、参照URLを介す
- PDF（閲覧・印刷向け）/ YAML（AI・システム入力向け）/ 共有フォルダ（用途別）の使い分けも整理
手触り感がなくても思い通りのクオリティの資料が出てくる状態を作りたい。グラフ・図解を自分で作り込まなくても、相手の期待値に合わせたアウトプットが出せる仕組み。
- 現状苦手なグラフ作成を可視化ツールとして適切に扱えるようにする
- 試行錯誤した結果をドキュメントとして送れば、藤井さん側で集約できる仕組みを作る
- クライアント / KPI の期待値に合わせて図解を出し分けられるようにする
VercelはプレビューURLが出るので使いやすいが、Cloudflareの仕組みがいまいち分かっていない部分がある。開発中のものはセキュリティ的に危ないので、認証機能の活用を検討したい。
- Cloudflare Access：特定のメールアドレス保持者しか見られない認証機能 → 開発中ページに活用
- Next.js → Vercel が反映が早い。ペラ1枚のページなら Cloudflare でも十分かを藤本さんに確認
- URLに個人名が入ってしまう点などは許容範囲か整理する
データが見えてくると「このタイミングでこういうUIがあれば」というアイデアが次々と出てくる。キャプチャ→言語化→リスト化の従来手法は非効率。Figmaのブループリントレベルで対話できる環境を作りたい。
- 決定事項プロジェクトと、その手前にある中間的なアイデアをどう接続するかが重要
- Figmaのローカルを見せながら「ここにこういう動線があれば、こういうユーザーインサイトが作れる」という対話を増やす
- プロトタイプ（ブループリント）レベルでの議論をチームの標準にする
思いついたことを言えば回答を引っ張ってきてくれるような環境をメンバー全員が持てるといい。ただし、アカウント設定を適切に行わないと個人のアクセストークンに紐づいてしまうなどのリスクがある。
- MCPを使うと外部ツール（Slack / Notion / Google Drive など）をAIが直接参照・操作できる
- アカウント設定の構造化：個人トークンではなくチーム共有のサービスアカウントで管理
- 誰がどのMCPサーバーにアクセスできるかの権限設計を先に決める
現状、BigQueryから1時間に1回ローカルにデータを落とす仕組みで動いている。コードには仕組み・設計・やり方がインストールされており、最新データは1時間毎に担保される。庄司くんのFigma MCPと同様に、生データへ直接アクセスできれば何が変わるかを議論したい。
- BigQuery → 1時間に1回ローカルに落とす / ソースコードも渡した時点のタイムスタンプで保持
- Slackの通知チャンネル履歴・スプレッドシートの生データにAIを繋げるだけでアウトプットの質は変わる
- 初回アンケート体制・退会分析など、生データへのアクセスで分析の深度が変わる
- 「これは無理」という判断基準を共有しておくことでアイデアの精度が上がる
- アイデアの源泉が庄司くん一点に偏っている問題を解消 → 庄司くんの脳みそをどこかに貯めておく仕組み
- 「庄司エージェント」：庄司くんのリソース・ナレッジをエージェント化して直接アクセスできる状態に
VSCodeローカルでワクワクするアウトプットが上がってきている。粒度がバラバラで、まだブランチ管理するフェーズでもない。ちょろっと出たアイデアをどう回収・同期するかを決めたい。そして、カスノエージェントのデモを見てほしい。
- 現状の課題：出したいものの粒度がバラバラ・まだ事業売上に直結するフェーズではない
- 解決案A：PRD検討会のような場で上がってきたものをバシバシ捌いていく
- 解決案B：「エージェント・カスノ（仮）」のような仕組みを作って管理する
- 🎤 デモ：Circlebackにある発言を全部まとめてエージェント化した「カスノエージェント」を見せる