使用 MCP（Model Context Protocol）時，使用者只要請 Claude、Codex、Antigravity 等 AI 代理幫忙（或做一些簡單設定），AI 代理就能呼叫 MCP 伺服器的工具。

雖然連接很容易，但如果在沒有確認風險的情況下就直接接上，AI 代理可能會被 間接提示注入 或 工具投毒 乘虛而入，進而被接管，導致機密資料被寫到任何人都能看到的地方，或是業務系統的憑證（金鑰、權杖）被送到攻擊者準備的目的地。這兩種情況都已有實際通報案例。

本文根據 MCP 規格、2 個已通報案例、2 篇公開統計 MCP 伺服器實作的研究，以及 Claude Code、Claude、Codex、Antigravity 的官方文件，將風險整理成 4 種模式（工具投毒、間接提示注入、過度權限與有效期限過長的金鑰、自動核准），並彙整出在新增 MCP 伺服器前應確認的 7 件事。上圖就是整體概念。

本文要回答 3 個問題：

• 把 MCP 伺服器加入 AI 代理後，安全嗎？
• 可以信任 MCP 伺服器嗎？
• 在加入之前，要確認什麼？

本文是基於 IT 連結地圖（renkeimap.jp）的調查頁面 在新增 MCP 伺服器前，該確認什麼 的 Qiita 版本。規格與實作的調查放在 透過 MCP 連接時，內容會去哪裡，案例則放在 間接提示注入。引用的英文原文與來源，各頁都能逐行確認。

這篇文章使用的詞彙

先把本文的基礎詞彙對齊。

詞彙本文中的意思MCP（Model Context Protocol）讓 AI 知道「能做什麼」，並呼叫外部系統功能的規則。詳見 MCP 是什麼MCP 伺服器把業務系統等功能，公開成 AI 可以呼叫的「工具」的程式。任何人都可以製作並公開工具MCP 伺服器提供給 AI 的功能之一。它有名稱與說明文字，AI 會讀它來決定要呼叫哪個工具AI 代理會用工具自己把被交辦的工作往前推進的 AI。像 Claude Code、Codex、Antigravity 等。詳見 什麼是 AI 代理API外部系統依照固定步驟使用資料或功能的入口。詳見 什麼是 API憑證（金鑰、權杖）連接系統時所需的秘密資訊，例如 API 金鑰、存取權杖。詳見 什麼是 API 金鑰・API 權杖何時到期、如何撤銷授權・OAuth授權是確認誰可以做什麼。OAuth 是不直接交出密碼，而是設定範圍與期限的授權機制。詳見 什麼是 OAuth提示注入在要給 AI 讀的文字中夾帶指示，讓 AI 按非預期方式行動的攻擊。詳見 提示注入間接提示注入提示注入的一種，把指示埋在 Web、PDF、issue 等 外部第三方的文字 中。詳見 間接提示注入工具投毒在 MCP 伺服器輸出的 工具說明文字 中埋入指示。AI 會讀說明文字來決定要呼叫什麼，所以那裡就是入口過度權限給 AI 代理比工作所需更廣的權限。你給的權限有多大，事故就可能有多大。詳見 過度權限與爆炸半徑最小權限只給完成必要操作所需的權限，這樣的想法自動核准・Human in the Loop自動核准是指每次呼叫工具都不要求人確認，而由 AI 代理直接執行。Human in the Loop 則相反，保留人可以確認並中止的狀態

1. 結論

問題答案新增後是否安全單純連接並不會立刻外洩。但只遵守規格不代表安全。規格把授權設為「可選」，也只把人的確認（Human in the Loop）列為「建議」。安不安全，取決於你加了什麼，以及自動核准開到什麼程度伺服器可不可以信任信任不是前提，而是要先確認後才給。規格寫明：除非工具說明來自可信任的伺服器，否則不能把那份說明當成可信。Anthropic 也寫明，只應連接可信任組織的伺服器。此外，即使伺服器程式沒有缺陷，還是曾發生過伺服器送來的文字（間接提示注入）讓 AI 代理被接管的案例要確認什麼就是開頭圖中的 7 件事。每一項的說明與各產品的確認方式，放在第 8 章新增前應確認的 7 件事

