ラピットくん 
開発のなかで「同じ LLM を呼んでいるのに、こっちは 5 秒、あっちは 2 分かかる」という現象にぶつかりました。調べてみると、「遅さ」の正体は API の呼び出し回数 と 1 回あたりの入力の重さ の 2 つでした。そしてその裏には「チャット」と「エージェント」という、まったく違う動き方の差があったのです。
1. きっかけ：「遅い」の正体
Ollama のチャット画面では 5 秒ほどで返答が返ってくるのに、AppTalentNavi (自社で研修的に使ったアプリ)経由で同じモデルを使うと 120 秒近くかかることがありました。Ollama はメッセージを送って 1 回返答をもらうだけ。AppTalentNavi はメッセージ 1 回に対して内部で API が 2 回以上呼ばれ、そのたびに長いプロンプトやツール定義が送られています。
GitHubPage 本当にプロトタイプになってしまった。
つまり「遅さ」の正体は、回数（1 回 vs 2 回以上）と 1 回あたりの入力の重さ（短い対話 vs ツール付き・履歴付き）の両方でした。
2. 「API 通信だけ」と「エージェント」の違い
API 通信だけ（チャット的な動き）
ユーザーのメッセージを 1 回送り、モデルが 1 回返答して終わり。いわゆる「チャット」です。
エージェント
同じ API を使いますが、返答のなかに「このツールを実行して」という指示（tool_calls）が含まれることを前提にしています。アプリがその指示を解釈してツールを実行し、実行結果をまた API に送ってモデルに続きを考えさせます。ツール呼び出しがなくなるまで、この 「API 呼び出し → ツール実行 → 結果を渡してまた API」をループで回す のがエージェントです。
では、このループを 誰が 回しているかで、さらに大きな違いが出てきます。
3. 「誰がループを回すか」で見るスペクトラム
「チャット」と「エージェント」は二者択一ではなく、段階的なスペクトラム（連続体） として整理できます。
| レベル | 代表例 | ループを回すのは | 人間の介入単位 |
|---|---|---|---|
| チャット | Ollama / ChatGPT | ループなし（1 往復） | メッセージごと |
| コパイロット | Cursor | 人間（1 ステップずつ承認） | ステップごと |
| エージェント | Claude Code | アプリ（ツール承認後は自律） | タスクごと |
| オーケストレーター | CoVIBE | 複数エージェントを統括するアプリ | プロジェクトごと |
右に行くほど、人間が介入する粒度が大きくなります。チャットは一言ずつ人間が操作しますが、オーケストレーターは「このプロジェクトをやって」と一度伝えれば、複数のエージェントが分担して動きます。
Cursor と Claude Code の違いは「ツールを使えるかどうか」ではなく、「1 回の指示でどこまで自律的に進むか」 です。そしてその先に、複数のエージェントを束ねて動かす「オーケストレーター」という段階があります。
4. コードに見える「組織」のかたち
CoVIBE のコードを読んでいると、まるで 会社の組織図 を見ているような気持ちになります。
| コードの仕組み | 組織に置き換えると |
|---|---|
| SubAgentTool（researcher / coder / reviewer / tester） | プロジェクトチームの専門メンバー |
| SmartTaskDecomposer（複雑な依頼を小さなタスクに分解） | PM が WBS（作業分解構成図）を作る |
| DAGWorkflow（依存関係を解決して並列実行） | ガントチャート：並行できる仕事は同時進行 |
| AgentBlackboard（共有メモリ） | チームの共有ドキュメント・朝会 |
| 3 段階モデル選択（strong / balanced / fast） | タスク難度に応じた人材配置 |
| ExecutionMemory（成功率を記録して自動最適化） | 振り返りと改善（学習する組織） |
1 つの大きな依頼が来ると、まず SmartTaskDecomposer が「何をどの順番でやるか」を分解します。DAGWorkflow が「並行できるものは同時に走らせる」段取りを組み、SubAgentTool がそれぞれ専門の役割で実行します。その間、AgentBlackboard に発見を書き込んでチーム全体で共有し、終わったら ExecutionMemory に結果を記録して次回に活かす。これはまさに、プロジェクトマネジメントそのもの です。
5. コードが語る「設計思想」3 つ
CoVIBE のコードからは、組織づくりにも通じる 3 つの設計思想が読み取れます。
「役割」は使える道具の制限で決まる
SubAgentTool の設定を見ると、researcher は読み取り系のツールだけ、reviewer は分析だけで書き込みはできないようになっています。coder だけがファイルを編集できる。つまり 「何ができるか」ではなく「何をさせないか」で役割が決まっている のです。
組織でも同じで、「権限の範囲」が役割を決めます。全員がすべてできる組織より、権限を適切に分けた組織のほうが安全に動けます。
「共有記憶」がチームを束ねる
AgentBlackboard は、各エージェントが見つけたことを書き込む共有メモリです。これがあるから、researcher が調べた内容を coder がすぐに使えます。もしこの仕組みがなければ、同じ調査を別々にやってしまう無駄が生まれます。
人間のチームでも「情報共有の仕組み」がないとサイロ化します。朝会や共有ドキュメントが大切なのと、まったく同じ理由です。
「学習する組織」を実装している
ExecutionMemory は、どのタスクにどのモデルを使って、成功したか失敗したかを記録しています。次に似たタスクが来たとき、過去の記録から最適なモデルを自動で選びます。
これは組織の「振り返り → 改善」サイクルそのものです。うまくいった方法を蓄積して、次の判断に活かす。エージェントの設計が、学習する組織のモデルになっている のです。
6. エージェントの定義がコードのどこで行われているか
AppTalentNavi の場合、hajime.py（appnavi）は起動と環境設定だけをして、実際の処理は co-vibe.py に任せています。
「エージェント」としての形は、co-vibe.py の次の 3 点で決まっています。
- API にツール定義を渡している — ToolRegistry でツール一覧を管理し、毎回のリクエストにスキーマを付けている。だからモデルは「ツールを呼ぶ」返答を返せる。
- 返答から tool_calls を取り出してツールを実行している — モデルの返答を解釈し、ツール名と引数に従って Write / Bash などを実行する。
- ツール結果を会話に追加して、また API を呼ぶループになっている — Agent.run() 内のループで繰り返す。
この 3 つがそろうことで「エージェント」になっています。
7. では、私たちはどう使いこなすか
スペクトラムの各段階には、それぞれ適した場面があります。
- チャット / コパイロット → 探索・学習・素早い質問に向いている。「この関数の意味は？」「エラーの原因は？」のように、対話しながら理解を深める場面。
- エージェント → ゴールが明確な実行タスクに向いている。「テストを書いて」「このバグを直して」のように、完了条件がはっきりしている場面。
- オーケストレーター → 並列に分解できる複雑なプロジェクトに向いている。「この機能を設計・実装・テスト・レビューまでやって」のように、複数の専門性が必要な場面。
大切なのは 「どこまで委ねるか」を自分で選べるようになること です。すべてを自律に任せればいいわけではなく、探索段階ではコパイロット的に対話し、実行段階ではエージェントに委ねる、という使い分けが効果的です。
そして気づくのは、エージェントの使い方を学ぶことは、マネジメントの練習でもある ということ。「タスクを分解する」「適切な役割に委任する」「情報共有の仕組みを作る」「結果を振り返って改善する」— これはすべて、チームを率いるときに必要なスキルと同じです。
8. まとめ
- 「遅い」＝ ループ × 入力の重さ — エージェントは 1 回の指示で API を何度も呼び、毎回長いプロンプトを送っている。
- エージェント ＝ ツール実行ループ — 「API を叩いているだけ」に見えても、内部でツール実行と API 呼び出しのループが回っている。
- Chat → Copilot → Agent → Orchestrator のスペクトラム — 違いは「誰がループを回すか」と「人間の介入粒度」。
- エージェント設計 ≒ 組織設計 — 役割分担・タスク分解・情報共有・振り返りは、コードでも組織でも同じ構造。
- 使いこなしの鍵は「委任力」 — どの段階にどこまで委ねるかを選べることが、AI 時代のリテラシー。
AppTalentNavi 開発のなかで得た知見をまとめたコラムです。Ollama のコードは co-vibe.py で読めます。クラス名を追うだけでも「組織の設計図」が見えてきます。
