最近、コードを書く友人数人と話していたが、みんな共通の悩みがある：大模型はロジックやアルゴリズムを書くのは得意なのに、なぜか定時タスクや時間スケジューリングの部分になると頻繁に失敗する。アスタリスクが足りなかったり、疑問符が多かったり、時間が合わなかったりして、実行してみると全然思い通りにならない。
要するに、問題はCron式にある。これは一見簡単そうに見えるが、5つか6つのフィールドがあるだけだ。しかし実際に使ってみると、落とし穴が多すぎて埋もれてしまう。大模型はどんなに賢くても、確率に基づいてテキストを生成しているだけで、サーバーのタイムゾーンを理解していないし、ビジネスにおける「毎週月曜日の朝9時」の意味も理解していない。ただトレーニングデータの一般的なパターンに当てはめているだけだ。要件が少し特殊になると、例えば「毎月最後の営業日」や「2時間ごとの30分目」など、文法上は正しいが意味的に完全に間違った式を生成し始める。それを実行すると、実行されないか、めちゃくちゃに実行される。結局デバッグに戻らなければならず、かえって手間がかかる。
私が見た中で最悪なのは、大模型に「毎日午前2時半にログをクリーンアップする」定時タスクを書かせたら、0 30 2 ? という式を生成したことだ。一見正しそうに見えるだろう？しかしデプロイしてみると、毎朝8時に実行されることが判明した。なぜか？サーバーのデフォルトがUTCタイムゾーンで、それを考慮していなかったからだ。大模型を責めても、彼もかわいそうだ。彼はただの言語モデルで、「北京時間の午前2時半はUTCで何時か」と聞けば正しく計算してくれるかもしれないが、プロンプトに「午前2時半」と直接書くと、現在の環境のデフォルトタイムゾーンを勝手に使ってしまう。これが典型的な「無言のエラー」で、最も厄介だ。
だから今の私のやり方は、時間スケジューリングのような要件がある場合、絶対に大模型に自由に生成させない。要件を明確に説明し、生成結果をCron式ジェネレーターに入れて検証させる。これは神ツールで、式を入力するとすぐに人間の言葉に翻訳してくれる：「毎月1日と15日の3時15分に実行」と表示され、次回の実行時間も示してくれる。一目で正しいかどうかが分かり、自分で星を数える必要はない。
「毎回手動で検証すればいいじゃないか」と思うかもしれないが、問題は大模型の生成速度が速いので、検証速度もそれに追いつかなければならない。フィールドを一つずつ確認していたら、効率が逆に下がる。しかしジェネレーターを使えば、バッチ検証ができる。例えば、10個の異なる式を生成させて、一度に全部投入すれば、どれに問題があるか一目瞭然だ。ドキュメントを見ながら「W」の意味や「L」の意味を調べるよりはるかに速い。
また、もう一つのコツを見つけた：大模型にCronを書かせる前に、プロンプトに「標準回答」の例を与えることだ。例えば、まず「毎日0時に実行：0 0 0 ?」と書き、「この形式に従って、毎週金曜日の午後6時に実行するものを書いて」と指示する。これでエラー率が大幅に下がる。しかしそれでも、最後の検証ステップは絶対に省略できない。時間スケジューリングは、一度間違えるとオンライン事故になりかねない。軽ければデータがバックアップされていない、重ければ業務ピーク時にタスクがフリーズする。
結局のところ、大模型は良い助っ人だが、神ではない。彼が得意なのは自然言語をコードに変換することだが、「時間」のような強い文脈と暗黙のルールを持つものは、確かに混乱しやすい。開発者として、ツールを使って自分を守ることを学ばなければならない。あのCron式ジェネレーターは、今や私のコードライブラリの常連ブックマークだ。定時タスクを書くたびに、「解析」ボタンをクリックしないと気が済まない。
だから、もしあなたも大模型が生成した時間スケジューリングコードに頻繁に悩まされているなら、急いで彼をバカだと罵る前に、自分のプロンプトが十分でないと疑う前に、2分だけジェネレーターを使って結果を可視化して確認してみてほしい。それが何よりも効果的だ。節約できたデバッグ時間で、コーヒーを2杯余分に飲めるだろう。