EP1: Every | Agent-Native Architecture

15人で年商数百万ドル。コードを書かないエンジニア。メディアのふりをしたベンチャービルダー。
Every.toは「AIネイティブ企業」の最前線で何をやっているのか、裸で分析する。

構成（30-45分想定）

OPENING（2-3分）

AI Naked初回の挨拶・番組説明

• AI Nakedとは何か：一発撮り、ノーカット、使ったことだけ語る
• なぜEP1がEveryなのか
  • AIを「語る」だけでなく「経営に組み込んでいる」最先端の実例
  • メディア×ソフトウェア×コンサルの三位一体モデル
  • （FlowStudioにとっての）ベンチマーク

PART 1: Everyとは何者か（8-10分）

1-1. Dan Shipperという人間

• ペンシルベニア大学・哲学科出身
• 在学中にFirefly（画面共有ツール）を創業。2人で6,000顧客、11ヶ月で6桁ドル収益
• 23歳で大学卒業とPegasystemsへの売却を同月に達成
• 「書くこと自体が思考」という信念 ← 哲学科＋文筆家Annie Dillardの影響
• ロールモデル: Sam Harris、Bill Simmons、Kevin Espiritu（書き手×起業家の先人たち）

1-2. Every創業ストーリー

話すポイント: ブレークイーブン運営のおかげで2023年の危機を乗り越えた。固定費が低いから死なない。

PART 2: ビジネスモデル — メディアのふりをした三角形（8-10分）

2-1. 収益の3本柱

         ニュースレター（MRR）
              /        \
             /          \
    AIプロダクト群 ——— コンサルティング

1. ニュースレター + サブスク（MRR $60k = ARR $720k相当、有料約4,000人）
2. AIプロダクト群（Spiral / Monologue / Sparkle / Cora）
3. コンサルティング（年$100-200万）

同一オーディエンスを3方向にマネタイズしている。

2-2. プロダクト群の概要

• 4つをサブスクバンドルとして提供 = 「AIと仕事するためのインフラ一式」
• 「自分たちが最初のユーザー」戦略（Dogfooding）
• 各プロダクトは基本的に1人で運営

2-3. Writerの集め方 — 雇用ではなくパートナー

• バッチ採用（募集→初回ドラフト提出→選抜）
• 利益の50%を永続的に配分
• 自分のメーリングリストを持ち出し可（ロックインしない）
• 前払いあり
• Li Jinも寄稿者として参加

話すポイント: 「雇用」じゃなく「条件で勝つ」。ソロプレナーが人を集めるときの設計思想として学びが大きい。

PART 3: Agent-Native Architecture（8-10分）★メイントピック

3-1. 概念: コードの終焉

従来のソフトウェア:

• 人間がコード（手順の集合）を書く
• 機能追加 = コード追加
• 変更 = 既存コードの修正

Agent-Nativeなソフトウェア:

• AIエージェントがアプリの中核
• 機能 = 「ゴールを記述したプロンプト」
• エージェントが手段（How）を自律的に決定
• 変更 = プロンプトとツールの更新（コード不要）

Shipperの比喩:「ビルの建設ではなく、庭を育てるようなもの」
設計図通りに建てる高層ビル vs 種を植え、剪定しながら育てる庭

3-2. 5つの設計原則（Dan Shipperの記事 + FleetingNote整理より）

究極のテスト: ドメイン内だが特定の機能として作っていない結果を記述する。エージェントがループで動作してそれを達成できるか？
Yes → Agent-Nativeなものを作った。No → アーキテクチャが制約されすぎている。

3-3. Coraでの実践例（ライブストリームより）

• Coraの基本機能: メールを要約し、即時対応不要なものをブリーフとして1日2回配信。重要なものだけがInboxに残る
• ユーザー:「受信箱を片付けて」と自然言語で指示
• 内部のAIエージェントがメール解析→要約→分類→返信ドラフト生成を自律判断
• 開発チームの機能追加 = コードではなくプロンプト設計

3-4. Agent-Native化の実践: CLIを作る（Kieranライブストリーム 2026-01-08）

KieranがCoraをAgent-Native化するライブコーディングで示した具体手順:

1. Parityの第一歩 = CLIを作る

   • 「ユーザーがUIでできること全てを、エージェントもできるようにする」の最短経路
   • CLIならエージェントはそのまま使える（MCP不要、トークンのオーバーヘッドなし）
   • GitHubもこの戦略（gh CLI）

2. Terminal Wire（Railsライブラリ）の採用

   • CLIの定義とアクションをRailsアプリ内で記述 → WebSocket経由でストリーム
   • サーバーを更新すればCLI側も即座に反映（CLIのアップデート不要）
   • Brad Martinが単独開発したOSS

3. primeコマンドの設計

   • kora prime = エージェント向けの詳細説明コマンド
   • エージェントが最初にこれを実行すれば、CLIの全コマンドと使い方を把握できる
   • 「helpのエージェント版」

4. 創発的機能の実例

   • CLIでTo-Do機能を公開したら、想定外の使い方が生まれる可能性
   • 例: To-Doの上にリーディングリスト体験を構築するユーザー
   • 例: WhatsAppのメッセージをCoraに流し込むユーザー
   • 「ビルディングブロックを渡してユーザーを信頼する」

5. 1.5時間でMVP完成

   • 認証 + To-Do CRUD + テスト + PR作成まで1セッションで完了
   • Agent-Nativeなソフトは、エージェント自身がCLIをテストできるため開発も速い

3-5. なぜこれが重要か

• 可塑性（malleability）が極めて高い
• ユーザーすらインターフェース上の指示を変えるだけで挙動を変えられる
• 要件変更への即応性が桁違い
• CLIという「古い」インターフェースが、エージェント時代に再評価される

