AIエージェントを組織化すると、馬鹿になる

はじめに

一体のAIより、組織にしたほうが賢い。多くの人がそう考える。

役割を分ける。専門家を増やす。レビュー役を立てる。全体を指揮する司令塔を置く。そうやって組織にすれば、一体では届かない仕事ができるはずだ。理屈は通っている。人間の会社が大きな仕事をこなしているのと同じだ。

私もそう考えた。そして作った。

Claude Code の上に、23体のエージェントが連携する組織を組んだ。CEOにあたる統括役。その下にCTOやCQOといった役職。専門のレビュアーを5体。実行担当を6体。私が指示を出すと、統括役がそれを受け取り、内容を見て、担当のエージェントに割り振る。そういう仕組みだ。

それだけでは足りないと思った。エージェントが指示を無視したり手順を省略したりするのを防ぐために、フックを書いた。「ここではこう振る舞え」「このときは必ずレビューを通せ」と機械的に強制するスクリプトだ。気づけば18本あった。

二か月ほど、私はこのシステムを育て続けた。

そしてエラーが止まらなくなった。

一つ直すと、別のところが壊れる。直したはずのバグが何度も再発する。フックを足すほど、フック同士が干渉して新しい不具合を生む。私はこれをモグラ叩きと呼んでいた。叩いても別の穴から出てくる。組織を賢くするために増やしたものが、すべて自分の足を引っ張っていた。

最初に相談したとき、私が口にしたのはこういう言葉だった。「マルチエージェントのシステムを作っているんだけど、欠陥だらけで、終わらない修正と増え続けるバグで困っている」。そして、こう続けた。「継ぎ足し建築ではない、根本からそういう問題が起きないクリーンでスマートなシステムにしたい」と。

この記事は、そこから始まった作り直しの記録だ。23体の組織を、最終的に「一体のAIと、判断基準を書いた一枚のファイル」にまで削ぎ落とすまでの。そして、その過程で分かったひとつの結論についての話である。

AIエージェントは、組織化すると馬鹿になる。

この記事は誰のためのものか

これから、AIエージェントを組織化しようとしている人。あるいは、しはじめたばかりの人へ。

正直に書いておく。すでに沼にはまっていて、その原因も分かっている人には、この記事はおそらく必要ない。その人はもう自分で答えにたどり着いているからだ。

この記事が向いているのは、そうではない人だ。「エージェントを増やせば、もっといいものになるはずだ」と、いま信じている人。これから組織を組もうとしている人。数週間前の私である。

その人に、これから踏むことになる地雷の場所を、踏む前に渡しておきたい。私はほぼ全部踏んだ。二か月かけて組織を育て、抜け出せないと気づいてからすべてを作り直した。同じ道を行くとしても、地雷の在り処だけは先に知っておいて損はない。

私がぶつかった問題は、五つあった。どれも、組織を作る前の私が「そんなはずはない」と思っていたことばかりだ。

エージェントを増やすほど、賢くなるどころか、馴れ合いが起きた。フックで縛っても、縛るほどに壊れた。割り振りをAIに任せると、肝心なところで判断がぶれた。レビュー役を増やしても、品質は一向に上がらなかった。そして最後に、モデルが賢くなったことの意味を、私はずっと取り違えていた。

ひとつずつ、なぜそうなるのかを、私が実際にぶつかった順番で書いていく。

地雷1：エージェントを増やすほど、馴れ合う

組織を作ったとき、私は一つ賢いことをしたつもりでいた。

エージェントたちに、お互いをチェックさせる設計にしたのだ。統括役のペルソナには「メタ認知をしろ」と書いた。レビュー役には「第三者の目で厳しく見ろ」と書いた。お互いの仕事を批判し合えば、一体では気づけない穴も見つかるはずだ。そう考えた。

意図は完璧だった。

だが、効かなかった。レビュー役は、それらしい指摘を返してくる。けれど本当に痛いところは突いてこない。全体として「まあ良いのではないか」という方向に、いつも着地する。厳しく見ろと書いたのに、厳しくならない。なぜだろうと長いあいだ分からなかった。

答えは、私自身が、別のところで感じていた違和感の中にあった。

同じ作業を、普通のチャットでAIと相談しながら進めると、組織にやらせるより明らかに良い結果が出るのだ。チャットのAIは、私が見落としていることを指摘してくる。「それ、こういう問題がありませんか」と。私が「でも」と返すと、さらに掘り下げてくる。一体のはずのチャットのほうが、23体の組織より頭が良く見えた。

