スクラムのスプリント計画で「このチケット、見積もりが毎回ブレる」と感じているなら、タスクの粒度設計そのものを疑う価値があります。
AIエージェント（人の指示なしである程度自律的に作業を進めるAIの仕組み）を個人で自作する方法が、チャット型・自動化型・実行型の3つに整理されて紹介されています。この分類は単なるツール選びの話にとどまらず、開発チームが日々行っている「作業をどう切り分けて誰に（何に）任せるか」という設計判断と驚くほど重なります。見積もりの精度や技術的負債との付き合い方を考え直したいエンジニアリングマネージャーやスクラムマスターの参考になれば幸いです。
3つの自作方式が意味する「任せ方」の違い
チャット型は、GeminiやClaudeのスキル機能を使い、対話の中で専用のアシスタントを作る方式です。手順は、任せたい作業を指示文として書き出し、名前・説明・指示を登録し、チャットで呼び出すだけという4ステップで完結します。これは人に例えると、口頭で依頼内容を伝え、その都度確認しながら進めてもらうやり方に近いイメージです。
自動化型は、n8nやDifyといったツールで、決まった作業（例えば情報収集やデータ整形）を自動で回す方式です。トリガーとなる条件を決めておけば、人の判断を挟まずに処理が流れていきます。スクラムで言えば、定型的なルーティンタスクをCIパイプラインに任せる発想と同じ構造です。
実行型は、Claude CodeやCodexのようなコーディングエージェントに、より大きな裁量を持たせて作業させる方式です。指示は抽象度が高くても、エージェント側が計画を立てて実行まで担います。3方式の違いは「どこまで人が手順を細かく定義し、どこからAI（あるいは実行者）の裁量に委ねるか」という境界線の引き方の違いだと言えます。
方式選びの前提にある「作業の切り方」という設計判断
ここで重要なのが、自作に入る前に決めるべきこととして挙げられている「任せる作業を1つに絞る」という原則です。欲張って複数の作業を1つのエージェントにまとめようとすると、指示があいまいになり、結果の検証も難しくなります。
これはスクラムにおけるタスク分解（ユーザーストーリーを実装可能な単位まで砕く作業）の失敗パターンと同じです。1つのチケットに複数の関心事を詰め込むと、見積もりの精度が落ち、レビューの焦点もぼやけます。INVEST（独立している・交渉可能・価値がある・見積もり可能・小さい・テスト可能という6つの頭文字を取った基準）という有名なチェックリストがありますが、「1つに絞る」という考え方はこのINVESTの「小さい（Small）」と「独立している（Independent）」の2条件に直結します。
もう1つの前提が「AIに任せる範囲と人が確認する範囲を分ける」という線引きです。これはスクラムの「完了の定義（Definition of Done）」の設計と同じ構造の問題です。完了の定義が曖昧なチームほど、レビュー工数が膨らみ、見積もりと実績の乖離が大きくなる傾向があります。AIエージェントに作業を任せる場合も、どこまでをAIの成果物として受け入れ、どこから人のレビューを必須にするかを先に決めておく必要があります。
既存の開発プラクティスとの対応関係
チャット型・自動化型・実行型という3分類は、開発チームが既に扱っている概念の言い換えとしても読めます。
| 自作方式 | 対応する開発プラクティス | 見積もりへの影響 |
|---|---|---|
| チャット型 | ペアプログラミング・対話的なレビュー | 都度確認が入るため見積もりは安定しやすい |
| 自動化型 | CI/CDパイプライン・定型バッチ処理 | 初期設計の工数は見えにくいが運用は安定 |
| 実行型 | 裁量の大きいタスク委任 | 見積もりのブレ幅が最も大きくなりやすい |
この対応関係を踏まえると、実行型に近いタスク（裁量が大きく、完了条件があいまいなもの）をスプリントに積むときほど、バッファを厚めに取る判断が妥当だと分かります。逆にチャット型・自動化型に近いタスク（手順が明確で確認ポイントが決まっているもの）は、見積もり精度が高く出やすいタスクだと判断できます。
今日チームで確認できること
実際に自分のチームのバックログを見返すときは、次の観点で棚卸しをしてみるとよさそうです。
- 各チケットが「任せる作業を1つに絞る」原則を満たしているか（複数の関心事が混ざっていないか）
- 完了の定義（Definition of Done）がチーム内で言語化され、全員が同じ基準でレビューしているか
- 見積もりが頻繁にブレるタスクは、実行型（裁量大・確認ポイント不明瞭）の構造になっていないか
- 定型的に繰り返す作業（自動化型に相当するもの）が、手作業のまま残っていないか
この棚卸しは、スプリントレトロスペクティブ（スプリント終了後の振り返り会）の議題に組み込みやすい内容です。例えば「見積もりが2倍以上ズレたチケット」を抽出し、それが実行型寄りの構造だったかどうかをチームで確認するだけでも、次のスプリント計画の精度向上につながります。
技術的負債との折り合いという観点では、自動化型の仕組み（n8nやDifyのようなワークフロー自動化ツール）を導入する判断基準も参考になります。決まった手順を何度も繰り返しているタスクがあるなら、それは自動化による負債解消の候補です。一方で、判断や裁量が必要な作業を無理に自動化・単純なルールに落とし込もうとすると、かえって例外処理が増え、新たな負債を生む結果になりかねません。
まとめ
AIエージェントの3つの自作方式は、ツール選びの話であると同時に、開発チームが日常的に行っているタスク設計・裁量の線引きの縮図でもあります。
次のスプリント計画の前に、バックログのチケットを「1作業1チケットになっているか」「完了の定義が明確か」の2軸で棚卸ししてみることから始められます。定型作業が手作業のまま残っていないかも合わせて洗い出すと、技術的負債の優先順位付けにも役立ちます。