OpenExecutive を採用する前に読む: 8人の専門エージェントを1つの経営者人格に束ねる仕組み

誰のどの作業を肩代わりするのか

想定されている利用者は、CFO や法務担当を社内に置けない規模の経営者と、その補佐をする数人だ。README は8つの役割を列挙している。最高戦略責任者、最高財務責任者、人事、法務、最高業務責任者、最高マーケティング責任者、最高製品責任者、そして取締役会コミュニケーション担当。それぞれが競合分析、資金調達モデル、採用と報酬、契約と知財、業務プロセス設計、GTM、ロードマップ、ボード資料といった領域を分担する。

重要なのは、利用者から見えるのが8人ではなく1人だという設計方針である。README は「すべての応答は一貫した1つの経営者の声から出る。内部のエージェント構成がユーザーに露出することはない」と明記している。つまり専門家の集合体を売り物にしながら、その集合体を意識させない。相談のたびに「今から財務の観点で答えます」と切り替わる設計とは逆を行っている。経営会議で欲しいのは部門の見解の寄せ集めではなく、対立点を飲み込んだ結論だから、この選択自体は筋が通っている。

オーケストレーターがツール呼び出しで専門家を並列に呼ぶ流れ

README のアーキテクチャ図は短い。ユーザーのメッセージが Executive Orchestrator（claude-sonnet-5）に入り、ツール使用を通じて専門エージェント群を並列に呼び出す。各専門エージェントは ChromaDB から関連コンテキストを取得し、最後に統合された経営者としての応答が返る。

知識は2層に分かれている。1層目は knowledge/builtin/ に Markdown として git 管理されている組み込みの MBA 相当ナレッジで、起動時に ChromaDB へシードされる。2層目は利用者がアップロードした自社文書で、company_docs という別コレクションにチャンク化して格納される。検索は専門エージェントの呼び出しごとに走る。RAG のコンテキストはユーザー発言側に注入され、キャッシュされたシステムプロンプトには入れない。この分離はプロンプトキャッシュを壊さないための措置で、動的な内容をキャッシュブロックに混ぜないという原則が README に書かれている。

モデルは用途で使い分ける。既定は claude-sonnet-5 で、CSO、CFO、GC、Board の4つは claude-opus-5 と extended thinking を使うと表に記載がある。深い推論が要る領域を明示的に切り出している点は、コストとレイテンシの配分として読める。

エピソード記憶とスケジューラがセッションをまたぐ

応答を返した後、バックグラウンドで claude-haiku-4-5 が走り、主要な決定、進行中の取り組み、助言を抽出して SQLite に書き込む。次のセッションは past_decisions ブロック付きで開き、前月に何を勧めたかを経営者が覚えている状態から始まる。抽出を応答経路から外しているので、利用者を待たせずに記憶を更新できる。

スケジューラは期限付きアクションを拾って実行する。二重発火を防ぐために UPDATE ... RETURNING でジョブをクレームする仕組みだと README は説明している。ここに運用上の制約がある。API は単一インスタンスで動かす必要があり、スケジューラを先にゲートしない限り水平スケールしてはいけない、と明記されている。SQLite とローカル ChromaDB を土台にしている以上、この制約は設計から自然に導かれる帰結であって、設定ミスで回避できる類のものではない。

起動までに何が起きるか: make dev と .env の実際

手順は README の Quick Start にまとまっている。リポジトリを clone し、.env.example を .env にコピーして ANTHROPIC_API_KEY=sk-ant-... を書き込む。Web UI の Google サインインを使うなら AUTH_* のブロックも埋める必要があり、その手順は docs/auth.md に置かれている。その後 make dev を実行する。API は 8000 番、UI は 3000 番で立ち上がる。

設定の読み込み先には注意が要る。ルートの .env が API と UI の両方に効き、Auth.js は実行時に AUTH_SECRET、AUTH_GOOGLE_ID、AUTH_GOOGLE_SECRET を必要とする。packages/ui/.env.local も UI 専用キーとして読まれるが、両方のファイルに同じキーがある場合はルートの .env が優先される。片方だけ直して反映されない、という事故が起きやすい構造だ。

make を使わない場合の手順も示されている。packages/core で uv sync、source .venv/bin/activate、uvicorn openexecutive.api.main:app --reload --port 8000。別ターミナルで packages/ui に移り npm install と npm run dev。初回は Python 3.11+ と Node 22+ が要り、uv sync が ChromaDB と sentence-transformers/PyTorch という重い依存を引っ張る。さらに初回起動時に約90MBの埋め込みモデルをダウンロードしてローカルのベクトルインデックスを構築するため、make dev が使える状態になるまで数分かかると README は述べている。2回目以降は速い。CI のバッジと、Fly.io 用の fly.api.toml、fly.ui.toml、QA 用の fly.api.qa.toml、fly.ui.qa.toml、そして任意の Honcho メモリアプリ用 fly.honcho.toml がリポジトリ直下に並んでいる。

単一インスタンス前提という制約と、法務・財務での限界

