こんにちは。CData Software Japan リードエンジニアの杉本です。

私は日々のタスク・プロジェクト管理に Jira とConfluence を使っています。たとえばウェビナー開催の一連の作業——コンテンツの方向性の整理、企画書の作成、LP やメルマガ文の生成、Confluence へのページ登録、タスク・マイルストーン分解、Jira へのチケット登録——を Claude と対話しながら進めています。Confluence・Jira への登録は MCP 経由で行っており、一連のフローが半自動化されています。

ところが、Jira 登録の段階でいつも引っかかる箇所がありました。チームで運用している Jira にはカスタムフィールドが多く、「Epic を切って紐づける」「カテゴリを正しく指定する」といった必須項目を AI が正しく判断してくれないことが頻発していたのです。

今回は、この問題を通じて気づいた MCP ツール設計の考え方を共有したいと思います。

標準の MCP ツール＋カスタムフィールド多数という組み合わせ

Jira の MCP ツールには標準の create_issue があります。フィールドを自由に指定できる汎用ツールで、単体で見れば必要十分に見えます。

問題は、チームで運用している Jira にはカスタムフィールドが多いという点です。AI は「どのフィールドを指定すればよいか」を毎回推論しますが、どれが業務ドメインとして必須でどれに何を入れるべきかはスキーマからは読み取れません。結果として、必須フィールドが空白のままチケットが登録されたり、カテゴリが毎回違う値になったりという再現性のなさが生じていました。

最初に試みたのは2つのアプローチです。ひとつは CLAUDE.md やプロジェクトに指示を書き込むこと——「Jira に登録するときは必ず Epic を指定し、カテゴリは MJ プロジェクトの場合は X を選べ」といったルールを記述しました。もうひとつは登録フロー全体を .claude/skills/ 配下のスキルファイルとして整備することです。

ただ、いずれも確実に動作する保証はありません。CLAUDE.md の指示はコンテキストの状況によって優先度が変わり、スキルも定義したトリガーに合致しなければ呼ばれません。そして、どちらも個人の環境に依存するため、チームメンバーに再現できないという組織展開の壁は変わらず残ります。さらにスキルなどの資産は共有するのが難しい、ないし個人毎でチューニングの余地もあるという点も挙げられます。

そこで課題の本質は、AI に迷う余地を与えすぎているインターフェース設計にあると考えました。

プロンプトで補おうとすること自体が、対処する場所を誤っているのかもしれない——そう捉え直したとき、思い出したのが API 設計の世界で確立されてきた API-led Connectivity の考え方でした。「コンシューマーに合わせてインターフェースを設計する」というこの思想を MCP に応用すれば、この問題は改善できるのではないか。そう発想して整理したのが、後述する MCP-led Connectivity です。その出発点として、まず責務の切り分けを定義しました。

MCP-led Connectivity：3層で整理する

ツール側でビジネスロジックを担うとはどういうことか。API-led Connectivity は、2010年代に MuleSoft が提唱したアーキテクチャパターンで、API を System・Process・Experience の3層に分離することで再利用性と保守性を高める考え方です。AI エージェントを「新しいコンシューマー」と捉えてこれを MCP に対応させると、以下の3層に整理できます。

Jira の例で言えば、create_issue（汎用）は System Tools に相当します。これをそのまま渡すのではなく、register_webinar_task(title, epic_key, due_date)のように、業務シナリオに応じて必須フィールドをパラメータとして明示し、カテゴリやプロジェクトコードはツール内部で固定してしまうのが Experience Tools の設計イメージです。AI が迷う選択肢をあらかじめ取り除いておくことで、毎回同じ品質でチケットが作られるようになります。

ちなみに汎用ツールが不要というわけではありません。新しいプロジェクトの構造を把握したい探索フェーズでは System Tools が役立ちます。しかし、毎週繰り返すウェビナー登録のような定着した業務タスクには、意図が埋め込まれた Experience Tools だけを渡す。このフェーズによる使い分けが、再現性を確保する鍵です。

今回はJira を例に上げていますが、これが大量のオブジェクトが標準的に存在するSalesforce やSAP、kintone のようなSaaS であれば、なおのこと再現性の確保が課題になるでしょう。

ビジネスロジックはインターフェース（MCPツール）に、ドメイン知識・業務プロセスはスキルに

