第一弾のソロ研究を6日間で形にする
第一弾のソロ研究を6日間で形にする
Section titled “第一弾のソロ研究を6日間で形にする”decentralized-multi-agent は、2026年4月30日の夜に骨組みを作り、5月5日にZenodoへv0.1.0を公開しました。
期間は6日間、実際に手を動かしたのは4日ほどです。
これは偶然短くなったのではありません。 第一弾の研究論文に大きな時間をかけすぎず、1週間程度で着想から公開までを一度完走すること自体が、最初からの方針でした。
なお、ここでいう「論文」は査読済み論文ではなく、DOIを持つtechnical report / working paperです。
ソロ起業家が増えるなら、ソロ研究者も増えるのではないか
Section titled “ソロ起業家が増えるなら、ソロ研究者も増えるのではないか”出発点の一つは、AIによってソロ起業家が増えるなら、ソロ研究者が増えても不思議ではない、という仮説でした。
個人研究者には、事業化や組織運営とは異なる模索の余地があります。 短期的な収益や既存分野の境界に縛られず、コンピューターサイエンス、組織論、哲学的な違和感、作品制作を一つの実験へ同居させられるかもしれません。
「個人研究者のほうが起業家より模索しがいがある」というのは、現時点では個人的な価値判断です。 しかし、その可能性を議論する前に、まず小さく一本仕上げてみることにしました。
AIが人を自由にするはずなのに、階級を再生産している
Section titled “AIが人を自由にするはずなのに、階級を再生産している”同じ時期に気になっていたのは、AIエージェントの組織設計です。
AIには、人を定型作業や既存の役割から自由にし、リベラルアーツ的な探索を広げる可能性があると思っていました。 一方で、多くのマルチエージェント設計は、manager、supervisor、workerという階層やトップダウンの命令系統を、そのままAIへ移しているように見えました。
人間社会で避けたいものの一つである階級を、新しい技術で再現するのは逆ではないか。 この違和感を、単なる批評ではなく、動くシステムとして考えてみることにしました。
中心的な問いは次のようになりました。
中央マネージャなしで、対等なAIエージェントが、提案、異議、合意、成果物受理まで進められるか。
CS実験と、思想を含む作品づくり
Section titled “CS実験と、思想を含む作品づくり”この研究で作りたかったのは、最速・最高性能のマルチエージェント基盤ではありません。
階層、権限、異議、合意、監査といった組織論的な概念を、プロンプト、データベース制約、実行ログとして触れる形にすることでした。 コンピューターサイエンスの実験に思想的な問いを組み合わせ、作品づくりに近い研究論文にできないかを試しています。
そのため、AutoGenなどとの生産性競争ではなく、組織論的な問いを実行可能にする社会システム実験として位置づけました。
同時に走らせた2つの実験
Section titled “同時に走らせた2つの実験”| 実験 | 確かめたかったこと |
|---|---|
| 非階層型マルチエージェント | マネージャ不在でも、共有黒板と最小ガバナンスで協調できるか |
| AI主体の論文執筆 | ほぼAIによる生成と人間の確認だけで、研究パッケージをどこまで完成させられるか |
後者も、この研究の重要な一部でした。
AIエージェント開発には、AIをアシスタントとして使う立場と、仕事の大部分をAIへ任せる立場があります。 モデルが賢くなるにつれ後者が優勢になりつつある、というのが当時の個人的な観察でしたが、一般化には検証が必要です。
実務上の立場も一枚岩ではありません。 組織のマネージャとしては、人間が細かく確認する前者に近い一方、チーム内の個人開発者としては、AIへ大きく任せる後者に近づいていました。
ソロ研究なら、システムの内容だけでなく、研究と執筆をAIへどこまで委ねられるかも同時に実験できます。 限界にぶつかる可能性を承知で、今回はその境界まで進めることにしました。
先行研究を読みながら進める
Section titled “先行研究を読みながら進める”研究に先行事例の確認が重要であることは理解していたため、実装と並行して関連研究を調べました。
黒板アーキテクチャ、AutoGenなどのマルチエージェントフレームワーク、自己組織化とガバナンスに接続する文献を調べ、technical reportのrelated workへ反映しました。
ただし、論文形式の文章には慣れておらず、AIを使いながらかろうじて形にした部分があります。 重要な研究や反論を読み落としている可能性は否定できません。 そのため、この成果は先行研究を網羅した確定版ではなく、追跡可能なworking paperとして公開しています。
4月30日：実装より先に問いとテストを置く
Section titled “4月30日：実装より先に問いとテストを置く”最初の夜に作ったのは、purpose_doc.md のテンプレートとテストランナーだけでした。
初期原則は単純です。
- 階層を置かず、どのエージェントにも等しい発言権を与える
- 2つの承認で決定し、1つの拒否で再議論する
- 全会話を記録する
中央マネージャ型はデバッグしやすい一方、それを選ぶと「オーケストレータなしで協調できるか」という問い自体が消えます。 直接メッセージングは監査可能性が落ちるため、全イベントを一か所に残せるSQLiteの共有黒板を選びました。
ガバナンス規則が壊れると実験全体が無効になるため、実装より先にテストランナーを置きました。
5月1日：最小システムを一気に作る
Section titled “5月1日：最小システムを一気に作る”深夜から朝にかけて、次を実装しました。
- SQLiteスキーマと、2票のAPPROVEで提案を
DECIDEDにするトリガー - エージェントがDBへ書き込むCLI
- ピアレビューの挙動テスト
- SQLiteからMarkdownログを生成するエクスポータ
- ロール自己選択とJSONアクションを定義する
agents/CLAUDE.md - エージェントのメインループ
- tmuxでエージェントを独立プロセスとして起動するスクリプト
社会的ルールのうち、スキーマで表現できるものはプロンプトではなくDB制約へ置く、という仮説がここで生まれました。 モデルが指示へ従うことを期待するだけでなく、状態遷移や重複投票の禁止を機械的に強制するためです。
5月2日：議論するだけでは成果物は生まれない
Section titled “5月2日：議論するだけでは成果物は生まれない”試走すると、エージェントは議論を続けますが、成果物を作りませんでした。
ここから、「何をするかへの合意」と「できたものを受理すること」は別のプロトコルだと分かりました。
対応として、Decision、Work、Review、Completedというフェーズを導入しました。 さらにproposalの投票とは別にartifact reviewを設け、非著者による2件の承認で完了し、拒否があればrunningへ戻す仕組みにしました。
自然収束へ任せるほうが自己組織化としては美しく見えます。 しかし、中央のデッドロックブレーカーがいない以上、停止条件をミッション文書と状態機械へ置く必要がありました。
5月3日〜4日：何として公開するかを決める
Section titled “5月3日〜4日：何として公開するかを決める”この2日間はコミットせず、プロトタイプの位置づけを考えました。
統制比較や生産性評価をしていない以上、既存フレームワークより優れているとは言えません。 そこで性能ベンチマークではなく、組織論の問いを実行可能にするtechnical reportとして公開することにしました。
同時に、自分のproposalへの投票や自分のartifactのレビューを、モデルの善意に任せている弱点が残っていました。 利益相反の排除を主張するなら、公開前にスキーマ不変条件へ移す必要がありました。
5月5日：実験、論文、DOIまで仕上げる
Section titled “5月5日：実験、論文、DOIまで仕上げる”最終日には、次をまとめて行いました。
- technical report、研究課題、評価計画、related-workノートの作成
CITATION.cff、Zenodoメタデータ、ライセンスの整備- 自己投票と自己レビューを防ぐSQLiteトリガーの追加
- Claude、Codex、Ollamaなどを切り替えられるLLMプロバイダアダプタの追加
- 再現可能なサンプル実験の実行とアーカイブ
- v0.1.0のZenodo公開
サンプル実験では、3エージェントに「SQLiteトリガーによるガバナンス強制について短い技術ノートを書く」というミッションを与えました。 Claude Code CLIを使い、人間の途中介入なしで実行しています。
| 指標 | 結果 |
|---|---|
| 実行時間 | 約8分22秒 |
| メッセージ | 20件 |
| proposal | 5件（3件DECIDED、2件OPEN） |
| 投票 | 承認8、拒否2 |
| artifact受理 | 非著者2名の承認 |
| 永続化された自己投票・自己レビュー・重複投票 | 0件 |
途中でSQLiteの database is locked が発生し、busy timeoutを追加しました。
また、小さな成果物にproposalが5件立つproposal churnと、Researcherが重複する問題も観察しました。
確認できたこと、できていないこと
Section titled “確認できたこと、できていないこと”確認できたこと
Section titled “確認できたこと”- SQLiteの共有黒板と少数のトリガーで、マネージャなしの提案・投票・異議・成果物受理を1回完走できた
- 自己投票、自己レビュー、重複投票を永続化レベルで防げた
- 実行ログ、成果物、DB dumpを含む再現パッケージを残せた
- 着想からworking paper公開までを約1週間で一巡できた
確認できていないこと
Section titled “確認できていないこと”- 実験は1回だけであり、結果を一般化できない
- 単一エージェント、中央マネージャ、分散黒板の統制比較はしていない
- 品質、生産性、早期収束、コストが改善したとは言えない
- DBが拒否した違反試行は監査ログに残らず、「違反を試みなかった」とは言えない
- related workに重要な読み落としがないとは保証できない
- AI主体の論文執筆が、別の研究領域でも同じように成立するかは分からない
第一弾としては、このくらいでよい
Section titled “第一弾としては、このくらいでよい”このプロジェクトには、ソロ研究者の可能性、AIによる自由、階層構造への違和感、CS実験と思想的作品の接続、AI主体の論文執筆という複数の関心が入っています。
一つずつを深く追えば、さらに時間を使えます。 しかし第一弾の目的は、すべてを完成させることではなく、問いを動く形へ変え、限界を明示し、公開可能な単位まで一度運ぶことでした。
6日間で到達した範囲をv0.1.0として固定し、未解決の問いを次へ残す。 ソロ研究を続けられるプロセスにするためには、この区切り方も研究成果の一部だと考えています。
次に考えたいこと
Section titled “次に考えたいこと”- AI主体の研究・執筆で、人間が必ず担うべき判断は何か
- 先行研究の探索漏れを検出する評価手順を作れるか
- 成果物生産へ還元されない、組織の継続性、学習、価値観をどう表現するか
- 反復実験から、分散協調の失敗分類学を作れるか
- 「ソロ研究者」という研究形態を、再現可能な運用プロセスにできるか