AIエージェントに30個の小さなプロジェクトを見張らせてみた

Transcript

1. AIエージェントに30個の小さなプロジェクトを見張らせてみた Multica・Obsidian・Piで、仕事を迷子にしないための運用記録 河野 英資（Eisuke Kawano）
2. この発表をする理由 Agentは毎日動き、IssueやPRは増えていました。しかし僕自身は、どの仕組みが何を見て、どこで次のAgentへ 渡し、どこから人間が判断しているのかを、ひと続きの流れとして説明できていませんでした。 今日は、実際に動かしている運用を一度整理し、今どこまでできていて、何がまだ難しいのかを共有します。 この発表を作ることで、自分の仕組みがどう動いているのかを一度整理しました。
3. 自己紹介 河野 英資 Eisuke Kawano フリーランスのRobloxクリエイターとして、ゲームの企画と実装をしています。そ の一方で、Pi向けの小さな拡張機能やOSSも作っています。 最近は、自分の困りごとを解決するツールを作り、OSSとして公開し ています。
4. 複数のプロジェクトを並行して進めるために始めた きっかけは、OpenClawプロジェクトを始めたことで 知られるPeter SteinbergerのAgent運用を見た ことでした。 複数のコーディングエージェントへ別々のプロジェクト を任せ、人間は設計、レビュー、次へ進める判断に集 中する。その運用を自分でも試したいと思いました。 複数のプロジェクトをまとめて並行して進めるため に、小さなプロジェクトを並べて実験を始めました。
5. プロジェクトが増えて起きたこと 小さなOSS、保守プロジェクト、プロダクト試作 を合わせて、現在は42プロジェクトあります。 公開した39パッケージは、直近30日でnpmか ら合計30,534回取得されました。download 数は、どのツールを先に保守するか決めるため の粗い目安として使っています。 難しくなったのは、コードを書くことより、次に何 をするか、誰が持っているか、どこで止まってい るかを把握することでした。
6. 記憶・状態・実行を分ける Obsidian 記憶 背景、設計、過去の判断を残す。 Multica 状態 仕事が今どこにあるかを持つ。 Pi 実行 最小限の道具を持つコーディングエー ジェントが作業する。
7. Obsidianでさまざまな情報を管理する ツェッテルカステン（Zettelkasten）を参考に、日次メモ、記事、知識、仕様、判断、進捗をMarkdown noteとして保 存しています。 Fleeting 日次メモ 思いつき → Literature 記事 外部情報 → Permanent 再利用する 知識 → Project 仕様・判断 進捗 → Structure 索引 入口 Agentは過去の会話ではなく、保存された背景・仕様・判断を読んで仕事を始めます。
8. Multicaで複数の仕事の状態をまとめる 仕事の状態がcloudへ保存され、登録した複数のPC から同じIssueとAgentを扱えます。 良いところ WindowsのメインPC、常駐させているMac mini、普段使う MacBookの3台を登録しています。iOS実装はMac miniへ渡 し、今使っているPCでAgentを動かせない場合は、別のPCの Agentへ仕事を渡せます。 難しいところ 現在のAutopilotでは単純なscriptを直接実行できず、Agent 経由で起動します。短い定期処理でも起動時間とmodel利用が 発生します。
9. Piでエージェントができることを狭める Agentを目的へ集中させるには、できることを増やすより、必要な 道具だけを渡すほうが分かりやすいと考えています。 良いところ Piは最小構成から始め、必要な拡張機能とtoolだけを追加できます。選択肢を減ら すことで命令を通しやすくし、余計な作業へ進む可能性を下げられます。 難しいところ 構成は手作業です。必要なtoolを入れ忘れたり、合わないtoolを渡したりすると、 Agentが遠回りするか作業を完了できません。軽いmodelではtoolを使えず、編 集を壊したり止まったりする場合もあります。
10. 仕事に合わせてモデルを選ぶ 判断軸は、仕事の難しさ、変更リスク、読む情報量、速度、コストです。全部を同じモデルへ任せません。 OpenAI Codex / GPT-5.5 重要な意思決定、設計、難しい原因調査。 OpenAI Codex / GPT-5.3 Codex Spark 高頻度の分類、監視、queue判断。 Cursor / Composer 2.5 仕様と完了条件が決まった通常の実装。 Z.AI / GLM-5.1・GLM-5-Turbo・GLM-4.7 複雑なtriage、routing、軽量な分類・監視。 Z.AI / GLM-5.2 Cursorが動かない場合の実装fallback。 DeepSeek / DeepSeek V4 Flash Z.AIの障害や利用上限時の従量課金fallback。
11. Agentが持つ道具も仕事ごとに替える 調査Agentには検索とWeb取得。実装Agentには編集、test、PR作成。小変更Agentには必要最小限の編集機 能だけを渡します。 モデル、Piの拡張機能、Skill、toolの組み合わせをAgent bundleとしてGitで管理しています。万能Agentを1 人作るのではなく、役割に必要な能力だけを持つAgentを複数用意します。 道具を絞ると、誤操作が減り、読む説明も減ります。軽いモデルでも「今やるべき仕事」を理解しやすくなります。 能力を増やすだけでなく、不要な能力を持たせないことも設計です。
12. 決まった行動はPython scriptへ移す 実行結果をfeedback dataへ残し、週1回見直します。そこで繰り返し発生している、判断が不要な処理をPython scriptへ移しています。 実行結果を残す 手戻り・停止理由・costを圧縮する → 週1回見直す 同じ失敗と無駄な判断を見つける → Pythonへ移す 決まったcodeとして固定する 同時にqueueへ入れる仕事数、1日に開始するPR作業数、review待ち件数の上限を計算します。同じIssue・PRへの二重 着手と、処理直後の同じPRを何度も確認することをcooldownで防ぎます。 決まったcodeはPython scriptへ。Agentには曖昧さ、例外、差し戻し先の判断だけを残します。 現在は運用・test用を含めて97本。将来は、散らばったPython scriptを共通CLIへ段階的に移す予定です。
13. Autopilotが拾っている変化 GitHubへ届いたIssue bug、regression、security、install失敗など、新しく報告された問題。 公開中PRのCI結果 testやpublish workflowが失敗し、作業が止まっている状態。 人間やCodeRabbitからの修正要求 reviewで届いた、具体的に対応できる指摘。 npmからの取得回数 どの公開packageを先に保守するか決めるための目安。
14. Autopilotは仕事を始める前に条件を確認する Autopilotは、AIに好きなものを作らせる機能ではありません。決められた時間に仕事を探し、実行可能なものだけを 次へ送ります。 変化を拾う Issue・CI・review → 仕事の候補を作 る local Issueも入口 → 開始条件を確認 依存・重複・利用上限 → Agentを選ぶ 仕事に合う役割 → 実装とtest PRと証拠を残す → reviewを修正 指摘を次のIssueへ → 人間へ戻す 判断できる状態
15. 人間を外すのではなく、判断できる状態まで運ぶ Agentが揃えるもの 実装、test結果、変更理由、確認command、残っている risk、review指摘への修正。 人間が判断するもの 最終review、merge、publish、大きな仕様変更、方向転 換、公開してよいかの判断。 目的は、人間の判断が必要な場所まで仕事と証拠を途切れさせないことです。
16. 段階が変わるたびにAgentとsessionを替える 調査、実装、reviewは、最終目標が同じでも、読む情報と守る条件が違いま す。 全部を1つのsessionへ詰め込むとcontextが増え、作業が遅くなります。 軽いモデルでは指示を整理しきれず、同じ場所を回ったり止まったりします。 前の会話全文ではなく、次の段階に必要な状態だけを渡します。 /new 会話は切る。 仕事の状態は切らない。
17. 次のAgentへ渡す4つの状態 入口 なぜ必要か。最初にどのIssue、設計、fileを読むか。 完了条件 どこまで直すか。変えてはいけないものと、通すtestは何か。 証拠 PR、差分、test結果、確認command、screenshotなど、次の人が確認できるもの。 差し戻し先 問題があれば誰へ戻すか。Agentが判断できない場合は人間へ戻すか。
18. reviewの指摘を次の仕事へ変える CodeRabbitの指摘を次のIssueへ変え、別Agentが同じPRを修正しました。再reviewでは追加修正コメントなし。残っ たwarningも含めて人間が確認し、mergeしました。
19. 人間は、最初の目的と最後の判断に集中できる 人間 目的・完了条件 を決める → Agent 実装・test review修正 → 人間 証拠を確認 merge・差し戻し 人間が最初と最後を担い、その間の作業をAgentへ任せられることが、この運用の強みです。
20. まとめ 発表を作ることで、自分でも曖昧だった運用の流れを初めて整理できました。 Obsidianに情報を残し、Multicaで状態をつなぎ、Piで実行する。 人間が最初の目的と最後の判断を担い、途中の作業をAgentへ任せる。 会話は切っても、入口・完了条件・証拠・差し戻し先は残す。 今後は、各プロジェクトの仕様・test・review基準を整え、人間へ返す判断材料の質を上げる。