AIのタスク管理台帳｜4項目と更新粒度で再開できる形にする

「昨日の続きって、どこまで進んでいましたっけ」。AIエージェントに仕事を渡していると、この確認が毎回発生します。

セッションは途中で切れます。アップデート、再起動、通信の切断。理由はさまざまですが、共通しているのは、切れる瞬間をこちらで選べないことです。会話の中にしか残っていない状態は、そこで消えます。

残るのは、ディスクに書いたものだけです。タスク台帳という1つのファイルに状態を書いておけば、プロセスが消えても状態は消えません。ただし台帳は、項目を並べただけでは機能しません。何を書き、どの粒度で更新するかを決めて、はじめて次のセッションが動けます。

この記事は、その決め方を扱います。素材は自社で動いているコードと、公式ドキュメントです（検証日2026-08-03）。

進行役は3人です。若葉さんが用語の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントのタスク管理を台帳に残すと、セッションが切れても何が消えないんですか？

若葉さん

若葉さんの発言

台帳って、要するに作業日報のようなものですか。

鈴木さん

鈴木さんの発言

近いのですが、向きが逆だと思っています。日報は終わったことを書きますよね。台帳は、次に読む人が最初にやることを書きます。読み手が未来にいる、という点が違います。

消えるのは、会話の中にしかなかった状態です。どこまで進んだのか、次に何をするつもりだったのか。これらは頭の中と画面の中にあるうちは、形を持ちません。

消えないのは、ファイルに書いた状態です。プロセスが落ちても、ディスクの中身はそのまま残ります。台帳という1つのファイルに状態を寄せておくと、セッションの寿命と作業の寿命を切り離せます。

この記事で決めるのは4つです。台帳に置く項目、更新の粒度、次の一手の書き方、そして自動検知との噛み合わせです。順番に扱います。

隣の記事との線引きも、先に示しておきます。

台帳という記録の持ち方は、役割と責任範囲をAI社員に持たせる組織設計ともつながります。組織側の全体像はAGIM-300で扱っています。

02AI社員のタスク管理を台帳に任せる前に、置き場所と読むタイミングはどう決めるんですか？

必要なものは多くありません。専用のソフトは要らず、Markdownファイルが1つと、それを読むタイミングを固定する仕組みがあれば足ります。前提は次の3つです。

• Markdownファイルを1つ置ける場所があること（追加の権限は要らず、通常のファイル読み書きの範囲に収まります）
• そのファイルを起動時に読む仕組み（フックや同等の自動処理）があること
• 読む対象のパスが、作業ディレクトリが変わっても解決できること

自社の実装では、台帳の実体は06-todo/クロード構築_tasks_20260624/_台帳.mdという1つのファイルです。読むタイミングは、Claude CodeのSessionStartという起動時イベントに固定しています（出典: Claude Code公式ドキュメント「Hooks」）。新規の起動でも、--resumeによる再開でも、このイベントは発火します。

台帳は、会話の保存先である~/.claude/projects/とは別の場所に置いています（出典: 同社公式ドキュメント「Manage sessions」）。会話が保存されることと、状態が引き継がれることは別だからです。

LEDGER_REL = "06-todo/クロード構築_tasks_20260624/_台帳.md"

def project_dir():
    configured = os.environ.get("CLAUDE_PROJECT_DIR")
    if configured and os.path.isdir(configured):
        return configured
    return os.path.abspath(os.path.join(os.path.dirname(__file__), "..", ".."))

（.claude/hooks/check-unfinished-tasks.py実測、64行、2026-08-03）

見どころは、台帳のパスを直書きせずCLAUDE_PROJECT_DIRから解決している点です。前提の3つ目がここで効きます。作業ディレクトリが変わっても、同じ台帳を指し続けます。

台帳ファイルそのものが無い場合、このスクリプトは何もせずに終了します。つまり、最初に台帳を作ることが、この仕組みの出発点になります。

03AIエージェントのタスク管理に使う台帳は、どの項目まで書けばいいんですか？

高梨課長

高梨課長の発言

項目は多いほうが安全に見えるんですが、増やすとまずいんでしょうか。