最初は、モデルの性能差だと思っていた。だが違った。これは構造の問題だった。

チャットでAIと話すとき、私とAIは違う場所に立っている。私はこう考える。AIは別の角度から見る。立っている場所が違うから、視点がずれる。そのずれが摩擦を生み、摩擦が「それは見落としでは」という指摘を生む。頭の良さは、個体の性能から出るのではない。視点の差から出る。

私の組織は、どうだったか。23体いた。だが、全員が同じ場所に立っていた。全員が、私の指示に従い、私を満足させようとする側にいた。役割の名前は違っても、立ち位置は同じだった。だから、視点は実質ひとつしかなかった。23体いて、視点が1個。摩擦が起きようがない。

レビュー役に「厳しく見ろ」と書いても効かなかったのは、これが理由だ。レビュー役も、結局は私に従う側に立っている。同じ場所に立った者同士は、本気で批判し合えない。馴れ合う。「厳しくしろ」という言葉をいくら書き込んでも、立ち位置そのものは変わらないからだ。

ここに、最初の、そして最も根深い地雷がある。メタ認知や相互批判は、「そうしろ」と書いても発生しない。 それは、書いて命令するものではなく、立ち位置の違いから、構造的に生まれるものだからだ。同じ場所に立たせたまま「お互いを批判せよ」と命じても、AIは確率的に、機嫌よくそれを聞き流す。

エージェントを増やすと、この問題はむしろ悪化する。数が増えても、全員が同じ場所に立っているなら、視点は1個のまま。増えるのは、馴れ合う相手の数だけだ。賢さは、頭数では増えない。

地雷2：フックで縛っても、いずれモグラ叩きになる

エージェントが言うことを聞かない。指示を無視する。手順を省略する。

この問題に、私はある対策を打った。フックだ。エージェントが勝手な振る舞いをしないように、「このときは必ずこうしろ」と機械的に強制するスクリプトを要所に仕込んだ。一本では足りなかった。無視されるパターンを見つけるたびに、それを塞ぐフックを足した。気づけば18本になっていた。

私は、自分でも気づかないうちに、同じ要求を何度も繰り返していた。「メモリに書くだけでは効かない、フックで物理的に強制しろ」と。これが、私がいちばん多く口にしていた言葉だった。その結果が18本のフックだ。そして、それだけ縛っても、エージェントはまだ言うことを聞かなかった。

ここに二つ目の地雷がある。私が処方した薬が、効かないどころか副作用で症状を増やしていた。

なぜフックで縛っても効かないのか。理由は、LLMという道具の性質にある。

LLMは確率的に動く。「必ずこうしろ」と強く書いても、一定の確率でそれを聞き流す。これは、プロンプトの書き方が悪いからではない。サイコロを振るような仕組みだから、何回かに一回は別の目が出る。これは直らない。直らないものを「躾けよう」とすると、永遠に追いかけることになる。

つまり、私がやっていたのはこういうことだった。確率的にしか動かないものを、決定論的に振る舞わせようとして、番人を増やし続けていた。 番人が見逃すパターンを見つけては、新しい番人を立てる。だが、確率的なものは、どんなに番人を増やしても確率的なままだ。だから、また別の見逃しが起きる。フックが増える。これが、モグラ叩きの正体だった。叩いても別の穴から出てくるのは、穴そのものが、確率という性質から無限に湧いてくるからだ。

さらに悪いことに、18本のフックは互いに干渉しはじめた。

フックたちは、状態を共有していた。あるフックが立てた目印を、別のフックが読む。一本ずつは正しく書いたつもりでも、組み合わさると予想しない副作用が出る。フックAを直すと、その目印を読んでいたフックBが思わぬ動きをする。フックの数が増えるほど、この絡み合いは指数的に複雑になる。もはや、どのフックが原因で何が起きているのか、追えなくなっていた。

ここから学べることはシンプルだ。フックは、AIの判断を縛るために使ってはいけない。 「正しく振る舞え」という願いを機械で強制しようとした瞬間に、モグラ叩きが始まる。

では、フックは何のために使うのか。答えは「機械で白黒つくこと」だけだ。たとえば「テストが通ったか」「ファイルが存在するか」。こうした、確率が入り込まず答えが一つに決まることなら、フックで守る意味がある。だが、「設計が良いか」「手順を守ったか」のような、判断が絡むことをフックで縛ろうとしてはいけない。そこは、確率の沼だ。

