こんにちは。作業に戻ろうとしてPCの前に座ったのに、気づいたらブラウザのタブ整理を始めて30分経ってました。ADHD社長です。
自作AIアシスタント「Jarvis」の実装寄りのメモです。この記事の主張は1つで、定型処理の実行役には判断を持たせないほうが、結果の再現性と検証のしやすさが上がる、ということです。AIエージェントの実装で、実行まわりをどう作るかの話として書きます。
現象：同じ依頼なのに、実行結果の細部が毎回違う
何が起きていたか
全部を1つの流れで処理していた頃、同じ定型処理でも、回によって手順の細部や出力の形が少しずつ違いました。致命的ではない違いです。ただ、違いがあること自体が、検証のコストを上げます。
前回の結果と今回の結果を比べる時、「この差分は異常か、それとも判断の揺れか」を毎回考えないといけない。差分の意味を判断する作業が増えると、定型処理を自動化したはずなのに、確認の手間が戻ってきます。
原因の切り分け
記録を追ってみると、揺れの発生源はおおむね次のどれかでした。
- 依頼の指定が曖昧で、実行側が不足分を補っていた
- 実行の途中に判断分岐があり、文脈によって進み方が変わっていた
- 完了の定義がなく、「どこまでやれば終わりか」が回ごとに解釈されていた
つまり、問題はモデルの賢さではなく、実行に解釈の余地が残っていることでした。解釈の余地は、そのまま揺れになります。
対処：実行役から解釈の余地を減らす
対処は、実行側の作りを次のように寄せることでした。
- 入力は「対象を一意に決める指定」だけを受け取る
- 手順は固定し、途中の判断分岐は外に出す（判断が要るなら止めて返す）
- 出力は決まった形にし、完了条件を満たしたかどうかを外から判定できるようにする
- 実行の記録は、依頼と結果が対になる形で残す
ここで大事なのは、判断分岐を「なくす」のではなく「外に出す」ことです。判断自体は必要なので、考える役の側に寄せる。実行役の中で判断が起きると、それは記録にも残らず、再現もできない判断になります。外に出した判断は、依頼文の形で残る。残る判断は、あとから検証できます。
実装の感覚としては、純粋な処理と、判断を含む処理を分ける、という昔からある話に近いと思います。新しさはない。ただ、相手がAIになると「ついでに考えておいて」と頼みたくなり、この分離が崩れやすい。意識して境界を守る必要がありました。
検証：揺れが減ると、何が楽になるか
この構成にしてから楽になったのは、異常の見つけ方です。出力の形が固定されているので、前回との差分がそのまま異常の候補になります。差分を見る、という単純な確認が効くようになりました。
もう1つは、直す場所の特定です。結果がおかしい時、まず依頼の指定を見る。指定が正しければ手順を見る。手順が正しければ、判断を外に出し損ねていないかを見る。この順番で追えるようになったのは、実行から解釈を抜いた副産物です。
もちろん、代償もあります。判断が要る場面では必ず一度止まるので、滑らかに全部が流れる感じはなくなります。止まる回数自体も、最初は増えました。ただ、止まった場所と理由が記録に残るので、止まり方を直すことはできます。揺れたまま進むより、止まって残るほうが、個人開発の体力では扱いやすかった、というのが現時点の結論です。
まとめ
- 定型処理の揺れは、実行に残った解釈の余地から生まれる
- 判断分岐はなくさず、実行の外（考える役）へ出す
- 出力形式と完了条件を固定すると、差分確認で異常を拾える
- 止まることは許容し、止まった理由を記録に残す
次回は、実行役を定期的に動かす土台側の話として、Windowsのタスクスケジューラとスクリプトを組み合わせた運用の基本形を書きます。
ADHD社長