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

作成日: 2025年06月14日

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

エグゼクティブサマリー

本レポートは、dai-motoki/haconiwaプロジェクト（以下、Haconiwa）の技術的要素に関する詳細な分析を提供する。Haconiwaは、複雑な協調的AI開発環境をオーケストレーションするために設計された、初期アルファ段階にある革新的なPython製コマンドラインインターフェース（CLI）ツールである 1。その中核的なパラダイムは、宣言的なYAML設定ファイルを通じて、開発者のローカルワークスペース自体にInfrastructure-as-Code（IaC）の原則を適用することにある。

Haconiwaは、以下の3つの主要技術を統合することで、そのビジョンを実現している。

1. tmux: セッションの仮想化と対話的な管理のため。
2. git worktree: コンフリクトのない並列開発ストリームを実現するため。
3. AIエージェント連携: 構造化された環境内でタスクを実行するため（例：Claude Code）。

本分析の冒頭で、このプロジェクトが、同名でありながら異なる目的を持つmrubyベースのコンテナランタイムhaconiwa/haconiwaとは無関係であることを明確にする 2。Haconiwaは現在、本番環境での使用が推奨される段階にはないが 1、そのマルチエージェントワークフローを管理するための革新的なアーキテクチャビジョンは、LLMOps（大規模言語モデル運用）の分野における重要な貢献となる可能性を秘めている。本レポートは、その構造、技術的基盤、そして戦略的ポテンシャルを体系的に解明することを目的とする。

第1章: コンセプトフレームワーク：協調的AI開発のオーケストレーション

1.1. 曖昧性の解消：対象となる「Haconiwa」の特定

分析を開始するにあたり、まず「Haconiwa」という名称を持つ2つの異なるプロジェクトを明確に区別する必要がある。

• dai-motoki/haconiwa（本レポートの分析対象）: PythonベースのAI協調開発支援ツールである 1。その主眼は、
  tmuxとgit-worktreeを活用して開発ワークフローを管理することにあり、Python Package Index (PyPI)でhaconiwaとして公開されている 1。
• haconiwa/haconiwa（分析対象外）: mrubyで記述されたLinuxコンテナランタイムであり、コンテナ設定にDSL（ドメイン固有言語）を使用する 2。このプロジェクトは、Linuxの名前空間、cgroup、ケーパビリティといった低レベルのコンテナ技術を扱う 3。

以降、本レポートはユーザーの要求に基づき、dai-motoki/haconiwaプロジェクトにのみ焦点を当てる。

1.2. コアパラダイム：コードとしての開発環境

Haconiwaの中心的思想は、マルチエージェント開発環境全体を、バージョン管理可能で宣言的な成果物として扱うことにある。この環境は、docker-compose.ymlがマルチコンテナアプリケーションを定義し、Ansibleのプレイブックがサーバーインフラを定義するのと同様に、単一のYAMLファイルによって定義される 1。

このアプローチは、DevOpsの世界で成熟したパターンを、従来はアドホックで手作業に頼りがちだったローカル開発セッションのセットアッププロセスに適用する、概念的な飛躍を示している。AnsibleやDocker Composeのようなツールは、リモートインフラやコンテナ化されたサービスの状態を宣言的なYAMLファイルで定義する手法を普及させ、運用に再現性とバージョン管理をもたらした 5。Haconiwaは、

haconiwa apply -f config.yamlというコマンドを通じて、この宣言的パターンを忠実に採用している 1。しかし、その適用対象はサーバーやDockerデーモンではなく、開発環境そのもの、すなわちユーザーのファイルシステム（

git worktree経由）とターミナルセッション（tmux経由）である。これにより、Haconiwaは「Workspace-as-Code」あるいは「Interactive-Environment-as-Code」とでも呼ぶべき新たな領域を開拓している。

1.3. 問題領域：マルチエージェントの複雑性の克服

Haconiwaが解決しようとしている問題は、単一のコードベースに対して複数の自律的または半自律的なエージェントが作業する際に生じる、ロジスティクスの混乱である。複数のエージェント（あるいは人間と複数のエージェント）が、異なる機能やタスクに並行して取り組む必要があるシナリオを想定している。従来の手法では、このようなプロセスは煩雑で、エラーが発生しやすい 11。Haconiwaは、この協調作業の問題に対して、構造化され、再現可能で、スケーラブルなソリューションを提供することを目指している 1。

第2章: 技術アーキテクチャ：Haconiwaのコアコンポーネント詳解

Haconiwaのアーキテクチャは、宣言的な設定、セッション仮想化、ファイルシステムの分離、そしてAIエージェントの実行という4つの主要な柱の上に構築されている。これらのコンポーネントが相互に連携することで、複雑な開発ワークフローを体系的に管理する。

2.1. 宣言的基盤：YAMLベースのカスタムリソース定義（CRD）

Haconiwaは、Kubernetesに触発されたカスタムリソース定義（CRD）の構造をYAML設定に採用している。これらのCRDは、開発環境全体の抽象的な設計図として機能する。

• Organization CRD: チームやプロジェクトといった最上位のエンティティを定義する。このリソース内で、PM（プロジェクトマネージャー）やWorker-Aといったエージェントとその役割を定義する 1。
• Space CRD: 協調作業のための「ルーム」やワークスペースを定義する。Gitリポジトリにリンクし、その設定（例えば、すべてのタスクブランチが分岐する元となるdefaultBranch）を指定する 1。これは、ブランチ戦略の整合性を保つ上で極めて重要な設定である。
• Task CRD: 特定の作業単位を定義する。タスクをエージェントに割り当て（assignee）、所属するSpaceを参照し（spaceRef）、そして決定的に重要な点として、worktree: trueと指定することで、そのタスク専用の隔離された開発環境を作成できる 1。
• Law CRD（計画中）: この将来的な機能は、階層的なルール、パーミッション、およびシステムプロンプトを定義することを目的としており、ガバナンスとセキュリティのレイヤーとして機能することが期待される 1。

これらのCRDを組み合わせることで、ユーザーは複雑なチーム構造とワークフローを単一の宣言的ファイルで表現できる。

表1: Haconiwa CRD仕様

出典: 1

2.2. 実行環境：tmuxによるセッション仮想化

Haconiwaはtmuxを単なるターミナルマルチプレクサとしてではなく、開発セッションそのものの仮想化レイヤーとして活用する。haconiwa applyコマンドは、YAMLで定義された抽象的なSpaceやTaskを、具体的なtmuxのウィンドウとペインに変換する 1。例えば、「マルチルーム」設定では、各「ルーム」（例：

room-frontend）がtmuxのウィンドウとなり、その中の各エージェントがペインとなるtmuxセッションが生成される 1。これにより、単一の永続的なセッション内で、複数の並行プロセス（人間またはAI）を直接操作し、監視し、デバッグすることが可能になる 14。

このアーキテクチャは、宣言的な設定と実践的な開発との間のギャップを埋める上で中心的な役割を果たす。YAMLファイルは環境の静的で抽象的な定義に過ぎない 1。しかし、特にAIエージェントを扱う開発者は、リアルタイムで何が起きているかを確認する必要がある。他のマルチエージェント実験（例：16）で見られるように、また

tmux制御ライブラリ（例：17）によって可能になるように、エージェント構造をペインベースで視覚的に表現する

tmuxの利用は、この不可欠な可観測性を提供する。したがって、tmuxは単なる実装の詳細ではなく、Haconiwaが管理する環境を具体的かつ利用可能なものにするコアコンポーネントである。ユーザーはhaconiwa space attach 1 を実行することで、文字通り自らが定義したワークスペースに「入る」ことができる。

2.3. 分離メカニズム：git-worktreeによるコンフリクトフリーな並列性

git worktreeは、Haconiwaのアーキテクチャにおいて極めて重要な役割を担う。Task CRDでworktree: trueが指定されると、Haconiwaはそのタスクのブランチ用に新しい、独立したディレクトリを作成する。このブランチは、関連するSpace CRDで指定されたdefaultBranchからチェックアウトされる 1。

これは、変更をスタッシュしたり、リポジトリを複数回クローンしたりする必要がある従来型のワークフローとは対照的である。これらの従来手法は非効率でエラーを誘発しやすい 11。

git worktreeを利用する利点は明白である。各エージェントは隔離されたファイルシステム内で作業するため、依存関係、ビルド成果物、あるいはファイル変更を巡るコンフリクトが防止される。これは、真の並列実行を実現するために不可欠な要素である 13。

この機能は、Haconiwaがスケーラブルなマルチエージェント開発を実現するための基盤技術と言える。マルチエージェントシステムの主要な目標の一つは作業の並列化であるが 13、共有コードベースでの並列作業は、例えば複数のエージェントが同一ディレクトリで

npm installを実行するような競合状態を生み出す。git worktreeは、単一の効率的な.gitデータベースを共有しつつ、複数の並行した作業ディレクトリを提供することでこの問題を解決する 11。Haconiwaは、この機能を深く統合し、

Task CRDと結びつけることで、git worktreeをニッチなパワーユーザー向けコマンドから、自動化されたマルチエージェントワークフローの基礎的要素へと昇華させている。これは、タスク分離の物理的な現れなのである。

2.4. 知的労働力：AIエージェント連携

Haconiwaは、AIエージェントのオーケストレーションをコマンド実行を通じて行う。haconiwa space runコマンドは、任意のコマンド（–cmd）や、–claude-codeのような特化された事前設定済みコマンドを、セッション内の全ペイン、あるいは特定のルームやペインに対して実行できる 1。

最近の開発活動（feat: Claude Code SDK並列実行機能を追加）は、この能力を強化することに焦点を当てていることを示している 22。これは、Haconiwaがエージェントの

実行環境と実行者として機能し、エージェントのロジック（例えば、Claude Codeのプロンプトや能力）は外部ツールによって提供されるという設計思想を裏付けている。Haconiwaは、これらのエージェントが活動するための構造化された舞台を提供するのである。

2.5. コマンドセンター：haconiwa CLI

ユーザーの主要なインターフェースであるhaconiwa CLIは、環境のライフサイクル管理、内観、および対話のためのコマンド群を提供する。

• ライフサイクルコマンド:
  • apply: YAMLファイルから環境を生成する。
  • space stop: tmuxセッションを停止する。
  • space delete: セッションを停止し、オプションで関連ディレクトリもクリーンアップする。
• 内観コマンド:
  • space list / space ls: Haconiwaが管理するアクティブなスペースを一覧表示する。
• 対話コマンド:
  • space attach: ユーザーのターミナルを特定のルーム（tmuxセッション）に接続する。
  • space run: セッション内でコマンドを実行する。

これらのコマンドは、宣言的な定義から対話的な操作、そしてクリーンな破棄まで、ワークフロー全体をサポートする。

表2: Haconiwa CLIコマンドリファレンス

出典: 1

第3章: 実践におけるHaconiwaワークフロー

前章で詳述した概念を具体化するため、ここではHaconiwaの典型的な利用シナリオをステップバイステップで解説する。

ステップ1：環境の定義
まず、開発者はプロジェクトの構造を定義するYAMLファイル（例：test-multiroom-with-tasks.yaml）を作成する 1。このファイルには、組織、所属するエージェント、使用するGitリポジトリ、そして各エージェントに割り当てられるタスクが宣言的に記述される。
ステップ2：環境のインスタンス化
次に、ユーザーは以下のコマンドを実行する。
haconiwa apply -f test-multiroom-with-tasks.yaml 1
このコマンドの実行により、HaconiwaはYAMLの定義を物理的な環境に変換する。具体的には、tmuxセッションが生成され、worktree: trueが指定された各タスクに対して、新しいディレクトリ（例：./test-multiroom-desks/tasks/20250609061748_frontend-ui-design_01/）と、そこに対応する新しいGitブランチが作成される 1。

