業務のAI化からAI中心の組織設計へ — 2,000年続いた組織図の常識が書き換わる

はじめに: AIの位置づけが、いま静かに変わっている

最近、いろんな経営者やPM、事業責任者と話していて、ほぼ全員が同じ違和感を抱えています。

「AIめちゃくちゃ使ってるのに、組織のスループットが思ったほど上がってない」

自分も同じ感覚で、ずっと違和感だったんです。個人の作業速度は確実に上がる。なのに、組織として出てくる成果はそんなに変わらない。

ただ、ここ1年、Anthropic / OpenAI  の発信を追っていると、その違和感の正体と、次に来る景色がはっきり見えてきました。

• Anthropic は2025年9月に Agent SDK をリリース。2026年2月には Agent Teams（複数のClaudeが「チーム」として協調動作する仕組み）を正式投入した。Dynamic Workflowも直近リリース。

• OpenAI は2026年2月、Codex デスクトップ版で multiple agents in parallel（複数エージェント並列実行）を打ち出し、VentureBeat は「コードを書くことから、自律タスクをマネジメントすることへ」と見出しを打った

• Anthropic の Claude Skills は、「個別タスクをAIに渡す」から「仕事の型をAIに渡す」というパラダイム転換を持ち込んだ

• 2026年3月、Claude Code Review （Skill）すらマルチエージェント構成になった。コードレビューという1つのタスクですら、複数の専門エージェントが分担する時代に

並べると見えてくるのが、「AIに何を渡すか」「AI同士・外部ツールをどう繋ぐか」の基盤側がほぼ出揃ったということです。Anthropic の Skills で「仕事の型」をAIに注入できるようになり、MCP（Model Context Protocol） で外部ツール・データソースとの接続規格が標準化された。さらに Agent SDK / Agent Teams / Codex parallel で複数エージェントの協調が可能になった。

技術スタックとしての配管は引かれています。

ということは、残された論点は1つ。「組織の側がこれをどう使うか」だけです。2026年に本丸として残ったのは、組織の議論だと自分は見ています。

これは決して小さい話ではない。AIの位置づけが「個人のツール」から「組織の構成員・調整層」へ昇格できる準備が整ったということは、組織図そのものを引き直せる前提が揃ったということです。

ところが、使う側の実態は、まだ「個人のツール」として配って終わっている。組織の構造には一切手を入れていない。だから個人の生産性は上がるのに、組織のスループットは変わらない。

このギャップの正体が、自分は最近ようやく腹落ちしました。

「個人業務のAI化」と「AI中心の組織設計」は、別物だということです。

ほとんどの企業がやっているのは前者。本当に成果を出している企業がやっているのは後者。同じ"AI活用"という言葉で語られていますが、構造が根本的に違う。

この記事では、何が違うのか・なぜそれが2,000年ぶりの変化なのか・規模別に何をすべきかを、自分なりに整理します。

第1部: 「業務のAI化」が壁に当たっている

業務のAI化とは何か

2024〜2025年に主流だったのは、既存業務にAIを足すというアプローチです。

• 営業担当者にAIライティングツールを配る

• カスタマーサポートに要約Botを入れる

• エンジニアにCopilotを入れる

• マーケに画像生成ツールを入れる

各人にコパイロット（副操縦士）を渡す発想。人間が主体で、AIは補助。

これが悪いわけじゃない。むしろ最初の一歩としては正しい。個人の生産性は確実に上がる。

問題はその次に起きる。

個人の生産性は上がるが、組織のスループットは変わらない

各人の作業速度は確かに上がる。問題は、それが組織全体のアウトプットに繋がっているかです。

実際に起きているのはこんなことです。

• マーケが速く資料を作る → でも承認に1週間かかる

• エンジニアが速くコードを書く → でもレビューが詰まる

• カスタマーサポートが速く返信する → でも複雑な問い合わせは結局人間にエスカレーション

