AIは日付がわからない｜時計を持たせると、はじめて「無理です」と言える
文・編集：ワークデイズ合同会社
生成AIは、今日が何日かを知りません。聞けば答えますが、それは会話や資料に出てきた日付から組み立てた推測です。私たちの現場でも、AIがこの推測を外したまま作業が進んだことが2回ありました。どちらもエラーは出ず、答えは自信ありげに返ってきました。
先に断っておくと、これは「AIが不注意だった」という話ではありません。日付を渡していなかったのは私たちです。 渡さなければ、AIは黙るのではなく推測で埋めます。
この記事では、日付を渡す仕組みを自社で作ってみて分かったことを書きます。結論を先に言うと、時間が足したのは情報ではなく制約でした。締切の可否について、時間を持たないAIは構造上「はい」に寄る——私たちはそう見ています。時間が入ってはじめて、「それは間に合いません」——つまり「無理です」——と言えるようになります。以下、この記事では具体的な言い方として「間に合いません」を使います。
AIは、今日が何日かを知らない
AIは時計を持っていません。理由は2つです。
- 学習に使ったデータは、過去のある時点までのまとまりです。そこから先の日付は、そもそも入っていません。
- AIの本体は、パソコンやサーバーの時計を読めません。読むための仕組みが、外から与えられていないかぎり存在しないからです。
だから「今日は何日？」と聞かれると、AIは手元にある材料——会話に出てきた日付、読んでいる資料に書かれた日付——から推測します。推測なので、外れます。しかも外れたことをAI自身が知りません。
日本語で使うときは、もう1つ落とし穴があります。多くのシステムは内部で世界標準時（UTC）を使っていて、日本時間はそこから9時間進んでいます。深夜から早朝にかけては、この9時間ぶんで日付が1日ずれます。
そして一番やっかいなのが、相対的な言い方です。「今週」「来週の月曜」「3日後」「さっきの打ち合わせ」——これらは全部、今日が何日か決まらないと決まりません。基準点が無いまま計算するので、答えは自信ありげに、静かにずれます。
AIが推測で埋めた、2つの経験
私たちの日常業務で実際に起きたものです。どちらも、AIが出した答えは自信に満ちていました。
経験1：期限が目前なのに、AIが「変化なしです」と3回報告した
私たちが使っている別のファイル置き場（リポジトリ）での作業中に起きました。ある資料の最終更新日が「2026-08-19」になっているのを見て、AIはそこを「今日」だと判断しました。実際には、そこから3日経っていました。
そのうえで、AIは「変化なしです」と3回報告しました。
「変化なし」自体は、事実として正しいのです。 資料は本当に変わっていません。抜けていたのは、それが何日ぶんの「変化なし」かでした。更新された当日の「変化なし」はただの正常で、3日動いていない「変化なし」は止まっているという意味になります。同じ言葉が、経過時間で意味を変えます。
そしてAIは、その資料に紐づく期限が目前に迫っていたことにも気づけていませんでした。今日が何日か分からなければ、期限まであと何日かも出せません。 ここは「変化なし」と違って、はっきり間違いです。
AIを責めても始まりません。資料に書かれた日付と今日を区別する手段が、AIには無かったからです。この一件のあと、そのファイル置き場では「状況確認するときは、日付を理解したうえで確認する」をルールにしました。順番の話です。日付が分からないまま状況だけ見ても、それが正常なのか止まっているのかは決まりません。
経験2：すでに書かれていたのに、AIが「リポジトリに無い」と断言した
このサイトのリポジトリで起きました。作業の間が長く空いているあいだに、別の作業が並行して進み、記録が追加されていました。AIはそれに気づかないまま、「その記録はリポジトリに無い」と断言しました。実際には、すでに書かれていました。
これも同じ形です。AIから見ると、会話はひと続きに見えます。前のやりとりから何時間空いたかが渡されないので、その間も時間が止まっていたかのように動きます。
すると視野から落ちるのが、自分の会話の外で進んでいたことです。別の作業が並行して動き、記録が追加されていた——それを疑う理由が、そもそも生まれません。
「知らなかった」のではなく、「確かめる理由がなかった」のです。
共通点は「エラーが出ないこと」
| 経験1 | 経験2 | |
|---|---|---|
| AIが立てた前提 | 資料の更新日＝今日（経過0日） | 会話の外でも時間は止まっている |
| AIが出した答え | 「変化なしです」（3回） | 「リポジトリに無い」 |
| 実際 | 3日止まっていて、期限が目前 | 会話の外で作業が進み、すでに書かれていた |
| 渡していなかったもの | 今日の日付 | 前回からの間隔 |
| 画面に出たもの | 何も出ない | 何も出ない |
| どう気づいたか | 記録に残っていない | あとで最新の状態を取り込んだとき |
どちらもエラーが出ません。 処理は最後まで通り、画面は何も赤くなりません。答えは、片方は足りないまま、片方は間違ったまま、どちらも自信ありげに返ってきます。だから気づくのは、いつも手遅れになってからです。
そしてもう1つ共通しているのが、表の「渡していなかったもの」の行です。間違えたのはAIですが、渡していなかったのは私たちでした。日付も間隔も、渡してさえいれば分かるものです。ここを取り違えると、対策が「AIに気をつけさせる」という効かない方向へ行きます。
よくある対策が、続かない理由
検索して出てくる対策は、だいたい次の3つに集約されます。
| 対策 | やること | 続くか |
|---|---|---|
| プロンプトに日付を書く | 「今日は2026年8月24日です」と毎回添える | 続かない（人が毎回やる必要がある） |
| Web検索で調べさせる | 「Webで今の日本時間を調べて」と毎回指示する | 続かない（人が毎回やる必要がある） |
| ツール側の時計を渡す | 仕組みが自動で渡す | 続く（一度作れば効き続ける） |
どれも間違っていません。私たちも最初は1番目をやっていました。問題は、1番目と2番目が人の記憶に依存することです。忘れたら効かなくなり、しかも忘れたことに気づけません。日付が渡っていなくても、AIは黙りません。推測で答えます。
再発防止策が「気をつける」の形で書かれているうちは、こういう抜け方をします。ルールの中身より置き場所の問題なので、詳しくはAIが指示を守らないのはなぜか｜再発防止策を3つの層に仕分けるにまとめました。
私たちが入れた仕組み：毎回、黙って日時を渡す
ここから先は、少し技術寄りの話が続きます。仕組みの中身に関心がなければ、「はじめて『間に合いません』と言える」まで読み飛ばしても筋は通ります。
やったことは単純です。メッセージを送るたびに、日時の1行を自動で差し込むようにしました。
私たちは開発の作業に Claude Code というツールを使っていて、そこには「メッセージを送信したタイミングで小さなプログラムを走らせる」仕組み（フック）があります。そこに時計を1つ登録しました。出てくるのは、この1行だけです。
[時計] いま 2026-08-19(水) 19:45 JST（UTC 10:45）／昨日 2026-08-18・明日 2026-08-20作ってみると、素直に作るとかえって悪くなる箇所がいくつもありました。
- 値をどこにも保存しない。 保存した瞬間に、その値は古くなります。毎回その場で計算します。
- 作業の開始時だけにしない。 長い作業では日付をまたぎます。自信のある壊れた時計がいちばん危ない。
- 日本時間と世界標準時を併記する。 自動実行の設定やログは世界標準時で動いているので、片方だけだと読み違えます。
- 時刻が取れなかったときも、黙って消えない。 取れなかったという事実を出します。時計が止まったことに気づけないほうが危ない。
- 時計が失敗しても、作業自体は止めない。 時計が壊れていても、リポジトリは使えるべきです。
最後に、この時計そのものが壊れていないかを見るテストを16ケース書きました。わざと3種類の壊し方（曜日をずらす／世界標準時の併記を消す／取得に失敗したとき黙る）を仕込んで、全部検出されることを確認しています。
もう1つ、運用のルールとしてこう決めました。「日時が話題に関係ないときは、返答で触れない」——時計は黙って正確でいるためのもので、報告するためのものではないからです。毎回「いま何時です」と書かれると、うるさくて読み飛ばされ、いざ必要なときにも効かなくなります。
時刻の次に渡すもの——「間隔」と「締切までの残り」
作ってみて分かったのは、現在時刻が分かることと、締切から逆算できることは別物だということでした。渡すものは、次の3段階になります。
①の「いま何時か」は前の節で入れたものです。ここでは②と③を書きます。
② 前回のやりとりからの間隔
前回から何時間空いたか、日付をまたいだかどうかが分かると、そのまま続きとして進めてよいのか、状況を確認し直すべきなのかを変えられます。経験2は、まさにこれが無くて起きました。
気をつけたのは、毎回は出さないことです。30分未満は黙ります。毎回出ると飾りになって、読まれなくなるからです。そして3時間以上空いたときと日付をまたいだときだけ、「この間に別の作業が進んでいるかもしれない」という趣旨の一文を添える。時間を伝えるのではなく、時間に紐づく行動を伝える、という形にしました。
③ 締切までの残り日数
私たちは毎週月曜にコラムを出しています。次の空き枠までの残りを、作業を始めるたびに（AIとの会話を開いた時点で）1行で出すようにしました。日時の1行が毎メッセージなのに対して、こちらは会話の頭で1回です。
[公開枠] OK｜次の空き 2026-09-21(月)／セット期限 2026-09-07（あと14日・営業日10日）これはこの記事を書いている時点の出力で、実際にはこの後ろに予約済みの本数と最終予約日も付きます。
ここで効いたのが、「暦で14日」と「営業日で10日」を並べたことです。土日を含む日数は、実態より長く見えます。「2週間ある」と思っていたものが、実際に動かせるのは10日しかない。並べて初めて見えました。
もう1つ、期限そのものについて。私たちの別のファイル置き場では、期限を書くときにその日付にした理由も必ず添える運用にしています。「◯日から逆算した日。ここを過ぎると◯日が動く」と書いておくと、前提が崩れたときに何が連鎖して動くかがその場で分かります。日付だけを並べた一覧では、これが分かりません。
はじめて「間に合いません」と言える
時間が足したのは、情報ではなく制約でした。
時計を持たないAIに何を頼んでも、着地はだいたい「選択肢を並べる」になります。良さそうな案を全部出して、選ぶのはあなたです、という形。親切に見えますが、判断はしていないということでもあります。
時間が入ると、話が可否の問題に変わります。「営業日で10日しかない。校閲はこれまで2〜5周かかっている。この企画は入らない」と言えるようになる。締切の可否については、時間を持たない相手は構造上「はい」に寄る——これが私たちの見方です。
実際に、止められたことがあります。納期のあるプロジェクトで、残り時間と進捗をAIに渡した状態で作業を追加しようとしたところ、「間に合わない可能性がある」と忠告されました。こちらが頼んだのは作業の追加で、返ってきたのは可否の判断です。時間を渡していなければ出てこなかった答えだと、私たちは受け取っています。
ただし範囲は切っておきます。これは1つの場面での話で、「間に合いません」と言われた回数を数えているわけではありません。
そのうえで、時間を渡さないことの損について1つ。損の大きさは、失敗にいつ気づくかで決まります。 その場で気づける失敗は安く済みます。取り返す時間が残っているからです。納期の失敗は逆で、気づくのが納期の当日——そのとき残る手は、残業か謝罪しかありません。前の週に気づけていれば、まだ手前で削る判断ができます。同じ「間違い」でも、発覚が遅いものほど取れる手が減ります。
冒頭の経験1が、まさにそれでした。3日止まっていたことだけでなく、期限が目前に迫っていたことにも気づけていませんでした。遅れと期限が、同時に見えなくなる。 時計が本当に効くのは、この種の見落としのほうです。
私たちの実感には、外に裏づけもありました。2026年1月に公開された論文 Real-Time Deadlines Reveal Temporal Awareness Failures in LLM Strategic Dialogues（arXiv:2601.13206）で、2体のAIに制限時間つきで交渉させる実験が報告されています。要旨によれば——
- 全体の制限時間だけを知らせた群では、合意成立が 4%（GPT-5.1）
- 毎ターン「残り時間」を伝えた群では 32%（同じモデル）
- 提案の受諾は 6倍
そして決定的なのが、制限のかけ方を変えた比較です。同じAIでも、制限を「時間」ではなく「ターン数」に変えると、成立率は95%以上になります。つまり失敗しているのは交渉の戦略ではなく、時間を自分で数えることのほうでした。
正直に断っておくと、私たちが読んだのは要旨までで、本文（実験の設定や回数）は読んでいません。ここで引いているのは、要旨に書かれている範囲だけです。あわせて、この実験が比べたのは「全体の制限時間だけを知らせる」と「毎回、残り時間を伝える」の2つで、「今が何時か」だけを渡す条件は試されていません。
限界：時計は納期を正確にするが、見積もりは正確にしない
時計を入れて正確になったのは、納期の側だけです。見積もりの側は、何も正確になっていません。
「営業日で10日ある」は正確です。しかし「この記事は校閲4〜5周で終わる」という見立てのほうは、根拠が過去4本ぶんの実績しかなく、当たるかどうかは終わってみるまで分かりません。曖昧な見積もりの上に精密な時間計算を乗せると、全体が実際より厳密に見えてしまいます。ここは危ないところだと思っています。
なので私たちは、時計とは別に「見積もりを先に書き残す」仕組みも足しました。書き始める前に「校閲は何周かかると思うか」を必ず書き、校閲が終わった時点で実績を並べて置く。いまの「4〜5周」も、書き始める前に書いたものです。外れても、あとから予測のほうを書き換えることはしません。外れを残すことが目的だからです。
そしてもう1つ、正直に。この記録から、時計の効果を取り出すことはできません。 校閲の周回数は、時計のあるなしだけでなく、校閲の厳しさやゲートを足したことでも動くからです（実際、私たちの周回数は最近ほど増えています）。日数のほうも、いま揃っているのは前に書いた記事1本ぶん——校閲5周・起草から校閲通過まで3日＝1周あたり約0.6日——だけです。1本では、何とも言えません。
明日、ひとつ試せること
3つだけ確認してみてください。
- いま使っているAIに、今日の日付は渡っていますか。 仕組みを作らなくても、会話の冒頭に1行書くところからで構いません。まずは渡っていない状態がどれだけ危ないかを知るところから。
- 締切までの残りは渡していますか。 上の実験で効果が確かめられているのは「毎回、残り時間を伝える」ほうです（「今が何時か」だけを渡す条件は、この実験では試されていません）。私たちは「この件は◯月◯日が期限で、あと営業日で◯日です」と添えるようにしています。営業日で数えるのは私たちの工夫で、研究で裏づけがあるのは「残りを毎回伝える」ところまでです。
- AIから「それは間に合いません」と言われたことがありますか。 一度も無いとしたら、それは仕事が全部間に合っているのではなく、AIが判断するための材料を渡していないだけかもしれません。
数字をAIに推論させず、計算結果を機械で照合するという話はAIの数字はなぜ間違うか｜“計算は計算機・AIは言語化”の実務に書きました。日付もまったく同じで、推論させずに渡すのが答えです。時計は、AIを賢くする道具ではありません。推測しなくて済む状態を作る道具です。