Compound Engineering：AIネイティブなエンジニアリング哲学

• すべてのエンジニアリング作業単位が後続の作業をより容易にする複利型ソフトウェア開発方法論であり、AIエージェントとの協業を体系化した**4段階ループ（計画→実行→レビュー→複利化）**を中核として構成
• 反復ループでは、エンジニアの時間の80%を計画とレビューに、20%を実行と複利化に配分すべき
• 26個の専門エージェント、23個のワークフローコマンド、13個のスキルを含むプラグイン形式で配布され、Claude Code・OpenCode・Codexにインストール可能
• 既存のソフトウェア開発における8つの通念（コードは手で書くべき、すべての行を手動でレビューすべき、など）を捨てるべき信念として提示し、システムに好みをエンコードする新しい原則を採用すべき
• 開発者のAI導入レベルを0段階（手動開発）から5段階（並列クラウド実行）まで区分し、各段階ごとのレベルアップ方法と、チーム協業・デザイン・リサーチ・マーケティングまで拡張した包括的フレームワーク

---

中核哲学

• 各エンジニアリング作業単位が後続の作業をより簡単にすべきだというのが中核原則
• 従来のコードベースは機能追加のたびに複雑性が増し、10年後にはシステムと戦うことにより多くの時間を費やすようになる
• Compound Engineeringでは、機能がシステムに新たな能力を学習させ、バグ修正が将来のバグカテゴリ全体を除去し、パターンがツールへと変換されることで、コードベースは時間が経つほど理解・修正・信頼しやすくなる

メインループ: Plan → Work → Review → Compound

• Everyチームは5つの製品（Cora, Monologue, Sparkle, Spiral, Every.to）を主に1人エンジニアリングチームで運営しており、それを可能にしているのがこの4段階ループ
• 最初の3段階（計画、実行、レビュー）は一般的だが、4段階目のCompoundで複利的な利益が蓄積される点が中核的な差別化要素
• 5分のバグ修正でも数日かかる機能開発でも同じループを使い、各段階に投入する時間だけを調整

• 1段階: Plan（計画）

  • 要件理解: 何を作るのか、なぜ作るのか、どのような制約があるのかを把握
  • コードベース調査: 類似機能の動作方式と既存パターンを分析
  • 外部調査: フレームワーク文書、業界のベストプラクティスを確認
  • ソリューション設計: アプローチと変更対象ファイルを決定
  • 計画検証: 計画全体の完全性と整合性を確認

• 2段階: Work（実行）

  • 分離環境の設定: Git worktree（リポジトリの分離されたコピー）またはブランチで作業を分離
  • 計画実行: エージェントが段階ごとに実装
  • 検証実行: 変更のたびにテスト、リンティング（自動コード検査）、型チェックを実施
  • 進捗状況の追跡と、問題発生時の計画修正
  • 計画を信頼できるなら、コードを1行ずつ監視する必要はない

• 3段階: Review（レビュー）

  • 複数のエージェントが並列でコードレビューを実施
  • 発見事項を**P1（必須修正）、P2（推奨修正）、P3（改善事項）**で優先順位付け
  • エージェントがレビューのフィードバックに基づいて問題を修正し、修正結果を検証
  • パターン記録: 何が問題だったのかを文書化して再発を防止

• 4段階: Compound（複利化） — 最も重要な段階

  • 従来の開発は3段階で終了するが、Compound段階でシステム改善が蓄積する
  • 最初の3段階が機能を生み出すなら、4段階目は機能をよりうまく作るシステムを生み出す
  • 実施内容:
    • 何が有効で何が有効でなかったか、再利用可能な洞察は何かを捉える
    • YAML frontmatterでメタデータ、タグ、カテゴリを追加して検索可能に設定
    • 新しいパターンをCLAUDE.mdに追加し、必要に応じて新しいエージェントを作成
    • 「次回はシステムがこの問題を自動で検出できるか？」を検証

プラグイン構成

