人と AI エージェントをまたぐ仕事のための共有レイヤー
AI エージェントの実行能力は向上しています。しかし実際の仕事は、人、エージェント、セッションをまたいで進むことが少なくありません。Epismo は、再利用可能な仕事の進め方と、そうした引き継ぎを越えて残り続ける必要がある実際の案件の両方を、チームで共有するためのレイヤーを提供します。
はじめに
AI エージェントは、ますます複雑な仕事をこなせるようになっています。Skills を使い、MCP 経由でツールを呼び出し、グラフを実行し、サブエージェントと連携し、高度なループを回しながら反復することもできます。しかし、実行能力が高まるにつれて、別の問題がよりはっきり見えるようになってきました。人とエージェントの間を仕事が移動するとき、その仕事自体はどこに存在するのでしょうか？
たとえば、ある人が Claude Code で作業を始めたとします。別の人がその結果をレビューし、重要な前提を変更します。翌日には、さらに別の人が Codex を使って同じ仕事を引き継ぎます。それぞれが高性能なエージェントと優れた環境を持っていたとしても、その仕事の状態は、セッション、チャット、ドキュメント、そして個々人の記憶の中に分散してしまいます。
次に担当する人が必要とするのは、最新の成果物だけではありません。何をすでに試したのか、何が決まったのか、なぜ方針が変わったのか、中間作業のうち何が重要なのか、そしてまだ何をする必要があるのかを知る必要があります。
Epismo は、この問題に対して2つの共有オブジェクトを中心に設計されています。再利用可能な仕事の進め方を保持する「プレイブック」と、人や AI エージェントの間を移動していく実際の仕事を保持する「案件」です。
📖 TOC
- プレイブックは仕事の進め方を保持する
- 案件は実際の仕事を保持する
- コラボレーションは案件を中心に行われる
- 残す必要があるものだけを実体化する
- 案件がプレイブックを改善する
- エージェント実行の上にある共有レイヤー
- 中心にあるのはプレイブックと案件
プレイブックは仕事の進め方を保持する
AI から継続的に良い結果を得ている人は、単に良いプロンプトを持っているだけではありません。彼らは独自の仕事の進め方を築いています。問題をどう分解するか、どのようなコンテキストを与えるか、どのツールや Skills を使うか、何を検証するか、どこで人間の判断が必要になるか、そして有用な結果とはどのようなものか、といった方法論です。
プレイブックは、その方法を再利用可能にします。
プレイブックには、推奨される手順、指示、期待される成果物、さらに Skills、グラフ、MCP サーバー、ドキュメント、その他のエージェントハーネスといった有用なリソースを記述できます。ただし、プレイブックはそれらのシステムを置き換えるためのものでも、Skill をより表現力豊かにしたものでもありません。
Skill やグラフには、すでに完全な実行方法が含まれている場合があります。違いは、それらが通常、特定のエージェントやランタイムに属していることです。プレイブックが表すのは、ある種類の仕事に対してチームが共有するアプローチであり、最終的にどのランタイムがそれを実行するかには依存しません。
この分離は重要です。実行レイヤーは急速に変化するからです。現在は Claude Code、Codex、OpenClaw、あるいは社内エージェントを使っているチームでも、6か月後には別のツールを使っているかもしれません。再利用可能な方法論まで、それらのツールとともに消えてしまう必要はありません。
案件は実際の仕事を保持する
再利用可能な方法と、実際の1件の仕事は別のものです。
プレイブックは、ソフトウェアアーキテクチャのレビュー方法、インシデントの調査方法、リサーチの進め方、プロダクトアイデアの評価方法などを記述できます。一方、案件は、その仕事の具体的な1件です。
案件によって、その仕事は個々のエージェントセッションから独立したアイデンティティを持てるようになります。担当者が変わっても、エージェントが変わっても、あるいは作業がいったん中断され、後から再開されても、その案件は存続できます。
案件が進展していく中で、人やエージェントは、今後に引き継ぐ価値のある情報を添付できます。中間結果、意思決定、レビューコメント、ファイル、引き継ぎ用のコンテキスト、最終成果物などです。Epismo では、これらを「記録」と呼びます。
目的は、エージェント内部で起きていることをすべて再現することではありません。ランタイム内部では、何十回ものツール呼び出し、リトライ、グラフ遷移が発生しているかもしれませんが、それらを他の人がすべて見る必要はありません。重要なのは、次の参加者がそうでなければ再構築しなければならない情報を残すことです。
ここに、ランタイムの状態と仕事の状態との重要な違いがあります。ランタイムの状態は、エージェントが実行するために役立ちます。案件の状態は、チームが仕事を理解し、継続するために役立ちます。
コラボレーションは案件を中心に行われる
AI を活用した仕事は、しばしば「1人の人間が1つのエージェントに仕事を任せるもの」として語られます。しかし、実際の組織では仕事は移動します。
ある人がエージェントを使って分析を始め、同僚がそれをレビューする。そのレビューによって方向性が変わり、別の人が異なるエージェントを使って引き継ぐ。さらに、作業を続ける前に、専門家が特定の質問に答える必要がある場合もあります。
その経路は、もはや単純な「人から人」や「人からエージェント」ではありません。たとえば、次のようになります。
人 → エージェント → レビュアー → 別の人 → 別のエージェント
このような環境では、単に担当者を変更するだけでは不十分です。有用な引き継ぎには、現在の成果、関連する意思決定、重要な中間作業、そして次の参加者が必要とするコンテキストも含まれます。
案件は、その継続性を支える共有の場所を提供します。
明示的な調整が必要な場合には、案件に「タスク」を持たせることもできます。たとえば、レビュアーが成果物を承認する必要がある場合や、別の人が特定の問題を調査しなければならない場合です。ただし、タスクは Epismo の中心ではありません。案件に明確な担当、レビュー、あるいは引き継ぎが必要なときにだけ存在します。
1つのエージェントがすべてを単独で完了できるのであれば、タスクがまったく存在しないこともあります。
残す必要があるものだけを実体化する
継続性の問題に対する1つの解決策は、すべてのエージェントが行うことをすべて記録することです。しかし、私たちはそれが必要だとは考えていません。
Claude Code がプレイブックに従い、作業を完了して良い結果を返せるのであれば、Epismo がその会話履歴全体や、すべてのツール呼び出し、内部グラフのあらゆる状態を保存する必要はありません。
その代わりに、Epismo は**materialize-on-demand（必要に応じた実体化）**という原則に従います。情報は、それを生み出したランタイムの外でも価値を持つようになった時点で、共有状態になります。
中間結果に人間のレビューが必要になった？ 残します。
意思決定によって仕事の方向性が変わった？ 残します。
別のエージェントが前の参加者からのコンテキストを必要としている？ 引き継ぎ用の要約や、関連する記録を残します。
内部でリトライが発生したが、他の誰も知る必要がない？ ランタイム内部に留めます。
こうすることで、Epismo は別の実行エンジンやテレメトリーストアになるのではなく、コラボレーションに集中できます。
案件がプレイブックを改善する
プレイブックと案件の関係は、フィードバックループも生み出します。
プレイブックは、ある種類の仕事に対する現時点での最善の進め方を記述します。しかし、実際の案件を通じて、その方法のどこを改善できるかが見えてきます。重要な質問はもっと早い段階で尋ねるべきだった、期待される成果物の定義が曖昧だった、人間によるレビューは別のタイミングで必要だった、といったことが分かるかもしれません。
そうした学びは、プレイブックを改善するための「改善提案」になります。
サイクルはシンプルです。
プレイブック → 案件 → 実際の仕事からの学び → 改善されたプレイブック
こうして、個人の仕事の進め方を、徐々にチームの能力へと変えていくことができます。ある人がより良い方法を見つけ、他の人がそれを再利用し、実際の仕事によって弱点が明らかになり、その方法が改善されていきます。
必要に応じて、プレイブックは1つのチームを越えて共有することもできます。有用な仕事の進め方が、非公開のチャット、ローカル環境、個人の習慣の中に埋もれたままである必要はありません。
エージェント実行の上にある共有レイヤー
現在、エージェントハーネス、グラフエンジニアリング、ループエンジニアリングをめぐって、多くの興味深い取り組みが進んでいます。こうしたアプローチは、個々のエージェントが複雑なタスクをよりうまく実行できるようにします。ツール利用、反復、コンテキスト管理、復旧、制御などを改善するものです。
Epismo が関心を持っているのは、仕事が1つのハーネス、1つのグラフ、1つのループ、あるいは1つのセッションよりも長く存続するようになったときに重要になるレイヤーです。
グラフは、エージェントシステム内部の実行を管理できます。Skill は、有用な能力をパッケージ化できます。ループは、エージェントがより良い結果に到達するのを助けられます。
しかし、人間が方向性を変えたり、別のエージェントが続きを担当したり、仕事が翌日まで持ち越されたりする場合、チームにはその仕事自体が存在し続けられる場所が必要です。
だからこそ、Epismo はエージェントランタイムを置き換えようとはしません。実行は、人々がすでに使っているエージェントやツールに任せるべきです。Epismo は、その周囲に共有レイヤーを提供します。
ランタイムが変わっても、案件は同じままです。
中心にあるのはプレイブックと案件
Epismo を理解する最もシンプルな方法は、この2つの概念から考えることです。
プレイブックは、ある種類の仕事をどのように進めるかという、再利用可能な方法です。
案件は、人とエージェントが一緒に継続していく、実際の1件の仕事です。
記録は、案件の中で今後に引き継ぐ価値のある部分を保持します。タスクは、明示的な調整が必要なときに登場します。改善提案は、実際の案件から得られた学びを、より良いプレイブックへと還元します。
それ以外のすべては、この2つのオブジェクトを支えるためにあります。
AI がチームの仕事における当たり前の参加者になっていくにつれ、この区別はますます重要になると私たちは考えています。強いチームは、単に高性能なエージェントを持っているだけではありません。優れた仕事の進め方を再利用し、担当が変わるたびにコンテキストを一から再構築することなく、実際の仕事を継続できるチームです。
プレイブックは方法を残す。案件は仕事を残す。
それが、私たちが Epismo で構築している共有レイヤーです。