MCPネイティブのタレントマネジメント、会計基盤、CRM、不動産情報。 既存SaaS製品からするとUIの優位性喪失、API課金モデルの崩壊、自社AI製品との競合。 MCP化に踏み切れないカウンターポジションで、MCPネイティブに踏み切る絶好の機会が世界中で生まれてる。SoRの優位性は、そんな単純でない。

エージェントの共通言語「MCP」を、基礎からハンズオンで学べる公式カリキュラムが登場しました📚 しかも6言語対応です。 タイトル: microsoft/mcp-for-beginners URL: 📚 概要 Model Context Protocol（MCP）を、実践的かつハンズオンで教えるMicrosoft公式のオープンソース教育カリキュラムです。MCPは、AIモデルとクライアントアプリのやり取りを標準化する「ユニバーサルな翻訳機」と位置づけられています。 ❓ 解決する課題 MCPは、AIシステムとさまざまなツール・サービスの通信を標準化する最先端のフレームワークです。 ・しかし新しいプロトコルゆえ、体系立った入門教材が不足していました ・基礎からセキュリティ、実装、応用まで段階的に学べる土台が求められていました 💡 内容と構成 4フェーズ・11モジュールで構成されています。 ・基礎フェーズ（0〜2）：導入、コア概念、セキュリティ ・構築フェーズ（3）：15の実践ガイドで最初の実装を作る ・成長フェーズ（4〜5）：高度な概念と実世界での応用 ・習熟フェーズ（6〜11）：コミュニティ貢献と専門トピック、13ラボの総まとめ コードサンプルはC#・Java・JavaScript・Python・TypeScript・Rustの6言語で、電卓の例からDB統合の高度な実装まで段階的に進みます。# 🌍 ユースケース / 対象読者 いずれかの対応言語で基本的なプログラミング知識があり、クライアント・サーバーモデルやREST APIを理解している開発者向けです。AI/MLの背景は任意。MCPを業務に取り入れたい人の信頼できる出発点になります。 #MCP# #AIエージェント#

Fable 5 vs Sonnetを@arcads_ai MCPでの比較。 Fable5の方が、指示通りに出すというより、解釈の細かく、映像としてどう成立させるかまで組み立てている印象。 AI動画は、モデル単体の比較から、MCP連携を含めた比較に移っていきそうです。 via：@rom1trs

# AIエージェントをソフトウェアに組み込むプラクティス # ツールゲートウェイ・MCP仲介 🎯 エージェントのツール呼び出し、全部「野良API」になっていませんか？ AIエージェントが複数のツールやMCPサーバを直接呼び出す構成は、認可漏れ・二重実行・監査不能の温床です。単一のゲートウェイを挟むだけで、セキュリティの一貫性が劇的に変わります。 🔥 解決する課題 エージェントが外部ツールを直接叩く構成では、認可・レート制限・ログがツールごとにバラバラになります。プロンプトインジェクションで悪意ある引数が混入しても個別ツール側では弾けず、権限昇格や意図しない操作が起きえます。さらに呼び出しログが分散し、「誰の権限で・なぜこのツールが呼ばれたか」の事後追跡コストが跳ね上がります。 💡 提案パターン 全ツール呼び出しを単一のゲートウェイ層に集約し、認可・入力サニタイズ・レート制限・監査ログを一元管理します。タスク種別やユーザ権限に応じてツールを動的にスコーピングし、LLMに不要なツールを見せない設計にします。書込系ツールには操作単位の細粒度認可とHITL承認を、読取系にはカテゴリ単位の緩い認可を適用する非対称ポリシーが鍵です。ツールの追加・削除もゲートウェイの設定変更だけで完結し、エージェント本体のコード変更は不要になります。 ✅ 選定条件 使うとき： - エージェントが複数ツールを呼び出し、少なくとも一つが副作用を持つ - ユーザ入力や外部データがツール引数に含まれうる（input_trustが低い） - 「どのツールが・どの引数で・誰の権限で呼ばれたか」の説明義務がある 使わないとき： - ツールが1つだけかつ読み取り専用で、ゲートウェイのオーバーヘッドが見合わない - 全ツールが社内信頼済みの実験環境で、まずプロトタイプ速度を優先したい ⚠️ 落とし穴 - ゲートウェイ自体が単一障害点になります。ヘルスチェックと縮退モード（読取のみ許可など）の設計が必須です - 認可やサニタイズをプロンプトで行ってはいけません。「このツールは使わないで」はインジェクションで迂回されます - レート制限はセッション単位だけでは不十分です。大量セッション攻撃に備え、グローバル単位との二層で設けましょう 🔧 実装方針 - ゲートウェイのポリシーをYAML等の宣言的定義で管理し、ツールごとにtype（read/write）・認可粒度・レート制限・サニタイズ・ログレベルを設定します - タスク種別・ユーザ権限・会話フェーズに応じてLLMに露出するツールを動的にスコーピングし、不要なツールを選択肢から除外します - ヘルスチェックと縮退モード（読取のみ許可）を設け、ゲートウェイ障害時にもシステム全体が停止しない設計にします - MCPサーバ間のスキーマ不統一をゲートウェイ層で正規化し、エージェントには一貫したインターフェースを提供します - 高リスクなコード実行はサンドボックスへルーティングし、長時間セッションには短命の権限リースで権限範囲を時間制限します #AIエージェント# #ソフトウェアアーキテクチャ#