• 26個の専門エージェント: レビュー（14個）、リサーチ、デザイン、ワークフロー、ドキュメント化など、それぞれ特定業務に特化
• 23個のワークフローコマンド: メインループ + ユーティリティ
• 13個のスキル: エージェントネイティブアーキテクチャ、スタイルガイドなどのドメイン専門性を提供
• Claude Code、OpenCode（実験的）、Codex（実験的）にゼロ設定でインストール可能

• ファイル構造

  • CLAUDE.md: エージェントが各セッション開始時に読む最重要ファイルで、好み・パターン・プロジェクトコンテキストを保存
  • docs/solutions/: 解決済みの問題が検索可能な文書として蓄積され、**制度的知識（institutional knowledge）**を構築
  • docs/brainstorms/: brainstormコマンドの出力を保存
  • docs/plans/: planコマンドの出力を保存
  • todos/: 優先順位と状態別に作業項目を追跡

中核コマンド

• /workflows:brainstorm

  • 何を作るべきか不明確なときに使うコマンド
  • 軽量なリポジトリ調査の後、目的・ユーザー・制約・エッジケースを一つずつ質問しながら明確化
  • AIがアプローチを提案し、結果はdocs/brainstorms/に保存されて/workflows:planへハンドオフ

• /workflows:plan

  • やりたいことを説明すると実装計画を返す
  • 3つの並列リサーチエージェントを実行: repo-research-analyst（コードベースのパターン）、framework-docs-researcher（文書）、best-practices-researcher（業界標準）
  • spec-flow-analyzerエージェントがユーザーフローとエッジケースを分析
  • ultrathinkモード有効時は**/deepen-plan**が自動実行され、40個以上の並列リサーチエージェントが稼働

• /workflows:work

  • エージェントが実際のコードを書く段階
  • 4つのフェーズ: quick start（Git worktree作成とブランチ設定）→ execute（進捗追跡とともにタスク別実装）→ quality check（任意で5個以上のレビュアーエージェントを起動）→ ship it（リンティング実行、PR作成）

• /workflows:review

  • PRを14個以上の専門エージェントが並列で同時レビュー
  • セキュリティ（security-sentinel）、性能（performance-oracle）、アーキテクチャ（architecture-strategist）、データ完全性（data-integrity-guardian）、コード品質（code-simplicity-reviewer）、フレームワーク別レビュアー（DHH-rails, Kieran-rails/python/typescript）、デプロイ検証、フロントエンドのレースコンディション、エージェントネイティブレビュアーなどを含む
  • 出力はP1（クリティカル）、P2（重要）、P3（軽微）に分類された単一の優先順位リスト
  • /resolve_pr_parallelコマンドで発見事項を自動修正（P1優先、各修正は分離実行）
  • /triageコマンドで発見事項を一つずつ承認・スキップ・カスタマイズしてフィルタリング可能

• /workflows:compound

  • 解決済みの問題を将来参照用に文書化
  • 6つの並列サブエージェントを起動: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • YAML frontmatterを含む検索可能なMarkdownを生成

• /lfg

  • 機能を説明すると、エージェントが計画・実装・レビューまでをすべて実行してマージ可能なPRを提出
  • plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compoundの全パイプラインを連結
  • 計画承認時に一時停止した後、自律的に実行し、全段階で50個以上のエージェントが稼働

捨てるべき8つの思い込み

• 「コードは手で書くべきだ」

  • 実際に求められているのは、保守可能で正しい問題を解決する良いコードを書くことであり、誰がタイピングするかは重要ではない

• 「すべての行を手動でレビューしなければならない」

  • 手動の行単位レビューは品質保証の一つの方法にすぎず、同じ問題を検出する自動化システムも有効
  • 結果を信頼できないなら、自分でやることで埋め合わせるのではなく、システムを修正すべき

• 「ソリューションはエンジニアから生まれるべきだ」

  • AIはアプローチの調査、トレードオフ分析、選択肢の提案ができるため、エンジニアの役割はテイスト（taste）を加えること――このコードベース、このチーム、この文脈にどの解決策が合うかを判断すること

