みなさん、おはようございます！マイクです。今日は2025年4月24日、木曜日ですね。今日も「zenncast」をお楽しみいただき、ありがとうございます！今日はZennでトレンドの記事をいくつかご紹介しますよ。
さて、前回紹介した記事ですが、AIエージェントのおかげでdbt開発の大部分を自動化した話や、フロントエンドDDD、TypeScriptでGitHub Actionsワークフローを記述する「ghats」の紹介をお届けしました。これらの内容、興味深いですよね！
では、早速今日の内容に移りましょう！今日ご紹介する記事は全部で5本です。
最初の記事は、「AI Agent × Cursor で要件整理から実装まで」です。この内容では、AIエージェントであるCursorを使った開発プロセスについて詳しく解説しています。具体的には、要求整理から実装に至るまでの流れを、実際のプロジェクト事例を交えて説明しています。
まずは、要求情報から実装用のドキュメントを作成する流れを紹介しています。ここでは、要求の明確化や実装方針の決定、タスクの分解が行いやすくなる3つのドキュメントが提案されています。その3つは「実装要件Doc」、「実装方針Doc」、「タスクDoc」です。これらを使うことで、手戻りを減らしながら効率的に開発を進められるんです。
具体的な手順としては、まず要求から実装要件Docを作成し、不明確な要求の整理を行います。次に、その実装要件Docに基づき実装方針Docを策定し、技術選定や設計アプローチを決定します。そして最後に、その実装方針DocからタスクDocを作成し、作業単位の計画を立てることで、開発をスムーズに進められます。
AIエージェントとのやり取りを通じて、細かい質問を投げかけることで不明な点を解消し、実装フェーズでは分割されたタスクに基づいてAIと協力しながら進められるのも魅力ですね。最終的にはPRを作成してコードをコミットすることで、チーム開発の要求整理から実装までの具体的な方法論を学べる内容となっています。
。...。
続いてご紹介するのは、「フロントエンドのリプレイスに、いつまでかけるんだ？」です。こちらの記事では、Ruby on RailsのERBとjQueryを基盤としたフロントエンドを、ReactやVueといったモダンフロントエンドにリプレイスするプロジェクトの現状について触れています。
最近、フロントエンドのリプレイスプロジェクトが増加していますが、多くのプロジェクトが途中で止まってしまっているという現実があります。ERBとjQueryに加えて、ReactやNext.jsが混在することで開発の複雑度が高まる一方です。
いくつかの企業の実例も紹介されています。タイミー社は30画面の移行に3年かけて途中で中断し、クックパッド社は2020年からNext.jsへの移行を開始したものの、今もなお移行中です。スタメン社やENECHANGE社も、ERBとjQueryのコードが残る中で新しい技術を導入しています。
これらの事例から、フロントエンドのリプレイスには一般的に数年がかかり、しばしば中断されることがあると分かりました。ビジネス的な観点からも、長期にわたるプロジェクトは中断されやすく、完全なリプレイスが実現しないケースが多いのです。そのため、ERBやjQueryのコードを整備・リファクタリングすることが、現実的な方法として求められています。
。...。
次にご紹介するのは、「Devinによって変化したエンジニアリングの現場」です。この記事では、Devinの導入がdelyのエンジニアリング現場にもたらした変化について、実例を交えながら紹介しています。
Devinの導入背景には、AI活用による生産性向上やエンジニアへの権限変更リクエストの急増、ドキュメント陳腐化、機能仕様に関する質問の集中が挙げられます。実際に、非エンジニアからの依頼対応の工数が大幅に削減されたのが大きなポイントです。
以前はエンジニアが権限変更リクエストに対応していましたが、Devin導入後はSlackでのメンションだけで自動的にPRが作成されるようになりました。また、Devin Wikiによる最新情報のキャッチアップや、Devin Searchを活用することでエンジニアへの質問が減少し、非エンジニアも容易に情報を取得できるようになったとのこと。
このように、Devinの導入によってdelyのエンジニアリング現場は大きく効率化され、今後もAIツールを活用した生産性向上を目指していく意向が示されています。
。...。
次にご紹介するのは、「MCPの通信に対する深い考察と実装」です。こちらの記事では、MCP、つまりModel Context Protocolの通信手法について詳しく解説されています。
MCPは主に非同期ビジネスプロセスにおける通信手法を提供しており、STDIOとSSE（Server-Sent Events）の2つのプロトコルが説明されています。特にSSEは、サーバーからクライアントに情報をプッシュする一方向性の通信チャネルであり、複数クライアントに対応可能で、HTTPを通じた接続が必要です。
具体的なSSE通信フローは、/sseエンドポイントで長接続を確立し、クライアントに一意のセッションIDを持つ別のエンドポイントを提供する形です。そして、クライアントはHTTP POSTリクエストを通じてサーバーに命令を送り、サーバーはSSEを通じて結果をプッシュします。
MCPを理解することで、単なるSDK使用を超えた柔軟なソリューションの構築が期待できるという内容になっています。
。...。
最後の記事は、「忙しい人向け nvim-lspconfigのnvim v0.11対応」です。Neovim 0.11ではLSP（Language Server Protocol）に関する大幅な変更が行われ、nvim-lspconfigの設定方法が更新されました。
これにより、runtimepath内のlspフォルダにLanguage Serverの設定ファイルを配置できるようになり、`vim.lsp.config`で設定を直接上書き、`vim.lsp.enable`でLanguage Serverを有効化することが可能になりました。これまでの`setup`関数による設定は凍結されており、新しい方式への移行が必要です。
急いで設定を変更したい場合、全てのLanguage Serverに共通の設定を記述でき、nvim-cmpのcapabilitiesも簡素化されています。各Language Serverの設定は、特定のファイルに格納し、戻り値として返す形で設定することが求められます。
また、mason-lspconfigを使用している場合、新方式に書き換えることで全てのLanguage Serverを有効化することが可能です。nodeとdenoを自動で切り分ける方法についても言及されており、プロジェクトごとの設定が推奨されています。これにより、Neovim本体でプラグインなしでもLSPサポートを受けられるようになるとのことです。
さて、今日ご紹介した5本の記事を駆け足でおさらいしますと、AIエージェントを利用した開発プロセスやフロントエンドのリプレイスの現状、Devinの導入によるエンジニアリングの効率化、MCPの通信手法、Neovimの設定変更に関する内容をお届けしました。
次回またお会いできるのを楽しみにしています！詳しい内容はショーノートに書いてありますので、ぜひチェックしてくださいね。番組の感想もお待ちしています！それでは、また！