良いプロンプトがあれば、エージェントはループに従うのではありませんか？

プロンプトはループを説明できますが、守らせることはできません。2つのエージェントが同じタスクを確保するのを止められず、クラッシュしたエージェントが持っているタスクを解放することもできません。Weft では確保はサーバーが持つリースなので、エージェントが指示を覚えていたかどうかに関係なく、そうした場合が処理されます。

エージェントが途中でクラッシュしたらどうなりますか？

ハートビートが止まります。最後の report_progress から20分後に実行は stale と記録され、リーストークンは消され、タスクは再び未割り当てになるので、別のエージェントや人が取れます。カードが1週間 Doing に居座ることはありません。

終わったタスクはすべて私のレビューを待つのですか？

いいえ。既定では、完了したタスクは結果と証拠を添えてそのまま Done に進みます。インボックスで承認、差し戻し、あとで、取りやめを待つのは、タスクにレビューが必要なときか、検証チェックに落ちたときだけです。

なぜエージェントが仕事を断られるようにしたいのですか？

そうしないと、確かめる時間のないものを作り続けるからです。5件（チームでは10件）、またはレビュー約45分ぶんが人を待つと、start_task は attention_queue_full を返し、エージェントにまだできることを示します。キューを片づければ再開できます。

Hypertask にもリースがあります。なぜ MCP が大事なのですか？

Hypertask のリースは、同社自身のドキュメントによれば REST エンドポイントで（MCP overview）、CLI からも確保できます。スクリプト化されたエージェントにはそれが合います。エディタやチャットで MCP ツールを通じて働くエージェントはそこではリースを得られませんが、Weft では得られます。start_task、report_progress、complete_task が MCP ツールだからです。

ブログ

AI エージェントのタスク管理: 確保のループはプロンプトではなく契約にする

サーバーが守らせる確保のループで AI エージェントのタスクを管理する方法。リース、ハートビート、質問、完了の記録、そして人の注意への上限。

Weft は、ひとり創業者と小さなチームのための AI タスク管理です。

記事一覧

著者: Andrei Finogeev · 2026年10月27日

AI エージェントのタスク管理がうまくいくのは、ループを持つのがプロンプトではなくボードであるときです。エージェントは何をすべきかを尋ね、黙ると切れるリースでタスクを一つ確保し、本人のものである判断だけを本人に尋ね、誰かが確かめられる記録を添えて終える。Weft ではその各段階がサーバーの検査する MCP ツールなので、段階を飛ばしたエージェントは、知らないうちにずれていくのではなく、断られるかタスクを失います。

Weft は私たちが作っています。他社製品についての事実は各社の公式ページから取り、2026年10月27日に確認しました。

チャットに貼ったタスクリストは、なぜうまくいかなくなるのか

タスクをチャットに貼るのは誰もが最初に試すことで、午後のあいだは機能します。やがてチャットが終わり、状態も一緒に消えます。エージェントは、どの項目を終え、どれをあきらめ、何に自信がなかったかを知っていました。いまは誰も知りません。

リストを貼った人が中継役になり、結果を本物のボードに書き戻し、取られていると何も示していなかったせいで2つ目のセッションが拾った仕事をやり直すことになります。

ボードへのアクセスが解決するのはスナップショットの問題で、残りは解決しません。ツールが「カードを動かす」と「コメントを付ける」だけなら、ループはやはり、エージェントが指示に書かれた約束事に従うかどうかにかかっています。約束事は、まさに物事がうまくいかないときに壊れます。エージェントが実行の途中でクラッシュしたとき、あるいは2つのエージェントが同時に始めたときです。

契約としての確保のループは、どんな形か

Weft ではループは五つの段階からなり、それぞれが一つの MCP エンドポイント https://letsweft.com/api/mcp 上の別々のツールです。段階の間の状態はサーバーが保つので、ループはどのチャットが終わっても生き残ります。

get_my_work: 選ぶ前に尋ねる。 答えには、このクライアントがすでに持っているもの、本人を待っているもの、期限切れや期限間近のもの、そもそも何かを始める余地があるかが含まれます。
start_task: リースで確保する。 確保は20分続き、タスクを Doing に動かします。応答には runId、leaseToken、renewEverySeconds: 300 が含まれます。同じタスクを試した2つ目のクライアントには already_claimed と、仕事を重複させないようにというヒントが返ります。
report_progress: ハートビート。 run id とリーストークンを付けた呼び出しのたびにリースが更新されます。エージェントが死ぬとハートビートが止まり、20分後に実行は stale と記録され、タスクは誰でも取れる未割り当てに戻ります。リースを失うと lease_lost が返るので、エージェントはもう自分の仕事ではないとわかります。
request_input: 本人のものである判断にだけ。 500文字までの質問と、最大10個の選択肢。エージェントが待っている間も確保は保たれます。
complete_task: 記録を添えて終える。 outcome、artifacts（URL、コミット、ファイルのハッシュなどの証拠）、notDone、unknowns、nextStep。

