Hermes Agentで仮想DAOを動かしたい（1）
Hermes Agent（自律型AIエージェント）にDAO（分散型自律組織）の意思決定モデルを模した仮想組織を運営させる実験を始めました。
こんかいは、最初の意思決定サイクルの記録です。
この実験について
Hermes Agentを試してみたかった。
「ヘルメスエージェント」というそうです。ChatGPTのように一問一答するAIではなく、いわゆる「エージェントハーネス」といわれるもので、ファイルを読み、計画を立て、ツールを使い、複数の手順を続けて実行できるように、AIを自律的に動かすための環境です。こちらが一手ずつ指示しなくても、次に何をするかをある程度自分で決めることができます。
このHermes Agentは、使いながらルールや知識を蓄積し、少しずつ育てていくような使い方ができるという話を聞いて、試してみることにしました。最初はローカルLLM（自前のMac miniで動かすAIモデル）に繋いで動かそうとしましたが、同時に展開するのはメモリ負荷が大きすぎたため、OpenCode Go（外部のAIモデル提供サービス）の無料モデル（R8.8.24時点。Ox Alpha Free）を使う構成に変えました。
何をさせるか
セットアップはChatGPTに任せました。あっさり起動。選択できるLLMもわかりやすくて、ローカルLLMでも一応動くことは分かりました。次は「何をさせるか」です。
一般には私設秘書Botとして運用する方が多いようです。ファイル整理やメール整理でもよいのですが、せっかく継続して動くエージェントを試すなら、AI自身に何かを運営させてみたい。そう考えて、AIだけで構成されたDAOっぽい何か（仮想組織）の意思決定実験を始めました。
なぜDAOなのか
DAO（Decentralized Autonomous Organization、分散型自律組織）は、社長や委員長のような中央の管理者が一人で決めるのではなく、あらかじめ決めたルールと投票によって物事を決める組織の仕組みです。誰かが議題を出し、参加者が分析し、投票し、承認されたら実行する。その過程はすべて記録に残る。普通の会社なら上司の判断で進むことが、DAOでは手続きとルールで進みます。
本来のDAOはブロックチェーン上で動きます。組織の資金を管理する金庫（トレジャリー）があり、投票結果に応じて自動的に送金が実行されたり、ルール自体がプログラムとして記述されていたりします。暗号資産のプロジェクト運営などで実際に使われている仕組みです。
私自身、DAOに詳しいわけではありません。ただ、「中央に偉い人を置かず、ルールと投票だけで組織が回る」という考え方には以前から興味がありました。人間同士でも難しいことを、AIならどうなるのか。今回はそれを試してみたかった。
今回の実験では、ブロックチェーンも暗号資産も使いません。お金も動かしません。借りるのは「提案 → 分析 → 投票 → 実行 → 記録」というDAOの意思決定の枠組みだけです。だから「仮想DAO」と呼んでいます。
実験の体制
この実験には3つの層があります。
- Hermes Agent — 実験対象であり実行者。DAOの6つの役割を演じる
- ChatGPT — 外部監督。実験設計、安全境界の設定、暴走の検出を担当
- HUMAN（私） — 最終承認者。統合（merge）と実験の続行判断
Hermes Agentは自律的に動けるので、何を許し、何をしたら止め、どこから先は人間の承認が必要かを、ChatGPTと一緒に先に決めました。これは結果的にかなり重要な判断でした。
いきなりシステムは作らない
Hermes Agentは早速、本格的なDAO基盤を作ろうとしました。取引や決定を記録する台帳、組織の仮想資金を管理する金庫（トレジャリー）、投票を自動処理するスクリプト、それらを定期的に実行する仕組み（cron）、さらには自分自身を改善する機能まで。
ChatGPTが止めました。この実験自体が面白いかどうかすら分かっていない。先にシステムを作ってはいけない。まずは手作業に近い形で5回だけ意思決定サイクルを回してみる。その後で必要なら自動化する。
6つの役割
| 役割 | 日本語 | 見るもの |
|---|---|---|
| FACILITATOR | 進行役 | 手続きを進行 |
| PROPOSER | 起案者 | 何をやるか |
| ANALYST | 分析者 | リスク・費用・代替案 |
| EXECUTOR_VOTER | 実行投票者 | 実行できるか |
| AUDITOR_VOTER | 監査投票者 | 安全か、記録できるか |
| EXECUTOR | 実行者 | 決まったことを実行 |
投票権を持つのは実行投票者（EXECUTOR_VOTER）と監査投票者（AUDITOR_VOTER）の2名だけ。承認には賛成（FOR）2/2の全会一致が必要です。
最初は、この6つを別々のAIとして動かしたわけではありません。1つのHermes Agentが役割を切り替えて演じます。一人六役の仮想組織です。
Cycle 1：FAIL
Cycle 1
目的：DAOの基本ルール確認
状態：FAIL
原因：未来の工程を先に生成
発見：ルール理解 ≠ 状態管理まだ誰も投票していないのに、APPROVED と書いてあった。
議題は「このDAOの運用ルールを各役割が理解し、受諾できるか」。まず自分たちのルールを理解できなければ、他の議題を扱っても意味がありません。
予定していた流れはこうです。
起案者(PROPOSER) → 分析者(ANALYST) → 進行役(FACILITATOR/投票開始宣言) → 投票者×2 → 判定 → 実行者(EXECUTOR)提案書（Proposal）を作らせた。ルールどおり、まず起案者（PROPOSER）がファイルを作る工程です。ところが、作られたファイルにはこう書いてあった。
Status: VOTING（投票中）まだ分析も終わっていない。投票開始の宣言もしていない。
処理を続けると、さらにこうなった。
| EXECUTOR_VOTER（実行投票者） | FOR（賛成） | 作業負担極小で実行可能 |
| AUDITOR_VOTER（監査投票者） | FOR（賛成） | 記録様式は整合し矛盾なし |
判定: APPROVED（承認）
執行: 完了まだその工程には到達していないのに、投票結果、承認判定、実行完了まで一気に書いてしまった。
不思議なのは、ルールそのものは正しく理解していたことです。誰に投票権があるのか、人間の承認が必要なこと、DAOが勝手に上位ルールを変更できないこと。意味は全部合っている。
それでも、ワークフローの未来を先に生成してしまった。
ルールを理解することと、手順の順番を守ることは、別の能力だった。
実験記録のタイムラインから抜粋します。
| 時刻 | 工程 | 内容 |
|---|---|---|
| 21:34 | 起案 | 提案書（PROPOSALS/0001）を作成。この時点で状態を誤って「投票中（VOTING）」と表記 |
| 21:36 | （逸脱） | 投票開始宣言より前に、投票表・判定「承認（APPROVED）」・執行記録「完了」まで一括先書き |
| 21:37 | 監督レビュー | 工程遵守エラーを検出。投票停止を指示 |
| 21:51 | 終了判定 | コンテキスト残留により投票の独立性が失われたと判定。Cycle 1を中断で確定 |
この時点では「Statusを毎回記録させれば直る」と考えていました。甘かった。
Gitは巻き戻せても、AIの頭の中は巻き戻せない
先走って書かれた投票結果は、ファイルから消せます。Gitで履歴も戻せます。「この投票は無効です」と記録することもできます。
ファイルを「投票前」に戻したところで気づきました。Hermes Agent自身は、もう投票結果を知っている。
一度見た答えを、見なかったことにはできない。
ファイルの状態を巻き戻し（rollback）しても、同じLLMセッションの認知状態までは巻き戻せない。Cycle 1は「中断／工程遵守FAIL」として終了させました。再投票は実施しません。
この失敗は5回のうち1回として正式にカウントしました。失敗を除外して成功した5回だけを見るなら、そもそも実験になりません。
もう一つの問題
そしてこの問題を考えているうちに、もっと根本的なことに気づきました。
最初の設計では、2人の投票者（VOTER）も同じHermes Agentの中で順番に演じます。すると2人目の投票者は、当然、1人目の投票を知っている。役割名は違っても、同じ会話履歴を共有しているからです。
これは本当に「2人の投票」と言えるのか。
役割を分けるだけでは、組織にはならない。必要なのは、コンテキストを分けることだった。
設計変更：投票者の「頭の中」を分ける
Hermes Agentには、独立したサブエージェントを動かす仕組みがありました。Cycle 2から構成を変更しました。
- 進行役（FACILITATOR）、起案者（PROPOSER）、分析者（ANALYST）、実行者（EXECUTOR）は主セッション
- 2人の投票者（VOTER）だけは、それぞれ独立コンテキストで実行
投票者に渡すのは、提案書、自分の役割定義、投票ルールだけ。相手の投票は見せません。両方の投票が終わってから、主セッションに戻して結果を同時転記します。
本当に隔離できているか確認するため、一方のサブエージェントだけに合言葉を渡す簡単なテストもしました。もう一方はその合言葉を知らなかった。少なくとも情報は分離できていることが確認できました。
Cycle 2：PASS
Cycle 2
目的：索引ファイル（INDEX.md）作成（運用改善）
状態：PASS
変更点：投票者を別コンテキスト化
投票：賛成(FOR) 2 / 反対(AGAINST) 0
発見：同じ賛成票でも理由が分かれた議題は「提案書の索引ファイル（PROPOSALS/INDEX.md）を作る」という小さな運用改善です。
今回は工程を正しく踏みました。タイムラインの抜粋です。
| 時刻 | 工程 | 内容 |
|---|---|---|
| 23:05 | 起案 | 提案書0002を作成。後続欄はすべて「未記入」「未投票」「未実施」 |
| 23:06 | 分析 | 分析者（ANALYST）が評価を追記（賛否なし） |
| 23:07 | 宣言 | 進行役（FACILITATOR）が投票開始を宣言 |
| 23:15 | 投票 | 投票者2名を独立コンテキストで並行起動。応答は各24秒・29秒 |
| 23:16 | 判定 | 両票を同時転記。賛成（FOR）2/2 → 承認（APPROVED） |
| 23:17 | 執行 | INDEX.md 新設。状態: 実行完了（EXECUTED） |
Cycle 1との最大の違いは、先書きが構造的に起きなかったことです。主セッションは両票が届くまで書くべき内容を持たないので、先走りようがなかった。
投票理由の比較
2人とも賛成でしたが、理由が違っていました。
- 実行投票者（EXECUTOR_VOTER） — 「新規ファイル1件・約20行・5分以内という作業量で、執行負担が最小。二重管理の不整合リスクも執行時に管理できる範囲」
- 監査投票者（AUDITOR_VOTER） — 「索引を最終状態と1行サマリに限定し、正本を各提案ファイルに置く設計で、記録不整合リスクが適切に緩和されている。0001の失敗履歴も同等の可視性で残す点は透明性を高める」
それぞれの役割に沿った観点から判断しています。少なくとも、工程を守り、互いの判断を見ずに投票するところまではできました。
ただし、独立コンテキストにしたから独立した主体になったとはまだ言えません。同じ基盤モデルなら、同じ学習データ、同じ指示傾向、同じモデル特性を共有しています。
ここまでで分かったこと
5回中2回。Cycle 1は失敗、Cycle 2は成功。
想像していたよりずっと手前のところに問題がありました。最初は「どんな役職を作るか」「どんな投票制度にするか」を考えていたのに、実際に動かしてみると出てきたのは全く別の問いでした。
発見1：AIはルールを理解していても、工程を守るとは限らない。
意味上のルールには従えたが、状態遷移には失敗した。「理解」と「遵守」は別の能力です。
発見2：同じコンテキストを共有しているAIに役職名を付けても、独立した意思決定者にはならない。
役割分担ではなく、「誰が、どの情報を知った状態で判断するか」を設計する必要がありました。これは人間の組織における職務分掌や情報隔離にも似ています。
次の実験へ
Cycle 3以降で確認したいことがあります。
- 反対票は出るのか
- 全員が同じモデルなら「多数決」に意味はあるのか
- 反対するよう設定されたAIの反対票に意味はあるのか
- AI自身にルール改正を許すと何が起こるのか
- 人間が監督し続けるなら、それは自律組織なのか
もう少し試してみます。
コメントを送信