AIエージェントに「憲法」を与える——ガバナンスフレームワーク「Axiarch」を作った理由と設計思想

AIエージェントが登場したとき、最初に考えたのは「どう使うか」ではなく、「どう統治するか」でした。

ChatGPTが登場した当初から、業務でAIを使ってきた経験があります。
コードを書かせるためではなく、新規事業の構想や実務での活用という感じです。
その中でひとつだけ、ずっと確信していたことがありました。

明確なルールなしに使い続ければ、品質は静かに、しかし確実に劣化していく。
「かもしれない」ではなく、「必ずそうなる」という感覚でした。

AIエージェントが登場して実際に触れてみると、その確信はすぐに裏付けられた。
同じタスクでも指示の書き方次第で結果が全然変わる。
セッションをまたぐたびに、それまで積み上げてきた文脈がリセットされる。
AIは人間のように問題を起こす——忘れる、ブレる、時には幻覚を見る。

本格的に開発を進める前に、まずガバナンス構造を整備しようと思いました。
コードを一行も書かせる前に「憲法」を作ることにしました。
AIが何を守るべきかを定義して、それを無視できない仕組みにする。
誰が操縦しても品質の床がずれない構造を、最初に作ってから開発を始めました。

その成果が、2026年4月10日に公開したOSS「Axiarch（アクシアーク）」です。
本記事では、なぜAxiarchを作ったのか、どんな設計思想に基づいているのか、そして何が変わるのかを、作者本人の視点から書いていきます。

※本記事は、AIエージェントを業務や開発で活用している方、バイブコーディングに取り組んでいる方、AI活用の品質やガバナンスに関心のある方向けに書かれています。

要点サマリー

AIエージェントの品質は、プロンプトの書き方や操縦者のスキルによって大きくばらつく。

Axiarchは「誰が操縦しても品質の床がずれない」構造を実現する、憲法駆動型のAIエージェントガバナンスフレームワークです。
Universal（不変）・Blueprint（可変）・Prompts（任意）の3層設計により、AIのコンテキスト忘却や品質ドリフトを構造的に抑制する。

Apache 2.0のOSSとして公開されており、個人開発において「Google Antigravity」での実戦検証済みです。

主要エンティティ

Axiarchを構成する主要な概念と要素を整理する。
それぞれが独立しているようで、実は深く連動している。
それぞれの役割と関係性を理解することで、なぜこの設計が有効なのかが見えてくる。

エンティティ	区分	補足
Axiarch	フレームワーク全体	憲法駆動型AIエージェントガバナンスフレームワーク。 Apache 2.0 OSS
Universal Rules	第1層（不変）	38ファイル・2,500以上の基準。 AIが最優先で従う不変の憲法
Blueprint	第2層（可変）	プロジェクト固有の仕様・教訓ログ。 開発とともに成長する
Prompts	第3層（任意）	監査・品質担保用の実行プロンプト。 憲法が先にあって機能する
AGENTS.md	最高法規	AIエージェントが最初に読み込む最上位の行動プロトコル
結晶化プロトコル	知見継承の仕組み	セッション終了前に教訓をルールに変換し、知見の消失を防ぐ
Quality Floor	設計思想の核心	操縦者のスキルに依存しない最低品質の保証ライン
Google Antigravity	検証環境	Axiarchを実戦投入し、数百セッションかけて検証したAIエージェント

AIエージェントが登場して、最初に考えたこと

AIエージェントが市場に出始めた頃、多くの人が「何を作れるか」を考えていたと思う。
自分が考えていたのは、「何を作れるか」もそうですがまた別のことも同時に考えていました。

ChatGPTが登場した当初から、業務でAIを活用していました。
コードを書かせるためではなく、事業設計や市場分析、意思決定の補助として使ってきた経験があります。
その経験の中で、ひとつの確信が生まれていました。
明確なルールなしに使い続ければ、品質は静かに、しかし確実に劣化していく。

なぜそう確信したのか。
AIは人間と同じように問題を起こすと思っていたからです。
忘れる。ブレる。時には幻覚を見る。

そこに指示のばらつきが重なれば、品質の一貫性は保てない。

AIエージェントが登場して試してみると、その確信はすぐに裏付けられました。
同じタスクでも指示の書き方次第で結果が変わる。
セッションが終わるたびに、積み上げてきた文脈がゼロにリセットされる。
「もっとうまく指示しよう」という解決策では、根本的な問題は解決しない。

