こんにちは、株式会社K.Platinum代表の沼田です。
2026年5月25日、富士通が「業務とともに学び続ける自己進化マルチAIエージェント技術」を発表した。製造・医療・金融・行政の領域で、業務特化前と比べて平均28ポイントの精度向上を確認した、というインパクトのある内容だ。
翌朝、僕のSlackには中堅製造業の情シス部長から「これウチでも使えるんですか？」という質問が3件入っていた。AIエージェントというワードはこの1年で完全に普通名詞化したが、「自己進化」「マルチ」「業務とともに学び続ける」あたりが新しく刺さったらしい。
答えはYESだ。中堅企業でも導入はできる。3年目に入った僕らのような17人規模のITコンサルでも、受託案件で組み込めるところまで来ている。
ただし、3本の境界線を引いてからじゃないと、半年で炎上する。今日はその話をしたい。
「業務とともに学び続ける」が意味する3つのリスク
富士通発表の要点を僕なりに整理すると、こうなる。
「複数のAIエージェントが業務文脈を共有しながら自走し、業務の進行とともに知識を継続的にアップデートする」
つまり、これまでのRAGみたいに「外部知識を都度引っ張る」のではなく、エージェント自身が会話・タスク・操作のたびに自分の中の文脈モデルを更新していく、という設計だ。OpenAI Agent SDKの方向性、Anthropic MCP の流れ、Microsoft Copilot Studio が乗ろうとしている世界とも完全に同じレイヤーにある。
「便利そうじゃん」と思う気持ちはわかる。僕も最初はそうだった。
ただ、僕らが実際に中堅企業の受託案件で去年から PoC を回してきて、これは絶対に踏み抜くなと判断したリスクが3つある。
- 顧客データが学習プールに混ざる — A社の業務文脈を学んだエージェントを、B社向けにも転用したくなる。ここで「ちょっとだけ知見を再利用」を許すと、A社の固有情報がB社の応答に出てくる事故になる
- 部署境界を越えて文脈が滲む — 人事評価の会話を学んだエージェントが、別の社員から見える形でその痕跡を出す。一見「便利な気付き」に見えて、内部統制的にはアウト
- 退職者の文脈が残り続ける — 退職者と一緒に走ったエージェントが、退職後もその人の意思決定パターンを再生してしまう。法務的にも、心理的にも、地味に怖い
「自己進化」というキーワードは綺麗だが、運用する側からすると「知らないうちに学んじゃう」「忘れさせるオペレーションがない」というのは、要するに監査困難なシステムになる、ということだ。
中堅企業の情シスがいちばん嫌うやつだ。
17人ITコンサルが受託案件で引いた3本の学習境界線
ここからが本題。じゃあ僕らはどうやって入れているか。
ちなみに大企業版の成功例だと、トヨタ×Microsoftのマルチエージェント「O-Beya（大部屋）」はパワートレーン開発の約800名が日常的に使っている。ただあれは専任チームありきの規模で、前職でトヨタにいた身からすると体制がまるで違う。17人の僕らは同じことを専任チームなしで、しかも複数顧客の受託で回す必要がある。だからこそ境界設計が効いてくる。
K.Platinumでは、マルチエージェント運用を入れるときに3本の境界線を「先に」引く。設計してから入れる、じゃない。入れることが決まったタイミングで、まず境界の絵を描く。
境界A: テナント境界 ─ 顧客データを学習プールに混ぜない
これがいちばん固い線。
複数の顧客企業を持つITコンサルにとって、エージェントの「学習」を顧客横断で許すと、それは一発で守秘義務違反になる。便利だからやりたくなる。誘惑が強い。だから「やらない」ではなく「物理的にできない」ように設計する。
具体的にはこうする。
- 顧客ごとに専用のエージェント実体を立てる（エージェントランタイムを顧客テナントで分離）
- 学習データの保存先は顧客テナントのオブジェクトストレージ。共通プールを置かない
- ベースモデルは共通、ファインチューニング層は顧客ごとに分離
- メタモデル（複数顧客から得た一般化知見）を作りたい時は、必ず人間レビューを経由させる
「メタモデルを作るために人間レビュー挟む？非効率では？」と思うかもしれない。実際そう。でも、これは効率と引き換えに、説明可能性を買っている。何かあったときに「この知見はこのレビューで承認した」と言える状態を作る。事故が起きてから後悔するより、最初から非効率な方を選んだ方が安い。
境界B: 部署境界 ─ 人事/経理/技術の文脈分離
社内マルチエージェント運用を始めると、つい「全社共通の賢いAI」を作りたくなる。これも罠だ。
部署ごとに必要な文脈は違うし、見せていい情報も違う。人事評価の文脈を学んだエージェントが営業の会議に出てきて「○○さんは評価のリスクがある」みたいなことを口走った瞬間、組織はあっという間に壊れる。
僕らがやっているのは、こう。
- エージェントの「ペルソナ」を部署単位で分割（人事ペルソナ、経理ペルソナ、技術ペルソナ、営業ペルソナ）
- ペルソナ間で会話履歴・学習結果を共有しない
- 部署横断で必要な情報は、別途「中立ハブ」エージェントを置いて、そこを経由する
- ハブ経由のデータには明示的に「どの部署から来た情報か」を属性として保持
「部署ごとに別エージェント？保守コスト3倍になりませんか？」と聞かれたことがある。なる。だがここをケチると、退職時の文脈漏れも統制違反も、全部跳ね返ってくる。
境界C: 時間境界 ─ 古い文脈を意図的に忘却させる
これは一番見落とされる線。
「学習し続ける」エージェントは、何もしないと「ずっと覚え続ける」エージェントになる。3年前のプロジェクトの古い前提が、今の会話に混ざってくる。3年前に辞めたメンバーの意思決定パターンが、今日のレビューに反映される。
これを防ぐには、意図的な忘却をシステム設計に組み込まないといけない。
- 学習データに有効期限メタデータを持たせる（例: 90日／1年／永久）
- 永久指定は限定的に。ほとんどのデータはデフォルト「1年で減衰」「3年で完全削除」
- 退職・案件終了・契約変更などのライフサイクルイベントで、関連学習データを一括失効させる
- 月次で「忘却レビュー」を実施。意図的に消したものと、勝手に残ったものを差分確認
このオペレーションを最初に組み込まないと、半年で文脈プールがゴミだらけになる。エージェントの応答品質は下がり、誰も信用しなくなり、最終的に「結局AI入れたけど誰も使ってないよね」というあのオチに着地する。
富士通 vs OpenAI Agent SDK vs Anthropic MCP ─ 3者比較で見える“境界の引きやすさ”
実装プラットフォームをどれで組むかは、上の3本の境界線を「どれだけ引きやすいか」で決めるべきだ。性能の話より、境界設計のしやすさ。これを2026年5月時点の情報で比較したのが下の表だ。
| 観点 | 富士通 自己進化マルチAIエージェント | OpenAI Agent SDK | Anthropic MCP |
|---|---|---|---|
| テナント境界 | 富士通クラウド前提、専用テナント分離可 | ランタイム側で実装。APIキー単位で分離 | サーバ側に責任。MCPサーバ単位で分離 |
| 部署境界 | エージェントペルソナを定義可、共有制御は実装次第 | カスタムインストラクション+メモリ分離で対応 | MCPサーバを部署ごとに立てて分離 |
| 時間境界 | 学習データのライフサイクル管理機能あり（発表時点） | メモリAPIに削除エンドポイント | サーバ実装側に依存 |
| 監査ログ | エンタープライズ機能として提供 | 標準ログ＋カスタム | サーバ実装側に依存 |
| 国内サポート | 富士通本体・SI部隊あり | リセラー経由 | リセラー経由 |
| 中堅企業向き度 | ◎（境界設計を支援してくれる） | ○（自分で設計が必要） | ◎（境界をサーバ分割で物理的に引ける） |
中堅企業が一番ハマりやすいのは、境界を「自分で設計しなきゃいけない」プラットフォームを選んでしまうケース。OpenAI Agent SDKは設計の自由度が高い分、内製エンジニアの設計力が必要になる。「ベンダーに任せて入れたい」「PoCで終わらせずに本番運用に乗せたい」中堅企業の場合、富士通のように境界設計をプラットフォームが支援してくれる側か、Anthropic MCPのように境界をサーバ単位で物理的に引ける側のほうが、運用の事故率は下がる。
僕ら受託側の本音を言うと、案件規模と顧客の社内体制で選び方が変わる。情シス3人以下の中堅企業なら富士通の伴走をベースに、僕らがアプリ層を作る。情シス10人以上で内製文化があるなら MCP でサーバを部署ごとに切る。OpenAI Agent SDK は「全部自分たちで作りたい」スタートアップ寄り顧客で採用する。
▼ K.Platinumでは、AIエージェントの本番運用を顧客と一緒に設計するエンジニアを募集中です。「PoC止まりじゃなく、境界設計から受託で踏み込みたい」という方は、エンジニア募集の詳細を見る。
中堅企業がマルチエージェント運用を始めるときの順序
最後に、現場でやっている順序を共有しておく。これは順番を間違えると地味に致命傷になる。
- ユースケースを「学習させる必要があるもの」と「させなくていいもの」に切り分ける — RAGで十分なものに自己進化を入れない。判断基準は「同じ問いに対する正解が3ヶ月で変わるか」
- 境界設計の絵を先に描く — テナント・部署・時間の3軸で、どこに線を引くかを上流で決める
- プラットフォーム選定 — 上で書いた3者比較。境界設計のしやすさで選ぶ
- PoC → 本番の橋渡し設計 — PoCで成功したら、本番に乗せる前に「忘却レビュー」「監査ログ確認」「定期的な境界線見直し」のオペレーションを定義
- 運用開始後の月次レビュー — 3本の境界線が機能しているか、学習データの偏りが出ていないかを月次で確認
僕らが受託で入る案件だと、ステップ1〜3で2ヶ月、ステップ4で1ヶ月、運用開始から3ヶ月で1回目のレビューを回す、というのが現実的なリズムだ。
まとめ ─ 「学習し続ける」は「無境界に学ぶ」ではない
富士通の発表は、いま日本のマルチエージェント運用が「PoCの先」に進むための重要なシグナルだと思う。
でも「自己進化」というワードに引っ張られて「全部学ばせれば賢くなる」と勘違いすると、中堅企業はほぼ確実に事故る。
学習し続けるエージェントを入れるときに必要なのは、学ばせる範囲を意図的に絞る境界設計だ。テナント、部署、時間。この3本の線を上流で引いておくと、運用後半年の景色が完全に変わる。
「便利」と「統制可能」を両立させるのが、僕ら受託側の腕の見せ所だと思っている。
僕らK.Platinum は、製造業・流通・金融の中堅企業を中心に、AIエージェント本番運用を伴走している。富士通の自己進化マルチAIエージェントを含めた最新プラットフォームのキャッチアップと、受託としての境界設計の両方ができるITコンサルは、まだ国内で多くない。導入検討の壁打ち相手としても声をかけてほしい。
沼田 海斗 / 株式会社K.Platinum 代表取締役
沖縄高専卒。トヨタ自動車・スタートアップITコンサルを経て、24歳でK.Platinumを創業。現在3期目・27歳。製造業AI・受託開発・ジゴカツ（プログラミングスクール）の3軸で、17人組織を回している。趣味はキックボクシング。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。