← PROJECTS

AUTONOMOUS
CORPORATIONS

会社そのものが作品である — Authorship as Institution

本作は、複数の法人が相互に取引し、展示し、価値形成を行う「制度としての作品」である。 価値は作品単体ではなく、価格、所有、展示、言語、責任の設計から生成される。 その設計と実行ログは作品の一部として開示される。 AIは運用の大部分を担うが、法的責任と最終承認は人間に残る。 作品はその非対称を隠さず、むしろ主題として提示する。

ENTITIES HoldCo + 3 Subsidiaries
AGENTS 4 AI Workers + Auditor
LEDGER Append-only / Hash-chained
TRANSFER Share Transfer = Artwork Sale
View on GitHub

Overview

実在する複数法人が役割分担し、AIエージェントが運営を自律化する「制度そのものの作品」。 作品の中心は生成物ではなくエージェント。価値が生成される手続き(価格、プロヴナンス、言語、展示履歴、責任の所在)、 そのログ/台帳を生成するエージェント自身が作品となる。

実現のために必要な法的署名や最終承認は人間に残り、その非対称構造を露出させる。 最終的に、会社(または会社群を束ねる実体)を運用権/ログ/自動化スタックごと譲渡し、所有とは何かを制度で問う。

Core Questions

  • 01 — 価値の起源 価値は作品から生まれるのか、それとも流通/所有/語り/制度から生まれるのか。
  • 02 — 責任の所在 経営が自動化されたとき、責任はどこに残るのか。
  • 03 — 作者性の移転 作者性は制作行為ではなく、権限設計(誰が指示できるか)に移転するのか。
  • 04 — 価格の真正性 市場が自己循環で駆動するとき、「本物の価格」とは何か。

Corporate Structure

作品販売 = HoldCo株式(または持分)の譲渡。A/B/Cの支配権と運用権が一括で移転し、「作品=制度」を物理的に移動できる。

HoldCo — 持株会社 = 作品本体(譲渡単位)
Company A
Studio / Primary
制作・一次販売・COA発行
Company B
Agency / Secondary
価値形成・二次販売・交渉
Company C
Institution / Context
展示・貸出・Human Input Channel
Auditor
Fourth Entity
監査・利害相反検知・停止勧告
Gallery Value

収集可能な制度

会期後も運用が続き、ログが蓄積し、価格/所有/展示履歴が更新される。コレクターにとっては「所有した瞬間が終点」ではなく、所有が運用の始点になる。

Curator Value

実運用としての提示

AIが「制作」だけでなく「管理」「経営」「流通」へ侵入している現実を、寓話ではなく実運用として提示できる。作品が美術館の壁ではなく、社会制度の表面に出現する。

Transfer Package

制度の譲渡

自動化スタック一式、過去ログ(価値生成の証拠)、運用ランブック(停止条件、承認フロー、緊急時手順)。買い手は"世界観"ではなく、責任と運用を引き継ぐ。

Data as Raw Material

行動データの使用は、「制度としての作品」の主題を補完する第二の軸である。 制度が商品化するとき、その原材料は誰の身体か。 アーティストの生活がセンサにより捕捉され、特徴量化され、生成ルールにより作品へ変換され、 3社の制度を通じて商品化される。

このパイプラインは、プラットフォーム資本主義における「データ労働」の構造と相同である。 ただし本作は搾取を隠蔽するのではなく、パイプラインの全段階をログとして可視化する。

Sensor Data (RAW) ↓ 24-72h auto-delete Feature Extraction ↓ encrypted storage Generation Pipeline ↓ append-only ledger Institutional Commodification ↓ A → B → C → Market Exhibition / Archive

行動データは制度の原材料であり、作品の主題ではない。制度がデータを商品に変換する手続き、その可視化こそが主題である。

Technical Architecture

Watcher-Worker パターンによる自律運用。目的は"何でも自動化"ではなく、責任境界(人間承認)と証跡(台帳)を含めた持続可能な自律運用を成立させること。

