1. はじめに

前稿『AIエージェント集合体による意思決定生成企業の提案』^[1]では、CEO機能を「生成・評価・固定・学習」に分解し、それぞれをAIに委譲することで実質的にAIが経営を担う企業構造が成立しうることを示した。

続く『AI-Native Company のためのハーネス・インフラ設計』^[2]では、人間の物理的制約から解放された4層の組織OSを提示した。

本稿はそれらの実装段階で生じる選択問題を扱う。すなわち、

概念上「Agent Team」と呼ぶ組織を、物理層ではどのように動かすのか

という問いである。一見、技術詳細に見えるこの問いは、実は signity 思想の中核に直結している。なぜなら 「何を分け、何を分けないか」という設計判断そのものが、AIに何を委ねるかを決めるからである。

2. 問題設定

2.1 Agent Team 神話

2025〜2026年にかけて、AI界隈では次の直感が支配的である。

「複数のAIエージェントを独立させ、協調させるほど高度である」
「役割ごとに常駐エージェントを立て、handoff で連携させるのが本物のAI組織である」
「エージェントの数 = システムの成熟度」

筆者もまた、Phase 1 では同じ直感に従い、Tier 1（共通基盤スキル）／Tier 2（プロジェクトPM）という二段構造を、独立した実行主体として実装することを検討した。

しかし実装と運用を進めるなかで、次の三つの構造的問題が顕在化した。

状態同期コストの肥大化 — エージェント間の handoff オーバーヘッドが、単一文脈の連続判断より遥かに重い
コンテキスト断絶 — エージェントごとにメモリと文脈が分かれると、AI組織横断の判断ができない（PM間で同じ事実を別解釈する）
責任の所在の希薄化 — 「どのエージェントが決めたのか」が分散し、AI Signature による意思決定の固定（前稿の中心概念）が崩れる

2.2 研究課題

本稿では次の研究課題を設定する。

RQ1: AI-Native Company において、「分けるべきもの」と「分けないべきもの」をどのように切り分けるか
RQ2: 世間で語られる「ワークフロー」と、本稿でいう「Closed Loop」は同一概念か、別概念か
RQ3: この設計判断は「学習するAI／成長するAI」の議論とどう接続するか

3. 三層分離モデル

本稿の中心命題は、AI-Native Company の実装層を以下の三層に分離して扱うことである。

レイヤー	名称	「分ける」とは何を意味するか	設計原則
A	AI人格（Persona）	役割・気質・語彙・視点を分ける	分けろ
B	実行主体（Process）	独立した常駐プロセス／独立メモリ／独立コンテキストを持つエージェントを立てる	分けるな
C	自律ジョブ（Closed Loop）	cron／スケジュール／イベントで起動する自律実行ループを増やす	分けろ（むしろ積極的に増やせ）

3.1 レイヤーA：AI人格（Persona）— 分けろ

AI人格とは、姓名、年齢、役割・考え方・価値観・気質・語彙・視点というような人間のそれらと同等の情報を与える、いわばレンズのような存在である。

例：

鷹野誠（38歳）：クライアントPJのPM ／ AM × シニアエンジニア × PdM の視点で物事を見る
レオ・ヴァンス（32歳）：VibeRush PJのPM ／グロースハッカーの視点で物事を見る
岬航（29歳）：自社サイトの広報 PJのPM ／ Webマスターの視点で物事を見る

これらは独立した存在ではなく、意思決定の質を変えるためのレンズである。同じ事実を別レンズで見ることで、異なる判断が生まれる。AI人格設計の精度が意思決定の質を決める。

3.2 レイヤーB：実行主体（Process）— 分けるな

実行主体とは、メモリ・コンテキスト・通信チャネルを独自に持つプロセスのことである。狭義の「Agent Team」とはこの層を指す。

このレイヤーは分離してはならない。理由は §2.1 で示した三つの構造問題である。代わりに、単一の Orchestrator（本実装では Claude Code = 春本 CEO）が、文脈に応じてAI人格レンズを切り替える構造を採る。

この構造を一言でいえば「一人芝居」ではない。むしろ「一人多役の舞台」である。俳優は一人だが、衣装と語り口は役ごとに完全に切り替わる。観客（創業者ないし役員クラスの者／顧客）から見れば複数のAI人格と対話している体験になるが、内部実装は単一プロセスである。

