先日、kaleidofuture.com のフィロソフィーに、 「一人で、チームを超える。」 と記載しました。AIを圧倒的に使いこなすことで、3〜5人のチームがやっていた仕事を一人で完結させる、と。
しかし、独立して活動していくうちに、4つの天井を実感します。
並列実行の物理上限、観察視点の単数性、ドメイン外知見の不在、気力の単点障害。フィロソフィーで宣言したスタンスを、自分自身で検証してみたら、そう簡単に「超えた」とは言えない場所が、いくつも残っていた。
今回はそれを正直に書きます。先に結論を出すと、 「3〜5人分の量を一人で出す」という素朴な目標は、独立7ヶ月の僕の実運用ではほぼ届いている。一方で、 「チームと違う形の仕事を一人で出す」という再解釈に、スタンスを書き直したい、ということを感じました。
「3〜5人分」の射程は本当に届いたか — 独立7ヶ月の実数
世界の数字から先に並べます。
個人で開発に関わる母集団そのものが、AI時代に入って一気に膨らんでいます。 GitHub Octoverse 2024 によると、生成AI関連の公開プロジェクト数は137,000本に達し、 前年比98%増でした。GitHubに登録された開発者の活動が、AIを土台にして指数関数的に伸びている。
そして、AIで実際に何が自動化されているかも一次データがあります。 Anthropic Economic Index 2025年9月版 では、 API経由のビジネス利用の約77%に自動化パターンが含まれる と報告されています（Claude.aiの個人利用では自動化と拡張がほぼ半々）。エージェント的な使い方が、開発業務の中心になりつつある。
日本側の数字も同じ方向です。 ITフリーランス及びフリーランスエージェント市場白書 2025 によれば、ITフリーランス人口は2024年35万人から2028年45万人へ拡大見込み。僕の独立7ヶ月も、この曲線の中の一点です。
僕自身の実数を晒すと、こうなります。
| 領域 | 7ヶ月の実数 |
|---|---|
| プロジェクト数 | 検証含め40件超 |
| ジャーナル | 公開記事40本超、隔日→週3公開ペース |
| daily_news自動収集 | 1日3回×シェルスクリプト＋AI、土曜の週次レポート |
| KaleidoAIMusic | 公開楽曲65本超 |
| KF Japanese Lab | Discord α期で運営中 |
これらすべて、設計・実装・運用・公開を僕一人で回しています。実体感として、独立前のチーム業務での「3〜5人分」のアウトプット量に、ほぼ届いている。
1ヶ月前の検証記事 ジャーナル制作で僕がやっていることを2,445件の発言から分析した で、ジャーナル制作中の自分の発言ログを定量分析したとき、僕の仕事の3分の1は「修正指示」と「質問」で、コードは一行も書いていない、という結果が出ていました。Claude側に構造化・文章化を相当部分任せて、判断と方向性だけ手元に残す。 この分業の中で、量としては『3〜5人分』に届いている、というのが2026年5月時点の僕の現在地です。
だから、フィロソフィーに「一人で、チームを超える」と書いた。そこまでは、いまも撤回しません。
天井に4回当たった — 並列実行・観察視点・ドメイン外・気力
とはいいつつ、これまでの活動の中で4つの天井に当たりました。順に書きます。
天井1: 並列実行の物理上限
Claude Max 5xの5時間枠、作業PCのGPU（GTX 1660 Super）、人間側の確認スループット — このどれかが、必ず先に詰まります。
並列でサブエージェントを8つ走らせれば、リサーチや構成案は確かに8倍速で集まる。でも、戻ってきた8本の出力を 読んで、判断して、採否を決める作業 は、僕一人の時間に乗ってきます。一次データの矛盾を検出した、 並列サブエージェントにリサーチさせたら、同じ事例で数字が食い違っていた で書いた構造そのままです。日立のCopilot導入事例で、3つのエージェントが「200人」「5,000名」「3万人」と3つの数字を拾ってきた。並列リサーチで集まった素材を整合させる仕事は、結局シーケンシャルに戻る。
Codex Plus契約の記事 で書いた「AI筋肉」のように2系統に増やしても、判断する人間が単数である以上、ここの天井は構造的に残ります。
天井2: 観察視点の単数性
自分のバイアスにバイアスをかけて、自分一人では気づけない、という構造です。
なぜ人は他人の間違いを指摘したくなるのか で書いた、自分の知っている読み方を絶対化してしまう知識の呪いと、構造的には同じ場所にあります。一人で動いていると、自分の「正しい」が誰にも当たらないまま走る。
並列リサーチで矛盾を検出できた経験も、僕がたまたま整合性チェックを習慣化していたから引っかかっただけで、別ペルソナ（Codex等）からのセカンドオピニオンが入っていなければ、自信を持って間違った数字を書いていた可能性があります。
Codex Plus契約の記事 で 「AI筋肉」 と表現したのは、ここに対する部分的な解です。Claude Opus が書いた段落を GPT-5.5 に書き直させて並べる、という運用は、一人の中に 仮想的な複数視点 を立てる動き。とはいえ、いずれもAI由来の視点なので、そもそもの観察軸が人間側に偏らずズレるかは、まだ実感できていません。
天井3: ドメイン外知見の不在
独立してから、入ってこなくなった領域があります。
たとえば、近所のカフェ会で出会った主婦から、子どもの夏休みの宿題でAIが使われ始めている、という肌感覚を聞いた瞬間に、自分の頭の中の景色が一段更新された経験がありました。 企業から依頼を受けてAI講義をしてきた ときも、現場の参加者から、リサーチで読んでいた論文の言葉とは温度感の違う質問や反応をいくつも受け取りました。
これらは 一人で机の前にいるだけでは、絶対に手元に来ない情報 です。AIに「世間の感覚を要約して」と頼んでも、出てくるのは平均化された記述で、生の温度感ではない。
独立すると、受動的に流れ込んでくる情報の偏差（同僚の雑談、上司の判断、隣の部署の動き、現場のグチ）がほぼ消えます。「ノイズが減って集中できる」ように見えて、実は ドメイン外の温度感の供給源を意図的に作らないと枯れる という構造です。
天井4: 気力の単点障害
これが、いちばん見落としやすい天井でした。
僕が高熱で丸1日寝込めば、ジャーナルの隔日公開は止まります。daily_news収集はスケジューラー機能で自動化されているけれど、出力をレビューして週次レポートに昇華させるのは僕の頭の中の仕事。AIMusicも、楽曲生成・サムネイル制作・YouTube公開が一連のパイプラインになっているけれど、最後に「これを出すかどうか」を判断するのは僕です。
24時間365日の運用に近づけば近づくほど、 僕一人の体調・気分・気力が単点障害 として浮かび上がる。チームならローテーションで吸収できるリスクが、一人体制では構造として吸収できない。「足りないから、もっと頑張らないと」というフレーミングを自分に許さない、というのが、天井を越えるためというより 天井の手前を保つ ための必須スキルになっています。
Brooks法則の逆向きと、Wickensの4次元で読み直す
4つの天井を、教科書側から照らし直してみます。
ソフトウェア工学の古典中の古典、Frederick P. Brooks Jr. の 人月の神話（原題 The Mythical Man-Month、1975年初版・1995年20周年記念版）には、 「遅れているソフトウェアプロジェクトに人を足すと、さらに遅れる」 というBrooks法則が書かれています。AI時代の文脈で読み返すと、これは「人を足さずに進める」道が開けたとも読めます。
ただし、Brooksが1986年のIEEE Computer誌の論文、 「銀の弾丸はない」（原題: No Silver Bullet — Essence and Accidents of Software Engineering）で残したフレームの方が、今回の天井議論には効きます。Brooksは、ソフトウェア開発の複雑性を 本質的（essential） と 付随的（accidental） に分けました。本質的複雑性は問題自体に組み込まれていて、付随的複雑性はツール側の制約から来る。Brooksが「銀の弾丸はない」と言ったのは、新しい言語やツールがいくら出ても、消せるのは付随的複雑性だけで、本質的複雑性の天井は崩れない、という主張でした。
僕の言葉に降ろすと、AIで圧縮されているのは、付随的複雑性。本質的複雑性は、AIが進化しても消えない。天井1（並列実行）と天井2（観察視点）は、この本質的複雑性の側にある気がしています。
ここで、自然な反論が浮かびます。「並列実行の天井は、AIをもっと増やせばスケールするのでは？」「観察視点の単数性は、AIに判断を任せれば消えるのでは？」 — どちらも一見もっとも。
でも、両方とも同じ場所で詰まります。8つのサブエージェントを並列で走らせれば、戻ってくるのは合計1万字を超えるレポートです。これを「採るか」「棄てるか」「混ぜるか」と判定する作業は、最終的に人間に乗ってきます。「では採否もAIに任せれば」と続けたくなるけれど、その瞬間に観察視点の天井に転化する。並列リサーチで3つのエージェントが同じURLから「200人」「5,000名」「3万人」を拾ってきたとき、矛盾を検出するには 3つともAIではない、外側の判定者が必要だった。AIを増やしても、判定の通信構造は1点に縮退する。
つまり、 AIで増やせるのは「複製」。責任ある「判断主体」は縮退する。並列度や視点数は付随的複雑性の側にあって、いくらでも増やせます。一方、採否判定や責任ある裁定は本質的複雑性の側にあって、AIでは代替できない。これがBrooksの本質的（essential）／付随的（accidental）の枠組みを、AI時代の1人開発に当てはめた結論です。
この縮退を理論的に支えているのが、認知側と構造側の2つの古典です。
天井1の認知側の構造には、Christopher D. Wickensの 多重資源理論 を当てはめると言語化できます。Wickensが2008年にHuman Factors誌の50周年特集で再整理した、 「多重資源と精神的作業負荷」（原題: Multiple Resources and Mental Workload）では、人間の認知資源は単一プールではなく、 処理段階、処理コード、入力モダリティ、視覚チャネルの4次元、計16セル に分かれていると整理されている。並列タスクが8倍に増えても、人間の意思決定は同じ次元（言語コード×中心視チャネル×知覚段階）を奪い合う。だから物理的に詰まる。
天井2の構造側は、Melvin Conwayの1968年のDatamation誌の論文 「委員会はどう発明するのか？」（原題: How Do Committees Invent?）で示された、Conway法則が刺さります。Conwayは 「システムを設計する組織は、その組織のコミュニケーション構造に制約されたアーキテクチャを生む」 と書きました。AI時代の一人体制は、コミュニケーション構造が単一ノードに縮退している状態。だから、アーキテクチャの多様性も同時に縮退する。「一人だからクリーン」の裏に、「一人だから視点が単線化する」という構造的限界が必ず付く、というのがConway法則からの読み筋です。
注釈を入れておくと、Brooks法則は理論ではなく経験則です。Hsia, Hsu, Kungの 1999年のシステムダイナミクス研究 では、人を足しても遅れない条件も部分的にあると指摘されている。鵜呑みにしてはいけない法則ですが、それでもAI時代の文脈で再読する価値は残っています。
「天井がある」を疑う3つの反論
ここまでの自分の論を疑います。
反論1 — 「天井がある」のは、まだAIに任せきれていないだけでは？
先ほどのセクションでもピックアップされたテーマですが、これに対しては最新の一次データが反論を強める方向に出ています。
2025年7月、 METR（Model Evaluation and Threat Research）が公開したRCT論文、「2025年初頭AIがベテラン開発者の生産性に与えた影響の測定」（原題: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity、arXiv 2507.09089）では、平均5年関わってきた成熟リポジトリを持つベテランOSS開発者16名が、Cursor Pro と Claude 3.5・3.7 Sonnet を使って246タスクをこなしたとき、 タスク完了時間が19%増加 という結果が出ました。
しかも、本人たちはAI使用後に 「20%速くなった」と感じていた。この体感値と実測値のズレは、2025年の研究、「AIで賢くはなるが、賢明にはならない」（原題: AI makes you smarter but none the wiser）で示された、 逆Dunning-Kruger効果（AIリテラシーが高いほど自分の成績を過大評価する）と整合します。
注意点として、METR 2025はN=16の小規模・査読なしのプレプリントです。METR自身が 2026年2月の続報 で、後続実験はシグナルが不安定、と認めている。だから「AIで必ず遅くなる」とは一般化できません。それでも、 ベテラン領域では、AIに任せ切るほど遅くなることがある という反例の存在自体は、天井議論を強めます。
加えて、Apiiroが2025年9月に出した、 「速度4倍、脆弱性10倍」（原題: 4x Velocity, 10x Vulnerabilities）では、AI生成コードで 特権昇格パスが322%増、設計欠陥が153%増、クラウドの認証情報の露出が約2倍。シンタックスエラーは76%減ったけれど、深いアーキテクチャ欠陥は増えた。「もっと任せれば消える」では、たぶん消えない天井もある。
反論2 — 「3〜5人分」はもともと比喩で、文字通りの定量ではない
これは半分受け入れます。確かに、フィロソフィーの「3〜5人のチームがやっていた仕事を一人で完結させる」は比喩で、文字通り3〜5人分のラインオブコードを意味するわけではない。ただ、行動原則 「正直に検証する — 数字を残す。事実で語る。」 を掲げている自分としては、比喩に逃げずに 具体に降りてみる 作業をしてみたかった。今回の天井検証は、その具体降ろしの結果です。比喩を維持してもいいけれど、僕は数字を残す側を選ぼうと。
反論3 — 一人で天井を経験するから、そこからチームを使う判断が活きる
これは受け止めます。 天井の経験は、それ自体が資産 です。一度も天井を見たことがない人が、チームを足すのか、一人で粘るのか、そこを判断するのは難しい。今回の検証で4つの天井の輪郭を言語化できたから、これから先で、「どこでチームを足すか」 を判断する材料が手元にできる。それは、天井の手前で勝手に怖がってチームを過剰に組むより、構造的に有利な立ち位置だと思います。
塾講師4年×エンプラ5年の延長線にあった天井
ここで、自分の経歴の話を少しします。
塾講師時代の4年間、僕は個別指導で中高生に 数学を中心に教えていました。生徒一人ひとりに向き合う設計は、いまのKFのスタンスである、「一人で、チームを超える」 とほぼ同じ構造です。当時から、自分の頭にあるドメイン以外には絶対に届かない、という天井を、感覚として持っていました。受験数学は教えられても、生徒の家庭環境までは見えない。 一人で深く向き合うほど、自分の外側が遠くなる。
エンプラ開発の5年間は、逆方向の経験でした。交通・製造・エネルギーの3業界で、5〜20人規模のチーム開発を回してきた。チーム開発のコミュニケーションコストも、毎日肌で感じていました。毎日の業務時間のうち、Slackでのやりとりとミーティングで、純粋な実装時間が侵食される現場の気持ち悪さも、当事者として知っている。
いまのKaleidoFutureは、 塾講師時代の「個別」とエンプラ時代の「チーム」の延長線 にあります。AIを武装にして、塾講師時代の個別性をエンプラ規模のアウトプットに引き上げる試み。だから、当然のように、両方の経験が見せていた天井もまた延長線として残っている。
塾講師時代に感じていた「自分の頭の外には届かない」が、いま天井3（ドメイン外知見）として顕在化している。エンプラ時代のコミュニケーションコストを消したら、消えたコミュニケーション構造そのものが天井2（観察視点の単数性）として戻ってきた。 過去の経験が、今の天井の輪郭を先回りで予言していた ということ。
これは不思議な接続です。
「超える」の意味を書き直す
長くなりました。最後に、スタンスの定義の置き換えを置きます。
kaleidofuture.com のフィロソフィーには、こう書きました。
AIを圧倒的に使いこなすことで、3〜5人のチームがやっていた仕事を一人で完結させる。設計、実装、テスト、デプロイ、運用 — すべてを自分の手で回します。
これは撤回しません。 量としての「3〜5人分」は、独立7ヶ月の実体感として、ほぼ届いている。これは事実として残ります。
ただ、「超える」の意味を、量だけで解釈するのはたぶん間違いです。今回の検証で見えたのは、こういう景色でした。
| 「超える」の解釈 | 量だけ | 量＋形 |
|---|---|---|
| 同じ形式の仕事を一人で出す | ○ 実現中 | — |
| チームと違う形の仕事を一人で出す | — | ○ これからの設計領域 |
| 4つの天井を意識して回す | △ 無自覚運用 | ○ 言語化済み |
チームと同じ形式で3〜5人分の量を出すのは、AIで届く射程です。一方で、 チームでは出せない形の仕事 こそが、「超える」のもう一つの軸になる。一人で動くからこそ、複数視点を意図的にAI側で立てる、ドメイン外を意図的に外から取りに行く、気力の単点障害を構造として認める。これが、量と形の両方で「超える」の実装になる、というのが今のところの僕の見立てです。
そして、この定義の置き換えを支えるのは、フィロソフィーの3つ目「正直に検証する — 数字を残す。事実で語る。」だと思っています。今回の記事自体が、その実装の一例です。
FAQ
「3〜5人分」って、具体的にどういうタスクの話？
KaleidoFutureでいま僕が一人で回しているのは、ジャーナル隔日公開（リサーチ・構成・執筆・公開・音声化・llms.txt更新まで）、daily_news自動収集（1日3回×シェルスクリプト+AI、土曜の週次レポート）、AIMusic楽曲制作（Suno→サムネ→動画→YouTube公開のパイプライン）、KF Japanese Lab Discord α期運営、KF Court Discord常設、企業向けAI講義、freee API連携の経理基盤など、独立7ヶ月で40プロジェクト超です。エンタープライズ時代に同じ量を出すのに5〜20人のチームが必要だった肌感はあります。ただ、これは「同じ形式の仕事を量で出した」話で、フィロソフィーの「超える」をそこに閉じ込めるのは、本記事で書いた通り、僕は不十分だと考えています。
AIで一人で全部できるなら、チーム開発はもう不要では？
不要ではないです。本記事の天井3で書いた「ドメイン外知見の不在」と天井4「気力の単点障害」は、AIでは構造的に埋められない。ドメイン外知見はチームメンバーや顧客との接触面でしか入ってこないし、気力の単点障害はローテーションでしか吸収できない。むしろ「いつチームを足すか」の判断材料を、一人で天井まで触ったから手にできる、というのが反論3の話です。チーム開発は不要にならず、「どこで足すか」の解像度が変わる、という方が実態に近いです。
METR 2025の「19%遅くなった」って、Claude Codeでも同じ？
METR 2025の実験はCursor Pro と Claude 3.5・3.7 Sonnet を使った、ベテランOSS開発者16名・246タスクのRCTで、結果は19%遅くなった、というものです。これは「成熟リポジトリ × ベテラン × 2025年前半のモデル」という限定的な文脈の結果で、Claude Codeで一般的に同じ結果になるとは言えません。実際、別エージェントの調査ではGitHub Copilot RCT 2023でHTTPサーバ実装が55.8%速い結果が出ているし、Anthropic Economic Index 2025年9月版ではAPI経由のビジネス利用の77%に自動化パターンが含まれる、というポジ側のデータも揃っています。ベテラン領域では遅くなることもある、という反例の存在は天井議論を強めるけれど、「AIで必ず遅くなる」とは一般化できません。
4つの天井のうち、一番厄介だったのはどれ？
体感だと天井2（観察視点の単数性）です。並列実行の物理上限はサブスク追加と運用で部分的に解決できるし、気力の単点障害は構造として認めれば対処できる。ドメイン外知見はMarineペルソナでJP Lab を回したり、地域のカフェ会に顔を出したりすれば部分的に取れる。でも、観察視点の単数性は、自分のバイアスにバイアスをかけて気づけない、という構造なので、自分一人では検出できない。Codex Plusを契約してセカンドオピニオンの仮想ペルソナを立てる動きは、ここへの部分的な解ですが、本当にズレた視点を取り入れるには、AI由来でない人間との接触面が要る気がしています。これが対外活動や、AI以外の人との接触面を意図的に増やしている動機の一つです。
著者本人は、これからチームに戻る予定はある？
短期では戻りません。フィロソフィーの「一人で、チームを超える」を、量と形の両軸で実装するのが、これから半年〜1年の主軸です。ただ、本記事の反論3で受け止めた通り、4つの天井を言語化できたいま、どこかで意識的にチームを足す瞬間が来る、という想定はあります。具体的には、ドメイン外知見の天井を対外活動やAI以外の人との接触で部分的に取りつつ、それでも届かない領域が見えたら、そこは外注やパートタイム協業の検討に入る、という順序を想定しています。一人で全てを抱え込むことが「超える」の実装ではない、というのが今回の検証の結論です。
この記事が参考になったら
Share