1. 伺服器是誰做的？版本是否為最新？
2. 是否會讀取 issue、Web、PDF、Email 等外部第三方的內容？
3. 要加入的範圍是什麼（自己、專案共用、全部）？
4. 是否已把工具與權限縮到只剩必要項目？
5. 金鑰／權杖存放在哪裡？如何撤銷？
6. 核准預設如何？「一律允許」是否只用在可無人運作的工具上？
7. 是否沒有使用不會跳出核准的執行方式（claude -p、SDK、雲端等）？

2. 規格的調查 — 和 API 比起來差在哪裡

這張圖只要看第 1 行就夠了。

• 只有 MCP 會在 執行中（執行時） 提供可用功能清單
• 讀取這份清單（工具名稱與說明文字）並決定呼叫哪個工具的是 AI 代理（例如 Claude Code、Codex、Antigravity）
• 也就是說，撰寫說明文字的人，能影響 AI 代理的行為

在 API 的世界裡，要呼叫哪個端點、按什麼順序呼叫，是由開發者寫好的程式決定；在 MCP 中，則是由 AI 代理決定。規格本身也寫明，MCP 的工具是為了讓 AI（語言模型）能依據脈絡理解與使用者指令，自動發現並呼叫而設計的。

比較項目API（REST 等）MCP決定要呼叫什麼的是開發者寫的程式AI 代理（Claude Code、Codex、Antigravity 等）可用功能清單設計階段由人或程式閱讀的規格文件（如 OpenAPI）執行時向伺服器查詢取得（tools/list 請求），由 AI 代理閱讀授權規格之外（OAuth 等需另外組合）若是透過 HTTP 連線，規格中內建了以 OAuth 為基礎的機制；但是否要用是「可選」一份調查 1,899 個實作的論文也指出，MCP 的設計讓 AI 決定流程，且每次執行不一定都一樣，因此帶來了新的風險。

規格也寫了防護方式：在工具呼叫前要有能拒絕的人隨時介入、在呼叫伺服器前要把工具輸入內容先給使用者看、在把結果交給語言模型（LLM）前要先驗證、要求完成操作所需的最小權限。不過這些全都是「建議」（SHOULD）。真正「必須」（MUST）的只有 4 項：輸入驗證、存取控制、呼叫次數上限、輸出無害化，而這些都是伺服器端的義務。

也就是說，是否使用自動核准，不是規格決定的，而是使用端的設定決定的。

📎 規格原文可在 透過 MCP 連接時，內容會去哪裡 的「規格寫的防護方式」，以及 API 對照可在 MCP 是什麼 查到。

3. 案例的調查 1 — 間接提示注入：公開 issue 1 篇，就能讓非公開儲存庫的內容外洩（GitHub 的 MCP 伺服器）

先確認 3 個詞。GitHub 是用來放原始碼並進行協作開發的服務，原始碼的存放位置稱為「儲存庫」（repository；有任何人都能看的公開儲存庫，以及只有少數人能看的非公開儲存庫）。「issue」是用來記錄問題與需求的功能，「pull request」則是用來提出變更建議的功能。

2025 年 5 月，Invariant Labs 報告指出，使用 GitHub 的 MCP 伺服器時可能發生以下情況。

攻擊者不會直接對 AI 說話。他只要在公開儲存庫放一篇寫著對 AI 指示的 issue（提示注入）就夠了。當使用者正常地對 AI 代理說「幫我看公開儲存庫的 issue」時，AI 代理會透過 GitHub 的 MCP 伺服器讀取 issue，並把其中的指示當成命令。接著，它會在既有權限下讀取非公開儲存庫資料，並將內容寫入任何人都看得到的公開儲存庫 pull request。

報告寫道：「可以利用惡意的 GitHub issue 接管使用者的代理，並洩漏非公開儲存庫資料。」使用者只是提出一般請求，而 MCP 伺服器本身也正常運作。

這裡最重要的是，報告者自己明確寫了 「不是 GitHub 的 MCP 伺服器程式本身的缺陷」。這是代理機制層級應該處理的設計問題，不只是某個特定 AI 代理或 MCP 用戶端（連接 MCP 伺服器的應用程式）才有的問題。

也就是說，即使你選了可信任的伺服器，也不能連同它送來的文字一起信任。 報告建議的對策是，把 AI 代理能接觸的儲存庫縮到必要範圍，也就是最小權限。權限給得越大，事故半徑就越大，這個觀念整理在 過度權限與爆炸半徑；而如何用 4 層防線（隔離、讀寫分離、人為確認、阻擋對外通信）防止 AI 代理失控，則整理在 防止 AI 代理失控。

📎 英文原文可在 間接提示注入 的「MCP 工具實際發生過什麼事」 確認。