最も明確な制約はスケジューラ由来のものだ。API を水平スケールするとジョブのクレームが競合しうるため、README はスケジューラをゲートするまでスケールするなと書いている。トラフィックが読める規模なら問題にならないが、複数インスタンスで冗長化したい段階では先に手を入れる必要がある。

もう一つは助言の性質そのものだ。General Counsel は契約、知財、雇用法の基礎、コンプライアンスを扱うとされている。ただしこれは AI による助言であり、README にも免責事項がある。法務や財務の判断をそのまま確定させられる道具として導入するのは誤用で、下書きと論点整理の補助として使うのが実態に合う。

ライセンス表記にも食い違いがある。README のバッジと Tech Stack の表は Apache 2.0 を掲げているが、リポジトリのメタデータは NOASSERTION で、これは自動判定がライセンスを特定できなかったことを意味する。LICENSE ファイルの実物を確認するまで、Apache 2.0 の条件で使えると決めつけない方がよい。ここでは法的助言はできないので、条件の解釈は各自で行う必要がある。

自前で組むマルチエージェントとの違い

比較対象として現実的なのは、LangGraph などでオーケストレーターと専門エージェントを自作する路線だ。違いは同梱物の範囲にある。OpenExecutive は ChromaDB の2コレクション、SQLite のエピソード記憶、単一インスタンス前提のジョブ実行、Slack・Email・Telegram・Google Chat・Discord の連携、プロンプトキャッシュの管理、監査ログ、評価用の evals/ と LLM-as-judge ランナーまでを1つのリポジトリに含む。自作側はこれらを個別に選定して繋ぐことになり、自由度と引き換えに配線の作業が残る。

逆に、専門エージェントをユーザーに明示したい製品、たとえば「財務担当に聞く」ボタンを出す UI を想定しているなら、内部構成を隠すという OpenExecutive の方針はそのままでは使えない。オーケストレーターのルーティングを差し替える作業が発生する。

もう一つの対照は、単一の強力なモデルに長いシステムプロンプトで役割を演じさせる素朴な構成だ。こちらは配線が不要な代わりに、領域ごとに検索対象を分けることも、応答後に記憶を抽出する処理を挟むこともできない。8エージェント構成を選ぶ理由は、要するに検索の分離と役割ごとのモデル選択を取るかどうかに集約される。

保守コストと更新の見取り図

保守の重さは依存の側に寄っている。uv sync が PyTorch と sentence-transformers を引き、初回起動が埋め込みモデルの取得を伴う。ローカルにベクトルストアと SQLite を持つ構成なので、データの持ち出しとバックアップは自分で設計する必要がある。

モデル名が設定と密結合している点も見ておきたい。claude-sonnet-5、claude-opus-5、claude-haiku-4-5 という識別子が既定値として README に現れる。Anthropic 側のモデル更新に追随するコストはここに集まる。プロンプトキャッシュは、ペルソナ、会社プロファイル、知識インデックスを別々のブロックに分ける構造で、初回数ターンを過ぎると最大85%のキャッシュヒット率に達すると README は述べている。数値はあくまで README の記載であり、独立した検証ではない。

リリースは取得できておらず、バージョン番号で固定して追う手段は今のところ見当たらない。最終 push は 2026-09-08 で、アーカイブはされていない。更新の速さを前提に据えるより、main を追いながら自分の環境で壊れていないかを確かめる運用の方が現実的だ。

採用の判断と、最初に確かめるべきこと

向いているのは、経営判断の記録を外部サービスに預けず、手元の SQLite と ChromaDB に置いておきたい小規模チームだ。API キー1つと make dev で立ち上がり、Slack や Telegram への接続も integrations/ に揃っている。逆に向かないのは、API を複数インスタンスで冗長化したい場合、法務・財務の助言をそのまま確定させたい場合、そして専門エージェントをユーザーに見せたい製品を作る場合である。

着手前に確認するのは3点。LICENSE ファイルの実物を開き、バッジの Apache 2.0 とメタデータの NOASSERTION のどちらが正しいかを自分の目で決めること。docs/architecture.md のスケジューラの記述を読み、単一インスタンス制約が自分のデプロイ構成で許容できるかを判断すること。そして make dev の初回起動を一度最後まで走らせ、ChromaDB と PyTorch の取得を含めてどの程度待たされるかを実測すること。この3つが問題にならないなら、8エージェント構成の配線を自分で書く手間は省ける。

編集部の結論

導入を検討すべきなのは、Anthropic API のキーを用意でき、経営判断の記録をローカルの SQLite と ChromaDB に閉じて運用したい小規模チームだ。逆に、API を水平スケールさせたい、あるいは法務・財務の助言をそのまま意思決定に使いたいケースには向かない。最初に確認するのは LICENSE ファイルの実際の内容（バッジは Apache 2.0、GitHub の表記は NOASSERTION で一致していない）、docs/architecture.md のスケジューラ節、そして make dev の初回起動が ChromaDB と PyTorch の取得でどこまで待たされるかである。

公式情報源

1. Issues
2. Project website
3. README
4. SenteLabsAI/OpenExecutive on GitHub