「AIにタスクを切らせて、人間にレビューさせる」が回らない理由
最初に試した方法から書きます。シンプルな発想で、私たちのチームでも最初はこれをやりました。要件をAIエージェントに渡してタスクを分解させ、AIに実装させ、人間がレビューする——これでスケールするはず、と。
回りませんでした。
理由は3つあります。
1つ目。AIが分解したタスクは、表面上は綺麗に見えても、「なぜそれをやるのか」が抜けていることが多いんです。「Aコンポーネントを実装する」とは書いてあっても、「なぜAコンポーネントなのか、Bじゃダメな理由は何か」が言語化されていません。人間がレビューに入ったとき、コードの正しさは判断できても、設計判断の妥当性は判断できなくなります。
2つ目。AIに実装させると、PRが2〜3倍の速度で上がってきます。1日1PRだった私のチームが、気づくと1日10PRになりました。レビュアーが律速になります。レビューが詰まったPRはコンフリクトを起こし、コンフリクトを解消したつもりがロジックがズレ、結果としてレビューに2倍時間がかかります。AIの速度をレビュー速度が追えません。
3つ目。AIがタスクを処理したログは、コードの中には残るけど、議論として残らないんです。なぜそのライブラリを選んだか、なぜそのデータ構造にしたか、AIに聞けば答えてくれるけど、その答えはチームの共有資産にはなりません。半年後に「なんでこの設計だったっけ」と振り返ったとき、ナレッジが空白になります。
つまり、AIエージェントは「実装の速度」だけを上げてくれて、「設計の意図」「レビューの帯域」「ナレッジの蓄積」は逆に圧迫します。タスク管理側がここに対応していないと、開発スピードは上がるどころか、半年でチームが疲弊します。
AIコーディングエージェントが現場に入って起きた4つの変化
もう少し具体的に、何が変わったかを書きます。私自身のチームと、知り合いの開発チームから聞いた話を混ぜています。
変化1：PRの量が2〜3倍になる
これが一番分かりやすい変化です。CursorのエージェントモードやClaude Codeのサブエージェント機能を使うと、人間1人が同時に複数のタスクを走らせられます。チーム全体のPR量は、ざっくり2〜3倍になります。
問題は、PRの数が増えてもマージできる数は増えないことです。マージにはレビューが必要で、レビューには人間の時間が必要です。PR数だけが増えると、滞留が起きます。
変化2：タスクの粒度が「実装単位」から「意図単位」にシフトする
人間にタスクを振るときは、「○○ファイルの△△関数を修正」というレベルまで分解する必要がありました。AIに振るときは、もっと抽象度を上げないと逆に動きません。「ユーザーがログイン状態を維持できないバグがあるから、原因を調べて直して」と書いたほうが、AIの強みが出ます。
これは、人間に振るタスクとAIに振るタスクで、書き方が変わるということです。同じタスクボードに混ざっているのに、書き方のルールが2系統必要になります。ここを意識せずに混ぜると、人間に振ったタスクは雑なまま放置され、AIに振ったタスクは細かすぎて窮屈になる。両方ハマりました。
変化3：レビューが律速になる
これは変化1の帰結ですが、独立して書きます。レビューが詰まると、チーム全体が止まります。AIが10件のPRを上げても、レビュー待ちで全部止まっていれば、合計の前進距離はゼロです。
私のチームでは、PR滞留を可視化するために「マージ済み」と「レビュー中」を分けて表示するようにしました。これだけで、滞留が見えなかった頃と比べて、レビューに使う時間の優先度が変わりました。
変化4：ナレッジが「コードの中」と「議事録の中」に二極化する
AIエージェントが書いたコードは、コミットメッセージやコメントの形でリポジトリに残ります。一方の人間側はというと、設計を議論したログはたいていSlackか議事録の中。場所が分かれます。
この2つが繋がらないんです。半年後に「なぜこの設計にしたか」を調べると、コードからは判断の結果しか分からず、議事録は探し出せません。AIが書いた量が増えるほど、この乖離は大きくなります。
AIと人間で分担するときの3つのアンチパターン
ここから、現場でハマりがちなアンチパターンを書きます。私自身、全部やりました。
アンチパターン1：AIを「無限に動く新人」として扱う
最初の頃、私はAIエージェントを「コストの安い新人エンジニアが何人もいる状態」だと思っていました。指示すれば動く、失敗しても気にしなくていい、無限に依頼できる——という発想です。
これが落とし穴でした。AIは新人と違って、振り返って成長しません。同じ失敗を、別のセッションで繰り返します。タスクを振れば振るほど、レビューと修正のコストが膨らみます。新人なら「これは前にも言ったよね」が効きますが、AIには効きません。次のセッションでも同じ間違いをします。
対処は、「AIには毎回ゼロから状況説明をする前提で設計する」ことです。長期的な暗黙知に依存するタスクは、AIに任せにくいと割り切ったほうが楽でした。
アンチパターン2：タスクの「Why」を書かないままAIに振る
これは現場で一番起きやすいパターンです。Slackで雑に「○○のバグ直しといて」とAIに投げる。AIは指示通り直します。でも、「なぜそのバグが致命的なのか」「直したら他に影響しないか」を判断していません。
人間の新人エンジニアなら、ピンとこない指示には「これって何のためですか」と聞き返します。AIは聞き返さないので、Whyが抜けたまま実装が進みます。結果として、表面のバグは直っても、本当の原因はそのまま、というケースが頻発します。
対処は、「タスクのWhyを必ず1行書いてからAIに渡す」運用ルールです。たった1行ですが、これがあるかないかで仕上がりが大きく変わります。
アンチパターン3：レビューを後回しにしてPRを溜める
AIが速くPRを上げると、人間側は「あとでまとめてレビューしよう」と思いがちです。これがダメです。
溜まったPRは、互いに干渉します。AがマージされるとBで衝突が起き、Bを直すとCで動かなくなります。レビューと修正の往復が指数関数的に増えます。私のチームで一度これをやってしまい、3日かけて20PRをマージするはずが、結局5PRしかマージできずに残り15PRは捨てる、という事態になりました。
対処は単純で、「PRは上がったらその日のうちにレビューする」を徹底することです。AIに任せるタスク数を増やすときは、人間のレビュー帯域を先に確保します。
小さなチームが取るべき4つの設計
ここからは、設計の話です。私たちのチームで実際に試して効いたもの、効かなかったものを混ぜて書きます。
設計1：タスクは「実装内容」ではなく「狙い」で書く
タスクのタイトルと説明文を変えました。今までは「○○APIにエンドポイントを追加」のような実装ベースの書き方でした。これを「ユーザーがマイページから直接プロフィール画像を変更できるようにしたい。理由：問い合わせの12%がこの操作の質問だから」のような書き方に変えました。
人間が書くときも、AIに振るときも、このフォーマットは効きました。地味な副産物として、狙いを書こうとした瞬間に「そもそもこれ要るんだっけ」が頭をよぎる回数が増えます。実装に入る前にタスク自体が消えることが、月に2〜3件は出るようになりました。
設計2：AIエージェント用のサブタスクを人間タスクと同じボードに置く
これは試行錯誤の結果、辿り着いた形です。最初は人間タスクとAIタスクを分けたボードにしていましたが、結局誰が何をやっているかが見えなくなりました。
今は、人間タスクの下に「AIに任せたサブタスク」をぶら下げる構造にしています。親タスク（狙い）は人間、子タスク（実装）はAI、というシンプルな親子関係です。「Aさんが見ている機能のうち、どこをAIが書いているか」が同じ画面で見えるだけで、口頭の確認がだいぶ減りました。
設計3：レビュー＝マージではなく、レビュー＝学習の場として残す
レビューコメントは、コードに対する指摘ですが、同時に「なぜこの判断をしたか」の議論でもあります。AIが書いたコードでも、人間がレビューする中で「なるほど、ここはこの設計のほうがいいな」という発見が出ます。
その発見を、PRに閉じ込めずに、ナレッジとして残す動線を作りました。私たちのチームでは、レビュー中に出た「次回からこうしよう」というコメントを、月末にまとめて社内ナレッジに転記しています。AIが書いた量が増えるほど、この転記作業の価値が上がります。
設計4：振り返りで「AIに任せて失敗したシーン」を必ず1つ言語化する
スプリント振り返りに新しい欄を足しました。「今スプリント、AIに任せて失敗したケース」を1つ書く欄です。
ここに書かれる内容が面白くて、「複雑なドメインロジックを丸投げしたら勘違いした」「セキュリティ要件をWhyに含めなかったら抜けた」「過去の実装パターンと違うやり方をされて、後から戻すコストが大きかった」みたいなパターンが見えてきます。AIの限界を、抽象論ではなく具体例で言語化すると、次のスプリントで誰が見ても同じ判断ができます。
GitHub・Linear・Jira・LOGLIKEを「AI共存」の観点で並べてみる
各ツールが、AIエージェントとの共存をどう設計しているかを並べます。素直に書きますが、それぞれ得意な領域が違います。
GitHub（GitHub Issues / Projects / Agent HQ）
GitHubは2026年にAgent HQ構想を発表し、複数のAIエージェントを統合管理する「ミッションコントロール」を作ろうとしています。リポジトリと地続きなので、エージェントがコードの文脈をそのまま読める強さがあります。逆に言うと、案件管理・顧客管理・請求といった、コードの外側の業務は守備範囲外。受託で顧客とのやり取りも同じ場所に置きたいチームには、別ツールがもう一つ要ります。
Linear
LinearはとにかくUIが速い。エンジニア向けに振り切っていて、GitHub連携も最初から噛み合っています。AIによるissue起票やステータス自動更新も入ってきました。機能を絞ってシンプルさを死守している作りで、小さな開発チームほど効きます。ただ、案件単位の利益や請求管理までは見ません。
Jira
Jiraはエンタープライズで強いです。AtlassianはJira RovoというAIエージェントを推しており、複雑なワークフローに沿った自動化ができます。一方、5〜20人規模の開発チームには重く、設定だけで1週間溶けることもあります。正直、5〜20人のチームでJiraを選ぶ理由は2026年時点ではほぼ思いつきません。
LOGLIKE
ここで自社の話に移ります。LOGLIKEは受託開発・自社プロダクト両方のIT・開発チームを想定して作っています。GitHubほどコードに密着してはいませんが、その代わり案件管理・顧客管理・請求書管理・ナレッジベースまで同じツールに揃えているのが特徴です。
開発タスクの裏側にある「どの顧客の、どの契約に紐づく案件で、いくらの請求が立つか」までを一つの場所で持ちたい受託開発チームには、選択肢としてフィットします。逆に、自社プロダクト一本で、コードレビューと密結合した運用がしたいチームには、GitHubやLinearのほうが薄くて速いです。自社の業務の重心が「コード寄り」か「案件寄り」かで、選ぶツールが変わる——これが私の実感です。
LOGLIKEを開発チームで使ってみるなら
ここまで書いてきた話を、自社のLOGLIKEに落とすとどこに当たるか。4つだけ書きます。
AI課題生成は、自然言語で書いた要件から課題を自動生成する機能です。タスク分解と工数見積もり、スケジューリングまでまとめて出してくれます。スプリント計画の最初に、雑な要件をAIに渡してドラフトを作らせ、人間がレビューして整える運用が回りやすいです。設計1で書いた「タスクを狙いで書く」を実践しやすくなります。
AI予告通知は、遅延リスクを予測して事前に通知する機能です。変化3で書いた「レビューが律速になる」問題に対する早期警報として置けます。レビューが詰まる前に動けるようになります。
AIと会議は、AIとの対話でプロジェクトを分析しつつ、議事録を自動生成する機能です。決定事項とTODOを整理する動線が組まれているので、変化4で書いた「議論が議事録の中に消える」問題に対して、議論→タスク→ナレッジの動線を一本化できます。
ナレッジベースは、設計3で書いた「レビューでの学びを残す」場所として使えます。案件と紐付けて保存できるので、「半年後にこの案件と似た案件が来たとき」に検索で拾えます。AIに任せた失敗ケースの蓄積場所としても機能します。
LOGLIKEの全体像と最新の機能一覧は製品ページにまとまっています。受託開発の現場や、自社プロダクトと並行して顧客案件も持つチームで、まずは触ってみたい方はデモのリクエストから実画面が見られます。
まとめ：AIに書かせるからこそ、人間の「意図の言語化」が値段になる
長くなりました。最後に1つだけ。
AIコーディングエージェントが現場に入って一番効いたのは、「仕事が減ったわけじゃなく、仕事の中身が入れ替わった」という感覚です。コードを書く時間は減りました。代わりに、何を書くべきか、なぜ書くべきか、書いたあと何を学ぶかを言語化する時間が増えました。
タスク管理ツールが今までと同じままだと、この変化を受け止めきれません。「実装の指示書」を作るためのツールから、「意図と判断の蓄積場所」を作るためのツールへ、設計の重心がずれていきます。
GitHub、Linear、Jira、LOGLIKE——どれを選ぶにせよ、選ぶ前に自社のチームで「AIに任せたいのは何で、人間が残したいのは何か」を1時間でいいので話し合うと、ツール選びが変わると思います。私たちのチームでは、これを話したことで、開発外の業務（顧客管理・請求・ナレッジ蓄積）まで含めた一元管理を選ぶ判断ができました。
便利なツールほど、便利になった先で何を残したいかを先に決めておくほうが、結局得をします。同じ景色を見ている開発チームの参考になればと思って書きました。