あなたは同じコードベースで複数のAIコーディングエージェントを動かしている。3体かもしれないし、13体かもしれない。それぞれが自分の作業を管理する必要がある。イシューの作成、ステータスの更新、依存関係の確認、進捗の報告。フリート全体で毎分数十回の書き込みが発生する。
これがagentic engineeringだ。人間がAIエージェントのフリートを統率してソフトウェアを出荷するワークフロー。新しい手法だが、誰もがまず手を伸ばすのは既に知っているツールだ。Jira。Linear。GitHub Issues。Notion。チームが使っているプロジェクト管理ツール。
それではうまくいかない。そしてこのミスマッチは表面的なものではない。アーキテクチャレベルの問題だ。
レイテンシがスループットを殺す
Jira APIの呼び出しには200〜800msかかる。Linear APIはそれより速いが、それでも100〜300msだ。1つのイシューを作成し、依存関係を読み取り、ステータスを更新する。HTTPS、DNS解決、TLSハンドシェイク、JSONシリアライゼーションを経由する3回のラウンドトリップ。良い条件で500msといったところだ。
ローカルCLIからSQLiteデータベースへの書き込みは50ms以下。多くの場合10ms以下。
これは誤差に聞こえるかもしれないが、オペレーション数を掛け合わせると話が変わる。エージェントがタスクを処理する際、2〜3件のサブイシューを作成し、親のステータスを更新し、ブロッカーを確認し、進捗をコメントするかもしれない。6回のオペレーション。1回500msなら3秒の純粋な待ち時間。1回10msなら60ミリ秒。30秒でタスクサイクルを完了できるエージェントが、その10%をコードを書く代わりにHTTP待ちに費やすことになる。
これを13体のエージェントに拡大すると、オーバーヘッドは1時間あたり数分単位になる。
認証インフラは脆い接着剤
すべてのエージェントにAPIトークンが必要だ。トークンには有効期限がある。レート制限がある。1体のエージェントが20回の連続更新を一気に行うと429 Too Many Requestsが返ってくる。本来の仕事をする代わりに、指数バックオフのリトライループに嵌まる。
作業そのものとは何の関係もない障害モードを丸ごと追加したことになる。トークンのローテーション、シークレット管理、エージェント間のレート制限の配分。ローカルデータベースにレコードを書き込むという、本来取るに足らないはずの機能のための運用オーバーヘッドだ。
イシュートラッカーがディスク上のファイルであれば、認証する対象が存在しない。エージェントがファイルシステムを読めるなら、イシューの読み書きもできる。壊れる要素が一つ減る。
データモデルが人間を前提としている
Jiraを開いてみよう。スプリントが見える。ストーリーポイント。プロフィール写真とメールアドレスを持つ担当者。「レビュー中」や「グルーミング準備完了」といった状態を持つワークフロー。データモデル全体が、スタンドアップ、スプリントプランニング、振り返りを行う人間のチームのために設計されている。
エージェントはスタンドアップをしない。ストーリーポイントで見積もらない。7つの状態と4つの承認ゲートを持つワークフローは不要だ。
エージェントが必要としているのは依存関係グラフだ。このタスクはあのタスクにブロックされている。このエピックには12の子があり7つが完了している。このエージェントがこのイシューを45秒前にクレームして以来、報告がない。基本的なデータ構造は、列を移動するカードのボードではなく、ブロック関係を持つタスクのツリーだ。
SaaSツールは「自動化」機能を後付けするが、その下のコアモデルは依然として人間のためのKanbanボードだ。Jiraプラグインを書いてエージェントにイシューを作成させることはできる。しかしJiraがあなたのエージェントをスプリントチームの一員だと認識していることは変えられない。
クラウド依存は単一障害点
あなたのエージェントはローカルで動く。ローカルファイルを読み、ローカルコードを書き、ローカルのgitリポジトリにコミットする。オフラインでも、飛行機の中でも、レイテンシ2000msのネットワークでも動作する。気にしない。
しかしイシュートラッカーがSaaS製品であれば、すべてのエージェントオペレーションにインターネットアクセスが必要になる。Linearが10分ダウンしたら？フリート全体が止まる。自宅のインターネットが30秒途切れたら？全エージェントがリトライループに入る。作業を調整するためのイシュートラッカーが、システム全体の単一障害点になる。
ローカルファーストなら、イシュートラッカーはファイルシステムと同じ信頼性を持つ。常に利用可能で、常に高速で、常に自分の管理下にある。
書き込み量の桁が違う
SaaSプロジェクト管理ツールは、5〜10人の人間チームが1日に数回の更新を行うことを想定している。チーム全体で50〜100回程度の書き込みだ。
13体のエージェントが数分ごとにイシューを更新すると、1つのプロジェクトから1時間に数百のAPI呼び出しが発生する。これは利用量のわずかな増加ではない。まったく異なる利用パターンだ。人間のチームには十分に見えるレート制限が、エージェントフリートにとってはハードウォールになる。
そして問題は量だけではない。並行性だ。3体のエージェントが同じエピックの子タスクを同時に更新する。ステータスフィールドの競合状態。コメントスレッドの楽観ロック失敗。これらはSaaSツールが解決する必要のなかった問題だ。人間が3つのターミナルから同じイシューを同時に更新することはないからだ。
コラボレーションはデータの放棄を意味する
Jiraプロジェクトをチームメイトと共有するには、双方にJiraアカウントが必要だ。データはAtlassianのサーバーに存在する。自分のプロジェクトデータにAPIを通じてアクセスする特権に対して、シートごと、月額で支払っている。
別のツールに移行したい？エクスポートできるものをCSVで書き出し、残りは諦める。コメント、添付ファイル、カスタムフィールド、監査履歴。使える形式で取り出せることを祈るしかない。SaaSモデルはデータの所有権を利便性と引き換えにする。
しかしコラボレーションにベンダーを介在させる必要はない。イシューデータベースがDolt(データベース版Git)のようなもので管理されていれば、リモートにpushしてチームメイトがpullする。コードをブランチするのと同じようにイシューデータベースをブランチする。マージも同じだ。コンフリクトの解決も同じツールとメンタルモデルで行う。データは自分のものであり続ける。コラボレーションはサブスクリプションではなく、gitのように機能する。
本当に機能するもの
ブランド名を取り払って、エージェントがイシュートラッカーに本当に必要なものを考えてみよう。
- ローカルファースト。 ネットワーク依存なし。データベースはディスク上のファイル。
- CLIネイティブ。 エージェントはターミナルに住んでいる。インターフェースもそうであるべきだ。
- Git管理。 バージョン管理、マージ可能、監査可能。ベンダーロックインなし。
- 認証オーバーヘッドなし。 エージェントがファイルシステムを読めるなら、イシューも追跡できる。
- 低レイテンシ。 オペレーションあたり50ms以下。500msではなく。
- 仲介者なしで同期可能。 API webhooksを経由せず、gitリポジトリのようにpush & pull。
これが私が日常的に使っているものだ。beadsはまさにこのワークフローのために作られたGitネイティブのイシュートラッカーだ。すべてをDoltによるバージョン管理と同期付きのローカルSQLiteデータベースに保存する。CLIがプライマリインターフェースだ。エージェントは他のコマンドを実行するのと同じようにイシューを作成、更新、クエリする。
Beadboxはその上に私が構築したビジュアルレイヤーだ。ローカルデータベースの変更を監視し、依存ツリー、エピックの進捗、エージェントのアクティビティをリアルタイムでレンダリングする。エージェントはCLIを使う。私はダッシュボードを使う。どちらも同じローカルデータベースから読み取る。
既存ツールが問題なのではない
Jiraはその本来の用途において優れている。構造化されたワークフローを通じた人間チームの調整だ。Linearはスピードと洗練さを求める小規模チームに美しい。GitHub Issuesはオープンソースコラボレーションにおいて摩擦がない。
どれも悪いツールではない。解決している問題が異なるだけだ。5人の人間が2週間スプリントを行うワークフローなら、そのまま使い続ければいい。
しかし5体、10体、あるいは13体のAIエージェントが同じコードベースでリアルタイムに連携しているなら、SaaSモデルの限界を超えている。Agentic engineeringにはagentic engineeringのために作られたツールが必要だ。人間のワークフローにAPIを後付けしたものではなく。