UTAGEって読み込み権限のみを付与ってAPIもMCPもできませんよね…？ これが解放されたら、たぶん全アカウントに対して投資先の会社全部に同じSkillsで対応出来るぜ！

AIエージェントをエンタープライズシステムに組み込むプラクティス 【MCPゲートウェイ / ツール・フェデレーション（MCP Gateway）】 💡 「エージェント5つ × SaaS 10種 = 50本の個別統合。この掛け算地獄を解消するのがMCPゲートウェイです。」 エージェントが増え、接続先SaaSが増えるたびに統合コストが爆発します。ツール定義の乱立、スキーマの不整合、そしてSaaSのサイレント仕様変更による暗黙の破綻。これらをアーキテクチャレベルで解決します。 🔥 解決する課題 - N（エージェント）×M（SaaS）の統合コスト爆発 - 各エージェントが独自にツール定義を持つことによる重複・不整合 - ツール経由の間接プロンプトインジェクション - エージェントに見えるツールが多すぎることによる選択精度の劣化 - SaaSのサイレント仕様変更（APIレスポンス形式変更等）による暗黙の破綻 🏗️ 提案パターン 各SaaSコネクタをMCP（Model Context Protocol）サーバとして束ね、ゲートウェイがツールの発見・認可・呼び出し監査・スコープ制御を一元管理します。ツール許可リストを主体（部署×エージェント種別）で動的に絞り、エージェントに見えるツールを必要最小限にします。危険ツール（削除・送金・外部送信など不可逆操作）には承認フックを設置します。さらに、ツール定義/APIスキーマを「契約」としてバージョン管理し、定期的に実APIと突合してドリフト（乖離）を検知します。後方互換のないドリフトを検出した場合は、アラート＋該当ツールの一時無効化で安全側に倒します。 ✅ 選定条件 - 採用する場合：連携SaaSが10種以上。複数エージェントが共通ツールを使う。N×M統合の複雑さに困っている。 - 採用しない場合：ツールが2〜3個固定の単機能エージェント（直結のほうが堅牢でシンプル）。依存APIが安定していて変更頻度が極めて低い環境。 ⚠️ 落とし穴 - エージェントに露出するツールが20〜30を超えると選択精度が低下します。tool RAGで意図に応じて動的に絞るか、役割別サブエージェントに分割してください。 - 契約テスト（ドリフト検知）を導入しないと、SaaS側の仕様変更に気づかず、エージェントが誤ったデータを処理し続けます。Salesforce APIのフィールド変更などは実際に起きる頻度が高いです。 - MCPサーバの認可設計を後回しにすると、全エージェントが全ツールにアクセスできる状態が放置されます。 🛠️ 実装方針 - 各SaaS（Salesforce / ServiceNow / Jira / Slack / Box 等）のMCPサーバを構築します。公式MCPサーバがあればそれを採用し、なければOpenAPI定義からツールを自動生成して自作MCPサーバとして用意します。 - MCPゲートウェイを配置し、ツールレジストリ（カタログ）を構築します。各MCPサーバが提供するツールを一覧化し、部署×エージェント種別でアクセス可能なツールを動的にフィルタリングする許可リストを設定します。 - OAuth 2.1 ベースの認可と承認フックを設定します。不可逆操作（削除・送金・外部送信）を行うツールにはP09（動的認可PDP）と連携した承認ゲートを設置し、人間の承認なしに実行されない構成にします。 - 契約テスト（Pact等）とスキーマレジストリでドリフト検知パイプラインを構築します。週次でツール定義と実APIスキーマを突合し、後方互換のない変更を検出した場合はアラート＋該当ツールの自動無効化を行います。 - tool RAG または役割別サブエージェント分割で、各エージェントに露出するツール数を20以下に制御します。意図に応じて動的にツールを絞り込み、選択精度を維持します。 #AIエージェント# #エンタープライズアーキテクチャ#