Claude Codeを中心に、
開発工程そのものをAI化する。
Notionで仕様を読み、Figmaでデザインを理解し、Linearで仕事を管理し、 GitHubでIssue・PRを扱い、SupabaseでDBを確認し、Vercelへデプロイ。 Playwrightで実ブラウザを検証し、Sentryで本番障害を観測する。 MCPを使えば、これらをClaude Code中心の1つの開発フローへつなげられます。
コードを書く能力だけでは、仕様・デザイン・DB・デプロイ・ブラウザ・本番環境の状態を理解できません。 MCPで外部システムへ接続することで、Claude Codeが開発工程全体のコンテキストを扱えるようになります。
AI自動開発環境とは？
ここでいうAI自動開発環境とは、単にAIへコードを書かせる仕組みではありません。
ソフトウェア開発には、コード作成以外にも大量の工程があります。
従来は、人間が各サービスを開き、必要な情報をコピーしてAIへ渡していました。
MCPを使うと、AIエージェント自身が対応するサービスへ接続し、必要な情報を取得できます。
今回使うAI開発スタック
仕様書・PRD・タスク・ドキュメントなど、開発の「なぜ・何を作るか」をClaude Codeへ渡します。
Components・Variables・Layout・Design Systemなど、UIの構造と意図をClaude Codeへ渡します。
Issue・Project・Milestone・Initiativeなど、現在進めている「仕事の状態」を扱います。
Repository・Issue・Pull Requestなどコード変更のContextとReview Workflowを接続します。
Database・SQL・Migration・Logs・Edge FunctionsなどBackend Contextを扱います。
Project・Deployment・Build Logsなど、実際のDeploy環境の状態を確認します。
実ブラウザを開き、クリック・入力・フォーム・画面遷移などユーザー操作を検証します。
本番Issue・Error・Stack TraceなどをAIが確認し、障害調査から修正へ戻します。
全部つなぐとどうなる？
Claude CodeがPRD・Acceptance Criteria・技術メモなどを確認します。
UI構造、Components、Variables、Layoutなどを確認します。
Priority・Project・完了条件・関連Issueなど、仕事の状態を把握します。
現在のコード・Issue・PR Contextを確認して影響範囲を特定します。
必要に応じてDB Schema・Migration・Logs・Authなどを確認します。
要件と既存コードに基づき、必要最小限の変更を行います。
Lint・Typecheck・Unit Test・Buildなどを実行します。
DeploymentとBuild Logsを確認し、環境固有の問題を調査します。
実際のブラウザでユーザー操作を再現して機能を確認します。
変更内容・Test Result・注意点を整理してReviewへ進めます。
実装結果・PR URL・テスト結果・残課題・Statusを更新します。
本番障害が発生した場合は、Issue ContextをClaude Codeへ戻して修正ループを再開します。
大事なのは「AIが最初から最後まで勝手に動く」ことではありません。 各工程から正しいContextを取得し、安全な範囲でAIが作業し、人間が必要な地点で承認できる開発ループを作ることです。
なぜMCPが必要なのか？
Claude Code単体でもRepository内のコードやTerminalは扱えます。
しかし外部サービス上に存在する最新の情報は、接続しなければ分かりません。
例えば、
これらを人間が毎回コピペするのではなく、MCPを通して必要な時にAIが取得できるようにします。
まず何個MCPを入れればいい？
最初から全部入れる必要はありません。
GitHub + Playwright。実装・Review・ブラウザQAまでをAI化。
GitHub + Supabase + Vercel + Playwright + Sentry。
Notion + Figma + Linear + GitHub + Backend + Deploy + QA + Observability。
人間が繰り返し画面を開き、コピーしてAIへ渡している工程から優先して接続するのが最も効果的です。
主要MCPの接続イメージ
各サービスの正式な設定方法は個別記事で解説していますが、Claude Codeでは概ね次のようにMCP Serverを追加します。
# Linear
claude mcp add --transport http linear-server \
https://mcp.linear.app/mcp
# Figma
claude mcp add --transport http figma \
https://mcp.figma.com/mcp
# Supabase
claude mcp add --scope project --transport http supabase \
"https://mcp.supabase.com/mcp?features=docs,database,debugging,development,functions"
# Playwright
claude mcp add playwright npx @playwright/mcp@latestRemote MCPではOAuth認証を使うサービスも多く、接続後に/mcpからAuthenticateするケースがあります。
サービスによってEndpoint・Scope・Read-only設定などが異なるため、必ず公式ドキュメントの現行手順を確認してください。
MCPを入れすぎると逆に悪くなることもある
MCPには大きなメリットがありますが、ツールを増やすほど常に良くなるわけではありません。
MCP ServerはAIへTool Schemaを公開します。
大量のMCP Server・大量のToolが有効になると、モデルが扱うContextやTool選択が複雑になります。
特にブラウザ自動化ではMicrosoft自身も、Coding Agentの用途によってはPlaywright MCPよりCLI + Skillsの方がTool SchemaやAccessibility TreeによるContext消費を抑えられると案内しています。:contentReference[oaicite:0]{index=0}
Browser操作が必要ないTaskでPlaywrightを呼ばない、DB変更が必要ないTaskではSupabaseをRead-onlyにするなど、 Agentへ与える能力をTaskごとに絞る方が安全で効率的です。
Source of Truthを決める
複数のMCPをつなぐと、同じ情報が複数サービスに存在する問題が出てきます。
例えば仕様変更がNotionにもLinearにもGitHub Issueにも書かれている場合、どれを正とするのか決める必要があります。
Agentへもこの優先順位を明示しておくと、情報が矛盾した場合に勝手な判断をしにくくなります。
自動開発で最も重要なのはガードレール
「やってはいけないこと」も明確にする。
AI AgentがGitHub・DB・Deploy・Browser・Project Managementへ接続すると、 誤操作の影響範囲も広がります。 自動化より先に権限と承認ルールを設計することが重要です。
- Productionへの直接変更を原則禁止する
- DBは開発環境またはRead-onlyから始める
- mainへの直接pushを禁止する
- 必ずPR・CIを経由する
- 削除・決済・公開・本番Migrationは人間承認を挟む
- QA用アカウントと本番ユーザーを分離する
- API KeyやTokenをRepositoryへ保存しない
- 外部コンテンツからのPrompt Injectionを想定する
Supabase公式も、AI Toolをプロジェクトへ接続することにはセキュリティリスクがあると明示し、read_only=true、project_ref、featuresなどでアクセス範囲を絞れるようにしています。:contentReference[oaicite:1]{index=1}
LinearにもRead-only専用Endpointがあり、書き込み不要な用途ならhttps://mcp.linear.app/mcp/readonlyを利用できます。 :contentReference[oaicite:2]{index=2}
どこを自動化し、どこを人間が承認する？
調査、コード検索、Lint、Typecheck、Test、Read-only情報取得、Diff整理。
コード変更、Issue更新、PR作成、Preview Deploy、テストデータ操作。
Production Migration、削除、課金、外部公開、main merge、機密情報変更。
QAをAI開発の中心に置く
AIコーディングで起こりやすい失敗は、「実装できた」と判断した時点で作業を終えることです。
実際には、
コードが書けた ≠ ユーザーが使える
です。
Playwright MCPは構造化されたAccessibility Snapshotを使ってWebページを操作できます。LLMは要素のrefを読み取り、クリック・入力などを行います。:contentReference[oaicite:3]{index=3}
Preview環境で以下を検証してください。
1. ログイン
2. 対象ページへ移動
3. フォーム入力
4. Submit
5. Success Message確認
6. DBの結果確認
7. Console / Network Error確認
8. 問題があれば原因調査
9. 最小修正
10. 同じテストを再実行Figmaまで接続する意味
AIにスクリーンショットだけを渡す場合、デザインの構造までは完全に分かりません。
Figma MCPはDesign Context、Variables、Components、LayoutなどをAIへ提供し、さらに対応するクライアントではFigmaへNative Contentを書き戻すこともできます。Figmaは現在Remote MCPを大半のユーザーに推奨しています。:contentReference[oaicite:4]{index=4}
つまり、
Figma → Code → Running UI → Figma
という双方向ワークフローが可能になっています。
Deploy後までAIに見せる
ローカルで成功しても、PreviewやProductionで失敗することがあります。
Vercelの公式MCPは、Vercel Docs検索、Project・Deployment管理、Deployment Log解析などを提供しています。公式MCPはRemote InterfaceとしてOAuth認証とStreamable HTTPに対応しています。:contentReference[oaicite:5]{index=5}
このため、
Local Build OK → Preview Deploy Failed → Vercel Log取得 → Claude Code修正
という流れを構築できます。
Productionから開発へフィードバックを戻す
自動開発ループの最後に必要なのがObservabilityです。
コードを書いてDeployするだけでは、本番で問題が起きてもAIは知りません。
Sentryのような監視サービスを接続すると、実際に発生したIssueやError Contextから原因調査へ戻れるようになります。
ここまでつながると、
Build → Deploy → Observe → Fix
という循環になります。
GitHubはAI開発の安全装置にもなる
GitHub公式MCP ServerはRepository・Code Files・Issue・Pull RequestなどをAI Toolから扱うための公式Serverです。GitHub MCP自体は全GitHubユーザーが利用できますが、一部Toolは対応するGitHub機能側の利用条件を引き継ぎます。:contentReference[oaicite:6]{index=6}
ただし、GitHub MCPの価値はAIがGitHubを操作できることだけではありません。
Branch → PR → CI → Review → Merge
という既存のソフトウェア開発プロセスを、そのままAIへのガードレールとして利用できます。
どこまで自律化できる？
「完全自動開発」という言葉は強いですが、現実には段階があります。
人間がTaskを細かく指示し、AIがコードを書く。
目的を渡すとAIが調査・実装・テストまで進める。
MCPで仕様・Design・Deploy・Productionまで外部Contextへ接続。
さらに進むと、Issue発生や監視イベントを起点にAI AgentがTaskを開始する形へ発展します。
ただし権限・検証・承認が必要な領域まで無条件に完全自動化するのは、安全面から推奨できません。
Claude Codeへ渡す自動開発プロンプト例
この開発Taskを進めてください。
SOURCE OF TRUTH
- Product Spec: Notion
- Design: Figma
- Work Status: Linear
- Code / PR: GitHub
- Database: Supabase
- Deployment: Vercel
- Browser QA: Playwright
- Production Errors: Sentry
WORKFLOW
1. Linearから対象Issueを取得
2. Notionから関連仕様を取得
3. Figmaから関連Design Contextを確認
4. Repositoryを調査
5. Supabase変更が必要か確認
6. 要件との差分を整理
7. 実装計画を作成
8. 計画を提示し、破壊的変更なら停止
9. 最小変更で実装
10. Lint / Typecheck / Tests / Build
11. Git diffを自己レビュー
12. Preview環境を確認
13. PlaywrightでAcceptance CriteriaをE2E検証
14. 失敗した場合は原因調査→最小修正→再テスト
15. PR用要約を作成
16. Linear / Notionへ更新する内容を提示
RULES
- mainへ直接pushしない
- Production DBを直接変更しない
- 削除・課金・公開操作は実行前に確認
- 根拠がない仕様を作らない
- 不明点を推測で埋めない
- 変更禁止ファイルを尊重
- 最後に変更ファイル・テスト結果・残課題を報告最終的にはCIへつなぐ
手元のClaude Codeで動くようになったら、次の段階は「毎回人間が同じ検証を依頼しなくてもよい仕組み」です。
例えば、
AIまたは人間が変更をPush。
Lint・Typecheck・Unit Test・Build。
Preview専用環境を生成。
QAデータ・QA Userを使ってPlaywrightを実行。
変更・Test・失敗内容をPRへ集約。
最終判断のみ人間が担当。
調査、実装、繰り返しテスト、ログ確認、ドキュメント更新などをAIへ移し、 人間は仕様・優先順位・リスク・最終承認に集中する。 これが現在もっとも現実的なAI自動開発の形です。
AI開発はどこまで進む？
複数のAIエージェントを管理する時代へ。
AI Agentが仕様・Design・Code・Test・Deploy・Productionへ接続されると、 人間は1つずつ作業する人ではなく、複数Agentへ仕事を割り当て、 品質と方向性を管理する役割へ移っていきます。
これまでは、
人間 → コード → テスト → デプロイ
でした。
これからは、
人間 → 目的・制約 → AI Agent群 → 開発工程 → 人間の承認
という形が増えていく可能性があります。
その中核になるのが、Coding Agentと外部システムを接続する仕組みです。
モデル性能に加えて、どのContextへアクセスできるか、 どこまで自動検証できるか、 どの操作に人間承認を残すか。 AI開発環境全体の設計が、開発速度と品質を左右するようになります。
各MCPを詳しく見る
出典：Anthropic Claude Code、Notion、Figma、Linear、GitHub、Supabase、Vercel、Microsoft Playwright、Sentry各公式ドキュメント。機能・接続方式・利用条件は記事執筆時点の情報です。