必須フィールドの指定や Epic 紐づけのルールは「このプロジェクトではこう登録する」という業務ロジックです。これはツール側があらかじめ受け取る値を絞り込み、AI が迷う余地をなくす設計で担うべきものです。

一方、スキル側にも明確な役割が残ります。「ウェビナー企画ではコンテンツの方向性整理→企画書→LP・メルマガ→タスク分解という順序で進める」といった業務プロセスの知識や、「この時期のウェビナーは製品アップデート紹介を優先する」といったドメインの文脈は、ツールに固定すべきものではなく、スキルやプロンプトが担うべき領域です。揺らいでも致命傷にならない判断はスキルに、揺らいではいけないルールはツールに——という線引きです。

ちなみに、先日参加した Code with Claude: Extended Tokyo でも、同じ構造の責務分離が語られていました。

旅行プラットフォーム Myrealtrip 社の CTO が、払い戻し金額計算の本番運用で「モデルは解釈し、コードが計算する（The model should interpret. Code should calculate.）」という設計に転換した事例です。印象的だったのは「重要な変化はモデルを賢くすることではなく、モデルに明確な責任を与えることだった」という言葉でした。スキルと MCP ツールの責務分離も、まさに同じ考え方だと思います。

必要なコンテキストを、必要なところに、必要なタイミングで提供すること

最近、メタデータカタログおよびセマンティックレイヤーやコンテキストレイヤーの整備が盛んに議論されていますが、私はもう一歩先を考える必要があると感じています。重要なのは「コンテキストを拡充する」ことだけではなく、「必要なコンテキストを、必要なところに、必要なタイミングで提供する」ことです。情報量が増えるほど、AI はかえって意図通りに動かなくなる瞬間があります。

これは人間の組織でも同じです。新入社員に業務マニュアルを全冊渡して「全部読め」と言う会社はありません。必要なシチュエーションで必要な情報を届けるのが、人を動かす情報設計の基本のはずで、AI も例外ではないと思います。コンテキストを「増やす」整備と、業務ドメインに応じてスリムに「絞って」届けるツール設計——この両立こそが、3層モデルが目指しているものです。

そして、この3層の設計はオーナーシップの分離にもつながります。System Tools はインフラ・情シス担当が管理し、Experience Tools はDXチームやエージェント担当が管理する——という分担が自然に生まれます。個人の設定ファイルではなく、組織のインターフェース設計として管理できるのが、この発想の本質的なメリットです。

CData Connect AI で実装する

Jira のチケット登録で気づいたこの設計原則は、データアクセス全般にそのまま適用できます。「Salesforce の商談データを毎週レポートする」「kintone のレコードを集計する」——こうした繰り返しのデータ活用タスクでも、汎用クエリツールを渡すか・意図を埋め込んだツールを渡すかで、AI の回答品質は大きく変わります。

この3層モデルは、スクラッチでAPI やMCP をラップしたリモートMCP を開発して提供していくこともできますし、CData Connect AI の Toolkits やWorkspace・Derrived View 機能を使っても実装できます。

Toolkits では、AI エージェントに渡すツール群を用途ごとに分離・管理できます。Custom SQL Tools でパラメータ付きの事前定義クエリを作成すれば Experience Tools に、Universal Tools（getTables・queryData 等）を有効化したツールキットは System Tools 専用として切り出せます。

各 Toolkit には MCP Remote Server URL が自動生成されるため、Claude Code・Dify・n8n など MCP 対応クライアントにそのまま接続して利用できます。

CData Connect AI は350種類以上のデータソースに対応しており、Salesforce・kintone・SAP・各種RDB などエンタープライズシステムをそのまま AI エージェントから活用できます。

詳しくは以下の記事もあわせてご覧ください。

https://jp.cdata.com/blog/cdata-connect-ai-toolkits

おわりに

「MCP でデータを公開する」から「AI エージェントのためのインターフェースとして再定義・再設計する」への発想の転換が、AI エージェント活用を組織に定着させる鍵だと考えています。

コンテキストを「増やす」整備と「絞って届ける」設計を両立できる仕組みこそが、これからの AI とビジネスデータの基盤の差別化になるはずです。

スキル定義で戦っている方は、ぜひ一度ツール設計の視点から見直してみてください。