なぜステータスではなくリースなのか。クラッシュしたエージェントが送れる信号は沈黙だけだからです。Doing にあるカードは、かつて誰かが取り組んでいたことを示すだけです。リースは、いま誰かが取り組んでいることを示し、それが事実でなくなれば自然にそう示さなくなります。

確保そのものは、一意インデックスで守られた一回のデータベースへの挿入です。2つのエージェントが競うと、どちらが勝つかはデータベースが決めるので、両方がタスクを得ることはありません。対照的に、1秒違いで投稿された2つの「確保しました」コメントは、どちらも正当なコメントです。

エージェントはいつ request_input を呼ぶべきか

本人にしか決められないことに行き当たったときです。お金、公開、本番環境、法務のような取り返しのつかないこと、あるいは妥当な既定のない本当の分かれ道。続けてよいかの許可を求めるためではありません。

この慎みが大事なのは、質問は終わったタスクと同じだけ本人の注意を使い、Weft では同じ上限に数えられるからです。質問はインボックスに入り、モバイルのプッシュが届き、20分以上待っている項目にはメールでの催促も届きます。Weft からエージェントを呼び戻すことはありません。答えは次の start_task か get_my_work で届きます。質問が開いている間、エージェントは60分間タスクを保ちます。その後リースは外れますが、質問は残ります。

complete_task の呼び出しには何を入れるか

短い結果、証拠、そして端の部分についての正直な説明です。バグ修正の現実的なペイロードはこうなります。

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

成果物は、エージェントの言葉を鵜呑みにせずに本人が確かめられるものです。notDone と unknowns は告白ではありません。頼れる結果と、差分から組み立て直す結果とを分けるものです。証拠がなくてもこの呼び出しは失敗しません。終わった仕事を失うほうが、未検証のまま記録するより悪いからです。これらの記録の読み方はAI エージェントは何をしたのかで詳しく書いています。

カードを動かしてコメントするのと何が違うのか

同じループについての Hypertask のガイド（確保、更新、報告、クローズ）は、この習慣をうまく説明しています。その MCP 版の確保は、タスクを読み込み、作業中のセクションに動かし、確保のコメントを付けることで、チームがエージェントの指示に書くプロンプトがそれを導きます。同じループを段階ごとに並べるとこうなります。

ループの段階	約束事だけのボード（エージェントがカードを動かしてコメントする）	Weft が守らせること、とその MCP ツール
仕事を選ぶ	エージェントがタスクを一覧にして選ぶ。本人がすでにレビューに埋もれていることは、何も教えてくれない。	`get_my_work` が、このクライアントがすでに持っているもの、本人を待っているもの、期限切れのもの、何かを始める余地があるかを返す。
確保	カードを Doing に動かし、「確保しました」と投稿する。2つのエージェントが同時にこれをやり、両方が自分のものだと思い込める。	`start_task` が、一意インデックスで守られた一回のデータベース書き込みで20分のリースを取る。負けたほうにはタスクの id とタイトル付きで `already_claimed`。
生きていることを示す	エージェントが覚えていれば、進捗のコメント。クラッシュしたエージェントは、カードを Doing に置きっぱなしにする。	`report_progress` がリースを更新する（エージェントには5分ごとにと伝えられる）。20分黙ると実行は stale と記録され、タスクはまた空く。
尋ねる	「Blocked:」のコメント。エージェントは止まるか推測する。カードはまだ進行中に見えるかもしれない。	`request_input` が、最大10個の選択肢付きの質問を本人のインボックスに入れ、確保を保つ（待機中は60分）。答えは `start_task` か `get_my_work` で戻る。
報告	自由記述の最後のコメント。その形はプロンプトの出来次第。	`complete_task` が名前付きの項目を受け取る: `outcome`、`artifacts`、`notDone`、`unknowns`、`nextStep`。
クローズかレビュー	エージェントがカードを Review か Done に、プロンプトの言うほうに動かす。	既定ではタスクは Done へ。レビューが必要なときや検証チェックに落ちたときは、インボックスで止まり、承認／差し戻し／あとで／取りやめを待つ。
過負荷	何もない。エージェントは仕事を始め続け、Review のカラムが伸びていく。	5件（1人）または10件（チーム）、あるいはレビュー45分ぶんが人を待つと、`start_task` は `attention_queue_full` で断る。

Hypertask に公平を期して言えば、本物のリースはあります。ドキュメントにはリースの確保、ハートビート、解放のエンドポイントが載っており、Known limitations の表には、タスクのリース、証拠、エスカレーションは設計上 REST エンドポイントのみとあります（Hypertask MCP overview）。tools reference の21の MCP ツールにリースのツールはありません（tools reference）。CLI も任意のコマンドとして確保できます（changelog、CLI reference）。つまり Hypertask 上のスクリプト化されたエージェントはリースを持てますが、Claude Code や Cursor で MCP を通じて働くエージェントは、誰かが REST の呼び出しを配線しない限り、カードとコメントの版になります。

エージェントがスクリプトや CI のジョブとして動くなら、Hypertask の CLI と REST API は本物の強みで、Weft にはどちらもありません。CLI なし、公開 REST API なし、Webhook なし。Weft は、MCP クライアントの中で暮らし、そこでループが保たれる必要のあるエージェントのためのものです。