• 「コードが主要な成果物だ」

  • コードを生み出すシステムは、個々のコードよりも価値がある
  • 一つの優れた実装よりも、一貫して良い実装を生み出すプロセスが重要

• 「コードを書くことが中核業務だ」

  • 開発者の仕事は価値を届ける（ship value）ことであり、コードはそのための入力の一つ
  • 計画、レビュー、システムの教育もすべて仕事に含まれる

• 「最初の試みが良くなければならない」

  • 最初の試みの不良率は95%、2回目でも50%
  • これは失敗ではなくプロセスであり、3回目の試みが1回目より速く完成するよう、高速な反復に集中すべき

• 「コードは自己表現だ」

  • コードはチーム、プロダクト、ユーザーのものであり、コードを自己表現として見なさなければ、フィードバックの受け入れ、リファクタリング、品質に関する議論が容易になる

• 「たくさんタイピングするほど多く学べる」

  • 今日では筋肉の記憶より理解が重要
  • AIによる実装10件をレビューする開発者のほうが、自分で2件をタイピングした開発者より多くのパターンを理解する

移行プロセスにおける心理的な課題

• タイピングが減ると、あまり仕事をしていないように感じる: 実際には、エージェントへの指示は実装そのもの以上の思考を要求する
• 自律実行への不安: それは制御権を手放すことではなく、制約・ルール・レビュープロセスに制御をエンコードすること
• 「これは自分が作ったものなのか？」という疑問: 計画、レビュー、品質基準の確保こそがその仕事であり、AIは記述だけを行う

採用すべき考え方

• システムにテイストを抽出すること

  • 命名規則、エラー処理パターン、テストへのアプローチなど、開発者のテイストは通常文書化されず、シニアエンジニアの頭の中に存在している
  • CLAUDE.md または AGENTS.md にこうした好みを記録し、レビュー・テスト・デプロイ用の専門エージェントとスキルを構築して、AIが承認に値するコードを自ら生み出せるようにすべき

• 50/50ルール

  • エンジニアリング時間の50%を機能開発、50%をシステム改善に配分する
  • 従来は90%が機能、10%がその他だが、レビューエージェントの作成、パターンの文書化、テスト生成器の構築などは、将来の機能開発をより容易にする投資
  • レビューエージェントへの1時間の投資で、1年間に10時間のレビュー時間を節約できる

• プロセスを信頼し、安全網を構築すること

  • AI支援を拡張するには、すべての行を人間がレビューすることはできないため、テスト、自動レビュー、モニタリングのようなガードレールの構築が鍵になる
  • 成果物を信頼できないなら手動レビューに戻るのではなく、その段階を信頼できるようにするシステムを追加すべき

• 環境をエージェントネイティブに構成すること

  • 開発者が見たり実行できたりすることは、エージェントにもできるべきだ。たとえば、テスト実行、プロダクションログの確認、スクリーンショットのデバッグ、PR作成など
  • エージェントに許可していない作業はすべて、自分で手動で実行しなければならない

• 並列化を活用

  • 過去のボトルネックは人間の注意力（一度に一つのタスク）だったが、新たなボトルネックはコンピュート（同時に実行できるエージェント数）
  • 複数のエージェント、複数の機能を同時に動かし、レビュー・テスト・文書化も並列に進める

• 計画が新しいコード

  • 計画文書が今や最も重要な成果物
  • 先にコードを書いて後から文書化するのではなく、先に計画を書けば、エージェントがコードを生成・テスト・検証するためのソース・オブ・トゥルースとして活用できる
  • アイデアを紙の上で修正するほうが、コード上で修正するより安い

• 中核原則の要約

  • すべての作業単位は、後続作業をより簡単にするものであるべき
  • テイストはレビューではなくシステムに組み込むべき
  • 自分で作業するのではなく、システムを教えるべき
  • レビュープロセスではなく安全網を構築すべき
  • 環境をエージェントネイティブに構造化すべき
  • 複利的思考をあらゆる場所に適用すべき
  • 委任の不快さを受け入れ、完璧だが拡張不可能な結果より、不完全でも拡張可能な結果を選ぶ
  • より少ないコードを書き、より多くの価値を届けるべき
  • これらの原則はエンジニアリングを超えて、デザイン、リサーチ、執筆など、テイストと文脈のコード化が役立つあらゆる分野に拡張可能

