比較
AI4Kanban vs.
GitHub Issues
代替品ではありません。別のボトルネックのための別の道具です。GitHub Issues は共有され、消えず、公開された正式な記録。ai4kanban はプライベートでローカル、エージェントのために作られた作業面。いま実際に何が足を引っ張っているかで選んでください。
リポジトリのなかのただの Markdown。エージェントの手元にある高速なローカル下書き板。
API の向こうにあるデータベース。共有され公開された正式な記録。
GitHub Issues でよくないですか？
よいです。ai4kanban がやることのほとんどは、GitHub Issues に gh CLI か GitHub の MCP サーバーを足せばできます。違うのは、そこに至るコストです。
同じ作業を GitHub Issues でやると、ノイズが増え、やり取りが増え、トークンが増え、レイテンシが上がり、そもそもエージェントに使わせるためのプロンプトも重くなります。ai4kanban は GitHub の広さを手放してローカルの速さを取ります。そしてエージェントを回してひとりで作る人にとって、足りないのはたいてい速さのほうです。
AI4Kanban vs. GitHub Issues
14 の観点。 は明確な勝ち、ダッシュはどちらが劣るでもない意図的なトレードオフで、必要なもの次第です。ai4kanban は速度とローカル性の行を取り、GitHub Issues は規模と協働の行を取ります。
リポジトリのなかのただの Markdown、git の中に。
API の向こうにある GitHub のデータベース。
使えます。ディスク上のファイルにすぎません。
使えません。ネットワークと認証が必要です。
ネイティブのファイル操作：Read、Grep、Glob。
gh CLI か MCP の往復。
少ない。grep は一致した行しか返しません。
多い。JSON のペイロードとツールスキーマ。
ローカルディスク、事実上ゼロ。
呼び出しごとにネットワーク往復。
プロンプト 1 つ：スキルファイル 1 枚と小さなスクリプト。
アカウント、認証トークン、MCP の設定。
なし。ボードはリポジトリと一緒に移動します。
GitHub の上にしか存在しません。
意図的に最小限。優先度と工数、ひとりで作る人に必要なのはこれだけ。
ラベル、マイルストーン、担当者、プロジェクト。チームを束ねるために。
なし。2 人が同時に #1894 を作れば ID がぶつかります。
ID はサーバーが割り当てるので、チームでも安全。
次のタスクを導く判断だけに刈り込まれます。なぜその案を却下したか、何をリリースしたか。だからエージェントは前へ提案し、済んだ作業や死んだ作業をやり直しません。
コメント履歴も編集履歴も丸ごと残り、何も落ちません。
項目にチェックが付いたらそのタスクをアーカイブします。
紐づいた PR と CI から issue を自動クローズします。
grep。小さなボードなら速いが、育つと扱いづらい。
索引付きの全文検索と保存済みフィルタ。
できますが、Markdown にコミットする形だけ。気軽に起票する手段はありません。
誰でもコミットなしに起票・コメント・リアクションできます。
カードはすべてリポジトリ上に見えたまま。刈り込まれるのは記憶ハブだけです。
公開されリンクもできる、オープンソースの既定解。
それぞれが勝つところ
どちらが一方的に優れているわけではありません。ai4kanban は 1 体のエージェントが速く動くことに、GitHub Issues は大勢が足並みを揃えることに最適化されています。
AI4Kanban
トークンが軽く、待ち時間がない
MCP もネットワークもなし。エージェントはリモート API をページングする代わりに、ローカルの Markdown を grep します。トークンは減り、レイテンシは下がり、作業の途中で認証を更新する必要もありません。
エージェントが実際に使う
エージェントは GitHub Issues を検索したがりません。既定ではファイルシステムのツールに手を伸ばします。Markdown のボードは、エージェントがすでに立っている場所で出迎えます。プロンプトは軽くなり、でっち上げのタスク状態も減ります。
オフラインで、あなたのもの
git のなかのただのファイル。飛行機の中でも動きますし、GitHub が落ちても動きます。SaaS 依存もロックインもなし。リポジトリを clone すればボードごと付いてきます。
提案のためにチューニングされた記憶
次のタスクを導く判断だけを記録します。なぜその案を却下したか、何をリリースしたか、ゴールまでの差はどれだけか。だからエージェントは前へ提案します。済んだ作業をやり直すことも、あなたが潰した案を蒸し返すこともありません。
GitHub Issues
チームのために作られている
サーバー割り当ての ID、安全な同時編集、担当者。ai4kanban にはデータベースがないので、2 人が同時に #1894 を作って衝突しえます。
透明性と到達範囲
公開されリンクもでき、外部の貢献者が起票・コメント・リアクションできます。生の速さより開かれていることが大事なときの正しい住処です。
文脈まるごと、ずっと
ai4kanban はわざと圧縮します。アーカイブしたカードは 1 行に縮みます。GitHub ではすべてのコメント、編集、相互リンクがそのまま残ります。
深い連携
PR からの自動クローズ、コミットへのリンク、プロジェクトボード、ラベル、マイルストーン、そしてサードパーティツールの一大エコシステムと、規模に耐える索引付き検索。
エージェントがファイルを好む理由
本当の差は、エージェントが実際に作業したときに現れます。同じことを頼んでみてください。「優先度の高い未完了タスクを探して」。2 つの道筋はほとんど似ていません。
しかもこれは積み上がります。「次は何をやる？」のたび、アーカイブのたび、ボード点検のたびに、GitHub Issues では往復のコストを払うことになります。そしてモデルは、選べるなら黙ってリモートのツールを避け、ファイルのほうへ手を伸ばします。
どちらを使うべき？
こんなときは ai4kanban
- ひとりで、あるいは気心の知れた少人数で作業している。
- ターミナルのエージェント越しに作業を進めている。
- 記録を残すことより、前に進むことを重んじる。
- ボードを git に置きたい。オフラインで、持ち運べる形で。
こんなときは GitHub Issues
- 公開の場で作っていて、透明性が大事。
- 複数人が同時にバックログをいじる。
- PR/CI のリンク、プロジェクトボード、マイルストーンに頼っている。
- 外部の貢献者に起票して議論してほしい。
そもそも競合ではありません。GitHub Issues は共有された正式な記録、ai4kanban はエージェントの手元にある高速なローカル下書き板です。ボトルネックが人と人の調整なら GitHub Issues を、エージェントと一緒に出す量なら ai4kanban を使ってください。
ひとりで作る人の多くは両方使っています。GitHub Issues を公開のトラッカーに、ai4kanban を自分のエージェントが毎日触る非公開の作業面に。