モデルも、エンドポイントも、 コスト曲線も、あなたのもの。
ここではエージェント層とモデル層が分かれています。agent4.io を OpenAI 互換のエンドポイントに向けるだけです。フロンティアモデルの API でも、自社の機材で動かす小さなオープンモデルでも、複数同時でも。エージェントを一つも作り直さずに。
モデルは設定項目であって、アーキテクチャではありません
多くのエージェント基盤は特定のモデルファミリーに合わせて作られ、その前提ごと引き継いでいます。コンテキスト窓も、ツール呼び出しの形式も、価格も。だからモデルを替えるということが、基盤を作り直すことになります。
ここでは、モデルはゲートウェイの向こうにいます。バックエンドはテーブルの一行にすぎません。base URL、キー、モデル名、種別、重み。一つ増やすのは設定変更であって、リリースではありません。エージェントもプロンプトもナレッジベースもスキルも、どのモデルが答えたかを知りませんし、知る必要もありません。
この一段の間接化が、このページの他のすべてを成り立たせています。コストの管理も、自社ネットワーク内のモデルも、用途ごとの使い分けも。一つの設計判断が、四つの仕事をしています。
小さなオープンモデルは、決まった壊れ方をします
「オープンモデルに対応」と言うのは簡単で、たいていは「HTTP 呼び出しが成功する」という意味しかありません。本当の不具合はもっとあとに、本番で、ツール呼び出しの経路で出てきます。そのうち四つは頻度が高く、私たちは直接そこに合わせて作っています。
ツール呼び出しがテキストで届く。 多くのオープンモデルは構造化された tool_calls フィールドを無視して、呼び出しを応答本文に書いてきます。XML か JSON の形で。放っておけば、ユーザーが見るのは記法の壁だけで、何も実行されません。agent4.io は両方の形式を解析し、ツールを実行し、記法を取り除くので、エンドユーザーには届きません。
ストリーミング中のツール呼び出しが断片で届く。 OpenAI 互換のサーバーは、ツール呼び出しをストリーミングの断片にどう切るかで足並みが揃っていません。断片はインデックスで組み直してから、はじめて実行に回します。
コンテキスト窓がはるかに小さい。 32K の窓のモデルを、100万の窓のモデルと同じようには使えません。使える入力の予算は、起動時に実際に検出した窓から出力の予約分と安全域を引いて求めます。ビルド時に書き込んだ数字からではありません。
思考が答えを食べる。 答える前に考えるモデルでは、素朴な出力予算が推論に食われ、肝心の答えが途中で切れます。予算はその分だけ引き上げます。
仕組みを詳しく — これが本物かどうかを聞かれる、御社の技術担当者向けの説明です。
ベンダーではなく、仕事で振り分ける
すべての工程に同じモデルが要るわけではありません。分類、抽出、定型の返答は小さなモデルでもよく動きます。難しい推論の工程はそうとは限りません。バックエンドが種別と重みを持っているので、並べて動かし、それぞれの仕事をふさわしい場所に置けます。
現実的な分け方は、難易度ではなく結果の重さで決めます。読むだけの、影響の小さい仕事は安いモデルに。書き込むもの、確定させるものは強いモデルに。
業界の言葉を話すモデル
汎用モデルは、正しいのにどこか素人くさく聞こえることがあります。行政書士も、保険の引受担当者も、放射線科医も、それぞれ固有の語彙と、語り口と、質問の順番を持っています。外の人間には真似できず、同業者にはひと目で分かるものです。検索は事実を正します。訛りまでは正しません。
モデルが設定項目である以上、業種向けにファインチューニングしたモデルは他に何も触らずに差し込めます。 同じエージェント、同じナレッジベース、同じ境界、その後ろにより良い勘。
ファインチューニングとは何か、手短に。 その分野の優れた実務家ならこう答えたであろう例を使って、ベースモデルの学習を続けます。既定値がずれます。選ぶ言葉、答えの形、答える前に何を尋ねるか。実務上これはアダプタ（LoRA）です。凍結したベースの上で学習した数十メガバイトのファイルであって、まるごと新しいモデルではありません。だから一つのベースモデルで多数のアダプタを扱えます。 同じ機材が法律事務所の分もクリニックの分も動かし、テナントごとに小さなファイルを差し替えるだけです。
これはデータベースではありません。 何かを保存して取り出しているのではありません。この違いが下の表のすべてであり、ここを取り違えることがこの種のプロジェクトが失敗する道筋です。
ファインチューニングが担うもの、担わないもの：
| 置き場所 | |
|---|---|
| 価格、規約、手順、在庫 | ナレッジベース。 これらは変わりますが、ファインチューニングされたモデルは一緒に変わりません |
| 業界の語彙 | ファインチューニング |
| 専門家が物事を尋ねる順番 | ファインチューニング |
| その業界が期待する語り口 | ファインチューニング |
この二つを混同することが、この種のプロジェクトが失敗する最もよくある原因です。自社の文書で学習させたモデルが、先週変えた価格を「知っている」わけではありません。それは検索の仕事です。私たちはこの線を、納品時ではなく作業に入る前に引きます。
きちんとやるには三つ必要です。 その分野を知る人が確認した数百件の実例。効果があったかどうかを誰にも言えなくなるので、切り分けておく評価用データ。そしてベースモデルが変わったときに、やり直すための段取り。ファインチューニングとは何か、詳しく。より良いプロンプトで十分だった場合の話も含めて。
ファインチューニングはプランの機能ではなく、有償の個別対応です。範囲は、手元の材料の量、業種、どこで動かす必要があるかによって変わります。何が必要になるか、ご相談ください。
コストについて、これが変えること
トークン単価は、多くのエージェント案件を終わらせる異議です。試験導入は安く、本番展開はそうではありません。モデルを基盤から切り離すと、レバーがゼロ本ではなく三本になります。量が多くて影響の小さいトラフィックを安いモデルへ移す。オープンウェイトをすでに持っている機材で動かす。強いモデルは、それに見合う仕事のために取っておく。
肝心なのは、オープンモデルが常に正解だということではありません。この判断が最後まであなたのもので、いつでも撤回できるということです。
よくあるご質問
- agent4.io で、既定のモデルではなく自社のモデルを使えますか？
- 使えます。agent4.io は OpenAI 互換のエンドポイントであれば接続でき、モデルのバックエンドはコードではなく設定です。ホスト型のフロンティア API に向けることも、vLLM や Ollama で自社運用しているオープンモデルに向けることも、複数のバックエンドに同時に向けることもできます。切り替えても、エージェントもナレッジベースもスキルもそのままです。
- agent4.io は Qwen のようなオープンソースモデルでも動きますか？
- 動きますし、互換性への対応はエンドポイントを受け付けるところで終わりません。小さなオープンモデルは、ツール呼び出しを構造化フィールドではなく素のテキストで返したり、ストリーミング中に呼び出しを断片で送ってきたり、フロンティアモデルよりはるかに小さいコンテキスト窓しか持たなかったりします。agent4.io はこの三つをいずれも処理し、フロンティアモデルの挙動を前提にしません。
- モデルがネイティブの function calling に対応していない場合はどうなりますか？
- agent4.io は、応答本文にテキストとして現れるツール呼び出しも解析します。オープンモデルがよく出力する XML 形式と JSON 形式の両方に対応し、その記法は取り除くのでエンドユーザーには届きません。ネイティブの function calling を持たないモデルでも、ツールを動かせます。
- 自社ネットワーク内のモデルに対して agent4.io を動かせますか？
- 動かせます。モデルへは通常の OpenAI 互換 HTTP エンドポイント経由で到達するため、そのエンドポイントは公衆インターネットに経路を持たない自社ネットワーク内のサーバーでも構いません。規制や社内方針により顧客データを第三者のモデル事業者に渡せない場合、通常はこの構成をとります。
- 自分のモデルを持ち込んだ場合も、agent4.io にトークン課金されますか？
- されません。トークンの上限は agent4.io が提供する推論に対するものです。ご自分のエンドポイントを使う場合、推論の費用は各社のサービスまたは自社の機材の費用となり、agent4.io は別途ライセンスとなります。実際の形はご相談ください。
- agent4.io で、自社の業界向けにファインチューニングしたモデルを動かせますか？
- 動かせます。agent4.io ではモデル層がエージェント層と分かれているため、ファインチューニング済みのモデルにエージェントを向けることは設定の変更です。エージェントもナレッジベースも業務の流れも境界も、手を触れません。ファインチューニング自体も有償の個別対応として承っており、範囲と費用はお客様ごとに決めます。
- ファインチューニングすれば、自社の価格や規定をモデルが覚えてくれますか？
- 覚えません。agent4.io はこの線を作業に入る前に引きます。事実はナレッジベースに置くべきものです。事実は変わりますが、ファインチューニングされたモデルはそれに合わせて変わらないからです。ファインチューニングが担うのは、毎週は変わらないもの、つまり業界の語彙、専門家が質問する順番、その業界が期待する語り口です。
- 用途ごとに違うモデルを使えますか？
- 使えます。バックエンドはテナントごとに種別と重みを付けて登録するため、対話と埋め込みを別のモデルで動かすことも、同じ種別の複数バックエンドにトラフィックを分散することもできます。あるバックエンドが落ちたり到達できなかったりした場合、agent4.io は諦める前に他のバックエンドで再試行します。
絞り込まれた専門性
何でも知っているチャットボットは、もう要りません。必要なのは、自社の事業を知り尽くし、あなたが引いた線の内側から出ないエージェントです。
エンジニアなしで作れる
プロンプトの工夫も、設定ファイルも、情シスへの依頼も不要です。自分の言葉で二、三ステップ。しかも何かが作られる前に、何が作られるのかを全部見て確かめられます。
顧客ごとの記憶
全員に一つの共用エージェント、ではありません。顧客ごとに一つ、その関係のすべてを抱えたエージェントです。CRM のレコードでは作れない個別対応を、顧客名簿の全体に配れるコストで。
時間を取り戻す
どの問い合わせに自分の時間を割く価値があるかは、一時間かけて確かめるまで分かりません。その確かめる仕事、つまり質問も、条件の確認も、書類集めもエージェントが引き受けます。あなたの予定表に届くのは、すでに整理された案件だけです。
実行するエージェント
話すだけのチャット窓は、結局あなたに仕事を残します。このエージェントは注文を通し、枠を押さえ、チケットを起票します。MCP と自社の API で、実際のシステムにつながっているからです。
関係の継続性
関係で成り立つ商売では、担当者が各顧客について知っていることこそが資産です。そしてそれはたいてい、一人の頭の中にあります。ここでは、それが会社に積み上がります。
ページを理解する会話
たいていのチャットバブルはまっさらな状態で開き、いま読んでいたことを訪問者に説明させます。これはページそのものから始まり、そのページが実際に生む疑問から口を開きます。