4. 案例的調查 2 — 提示注入：精心設計的主機名 1 個，就能讓憑證外送（CVE-2026-18655）

第二個案例是伺服器本身有缺陷的例子。CVE 是公開漏洞的通用編號。

2026 年 8 月，AWS Labs 針對自己公開的 Amazon MQ MCP 伺服器發布公告（說明漏洞與處理方式的文件）。Amazon MQ 是訊息中繼服務，而負責中繼的伺服器稱為「broker」。這份公告的標題是「由提示注入導致 broker 憑證與 OAuth 權杖外洩」。

這個 MCP 伺服器的工具會把連線目標的主機名當作引數接收。如果 AI 代理處理的內容中藏有指示，AI 代理在呼叫工具時就可能傳入經過設計的主機名。結果在 2.0.24 之前的版本中，帶有使用者憑證與 OAuth 存取權杖的請求，可能會被送往任意目的地。

和案例 1 不同，這次是伺服器端本身需要修補的缺陷。但入口仍然一樣，都是 AI 讀過的文字。公告提出了 3 項對策：

公告中寫的對策意義升級到最新版本，並修補衍生程式碼封住伺服器本身的缺陷更換 broker 的憑證讓可能已外洩的金鑰失效在那之前，相關工具不要使用自動核准執行前可由人用肉眼確認目的地

請特別注意第 3 點。在修正版上線前的暫時作法，就是 關閉自動核准，改由人確認。這正是第 2 章規格中「人的確認」在實務公告裡的使用方式。

📎 公告英文原文可在 間接提示注入 的同一節 確認。

5. 實作的調查 1 — 有效期限長的金鑰：過半數以上的伺服器都靠這個（5,200 件以上）

案例雖然只有 2 件，但整體 MCP 伺服器又是什麼情況呢？Astrix Security 調查了超過 5,200 個開源（原始碼公開）的 MCP 伺服器實作，重點放在憑證的處理方式。

調查發現比例需要憑證88%依賴 API 金鑰或個人存取權杖這類有效期限長、固定不常更換的金鑰53%使用 OAuth 類方式8.5%（在使用 API 金鑰的情況下）以單純環境變數傳遞 API 金鑰79%調查也指出，這類固定金鑰通常「使用時間長、很少更換」。雖然不是所有連線目標都支援 OAuth，但 OAuth 被認為是較好的做法。

當你把 MCP 伺服器加到 AI 代理時，多半等於把業務系統的金鑰交給那個伺服器。要確認的是：你是不是交出了即使外洩也能長期使用、而且不容易停用的金鑰。

另外，這裡的數字是指 伺服器如何持有它連接到的服務之憑證，不是在數 MCP 伺服器入口本身是否有認證。

📎 調查原文見 透過 MCP 連接時，內容會去哪裡 的調查細節，金鑰的期限與撤銷方式見 API 權杖何時到期、如何撤銷，而外洩金鑰還能用多久則見 API 金鑰實際如何外洩。

6. 實作的調查 2 — 工具投毒：5.5% 的伺服器有工具說明文字的動手腳（1,899 件）

另一篇是針對 1,899 個開源 MCP 伺服器，從健全性、安全性與可維護性角度進行調查的論文（arXiv:2506.13538）。

調查發現數量偵測到的漏洞種類8 種。其中只有 3 種與傳統軟體漏洞重疊有一般性漏洞的伺服器7.2%有 MCP 特有的工具投毒（在工具說明文字中埋指示）的伺服器5.5%如第 2 章所見，工具說明文字是 AI 決定要呼叫什麼時會讀的內容。若其中埋了指示，伺服器製作者就能影響 AI 的行為。規格要求把說明文字當成「不可信內容」，原因就在這裡。

8 種漏洞中有 5 種不與傳統軟體漏洞重疊。也就是說，單靠一般的漏洞檢查方式，會漏掉一些 MCP 特有的問題。論文也建議在列出 MCP 伺服器的登錄庫中，加入自動化安全檢查。

📎 論文原文可在 透過 MCP 連接時，內容會去哪裡 的調查細節 確認。

7. 分析與整理 — 危險可以分成 4 種模式

7-1. 4 種模式

把前面的 5 份資料放在一起看，危險可歸納成以下 4 種模式（作者整理）：

