Board Planner

Board Planner

ボードはひとつ。チームもエージェントも、そこで作業します。

小規模チームが実際に運用できるカンバンボード、スプリント、ダッシュボードに、MCP サーバーと REST API を組み合わせました。コーディングエージェントも、ほかのメンバーと同じルールのもとで同じタスクに取り組めます。

多くのトラッカーは、自動化を後付けします。ボットがコメントを投稿し、スクリプトがカードを移動させ、実際の作業状況はボードから見えない場所に残ります。Board Planner は逆の発想から始まります。ボード、REST API、MCP サーバーは、ひとつのモデルにアクセスするための 3 つの入口であり、どの入口でも同じ権限チェックが行われます。エージェントがタスクを レビュー中 に移動する際は、担当者がカードをドラッグするときと同じステータスルールが適用され、同じ履歴に同じ記録が残ります。

クラウドまたはセルフホスト

クラウド版では、登録すると、board-planner.com のサブドメインに新しい組織が作成されます。カード登録不要の Pro トライアルが 30 日間利用でき、その後は Free に移行します。Free では、メンバー 10 人まで、プロジェクトとタスクは無制限、REST API、MCP サーバー、1 台のマシンでのワーカーとエージェントが利用できます。または、メンバー数の上限が増え、マシンを何台でも使え、当社のキーによる毎月の AI 利用枠と Coda 同期が追加される Pro を選択できます。エージェント、ワーカー、API トークンはメンバー数に含まれません。

自分のサーバーでは、docker compose up を実行すると、自分専用の組織が 1 つ作成されます。Community エディションは AGPL-3.0 で、メンバー数やマシン数に制限はなく、AI 機能は自分のキーで実行します。Pro のセルフホスト版では、Coda 同期とメールサポートが追加されます。

自分のキーを使った AI は、すべてのプランで無料です。また、Free で提供される機能が Pro に移行することはありません。料金と詳細な比較は、board-planner.com/pricing をご覧ください。

作業をマシンに引き継ぐ

マシンにコードを書かせるツールは、今や数多くあります。Board Planner が扱うのは、その周辺にあるすべてのことです。誰が作業を提案したのか、誰が承認したのか、マシンに何を変更する権限があったのか、完了前に何を通過する必要があったのか、そしてどこで作業を止めて引き継ぐのか。

その一連の流れの両端を担うのが、2 種類のエージェントです。提案して内容を書き残す PM エージェントと、承認済みのタスクを引き受けて実行する 実行ワーカーです。どちらも、許可されていない判断を勝手に行うことはありません。

PM エージェントは、プロジェクト内に常駐するプロジェクトマネージャーです。ボードを読み、行き詰まっているタスク、重複しているタスク、足りないタスクに気づき、誰も頼んでいないチケットを大量に登録するのではなく、判断材料を提示します。誰もやりたがらない作業、たとえば受け入れ条件を設定せずに作成されたタスクに条件を書き加えたり、重複を見つけたり、スプリントの実際の進捗を伝えたりするのが得意です。

このスクリーンショットでは、返信の下にあるバッジがアクションを示しています。メッセージと書き込みは 1 つの記録なので、単に言及しただけでなく、返信と同時に ORB-9 も変更されたことがわかります。また、指示に従ってタスクは元の場所に残しています。ボードのレビューでは change_status と create_task が無効になるため、自律実行でも、ボードをひそかに一晩で再編成することなく、問題を知らせることができます。

プロジェクトごとにデフォルトでは無効になっており、無条件に信頼するのではなく、使用量が計測されます。自律ターンもユーザーのターンも含め、すべての呼び出しが組織ごとのトークン数としてカウントされ、インスタンスで設定できる利用上限に対して計上されます。また、インスタンス管理者は、プロジェクト設定で上書きできない形で、プロジェクト単位でこの機能をロックして無効にできます。OPENROUTER_API_KEY がない場合、ページにその旨が表示され、機能は動作しません。AI Assist も同じキーを使用します。

📖 PM エージェント · 自律的なボードレビュー

