AIエージェントは「作って終わり」じゃなくなる——富士通MAAFが変える運用の常識
AIエージェントの最大の弱点は、完成した瞬間から陳腐化が始まることだ。
業務フローが変わる、担当者が変わる、規則が変わる。そのたびにエージェントの仕様を書き直し、再テストし、再デプロイする。それが現実の運用コストであり、多くの企業がAIエージェントを「PoC止まり」にさせている根本原因でもある。
富士通が2026年7月13日に発表した「Fujitsu Kozuchi Multi AI Agent Framework（MAAF）」は、この問題に正面から挑んでいる。同月15日より先行検証を開始するという。
AIエージェントの「作って終わり」問題、富士通が本丸に切り込む
富士通の発表資料が指摘する従来課題は明快だ。「仕様変更や業務手順の変更への対応負荷が高く、継続運用が困難になる」。これはAIエージェントに限った話ではなく、あらゆるシステムが抱える運用の重力だ。ただ、AIエージェントの場合は「自律的に動く」という性質が絡むぶん、ズレの検知と修正がより難しい。
MAAFのコンセプトは、エージェントの「構築→運用→改善」を分断されたプロジェクトとして扱うのではなく、ひとつの連続したライフサイクルとして管理することだ。そこに「自己進化」という言葉が乗ってくる。
何ができるのか：構築から自己進化までのライフサイクル
具体的な機能として発表資料から確認できるのは、大きく4つだ。
1. 非構造化データからの要件抽出
既存のマニュアルや会議録画などから、AIが自律的に要件を抽出し、複数の構成案を提示する。「会議録画から」という点が興味深い。暗黙知として口頭でしか伝わっていない業務ルールを拾い上げることを想定している。
2. 対話型セッションによる自動構成
人間が専門コンサルタントとヒアリングを行うような対話型セッションを通じて設計の論点を整理し、マルチAIエージェントシステムを自動構成する。ユーザーは設計書を書くのではなく、「対話して確認する」という役割になる。
3. 誤進化防止機構
ここが技術的な肝だと思う。変更によってかえって性能が低下する「誤進化」を防ぐため、生成された候補を実行環境上で事前検証し、効果が確認された変更のみを本番環境へ反映するという制御機構を備えている。自動化するが、野放しにはしない、という設計思想だ。
4. 人の承認プロセスと監査ログ
特に影響の大きい重要な変更については、人の承認プロセスを組み込むとともに、変更履歴を監査可能な形で保持する。自律性と統制の両立を明示的に設計している。
さらに、運用過程で得た「成功パターンや失敗理由を構造化して蓄積し、類似のユースケースへ横展開する」という学習の循環も組み込まれているとされる。単に動くだけでなく、組織の経験を資産として積み上げていく発想だ。
ここからは見方だが：この発表が示す業界の構造変化
率直に言えば、この発表が示している方向性自体は、業界の大きな流れと一致している。「作る」フェーズのAI活用から、「育てる・管理する」フェーズへのシフトだ。
AIエージェントが増殖すればするほど、その管理コストは線形以上に増える。誰がどのエージェントを承認したのか、変更の影響範囲はどこまでか、失敗したときの責任はどこにあるのか。これらは全部、「作る」フェーズでは見えなかった問題だ。
MAAFはその問題を「フレームワークとして包む」ことで解こうとしている。ガバナンス機能を後付けではなくアーキテクチャに組み込んでいる点は、設計判断として評価できる。
ただし、期待値の調整は必要だ。発表時点では「先行検証を開始する」段階であり、本番環境での実績はまだない。「自己進化」という言葉のインパクトに引っ張られすぎると、実態より大きな期待を持ってしまう。今は「仕組みとして筋が良い」と評価できる段階であって、「確実に機能する」と判断できる段階ではない。
実務的な視点：開発者・IT部門・経営者は何を考えるべきか
ガバナンス設計が先、自動化は後。
MAAFの設計を見ていて感じるのは、「どこまでを人が決め、どこからをシステムに委ねるか」という境界線の設計が、実用化の鍵を握るということだ。自動化ツールを導入する前に、その境界線を社内で合意できているかどうかを確認すべきだ。承認フローを誰が持つのか、監査ログを誰がレビューするのか。ここが曖昧なまま「自己進化」を導入すると、何かが起きたときに責任の所在がわからなくなる。
適用領域の選び方に富士通の現実認識が見える。
富士通が最初に適用を進める領域として挙げているのは、小売業における発注業務、システム開発・モダナイゼーションにおける調査・影響分析・テスト、営業業務における提案準備だ。「複雑で属人化しやすい業務領域」という括り方をしている。
逆に言えば、単純な繰り返し業務への適用は後回しにしている。これは正直な選択だと思う。自己進化の恩恵が大きいのは、変化が多く、暗黙知が蓄積されている領域だからだ。
Kozuchi・Takaneとの連携が示す富士通のエコシステム戦略。
MAAFは単体のプロダクトではなく、富士通のAIプラットフォーム「Fujitsu Kozuchi」やエンタープライズ向け生成AI「Takane」との連携を前提として設計されている。これは、MAAFを導入すれば自然と富士通のAIエコシステムに深く組み込まれていくことを意味する。ベンダーロックインのリスクと、統合の恩恵をセットで考える必要がある。
次の論点：「自己進化」が実用化されたとき何が問題になるか
仮にMAAFが設計通りに機能するとして、その先に何が待っているかを考えておく価値はある。
変更の責任はどこに帰属するか。
エージェントが自律的に構成を変更した結果、業務に悪影響が出たとき、誰が責任を取るのか。変更を承認した担当者か、フレームワークを導入したIT部門か、それとも富士通か。監査ログがあっても、責任の帰属が不明確なままでは、運用担当者は承認ボタンを押すことに慎重になりすぎる。「自動化したはずなのに承認待ちが詰まる」という逆説が起きかねない。
自律改善と組織の意思決定の境界線。
エージェントが「成功パターンを横展開する」とき、それは本来、業務設計の意思決定に踏み込む行為だ。AIが業務プロセスの変更を主導するとき、組織内の誰がそれをオーナーシップとして持つのか。これは技術の問題ではなく、組織設計の問題だ。
コスト構造の不透明さ。
自己進化型フレームワークは、運用コストの予測が難しい。改善サイクルが回るたびにどれだけのコンピューティングリソースを消費するのか、LLM APIの呼び出しコストはどう変動するのか。導入前に「ランニングコストの上限設計」を明示的にしておかないと、便利さの代わりに予算超過が待っている。
まとめ：「育てるAI」時代の入口
MAAFの発表が面白いのは、AIエージェントの「使い捨て問題」に対してシステム的に答えようとしている点だ。単なる機能追加ではなく、ライフサイクル全体を包む思想が見える。
ただし、先行検証を開始したばかりという段階で「自己進化」という言葉を額面通りに受け取るのは早い。見るべきは、半年後・1年後に小売業などの実際の業務でどんな成果が出たか、そしてガバナンス設計が実運用で機能したかどうかだ。
同種のニュースを今後目にするときは、「自律化の範囲がどこまでか」「人の承認プロセスがどう設計されているか」「失敗したときの責任の帰属がどう定義されているか」の3点を確認する習慣を持っておくと、実態が見えやすくなる。
