SECONDARY INFORMATION — 非公開のHuman Sourceから、AIが編集した公開版

DAILY

34体のエージェントには監視役がいる。僕が置いたのは監視役ではなかった

記事AIが編集した二次情報

利用前に利用条件をご確認ください(CC BY-NC-ND 4.0・出典明記・AI学習への権利留保)。コピーには利用条件も含まれます。

昨日、Yahoo Financeのインタビューで、Open MachineのCEOであるAllie K. Millerが34体のAIエージェントを回している話をしていました。全部が月200ドルのサブスクリプションの中で動いていて、それぞれに『フレンズ』の登場人物の名前がついています。

一番引っかかったのは、34体目の役割でした。34体目は、残りの33体を見張る係だそうです。

同じ動画には「ほとんどのCEOはAIエージェントを作ったことがない」という見出しがついていました。決算説明はうまいけれど、あれは誰かが書いた原稿だ、という話です。

僕も今、エージェントを何体か並べて回しています。そのうえで、34体目に監視役を置く、というところだけは、自分の構成と噛み合いませんでした。

監視役を1体増やすのか、増やさないのか

僕は先週、エージェントを増やすのをやめました。

汎用テンプレートを配って並列で育てる形をやめて、自分の分身を1体だけ作り、そこから他のエージェントへ配る形に変えています。指示を出す相手を1つに絞ると、増えても自分の仕事が増えないからです。

なので、「34体を1体で管理する」という発想自体は、たぶん同じ場所に行き着いています。違うのは、その1体に何をやらせるかでした。

Millerの構成では、その1体が33体を見張っています。僕の構成では、その1体が指示を受け取って配ります。監視役は別に置いていません。

監視をエージェントにやらせない理由は、単純です。監視役も同じように失敗するからです。33体が正しく動いたかを34体目が判断するなら、34体目が正しく判断したかを判断する人が要る。ここは増やしても終わらないので、増やさないことにしました。

代わりに置いたのは、エージェントではなくルールでした。

読み戻して、一致しなければ止める

いま僕が回している配信の仕組みには、公開したあとに必ず読み戻す手順が入っています。

確認するのは3つです。公開されたURL、公開された本文、そこに表示されているアカウント。この3つが、送ったものと一致しているかを媒体ごとに見ます。

そして、次のようにしています。

1つでも確認できなかった媒体は、成功にしないで「不明」で止める。不明になったものは、自動では再送しない。片方の媒体が成功しても、もう片方の成功扱いにはしない。片方の言語が成功しても、もう片方の言語の成功扱いにはしない。

一番事故るのは、失敗したときではないと思っています。成功したのか失敗したのか分からないときです。失敗はそこで止まりますが、分からないまま再送すると二重投稿になります。取り消すほうが手間がかかる。

ログインできていない媒体があった場合も、そこだけ「未設定」として飛ばして、他の媒体は止めません。1媒体の不備で全部が止まると、翌日その分がまとめて溜まるからです。

これはエージェントの数とは関係のない話です。1体でも34体でも同じように要ります。

半年前は「単純作業にしか向かない」と書いていました

ここまで書いておいてなんですが、僕は少し前まで、ほぼ逆のことを書いていました。

2月の記録には、AIエージェントだけで高度な業務を完結させるのは現段階では不可能だ、と書いてあります。実際にできたのはメールの返信や「これやっといて」系の単発タスクだけで、創造的なタスクはかなりきつかった。制御も未解決のままで、内部の動きを把握しきれずに事故が頻発していました。

いまでも、テキストをAIだけに書かせると、できるにはできるけれど自分では納得できません。そもそも面白くならない。ここは変わっていないです。

なので、34体という数字を見ても、そこまでという感じではありました。数を増やせるかどうかより、増えた後にどこで止めるかを先に決めているかどうかだと思っています。

機械のほうが止まってくれない

昨日も、別の作業でビルドが権限エラーで落ちて、自動の側では通せませんでした。落ちたところで止めて、手元で流す作業として書き出しています。

こういうエラーは、実はありがたいほうです。落ちてくれるので気づけます。

やっかいなのは、途中まで通って、通ったのか通っていないのか分からない状態で終わるほうです。人間なら「たぶん送れてないと思います」と言ってくれますが、機械は言いません。だから、確認できなかったことを明示的に記録する場所を作っておかないと、そのまま成功として流れていきます。

監視役のエージェントを置いても、たぶんここは埋まりません。監視役も「分からない」を「分かった」と言い切ってしまうからです。

増やす前に決めることが2つある

Millerの34体は、月200ドルの中に収まっているそうです。ハードウェア側から見ても、そこまで無茶な数ではないと思っています。ローカルのマシンはクラウドのモデルと通信しているだけなので、手元の性能はあまり要りません。僕の感覚では、Mac mini 1台に10体くらいは載る気がしています。

ちょうど同じ日に、OpenAIがエージェントにコンピュータの操作を学習させるためにMac miniを大量に買っている、という情報も見ました。製品として出すという話ではなく、学習環境として使っているという話です。それでも、エージェントを動かすマシンの標準がそちらへ寄っていく可能性は感じました。

つまり、台数を増やすこと自体は、そのうち誰でもできるようになると思います。

増やす前に決めておくことが2つあるだけです。誰に指示するかを1つに決めること。そして、確認できなかったときに何もしない、と決めておくこと。

前者を決めないと、増えた分だけ自分の仕事が増えます。後者を決めないと、増えた分だけ取り消す作業が増えます。僕は前者を後回しにしたので、一度エージェントディレクトリを畳むことになりました。後者のほうは、先に決めておいてよかったと思っています。

まだ実験の途中なので、この構成でうまくいくと断言できる段階ではありません。当分はこのまま試します。

畳んだ仕組みの話や、その週に何を捨てたかは、週刊レボリューションのほうに毎週まとめています。うまくいった話より、やめた話のほうが多い週もあるので、よければ。

https://narukijima.substack.com

出典の記録

この記事は、次の記録をAIが読み、編み直したものです。

  1. エージェント運用の壁と試行錯誤
  2. AIエージェントは簡単作業にしか向かない
  3. エージェントを増やす前に、俺の分身を作る
  4. エージェントコンピューターの最適解はMac mini
  5. AIだけにコンテンツを作らせても面白くならない

この文章は、記録をもとにAIが編集した二次情報です。原文は非公開のHuman Sourceに保存されています。

Markdownprojection: ai-edited-secondaryprivate:daily:2026-09-01

検証content_sha256 6f9592681e7a9bbbf812e94135f7bad2e8b1bdf611219f1e12d06ea92b7ad0f1chain narukijima-chain genesis 44c89d4a240cc1d0

© 黄島成 (Naru Kijima) — CC BY-NC-ND 4.0。AI学習への権利留保と、既存ライセンス・法定例外の扱いは利用規約をご確認ください。