人事をやりながら、ひとりでAIプロダクトを作っている立場で考えた仮説です。前半は「なぜ組織はそう変わるのか」、後半は「ひとりでそれをどう実装しているか」の実践編です。思想寄りのフル版は Zenn に置いています。
はじめに：ツールの話ばかりされている
個人開発でAIを使い倒していると、「AI時代の組織」という話題が、たいてい使い方の話で止まっているのに気づく。どのモデルが速い、利用率が何%、どの業務を自動化したか。
でも本当に効く問いは一段下にある。そもそも、組織はなぜ存在するのか。 そこを定義し直さないと、ツールを入れても何も変わらない。
なぜ組織は存在するのか（Coase → AIが壊す）
経済学の古典的な答えは、Ronald Coase「企業の本質」(1937) だ。会社が存在するのは、市場で取引するより人を中に抱えて協働させた方が安いから。探索・交渉・契約・検証という取引コストを内部化して下げている。会社の正体は「協働コストを下げる器」だった。
ここにAIが入る。AIエージェントが探索・調整・実装のコストをゼロ近くまで下げると、「内部に抱える方が安い」という前提が崩れ、組織の境界が溶ける（NBER「Coasean Singularity?」等で議論されている）。協働が安くなるほど、規模もプロセスも堀ではなくなる。
再定義：組織は「学習する主体（Learning System）」になる
残るのは、AIに安くコモディティ化されないもの＝その組織にしかない判断と学習だ。だから定義し直す。
AI時代の組織とは「器」ではなく、固有の判断と学習を蓄積し続ける「学習する主体（Learning System）」である。
Microsoft の2026 Work Trend Index も、組織は「Learning System」に変わり、自分たちの仕事から最も速く学ぶ組織が勝つ、と書いている。堀は規模ではなく学習ループそのものに移る。
【実践編】ひとりの「学習する主体」をどう運用しているか
ここからが本題。抽象論で終わらせたくないので、ひとりの個人開発でこの「学習する主体」を実際どう回しているかを書く。核は 「AIが提案 → 人間が決める → 結果を記録 → 学習が貯まる」 のループを、ツールではなく仕組みとして組むことだ。
① 提案：作り手としてのAI
Claude Code に /plan で実装計画と変更案を出させる。ここでAIは「作り手」に徹する。いきなり本番を変えさせず、まず提案を作らせるのがポイント。
② 決定：人間がゲートする
提案を自分がレビューして、採否を判断する。ここを人間が握り続けることが、後述する「主権」の条件になる。 どこまでAIに委ね、どこから人間が止めるかの線引きは、ツールが決めることではない。
③ 記録：判断をリポジトリの外に残す
採否の判断と経緯を、各リポジトリの STATUS.md（状態ファイル）に残す。エージェントは忘れるが、ファイルは忘れない。 次のセッションはこれを読んで再開するので、毎回ゼロからにならない。これが組織でいう「institutional memory」の最小実装にあたる。
④ 学習：繰り返す判断を skill に固定する
何度も同じ判断が出るなら、それを skill（SKILL.md）に書き出す。一度書けば、以降のセッションが毎回それを読む。プロジェクトの作法・設計方針・「あの失敗があったからこうしない」という暗黙知が、外側に蓄積されて複利で効く。
⑤ 自己採点を避ける：maker / checker を分ける
書いたエージェントは自分のコードに甘い。なので作り手と検証役を別のエージェント（subagent）に分ける。テストや型チェックという客観的なゲートを通す。これがないと、ループは静かに失敗してトークンだけ燃やす。
この5つを回すと、ひとりでも「学習する主体」になる。そして重要なのは、土台のモデルを差し替えても、STATUS.md と skill に貯めた判断は手元に残ること。これが「学習を自分の側に所有する＝主権」の実体だ。先日あるモデルが一時使えなくなる出来事があって、この設計の意味を痛感した。
人間の居場所（Brynjolfsson の Turing Trap）
経済学者 Erik Brynjolfsson は「Turing Trap」で警告している。AIを「人の代替」に向けると価値は一握りに集中し、「人の増幅」に向ければ価値は広がる。
実装に引き直すと明快だ。AIが安くするのは実装で、人間に残るのは「何を作るべきか」の判断と、その結果への責任。/plan の中身を読まずに丸呑みした瞬間、増幅は代替に変わり、自分の理解（と主権）が痩せていく。差分は読む。ゲートは点検する。
これは結局「人事／組織設計」の問題でもある
Microsoft の調査は、組織図が職能でなく「やるべき仕事」で組み直され（Work Chart）、AI労働力を束ねる機能は「ITと人事の融合」になると言う。そして全組織が答えるべき問いを挙げている ―「誰がAIの成果をレビューし、誰がワークフローを更新でき、現場の勝ちをどう全社展開するか」。
個人開発でやっている①〜④は、規模を上げるとそのままこの問いになる。メルカリがCTOをCHROにしたのも地続きだろう。学習する主体の設計者になることが、エンジニアにとっても人事にとっても、次の中心スキルになると思っている。
まとめ：明日からできる最小の一歩
- AIに「いきなり実行」ではなく「まず提案」させる（
/plan） - 採否の判断を
STATUS.mdに残す - 繰り返す判断を
skillに固定する - 作り手と検証役を分け、客観的ゲート（test/lint/build）を通す
これだけで、自分の開発は小さな「学習する主体」になる。規模の話ではない。ひとりでも組織だ。
人事と個人開発の両側に立って出した、現時点の仮説です。外れていたら、また直します。
参照
- Ronald Coase「企業の本質」(1937) / NBER「Coasean Singularity?」ほか
- Erik Brynjolfsson「The Turing Trap」(2022)
- Microsoft Work Trend Index 2025–2026（Frontier Firm / Learning System）
- CNET Japan「メルカリのCTOがなぜCHROに？」（木村俊也氏）
- 「人的資本×トークン資本」「暗号屋OS（Palantir FDE / オントロジー）」をめぐる各論考