問題の本質は「指示のばらつき」ではなく「構造の不在」

うまく指示できるかどうかは、操縦者のスキルに依存する。
スキルに依存するということは、品質も操縦者によってばらつくということです。
そしてスキルが高い人が作ったルールも、セッションが終われば消える。

これは「プロンプトエンジニアリング」の問題ではなく、ガバナンス構造の不在という問題です。
どれだけ優れたプロンプトを書いても、それをAIが「忘れない仕組み」がなければ意味がない。
必要なのは、うまい指示ではなく、AIが無視できないルールの体系でした。

では、なぜ「うまく指示する」だけでは根本的に解決しないのか。
その理由を次の章で整理していきます。

なぜ「うまく指示する」だけでは解決しないのか

「プロンプトエンジニアリング」という言葉が注目されるようになっていました。
AIへの指示の精度を上げることで、出力品質を高めようという考え方です。

これは一定の効果がある。
しかし、根本的な問題は解決しない。

問題の本質を整理すると、次の通りです。

問題	原因	プロンプト改善で解決できるか
出力品質のばらつき	指示の書き方と操縦者スキルへの依存	部分的にのみ
コンテキストのリセット	セッション間の記憶がない	できない
品質ドリフト（退行）	ルールが形骸化・上書きされる	できない
知見の消失	教訓がセッション終了とともに消える	できない
幻覚・ルール無視	AIが構造を認識していない	できない

プロンプトを改善することで改善できるのは、このうち「指示の精度」の部分だけです。
セッションをまたぐ記憶の保持、ルールの恒久的な強制、知見の継承——これらはプロンプトでは解決できない。

「指示する」から「統治する」へのパラダイムシフト

解決策は、AIをうまく操縦することではなく、AIが従う憲法を先に定義することです。

人間組織に置き換えると分かりやすい。
優れたリーダーがいれば組織は動く。

しかし、そのリーダーが去れば組織は崩れる。
恒久的に機能する組織には、個人に依存しないルール体系——つまり「憲法」が必要です。

AIエージェントも同じです。
優秀な操縦者のプロンプトに依存するのではなく、AIが無視できない憲法を先に定義する。
その考え方がAxiarchの出発点でした。

事業設計においても、ガバナンス構造の重要性は同じです。
COOに必要なオペレーション視点でも触れているように、個人のスキルに依存しない構造設計こそが、組織の持続的な品質を担保します。

実務チェックリスト

• 「指示を改善する」ではなく「ガバナンス構造を設計する」観点で現状を見直す
• 現在のAI活用が「操縦者のスキル」に依存しているか評価する
• セッション間で引き継がれるべきルールを明文化できているか確認する

Axiarchの3層ガバナンス設計

Axiarchの中核は、3層に分かれたガバナンスアーキテクチャです。
それぞれの層が明確な責務を持ち、物理的に分離されている。

層	名称	変更可否	主な役割
第1層	Universal（普遍憲法）	不変	AIが最優先で従う普遍的基準。 38ファイル・2,500以上の基準を格納。
第2層	Blueprint（固有仕様）	可変	プロジェクト固有の技術仕様・教訓ログ。 開発とともに成長する。
第3層	Prompts（実行エンジン）	任意	監査・品質担保タスク用の実行プロンプト。 憲法が先にあって機能する。

第1層のUniversalは「物理法則」として設計されている

エンジニアリングだけでなく、プロダクト戦略・収益設計・セキュリティ・SREまで、各領域の世界水準のベストプラクティスを徹底的に調査・分析して体系化した2,500以上の基準が含まれる。
これは「AIが守るべき最低基準」を、プロジェクトや操縦者に関わらず強制するための設計です。

なぜ「不変層」と「可変層」を物理的に分ける必要があったのか。

開発を進める中で、あることに気づいていました。
「絶対に守り続けてほしいルール」と「このタスクに合わせて変えてほしいルール」が同じ場所に混在していると、AIがどちらを優先すべきか判断できなくなる瞬間が来る。

セキュリティ基準のような「絶対に変えてはいけないもの」と、機能仕様のような「開発が進むにつれて変わっていくもの」は、性質が根本的に異なります。
同じ場所に置いておくと、可変であるべきものが不変のものを侵食するか、不変であるべきものが可変なものとして扱われるかのどちらかが起きる可能性が高い。

だから分ける必要がありました。
物理的な層として分離することで、「これは絶対に守る」「これはプロジェクトに合わせて更新する」という責務を構造で強制する設計にしました。

