Claude Codeで朝の確認表を作るには、「自分の返事待ちはどれか」という一つの問いに答える表を設計するところから始めます。新聞のように全部を短くするのではなく、今日自分が判断する案件、前回から解決した案件、読めなかった範囲の三つに仕分けて、根拠のリンクを付ける。この形にしておくと、毎朝の確認が「どこへ進むか」を決める作業に変わります。
この記事は、2026年10月13日（日本時間）にS.EarchのYouTubeチャンネルで公開された無料動画「朝の確認をAIに任せる｜Claude Codeで「自分の返事待ち」を整理」の無料公開部分（冒頭から終盤の手前まで）を核にしています。仕事のチャットや開発中の変更を日々確認している方が、自分の仕事に当てはめて依頼文を書けるところまで、手順を補いました。
定期実行の仕組みについては、2026年10月13日に確認したAnthropic公式ドキュメントの4ページ（Claude Managed Agents overview、Scheduled deployments、Session budgets、Pricing）の記載で裏付けた範囲に限っています。動画は公式の構築ガイドに触れていますが、そのガイドの公開日とガイド名は、今回確認した公式ページからは特定できませんでした。そのため、この記事では日付とガイド名を書かず、上の4ページの記載だけを根拠にしています。公式ドキュメントは更新されるため、使う前に最新の記載も見てください。
Claude Codeで朝の確認表を作る考え方｜自分宛ての用件を仕分ける受付
朝の確認表とは、チャットや開発中の変更の中から「今日、自分が判断すべき案件」を拾い、根拠のリンクと一緒に仕分けて一枚に並べた表のことです。
毎朝の確認でほしいのは、突き詰めると「結局、僕の返事待ちはどれなのか」という答えです。動画ではこれを、新聞を隅から隅まで短くする仕事ではなく、自分宛ての用件を仕分ける受付に近い仕事だとたとえていました。受付は、来訪者全員の話を要約するのではなく、誰がどの担当に会うべきかを整理します。確認表も同じで、読んだ量ではなく、次に進む先が分かるかどうかで価値が決まります。
動画が完成形として示した例は、確認が必要な変更が二件、昨日の保留が一件解決済み、Slackは読めず未確認、という三つの並びでした。数字は動画でも説明用の例として扱われていて、この記事でも同じ扱いです。個人開発なら、自分へのレビュー依頼を拾う。企業なら、指定したチャンネルとリポジトリから、担当者の判断待ちを拾う。対象が変わっても、仕分けの考え方は同じです。
最初の一歩として動画が勧めていたのは、何を読むかを決める前に、朝に何を決めたいかを一つ選ぶことです。「レビュー依頼を拾いたい」「期限が今日の返答待ちを拾いたい」のように、決めたいことが先にあると、読む場所や条件は後から絞り込めます。
動画の要点｜三つの欄で次の動きが変わる
三つの欄で次の動きが変わるとは、確認表の上段・中段・下段がそれぞれ別の行動（開いて確認する、追わない、人が確認するか接続を直す）に結びつく設計のことです。
動画は、架空の開発チームの朝を例にしていました。ここで出てくるGitHubのプルリクエスト（PR）は、コードの変更を確認してもらうための依頼のことです。以下は動画の説明用の架空例で、実在のチームや案件ではありません。昨日はあなたの確認待ちだったPRが一件ありましたが、今朝までに解決しています。一方、別のPR二件にあなたへのレビュー依頼が届きました。Slackの開発チャンネルは、認証の問題で取得できませんでした。
この材料から、確認表は次のように組み立てます。上段にはレビューが必要な二件と、それぞれの元情報へのリンク。中段には、昨日の保留一件は解決済みと書く。下段には、Slackは取得できず未確認と残す。大事なのは、三つの欄で次の動きが変わることです。二件の依頼は開いて確認する。解決した一件は追い続けない。Slackは人が確認するか、接続を直して読み直す。情報を全部読んだ気になるより、どこへ進むか分かる方が朝の仕事には合う、というのが動画の主張でした。
最初に送る依頼も、ここまで絞れば短く書けます。動画の例は「このリポジトリで、私にレビュー依頼がある未完了PRを、根拠リンク付きでまとめて」というものです。対象のリポジトリ、拾う条件、根拠リンクの有無がそろっているので、AIが探す仕事の輪郭がはっきりします。
確認表の三つの欄｜判断が必要・解決済み・未確認を分ける
確認表の三つの欄とは、「今日判断すること」「前回から解決したこと」「取得できず未確認の範囲」の三つに案件を分け、それぞれに次の動きを決めておく区分のことです。
三つの欄を、動画の架空例に当てはめて表にまとめます。表の内容は説明用の架空例で、実際の案件ではありません。
| 欄 | 架空例での中身 | 読んだ人の次の動き |
|---|---|---|
| 今日判断すること | レビュー依頼が届いたPR二件（元のPRへのリンク付き） | リンクを開いて内容を確認し、自分で判断する |
| 前回から解決したこと | 昨日は確認待ちだったPR一件が、今朝までに解決済み | 追い続けない。履歴として残すだけにする |
| 取得できず未確認の範囲 | Slackの開発チャンネルは認証の問題で読めなかった | 人が直接確認するか、接続を直して読み直す |
表の三行目が、確認表の信頼性を左右します。読めなかった範囲を黙って省くと、「何も来ていない」のか「読めていない」のかが区別できません。下段に「未確認」と明記しておけば、朝の表が空に見えるときでも、安心してよい理由が分かります。逆に、未確認が書かれていれば、その範囲だけ自分の目で見に行けます。
中段の「解決済み」も、見落とされがちですが役に立つ欄です。昨日は気にしていた件が消えたとき、表に何も出ないと、見落としたのか解決したのかが分かりません。解決したと書いてあれば、追うのをやめてよい根拠になります。
Claude CodeとManaged Agentsの役割｜作る側と定期実行する側
Claude Codeとの役割分担とは、確認表の仕組みを設計して作る支援をClaude Codeが担い、決まった時刻に動かす定期実行をClaude Managed Agents側が担う、という動画の整理のことです。
動画は、今回の更新を新機能の発売ではなく、定期的な取得、前回からの変化、取得失敗を扱う設計の紹介として説明していました。そのうえで、Claude Codeはその仕組みを作る支援役、定期運転はManaged Agents側が担う、という分担で整理しています。普通のClaude Codeの会話に「毎朝よろしく」と書けば接続や予約まで完成する、という話ではありません。
Managed Agentsについて、公式ドキュメントで確認できたことは次のとおりです。公式の概要ページによると、Claude Managed Agentsは、管理されたインフラの中で動かせる、あらかじめ用意された設定可能なエージェントの実行基盤で、長時間かかる作業や非同期の作業に向くと説明されています。同じページに、Managed Agentsはbetaで、すべてのエンドポイントにベータ用のヘッダーが必要だと書かれています。利用を始めるには、Claude APIキーが必要です。また、cronスケジュールによる定期的な実行が、機能の一つとして挙げられています（Claude Managed Agents overview）。
一方で、Claude Codeがこの仕組みを作る手順そのものは、今回確認した4ページ（概要、定期実行、予算、料金）には書かれていませんでした。そのため、「Claude Codeに設計を手伝ってもらう」という部分は動画の整理として紹介し、公式がその手順を案内しているとは書きません。実際に作るときは、Claude Codeに「必要な接続、読み取り権限、保存する記録、不足する条件を整理して」と頼み、出てきた設計を公式ドキュメントと照らして確かめるのが安全です。
定期実行で確認できた公式の仕様｜cron・時刻・予算・失敗の記録
定期実行の公式仕様とは、Managed Agentsの「スケジュールされたデプロイメント」が、cron式とタイムゾーンで決めた時刻にエージェントのセッションを自動で始め、実行ごとの記録を残す仕組みのことです。
朝の確認表を毎朝作るには、決まった時刻に自動で動く仕組みが要ります。公式のScheduled deploymentsのページで確認できた内容を、確認表づくりに関係する部分に絞って整理します（Scheduled deployments）。
| 確認表づくりで気になること | 公式ページの記載 |
|---|---|
| いつ動かすか | cron式とIANAタイムゾーンで指定する。最小の粒度は分単位。スケジュールは、決まった周期でエージェントがセッションを自動で始められるようにするもの |
| 実行時刻のずれ | 負荷を分散するため、実際の実行には周期に応じたジッター（ばらつき）が入る。ページには最小5秒、最大9分と書かれている |
| 夏時間などの扱い | 壁時計の時刻で照合する。存在しない時刻は実行されず、二度現れる時刻は二度実行される。欠落や重複を避けたいときは、午前1時から3時の間を避けるかUTCを使うよう案内されている |
| 費用の上限 | デプロイメントに予算（budget）を指定できる。上限は起動する各セッションに複写され、実行ごとに別々に働く。全実行の累計の上限ではない |
| 失敗したとき | 実行を試みるたびに記録（デプロイメントの実行記録）が残り、成功すればセッションID、失敗すればエラーの種類が入る。セッション作成がレート制限された場合は再試行せず、次のスケジュールで再び試みる |
この表のうち、動画が「公式ガイドでも扱っている」と紹介した取得失敗の明示、実行ごとの予算上限に近いのは、下の二行です。公式ページの記載は、確認表の中身（Slackが読めなかった、など）を直接扱うものではなく、実行そのものの成否と費用の上限を扱っています。確認表の中に「読めなかった範囲」を書かせる部分は、依頼文の側で指定する必要があります。
予算については、予算のページにも記載があります。セッション予算は、設定したセッションの費用が上限に達すると新しいモデルへのリクエストを止める、任意の上限です。上限に達したセッションは終了ではなく待機状態になる、と書かれています。また、上限をまたぐ時点で処理中だったリクエストは最後まで実行されるため、記録上の費用が上限をわずかに超えることがある、とも案内されています（Session budgets）。上限は「新しい作業を止める目安」として設定し、ぴったり止まる金額とは考えないほうが誤解が少なくなります。
しおりと現在状態｜前回の位置を残し、報告の直前に確かめ直す
しおりと現在状態の組み合わせとは、前回どこまで確認したかの位置を保存しつつ、報告する直前にその案件が今どうなっているかを確かめ直す、二段構えの仕組みのことです。
毎朝の確認表には、前回の続きが分かる仕組みが必要です。動画は、本を読むときのしおりにたとえていました。どこまで読んだかを残しておけば、次の日はその続きから探せます。ただし、仕事の案件は本と違って、途中で状態が変わります。昨日は返事待ちだった件が、今朝は解決しているかもしれません。だから、前回の確認位置を保存することと、報告直前に案件の現在状態を確認することを組み合わせます。
しおりだけだと、すでに解決した件を「まだ返事待ち」として載せてしまうおそれがあります。現在状態の確認だけだと、前回から何が変わったかが分かりません。両方を使えば、「昨日は返事待ちで、今朝は解決済み」という変化を、確認表の中段にそのまま書けます。
もう一つ、重複を避ける視点も動画は挙げていました。同じ案件が二日続けて上段に載ると、読む側は「また同じ件か」と読み飛ばすようになります。前回載せた案件の記録があれば、すでに載せた件には「前回から継続」と印を付け、新しく届いた件と見分けられます。今回確認した公式の4ページには、重複を防ぐ機能についての記載は見つけられなかったため、これは公式の機能ではなく、依頼文と保存する記録の設計で実現する考え方として紹介します。
保存する記録の中身は、案件を特定する番号やリンク、最後に確認した時刻、そのときの状態、の三つが基本です。記録は小さいほど、翌朝の読み込みも見直しも楽になります。
「重要」の意味を決める｜載せる案件と外す案件を先に分ける
「重要」の意味を決めるとは、確認表に載せる条件と外す条件を言葉にして、AIが「重要そう」という曖昧な印象で選ばないようにする作業のことです。
動画で最初に決めたいと言われていたのが、「重要そう」の中身です。例として、対象はGitHubのリポジトリ一つ、Slackの開発チャンネル一つ。日本時間の朝9時に確認する想定でした。載せる条件は、自分へのレビュー依頼、今日が期限の返答待ち、前回から続く判断待ちの三つです。この三つなら、なぜ載せたのかを一言で説明できます。反対に、完了した案件、取り下げた依頼、参考共有だけの投稿は、対応欄から外します。
| 案件の種類（架空の例） | 確認表での扱い | 理由 |
|---|---|---|
| 自分へのレビュー依頼が届いたPR | 上段に載せる | 判断を求められているため |
| 今日が期限の返答待ち | 上段に載せる | 期限が近く、今日動く必要があるため |
| 前回から続く判断待ち | 上段に載せ、継続と印を付ける | 止まっている案件を見落とさないため |
| 完了した案件 | 対応欄から外し、中段に解決済みとして書く | 追う必要がなくなったことを示すため |
| 取り下げた依頼 | 対応欄から外す | 判断を求められなくなったため |
| 参考共有だけの投稿 | 対応欄から外す | 返事も判断も求められていないため |
朝9時という実行時刻、出力先、実行ごとの予算上限は、後から値を決める設定項目にしておきます。最初から数字を決め打ちにせず、動かしながら調整できるようにしておくためです。なお、公式のScheduled deploymentsのページで確認できる範囲では、時刻の指定はcron式とタイムゾーンで行います（Scheduled deployments）。日本時間の朝に動かしたいときは、タイムゾーンにはIANAの識別子（公式ページの例はAmerica/New_Yorkです）の形式で、自分の地域のものを指定します。
Claude Codeへの依頼文の型｜設計を頼むときに書く内容
Claude Codeへの依頼文の型とは、対象・拾う条件・除外する条件・必要な接続と権限・保存する記録・不足する条件の整理、の六つを順に書く依頼の書き方のことです。
動画で紹介された依頼文は、おおよそ次のとおりです。「指定するリポジトリ一つとチャンネル一つから、私へのレビュー依頼、今日が期限の返答待ち、前回から続く判断待ちを抽出する仕組みを設計してください。完了、取り下げ、参考共有は対応欄から除外してください。必要な接続、読み取り権限、保存する記録、Managed Agentsの定期実行設定と、不足する条件を整理してください」。
この依頼文は、設計を頼む内容になっている点が大切です。いきなり「実装して動かして」と頼まず、まず何が必要で何が足りないかを整理させています。接続や権限は、利用している環境によって設定方法が違います。足りない条件を先に洗い出しておけば、設定の途中で止まる原因を前もって知れます。
注意したいのは、秘密の認証情報を依頼文に貼らないことです。動画も、この依頼文へ認証情報を貼る必要はないと説明していました。どこを読めば判断できるのかを決めて、接続は利用環境の方法に沿って設定します。依頼文に書くのは、何を読み、何を拾い、何を外すかという条件だけです。
依頼文を作るときの確認として、次の点を見てください。拾う条件が絞られているか。除外する条件が書かれているか。読めなかった範囲をどう扱うかが決まっているか。これらがそろっていれば、設計の相手が迷いにくくなります。
判断の境界を残す｜確認表は決裁まで引き受けない
判断の境界とは、確認表が案件を整えるところまでを受け持ち、承認や採用の決定は人が行う、という役割の線引きのことです。
会社の仕事に置き換えるときも、読む場所の数より、判断の境界を先に決めます。動画の例では、架空のPRに「公開前の文言確認をお願いします」と書かれていたとします。この場合、確認表に残したいのは、公開前に文言を確認する必要があることと、元の依頼へのリンクです。AIに「承認してよい」と決めてもらうのではなく、本人が文言を読んで判断する場所へ案内してもらう。その方が、今回の朝の仕事に合います。
完成物の依頼文は、動画ではこう頼んでいました。「今日判断すること、前回から解決したこと、取得できず未確認の範囲に分けてください。各案件には、短い件名、判断が必要な理由、担当、期限、元情報のリンク、状態を確認した時刻を付けてください」。担当や期限が元の資料にない場合は、不明と表示させます。朝の表に載せたからといって、期限を勝手に今日へ変えてはいけません。
個人で使う場合も同じです。自分へのレビュー依頼は拾いますが、そのコードを採用するかどうかの判断は自分が行います。受付が用件を整えても、決裁まで引き受けるわけではありません。誰が最後に決めるのかを確認表の仕様として残しておけば、便利さを自分の担当範囲に収めやすくなります。
始める前の確認とつまずきやすい点｜費用・接続・読めない範囲
始める前の確認とは、定期実行を作る前に、費用の仕組み、必要な接続、betaであることの前提、読めなかったときの扱いを、公式の記載と照らして確かめておくことです。
最初に押さえたいのは費用です。動画は、Managed Agentsはbetaで、APIの設定と費用が別途必要なので、無料でそのまま運転できる前提では始めないでください、と注意していました。公式の料金ページによると、Claude Managed Agentsはトークンとセッション実行時間の二つの軸で課金されると書かれています（Pricing）。具体的な単価は、利用するモデルや時期で変わりうるため、この記事には書きません。使う前に、公式の料金ページで最新の金額を確認してください。使う件数から従量課金と月額制の総額を見比べる考え方は、従量課金と月額制の比較は件数で決まる｜ChatGPTで総額を計算する方法で整理しています。
次に、betaであることの意味です。公式の概要ページには、挙動はリリースの間で改善のために調整されることがある、と書かれています（Claude Managed Agents overview）。朝の確認表を仕事の流れに組み込むなら、仕様が変わる可能性があるものとして、確認表が出ない朝の手動確認の手順も残しておくと安心です。
三つ目は、読めなかった範囲の扱いです。動画の架空例では、Slackが認証の問題で読めませんでした。実際の運用でも、接続の期限切れや権限の不足で読めない日は起こりえます。そのとき確認表が「何も来ていない」と表示してしまうと、見落としにつながります。依頼文に「取得できなかった範囲は、省略せず未確認として書く」と明記しておくことが、いちばん効く対策です。
もう一つの確認は、予算を設定しても、新しい作業を止める目安にとどまる点です。前の章で触れたとおり、処理中のリクエストは最後まで実行されるため、記録上の費用が上限をわずかに超えることがあります。上限は少し余裕を見て決め、最初のうちは結果と費用を見ながら調整するとよいでしょう。
個人と企業での置き換え例｜同じ型で別の「返事待ち」を拾う
置き換え例とは、朝の確認表の型（対象、拾う条件、除外する条件、三つの欄）を保ったまま、拾う対象だけを自分の仕事のものに入れ替えることです。
型は同じで、中身を入れ替えるだけで使えます。以下は説明用の架空例で、実在の人や会社ではありません。
| 使う場面（架空の例） | 拾う対象 | 除外するもの |
|---|---|---|
| 個人で開発している人 | 自分のリポジトリで、自分にレビュー依頼が来ている未完了のPR | 完了したPR、取り下げられた依頼 |
| 少人数のチームの担当者 | 指定した開発チャンネルで、自分宛てに期限付きで頼まれた返答待ち | 参考共有だけの投稿、他の担当者宛ての依頼 |
| 公開前の確認を担当する人 | 文言の確認を頼まれているPR（確認が必要である旨と元リンク） | すでに確認が済んだPR |
どの場合も、最初は一つのリポジトリと一つのチャンネルから始めます。範囲が広いと、読めなかった範囲が増えて、確認表の信頼性が下がります。狭く始めて、確認表が毎朝役に立つと分かってから、対象を足していくほうが失敗が少なくなります。
Instagramの運用に関わる方なら、同じ考え方を別の場面にも使えます。例えば、1つの作業に絞ってAIに任せる考え方はChatGPTでインスタ運用を始めるなら「1作業だけ」で、AIツールを契約する前の確認はInstagram AIツールを契約する前に確認する7項目で、それぞれ扱っています。
Claude Codeを離席中に使う方法は、同じ媒体のClaude Codeクラウドセッションで離席中に修正を任せる方法｜依頼文の型で整理しています。Claude Codeの基本的な使い方は、姉妹サイトのClaude Code Web版の使い方｜クラウドセッションの始め方と制限も参考になります。
よくある質問
- Q1. Claude Codeに「毎朝確認して」と頼めば、毎朝自動で動きますか。
- 動画では、普通のClaude Codeの会話に「毎朝よろしく」と書くだけで接続や予約まで完成するわけではない、と説明されています。定期的に動かす部分は、Managed Agents側の設定で、cron式とタイムゾーンを指定して行います（Scheduled deployments）。
- Q2. Managed Agentsは正式版ですか。
- 公式の概要ページには、Claude Managed Agentsはbetaで、すべてのエンドポイントにベータ用のヘッダーが必要だと書かれています。挙動はリリースの間で調整されることがあるとも書かれているため、使う前に最新の記載を確認してください（Claude Managed Agents overview）。
- Q3. 費用はどのくらいかかりますか。
- この記事では金額を書きません。公式の料金ページには、Managed Agentsはトークンとセッション実行時間の二つの軸で課金されると書かれています。金額は変わることがあるため、最新の数字は公式ページで確認してください（Pricing）。
- Q4. 実行ごとの費用の上限は設定できますか。
- スケジュールされたデプロイメントには、予算（budget）を指定できます。上限は起動する各セッションに複写され、実行ごとに別々に働く、累計の上限ではないと書かれています。ただし、処理中のリクエストは最後まで実行されるため、記録上の費用が上限をわずかに超えることがあります（Scheduled deployments、Session budgets）。
- Q5. Slackなど、読めなかった場所があったときはどう表示すればよいですか。
- 省略せず、下段に「取得できず未確認」と書かせます。動画でも、Slackは取得できず未確認と残す例が示されていました。依頼文に「取得できなかった範囲は未確認として書く」と明記しておくと、何も来ていない日と読めなかった日を区別できます。
- Q6. AIに「承認してよい」まで判断させてもよいですか。
- 動画では、判断の境界を先に決め、AIには判断が必要な場所へ案内させる使い方が勧められていました。承認や採用の判断は本人が行い、確認表は件名、理由、担当、期限、元リンク、確認した時刻を整えるところまでを受け持たせます。
まとめ｜朝に決めたいことを一つ選び、三つの欄で仕分ける
Claude Codeで朝の確認表を作るときは、読む量ではなく、次に進む先が分かるかどうかで設計します。今日判断すること、前回から解決したこと、取得できず未確認の範囲の三つに分け、各案件に元情報のリンクと状態を確認した時刻を付けます。前回の確認位置を保存し、報告の直前に現在状態を確かめ直すことで、解決済みの件を返事待ちとして載せるミスを防げます。
定期的に動かす部分はManaged Agents側の設定で、betaであり、トークンとセッション実行時間で課金される点を前提に始めます。cron式とタイムゾーンで時刻を指定でき、実行ごとの予算と実行記録が用意されていることは、公式ドキュメントで確認できました。一方で、Claude Codeがこの仕組みを作る手順や重複防止の機能は、今回確認した公式ページには書かれていなかったため、動画の考え方や依頼文の設計として紹介しています。
最初の一歩は、何を読むかを決める前に、朝に何を決めたいかを一つ選ぶことです。一つのリポジトリと一つのチャンネルから始め、載せる条件と外す条件を言葉にして、承認の判断は自分の手に残してください。文章で読んだ後に、2026年10月13日公開の無料動画で流れを確認すると、依頼文の組み立て方がつかみやすくなります。ほかの動画記事はS.Enseのトップページから読めます。
この記事は、2026年10月13日公開の無料動画のうち無料で見られる部分と、2026年10月13日に確認した公式ドキュメントの記載をもとにしています。GitHubのPR、Slackのチャンネル、確認表の中身はすべて説明用の架空例です。Managed Agentsはbetaのため、提供条件や料金は変わることがあります。利用前に公式ドキュメントで最新の記載を確認してください。
