Quantum Box / Solutions
MCPサーバー開発・既存システム連携の設計AIと いまの システムを つなぐ
AIエージェントから社内データや業務システムを利用するために、接続先・権限・人の承認をどう設計するか。MCPサーバー、直接API連携、定型ワークフローの選び方を整理します。AIに どの しごとを まかせ、だれが たしかめるかを きめます。いまの システムと つなぐ ほうほうを せつめいします。
更新日：2026年9月11日。以下は開発の検討・設計方針です。個別案件の仕様や効果を保証するものではありません。2026年9月11日に こうしん。つくりかたの かんがえです。できることは そうだんして きめます。
MCPを導入する前に、仕事の単位を決めるまず、まかせる しごとを きめる
MCPを使うこと自体を開発の目的にはしません。まず「担当者が、何を見て、どの判断をし、どのシステムに結果を残すか」を一続きの業務として整理します。たとえば問い合わせの回答案を作る仕事なら、顧客情報の参照、社内文書の検索、回答案の作成、担当者による承認、送信という境界を分けます。この例は設計の説明であり、当社の導入実績を示すものではありません。どの じょうほうを みて、だれが きめ、どこに のこすかを かきます。たとえば、へんじの あんを AIが つくり、ひとが たしかめます。これは つくりかたの れいです。
そのうえで、AIに判断を任せる必要がある箇所と、通常のプログラムで確実に処理する箇所を分けます。毎回同じ条件で集計するだけなら、定型処理で足りる場合があります。自然言語で依頼内容が変わり、複数の機能を選びながら進める仕事なら、AIエージェントと接続層の分離を検討します。先に境界を決めることで、接続数だけを増やして業務の責任者が不明になる状態を避けます。いつも おなじ しごとは、ふつうの プログラムで よいことも あります。AIが きめる ところと、ひとが きめる ところを わけます。
MCPは共通の接続方式。業務権限の代わりではありませんつながっても、なんでも してよい わけではありません
MCP（Model Context Protocol）は、AIアプリケーションと外部の機能・情報をつなぐためのプロトコルです。公式仕様ではホスト、クライアント、サーバーを分け、サーバーがツールなどの機能を提供します。MCPに対応しただけで、接続先の利用権限や業務上の承認が自動的に整うわけではありません。プロトコルの互換性と、実際に許可する操作は別に確認する必要があります。MCPは、AIと ほかの どうぐを つなぐ きまりです。だれが なにを してよいかは、べつに きめます。
当社が開発するTACHYON Agent APIはMCP準拠の自律型AIエージェント開発基盤として2025年10月29日に提供を開始しました。この公開情報と、個別の受託開発で必要な機能は区別します。利用したいクライアント、接続先、認証方式、実行環境を確認してから適用範囲を決めます。ここで説明する監査や承認の設計は、すべてが既成の製品機能として提供されることを意味しません。TACHYON Agent APIは MCPに そって つくられています。つなげる ばしょや、ひとの かくにんは、そうだんして きめます。
接続先は、名前よりも「使える条件」で確認するつなぐ ための じょうけんを しらべる
社内DB、文書管理、顧客管理、在庫管理など、候補を一覧にします。各接続先について、公式APIの有無、利用契約、認証方法、アクセスできるデータ、呼び出し制限、検証環境の有無を確認します。サービス名が分かっただけでは連携の可否や工数は決まりません。契約プランによってAPIが使えない、管理者の承認が必要、書き込みは許可されていないといった条件を、着手前の論点として残します。APIという つなぎぐちが あるか、けいやくで つかえるか、だれの きょかが いるかを しらべます。
既存システムに安全な接続口がない場合は、読み取り専用のデータ出力や、人が確認して取り込む方式も候補です。画面の自動操作が必要な場合は、画面変更への弱さ、認証の扱い、利用規約、異常終了時の復旧を別途評価します。接続が難しい範囲を最初のPoCから外すことも、実現性を確かめるための選択です。未確認の接続先を、対応済みのサービスとして列挙しません。つなぎぐちが なければ、データを よむだけにする ほうほうも あります。むずかしい ところは、さいしょの ためしから はずせます。
ツールは、業務上の意味が伝わる大きさにするどうぐが することを はっきりさせる
公開する機能は「任意のSQLを実行する」のように広げすぎず、「許可された範囲の注文状況を取得する」のように、入力と操作範囲を説明できる形にします。必須項目、受け付けない値、結果に含める情報、失敗したときの返し方を決めます。データベースの内部構造や秘密情報を、そのままAIに渡す必要があるかも見直します。取得した情報に含まれる文章は、システムからの命令とは分けて扱います。どうぐが すること、うけとるもの、できないことを きめます。ひみつの じょうほうを AIに わたしすぎないようにします。
自由度と安全性は、ツールの数だけでは判断できません。細かすぎる機能を大量に出すと、選択や組み合わせが複雑になります。一方で、確認と実行を一つにまとめすぎると、人が途中で判断できなくなります。読み取り、変更案の作成、変更の確定を必要に応じて分け、どの段階で再確認するかを業務担当者と決めます。よむこと、へんこうの あんを つくること、じっこうすることを わけて、ひとが たしかめられるようにします。
認証と認可を、接続する両側で設計するだれが なにを できるかを きめる
認証は誰かを確かめること、認可は何を許すかを決めることです。接続できたことを、すべてのデータを読んでよい根拠にはしません。部署、担当範囲、顧客、拠点などの境界がある場合は、サーバー側で対象範囲を絞ります。AIに「他部署のデータを見ないで」と指示するだけでは、権限管理の代わりになりません。利用者の入力に含まれる組織名や識別子も、そのまま信用しない設計を検討します。つなげた ひとにも、みてよい じょうほうと、みてはいけない じょうほうが あります。システムが たしかめます。
HTTP経由のMCP認可は公式仕様を参照し、接続先サービス用の認証情報と区別して扱います。トークンを安易に別サービスへそのまま転送せず、有効期限や対象サービスを検証する方式を確認します。秘密情報の保管先、更新担当、失効時の対応、ログへの記録禁止を設計書に残します。必要な仕様やクライアント対応は更新されるため、開発時点の公式仕様と接続試験で確認します。かぎになる じょうほうは、あんぜんな ばしょに おきます。きげんが きれたときの たいおうも きめます。
書き込みには、確認できる承認点を置くかえる まえに、ひとが たしかめる
登録、更新、送信などの操作は、読み取りよりも影響範囲が大きくなります。変更対象、変更前後の内容、外部への送信先を人が確認してから進める設計を検討します。「承認」ボタンがあるだけで十分とは考えません。確認画面に見えていた内容と、実際に実行される内容が一致していること、承認後に条件が変わった場合は再確認することを確認項目に含めます。どこを どう かえるかを みてから、ひとが きめます。みた ないようと、じっこうする ないようを そろえます。
取り消せない操作は、権限のある担当者が最後に実行する運用を残すことも選択肢です。通知の送信や外部システムの更新は、再試行による二重実行を防ぐ仕組み、実行済みかを照会する手段、障害時に人が判断できる記録を検討します。自律性を一律に高めるのではなく、失敗したときの業務への影響から、許可する操作を決めます。もどせない しごとは、ひとが さいごに おこなう ほうほうも あります。おなじ しごとを まちがえて くりかえさないようにします。
PoCでは、成功する例だけを試さないうまく いかない ときも ためす
評価対象には、必要な情報がない依頼、権限外の参照、曖昧な対象、接続先の停止、途中で取り消された依頼を含めます。意図どおりに拒否できるか、人へ引き継げるか、処理を途中から二重に実行しないかを観察します。実データを使う場合は利用許可と持ち出し範囲を確認し、開発用と評価用のデータを分けます。接続試験で成功したことと、業務として採用できることを別の判断にします。じょうほうが たりないとき、きょかが ないとき、とちゅうで とまるときも ためします。ひとに もどせるかを たしかめます。
合格ラインは発注側と開発側で事前に決めます。結果の正しさに加え、誤操作、確認にかかる負担、処理時間、外部サービスの利用料、復旧の手順を判断材料にします。本番に進む、読み取り専用に限定する、対象を絞って再検証する、開発を止めるといった選択肢を残します。当社は未測定の成功率や削減率を、提案段階で実績として掲載しません。なにが できたら よいかを、さきに きめます。つづける、はんいを せばめる、とめる、どれも えらべます。
検証から本番へは、許可する範囲を段階的に広げるすこしずつ つかう はんいを ひろげる
初めから全社のデータと書き込み権限を与えるのではなく、検証環境、限られた利用者、読み取り中心の業務から始める構成を検討します。実際の担当者が使って、依頼の曖昧さや確認しにくい出力を見つけ、手順と画面を調整します。本番データを使わないと確認できないことは、どこまで事前検証し、何を限定運用で確かめるかを文書で分けます。検証のために権限を広げたまま残さないことも確認事項です。さいしょは、すくない ひとと しごとで ためします。ためすための きょかを、そのまま のこさないようにします。
本番化を判断する資料には、確認した操作、確認していない条件、残る制約、問い合わせ先、停止と復旧の手順をまとめます。担当者が変わっても、なぜその権限を与えているか、どの結果を人が見直すべきかが分かることを重視します。接続先の仕様変更やモデル更新で評価結果が変わった場合に備え、再検証の対象をたどれるようにします。できたこと、まだ ためしていないこと、とめかたを のこします。たんとうしゃが かわっても わかるようにします。
発注時の成果物を、コード以外にも定義するプログラム いがいに うけとるもの
見積もりの段階で、接続先一覧、ツールの入力・出力仕様、権限の対応表、承認フロー、評価結果、運用手順のうち何を納品対象にするかを確認します。必要な資料は案件ごとに異なるため、すべてを標準料金に含むとは限りません。画面やコードが完成しただけでは、運用側が安全に引き継げない場合があります。発注側で維持する設定と、開発側が保守する範囲を分けておくと、運用開始後の問い合わせ先も明確になります。つなぐ ばしょの いちらん、きょかの ひょう、つかいかたなど、うけとるものを きめます。ぜんぶが おなじ おかねに ふくまれるとは かぎりません。
運用・変更・引き継ぎまでを見積もるつくった あとの しごとも きめる
運用中は、接続先APIや認証設定、業務ルール、利用モデルが変わります。変更時にどのテストを再実行するか、停止を判断する担当者は誰か、接続先の障害を誰に知らせるかを決めます。ログは必要な操作と結果を確認できる範囲にし、個人情報や認証情報を無制限に残さない方針にします。保存期間、閲覧権限、削除手順も、扱うデータに応じて確認します。つなぐ しくみや しごとの きまりが かわったら、もういちど ためします。だれが なおすか、とめるかを きめます。
発注時は、対象業務、利用者、候補の接続先、読み取りと書き込みの範囲、承認者、希望する運用環境を共有してください。認証キーや顧客データを問い合わせフォームに入力する必要はありません。資料が揃っていない場合は、分かる範囲の業務説明から始められます。料金の下限は親ページに公開していますが、接続条件や安全対策によって必要な範囲が異なるため、個別の仕様を確認して見積もります。しごと、つなぐ ばしょ、たしかめる ひとを おしえてください。ひみつの かぎや おきゃくさまの データは、フォームに かかないでください。
MCP・直接API・定型ワークフローの3方式を比較3つの つなぎかた
| 方式ほうほう | 検討する場面つかう ばめん | 確認する負担たしかめること |
|---|---|---|
| MCPサーバーMCP | 複数の対応クライアントから共通の業務機能を使いたいいろいろな AIから おなじ どうぐを つかう | クライアント互換性、ツール境界、接続先ごとの認可を検証つながりかたと きょかを たしかめる |
| 直接API連携APIで つなぐ | 用途と呼び出し元が決まっているきまった しごとで つかう | 個別実装を管理し、接続先の仕様変更に追随それぞれの へんこうを なおす |
| 定型ワークフローきまった てじゅん | 順序と分岐条件を明示できるじゅんばんを きめられる | 例外を設計し、不要なAI判断を増やさないいつもと ちがう ときを きめる |