agkan + agkan-skills + Claude Code /loop で、開発者の仕事が「タスク積み＆レビューだけ」になる話
「AIに仕事を任せる」という話は何年も前からあった。しかし実際にやってみると、結局は人間がプロンプトを打ち込んで、出力をコピペして、次の指示を与える——という繰り返しになる。これは「支援を受けている」だけで、「任せている」とは言いがたい。
本当に「任せる」とはどういうことか。その答えが、agkan × agkan-skills × Claude Code /loop の組み合わせにある。
この構成を使い始めてから、agkan自体のソフトウェア開発における人間の作業が劇的に変わった。IssueのトリアージからBacklogの整理、タスクの実装、PRの作成、レビュー状態の自動クローズ——これらがすべて自動で回り続けている。人間がやることは、タスクを積むこととPRをレビューすることだけだ。
この記事では、その仕組みの全体像と、実際の動かし方を具体的に解説する。
背景：なぜ「ループ型AI自動化」が今重要なのか
「一発プロンプト」時代の限界
Claude CodeやGitHub Copilotが普及した2024〜2025年、多くのエンジニアが「AIを使って生産性が上がった」と感じた。確かに上がった。しかしそれは「補助輪付きの自転車」の段階だ。
AIが一度に処理できるコンテキスト量は増えた。しかし「継続的に・自律的に・繰り返し」動き続ける仕組みを持っているツールはまだ少ない。人間が起動し、人間が次の指示を出し、人間が結果を確認する——このフローは本質的に変わっていない。
転換点：スケジュール実行とタスクキュー
2025年後半から2026年にかけて、変化の兆しが出てきた。
| 年月 | 変化・出来事 |
|---|---|
| 2024年5月 | Claude CodeがAIコーディング支援としてリリース。「一発プロンプト型」が主流に |
| 2026年2月18日 | agkan v1.0.0リリース。AI協働に最適化されたCLIタスク管理が登場 |
| 2026年2月25日 | Claude Codeのスケジュール実行（/loop）を活用した自律ループが現実に |
この3つのタイムラインが重なったのが、今まさに起きていることだ。
論点1：agkanとは何か、なぜAI協働に向いているのか
agkan は TypeScript製のCLIタスク管理ツールだ。SQLiteをローカルストレージとして使い、タスクのステータス・親子関係・依存・タグを一元管理する。
一言で言うと「人間とAIが共有するカンバンボード」だ。
前提: Node.js 18以上が必要。
npm install -g agkan
agkanのステータス管理
agkanは7段階のステータスでタスクを管理する：
icebox → backlog → ready → in_progress → review → done → closed
この流れが重要なのは、AIがCLIコマンドでステータスを自律的に更新できる点だ。
# タスク一覧をJSON形式で取得（AIが読み込みやすい形式）
agkan task list --status ready --json
# タスクを着手中に更新
agkan task update <id> status in_progress
# 作業完了
agkan task update <id> status review
--json フラグで出力するとClaude Codeがそのままパースして次のアクションを決定できる。これが「AIが自律的に動ける」理由だ。
なぜ既存のタスク管理ツールではダメか
NotionやJiraでもタスク管理はできる。しかしこれらはMCPなどの特別な連携設定が必要で、CLIから即座に読み書きするには冗長な設定が必要になる。
agkanはそもそも「AIエージェントが読み書きすること」を前提に設計されている。このコンセプトの差が、実際の自動化フローでは大きく効いてくる。
筆者の経験: Notionタスクとagkanを両方試したが、agkanの方がAIエージェントとの連携コードが圧倒的にシンプルになった。Claude Codeのスキルファイル内でタスク取得から更新まで5行以内で書ける。
論点2：agkan-skillsとスキル定義の考え方
agkan-skills は、agkanに渡すスキル定義を集めたリポジトリだ。
スキルとは「Claude Codeに何をやらせるかの定義ファイル」だ。Markdownベースで記述し、Claude Codeがこれを読んで自律的に作業を進める。
スキルファイルの構成例
agkan-skillsには、開発ワークフローに対応したスキルが揃っている。たとえば agkan-run スキルの意図はこのように書かれている：
# agkan-run
## 概要
agkanのBacklogからReadyなタスクを1件選択し、実装してPRを作成する。
## 手順
### 1. タスク選択
- agkan task list --status ready --json でタスクを取得
- 優先度・依存関係を考慮して1件を選ぶ
- agkan task update <id> status in_progress
### 2. 実装
- タスクの内容を読み、コードを変更する
- テストを実行して通過を確認する
### 3. PR作成
- ブランチを作成してコミット・プッシュ
- PRを作成してagkan task update <id> status review
このスキルファイルをagkan-skillsリポジトリで管理し、バージョン管理する。「スキルを改善する」というのは、このMarkdownを書き直してコミットするだけだ。
スキルの設計思想
重要なのは、スキルは「やり方の手順書」ではなく「何を達成するかの意図書」として書くことだ。
細かい実装（どのAPIを叩くか、どのファイルに保存するか）はClaude Codeが判断する。スキルには「なぜやるか」「何を達成するか」「どう判断するか」を書けばよい。
実装の詳細まで書くと、環境が変わったときにスキルの書き直しが必要になる。意図を書いておけば、Claude Codeが状況に応じて最適な方法を選ぶ。
論点3：Claude Code /loop で「人が起動しない世界」を実現する
Claude Codeのスケジュールタスク機能、通称 /loop は、2026年に登場した。
/loop を使うと、Claude Codeが指定した間隔やトリガーで自律的にタスクを繰り返し実行する。プロンプトがアイドル状態のとき（人間が操作していないとき）に、バックグラウンドで動き続ける。
/loop の動作イメージ
/loop 1d /agkan-run
これを設定しておくと、24時間ごとに agkan-run スキルが自動で走る。インターバルは 5m（5分）〜1d（1日）の形式で指定できる。人間が起動する必要はない。
/loop でできること・できないこと
できること:
– BacklogのReadyタスクを自動選択・実装・PR作成（agkan-run）
– Backlogタスクの分解・優先順位整理（agkan-planning）
– Review状態のタスクをGH PRと照合してdone/closeに自動更新（agkan-review）
– Iceboxタスクのレビューとbacklog昇格判断（agkan-icebox）
– 依存パッケージの更新PRを定期生成
注意点:
– /loop はプロンプトがアイドルのときのみ実行される（作業中は止まる）
– Claude Codeのセッションが生きている間のみジョブが有効。セッションを終了するとジョブは消滅するため、常時起動環境（VPSなど）が前提になる
– スキルが長時間かかる場合、タイムアウトの設定が重要
– 外部APIのレート制限を意識したスキル設計が必要
メリット側の意見:
– 人間の作業時間に関係なく24時間動ける
– 起動し忘れがなくなる
– スケジュール管理コストがゼロになる
懸念側の意見:
– スキルに誤りがあると誤った処理が繰り返される
– 外部APIコストが積み上がる可能性がある
– 何が動いているか把握しにくくなる
筆者の見解: 懸念はすべて「スキルの品質管理」に帰着する。スキルをgitで管理し、変更前にレビューする習慣をつければ、リスクは許容範囲に収まる。むしろ「手動で毎日実行し忘れる」コストの方が、長期的には大きい。
実際の現場ではどうか
ケーススタディ: agkan自体の開発をagkanで回す
状況・背景:
agkanはOSSのCLIタスク管理ツールだ。機能追加・バグ修正・依存更新といった開発タスクが継続的に発生する。以前は「IssueをBacklogに移す」「タスクを選んで実装する」「PRを作成してレビュー待ちにする」という一連の作業をすべて手動でこなしていた。
皮肉なことに、AIエージェントとの協働を前提に設計したツールの開発を、自分たちは手動でやっていた。
取った行動・判断:
agkan-skillsのスキルを /loop に登録した。
| スキル名 | 実行タイミング | 内容 |
|---|---|---|
agkan-run |
常時ループ | ReadyタスクをBacklogから選択・実装・PR作成 |
agkan-planning |
毎日 | Backlogタスクの分解・優先順位整理 |
agkan-review |
常時ループ | Review状態のタスクをGH PRと照合してdone/closeに更新 |
agkan-icebox |
週次 | Iceboxタスクをレビューしてbacklog昇格か削除を判断 |
結果・学び:
「タスクをBacklogに積む → PRが上がってくる → レビューする」というサイクルが自動で回り始めた。人間がやることはタスクの定義とPRレビューだけになった。
重要な発見は、スキルの品質が上がるにつれて、人間のレビュー時間も短縮されることだ。最初は「このPRは意図と違う」とフィードバックしてスキルを改善する。数サイクル回すと、精度が上がって確認がほとんど不要になる。
また「agkanの開発にagkanを使う」というドッグフーディングの構造が、ツール自体の改善にも直結した。使いにくい点がすぐに自分たちのタスクとして積まれ、スキルを通じて修正されるフィードバックループが生まれた。
3つを組み合わせたフルループの構成
全体の流れを整理すると以下のようになる：
人間（タスクをBacklogに積む）
↓
agkan-skills（スキル定義をgitで管理）
↓
agkan（CLIでタスクキューを管理）
↓
Claude Code /loop（自律ループで実行）
↓
agkan-run: タスク選択 → 実装 → PR作成 → review状態に更新
↓
agkan-review: GH PRのマージを検知 → done/closeに自動更新
↓
人間（PRレビューのみ）
↓
（改善があればスキルをcommit）
このループの中で「人間が操作する」ポイントは2箇所だけだ：
-
タスクをBacklogに積む（何を実装するかをagkanに登録する）
-
PRをレビューする（Claude Codeが作成したPRを確認してマージする）
それ以外はすべて自動で回る。夜中にも回る。週末にも回る。
さらに先の可能性
現在検証中のアプローチとして、「考えるべき事柄を与えるプロンプトだけ出して、AIが自ら改善するタスクを生み出す」というループもある。
たとえば「コードベースの技術的負債を分析して、改善タスクを提案せよ」というメタスキルを設定する。すると Claude Codeが「こういうリファクタリングが必要だ」という提案タスクをagkanに積む。人間はその提案をレビューしてタスクを昇格させるかどうか判断するだけになる。
エンジニアの役割が「何を作るか設計する人」と「結果を判断する人」に純化されていく。
このパラダイムのこれから
「AIに任せきる」ことへの抵抗感は、まだ多くのエンジニアの中にある。「自分でコードを書かないとスキルが落ちる」「AIが間違えたらどうするか」という懸念だ。
しかしこの懸念は、20年前の「自動テストを導入したら手作業での確認スキルが落ちる」という懸念と本質的に同じだ。自動テストは「確認する能力」を奪わなかった。むしろより高次の「テスト設計能力」の重要性を高めた。
agkan × agkan-skills × /loop の構成も同様だ。「実装する能力」を奪うのではなく、「何を実装すべきか設計する能力」「PRを的確に評価する能力」の重要性を高める方向に向かっている。
AIエージェントの自律ループが当たり前になる世界では、スキルの設計力とコードレビュー能力こそが差別化要因になる。コードを書く速さではなく、AIに何をやらせるかを定義する力と、出力の質を判断する力が問われる。
まとめ
agkan × agkan-skills × Claude Code /loop の組み合わせについて考察した。
-
agkanの役割: AI協働に最適化されたCLIタスク管理。
--json出力とシンプルなCLIでAIが自律的にタスクを読み書きできる -
agkan-skillsの役割: 開発ワークフローに対応したスキル定義をgitで管理。
agkan-run/agkan-planning/agkan-review/agkan-iceboxを組み合わせることで、開発サイクル全体を自律的に回せる -
/loopの役割: 人間が起動しなくても24時間自律的にスキルを実行し続ける。人間の操作ポイントをタスク積みとPRレビューの2点のみに絞る
まず npm install -g agkan して、agkan-skillsをforkするところから始めてほしい。最初のスキルを /loop で動かした瞬間、このパラダイムシフトの感覚は体で理解できる。