🎯

Phase 1完成！6つのAIが初めて議論するまでの技術的挑戦

2025/11/17に公開

 はじめにSixMindeの開発で、ついにPhase 1（基本的な議論システム）が完成しました！🎉
6つのAI Agentが異なる視点から議論を重ね、司会AIが全体を統括するシステムが、初めて実際に動作した瞬間です。
この記事では、Phase 1完成までに遭遇した3つの技術的課題と、その解決プロセス、そして実際に動作した議論の様子を共有します。

 Phase 1で実現したこと
 システム構成
6つのAI Agent: Creator, Analyzer, Facilitator, Implementer, Devil's Advocate, Wild Card

司会AI (Facilitator): 議論全体を統括し、結論を生成

立場表明機能: 各AIがOption A/Option B/中立のいずれかの立場を取る

影響関係分析: どのAIがどのAIの発言に影響を受けたかを可視化

 技術スタック
n8n: ワークフローエンジン & Agent オーケストレーション

PostgreSQL (Neon): 議論データの永続化

OpenRouter: 6社のAIモデルへの統合アクセス

TypeScript: フロントエンドの型安全性

 開発で遭遇した3つの技術的課題Phase 1完成までの道のりは決して平坦ではありませんでした。特に以下の3つの問題に苦戦しました。

 1. n8nのCode Nodeキャッシング問題 🔥何が起きたか:
コードを修正してワークフローを保存しても、古いコードが実行され続ける
ワークフロー定義は更新されているのに、実行ログには古い出力が残る
Dockerコンテナを再起動しても解決しない
デバッグプロセス:
// Code Nodeに追加したログ
console.log('🔍 DEBUG: Current code version:', 'v3.2');
console.log('🔍 DEBUG: Input data:', JSON.stringify(items[0].json));
しかし、実行ログを見ると：
🔍 DEBUG: Current code version: v2.1  // ← 古いバージョン！
解決策:

n8nがCode NodeのJavaScriptをキャッシュしている可能性があると判断。
データソースを変更することでキャッシュを回避：
変更前: Build Facilitator Prompt node
変更後: Extract Request Data node
これにより、n8nが「新しいノード」として認識し、キャッシュが無効化されました。
学び:
n8nはCode nodeのJavaScriptをキャッシュする可能性がある
デバッグには console.log() が必須（実行ログで確認）
解決できない場合、データソースや接続を変更してキャッシュを回避

n8n MCP (Model Context Protocol) が非常に便利：

n8n_get_execution でノード出力を直接確認

n8n_update_partial_workflow でコード修正が簡単


 2. camelCase vs snake_case の混在問題 🐍🐪何が起きたか:

フロントエンド（TypeScript）の型定義が混在スタイルを期待していました：
voteBreakdown: {      // camelCase (トップレベル)
  option_a: number,   // snake_case (ネスト内)
  option_b: number,
  neutral: number
}
PostgreSQLのJSONカラムから取得したデータをどこまで変換すべきか判断が難しい状況でした。
問題の本質:
データベースは snake_case で統一
フロントエンドは camelCase が基本
しかし、JSONカラムの内容は snake_case のまま保持すべき
解決策:

n8nワークフローで、特定のJSONカラムをホワイトリスト化：
// PostgreSQL結果の変換ロジック
const jsonColumns = ['vote_breakdown', 'stance_analysis', 'influence_analysis'];

function convertKeys(obj) {
  const result = {};
  for (const [key, value] of Object.entries(obj)) {
    const camelKey = snakeToCamel(key);

    // JSONカラムはパース後の内容をそのまま保持
    if (jsonColumns.includes(key) && typeof value === 'string') {
      result[camelKey] = JSON.parse(value);  // snake_caseのまま
    } else {
      result[camelKey] = value;
    }
  }
  return result;
}
学び:
データベース設計とフロントエンドの型設計の一貫性が重要
JSON列の変換ロジックは明示的にコントロールする必要がある
TypeScript + PostgreSQL + n8nの組み合わせでよくある問題

 3. 3層アーキテクチャでのデバッグの難しさ 🕵️システム構成:
Database (PostgreSQL)
    ↓
n8n (Workflow Orchestration)
    ↓
Frontend (React/TypeScript)
何が起きたか:

フロントエンドの表示がおかしい：
投票結果が 0-0-2 と表示される
AIの名前が「🤖 AI」と表示される
デバッグプロセス:
Step 1: フロントエンドの確認
console.log('voteBreakdown:', debateData.voteBreakdown);
// 出力: { option_a: 0, option_b: 0, neutral: 2 } ← データは正しい
Step 2: データベースの直接確認
SELECT
  vote_breakdown,
  facilitator_summary
FROM debates
WHERE debate_id = 'd7f5770d-605a-438f-8da2-3facbdd07ef7';
結果: データベースには正しいデータが保存されている ✅
Step 3: n8n実行履歴の確認

n8n MCPを使用：
// n8n_get_execution で特定の実行結果を確認
{
  "id": "execution_12345",
  "mode": "summary"
}
発見: n8nの変換ロジックにバグがあった！
// 問題のコード (BEFORE)
const aiParticipants = items[0].json.ai_participants.map(ai => ({
  aiId: ai.ai_id,
  aiRole: ai.ai_role,
  // ❌ ai_name が undefined になっていた
}));

// 修正後 (AFTER)
const aiParticipants = items[0].json.ai_participants.map(ai => ({
  aiId: ai.ai_id,
  aiRole: ai.ai_role,
  aiName: ai.ai_name,  // ✅ 追加
  stance: ai.current_stance
}));
Step 4: n8nで修正

