AI Native な組織 — リソース一覧

Prompting Claude Fable 5（Claude Platform Docs）

独自視点: Mythosクラスは「指示を足す」より「古い指示を削る」移行。従来モデル向けの細かすぎるスキルはむしろ出力の質を下げる

Opus 4.8 から Fable 5 への移行で調整が要る挙動を公式が網羅。デフォルトで実行時間が長期化（単一リクエストで数分、自律実行で数時間）するためタイムアウト・非同期化の見直しが前提。進捗報告の根拠付け（ツール実行結果と照合させる指示で捏造報告がほぼゼロに）、並列サブエージェント（ブロッキングではなく非同期通信＋長寿命サブエージェントでキャッシュ節約）、メモリ(1ファイル1教訓、過去セッションからの立ち上げ）、稀な早期停止・コンテキスト予算懸念への対処、send_to_user ツールの定義と呼びかけ方まで、すぐ流用できる指示文のサンプル付き。#26 の実験結果を運用指示に落とし込んだ実装リファレンスで、#28（Sonnet 5 版）と対になる。

Agentic Autonomy Levels（Addy Osmani）

独自視点: 自律性は Yegge 的な単一ラダーでは測れない。「Agency（個別エージェントをどこまで手放すか）」×「Orchestration（多数を調整するスキル）」の2軸で捉え直す

レベル0〜5（アシスト→監視下の実行→範囲限定のタスク委任→目標駆動型の自律性→並列委任→例外管理によるオーケストレーション）を定義し、各レベルの失敗パターン（承認疲れ・偽の並列化・オーケストレーション税）と対策を明示。エージェント実行前の「契約」8項目（目標・範囲・非目標・ツールと権限・停止条件・エビデンス・エスカレーション・予算）、自律性を信頼可能にするメトリクス10種、4つのアンチパターン（ステータスとしての自律性／権限のロンダリング／要約による代用／フリートのコスプレ）が実務チェックリストとして優秀。Anthropic の約40万セッション分析「計画判断の約70%は人間、実行の約80%はClaude」も引用。結論は「検証こそが常にボトルネック」— #25 の続編として読む。

Prompting Claude Sonnet 5（Claude Platform Docs）

独自視点: 組織論ではなく実装リファレンス。Sonnet 4.6 からの移行で「調整が要る挙動」だけを公式が網羅

effort 5段階の使い分け（Sonnet 5 の medium ≒ 4.6 の high）、適応思考のデフォルトオン化、temperature/top_p/top_k 指定は400エラー、新トークナイザーで同一テキストが約30%トークン増、低 effort でのリテラルな指示追従など、移行時の落とし穴を列挙。特にコードレビュー・ハーネスの節（再現率低下は能力退化ではなく「指示への忠実さ」由来。発見ステージは網羅に徹し、フィルタリングは後段に分離せよ）と、フロントエンドの「AI スロップ」回避スニペットは実務でそのまま使える。ループ設計の実装フェーズで手元に置くリファレンスとして。

Getting started with loops（Claude Code 公式ブログ）

独自視点: ループの公式定義「停止条件が満たされるまでエージェントが作業サイクルを繰り返すこと」。バラバラだった議論を4類型で決着

Claude Code チーム自身による「エージェンティック・ループ」の分類学。トリガー／停止条件／使用プリミティブ／適所の4観点で整理：(1) ターンベース（プロンプト起点。検証手順を SKILL.md 化してターン数を削減）、(2) ゴールベース（/goal。決定論的な成功基準＋最大試行回数。エバリュエーターモデルが完了判定）、(3) タイムベース（/loop・/schedule。定型業務と外部システム連携）、(4) プロアクティブ（schedule＋goal＋ダイナミック・ワークフロー＋オートモードの合成）。後半のコード品質維持（レビューは新鮮なコンテキストの別エージェントに）とトークン管理術（明確な停止条件・小規模試験運用・/usage）も実務直結。#25 Loop Engineering の概念を公式が体系化した決定版で、あなたの /loop・/goal 運用の教科書。

Designing loops with Fable 5（Lance Martin / Anthropic）

独自視点: プロンプトの工夫より「環境の設計」。自己批判より独立コンテキストの検証用サブエージェントの方が性能が出る、を実験で示す

Anthropic の Lance Martin が Fable 5 活用の2大ヒントを実験付きで解説。(1) 自己修正ループ — Parameter Golf（8×H100・10分・16MB制約のMLチャレンジ）を Claude Managed Agents + Outcomes（ルーブリック採点サブエージェント）で最大8時間実行し、Fable 5 は Opus 4.7 の約6倍パイプラインを改善。量子化による一時的な精度低下を乗り越えて構造的変更に賭けるレジリエンスを示した。(2) メモリ — Continual Learning Bench で「失敗→調査→検証→抽出→参照」の5段階を完遂できるかがモデル差になる（Sonnet 4.6 はステップ1、Opus 4.7 はステップ3で脱落、Fable 5 は検証網羅率73%）。#27 のループ4類型を「なぜ効くのか」の側から裏付ける一次実験データ。

Loop Engineering（Addy Osmani）

独自視点: プロンプトを出す側を卒業し、プロンプトを出し続ける「システム」を設計する側へ。ハーネスの一段上の抽象

@steipete「もうエージェントにプロンプトを出すな、ループを設計しろ」と Claude Code 責任者 @bcherny「私の仕事はループを書くこと」を起点に、ループの6要素を体系化：(1) オートメーション（スケジュール起動・トリアージ受信箱・/loop・/goal）、(2) ワークツリー（並行エージェントの競合防止）、(3) スキル（SKILL.md による知識の蓄積）、(4) プラグインとコネクタ（MCP で Slack/GitHub 連携）、(5) サブエージェント（作る役とチェックする役の分離）、そしてメモリ（コンテキストではなくディスク上に置く記憶）。Codex と Claude Code が両方とも全要素を製品に組み込んだ今、ツール選択の議論は重要でなくなったと指摘。同時に「検証の責任」「理解の減衰」「認知的降伏」という3つの罠も明示し、「ループを築き、エンジニアであり続けろ」と締める。あなたの Symphony/Linear パイプライン構想の理論的な土台。

The Playbook for Building an AI Native Company (Diana Hu / YC)

独自視点: AIは「会社が使うツール」ではなく「会社が動く OS」。クローズドループ化と Software Factory で人間 middleware を除去する

YC partner Diana Hu による AI Native 会社建設の処方箋。AIを生産性向上ツールではなく「会社が動く OS」として捉え、6つの処方箋を提示： (1) Closed Loop化 — 旧来のオープンループ運用（決定→実行→計測なし）をクローズドループ（artifact→学習→自己改善）に変換。ミーティングはAI議事録、DM/email最小化、Linear/Slack/Notion/GitHub/Gong全部にエージェント埋め込み、カスタムダッシュボードで全社可視化。 (2) Engineering Sprint Planning agent — Linearチケット、Slack、Pylon、Notion、stand-up録音すべてに access するエージェントが「実際にshipされたもの」と「顧客ニーズ」のギャップを定量化、次sprintを予測。YC内事例で sprint時間が半減、達成量は最大10x。 (3) AI Software Factory — StrongDM AI Team の事例。リポジトリには手書きコードがなく spec + scenario test だけ、agent が probabilistic satisfaction threshold まで反復実装。Steve Yegge の「1000xエンジニア」が現実化。 (4) Org Chart の解体 — Jack Dorsey/Block の主張を引用し、middle manager が情報を上下に routing する必要がなくなる。3アーキタイプ（IC=builder-operator / DRI=直接責任者 / AI Founder=先頭に立つ創業者）。 (5) Token Maxing — headcount ではなく API 使用量を最大化。「居心地悪いほど高い API 請求書を受け入れろ」。 (6) スタートアップ優位 — レガシーシステム/組織図/再教育人員がない分、大企業より圧倒的に有利。Mutiny 等の skunkworks 事例も言及。
※元は YC Library の動画コンテンツだが、ユーザー提供のトランスクリプト全文を元に要約

Anthropic Cybersecurity Skills (Mahipal)

本文は HTTP 403 で取得不可（Cloudflare等のbot遮断）。タイトルとAnthropic Skills の一般的性質から、Skill＝再利用可能なドメイン専門指示パッケージをサイバーセキュリティ業務で運用する個人エンジニアの実装解説と推測される。「組織」観点での射程は限定的で、Skill運用を組織導入したい場合のサンプルとして読む価値あり。

バクラクの「営業企画」という仕事の面白さと本質

LayerXバクラク事業の営業企画チーム紹介。AI Native組織論ではなく営業企画職の解説記事。Sales PortalでSalesforce入力をAI自動化、商談資料の初回提案を自動生成、AIクイズによるプロダクト理解度可視化など現場AI実装の事例として参考にはなる（Sales/BizOps領域でAI実装する人向け）。LayerXのAI Native系の主力記事は #7 の mjunya 氏記事が該当。

Ledge.ai: OpenAI Codex Orchestration Symphony 解説

#2 の二次情報。一次の OpenAI 公式記事を読めば不要。ただし日本語で短く全体像を掴みたいときの早見表として有用。「Symphonyがすべての作業に適しているわけではない」「チケット単位だと途中の軌道修正が難しい」というOpenAI自身の留保が引用されている点だけ抑えればよい。

How finance teams use Codex

Finance部門向けCodex 10ユースケース。「重要な数字には必ずワークブックのタブやダッシュボードを引用させる」という財務領域固有のガードレールが特徴。CFO組織/FP&A/コーポレートFinanceの実務指南だが、組織再設計の知見というよりCodex活用テンプレ集。

How business operations teams use Codex

BizOps向けのCodexユースケース集（5パターン）。「散在する初期コンテキストを統合して決定可能なブリーフの第一版を作る」役割定義。組織論ではなく個別職能のプロンプトテンプレ集。BizOps/戦略企画/CoSが具体的な実装案を欲しいときの参照用。

The Founder's Playbook（Anthropic）

位置付け: 創業者向けの俯瞰土台。#4 OpenAI Codex Guide（既存組織再設計向け）と補完関係

2026年版スタートアップ構築ガイド。Idea / MVP / Launch / Scale の4フェーズで、問題仮説検証・顧客発見・MVPアーキテクチャ・PMF測定・スケーリングの各局面でAIをどう組み込むかを実践的に提示。中盤以降はAI生成コードの技術負債リスクとセキュリティ管理、Launch段階でのエージェント運用を強調。日本語版を playbook.html として用意してあるので、Day 2 で #4 とセットで読むのが効率的。

about_hiroppy: skill層でagent非依存化する組織AI化

独自視点: agentロックインを避けるため skill層を組織の永続資産として切り出すアーキテクチャ判断

GWを丸ごと組織のAI化研究に充て、結論として「ナレッジや手順は全部Hermes流のskillとして管理し、別のagentに乗り換えてもそのまま移行できる状態にしておく」という方針に達したという報告。AgentOps的な発想を個人〜組織レベルで実践した実例。#10 と合わせて hiroppy 構成の全体像が見える。

AINews: Everything is Conductor

独自視点: 「カニ化（carcinization）」――開発ツールが収束進化的にエージェント中心UIに揃いつつある

GitHub App、VS Code、Claude CodeなどがConductor先行のエージェント中心UIに収束する現象を指摘。形式を開拓した先行者が大手の模倣で差別化を失う「先行者の収益化ジレンマ」と、Claude Code制限騒動を踏まえた「サブスクリプション型エージェント基盤は不安定な土台」というプラットフォーム依存リスクを提示。AI Native組織への含意は、単一エコシステムへのロックイン回避とBYOK対応の戦略必須化。

Agentic Coding is a Trap

独自視点: Anthropic自身の研究を引用した「監督のパラドックス」、コーディング自体が思考・計画行為だと結論

Spec Driven Development とエージェント任せの開発スタイルは、開発者の批判的思考と認知能力を萎縮させる「罠」と主張。過去の抽象化（FORTRAN・コンパイラ・クラウド）と違い、AI採用はわずか数年で熟練者にも「メンタルモデル喪失」「ブレインフォグ」を引き起こす実証データが出ている点が新しい。#1 Anthropic研究と合わせ技で読むと深まる。

米国AI駆動GTMの最前線 ー SaaStr AI 2026 現地レポート（_mayumayu13/工藤真由）

独自視点: Vercel SDR 10→1（年$5K運用、32x コスト効率）、Anthropic は新規エンタープライズロゴの54%をself-serveで獲得

Globis Capital Partners 工藤真由氏による SaaStr AI 2026 現地レポート（X Article、17万view）。Jason Lemkin の「最高のエージェントが今後12ヶ月で勝者を決める」を起点に、(1) Vercel GTM Engineering の Tripod Model（GTMエンジニア×データサイエンティスト×ベストパフォーマー）で SDR 10→1、サポートケース 93%自動化、リード資格判定エージェントが年$5K で 10人分を代替、(2) Anthropic Eleanor Dorfman セッション：既存スタック（Clay/LeanData/Salesforce/Gong/Ironclad/Slack）を捨てず Claude を間に縫う、Sales Plugin（Morning Brief / Call Prep / Customer Follow-up / Competitive Intel）を Skills化、エンタープライズ self-serve で新規ロゴの54%獲得、(3) Slackを全サポート機能のフロントドアに、(4) セマンティックレイヤー必須。i_flatfield記事 #13 と同イベントだが、こちらは数値とSkill構成が圧倒的に具体的。両方読むと立体感が出る。

AI Native企業の本当の差は、プロダクトではない（i_flatfield/平野いさむ）

独自視点: AI Nativeはプロダクト論から「会社設計論」へ。日本市場では業務翻訳できる FDE 的人材の価値が上がる

AWS Japan Startupチーム 平野いさむ氏による SaaStr AI Annual 2026 現地レポート（X Article、10章構成、2.6万view）。「AI Native企業とは AI機能を持つ会社ではなく、AIを前提に会社全体を再設計している会社」と定義。Anthropic "No Legacy, No Playbook" セッション（territory/qualification/handoff の再設計）、Vercel "10 to 1 SDRs"、Replit Vibe Coding（Buyer to Builder）、Databricks Data Layer = AI moat、Stripe AI startup margin、Google Cloud "Pilot Purgatory Is Over"、CoreWeave Agent-first GTM、20VC × SaaStr の AI=capital allocation cycle まで網羅。日本市場向け5つの示唆で締めるVC視点の総括は他に類を見ない解像度。

How to Build an AI-Native Startup from Day One

独自視点: 機械可読性（machine-legible）を組織設計の第一原則に

5原則: ①知識をmarkdown等の機械可読形式で保存 ②ベンダーロックイン回避と移植性 ③管理層より先に専門家ループを構築 ④「引き継ぎ」ではなく「結果」中心に組織化 ⑤評価・権限・レビューを初期から組み込む。「廊下の雑談」は社会技術として優れるが長期記憶には不適、と指摘。レガシーを持たないスタートアップ向け greenfield 設計の自由度を活かす指針。

How to set up an AI-native organization (aweb.ai)

独自視点: エージェントに「名前と住所（永続コンテキスト）」を与え、人間ハブを介さず直接ハンドオフ。7エージェント+2人間の具体モデル

AI支援ではなくAI-Native組織を実現するには、エージェントに「名前付き責任」と永続的文脈、堅牢なハンドオフを与え、人間は方向性のみ示す構造が必要。AGENTS.mdを本人が更新、重要決定には常にペアレビュー（builder+reviewer）を置く。公開テンプレ（github.com/awebai/agent-first-company-template）も提供。「エージェントを社員として扱う」運用論。

about_hiroppy: Slack→Hermes→Superpowers→Linear→Symphony→Codex→GitHub

独自視点: subscription依存削減と「人によるプロンプトばらつき排除」を両立させる二重チェック型パイプライン

5/5の構成案ツイート（極力 subscription に依存しない形：slack(I/F) → hermes(agent) → superpowers(brainstorming skill) → linear(ticket) → symphony(runner) → codex(coding) → github(pr)）を、5/6に「こんなかんじでチケット作らせて、あとは自分が TODO にしてって Slack で言ったら Symphony が勝手に拾ってくれて PR が作られる感じ」とスクショ付きで自己引用。Symphony単独だと一方向調査になる弱点を Superpowers でダブルチェックする設計思想。組織導入時に問題となる「プロンプトのばらつき」をタスク生成段階で吸収して個人スキル差を均す。#2 Symphony 公式と合わせて読むと一段腹落ちする。

数百人のエンジニア組織から、20人のAI Native組織へ

独自視点: 大企業の合理性（四半期予算・厚い意思決定層）こそが変化阻害要因、「やりましょうの翌日にMVPが動く」スピード基準

数百人組織からSTRACT（20人）に移った宇佐美ゆう氏の経験談。コードだけでなく要件定義・QA・経理・営業まで全領域をAI前提で再構築、バックオフィスは「AIが実行・人間が承認」モデル。MAU100万人超、年間GMV100億円、収益年300%超成長を達成。アイデアから1日以内でMVPが動く体制を実現。小規模AI Native化のリアル。

エンジニアリングの常識を「AI-Native」に再定義。メルカリが実現した"再現性"のある開発組織

独自視点: AI導入の数値的成功を「ゴールではなくスタート地点」と再定義、主眼は「再現性」

メルカリCTO木村俊也氏インタビュー。AI Task Force（33領域100名規模）を2025年7月立ち上げ、約4000のワークフローを再定義。中核はAgent-Spec Driven Development（ASDD）で、API定義・データモデル・処理フロー・テスト・コードスタイルまで全手順を明示し個人スキル依存を排除。社員95%がAIツール活用、コード生成70%がAI、開発スピード前年比64%向上。大企業スケールのAI Native化事例。

AI Nativeな組織OSをどう作るか ーHR Enabling部を立ち上げましたー

独自視点: HRを Identity / Activity / Intelligence の3層で再定義、マネージャーのスパン上限（7〜10名）をAIで突破

LayerXが新設した「HR Enabling部」の設計思想。Identity Layer（従業員属性）・Activity Layer（GitHub/Salesforce等の事業ログ）・Intelligence Layer（AI解析）の3層で、マネージャーは事実集約をAIに任せて意味づけに集中。入社XX日後をトリガーに目標設定を自動化、評価サマリを事実ベースで自動生成。日本企業視点の体系設計として最重要。

When Everyone Has AI and the Company Still Learns Nothing

独自視点: トークン消費量ではなく「ループ学習量」を測れ

個人AI活用が進んでも組織が学ばない原因は、既存業務設計が「イテレーション高コスト時代」のままだから。3つの組織機能（Agent Operations / Loop Intelligence / Agent Capability）を提唱し、学習信号を抽出する「Loop Intelligence Hub」を提案。同時に、従業員監視に転化しない倫理設計の重要性も指摘。あなたが言う「ループインテリジェンス」の出典。

You Need AI That Reduces Your Maintenance Costs

独自視点: 「速度向上率 × 保守コスト削減率 = 1」を満たさないと長期で逆効果。AIを剥がしても保守コストは戻らない（ロックイン）

AIコーディングエージェントは短期生産性を引き上げるが、保守コストが同時に増えると数か月で利益が消える、と数式的に論じる長文エッセイ。「生産性が2倍になるなら保守コストは半減させなければ釣り合わない」という具体閾値を提示し、自社の数値で検証できるスプレッドシートも提供。AI導入の意思決定基準として最も強力。

Build an AI-native engineering team

独自視点: エージェント=「第一次実装者」、エンジニア=「レビュアー兼編集者」へ役割反転

Plan/Design/Build/Test/Review/Document/Deployの7フェーズで責務を表形式化。AGENTS.md整備、MCP連携、PR反応数など低摩擦な品質メトリクス、権限スコープ管理など実務チェックリスト。Anthropic Founders Playbookが創業者向けなら、こちらは既存エンジニア組織の再設計向けで補完関係。

シリコンバレーAIスタートアップの「組織マネジメント革命」

独自視点: プロダクトにAIを実装するより先に、組織にAIを実装する方が本質

令和トラベルCEO 篠塚孝哉氏が、Cursor 300人で$1B ARR、Midjourney 107人で$500M売上、Cognition 10人スタートで$10.2B評価、Lovable 90日で$17M ARR などを引用し、AI-native企業のRevenue per Employee $3.48M（従来SaaSの17倍超）を提示。実装策は ①CLAUDE.md を Git 共有 ②Agent Skills でタスク別ロード ③Anthropicの16体Claude Codeエージェントで$20K・10万行のCコンパイラ開発事例 ④AgentOps チーム設置（成熟企業40%超）⑤Shopifyの「AIで代替できないことの証明」を採用時に要求。定量データ＋実装＋評価制度変革まで一気通貫。
同内容を X Article版（10.8万view）でも公開。引用元20以上を明記

An open-source spec for Codex orchestration: Symphony

独自視点: 「Linear（課題管理）を agent の control plane にする」= 人間の注意こそが新ボトルネック

OpenAI社内チームが「Codexが書く」リポジトリ運用後、人間の同時管理限界（3〜5セッション）に直面 → Symphony を開発。Linearの各 issue に専用エージェントを自動割当、ステータスを状態機械化、エージェントが依存DAG・新タスク・CI追従まで自己生成。一部チームで着地PR数が5倍。あなたが組んでいる Slack→Hermes→Linear→Symphony→Codex パイプラインの理論的支柱。

How AI is transforming work at Anthropic

独自視点: 「監督のパラドックス」――AIをよく監督するにはドメイン知識が必要だが、AI使用がその知識を奪う

Anthropic自身の社内132名調査の一次データ。Claude使用率 28%→59%（12ヶ月）、自己報告生産性 +20%→+50%、業務の27%は「AIなしでは存在しなかった新規タスク」。同時にスキル劣化・キャリア不安への対策（AIなしで解く練習、メンターシップ制度化、検証能力の専門化）も提示。AI Native組織を実装済みの会社の内省データという稀有性が決定的。