何が起きたか

私はClaude Codeを使って記事執筆・調査・自動化を日本語指示だけでまわしている。

この日、Claude Codeに搭載された新機能「Routines（ルーティン）」の活用を考えていた。Routinesとは、スケジュール・GitHubイベント・API呼び出しの3種のトリガーでClaude Codeをクラウド上で自動起動できる機能だ。「GitHubにPRがマージされたら自動でレビューを走らせる」といった自動化が、コードなしで組めるようになった。

私はClaude Codeを複数の専門役割（「調査担当」「設計担当」など）に分けて動かしている。それぞれを「エージェント」と呼んでいる。全体の指示をまとめる役割が「CEO」、技術設計を担当する役割が「architect」だ。

ここで全体を仕切るCEOが動いた。

「architectに設計を任せよう」

CEOはarchitect（設計担当）にこう伝えた。

「Routine GitHubイベントトリガーを使って自動マージを設計して」

architectは調査を開始した。しかし調査の結果、「Routineの設定ファイルにGitHubイベントトリガーの設定例が見当たらない」として、代替案であるGitHub Actionsを採用した設計書を返してきた。

私はそれを受け取り、ふと思った。

「ちょっとまって、GitHubアクションなの？Routineの新機能調べた？」

（この状況、マルチエージェントを組んでいない人でも同じだ。ChatGPTやClaude.aiに「最新の〇〇を教えて」と聞いて、古い情報が返ってきた経験はないだろうか。）

「Claude Codeに調べさせる」という発想

問題は単純だった。architectが参照した知識に、Routines（2026年4月14日リリース）が含まれていなかったのだ。

AIには知識のカットオフ（学習データの締め切り日）がある。それ以降にリリースされた機能は、学習データに入っていない。Claude Code自身の新機能を、Claude Codeが知らない——これは構造上、避けられない話だ。

問題は私にもあった。「architectが知っているはずだ」と思い込んで、調べさせるよう指示しなかった点だ。

改めてresearcherエージェントとclaude-code-guideに「Routine GitHubトリガーの仕様を調べて」と指示した。

調べてわかった正確な仕様

調査結果は明快だった。

GitHubトリガーが対応するイベント

イベント	対応
Pull Request	対応
Release	対応
Push	非対応

architectが設計しようとした「pushイベントでトリガー」は、Routinesでは現時点で使えない。自動マージをやりたければ、Pull Requestイベントで代替する設計が正しかった。

APIトリガーの使い方も判明した

外部システムからRoutineを起動するAPIエンドポイントも明確になった。

curl -X POST https://api.anthropic.com/v1/claude_code/routines/{routine_id}/fire \
  -H "Authorization: Bearer {per-routine-token}" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "任意のコンテキスト"}'

レスポンスには起動されたセッションのURLが返るため、実行状況をブラウザで確認できる（非同期実行）。

さらに、このプロジェクトには既存の「Hourly Dispatcher」（毎時1回起動のRoutine）がすでにあることも確認できた。これを流用すれば、新たにRoutineを作らなくても自動化の枠組みを使いまわせる。

「Claude Codeってそんなことも知らないの？」と思ったあなたへ

これはClaude Codeが「バカ」なのではない。

人間だって、自社の新機能を全員が知っているわけではない。入社して3年の社員に「先月リリースした新サービスの仕様を設計して」と頼んで、その社員が古い仕様書だけを頼りに設計書を返してきても、責める気にはなれない。

問題は指示する側にある。「新機能に関わる話だから、まず最新仕様を調べるよう伝えなかった」——それが今回の失敗だった。

「結局AIって使えないじゃん」と思ったあなたへ

「調べさせた」ことで解決した、という点に注目してほしい。

architectが間違えた設計書を返してきたとき、私がそれを疑わずに実装に進んでいたら——GitHub Actionsの設定を組み、後になって「なぜRoutineのGitHubトリガーを使わなかったのか」と気づく、という無駄が発生していた。

でも、私は（ぎりぎりで）気づいた。そして「調べて」と言い直した。

AIを使うということは、AIの出力をそのまま受け取ることではない。「これは最新情報が必要な話では？」と気づき、「調べて」と一言足す——その判断が人間の仕事になる。

AIに情報を「知らせる」か、AIに「調べさせる」か。 この区別が、AI活用の精度を大きく変える。

この話の普遍性——あなたも同じ罠に踏み込んでいないか

Claude Code固有の話ではない。

ChatGPTでも、Geminiでも、どのAIにも学習カットオフはある。「最新の〇〇の仕様を教えて」と聞いて、AIが古い情報を自信満々に答えることは珍しくない。

特に危ないのは、「詳しそうだから知っているはず」という思い込みだ。コードが書けるからといって、先月リリースされたライブラリの最新仕様まで把握しているわけではない。

AIを相手にするときの実践的な習慣を一つ上げるなら：

「これは〇〇以降にリリースされた機能の話だが、最新ドキュメントを確認してから設計して」

この一言を足す習慣が、今回の失敗を防げた。

Claude Code Routinesとは——ちゃんと使えばこれだけ便利

失敗談の後で恐縮だが、正しく把握したRoutinesは便利な機能だ。

スケジュールトリガー: / schedule daily PR review at 9am の一言で毎朝自動実行
APIトリガー: 外部のwebhookからClaude Codeを起動できる（GitHub Actions、Slack通知など連携先は自由）
GitHubトリガー: PRやReleaseに連動してClaude Codeが動く（pushは非対応だが、PRで代替できる場合が多い）

私は今、Hourly Dispatcherと組み合わせて「記事公開の自動スケジュール管理」を組んでいる。このあたりの実装については別の記事で書く予定だ。

まとめ

今日学んだことを一言で言うなら：

AIは知らないことを「知らない」と言わない場合がある。

自信満々に代替案を返してくることもある。それがベストアンサーに見えても、「これは最新情報が関係する話か？」と一度立ち止まる習慣が、AI活用の精度を上げる。

「AIに全部任せる」より、「AIに調べさせる」——この一歩が意外と大きい。

Claude Codeに興味が出た方には、こちらの書籍も参考になります。

Claude CodeによるAI駆動開発入門（平川知秀著）

実践Claude Code入門――現場で活用するためのAIコーディングの思考法（西見公宏・吉田真吾・大嶋勇樹著）

この記事ははてなブログからのクロスポストです。