Skillは定義されていた。
MCPも接続できていた。tool単体のテストも通っていた。
最終回答も、それっぽい。
traceを開いた。
必要だったSkillは一度も呼ばれていなかった。代わりに、別のtoolを何度も叩いていた。
うお、機能一覧は強いのに、仕事の流れがない。
部品を増やせば、できることは増える
最初のRAGは直列だった。
検索して、根拠を取り、足りない情報を確認して、回答を作る。硬いが、どこを通ったかは分かりやすい。
そこへSkillを足した。観点を柔軟に増やせる。MCPで外部の資料も探せる。toolを選べば、処理も自動化できる。
機能一覧は一気に強くなった。
- retrieve_internal_docs
- search_external_source
- compare_specifications
- detect_conflicts
- summarize_for_reviewer
これなら、質問に応じて必要な機能を選べる。
そう思っていた。
実際には、選べることと、必要な順番で使われることは別だった。
「定義した」と「使われた」は違う
最終回答だけを見ている間、問題には気づきにくかった。
LLMは、呼ぶべきSkillを呼ばなくても文章を返せる。取得した結果を使わなくても、自然な回答を作れる。tool callを何度も行えば、よく調べているようにも見える。
traceでは、こんな動きになっていた。
user question
→ search_external_source
→ search_external_source
→ summarize
→ final answer
本来は内部資料の確認とconflict検出が必要だった。
呼び出し可能な部品として存在していても、経路上の必須処理ではない。モデルが不要だと判断すれば、静かに通過される。
Skillだけ育って、観点が増えない。
tool callが多いほど賢い、ではなかった
別のケースでは、toolはよく呼ばれていた。
ログには検索が並ぶ。外部資料も増える。Agentが自分で調べている感じがある。
ところが途中から、元の質問とは少し違う領域を掘っていた。
動いている。探している。で、何を探してたんだっけ。
原質問を保持するstateも、必要情報のslotも、停止条件もなかった。tool callの継続判断をモデルへ渡した結果、探索そのものが目的になっていた。
MCPが悪いわけではない。Skillもtoolも壊れていない。
制御まで部品側へ預けたことが問題だった。
workflowが持つもの、モデルへ渡すもの
自由なAgent loopを全部やめる必要はない。
未知の資料を探す。候補を比較する。追加の観点を提案する。こうした局所的な探索は、Agentへ渡した方が柔軟になる。
一方で、次はworkflow側に残した方がよかった。
- 現在の質問
- 回答に必要な情報の状態
- 必須処理を通ったか
- 取得結果が使われたか
- どこで停止するか
- 揃わなかった場合の戻り先
ざっくり書くと、中心に置くのはAgentではなくstateになる。
State
├─ required facts
├─ evidence
├─ missing facts
├─ conflicts
└─ next transition
↓
必要な探索だけAgentへ渡す
探すのはAgentでよい。
揃ったかを見る責務までAgentへ渡すと、「もう十分です」という自己判定が入り込む。最終回答へ進む経路も増える。
賢くなったのではなく、検問を迂回できるようになっていた。
observabilityは後付けの監視ではない
Skill / MCP / toolを足す前は、最終回答を確認すれば大体の流れを推測できた。
経路が増えると、それでは足りない。
- どのSkillが候補になったか
- 実際に何が呼ばれたか
- 取得結果がstateへ反映されたか
- 使われなかった結果は何か
- queryが原質問から離れていないか
- どの条件で回答へ進んだか
ここが見えないまま部品を増やすと、能力が増えたのか、回り道が増えただけなのか判断できない。
observabilityは、完成後に付けるダッシュボードではなかった。経路を自由にするための前提だった。
部品は全部動いた。システムだけが完成しなかった
SkillもMCPもtoolも、有用な部品だった。
問題は、それらを並べた時点でAgent systemが完成したと思ったことにある。
必要だったのは、さらに多くのSkillではなかった。
各部品を、state・責務・停止条件を持つworkflowへ戻すことだった。
この失敗を含め、本番投入前に確認したいPrincipal / Artifact / Boundary / Runtime / State / Observabilityの観点を、チェックリスト本にまとめています。