全員がAIを持ちながら、組織としては何も学べていないとしたら

AIを使っているのは「人間」か、それとも「組織」がそこから学びを得ているのか。トークンを消費したことで、一体何が変わったのだろう。そして、個人の発見をチームへ、さらには組織の能力へと昇華させているのは誰なのだろうか。

イーサン・モリックは、組織におけるAI導入について以前から発信を続けている。彼の著書『Making AI Work』で指摘されているのは、AIによる個人の生産性向上は、自動的に組織の利益にはならないという点だ。 個人は作業が速くなり、文章が上手くなり、分析や自動化を加速させ、静かに「サイボーグ化した自分」へと進化していくかもしれない。だが、会社自体は相変わらず何も学んでいない、なんてことが普通に起こり得る。

多くの企業がいま、GitHub Copilotのライセンスが配布され、ChatGPT Enterpriseが導入され、現場のあちこちでClaudeやGemini、Cursorが使われ始めるフェーズに差し掛かっている。どのチームにも、公式の教育資料を遥かに先取りした「使いこなしている人」が最低一人はいるはずだ。 その一部は可視化されているが、多くは隠れたままだ。経営陣が見ているのはライセンスの使用率（「去年Anthropicに払った200万ユーロの投資対効果はどこにあるんだ？」）や、せいぜいプロンプトの実行数、アンケート結果、あるいはステアリングコミッティーの資料に載せるための、景気のいい社内PoC（概念実証）の結果くらいだろう。他の会社では、AI導入がIT部門に丸投げされた瞬間に死んでいるケースもある。

誰もが気づいているはずだが、ここからが本当に、めちゃくちゃややこしいフェーズになる。 AI利用が至る所に広がり、バラツキがあり、一部は隠蔽され、比較も難しく、それでいて組織の学習に結びついていない。この「混沌とした中間期（messy middle）」が始まるのだ。

全員がCopilotを持った、その先

AI導入の第一段階は（大抵の場合）心地よいものだ。他のエンタープライズ製品の導入と同じように見えるからだ。ライセンスを買い、利用規約を定め、トレーニングを行い、推進リーダー（チャンピオン）のネットワークを作る。Teamsのチャンネルで事例を共有してくれと呼びかける。そのチャンネルは一瞬だけ盛り上がり、やがて「善意」という名のガラクタが詰まった、企業の屋根裏部屋の一つへと成り果てる。

だが、第二段階はもっと奇妙なことになる。 あるチームはCopilotを単なる「自動補完」として使い、それで満足する。別のチームはClaude Codeを駆使し、テストとレビュー、継続的な軌道修正のループを高速で回す。プロダクトオーナーがいきなり、Figmaで画面を作る代わりに動くソフトウェアのプロトタイプを作り始める。シニアエンジニアは、AIなしでは2週間かかったはずの原因分析をエージェントに任せ、1時間足らずで妥当な解に辿り着く。一方で、ジュニア層は洗練されたコードを出力するが、そのシステムにどんなアーキテクチャ上の前提が紛れ込んだのか全く理解していない。サポートチームは、CoE（Center of Excellence）の誰も問いを立てなかった「現場の痛み」を熟知しているがゆえに、定型チケットをワークフロー自動化へと静かに作り変えていく。

これらすべてが、同じ会社で同時に起こり得る。 これこそが「中間期」をカオスにしている正体だ。導入の単位はもはや組織ではなく、チームですらない。「仕事の中にあるループ」そのものなのだ。

モリックの「リーダーシップ、ラボ、クラウド（大衆）」という枠組みはここで役に立つ。リーダーシップが方向性と許可を与え、現場（クラウド）が実際の仕事を通じてユースケースを発見する。そしてラボが、それらの発見を共通のプラクティスやツール、ベンチマークへと変えていく。 だが、僕がどうしても引っかかるのは、エージェントによるエンジニアリングで繰り返し直面する問題と同じことだ。つまり、「その学びはどうやって伝播していくのか？」という点である。

古い「変化の仕組み」は遅すぎる

ほとんどの企業は、既存の仕組みでAI導入を処理しようとするだろう。コミュニティ、勉強会、推進ネットワーク、マニュアル、相談会、月次のデモ、アンケート、あるいはダッシュボード。まあ、僕もやったし、君もやったはずだ。実験の許可が必要な組織においては、それも多少は助けになる。

