見出し画像

[Hermes agent] Orbを仕事に統合してわかった。足りなかったのはPromptではなく、プロジェクト管理だった

Karry

Agentの話になると、どうしても能力の話になりがちです。どこまで自律できるのか、どれだけ賢いのか、Promptをどう書くのか。

でも、この数ヶ月で自分がいちばん強く感じたのは、そこではありませんでした。

自分にとって本当に重要だったのは、一回うまく返せるかどうかではない。三ヶ月後も、半年後も、案件がちゃんと前に進み続けているかどうかでした。

だから今の自分は、「Orbをどう使うか」より先に、「Orbをどう仕事の構造の中へ入れるか」を考えるようになりました。

そして、ここでいちばん難しいのは、作ることではありません。難しいのは、長く保ち、崩さず、回し続けることです。

本当の問題は、一文うまく書けるかではなく、連続した仕事を受け止められるかだった

いまの自分の仕事は、かなり連続性が強いです。

複数のpre-salesやPoC案件を並行で進めながら、提案書も書くし、構成も詰めるし、会議メモも整理するし、対外向けの最終稿も作る。そのあいだにも前提は変わるし、論点は増えるし、優先順位も動く。

こういう仕事は、一回の問答では終わりません。

今日の原資料が、明日の判断になり、明後日のドラフトになる。さらに次の会議で前提が更新され、その次には顧客向けの言い方に直す必要が出てくる。

もしOrbが会話の中だけでうまく振る舞う存在にとどまるなら、それは確かに便利です。でも、それだけでは現実の仕事を受け止めきれない。

自分が欲しかったのは、その場でそれっぽく返してくれる存在ではなく、仕事の文脈を引き継ぎながら、次の状態へ運んでくれる存在でした。

最初に踏んだ罠は、Promptではなく、構造が立っていなかったことだった

振り返ると、最初の頃からOrbはかなり使っていました。壁打ちもしたし、草案も作ってもらったし、言い回しの調整も相当助けてもらっていた。

でも、あの頃の自分はOrbを呼び出していただけで、まだ仕事の中には入れられていなかったと思います。

問題はだいたい三つありました。

ひとつ目は、案件ごとの入口が安定していなかったことです。新しい依頼が来るたびに背景を説明し直し、案件が切り替わるたびに、また最初から温め直していた。

ふたつ目は、情報が分かれていなかったことです。原資料、会議での判断、途中のドラフト、最終版が混ざると、どれが現時点の真実なのかがすぐ曖昧になる。

三つ目は、会話の中で出た結論が仕事側へ戻っていなかったことです。せっかく良い整理ができても、回写されなければ、次回また同じ話から始まる。

その頃に強く感じたのは、Orbの出力が不安定だったというより、出力を受け止める側の構造がまだ立っていなかった、ということでした。

まず、いま自分が使っている構造を見せたほうが早い

この話は、抽象語だけで書くとすぐに薄くなります。

なので、かなりそのままに近い形で、いま自分が日常的に使っているworkspaceの骨格を書いておきます。

~/.hermes/
├── workspace/
│   ├── AGENTS.md
│   ├── procedures/
│   ├── docs/references/
│   └── memory/
│
├── work/
│   ├── INDEX.md
│   ├── DASHBOARD.md
│   ├── SYNC_POLICY.md
│   ├── openviking-import-registry.yaml
│   ├── projects/
│   ├── partners/
│   └── psr/
│
└── scripts/

大事なのは、ディレクトリが多いことではありません。役割が切られていることです。

  • workspace/ には、ルール、参照、手順、記憶を置く

  • work/ には、プロジェクト、ルーティング、状態、資産を置く

  • scripts/ には、自動化と保守の動線を置く

Orbは、ただ会話ログの上で働くのではなく、この分かれた構造の上で働くようになりました。

さらに、個別のprojectの中では、少なくとも次の四層を維持するようにしています。

00_source   原資料
01_meetings 会議メモと意思決定
02_draft    分析、中間稿、構成整理
03_delivery 最終成果物

この四層は地味ですが、かなり効きます。

Orbが読んでいるものが原文なのか、会議で更新された判断なのか、まだ途中の草稿なのか、もう対外版なのか。そこがここで切り分けられるからです。

そしてprojectより上の層には、さらに三つの骨格があります。

  • registry：プロジェクトのメタデータの真実源

  • INDEX：全体のルーティング

  • DASHBOARD：現在地を俯瞰するための面

本当に効くworkspaceは、フォルダが多いものではありません。ディレクトリ、ルール、入口、状態管理、保守が、一緒に回るものです。

このworkspaceは、単なる整理ではなく、連続した仕事の流れを支えるためにある

フォルダ構成だけを見ると、単にきれいに整理しているだけに見えるかもしれません。

でも、自分が欲しかったのは整理そのものではなく、入力、判断、出力、回写がつながることでした。

その流れをかなり単純化すると、こんな形です。

新しい入力が入る
      ↓
project入口 / registry を更新する
      ↓
source / meetings / draft / delivery に分けて置く
      ↓
Orbが整理された文脈をもとに分析と下書きを進める
      ↓
人間が重要な判断と対外版をレビューする
      ↓
結果をproject側へ回写する
      ↓
INDEX / DASHBOARD / knowledge mirror を更新する
      ↓
