知識ベース、ツール、Skill——どれが何をするのか

エージェントの設定で人がつまずく問題のほとんどは、この三つのうち間違ったものに何かを入れてしまうことから生じます。そこで、住宅ローンブローカーを例に、その境界線を示します。

三つの問い、そしてそれぞれがどこで答えられるか

「固定金利商品の条件は何で、私は対象になりますか？」

これは事実です。どこかあなたの資料に書かれており、尋ねる誰にとっても同じ答えで、唯一の正しい情報源はあなた自身の文書です。→ 知識ベース。

検索がその商品についての一節を見つけ、エージェントはそこから答え、何を使ったかを引用します。あなたの文書がそれを扱っていないなら、正しい結果はもっともらしい言い換えではなく「それは持ち合わせていません」です。

「私の収入とこの頭金で、38万を25年で借りたら返済はいくらになりますか？」

これは計算です。正解は一つで、その裏にあるルールは長く込み入っており、規制業種では間違った数字は恥ではなく責任問題です。→ MCP ツール。

いくら有能でも、言語モデルに返済可能性のルールを即興で計算させたくはありません。あなた自身のシステムが呼ぶのと同じ関数を呼び、数字を受け取り、その数字を報告してほしいのです。あとで監査可能なのは、入力と出力を伴うツール呼び出しであって、たまたまどこかにたどり着いた推論の段落ではありません。

「これまで話したことを踏まえて、実際に検討すべきなのはこのうちどの商品ですか？」

これは手順です。いくつかのことが順番に起こる必要があり、次に何を尋ねるかの判断を伴います。→ Skill。

Skill は手順を保持します。何かを見積もる前に雇用形態と頭金を確認し、顧客が対象となる商品について見積もりツールを実行し、多くても3つまで提示し、条件を満たさない商品は決して提示せず、何かが確定する前に人間へ引き継ぐ。Skill はその仕事の一部として MCP ツールを呼び、道中で説明する条件については知識ベースに頼ることもできます。

人が見落とす四つ目の線

ここでの「事実」は実は二つのものであり、それを取り違えるのがこのページで最も高くつく間違いです。agent4.io は、テナントの知識ベース——あなたのルール、価格、規制で、検証済みかつ権威あるもの——を、各顧客自身の知識ベース——彼らがアップロードした文書を保持するもの——とは別に保ちます。

住宅ローンの問いには両方が必要です。あなたの融資基準はあなたのものから、彼らの給与明細は彼らのものから来て、答えはその比較です。両者は同時に検索され、別々のブロックとして注入されます——一方は従うべき方針として、もう一方は参照用の顧客自身の資料として枠付けられ——そうすることでエージェントは、顧客自身の文書をあなたの方針であるかのように顧客本人に引用し返すことがありません。知識ベースを参照。

目安

もっと端的に言えば、事実は検索され、計算は呼び出され、手順は従われる。

別の業種における同じ三つ

移民業務も、まったく同じ場所に線を引きます。

• 知識ベース——各ルートに必要な書類、現在の処理期間、あなたの料金表
• MCP ツール——熟練労働者申請のポイント計算を、記憶からではなく公式基準に照らして実行する
• Skill——「新しい問い合わせを審査する」：在留資格、時間軸、雇用、過去の却下歴を正しい順序で尋ね、ポイントツールを実行し、検討に値するルートを添えた構造化されたプロフィールをケースワーカー向けに作成する

なぜエージェントは複数の Skill を携えるのか

一つのエージェントが多数を保持できます——審査、見積もり、書類の催促、予約——そして会話が必要とすると分かった一つだけを読み込みます。見積もり用の Skill は見積もりツールを解放でき、審査用の Skill は何も解放せず、単に正しい順序で質問するための手立てであることもできます。

これは権限の境界でもあります。読み込まれたどの Skill も有効にしていないツールは、エージェントが手を伸ばさないツールです。これこそが、その手のデリケートな計算をそもそもツールとしてカプセル化する本当の理由です——単に正確だからではなく、それに手を伸ばすことが、モデルが下した決定ではなく、あなたが設定した決定になるように。