まず最初に：心配しないでください。ここで私はMoltbookを作り直したわけではありません。
私が知っているあらゆるスタートアップは、だいたい「多すぎる3つのツール」で回っています。ここにボード、あそこにNotionドキュメント、いつの間にか事実上の仕様になったSlackスレッド。fluado で、私たちはエンタープライズ向けのAIエージェントを作っていますが、ここ数週間の間に新しい層がこっそり忍び込んできました。エージェントが、markdownをドキュメント用のリポジトリに書き込むのです。スプリントチケット、完了レポート。何十ものファイル。ファイルシステムが真実の源（source of truth）になりました。プロジェクトボードはそうではありませんでした。
Arboと私は毎日話しています。何度も。ですが、会話は「指させる形で」記録として残りません。Jiraがその痕跡（trace）になるはずでした。今朝それを開いたとき、表示されていたのは4週間前の状態のままでした。誰も触っていません。
以前に書いた通り、AIは「家が整っているなら」生産性の掛け算になります。分かったのは、それにはプロジェクトボードも含まれているということです。
そこで私はArboに提案しました。既に存在しているmarkdownファイルだけを読み取る、小さなボードを作ったらどうだろう？ 現実の上にかぶせる窓。
彼は懐疑的でした。午後が終わるまでにその案が生き残るかは、私にも自信がありませんでした。とはいえ代替案は、午前中ずっとJiraボードを更新し続けることで、しかも1週間もすると陳腐化する可能性がありました。
午後遅くには、Jiraは消えていました。すべてのチケットが移行済み。私たち2人と、そしてエージェントも同じボード上で作業しています。
ボード
私たちのエージェントはすでにmarkdownで動きます。YAMLフロントマター付きでファイルを作り、レポートを書きます。なら、なぜ「人がボタンをクリックする」ために設計されたSaaSのボードに、それを流し込む必要があるのでしょう？
すべてのタスクはbacklog/の中のフォルダに存在します。フォルダ名には日付とカテゴリがエンコードされています。その中には、markdownファイルの星座のようなものが並びます：
backlog/
├── 2026-03-26-CHAT-UX/
│ ├── chat-ux-milestones.md # the plan
│ ├── chat-ux-tickets.md # broken into tasks
│ ├── CUX0-report.md # agent completion report
│ └── CUX1-report.md
├── 2026-03-27-AGENT-I18N/
│ ├── agent-i18n-milestones.md
│ ├── agent-i18n-tickets.md
│ ├── I0-report.md
│ ├── I1-report.md
│ └── i18n-audit-report.md
└── 2026-04-01-OPS-DEPLOY-STAGING/
└── CARD.md # simple card, no sub-tasks
マイルストーンファイルは計画（plan）です。チケットはそれを分解したタスクになります。レポートは、マイルストーンを完了したときにエージェントが生成するものです。CARD.mdは、分解するものが何もない単純なタスク用です。各フォルダには、ボードが読み取るYAMLフロントマターを持つ「正（canonical）」なmarkdownファイルがあります：
---
title: "Chat UX Improvements"
type: product
status: wip
assigned: yves
created: 2026-03-26
edited: 2026-04-01
---
タスクを作るエージェントはmkdirを行い、正しいフロントマターを持つmarkdownファイルを書き込みます。スキーマは十分に単純なので、エージェントはフォルダ内の既存ファイルから推測できます。フロントマターが間違っていれば、ボードはそのファイルをスキップするだけです。gitログを見て、YAMLを10秒で直します。
IDEでフォルダツリーをスクロールします。するとボードは、ブラウザ上でまったく同じ構造を描画します。3列：todo、wip、done。カードをドラッグしてステータスを変更するか、タイトルをクリックしてインラインで名前を変更できます。すべてのカードには「エディタで開く」ボタンがあり、ファイルがポップアップで開きます。
IDE上で誰かがbacklogファイルを編集すると、ボードサーバーがすぐに気づきます。ファイルウォッチャーがbacklog/を監視し、5秒間デバウンスして、gitに自動コミットします。保存するだけで、gitが同期されます。
同期
2人と数体のエージェントが、同じ状態を見続けるために最も簡単なものは何でしょう？ Gitです。
ボードのあらゆる操作が、即座にコミットとpushを引き起こします：
[15:42:06] committed: move CHAT-UX to done
[15:42:07] ⬆ pushed
[15:43:12] committed: create OPS-DEPLOY-STAGING as todo
[15:43:13] ⬆ pushed
[15:44:30] committed: rename AGENT-I18N
[15:44:31] ⬆ pushed
受信側の変更については、サーバーが5秒ごとにgit ls-remoteをポーリングします。SSHの往復が1回、SHAの比較が1回。リモートに新しいコミットがあれば、それをpullし、何が入ってきたのかをログに記録します：
[15:45:10] ⬇ synced from remote:
abc1234 board: move AGENT-I18N to wip
def5678 board: update 2026-04-01-SURFACE
ブラウザの更新はServer-Sent Events経由です。ボードは静かに再描画されるので、カードの編集途中であったりフォームを埋めている途中でも、何も消えません。これは最初、手痛い失敗で学びました。最初のバージョンはlocation.reload()をやっていました。:D
同じフローは逆方向でも動きます。エージェントがマイルストーンを完了したら、その時点でバックログフォルダにレポートをコミットし、gitへpushします。5秒後にボードがそれを拾い、カードの詳細表示に新しいファイルが現れます。エージェントに「終わった？」と聞く必要はありません。ボードで見えます。
ボードのコード自体も同じリポジトリにあります。nodemonを通して動かしているので、私たちのどちらかがサーバーへの修正をpushすると、リモートのポーリングがそれを取り込み、nodemonが再起動され、新しいフロントエンドがSSE経由で届きます。私は15時00分にCSSを変えました。ブラウザのタブを切り替えるまでには、反映された新しいスタイルがそこにありました。Arboもそれを見ていました。
カードは更新日時（modified time）の降順で並びます。直近で触ったカードが上に浮かびます。分数インデックスを使った手動のドラッグ順序付けも実装してみました。5分だけ使って、捨てました。ファイルシステムは、そもそも私が今取り組んでいるものを分かっています。
実際に変わったこと
私たちは、これまでのやり方のまま働き続けました。Arboと私がIDEとボードで作業し、エージェントがbacklog/にコミットする。Gitがそれを全部つなぎます。スタック全体は素のHTML/CSS/JSで、ビルド工程もなく、npm依存もゼロです。http.createServer、少しのYAMLパース、そしてfs.watch。
スケールに関する注記
返却形式: {"translated": "翻訳されたHTML"}「SaaSは死んだ、AIなら何でも作れる」という主張が、フィードにやたらと流れてきます。これは人間2人のチームと、数体のエージェントであれば機能します。チーム10人でJiraを置き換えられるのか、置き換えるべきなのかは分かりません。このボードは6か月持つのでしょうか？分かりません。
私が確実に言えるのは、私たちは午前中それを作り、午後にはそれを使ったということです。夕方には、3つのカラムにカードが14枚並んでいました。私がこれを書いている間に、Arboが1枚をWIPへドラッグしました。動くのを見ました。
私たちはJiraに不満があったから置き換えたわけではありません。実は、実際のボードはすでに私たちのファイルシステム上に存在していたから置き換えたのです。Jiraはそれのコピーでしたが、誰もそれをメンテナンスしていませんでした。だからコピーを削除し、元のものにウィンドウをかけました。
私たちの作業のやり方に合うツールだからです。私たちは、自分たちのやり方に合わせてそれを作ったから。これは普遍的な教訓ではありません。これは私たちの話です。
次に私たちが何を作るのか見たいなら、ニュースレターを購読するか、LinkedIn、Mastodon、Blueskyでフォローしてください。
エージェントが必要なプロセスはありますか？お話しましょう。