話すポイント: 「コードを書く」という行為自体が過渡期の産物になりうる。CLIをAgent-Nativeの入口にするのは今すぐ真似できるプラクティス。

PART 4: Compound Engineering（5-8分）

4-1. 概念: AIが学習し続ける開発ループ

Plan（計画）→ Work（実装）→ Review（評価）→ Compound（蓄積）
                                                    ↓
                                    知見を記録 → 次のPlanで参照
                                                    ↓
                                         複利的に開発効率が向上

1. Plan: エージェントがリサーチ・仕様確認・方針立案
2. Work: エージェントがコード実装（人間はオーケストレーター）
3. Review: エージェントが自己レビュー・改善提案
4. Compound: 知見を構造化してドキュメントに自動追記 ← ★これが肝

「今日直したバグの教訓が、明日の開発では最初から活かされる」

4-2. Everyでの実践（Kieran Klaassen）

• シニアエンジニアKieranがClaude Codeで確立
• 社内で「compound-engineering plugin」を独自開発（OSSとして公開中）
• 具体的な開発フロー:
  1. Kieranが音声（Monologue使用）で機能の概要をClaudeに伝達
  2. Claudeがウェブ検索・コードベース解析でリサーチ→GitHub Issueに実装プランを自動生成
  3. 複数エージェントを並行稼働（フロントエンド / バックエンド / テスト / ドキュメント）
  4. 人間は「指揮者」として設計判断を下すのみ
  5. Claudeが自己レビュー→知見をドキュメントに追記
• 結果: 2人のエンジニアで通常15人分の機能開発を数時間で完了

Shipper:「もはやエンジニアはコードを書かず、AIエージェントのチームを指揮している」

4-3. ライブストリームで見えた実際の作業風景（2026-01-08）

Kieranの開発セッションから見えたCompound Engineeringのリアル:

• Plan: workflows planコマンドで3つのリサーチエージェントが並行稼働

  • 各エージェントが4-7万トークンを消費するが、メインのコンテキストには要約だけが返る
  • 計画完了後にSpec Flow Analyzer（俯瞰チェック用エージェント）が自動実行
  • 計画をTyporaで開いて人間がレビュー → 修正指示 → 再生成

• Work: workflows workコマンドで計画をPR化

  • 計画を渡すとブランチ作成→実装→テスト→PR作成まで自動
  • 計画の入力はGitHub Issue、Linear ticket、自作のplan.mdなんでもOK
  • 実装中にKieranは次の計画を並行して進める（マルチスレッド開発）

• Review: 6つの専門レビューエージェントが並列でコードを検証

  • Code Simplicity Reviewer / DHH Rails Reviewer / Pattern Recognition / Agent-Native Reviewer / Performance / Security
  • 発見事項をTo-Doとしてファイルに保存 → triageコマンドで人間が判断
  • 「テックリードがエンジニアとレビュアーの間に入って判断する」体験

• Compound: workflows compoundコマンドで学習を蓄積

  • 例: 「Terminal Wireで常にcurrent_accountでスコープすべき」→ CLAUDE.mdに記録
  • 次回のReviewでこの知見が自動適用される
  • スキル・エージェント定義・ドキュメントを自動更新

Kieranの作業哲学:

• 25分ポモドーロで2時間ブロック
• AIが動いている間は「水を飲む、ストレッチ、X確認、ピアノ練習」
• 「あなたが関与する回数が最小限になるのが理想」
• コンパクション（コンテキスト圧縮）は気にしない。サブエージェントを増やしてコンテキストを短く保つ方が賢い

話すポイント: 「複利」という言葉がそのまま当てはまる。使えば使うほど賢くなる開発環境を自分たちで構築している。ライブストリームで実際にやってるのが説得力。

PART 5: コンサルティング事業 — 思想の外販（3-5分）

Agent-NativeとCompound Engineeringを他社にも展開

提供内容:

• 部門別AIトレーニング
• カスタムプラグイン開発（独自データ接続）
• Claude Codeを使ったE2E自動化の教育
• ワークフロー全体を走らせるエージェントの配備

実績:

話すポイント: 自分たちで実践した手法をそのままコンサルとして売っている。Skin in the Gameの典型。

PART 6: 我々の学び・クロージング（5分）

6-1. Everyから盗めること

• 三角形モデル: コンテンツ→プロダクト→コンサルの段階的展開
• ブレークイーブン経営: 固定費を下げて生き残り力を確保
• 条件設計でタレントを集める: 雇用ではなくパートナーシップ
• Compound思想: 使えば使うほど組織が賢くなる仕組み

6-2. 日本でEveryモデルは成立するか

• （フリートーク）

6-3. 次回予告

Appendix: ファクトチェック用データ

検証済み数値

未検証（収録時に言及する場合は注意）

• 創業初期（2020年頃）の正確なARR
• 従業員あたり利益のYoY推移（利益ベースの内訳は非公開）
• コンサルクライアントの完全リスト

References

Primary

• Every.to 公式
• AI & I Podcast
• Lenny's Podcast - Dan Shipper回
• Spotify - Dan Shipper on Lenny's

Every記事・動画

• Agent-native Architectures: How to Build Apps After Code Ends - Dan Shipper & Claude共著
• Every LIVE: Building Agent-Native Software in Real Time - Kieranライブコーディング（2026-01-08）★台本の実践例の主要ソース
• Compound Engineering（2025-12-11）
• Introducing Every Consulting
• The Next Chapter of Every Consulting（2026-02-03）

外部

• Mixergy - Dan Shipper インタビュー
• Business Insider - Firefly買収報道
• Indie Hackers - Every収益モデル解説