以前、コードは最後でいい — 1人とAIで会社を回す進め方という記事を書きました。代表ほぼ1人と複数のAIエージェントで会社を回している、その体制の話です。今日はその実践編として、実際の開発で私たちが守っている「任せ方の型」を書いておきたいと思います。
前回は、何をやるかを決めるのは人間で、作るのは最後でいい、という運営の輪郭の話でした。今日はもう一段だけ手前に降りて、では実際にAIに手を動かしてもらうとき、どこまで任せて、どこは任せないのか。その線をどう引いているか、という話です。
AIは速くて賢い。けれど、何でも丸ごと預けると、ある日きれいに壊れます。私たちはその壊れ方を何度か見てきました。これから書くのは、その痛い目と引き換えに手元に残った、いくつかの型です。抽象的な心得というより、毎回守っている具体的な作法のつもりで書きます。
作る係と、点検する係を分ける
最初の型は、作る役と評価する役を、別のAIにすることです。
人は、自分で書いたものを自分で正しいと言いがちです。書いた直後ほど、その判断は甘くなる。これはAIでもまったく同じでした。コードを書かせたAIに「これで合っているか確認して」と続けて頼むと、たいてい「問題ありません」と返ってきます。自分の作ったものを、自分の目で公平に裁くのは、誰にとっても難しいのです。
だから私たちは、作ったAIとは別のAIに、改めて点検させます。作る係は作ることに集中し、点検係はあら探しに徹する。同じ一つのAIに「作って、ついでに自分で評価して」と同時に頼むことは、原則しません。生成と評価を、はっきり別の手に分ける。
地味な分担ですが、これが成果物の信頼性をいちばん下から支えています。速く作れることより、出てきたものを信じられること。結局そこが効いてくるからです。
決まった手順は、AIに毎回ゆだねない
二つ目は、手前から言うと一度きれいに壊れて学んだ型です。
私たちは自社のメタバースの中に、話しかけられるAIの店員を置きました（その顛末はメタバースの店に、話せる店員を置いたに書きました）。作っている途中、会話の「次にどの段階へ進むか」という判断を、毎ターンAIに決めさせていた時期があります。賢いものに任せれば自然に進んでくれるだろう、という素朴な期待からでした。
ところが、これが安定しませんでした。AIの判断は毎回わずかにぶれます。気分をもう聞き終えているのに、また同じことを尋ねる。同じ問いを繰り返し、いつまでも先へ進まない。会話がその場でぐるぐると回り続ける、無限ループのような状態に陥ったのです。
ここで引けた線が、私たちの中ではかなり大きなものになりました。決まった形があるべきもの——手順、段取り、状態の管理——をAIに毎回ゆだねると、判断がぶれて壊れる。だから定型の流れはコードでかっちり固める。そのうえで、おすすめの理由やその場をやわらげる一言といった、人間味のある「言葉」の部分だけをAIに書かせる。
「決まった手順」と「人の心に触れる言葉」を切り分ける。段取りは演出家であるコードが握り、AIは与えられた場面で生きたセリフを吹き込む役者に徹する。そう分けた途端、あれほどぐらついていた会話がぴたりと安定しました。この線引きは、ほかの開発でもずっと効いてきます。
レビューは、一往復で終わらせない
三つ目は、点検の回し方です。
作る係と点検係を分ける、と書きました。けれど、一度点検して指摘をもらい、それを直して、はい完成、では足りません。直したものには、たいてい直した分の新しいほころびが残っているからです。
だから私たちは、AIにコードを書かせたら、別のAIに査読させ、出た指摘を反映し、また同じ査読役に投げ直します。これを、指摘が出なくなるまで繰り返す。一往復で切り上げず、何往復でも、静かになるまで回す。それからようやく本番に出します。
手間に見えますが、この往復は省くと必ずどこかで跳ね返ってきます。速く出して後で火を噴くより、出す前に静かになるまで回しておくほうが、結局は安くつく。レビューは儀式ではなく、収束するまで続ける反復だ、と考えています。
思い込みより、観測を信じる
四つ目は、外の世界とつなぐときの構えです。
開発では、自分たちの外にあるサービス——他社のAPIや基盤——と組み合わせる場面が必ず出てきます。そういうとき、つい仕様書に書いてある説明を信じて作ってしまいがちです。けれど、書いてある通りに動かないことは、驚くほどよくあります。
そこで私たちは、仕様書の記述より、実際に返ってきた生のデータを一次根拠にすることにしています。ドキュメントにこう書いてある、ではなく、叩いてみたら実際にこう返ってきた、を信じる。思い込みで作ったものは、思い込みの分だけずれるからです。
そのために、作る順番も変えました。まず、エラーが起きたときにその中身をそのまま記録できるように作っておく。何かおかしいとき、推測で原因を語る前に、生のレスポンスやエラーの中身を見にいけるようにしておくのです。これはAIに任せる任せない以前の、開発そのものの作法ですが、AIと組むとなおさら効きます。AIもまた、もっともらしい推測を自信たっぷりに語るからです。手元に観測した事実があれば、その推測を地に足のついたところへ引き戻せます。
会社の形そのものが、線引きでできている
五つ目は、型というより、ここまでの型がそのまま形になったものの話です。
私たちは一人の会社を、役割を分けたAIエージェントのチームで回しています。全体を見て依頼を分析し、どの担当に何を任せるかを決める司令塔。その下に、戦略、空間設計、技術実装、営業、品質といった専門の担当。何でも一つのAIにまとめて頼むのではなく、人間の組織図をそのままなぞるように、役割で切り分けています。
これは前回も書いたことですが、実践編として言い直すと、この会社の形そのものが、ここまでの線引きの集大成になっています。作る係と点検する係を分けるのも、手順をコードに、言葉をAIに振り分けるのも、すべて「どこを誰に握らせるか」という同じ問いの、別の現れ方です。
そして、その全部の真ん中に人間が残ります。人間がやることは二つだけ。何をやるかを判断すること。そして、最後の責任を引き受けること。AIをいくら増やしても、この二つは誰にも渡せません。むしろAIが増えるほど、人間の仕事はこの二点に純化していきます。
線引きの知恵こそが、資産
ここまで書いてきた型は、どれも最初から分かっていたわけではありません。
毎ターン手順を任せて無限ループにはまり、自分で書いたものを自分で正しいと言わせて甘い成果物を掴み、仕様書を信じて実際の挙動に裏切られる。そういう小さな失敗のたびに、ここはAIに任せていい、ここはコードや人間が握らないと壊れる、という線を一本ずつ引き直してきました。痛い目を見ながら引いてきた線なのです。
AIは強力です。けれど、何でも丸投げすると壊れる。賢い道具ほど、任せどころを間違えると壊れ方も派手になります。だからこそ、「任せるところ」と「人やコードが握るところ」の線を、どこに引くか。その線引きの知恵こそが、私たちにとっていちばんの資産だと思っています。
道具が速く賢くなっても、線をどこに引くかを決めるのは、結局のところ人間です。ツールは入れ替わっていくでしょう。けれど、この線引きの感覚は残り続ける。その地味な型の記録として、これを残しておきます。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。