Hermes Agentを LocalLM向け準並列キューとして使用する ― Hermes Agent × Ollama で「受付は並列、推論は直列」を実装した話 ―
本記事は、筆者が所属するクイックイタレート株式会社で社内エージェント環境を構築した際の整理メモをもとにしています。
関連する公開事例は 事例紹介 をご覧ください。
LLM（Local/フロンティアモデル） × エージェントツール × 社内システム連携の
設計・構築・運用のご相談も承っております。
概要
- 64GB Apple Silicon (Mac Studio M1 Ultra) 単機で 35B 級ローカル LLM を複数チャネルから同時に叩くと、巨大プロンプト時に runner stall と swap 地獄が起きた。
- Ollama を
OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1、OLLAMA_MAX_QUEUE=10にして、実推論を直列化した。 - Hermes Agent は複数チャネルからの並列受付と進捗通知を担当し、Ollama 側で 1 件ずつ処理する構成にした。
- 同じタイミングで Ollama を v0.22.1 → v0.24.0 に更新し、検証時の API endpoint も
/v1/chat/completionsから/v1/completionsに変えてしまっている。速度面の改善 (応答時間 11 分 → 1 分 14 秒) は、版上げ・直列化・endpoint 差分の複合効果 で、両者の寄与比は本稿では切り分けられていない。 - 一方、stall の根絶と 4 入口同時投入の完走可能性 は、KV/context 競合が構造的に消えるという理由から、直列化の寄与が大きいと考えられる。これは速度の話とは別軸として扱う。
はじめに
ローカル LLM をエージェント基盤に組み込んで本気で運用しようとすると、必ず一度はぶつかる壁があります。
「少なくとも 64GB Apple Silicon 単機で 35B 級モデルに長大コンテキストを投げる場合、複数チャネルから並列リクエストを受けると、推論性能が上がるどころか runner stall と swap 地獄に落ちる」というやつです。
ここでいう「落ちる」は比喩ではなく、実測値として、
- 1 リクエストの推論に 11 分 かかる
- 推論プロセスが CPU 23% で固まって応答を返さなくなる
-
/api/tagsは即応するのに/api/generateだけ無限タイムアウト - 最終的に
SIGKILLでプロセスを叩き起こすしかなくなる
という症状が再現します。クラウド LLM の感覚で「複数チャネルから同時に投げてもサービス側がよしなにさばいてくれる」と思って組むと、確実にこの壁に当たります。
この記事は、Hermes Agent を前段に置いて、ローカル LLM への問い合わせを 並列禁止のキュー に流すことで、見かけ上は複数リクエストを受けつつ、実推論は 1 件ずつ順次処理する構成 ― 本稿ではこれを「準並列処理」と呼びます ― について、実際に観測した数値とともに書いたものです。
主張は一文で済みます。
ローカル LLM は無理に並列実行させるより、エージェント側で受付を並列に保ちつつ、推論を直列キューに流すほうが、止まらない。
環境
実測した環境はこちらです。
| 項目 | 値 |
|---|---|
| ハード | Mac Studio M1 Ultra (Apple Silicon, unified memory 64 GB) |
| Ollama | v0.22.1 → v0.24.0 にアップデート |
| Hermes Agent | v0.14.0 |
| Python | 3.13.13 (venv) |
| OpenAI SDK | 2.24.0 |
| 入口チャネル | Discord (複数 profile) + 別チャネル経由 |
| 主要ローカルモデル |
gemma4:26b-mxfp8 (26GB)、qwen3.6:35b-a3b-coding-mxfp8 (37GB)、gemma4:26b-a4b-it-q4_K_M (17GB)、qwen3.6:35b-a3b-q4_K_M (23GB) ほか |
Hermes Agent は複数 profile を持っていて、profile ごとに別のチャットトークンで接続しています。入口は 3〜4 系統あり、すべて同じ 127.0.0.1:11434 の Ollama に向かっている、という構成です。これが問題の本質的な土壌でした。
なお、Apple Silicon は CPU/GPU 間で unified memory を共有する設計のため、本稿で「メモリ圧迫」と書いている箇所はすべて統合メモリの話です。「VRAM 圧迫」とは内部的に同じことを指しています。
観測された現象
4 入口同時リクエスト時の挙動 (v0.22.1)
ある日の 12:03:46 に、4 つのチャネルから同時に inbound が来ました。
12:03:46 4 thread から同時 inbound
chat=...329 / ...860 / ...101 / ...156
それぞれの応答時刻はこうなりました。
| 順序 | chat id | 応答時間 |
|---|---|---|
| 1 番目 | ...860 | 169.4 秒 |
| 2 番目 | ...156 | 256.1 秒 |
| 3 番目 | ...329 | 328.8 秒 |
| 4 番目 | ...101 | 407.7 秒 |
ログだけ見ると、それなりに順次返ってきているように見えます。
が、実際にはこの裏で 推論プロセスが何度も固まり、手動 SIGKILL → 自動 respawn → 再開 を繰り返していました。たまたま完走したものから返ってきていただけです。
巨大プロンプトの証拠
Ollama サーバログから、prompt processing 時のピークメモリと cache 状態を抜き出すとこうなっています。
peak memory size = 28.91 GiB (1st req)
peak memory size = 32.55 GiB (2nd req)
peak memory size = 35.19 GiB (3rd req)
cache hit total=39617 matched=25312 cached=25308 left=14309
cache hit total=45606 matched=28256 cached=28252 left=17354
total が新しい prompt の総 token、cached が KV cache ヒット分です。最終的なプロンプトは 約 47,324 token に達していました。文字数にして約 35,000 字。
Discord の同じスレッド内で会話履歴が累積していった結果です。
この巨大プロンプトを、4 入口から同時に同じモデルに投げる ― これがそもそも無理筋でした。
11 分推論の証拠
v0.22 時代のログにはこんな行が並んでいます。
[GIN] POST /v1/chat/completions took=10m59s status=200
[GIN] POST /v1/chat/completions took=11m6s status=500 ← timeout 派生エラー
これを v0.24 + 並列禁止に切り替えた後、同サイズの prompt で計測したのが下です。
POST /v1/completions took=1m14.05s status=200
POST /v1/completions took=1m14.78s status=200
POST /v1/completions took=1m16.68s status=200
なお、上記 11 分のログは別タイミングの単発推論 (4 入口同時投入とは別事象) であり、前述の 169.4〜407.7 秒は 4 入口同時投入で stall を SIGKILL で叩いて完走させた結果です。
単発推論の方が時間がかかっているのは、11分を記録したタイミングが会話履歴の累積によりプロンプトが最も肥大化し、メモリのswapが限界に達していたためと考えられます。
対して4並列時は、SIGKILLによるプロセス再起動で不良な状態が一旦リセットされながら完走したため、結果的に短い時間で応答が返っています。
このように、両者は異なる状況を示す数字なので、ベンチマークとして同列に比較できるものではありません。
約 11 分から約 1 分 14 秒 へ。ただし重要な注釈があります(後述)。
内部 stuck の症状
「落ちる」の中身はこうでした。
症状:
/api/tags → 即応 HTTP 200
/api/ps → 即応 (モデルは unload されていない)
/api/generate → 30〜180 秒タイムアウト、空レスポンス
ollama runner プロセス CPU 23.7% ← 何かしてるが進捗ゼロ
復旧:
ollama runner プロセスを SIGKILL → 自動 respawn → 動作復帰
死んでいるわけではなく、進捗だけが止まる、という質の悪い詰まり方です。
原因の構造化
切り分けた結果、複合要因でした。重要度順に並べるとこうなります。
| # | 要因 | 観測根拠 | 重大度 |
|---|---|---|---|
| 1 | 統合メモリ圧迫 (swap 常用) |
vm.swapusage used=6.5GB、64GB に対し peak 35GB のモデル + Hermes Python + チャットクライアントで物理超過 |
★★★ |
| 2 | 巨大プロンプト | 同一スレッド履歴累積で 47K token、prompt processing 単独で 1〜11 分 | ★★★ |
| 3 | KV cache / context 競合 (内部推論 or 同時投入由来) | 4 入口同時投入時に runner がフリーズする現象を複数回再現 | ★★ |
| 4 | モデル swap-in/out | gemma4 ↔ qwen を切替時に統合メモリ完全 reload + メモリ圧迫加速 | ★★ |
| 5 | 長時間プロセス | Ollama runner が 3+ 日連続稼働で内部状態蓄積 | ★ |
| 6 | Ollama 旧版の prompt 処理速度 | v0.22 で 11 分 → v0.24 で 1 分 14 秒 (約 9 倍速) | ★★ |
要因 1〜4 は、すべて「並列を許したこと」によって悪化していました。
要因 6 (版上げの効果) は、後述する効果検証セクションで重要になります。
4 入口同時投入時のスタック典型シナリオ
ログをつなぎ合わせると、こういう連鎖が起きていました。
[Discord] bot A, bot B, bot C, bot D が同時にメッセージを受信
↓
[Hermes] 4 つの aiohttp 接続を 127.0.0.1:11434 に張る
↓
[Ollama] 4 リクエストが同一モデルへ同時到達
※ 4 チャネルから同時にリクエストが到達していたことは
ログから確実。ただし Ollama 内部で同一モデルが何並列で
推論していたかは、当時の runner log からのみ確定できる。
`OLLAMA_NUM_PARALLEL` のソース上のデフォルトは
v0.6.x / v0.11.x / 現行 main いずれも 1 で、v0.22.1 でも
同様だったと考えるのが自然。よって本稿では「実効並列度
を断定する」立場は取らず、未明示設定で複数入口から同時
投入した状態を Before、`OLLAMA_NUM_PARALLEL=1` を明示
した状態を After として扱う。
↓
[KV/context] 仮に Ollama 側で並列処理が有効化されていた場合、
並列リクエスト処理ではコンテキスト窓が並列数倍に拡張される
(公式 FAQ[^1]: 2K context × 4 parallel = 8K context + 追加メモリ割当)。
47K token 級の prompt を同時投入した結果、モデル重みではなく
KV/context 領域の確保が膨れたと推測される。
↓
[統合メモリ] swap heavy → ディスク I/O ボトルネック
↓
[症状] Hermes ← Ollama 接続は ESTABLISHED 維持
/api/tags は即応するが /api/generate が永遠に返らない
Discord 側は "Still Working" reaction を繰り返すだけ
ポイントは、仮に並列処理が起きていたとしても、モデル重みが 4 重化されるわけではない、という点です。膨らむのは主に KV cache と context window 側 で、これがすでに 47K token 級だったので、必要メモリが一気に統合メモリの物理上限を超え、swap thrashing に至った ― という機序が、もっとも整合的な説明になります。
解決方針: エージェントを並列キューにする
ここで普通の発想は「Hermes 側にジョブキューを実装する」だと思います。
実際それも有効なのですが、今回採った最短ルートはもっと身も蓋もないものでした。
Ollama サーバ自体に、同時推論数 = 1 を強制する。
これだけで、Hermes Agent 側のコードを 1 行も変えずに、Ollama が複数リクエストを内部キューイングして 1 件ずつ処理してくれます。Hermes Agent から見ると、複数のチャネルに対して並行に応答しているように見える。実際の推論は内部で順次化されている。
タイトルの「エージェントをリクエスト並列キューとして使用する」というのは、
ここで言う通り 利用者から見ればエージェントが並列受付窓口兼キューになっている ということです。
実装上の直列化を担うのは Ollama ですが、論理構造としては「エージェント = キュー」「Ollama = 1 並列ワーカー」というモデルになります。
設定変更
a. ランタイム反映 (即時)
launchctl setenv OLLAMA_NUM_PARALLEL 1
launchctl setenv OLLAMA_MAX_LOADED_MODELS 1
launchctl setenv OLLAMA_MAX_QUEUE 10
その後、Ollama.app を完全に再起動します。ここが地味に重要で、launchctl setenv で環境変数を立てても、すでに起動している Ollama プロセスには反映されません。
killall Ollama
pkill -f "ollama serve"
pkill -f "ollama runner"
open -a Ollama
b. 永続化 (Mac 再起動後も自動適用)
~/Library/LaunchAgents/ai.ollama.envsetter.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key><string>ai.ollama.envsetter</string>
<key>ProgramArguments</key>
<array>
<string>/bin/sh</string>
<string>-c</string>
<string>launchctl setenv OLLAMA_NUM_PARALLEL 1; launchctl setenv OLLAMA_MAX_LOADED_MODELS 1; launchctl setenv OLLAMA_MAX_QUEUE 10</string>
</array>
<key>RunAtLoad</key><true/>
</dict>
</plist>
ロード:
launchctl load ~/Library/LaunchAgents/ai.ollama.envsetter.plist
これを /Library/LaunchAgents/ ではなく ~/Library/LaunchAgents/ に置くのも意図的です。Ollama.app は GUI アプリで、ユーザーのログインセッション内で動きます。システム LaunchAgents に置いても、Ollama.app からは見えません。
c. Ollama 本体アップデート (v0.22.1 → v0.24.0)
killall Ollama
mv /Applications/Ollama.app /Applications/Ollama.app.bak-v0.22.1
curl -L -o /tmp/Ollama-darwin.zip \
https://github.com/ollama/ollama/releases/download/v0.24.0/Ollama-darwin.zip
unzip -d /tmp/ollama-upgrade /tmp/Ollama-darwin.zip
mv /tmp/ollama-upgrade/Ollama.app /Applications/
xattr -dr com.apple.quarantine /Applications/Ollama.app
open -a Ollama
xattr -dr com.apple.quarantine を忘れると、Mac の Gatekeeper が初回起動を止めます。
設定変数の意味と値の根拠
| 変数 | 値 | デフォルト | 効果 |
|---|---|---|---|
OLLAMA_NUM_PARALLEL |
1 | 1 (※注) | 同時推論数を 1 に明示固定。本記事の主役 |
OLLAMA_MAX_LOADED_MODELS |
1 | 3 × GPU 数 (CPU は 3) | 統合メモリに同時ロードできるモデルを 1 つに制限。切替時に古いのを即 unload してメモリ圧迫を防ぐ |
OLLAMA_MAX_QUEUE |
10 | 512 | キュー上限 10 件。これを超えると Ollama は 503 を返す |
MAX_QUEUE を 10 まで絞っているのは意図的です。我々の構成では入口チャネル合計 3 系統 × 同時会話数を見積もっても、現実的に並ぶリクエストは数件程度。デフォルトの 512 のままだと、詰まったときに統合メモリだけ食い続けて状況が見えなくなります。10 件溢れたら早めに 503 で叩き返してもらったほうが、Hermes Agent 側で「いま満員です」とユーザーに伝えられる、というトレードオフです。
効果の検証 ― 9 倍速をどう解釈するか
これが本稿で一番ハマりやすい場所なので、丁寧に書きます。
観測された改善
単発の巨大 prompt 観測値と、4 入口同時投入の観測値は、性質が異なるので別の表に分けます。
(a) 単発巨大 prompt の推論時間
| 条件 | endpoint | 応答時間 |
|---|---|---|
v0.22.1, NUM_PARALLEL 未明示 |
/v1/chat/completions |
約 11 分 |
v0.24.0, NUM_PARALLEL=1 明示 |
/v1/completions |
約 1 分 14 秒 |
(b) 4 入口同時投入時の挙動
| 条件 | 最遅応答 | stall | SIGKILL |
|---|---|---|---|
v0.22.1, NUM_PARALLEL 未明示 |
407 秒 | あり | 必要 |
v0.24.0, NUM_PARALLEL=1 明示 |
約 300 秒 | なし | 不要 |
加えて、Hermes 側 timeout エラーは多発からゼロに、手動 SIGKILL の必要回数も数時間に数回からゼロになりました。
9 倍速の因果は分離できていない
この Before/After で、同時に変更している変数が 3 つ あります。
- Ollama v0.22.1 → v0.24.0 への版上げ
-
NUM_PARALLEL未明示 →OLLAMA_NUM_PARALLEL=1明示による直列化 - ログ取得時の API endpoint が
/v1/chat/completions→/v1/completionsに変わっている
3 つ目は本来揃えるべきもので、これだけでも prompt 整形パスや一部前処理が変わる可能性があり、厳密なベンチマークの体は成していません。したがって、「11 分 → 1 分 14 秒、約 9 倍速」を 直列化の効果 として読むのは正しくありません。実態は 「版上げ + 直列化 + endpoint 差分の複合効果」 です。本記事の主題は並列禁止キューですが、ベンチマークとして因果を切り分けるなら、最低でも次の 4 条件を同一 endpoint で測る必要があります。
| 条件 | 目的 |
|---|---|
v0.22.1 + NUM_PARALLEL 未明示 |
Before |
v0.22.1 + NUM_PARALLEL=1 明示 |
直列化だけの効果 |
v0.24.0 + NUM_PARALLEL 未明示 |
バージョンアップだけの効果 |
v0.24.0 + NUM_PARALLEL=1 明示 |
最終構成 |
今回はこの A/B/C/D を取り切れていません。したがって、9 倍速のうちどれだけが版上げで、どれだけが直列化由来かは、本稿では不明としておきます。
それでも直列化の寄与として強く言えること
ただし、直列化の寄与が大きいと考えられること は 2 つあります。
- 4 入口同時投入が完走するようになった ― Before は stall を SIGKILL で叩き起こしてようやく完走していた。After は stall 自体が消えた。これは内部推論を 1 に固定したことで KV/context 競合と統合メモリ thrashing が解消されたためで、版上げの寄与は副次的と説明できる。
- 最遅応答が 407 秒 → 約 300 秒に短縮された ― 順次化したのに最遅も短縮されたのは、1 件あたりの素の処理時間が swap thrashing 解消で正常化したから。
つまり、
- 「速くなった」の総量は版上げ + 直列化 + endpoint 差分の合算で評価する
- 「止まらなくなった」「完走する」は直列化に強く帰属できる
という整理が、もっとも誠実な書き方になります。なお、47K token の巨大プロンプト自体は何も縮んでいません。版上げで処理速度が上がったので 1 分 14 秒で捌けるようになっただけで、プロンプト肥大は別途 compression.threshold の調整や定期 /new で対処する必要があります。これは後述の「残課題」に残しました。
エージェントを並列キューとして使うとは何だったのか
設定変更それ自体は単純です。本質はその後の運用設計のほうにあります。
Hermes Agent の役割は、ここから 2 つに分かれます。
並列にしてよいもの (Hermes が引き受ける)
- 複数チャネル (Discord / CLI / webhook など) からの受付
- ジョブ登録、状態管理、進捗通知
- 軽い分類 (これはローカルに流す? クラウドに流す?)
- 完了結果のチャネルへの戻し
直列にすべきもの (Ollama が引き受ける)
- 重い推論
- 大きなコンテキストを伴う生成
- モデルロードを伴う処理
ユーザーから見れば「複数のスレッドで並行に話しかけている」状態が維持されます。Hermes Agent は受付時に即座に reaction を返し、処理状態を見せ、完了時にスレッドへ返信する。実推論はその裏側で 1 件ずつ淡々と進む。
この構造が、本稿で言う 準並列処理 です。受付・通知・分類は並列、推論は直列。エージェントは LLM のラッパーではなく、LLM の前に置く交通整理役 になります。
Hermes 側で関連する設定だけ
参考までに、ローカル Ollama 接続部分だけ抜粋しておきます (記事の主題でない外部 LLM provider 設定は省略)。
providers:
ollama:
api_key: ollama # ダミー値で OK
base_url: http://127.0.0.1:11434/v1
# ローカル LLM をデフォルトにする場合
model:
default: qwen3.6:35b-a3b-coding-mxfp8 # 8bit coding 特化 (37GB)
provider: ollama
base_url: http://127.0.0.1:11434/v1
軽量 4bit モデルへの差し替えは:
model:
default: gemma4:26b-a4b-it-q4_K_M # 4bit 軽量 MoE (17GB)
provider: ollama
base_url: http://127.0.0.1:11434/v1
設定変更後は hermes gateway restart で反映します。
Hermes 側で「同一 session 内の並列入力」をどう扱うかは別軸の話で、本稿で採った Ollama 側 NUM_PARALLEL=1 のほうが、複数 profile・複数チャネルをまたいだ並列を一括で抑える という点で確実です。
落とし穴と回避策
実装中に踏んだ罠を残しておきます。
1. launchctl setenv の反映タイミング
環境変数を立てても、Ollama.app が起動中だと反映されません。/api/version で動いていることを確認しても、内部の env はそのままです。
→ 必ず killall Ollama してから open -a Ollama。
2. 「動いてる風」で固まる runner
Ollama runner が CPU を 23% 食っているのに、/api/generate は無限に返らない、
という状態が起きます。ps だけ見ると元気そうに見えます。
→ /api/generate を直叩きして 30 秒タイムアウトを確認。確定したら SIGKILL → 自動 respawn。
3. Session 履歴肥大は compression だけでは止まらない
自動圧縮を有効にしていても、47K token に達した実績があります。
閾値の計算が「コンテキスト窓に対する割合」なので、大きなモデルだと閾値到達前にすでにプロンプトが重くなっているからです。
→ 長時間使うスレッドでは定期的に /new、または compression.threshold を下げる。
4. システム LaunchAgents に置くと効かない
/Library/LaunchAgents/ に plist を置いても、Ollama.app は GUI アプリでユーザーセッションに紐づくので効きません。
→ ~/Library/LaunchAgents/ 配下に置く。
5. Mac の Quarantine 属性
ブラウザでダウンロードした .zip から取り出した .app には quarantine 属性が付き、初回起動時に Gatekeeper のダイアログで止まります。launch agent 経由で起動するとそれだけで詰みます。
→ xattr -dr com.apple.quarantine /Applications/Ollama.app。
まとめ
ローカル LLM の運用で「複数同時リクエストを捌けるようにする」という方向に進むと、ハマります。少なくとも 64GB クラスの Apple Silicon 単機で 35B 級モデル + 47K token 級プロンプトを扱う場合、並列で動かす余地はありません。
正解は逆向きで、受付の並列性をエージェントに、推論の直列性を LLM サーバに分離する ことです。今回は Ollama の OLLAMA_NUM_PARALLEL=1 などの限定的な環境変数のへ設定で、それが達成できました。Hermes Agent 側のコードは 1 行も書いていません。
得られたのは、
- 完走可能性: 4 入口同時投入で stall していたものが、約 300 秒で全件完了。手動 SIGKILL 不要に。これは直列化に強く帰属できる。
- 応答時間: 1 件あたり 11 分から 1 分 14 秒へ。ただしこれは版上げ・直列化・endpoint 差分の複合効果で、純粋な並列禁止の効果ではない点に注意。
- エラー消失: Hermes 側 timeout エラーがゼロに。
エージェントを並列キューとして使うというのは、LLM の前に重い実装を載せる話ではなく、「LLM の同時実行数を 1 にして、エージェントを唯一のリクエスト受付窓口にする」 という、設計上の役割分担の話でした。これが 準並列処理 という発想の中身です。
参考: 観測・運用に使うコマンド
# 環境変数確認
launchctl getenv OLLAMA_NUM_PARALLEL
launchctl getenv OLLAMA_MAX_LOADED_MODELS
launchctl getenv OLLAMA_MAX_QUEUE
# Ollama 状態
curl -s http://127.0.0.1:11434/api/version
curl -s http://127.0.0.1:11434/api/ps
curl -s http://127.0.0.1:11434/api/tags
# Ollama ログ
tail -f ~/.ollama/logs/server.log
# 推論テスト (詰まり検査)
curl -s --max-time 30 http://127.0.0.1:11434/api/generate \
-d '{"model":"gemma4:26b-mxfp8","prompt":"say pong","stream":false}'
# Hermes 状態
hermes --version
hermes status
hermes profile list
hermes gateway restart
# プロセス状態
ps -ax -o pid,pcpu,etime,comm | grep -iE "ollama|hermes_cli"
# スワップ確認
sysctl vm.swapusage
再現条件 (フェアネスのために)
本稿の現象は、以下の条件で再現したものです。
- Apple Silicon 単機 (Mac Studio M1 Ultra, 統合メモリ 64GB)
- 35B 級モデル + 47K token 級プロンプト
- 複数入口チャネル (Discord 複数 profile を含む 3 系統) からの同時アクセス
- 同一 Ollama インスタンスに対する複数 Hermes profile 同時接続
軽量モデルや短文プロンプト、もっと大きなメモリを積んだマシンでは、ここまで深刻な症状にはならない可能性があります。
逆に言えば、ローカル LLM の並列実行は環境依存性が極めて強く、一見動いていても境界を越えた瞬間に破綻する ということでもあります。
本稿の主張も、その境界の内側で読んでいただければと思います。
本記事は、筆者が所属するクイックイタレート株式会社で社内エージェント環境を構築した際の整理メモをもとにしています。
関連する公開事例は 事例紹介 をご覧ください。
LLM（Local/フロンティアモデル） × エージェントツール × 社内システム連携の
設計・構築・運用のご相談も承っております。