AI_Review_Agent_Blueprint

AIエージェントによる設計レビュー実装ガイド LangChain・LangGraph・n8nの方式比較と、 PoC検証における「未確認リスク」の可視化 Human Approval 制作：うさうさ研修工房 APIは現行（2025-2026）準拠/公式docで都度確認・嘘つかず

基礎概念：「ワークフロー」と「エージェント」の境界線 ワークフロー（決め打ち） エージェント（自律） 観察 (Observation) Tool A Tool B LLM CORE Tool B Tool C 推論 (Reasoning) Tool C External API ■ 手順を人が固定 ■ 毎回同じ順で実行 ■ 分岐はIF/ルールで明示 ■ 再現性が高い・予測可能 用途：単純・定型のレビュー向け ■ LLMが次の行動を判断 ■ ツールを自分で選んで呼ぶ ■ 観察→推論→行動のループ ■ 柔軟だが制御が要る 用途：文脈依存・多段のレビュー向け

共通アーキテクチャ：レビュー・エージェントの基本パイプライン 規約検索 (RAG) 社内標準を根拠化 レビュー生成 ×N Self-Consistency 多数決マージ votes / 確信度計算 人間承認ゲート 重大/低確信→人間承認 確定・記録 トリアージ蓄積 社内標準を根拠化 Self-Consistency votes / 確信度計算 interrupt / 承認 トリアージ蓄積 3方式とも同じ流れ。違いは「どこで誰がどう制御するか」。本編ルーブリックと評価軸はそのまま維持。

方式① LangChain — 最速のプロトタイピング agent_agentor = create_agent() @tool def invoke(aeom, imethod): return agent[] Prompt LLM Node Toolbox RAG/Search agent_executor = agent.invoke(agent, agent_agent)) npts = PromptTemplate( "name ="Bantanne, PromptTemplate", "processs": {from Prompt}name. PromptTemplate", "promptTemplate(np)) ) ✓ 最速: 数十行で動く。ツール付きエ ージェントを最短で起動。 ✓ 現行API: create_agent が推奨。 (create_react_agentは非推奨化) ✓ 自律ツール選択: 規約検索・過去指 摘をLLMが必要時に呼ぶ。 限界: 複雑な承認ゲート制御はLangGraphへ昇格。

方式② LangGraph — 堅牢な状態管理と人間介入 retrieve review merge interrupt() (Human Gate) finalize ✓ 状態の明示管理: TypedDict+reducerで指摘を積み増す ✓ 人間承認が一級市民: interrupt()で停止し、 Command(resume='採用')で再開。 ✓ 途中再開・監査: checkpointerで状態保存 (SQLite/Postgres) ✓ 自在な分岐: 条件付きエッジで再レビューも可

方式③ n8n — チーム運用と既存SaaS連携のハブ Memory AI Agent Slack/Mail (人間の承認) Anthropic Chat Model HTTP Tool (RAG) ✓ ノーコードで可視化: ノードを線 でつなぐだけ。非エンジニアと共 有しやすい ✓ 内部はLangChain: 同じ概念（ ツール/メモリ/エージェント） で地続き ✓ 承認・連携が容易: Slack/メール 承認、既存SaaS連携が標準ノー ドで完結

診断マトリクス：どの方式を選ぶべきか？ 観点 LangChain LangGraph n8n 導入の速さ ◎ 最速 ○ やや手間 ◎ ノーコード 制御・分岐 △ 限定的 ◎ 自在 ○ IF/ルール 人間承認 △ 自前実装 ◎ interrupt標準 ◎ 承認ノード 途中再開・監査 ○ checkpointer ◎ 状態保存で強い ○ 実行履歴 非エンジニア共有 △ コード △ コード ◎ 画面で共有 既存SaaS連携 ○ 自前 ○ 自前 ◎ 標準ノード多数 Synthesis Insight 進化論的アプローチ: 迷ったら：試作はLangChain→本番の制御設計はLangGraph → チーム運用と見える化はn8nへ段階的に昇格させる。

PoCの要：「調べられなかったこと」の台帳 空白を「無い」ことにしない。 PoCの信頼は「何ができるか」ではなく「何をまだ確かめていないか」 を明確に言えることから生まれる。 「面白きこともなき世を面白く」- うさうさ

実装レイヤーの深掘り：Python vs TypeScript モデルの優劣と、実装の作りやすさ・壊れにくさは別物。後者は言語とSDK選定で決まる。 The Risks / 論点 The Verification / 最小検証 ● 各公式SDKの機能パリティと実挙動 ● 型推論・ランタイム制約 (Pydantic vs Zod) の実用度 ● フレームワークの破壊的変更の頻度 薄く作って測る ● 成功率 (Success rate) ● p95レイテンシ (p95 Latency) ● スキーマ遵守率 (Schema adherence rate) ● 逸脱時の挙動 (Behavior on deviation)

ステークホルダー別：誰の「空白」か？ 経営・財務 現場ユーザー ▲ 投資回収(ROI)と総額(TCO)が読めない ▲ 撤退基準・成功判定が未定義 ● 日本語の使い勝手・自業務での精度が 未検証 ● 既存手順への接続・教育コストが不明 法務・セキュリティ 情シス・運用 ● データ国内保管・学習利用の現行可否が 未照合 ● 最新DPA・認証が未確認 ● 統合工数・運用体制が未見積り ● 障害時の責任分界・SLAが未確定

タイムラインと情報源：いつ、どうやって空白を埋めるか 着手時 / 即変動 PoC期間中 運用後 構造的 ● 価格・ ● 世代・ ● 新機能 ● 日本語品質・ ● 統合工数・ ● 実レイテンシ ● 実TCO・ ● 定着率・ ● 実ROI ● 規制動向・ ● 市場シェア 公式情報・DPAを ベンダーに確認 自社環境での実測検証 (最優先: 最初の2週間) 本番の計測設計が 前提 仮定として明示し 定点観測 メーカーの公式情報(DPA等)と、自社環境での実測検証(自前のゴールドセット)を明確に区別する。

総括：嘘つかずの実装原則 The Architecture Elevation (アーキテクチャの昇格) Human in the Loop (人間の承認ゲート) Risk Transparency (未検証リスクの透明性) 用途に応じて進化させる。 試作はLangChainで最速検 証し、本番の制御・承認設 計はLangGraphへ、運用共 有はn8nへ段階的に昇格 させる。 LangChain (Prototype) LangGraph (Production Control) n8n (Operations Sharing) 重大な判断は必ず人間へ。 AIはあくまで下書き。 採否と説明責任は人間が 担うシステム設計を死守す る。 MANUAL INTERVENTION REQUIRED STATUS: CRITICAL HUMAN GATE ACCOUNTABILITY 空白を「無い」ことにしない。 未確認事項(コスト、機密、 日本語様式)を明示し、 PoCの最初の2週間で優 先的に潰す。 UNKNOWN RISKS (コスト, 機密, 日本語) PoC WEEK 1-2 (PRIORITY REMEDIATION) 参考資料: LangGraph / LangChain / n8n 公式ドキュメント準拠