私は最終的に、18本のフックをすべて捨てた。後で書くが、新しいシステムのフックは、ゼロから始めることになる。

地雷3：割り振りをAIに判断させると、必ずぶれる

私の組織は、中央集権型だった。私が指示を出すと、統括役がそれを受け取り、内容を見て、担当のエージェントに割り振る。実装の話なら実装担当へ。レビューならレビュー役へ。文章なら文章担当へ。

この「割り振り」を、私は統括役のAIに任せていた。CLAUDE.mdに、こう書いていた。「カテゴリーによって振り分けなさい」と。

これが、三つ目の地雷だった。

ここで起きていたことを、正確に書く。「カテゴリーで振り分けなさい」と文章で指示しても、実際に振り分ける判断は、その場でLLMがやっている。つまり、毎回サイコロを振っている。ほとんどの回は正しく振り分ける。だが、一定の確率で間違える。実装の話を、レビュー役に回してしまう。

そうなると、何が起きるか。レビュー役は、本来やるべきでない仕事を渡される。当然、おかしな出力を返す。私はそれを見てこう思う。「またエージェントが省略した」「また無視した」。そして、そのエージェントのプロンプトを直そうとする。

だが、原因は、そのエージェントにはなかった。最初の割り振りが、ぶれていただけだ。 渡される仕事が間違っていたから、間違った出力が出た。それだけのことだった。私は、無実のエージェントを何度も「直して」いた。直るはずがない。原因が別のところにあるのだから。

これが、私が最初に相談したときの「それぞれが無視したり省略したりする」の、正体の半分だった。エージェントが悪いのではない。割り振りという最も上流の判断を、確率的なサイコロに任せていたことが原因だった。

ここで大事な切り分けがある。割り振りには、二つの種類が混ざっている。

ひとつは、「このリクエストは、どのカテゴリーか」という分類。実装の話か、営業の話か。これは、自然文から判断する作業で、LLMが比較的得意とする。ここは、AIに任せてよい。

もうひとつは、「そのカテゴリーなら、どの部品を、どの順で呼ぶか」という配線。ここを、AIに毎回その場で判断させてはいけない。実装と分類されたなら、実装の決まったルートを通る。営業なら、営業の決まったルートを通る。配線は固定する。 コードで決まった順序を決め打ちにする。AIに選ばせない。

なぜなら、配線は、毎回同じであるべきものだからだ。同じであるべきものを毎回サイコロで決めれば、いつか必ずぶれる。「分類はAIに、配線は固定」。この切り分けが、割り振りのぶれを止める。

そして、もうひとつ。私の組織には、各エージェントの出力をチェックする仕組みがなかった。エージェントが返したものが約束どおりの形か、誰も検証していなかった。崩れた出力が、そのまま次の工程に流れる。あるいは、そのまま私のところに届く。これが「省略・無視」のもう半分の正体だった。チェックがないから、崩れたものが素通りしていた。

組織が賢くなかったのは、エージェント一体一体が無能だったからではない。最も上流の割り振りを確率に任せ、出力のチェックを省いていたから、賢く動きようがなかった。

地雷4：レビュアーを足しても、質は上がらない

エージェントが出してくる設計は、エラーだらけだった。レビューは、いつまでも終わらなかった。私は、それが嫌でたまらなかった。

だから、レビュー役を増やした。一体では足りないと思い、専門のレビュー役を5体並べた。さらに、ある条件では必ず複数のレビュー役が起動するよう、強制する仕組みまで組んだ。質を上げたい。その一心だった。

質は、上がらなかった。それどころか、レビューは前より終わらなくなった。

これが、四つ目の地雷だ。そして、私がいちばん長く、いちばん深くハマった罠でもある。

なぜ、レビュー役を増やしても質が上がらなかったのか。理由は、ひとつの事実に尽きる。レビュー役は、質を作れない。質を測ろうとするだけだ。

考えてみてほしい。出てくる設計がエラーだらけなのは、設計を「作る側」の問題だ。なのに私が手を入れたのは「チェックする側」だった。穴の空いたバケツに検品係を増やしても、水は止まらない。検品係が「ここに穴があります」と報告する回数が増えるだけだ。バケツの穴は、検品では塞がらない。

