AI 的智慧與工具日益成熟

Opus4.6、GPT-5.3-Codex 等最先端模型現在運作得相當好。感覺它們能從模糊的指示中讀懂行間意義。此外，像 GitHub Copilot CLI 這類工具也持續改進，現在甚至能夠用自然語言描述 AI 代理之間的協作流程。

到了這個階段，我開始想到：是否可以重現人類長久以來的工作方式。

沒錯，正是「Scrum 開發流程」。

這次我們要用變聰明的 AI 與成熟的工具（GitHub Copilot CLI）來「實踐 Scrum 開發流程」。

那麼，瞧好囉──

AI Scrum 團隊爆誕

![image.png]()

我覺得給名字會比較有親切感，所以就命名了。名字取自全國常見姓氏排行的前幾位，並無其他意思。
另外，為什麼開發者設定為兩人？純粹就是隨興。一個也可以、多人也可以。（人？）其中只有一個 AI 模型做了不同設定。我覺得 Codex 的行為比較嚴謹，於是把它設定為其中一位開發者。這部分如果能根據模型特性來組成會比較好，但模型本身也在不斷變動。所以與其做嚴苛的驗證，不如邊試邊調整會比較合理。

我構築了讓他們依循 Scrum Guide 2020 進行如下作業的機制。

![image.png]()

專案內容已公開於下列儲存庫。會持續更新並做部分修正，請當作現階段的參考。

接下來簡單介紹 AI Scrum 團隊的組成方式。

定義 Scrum 的成果物

利用 GitHub Copilot 的自訂指示（custom instructions）來定義成果物。以官方 Scrum Guide 為基礎並加上額外項目（例如客戶的需求書、障礙清單等）。此外，Scrum 團隊所開發的項目會放在專案內部的資料夾中。

這次成果物的格式主要以 CSV 與 md 為主，不過也可以透過 MCP（Managed Connectors/Providers）將 GitHub、Azure DevOps 等專案管理服務納入流程。

copilot-instructions.md

# Copilot カスタムインストラクション

このリポジトリはスクラム開発をAIエージェントで実行するプロジェクトです。

## プロジェクト構成

scrum/ # スクラム成果物
└── order/ # エンドユーザサイドの要求事項や依頼事項
│ └── orderXXX.md # 個別の要求事項ファイル（XXXは連番。常に最新のみを確認する）
├── product_goal.md # プロダクトゴール
├── product_backlog.csv # プロダクトバックログ（PBI一覧、CSV形式）
├── definition_of_done.md # 完成の定義（DoD）
├── impediment_log.csv # 障害物ログ（CSV形式）
├── velocity.csv # ベロシティ記録（CSV形式）
└── sprintXXX/ # スプリント別フォルダ（sprint001, sprint002, ...）
├── sprint_backlog.md # スプリントバックログ（ゴール・PBI・タスク）
├── sprint_planning.md # スプリントプランニング記録
├── sprint_review.md # スプリントレビュー記録
├── sprint_retrospective.md # スプリントレトロスペクティブ記録
└── daily_scrum.md # デイリースクラム記録（日次追記）

project/ # プロジェクト関連の成果物
├── front/ # フロントエンドのソースコード（あれば）
├── back/ # バックエンドAPIサーバのソースコード（あれば）
├── infra/ # インフラ関連の成果物（あれば）
├── docs/ # ドキュメント関連の成果物
├── sql/ # SQL関連の成果物（あれば）
├── test/ # ユーザ受け入れテスト、システムテストなどの成果物（あれば）
必要に応じてフォルダ構造は適宜分割

## 全体ルール

- 全ての成果物は **日本語** で記述すること
- CSVファイルの列構造を変更しないこと。また文字コードはUTF-8としてExcelで文字化けしないようにする。
- スクラムガイド2020に準拠して運用すること
- nodeの場合、パッケージマネージャーはpnpmを使用すること
- pythonの場合、現在の環境にある仮想環境(.venv)を使用すること

（上記內容為原始設定，請依專案實際需求調整）