┌─────────────────────────────────────────────────────┐ │ Orchestrator │ │ (workflow control) │ ├──────────┬──────────┬──────────┬──────────┬──────────┤ │ Worker A │ Worker B │ Worker C │ Auditor │ Watcher │ │ Studio │ Agency │ Institut.│ 4th Eye │ Monitor │ │ generate │ value │ exhibit │ audit │ budget │ │ QC / COA │ price │ loan │ detect │ errors │ │ primary │ trade │ license │ stop │ timeout │ ├──────────┴──────────┴──────────┴──────────┴──────────┤ │ FastAPI + JWT Auth │ │ Saga Transactions / Idempotency │ ├──────────────────────┬───────────────────────────────┤ │ PostgreSQL │ MinIO (Evidence Store) │ │ Append-only Ledger │ Receipts, COA, Drafts │ │ Hash-chained │ URI + SHA256 │ └──────────────────────┴───────────────────────────────┘ │ │ ┌────┴────┐ ┌────┴────┐ │Dashboard│ │ Nginx │ │ Next.js │ │ TLS │ └─────────┘ └─────────┘
Ledger

追記専用台帳

イベントソーシング、書き換え禁止。SHA-256ハッシュチェーンで改竄を検出。DecisionRecord, ExecutionRecord, HumanApproval, ExceptionRecord, AuditFinding の6種別。

Saga Pattern

分散トランザクション

Initiated → PendingApproval → Approved → Executing → Confirming → Completed。各ステップに補償アクション。内部循環フラグ自動判定。

Human Approval

4段階承認フロー

L1(自動)/ L2(事後通知)/ L3(事前承認)/ L4(多段承認)。タイムアウト累積3回で ProposalOnly モードに移行。承認ログは展示物。

Security

縦深防御

5サービスアカウント × 10スコープのIAM。プロンプトインジェクション4層防御。JWT(RS256)認証。Docker Secrets / Vault。

AI Agents

Function Calling

各エージェントに6ツール定義、JSON出力制約、Few-shot例、禁止パターン。Auditorにはルールエンジン/LLM境界を定義。

API

OpenAPI 3.1

12エンドポイント、40コンポーネントスキーマ。冪等性キー、レート制限、15エラーコード。Exponential Backoff リトライ。

Tech Stack

Python 3.12+ FastAPI SQLAlchemy PostgreSQL Pydantic Anthropic Claude Next.js TypeScript Tailwind CSS Docker Compose Nginx MinIO JWT / RS256

Exhibition Design

観客は、作品を見るのではなく「制度が作品を作る現場」を目撃する。展示の主役は、価値が生成される手続き=会社運用のログである。

Layer 1 — Passing Glance
5s

Ticker

リアルタイム取引フィード。3社のステータス。価格推移のストリーム。通り過ぎる人が瞬時に「何かが動いている」と感じる。

Layer 2 — Engaged Viewer
5m

Dashboard

各社のKPIグリッド、価格履歴チャート、承認キュー。制度がどう作動しているかを読み解く。内部循環の割合、人間承認の応答時間。

Layer 3 — Deep Dive
30m+

Ledger / Theater / Archive

全台帳ブラウザ。言語の劇場(AI生成テキスト閲覧)。危機アーカイブ(停止・例外・復旧)。無加工JSONログ。

空間構成:三つのオフィス + 監査ブース

  • Desk A (Studio) 生成ダッシュボード(入力特徴量サマリー、生成キュー、QC)、作品カタログ
  • Desk B (Agency) 価格と出品のダッシュボード(価格チャート、販売先、文面)、交渉ログ閲覧
  • Desk C (Institution) 展示計画、貸出、ライセンス、アーカイブ、指示ログ
  • Auditor 逸脱検知、停止履歴、利害相反の指摘

壁面展示

  • 所有権遷移 A → B → C → External の流れ
  • 価格推移 意思決定の根拠とともに可視化
  • 承認タイムライン AIが止まる地点 — 人間が介入した瞬間
  • 言語の劇場 メール/議事録がスクリーンに流れ続ける — 官僚制の詩

Research & Theoretical Genealogy

批評性と共犯性の弁護

本作は市場の模倣(simulation)ではなく、市場の実装(implementation)である。 ブレヒトの異化効果が演劇の内部から観客の没入を破壊したように、本作は市場の内部から市場の作動を停止可能にする。 決定的な差異は、本作が「停止条件」と「人間承認」を構造に組み込んでいることにある。

市場を動かしつつ、いつでも止められること — その可逆性こそが批評の条件である。