• リサーチャーが速くレポートを出す → でも経営会議は週1回

つまり、ボトルネックが「作業」から「判断・調整・承認」に移動しているだけで、消えてはいない。

そしてこの「判断・調整・承認」の大半は、人間（特に中間管理職）の手に集中したまま。AIで作業が速くなればなるほど、判断レイヤーに上がってくる量が増えて、結局は人間の処理速度がボトルネックに戻る。

これが冒頭で言った「個人の生産性は上がるのに、組織のスループットは変わらない」ギャップの正体です。コパイロット配布だけでは、組織のスループットは構造的に上がらない。

冒頭で書いたとおり、Anthropic も OpenAI も、「組織の構成員としてのAI」を出してきた。一方、企業側は「個人のツール」として配って終わっている。この技術と組織のミスマッチが、いまの数字を作っている。

「業務のAI化で止まる側」と「組織のAI化に踏み込む側」。この分岐点が2026年だと、自分は見ています。実際、この記事で取り上げる Block / Base44 / Pieter Levels は、すでに「組織のAI化」の実装フェーズに入っている先駆者たちです。

第2部: AI中心の組織設計 — 2,000年の前提が壊れる

そもそも「組織図」は2,000年前のローマ軍の発明だった

以下の歴史パートは、Block の論文 From Hierarchy to Intelligence の整理を下敷きにしています。

最初の企業組織図ができる2,000年前、ローマ軍は同じ問題を解いていました。「広い範囲に散らばる何千人を、限られた通信手段でどう協調させるか」。彼らの答えが、入れ子型のヒエラルキーです。

人間が直接管理できるのは3〜8人が限界だから。これを span of control（統制範囲） と呼びます。

自分自身、過去にチームを持っていたときの経験でも、直接マネジメントできるのは8人くらいが限界でした。それを超えると、必ずレイヤーを増やすか、誰かに権限委譲するしかなくなる。これは個人の能力の問題というより、人間の認知の構造的な制約だと思っています。

この制約があるから、人数が増えるとレイヤーを増やすしかない。レイヤーが増えるほど情報の流れは遅くなる。これが2,000年間、地球上のあらゆる大組織が抱えてきたトレードオフです。

2,000年の間、組織はずっとこの制約と戦ってきた。プロイセンが1806年に参謀本部（中間管理職の発明）を生み、アメリカ鉄道会社のマッカラムが1850年代に世界初の組織図を書き、戦後はマトリクス組織やスクワッド・ホラクラシー・フラット組織と色んな実験が続いた。

でも数千人を超えるとみんなヒエラルキーに戻った。span of control を破る、現実的な代替の情報ルーティング機構が存在しなかったからです。

AIが置き換えるのは「情報ルーティング機能」そのもの

ところが2026年になって、Jack Dorsey の Block がFrom Hierarchy to Intelligence という強烈な文章を出します。要約するとこうです。

これは、情報処理の人海戦術が要らなくなる、ということ。

中間管理職が肉体労働として担っていた「ステータス把握 → 集約 → 上に伝達 → 下に伝達 → アラインメント」の機能を、AIが常時・非同期・自動で処理できる。だから2,000年続いた span of control の制約が、はじめて緩むんです。

Blockが提案する4層モデル（汎化）

Blockは、企業を4つのレイヤーで組み直すべきだと言っています。各層を順に見ていきます。

1. Capabilities（能力の積み木）

「プロダクト」ではなく、再利用可能な能力単位。UIを持たず、信頼性・コンプライアンス・性能の目標を持つ。

例えばこういう仕事: 「自社の"通知"機能を、顧客通知だけでなく社内アラートにも、パートナー通知にも使える形に汎用化する」「リサーチ機能を、新規案件にも既存案件にも、社内リサーチにも使える形で抽象化する」

なぜ重要か: ロードマップが「機能を作る」から「能力を組み合わせる」に変わる。プロダクトマネージャーの仕事の前提も変わります。

