「ビルド用のコード作成は、戦いの半分にすぎません。維持することがもう半分です。」
2026年にAIエージェントと連携して仕事をするということは、人間の「アーキテクチャの地図」が追いつけないことがあるほど速くコードが生成される、ということを意味します。先月、私のプロジェクトであるShortshubが「アーキテクチャのドリフト」に悩まされていることに気づきました。これは、エージェントが、ある機能がどこで終わり別の機能がどこで始まるのかという境界を明確に持っていなかったためです。
それを解決するために、私は標準的なモノリシック構造から離れ、完全に疎結合されたControl Plane（ポート5004で稼働）を構築しました。ここから、私の実験的な「Fractal Kernel」アプローチの内訳です。下の動画をご覧ください。
問題：『ハルシネーション・スプレッド（幻覚の拡散）』
AIエージェントが持つコンテキストが多すぎると、グローバル状態について「創造的」（誤った）な前提を作り始めます。逆に少なすぎると、依存関係が壊れます。そこで私は、エージェントに必要な分だけのコンテキストを、そしてそれ以上は与えない方法が欲しいと考えました。
コアとなるアーキテクチャの柱
1. Fractal Kernel Manifest（実験）
このリポジトリの土台です。すべての機能は、厳密な.manifestファイルを伴う、それぞれの「セル」の中に存在します。
仕組み：カーネルは起動時にこれらを自動で検出します。
目標： コードベースを「エージェントネイティブ」にします。100個のファイルをスキャンする代わりに、エージェントは1つのマニフェストを読み、どこまでが「セル」の境界かを理解します。（稼働80%）。
2. 実行時キルスイッチ（モジュール分離）
これは私のお気に入りの「安全機能」です。機能は切り替え可能なFeature Card（機能カード）として整理されています。
価値： AIが生成した機能が本番環境で幻覚によるエラーを投げたとしても、ビルド全体をロールバックする必要がありません。その特定の機能をControl Planeから即座に「OFF」に切り替えます。（稼働70%）。
3. デバッグ用メモリ＆依存関係グラフ
共通のエージェントエラーを、専用パネルにログとして記録し、その「デバッグ経路」を次のプロンプトにフィードバックすることを試みています。
アーキテクチャ・ログ：Fractalのセル同士がどうつながるかを示す可視グラフを作成中です（現在は未稼働）。
デバッグメモリ：反復するロジックエラーを防ぐのに役立つのは約50%です。（稼働50%）
私は主にFree-TierのLLMモデルを使ってこれを構築しています。目的は、Context Engineering（AIのためにリポジトリを構造化すること）が、Model Raw Power（モデルの生のパワー）に勝てるのかを確かめることです。
トークン最適化： 高。エージェントは関連する機能フォルダだけを「見る」ようにします。
スピード： 高。機能は分離された状態で作られ、その後カーネルに「接続」されますが、制約があります。
免責事項＆オープンソース
これは、構造的なガードレールによって温度調整された、非常に実験的な「Vibe Coding（ノリベース・コーディング）」です。Multi-Agent Orchestration（複数エージェントのオーケストレーション）やMicro-frontendのパターンで取り組んでいる方からのフィードバックを探しています。
デモサイトを確認してください：www.shortshub.app
GitHubでコードをのぞいてください：Maqsood32595/fractal-kernel
あらゆるフィードバック、交流、提案を歓迎します。