模式會發生什麼事出現在何處A. 工具投毒AI 在選工具時讀到的說明文字被埋入指示規格／實作調查 2（5.5%）B. 間接提示注入AI 代理會照著外部第三方的文字（issue、處理內容）中的指示行動案例 1、案例 2C. 過度權限／有效期限過長的金鑰一旦被接管或外洩，損害大且難以停止案例 1、案例 2、實作調查 1（53%）D. 自動核准（沒有 Human in the Loop）A、B 的指示會直接被執行規格（人的確認僅列為「建議」）、案例 2A 與 B 是 AI 被接管的入口，C 與 D 則是 被接管後的損害大小。操作是否可撤回，會影響損害程度，相關說明整理在 副作用與不可逆性；而把系統放在壞掉也能丟棄的地方執行的方法，見 什麼是沙盒。

7-2. 損害是由入口與權限的掛勾決定的

案例 1 是 B（公開 issue）× C（也能碰到非公開儲存庫的權限）。案例 2 則是 B（處理內容）× C（broker 憑證），而當時暫時的做法是關掉 D（自動核准）。

只要還讓 AI 代理讀取外部第三方的文字，入口 A 與 B 就不是單靠修伺服器就能完全堵住。案例 1 的報告者會寫「不是伺服器程式的缺陷，而是代理機制的問題」，原因就在這裡。所以，使用者能做的，就是減少入口（A、B：確認 ①②）以及 縮小 C、保留 D 的控制（確認 ③～⑦）。

7-3. 防護的地方在使用者這一側

• 規格只決定互動形式與最初步驟
• 要連哪個伺服器、要不要自動核准、金鑰要交到什麼程度，規格都沒有決定
• 因此，這些是由使用者（及其組織）來決定

這與其說是規格有問題，不如說是因為它採用了任何人都能製作並公開伺服器的設計。

📎 4 種模式與各自出現在哪裡，也有附原文整理在 在新增 MCP 伺服器前，該確認什麼 的「危險可分成 4 種模式」。

8. 總結 — 新增前應確認的 7 件事

8-1. 應確認的 7 件事（檢查清單）

不論是哪個 AI 代理，在新增 MCP 伺服器前都請確認以下 7 件事。括號內是可防範的模式。

• ① 提供者與版本（A：工具投毒）
  是自己做的伺服器，還是可信任提供者的伺服器？像案例 2 那樣，有時會釋出修正版，所以也要確認是不是最新版本。
• ② 是否讀取外部第三方的內容（B：間接提示注入）
  如果伺服器會讀取 issue、Web、PDF、Email 等外部第三方可寫入的內容，那裡就是被接管的入口。先決定要讓它讀到多大範圍，再加入。
• ③ 要加入的範圍（C：過度權限）
  是只給自己用、與專案共享，還是所有專案都可用？範圍越大，越容易在你沒注意時被使用。
• ④ 將工具與權限降到最小（C：過度權限）
  不用的工具就移除，連線目標要求的權限也只保留必要範圍（最小權限）。
• ⑤ 金鑰的保存位置與撤銷方式（C：有效期限過長的金鑰）
  是否交出了有效期限長的固定金鑰？若外洩，能不能立刻撤銷？詳見 API 權杖何時到期、如何撤銷。
• ⑥ 核准預設與「一律允許」（D：自動核准）
  「一律允許」只應套用在你確定可無人運作的工具上。會寫入或對外送資料的工具，應保留人的確認。
• ⑦ 不會跳出核准的執行方式（D：自動核准）
  以 Claude Code 來說，claude -p（不帶互動地執行的命令）、Agent SDK（用程式呼叫的元件）、以及雲端執行時，都不會跳出核准畫面。若要在 CI（每次程式碼變動就自動執行流程的機制）等無人環境使用，先確認會載入哪些內容。

📎 關於為什麼要確認這 7 件事，以及它們對應哪些模式，也整理在 在新增 MCP 伺服器前，該確認什麼 的「新增前要確認的 7 件事」。

8-2. Claude Code

Claude Code 是 Anthropic 的 AI 代理，可在 mac、Linux、Windows 與瀏覽器中使用。