鈴木さん

鈴木さんの発言

増やすほど埋まらなくなります。埋まらない欄が並ぶと、読む側はどの欄を信じていいのか分からなくなる。だから基本形は小さく持っています。

自社の検証コードは、状態・次の一手・人間ゲート・最終更新の4つを基本形とし、それ以外はオプション扱いにしています。

case_idは、台帳のパーサが実際に読んでいる項目です。省略するとタスクの見出しが代わりに使われます。ただし重複させると、衝突として扱われます。ここは後の章で扱います。

（90_tools/task-governance/task_ledger.py実測、225行、2026-08-03）

04項目を足したくなったとき、AI導入の現場では何を基準に決めるんですか？

基準は1つだけです。その項目が無いと、次のセッションが再開できないかどうか。 次のセッションが再開できるなら、その項目が無くても運用は壊れません。

この基準に当てると、増やしたくなる項目の多くは外れます。優先度、担当者、見積もり時間。どれも管理表としては自然ですが、無くても再開はできます。

外れた項目に価値が無いという話ではありません。置き場所が台帳ではない、というだけです。台帳は引き継ぎ書なので、引き継ぎに要らないものを置くと、読む速度が落ちます。

項目を増やす提案が出たら、いったんこの基準に戻します。「これが無いと再開できませんか」と1回聞くだけで、たいていの候補は自分から降ります。

逆に、この問いに答えられない欄は、後から誰も埋めません。増やすかどうかを決める前に、その欄を埋めるのは誰なのかも一緒に見ておきます。

05台帳の更新粒度は、AIエージェントのタスク管理でどこまで細かくするんですか？

更新の刻み方は、クラッシュしたときに失う範囲で決まります。刻み方は大きく3つに分かれます。

この分け方そのものは、AGIM-216が示している基本形と同じです。ここから先で扱うのは、この刻み方の選び方が自動検知の判定にどう効くのかという、実装側の視点です。

「検証可能な区切り」とは、終わったと言い切れる単位のことです。手順を1つ通した、成果物を1つ出した。そこまで来たら書く、と決めておくと、書くかどうかで迷わなくなります。

06生成AIが日付でしか中断を疑わないなら、更新粒度は何のために細かくするんですか？

粒度を考えるとき、見落としやすい事実があります。自動検知は、日付の単位でしか中断を疑いません。

updated = str(task.get("最終更新", "不明"))
stale = ""
if updated and updated != "不明" and updated < today:
    stale = "  ⚠️前回更新が本日以前＝中断疑い"

（90_tools/task-governance/task_ledger.py実測、2026-08-03）

このコードがやっているのは、最終更新の文字列を今日の日付と比べることだけです。同じ日のうちに何度更新しても、判定の結果は変わりません。中断の疑いが表示されるのは、日をまたいでも最終更新の日付が変わらなかったときだけです。

つまり、粒度を細かくする理由は、自動検知の精度を上げるためではありません。次のセッションが（AIでも人でも）、直前の1区切りをそのまま読める状態にしておくためです。

自動検知は、日をまたいだ放置を拾うための網にすぎません。網の目より細かい動きは、そもそも見ていません。ここを取り違えると、「検知されないなら書かなくていい」という逆の結論に着地します。

07次の一手をどう書けば、AIエージェントは次のセッションで動けるんですか？

次の一手は自由記述です。自由であるぶん、書き方の差がそのまま再開のしやすさに出ます。

良い次の一手の条件は2つです。

• 対象を固有名詞（記事ID・ファイル名・案件名）で書く
• 動詞を1つに絞る

「見直す」だけでは、何をどう見直すのかが次のセッションに伝わりません。対象と動詞がそろって、はじめて次の一手として働きます。

分量は1〜2行が目安です。長く書くほど正確に見えますが、増えるのは状況説明で、対象と動作は変わりません。2行を超えたときは、対象を1つに絞れていない疑いがあります。

08進捗ログの設計で、AI社員のタスク管理がつまずくのはどこですか？

高梨課長

高梨課長の発言

項目と粒度が決まれば、あとは書くだけですよね。

鈴木さん

