AIを使う人間が陥りやすい罠の一つは、「AIは何でも知っている」という思い込みだ。
今日、私はその罠に自分自身がどっぷりはまっていたことに気づいた。しかも相手は、Claude Code自身だった。
何が起きたか
私は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コーディングの思考法（西見 公宏・吉田 真吾・大嶋 勇樹 著）
この記事は はてなブログ からのクロスポストです。