“品質の床”を実装する——個人開発のAIガバナンスOSSと、私の設計判断

私は個人で、Axiarch（アクシアーク）というオープンソースのフレームワークを作って公開しています。
ひとことで言うと、AIにコードを書かせるときの「品質の床（最低ライン）」を、操縦者のスキルやツールに依存せず引き上げ・維持するための仕組みです。

この記事は機能紹介ではなく、私がどんな判断軸でものを作る人間なのかの記録です。
一緒に働くかもしれない方や、同じく個人開発をしている方に、判断のクセが伝わればと思っています。

なぜ「品質の床」を作るのか

AIに実装を任せるほど、怖いのは最高品質を出せないことではなく、気づかないうちに最低ラインを割ることです。

文脈が長くなったり、ツールが変わったり、自分の集中が切れていたりすると、品質は静かに下がる。
だから「誰が・どのエージェントで動かしても、ここから下には行かせない」という床そのものを設計対象にしました。

これが Axiarch の出発点です。
自分の本当のプロジェクトで使いながら、2ヶ月で57回コミット、ルールは38から50ファイルへと育ててきました。

設計判断1：書いただけでは守られない、を前提にする

最初から「ルールは書いただけでは守られない」を前提にしています。
AIは文脈が長くなると、自己判断で再確認を省きます。
だから「守ってくれるはず」という願望に賭けず、「守られない瞬間がある」という観測された事実に設計を合わせました。

お願い（リマインダー）と、どうしても外せない一線を機構で止める物理ブロックの二段で、「善意がなくても床は割れない」状態を作る。
意思決定として振り返ると、ここが一番の分岐でした。

設計判断2：層を増やさず、実行に橋渡しする

床を守らせる手順には、AIエージェント開発の文脈で使われる「ハーネスエンジニアリング」という考え方を取り入れました。

憲法の3層（普遍ルール・プロジェクト固有・プロンプトテンプレート）は変えず、それを実行順序・監査・証跡・人間承認へ橋渡しする運用工学です。

新しい権威を足すのではなく、既存の床を実際に効かせる通り道を作る。
増やすのは判断の数ではなく、判断の通り道だ、という判断です。

設計判断3：床は上げ続けられるようにする

床の上げ方は層で分けました。

普遍ルール（憲法本体）は、どのプロジェクトでも効くと分かった領域を足して引き上げる——38→50はこの普遍層の増分です（直近は認証スタック）。

一方、個々の現場で起きた教訓は、プロジェクト固有の層（Blueprint）で結晶化させて育てる——一か所のログにためておき、同じ領域で3件たまったら正式ルールへ昇華させる（昇華前に普遍ルールとの重複も確認）。

層を混ぜないまま、両方の床を使いながら上げていく。
最初に完璧な体系を組むより、フィードバックが床を一段ずつ押し上げていく流れのほうが、私には合っています。

設計判断4：床の「高さ」を誇張しない

検証できたことだけを言う、と決めています。

主対象の Google Antigravity・Claude Code・Codex は、いずれも実運用（ドッグフーディング）で稼働確認済み——この今回のリポジトリ自体、コミット履歴の大半が Claude Code・Codex 経由です。

ただし全環境での動作保証まではしない、とも明記する。
Codex でスラッシュコマンドを見送ったのも、思想ではなく確実に動く保証がなかったからです。

品質の床を扱う道具が、自分の床の高さを偽ったら本末転倒。
言い切れる範囲を狭く保つほど、その一言の重みが増す——これは仕事の進め方そのものについての信条でもあります。

振り返って

品質の床は、一度引いて終わりの線ではなく、定義し・守らせ・上げ続けるものだと、この2ヶ月であらためて自覚しました。

仮説を立てて出してみて、実プロジェクトで検証して、観測された事実に素早く設計を合わせ直す。
そのループを、正直さを保ったまま速く回す。
それが私の進め方です。

もし、そういう向き合い方に共感してもらえる方がいたら、とても嬉しいです。

Axiarch はオープンソースで公開しています。
興味があれば、覗いてみてください。
→ https://github.com/hiroyuki-miyauchi/axiarch