生成AIで仕事をどうにかして怠ける話

Transcript

1. 生成AIで仕事をどうにかして怠 ける話
2. 自己紹介 なまへ：にしむらてつ 趣味：スノーボード、クライミング、スキューバダイビング すんでるとこ：長野県 おしごと：ツクリンク Webエンジニア 好きな言語・技術：Rust, TypeScript, AIがんばります
3. 前提 関わっていること ツクリンクの仕様として、基本的にRailsがモノリスで動作してお り、一部のフロントエンドはReact Router v7へ移行中。その中 でチームで担当しているのが以下。 • Rails：非機能分野、CRM連携 • React Router v7：Railsフロントエンドの移行PJ チームのAI活用状況 正直まだ控えめな段階。。。 今日話すこと まだまだ使いこなせていないが、使ってよかった具体例とこれからの試み
4. 活用例①：問い合わせ対応 (before) 問い合わせを受ける 運用チームからの「この仕様どうなってる？」という質問 地道な調査 コードを追って調べる → 時間と集中力を消費 追加調査が必要 「このクラスってどの画面で使われてる？」「この処理ってどこから呼 ばれてる？」の確認が面倒
5. 活用例①：問い合わせ対応(after) Cursor Agentに質問内容を貼って回答させる コードのポイントや仕様の要約を得て、回答のたたき台 に 結構雑な質問でも着眼点は外さずに回答してくれる 調査の初動が速くなり、着手までの心理的ハードルが下がった
6. 活用例②：PRのテスト観点整理 背景： ツクリンクではリリース時に機能のオンオフを切り替えられる「リリーストグル」を採用して います。 リリーストグルは実装時に条件分岐コードを記述しますが、後にそのトグル部分を削除す るフェーズも存在します。今回はその削除するフェーズについてです。 大規模なリリーストグル削除は、複数のPull Requestに分割して対応しています。 削除するPRをリリースする前の動作確認は手動で実施しています。 各Pull Request（PR）が担当する機能に応じて、実施すべきリリース前テストの内容が異 なります。
7. 活用例②：PRのテスト観点整理 の変化 Before： • 各PRの内容を読んで「どの機能をテストするか」を判断 • 担当者以外にはわかりづらい構成 After： • CursorにPRのブランチ名を渡して「どの機能のテストをすべきか」を根拠とな るコードとともに回答してもらう • 機能A, Bの両方に関わることが明示されるなど、観点の発見に繋がった 👉 観点の洗い出しに役立ち、レビュー効率が向上
8. AI活用を前提としたPJの進め方 背景 RailsフロントエンドのReactRouter v7移行プロジェクトが進行中。 ゼロからの立ち上げのため、生成 AI活用を前提にプロジェクトを進行 ツクリンクでは、JIRAでタスク管理や進捗共有し、意思決定の背景、理由、選択肢を記録する ADR（Architecture Decision Record）を導入。 JIRAチケット作成 実装背景、対象コンポーネント、完了条件を定型フォーマットで記述。 AIによるチケット理解と実装 CursorがJIRA MCPを使ってチケットを理解し、実装計画の立案とコードを生成。 ADRへの実装背景記録 実装の背景や設計判断を ADRに記録することで、コードに文脈を残す。 人間による微調整とレビュー 生成されたコードを人間がレビュー・微調整。
9. 課題 できている点 ✅ツール理解：Claude / Cursor などツールの特性を理解して使い分けられている ✅ワークフロー統合：AIを日常業務に自然に組み込めている ✅精度と検証：AIの回答を過信せず、検証・再構成して使う姿勢がある イマイチな点 🤔プロンプト設計：明確な目的と前提条件を記載したプロンプトを意識して書 いているか できていない点 ❌応用拡張：MCP（Model Customization Protocol）やRAG、Agentsなど 高度な仕組みを理解し、可能性を探っているか
10. まとめ • AIを本格活用しなくても、少し使うだけで効果が出て業務が軽くなる。 • 課題はMCP、RAG等の仕組みやプロンプト設計等についての理解が足りて いない。 • 生成AI活用を前提とした開発サイクルの作り直すほうがよい 生成AIを受動的に使用しているとその課題は解決できないため危機感が日々膨 らんでいます