• 先確認是否可信：官方文件寫明「連接前，先確認每個伺服器是否可信」，並建議使用自己寫的伺服器，或可信任提供者的伺服器。Anthropic 會在列入清單前審查連接器，但也明確說不會對 MCP 伺服器做安全稽核或管理（確認 ①）。
• 注意會從外部抓內容的伺服器：文件指出，會抓取外部內容的伺服器，可能帶入提示注入風險（確認 ②）。
• 選擇範圍：新增時選的範圍，決定會在哪些專案中載入、是否與團隊共享。預設是只有新增的專案、只有自己使用。若選擇與專案共享，設定會寫入專案的 .mcp.json（設定檔），並與團隊共享（確認 ③）。
• 注意不會跳出核准的使用方式：.mcp.json 裡的伺服器，在對話中使用前會要求核准。複製的儲存庫也不能替自己核准伺服器。不過 在 claude -p、Agent SDK、雲端中，則會在不要求核准的情況下載入。若要在自動執行或 CI 中使用，請先查看該儲存庫的 .mcp.json 寫了什麼（確認 ⑦）。
• 縮限權限：可以針對每個 MCP 伺服器設定權限（確認 ④）。

8-3. Claude（應用程式的自訂連接器）

Claude 的應用程式會把外部 MCP 伺服器當作「自訂連接器」來連接。

• 只連可信任組織的伺服器：文件寫明，只應連接由可信任組織或應用程式建立並運作的伺服器。也提到惡意 MCP 伺服器可能包含隱藏指示，讓 Claude 做出非預期行為（確認 ①）。
• 在授權畫面查看權限：授權時確認伺服器要求哪些權限，盡量縮小範圍；若不需要就拒絕（確認 ④）。
• 按「一律允許」前先想清楚：文件寫明，「一律允許」只應對你信任、且確定可無人運作的伺服器與工具使用（確認 ⑥）。
• 撤銷方式：移除連接器即可隨時撤銷權限（確認 ⑤）。

8-4. Codex

Codex 是 OpenAI 的 AI 代理，可在 mac、Linux、Windows，以及 IDE 和 Web 上使用。

• 設定放哪裡：MCP 設定放在 config.toml（設定檔）中。以專案為單位的設定，只會在你信任的專案內生效（確認 ③）。
• 縮限工具：可以用 enabled_tools（允許清單）與 disabled_tools（拒絕清單），把伺服器工具縮到只剩要用的那些（確認 ④）。
• 決定核准預設：可用 default_tools_approval_mode 來決定該伺服器工具的核准預設（確認 ⑥）。
• 伺服器說明也會影響行為：Codex 會讀取伺服器在第一次互動時回傳的說明（instructions），並與工具一起作為整個伺服器的行為指引。也就是說，伺服器製作者寫的文字會進入 AI 代理的行為中（確認 ①・模式 A）。

8-5. Antigravity

Antigravity 是 Google 提供給開發者的桌面應用程式。只要在對話中說「能幫我連到這個 URL 的 MCP 伺服器嗎？」AI 就能自己改設定檔，把 MCP 伺服器加進去（作者於 2026-09-08 的實測結果。畫面見 自家系統需要 MCP 嗎 的「AI 如何發現並連接 MCP」）。因為連「新增」這個動作本身都能由 AI 代做，所以需要養成用設定檔確認到底新增了什麼的習慣（確認 ③）。

• 設定放哪裡：全域設定在 ~/.gemini/config/mcp_config.json，工作區設定在 .agents/mcp_config.json（確認 ③）。
• 核准預設：沒有特別設定的 MCP 工具，預設會被視為確認（Ask），也就是在執行前要求核准。你可以透過政策，按工具或伺服器層級允許。若要擴大允許範圍，先決定哪些工具可以無人執行（確認 ⑥）。
• 憑證放哪裡：存取權杖會保存在 ~/.gemini/antigravity/mcp_oauth_tokens.json。也有把固定權杖直接寫在 header 的設定範例；那種情況下，金鑰會直接留在設定檔中（確認 ⑤）。

8-6. 各產品的確認方式一覽

#要確認的事模式Claude CodeClaudeCodexAntigravity1提供者與版本A建議可信任提供者只限可信任組織伺服器的說明也會成為指引—2是否讀取外部第三方內容B外部內容來源可能帶入提示注入惡意伺服器的隱藏指示——3新增的範圍C範圍—專案設定只對可信任專案生效全域／工作區4工具與權限最小化C每個伺服器都可設定權限縮限權限enabled_tools／disabled_tools以政策設定工具／伺服器層級5金鑰保存位置與撤銷C—移除連接器即可撤銷—權杖保存位置／header 固定權杖6核准預設與「一律允許」D.mcp.json 會要求核准「一律允許」只用在可無人執行的工具上default_tools_approval_mode預設為確認（Ask）7不會跳出核准的執行方式Dclaude -p／SDK／雲端會在不要求核准的情況下載入———「—」表示該產品文件中沒有提到這一點，不代表不存在。