第2層のBlueprintは、プロジェクト固有の情報を格納する

技術スタック・機能仕様・過去の教訓・禁止事項などが含まれ、開発が進むにつれて成長していく。
Universalとは異なり、可変であることがこの層の特徴です。

第3層のPromptsは任意です

ただし、Universalという憲法が先に存在するからこそ、このプロンプトが有効に機能します。
憲法なしにプロンプトだけを使っても、それは「うまい指示」の域を出ません。

Boot Sequence Protocolという仕組み

Axiarchには、AIエージェントが起動時にルールを読んでから行動することを促す「Boot Sequence Protocol」がある。

これは「まずルールを読んでから行動せよ」という手順を定義した仕組みです。
AGENTS.md（最高法規）を最初に読み込み、次にUniversal Rules、そしてBlueprintの順でルールを階層的にロードする設計になっています。
これにより、AIが「プロジェクト構造を幻覚で生成する」という典型的な問題を構造的に抑制します。

後から知った、設計思想の重なり

Axiarchを作り終える少し前、YouTubeで「Anthropic」が2026年1月に発表したClaudeの新しいConstitutionについての解説動画を見る機会がありました。

そこには、Claude自身の行動を規律するための設計として「hardcoded（絶対に変えない）」と「softcoded（状況に応じて調整できる）」という2層構造が採用されているようでした。
絶対に守るべき原則と、状況に応じて調整できる部分を明確に分離するという考え方でした。（参照：Claude’s new constitution – Anthropic）

SDDもTDDも、このConstitutionも、Axiarchを作り始めた時点では知りませんでした。
同じような問題を深く考え続けた結果として近い構造に辿り着いていたことは、設計の方向性が根本的に間違っていなかったという確信につながりました。

詳細なアーキテクチャは「Axiarch公式リポジトリ」で確認できます。

構造の設計ができたとして、次に課題になったのは「開発の順序」でした。
どれだけ良い憲法を作っても、使い方の順序が間違っていれば意味がありません。

コードより先に「憲法」を作るという逆転発想

多くのプロジェクトでは、まずコードを書き始める。
仕様が決まってから、あるいは決まらないまま、開発が先行する。
Axiarchの設計思想は、その順序を逆転させる。

「Blueprint First」——コードより先に仕様を定義せよ。

これはバイブコーディング（AIエージェントに自然言語で指示してコードを生成させる開発スタイル）において、特に重要になる考え方です。
バイブコーディングでは「とにかく動くものを素早く作れる」という利点がある一方、仕様の定義なしに進めると品質が安定しないという問題があります。

仕様なき開発が引き起こす問題

問題	具体的な現象	Axiarchでの対応
品質のばらつき	指示次第で全く異なる実装が生まれる	Universal Rulesが最低品質基準を設定
仕様の揺れ	セッションごとに設計方針が変わる	BlueprintがプロジェクトのSingle Source of Truth
知識の消失	教訓がセッション終了とともに消える	結晶化プロトコルで教訓をルールに変換
AI幻覚	プロジェクト構造を誤って生成する	Boot Sequence Protocolで構造を先に読み込ませる

Blueprint Firstとは、コードを一行も書く前に「このプロジェクトで何を守るべきか」を文書化することを意味する。
これにより、AIエージェントはプロジェクト固有の文脈を理解した上でコードを生成できる。

「Google Antigravity」での実際の開発（個人開発）に持ち込み、数百セッションを経てこのアプローチを検証してきました。
「Axiarch公式リポジトリ」のドキュメントに、この設計原則の詳細が記載されています。

実務チェックリスト

• AIエージェントに作業を依頼する前に、プロジェクトの仕様が文書化されているか確認する
• 「とりあえず作ってみる」ではなく「まず仕様を定義する」順序を実践できているか問い直す
• Blueprintに相当するプロジェクト固有のルール集が存在するか確認する

結晶化プロトコル——知見をルールに変える仕組み

Blueprint Firstで仕様を先に書くことで、開発の品質は安定するようになりました。

しかし、もう一つ解決したい問題がありました。
AIエージェントを使い続けると、ある問題が繰り返し発生する。
「一度発見したことが、次のセッションでは引き継がれない」という問題です。

セッションが終わると、AIのコンテキストはリセットされる。
それまでに積み上げた教訓・発見・判断——これらがすべて消えてしまう。
これを「コンテキストの忘却」と呼ぶようです。