次の仕事でそのまま再利用する

この流れの中で自分が見ているのは、「どれだけAIを挟んだか」ではありません。一歩進むごとに、状態がより明確になっているかどうかです。

つまり、project内部の階層が乱れず、workspace全体の入口も崩れず、前回の結果が次回にちゃんと残る。この三つが揃って、はじめてOrbが継続した仕事の中に入れるようになった。

いちばん実感したのは、案件をまたぐ瞬間だった

この差がいちばん分かりやすく出るのは、案件をまたぐ瞬間です。

以前は、新しい案件に入るたびに背景説明から始まっていました。どの資料が元で、どの会議で何が変わって、いま何が論点なのかを、その都度もう一回まとめ直す必要があった。かなり地味ですが、これはかなり消耗します。

たとえば、午前に案件Aの会議を終えて、午後に案件Bの提案書修正へ入り、夜に案件Cの構成だけ先に詰める日があります。前のやり方だと、そのたびに頭の中で文脈を持ち替えながら、Orbにもゼロから説明し直す必要がありました。会議で決まったことはどこに置くのか。仮説と確定事項は何が違うのか。いま見せるべき資料はどれか。そこが曖昧なままだと、会話は成立しても、仕事としては少しずつズレていきます。

いまは、入口が先に立っているので、その案件でいま見るべき材料と、更新済みの判断が最初から分かる。Orbもその前提で入れるので、毎回ゼロから温め直さなくていい。

この差は、単に速いか遅いかではありません。思考のエネルギーを、毎回の再説明に使うのではなく、今回どこを深掘りするかに使えるようになる。自分にとって大きかったのは、むしろそこでした。

ここから先で本当に難しくなる。作ることではなく、30日後に劣化させないこと

正直、最初の形を作るだけなら、そこまで難しくありません。フォルダを分けて、入口ファイルを作って、最低限のルールを書けば、ひとまず回り始めます。

難しいのは、そのあとです。

しばらくすると入口が増え始めます。チャットにしかない最新版、ローカルにだけある修正版、送付済みだけど反映されていない版、会議で口頭合意したのに文書化されていない判断。こういうものが少しずつ積み上がって、どこが現在地なのかがぼやけていく。

同時に、階層も崩れやすい。急いでいると、会議で出た仮説をそのまま本文に入れてしまったり、古いドラフトを現行案として扱ってしまったりする。そうなると、Orbの問題というより、自分たちが曖昧な床の上で作業している状態になります。

もうひとつ大きいのが、産出物はあるのに沈殿しないことです。会話の中で良い構成が出ても、やり方として残らなければ、次回はまたゼロに近いところからやり直しになる。

ここに気づいてから、自分は構築より保守のほうを強く意識するようになりました。

後から足したのは、機能ではなく、メンテナンス機構だった

その後に固定化したのは、派手な新機能ではありませんでした。

まず、入口を安定させることです。案件ごとに「まずここを見る」という場所を決めておく。これだけで、毎回の立ち上がりがかなり変わります。

次に、情報を階層のまま置くことです。原資料は原資料のまま、会議判断は会議判断として、中間稿は中間稿のまま残す。混ぜないだけで、あとから読み返したときの解像度が大きく変わる。

そして、write-backを外さないことです。会議で更新された判断、会話の中で詰まった構成、確定した最終版を、その都度ちゃんと仕事場へ戻す。これをやらない限り、どれだけ賢くても、毎回ほぼ初対面に近い状態になります。

最後に、archiveとskillです。古い版はarchiveへ寄せる。再利用できるやり方はskillとして残す。そうすると、Orbが引き継ぐのは単なるテキストではなく、仕事の進め方そのものになる。

ここまで来て、やっと少しずつ見えてきました。大事なのは高機能な箱を作ることではなく、劣化を防ぐ仕組みを日常の中に置くことなのだと。

OpenClawからHermesに来て、ようやくこの形が成立した

ここで誤解されたくないのは、フレームワークを替えたから全部解決した、という話ではないことです。

ただ、自分の体感としては、OpenClawの段階では長い仕事を預けるにはまだ不安定でした。短い往復なら助かる。でも、案件をまたいで継続させたり、回写や記録まで含めて運用したりすると、どこかで漂いやすかった。

Hermesに来て大きかったのは、Orbを仕事の枠組みに収めやすくなったことです。ルール、記憶、案件、回写、skillが別々に存在するのではなく、ひとつの運用としてつながりやすくなった。

自分にとって重要だったのは、Orbが「もっと賢く見える」ことではありませんでした。仕事の中で、安定して働き続けられる形に近づいたことのほうです。

最後に

最近の自分は、ますますこう考えるようになっています。

Promptが決めるのは、一回の出力です。Orbが本当に働き続けられるかどうかを決めるのは、仕事の構造と、プロジェクト管理のほうでした。

もっと言えば、システムを作ること自体はそこまで難しくありません。難しいのは、それを劣化させず、更新し続け、次の仕事にも使える形で保ち続けることです。

Orbを仕事に統合するというのは、便利な会話相手を増やすことではありませんでした。仕事の流れそのものを、少しずつ継続可能な構造に変えていくことだった。

自分にとって、そこがいちばん大きな変化でした。

いいなと思ったら応援しよう！