2. World Model（会社・顧客の状態を保持する層）

中間管理職が運んでいた情報を、ここが代替する。2種類あります。

会社 World Model: 社内の意思決定・議論・進捗・課題が、機械可読な形で1箇所に集約されている状態

例えばこういう仕事: 「火曜の朝、誰がどのプロジェクトでブロックされているかを、CEOが起きる前にAIが把握している状態を作る」「Slackの会話を、意思決定として残るドキュメントに昇華する仕組みを設計する」

顧客 World Model: 顧客の状態（行動・課金・離脱兆候）がリアルタイムで反映されている状態

例えばこういう仕事: 「アンケートではなく、実際の使用ログから"この顧客は来月離脱しそう"と判定するモデルを保持する」「決済データから、加盟店の事業フェーズの変化を検知する」

なぜ重要か: かつて中間管理職が運んでいた情報フローを、ここが代替する。週次定例で「いまどうなってる？」と確認する必要がなくなる。

3. Intelligence Layer（構成と先回り）

World Modelを読んで、Capabilitiesを組み合わせ、解決策を構成して先回りで届ける層。AIエージェント群の本体です。

例えばこういう仕事: 「特定の顧客状況パターンに対する解決策テンプレートをAIに学習させ、新しいパターンを発見したらレパートリーを増やす」

ここが、かつての PM／プロダクト戦略／カスタマーサクセス企画の仕事を、構造的に代替していく層です。

4. Interfaces（提供面）

Web、アプリ、API、CLI、Slackボット、Email など。

例えばこういう仕事: 「同じソリューションを、エンタープライズ顧客にはSlackで、個人ユーザーにはアプリで、APIユーザーにはWebhookで届ける」

重要なポイント: 価値はここではない。差し替え可能。価値は World Model と Intelligence の側に宿る。「UIから設計する」発想を捨てる必要があります。

人の役割は3つに正規化される

4層モデルが組まれると、人間の役割は自然と3つに収束していきます。

1. IC（Individual Contributor）

各レイヤーを作って動かすスペシャリスト。マネージャーの指示を待たない。World Model を読んで自分で判断する。

旧組織との対応: エンジニア、デザイナー、データアナリスト、編集者、リサーチャー

例えばこういう仕事:

• 「Capabilities担当のエンジニアが、World Modelで"このセグメントには非接触決済の需要が高い"とわかったから、誰の指示も待たずに新モジュール開発に着手する」

• 「編集者が、AIエージェントが書いた初稿に対して、World Modelの過去パフォーマンスデータを参照してフックの修正を入れる」

2. DRI（Directly Responsible Individual）

特定の課題・成果に責任を持ち、必要に応じて各レイヤーからリソースを引き出す。役職ではなくアサインメント。終わったら別の課題に移動する。

旧組織との対応: PdM、プロジェクトオーナー、横断PM

例えばこういう仕事:

• 「"中小企業セグメントの90日離脱率を30%下げる"というKPIに責任を持って、Capabilities / World Model / Interface 各チームからリソースを引き出して施策を回す」

• 「特定のエンタープライズ顧客の導入成功に責任を持って、契約から導入完了まで90日間オーナーシップを取る」

期間限定。完了したら次の課題へ移動する。マネージャー職ではなく、課題ごとのオーナーです。

3. Player-Coach

自分も手を動かしつつ、人を育てる。情報ルーティングはやらない（それはWorld ModelとDRIが担う）。

旧組織との対応: シニアエンジニア + マネージャーのハイブリッド

旧マネージャーとの違い: ステータス会議・1on1・優先順位調整に時間を使わない

例えばこういう仕事:

• 「シニアエンジニアが自分でも本番コードを書きつつ、若手のコードレビューと技術判断のメンタリングをする。週次定例ではなく、ペアプロと非同期レビューでやる」

