コーディングエージェントとの付き合い方

Transcript

1. コーディングエージェントとの付き合い方 任せる・一緒にやる・自分でやる PRESENTATION SLIDES [ ver.01 2026.03 ] MOSH develops and operates a platform that supports independent creators in selling their services online. © MOSH, Inc.
2. © MOSH, Inc. 真部 拓未 MOSH 株式会社 プロダクト開発部 ページビルダー& ワークフローの開発 TypeScript, React, CSS 好き Claude Code 歴: 2025 年7 月〜 Nabe847
3. 作業を始める前に 明確なプランを立てる © MOSH, Inc.
4. 明確なプランを立てる コードベースの現状はどうなっているか ゴールは何か（実装が完了したとき、プログラムの振る舞いはどう変わるか） どこを、どう変更するのか、依存関係やインターフェースはどうするのか なぜ？ 理解が甘くてもその部分をAI が補ってとりあえず動くものが生成される 微調整が多くなるにつれてAI の速さの恩恵と自分の集中力が削られていく 大体良さそうだけど何か変、みたいな状態から問題点を探すのは大変 コーディング以外に、調査や実験などプランニングに必要な作業にもAI は使える → 曖昧さを排除して無駄が生まれる可能性をできるだけ減らすことが大事 © MOSH, Inc.
5. プランの例 # タスク指示書: ワークフロー機能にライセンス上限エラーダイアログを追加 ## 概要 ワークフローの特定操作でAPIから `403 QUOTA_EXCEEDED` エラーが返った場合、ライセンス上限に達したことを示すダイアログを表示する。 ## 作業内容 ### 1. ダイアログコンポーネントの新規作成 ファイル: `src/components/quota-error-dialog.tsx` コンポーネント名: `QuotaErrorDialog` **仕様:** - ベースコンポーネント: `src/components/dialog.tsx` - ヘッダー: `ライセンスの上限に達しました` - 「あとで」ボタン → ダイアログを閉じる - 「ライセンスを見る」ボタン → 外部リンク（`<Button asChild><a href="#">ライセンスを見る<ExternalLink /></a></Button>`） - リンク先は仮で `#` **本文:** """ 上限を増やすにはライセンスをアップグレードしてください。 または不要なワークフローをアーカイブしてください。 """ ### 2. ダイアログのレンダリング `src/routes/workflows/workflow-list.tsx` の `WorkflowList` コンポーネント内に `QuotaErrorDialog` をレンダリングする。 - `WorkflowList` で `QuotaErrorDialog` の表示状態（open/close）を管理する - 複製・アーカイブ解除の操作時は、子コンポーネントからのイベントハンドラ経由で `WorkflowList` 側のダイアログ表示状態を変更する ### 3. 403エラーハンドリングの追加 以下の3操作のAPI呼び出し箇所で、`403 QUOTA_EXCEEDED` エラー時にダイアログを表示するハンドリングを追加する。 | 操作 | 表示するダイアログ | | ---- | ------------------ | -- 省略 -- © MOSH, Inc.
6. Agent Skills を使ってプランの精度を上げる --- name: grill-me description: 計画や設計について共通理解に達するまで容赦なく質問し、決定ツリーの各分岐を解決する。「grill me」と言われたときに使用する。 --- この計画のあらゆる側面について、共通理解に達するまで容赦なく質問する。決定ツリーの各分岐をたどり、決定間の依存関係を一つずつ解決する。各質問に対して、推奨する回答を提示する。 コードベースを調査すれば回答できる質問は、質問する代わりにコードベースを調査する。 引用元: https://www.aihero.dev/5-agent-skills-i-use-every-day --- name: dry-me description: この計画や設計・実装をDRY原則の観点で評価する。「dry me」と言われたときに使用する。 --- この計画や設計・実装をDRY原則の観点で評価し修正する。特に同種の修正が複数箇所に必要な場合は根本原因を特定し、個別に修正するのではなく一箇所で解決する。 © MOSH, Inc.
7. プランの実行 状況に応じて方法を変える © MOSH, Inc.
8. 3 つのパターン パターン 使いどころ 1. AI に任せる 既存機能の拡張などパターンがある程度決まっているもの 2. AI とペアプロ 新機能・リファクタリング・不具合調査など 3. 自分でやる 理解を深めたいとき、書きたいとき © MOSH, Inc.
9. 1. AI に任せる プルリクエスト作成まで一気に実行 TAKT （TAKT Agent Koordination Topology ） を使 って複数のコーディングエージェントを協調させな がら実装する name: plan-implement-review initial_movement: plan max_movements: 10 movements: - name: plan persona: planner edit: false rules: - condition: Planning complete next: implement - name: implement persona: coder edit: true required_permission_mode: edit rules: - condition: Implementation complete next: review - name: review persona: reviewer edit: false rules: - condition: Approved next: COMPLETE - condition: Needs fix next: implement # ← fix loop © MOSH, Inc. 引用: github.com/nrslib/takt
10. 2. 一緒にやる / 3. 自分でやる 一緒にやる — AI とのペアプロ 新機能の実装、新しいライブラリを使う場合など リファクタリングや不具合の調査などで結論がまだ見えていない場合 エージェントに逐次的に指示を与えながら探索・コーディング 自分でやる — 手書き 指示を出すよりやった方が早いとき（ちょっとした修正など） コードの理解を深めたいとき 細かいスタイルにこだわりたいとき © MOSH, Inc.
11. レビューと動作確認 レビュー チームメンバーにレビュー依頼を出す前に 自分 + AI エージェント でレビュー Devin × 1 、Claude Code × 2 （レビュー観点をskill にまとめておく） エージェントごとに観点の異なるプロンプトを与えたり、エージェント同士が連携するようにする 良いかもしれない 先にAI のレビューを通して人間の負担を減らす 動作確認 ステージング環境で人間が実施 スクリプト生成やAI による自動化など試行錯誤中 © MOSH, Inc.
12. 新しい課題 速くなったことで見えてきたもの © MOSH, Inc.
13. 新しい課題 1. 意思決定が間に合わない 実装待ちより実装するものが決まっていないことが増えてきた 文書化しきれていない情報も多いのでAI の支援も受けづらい 2. レビューの負担増 コード量が増えた。特にテストコード AI にレビューを手伝って貰っているがそれだけでリリースするのはまだ現実的ではない レビュー指摘対応の自動化、レビュー対象の解説の生成などで人間の負担を減らす方法を模索中 3. 動作確認の負担増 プロダクトの性質的に自動化が難しい（外部サービスとの連携、自由度の高いUI ） © MOSH, Inc.
14. まとめ 1. 明確なプランを立てる 2. 状況に応じてコーディングの方法を変える 3. 意思決定・レビュー・動作確認の負担増など課題が出てきた © MOSH, Inc.