しかし、本当に興味深いAIの成果は、次のコミュニティ会議を待ってくれない。 それはコードレビューや営業提案、リサーチ作業、プロダクトの試作、障害対応、テスト戦略、コンプライアンスの検討といった日々の仕事の「内部」で発生する。あるいは、特定のコンポーネント群に対して「ダークファクトリー（無人工場）」に近い体制を誰かが構築した時に現れる。 やりたいこと（意図）を書き、エージェントを自由に走らせ、脱線しない程度の適度な負荷（バックプレッシャー）をかけ、厳しいシナリオで結果を評価し、意図を磨き上げ、高品質な結果を繰り返し得る。 そのストーリーが「ベストプラクティスのスライド」にまとめられる頃には、肝心の学びは往々にして牙を抜かれている。本当に価値があったのは、摩擦の部分なのだ。欠落していた文脈、失敗したテスト、奇妙なAPIの挙動、エージェントが支離滅裂になり、誰かが引き戻さなければならなかったあの瞬間だ。

僕はこれを「エラスティック・ループ（伸縮するループ）」というレンズで考えてきた。 AIとのコラボレーションは単一のモードではない。密結合した同期的な共同運転から、疎結合で非同期な委譲まで、その幅は伸縮する。導入における問いは、単に「AIを使っているか？」ではない。チームが「どのサイズのループを使うべきか」「どこに抵抗が必要か」「どの成果物を残すべきか」を理解しているか、そしてそれらが「組織が学べる何か」になっているか、なのだ。

これはツールの利用率やトークンの消費量を数えるよりも、ずっと難しい問いだ。

スクラムは「高価なイテレーション」のために作られた

かつて僕は、現代のソフトウェア開発プロセスの多くは、人間による反復（イテレーション）が高価だったから存在しているのだと主張した。スプリントプランニング、見積もり、スタンドアップ、ユーザーストーリー、チケットの整理、引き継ぎ。これら調整とリスク軽減のための儀式は、制約下では合理的だった。1回の反復に数日や数週間かかるなら、無駄を省くための構造が必要だからだ。

しかし、エージェントによるエンジニアリングは経済学を変えてしまう。より多くの選択肢を「具現化可能」にするのだ。 意図からプロトタイプ、そして評価へと、チームは遥かに速く動けるようになる。プロダクト担当者は動作するソフトをより早い段階で目にでき、エンジニアはコミット前に多くの仮説を検証できる。魔法のようにデリバリーが楽になるわけではないが、制約の場所が「実装」から「意図、検証、判断、フィードバック」へと移動する。

厄介なのは、多くの組織が20年もの間、アジャイルを自称しながら、アジャイルが取り除こうとしたはずの「組織的反射」を温存してきたことだ。いまやAIによって真のアジャイルが現実味を帯びているのに、システムはいまだに2週間のスプリントへのコミットメントや引き継ぎ文書を求めてくる。反復が「希少」であることを前提とした古い仕組みだ。

これもまた「儀式の墓場」なのだが、今度は導入レベルでそれが起きている。現場のループは、組織がその学びを消化（代謝）できるスピードよりも速く回ってしまうのだ。

「飲み放題」はいつまでも続かない

もう一つ、水面下で高まっている圧力がある。AIの利用は、より明確に「従量制」として可視化されるようになるだろう。 今のエンタープライズ界隈にある「全員にアクセス権があるから、請求書なんて気にするな」という空気は、長くは続かない。少なくとも今の形では。 モデルのルーティング、トークンの予算管理、利用状況に応じた価格設定、推論コスト、どのタスクにどのモデルを許可するかというガバナンス。これらは、企業が単なる「カジュアルなアシスタント」から「本格的なエージェント業務」へと移行するにつれ、より厳格に管理されるようになる。

ただ、これをコストへのパニックとして語りたいわけではない。それは「レンタルされた知性」の捉え方として一番つまらない。問いは抽象的なトークン消費の最小化ではない。ソフトウェア開発の目的が「キーストロークの最小化」ではないのと同じだ。