結晶化プロトコルの仕組み

Axiarchはこの問題を「結晶化プロトコル」で解決する。
セッション終了前に、発見した教訓・判断・注意点をBlueprintのルールとして書き下ろすことを推奨する仕組みです。

フェーズ	内容	効果
発見	セッション中に教訓・問題・判断基準を特定	暗黙知の可視化
結晶化	セッション終了前にルールとして言語化	知見の形式知化
蓄積	BlueprintのLessons Logに追記	次セッションへの継承
適用	次セッションでAIが自動的に読み込む	同じ失敗の防止

後から調べる中で、この仕組みに近い研究が2025年以降の学術論文に登場し始めていることを知りました。
「タスク間自己進化（Inter-task self-evolution）」と呼ばれる概念で、AIエージェントが複数のタスクを通じて得た知見を蓄積し、次のタスクでより効率的に動けるようになる仕組みの研究だそうです。（参照：A Survey of Self-Evolving Agents – arXiv:2507.21046）。

研究者の言葉と自分の実装は異なるが、「セッションをまたいで知見を継承し、エージェントが学習し続ける」という方向性は重なっているところがあると思います。
同じ問題に着目している研究者がいることを知り、この方向性への確信が深まりました。

この仕組みにより、開発が進むにつれてBlueprintが成長していく。
一度発見した教訓が永続的にルールとなり、同じ失敗を繰り返しにくい構造が生まれる。

これは個人開発だけでなく、チーム開発でも有効だと思っています。

チームメンバーが発見した教訓を共有のBlueprintに蓄積することで、組織の知見が体系化されていく。
ナレッジ継承の観点については、ディレクション進行管理の知見も参考になかと思います。

実務チェックリスト

• セッション終了前に「今回の発見と教訓」を記録する習慣があるか確認する
• 記録した教訓が次のセッションで自動的に参照される仕組みになっているか問い直す
• ドキュメント化されていない暗黙知が組織内に溜まっていないか確認する

OSSとして公開した理由と今後の可能性

Axiarchは最初、完全に自分用として作り始めました。
他の人に使ってもらうことは想定していなかったですが、他の事にも応用できるように汎用的に使えるようには意識して作っていました。

「Google Antigravity」での実際のプロダクション開発（個人開発）に持ち込んで、数百セッションを経てブラッシュアップしていきました。
そのうち「せっかくなら公開してみようか」という気持ちになってきました。
役に立てる人がいればそれに越したことはないし、使えなくても自分は使い続けると思うのでまあいいかなと。

「憲法の概念」はコーディング系のAIエージェントに限らない

Axiarchを公開する中で、もう一つ思っていることがあります。
この「憲法的な考え方」は、コーディング系のエージェントに限らないということです。

活用領域	具体的な適用イメージ
コーディング系AIエージェント	コード品質・セキュリティ・アーキテクチャの基準を憲法として定義
文章生成AI	トーン・スタイル・禁止表現・引用ルールを憲法として定義
業務自動化エージェント	実行してよい操作・禁止操作・エスカレーション条件を憲法として定義
意思決定支援AI	判断基準・倫理原則・優先順位を憲法として定義

AIに何かをさせるあらゆる場面で、「AIが守るべきことを先に定義する」という発想は応用できると思っています。

事業戦略の観点からも、AI活用の品質管理は今後の競争力に直結すると思います。
事業戦略カテゴリでも継続的にAI活用の戦略的視点を発信していく予定です。

私はフロントエンドエンジニアとしての経験はありましたが、バックエンドもインフラも最初は未経験でした。
だからこそ、エンジニア経験の深さに関わらず誰でも使えるものを目指していました。

Axiarch（アクシアーク）は2026年4月10日に「Apache 2.0ライセンス」で「v1.0.0」を公開いたしました。
現在も継続的にブラッシュアップを進めています。

もしご興味もっていただけたら使ってみて頂いて、少しでも役に立てたなら嬉しいです。
GitHubの「Star」や「フィードバック」をもらえると励みになります。

テクノロジー領域に関連する知見はテクノロジーカテゴリでも発信していく予定です。

実務チェックリスト

• 自社・自チームのAI活用で「守るべき基準」が明文化されているか確認する
• コーディング以外のAI活用にも「憲法的な設計」を適用できないか検討する
• OSSの活用・コントリビューションを組織のAI戦略に組み込めないか考える

ミニ用語集

