TL;DR
- タスクの難易度に応じてモデルを使い分ける「AIルーター」で、APIコストを抑える
- 改善案の反映前には、複数のAIエージェントによる合議制レビューを挟む
- 戦略ごとの成功率はベイズ推定で追い、調子が落ちたら自動で戦略を切り替える
大創社でAI共創の仕組みを運用する中で形になってきた設計を、考え方中心に紹介します。
設計の全体像
オーケストレーターは、単なるタスクランナーではありません。「今、何をすべきか」を現状の指標から判断し、改善案の生成、審査、検証、適用までを1サイクルとして回します。
class Orchestrator:
"""自律改善パイプラインを管理するオーケストレーター"""
def __init__(self, config):
self.council = Council(config.principle_db_path)
self.tracker = SuccessRateTracker()
self.sandbox = SandboxEnvironment()
async def run_cycle(self):
# 1. 現状把握と課題検出
metrics = await self._collect_metrics()
issues = self._detect_issues(metrics)
if not issues:
return CycleResult(action="no_action")
# 2. 改善案の生成（軽量モデルで複数案）
proposals = await self._generate_proposals(issues)
# 3. 合議制レビュー
approved = []
for proposal in proposals:
ok, reasons = self.council.vote(proposal)
if ok:
approved.append(proposal)
# 4. 検証環境でテストし、通ったものだけ適用
for proposal in approved:
if await self.sandbox.test(proposal):
await self._promote_to_production(proposal)
self.tracker.record_success(proposal.strategy)
else:
self.tracker.record_failure(proposal.strategy)
return CycleResult(action="evolved", count=len(approved))
コストを抑える考え方
APIコストの多くは、「軽い作業に重いモデルを使う」ことで生まれます。私たちは作業を3段階に分けています。
- 量産の段階（下書き、候補の生成）：軽量で速いモデル
- 審査の段階（文脈を読んで判断する）：じっくり読めるモデル
- 最終確認：人、または最も信頼できるモデル
全工程を最も高性能なモデルで回すのではなく、工程ごとに適切なモデルを置く。これだけで、品質を落とさずにコストは大きく下がります。
成功率をベイズ推定で追う
戦略（どのモデルに、どう頼むか）ごとの成功と失敗を数え、Beta分布で成功率を推定します。調子が落ちた戦略は、閾値を下回った時点で切り替えの候補になります。
class SuccessRateTracker:
"""ベイズ推定でタスク成功率を動的予測
Beta分布 Beta(alpha, beta) を事前分布とする
"""
def __init__(self):
self.alpha = defaultdict(lambda: 1.0) # 事前: 成功1
self.beta = defaultdict(lambda: 1.0) # 事前: 失敗1
def record_success(self, strategy):
self.alpha[strategy] += 1
def record_failure(self, strategy):
self.beta[strategy] += 1
def expected_success_rate(self, strategy):
"""事後分布の期待値 E[p] = alpha / (alpha + beta)"""
a = self.alpha[strategy]
b = self.beta[strategy]
return a / (a + b)
def should_switch_strategy(self, strategy, threshold=0.4):
"""成功率が閾値を下回ったら戦略変更を推奨"""
return self.expected_success_rate(strategy) < threshold
試行回数が少ないうちは乱高下せず、記録が積み上がるほど実態に近づく。運用の勘どころに合った性質です。
合議制レビューを挟む理由
コスト最適化だけなら、ルーターと成功率の追跡で足ります。そこに合議制レビューを足したのは、自動で回す仕組みほど「止める仕組み」が要るからです。
複数のエージェントが、整合性、安全性、技術、表現、倫理の視点から変更案を読み合い、原則に反する変更には拒否権で止めます。スコアで一律に判定するのではなく、意図と文脈を読む。これは、大創社が教育の現場で続けてきた「評価から鑑賞へ」という考え方を、そのままシステムの設計に持ち込んだものです。
まとめ
- モデルは工程ごとに使い分ける（コスト）
- 戦略の調子は数字で追う（安定性）
- 反映の前には、複数の視点で読み合う（品質と安全）
ベイズ推定が数字の裏側にある「傾向」を読むように、合議が変更案の裏側にある「意図」を読む。その組み合わせが、長く回し続けるための設計だと考えています。
著者：灯台守 MASATAKA｜大創社
大創社公式：https://daisosha.com/
学習鑑賞ポートフォリオ：https://learning-appreciation.daisosha.com/