AIに仕事を任せる、と一口に言っても、中で起きていることは案外知られていない。私自身、自分の環境を毎日のように書き換えていながら、「ではエージェントとは具体的に何か」と問われると、少し考えてしまう。
この記事は、私のAI環境の見取り図のうち、②基盤層の話だ。入口であるチャット画面のすぐ下で、会話を組み立て、道具を選び、実行を繰り返している部分について書く。ここが土台になっている。
見取り図を先に読んだ人は、4層のうちの2枚目の話だと思ってもらえればよい。読んでいない人にも伝わるように、必要な前提はその都度説明する。
エージェントは「一度答えて終わり」ではない
ふつうのチャットAIは、問いを受けて一度答えを返したら終わる。こちらが追加で聞けば、また一往復する。会話はするが、自分では何もしない。
私の環境のエージェントは違う。答えを返す前に、自分で道具を使って調べ、その結果を見て考え直し、また道具を使う。この「考える」「道具を使う」「結果を見る」「また考える」を、こちらが手を出さずに何十回も繰り返す。最終的な答えは、一往復ではなく、この繰り返しの末に出てくる。
この繰り返しを回しているのがループエンジンである。名前のとおり、ループ（反復）を回す引擎だ。
ループエンジンの中身
動きは単純だ。エージェントは1回の思考で、次のどちらかを選ぶ。
- 道具を使う（ツール呼び出し）— ファイルを読む、コマンドを実行する、チケットを起票する、など
- 答えを返して終わる — もう道具は要らないと判断したとき
道具を使った場合は、その実行結果を受け取って、また最初に戻る。考え直し、次の一手を選ぶ。これを、答えに辿り着くまで延々と繰り返す。単純な問いなら一、二回で終わるし、サーバーを調べ上げて設定を直すような仕事なら、何十回と回る。
つまり、エージェントの賢さは「一度の思考の質」だけでなく、何回試行錯誤できるかに強く依存する。だから私は、反復の上限をかなり大きく取ってある。既定で300回、環境変数でさらに増やせる。上限が小さいと、複雑な仕事の途中で「はい、ここまで」と打ち切られてしまう。人間だって、複雑な作業を数回の手番で終わらせろと言われたら無理だろう。それと同じだ。
ここで大事なのは、エージェントが自分の思考の結果を自分で見ていることだ。サーバーの状態を調べたければ、まず調査コマンドを実行し、返ってきた出力を読み、それを踏まえて次の判断をする。推測で話を進めない。手を動かし、結果を見て、それから考える。この順番を機械に守らせている。
なぜ自作したのか
この土台は既製品ではなく、私が自分で書いた。使える既製品はたくさんあるのに、なぜ作ったのか。
理由は、道具の選ばせ方とプロンプトの組み立てを、自分の判断で細かく制御したかったからだ。既製品は便利だが、こちらが意図しない道具まで見せてしまったり、会話の組み立てを勝手に決めてしまったりする。私が欲しかったのは、その時々の仕事に必要な道具だけを、ちょうどよく渡す仕組みだった。それには、土台そのものを自分で持っている必要があった。
土台を自作するということは、面倒を引き受けるということでもある。だが、困ったときに中身を直せるのは大きい。実際、この土台は今も毎日のように書き換えられている。後で触れるが、AI自身がこの土台を改修している。
ツールボックス — 道具は必要なときだけ渡す
ループエンジンと同じくらい重要なのが、ツールボックスという考え方だ。
エージェントに仕事をさせるには、道具を渡さなければならない。ファイルを読ませたいなら読む道具を、チケットを起票させたいならその道具を渡す。ここで素朴に考えると、「使えそうな道具を全部渡しておけばいい」となる。実際、最初はそういう作りが多かったはずだ。
だが、これは失敗する。道具を全部並べておくと、エージェントは使わない道具まで視野に入れて迷い、的外れな操作をしかねない。選択肢は、多いほどよいとは限らないのである。
そこで、会話の目的に応じて道具の束を丸ごと差し替える方式にした。ファイル操作の仕事ならファイル操作の束を、会計の仕事なら会計の束を、というように。この「束」がツールボックスだ。私はこれを、道具箱の差し替えだと思っている。会話を始めるたびに、その仕事に要る道具箱だけを作業台に置き、終わったら仕舞う。人間が作業台の上を整理するのと同じことを、機械の側でもやっている。
この方式には、実利が二つある。ひとつは先ほどの失敗が減ること。もうひとつは、トークン（AIが一度に扱える文章量）の節約だ。道具の説明を全部並べると、それだけで文脈が埋まってしまう。必要な分だけ渡せば、その分を実際の仕事に使える。
道具箱の「正」を一つに決める — 自己登録レジストリ
ツールボックスが増えてくると、別の問題が起きる。新しい担当者を足すたびに、本体のコードのあちこちに「この担当者はこの道具箱を使う」と書き足さなければならない。追加のたびに複数箇所を直すのは、必ずどこかが漏れる。実際、昔は漏れた。
そこで今は、各担当者のフォルダに置いた一枚の設定ファイルを、唯一の「正」とする方式にした。担当者を追加したいときは、そのフォルダに設定ファイル（道具の一覧と、道具箱の名前・説明・振り分けの合図）を置くだけでよい。土台の側は、起動時に各フォルダを走査して、書いてあることをそのまま読み取る。本体のコードは一切触らない。
これが自己登録レジストリだ。道具箱の名前も、利用できる道具も、どの会話でどの箱を使うかの振り分けも、すべてこの設定ファイル群から自動で集められる。「追加はフォルダを一つ置くだけ」で済むようになった。
自己登録にした効果は、追加の手軽さだけではない。設定ファイルがそのまま仕様書になる。どの担当者が何をできるかは、そのファイルを見れば分かる。コードを読まなくてもよい。人間にとっても、AIにとっても、見通しがよくなった。
誰がどの道具箱を使うか
担当者は今のところ12種いる。タスク管理、インフラ構築、ブラウザ操作、記事化、画像生成、会計、物理サーバの電源操作、動画要約、障害アラートの一次調査、そして土台そのものを差し替える係、再起動を安全な瞬間まで繰り延べる係、といった具合だ。それぞれが自分の道具箱を持ち、専門の外へは出ない。
汎用の何でも屋を一つ置くのではなく、専門を分けて足し算している。何でも屋は、何にでも手が届く代わりに、どの分野でも半端になりやすい。担当を分けておけば、ある分野の手順を磨き込めるし、その分野だけを差し替えるのも簡単だ。
道具箱の設計と担当の分割は、結局は同じ一つの問いに帰着する。「この仕事に必要なものだけを、この仕事の間だけ渡す」。人間の仕事の組み立て方と、根本は変わらない。
止めずに直す — ホットリロード
土台の話で、もう一つ外せない仕掛けがある。止めずに直す、ホットリロードだ。
ふつう、プログラムのファイルを書き換えたら、反映するには一度止めて起動し直す。起動し直している間は使えない。ところが私の環境では、AIが自分で自分の土台を書き換える。そのたびに止まっていたら、会話が途切れて仕事にならない。
そこで、ファイルの更新時刻を監視し、変更を検知したら次の処理から新しい内容を読み込む方式にした。実行中の会話はそのまま続き、新しい会話から新しい内容が使われる。ファイルを保存した瞬間に、次に話しかけたときから挙動が変わる。止める必要はない。
これがあるおかげで、AIは自分で自分の環境を直しながら、その場で会話を続けられる。土台を書き換える係と、再起動を安全な瞬間まで繰り延べる係を別に置いたのも、この「止めない」という方針の延長にある。
動かして分かったこと
この土台を作り、何度も直してきて、分かったことがある。
第一に、エージェントの性能は、思考の回数と道具の見せ方で大きく変わるということだ。賢いモデルを使えば何とかなる、という話ではない。何回試行錯誤させるか、どの道具を見せるか。この地味な設計が効く。逆に言えば、ここを疎かにすると、良いモデルも力を出せない。
第二に、「正」を一箇所に決めることの効き目は絶対的だということ。道具箱の設定を各担当者のフォルダに集め、本体からは読み取るだけにした瞬間、追加と修正が嘘のように楽になった。同じ情報を複数箇所に書かない。これは、自動化に限らず仕事全般に通じる原則だと改めて思う。
第三に、止めずに直せることは、任せる量を増やす前提条件だということ。反映のたびに止まる環境では、AIに自分を直させようなんて思わない。止まらないから、思い切って任せられる。安全策は、機能を増やすためではなく、任せる量を増やすためにある。
まとめ
エージェントの土台は、二つの部品でできている。答えを返すまで試行錯誤を回すループエンジンと、仕事に必要な道具だけを渡すツールボックスだ。そしてツールボックスは、各担当者の設定ファイルを唯一の正とする自己登録レジストリで管理し、土台のコードは止めずに直せるようにしてある。
派手な部品は一つもない。ループを回し、道具を選び、設定を一箇所に集め、止めずに直す。どれも地味な作りだ。だが、この地味さがあるからこそ、その上の12種の担当者が思い切り働ける。
見取り図の②基盤層の話は、ここまでだ。次は、この土台の上で働く担当者たちの個別の話に移る。土台がどう組み立てられているかを知っておくと、その先の話がどこに収まるのかが見えやすくなるはずだ。