用語	意味	補足
AIガバナンスフレームワーク	AIエージェントの行動を統制するためのルール体系・設計思想	Axiarchはこれの実装形
Universal Rules	Axiarchの第1層。 変更不可の普遍的な憲法	38ファイル・2,500以上の基準を含む
Blueprint	Axiarchの第2層。 プロジェクト固有の可変仕様	開発とともに成長する
結晶化プロトコル	セッション終了前に教訓をルールとして書き下ろす手順	コンテキスト忘却への構造的対策
Quality Floor	操縦者のスキルに依存しない最低品質の保証ライン	Axiarchの設計思想の核心
Blueprint First	コードより先に仕様・ルールを定義するという設計原則	バイブコーディングでは特に重要
バイブコーディング	AIエージェントに自然言語で指示してコードを生成させる開発スタイル	2025年以降急速に普及
コンテキスト忘却	セッション終了とともにAIの記憶がリセットされる現象	Axiarchが構造的に対策する問題のひとつ
AGENTS.md	Axiarchの最高法規。 AIエージェントが最初に読み込む行動プロトコル	主要なコーディングエージェントが対応する標準フォーマット

よくあるご質問

Q. Axiarchはプロンプト集とどう違うのですか？

Axiarchはプロンプト集ではありません。
プロンプト（第3層）はAxiarchの任意要素に過ぎず、なくても機能します。
Axiarchの本体はUniversal（第1層）とBlueprint（第2層）の2層のガバナンス構造です。
「よいプロンプトを書く」のではなく「AIが無視できない憲法を先に定義する」という考え方が根本的に異なります。

Q. エンジニアでないと使えませんか？

使えます。
Axiarchを作ったのは、私はフロントエンドエンジニアとしての経験はあったが、バックエンドもインフラも最初は未経験だった人間です。
エンジニア経験の深さに関わらず誰でも使えるものを目指して設計されています。
ルールはすべて純粋なMarkdownで書かれており、特別な技術知識は不要です。

Q. Google Antigravity以外のエージェントでも動きますか？

動くと見込んでいますが、現時点では未検証です。
Axiarchのルール本体は純粋なMarkdownであり、AGENTS.mdは主要なコーディングエージェント（Cursor・Claude Code・GitHub Copilot等）が参照する標準フォーマットのため、互換性があると考えています。
ただし、Google Antigravity以外での検証は行っていないため、公式リポジトリにその旨を明記しています。

Q. ライセンスはどうなっていますか？商用利用できますか？

Apache 2.0ライセンスで公開されています。
商用利用・改変・再配布いずれも可能です。
完全にオープンソースであり、無料で利用できます。

まとめ

AIエージェントを使い始めて気づいたのは、「どう指示するか」より「どう統治するか」が本質的な問いだということです。

どれだけ優れたプロンプトを書いても、セッションが終われば記憶はリセットされる。
どれだけ熟練した操縦者でも、その人が去れば品質は担保できなくなる。
これはプロンプトの問題ではなく、ガバナンス構造の不在という問題です。

Axiarchの設計思想を一言で表すなら、「統治を先に、開発はその後」です。
Quality Floor・Blueprint First・結晶化プロトコル——これらは独立した機能ではなく、ひとつのガバナンス思想から生まれた考え方です。

提供する価値	内容
Quality Floor	誰が操縦しても品質の床がずれない最低基準の保証
Blueprint First	コードより先に仕様を定義するという開発順序の設計原則
結晶化プロトコル	教訓をルールに変換し、知見の消失を防ぐ継承の仕組み

私はフロントエンドエンジニアとしての経験はあったが、バックエンドもインフラも最初は未経験でした。
だからこそ、エンジニア経験の深さに関わらず誰でも使えるものを目指しました。

もし少しでも試してみたいと感じた方は、「Axiarch公式リポジトリ」から試してみていただけると嬉しいです。
ライセンスは「Apache 2.0」の完全無料のOSSです。

もし使ってみていただいて、少しでも役に立てたなら嬉しいです。
使ってみた感想があれば、「GitHub Discussions」で共有してほしいです。
GitHubの「Star」や「フィードバック」をもらえると励みになります。

最後に、この「憲法的な考え方」はコーディング以外の領域——文章生成・業務自動化・意思決定支援——にも応用できると考えています。
AI活用が広がる中で、ガバナンスの設計という視点は今後さらに重要性を増していくはずだと思っています。
引き続き、テクノロジーカテゴリでこの視点から発信を続けていく予定です。