• 「シニアデザイナーがプロダクトの要のUIを自分で設計しつつ、ジュニアの作品を週次でクリティーク（批評）する」

置かれない役割: 「情報ルーティングが主業務の中間管理職」

これが Block モデルの肝です。

これまでの組織で「マネージャー」と呼ばれていた職種の業務内訳を分解すると、実は情報ルーティングが大半だった。会議でステータス確認、Slackでメンション転送、上に報告、下に伝達、横と調整、優先順位の交通整理。

これらは全部 World Model がやれる。だから中間管理職レイヤーそのものが要らなくなる。

これは「マネージャーが要らない」というより、「情報ルーティングだけのマネージャーは要らない」と言った方が正確です。判断・育成・対外関係といった人間にしかできない部分は、DRI と Player-Coach が引き取る。

第3部: 3つの実装ケース ― 規模が違っても構造は同じ

ここまでが理論で、具体例を示す意図で。実装している企業を見ていきます。

スケールが大きい順に並べます。規模は違っても、構造は同じです。

Case A: Block（1万人規模 / 上場企業）

すでに述べた通り、Blockは From Hierarchy to Intelligence でこのモデルを宣言し、実装フェーズに入っている1万人規模の上場企業です。

具体的にやっていること

• 全社のオペレーションを機械可読なアーティファクトとして残す（リモートファーストだから可能）。これが会社 World Model の原材料

• Cash App と Square から得られる取引データを顧客 World Model の核に据える。「アンケートでは嘘をつくが、金は嘘をつかない」

• AI agent framework Goose を社内で全社展開、同時にオープンソース化

• Square 側では Managerbot という、自分から動くAIエージェントを投入

そして文の最後はこう締めくくられています。

記事の末尾では、要するに、AIの使い方が2通りあると言っています。

1つ目は、既存組織を維持したまま、AIで人を減らして利益率を改善するという使い方。短期的には数字が出るけど、組織の構造そのものは変わっていないので、いずれ「AI前提で組み直された競合」に市場ごと持っていかれる。

2つ目は、AI前提で組織そのものを引き直すという使い方。何が自社の本質的な強みで、何が単なる手続きで、誰がエッジ（人間にしかできない判断）に立つべきか？これを問い直す。AIは答えをくれるんじゃなくて、自分たちが本当に何で勝っているのかを暴き出す。

Block が言いたいのは、前者の道はやがて後者に吸収されるということ。「AIでどの業務をAI化出来るか」だけ考えている会社は、実は静かに死んでいるかもしれない。これは経営者として読むと、ぞくっとする問いかけです。

Case B: Base44（1人 → 8人 / 6ヶ月で $80M exit）

イスラエルの個人開発者 Maor Shlomo が完全ソロで立ち上げた、no-code / vibe coding プラットフォーム。

数字が衝撃的です（出典: TechCrunch / Lenny Rachitsky による本人インタビュー）。

• 2024年末にローンチ

• 3週間で $1M ARR 到達

• 3ヶ月の間、HTMLもJavaScriptも自分で書いていない（AIが実装担当）

• 6ヶ月後、Wix が $80M キャッシュで買収（2025年6月）

• ユーザー数は買収時点で 25万〜40万人

• チームは買収時点で 8人。Maor は買収益から自主的に $25M をチームに分配

• 外部資金調達はゼロ。自己資金 $10K〜$20K（ほとんどがLLM API代）

何が起きていたか。Maor 自身、ADHD を公言している。普通なら「組織を作ってマネージャーを採用してスケールする」フェーズで、彼はそれをやらなかった。代わりにやったのは:

• Capabilities: アプリ生成、データベース、認証、ストレージ、分析、外部統合などを再利用可能な部品として実装

• World Model: ユーザーがどんなプロンプトを入力し、どんなアプリを作って、どこで詰まり、どこで成功したか？をリアルタイムで蓄積したコンテキストなど