開発者の成長段階（5段階ラダー）

• Stage 0: 手動開発

  • AIなしでコードを1行ずつ書き、ドキュメントと Stack Overflow で調べ、print文でデバッグする
  • それでも何十年にもわたって良いソフトウェアを作ってきたが、2025年には十分に速くない

• Stage 1: チャットベースのアシスタンス

  • ChatGPT、Claude、Cursor などに質問してコードスニペットを受け取り、有用なものをコピー＆ペーストする
  • AIがリサーチとボイラープレート生成を加速するが、すべての行を自分でレビューし、完全な制御を維持する

• Stage 2: エージェント型ツール + 行単位レビュー

  • Claude Code、Cursor Composer、Copilot Chat などのエージェント型ツールがファイルを読み、コードベースに直接変更を加える
  • エージェントの提案するすべてを承認/却下するゲートキーパー役
  • ほとんどの開発者はこの段階で停滞し、AI委任の利点を享受できない

• Stage 3: 計画優先、PRレベルのレビュー

  • すべてが変わる段階。要件・アプローチ・エッジケースを含む詳細な計画をAIと共同作成する
  • 計画を立てた後はAIが監督なしで実装し、成果物はPRとしてレビューする
  • Compound Engineeringはここから始まる――各サイクルの計画・実装・レビューがシステムを学習させ、次のサイクルをより速く、より容易にする

• Stage 4: アイデア → PR（単一マシン）

  • アイデアを与えると、エージェントがコードベース調査、計画、実装、テスト、自己レビュー、課題の解決、PR作成まですべて処理する
  • 関与はアイデア提示、PRレビュー、マージの3段階に縮小される
  • まだ1台のコンピュータで一度に一つしか実行しない

• Stage 5: 並列クラウド実行（マルチデバイス）

  • 実行をクラウドへ移し、並列実行する
  • 3つの機能に3つのエージェントを同時投入し、PRが完了したらレビューする
  • エージェントがフィードバックを監視し、自発的に修正提案までできる
  • 個々の貢献者ではなく、エージェントの艦隊を指揮する役割

レベルアップガイド

• 0 → 1: 協業を始める

  • ツールを1つ選び（Cursor with Opus 4.5 または Claude Code など）、毎日使う
  • コードを書く前に、既存コードの説明をAIに依頼して理解度を確認する
  • テスト、設定ファイル、反復関数など、ボイラープレートから委譲する
  • すべての行をレビューして学習する
  • 複利化タスク: うまく機能したプロンプトを継続的に記録する

• 1 → 2: エージェントへのアクセスを許可する

  • エージェントモードに切り替え、エージェントにファイルシステムへのアクセス権を与える
  • 「この関数にテストを追加」のような、単一ファイル・単一目的の狭い変更から始める
  • 各アクションを承認・拒否しながら信頼の直感を築く
  • diff をレビューして、変更された箇所に集中する
  • 複利化タスク: CLAUDE.md ファイルを作成し、エージェントがミスしたときにメモを追加する

• 2 → 3: 計画を信頼する（核心的な転換）

  • 要件、アプローチ、エッジケースを明示的な計画として作成する
  • AI がコードベースを読み、パターンを見つけてアプローチを提案できるようにする
  • 計画を作成した後はエージェントに実装を任せ、完了するまで席を外す
  • 個別のステップやコード行ではなく、PR レベルでレビューする
  • 複利化タスク: 各実装後に、計画で見落としていた点を文書化する

• 3 → 4: 指示ではなく結果を示す

  • 「新しいコメントにメール通知を追加」のように、結果（outcome）を提示し、実装方法はエージェントに任せる
  • エージェントはコードベースを理解し、リサーチも行うため、計画もエージェントの責任となる
  • 実装前にアプローチをレビューして、誤った方向を早期に遮断する
  • 複利化タスク: うまく機能した結果中心の指示ライブラリを構築する

