01運営者は同じ日に、同じ順序を言い方を変えて 2 度伝えた
材料は 2026 年 9 月 9 日の依頼 2 件である。1 件目で運営者は、日本語版ができたら順に英語のサイトの構築へ進むよう AI に頼んだ。
2 件目は後回しの依頼として送られた。言うまでもないがと前置きしたうえで、日本語版の次は英語版だと改めて書き、英語版は日本語版の公開が完全に終わってから順に始めるよう求めた。
ここで材料の範囲を断っておく。残っているのは依頼の側だけである。AI が順序を破ったのか、なぜ 2 度目を書いたのかは、この 2 件からは分からない。言えるのは、同じ順序が同じ日に 2 度書かれ、2 度目のほうが条件が細かいという事実である。
この事実から、誰でも使える型を取り出せる。同じ順序を言い直したくなったら、言い直す前に、前回の文に何が欠けていたかを見る。
022 度目で増えたのは順序ではなく、開始の条件である
2 件を部品に分けて並べると、順序そのものは変わっていない。日本語が先で英語が後である。変わったのは、英語版を始めてよい時点の書き方である。
| 見るところ | 1 度目 | 2 度目 |
|---|---|---|
| 前の作業 | 日本語版 | 日本語版 |
| 完了の条件 | できたら(どの状態かは書いていない) | 公開が完全に終わった後 |
| 次の作業 | 英語のサイトの構築 | 英語版の対応 |
| 同時に進めるか | 順に進める | 順に始める |
「できた」には幅がある。原稿が書けた時点、組み上がった時点、公開した時点のどれとも読める。「公開が完全に終わった」なら、読み方の幅はかなり狭くなる。
03開始の条件があいまいだと、直しが次の作業に届かなくなる
順序の規則が要るのは、後の作業が前の作業の結果を土台にするときである。公開の直前に日本語版を直せば、その前に訳し始めた英語版には直しが入らない。同じ箇所を二度直すことになり、直し漏れは日本語版と英語版の食い違いとして残る。
食い違いをそろえる仕事は、記録にも現れる。運営者は同じ 9 月 9 日に、日本語と英語の食い違いを探して解消する作業も別に頼んでいる。順序の規則との因果は記録からは言えない。言えるのは、二つの版をそろえることが、別に頼む一つの作業になっていたという事実である。
もう一つの損は、使う人の注意である。規則が頭の中にしかなければ、作業のたびに思い出して書くことになる。書き忘れた回は、規則がないのと同じである。前置きで言うまでもないと書いた順序も、AI の側では書かれた範囲でしか扱えない。
04順序の規則とは、四つの部品を持つ一文である
この回でいう順序の規則とは、繰り返し当てはまる「この作業はあの作業の後」という約束を、次の四つで書いた一文である。
前の作業
土台になる作業を名指しする。日本語版の公開など。
完了の条件
人が見て、はい・いいえで答えられる状態で書く。
次の作業
条件を満たした後で始める作業を名指しする。
同時に進めないこと
条件を満たすまで手を付けない範囲をはっきり書く。
中心は 2 番目である。Anthropic の Claude Code の文書は、確かめられるほど具体的に書くことを勧め、「コードを整える」より「2 字下げにする」のように書くよう例を挙げている。順序でいえば、「終わったら」より「公開したページを確かめた後」である。
対象には境界がある。今回の作業の順番を一度だけ決める指示は、ここでいう規則ではない。依存のない作業に順序を付けると、並行して進められる仕事を遅らせる。規則にするのは、後の作業が前の結果を土台にし、しかも同じ順序が繰り返し要る場合に限る。
05資材審査では、元の資材が確定してから派生物を作る順に効く
製薬企業の資材作りにも、同じ形の順序がある。次の表は、この型を当てはめた例である。実際の条件は、各社の手順書に合わせて書き換える。
| 場面 | あいまいな言い方 | 一度で伝わる言い方 |
|---|---|---|
| 元の資材と英語版 | 日本語ができたら英訳して | 日本語の資材の社内審査で承認が記録された後に、英訳の下書きを始める。それまで英訳しない |
| 冊子と説明用スライド | 冊子が固まったらスライドも | 冊子の最終版が確定した後に、その版を元にスライドを起こす。版の番号を明記する |
| 添付文書の改訂と資材 | 改訂が出たら資材を直して | 改訂後の文書を受け取った後に、影響する資材の一覧を作る。一覧を担当者が確かめるまで本文を直さない |
どの例でも、AI に任せるのは下書きと一覧までである。承認されたかどうかを決めるのは審査の担当者で、AI ではない。完了の条件に人の判断を置くと、その判断の前に AI が先へ進まないよう指示できる。
06会話の中で伝えた順序は、次の作業まで残るとは限らない
順序を言い直すことになりやすい理由は、製品の仕組みからも説明できる。Claude Code を例にとる。文書によれば、セッションごとに新しい文脈で始まる。会話の中だけで伝えた指示は、長い会話の圧縮の後で消えることがあるとも書かれている。
設定のファイルに書いても、絶対ではない。同じ文書は、そのファイルは AI にとって強制の設定ではなく文脈であり、あいまいな指示や矛盾した指示では厳密に守られる保証がないと説明している。
だから、置き場所は破ったときの損で選ぶ。Claude Code の文書は、毎回必ず起こす必要があることは AI の判断に任せる指示ではなく、仕組みで強制するよう勧めている。ソフトウェアの自動処理にも同じ考え方がある。GitHub Actions では、前の処理が成功しなければ後の処理を走らせない依存関係を書ける。前の処理が失敗すると、後の処理は飛ばされる。
製品が違えば仕組みも違う。自分の使う AI で何が次の会話に残るのかは、その製品の文書で確かめる。
07明日からは、2 度言った順序を一文にし、置き場所と止め方を決める
手順は四つある。
- 言い直した順序を見つける。Claude Code の文書も、すでに 2 度直したことを常に読み込むファイルに書く候補に挙げている。2 度目を、前回の文に欠けていたものを探す合図にする。
- 四つの部品で一文にする。「○○が(確かめられる状態)になった後で、△△を始める。それまで△△には手を付けない」と書き、理由を一言足す。Anthropic の文書は、指示の背景を伝えると、目的に合った応答を得やすくなると説明している。
- 毎回読み込まれる場所に置く。使っている AI にプロジェクトの指示や常に読まれる設定の欄があれば、そこに書く。なければ依頼の文面の定型にする。
- 取り返しにくい順序には止める仕組みを足す。公開や社外への送信が絡むなら、人の承認か機械の確認を次の作業の前に置く。
書いた後に一度試す。新しい会話で、次に何を始めてよいかを AI に尋ね、条件を自分の言葉で答えさせる。答えがずれたら、ずれた箇所の書き方を直す。一文にしても守られる保証はないので、公開の前の確認は人の側に残す。
- 同じ順序を言い直すときは、回数を増やす前に開始の条件を見る。「できたら」を確かめられる状態の言葉に置き換える。
- 順序の規則は、前の作業・完了の条件・次の作業・同時に進めないことの四つを持つ一文である。依存があり繰り返す順序にだけ作る。
- 会話の中の指示は残るとは限らない。毎回読み込まれる場所に置き、取り返しにくい順序には人の承認か機械の確認を足す。
同じ順序を繰り返し伝えることは、AI の物覚えの問題としてだけ片づけられない。自分の頭の中にある完了の条件を、まだ文にしていないという合図でもある。その条件を文にして置き場所を決めれば、次からは同じ順序を毎回書き直さずに依頼を始められる。守られたかどうかを確かめる役は、使う人に残る。
- Anthropic. How Claude remembers your project. Claude Code Docs. https://code.claude.com/docs/en/memory
- Anthropic. Best practices for Claude Code. Claude Code Docs. https://code.claude.com/docs/en/best-practices
- Anthropic. Prompting best practices. Claude Developer Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- GitHub. Using jobs in a workflow. GitHub Docs. https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs