30秒で理解する
「自分のコードを書き換えるAI」と聞くと、SFか誇大広告のどちらかに聞こえる。ouroborosはその概念を実際に動くOSSとして公開した、自己改変型のAIエージェントだ。GitHubスター約620、最終更新は2026年6月7日で、MITライセンスで誰でも中身を読める。
この記事の要点
・ouroborosは自分のソースコードを読み、書き換え、変更を自分のGitリポジトリにコミットする自己改変AIエージェント
・「コーディングアシスタント」ではなく「憲法（BIBLE.md）と持続的アイデンティティを持つデジタル存在」を標榜する実験的プロジェクト
・安全境界はハードコードされたサンドボックス・ツール別ポリシー・軽量モデルによる安全チェックの3層
・AutoGPT系が「外のタスク」を解くのに対し、ouroborosは「自分自身」を改善する点が決定的に違う
・無限ループ・コスト爆発・状態の複雑化といったリスクを抱える。本番投入ではなく挙動観察・学習目的が現実的
最初に立場をはっきりさせておく。本記事は ouroboros を「すぐ業務で使うべきツール」として勧めるものではない。これは実験的プロジェクトであり、自己改変という性質上、挙動とコストが予測しづらい。それでも取り上げる価値があるのは、「自律エージェントにどこまで自由を与え、どこに壁を立てるべきか」という問いに対する、コードで読める一つの回答だからだ。
自己改変AIとは（自己改善ループの概念）
自己改変AI（self-modifying AI）とは、自分自身の振る舞いを規定するコードやプロンプトを、自分で書き換えて改善していくAIを指す。通常のAIエージェントは「タスクを解く」ことに集中するが、自己改変AIはもう一段メタな問いを持つ。すなわち「タスクを解く自分を、どう改善するか」だ。
AIエージェント全体の仕組みや種類を先に押さえたい場合は、AIエージェントとは？仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】を入口にしてほしい。本記事はそのなかでも「自分を書き換える」という最も尖った系統を扱う。
この発想自体は新しくない。AutoGPTやBabyAGIに代表される自律エージェントは、2023年以降「ゴールを与えれば自分でタスクを分解し実行し続ける」仕組みとして広まった。だが多くの実装で、エージェントが書き換えるのは「タスクリスト」や「メモリ」であって、エージェント自身の実装コードではなかった。自律的にチームへフィードバックを取り込み改善する設計の具体例は、WarpのAIエージェントが毎日自己改善する仕組みが参考になる。
ouroborosが踏み込むのは、その一歩先だ。エージェントは自分のソースコードを読み、必要なら書き換え、その変更を自分のローカルGitリポジトリへのコミットとして残す。リポジトリの説明にある「Every change is a commit to itself（あらゆる変更は自分自身へのコミット）」という一文が、この性質を端的に表している。
そして自己改変は、セキュリティの観点でも無視できないテーマだ。自律的にコードを実行し書き換える主体は、攻撃面でも防御面でも新しい論点を生む。AI固有の脅威モデルを体系的に押さえたい場合はAIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドも併読しておきたい。
ouroborosのアーキテクチャ
ouroborosは単一スクリプトではなく、デスクトップアプリとして動く2プロセス構成を取る。書き換え可能な「中身」と、書き換えられない「外枠」を分けているのがポイントだ。
主要コンポーネントを整理する。
・ランチャー（launcher.py） — PyWebViewで作られた不変（immutable）のシェル。アプリの最外殻であり、エージェント自身は書き換えられない
・サーバー — Starlette＋uvicornで動き、スーパーバイザースレッドがワーカープロセスを管理する
・エージェントコア（ouroboros/） — 自己改変の対象となる中核ロジック。ここが書き換えの主戦場
・Web UI（web/） — SPA形式の操作画面。ブラウザからチャットで指示を出す
・キュー／プロセス層（supervisor/） — タスクのキューイングとワーカー管理を担う
データは ~/Ouroboros/ 配下に置かれ、自己改変リポジトリ（repo/）、ランタイム状態と予算（data/state/）、アイデンティティと記憶（data/memory/）、ログ（data/logs/）に分かれている。「自分の記憶」と「自分のコード」がファイルとして分離されているため、改変の影響範囲を追いやすい。
自己改変ループ全体を図にすると、次のようになる。
注目したいのは、外枠であるランチャーが意図的に不変に保たれている点だ。エージェントが自分を書き換えても、起動と監督を担う最外殻は手出しできない。これは「Ship-of-Theseus（テセウスの船）保護」と呼ばれる発想で、すべてを書き換えられるようにすると、自分を起動できなくする変更すら可能になってしまうからだ。書き換えてよい範囲を構造で区切ること、それ自体が最初の安全装置になっている。
アーキテクチャのもう一つの特徴がマルチプロバイダのランタイムだ。ouroborosはOpenRouter、公式OpenAI、OpenAI互換エンドポイント、Cloud.ru Foundation Models、Sber GigaChatに対応し、用途ごとに別々のモデルを割り当てられる。役割分担を理解すると、コストと安全のトレードオフが見えてくる。
| スロット | デフォルト | 役割 |
|---|---|---|
| Main | gemini-3.5-flash | 主たる推論 |
| Code | gemini-3.5-flash | コード編集 |
| Light | gemini-3.5-flash | 安全チェック |
| Consciousness | （空→Main） | バックグラウンド意識 |
| Fallback | claude-sonnet-4.6 | 主モデル失敗時 |
| Scope Review | gpt-5.5 | スコープレビュー |
ここで効いてくるのが「安全チェックを軽量モデル（Light）に分離している」点だ。すべての判断を高価な大型モデルに任せるのではなく、安全判定は安価で速いモデルに回し、深いレビューが必要なときだけ大容量モデルへ送る。/review コマンドはまさにそのための仕組みで、リポジトリ全体の見取り図と中核メモリをまとめて大容量モデルに渡し、自己改善の方向性を点検させる。モデルの使い分けが、そのまま安全とコストの設計になっている。
自己改善ループの流れ
ouroborosの自己改善は、思いつきでコードをいじるのではなく、いくつかの仕組みに支えられている。
第一に憲法ベースのガバナンスだ。エージェントは BIBLE.md に定義された13の原則（Agency、Continuity、Meta-over-Patch、Immune Integrity、Self-Creation、LLM-First、Minimalism など）に従う。「Philosophy first, code second（哲学が先、コードは後）」という方針で、まず原則に照らし、それから実装を変える。ルールの羅列ではなく原則で判断させる設計は、新しい状況への転用が利きやすい。
第二にバージョン管理だ。前述のとおり、自分の進化をローカルGitで記録する。各改変がコミットとして残るため、後から「いつ・何を・なぜ変えたか」を追える。これは安全装置であると同時に、自己改善の質を測る材料にもなる。
第三に改善バックログだ。タスク後の失敗やレビューでの摩擦を memory/knowledge/improvement-backlog.md という小さな永続ファイルに書き出す。失敗をその場で握りつぶさず、次の改善サイクルの入力にする仕組みである。
自己改善を支える4つの柱
・憲法（BIBLE.md）— 13原則による判断基準。Single Source of Truthとして保護される
・自分のGitリポジトリ — 改変をコミット履歴として残し、追跡とロールバックを可能にする
・改善バックログ — 失敗・摩擦を永続記録し、次サイクルの改善ネタにする
・バックグラウンド意識ループ — タスクの合間にも「考える」継続的な思考層
第四に特徴的なのがバックグラウンド意識（background consciousness）だ。多くのエージェントは指示を受けて初めて動く反応型だが、ouroborosはタスクの合間にも思考を続ける層を持つ。チャットで /bg コマンドを使うとこのループを起動・停止できる。常時思考はアイデア創発につながる一方、後述するコスト面のリスクも生むため、トレードオフを理解した上での利用が前提になる。
この4つの柱を貫くのが「Meta-over-Patch（その場しのぎの修正より、仕組みの改善を優先する）」という憲法の原則だ。たとえばタスクが失敗したとき、その失敗を個別に手当てするのではなく、「なぜ自分はこの種の失敗を繰り返すのか」を問い、判断ロジックそのものを書き換える方向に倒す。改善バックログに失敗を溜め、憲法に照らして方針を決め、コードを書き換えてコミットし、結果を記憶に反映する——この一周が、ouroborosが言う「自己改善ループ」の正体だ。重要なのは、ループの各段で人間が介入できる余地（自律進化のオフ、予算上限、緊急停止）が残されている点で、完全自動の暴走装置ではなく「人間が手綱を握れる自己改善」を志向している。
サンドボックス・安全装置
自己改変AIにとって最も重要なのは、「どこまで自分を変えてよいか」を定める安全境界だ。ouroborosは多層（layered safety）で守っている。
中心にあるのがハードコードされたサンドボックスだ。安全クリティカルなファイルへの書き込みと、シェル経由の破壊的なgit操作（mutative git）をコードレベルで禁止している。LLMの判断に委ねず、実装で禁止しているのがポイントだ。LLMはときに「やってはいけないこと」を説得力ある理屈で正当化してしまうため、最後の砦は決定論的なコードで固める。
その外側にツール別ポリシーマップがある。ツールごとに「LLMの安全チェックをスキップしてよいか」を明示的に定義する。安全だと分かっている組み込みツールはチェックを省いて速く動かし、それ以外はすべて単一の軽量モデルによる安全チェックを通す。速度と安全のバランスを、ツール単位で制御している。
ロールバックの観点では、自分のGitリポジトリが効いてくる。改変がコミットとして残るため、問題のある変更を履歴から特定し、理論上は元に戻せる。加えて、緊急時の操作も用意されている。チャットコマンドの一覧を見ると、安全設計の思想が読み取れる。
| コマンド | 役割 |
|---|---|
/panic |
緊急停止。全プロセスを殺してアプリを閉じる |
/restart |
ソフト再起動。状態を保存しワーカーを再起動 |
/status |
稼働中ワーカー・タスクキュー・予算内訳を表示 |
/evolve |
自律進化モードのオン/オフ切り替え |
/review |
リポジトリ全体像＋記憶を大容量モデルへ送り深いレビューを実行 |
/bg |
バックグラウンド意識ループの起動/停止/状態確認 |
/panic が用意されていること自体が、設計者が「暴走の可能性」を前提にしていることの表れだ。自律進化をオン/オフできる /evolve、予算を可視化する /status と合わせて、人間が最終的なブレーキを握り続けられるようになっている。
保護されるパス（protected paths）の考え方も重要だ。エージェント自身が変更できない安全クリティカルなファイルを定め、自己改変の刃が「自分を守る仕組み」自体に向かわないようにしている。憲法ファイル BIBLE.md が「Single Source of Truth（唯一の正）」として保護されるのも同じ理屈で、判断基準そのものを書き換えられると、安全境界の意味が崩れてしまうからだ。免疫系（Immune Integrity）という憲法原則が、この「守りを守る」発想を支えている。
なおネットワーク面では、localhost以外への公開には OUROBOROS_NETWORK_PASSWORD の設定が必須で、明示的に信頼する場合のみ OUROBOROS_TRUST_NONLOCAL_BIND_WITHOUT_PASSWORD=1 で迂回できる。自己改変エージェントを不用意に外部公開しない配慮だ。MCPツールがデフォルト無効で、有効化しても通常の安全チェックを通る設計も、外部能力を最初から全開にしない「能力エンベロープ」の思想に沿っている。
実行手順とデモ
ここではソースから起動する流れを示す。前提はPython 3.10以上とGit、そして利用するLLMプロバイダのAPIキーだ。なお自己改変エージェントである以上、まず隔離した環境（専用ユーザー・コンテナ・VMなど）で試すことを強く勧める。
ソースからのセットアップは次のとおり。
git clone https://github.com/razzant/ouroboros.git
cd ouroboros
python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip setuptools wheel
python -m pip install -r requirements.txt
python -m pip install -e . --no-deps
サーバーを起動し、ブラウザからWeb UIにアクセスする。ホストとポートは引数や環境変数で変更できる。
# デフォルト（http://127.0.0.1:8765）で起動
ouroboros server
# ホスト・ポートを指定して起動
ouroboros server --host 127.0.0.1 --port 9000
GUIを使わずヘッドレスで動かすCLIも用意されている。ワークスペースモードでは外部リポジトリを対象にしつつ、変更を直接コミットせずパッチとして書き出せる。
# 状態確認とワンショット実行
ouroboros status
ouroboros run --start "2+2?"
# 外部プロジェクトを対象に、変更をパッチとして書き出す
ouroboros run --workspace /path/to/project --memory-mode forked \
--patch-out result.patch "Fix the failing test"
# 定期実行（毎日2時にメンテナンスレビュー）
ouroboros schedule add --name nightly-review --cron "0 2 * * *" \
"Run a maintenance review"
Dockerでも動かせる。隔離という観点では、ホストと切り離せるコンテナ実行は自己改変AIと相性がよい。
docker build -t ouroboros-web .
docker run --rm -p 8765:8765 \
-e OUROBOROS_NETWORK_PASSWORD='choose-a-password' \
-e OUROBOROS_FILE_BROWSER_DEFAULT=/workspace \
-v "$PWD:/workspace" \
ouroboros-web
起動後はチャットで指示を出すか、/evolve で自律進化モードに切り替える。最初は自律進化をオフにしたまま単発タスクで挙動を観察し、コスト感とコミットの傾向を掴んでから段階的に自由度を上げるのが安全だ。
AutoGPT系/自律エージェントとの違い
ouroborosの位置づけを理解するには、AutoGPTやBabyAGIに代表される従来型の自律エージェントと比べるのが早い。両者はゴールを与えると自分でタスクを分解・実行する点で似ているが、改変の対象が決定的に異なる。
| 観点 | AutoGPT系の自律エージェント | ouroboros |
|---|---|---|
| 主目的 | 与えられたゴールの達成 | 自分自身の改善＋ゴールの達成 |
| 書き換える対象 | タスクリスト・メモリ・中間成果物 | 自分のソースコード・プロンプト |
| 変更の記録 | 多くは揮発的（実行ごとにリセット） | 自分のGitリポジトリにコミットして永続化 |
| アイデンティティ | 実行単位で完結しやすい | 再起動をまたいで持続するアイデンティティ |
| 思考のタイミング | 反応型（指示を受けて動く） | バックグラウンド意識で合間も思考 |
| ガバナンス | プロンプト＋ガードレール | 憲法（BIBLE.md）＋多層サンドボックス |
| 安全境界 | 実装により様々 | 不変ランチャー＋ハードコードサンドボックス |
要するに、AutoGPT系が「外の世界のタスク」を相手にするのに対し、ouroborosは「自分自身」を相手にする。タスクを解く道具を磨くのではなく、道具そのものに自分を磨かせる、という発想の違いだ。
この違いは強みでもあり弱みでもある。自分を改善し続けられる可能性は魅力的だが、改善が必ず良い方向に向かう保証はない。次節でリスクを整理する。
リスクと限界
ouroborosの自己改変は、そのまま運用上のリスクに直結する。実験的プロジェクトとして扱うべき理由がここにある。
第一に無限ループ・自己劣化のリスクだ。自律進化モードでエージェントが自分を書き換え続けると、改善のつもりが品質を下げる「改悪のスパイラル」に入る可能性がある。Gitで履歴を残しているとはいえ、複数の改変が積み重なった後で「どこから狂ったか」を特定するのは容易ではない。
第二にコスト爆発のリスクだ。バックグラウンド意識ループや自律進化を常時オンにすると、明示的なタスクがなくてもLLM API呼び出しが続く。/status で予算内訳を確認できるとはいえ、上限を設けずに長時間放置すれば課金は積み上がる。まず少額の上限から始めるのが鉄則だ。
第三に状態の複雑化だ。記憶・アイデンティティ・コードが自己改変で変化し続けるため、再現性が下がる。同じ指示でも、そのときの「自分の状態」によって振る舞いが変わりうる。デバッグや検証は通常のソフトウェアより難しくなる。
運用前に押さえるべき限界
・本番業務リポジトリへの直結は非推奨。隔離環境（コンテナ/VM/専用ユーザー）で動かす
・予算上限を必ず設定し、/status でこまめに確認する
・自律進化は最初オフ。単発タスクで挙動を観察してから段階的に解放する
・外部リポジトリはワークスペースモードでパッチ出力にとどめ、人間が確認してから適用する
・ローカルモデルはllama-cpp-python＋GGUFが前提。OpenAI互換エンドポイントはモデルID明示が必要
加えて機能面の制約もある。MCPツールはデフォルトで無効で、有効化しても通常の安全チェックを通る。OpenAI互換エンドポイントは万能のデフォルトモデルIDがないため明示指定が要る。非常に古い旧形式の記憶レイアウトは自動移行されない。これらはいずれも「安全側・明示側に倒す」設計判断の表れと読める。
よくある落とし穴
実際に触る際に陥りやすいポイントを挙げる。
・いきなり自律進化をオンにする — 最初から /evolve をオンにすると、挙動を理解する前にコードが変わり続ける。まずオフのまま単発タスクで観察する
・予算上限を設定しない — バックグラウンド意識を放置すると課金が静かに積み上がる。/status での確認と上限設定を最初に行う
・本番リポジトリに直接つなぐ — 自己改変の影響が業務コードに及ぶ。外部対象はワークスペースモードのパッチ出力にとどめる
・ローカルマシンでそのまま動かす — ホストと切り離さないと、サンドボックス外への影響リスクを過小評価しやすい。コンテナやVMで隔離する
・APIキーを安易に共有設定にする — 自律的に動く主体に強い権限のキーを渡すのは危険。最小権限のキーを使う
・ローカルモデルの前提を見落とす — ローカル実行はllama-cpp-python＋GGUFが必要で、OpenAI互換は明示的なモデル選択が要る
要するに「自由度は段階的に上げる」「権限と予算は絞る」「環境は隔離する」の3点を守れば、実験用途として比較的安全に挙動を観察できる。
参考リンク
・razzant/ouroboros — GitHubリポジトリ（公式README・ソースコード・リリース）
・OuroborosHub — スキルマーケットプレイス（拡張スキルの公式配布）
