こんにちは！代表取締役 兼 AIサービス開発室の鈴木生雄です。
さて、唐突ですが “Agentic Engineering” というキーワードを知っていますか？実はこれ “Vibe Coding” の名付けの親である Andrej Karpathy 氏がXに投稿して話題になった「AIコーディングエージェントに“自律的に”実装・テスト・修正まで走らせつつ、人間が“仕様・制約・検証”を工学的に設計して品質責任を持つ開発様式」のことを指します。いつも思うのですが、Karpathy氏を含め、米国企業やそこに属する人は新しいキーワードを作って、事業の流れを引き寄せるのがとても上手いですね。（最近流行っている他の例としては、Forward Deployed Engineer なんかも挙げられると思います。）
Vibe Coding が勢いと試行錯誤で「とりあえず動くもの」を最短で作るノリの開発に近い概念なのに対して、Agentic Engineeringは、目的（作るもの）、制約（セキュリティ、性能、互換性、コスト、運用）、品質基準（テスト、受入条件、レビュー観点）を人間がきちんと定義し、エージェントの作業にムラが出ないように検証可能な枠（ガードレール）を作った上で自律実行させる、という工学寄りの姿勢です。
先日投稿した Claude Codeを用いたSDD開発の実践 でお見せしたSDDのフローは、まさにAgentic Engineeringの実装系と言えると思います。そして現在、こうした人間とAIの協働による開発フローを洗練させる方法論やツールが次々と登場し、多くの技術者によって盛んに検証されています。
という現在のトレンドを踏まえまして、今回は、開発フローの中で重要な要素である「タスク管理」を BeadsというOSSを導入してAIコーディングに相応しい形に洗練させたという話をお届けしたいと思います。
検証用のサンプルプロジェクト
新しいタスク管理を試すためにはプロジェクトが必要でしたので、以下のとおり「AI Clone Podcaster」という簡単なアプリを作成しました。
自分の声のクローンを使ってポッドキャストを生成するWebアプリケーション。 ブラウザ上で声を録音・登録し、台本テキストを入力するだけで、自分の声で読み上げたポッドキャスト音声（MP3）を生成できます。BGMのミキシングにも対応。
今回のテーマの主題からは外れますが、Qwen3 TTS を使っています。自分の声が簡単にクローンできるなんて…怖い時代になりました。
元々のタスク管理方法
Claude Codeを用いたSDD開発の実践を投稿した際のプロジェクト（DocFlow）では、.steering/配下に Markdown文書（requirements.md / design.md / tasklist.md）をClaude Codeに作成させて、ファイル内のチェックボックスでタスクの完了／未完了を管理していました。
課題
この方法には、人間が読みやすいという良い点もあるのですが、以下のような結構大きな欠点がありました。
- セッション横断が弱い … ファイルベースのため、複数セッションにまたがる場合には都度読ませる必要がある。（時間やコンテキストウィンドウの利用効率が悪い）
- 依存関係が表現できない … タスク間のブロッカーや依存を構造的に管理できない。（Claude Codeが実施順序を誤ったり、タスクを飛ばしたりするリスクがある）
- 検索性が低い … 過去の意思決定を探すには.steering/配下をgrepするしかない。
- イシューとソースコードの関連付けができていない … 単なる文書なのでもちろんできない。やるためにはバージョン管理と連携可能なイシュー管理システム（e.g. GitHub）を使う必要あり。
Beadsの導入
これらの欠点を解消するためにBeadsというOSSを導入してみることにしました。
Beads は、Git リポジトリ内に直接組み込まれる軽量なイシュー管理システムです。CLIファーストの設計により、AIコーディングエージェント（Claude Code など）との連携に最適化されています。
特徴
BeadsにはAIコーディングエージェントに適した以下のような特徴があります。
- リポジトリ内蔵: イシューは内臓されたSQLiteデータベースに保存され
.beads/issues.jsonlにエクスポート、コードと一緒にGit管理される - CLI操作: Web UIを介さず、すべての操作をターミナルから実行できる
- 依存関係管理: タスク間の依存関係（ブロッカー・先行タスク）がサポートされる
- Epic/子タスク構造: 親タスク（Epic）と子タスクの階層管理ができる
- Git同期:
bd syncでGitリモートと自動同期。コードを管理するメインと別の専用ブランチでイシュー管理ができる - オフライン動作: ネットワーク不要で動作し、push時に同期される
何よりCLIが充実しているので、AIコーディングエージェントととても相性がよいです。以下はこの特徴を活かして epic-progress という独自に定義したSkill（特定の開発タスクやワークフローに必要な指示・知識・手順などをパッケージ化し、Claude AIが自動で参照・実行できるようにする機能）経由でBeadsのCLIを実行して、任意のEpic（複数のタスクを包含する概念。親タスク。）の進捗状況を子タスクも含めて表示している画面です。
GitHub によるイシューとソースコードの関連付け
さて、Beadsの導入によって、先ほど挙げた課題のほとんどを解決することができましたが、最後の一つとして「イシューとソースコードの関連付けができていない」という課題が残っています。これについては、開発のワークフローの中にGitHubのPull RequestをIssueにリンクすることで解決できます。なお、今回のサンプルプロジェクトではGitHub IssueとBeadsのEpicを１対１対応させ、GitHub Issue内のチェックボックスで表すタスクリストとBeadsの子タスクを１対１対応させるというルールを敷くことにしました。
タスク管理のフロー
サンプルプロジェクトで実装したイシューとソースコードの関連付けを含むタスク管理の流れをシーケンス図で表すと以下のようになります。
ステップ1: GitHub Issue の登録
開発者がGitHub上で新しいIssueを作成する。Issueには目的・要件・チェックリスト（- [ ] 形式）を記載する。
ステップ2: 人間によるIssueのレビュー
人間のレビュアーがIssueの内容を確認し、要件の妥当性や設計方針についてコメントで議論する。合意が取れたらIssueが承認される。
ステップ3: タスク分解と作業開始
承認されたIssueをもとに、beads（タスク管理ツール）でEpicと子タスクを作成する。EpicにはIssue URLを紐付け、Issueのチェックリスト項目ごとに子タスクを切る。作業着手時にタスクのステータスを「in_progress」に変更する。
ステップ4: 実装
AIアシスタント（Claude）と開発者が協力してコードを実装する。featureブランチ上で作業し、コミットメッセージには #N（Issue番号）を含める。
ステップ5: タスク完了とチェックリスト更新
各子タスクの実装が終わるたびに、beadsでタスクをcloseし、対応するGitHub Issueのチェックリスト項目を - [x] に更新する。全チェックリストが埋まるまでステップ4〜5を繰り返す。
ステップ6: Pull Request の作成
全タスク完了後、GitHub上でPull Requestを作成する。PR本文には Closes #N を記載し、変更内容のサマリーとテスト計画を含める。
ステップ7: 人間によるPRレビューとマージ
人間のレビュアーがコードの品質・設計・テストを確認し、必要に応じて修正を依頼する。承認後にmainブランチへマージされ、Issueが自動クローズされる。
CLAUDE.mdへの記述
上記のフローをClaude Codeに遵守させるために、CLAUDE.mdにルールを記載しておく必要があります。以下はサンプルプロジェクトの CLAUDE.md からの抜粋です。
タスクの管理
作業管理は beads（bd）で行う。GitHub Issue と beads を連携させて運用する。
GitHub Issue 1件 → beads Epic 1件（親）
Issue内のチェックリスト項目 → beads 子タスク（--parent で紐付け）
beads Epic の description に GitHub Issue URL を記載して相互参照
コミットメッセージに #N（GitHub Issue番号）を含める
PRの description に Closes #N を含め、マージ時にIssue自動クローズ
GitHub Issue の起票ルール
新しい作業単位は GitHub Issue を起点とする。
GitHub Issue を作成（設計・要件・チェックリスト - [ ] を記載）
beads に Epic を作成し、description に Issue URL を記載: bd create --title="GH#N: タイトル" --type=epic --description="https://github.com/ikuo5710/ai-clone-podcaster/issues/N"
Issue 内のチェックリスト項目ごとに beads 子タスクを作成: bd create --title="タスク名" --type=task --parent=<EPIC_ID>
必要に応じてタスク間の依存を設定: bd dep add <後続タスク> <先行タスク>
beads 運用ルール
セッション開始時（必須）:
git status で作業ツリーを確認（汚れていたら commit / stash が必要と伝えて止まる）
bd sync で beads を同期
作業中:
着手: bd update <ID> --status=in_progress
意思決定やブロッカーはコメントで記録:
bd comments add <ID> "DECISION: …"
bd comments add <ID> "ROOT CAUSE: …"
bd comments add <ID> "BLOCKER: …"
bd comments add <ID> "LEARNED: …"
bd comments add <ID> "NEXT: …"
完了: bd close <ID> --reason "…" し、対応する GitHub Issue のチェックリスト項目を - [x] に更新する（gh issue edit で body を更新）
コミット・PR:
コミットメッセージに #N（GitHub Issue番号）を含める
PR description に Closes #N を含める
セッション終了時（必須）:
git status を確認（汚れていたら確認して止まる）
bd sync で beads を同期
可能なら bd doctor で健康チェック
ブランチ運用:
main/feature ブランチに .beads/*.jsonl を混ぜない
混入したら即除外: git restore --staged .beads
.beads/config.yaml は main に含めてよい
ガードレール（止まって確認する条件）:
bd sync 中に rebase/merge/conflict が出た
git status が汚れているのに bd sync が必要になった
.beads/*.jsonl が main/feature に混入した
bd doctor が Sync Divergence を繰り返し検出するまとめ
ここまでAIコーディングエージェントの為に開発されたタスク管理システム「Beads」をClaude Codeの開発プロセスに統合したという話をしてきました。今回の作業を実施してみて、Agentic EngineeringはAIコーディングエージェントを安定して自律実行させるようにする工学的取り組みだということを実感しました。つまりは、AIの特性（CLIが得意とか、コンテキストから情報が落ちると意図した動作をしなくなるとか）を理解した上で、安定して動作してくれるようにルールや手順、ツール等の環境を整えるということです。これ、難しく感じる必要はあまりなくて、実際に手を動かしながら、日頃からこういうふうにするとAIはこう動くという直感を磨くことをしていれば、意外にできてしまうものだと思います。Claude Codeのベストプラクティスにも「Develop your intuition」と書いてありますし、だからこそ私も今回のように手を動かしてみているわけですね。
PS：Claude Codeにタスク管理システム標準搭載
Claude Codeのv.2.1.16でタスク管理システムが標準搭載されたようです。開発者の方のXへの投稿をみると「Beadsからインスピレーションを受けた」という記載がありますので類似した仕組みなのだろうと推察しています。
It was clear we needed to evolve Todos to help Claude work on longer projects. This need was also emerging in the community and we took inspiration from projects like Beads by Steve Yegge.
We’re turning Todos into Tasks in Claude Code – X posted by Thariq
とりあえずはBeadsを使っていくつもりですが、標準機能で完結した方が外部プラグイン/フック由来の不安定さを減らせるような気がするので、そのうち移行するかもしれません。