• Intelligence Layer: ここがBase44の核心。「自然言語のアプリ要求 → 仕様 → コード生成 → デプロイ」までをルーティング・最適化する独自のプロンプト・ハーネス層を Maor が構築している。GPT / Claude は実装エンジンとして"燃料"のように使われていて、Intelligence Layer 側がアプリ開発というドメインに特化している。だから LLMが進化すると、製品が一晩で勝手に良くなる（Claude 3.5 リリース時、エンジニアリングなしでクオリティが跳ね上がったと本人が証言）。これは「LLMをそのまま使っている」のではなく、「LLMの進化を直接的にプロダクト品質に変換できる Intelligence Layer を持っている」という構造的優位

• Interfaces: Webアプリ単一

人の役割で見ると、Maor 1人が DRI = 全部の課題のオーナー。後から加わった8人は全員 IC か Player-Coach。マネージャー職は1つもない。

この構造で、6ヶ月で $80M。Wix が買ったのは「Base44のプロダクト」というより、「6ヶ月で40万ユーザーに到達できる、組織アーキテクチャそのもの」だった、と多くのアナリストが指摘しています。

Case C: Pieter Levels（ピュアソロ / 5+プロダクト並列）

オランダの個人開発者 Pieter Levels（@levelsio） は、いま5つ以上のプロダクトを完全に1人で並列運営しています。本人が公開しているリアルタイム収益ダッシュボードがソースです。

ポートフォリオ:

• PhotoAI（AI画像生成）: 月 $130K

• Nomad List（ノマド向けプラットフォーム）

• RemoteOK（リモート求人）

• InteriorAI（部屋の画像生成）

• fly.pieter.com（3Dフライトシム）

合計で月 $250K 以上。年商換算で $3M超を、1人で回しています。

特に象徴的なのが fly.pieter.com です。2025年2月22日、Pieter は AI コーディングエディタ Cursor に「ブラウザで動くフライトシムを作って」と指示した。3時間でプロトタイプが完成。彼はそれまでゲーム開発経験がなく、ほぼコードを書いていない（出典: みんなのニュースレター解説記事 および本人の X 投稿）。

ここから先がもっと面白い。

Pieter はプロトタイプをそのままX（旧Twitter）に投稿。ユーザーが触る → 反応・要望・不満がリプで返ってくる → Pieter が Cursor に「これを足して」と指示 → AI が実装 → 数時間後にデプロイ → またX投稿。このループを毎日回した。最初は殺風景な土地でフライトするだけだったゲームに、ミサイル、マルチプレイヤー、バルーン、撃墜カウントが日替わりで足されていく。ローンチ20日で月収益 $130K に到達しています。

これって構造的に何が起きているかというと、「ユーザーフィードバック → 仕様判断 → 実装 → デプロイ」の意思決定ループが、人間1人＋AI＋Xで完結している。普通の会社ならPM・エンジニア・QA・CS・マーケで分業されるこの一連のフローが、Pieter の頭の中でほぼリアルタイムに圧縮されている。マネジメント階層がないから、判断から実装までの時差がほぼゼロ。これがソロ × AI の最大の構造的優位です。

これを4層モデルにマップするとこうなります。

• Capabilities: 各プロダクトを構成するプロダクト機能そのもの——ユーザー認証、Stripe決済、画像生成API（PhotoAI / InteriorAI）、地理データ＋コミュニティ機能（Nomad List）、求人投稿（RemoteOK）、ゲームエンジン（fly.pieter.com）など。これらは Pieter のプロダクト群で再利用される部品

• Intelligence Layer: ここが Pieter の核心。Pieter自身の頭の中にある「何を作るべきか」の判断 ＋ Cursor / Claude / GPT を使ってそれをコードに落とすハーネス。コーディング・デザイン・3Dモデリングは「Capability」ではなく、この Intelligence Layer の中にあるAI能力。彼は「コーディングできるAI」を、Capability を構成する道具として使っている