ステップ3：対話と実行
環境が構築された後、開発者は以下のコマンドで対話を開始する。

• haconiwa space listを実行し、作成されたスペースを確認する 1。
• haconiwa space attach -c test-company-multiroom-tasks -r room-frontendのようなコマンドで、特定のtmuxセッションにアタッチし、エージェントの活動を直接監視する 1。
• haconiwa space run -c test-company-multiroom-tasks --claude-codeを実行し、すべてのエージェントに一斉に作業開始を指示する 1。このコマンドは、各
  tmuxペイン内で指定された処理を並列に実行する。

ステップ4：環境の破棄
作業が完了したら、haconiwa space stopでtmuxセッションを終了させるか、haconiwa space delete -c test-company-multiroom-tasks --clean-dirs --forceコマンドで、セッションと関連するすべての作業ディレクトリを完全にクリーンアップする 1。このライフサイクル全体を通じて、Haconiwaは複雑な環境のセットアップ、実行、破棄を体系的かつ再現可能な方法で管理する。

第4章: 戦略的分析と将来展望

Haconiwaの真価を理解するためには、その技術的実装だけでなく、LLMOpsエコシステム内での戦略的ポジショニング、セキュリティへのアプローチ、そして他のエージェントフレームワークとの関係性を分析する必要がある。

4.1. LLMOpsランドスケープにおけるポジショニング

Haconiwaは、LLMOpsの分野で発生する根本的な課題、特に環境の一貫性、再現性、そして複雑なパイプラインのオーケストレーションに関連する課題に対処するツールとして位置づけられる 23。

LLMOpsの文献では、データ準備、プロンプトエンジニアリング、デプロイメントといったLLMライフサイクル管理の難しさが指摘されており、特に堅牢で再現可能なパイプラインの構築が大きな課題とされている 24。Haconiwaは、この「パイプライン実行環境」に対するソリューションを提供する。環境設定全体をバージョン管理されたYAMLファイルで定義することにより、エージェントがテストまたは実行される環境が完全に再現可能であることを保証する。これは、一貫したテスト環境の必要性というLLMOpsの主要なハードルに直接応えるものであり、エージェントを開発ワークフローに統合するプロセスを大幅に簡素化する 27。したがって、HaconiwaはLLMアプリケーションフレームワークそのものではなく、エージェントのための再現可能でバージョン管理されたランタイム環境を提供することで、「入力とパイプライン」および「統合」の課題に取り組む、重要なLLMOpsツーリングレイヤーと見なすことができる。

4.2. セキュリティのフロンティア：Law CRDのポテンシャル

Haconiwaの計画されているセキュリティ機能、特にLaw CRDとagentDefaults.permissions 1は、宣言的なセキュリティモデルへのビジョンを示しており、将来性を評価する上で極めて重要である。LLMによって生成されたコードを実行することは本質的にリスクを伴うため 29、業界ではセキュアなサンドボックス化が活発に研究されている 31。

この問題に対するHaconiwaの提案は、Law CRDを通じてセキュリティポリシー（例：allow/denyコマンドパターン）を高度なYAMLファイルで定義するというものである 1。このアプローチは、LLMエージェントセキュリティに対する「Policy-as-Code」という先進的な概念を体現している。Haconiwaは、この高レベルなルールを、

seccomp-bpf 34 や

AppArmor 38 といった複雑な低レベルのサンドボックス技術に変換する「ポリシーコンパイラ」として機能する可能性がある。もしこれが実現すれば、エージェントの

