この記事はなに？
この記事では、現時点でのAIツールで確実に恩恵を受けるためには、
スコープを小さくすることで確実性を上げることが重要であるという考え方を紹介します。
扱わないもの
ツールの機能説明、チャレンジングなハック的アプローチのAIに自由に編集・参照させている memories.md ファイルや大きなタスクの context を自然言語でまとめておく issues.md ファイルや.cursor/rulesをAIに自動で修正してもらうなど
AI要約
丸投げせず、小さく刻むのがカギ！
💡 3つのポイント
1️⃣ プロンプトを工夫 - 明確に指示するが、手間をかけすぎない！
2️⃣ .cursor/rules でルールを設定 - 一貫性を保つ✨
3️⃣ タスクを小さく分割 - 実装計画 → テスト → 実装 の3ステップ！
ツールの進化を見つつ、最適な使い方を模索しよう💡
自己紹介（あなたは誰？）
株式会社グロービスのデジタルプラットフォーム部門のGLOPLA事業開発室のエンジニアです。
最近は設計周りの技術書を読み漁るのにハマっています。
↓↓↓ ちなみに、下記の記事の方と一緒に働いている者です。 ↓↓↓
おいでよ！GLOPLA事業開発室へ！🍂
前提
- ある程度複雑な業務コーディングを行っている場合
- AIに 大きなタスクは渡さない方が効果的かもしれない
- AIには、小さなユニットに分けてタスクを実行してもらう事で確実性を上げられそう
- Context を上手く渡せる方法が出てくれば覆るかもしれない
- 例えば、画面が見える、長期記憶がある、複雑なデバッグができるなど
なぜタスク分割が必要か？
- 処理時間が長くなる割に、期待したコードが得られない
• AIがコンテキストを適切に処理しきれず、間違ったコードが出力される。
• 特に大きなコードベースでは、AIが全体の整合性を保つのが難しくなる。 - エラーやテスト失敗のループに陥る
• AIが一度に多くのコードを生成すると、意図しないエラーが混入しやすい。
• テストが通らないまま修正のループに陥り、最終的に25 limitで終了することも。 - AIにコンテキストを正しく伝えるのが難しい
• 人間が適切にAIへ指示を出せる範囲には限界がある。
• スコープを小さくすることで、AIが理解しやすくなり、意図通りの出力を得やすくなる。
複雑なタスクはAIが思う結果を出さない
なぜか
人間が正しくAIに context を渡す事ができないからでは無いか？と考えます。
そこで、人間の context を渡す能力とコストがボトルネックになってしまうなら、一旦スコープを小さくして context を正しく渡せるようにしてみようという発想です。
(Anthropic CEOの語る「事前学習 + 強化学習」のモデルの登場か、Cursor等のアプリケーション側で優秀な memories 機能が備われば話は違うのかもしれませんね)
実装のポイント
- ユニットを小さく
- テストを先に書いて、成果物を明確に
まとめて実装が上手く行かない時の選択肢
LLMとツールの進化を信じてある程度のサイズ感の issue レベルのタスクをまるっと投げてみる。それも全然いいと思います。
ただ、その結果として「思うコードが上がってこなかった」となった場合に取れる選択肢として
- プロンプトをしっかり書く
-
.cursor/rulesで基本ルールを書いておく - 小さなユニットに分割してタスクを投げる
という選択肢があります。
1. プロンプトをしっかり書く
指示を明確に書くパターンです。
正直「これ、自分で実装した方が早くね？」となる典型例なので、ここはあまり力を入れないようにしたいと思っています。
ただ、この後の 「3. 小さなユニットに分割してタスクを投げる」 という選択肢を使う際にも有効なので、できるだけ楽をする方向性でこれに取り組むならどうするかを考えたいと思います。
↓↓↓ 楽をしよう ↓↓↓
1度のAIへの指示はこのくらい
@issues.md をやっている
spec のケースを洗出して
@spec-rules.md に従って
issueやEpicで複数のcommit, PRに分けると思うので、それらで横断して知っておくと良い情報や計画を作成しておく
- 毎回入力する必要がなくなる
- chatでも、agentでも、command + Kでも横断して情報を伝えられる
## やりたいこと
- {issue number}
- {具体的に達成したいこと}
## How
- {どうやって達成したいか}
- {どんな順番でやりたいか}
- {どこを修正したいか}
## 背景情報
- {前後の実装}
- {先送りにする課題}
2. .cursor/rules で基本ルールを書いておく
先ほどのプロンプトで参照していた @spec-rules.md に従って もrulesです。
自動で読み取ってくれますが、明示的に指定するのも結構有効です。
特に設計思想や書き方系は、「違うな」と思うたびに微調整していくのをおすすめします。
- Backendのライブラリや設計思想
- Backendの specの書き方・実行の仕方
- Frontendのライブラリや設計思想
- Frontendの specの書き方・実行の仕方
- Linterの基本・実行の仕方
- Pull Requestの書き方
- Directory構成の説明（treeで用意しておく）
3. 小さなユニットに分割してタスクを投げる
基本的には以下の3つ（実装計画、テスト、実装）に分けてAIにタスクを依頼して、その中でさらにメソッド毎などユニットの数が多ければ、その数分だけ分割していきます。
ex: Agent に任せる
- 実装計画を立てる (Chat with o3-mini, deepseek-r1)
- 項目の value を計算する method or class を雑に作る（手動 + Tabが多い）
- テストケースを出す（Chat with gemini-2.0-flash, claude-3-5-haiku）
- テストが通るまで実装を繰り返す（Agent with claude-3-5-sonnet）
ex: Chat Apply 多めパターン
Premium Request を節約したり、もっと人間がコントロールしたいんだ。という場合におすすめ
案外 Agent を使わなくても大きな恩恵は得られます。
- 実装計画を立てる (Chat with o3-mini, deepseek-r1)
- 項目の value を計算する method or class を雑に作る（手動 + Tabが多い）
- ユニットテストのケースを出す（手動 + Chat with gemini-2.0-flash, claude-3-5-haiku）
- ユニットテストの実装（Chat with o3-mini, deepseek-r1）
- ユニットの実装（Chat with o3-mini, deepseek-r1）
- テストを回す（手動）
- 問題が有れば修正（手動 or command + K）
余談: 「FrontendはAI開発の効果が上手く出ない」
これもタスクの粒度が大きいんじゃないかな？と思っていたりしています。
- Precentation層の見た目だけ実装
a. Figma と 現状のスクショ を渡して大枠 マークアップ と Style を作成(Agent)
b. UIの修正（手動 - ここはまだ無理ぽよですね） - Storybookの作成
a. 欲しいケースを書き出す（手動）
b. Storyの作成（Chat with o3-mini, deepseek-r1） - Container層の実装
a. APIとのつなぎ込みの実装大枠（手動 + Tab）
b. （責務毎に小さく切り出していく） - 振る舞いの実装切り出し（hooksや純粋関数へ切り出し）
a. hooksや純粋関数へ大枠を切り出し
b. specのケース出し（手動 or Chat with o3-mini, deepseek-r1）
c. 実装 & テスト（Agent with claude-3-5-sonnet） - 必要なテストの追加（ハッピーパスや振る舞い込のUIテストが有れば）
- リファクタリング（構造を整える）
あ〜、なるほど
書いてみて、確かにRailsの基本的な実装と比べると手作業が多いのは同意ですね。
でも構造を整えたりするのが面白いので、美味しいところは自分でやれるから個人的にはそれはそれでいいかな〜？と思ったりしました。
マークアップやスタイルが苦手なので、基本の大枠をゴリッと作ってもらえるのはとても嬉しいです。また、スクショを限定的にして、ここの Component ですよとスコープを小さくしてあげないとトンチンカンな修正を入れてくるので注意は必要
もし改善されるなら、下記が満たされれば行けるのかもしれませんね〜。
- AIがブラウザを見れる
- 構造やコーディングルールを完全に固めて渡し切る
MCPサーバーで実現する可能性とか、コーディングルールガチガチにして、Hygenでテンプレート固められる範囲の実装ならある程度は行けるかも、、、ですがROI考えてコストに見合わないとか起こりそうですね。
余談: 「RailsのSpecが通らない」
Modelの spec とか、letやbeforeで色んなデータの状態を作っておかないと通せない系のテストが難しいですよね。
これこそ完全に context を上手く渡せていない居ないの典型例だと思います。
解決策は、下記くらいですかね？
- 責務をできるだけ小さくする
- 似たデータセットのテストを参考に渡す
- Chat + Codebase + o3-mini, deepseek-r1 で不足しているデータセットを見つける
まあ、責務を小さくするの頑張れって感じなんでしょうが、、、（ひぇ
クリーンアーキテクチャ読みます
まとめ - どの粒度を任せるか
長々と書きましたが、TDDをしていたり、普段から小さくcommitやPRを分けて実装をしていれば当たり前のようにやっている粒度の切り方のどこをAIに任せるかというだけの話です。
「AIに全部やってもらおう！」とするには、人間が「何をして欲しいか」を分かっていて、伝えられる必要があり、AIの能力の向上に対して、ツールと人間の cotext を伝える能力が追いついていないのと、コストが上手く合わないために発生している中間状態だなという話です。
ツールの進化でこのラインは一気に変わる可能性があるので、実務で恩恵を受けつつ、時々実験がてらAIの可能性を信じる実験をしていくのがちょうどいい付き合い方かな〜？と思います。
Discussion