• World Model: 各プロダクトの利用ログ・課金データ・離脱パターンが核。X（Twitter）はそれを補強する生のシグナル源。Build in Public で要望・不満・反応が常時流れてくるが、これ自体はモデル化されたものではなく原材料。Pieter の頭の中で集約され、「次に何を作るか」の判断に使われている

• Interfaces: Webサイト群（5+プロダクトそれぞれ）

役割で見ると、Pieter = DRI（5プロダクトすべての課題オーナー）= IC（プロダクト企画・指示出し）。マネージャーはいない。社員もいない。

面白いのは、プロダクトが5つに増えてもチームを増やさず、AIで横展開していること。普通なら「PhotoAIに専任PM、RemoteOKに専任CSを置こう」となるところを、「全部 Pieter + AIエージェント群」で回している。

これは Block の "From Hierarchy to Intelligence" を、1人スケールで完全に体現している実装です。

共通している設計原則

3ケースを並べると、規模はバラバラ（10,000人 / 8人 / 1人）ですが、設計の核は同じです。

1. 役割・権限・引き継ぎが明文化されている — 暗黙のルールに依存しない

2. World Model が中央化されている — Block はリポジトリ + 取引データ、Base44 はユーザーのプロンプト履歴とアプリ生成ログ、ソースコードそのもの。Pieter は各プロダクトの利用・課金ログ + X からの生シグナル

3. 判断基準がドキュメント化されている — 人ではなくシステムが判断を下す部分が多い

4. 中間管理職レイヤーを置いていない — 情報ルーティングは AI と World Model が担う

5. 既存組織の機能別分業を持ち込まない — 「PMチーム」「エンジニアチーム」のような縦割りがない

つまり、AI中心の組織設計はハイテク大企業だけの話じゃない。1人スケールでも8人スケールでも、構造として同じことが成立する。

そしてここが本記事の核心ですが、この設計は規模が小さいほど組みやすいんです。既存ヒエラルキーを引き継いでいないぶん、抵抗が少ない。逆に大企業ほど苦労する。

第4部: ではどんな変化が求められるのか — 規模別プレイブック

ここからは、スケールに応じて何をすべきか？という例を書いていきます。

4-1. 大企業（数百〜数千人規模）

現状の制約

特に日本企業では、既存のヒエラルキー、既存のマネージャー、既存のシステム、既存の評価制度を引き継いでいる。一気には変えられない。

しかも厄介なことに、既存の中間管理職は「AI中心の組織設計」に最も抵抗するインセンティブを持つ層です。自分の仕事がなくなる話だから当然です。

やるべき順序

1. World Model の基礎工事から始める

全社の意思決定・議論・進捗を機械可読な形に集約する。SlackじゃなくGitHub/Notion/Confluence/自社ポータルなどの公開ドキュメントに。会議の議事録ではなく、決定事項のレコード。キモはAIが可読である状態を作ること。

これがないとAIエージェントは何もできない。逆に言えば、World Model の質が、組織のAI化の上限を決める。

2. パイロットチームを1つ作る

中間管理職を置かない3〜5人 + エージェント群のチーム。新規事業や独立性の高いプロジェクトを担当させる。既存の評価制度から外すことが重要。

ここで「DRI + IC + AI Intelligence」の最小構成を試す。うまく回ったら、別チームに展開する。

3. 既存マネージャーの再定義

「ステータス共有のためのマネージャー」を Player-Coach に転換。情報ルーティング業務はAIに渡す。代わりに、自分も手を動かして、若手を育てる役割に戻す。

これは大規模な人事制度改革を伴うので、時間がかかる。3〜5年スパンで考えるべき。

4. AI活用度を評価軸に組み込む

Block 方式（賛否はあるが意思は明確）。AI活用度が人事評価に直結するようにすれば、組織全体の動きが変わる。究極的には組織の動きは大きな組織であれば人事制度・評価制度によって変化します。