tmuxペインやプロセスに適用される堅牢なseccompやAppArmorプロファイルを、ユーザーフレンドリーな宣言的形式で定義できるようになる。これは、高度なセキュリティ制御へのアクセスを民主化し、LLMOps分野における重要なイノベーションとなるだろう。

4.3. 比較分析：Haconiwa vs. エージェントフレームワーク

Haconiwaの独自の立ち位置を明確にするため、他の著名なエージェントフレームワークと比較する。

• AutoGPT: 単一の自律エージェントが目標を達成するための認知ループ（思考、推論、計画、行動）を提供することに焦点を当てている 41。これは
  エージェントの推論のためのフレームワークである。
• CrewAI: 複数の役割ベースのエージェント間の協調をオーケストレーションすることに焦点を当てている。エージェントがどのようにタスクを委任し、協力して問題を解決するかを定義する 44。これは
  エージェントの協調のためのフレームワークである。
• Haconiwa: これらのエージェントが活動する実行環境（ファイルシステムディレクトリとターミナルセッション）の作成、管理、分離に焦点を当てている。これは環境のオーケストレーションのためのフレームワークである。

この比較から、HaconiwaはAutoGPTやCrewAIのような「エージェントの振る舞いをオーケストレーションする」フレームワークとは異なり、「エージェントの環境をオーケストレーションする」ものであることがわかる。これらは技術スタックの異なる、しかし相互補完的なレイヤーで機能する。エージェントには「頭脳」（ロジック/認知アーキテクチャ）と「作業場」（実行環境）の両方が必要である。CrewAIやAutoGPTは「頭脳」を提供し、エージェントがどのように考え、相互作用するかを定義する。一方、Haconiwaは「作業場」を提供し、エージェントが互いに干渉することなく作業できる隔離されたgit worktreeディレクトリとtmuxペインをセットアップする。したがって、これらは競合関係にはなく、高度なワークフローでは、Haconiwaを使ってプロビジョニングされた環境にCrewAIエージェントのチームを展開して協調的にタスクを解決する、といった組み合わせが考えられる。

表3: 比較特徴分析：開発オーケストレーター vs. エージェントフレームワーク

出典: 1

4.4. 最終評価とプロジェクトの軌道

本レポートの分析を総括し、Haconiwaプロジェクトの現状と将来性を評価する。

• 現状: Haconiwaは、単一の作者による野心的なプロジェクトであり、現在バージョン0.4.0の初期アルファ段階にある 1。宣伝されている機能の多くはプレースホルダーか、活発な開発の途上にある 1。現時点での本番環境での使用は推奨されない 1。
• 強み: その中核となるアーキテクチャビジョンは革新的かつエレガントであり、AI支援ソフトウェア開発における現実的かつ新たな課題に対応している。tmuxとgit worktreeを基盤技術として選択したことは、技術的に健全であり、問題領域に非常によく適合している。
• 弱み/リスク: 初期段階のプロジェクトとして、機能の完成度、コミュニティの採用、長期的なメンテナンスに関するリスクに直面している。その成功は、主たる作者の継続的な貢献に大きく依存している。
• 将来の軌道: もし計画されている機能、特にLaw CRDが完全に実現されれば、HaconiwaはLLMOpsツールキットにおける基礎的なツールとなる可能性がある。それは、マルチエージェント開発のライフサイクル全体を管理するための、標準化され、安全で、宣言的な方法を提供するだろう。Haconiwaの未来は、その先見的なアーキテクチャを、堅牢で本番品質の実装によって証明できるかどうかにかかっている。

引用文献

1. dai-motoki/haconiwa - GitHub, 6月 14, 2025にアクセス、 https://github.com/dai-motoki/haconiwa
2. Haconiwa - GitHub, 6月 14, 2025にアクセス、 https://github.com/haconiwa
3. haconiwa/haconiwa: MRuby on Container / A Linux … - GitHub, 6月 14, 2025にアクセス、 https://github.com/haconiwa/haconiwa