人に任せるときと同じように、エージェントに引き継ぎます

タスクを割り当て、エージェントを指定し、承認する列にドラッグします。この 2 つが引き継ぎの条件です。エージェントが指定されていないタスクでは何も実行されず、プロジェクトのデフォルト設定にフォールバックすることもありません。ほかの人があなたに割り当てたタスクは提案であり、あなたのマシンで実行待ちになっている仕事ではありません。

エージェントはステップとゲートのリストです

エージェントは順序付けられたブロックのリストで、種類は次の 2 つだけです。

ステップは拒否できず、ゲートは書き込みができません。そのため、実行を停止できるブロックはすべてゲートであり、そのすべてをひと目で確認できます。

各ステップはそれぞれ独立したモデルセッションです。1 つのエージェント内にある 2 つのステップが共有するのはタスクとワークツリーだけです。そのため、分析してから実装するのと、1 つのモデルに両方を依頼するのとでは結果が異なります。2 番目のステップが読み取るのは、最初のステップが書いた内容であり、考えていた内容ではありません。

マージは切り替え設定ではなく、ステップです。「自動マージ」のチェックボックスはなく、レビュー設定に連動するルールもありません。エージェントは、シーケンスの最後に Merge ブロックがある場合にマージします。ブロックを省略すると、実行はプルリクエストの段階で停止します。

3 つのエージェントが付属しています。Default、With security review、Merges its own work です。エディターを一度も開かないプロジェクトでは、Default が実行されます。

この設計では、マシンは信頼されていません

ここを正しく仕上げるのに最も時間がかかりました。実際のリポジトリで安全に引き継ぎを使えるのは、このためです。

実行中の情報は、その都度すべてタスクに記録されるため、タスクのコメントが実行ログになります。ブランチ、編集内容、どのゲートが拒否したか、モデルの残り使用量を確認できます。別の通信経路も、CI のタブも必要ありません。

📖 詳細はこちら：エージェント · 実行ワーカー · worker/README.md

ボードのその他の機能

まずはボードとして

列の名前も順序も自由に設定できます。各列には自動化が理解できる役割（backlog、approved、active、review、blocked、done）を割り当てるため、Up next を Ready に変更しても何も壊れません。review の役割を持つ列は、自動化を停止する目印となり、作業は人間による確認を待ちます。ドラッグ＆ドロップ対応のボード、リスト表示、スプリント、依存関係とサブタスク、繰り返しタスクに加え、アプリのどこからでもすべてのタスクを検索できる ⌘K 検索を備えています。

システムのテーマに従い、アプリ全体が次の両方に対応しています。

作業に必要なものをすべてタスクにまとめられます

1つずつチェックできる受け入れ条件、依存関係、タスクを完了させるプルリクエスト、プロジェクトごとに定義できるカスタムフィールド、作成後のすべてのコメントと変更を記録できます。ブランチ名を bp-8/dark-mode にすると、プルリクエストが自動でタスクを見つけます。

エージェントも同じボードで作業します

HTTP 経由で使える46個の MCP ツールにより、ターミナルからボードを操作できます。Claude Code はバックログを読み取り、タスクを引き受けて移動できます。操作にはチームメイトと同じ権限が適用されます。API トークンは特定のプロジェクトに限定でき、その範囲は一元的に適用されるため、REST と MCP のどちらでも有効です。

月曜日の質問に答えるのに十分な情報

作業の進み具合、積み上がっているもの、着手したのと同じ速さで完了できているかを確認できます。 スプレッドシートなしで、6つのグラフを表示します。

その他

アプリ内、メール、Slack、Discordで通知を受け取れます。ユーザー、プロジェクト、イベントごとに設定できます。プロジェクトの監査証跡。署名付きWebhook。GitHubとGitLabのPR連携。スマートフォンでも使えます。

クイックスタート

Docker Compose 2.24以降が必要です。それより古いComposeでは、.envがなくてもenv_fileの記述が原因でファイルを読み込めません。それ以外は何も必要ありません。NodeもMongoDBも、リポジトリのクローンも不要です。