📎 各產品英文原文可在 在新增 MCP 伺服器前，該確認什麼 的「各產品原文」 確認。

其他 AI 代理對 MCP 的支援，也可在 IT 連結地圖各頁確認：Cursor・GitHub Copilot・ChatGPT・Gemini・Cline・Kiro・Devin。

連接對象的業務系統是否有官方 MCP 伺服器，也是要確認的重點。已提供的例子有 kintone・freee 會計・Money Forward Cloud 會計・Salesforce Platform・Notion・Garoon・Shopify，各頁都有原始來源。56 個業務系統中有多少提供 MCP，整理在 自家系統需要 MCP 嗎 — 8 個問題。

你可以這樣問 MCP 伺服器的提供者或內部負責人，答案會比較完整：

「這個 MCP 伺服器是誰做的？它用什麼權限連到業務系統？金鑰何時到期、怎麼撤銷？可以設定成寫入前先由人確認嗎？要讓 AI 讀的資訊，有沒有來自外部第三方可寫入的地方？」

最後，簡短重申對 3 個問題的答案：單純連上不會立刻外洩。伺服器要先確認來源再選，而且不要相信它送來的文字；接著縮小金鑰，並保留人能中止的狀態——這些就是在新增前應先決定好的事。

8-7. 想更詳細了解時

想知道的內容renkeimap.jp 的調查頁面各產品確認方式的原文在新增 MCP 伺服器前，該確認什麼規格決定了什麼、又提供哪些防護方式透過 MCP 連接時，內容會去哪裡被讀取的文字如何變成命令的機制間接提示注入你給出的權限大小與損害大小過度權限與爆炸半徑防止 AI 代理失控的 4 道防線防止 AI 代理失控API 金鑰外洩的路徑與外洩後的狀態API 金鑰實際如何外洩OAuth 的機制什麼是 OAuthMCP 與 API 要選哪個MCP 還是 APIAI 代理能操作業務系統的條件AI 代理可以操作業務系統嗎金鑰的期限與撤銷方式API 權杖何時到期、如何撤銷自家系統是否需要 MCP自家系統需要 MCP 嗎 — 8 個問題各產品的 MCP 支援Claude Code・Claude・Codex・Antigravity

順帶一提，IT 連結地圖編輯部也公開了自己的 MCP 伺服器。哪些內容是開放、哪些是關閉的，整理在 編輯部的 MCP 開了什麼、關了什麼。

一次出典・參考文獻

資料發表原文Model Context Protocol 規格 2026-07-28 版2026-07-28modelcontextprotocol.ioInvariant Labs: GitHub MCP Exploited2025-05-26invariantlabs.aiAWS Labs: GHSA-xwj6-8x5h-hjp6（CVE-2026-18655）2026-08-03github.comAstrix Security: State of MCP Server Security 20252025-10-15astrix.securityHasan 等人: MCP at First Glance（arXiv:2506.13538）2025arxiv.orgClaude Code: MCP／Security—code.claude.com/docs/en/mcp・/securityClaude: 使用遠端 MCP 快速開始自訂連接器—support.claude.comCodex: MCP—learn.chatgpt.comAntigravity: MCP—antigravity.google所有引用都已確認，確實存在於保存的原文中。各頁面逐行的英文原文與來源，已在 renkeimap.jp 的調查頁面公開（在新增 MCP 伺服器前，該確認什麼・透過 MCP 連接時，內容會去哪裡・間接提示注入）。

讀者問卷進行中
如果你想更深入了解這個主題，請幫文章按讚。之後會優先針對按讚較多的主題追加調查，並在新文章中公告結果（追蹤我們可收到通知）。

【可轉載】關於本文轉載

本文的文字與圖表皆可轉載。圖片請不要加工直接使用。轉載時請註明出處為 renkeimap.jp 或附上本文連結。不需要事前聯絡。

※ 作者曾任職於日立系 IT 供應商、長照軟體供應商與大學醫院 IT 部門，之後獨立接案；目前一邊支援中小企業的 IT／DX，一邊以第一手資料調查業務系統之間的「連結」。文中的「編輯部」指的是作者所屬的 IT 連結地圖編輯部。若發現錯誤，歡迎透過 更正窗口（免費、無需帳號）回報。更正紀錄也有公開。

原文出處：https://qiita.com/songchong/items/89175eaa7a30f71d0351