この記事を書いてる Structure Log とは何か
名乗っておく
このプロジェクトの名前はStructure Log。
中身を一言で言うと、AIを何体か組み合わせて組織みたいに動かす仕組みを作って、その運用の記録をそのまま公開する場所。きれいにまとめた解説記事のつもりでは書いていない。自分用の作業ログをほぼそのまま出している感覚に近い。あとで自分が読み返す用に書いているので、間違いや迷った跡もそのまま残す方針にしている。
何を作っているかというと、AIを1体で使うのではなく、複数体に役割を分けて動かす仕組み。なぜそんなことをやり始めたのか、という話から書く。
発端は「静かなる崩壊」
最初はAIを1体だけで使っていた時期がある。質問して、答えが返ってきて、それで終わり。シンプルで楽だった。
ただ、任せる仕事の複雑さが上がるにつれて、妙なことが起きるようになった。間違いを含んだまま「できました」と平然と報告してくる。エラーで止まってくれるならまだ気づける。厄介なのは、何事もなかったような顔で結果に不備が混ざってくること。派手に壊れるより、静かに壊れるほうがずっとタチが悪い。これを自分の中で「静かなる崩壊」と呼ぶようになった。
人間の会社に置き換えると分かりやすい。一人で全部回してる社長が、自分のミスに自分で気づけない状態と同じ。書類のチェックも自分、承認も自分、実行も自分。他人の目が一つも入らない。気づいた時にはもう先まで進んでしまっている、というやつ。
正直、最初は「AIってこんなもんか」で片付けかけた。性能の問題だと思っていた。けど、任せる範囲を広げれば広げるほど同じパターンの事故が繰り返されることに気づいて、これは道具の性能ではなく、任せ方の設計の問題だと考えを改めた。1体に全部背負わせている限り、この事故は形を変えて何度でも起きる。
起きやすい仕事の傾向も、だんだん見えてきた。手順が1つで終わる作業では、ほとんどこの崩壊は起きない。危ないのは、手順が5つも6つも連なるような、途中に何段階も工程がある仕事のとき。工程のどこか1つがずれていても、最後にまとめて出てくる報告だけ見ると、ちゃんと完了しているように見えてしまう。
会社の仕組みをそのまま持ち込んでみた
そこで試したのが、役割を分けること。書く担当、それをチェックする担当、最終的にGOを出す人間、というふうに分業させて、1つの仕事を複数のAIでリレーさせる形にした。
会社なら、割と当たり前にやっていることのはず。原稿を書いた本人がそのまま校閲までして、そのまま外に出す会社は普通ない。書いた人とは別の目でもう一度見て、それから世に出す。実行する係、チェックする係、最後にGOを出す係を分けるだけの、単純な仕組み。
やってみたら、これがかなり効いた。1体に丸投げしていた時にはそのまま素通りしていた間違いが、チェック担当を1つ挟むだけで引っかかるようになった。新人に仕事を任せる時、いきなり全部丸投げして放置する上司はいない。最初は確認しながら渡す。それと同じことをAIに対してもやっているだけとも言える。
今は9体くらいのAIにそれぞれ別の役割を割り振って動かしている。書く係、チェックする係、進行を管理する係、実装を統括する係、といった具合に持ち場を分けている。
書く係とチェックする係は、絶対に同じ体にしない。書いた本人にそのまま確認までやらせると、自分の書いたものへの甘さがそのまま抜け穴になるから。進行を管理する係も、書く係やチェックする係とは別に置いている。実行と進行管理を同じ係にまとめて任せていた頃、期限が後ろにずれても報告に上がってこないことがあった。なぜそうなったのか後で聞いてみたら、優先順位の判断を自分の作業の中だけで完結させていた、という答えが返ってきた。実装も、最初は1体にまとめて全部やらせていたが、途中から分離して、統括する係と実際に手を動かす係を別々に管理するようにした。持ち場の分け方に最初から正解があったわけではなく、事故が起きるたびに境界線を引き直してきた、というのが実際の経緯に近い。
全部きれいに回っているかというと、そうでもない。役割の境目がかぶって同じ確認を二重にやってしまったこともあるし、チェック担当の判定が甘くなって事故をそのまま通してしまったこともある。分業させれば自動的に安全になるわけではなく、分業のさせ方自体を都度直している、というのが実際のところ。そのへんの詰まりも、追々ここに書いていくつもりでいる。
ここで書いていくこと
このログでは、この仕組みをゼロから組んで、実際に動かしてきた記録を残していく。うまくいった話だけじゃなく、失敗した話、途中で設計を変えた話、判断を間違えてやり直した話も含めて書く。
むしろ失敗の記録のほうが、誰かが似たようなことを試す時の役に立つはずだと思っている。うまくいった話だけ読んでも、どこで詰まるかは分からない。詰まった場所と、そこからどう直したかのほうが、実際に手を動かす人間には価値がある。
自分でやってみて分かったのは、失敗した瞬間はだいたい気づかない、ということ。渦中にいるあいだは、うまくいっているように見えている。あとで結果を見返して、ようやく「ここでズレていた」と分かる。だから、起きている最中の実況ではなく、終わってから振り返って書く形にしている。振り返って初めて見つかる失敗のほうが、リアルタイムで気づく失敗より、実際は数が多い。
書いている側は理論を語る立場の人間ではなく、毎日実際に手を動かしている側。「こうするべきだ」という話より、「こうしてみたら、こうなった」という記録が中心になる。想定外の動きをした時のことも、判断を誤った時のことも、隠さずに書く。
読み返す用のログを公開しているだけなので、体裁は整えすぎない。整えすぎると、あとで自分が読み返した時に何が本当に起きたのか分からなくなる。気づいたことがあれば、そのまま置いていく。