本人には何が見えるか

たいていは Done にあるカードです。既定では、完了したタスクは結果と証拠を添えてそのまま Done に進みます。

タスクが本人のインボックスで止まるのは、レビューが必要と印が付いていたとき、または検証チェックに落ちたときです。そこで本人は四つの答えから一つを選びます。

承認: 仕事はそのまま認められます。エージェントが nextStep を渡していれば、本人はそれをボタンの上に見ます（「承認すると、エージェントは次を行います…」）。承認はまさにその一歩を承認し、それより広いことは承認しません。承認は72時間有効で、get_my_work か start_task を通じてエージェントに戻ります。
差し戻し: 何が違うかを書いたメモを付けて戻します。
あとで: いまではない。取りやめ: これ以上取り組まない。

インボックスはウェブにあり、何かが入ると本人には Weft のモバイルアプリにもプッシュが届きます。nextStep のやり取りがあるので、エージェントは「良さそう」をマージ、デプロイ、送信の許可と取り違えません。許されるのは承認された一歩だけで、その後もう一度タスクを完了させます。

なぜエージェントは、仕事を増やす代わりに断られるのか

足りないのは仕事ではなく注意だからです。人が一つをレビューする間に、エージェントは十のことを始められます。

Weft は人を待っているもの、つまりレビュー待ちのタスクと未回答の質問を数えます。それが1人のワークスペースで5件、チームで10件、または見積もりのレビュー時間で約45分の、どれか早いほうに達すると、start_task は attention_queue_full で断ります。上限はプランではなく、ワークスペースの人数で決まります。

この拒否は行き止まりではなく指示です。キューの大きさ、いちばん古い項目の経過時間、まだ許される呼び出し（report_progress、get_my_work、get_board_state、search）を返します。そのカードで本人がすでに承認した一歩は対象外なので、承認済みの「PR #418 をマージする」がキューに止められることはありません。

どう設定するか

クライアントを接続し、ブラウザでサインインします。コピーするキーはありません。Weft はリフレッシュトークンを発行するので、クライアントが自分でサインインを更新します。Claude Code ではコマンド一つ、claude mcp add --transport http weft https://letsweft.com/api/mcp です（設定ページ）。Cursor はワンクリックでインストールでき（Cursor）、Codex は設定項目と codex mcp login weft が要り（Codex）、ChatGPT には Free を含む全プランで公開済みの Weft アプリがあります（ChatGPT）。ループはサーバー自身がエージェントに説明するので、ライフサイクルのためのプロンプトは要りません。

Claude Code での手順はClaude Code のタスクボードをご覧ください。リースと already_claimed がいちばん効いてくる、1つのボードで複数のエージェントを動かす場合は1つのボードで複数の AI エージェントを動かすをご覧ください。プロトコル自体は modelcontextprotocol.io に、ほかの MCP ボードの比較は MCP タスク管理ツールにあります。

ここで Weft がやらないこと

CLI、公開 REST API、Webhook はありません。cron のジョブや CI のパイプラインは、MCP クライアントの外からループを動かせません。
GitHub や Slack との連携はありません。証拠は、エージェントが artifacts にリンクしたものです。
内蔵 AI はありません。考えるのはあなた自身の AI クライアントで、だから Weft には AI クレジットが要りません。

Free はタスク50件と月200回の AI 呼び出しをカバーします。Pro は1席あたり月 ¥1,182 または年 ¥10,000 です（料金）。

良いプロンプトがあれば、エージェントはループに従うのではありませんか？: プロンプトはループを説明できますが、守らせることはできません。2つのエージェントが同じタスクを確保するのを止められず、クラッシュしたエージェントが持っているタスクを解放することもできません。Weft では確保はサーバーが持つリースなので、エージェントが指示を覚えていたかどうかに関係なく、そうした場合が処理されます。
エージェントが途中でクラッシュしたらどうなりますか？: ハートビートが止まります。最後の report_progress から20分後に実行は stale と記録され、リーストークンは消され、タスクは再び未割り当てになるので、別のエージェントや人が取れます。カードが1週間 Doing に居座ることはありません。
終わったタスクはすべて私のレビューを待つのですか？: いいえ。既定では、完了したタスクは結果と証拠を添えてそのまま Done に進みます。インボックスで承認、差し戻し、あとで、取りやめを待つのは、タスクにレビューが必要なときか、検証チェックに落ちたときだけです。
なぜエージェントが仕事を断られるようにしたいのですか？: そうしないと、確かめる時間のないものを作り続けるからです。5件（チームでは10件）、またはレビュー約45分ぶんが人を待つと、start_task は attention_queue_full を返し、エージェントにまだできることを示します。キューを片づければ再開できます。
Hypertask にもリースがあります。なぜ MCP が大事なのですか？: Hypertask のリースは、同社自身のドキュメントによれば REST エンドポイントで（MCP overview）、CLI からも確保できます。スクリプト化されたエージェントにはそれが合います。エディタやチャットで MCP ツールを通じて働くエージェントはそこではリースを得られませんが、Weft では得られます。start_task、report_progress、complete_task が MCP ツールだからです。