• 4 → 5: すべてを並列化する

  • 実行をクラウドへ移し、ローカルマシンのボトルネックを解消する
  • 3つのエージェントに3つの機能を同時に割り当てる
  • アイデア、バグ、改善事項をキューとして構成し、エージェントが順番に処理するようにする
  • エージェントがユーザーフィードバックを監視し、機能を自発的に提案できるよう有効化する
  • 複利化タスク: 並列実行できる作業と、本質的に直列な作業を区別して文書化する

AI の成果物を承認する前の3つの質問

• 「ここで最も難しい判断は何だったか？」 — AI に難所や判断ポイントを明らかにさせる
• 「どんな代替案を退け、その理由は何か？」 — 検討した選択肢を確認し、誤った選択を見つける
• 「最も確信が持てない部分はどこか？」 — LLM に自分の弱点を認めさせる。ただし、直接尋ねたときにのみ答える

エージェントネイティブなアーキテクチャ

• エージェントに開発者と同等の能力を与えることが核心
• エージェントがテストを実行できなければ自分で実行する必要があり、ログを見られなければ自分でデバッグする必要があるため、許可しないすべての能力は手作業に変わる

• エージェントネイティブ・チェックリスト

  • 開発環境: ローカルアプリケーションの実行、テストスイートの実行、リンター・型チェッカーの実行、DB マイグレーション、開発データのシード
  • Git 作業: ブランチ作成、コミット、リモートへの push、PR 作成、PR コメントの読解
  • デバッグ: ローカル/本番ログの参照（読み取り専用）、UI スクリーンショット、ネットワークリクエストの検査、エラートラッキング（Sentry など）へのアクセス

• 段階的なエージェントネイティブ導入

  • Level 1（基本開発）: ファイルアクセス、テスト実行、Git コミット — 基本的な Compound Engineering が可能
  • Level 2（ローカル全体）: ブラウザ、ローカルログ、PR 作成へのアクセス — Stage 3〜4 が可能
  • Level 3（本番可視性）: 本番ログ（読み取り専用）、エラートラッキング、監視ダッシュボード — エージェントによる能動的デバッグが可能
  • Level 4（完全統合）: チケットシステム、デプロイ能力、外部サービス統合 — Stage 5 が可能

• エージェントネイティブなマインドセット

  • 機能を構築するとき: 「エージェントはこれとどのように相互作用するのか？」
  • デバッグするとき: 「エージェントは何を見られる必要があるのか？」
  • 文書化するとき: 「エージェントはこれを理解できるか？」

Skip Permissions

• Claude Code の --dangerously-skip-permissions フラグは、各アクションごとに求められる権限リクエストを無効化する
• 名前が意図的に物騒なのは、使用前によく考えるよう促すため

• 使うタイミング

  • 使用推奨: 良い計画とレビュー体制があるとき、サンドボックス環境で作業するとき、速度が必要なとき
  • 使用を控える: 学習中のとき（権限リクエストが理解の助けになる）、本番コードを扱うとき、ロールバック体制がないとき

• 権限省略時の安全メカニズム

  • Git が安全網: エージェントの作業は Git に記録されるため、git reset --hard HEAD~1 で復元できる
  • テストがミスを検出: マージ前にテストを実行する
  • マージ前レビュー: 実装中は権限を省略しても、最終レビューは必ず行う
  • Worktree でリスクを隔離: 危険な作業は隔離されたディレクトリで試す

• 生産性の計算

  • 権限を省略しない場合は約30秒ごとにプロンプトが発生し、そのたびに「y」を入力して集中が途切れる
  • 権限を省略すればフロー状態を維持でき、5〜10倍速い反復を達成できるため、ときどきロールバックするリスクを大きく上回る時間を節約できる

デザインワークフロー

