NexusCore

なぜ作ったか

ソフトウェア開発の各フェーズ（要件定義・設計・実装・テスト・レビュー）は、本来それぞれ異なる視点と専門性が必要です。一人のエンジニアが全フェーズを兼務すると、どうしても視点が偏ります。そこで各フェーズに専門のAIエージェントを割り当て、協調させることで、一人開発でも多様な視点での品質担保を実現できないか——という構想から生まれました。

アーキテクチャ

14の専門エージェント

エージェントは大きく3つのグループに分かれています：

① 開発パイプライン（上流→下流）

Requirement（要件分析）
    ↓ 要件仕様書
Planner（実装計画）
    ↓ 実装プラン
Architect（アーキテクチャ設計）
    ↓ 設計書
Coder（コード生成）
    ↓ コード
Tester（テスト自動生成）
    ↓ テスト結果
Guardian（品質ゲート判定）
    ↓ 合格/不合格

② 品質保証・分析

③ ガバナンス・管理

設計上の判断と理由

Q: なぜ14エージェントに分割したのか？

1つの巨大エージェントに全役割を担わせることも可能ですが、あえて分割した理由は：

• 責任の分離: 各エージェントが単一責任を持つことで、出力の品質が安定する
• 品質ゲートの客観性: Coderが書いたコードをReviewerが批判的に検証できる（自分の書いたコードを自分でレビューする問題を回避）
• 差し替え可能性: 各エージェントの背後にあるLLMを独立に変更できる（コスト最適化）

Q: なぜ2層の品質ゲートにしたのか？

• Tier 1（静的解析）: カバレッジ80%+ / Pylint 8.0+ / Mypy / Bandit → 機械的に検出できる問題は即座に弾く
• Tier 2（動的テスト）: ミューテーションテスト → テストコードが「本当にバグを検出できるか」を検証する
• 理由: 静的解析だけでは「テストが形式的で実質的にバグを検出できない」問題を発見できないため

LLMルーティング（8プロバイダー）

Task → LLM Router → [品質ティア: GPT-5.5 / Sonnet 4.6 / Gemini 3.1 Pro]
                     [軽量ティア: Claude / 代替プロバイダー / DeepSeek / Moonshot]
                      ↕
                 Budget Manager（日次上限・フォールバック制御）

33種のタスクを自動分類し、最適なLLMにルーティングします。コード生成などの重要タスクは品質ティア、チャットや分類は軽量ティアに振り分け、月額コストを最適化しています。

面接で聞かれそうなポイント

「ミューテーションテストとは？」

通常のテストは「コードが正しく動くか」を検証します。ミューテーションテストは逆に「テストが本当にバグを見つけられるか」を検証します。

具体的には：

1. 本体コードに意図的に小さなバグ（ミュータント）を注入する
2. テストを実行する
3. テストがバグを検出（kill）できればOK、見逃せばテストが不十分

例：if a > 0 を if a >= 0 に変えて、テストが失敗するか確認する。失敗しなければ a == 0 の境界値テストが漏れていることになります。

「Authority Runnerとは？」

変更の重要度に応じて、実行の自動化レベルを3段階に切り替える仕組みです：

技術スタック

• Python 3.12 / FastAPI / Gradio
• pytest（4,895テストケース）
• GitHub Actions CI/CD
• Apache 2.0 ライセンス