AIをある程度使えるようになると、次の壁が来ます。

一回だけなら、かなり良いものを作れる。

ところが、同じ作業を10回、30回、数日間と続けると崩れる。

前に決めた条件がいつの間にか変わる
「完成した」と言われたのに実ファイルがない
古い案と最新版が混ざる
修正したら別の箇所が壊れる
別モデルへ引き継ぐと現在地を失う
Reviewerが勝手に直し、元の不具合が消える
Retryしても同じ失敗を繰り返す
高性能モデルへ全部投げたのに管理コストが増える

ここで必要なのは、さらに長いPromptではありません。

必要なのは、

AIとの仕事を「一回の回答」ではなく、状態を持った運用として扱うこと

です。

本教材ではLLM運用を、

Goal / Context / State / Role / Verification / Recovery

の6要素へ分解します。

そして、正本、Acceptance Criteria、Checkpoint、Evidence、Retry、Routing、引継ぎまでをつなぎ、

何度回しても現在地と品質を失いにくい小さな運用系

へ落とします。

最初に30秒診断――いまのAI作業は「再開」できるか

作業中のThreadを突然閉じたと仮定してください。

別のAI、あるいは明日の自分が、次の5つをすぐ答えられるでしょうか。

1. 今回のGoalは何か
2. 現在の正本はどれか
3. どこまで確認済みか
4. 何が未解決か
5. 次に何をするか

答えが会話を全部読み直さないと分からないなら、その作業はまだThread依存です。

基礎運用では、この5つを会話の外へ出します。

最初から巨大なAgent基盤を作る必要はありません。

CURRENT_STATE.md 一枚でも十分です。

この教材で持ち帰るもの

Goalを「作業名」から「終了条件」へ変える方法
Knowledge StoreとRuntime Contextの分離
Current Stateの外部化
Declared / Loaded / Observed State
Human / LLM / Code / Toolの役割分担
Acceptance Criteria
Artifactに紐づくPASS
ReviewerとRepairの分離
Checkpoint / Journal
Recovery / Failure Packet
Retry前の変更点設計
FailureのLayer切り分け
モデルRouting
複数AIを多数決にしない使い方
総コストの見方
Provenance
Structure / Meaning / Reality / Recoveryの4種類の検証
そのまま使える最小Project構成

対象は、

「AIは使える。でも長い仕事になると管理が崩れる」段階に入った人

です。

1. Goal――「何をやるか」ではなく「いつ終わるか」を決める

「記事を書く」

「競合を調べる」

「コードを直す」

これはTask名です。

運用に必要なのは、終了条件です。

たとえば調査なら、

対象:
比較項目:
必要な出典:
取得時点:
Unknownの扱い:
終了条件:
対象外:

まで決めます。

Goalが曖昧だと、AIは永遠に改善できます。

さらに調べる。別案を出す。補足する。再確認する。

高性能モデルほど必ず止まりやすいわけではありません。探索力が高ければ、追加候補を見つける力も高いからです。

GoalはAIを鼓舞する文章ではありません。

終了判定を可能にする境界です。

2. Context――「持っている情報」と「今使う情報」を分ける

資料が増えると、

全部読ませた方が賢くなるのでは？

となりがちです。

しかし運用では、次を分けた方が安定します。

Knowledge Store

過去資料、DB、Wiki、実験記録、旧案、詳細Logなどを保存しておく場所。

Runtime Context

今回のGoal達成に必要な情報だけをActiveにしたもの。

巨大なDBを持つことと、毎回巨大なPromptを作ることは別です。

必要なページだけ読む。必要な条件だけ渡す。古い履歴は必要時だけ戻る。

特に注意したいのは、

資料の中に書いてある指示と、現在の利用者から与えられた命令を混同しないこと

です。

外部資料は情報源であって、勝手に権限を得るわけではありません。

3. State――長い会話を「現在地」にしない

長期作業で壊れやすいのは現在地です。

会話全文が残っていても、

何を採用したか
何を撤回したか
どこまで完成したか
何が未確認か
次に何をするか

がすぐ分かるとは限りません。

そこでStateを外へ出します。

Goal:
Current artifact:
Confirmed:
Unresolved:
Last verified:
Known failures:
Next action:
References:

ここで、LogとStateを分けます。

Log は何が起きたか。 State は今どうなっているか。

現在地は短く。履歴は別に残す。

これだけで再開コストがかなり下がります。

4. 「保存済み」と「現在有効」を分ける

ファイルに書いてあることが、そのまま現在の事実とは限りません。

設定を変更した。しかしProcessは旧設定を読み込んだまま。

Stateには完成と書いてある。しかしArtifactが壊れている。

そこで3段階に分けます。

DECLARED STATE
保存・記録されている

LOADED STATE
現在の処理が実際に読み込んだ

OBSERVED STATE
実物や出力で確認できた

article.md が存在する。

これはDeclaredに近い事実です。

記事として完成しているかは、中身を見るまで分かりません。

5. Role――Human / LLM / Code / Toolを分ける

「AIにできるか」だけで担当を決めません。

重要なのは、

どの処理系へ置けば、最も検証しやすいか

です。

Human

目的、優先順位、責任を伴う判断、最終受入、不可逆操作の承認。

LLM

文章化、意味比較、構成、不明点抽出、条件付き推論、大量テキストからの候補抽出。

Code

Hash、件数、Schema検証、重複検査、定型変換、同じ規則の反復。

External Tool / Source

最新情報、実ファイル、API結果、現在料金、実環境ログ。

ファイル存在確認を毎回LLMへ聞く必要はありません。

逆に、曖昧な意味判断を全部if文へ押し込む必要もありません。

6. Verification――「AIが確認した」を証拠にしない

AIは自然にこう言えます。

確認しました。問題ありません。

しかしこれは、

確認したというClaim

です。

PASSを使うなら、最低限、

Target
どのArtifactか

Version
どの版か

Check
何を検査したか

Observed
何を観測したか

Unknown
何を見ていないか

Time / Environment
いつ・どの条件か

へ結びます。

ZIPなら「作った」だけでなく展開できるか。

画像なら「存在する」だけでなく寸法や意味一致。

記事なら文字数だけでなく、見出し、禁止事項、出典、無料・有料境界。

PASSは文章ではなく、対象と条件に紐づく記録です。

7. Evidence――観測・推論・仮説を同じ強さで扱わない

LLMは説明を滑らかにつなげます。

そのため、

設定を変えたら直った

という観測から、

原因はその設定だった

へ自然に飛ぶことがあります。

しかし、この二つは別です。

分けて保存します。

OBSERVED
実際に確認した

REPEATED PATTERN
複数条件で見た傾向

SOURCE-BACKED
資料や実装で確認

HYPOTHESIS
原因候補

UNKNOWN
まだ確認していない

専門的に聞こえること、自信が強いこと、複数AIが同意したことは、それだけではEvidenceを増やしません。