n8n_update_partial_workflow を使用して修正：
{
  "id": "workflow_abc123",
  "operations": [{
    "type": "updateNode",
    "nodeId": "Transform_Response",
    "updates": {
      "parameters": {
        "code": "// 修正後のコード"
      }
    }
  }]
}
Step 5: 検証

フロントエンドを再確認 → 正しく表示された！✅
学び:
各層のログを確認する習慣が重要

n8n MCP (Model Context Protocol) が非常に便利：

n8n_get_execution: ノード出力を直接確認

n8n_update_partial_workflow: コード修正が簡単

n8n_list_executions: 過去の実行履歴を検索

問題の切り分けは下層（Database）から上層（Frontend）へ

 完成した議論システムの実際の動作苦労の末、ついにPhase 1が完成しました！実際の議論の様子を見てみましょう。

 司会AIによる議論の統括
【結論】Round 1の結論:
議論のテーマ:
ダイエット手段として「早起き消費(A)」vs「午前ディスクゴルフ(B)」の議論
投票分布:
🟢 Option A: 2票
🟠 Option B: 2票
🔵 Neutral: 2票
立場変更分析:

各AIの初期立場と最終的な立場が記録され、6つの異なる視点が明確に可視化されています。
💡 Creator: Option B支持
🔍 Analyzer: Option A支持
🎯 Facilitator: Option B支持
🔧 Implementer: 中立
😈 Devil's Advocate: Option A支持
🎲 Wild Card: 中立

 影響関係の可視化
影響関係分析セクションでは、各AIが他のどのAIの発言に影響を受けたかが明確に表示されています。
例えば：
🔍 Analyzer が 💡 Creator に影響
🔧 Implementer が 💡 Creator に影響
😈 Devil's Advocate が 💡 Creator に影響
このように、議論の中でAI同士がどのように相互作用しているかがビジュアルで追跡可能になりました。

 実際の議論内容
Facilitator (推進AI) の発言:
Analyzerの「PDCAサイクルを回しやすく」「Option Bは『運動効果が極めて測定しにくい』」との指摘に対し、Facilitatorの観点では“継続率×実行可能性”を最大化する設計が肝です。Bでも計測は可能で、心拍計でゾーン2–3、歩数、RPE、週ラウンド数を指標化すればPDCAは回せます。Wild Cardの「厳格な計画性が逆効果になるケースも考えられます」に同意し、楽しさと屋外要素が食欲・睡眠・ストレスを整えNEATを底上げする点で、Bは遵守率に優れます...
Devil's Advocate (悪魔の代弁者) の反論:
先の発言者たちの分析は確かに示唆的ではありますが、Option A支持の立場から重要な反証と懸念を述べさせていただきます。
Analyzerが指摘した「計測可能性」と「計画性」はOption Aの決定的優位性であり、Wild Cardが述べる「継続性の計画性がストレスになる」のは、むしろ習慣化後の安定したルーティンとして捉えるべきです...
このように、各AIが自分の役割に忠実に、かつ他のAIの発言を引用しながら議論を展開しています。

 Phase 1完成で見えてきたこと
 成功したポイント ✅6つのAIペルソナが機能している
Creator（創造者）、Analyzer（分析者）、Facilitator（促進者）、Implementer（実装者）、Devil's Advocate（悪魔の代弁者）、Wild Card（ワイルドカード）がそれぞれの役割を果たしている
議論の流れが自然
AIが他のAIの発言を引用し、建設的な議論が成立している
単なる順番に発言するだけでなく、相互作用が生まれている
データの可視化が成功
投票分布、立場変更、影響関係が一目で理解できる
デバッグも容易になった

 今後の課題と展望 🚀Phase 2に向けて:
より複雑な議論テーマでのテスト
議論の質の向上（より深い洞察を引き出す）
パフォーマンスの最適化（応答時間の短縮）
結論生成アルゴリズムの改善
Phase 3以降:
Webフロントエンドの本格開発
ユーザーが自由に議論テーマを設定できる機能
議論履歴の分析機能
実際の意思決定への応用実験

 まとめPhase 1の完成は、SixMinde開発における大きなマイルストーンでした。
技術的な学び:
🔥 n8nのCode Nodeキャッシング問題への対処法
🐍🐪 TypeScript + PostgreSQL + n8nでのcamelCase/snake_case管理
🕵️ 3層アーキテクチャでの効果的なデバッグ手法
n8n MCPの有用性:

n8n_get_execution: 実行結果の詳細確認

n8n_update_partial_workflow: 効率的なコード修正

n8n_list_executions: 過去の実行履歴の検索
これらの経験は、今後のPhase 2以降の開発にも活きてくるはずです。
次回は「Phase 2 - 議論の深化」について、より詳しい技術的な挑戦を共有します。
SixMindeの開発は継続中です。今後も技術的な学びや面白い発見を共有していきます！
GitHub: https://github.com/edhiblemeer/six-minds-debate

はじめに

Phase 1で実現したこと

システム構成

技術スタック

開発で遭遇した3つの技術的課題

1. n8nのCode Nodeキャッシング問題 🔥

2. camelCase vs snake_case の混在問題 🐍🐪

3. 3層アーキテクチャでのデバッグの難しさ 🕵️

完成した議論システムの実際の動作

司会AIによる議論の統括

影響関係の可視化

実際の議論内容

Phase 1完成で見えてきたこと

成功したポイント ✅

今後の課題と展望 🚀

まとめ

Discussion