しかし、請求書はより本質的な問いを突きつけてくる。 「これらのトークンを消費したことで、何が変わったのか？」

お願いだから、プルリクエストの数なんて数えないでほしい。 そうではなく、「どのループがより速く閉じたか？」「どの意思決定が改善されたか？」「どの原因分析が鋭くなったか？」「どのレビューでより多くの問題が見つかったか？」「どのチームが再利用可能なパターンを学んだか？」「プロトタイプによって欠点が明らかになり、早期にボツにできたアイデアはどれか？」。 AIが「学習」を生んだのはどこで、単なる「アウトプットの増量」に終わったのはどこなのか。

「トークン対アウトプット」は、古い測定の反射が新しい衣装をまとっただけに過ぎない。「トークン対学習」こそが、本来重要視すべき指標に近い。

ループ・インテリジェンス：欠落したフィードバック経路

「混沌とした中間期」において、企業に必要となる3つの能力がある。

1. エージェント・オペレーション（Agent Ops）：

どのエージェントやAIツールが動いているか、どのシステムに触れ、どのデータを見ているか。どのアクションに承認が必要で、アイデンティティや監査、権限、実行時の可視性がどこにあるか。これは「制御」の側面であり、エージェントの仕事が実システムに触れる以上、極めて重要だ。

1. ループ・インテリジェンス（Loop Intelligence）：

AI支援（あるいはフルエージェント）のループのうち、どれが実際に「学び」を生み、どれが停滞し、どれが腐敗しているか。エージェントがレバレッジを生んでいるのはどこか、逆に無益な寄り道に走っているのはどこか。テストやコンテキスト、直感が足りないために、密着した監視から抜け出せないチームはどこか。逆に、より緩やかな委譲（疎結合なループ）への準備ができているチームはどこか。

1. エージェント能力（Agent Capabilities）：

便利な能力を、どうやって組織全体に配布するか。3つの巨大なエージェントが全員の仕事を代行してくれる、なんて幻想は捨てたほうがいい。AIは単一のアプリケーションカテゴリというより、流動的な基盤技術のように振る舞い始めている。エンタープライズという動物園のどこかに「人事エージェント」「開発エージェント」「営業エージェント」が整然と並ぶわけではない。 問うべきは、いかにして仕事が発生する現場に能力を流し込むかだ。従業員向けのハーネス、バックグラウンドで動くエージェント、プロダクトチーム、プラットフォームサービス、ローカルなスキル、MCPサーバー、評価スイート、ランブック、事例、ドメイン特化の手順書。

ここでプラットフォームの問いが面白くなる。これらの能力を所有するのは誰か。あるチームで発見された便利なエージェントのスキルを、死んだテンプレートにすることなく、どう他チームで利用可能にするか。 これら三つのうち、どれか一つが欠けても歪みが生じる。 「学習（Loop Intelligence）」のない「制御（Agent Ops）」は、単なる官僚主義的な管理になる。「能力（Capabilities）」のない「学習」は、有益なパターンは見つけるが、それを現場に還元する手段を持たない分析レイヤーに過ぎない。そして「制御」と「学習」のない「能力」は、単なるツールの乱立だ。

制御の経路、学習の経路、そして能力の経路。これらがどこかで交わる必要がある。

その場所を、僕は社内で「フィードバック・ハーネス（feedback harness）」と呼んでいる。顧客向けの言葉としてはあまり好きじゃないけれど。アーキテクチャ図に出てきそうな響きだし、顧客が買うのは仕組みの優雅さではないからだ。彼らが買うのは、確信であり、より良い意思決定であり、学習の加速であり、無駄の削減であり、安全な委譲であるはずだ。

だから、顧客向けのコンセプトとしては「ループ・インテリジェンス・ハブ（Loop Intelligence Hub）」という方が有用かもしれない。

フィードバック・ハーネスは、実際の業務ループ――タスク、プロンプト、仕様、レビュー、シナリオ、採用・却下された仮説、本番シグナル、手戻り、人間の判断と介入――に耳を傾ける。人間を監視するためではなく、ループを理解するためだ。 最初のバージョンは巨大なプラットフォームである必要はない。いくつかの実際のワークフローを選び、意図・エージェントの作業・検証・人間の判断が痕跡を残すポイントを計測する。ループがなぜ成功し、あるいは失敗したのかを理解するための定性的なフィードバックを集め、それを継続的な「学習の成果物」へと変えていく。