• Baby App アプローチ

  • テスト・アーキテクチャ・破壊的変更の心配なく自由に反復できる**使い捨てプロジェクト（baby app）**を作成する
  • デザインに満足したら、色・間隔・タイポグラフィ・コンポーネントパターンを抽出し、本プロジェクトへ移植する

• UX 探索ループ

  • 複数バージョンを作成してクリック可能にし、ユーザーに機能するプロトタイプを共有してフィードバックを集める
  • Figma のモックアップと違い、実際にクリックできる
  • プロトタイプは学習のためのものであり、その後適切な計画でゼロから再構築する

• デザイナーとの協業: Compound フロー

  • 従来のフロー: デザイナーのモックアップ → 開発者の解釈 → 修正の反復
  • Compound フロー: デザイナーの Figma モックアップ → /plan に Figma リンクを渡す → AI が実装 → figma-design-sync エージェントが実装とモックアップの一致を確認 → デザイナーがスクリーンショットではなくライブ版をレビューする

• デザインの嗜好をコード化する

  • デザイナーといくつかの機能を一緒に作業しながら発見したパターン（好みの色、フォームレイアウトなど）をスキルファイルに記録する
  • AI はデザイナーなしでも、デザイナーの嗜好に合ったデザインを生み出せる

• デザインエージェント

  • design-iterator: 現在のデザインのスクリーンショットを分析し、改善を反復して段階的に洗練する
  • figma-design-sync: Figma からデザインを取り込み、実装と比較して差分を自動修正する
  • design-implementation-reviewer: 実装が Figma 仕様と一致しているかを検査し、視覚的バグをユーザーに届く前に発見する

バイブコーディング（Vibe Coding）

• コードそのものではなく結果だけを求める人向けのアプローチ: プロダクトマネージャー、デザイナー、個人プロジェクトなど
• ラダーを飛ばしてStage 4 に直行: 欲しいものを説明 → エージェントが計画・コード・テスト・レビュー・PR まで全部処理
• 適しているケース: 個人プロジェクト、プロトタイプ、実験、「これは可能か？」の調査、社内ツール、UX 探索
• 適していないケース: ユーザーがいる本番システム、他人が保守するコード、セキュリティに敏感なアプリ、性能クリティカルなシステム

• バイブコーディングのパラドックス

  • バイブコーディングはむしろ計画能力を向上させることがある
  • 何を作るべきかわからないときは、プロトタイプを作ってユーザーフィードバックを集め、その後すべて削除して適切な計画でやり直す
  • 最適な配分: バイブコーディングで発見し、仕様で構築する — 最終実装では常に仕様が勝つ

チームコラボレーション

• 新しいチームダイナミクス

  • 従来型: 人Aがコードを書く → 人Bがレビュー → PRコメントを議論 → 承認後にマージ
  • Compound: 人Aが計画を作成 → AIが実装 → AIエージェントがレビュー → 人BがAIレビューをレビュー → 人間が承認してからマージ

• チーム標準

  • 計画承認: 沈黙は承認ではないため、実装前に明示的なサインオフが必要
  • PRの所有権: コードを書いた主体に関係なく、作業を始めた人がPRの所有者であり、計画の品質・レビュー・修正・マージ後の影響に責任を負う
  • 人間レビューの焦点: AIレビューエージェントがすでに分析したPRでは、人間は構文エラー・セキュリティ・性能・スタイルではなく、意図(intent)を中心にレビューする — 「合意した内容と一致しているか？」「アプローチは妥当か？」「ビジネスロジック上の問題はあるか？」

• コミュニケーションパターン

  • 非同期が基本: 計画の作成・レビュー・承認に会議は不要、「計画ドキュメントを作ったので今日中にコメントをお願いします」
  • 明示的なハンドオフ: 状態、完了した内容、残っている作業、コンテキスト、継続方法を含める