curl -fsSLO https://raw.githubusercontent.com/rafalpodles/board-planner/main/docker-compose.yml
docker compose up -d

このコマンドは公開イメージghcr.io/rafalpodles/board-plannerを実行します。このイメージは1.1.0以降の各リリースでlinux/amd64およびlinux/arm64向けにビルドされています。1.0.xはこれより前のバージョンで、イメージはありません。:latestは最新リリースを指します。バージョンを固定するには、Composeファイルと同じ場所にある.envにBOARD_PLANNER_VERSION=1.2.3を設定してください。アップグレードするには、docker compose pull && docker compose up -dを実行します。

mainブランチのComposeファイルには、1.1.2以降のイメージが必要です。COOKIE_ALLOW_INSECURE=autoを渡しますが、1.1.1ではこの設定を認識しないため、localhost以外で平文HTTP経由で提供される1.1.1のイメージにはサインインできません。1.1.1で実行する場合は、.envにCOOKIE_ALLOW_INSECURE=1を設定してください。

クローンから実行する場合は、docker compose up -d --buildを実行してください。 docker compose up -dだけでは、チェックアウトしたコードではなく、直近のリリースを取得して実行します。--buildを付けると、チェックアウトしたコードをビルドして実行します。

http://localhost:3000を開きます。サインインページで最初に作成されたアカウントがインスタンス管理者になります。それ以降のアカウントは、Settings → Usersから作成します。

最初のアカウントを作成するにはセットアップコードが必要なので、初期状態のインスタンスにあなたより先にアクセスした人がアカウントを取得することはできません。BOOTSTRAP_TOKENを設定しない場合、アカウントがない状態でアプリを起動すると、アプリがコードを生成してサーバーログに出力します。docker compose logs app | grep "setup code"で確認できます。コードはメモリに保持されるため、再起動すると新しいコードが出力されます。また、複数のレプリカがある場合は、それぞれが独自のコードを出力します。その場合は、代わりにBOOTSTRAP_TOKENを設定してください。

停止するにはdocker compose downを実行します。データベースはmongo-dataボリュームに保存され、停止後も保持されます。docker compose down -vを実行すると削除されます。

公開イメージより前のビルドからアップグレードする場合

.envのNEXT_PUBLIC_APP_URLをPUBLIC_ORIGINに変更してください。アプリは古い名前をまったく読み込みません。PUBLIC_ORIGINが設定されていない場合、docker-compose.ymlはNEXT_PUBLIC_APP_URLの値をPUBLIC_ORIGINとして渡すため、.envを変更しなくてもリンクは維持されます。ただし、このフォールバックがあるのはComposeファイルを使う場合のみです。イメージを別の方法で実行する場合は、PUBLIC_ORIGIN自体を設定する必要があります。

Dockerを使わない場合

自分で用意したNode 26とMongoDB 4.4以降が必要です。

npm install
MONGODB_URI=mongodb://localhost:27017/boardplanner npm run build
MONGODB_URI=mongodb://localhost:27017/boardplanner npm start

開発サーバーを起動するにはnpm run devを実行します。以下の変数を保存する場所として、.env.exampleを.env.localにコピーしてください。npm startはPORTで待ち受けます。PORTは、まず環境変数から、次にNext.jsが読み込む順序に従って.env.production.local、.env.local、.env.production、.envから取得されます。いずれにも指定がない場合は3000を使います。

エージェントを接続する

MCP サーバーはアプリに組み込まれており、POST /api/mcp で利用できます。クローンもビルドも不要です。設定 → API トークンでトークンを作成し、エージェントが操作するプロジェクトにスコープを設定して、クライアントを 1 つの URL に接続します。

{
  "mcpServers": {
    "boardplanner": {
      "type": "http",
      "url": "https://your-instance.example.com/api/mcp",
      "headers": { "Authorization": "Bearer cp_..." }
    }
  }
}

エージェントが作業するグループに分けられた 46 個のツールを利用できます。全ツールの一覧と各ツールが返す内容については、MCP ページをご覧ください。