ハブはそれらのシグナルを、組織が行動可能な何かに変える。イネーブルメントのバックログ、能力のレーダーチャート、投資の概要、ガバナンスの欠落、再利用可能なワークフロー、トレーニングのニーズ、評価の優先順位。ダッシュボードは画一的である必要はなく、関連性の高いものにカスタマイズすればいい。 そもそも、面白いのはダッシュボードそのものではない。その後に続く「意思決定」だ。 「このチームはもっと委譲を進める前に、適切なバックプレッシャーが必要だ（ループを伸ばせ）」「このプロダクトグループには、特定のコンポーネントに対する再現可能なダークファクトリーのパターンがある」「このコンプライアンス業務には管理されたツールの境界線が必要だ」「5つのチームがバラバラに、しかも下手糞に再発明しているこのスキルは、プラットフォーム側に移すべきだ」。

ハーネスが収集し、ハブが組織の意思決定を助け、能力レイヤーがその学びを再び現場へとフィードバックする。

従業員監視になってはいけない

これが「従業員のスコアリング（評価）」に転じた瞬間、すべては死ぬ。

組織が「AIを十分に使っているか」を測定していると人々が信じれば、彼らはシグナルをハックし始めるだろう。あらゆる実験が「生産性のノルマ」になると信じれば、彼らは実験を隠すだろう。自分たちの最高のワークフローが単に「新しい基準の作業量」に置き換わるだけだと信じれば、彼らはそれを自分だけの秘密にする。 そうなれば、企業が得るものは最悪の形の導入結果だ。「表面上のコンプライアンスと、不可視化された学習」である。

だからこそ、単なる建前ではなく、真実の「意図」が重要になる。「誰がAIを十分に使いこなしているか？」ではなく、「AIによって仕事がどう変わり、そこから組織は何を学べるか？」を問わなければならない。

これについてはポリシー（規定）を書くこともできるし、そうすべきだろう。だが、ガバナンスも学習と同じで、実践を通じてしか本物にはならない。 エージェントが本番に近い仕事に触れ、プロダクト担当者が仕様書の代わりにプロトタイプを作り、開発者が原因分析を委譲し、トークンの支出が経営陣の目に留まるほど大きくなった時。その時初めて組織は、自分たちが「学習システム」を構築したのか、それとも単に「大量のライセンス」を買っただけなのかを知ることになる。

「混沌とした中間期」は、耐え忍ぶだけのフェーズではない

AI導入の第一段階は「アクセス」だった。誰がツールを持ち、誰が許可を持ち、誰が契約を交渉し、誰が調達チケットを切らずに最新モデルを試せるか。そのフェーズもまだ重要だが、長くは差別化要因にならない。最先端の知性へのアクセス権は、金でレンタルできるからだ。 だが、運用の制御（Ops）と組織的な学習は、同じようにはレンタルできない。

次の優位性は、「学習の速度（Learning Velocity）」にある。

誰が真のパターンをいち早く見つけるか。誰が個人の発見を組織の能力へと昇華させるか。エージェントが暴走しないよう、誰がループにバックプレッシャーを組み込めるか。便利なエージェント能力を、誰にも適合しない巨大な「エンタープライズ・エージェント」にすることなく、いかに適切に配布できるか。そして、古い儀式にAIを貼り付けるのではなく、誰がエージェントによるエンジニアリングを用いて「真のアジャイル」を実現するか。

まだ誰も答えを持っていないし、もちろん僕もそうだ。僕は「エラスティック・ループ」の概念を数ヶ月にわたって練り続けているが、顧客との会話、社内の議論、現場で起きる奇妙な事例のたびに、それは形を変え続けている。 それでいいのだ。ベンダーやコンサルタント、あるいはAIラボから「決定版の導入プレイブック」が届くのを待っていても、この変化の本質は理解できない。仕事を計測し、泥臭い学びを共有し、他人にツッコミを入れさせ、オープンに反復し続ける。それによってのみ、僕たちはこの変化を理解できるのだと思う。