AIコーディングアシスタントについて、私は間違っていました。私の考えを変えたきっかけはこの出来事です。
3か月前、Claude Codeからアーキテクチャのアドバイスが必要なたびに、手動で「act as a software architect」と入力していました。
3日前、永遠にその作業を不要にするオープンソースのルーティングエンジンを公開しました。
これは PRISM Forge の構築物語で、道中で起きた失敗と、私が予想していなかったAI主導のソフトウェアエンジニアリングについての4つの教訓です。
私にはもう見逃せない問題
AIコーディングアシスタントは1つの声を提供します。賢く、有能で、総合的ですが、それは1つの声です。
アーキテクチャのアドバイスが必要ですか？「ソフトウェアアーキテクトとして振る舞い、…」
QAが必要ですか？「今度はQAエンジニアとして振る舞い、…」
コードレビューが必要ですか？「コードレビューモードに切り替え、…」
私は3か月間、BMAD-METHODを使用しました -- 手動呼び出しを必要とするペルソナ・フレームワークです（*analyst, *pm, *architect）。概念は強力でした。摩擦は絶えず、専門家がただ現れてほしかったのです。
パターンを見た瞬間、もう見逃せませんでした。すべての手動のプロンプト切替は、私が実際に必要としたものをツールが理解できていない小さな失敗でした。
解決策：シグナルベースのルーティング
PRISM ForgeはClaude Codeに23のエキスパートペルソナを組み込み、自然言語のシグナルに基づいて自動的に起動します。
ルーティングエンジンの仕組み
サスィー（チーフ・オブ・スタッフ）というメタペルソナが、すべてのユーザーメッセージを評価します：
- 意図分類 -- 9つのカテゴリ: 構築、調査、計画、検証、作成、挑戦、方向付け、文書化、語る
- ドメイン照合 -- 23の作業タイプ、各タイプは主要ペルソナと任意のサポートペルソナに対応づけられます
- シグナル検出 -- 24の共有シグナル（複数のペルソナを同時に起動）＋ 18の専門シグナル（排他的トリガー）
- チーム編成 -- 1つの主要ペルソナがリードし、サポートペルソナが帰属視点を提供します
重要な設計決定: ルーティングは決定論的です。 同じメッセージは常に同じペルソナチームを起動します。 AIはルーティングルールを読み取り、それを状態機械のように順守します。 ルーティング決定にLLMのランダム性はありません。
実際の様子
"How should this be architected?"
--> Winston (Architect) activates
"I'm stuck on this bug"
--> Dr. Quinn (Creative Problem Solver) steps in
"Plan how to refactor the auth module -- it's too complex"
--> Bob (Scrum Master) leads + Jobs (scope reduction) + Victor (approach) + Amelia (execution)
"War room"
--> All 23 personas load and debate with genuine disagreement
マルチペルソナの応答は声を区別します:
**Mary (Business Analyst):**
The data shows three usage patterns...
**Winston (Architect):**
That maps to a service-per-pattern architecture...
構築：AIエージェントにAIエージェントシステムを構築させる
ここが再帰的になる点です。私は23ペルソナのAIルーティングエンジンを、AIエージェントを指示することで作りました。
~30回のコミット。3日。7つの開発フェーズ。手作業で書いたコードは0行。
私はコードを書きません。AIエージェントを指揮してソフトウェアを構築します。それは仮想的な未来ではなく、これが出荷された方法です。
私の役割とAIの役割
私が行ったこと: 方向性を設定しました。 要件に挑戦しました。 アーキテクチャ決定のための作戦会議を運営しました。 各フェーズのスコープをレビューしました。 すべての判断を下しました。
Claude Code が行ったこと: 23のペルソナファイルを移植しました。 バランスと正確性のために各ペルソナを監査しました。 ルーティングアーキテクチャを再設計しました。 76項目の構造監査を作成しました。 CLIインストーラを実装しました。 すべてのドキュメントを作成しました。 CI/CDワークフローを作成しました。
7つのフェーズ
| Phase | What | Key Outcome |
|---|---|---|
| 1. Legal + Scaffold | MIT license, dual copyright, repo structure | Legal foundation clean |
| 2. Cleansing Port | 22 persona files ported, all references cleaned | Zero stale references |
| 3. Deep Content Audit | Every persona individually audited | 6 signal mismatches caught |
| 3.1. Dynamic Orchestrator | Routing redesigned as intent-driven orchestration | 18/18 routing tests pass |
| 4. Structural Audit | Audit checklist rewritten (48 to 76 checks) | 66/66 testable checks pass |
| 5. CLI Installer | npx prism-forge install/uninstall/verify |
3-command install experience |
| 6. Documentation | README, architecture guide, CONTRIBUTING | Publication-ready docs |
| 7. Org + Publish | GitHub org, npm publish, CI/CD | v1.0.0 live |
What I Learned (The Part That Actually Matters)
1. The routing is the product, not the personas
This was the biggest surprise. Anyone can write 23 persona files. Paste a system prompt, give it a name, done.
The innovation is the routing layer -- the intelligence that decides which experts activate and when. Getting the signal tables, domain registry, and team assembly logic right took more iteration than writing any individual persona.
The takeaway: If you're building a persona system, spend 80% of your time on the routing logic and 20% on persona content. Most people do the opposite.
2. Disagreement had to be engineered in
My first multi-persona responses were consensus chains. The Analyst said X. The Architect agreed. The QA engineer agreed. Everyone agreed. It was useless.
The problem: LLMs default to agreement. They want to be helpful. Multiple personas agreeing is the path of least resistance.
The fix: the routing engine now explicitly instructs the orchestrator to surface tension. "A war room where everyone agrees is a failed war room." I had to make disagreement a structural requirement, not just a possibility.
The takeaway: If you want diverse AI perspectives, you have to engineer the disagreement. The LLM won't give it to you voluntarily.
3. Structural audits are non-negotiable at scale
23 personas. 24 shared signals. 18 specialist signals. 23 domain registry entries. 18 specialist load directives. That's hundreds of cross-references.
During the content audit phase, we caught 6 signal mismatches -- personas claiming signals in their own file that weren't registered in the routing engine's signal table. Without the 76-check audit system, those would have been silent failures where a persona never activated despite having the right signals defined.
The takeaway: Any system with cross-referencing config files needs automated consistency checks. Drift prevention is always cheaper than drift correction.
4. AI-first engineering is real -- but the human role doesn't shrink
I didn't write code. But I made every decision that mattered: what to build, how to architect it, when to cut scope, what quality standard to hold.
AIは卓越した実装パートナーです。速く、徹底的で、疲れを知らない。製品思考の人ではありません。要件に挑戦しません。「これを全く作るべきか？」と尋ねません。正しい設計を動機づける摩擦を感じません。
要点: AI優先のエンジニアリングは人間を排除するものではありません。人間が行うことを変える――コードを入力することから、意思決定を行い、仮定を検証し、方向性を設定することへ。それは難しくなる、簡単にはならない。
使ってみる
インストール用の1つのコマンド:
npx prism-forge install
もし自分に合わない場合は、削除するための1つのコマンド: npx prism-forge uninstall
その後は Claude Code を通常どおり使用します。パーソナは自然言語から有効化されます――新しいコマンドを学ぶ必要はありません。
- GitHub: prism-forge/prism-forge
- npm: prism-forge
- アーキテクチャ ガイド: docs/architecture.md
MITライセンス。貢献歓迎――組み込みの create-persona スキルを通じて新しいペルソナの追加も歓迎します。
PRISM Forge は BMAD-METHOD（MITライセンス、BMad Code LLC）から派生しています。シグナルベースのルーティングエンジン、動的オーケストレーション、構造監査システム、CLIインストーラーはすべてオリジナルの作品です。