4. haconiwa/haconiwa-mri: PoC code by MRI. see haconiwa/haconiwa

   Ruby on Container / helper tools with DSL for your handmade linux containers - GitHub, 6月 14, 2025にアクセス、 https://github.com/haconiwa/haconiwa-mri

5. Ansible vs. Docker - Pure Storage Blog, 6月 14, 2025にアクセス、 https://blog.purestorage.com/purely-educational/ansible-vs-docker/
6. Pretty much. I’ve been using Ansible with Docker Compose since 2015. I can set u… - Hacker News, 6月 14, 2025にアクセス、 https://news.ycombinator.com/item?id=35268244
7. How I Switched from Docker-Compose to Pure Ansible - Red Hat, 6月 14, 2025にアクセス、 https://www.redhat.com/en/blog/how-i-switched-from-docker-compose-to-pure-ansible
8. Why I use Ansible over docker-compose - DEV Community, 6月 14, 2025にアクセス、 https://dev.to/kuwv/why-i-use-ansible-over-docker-compose-edg
9. Ansible vs Docker Compose for Container Orchestration : r/selfhosted - Reddit, 6月 14, 2025にアクセス、 https://www.reddit.com/r/selfhosted/comments/1czgjwv/ansible_vs_docker_compose_for_container/
10. Docker vs ansible : r/devops - Reddit, 6月 14, 2025にアクセス、 https://www.reddit.com/r/devops/comments/1ctf4pq/docker_vs_ansible/
11. Exploring the Benefits of Git Worktree Livefront Digital Product Consultancy, 6月 14, 2025にアクセス、 https://livefront.com/writing/exploring-the-benefits-of-git-worktree/
12. Git Worktrees: The Most Underappreciated Feature - SimpleBackups, 6月 14, 2025にアクセス、 https://simplebackups.com/blog/git-most-underappreciated-feature
13. LLM Codegen go Brrr – Parallelization with Git Worktrees and Tmux - DEV Community, 6月 14, 2025にアクセス、 https://dev.to/skeptrune/llm-codegen-go-brrr-parallelization-with-git-worktrees-and-tmux-2gop
14. Why I *love* TMUX - DEV Community, 6月 14, 2025にアクセス、 https://dev.to/antjanus/why-i-love-tmux-12ak
15. TMUX: Basic Usage for ML Practitioners extras – Weights & Biases - Wandb, 6月 14, 2025にアクセス、 https://wandb.ai/wandb_course/extras/reports/TMUX-Basic-Usage-for-ML-Practitioners–VmlldzoyMjgyMDIx
16. Building News Agents to Summarize News with MCP, Q, and tmux - GitHub, 6月 14, 2025にアクセス、 https://github.com/eugeneyan/news-agents
17. Tmux Control Lib: AI-Powered Tmux Session Automation - MCP Market, 6月 14, 2025にアクセス、 https://mcpmarket.com/server/tmux-control-lib
18. Git Worktrees and GitButler, 6月 14, 2025にアクセス、 https://blog.gitbutler.com/git-worktrees/
19. Git Worktree: Manage Git Workflow Efficiently - DevDynamics, 6月 14, 2025にアクセス、 https://devdynamics.ai/blog/understanding-git-worktree-to-fast-track-software-development-process/
20. Git Worktrees: Boost Productivity with Parallel Branching - Devōt, 6月 14, 2025にアクセス、 https://devot.team/blog/git-worktrees
21. What would I use git-worktree for? - Stack Overflow, 6月 14, 2025にアクセス、 https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for
22. Activity · dai-motoki/haconiwa - GitHub, 6月 14, 2025にアクセス、 https://github.com/dai-motoki/haconiwa/activity
23. LLMOps: Overcoming Text Data & LLM Challenges SoftServe, 6月 14, 2025にアクセス、 https://info.softserveinc.com/future-of-ai-applications-part-2-white-paper
24. LLMOps: What It Is, Why It Matters, and How to Implement It - Neptune.ai, 6月 14, 2025にアクセス、 https://neptune.ai/blog/llmops
25. LLMOps: The Hidden Challenges No One Talks About - HatchWorks, 6月 14, 2025にアクセス、 https://hatchworks.com/blog/gen-ai/llmops-hidden-challenges/
26. Overcoming Challenges in LLMOps Implementation - Deepchecks, 6月 14, 2025にアクセス、 https://www.deepchecks.com/overcoming-challenges-in-llmops-implementation/
27. The State of LLM Operations or LLMOps: Why Everything is Hard (And That’s OK) - ZenML, 6月 14, 2025にアクセス、 https://www.zenml.io/blog/state-of-llmops-why-everything-is-hard
28. LLMOps unpacked: the operational complexities of LLMs Tryolabs, 6月 14, 2025にアクセス、 https://tryolabs.com/blog/llmops-unpacked-the-operational-complexities-of-llms
29. Secure code execution - Hugging Face, 6月 14, 2025にアクセス、 https://huggingface.co/docs/smolagents/tutorials/secure_code_execution
30. SandboxEval: Towards Securing Test Environment for Untrusted Code - arXiv, 6月 14, 2025にアクセス、 https://arxiv.org/html/2504.00018v1
31. Setting Up a Secure Python Sandbox for LLM Agents - dida Machine Learning, 6月 14, 2025にアクセス、 https://dida.do/blog/setting-up-a-secure-python-sandbox-for-llm-agents
32. Code Sandboxes for LLMs and AI Agents Amir’s Blog, 6月 14, 2025にアクセス、 https://amirmalik.net/2025/03/07/code-sandboxes-for-llm-ai-agents
33. Sandboxed Code Execution - Modal, 6月 14, 2025にアクセス、 https://modal.com/use-cases/sandboxes
34. Securing Containers with Seccomp - GitGuardian Blog, 6月 14, 2025にアクセス、 https://blog.gitguardian.com/securing-containers-with-seccomp/
35. avilum/secimport: The first open-source eBPF sandbox for Python (macOS/Linux) - GitHub, 6月 14, 2025にアクセス、 https://github.com/avilum/secimport
36. Reference Guide — seccomp documentation - pkgbuild.com, 6月 14, 2025にアクセス、 https://pkgbuild.com/~jelle/seccomp/function_reference.html
37. Seccomp filtering, 6月 14, 2025にアクセス、 https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
38. [apparmor] AppArmor dependency on python, 6月 14, 2025にアクセス、 https://apparmor.narkive.com/qJU3v3ig/dependency-on-python
39. AppArmor / apparmor · GitLab, 6月 14, 2025にアクセス、 https://gitlab.com/apparmor/apparmor/-/tree/master
40. Debian -- Details of package python3-apparmor in buster, 6月 14, 2025にアクセス、 https://packages.debian.org/buster/python3-apparmor
41. Everything You Need to Know About the AutoGPT Platform, 6月 14, 2025にアクセス、 https://autogpt.net/everything-you-need-to-know-about-the-autogpt-platform/
42. Decoding Auto-GPT - Maarten Grootendorst, 6月 14, 2025にアクセス、 https://www.maartengrootendorst.com/blog/autogpt/
43. AutoGPT: Exploring The Power of Autonomous AI Agents - Webisoft, 6月 14, 2025にアクセス、 https://webisoft.com/articles/autogpt/
44. CrewAI: Introduction, 6月 14, 2025にアクセス、 https://docs.crewai.com/introduction
45. Framework for orchestrating role-playing, autonomous AI agents. By fostering collaborative intelligence, CrewAI empowers agents to work together seamlessly, tackling complex tasks. - GitHub, 6月 14, 2025にアクセス、 https://github.com/crewAIInc/crewAI
46. Crewai: Features, Use Cases & Alternatives - Metaschool, 6月 14, 2025にアクセス、 https://metaschool.so/ai-agents/crewai