• プロジェクトとタスク： list_projects、get_project、list_tasks、get_task、create_task、 update_task、change_task_status、reorder_tasks、search_tasks、my_tasks、archive_task、 unarchive_task、delete_task（ボードのオーナーのみ）
• 一括操作： create_tasks、update_tasks、link_task_pairs（1 回の呼び出しで最大 30 件または 60 件を処理し、項目ごとに結果を返します）
• リンクとチェックリスト： link_tasks、unlink_tasks、add_checklist_item、set_checklist_item、 remove_checklist_item
• スプリント： list_sprints、get_sprint、create_sprint、update_sprint、delete_sprint
• コメントと履歴： add_comment、list_comments、edit_comment、delete_comment、get_task_activity、 watch_task、unwatch_task
• メンバーとエージェント： list_members、whoami、list_agents
• レポート： get_project_stats、list_runs、list_notifications、mark_notifications_read
• ボードの設定（追加のみ）： add_custom_field、add_field_option、add_category（アプリと同様、すべてのメンバーが操作できます）、 add_column、rename_column（プロジェクトのオーナーのみ）。その他の項目の削除や名前の変更は、引き続きアプリで行います。
• リポジトリ： sync_repository は、同期ボタンと同様に、ボードのプルリクエストまたはマージリクエストと CI バッジを更新します。

トークンを貼り付ける代わりにコネクターを利用するクライアント向けに、同じ URL で OAuth 2.1 with PKCE と動的クライアント登録を完全にサポートしています。クライアントシークレットは不要です。

サーバーは接続時に、すべてのクライアントにボードの操作方法を伝えます。選択、担当、報告、エスカレーション、完了までのワークフロー全体を利用するには、Claude Code にエージェントスキルをインストールしてください。

/plugin install board-planner --marketplace rafalpodles/board-planner

エージェントスキルをご覧ください。

設定

データベース以外はすべて省略できます。docker-compose.yml と同じディレクトリに .env ファイルを置いて設定を上書きしてください。compose ファイルは、NODE_ENV、PORT、HOSTNAME をそれぞれ production、3000、0.0.0.0 に固定し、それ以外のファイル内のすべての変数をアプリに渡します。

A request arrived with X-Forwarded-For carrying 2 entries while TRUSTED_PROXY_HOPS=0, so the
header is ignored and the login throttle has no per-address key. …

CDN の前に、それ自体がプロキシとして動作するホスティングプラットフォームがある場合は、各プロキシが値を追加するため、複数のエントリーが記録されると予想してください。件数はログで確認できます。料金を支払っているボックスの数を数えても、ホップ数は分かりません。だからこそ、測定が必要なのです。

この件数が正しいのは、すべてのプロキシが値を追加する場合だけです。 ヘッダーを置き換えるプロキシは、それより前の情報をすべて隠します。Caddy は、前段のプロキシを trusted_proxies に指定しない限り、まさにそのように動作します。CDN の背後にそのようなプロキシがあると、ログには 1 と記録されます。その場合に 1 を設定すると、スロットリングの基準が訪問者ではなく CDN のエッジアドレスになり、上記の「少なすぎる」場合の問題が起こります。各プロキシが値を追加するようにしてから、測定してください。

チェーン全体を経由して、ご自身が送信したリクエストの件数を確認してください。呼び出し元もヘッダーを送信でき、アプリに通常より短い経路で到達するヘルスチェックや稼働監視プローブには、ブラウザーより少ないエントリーしか含まれません。そのため、アプリは最初の件数だけでなく、新しい件数ごとに報告します。最初の4種類の異なる件数はすぐに記録され、それ以降の新しい件数は、10分間の待機を経てから記録されます。この上限は、悪意のある呼び出し元に占有される可能性があります。 アプリは、正規のサインインと偽造ヘッダーを区別できません。そのため、呼び出し元が数分おきに新しいヘッダーの長さを送信すると、枠が占有され続け、ご自身の行が一度も表示されない場合があります。再起動すると最初の4枠が空くので、再起動した直後にサインインを試みてください。これは低速な偽造トラフィックには有効ですが、呼び出し元が毎秒数件のリクエストを送ると、すぐに枠が再び占有されます。その場合、確実な対処方法は、公開状態を止めることです。送信元をブロックするか、同じチェーンの背後にあるステージング環境またはローカル実行環境で件数を確認してください。アドレスをまったく含まないヘッダーは報告されず、4枠のいずれも消費しません。