AIをコパイロット配布で終わらせない。各人の生産性は上がるが、組織のスループットは変わらない。この状態を割けるためにトップの意志の明確化をする。

※下記のように人事部門のトップにCTOが立つような事例もでてきています。（評価制度に関しては不明ですが）

4-2. 成長期スタートアップ（10〜100人）

現状の制約

ちょうどヒエラルキーが芽吹く時期。「PM入れる？マネージャー入れる？シニアエンジニアにマネージしてもらう？」と悩むタイミング。

ここで普通の組織テンプレに従って機能別分業を作ると、ローマ軍と同じ罠にハマる。スケールしてから戻れなくなる。

やるべきこと

1. 採用前にエージェントで代替を考える

「マネージャー1人」を採用する前に、「World Model + DRI + AI調整層で同じ問題が解けないか」を必ず1度考える。

採用は最終手段。「人を増やす」は調整コストを増やすという認識を持つ。

2. 機能別組織を作らない

「PMチーム」「エンジニアチーム」「デザインチーム」に分けると、ローマ軍と同じ罠にハマります。課題ベースのDRIアサインにする。

「決済機能の改善」というプロジェクトには、PMもエンジニアもデザイナーも入る。次の四半期は別の課題に再アサイン。固定の機能別チームを作らない。

3. 会議をログに置き換える

週次定例を廃止して、AIによる週次サマリーに替える。会議は「意思決定・判断」のためだけに使う。「共有」のための会議はゼロにする。

4. 採用基準: マネージャー候補ではなく Player-Coach 候補を採る

「人を管理する人」ではなく「自分でも手を動かせて、周りを育てられる人」。これが探しにくいので、採用基準を最初に明文化しておく。

割けるべきは、スケールしてきたとき「やっぱりマネージャー必要だ」と既存組織のテンプレに戻ること。戻らないために、World Modelを採用ペースより速く育てる。

組織が30人を超えたあたりで、必ず「マネージャー入れよう」という議論が出ます。そこで踏みとどまれるかどうかが分水嶺。

4-3. 創業期スタートアップ（1〜5人）

現状の有利を持っているのは実はこの層かもしれません。なぜなら引き継ぐべきヒエラルキーがないから。初日から intelligence-native で組める唯一のフェーズ。

ここで普通のスタートアップ組織図（CEO / CTO / Designer / Sales）を作ると、自分の手で2,000年前のローマ軍の構造を再生産することになる。もったいない。

そんな創業期スタートアップがやるべきこと

1. Day 1: 共有リポジトリを会社の本体にする

まずは、GitHub / Notion / Linear など、何でもいいので、単一の中央リポジトリを会社の本体として運用する。全意思決定・全議論・全アーティファクトをここに集める。

そして生データをただ放り込むだけでなく、コンテキストを整える。セマンティックレイヤーやらオントロジーやら言われるレイヤーです。これを0からの状態で構築出来るのが何よりの強みです。

ここが会社の World Model になります。

2. 役割を「機能」ではなく「ロール」で定義する

CEOではなくDRI、エンジニアではなくIC、デザイナーもIC。肩書きをロール名に変える。これだけで思考が変わる。日本語では馴染みがない言葉なのでリデザインは必要だと思いますが。

3. AIエージェント基盤を先に組む

採用より先に、Research / PM / Brand / QA / Marketer … など、4〜5体のエージェントから始める。Claude Code / Codex / Cursor あたりで利用可能なエージェント群と携えるSkillを設計しておく。これはつまりこれまでだと「採用要件を決めて採用して始めて動き出す」ことでしたが、今ではもはや「採用・業務要件を決めてAIと動き出す」が定石です。

人を雇う前に、「人を雇わずに済む構造」を先に作る。

4. 判断基準をスキル(.md)に書き出す

