作って覚えるAIエージェント：1000行以内のtiny-agentをバイブコーディングで作ってみる
Hugging Faceのブログで提唱されている「Tiny Agents」。
そのコンセプトに触発され、バイブコーディングで1000行以内の軽量エージェント作りに挑戦してみました。
これらの記事では、MCPをツールとして用いる軽量なエージェントの概念として、Tiny Agentsを紹介しています。(Githubリポジトリも公開）
今回は上記記事をインスパイアにTiny Agentsを作ってみました、せっかくなのでAIコーディング・バイブコーディング縛りです。
（コードの細かい部分は全然確認していないので、お見過ごしください）
冷静に考えたら、1000行はtinyなのか？と思いましたが、プロンプトやコードコメントも含めて1ファイルに収めた時のコード行数なので、一旦tiny寄りと見なして頂けたらとても嬉しいです。
そして、最初に懺悔しておくと、MCPサーバーの実装も含めたら1000行を超えています🫠
（エージェント部分の実装ファイルは1000行以内に収まっています..）
（5/29追記: 色々プロンプト等改善してたら、エージェント部分の実装ファイルも1000行超えてしまった..）
AIサマリー
- AIコーディングで軽量エージェント作成: Hugging Faceの「Tiny Agents」に着想を得て、AI（バイブス）コーディングで1000行以内の軽量AIエージェントを開発。
- MCPサーバーをツールとして活用: ターミナルで動作し、自作のMCPサーバー（GitHubトレンド取得、Web検索、ファイル操作等）をツールとして利用可能。
- 独自のシンプル実装とプロンプト設計: LangChain等を使わずPythonでコア機能を実装。システムプロンプトにプロセスを導入し、思考の可視化や順次実行を重視。
- 実践による学びとAIコーディングの威力: 実際に作ることで技術理解が深まり、AIコーディングの効率性を実感。一方で、プロンプト調整の難しさやエージェントの限界も認識。
- Tiny Agentsの簡単さと難しさ: AIコーディングで短時間で基本実装できる手軽さ（簡単さ）と、意図通りに賢く動作させるための調整や実用レベルへの到達（難しさ）の両面を体験。
作ったもの
作成したのは、MCPサーバーをツールとして扱える、ターミナルで動く軽量なエージェントです。
MCPサーバーとして、Github TrendやDuckDuckGo APIを呼び出せたり、ローカルファイルをデータとしたタスク管理やコマンド実行もツールとして渡しているので、下記デモ動画の通り、「Githubのトレンド取得、一つずつ確認タスクを追加」や、「リポジトリのClone」がターミナルから操作できます。
MCPサーバーはserverディレクトリ配下に追加することで、エージェントからも扱えるようになります。
tiny-agentsの名前の通り、出来るだけ少ないコードで動くことを一応は目指しました。
動画はGithubのREADMEにも。
実装
実装自体はシンプルで、コアファイルは1ファイル（944行）のみのPython製です。
こだわりとして、LangChain・LangGraphなどのライブラリは利用していません。
基本的にエージェント自体のできることを増やす際には、MCPサーバーの追加を行うことで対応しますが、それもserver配下に実装を追加するのみで完了します。
作ってないもの・Moreな部分はたくさんあります。私のエージェント実装を育てるモチベに期待です。
アーキテクチャ概要
大きく2つのコンポーネントで構成されています：
- エージェント実装（tiny_agents.py） - LLMとの対話を管理し、ツール呼び出しを制御
- MCPサーバー群（servers/） - 各種ツールを提供するサーバー実装
my-tiny-agents/
├── tiny_agents.py # エージェント実装（944行）
├── servers/ # MCPサーバー実装
│ ├── github_trends_server.py # GitHubトレンド取得
│ ├── command_executor_server.py # システムコマンド実行
│ ├── web_search_server.py # Web検索
│ ├── python_executor_server.py # Pythonコード実行
│ └── task_manager_server.py # タスク管理
└── pyproject.toml # 依存関係管理
主要な実装
ツール呼び出し
システムプロンプトでアクションプランを作らせつつ、それを受けてツール＝MCPサーバーの呼び出しを行っています。
基本的な流れは下記の通りです。
-
ユーザーがリクエスト
"GitHubのトレンドを取得してファイルに保存して" -
AIが計画を立てる
📋 Action Plan: 1. fetch_github_trends を実行 2. execute_command でファイル保存
-
ツールを順番に実行
Step 1: GitHubからデータ取得 ✓ Step 2: trends.txt に保存 ✓
- 結果をまとめて報告
アクションプランは特に構造化された形式でやりとりしていない、古き良き？原始的な設計です。
システムプロンプト
システムプロンプトは下記です。Claude Code Actionのプロンプトを参考にバイブスで作成しました。
- 役割定義の明確化
- 役割と能力の明確な定義（できること/できないこと）
- フェーズ（分析→計画→実行→要約）
- タスク実行前の分析フェーズの追加
- タスク実行前に必ず分析を行うよう指示
- 分析結果を<analysis>タグで囲んで出力
- 分析内容：要求の理解、タスクタイプの特定、必要なツール、依存関係、実行計画
- 構造化された指示
4段階のタスク実行プロセス
Claude Code Actionのプロンプトを（AIが）参考に、フェーズの概念をシステムプロンプトに組み込みました。
1. Analysis Phase（分析フェーズ）
2. Planning Phase（計画フェーズ）
3. Execution Phase（実行フェーズ）
4. Summary Phase（要約フェーズ）
Analysis Phase - 思考の可視化
必ず最初に分析フェーズを実行させています。
エージェントは<analysis>タグ内で以下を整理します：
<analysis>
a. ユーザーが求めていることの要約
b. タスクタイプの特定（質問、実装、分析など）
c. 必要なツール/リソースのリスト
d. 潜在的な課題や依存関係
e. 単一/複数ツール呼び出しの判断
f. 高レベルの実行計画
</analysis>
この分析結果は実際にターミナルに表示され、エージェントの「思考過程」が可視化されます。
Planning Phase - アクションプランの明示化
複雑なタスクでは、アクションプランを生成させます。
- ユーザーが実行前に計画を確認できる
- 各ステップの目的が明確になる
- 実行の進捗が追跡しやすい
Execution Phase - 順次実行の徹底
プロンプトで特に強調しているのが順次実行です。
CRITICAL EXECUTION RULES:
- Execute tools sequentially - wait for each tool's result before calling the next
- Use tool outputs as inputs for subsequent tools when needed
これにより、前のツールの出力を次のツールの入力として使う「パイプライン処理」が可能になります。
それ以外にもエラーハンドリングの指示を含めてみたり、
- Handle errors gracefully and adapt your approach if needed
- If a tool fails, consider alternatives before proceeding
- Provide meaningful error messages
システムプロンプトには具体的なパターン例も含めて、エージェントが適切な実行戦略を選択できるようにしてみています。
Pattern 1: Data Processing Pipeline
→ read_file → execute_python → write_file
Pattern 2: Multi-Source Aggregation
→ fetch_data_source1 → fetch_data_source2 → create_report
ターミナルUI
エージェント関係なく、ターミナルUIの話ですが、Richライブラリを活用して、視覚的にわかりやすいインターフェースを目指しました。
（もしかしたら一番ここが気合を入れたかもしれない）
from rich.console import Console
from rich.panel import Panel
from rich.progress import Progress, SpinnerColumn
# ツール実行時の表示
def display_tool_execution(tool_name: str, tool_args: Dict[str, Any]):
console.print(Panel(
f"[bold yellow]Tool:[/bold yellow] [cyan]{tool_name}[/cyan]\n"
f"[bold yellow]Arguments:[/bold yellow]\n{json.dumps(tool_args, indent=2)}",
title=f"[bold]🔨 Executing Tool[/bold]",
border_style="yellow"
))
MCPサーバーの実装
MCPサーバーの実装自体は本題ではないので、今回はFastMCPを使用しました。
（実装をほぼ見てすらいない、バイブス100%で作りました）
既に公開されているMCPサーバーを利用しても良かったのですが、自作のTinyAgentsを突き詰めると、MCPもカスタマイズしたいニーズが高いことが見込まれるので、最初からMCPサーバーも自作することにしました。
ただ、FastMCP and Curslr Rulesを作成することで、今回の実装であれば、苦労は少なかったです。
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("GitHub Trends Server")
@mcp.tool()
def fetch_github_trends(language: str = "python", since: str = "daily") -> dict:
"""GitHubのトレンドリポジトリを取得"""
try:
repos_data = fetch_repos(language=language, since=since)
return {"repositories": repositories_info}
except Exception as e:
return {"repositories": [], "error": str(e)}
これでserver配下にMCPサーバーの実装を追加したら、AIエージェントがアクセスできるツールを増やせるようになりました。
複数ツールの実行
タスクを分解し、必要なツールを順次実行できるようにしています。
とはいえ、特にファイル操作系などは実行してくれない瞬間もあったので、まだまだ改善の余地は大きそうです。
（わかりづらくて恐縮ですが）例えば、Githubトレンドの取得を行った後に
15ステップ・15個分のタスク管理システムへの追加を実行するなどの挙動ができるようにはしています。
Cursor Rules
この程度の実装・コード量・ファイル数だと、特に困ることはありませんでしたが、一応Cursor Rulesも作成しました。
とはいえ、これもAIにバイブスで作ってもらったルールなので、これから育てていく必要があるやつです。
まとめ
Tiny Agentsを作ってみた話を書いてみました。
本当はせっかく自前でtiny-agentsを作るなら、もっと尖ったユースケースにしたかったのですが、発想力の限界でこれからの自分に期待です。
過去にSingle AgentについてのOpenHadnsやBig Modelsなどのブログ記事を読みましたが、まさしくモデルの進化とMCPによるI/Fの共通化により、簡易的な実装でもそこそこ動くようになってきたことを実感しました。
作ってみて見えた「手軽さ」と「一筋縄ではいかない奥深さ」
とはいえかなり賢さは限定的で、記事執筆中にも色々自由に試したら粗もたくさん見つかりしたし、想定外の事態に非常に弱い、マニュアルくんみたいなAIになってしまっているので、もっとAIにぐるぐる試行錯誤させる必要性は実感しています。
少し賢くさせようと少しプロンプトをいじったら壊滅的に壊れるようになったりもしました・しています。（これがEval..！の気持ち）
手軽さとプロダクションレディな汎用AIエージェントのハードルの高さを多少なりとも感じることが出来ました。
Tiny Agentsが教えてくれたこと、そしてこれから育てていきたいこと
一方で、Tiny Agentsは、「エージェントはもっと身近で、もっと手軽に作れるものなんだ」というメッセージを伝えてくれているように思います。この記事を読んで、「自分も何か作ってみようかな」と思っていただけたら嬉しいです。
他にも追加でやりたいことはたくさんありますが、例えば、現在のプロンプト構造はテキストベースですが、構造化された出力フォーマットの採用やタスク分解やツールの並列実行サポートなんかは実装してみたいですね。
せっかく自作するなら、より専門的でユニークなタスクをこなせるようにしたいものです。
コードは下記リポジトリで公開しています。
今回は以上です！
Discussion