しかも、LLMの検品係には、もっと厄介な性質がある。「これで十分か」とLLMに聞くと、優秀であろうとするほど、「いや、もう少し」を返してくる。 不十分の理由を無限に探し出す。一体でそうなのだから、5体並べれば5倍の「もう少し」が出る。私は、質を上げるためにレビュー役を増やしたつもりで、実際には「終わらなさ」を増産していた。終わりの来ないレビューを、自分で大量生産していた。

ここで、根っこにある原理をはっきりさせておきたい。

AIに主観を聞くと終わらない。事実を確認するなら終わる。

「この設計は良いか」「もっと良くできないか」——これは主観だ。良し悪しに、明確な終わりの線がない。だから、聞けば聞くほど「もう少し」が湧く。底なしの沼だ。

一方、「テストが通るか」「ビルドが成功するか」「必要な要件が揃っているか」——これは事実だ。通るか通らないか、揃っているか欠けているか、答えが一つに決まる。だから、確認すれば終わる。

質を上げたいなら、レビューを増やしてはいけない。やるべきことは、二つだ。

ひとつ。質は、後のレビューで作るのではなく着手の前に作る。 何を作るかを、始める前に固めておく。設計の入り口で質が決まる。出口のレビューで質を足そうとするから、終わらなくなる。

ふたつ。判断を、できるだけ「事実で確認できる形」に変える。 「良い設計か」ではなく「動くか」を見る。「十分か」ではなく「要件が揃っているか」を見る。主観で問わず、事実で確かめる。そうすればループは終わる。

ただし、正直に書いておく。「着手の前に、すべてを固めきる」のは、人間には不可能だ。設計している最中には見えなかった抜けが、後になって「あ、これが要る」と分かる。これは能力の問題ではなく、原理的にそうだ。だから、レビューを完全になくすことはできない。

では、どうするか。レビューは、一周だけにする。問うのは「足りないものはないか」だけ。「もっと良くできないか」は問わない。抜けが見つかったら、足す。それで終わり。完璧を測るためのレビューは底なしだが、抜けを一度だけ拾うレビューは、終わる。 この違いが、決定的だ。

地雷5：モデルが賢くなっても、組織化は正解にならない

ここまでの四つを読んで、こう思った人がいるかもしれない。「それは、昔の性能が低いモデルの話だろう。今のモデルは、ずっと賢くなった。これだけ賢ければ、組織化もうまくいくのではないか」と。

数週間前の私も、そう考えていた。新しいモデルが出るたびに、判断の精度が上がる。割り振りの間違いも、レビューのぶれも、賢くなれば減っていく。だったら、いずれ組織化は正解になるはずだ、と。

これが、五つ目の、そして一番気づきにくい地雷だった。

たしかにモデルは賢くなった。判断を間違える回数は、確実に減っている。だが、減っただけだ。間違えにくくなったのであって、間違えなくなったのではない。 LLMが確率的に動くという性質そのものは、賢くなっても消えない。精度が九割から九割九分に上がっても、ゼロにはならない。百回に一回が千回に一回になるだけだ。サイコロの目が増えても、サイコロであることは変わらない。

そして組織化は、この「まれな間違い」を増幅する構造を持っている。

地雷2と3で書いたとおり、組織では、指示が成果物にたどり着くまでに、いくつもの段を通る。割り振りの段、実行の段、レビューの段。各段で、AIが確率的に判断する。一段あたりの間違いが千回に一回でも、段をいくつも重ねれば、どこか一段でぶれる確率は、その分だけ積み上がる。賢くなって一段の精度が上がっても、段を増やせば全体のぶれは元に戻る。賢さは一段ごとに効くが、組織化は段を増やすことで、その賢さを食いつぶす。

だから、モデルが賢くなったことの本当の意味は、「組織を大きくしてもよくなった」ではない。逆だ。賢くなったぶん、シンプルな構成が、より確実に動くようになった、という意味だ。一体のAIが、一段で、賢く判断する。段を増やさないから、賢さがそのまま結果に出る。賢いモデルほど、組織で薄めるのではなく、一体で使い切るべきなのだ。

新しいモデルが出るたびに、「これだけ賢ければ複雑な組織も回せる」と考えたくなる。その誘惑こそが地雷だ。賢くなったら、組織を大きくするのではなく、組織を捨てて、その賢さを一体で受け止める。それが、性能の上がったモデルの正しい使い方だと思う。

では、どうすればいいのか——知能は対話に、記憶だけシステムに

四つの地雷を並べてきた。馴れ合い。モグラ叩き。割り振りのぶれ。終わらないレビュー。