鈴木さんの発言

そこで一度つまずきます。項目名は自由に決めていいのですが、値の書き方だけは自由にできません。ここをそろえないと、自動検知が黙ります。

つまずくのは、決まって次の3か所です。

1. case_idを使い回す：case_idが別のタスクと重なると、LedgerValidationErrorが発生します。その回の起動時チェックでは🔴🟡の一覧が出ず、「❌ タスク台帳エラー」という1行だけが表示されます（task_ledger.py実測）。台帳全体の自動検知が、その1件のミスで丸ごと止まる設計です。
2. 状態の表記をそろえない：自動検知は「進行中」「中断」「ブロッカー」など、決まったキーワードで分類します。どの語にも一致しない独自の状態名を書くと、「⚠️非標準の状態」という別枠に分類され、優先度の高い🔴の一覧には出ません（task_ledger.py実測）。
3. 最終更新の書式をそろえない：中断疑いの判定は日付の文字列比較です。2026-08-03のようにゼロ埋めした形式なら日付順に正しく比較できますが、8/3のような形式が混ざると、比較結果が実際の日付の前後と一致しなくなります。

3つに共通するのは、台帳の自由度を人が使いこなせなかったときの壊れ方です。項目名は自由に書けても、値の表記だけは決まった形にそろえます。

とくに1つ目は、影響の出方が他の2つと違います。自分のタスクだけが見えなくなるのではなく、台帳の一覧そのものが出なくなります。

09AIのタスク管理が台帳で機能しているかは、AI活用の現場でどう確かめるんですか？

設計しただけでは、自動検知が実際に動くかは分かりません。次の3点で確かめます。

# 1. フックを手動で実行し、分類結果を目で確認する
python3 .claude/hooks/check-unfinished-tasks.py

# 2. 最終更新を過去の日付にしたテスト用エントリで、
#    中断疑いの表示が出るかを確認する

# 3. case_idを重複させたテスト用コピーで、
#    タスク台帳エラーが表示されるかを確認する

1. 通常実行：「🔔 タスク継続チェック」という見出しと、🔴・🟡・⚠️のいずれかの一覧が表示されるかを確認します。台帳がクリーンなら、未完了・中断タスクが無い旨の1行だけが出ます。
2. 中断疑いの再現：最終更新を過去の日付にしたテスト用エントリを台帳に足し、中断疑いを示す表示が該当行に出るかを確認します。
3. エラー経路の再現：case_idを重複させたテスト用コピーを読み込ませ、通常の一覧の代わりにタスク台帳エラーが表示されることを確認します。

この3点を確認できれば、項目設計と更新粒度が、自動検知という後段の仕組みと噛み合っています。テストが終わったら、テスト用エントリは台帳から削除します。

10台帳の更新時刻とファイルの更新時刻は、AIエージェントの運用でどう違うんですか？

若葉さん

若葉さんの発言

ファイルを触った時刻を見れば、進んだかどうかは分かりそうな気がします。

鈴木さん

鈴木さんの発言

分かりそうに見えるのが厄介なところです。保存すれば新しくなるので、中身が進んだかどうかとは別の話になります。だから台帳は、人が書き入れた欄のほうを見ています。

ここまで見てきた比較は、台帳の「最終更新」欄に書かれた値です。OSが管理するファイルの更新時刻（mtime）とは別物です。

違うのは、値を入れる主体です。台帳の欄は、作業した側が自分で書き入れます。mtimeは、ファイルが保存された時点で機械の側に入ります。

自動検知が見ているのは前者だけです。作業が進んでいても、書き入れなければ中断疑いになります。逆に、ファイルへ触れただけでは、この判定は変わりません。

この2つを取り違えると、「更新時刻が新しいから進んでいるはずだ」という読み方になります。障害の切り分けで更新時刻を犯人にしてしまう事故と、その直し方はAGIM-401で扱っています。

11よくある質問

12まとめ｜今日やる3つのこと

台帳は記録簿ではなく引き継ぎ書でした。項目は「無いと再開できないか」で決まり、粒度は次に読む人のために刻みます。そして、値の書き方だけは自由にしません。