思考の瞬間に開発者のインテントをキャプチャする

5 min read

Last edited: Jun 02, 2026

AIコーディングアシスタントは開発速度を2倍にできます。しかし、スプリントボードは違う物語を語っていました — 作業の半分が見えていなかったのです。問題は開発者がトラッキングを気にしなくなったことではありません。問題は、既存のすべてのインテグレーションが間違ったタイミングで作業をキャプチャしていたことです。

私たちはMCPベースのシステムを構築し、開発者が作業を完了した時ではなく、考え始めた時にインテントをキャプチャします。この記事では、Model Context Protocolを通じてDevRevのワークトラッキングをCursorに接続した際に学んだことを紹介します。

このギャップは2025年5月のDevRev LinkedIn Liveで明確に示されました。Ahmed BashirとShivamがエンドツーエンドのフローをデモしました。AIアシストによるコーディングで社内チームの生産性は約2倍に向上していましたが、日々の可視性に重要なタイミングを過ぎても、作業はシステムオブレコードに表示されていませんでした。

生産性のパラドックス

繰り返し見たパターンがあります。開発者がタスクに取りかかり、CursorでCopilotやClaudeと2時間過ごし、PRをプッシュして次に移る。速い。生産的。まさに望ましい姿です。

ただし、PRがランディングするまで、その作業はスプリントボードに一切表示されませんでした。ステージ遷移なし、進捗更新なし、痕跡なし。スプリントレビューの時期が来ると、完了した作業の半分がトラッキングされていませんでした。マネージャーがステータスを聞く。開発者がコンテキストスイッチしてチケットを更新する。2倍のコーディング速度の向上は、静かにオーバーヘッドに侵食されていきました。

核心的な緊張：AIはコーディングを速くしましたが、作業をすることと作業を記録することのギャップは広がりました。コードを書くことで節約した1時間ごとに、事後の手動ブックキーピングで部分的に失われていたのです。

GitHubフックだけでは不十分だった理由

最初の直感は明白なもの — GitHubウェブフックでした。PR作成時に、リンクされたDevRevの課題を自動更新する。ステージを遷移させる。コメントを投稿する。

技術的には機能しました。しかし、間違った問題を解決していたのです。

GitHubフックは完了をキャプチャするものであり、インテントではありません。PRが存在する時点で、開発者はすでに計画のマインドセットからコンテキストスイッチしています。課題のタイトルは古くなっている。説明は後付け。分類 — これは新規開発か、バグ修正か、テクニカルデットか — は一切行われません。セッションで述べたように、フックはtoo little, too lateに感じられます。PRは数日の作業を一瞬に圧縮するため、火曜日と木曜日で何が動いたか、週末までに誰がヘルプを必要としているかといった質問に必要な時間的な視点が失われます。

公平を期すと、MCPの更新も事後に行われます — コードを書いた後、PRを作成した後です。違いはMCPが思考と同期しているということではありません。MCPの更新は、単一のサイクル終了時のフックではなく、開発者の既存のカンバセーション内で自然にトリガーされるより細かい粒度で行われることです。開発者はまだコンテキストの中にいます。メンタルモデルはまだ温かい状態です。

より微妙な問題も見つかりました。ウェブフックがいずれ課題を更新してくれると知っている開発者は、開発中に課題を最新に保つモチベーションがさらに低下していました。自動化は先延ばしの口実になり、「先延ばし」は多くの場合「忘れられる」ことを意味しました。

フックはtoo little, too lateだったのです。

開発者がすでにいる場所で会う

開発者がコンテキストスイッチを避けるのは当然です。これは性格の欠陥ではなく、中断のコストに対する合理的な反応です。ブラウザタブを開くことを要求するワークトラッキングソリューションは、その時点ですでに負けています。

Model Context Protocolは別のエントリポイントを与えてくれました。MCPはAIアシスタントがカンバセーション中に外部ツールを呼び出すことを可能にします。つまり、開発者の既存のCursorセッションが、コードだけでなくプロジェクト管理も含むすべてのインターフェースになるのです。