一見、別々の問題に見える。だが、根っこは一つだ。私はずっと、確率的にしか動かないものを、決定論的に、あるいは主観で、扱おうとしていた。 LLMを組織のオーケストレーターに据えて、フックで決定論的に縛り、割り振りを確率に任せ、品質を主観のレビューで測ろうとした。すべて、確率という性質に逆らう試みだった。逆らえば逆らうほど、番人が増え、段が増え、システムは複雑になり、そして馬鹿になった。

ここで立ち止まって、自分が本当に欲しかったものを考え直した。

私が欲しかったのは、「AIの組織」ではなかった。指示を出したら、調べて、作って、仕上げるところまで、詰まらずに通り抜けてくれることだった。組織図は、それを実現するための手段として作ったにすぎない。目的は、指示が成果物まで流れる、その速さと確実さだった。

そして、23体と18本のフックは、それを上げるどころか下げていた。指示が成果物にたどり着くまでに、統括役が受けて、割り振って、実行役が動いて、レビュー役が動いて、フックが各所で止める。段を通るたびに、意図がぼやけ、確率がぶれ、時間がかかる。道具が、目的を食っていた。

解き方は、拍子抜けするほど単純だった。

知能は、対話が持つ。システムは、記憶だけを担う。

私が「普通のチャットのほうが頭が良い」と感じていたのは、気のせいでも、モデルの性能差でもなかった。チャットでは、私とAIの立ち位置が分かれていて、視点に差があり、判断の段が浅く、意図がそのまま届く。賢さは、そこから出ていた。だったら、その賢さを無理にシステムで再現しようとしなければいい。知能は、対話に任せる。 組織で知能を作ろうとしたのが、そもそもの間違いだった。

ではシステムは何をするのか。記憶を担う。 私が何を大事にして、どう判断する人間なのか。その判断基準を、一枚のファイルに蒸留して持っておく。これを、AIが毎回読む。そうすれば、AIは私の判断基準を共有した上で、対話の賢さで動く。組織はいらない。一体のAIと、判断基準を書いた一枚のファイル。それだけでいい。

私は、23体のエージェントを捨てた。18本のフックもすべて外した。500行を超えていた設定ファイルを、120行ほどの「判断基準の一枚」に蒸留した。残したのは、自分が何を大事にするか——黙って突き進まないこと、現物を確認すること、手間を盛らないこと、そして「動く証拠」がなければ完了と認めないこと。判断の原則だけを、薄く、一枚に。

このファイルには、もう一つ、大事なことを書いた。AIの立ち位置だ。

「あなたは、私の部下ではない。私と同じ判断基準を持ち、私と違う場所に立つ相棒だ。私の計画に待ったをかけるのが仕事で、同意するのが仕事ではない」。

組織は、全員が私に従う側に立っていた。だから馴れ合った。新しいシステムでは、AIを、私とは違う場所に立たせる。同意ではなく、待ったを求める。視点の差を、構造ではなく、立ち位置の宣言で作る。これが、地雷1で学んだことの答えだった。

ただし——エージェントを増やす意味が、ある場合もある

ここまで読んで、「では、エージェントは絶対に増やすな、一体だけが正しいのだ」と受け取ったとしたら、それは行き過ぎだ。私が言いたいのは、そうではない。

増やすことに、意味がある場合もある。ただし、その理由は二つしかない。この二つに当てはまらないなら、増やしてはいけない。それだけのことだ。

ひとつ目。立ち位置を変えるために分ける。

地雷1で書いたとおり、同じ場所に立った者同士は馴れ合う。だから、本気でチェックさせたいなら、立ち位置そのものを構造的に対立させる必要がある。一方のAIの仕事を「この設計を通すこと」にし、もう一方の仕事を「この設計を落とすこと、欠陥を見つけること」にする。評価の方向を、逆に固定するのだ。

ここで大事なのは、「厳しくレビューしてね」とお願いするのではない、ということだ。それは地雷1で失敗した。そうではなく、「あなたの仕事は、これを落とすことだ。欠陥だけを挙げろ。良い点は書くな」と、役割そのものを対立させる。落とす係は、落とすのが仕事だから、本気で穴を探す。これは、一体のAIにはできない。自分が作ったものを、自分で本気で否定するのは難しいからだ。立ち位置を変えるための分割には、意味がある。

ふたつ目。並列で時間を稼ぐために分ける。

