結論：「良くなった」ではなく、誰が何を変え、同じ結果を再現できるかを残す
富士通は2026年7月13日、自己進化マルチAIエージェント技術を組み込んだ「Fujitsu Kozuchi Multi AI Agent Framework（MAAF）」を発表し、7月15日から先行検証を始めるとしました。
公式発表では、業務知識からAIエージェント群を自動構成し、実行結果や人のfeedbackをもとに継続改善し、得られた知見を他のuse caseへ展開する考え方が示されています。制度、仕様、顧客要望の変化に追随できずPoCで終わる課題に対するアプローチです。
経営者が追加すべき問いは「自動で改善するか」ではありません。変更前後のversion、評価set、承認者、権限差分、失敗時のrollbackがあるかです。
この記事は、AIエージェントをPoCから本番へ進めたい経営者、業務責任者、CIO、兼任情シス向けです。PoC本番化診断から、agent設計、system連携、月次監視へつなぐ判断軸を提供します。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
公式発表で確認できる範囲
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 発表日 | 2026年7月13日 |
| 先行検証開始 | 2026年7月15日 |
| 対象 | Fujitsu Kozuchi Multi AI Agent Framework |
| 主要な考え方 | 業務知識からagent群を構成し、実行結果・人のfeedbackで継続改善 |
| 横展開 | あるuse caseの知見を他業務へ展開 |
| 背景課題 | 制度・仕様・顧客要望の変化に追随できずPoCで終わる、知見が個別最適になる |
先行検証の結果、精度、費用、正式提供条件は発表時点で確定実績として扱えません。自社導入時は個別に確認します。
自己進化で起きる5つの失敗
- feedbackを正解dataとみなす。 一部担当者の好みや一時的な例外を全体ruleへ広げます。
- 改善と仕様変更を分けない。 顧客承認済みの業務ruleが知らないうちに変わります。
- 複数agentの責任境界がない。 誤りがmemory、routing、tool、modelのどこで生じたか追えません。
- 横展開でdata境界を越える。 ある部門の事例・個人情報・機密を別部門へ持ち込みます。
- 最新versionだけを残す。 問題発生時に再現・比較・rollbackができません。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
GXO式「自己進化agent変更管理5ゲート100点」
横にスクロールして確認できます
| ゲート | 配点 | 満点の証拠 | レッドフラグ |
|---|---|---|---|
| 業務契約 | 20 | 目的、入力、出力、禁止行為、KPI、ownerをversion管理 | 「問い合わせ対応を自動化」だけ |
| 変更起点 | 20 | feedback、実行結果、制度改定の採用条件とdata出所を記録 | 全feedbackを自動学習 |
| 評価・承認 | 25 | 固定評価set、回帰test、risk別承認、human review | 平均精度だけ比較 |
| 権限・分離 | 20 | agent/tool/data/memoryの最小権限、部門境界、監査log | shared admin token |
| version・復旧 | 15 | model、prompt、workflow、memory、toolを固定しrollback訓練 | 最新構成しか残らない |
合計点に関係なく本番変更を止める条件
- 顧客連絡、支払い、削除、契約、採用判断を無承認で実行する
- 固定評価setがなく、変更前後の品質と安全性を比較できない
- feedbackの提供者、data区分、採否理由が追えない
- 他部門・他顧客のmemoryや事例へ越境できる
- 変更後に以前のworkflowへ戻す手順がない
仮想記入例：受注処理を3agentで自動化
横にスクロールして確認できます
| ゲート | 得点 | 不足 |
|---|---|---|
| 業務契約 | 15/20 | 例外受注の停止条件が曖昧 |
| 変更起点 | 9/20 | 担当者feedbackの採否基準なし |
| 評価・承認 | 12/25 | 正常case中心で返品・取消が不足 |
| 権限・分離 | 11/20 | 受注agentが更新・取消の両権限を保有 |
| version・復旧 | 7/15 | memory snapshotの復元未試験 |
| 合計 | 54/100 | 自動変更を止め、read-onlyで再検証 |
受注登録は人承認付きに戻し、返品、二重注文、在庫不足、価格例外を評価setへ追加します。feedbackは採用会議を通し、prompt、workflow、memory、tool権限を一つのrelease IDで固定します。
変更台帳の最小項目
横にスクロールして確認できます
| 項目 | 記録内容 |
|---|---|
| 変更ID | 日付、version、対象agent・業務 |
| 起点 | feedback、失敗log、制度改定、KPI悪化 |
| 差分 | prompt、routing、memory、model、tool、権限 |
| data | 出所、利用目的、個人・機密区分、保持期限 |
| 評価 | 固定set、追加case、品質、安全、cost、latency |
| 承認 | 業務、IT、security、必要時に法務・経営 |
| 復旧 | 旧version、切戻し条件、所要時間、実施者 |
先行検証でベンダーへ聞く12問
- 「自己進化」で自動変更されるcomponentは何か
- 変更前後のprompt、workflow、memoryを比較できるか
- 人のfeedbackを誰が採用・却下できるか
- 悪意あるfeedbackやdata injectionをどう防ぐか
- agent間通信とtool実行をどこまで記録するか
- 顧客・部門・案件ごとにmemoryを分離できるか
- 評価setは固定部分と追加部分を分けられるか
- 品質悪化やcost急増を自動停止できるか
- model/provider変更時の回帰testは何か
- 旧versionへ何分で戻せるか
- 検証終了時にlog、設定、評価結果をexportできるか
- 正式提供前後で仕様・料金・supportはどう変わるか
GXOのPoC本番化診断では、評価、権限、変更、監視、rollbackの不足を可視化します。業務選定から見直す場合はAI導入可否アセスメント、agentと既存systemの実装はシステム開発相談へ接続します。
FAQ
自己進化を止めると価値がなくなりませんか
自動反映を止めても、改善候補の生成やshadow評価はできます。riskの低い変更だけ自動化し、高risk変更は承認制に分けます。
人のfeedbackがあれば安全ですか
人も誤り、偏り、悪意を持ち得ます。提供者、data区分、採否、影響範囲、回帰testを記録する必要があります。
先行検証開始は正式提供と同じですか
同じとは限りません。提供範囲、料金、SLA、support、data条件は先行検証の契約と最新公式情報で確認してください。
出典・確認日
- 富士通「自己進化マルチAIエージェント技術を組み込んだFujitsu Kozuchi Multi AI Agent Frameworkの先行検証を開始」（2026年7月13日発表、2026年7月15日確認）
- 富士通 Research Portal「Multi AI Agent Framework」（2026年7月15日確認）
機能、提供条件、精度、料金、security仕様は変更される可能性があります。先行検証の個別条件と最新公式文書を確認してください。本記事の配点と仮想例はGXO独自であり、富士通の評価基準ではありません。