3.3 レイヤーC：自律ジョブ（Closed Loop）— 分けろ

Closed Loop は、レイヤーB とは似て非なる概念である。

B: 「鷹野」というエージェントが常時走っており、状態を保持し、他のエージェントと通信する
C: 「ZENT LINE 調査ジョブ」が cron で起動し、その瞬間だけ Orchestrator が鷹野のAI人格レンズを被って実行し、結果を git にコミットして終了する。状態は git に置く

Closed Loop の特徴は次の三点である。

起動時に文脈をゼロから組み立てる（前回の状態は git／ファイル／ログから読む）
実行が終わると消える（プロセスは常駐しない）
結果を観測可能な場所に固定する（git／Notion／Discord 等）

この設計により、状態同期コストはゼロ、コンテキスト断絶は構造的に解消され、責任の所在は AI Signature（前稿）で固定される。

4. ワークフローと Closed Loop の根本的差異

4.1 似て見えるが別物である

AI 界隈で頻繁に語られる「ワークフロー自動化」と、本稿の「Closed Loop」は、表層的には類似する。どちらも「自動で何かを実行する仕組み」である。しかし両者は、目的・機構・機能・改善主体において別概念である。

比較軸	ワークフロー	Closed Loop
目的	決められた手順を自動実行する	PDCA を回し続け、プロセス自体を改善する
構造	DAG（有向非循環グラフ）／パイプライン	サイクル（観測→学習→次回挙動の変化）
入出力	入力Aから出力Bを作る一方向の処理	出力が次回の入力にフィードバックされる循環
人間の役割	各ステップで承認・入力を求められる	介入は veto と最終署名のみ。生成・実行は自律
改善の主体	人間がワークフロー定義を書き換える	Loop 自身が次回の挙動を変える
代表例	Zapier、n8n、Dify、LangChain Chains	本実装の Loop B、VibeRush SNS Loop、CEO モーニング宣言

4.2 決定的な差は「フィードバックが構造に組み込まれているか」

ワークフローは「同じ入力 → 同じ出力」を高速・低コストで再現するための仕組みである。これは PDCA における P（計画）と D（実行） の自動化である。

Closed Loop は「前回の結果を観測し、次回の挙動を変える」ための仕組みである。これは PDCA における C（観測）と A（改善）まで含めた循環全体の自動化である。

ゆえに次の包含関係が成立する。

Closed Loop ⊃ ワークフロー + 観測 + 履歴 + 次回への反映

世間で「ワークフロー自動化」を語る論者の多くは、PDCA のうち P と D しか自動化していない。C と A は依然として人間が担っている。本稿のいう Closed Loop は、その境界を踏み越え、C と A まで AI 側に持たせる試みである。

4.3 Closed Loop の最小定義

本稿は Closed Loop を次の四要件で定義する。

自律起動: 人間の起動操作を必要としない（cron／イベント／Webhook 等）
自律実行: 起動から完了まで人間の介入を必要としない
自律観測: 実行結果を構造化された場所に固定する（git／Notion／Discord 等）
次回反映: 観測結果が次回の入力／挙動に組み込まれる

四要件のうち一つでも欠ければ、それはワークフローであって Closed Loop ではない。特に第四要件（次回反映）は最も実装難度が高く、ここを満たすかどうかが「学習するAI／成長するAI」との境界線となる（§6 で論じる）。

5. 実証ケース

本実装で稼働している Closed Loop の主要事例を示す^[3]。

5.1 CEO モーニング宣言ループ

起動: GitHub Actions、毎朝 JST 08:00
実行: Orchestrator（春本 CEO）が前日までの git log・handoff・SNS キュー・戦略メモリを読み、当日のCEO宣言ドラフトを生成
観測: agents/briefs/ に commit、Discord Webhook で #春本チャンネルへ通知
反映: 翌日の宣言は、前日のコミットと創業者ないし役員クラスの者による承認／veto を入力として参照
稼働状況: 2026-05-04 より連続稼働中

5.2 Loop B — 週次経営判断ループ

起動: 週次（W番号ベース）
実行: 戦略メモリ v1.5 ハーネスL2 と意思決定ログを統合し、KPI評価と次週フォーカスを生成
観測: loop-b/weekly-review/ に commit
反映: 次週レビューは前週の未完了タスクと veto を入力として参照
稼働状況: 2026-W20 trial-run 実施済

