MAGI風・合議制AIをローカルLLMで作ってみた記録― Ollamaで3人格AIの意思決定プロセスを実装する
こんにちは、yukiです。
今回は、MAGI風AI（3人格合議制AI）をローカルLLMで試作した記録を、あとから振り返れる形でまとめます。
テーマは、
**「新世紀エヴァンゲリオンのMAGIシステムを、AIに作らせたらどうなるか」**です。
単なるLLM呼び出しではなく、
-
人格の違い
-
合議による意思決定
-
判断不能時に“追加で何を聞くか”を生成する
この意思決定プロセスそのものを作ることを目的にしました。
最終的にはUI付き公開も視野に入れていますが、まずは完全ローカルで動くプロトタイプを作っています。
結論（先に要点）
先におすすめだけまとめます。
-
ローカルLLM開発はモデル選定が8割
-
最初は gemma3:4b でフロー検証
-
仕上げるなら llama3.1:8b-instruct-q4
-
人格設計と合議ルールは、モデルサイズ以上に効く
-
「制約込み」で設計すると、ローカルLLMはかなり楽しい
以下は、その判断に至るまでの記録です。
背景と目的
原作のMAGIシステムは、
-
3つの人格が独立に判断し
-
多数決で意思決定する
という構造を持っています。
これをそのままAIに落とすのではなく、
-
人格差をどう作るか
-
意見が割れたとき、どう扱うか
-
何が足りないかをAI自身に言わせるか
このあたりを実装上のテーマにしました。
採用した基本方針
今回の前提はかなり割り切っています。
-
完全ローカル実行
-
API課金・トークン管理を避ける
-
-
Ollama + ローカルLLM
-
Pythonベース
-
実装補助に GitHub Copilot
-
UIは後回し（最終的に Streamlit）
まずは「動く意思決定フロー」を作るのを最優先にしました。
MAGIシステムの設計
人格構成（原作準拠）
人格は原作にならって3つ。
-
MELCHIOR（科学者人格）
-
合理性、再現性、成功条件の明確さ
-
-
BALTHASAR（母人格）
-
安全性、人間への影響、不可逆リスク
-
-
CASPER（女人格）
-
政治性、対外評価、責任構造、見え方
-
人格プロンプトは「性格」よりも、判断軸がズレるように設計しています。
合議ルール
各人格は必ず以下を出力します。
-
vote-
APPROVE / REJECT / ABSTAIN
-
-
rationale-
短い理由
-
-
blocking_info-
判断に不足している情報
-
ルールはシンプルです。
-
2/3で決定
-
割れたら DEADLOCK
-
DEADLOCK時は「追加質問」を生成
ABSTAINを許容したのが、あとから効いてきました。
実装で詰まったところ
Ollama（Windows）の初期トラブル
インストール後に ollama コマンドが認識されない問題に遭遇。
原因は単純で、
-
PATHが PowerShell / VSCode に反映されていなかった
対処としては、
-
ollama.exeの実体を確認 -
一時的にPATH追加
-
ターミナルとVSCode再起動
Windowsは、こういうところで時間を吸われがちです。
モデル選定の罠
ここが一番の学びでした。
試したモデルと結果：
-
llama4 / llama3.3
→ 500 Internal Server Error -
原因
→ 要求RAM（50GB超） > 実メモリ（約36GB）
学びとしては、
-
「新しいモデル」≠「ローカルで動く」
-
モデル名 + B数 + 量子化タグが超重要
でした。
実際に評価が良かったモデル
gemma3:4b
-
軽い・速い
-
JSONが比較的安定
-
人格差は薄め
👉 フロー検証用としては最適
llama3.1:8b-instruct-q4
-
人格差が明確
-
rationale・質問の質が一段上
-
メモリ的にも現実的
👉 MAGIらしさを出すなら最有力
llama3.3 / llama4
-
今回の環境では非現実的
-
ローカル36GB帯では厳しい
JSON安定化のための工夫
ここは地味ですが重要です。
-
format: "json"を必須指定 -
JSONバリデーション
-
失敗時の再プロンプト（最大2回）
-
それでも失敗した人格は ABSTAIN扱い
-
rationale/blocking_infoの文字数制限
「全員成功しない前提」で設計すると、全体が安定します。
Streamlit UIを触って気づいたこと
-
起動時のメール入力は空欄でEnterでOK
-
UIで重要なのは：
-
人格ごとの色分け
-
rationaleの一覧性
-
DEADLOCK時の「追加質問」の目立たせ方
-
UIは判断を助ける補助線だと割り切った方が楽でした。
次にやろうとしていること
MAGI構造を流用して、
-
スライドショー自動ダイジェスト生成
-
動画 → フレーム抽出 → スコアリング
-
候補としては、
-
llava-llama3.1:8b（画像理解）
-
qwen2.5-vl:7b（構造化評価）
-
gemma3:4b + OpenCV（高速・安定）
用途次第で人格の定義も変える予定です。
全体を通しての学び
改めてまとめると、
-
LLM開発はモデル選定が8割
-
まず「軽く動かす」
-
人格・制約・合議ルールは、モデルサイズ以上に効く
-
ローカルLLMは「制約を受け入れる」と楽しい
-
Copilot + 小さな反復は相性がいい
という感じでした。
おまけ
使用した技術・サービス一覧（URL付き）
ローカルLLM実行環境
-
Ollama
https://ollama.com/
ローカルでLLMを動かすためのランタイム。モデル管理と実行が非常に楽。
使用・検証したモデル
-
Gemma 3 (4B)
https://ollama.com/library/gemma
軽量・高速。JSON運用の安定性が高く、プロトタイプ向き。
実装・開発環境
-
Python
https://www.python.org/
制御ロジック・プロンプト設計・JSONバリデーションを実装。 -
GitHub Copilot
https://github.com/features/copilot
実装スピードを上げるための補助。試行錯誤との相性が良い。
UI（プロトタイプ）
-
Streamlit
https://streamlit.io/
人格ごとの判断・理由・DEADLOCK表示を可視化するために使用。
リポジトリ
-
magi-like（GitHub）
https://github.com/yukimomo/magi-like
MAGI風・合議制AIのプロトタイプ実装。
「エヴァ × LLM × ローカルAI」という切り口、意外といけました。
にほんブログ村