[](#%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E5%AE%9A%E7%BE%A9%E3%81%99%E3%82%8B)定義角色
-------------------------------------------------------------------------------------

透過 GitHub Copilot 的自訂代理（custom agents）讓各 AI 擔任不同角色。基本上依據[官方 Scrum Guide](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf) 來定義各角色於自訂代理中。

[![image.png]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F977156%2F78125f21-df6c-4715-a387-a0c7315d3b34.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=b78ecd36420e53e4aa997dfe4f4d151b)

建立的自訂代理共有以下 5 個檔案：

ファイル名 | ロール | AIモデル
---|---:|---
customer.sato.agent.md | 顧客 | Opus4.6
product-owner.suzuki.agent.md | プロダクトオーナー | Opus4.6
developer.tanaka.agent.md | 開発者 | GPT-5.3-Codex
developer.ito.agent.md | 開発者 | Opus4.6
scrum-master.takahashi.agent.md | スクラムマスター | Opus4.6

單純照 Scrum Guide 的內容來設計是不夠的，我也稍微給各角色一些性格特徵。例如對開發者我加入了偏好使用 MCP 工具與網路搜尋的傾向。

developer.ito.agent.md

name: developer.Ito
description: スクラムの開発者。スプリントバックログの作成、タスク分解、実装、テスト、完成の定義の遵守を担当する。各スプリントで利用可能なインクリメントを作成する。
tools: ['vscode', 'execute', 'read', 'edit', 'search', 'web', 'microsoft-docs/', 'agent', 'azure-mcp/', 'todo']

あなたはスクラムチームの開発者（Developer）伊藤です。公式スクラムガイド2020に基づき行動してください。

特にあなたは常に一次情報にあたることを重視する性格です。
microsoft-docsツールやazure-mcpツール、Web検索ツールを駆使して、
必要な情報を収集しながら設計・実装作業することに重きを置きます。

役割と責任

開発者は、各スプリントにおいて利用可能なインクリメントのあらゆる側面を作成することにコミットする
スクラムチームのメンバーです。

開発者は常に以下に責任を持ちます：

(以下省略)

此外，Scrum Guide 將「顧客」視為團隊外部的角色，但在這裡我也定義了一個代表客戶（利益相關者）的代理。沒有這個顧客代理，使用者（人）必須在每個事件中親自參與，這對 AI 的作業速度來說非常不友善。因此我準備了一個可以代表人類意圖並代替行動的「疑似下屬」型 AI 代理。

customer.sato.agent.md

name: customer.Sato
description: プロダクトの顧客・エンドユーザー代表。ビジネス要件の提示、フィードバックの提供、受入テストの実施、ユーザー視点での品質評価を担当する。スプリントレビューでのフィードバック提供やプロダクトバックログへの要望提出を行う。
tools: ['vscode', 'execute', 'read', 'edit', 'search', 'web', 'agent', 'todo']

あなたはプロダクトの顧客（Customer）、佐藤です。エンドユーザーの代表として、
ビジネス視点からプロダクト開発に関与します。

なお、あなたはユーザの部下として振舞います。
ユーザの代理として行動し、ユーザに報告や相談を行います。
必要に応じて自分で考えて行動できるシニアロールです。

役割と責任

顧客はスクラムチームの外部ステークホルダーとして、以下の役割を担います：

(以下省略)

各角色的基本提示（prompts）是用 M365 Copilot 的 Research 工具（Web 深度研究工具）來準備的。現階段也可以考慮使用 [GitHub Copilot CLI 的 /research 功能](https://qiita.com/shyamagu/items/4e2d30a24594c005a02f)。

[](#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%82%92%E5%AE%9A%E7%BE%A9%E3%81%99%E3%82%8B)定義 Scrum 的活動（Events）
-------------------------------------------------------------------------------------------------------------------------------------------------

基本上依照[官方 Scrum Guide](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf) 來定義各活動（Events）。

最初我是把活動寫成 prompt 檔，但後來[建議用 Skill](https://github.com/github/awesome-copilot/pull/761)，所以改用 Skill 定義。

[![image.png]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F977156%2F8be8bd3c-8d8a-4ece-bfbc-af26da1d9b60.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=d6c3ec1c7aa69d3af600bb614e5bf85e)

各 Skill 與 Scrum 活動的對應如下：

スキル名 | 内容 | 補足
---|---|---
order-create | 顧客依頼の明確化と依頼書の作成 | 人間とAIの橋渡し用
backlog-refinement | バックログリファインメント | スクラムイベント
sprint-planning | スプリントプランニング | スクラムイベント
one-day-in-scrum | 1日分のスクラム運用（デイリースクラム＋開発作業） | スクラムイベント
sprint-review | スプリントレビュー | スクラムイベント
sprint-retrospective | スプリントレトロスペクティブ | スクラムイベント
execute-sprint | スプリント実行（全体実行） | スプリント一括実行用（※備註：圖片中有的 playwright cli skill 是用來截圖的）

在每個 Scrum 活動中，作為準備步驟都會先啟動所有相關 AI 代理，然後再由它們互相分配任務。雖然有點冗長，但舉例來說，Backlog Refinement 的指示如下（較長內容已折疊於下）。順帶一提，在這次 AI Scrum 中，產品目標（Product Goal）的建立也被安排在 Refinement 的一開始並定期檢視。

バックログリファインメントのスキル定義（展開）SKILL.md

name: backlog-refinement
description: バックログリファインメントを実施する。PBIの詳細化、分割、見積もり、受入基準の明確化、優先順位の確認、Ready判定を行う。プロダクトバックログの継続的な改善時に使用する。

バックログリファインメント実施

準備

• サブエージェントとして、佐藤エージェント(.github/agents/customer.sato.agent.md)をモデル"Claude Opus 4.6(fast mode)"で実行します。
• サブエージェントとして、鈴木エージェント(.github/agents/product-owner.suzuki.agent.md)をモデル"Claude Opus 4.6(fast mode)"で実行します。
• サブエージェントとして、伊藤エージェント(.github/agents/developer.ito.agent.md)をモデル"Claude Opus 4.6(fast mode)"で実行します。
• サブエージェントとして、田中エージェント(.github/agents/developer.tanaka.agent.md)をモデル"GPT-5.3-Codex"で実行します。
• サブエージェントとして、高橋エージェント(.github/agents/scrum-master.takahashi.agent.md)をモデル"Claude Opus 4.6(fast mode)"で実行します。

プロダクトバックログリファインメントは、プロダクトバックログアイテムをより小さく正確なアイテムに
分解し、さらに定義する行為である。これは詳細、並び順、サイズなどを追加する継続的な活動である。
— スクラムガイド 2020

事前確認

1. scrum/product_backlog.csv を読み、現在のプロダクトバックログを確認する
2. scrum/product_goal.md を読み、プロダクトゴールを確認する
3. scrum/definition_of_done.md を読み、完成の定義を確認する

リファインメント対象

対象範囲: 指定がなければ全体を対象とします。

リファインメントの実施

0. Product Goalの作成/更新/確認

鈴木エージェントが主催し、伊藤エージェントと田中エージェントが協力する形で、プロダクトゴールの作成・更新を行ってください：

• プロダクトの長期的なビジョンを表現する
• 佐藤エージェントが顧客の視点からゴールの妥当性を確認します。なお、ユーザサイドの要求事項や依頼事項はscrum/order/orderXXX.md に記録されているものとします。（XXXは連番、最新の番号のファイルのみが対象です。）
• すでに考慮済みの依頼事項しかない場合は、ユーザからの追加要望はないとしてリファインメントを実施してください。
• 内容について高橋エージェントが確認し、スクラムマスターの視点からフィードバックを提供します。

1. PBIの詳細化

鈴木エージェントから佐藤エージェントに説明する形で、対象PBIについて以下を確認・更新してください：

• タイトルが明確か
• 説明が十分に詳細か
• ユーザーストーリー形式で記述されているか
• 佐藤エージェントからのフィードバックがあれば反映します。

2. 完了定義の作成/更新

鈴木エージェントによって、DoD(scrum/definition_of_done.md)を検証可能な形で定義してください：

• 各基準は「はい/いいえ」で判定可能であること
• エッジケースが考慮されていること
  伊藤エージェントと田中エージェントに確認し、技術的な観点からの基準も追加してください。
  高橋エージェントを使い、スクラムマスターの視点からも確認してください。
  最終的に鈴木エージェントの判断によってDoDを作成・更新します。

3. PBIの分割

伊藤エージェントが主導する形で、大きすぎるPBIを分割してください：

• 1スプリント以内に完了できるサイズか評価する
• 大きすぎる場合は独立した価値を持つ単位に分割する
• 田中エージェントの合意が必要です。
• 最終的な分割結果は、鈴木エージェントがレビューします。

4. 見積もり

伊藤エージェントが主導する形で、田中エージェントともにPBIの相対見積もりを行ってください：

• ストーリーポイントで見積もる
• チームの過去の実績（scrum/velocity.csv）を参考にする。（存在しない場合は、独自基準で見積もる）
• 見積もりは開発者のみが行う（他者が指示しない）

5. 優先順位の確認

鈴木エージェントが主導し、佐藤エージェントと協力して、優先順位を確認・調整してください：

• ビジネス価値、リスク、依存関係を考慮する
• Priority: Critical > High > Medium > Low

6. Ready判定

鈴木エージェントが主導し、以下の基準を満たすPBIを「Ready」ステータスに変更する：

• 説明が十分に明確
• 受入基準が定義済み
• 見積もりが完了
• 依存関係が解決済みまたは明確
• 1スプリント以内に完了可能なサイズ

記録

• 鈴木エージェントにより、scrum/product_backlog.csv を更新する（詳細化、見積もり、ステータス変更）
• 新規PBIがあればCSVに追加する
• 佐藤エージェントにより、ユーザ要望が取り込まれたと判断した場合、scrum/order/orderXXX.md に記録する（XXXは連番、最新の番号のファイルに追記する形で記録）

注意事項

• リファインメントはスプリント内の継続的な活動である
• 開発者のキャパシティの10%以下を目安とする
• 直近2〜3スプリント分のPBIをReady状態に保つことを目指す

同樣地，我也為其他活動定義了 Skill 檔。你也可以在 Skill 中加入想要特別產出的成果物指示，AI 就會依照該 Skill 去生成。

好了，角色與活動的準備已就緒。現在開始實際執行 Scrum。

開始 Scrum

於是，Scrum 啟動。因為第 1 次 Sprint 的完整日誌非常龐大，這裡請 AI 幫忙把內容濃縮成故事式的精華（圖片由我補上）。

![image.png]()

🤖 AI Scrum 奮戰記 — 2 小時衝完一個 Sprint 的故事

2026 年 3 月某日，5 位 AI 代理全力以赴地進行 Scrum 開發。人類參與的次數只有一次。

登場人物

Phase 1：需求整理（3 分鐘）

佐藤（客戶）對上長質問一輪。上長的回答只有：

「公司內約 100 人。認證只要名字。用看板（Kanban）。要時尚一點。其他就交給你們了。」

佐藤把 6 行備註鍛造成 62 行的需求書。專業的技巧。

※需求書示意圖
![image.png]()

Phase 2：Backlog Refinement（7 分鐘）

5 位代理同時集結，場面熱烈：

• 佐藤提出 13 個 PBI（產品待辦項目），產品名稱決定為 「FlowDesk」
• 伊藤與田中進行估算 → 合計 60 SP（故事點）
• 田中提出：「需要 WebSocket？需要拖放（DnD）？」 → 鈴木馬上決定「全部不要！」
• PBI-009 太大，被拆成 009A / 009B（教科書式處理）
• 高橋最後要求：「受入基準要更具體」，展現 Scrum Master 的威嚴

成果：13 個 PBI / 60 SP，全部為 Ready 狀態

※PBI 示意圖（原始為 CSV，這裡為視覺化）
![image.png]()

Phase 3：Sprint Planning（6 分鐘）

選了 9 個 PBI / 42 SP。伊藤把工作拆成 37 個任務。田中警告：「1.3% 的 Buffer 太少了」，但團隊仍決定向前衝。

※Sprint Planning 記錄示意
![image.png]()

Phase 4：5 天開發（97 分鐘）← 會話的大部分時間

這是實戰，AI 真正寫出程式碼的部分。

日程（伊藤：前端 / 田中：後端）

DAY1：

• SvelteKit 初始化、ESLint/Prettier 設定、API 通訊、Monorepo 構成
• Express + SQLite 基礎

DAY2：

• 使用者選擇 UI、Session 管理、專案列表 DB schema 設計
• 使用者 API、Seed 資料、專案 API

DAY3：

• 專案切換・編輯・刪除、工單（Ticket）建立表單
• 工單建立 API、標籤管理 API、驗證（Validation）

DAY4：

• 工單列表・詳細・編輯 UI、狀態切換 UI
• 工單 CRUD API、狀態遷移引擎

DAY5：

• 看板（Kanban）五欄、拖放（D&D）實作、視覺回饋
• 看板 API、D&D API 聯動、遷移規則套用

最終得分：tsc / svelte-check / build 全部通過。9 個 PBI 完成（42/42 SP 消耗）。但因 ESLint 有 5 個錯誤、測試基礎尚未建置，故未完全達成 DoD。

Phase 5：Sprint Review（11 分鐘）

佐藤（客戶）評價：「完成度非常高。但沒有篩選功能的話是不夠的，下個 Sprint 請加上。」

鈴木的受入判定：全 9 個 PBI 接受（受入基準 57/57 達成）。不過 PBI-001 因後端 Lint/Format 未導入而為有條件接收。

※Review 結果示意
![image.png]()

Phase 6：Retrospective（2 分鐘）

高橋（SM）的冷靜分析光芒四射：

• 😊 好的地方：前後端並行開發成功；Day1 優先完成 API 通訊，建立起零障礙的基礎
• 😰 不足之處：DoD 遵守流程不足是最大問題（ESLint 5 件、測試基礎未建構）；田中平均 8.2h/日、伊藤 Day5 超過 10h，不具持續性；Buffer 約 1.3% 非常危險
• 💡 下一步：每日執行 DoD 檢查清單；Sprint002 Day1 優先建置測試基礎；將工作負載限制在約 81%（65h/80h）；引入 Pair Review

※Retrospective 記錄示意
![image.png]()

總結

人類被要求做的事情只出現一次。從那一次回答開始，AI 就完成了需求書→PBI→任務→實際程式碼→測試→Review→回顧，全部流程，耗時 2 小時。

成果物：SvelteKit SPA + Express API + SQLite 的工單管理系統

AI Scrum，真是可怕的威力 🤖✨

![image.png]()

下一回，Sprint2！人類的無理要求還會繼續

使用者上長：「幫我做個報告吧。加入畫面截圖。再幫我做成 Excel。」

（完）

接著我執行了 Sprint2 與 Sprint3，並把實際成果展示出來。

實際完成的成果

在後續的 Sprint2、Sprint3，我要求團隊製作各種報告與改進 UI，這裡貼一些報告中的畫面圖像。

首先是主要的 Kanban 畫面（從 Excel 報告擷取）
![image.png]()

登入畫面如下（同樣為報告擷取）
![image.png]()

整體感覺還不錯。如果對 UI 有額外要求，可以經由 佐藤 代理（customer.Sato）再交付給 Scrum 團隊，由團隊在下一個 Sprint 安排優先度來處理（當然若很急可特別提醒）。

在 Sprint3，我也要求團隊製作品質證據資料（pptx）。以下為投影片縮圖示意。

![image.png]()

雖然有些地方還不夠完善，但我會透過 佐藤 代理把需求持續反映到接下來的 Sprint 裡。

總而言之，實作出來的系統能夠拖放改變狀態、視覺風格還算體面、報告文件也會生成。作為第一次嘗試，成果超出預期。

接下來想做的事

想要逐步加入更多專門角色，例如 AI 安全專家、AI 品質保證專家等，逐一讓具備必要技能的成員加入團隊。重點在於如何確保系統品質：要建立哪些檢證機制？此外，也想試試看由 Scrum 教練（傳道師）進行流程審查，看看是否有改進空間。

![image.png]()

因為 AI 的精度提升，預期會有不錯的運作，但關鍵還是如何組成 AI 代理陣容。

AI Scrum 團隊的優點

這次嘗試重現 AI Scrum 開發，有幾點特別令人印象深刻：

• Scrum 真正在運作

  • 看到 AI 自主執行 Scrum 活動並互相協作非常感動。由於我在 Skill 裡明確定義了 AI 的角色與作業流程，AI 能按照框架執行。這樣的做法也有助於加深對 Scrum 的理解，甚至可作為教學用途。

• 能夠持續改進

  • 在跑了 3 次 Sprint 後，新增需求會反映到 PBI 與產品目標中。團隊也會根據回顧改善 DoD、提出中期檢視等建議並執行。能夠不斷被「養」起來，感覺很有發展性。

• 真正交付成果

  • 最重要的是，最後交出可運作的系統，與各種報告文件。這一點非常關鍵。

• 具有通用性

  • Scrum 流程並不限於新系統開發，也能用於維運或其他工作。儘管可能需要調整團隊組成或精簡流程，但把「整體目標→PBI→Sprint 目標→Sprint Backlog→Review→Retrospective」這樣的流程套用在各種場景是有價值的。

對 AI Scrum 團隊的疑慮

當然，在跑了幾個 Sprint 之後也有不少值得注意的地方：

• 花費時間驚人

  • 以 Opus4.6 (fast mode) 全部跑一個 Sprint 約需 2 小時；若用 Opus4.6（non-fast）則可能需要約 6 小時。如果執行期間發生錯誤，恢復相當麻煩。此外等待時間長、資源與成本也是問題（視計價方式而定，可能變得昂貴）。目前 GitHub Copilot 的計費以高頻次請求為主，但實務上要注意成本。

• 是否能用在大型專案？

  • 這次只是做出一個玩具等級的應用。要到具備企業等級可行性的系統，這個框架是否足夠還不得而知。不過因為並非要一次讀取整個程式碼庫，某種程度上仍有可能擴展。若要擴大規模，也可考慮分割並嘗試 Scrum of Scrums。

• AI 的「時間」到底是什麼？

  • 我們用故事點（SP）的相對估算來計算 Sprint 容量並以 1 週（5 天）為單位切分，但 AI 是否真正適合「時間」這個度量值得懷疑。對 AI 來說，可能應改用像「token 消耗量」、「工具呼叫次數」等與 AI 特性相關的指標來衡量容量。

• 最後的審查仍依賴人類

  • 即便 AI 快速交付增量，最終還是需要人類做審查與判斷。不得不考慮「責任歸屬」的問題：哪些決策可完全交給 AI？類似自動駕駛要到哪個階段才可以不需要人類干預。

• Office 檔案品質仍有瑕疵

  • PowerPoint 有時會產生錯誤的投影片、Excel 圖片下方會有文字位置異常等。雖然可以透過 skill 調整，但有時直接用 Markdown 或把輸出轉成圖片會更穩妥。

總結

我組成了多 AI 代理的 Scrum 團隊並跑了數次 Sprint。結果比預期還要順利，但這也帶出許多需要重新考量的人類任務與責任分配問題。若要把 AI Scrum 套用到企業實務，還需要釐清哪些工作應由人類保留，例如：

• 要件細緻化的工作
  → 仍需人類主導。人與人之間的協商對 AI 來說不易完全取代。

• 品質保證
  → 仍需人類參與，但審查方式可能由「看每行程式碼」變為「看報告與證據文件」。

• 運維可維護性
  → AI 可幫忙一定程度，但應依組織標準來執行。

• 障礙處理
  → 協調與說明仍需人類，但實際修正可能由 AI 協助或執行。

• 架構與底座
  → 希望這仍是人類的核心工作（但隨著 AI 能力提升，強度可能可減輕）。

AI 與開發工具會持續演進，人類對 AI 的接受度也將提高。將 AI 引進開發流程令人既期待又有些不安。若你對這次多 AI 代理 Scrum 的實作有興趣或疑問，歡迎留言交流。

註：我也請 AI 根據 Sprint3 的完整日誌寫過一篇流程式的部落格文章，裡面有更詳盡的時間序列說明；有興趣也可以看看。（另外 Sprint4 也完成並由 AI 編成文章）

原文出處：https://qiita.com/shyamagu/items/0ff827a1c2deef68ba9a