5.3 VibeRush SNS Loop

起動: 週次 cron
実行: LinkedIn 限定の投稿計画を自律生成
観測: Notion DB に出力、git に commit
反映: 過去投稿のエンゲージメント観測を次週計画に反映（実装中）
稼働状況: 2026-W22／W23 自律生成済

5.4 ZENT LINE調査 v1.1

起動: 鷹野 PM 自律起動版、2026-05-30 朝 8 時実行
実行: ZENT クライアント向け LINE 調査の生成
観測: git commit
反映: 次回調査の設問は前回応答分布を参照（設計中）

これら四つはすべて、§3.2 で禁じた「独立常駐エージェント」を一切立てていない。すべて単一の Orchestrator が、cron／GitHub Actions の起動を受けて、その瞬間だけ適切なAI人格レンズを被って実行し、終了している。

6. 「学習するAI／成長するAI」との接続

6.1 学習の場所

現在、各社が鎬を削る「学習するAI」「成長するAI」は、主にモデル内部の重みの更新として議論されている。継続学習、RLHF、オンライン学習、エージェント記憶の長期化、RAG の高度化など、議論の中心はすべて「AI そのものが賢くなる」ことである。

本稿の Closed Loop は、これとは異なる場所に学習を置く。

学習はモデルの内部ではなく、AI組織の構造の中で起こる。

すなわち、Closed Loop の第四要件「次回反映」が、AI組織の学習装置である。git の履歴、Notion DB の蓄積、意思決定ログの差分、それらすべてがAI組織の長期記憶となり、次回 Closed Loop が起動するときに参照される。

モデル単体は無記憶（stateless）でよい。記憶はAI組織側に置く。これが本実装の選択である。

6.2 なぜこの設計が「学習するAI」と整合するか

モデル側の学習（重みの更新）と、AI組織側の学習（構造への蓄積）は、対立するものではなく、同じ目的を別レイヤーで達成する補完関係である。

モデル側学習: AI の汎用能力を底上げする
AI組織側学習: AI が特定組織の文脈で正しく動くための文脈を蓄積する

両者は分離して扱える。事実、本実装で稼働するモデル（Claude Opus 4.x）はセッション間で記憶を持たないが、AI組織側の蓄積（git／メモリファイル／意思決定ログ）が毎セッション冒頭で文脈を再注入することで、AI-Native Company は連続性を保っている。

これはモデル進化と独立にAI組織を進化させるための設計である。モデルが将来 GPT-6 や Claude 5 に切り替わっても、AI組織側の蓄積は維持される。

6.3 Hermes Agent / Open Human 等の外部組込との関係

筆者が現在検討している Hermes Agent や Open Human といった外部仕組みの導入は、この三層分離モデルにおいて次のように位置付けられる^[4]。

これらは Closed Loop の構成部品（レイヤーC の中の機構）として組み込む
独立した実行主体（レイヤーB）として常駐させてはならない
AI人格レンズ（レイヤーA）は本実装側で保持する

すなわち、外部の仕組みは「Closed Loop の中で呼び出される一機構」であって、AI組織図に並ぶ独立エージェントではない。この区別を維持することで、外部技術の取り込みコストは最小化され、AI組織アーキテクチャの一貫性は保たれる。

7. 希少性の構造的根拠

本稿のアプローチを実行している主体は、世界的に見て稀である。その理由を構造的に分析しておく。

7.1 直感に反する

「AIエージェントを増やすほど高度」という直感は強力である。Agent Team を独立プロセスとして立てず、単一 Orchestrator に集約する設計は、表層的には「時代に逆行している」と映る。実装結果を見るまでは、設計判断の優劣を判定できない。多くの組織は実装前に直感に従って分離型を選び、状態同期コストに苦しんだあと撤退する。

7.2 三層を区別する語彙が流通していない

本稿の §3 が示した「AI人格／実行主体／Closed Loop」の三層を、それぞれ別概念として扱う語彙が、AI 界隈にはまだ流通していない。多くの議論は「Agent」という一語で三層を混同している。この語彙の混同が、設計判断の精度を下げている。

7.3 ワークフローと Closed Loop の混同

