はじめに
こんにちは。株式会社FLINTERSの小林です。
この記事は FLINTERS BLOG Advent Calendar 2025 12日目の記事です。
私は普段、Reactなどを使ってWebアプリ開発を行うフロントエンドエンジニアをしています。
2025年の初めまで、私にとってAIは「便利な検索エンジン」でした。コードの書き方をGitHub Copilotに聞いたり、エラーログを貼り付けて解説してもらったりする程度で、あくまで 「開発の補助ツール」 という認識でした。
しかし、今年、2025年下半期のわずか数ヶ月でその認識は大きく変わりました。
きっかけはAIコーディングエージェント、Claude Code の社内本格利用と、それを効率的に運用する 自作のVSCode拡張機能「Claude Code Workflow Studio」の開発 です。
VSCode内でClaude Codeのワークフローを視覚的に構築できる「Workflow Studio」
この記事は、2025年10月までAIを「使う側」でしかなかった私が、「AIを制御するためのツール」を3連休という短期間で開発し、OSSとしてVSCode拡張機能マーケットプレイスに公開するまでの記録 です。
課題解決の熱意があれば、私たちエンジニアはAI開発体験そのものを自分で作り変えることができる。
今回はその可能性と、それを支えた 「Spec Kit駆動開発」 の一端をお伝えできればと思います。
今回開発したVSCode拡張機能
第1章：Claude Code設定の壁と社内AIイベントで掴んだ「GUI化」の必然性
AI導入と成功体験
始まりは2025年7月、社内でClaude Codeが導入されたことでした。
当時、納期が非常に厳しいプロジェクトを抱えていましたが、チーム全体でClaude Code等のAIエージェントを積極活用し、多くの実装をAIと協業することで無事にリリースすることができました。
この経験で、 「AIを活用すれば、従来の工数では不可能なスピードと精度で開発ができる」 という手応えを掴みました。その後、社内ブログでノウハウを共有し、2025年10月の社内AIイベントで登壇するなど、私の中でAI活用への関心が一気に高まっていきました。
直面した課題：設定ファイルの管理コスト
しかし、日常的に使い込むにつれて、運用面の課題も見えてきました。それは 「設定管理の煩雑さ」 です。
Claude Codeをプロジェクトに適した状態で動かすには、CLAUDE.md、Slash Command、Sub-Agent、Skill、MCP 等の設定ファイルを事前に用意して管理する必要があります。
この辺りの情報はこちらにまとめてあります。
この記事を執筆する中で「AIで開発を楽にしたい」はずなのに、「AIへの指示書を作る作業」に時間を取られている。そんな本末転倒にも近い状況にモヤモヤを感じていました。
転機：社内AIイベントとチーム内AI情報共有で繋がった「3つの点」
そんな中、私の思考を一変させる出来事がありました。2025年10月に登壇したAIイベントでの、他の方々の発表と社内の技術共有です。そこで得た3つのヒントが、私の頭の中で繋がり、化学反応を起こしました。
-
アイデアの源泉：DifyとAskUserQuestion（What）
登壇者の一人が紹介していた「Dify」は、LLMのワークフローをノードベースで視覚的に構築できるSaaSです。「これだ！」と思いました。また、同時期にチームメンバーがClaude Codeに備わるAskUserQuestionという、ユーザーに選択肢を質問するツールを発見し、共有してくれました。この「質問による分岐」こそが、Difyのような視覚的なフロー設計に落とし込める中核機能だと確信しました。 -
開発手法の確立：GitHub Spec Kit（How）
別の登壇者が紹介していた「GitHub Spec Kit」。AIに漠然と指示するのではなく、仕様（Spec）を定義して開発させるフレームワークです。「これを使えば 自分は価値を生み出すことに集中して短期間でツールを作れる のではないか？」という仮説が立ちました。 -
実現手段の発見：VSCode × React（Where）
そして後日、あるチームメンバーがAIコーディング支援ツールのPoC（概念実証）をVSCode拡張機能として開発し、そのソースコードを共有してくれたことで、 「VSCode拡張機能のGUIはReactで作れる」 という事実を知りました。
この3つが揃った瞬間、迷いは消えました。 「Claude Code Workflow Studio」 の開発プロジェクトの始動です。
WebアプリではなくVSCode拡張機能を選んだ4つの理由
普段の業務で開発し慣れているWebアプリではなく、VSCodeで開発したのには明確な理由があります。
-
ローカルファイルシステムへの直接アクセス
Webアプリ（ブラウザ）からは、ユーザーのローカルにある.claude/ディレクトリを直接読み書きすることが困難です。VSCode拡張機能ならNode.js環境を通じてセキュアかつ容易にアクセスできます。 -
コンテキストスイッチの排除
コードを書く（VSCode）↔ AIを動かす（Terminal）のループに「ブラウザを開く」動作を入れたくありませんでした。VSCode内で完結することが、開発フローの維持に不可欠でした。 -
情報の機密性・安全性の確保
ワークフロー設計情報やプロジェクトの機密コードを外部サーバーに送信せず、すべてローカルで処理することで、企業レベルのセキュリティ基準を満たせます。また、ローカル端末での動作とすることで、セキュリティ攻撃のリスクをかなり低減できました。
もしWebアプリとして公開していたら、先日公表され猛威を振るっている React Server Componentsの脆弱性（CVE-2025-55182） の対応に追われていたかもしれません。
「攻撃可能なサーバーを持たない」ことは、個人の短期開発において最強のセキュリティ対策となりました。 -
運用コストゼロ
ユーザー端末のClaude Code環境を利用するため、別途APIキーの設定や外部サービス登録が不要です。
第2章：最大のチャレンジ —— 「3連休」でMVP版を作り切る
開発を決意したのは11月の3連休直前でした。
モチベーションは最高潮でしたが、時間は72時間しかありません。この短期間で、未知の領域であるVSCode拡張機能を完成させ、公開まで持っていくには、従来の手法では不可能です。
そこで、今回のプロジェクトにおける最大のチャレンジを次のように定義しました。
なぜこれが「チャレンジ」なのか
一見、AIに任せるのは「楽をする」ことのように思えます。しかし、実際は全く逆の難しさがありました。
- メタ認知の複雑さ: 「Claude Codeを制御するツール」を「Claude Code」に作らせる再帰的な構造。「AIにとって使いやすい設定ファイル」をAIに理解させる言語化能力が問われます。
- 上流工程へのシフト: コードを1行も書かないということは、仕様の曖昧さが許されないということです。「なんとなく動く」ではなく、「Spec Kit」で実現したい価値を要件定義し続ける必要がありました。
-
AIマネジメント：実装者から「責任者（テックリード）」への役割変化:
コードを書く作業はAIが行いますが、そのコードがプロダクトとして適切かどうかの判断は人間にしかできません。AIは時に「動くけれど保守性が低い実装」や「セキュリティ的に危うい書き方」を提案してくることがあります。
そのため、私は以下の観点で常に厳格なコードレビューと軌道修正を行い続けました。- 技術選定と方向性の監督: AIが過度に複雑な実装方針（Over-engineering）を選ぼうとした際、よりシンプルで堅牢なアーキテクチャへ引き戻す。
- セキュリティ監査: ローカルファイルを直接操作する拡張機能であるため、ディレクトリトラバーサルなどの脆弱性がないか目を光らせる。
- 最適化の判断: 提示されたコードに対し「もっと効率的なVSCode APIがあるはずだ」と指摘し、再実装させる。
コードを書く手は止めていても、 「テックリードとしての審美眼」 と 「品質への責任」 は、かつてないほど問われる72時間でした。
第3章：解決策のアーキテクチャとSpec Kitの実践
では、実際にどのように開発を進めたのか。ここが技術的なハイライトです。
アーキテクチャ：React × VSCode API
GUIを持つVSCode拡張機能の構成は、Web技術そのものです。
- UI層（Webview）: Reactで実装。ユーザーがGUIで設定を入力する画面。
- ロジック層（Extension Host）: VSCode APIを使用。ファイルの読み書きやコマンド実行を担当。
-
通信: VSCode拡張機能の Webview API (
postMessage) を使って、JSONメッセージでやり取りして状態を同期。
開発フロー：Spec Kit駆動開発の真髄
私が実践したのは、コードを書く代わりに「物語（User Story）」を書くプロセスです。
実際に私が記述し、Claude Codeに渡したSpec Kitの一部（User Scenarios）をご覧ください。
実際のSpec Kit（User Scenarios & Testing）の断片
## User Scenarios & Testing *(mandatory)*
### User Story 1 - ワークフロービジュアルエディタでの作成 (Priority: P1)
開発者がVSCode上でビジュアルエディタを開き、Claude Codeのワークフローをドラッグ&ドロップで設計できる。ワークフローはSub-Agentをノードとして配置、分岐をAskUserQuestionで配置し、AWS Step Functionsのような視覚的なフローチャート形式で構成する。出来上がったフローはSlashCommandsから実行できる。
**Why this priority**: ワークフローの視覚的な設計機能は本機能の中核であり、これがなければ他の機能も価値を持たない。ユーザーが最初に体験する主要機能として最も重要。
**Independent Test**: VSCode拡張機能をインストール後、コマンドパレットから「Claude Code Workflow Studio」を開き、新規ワークフローを作成。Sub-Agentノードを1つ配置して保存できることを確認すれば、基本的なエディタ機能が動作していると検証できる。
**Acceptance Scenarios**:
1. **Given** VSCodeが起動している状態で、**When** コマンドパレットから「Open Claude Code Workflow Studio」を実行する、**Then** ビジュアルエディタが新しいタブで開く
2. **Given** ビジュアルエディタが開いている状態で、**When** 左側のツールパレットから「Sub-Agent」ノードをキャンバスにドラッグ&ドロップする、**Then** キャンバス上にSub-Agentノードが配置される
3. **Given** ビジュアルエディタが開いている状態で、**When** 左側のツールパレットから「AskUserQuestion」ノードをキャンバスにドラッグ&ドロップする、**Then** キャンバス上にAskUserQuestionノードが配置され、分岐ポートが表示される
（中略）
実を言うと、私はこのMarkdownをゼロから書いたわけですらありません。
私がやったのは、最初に**「こういうことがやりたい」と一言伝えただけ**。
それを元にSpec Kitのワークフローがユーザーストーリーの雛形（テンプレート）を瞬時に生成してくれます。私はそれに対し、対話をしながら整理・推敲を行いました。
「このシナリオだと、ユーザーが設定を間違えたときのエラーハンドリングが抜けている。バリデーションの仕様を追加して」
「UIイメージはAWS Step Functionsよりも、Difyのフロー作成画面に近づけてほしい」
といった具合です。「Reactのこのフックを使って…」や「Reduxで状態管理して…」といった実装指示はおろか、仕様書の初稿作成すらAIが担う。人間は「やりたいこと（Will）」を提示し、AIが提示した仕様を承認・修正する役割に徹する。
この 「仕様定義の自動化と対話的修正」 こそが、72時間でのMVP完成を可能にした最大の要因です。
第4章：完成したもの —— Claude Code Workflow Studio
こうして3日間の集中開発を経て完成したのが、 「Claude Code Workflow Studio」 です。
MVPの核となる機能は以下の通りです。
- Visual Flow Editor: 複雑なJSONやMarkdownを手書きせず、ノードベースで直感的に設計。
- AskUserQuestionとの統合: 第1章で触れた「ユーザーへの質問機能」を分岐ノードとしてGUIに統合。これにより、「Yesならデプロイ、Noなら修正」といったインタラクティブなフローが視覚的に作れるようになりました。
-
設定ファイルの自動生成: 設計したフローはボタン一つで
.claude/commands/や.claude/agents/に変換され、即座にCLIで実行可能です。
Q.見た目は面白そうだけど、どういう価値があるの？
A. プロンプト設計において、人間の「理解のしやすさ」とAIの「実行確実性」を両立させることが可能となります
Workflow Studioの本質的な価値
例えば、
「Claude Codeスキルを使用して、PowerPointファイルで作成された要望定義書を元に、要件定義書とE2Eテスト項目を出力したい」
ということをAIエージェントで実現したいとします。
上記の指示をそのままAIエージェントに作業させた場合、ファイル作成はできると思いますが、指示が抽象的なので作業する度にできあがったファイルの項目粒度が異なってしまうはずです。
そのため、このままではチーム共有するなどといった実業務での実用性が低いです。
そこで通常はプロンプト(SlashCommand)を設計し、作り込むことでチーム内で共有できるレベルにするのですが、この指示はmdファイル等のテキストベースで作る必要があるため、慣れている人でないと人間側の認知的負荷がかかってしまいます。
つまり、
- 指示が抽象的すぎるとAIのアウトプットが安定しない
- しかし、具体的なプロンプトは人間側の認知的負荷がかかる
という問題があるのです。
そこで、このWorkflow studioが登場します。
Workflow StudioのAI編集機能で
「Claude Codeスキルを使用して、PowerPointファイルで作成された要望定義書を元に、要件定義書とE2Eテスト項目を出力したい」
の旨を指示するだけで、人が理解しやすい形でAI指示プロンプトが出来上がります。
あとは、この視覚的に表現されたプロンプトを作り込むことで、先の問題を解決するということができます。
ex).PowerPointファイルで作成された要望定義書を元に、要件定義書とE2Eテスト項目を出力するフロー
第5章：MVP版後の進化 —— Gemini Deep Researchで「勝てる機能」を見極める
MVPを公開した後、私はさらなる機能拡張を模索しました。しかし、やみくもに機能を追加しても使われるツールにはなりません。
ここで活用したのが、Gemini Deep Researchです。
開発（Coding）はClaude Code、戦略（Strategy）はGemini。 異なる特性を持つAIを適材適所で使い分けること も重要です。
市場リサーチと戦略の策定
Deep Researchで既存の類似ツールや競合を徹底的にリサーチさせた結果、以下のインサイトが得られました。
- 競合状況: GUIでLLMフローを作るツールはDifyなど存在するが、「VSCode拡張機能として」「ローカル完結で」「Claude Code専用に」特化したものはブルーオーシャンである。
- 伸ばすべき方向性: 単なる設定生成にとどまらず、 「外部ツール（MCP/Skill）との連携」 を強化することで、実務での自動化ツールとしての価値が跳ね上がる。
- 効果が薄い方向性: 汎用的なチャットUIの強化など、Claude Code本体と競合する機能は避けるべき。
この分析に基づき、Spec Kitを使って以下の機能を追加実装しました。
- MCP / Skill ノード: GitHub操作やDB検索,Excel読み書きなど、インストール済みのMCPサーバーやSkillフローに組み込む機能。
- AIワークフロー作成/編集: 自然言語で指示するだけで、AIがワークフローを作成/編集してくれる機能。
- Slack共有: チームでフローを資産化するためのインポート/エクスポート機能。
第6章：振り返りと今後の展望
技術的な学び：フロントエンド知識はWeb開発以外でも武器になる
今回の開発を通じて得た最大の技術的な学びは、 「普段使っているReactの知識があれば、VSCode拡張機能という全く異なる領域もハックできる」 ということです。
「VSCode拡張機能開発」と聞くとハードルが高く感じるかもしれませんが、UI部分はReactなどのWeb技術そのものです。AI（Claude Code）という強力なパートナーがいれば、未知のAPI（VSCode Extension API）のキャッチアップコストは極限まで下がります。
2025年の最も大きなチャレンジとは
今回のコンテストのテーマである「2025年の最も大きなチャレンジ」。
私にとってそれは、コードを書いた量でも、扱った技術の難易度でもありません。
私にとっての最大のチャレンジは、日進月歩のAI技術を必死にキャッチアップし、その力を借りて「AIを使う側」から「AIを作る側」へとエンジニアとしての軸足をシフトさせたこと です。
「Claude Codeの設定が面倒だ」と不満を言う側で終わらず、技術仕様を学び、AIと協業し、 「AIのためのツールをAIと作成する」 という開発スタイルを確立したこと。
この経験は、一人のSIer社員としての私のキャリアにおいて、大きな転換点となりました。
今後の展望
今後はVSCodeで開いているプロジェクトのコードベースを元に、プロジェクトに最適な、新機能追加、バグ改修、E2Eテストシナリオ追加等の最適な開発ワークフローをAIで提案する機能など、さらなる機能拡充を検討しています。
気になる方はぜひVSCodeにインストールして利用してみてください。（CursorやAntigravity等でも利用可能です）
また、実装内容について気になる方はぜひレポジトリも覗いてみてください。
Discussion