初期課題の提起とDSPyの提案

日付: 2026-06-13 作成者: プロジェクトチーム
課題提起 アイデア提案

1. プロジェクトの背景と現状課題

Claude Codeを利用したクラウド関連案件のプロジェクト立ち上げ前フェーズ。AIエージェントを利用したクラウドインフラ構築は可能になりつつあるが、現状の精度は約50%に留まっている。

コア課題（スタート課題）

  • 精度の担保が困難: 自動生成された構築内容の確認には高度なスキルを持つ人材が不可欠。
  • 上流工程（要件定義等）の評価難易度: 正解が固定的でなく、非決定的な出力であるため、人間による評価も難しい。
  • プロジェクト管理上の要請: 精度の経過を監視し、KPI等への寄与過程を示す必要があるが、現状は「精度を測るすべがない」。

2. 対応方針の仮説

課題解決に向けたアプローチとして、以下が挙げられた。

  • 「確認のための時間をとる」＝ 作成に時間がかかる作業を代替する（カバーできるskillsが多い）
  • 「確認項目数が少ない」＝ 生成物の精度が高い
  • 「確認できる人を増やす」＝ サポート的なAIに必要なナレッジが接続されている

3. 提起されたアイデア：DSPyの活用

この「精度を測る・向上させる」課題に対し、プロンプトをプログラムとして最適化するフレームワークであるDSPyが使えないかというアイデアが提示された。

保留・次ステップ

DSPyがこの特定の課題（クラウドインフラの要件定義という非決定的なタスクの評価とKPI化）に対して技術的に適合するか、調査・検討を行う。

DSPy調査結果の報告

日付: 2026-06-13 作成者: Manus AI
調査・分析 方向性決定

1. 調査の結論

DSPyの導入は、本プロジェクトの課題に対して非常に有効かつ的を射たアプローチであると結論付けた。

2. 課題とDSPyの機能マッピング

graph TD A[プロジェクトの課題] --> B(要件定義の正解が固定的でない) A --> C(精度の経過をKPI化したい) A --> D(現状の精度50%を向上させたい) B -.->|解決策| E[DSPy: LLM-as-a-Judge] C -.->|解決策| F[DSPy: Evaluate & Metrics] D -.->|解決策| G[DSPy: MIPRO / COPRO Optimizer] E --> H(カスタムルーブリックによる定量的評価) F --> I(Devsetに対するスコア算出とトラッキング) G --> J(プロンプト・Few-shotの自動最適化)

3. 適用アーキテクチャ案

調査レポートにて、以下の3フェーズからなるアーキテクチャ案を提示した。

  1. 評価データセット（Devset）の構築: 「入力条件」と「期待される要件（キーワード等）」のペアを作成。
  2. カスタム評価指標（Metric）の定義: 網羅性やセキュリティ要件を評価するLLM JudgeをDSPyプログラムとして実装。
  3. 評価パイプラインの自動化とKPI化: 定期的にEvaluateを実行し、スコアをダッシュボードでトラッキング。

決定事項

DSPyを活用する方向性は有望であると確認。まずはPoC（概念実証）として、特定のシナリオ（例：Web3層アーキテクチャ）に絞った小規模な評価基盤の構築を検討する。

エージェント構成の比較分析（シングル vs マルチ）

日付: 2026-06-13 作成者: Manus AI / ユーザー
調査・分析 方向性決定

1. 検討の背景

ブレインストーミングで出た「ペルソナ別マルチ評価」や「Adversarial Testing（レッドチーム）」といったマルチエージェント構成について、従来のシングルエージェント構成と比較した場合の具体的な違い（精度・コスト・レスポンス速度等）を整理する必要性が生じた。

また、セキュリティに特化したAnthropicの最新モデル「Claude Mythos 5」をレッドチームLLMとして採用するアイデアについても技術的妥当性を検証した。

2. 比較分析結果の要約

最新の研究動向（2025-2026年）を踏まえた比較分析を実施し、詳細な資料を「設計・仕様書」カテゴリに追加した。
→ 資料：AIエージェント構成比較：シングル vs マルチ（ペルソナ・レッドチーム）

