この記事は Supershipグループ Advent Calendar 2025 の 8日目の記事です。
はじめに
Supershipで広告配信データ基盤を管掌している @yu-imamura です。
個人的なツールにAIエージェントを組み合わせたワークフローを導入した時に期待通りに動作させるために苦戦したことを書きます。
要旨
AIエージェント開発は自分でまずやってみる。
自分の道具作りの一環で取り組むことによって継続的な改善の勘所がつかめるようになる。頑張ろう。
背景
Get Things Done方式で個人的にタスク管理している。
todo.txt 形式のテキストファイルをVisual Studio Codeで編集しつつ管理している。
課題
情報の収集が重たい。
収集:
タスクを集める。Slack、メール、GitHub、、、
ここの時点で情報量が多くて疲弊する。
結果、その後のプロセスに費やす時間がどんどん増えていく。
収集をしている間にその日の打ち合わせが始まっていく。
せめてSlackの収集だけでも楽したい。
解法1: Claude Code Subagents
プロンプト書けばよいだけなので、以下のフェーズに分けて分担させてみる。
-
capture: 収集 -
clarify: 処理 -
organize: 整理
以下のような手続きはPythonなどで記述したMCP Serverとしてツール接続させる。
- Slackのメッセージ検索
- todo.txt形式のファイルの更新
など。
Claude Code Subagents 効用
- Slackのメッセージ収集の負担が減った
- 腰が重かったが収集作業が簡単に始められるようになったので、あとは一個ずつ点検して進めるだけでよくなった
- タスク処理の効率はそんなに変わらない。（ほんと最初の負担が減っただけではある）
Claude Code Subagents 課題
挙動が安定しない。
- 嘘のタスクを作り出す
- 指示したフォーマットで記録してくれない
- 消してほしくないタスクを消してしまう
こうした問題が出るたびに、エージェントへの指示（プロンプト）を調整していたが限界を感じる。
ある程度の定型化できそうなものを大きな裁量でAIエージェントにまかせているのが問題か？
ブレない部分をコード化して固定するならAgent Frameworkでワークフローにしてしまうのがいいのでは？
細かいところもコード書いて調整できるしよさそう。
解法2: Google Agent Development Kitを使ってワークフロー化する
いっそ自分でAIエージェントベースのワークフロー自作を試すか！となった。
Sequential agents という機能があるのでこれで作業のステップは固定できる。
全体の流れは固定できるので個別のAgentの調整をしていけばいい。（はず）
実装
全体の流れを定義する SequentialAgent の下に各種工程を表す LlmAgent を並べる。
記述自体はこのように個別の BaseAgent のサブクラス達を並べる。
from google.adk.agents import SequentialAgentfrom gtd_agents.team.workers import capture_agent, slack_summary_agent, clarify_agent, organize_agent
# 開始ワークフロー（シーケンシャル構成）
# 各ワーカーエージェントが独自の責任と指示を持つ
start_workflow_agent = SequentialAgent(
name="start_workflow",
sub_agents=[capture_agent, slack_summary_agent, clarify_agent, organize_agent],
description="開始ワークフロー: Slackからタスクを収集し、メッセージを要約し、コンテキスト（プロジェクト、優先度、見積もり、期日）を付与し、適切なリストに振り分ける。",
)
Agent Development Kitの効用
作業の流れが保証されるようにはなった。
はっきりとしたステップが前提として存在するならSequential agentsは有効であるようだ。
Agent Development Kitの課題
LlmAgent に大きい裁量を渡しても意図通りにツールを呼んでくれないことがある。
- slackメッセージ収集
- 収集結果をtodo.txt形式でinboxに書き込み
のような順序をプロンプトとして指示しても、出力パターンが安定しないこともあった。
改善に取り組んだがプロンプトの調整に限界を感じた。
結果的にslackメッセージ収集→inbox書き込みの一連の手続きをまとめてツール化した。
改善前:
-
LlmAgentがSlackメッセージ収集ツール呼び出し -
LlmAgentがSlackメッセージのリストをtodo.txt形式に変換してファイルに追記
改善後:
-
LlmAgentがSlackメッセージ収集→ファイル保存ツールを呼び出し
結果
LlmAgent が判断をする裁量はどんどん削られてしまいほぼルールベースになった。あるいは巨大な手続きを持つ ツールを呼ぶだけのラッパー のようになった。
結果的に LlmAgent として残留している機能は、「Slackメッセージを入力として受け取りタスクのメタデータを付与する clarify 」くらいになっている。
これで LlmAgent を使う意義があるのだろうか、という疑義はある。
振り返り
事前の分析と設計不足により不要な部分にまで LlmAgentを適用したことは反省すべき点として挙げられる。
開発する中でエージェントの必要な領域が絞り込まれていった。ドメインの性質に対して理解が進んだことで、
- プログラムとして記述できるものはできるだけプログラムにしてツール化する
-
- 機能をツールへとファクターアウトした結果として残る責任を
LlmAgentに渡す
- 機能をツールへとファクターアウトした結果として残る責任を
という分担が明確になっていった。
今振り返ってみると、エージェンティックな振る舞いはそれほど必要ない要件だったのかもしれない 。
こうした発見は事前の分析と設計によって明確にできたはず。商用向けのワークフローを作る時には当たり前だがこうした分析を進めたい。
この今回の要求は記事の基準でみるとTraditional AI Workflowに近いようだ。
Agentic Workflowとはもっとハイレベルな指示を元にタスクの分割や実行をAIエージェントが自律的に計画して実行するものであるとのこと。
まとめ
Claude Code Subagentsにタスク管理を一部移譲することから始まり、ADKを使いだすまでに至った。
しかしなんでもかんでも "Agentic" にするべきか？というとそうでもないのが実感として得られたのだった。
現在ADKで構築しているツールは日々の運用に耐える程度の動作にはなっている。
最後に宣伝です。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト
是非ともよろしくお願いします。