• 拡張パターン

  • 明確な所有権 + 非同期アップデート: 主要機能ごとに1人の所有者が計画・監視・レビュー・マージ・チームへの更新を担当
  • Feature flag + 小さなPR: 全員が速くデプロイするほどマージ衝突は増えるため、小さな単位でデプロイし、メインへ頻繁にマージし、衝突は即座に解決する
  • Compoundドキュメント = 属人的知識(tribal knowledge): 「Sarahに聞いて、authに詳しいから」ではなく、Sarahが/compoundを実行してソリューションを文書化すれば、誰でも検索可能になる

ユーザーリサーチ

• リサーチと開発のギャップ

  • 従来型: リサーチャーがインタビュー → レポート作成 → Google Driveに放置 → 開発者がレポートを確認しない → 機能がユーザーニーズを反映しない
  • Compound: リサーチが構造化されたインサイトを生成 → インサイトが計画コンテキストとして活用される → AIが計画時にインサイトを参照 → 利用データがインサイトを検証 → インサイトが複利的に蓄積される

• リサーチの構造化

  • 生のインタビューノートをAIが活用できるよう、構造化Markdownに変換: 参加者情報、主要インサイト、引用、示唆、信頼度(n/5参加者)を含む

• ペルソナ文書

  • 目標、不満、引用を含むペルソナ文書を作成し、AIが参照できるようにする

• リサーチに基づく計画

  • /workflows:plan実行時にリサーチコンテキスト(インタビュー結果、ペルソナパターン、現在のペインポイント)を含め、リサーチインサイトが機能へ直接つながるようにする

データパターンの抽出

• ユーザーが製品を使う方法は、何を作るべきかを示す手がかりになる

• 注目すべきパターンの種類

  • 過剰利用パターン: 想定よりはるかに多く使われる機能、同じページへの繰り返し訪問
  • 困難パターン: 単純なページでの高い滞在時間、同じアクションの繰り返し試行、エラー→再試行→エラーのループ
  • 回避パターン: ある場所からデータをエクスポートして別の場所へ再インポートする、画面間でコピー＆ペーストする、比較のために複数タブを同時に開いておく
  • 離脱パターン: フローからの離脱、開始したが完了しなかった機能

• パターンから機能へ

  • ユーザーがテーブル間でデータを週50回コピー＆ペーストする → 「テーブルBに同期」ボタンとして機能化
  • ユーザーが「テンプレート」プロジェクトを作って複製する → ファーストクラスのテンプレート対応として機能化

コピーライティング

• 計画にコピーを含める

  • ほとんどのチームはコピーを機能構築後に埋める後回しのものとして扱うが、コピーはユーザー体験の一部
  • 計画段階からメール件名、成功メッセージ、エラーメッセージなどユーザー向けコピーを含めると、AI実装時にはコピーがすでに用意されている

• ボイスのコード化

  • 原則(人間のように話す、エラーメッセージは助けになるべき、短い文、明確な言葉)と避けるべき言葉(Invalid → didn't work、Error → 何が起きたのかを説明する、など)をスキルファイルとして作成

• コピーのレビュー

  • /workflows:reviewプロセスにコピーのレビューを追加: 明確さ、役立ち度、トーン、一貫性の4つの基準で確認するcopy-reviewerエージェント

プロダクトマーケティング

• Compoundフロー

  • エンジニアが製品の価値提案を含む計画を作成 → AIが機能を実装 → AIが計画からリリースノートを生成 → リリースノートからソーシャル投稿を生成 → Playwrightでスクリーンショットを自動キャプチャ → エンジニアがレビュー後、すべてをまとめてリリース
  • すべてが1か所で流れるためハンドオフが不要で、抜け漏れがない

• リリースノートの生成

  • AIは計画、コード変更、テストをすべて保持しているため、何が実装されたのかを正確に把握できる
  • ユーザーの利点を優先し、具体例を1つ含め、破壊的変更に言及し、200語以内

• 変更履歴の生成

  • /changelogコマンドで最近のメインへのマージを確認し、各計画/PRを読んで魅力的な変更履歴を生成

• 自動スクリーンショット

  • Playwrightを使ってマーケティング用スクリーンショットを自動キャプチャし、エンジニアリングにスクリーンショットを依頼する必要をなくし、古いスクリーンショットの問題を解消する