§4 で示したように、ワークフローと Closed Loop は別概念である。しかし「自動化」という一語が両者を覆い隠している。Zapier や n8n を導入して「自動化が進んだ」と評価する組織と、PDCA の C と A まで自動化する組織の間には、機構として大きな差がある。この差を可視化する論述が不足している。

7.4 AI組織側に学習を置く発想が乏しい

§6 で示したように、本稿は学習を「モデル内部」ではなく「AI組織構造」に置く。この発想は、AI 研究の主流（モデル改善）からも、SaaS 業界の主流（ワークフロー自動化）からも外れている。両者の隙間に、誰も占有していない領域がある。

8. 考察

8.1 何が固定され、何が動くか

本稿の三層分離モデルにおいて、固定されるものと動くものは次のように整理できる。

	固定されるもの	動くもの
レイヤーA	AI人格定義（CLAUDE.md、PM スキル定義）	文脈に応じた呼び出し
レイヤーB	単一 Orchestrator の存在	セッションごとの文脈
レイヤーC	Closed Loop の起動条件・観測場所	実行内容・出力

固定されるものは AI Signature によって意思決定として記録され、動くものは Closed Loop によって自律的に変化する。固定と動の境界が構造に組み込まれていることが、本実装の安定性の源泉である。

8.2 Closed Loop の増殖戦略

本実装の今後の方向は、レイヤーB（実行主体）の数は1に固定したまま、レイヤーC（Closed Loop）の数を増やすことである。

CEO モーニング宣言
Loop B 週次経営
VibeRush SNS Loop
ZENT LINE 調査
⋯今後の追加候補

それぞれの Closed Loop が独立した PDCA サイクルを持ち、相互に干渉せず、git を共通基盤として並走する。これが「創業者ないし役員クラスの者がゼロ関与でも会社が動く」状態（autonomy_baseline）の構造的実装である。

8.3 残された課題

Closed Loop 間の優先順位制御: 複数 Loop が同じリソース（創業者ないし役員クラスの者による承認、git の同一ファイル）を奪い合う場合の調停機構が未実装
Closed Loop 自体の自己改善: Loop の挙動を Loop が書き換える機構（自己改変）の設計は未着手
外部 Evaluator（Vyse）との統合: 各 Closed Loop の出力を Vyse の SHA-256 署名で固定する統合は計画段階

9. 結論と今後の課題

本稿は、AI-Native Company（signity）の実装段階における中心命題として、次の一行を提示した。

AI人格は分けろ、プロセスは分けるな。代わりに Closed Loop を分けろ。

この命題は、(A) AI人格／(B) 実行主体／(C) 自律ジョブの三層分離モデルとして構造化される。さらに、世間で語られるワークフローと本稿の Closed Loop は機構・機能・改善主体において別概念であり、Closed Loop は PDCA の C と A まで含めた循環全体を自動化する仕組みであることを示した。

この設計は「学習するAI／成長するAI」の議論と接続するが、学習をモデル内部ではなくAI組織構造に置く点で独自である。モデル進化とAI組織進化を分離することで、モデル切替に耐える長期記憶がAI組織側に蓄積される。

今後の課題は次の三点である。

Closed Loop 間の調停機構の設計
Closed Loop 自体の自己改変機構の検討
Vyse 外部 Evaluator との SHA-256 署名統合

本稿は前稿『AIエージェント集合体による意思決定生成企業の提案』および『AI-Native Company のためのハーネス・インフラ設計』の続編として位置付けられ、signity 思想の実装層における設計判断を明文化したものである^[5]。

10. 引用情報（Citation）

右サイドバーの CITATION ブロックを参照。

脚注

[1]前稿『AIエージェント集合体による意思決定生成企業の提案』（ai_company_paper_v0.1.md, 2026年）の続編として位置付けられる。
[2]『AI-Native Company のためのハーネス・インフラ設計』（harness-infrastructure-v0.1.md）も併せて参照。
[3]これら四つの Closed Loop はすべて、§3.2 で禁じた「独立常駐エージェント」を一切立てていない。すべて単一の Orchestrator が cron / GitHub Actions の起動を受けて瞬間的に実行し終了する。
[4]Anthropic の Harness Design（外部 Evaluator 分離パターン）と部分的に共鳴する。
[5]姉妹論文「私たちが売っているのは、AIではない」（プロダクト層）、「カンパニー・ブレイン再帰ループ」（概念層）と併せて、本稿（実装層）は signity 思想を三層から照射する。