暗黙知を最初から最後まで常に最新状態で明文化する。「組織が良い定義するもの」「やってはいけないこと」「品質基準」「価値観」「経営思想・事業計画」を、まずはMarkdownで蒸留する。

これがAIエージェントへの指示にも、後から人を採用したときのオンボーディングにも使える。1度書けば永久資産。

5. 採用は Player-Coach か IC のみ

「マネージャー職」を1つも作らない。これを最初の20人くらいまで貫く。

地雷は、「最初は普通の組織で、軌道に乗ってからAI化しよう」と思うこと。逆です。

最初に組み直すコストが一番低い。後から組み直すのは、既存社員の再教育・人事制度変更・抵抗との対峙、すべてが重なってむしろ工数が激増します。AI化するにしても新しい組織・小さな事例から始めるのがキモです。

まとめ — 組織の側を、AIに合わせて引き直そう

長い記事になったので、最後に要点を3つだけ。

1. 2026年は「業務のAI化」から「組織のAI化」への踊り場

AnthropicもOpenAIもMicrosoftも、AIを「個人のツール」ではなく「組織の構成員・調整層」として出してきた。SkillsとMCPで配管はもう引かれている。残された論点は「組織の側がどう使うか」だけ。

2. これからの数年で、企業は2つに分かれる

• 既存組織にAIを足した企業 → 個人の生産性は上がるが、組織のスループットは変わらない。やがてAI前提で組み直された競合に、市場ごと持っていかれる

• AIを軸に組織を引き直した企業 → 規模に関わらず、桁違いのスループットを出す。Block / Base44 / Pieter Levels はその先駆け

3. この分岐は、規模も業種も選ばない

1万人の上場企業も、1人の個人開発者も、同じ問いに向き合う。「役割・権限・引き継ぎを、AI前提で書き直すか、書き直さないか」。それにつきます。

この変化は、エンジニアだけの話ではなく、経営、もはやあらゆる組織の問いです。

「誰に何を任せるか」「判断基準は何か」「成果物の品質をどう定義するか」？全部、組織設計・経営の問いです。

人間のチームを動かしてきた経験を持っている人ほど、向いている。「自分は非エンジニアだから乗り遅れる」と感じている人ほど、実は最も有利な側にいるかもしれない。

業務にAIを足す時代は終わり、組織の側をAIに合わせて引き直す時代が、もう始まっている。

少なくとも自分は、そう確信しています。

引用元 / References

Block / Jack Dorsey

• Block. (2026). From Hierarchy to Intelligence. — https://block.xyz/inside/from-hierarchy-to-intelligence

• Block. (2025). Block Open Source Introduces "codename goose." — https://block.xyz/inside/block-open-source-introduces-codename-goose

• VentureBeat. (2026). Block introduces Managerbot, a proactive Square AI agent. — https://venturebeat.com/data/block-introduces-managerbot-a-proactive-square-ai-agent-and-the-clearest

Base44 / Maor Shlomo

• TechCrunch. (2025-06-18). 6-month-old, solo-owned vibe coder Base44 sells to Wix for $80M cash. — https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/

• Lenny's Newsletter. The Base44 bootstrapped startup success story | Maor Shlomo. — https://www.lennysnewsletter.com/p/the-base44-bootstrapped-startup-success-story-maor-shlomo

Pieter Levels

• 本人プロフィール / リアルタイム収益ダッシュボード — https://x.com/levelsio

• みんなのニュースレター. ✈️AIだけで3時間でゲームを作り20日で月1300万円の収益まで成長させた天才Pieter levels氏. — https://umatan.m-newsletter.com/posts/a167291560b0bf78

• 本人 fly.pieter.com 制作開始の X 投稿 — https://x.com/levelsio/status/1893350391158292550

関連参考

• Anthropic. Building effective agents. — https://www.anthropic.com/engineering/building-effective-agents

• Anthropic. How we built our multi-agent research system. — https://www.anthropic.com/engineering/built-multi-agent-research-system