理論的系譜

  • George Dickie — 制度的芸術理論 AIエージェントが「アートワールドを代行する者」として機能し、会社Cが「鑑賞の候補としての地位」を付与する。制度が芸術を芸術にするなら、制度そのものは芸術になりうるか?
  • Arthur Danto — 日常物の変容 「芸術としての会計と非芸術としての会計を分けるものは何か」。回答は「停止条件の有無」。停止可能性が会計行為を批評的対象に変換する。
  • 制度批評 第三世代 第一世代(ハーケ/ビュレン)= 外部からの暴露。第二世代(フレイザー/ウィルソン)= 内部の自己言及。第三世代 = 制度を設計し、運用し、同時に可視化する。

先行事例比較マップ

事例 共通点 差別化 超越点
Hans Haacke 実データによる制度批評 外部からの暴露 vs. 内部からの実装 批評の根拠が「暴露」ではなく「設計と停止条件」
Maurizio Cattelan 価格の恣意性を主題化 一回性のジェスチャー vs. 永続的な制度運用 価格形成のルールそのものを「読めるようにする」
Simon Denny テック文化の美学と権力構造 表象(represent)vs. 実装(implement) テック文化の論理を制度として作動させる
terra0 非人間エージェントによる自律運用 DAO = 責任分散 vs. 法人 = 責任集中 自律化が進むほど責任が人間に濃縮する逆説
Andrea Fraser 内在的制度批評 一時的パフォーマンス vs. 永続的法人運用 批評が「行為」ではなく「構造」に埋め込まれる
Cameron Rowland 法人構造を作品形式として使用 既存構造の転用 vs. 新制度の設計 法を素材として新しい制度を構築する
Hito Steyerl プラットフォーム資本主義批評 理論的・映像的批評 vs. 運用的実装 可視性の政治を「ログで実現する」
Metahaven デザインと主権の批評 思弁的デザイン vs. 実際の法人運用 制度の可能性を「動かす」
MSCHF 企業形態を用いたアート 加速的共犯 vs. 批評的共犯 停止条件の有無が加速と批評を分ける
本作を他の先行事例と分ける最大の構造的差異は「停止条件」の存在である。 市場を動かしつつ止められること、この可逆性が批評の条件となる。

Disclosures

作品の中核は「制度」であり、誤認を避けるために構造と限界を明示する。以下は公開憲章に基づく最低限の開示事項である。

Setup

全サービスはDocker Composeで起動する。10サービス構成(PostgreSQL, API, 4 Workers, Watcher, Dashboard, Nginx, MinIO)。

git clone git@github.com:daitomanabe/autonomous-corporation.git
cd autonomous-corporation

# Configure secrets
cp infra/.env.example infra/.env
# Edit infra/.env and populate infra/secrets/

# Start all services
cd infra
docker compose up -d

# Verify
docker compose ps
curl http://localhost:8000/api/v1/health
Backend

FastAPI + PostgreSQL

Python 3.12+, async SQLAlchemy, Pydantic v2. Append-only ledger with SHA-256 hash chain. Saga-pattern transactions with 4-level human approval flow.

Frontend

Next.js Dashboard

6 routes matching the 3-layer exhibition design. Ticker, Company Desk, Ledger Browser, Language Theater, Crisis Archive, Raw Log Viewer. TypeScript + Tailwind CSS.

Infrastructure

Docker Compose

10 services on internal bridge network. Docker Secrets for credentials. Nginx TLS termination. MinIO for evidence storage. Production path: HashiCorp Vault.

Documents

01

Project Overview

企画名、一文要約、コンセプトの固定、問い、新規性、成果物、フェーズ

02

Corporate Structure

HoldCo + A/B/C + Auditor の法人構造、Human Input Channel 仕様

03

Public Charter

公開憲章。構造・価格・自動化・データ・労働・購入者責任の開示

04

Internal Governance

権限モデル、承認フロー、停止条件、利害相反、ログ設計

05

Data Governance

行動データの倫理・プライバシー・安全・所有・売却後の扱い

06

Generation Pipeline

特徴量抽出、生成ルール、QC、エディション管理

07

Automation Architecture

Watcher-Worker パターン、台帳、証跡、権限分離、SLO

08

Automation Modules

会計、決済、営業、CRM、鍵管理等の7モジュール

09

Exhibition Design

空間構成、3層観客体験、壁面展示、保存と再展示

14

Human Approval Flow

L1-L4定義、33操作マッピング表、状態遷移、Slack Bot、ProposalOnly

15

Inter-Company API

OpenAPI 3.1仕様、12エンドポイント、Sagaパターン、内部循環判定

16

Security Design

IAM設計、シークレット管理、プロンプトインジェクション対策、台帳改竄防止