2026年9月18日の開発では、TK Agentを「何でも処理するAI」から、専門Agentへ仕事を振り分けるManager / Routerへ変えた。

User
  ↓
TK Agent（Manager / Router）
  ├─ Website Agent
  ├─ Article Agent
  └─ SNS Agent

狙いは、依頼ごとに必要な権限とContextを小さく保つことだった。例えば記事作成にWebサイト編集の機能は不要であり、SNS投稿案の生成に本番サーバーへ接続する権限も不要である。

役割を分けた

Article Agentは、選ばれた履歴と関連する長期記憶を受け取り、Markdown記事を生成する。SNS Agentは記事や開発履歴をもとに、X向けの投稿案、ハッシュタグ、添付ビジュアル案、カルーセル案を作る。外部SNSへの送信は、この通常の生成経路に含めない。

Website Agentは、既存の安全なWeb操作を利用して、対象ファイルの確認や編集案の作成を担う。操作権限を持つ具体的な処理は後述のとおり固定関数に残し、Agentが任意のコマンドを作って実行する構成にはしなかった。

明確な依頼はPython側で先に確定する

LLMだけに分類を任せると、明確な依頼でも揺れることがある。実際に「Someday100について教えて」が一般質問として扱われたため、明示ヒントを追加した。

「Someday100について教えて」       → website
「今日の開発内容を記事にして」       → article
「この記事をX用にして」              → sns

明確な依頼は先に確定し、曖昧な依頼だけをGemma Routerへ渡す。この分担により、分類の柔軟性を残しつつ、重要な経路を安定させた。

確認できたこと

  • Article RouterからArticle Agentを通り、Markdownを保存できた
  • Website RouterからWebsite Agentを通り、実ファイル参照ができた
  • SNS Routerから投稿案の保存ができた
  • remember / forget の優先処理を維持できた

この構成は、専門Agentを増やすためだけのものではない。各Agentに渡す情報と実行可能な操作を限定し、どの経路で何が起きるかを追いやすくするための土台でもある。