Multica × 長期記憶：40個のミニプロジェクト管理

Transcript

1. Multica × 長期記憶： 40個のミニプロジェクト管理 プロジェクトを、記憶・状態・実行に分けて管理する 河野 英資 / Eisuke Kawano / eiei
2. 自己紹介 RobloxとPi Coding Agent向けOSS をつくり、約40件を並行しています。 普段はRobloxクリエイターとして、ゲームの企画と実 装をしています。最近はPi Coding Agent向けの小 さな拡張機能などのOSSを作っています。 公開パッケージは36件ほど。直近30日間の取得回 数は、合計で約1.6万回でした。
3. OpenClaw開発者の並行運用に学ぶ 多数のプロジェクトを、Agentと並行して 回す。 きっかけは、OpenClawの開発者Peter Steinbergerさんの活動でした。Peterさんのよう に、多数のプロジェクトをAIエージェントと並行して回 す運用を、自分でも再現できないかと思って始めまし た。 小さなプロジェクトを並べて、運用を実験していま す。
4. Multicaの開発者と公開プロジェクト 開発者は、AIの知見も公開している。 Jiayuan Zhangさんは、以前話題になったスキルを 公開していた開発者です。 そのスキルはAndrej Karpathyの考えをもとにし た、Claude Code向けのものでした。Xでたまたま そのリポジトリが流れてきて、Multicaのことを知り ました。 “Your next 10 hires won't be human.” Building the platform to make that happen.
5. 目指している運用 人間は、ゴール設定・設計・確認・軌道修正に集中する。 ゴール設定 人間が決める → 大まかな設計 人間が決める → 実装 Agentに任せる 細かな実装をずっと見続けなくても、プロジェクトが進む状態を目指す。 → 動作確認・QA 人間が確認する
6. 全体構成 Obsidianを入口に、MulticaからAgentを動かす。 Obsidian 方向性・実装状況 → Multica タスク・状態・方針 今回は、真ん中のMulticaを中心に話します。 → Pi Coding Agent Agentが作業 → GitHub 各リポジトリのコード
7. 長期記憶の構成 Zettelkastenで、メモとプロジェクトをまとめ る。 Obsidian 基本はMarkdownリーダー。 Vault root/ ├─ 1_Fleeting/ ├─ 2_Literature/ ├─ 3_Permanent/ ├─ 4_Project/ ├─ 5_Structure/ └─ CONTEXT-MAP.md 日々のメモ 外部情報 長く使う知識 プロジェクト 案内図・索引 探索の入口 ドキュメント 背景・目的・設計・過去の判断を残す。 探索 OKFでファイル関係を定義・地図化し、QMDで探す。
8. Multica：AIエージェントをチームの一員に Multicaは、仕事の状態と担当をまとめて扱うオープンソース基盤です。 Claude CodeやCodexなどのAIエージェントを、チームの一員として扱います。プロジェクト、担当者、実行場所、 定期実行を一つのワークスペースで管理できます。 ここから、自分が使っている機能に絞って紹介します。
9. 人間とAgentを同じワークスペースで扱う 人間もAgentも、Issueの担当先として 選べる。 ワークスペースには、人間もAgentもメンバーとして 参加します。Issueの担当者を選ぶと、人間のメンバ ーと複数のAgentが同じ一覧に出てきます。 マネージャー役のAgentから、人間や別のAgentへ 仕事を割り当てることもできます。特定の人間の判断 が必要な仕事は、その人へ直接アサインします。 便利そうな一方で、少し怖さもあります。
10. プロジェクトの状態管理 Issuesで状態を追い、Projectsで仕事をまとめる。 40件ほどのプロジェクトを並行していても、次に何をするか、誰が担当か、どこで止まっているかを一か所で確認できます。
11. Autopilot：定期的に状況を確認する Autopilotは、決めた時間にプロジェクト を自動で確認する仕組み。 人間が40個のプロジェクトを一つずつ見に行かなく ても、登録したプロジェクトに変化がないかを確認し ます。 IssueやPR、CIの失敗など、設定した条件に当ては まるときだけ、タスク候補を作ります。何もなければ、 何もしません。
12. Autopilot：動かし方を設定する 誰が、何を、いつ確認するかを決める。 設定ごとに、担当Agent、対象Project、実行する時 間を指定します。条件に合ったときにIssueを作る か、確認だけで終えるかも選べます。 どのプロジェクトを、いつ、どのAgentに確認させる かを先に決めておきます。
13. RuntimesとAgents 動かす場所と担当者を、役割に合わせて選ぶ。 RuntimesはAgentを動かすPCと実行環境、Agentsは調査・実装・修正・計画などの役割を管理します。
14. Obsidianを入口に、タスクと方針をまとめる 各リポジトリを直接開かず、Obsidianを 入口に整理する。 各プロジェクトの方向性や実装状況をドキュメントに まとめ、その内容をもとにタスクを積んだり、次の方 針を決めたりします。 必要なタスクが決まったら、MulticaからAgentを 起動し、Agentが該当するGitHubのリポジトリで実 装します。 人間が各リポジトリやコーディングエージェントを一 つずつ開いて回る運用ではありません。
15. Pi Coding Agent：タスクごとに設定を絞る Pi Coding Agentでは、タスクごとに設定を変える。 システムプロンプトやAgent設定を書き換え、タスクの目的に合わせて役割を調整します。 必要なツールと権限だけを持たせ、不要な操作はできないようにします。 渡す情報もタスクに必要な範囲に絞り、実行範囲を調整しています。 役割・ツール・権限を、タスクに合わせて最小限にする。
16. トークン効率化：ログから定型処理を減らす 実行ログを見直し、Agentの繰り返しを減 らす。 Multicaには、AgentのTool callやThinkingな ど、作業のログが残ります。週に1回ほどログを見返 し、同じ処理はPythonスクリプトに切り出します。 定型処理をスクリプトに移すことで、トークンとコスト を抑えます。 Agentには、判断が必要な仕事だけを残す。
17. まとめ 記録 背景・目的・判断をドキュメントに残す。 管理 Multicaで状態と次のタスクをそろえる。 Agent設定 タスクに必要な役割・ツール・権限だけに絞る。 人間の判断 ゴール・レビュー・軌道修正に集中する。 ここまでやってきて、Agentに任せる量を増やすより、タスクごとに設定を絞ることが大切だと思いました。
18. ご清聴ありがとうございました