AIエージェントにも「組織の粘性」はあるのかも?
AIエージェントの「人間臭い」組織論
Codex や Claude Code のようなコーディングエージェントを使っていると、妙に人間臭い挙動に出会うことがある。
大きめの機能を直接実装させようとすると、確認が増える。影響範囲を気にし、作業範囲を切り分け、実装前に計画を立てようとする。既存コードを壊さないためには当然の振る舞いだが、使う側から見ると、少し腰が重く見える。
このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。
散々行ったり来たりの問答の末、割といい感じの設計書ができたと思ったら、そろそろコンテキスト不足だから次のセッションがおすすめです、とか、会話をコンパクトにしますか？など作業の先延ばしとしか思えない提案をしてくる。個人的には「イヤイヤ期」が来たと思って、はいはいそうですねーと引き継ぎ資料などを作らせ別のセッションを始めるなどしていた。
ところが、同じ作業でも「別の Codex に実装を依頼して、あなたはそれを管理・監督してください」と指示すると、急に動きがよくなる。作業を分解し、担当を切り出し、レビューし、次の指示を出す。直接やるときより、管理者の立場に置いたときのほうが、なぜか前向きに見える。急にスピーディな対応をしてくださる。とてもありがたいのだが。
なんだか、人間の組織を見ているようで面白い。
経営層や管理職は改革に前のめりで、現場は変化に慎重になる。上のレイヤーから見ると、改革は合理的に見える。無駄をなくし、業務を標準化し、新しいシステムを導入する。常に問題意識があるのはいいが、常に変革を求めている。当然、全体最適を指向している。
しかし、現場から見ると話は違う。そこには最適化された手順があり、例外処理があり、過去の経緯があり、暗黙知があり、壊すと困る依存関係がある。現場にとっての局所最適は、「今動いている業務をより効率化すること、作業の時間を最短に、効果を最大化すること」である。上から見た全体最適は、現場にとっては、自分たちの最適化をゼロクリアする現場の破壊として現れることがある。
だから現場は抵抗する。あるいは、抵抗しているように見える。
ただし、それは単に保守的だからではない。現場はより多くのコンテキストを抱えている。コンテキストを多く抱えている場所ほど、変化に対して粘る。この「粘り」は、組織の弱さではなく、組織が持つ情報量そのものでもある。
この感覚は、組織研究でも古くから扱われてきた。Hannan と Freeman は 1984 年の “Structural Inertia and Organizational Change” で、組織には構造的慣性があり、組織形態や制度は簡単には変わらないと論じた。組織は信頼性や説明責任を高めるために手続きや役割を固定化するが、その固定化自体が変化への抵抗を生む。つまり、安定のために作られた構造が、変化の場面では重りになる。1
この「慣性」という言葉は、とても示唆的である。止まっているものは止まり続けようとし、動いているものは動き続けようとする。組織も同じように、現在の業務手順、責任分界、評価制度、権限構造を保とうとする。
さらにKrackhardt は、論争的なイノベーションが組織内でどう広がるかを “Organizational Viscosity” という概念で説明している。新しい考えは、組織の中を水のように自由には広がらない。そこには粘性があり、抵抗があり、通りやすい経路と通りにくい経路がある。2
ここで重要なのは、抵抗が単なる邪魔者ではないということだ。
摩擦がなければ、歩くこともできない。粘性がなければ、流れは制御しにくい。化学反応でも、すべてが瞬時に進めばよいわけではない。反応速度には意味があり、活性化エネルギーには意味がある。
組織の抵抗も同じである。変革への抵抗は、既存システムが持つ履歴、失敗経験、責任構造、暗黙知の総量でもある。粘性があるから、組織は急激に崩壊しない。摩擦があるから、無責任な改革案が現場を一気に破壊することを防いでいる。
一方で、粘性が強すぎれば変化は進まない。局所最適が強すぎると、全体最適は実現できない。各部署、各担当者、各プロセスがそれぞれ合理的に振る舞っていても、全体としては古い構造に閉じ込められることがある。
AIエージェントの組織化でも、同じことが起きているのではないかと感じられる。
一体のAIエージェントに大きな機能を直接実装させると、そのエージェントは既存コード、テスト、仕様、影響範囲、失敗時のリスクを一気に背負うことになる。その瞬間、エージェントは慎重になる。これは人間の現場担当者と似ている。局所的には、それが正しい。壊さないこと、失敗しないこと、確認することは合理的である。
しかし、全体として見ると、それだけでは進まない。大きな変更を実現するには、調査、設計、実装、レビュー、テストを分け、各役割が異なる粒度で判断する必要がある。監督するエージェント、実装するエージェント、レビューするエージェントを分けることで、コンテキストの負荷が分散され、全体として前に進みやすくなる。
これは単なるプロンプトテクニックではなく、かなり組織論的な現象なのではないか。
AIエージェントは単体の知能として見るより、制度の中で動く作業主体として見たほうがよい。ここで言う制度とは、README、作業指示書、テスト方針、タスク分解、レビュー手順、ログ形式、完了条件、失敗時の戻し方のような小さなルールの集合である。
制度ができると、そこには必ず粘性が生まれる。一度作ったプロンプトは使い回され、一度決めたレビュー形式は残り続ける。それは安定を生むが、同時に変化への抵抗にもなる。
だから、AIエージェントを組織化するとは、単に複数のAIを並べることではない。どの役割にどのコンテキストを持たせるか、どこで確認させ、どこで実行させるか、どこに摩擦を残し、どこで摩擦を減らすかを設計することだ。
全体最適と局所最適は、しばしば矛盾する。
現場エージェントにとっては、確認を増やすことが局所最適である。監督エージェントにとっては、作業を進めることが局所最適である。利用者にとっては、成果物が完成することが全体最適である。これらは同じ方向を向いているようで、実際には簡単にズレる。
だからこそ、必要なのは、より強いプロンプトではなく、よい『流路設計』である。
化学反応における触媒のように、反応が始まる経路を作る。流体が通りやすい管を設計するように、作業が進みやすい制度を作る。AIエージェントの時代に必要なのは、単に賢いモデルを選ぶことではなく、粘性を読み、摩擦を調整し、全体最適と局所最適のズレを扱うことなのだと思う。たとえば、実装前に、仕様分解をさせ、実装役にはTDDで失敗するテストから書かせる。レビュー役には、コードの好みではなく、テストが仕様を表しているか、既存機能を壊していないか、変更範囲が広がりすぎていないかを確認させる。これらを「スキル」として事前に身につけさせておく。こうすると、「前に進めること」と「壊さないこと」の矛盾を、命令の強さではなくプロセスで調整できる。
Codex や Claude Code が、直接実装を任されると慎重になり、監督役にすると急に前向きになるのを見ると、少し笑ってしまう。AIまで管理職しぐさをするのか、と思う。
だが、それは単なる笑い話ではない。そこには、組織の慣性があり、粘性があり、局所最適と全体最適の矛盾がある。
AIにコードを書かせているだけのつもりが、気づけば小さな組織を設計している。
これから重要になるのは、AIをどう使うかだけではない。AIたちが動く制度をどう設計するかである。
賢いAIを呼ぶだけでは、組織は動かない。
流れを作り、摩擦を読み、局所最適が全体最適を壊さないように調整する。それは、プロンプトエンジニアリングというより、AIエージェント時代の組織設計なのだと思う。
Michael T. Hannan and John Freeman, “Structural Inertia and Organizational Change,” American Sociological Review, 1984.
https://www.jstor.org/stable/2095567
PDF参考: https://www.iot.ntnu.no/innovation/norsi-pims-courses/harrison/Hannan%20%26%20Freeman%20%281984%29.PDF ↩David Krackhardt, “Organizational Viscosity and the Diffusion of Controversial Innovations,” The Journal of Mathematical Sociology, 1997.
https://www.tandfonline.com/doi/abs/10.1080/0022250X.1997.9990200 ↩
ここまでお読みいただき誠にありがとうございました。
このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。