判明した課題とトレードオフ

  • 精度の向上： マルチエージェント構成は複雑なタスクにおいてシングル構成より30〜40%高い精度（Success Rate）を達成可能。
  • コストとレイテンシの壁： 特にレッドチーム構成（直列の議論ループ）は、コストが数倍に跳ね上がり、レスポンス速度も著しく低下する。

3. Claude Mythosの評価

調査の結果、Claude Mythos 5はゼロデイ脆弱性の発見やエクスプロイト開発において桁違いの性能を示しており、「レッドチームLLMとしてMythosを採用する」というアプローチは極めて強力かつ理にかなっていることが確認された。

決定事項（次ステップへの方針）

精度向上のためにはアーキテクチャレベルでの転換（マルチエージェント化）が不可欠だが、コストとレイテンシの観点から「段階的な導入とハイブリッドルーティング」を基本方針とする。

  1. まずは「シングルエージェント＋DSPy」でベースライン環境を構築。
  2. 「ペルソナ別マルチ評価」を導入し、安価なモデル（Haiku等）を活用して網羅性を担保。
  3. クリティカルな領域（IAM、ネットワーク境界等）や夜間バッチ評価に限定して、「Claude Mythosによるレッドチーム評価」を組み込む。

評価アプローチのブレインストーミング

日付: 2026-06-13 作成者: Manus AI / ユーザー
ブレスト 多角化

1. ブレストの目的

DSPy以外にも「精度を測る・担保する・上げる」ためのやり方がないか、技術・プロセス・組織・発想の転換など、カテゴリを横断して自由な発想でアイデアを広げる。

2. アイデアの全体像（マインドマップ）

mindmap root((精度向上・評価)) A. 評価の仕組み チェックリスト駆動評価 ペルソナ別マルチ評価 Adversarial Testing 差分テスト Mutation Testing B. 正解データ 専門家アノテーションUI 過去案件のナレッジマイニング 独自ベンチマーク内製化 C. 出力設計 構造化出力の強制 根拠出力の義務化 信頼度スコアの付与 D. プロセス設計 Human-in-the-Loop ステージゲート型レビュー AI-AI Debate E. フィードバック 本番フィードバック収集 A/Bテスト型比較 失敗事例データベース F. 発想の転換 精度ではなくリスクを測る 何が足りないかを測る 評価モデルのファインチューニング

3. アイデア詳細カタログ

A. 評価の仕組み

ペルソナ別マルチ評価

セキュリティ、コスト、運用など異なるペルソナを持つLLM Judgeを並列稼働させ、多角的に抜け漏れを検出する。

A. 評価の仕組み

Adversarial Testing

レッドチームLLMを用意し、生成された設計の「穴」を積極的に探させることで、人間が見落としやすい脆弱性を炙り出す。

B. 正解データ

過去案件のナレッジマイニング

実際に稼働した過去のインフラ設計書を正解データとして構造化し、AIの生成物との類似度や網羅率を比較する。

C. 出力設計

信頼度スコアの付与

AIに各設計要素の自己評価（信頼度）を付与させ、信頼度が低い要素のみを人間がレビューするリスクベースのアプローチ。

D. プロセス設計

AI-AI Debate

2つのAIエージェント（提案者と批評者）に議論させ、反論と修正を繰り返すことで単一AIより高品質な成果物を生成する。

F. 発想の転換

「何が足りないか」を測る

「正しいか」の定義は難しいが「抜け漏れ」は定義しやすい。評価の問いを網羅率の測定に切り替える。

今後の検討事項（保留・課題）

  • これらのアイデアの中で、どれをDSPyの枠組みに組み込むか？（例：ペルソナ別マルチ評価はDSPyの複数Metricとして実装可能）
  • どれをDSPy外のプロセスとして実装するか？（例：構造化出力の強制や、AI-AI Debateはプロンプト設計の範疇）
  • PoCにおいて、どこまでスコープを広げるか（最初はシンプルに単一のJudgeから始めるか）を決定する必要がある。