Cursorに2つのMCPサーバーを設定しました。1つはDevRev（ワークトラッキング、スプリント管理、カテゴリ分類）用、もう1つはGitHub（リポジトリ操作、PR作成）用です。開発者はIDEを離れません。AIアシスタントが思考とトラッキングの間の接着レイヤーになります。

同じDevRev MCPサーバーはRaycastやWarpなど他のクライアントにも接続できるため、作業のコンテキストはIDEだけでなく、すでに使っているサーフェスに常に表示されます。

重要な洞察はポジショナルなものでした。より良いインテグレーションを構築していたのではありません。インテグレーションをワークフロー内でより早いタイミングに移動させていたのです — 完了の瞬間から思考の瞬間へ。

ゼロフリクションの課題作成

最もシンプルなインタラクションはこのようになります。開発者が新しいブランチを作成し、Cursorのチャットで「create issue」と入力します。まだコードはコミットしていません — 実装前にインテントを記録に残したい瞬間です。

裏側では、MCPサーバーが求められることなくいくつかのことを行います。ローカルのGit設定から開発者のアイデンティティを検出し、DevRevユーザーアカウントにマッピングします。リポジトリとディレクトリのコンテキストからpart — DevRevのビジネスエリアまたはプロダクトコンポーネントの概念 — を推論します。まだdiffがないため、最初のタイトルはブランチ名程度に薄いかもしれません。それでも実際の課題を作成し、次の更新で改善するには十分です。正しいpartの帰属はダウンストリームの自動化をトリガーできます — 私たちの設定では、レコードが作成されるとすぐにWeb UIを開くことなくアクティブスプリントと初期ステージを割り当てることが含まれていました。

開発者はリンク付きのフォーマットされた課題を受け取ります。一文の入力で、1つのトラッキングされた作業アイテムが出力されます。

ここで重要なのは自動化そのものではなく、タイミングです。課題は一行のコードが書かれる前に存在します。開発者のインテントは、それを言語化した瞬間 — コンテキストが新鮮でメンタルモデルが完全な状態 — でキャプチャされるのです。

ブラウザタブなし。フォームフィールドなし。優先度、part、スプリントのドロップダウンメニューなし。デフォルトは推論され、オーバーライドが必要になるのは例外的なケースです。

コードアウェアな更新

作成は簡単な部分でした。より難しい問題は継続的な更新 — 作業の進行に合わせて課題を正確に保つことでした。

開発者がコードを書いた後に「update issue」と入力すると、MCPサーバーは現在のコンテキストを読み取ります。どのファイルが変更されたか、最近のGit diffがどのようなものか、開発者がチャットで何を言ったか。そこから3つのことを行います。

まず、課題のステージを遷移させます。コーディングを開始したばかりなら、課題は「In Development」に移動します。テストを書いているなら、「In Development」のまま — テストはビルドの一部であり、レビューではありません。課題が「In Review」に移動するのは、開発者がPRを作成し、チームメイトが確認できる状態になった時だけです。これらはヒューリスティックなデフォルト — AIがカンバセーションのコンテキストに基づいてオーバーライドできるルールベースのアンカーです。開発者が「完了したけどマージ前にフィードバックを待っている」と言えば、正式なPRがなくてもAIは「In Review」に移動できます。原則は一貫しています。「In Review」は別の人間がアクションを取る必要があることを意味し、開発者がまだイテレーション中であることではありません。

次に、課題のタイトルを生成または改善します。開発初期段階では、課題のタイトルは曖昧になりがちです（「あの件を直す」）。コードが存在した後、MCPサーバーは実際に構築されたものから導出された正確なタイトルを提案できます。開発者は一つのメッセージで承認または編集します。

最後に、DevRevの課題にタイムライン更新を投稿します — 何がいつ起こったかを示す痕跡です。複数日にわたるタスクでは、これらが蓄積されて、意図的なドキュメンテーション作業を必要としないナラティブになります。