IPv6 の呼び出し元は /64 単位で数えられます。 /64 に属する1台のホストは 2^64 個のアドレスを持つため、アドレス単位で数えると、リクエストごとに新しいバケットが割り当てられてしまいます。スロットリングでは、IPv6 クライアントを先頭の64ビットで識別します。IPv4 は変更されません。また、IPv4 マップアドレス、または既知の NAT64 プレフィックス（64:ff9b::/96）で表された IPv4 クライアントは、その IPv4 ホストとして数えられます。先頭の64ビットがすべてゼロのアドレス（ループバック、未指定アドレス、旧形式の IPv4 互換アドレス）は、その範囲が誰のサブネットでもないため、アドレス全体で数えられます。独自のプレフィックスを持つ NAT64 は、他の IPv6 ネットワークと区別できないため、同じく先頭の64ビットで数えられます。/64 または /96 のプレフィックスの背後では全員が同じバケットを共有しますが、より短いプレフィックス（/32 から /56）では、各 IPv4 アドレスの一部がこの64ビット内に入るため、クライアントは複数のバケットに分散します。セッションに保存され、監査ログに記録されるアドレスは、引き続き完全なアドレスです。/56 または /48 を割り当てられたホストでは、バケットがそれぞれ256個または65,536個に分散します。

重要

MongoDB は 4.4 に固定されており、ホストポートには公開されていません。アクセスできるのはアプリコンテナだけです。集約処理では、5.0 以降でのみ使える演算子を意図的に避けています。このバージョン固定により、それが維持されます。

構成

Next.js 16（App Router）と TypeScript、Tailwind CSS 4、MongoDB と Mongoose を使用しています。認証には、ブラウザーではセッション Cookie、API クライアントと OAuth では Bearer トークンを使います。ブラウザーにパスワードが保持されることはありません。

src/
  app/api/          REST API — ~150 routes, plus the MCP endpoint at /api/mcp
  app/              board, task detail, sprints, dashboard, search, settings
  components/       kanban/, tasks/, search/, shell/, pm/, settings/, ui/
  lib/              auth, notifications, webhooks, custom fields, PM agent, force guard
  models/           Mongoose schemas
worker/             execution worker — claims tasks, runs an agent, enforces gates
menubar/            macOS menu bar app
e2e/                Playwright specs

開発

npm test           # unit tests (vitest)
npm run test:e2e   # end-to-end tests (playwright)
npx tsc --noEmit   # types

フィクスチャはデフォルトでは分離されていないため、e2e の実行には専用のポートとデータベースを割り当ててください。

E2E_PORT=3200 PM_STUB_PORT=3201 E2E_MONGODB_URI=mongodb://localhost:27017/local_e2e npx playwright test

Web サイトとドキュメント

board-planner.com は製品の概要を体験できるページです。カードを実際にドラッグできるボード、実行中のワーカーを途中で停止してみる体験、そして拒否するゲートがあります。

board-planner.com/docs は全 33 ページのマニュアルであり、唯一の信頼できる情報源です。board-planner-site リポジトリで管理され、マージ時に公開されるため、掲載ページが製品より遅れることはありません。

ライセンス

Board Planner は、GNU Affero General Public License v3 に基づくフリーソフトウェアです。例外は 1 つのディレクトリである src/ee/ で、商用の Enterprise Edition が含まれています。ライセンスは独自の条件に従い、Board Planner のサブスクリプションまたはライセンスキーがあれば利用できます。ここには有料コネクター（現在は Coda 同期）が含まれており、有料 AI 機能も今後ここに追加されます。それ以外への貢献は歓迎します。詳しくはCONTRIBUTING.mdをご覧ください。