Haconiwa

宣言的AI中心開発環境のアーキテクチャ分析

複雑なAI協調開発を、コードで管理する新時代へ

本セッションでわかること

  • Haconiwaとは何か？ - その核心的なアイデア
  • なぜHaconiwaが必要か？ - AI開発が直面する課題
  • どう動くのか？ - 支える3つのコア技術
  • Haconiwaの未来は？ - LLMOpsにおける戦略的価値

起: 問題提起と解決策

【問題提起】AI協調開発の「カオス」

複数のAIエージェントによる開発。理想とは裏腹に、現実は...

ブランチ管理

「誰がどのブランチで作業してる？」

環境コンフリクト

「依存関係が衝突した！」

進捗の不透明性

「何がどこまで進んでいるか不明...」

再現性の欠如

「あの時の実行環境が作れない...」

手動での環境管理は限界。構造化されたアプローチが必要です。

【解決策】Haconiwa: Your Workspace, as Code

開発環境そのものを、コードとして宣言的に管理する。


# config.yaml
apiVersion: haconiwa.sh/v1alpha1
kind: Task
metadata:
  name: frontend-ui-design
spec:
  assignee: worker-a
  spaceRef: main-project
  worktree: true
  branch: feature/ui-revamp

haconiwa apply

再現可能で隔離された
開発環境を自動構築

AnsibleやDocker Composeのように、ローカル開発環境を自動化します。

承: Haconiwaの仕組み

Haconiwaを支える3つのコア技術

tmux

セッション仮想化
ターミナルを仮想化し、エージェントの活動をリアルタイムに監視・操作。

git worktree

ファイルシステム分離
タスク毎に独立したディレクトリを生成し、コンフリクトを物理的に防止。

AI Agent

コマンド実行
仮想化された環境内で、AIエージェント（例: Claude Code）にタスクを実行させる。

技術解説①：tmuxによるセッション仮想化

YAMLで定義した抽象的な「ルーム」と「エージェント」が、
具体的なtmuxの「ウィンドウ」と「ペイン」に変換されます。

haconiwa.yaml


Space:
  name: room-frontend
  agents:
    - PM
    - Worker-A
    - Worker-B

tmux Session

Window: [room-frontend]
Pane 1
(PM)
Pane 2
(Worker-A)
Pane 3
(Worker-B)

これにより、宣言的な定義と実践的な開発（監視・操作）のギャップを埋めます。

技術解説②：git worktreeによる物理的な分離

worktree: trueと指定されたタスクは、
完全に独立したディレクトリで作業が行われます。

.git (Single Repository Database)

./project-dir/

(main branch)

./tasks/task-A/

(feature/task-a branch)

./tasks/task-B/

(feature/task-b branch)

これにより、依存関係の衝突やファイル変更の競合を防ぎ、真の並列開発を実現します。

設計図: YAMLによるカスタムリソース定義 (CRD)

Kubernetesに触発されたCRDで、複雑なチーム構造とワークフローを表現します。

Organization
チームやプロジェクト、所属するエージェント（PM, Worker-Aなど）を定義。
Space
協調作業の「場」。Gitリポジトリやベースとなるブランチ（例: dev）を指定。
Task
個別の作業単位。担当エージェントを割り当て、`worktree: true`で環境分離を指定。
Law (計画中)
ルールや権限、システムプロンプトを定義するガバナンスレイヤー。

ワークフロー in Action: 3つのコマンドで完結

1. 構築

haconiwa apply

YAMLから環境 (tmux, git worktree) を一括生成。

2. 実行

haconiwa attach/run

セッションに接続して監視、または全エージェントに一斉にコマンド実行。

3. 破棄

haconiwa delete

セッションと作業ディレクトリを完全にクリーンアップ。

転: 戦略的価値と未来

戦略的分析: LLMOpsにおけるHaconiwaの役割

Haconiwaは、LLMアプリ開発そのものではなく、
その土台となる「実行環境」を提供する重要なLLMOpsツールです。

LLMOps Pipeline

データ準備
プロンプト設計
実行環境
(Haconiwaの領域)
デプロイ

再現性と一貫性のある環境を提供することで、
AIエージェントのテストと開発の信頼性を劇的に向上させます。

競合ではない、共存関係

Haconiwaは、他のAIエージェントフレームワークとは役割が異なります。

CrewAI / AutoGPT

エージェントの「頭脳」
どう考え、どう協調するか
（思考・協調のオーケストレーション）

Haconiwa

エージェントの「作業場」
どこで、どう安全に作業するか
（環境のオーケストレーション）

Haconiwaが用意した「作業場」で、CrewAIが定義した「チーム」が働く、という連携が可能です。

役割分担の比較

特徴 Haconiwa CrewAI AutoGPT
主要な焦点 環境のオーケストレーション エージェントの協調 自律的なタスク達成
コア抽象化 Space, Task (YAML) Crew, Agent, Task 認知ループ
役割 「作業場」を構築・管理 「チームワーク」を定義 「自律的行動」を駆動

将来展望: Law CRDによる宣言的セキュリティ

計画中のLaw CRDは、AIエージェントのセキュリティを
宣言的に管理する「Policy-as-Code」という先進的なビジョンを示します。

law.yaml (構想)


spec:
  permissions:
    - agent: Worker-A
      allowCommands:
        - "npm install"
        - "npm run test"
      denyCommands:
        - "rm -rf *"

低レベルのサンドボックス技術
(seccomp, AppArmor) へ自動変換

これが実現すれば、安全なAIエージェント実行環境の構築が劇的に容易になります。

結: まとめと評価

総括: Haconiwaの可能性と課題

強みと可能性

  • 革新的でエレガントなビジョン ("Workspace-as-Code")
  • 技術選定の的確さ (tmux, git worktree)
  • LLMOpsにおける独自の価値提供
  • 宣言的セキュリティへの先進的アプローチ

現状と課題

  • 初期アルファ段階のプロジェクト
  • 機能は開発途上、ドキュメントも未整備
  • 単一開発者への依存リスク
  • コミュニティ形成と普及が今後の鍵

その未来は、先見的なアーキテクチャを堅牢な実装で証明できるかにかかっています。

まとめ: Haconiwaがもたらす未来

  • Haconiwaは、AI協調開発の複雑性を「宣言的なYAML」で解決します。
  • tmuxとgit worktreeを使い、再現可能で隔離された「作業場」を提供します。
  • CrewAI等とは競合せず、「環境オーケストレーション」という独自の役割を担います。
  • まだ黎明期ですが、LLMOpsにおける重要な基盤技術となる可能性を秘めています。

ご清覧ありがとうございました

プロジェクトについて、より詳しく知りたい方はこちら

github.com/dai-motoki/haconiwa

本資料は、dai-motoki/haconiwaリポジトリのREADMEおよび関連資料を基に作成されました。