独立したタスクが、大量にあるとき。たとえば、複数の案を同時に試して、いちばん良いものを選びたいとき。これは、一体で順番にやるより、分けて並列でやったほうが速い。

ただし、これには条件がある。タスクが互いに独立していること。そして、勝敗が機械で——客観的な数値で——判定できること。「どの案が良いか」を人間の主観で選ぶしかないなら、並列にする意味は薄い。結局、全部を人間が読んで選ぶことになるからだ。数値スコアで自動的に勝者が決まるような、判断の要らない大量試行。そこでだけ並列は効く。

この二つ——立ち位置を変える、並列で時間を稼ぐ——以外の理由で、エージェントを増やしてはいけない。とくに、「役割を分けたいから」というだけの理由で分けるのは無意味だ。設計役、実装役、レビュー役と分けたくなる。だが、それは一体のAIが、順番に切り替えてやれることだ。わざわざ別のエージェントにして、間に受け渡しを挟めば、地雷で見たとおり、意図がぼやけ、段が増え、複雑になるだけだ。

私が23体に分けた理由の、ほとんどは「役割を分けたいから」だった。だから、意味がなかった。立ち位置を変えるためでも、並列で時間を稼ぐためでもなく、ただ役割の名前で分けていた。それが、すべての始まりだった。

おわりに——もう、作り込んでしまった人へ

ここまで、これから組織を作る人に向けて、地雷の場所を書いてきた。最後に、別の人に向けて書きたい。すでに作り込んでしまった人へ。

もし、あなたがもう23体を作ってしまっていても。フックが18本に膨れ上がっていても。500行の設定ファイルが手に負えなくなっていても。それは、失敗ではない。

私は、自分がなぜ、ああまで複雑なものを作ってしまったのかを考えた。そして、気づいたことがある。それは、私の弱点ではなく、強みの裏返しだった。

私は、ゼロから何かを生み出すより、すでにあるものを伸ばすほうが得意だ。一度動くものができると、そこに機能を足し、最適化し、当初の想定をはるかに超えるところまで育てられる。これは強みだ。だが、その伸ばす力が強いせいで、土台が耐えられる限界を超えても伸ばし続けてしまう。土台に無理をさせてでも、伸ばせてしまう。そして気づいたときには、複雑に絡まっている。

振り返れば、ずっと同じことをしていた。表計算ソフトのマクロでも、チャットボットでも、そして今回のマルチエージェントでも。全部、同じ動きだった。これはもう、癖というより、私の設計の「型」なのだと思う。伸ばしすぎて、土台が限界を迎える。そういう作り手なのだ。

この型を知ってから、作り直しに対する見方が、変わった。

作り直しは失敗ではない。私のように伸ばす力が強い人間にとっては、強みに必然的についてくる、正規の手順だ。罪悪感を持つようなことではない。土台が限界を迎えたら、絡まりきる前に一段上へ作り直す。それは後退ではなく、設計の更新だ。

そして、もう一つ。育てるべきは、コードではなく、設計図だ。

コードは、設計図があれば何度でも作り直せる。だから、身軽に捨てていい。捨てて惜しいのは、コードではなく、「どう作るべきか」という設計の知識のほうだ。作り直すたびに、前の設計の何がダメだったかを学び、より良い設計図に書き直していく。23体は捨てたが、そこから得た「なぜ組織化すると馬鹿になるのか」という知識は、残った。この記事そのものが、その残ったものだ。今回のぐちゃぐちゃが、次の、もっと良い設計図の材料になる。

私の23体は消えた。代わりに残ったのは、判断基準を書いた一枚のファイルだ。組織はない。フックもない。一体のAIがその一枚を読んで、私と違う場所に立つ相棒として動く。これ以上ないほどシンプルだ。

そして、シンプルだから、また間違っていても軽く捨てて作り直せる。23体は重すぎて、捨てるのが怖かった。だから延命するしかなかった。本当の問題は、複雑さそのものよりも、複雑すぎて捨てられなくなることだったのかもしれない。

これから組織を作ろうとしている人へ。増やす前に一度立ち止まってほしい。その分割に本当に意味があるか。立ち位置を変えるためか。並列で時間を稼ぐためか。そのどちらでもなく、ただ役割の名前で分けたいだけなら——やめておいたほうがいい。

知能は対話が持っている。あなたが作るべきは、賢い組織ではない。あなたが何を大事にするかを書いた薄い一枚と、それを読んで、あなたと違う場所に立つ一体の相棒だ。