結果として、開発者が直接訪問することなく常に最新状態を維持する課題が生まれます。トラッキングシステムは開発のカンバセーションの副産物になり、別の雑務ではなくなります。

自動カテゴリ分類

より目立たない成果の1つが分類でした。すべての作業はカテゴリに分類されます。新規開発、バグ修正、テクニカルデット、その他。チームはこのデータを計画やレトロスペクティブに必要としますが、開発者が自発的に提供することはほぼありません。

MCPを通じて課題が作成または更新された時に実行されるカテゴリ分類エージェントを構築しました。課題の説明、コードのコンテキスト、カンバセーション履歴を調べ、理由付きでカテゴリを割り当てます — またはコンテキストが不十分な場合は保留し、コミットと説明で作業が判読可能になった段階で分類します。

理由付けが重要であることがわかりました。単なるラベル — 「テクニカルデット」— は議論を招きます。理由付きのラベル — 「テクニカルデット：非推奨の依存関係を削除するために認証ミドルウェアをリファクタリング、ユーザー向けの動作変更なし」— は同意を招きます。チームは根拠を読んで数秒で検証できるため、分類を信頼しました。

エージェントは誤った分類も早期にキャッチします。開発者は新機能の作業だと思っているかもしれませんが、コード変更が新しいエンドポイントやUIなしに既存モジュール内で完結している場合、エージェントはリファクタリングとしてフラグを立てます。これは開発者をオーバーライドすることではなく、キャパシティプランニングのためにチームに正確なデータを提供することです。

IDEを離れずにPRを作成

最後のピースはループを閉じることでした。開発者はコーディングを終え、MCPを通じて課題を更新し、「create PR」と言います。

GitHub MCPサーバーが残りを処理します。課題IDからのブランチ命名、コミットメッセージのフォーマット、課題とコードのコンテキストから生成されるPR説明、PRボディに埋め込まれたDevRev課題へのリンク。ライブウォークスルーでは、クライアントはテキストのblobで置き換えるのではなく、チームのチェックイン済みPRテンプレートをセクションごとに埋めていました。

ここで2つのMCPサーバー — DevRevとGitHub — が連携して動作します。DevRevサーバーはワークトラッキングのコンテキスト（課題ID、タイトル、説明、part）を提供します。GitHubサーバーはリポジトリ操作を提供します。CursorのAIアシスタントが、1回のカンバセーションターンで両者間をオーケストレーションします。

開発者の完全なワークフロー — 「これを直さないと」から「PRがレビュー待ち」まで — が1つのツールで完結します。スプリントボード、課題トラッカー、リポジトリのすべてが、カンバセーションの自然な結果として同期されます。

何が変わったか

プロジェクト管理ツールを構築しようとしたのではありません。データ品質の問題 — 現実を反映しないスプリントボード — を解決しようとしたのです。

修正はアーキテクチャ的なものであり、モチベーション的なものではありませんでした。開発者が作業をトラッキングできなかったのは不注意だったからではありません。トラッキングのすべての既存タッチポイントが間違った場所、間違った時間にあったからです。そのタッチポイントをIDE内 — 開発者がすでに構築したいものを説明しているまさにその瞬間 — に移動させることで、データギャップを生んでいた摩擦を排除しました。

実際には、MCPを通じて作成された課題は、Web UIで作成されたものより、より豊かな説明、より正確なカテゴリ分類、より頻繁なステージ更新を持っていました。開発者にコンプライアンスを促したからではなく、システムが開発者がすでに作業している場所で会ったからです。

限界はあります。複雑なマルチパートのエピックは依然として意図的な計画セッションが有益です。すべてのワークフローがチャットベースのインタラクションに適合するわけではありません。しかし、タスクを拾い、コードを書き、PRを出す日々のリズムにおいては、思考の瞬間にインテントをキャプチャすることが、ミスリードするスプリントボードと現実を反映するスプリントボードの違いになることがわかりました。

このシリーズの次の記事では、技術的な実装を取り上げます。MCPサーバーの構造化方法、ツール間の認証処理、DevRevとGitHub間のステート同期の管理について。