長時間AIタスクの初期コスト上限と停止条件

まず分ける：長時間AIは単一のスイッチではない

多くのチームは新しいモデルを試すとき、問いをこう立てる。「このモデルを全員に使わせるべきか？」

この問いは粗すぎる。よりよい問いはこうだ。「どの種類のタスクなら最後まで自動実行してよいのか。どの種類のタスクは下書きまでに留めるべきか。どの種類のタスクは各ステップで人の確認が必要か。」

たとえば、同じAI agentでも次のように違う。

• 公開資料20本を整理し、調査要約を出すタスク。
• コード保管先のコードを修正し、pull requestを作るタスク（変更提案をレビュー後に反映する申請）。
• 顧客データを読み、返信を送信し、CRM（顧客関係管理システム）を更新するタスク。

これらはまったく異なるリスク階層にある。

AI エージェントにコードを書かせるなら、あわせてこちらも読むとよい：AIエージェントにコードを書かせる前に、タスクへチェックポイントを入れる。その記事は「タスク内にどんな停止点を置くか」を扱う。この記事では、その各停止点の前に「最大でどれだけトークンを使い、いくら使い、何回まで再試行してよいか」を補う。

小チームの業務フローに組み込む5ステップ

上限表ができたら、次にやることは全社開放ではない。小さな経路で試走することだ。以下の流れは3〜20人の小チーム、特に専任のAI基盤チームをまだ持たない状況に向いている。

1. まず「出力を検査できる」長時間タスクを1つ選ぶ

最初のタスクに「もっと賢くしてほしい」のような結果が曖昧な依頼を選んではいけない。出力を検査でき、失敗しても回収しやすいタスクを選ぶ。

• 公開文書15本を1ページの要約にする。
• サポートメッセージ30件を5分類し、各分類の代表例を3件ずつ出す。
• 小さなpull requestを読み、人が見るべき可能性のあるファイルを列挙する。
• 内部SOPを新人向けに書き換える。ただし直接公開しない。

判断基準は単純だ。出力が間違っていたとき、10分以内に気づけるか。気づけないなら、それは最初の試験導入タスクではない。

2. タスクに「最大で何を読んでよいか」を書く

長時間タスクはすぐにコンテキストを使い切る。コンテキストは、AIがその時点で読めて、覚えて、推論に使える材料だと考えるとよい。多く読むほど正確になるとは限らない。データ範囲が曖昧だと、古い情報や無関係な情報が混ざりやすくなる。

タスク仕様には次のように明記できる。

• 指定フォルダまたは指定URLだけを読める。
• 1回につき最大10ファイルまで読む。
• 各ファイルはタイトル、要約、直近30行の変更だけを読む。責任者が承認した場合を除く。
• 顧客の個人情報、決済情報、秘密鍵、社内給与、契約書の原文は読まない。

こうした制限は「慎重に扱ってほしい」より有効だ。agentをプログラム上で止められるからだ。

3. dry-runと正式実行の違いを決める

ドライラン（データ変更・公開をしない試走）とは、先に試走すること。長時間タスクを実行する AI エージェントを初めて業務フローに入れるときは、初期設定ではドライランだけにする。

たとえばcoding agentは次のことができる。

• issueを読む（対応すべき依頼チケット）。
• 関連ファイルを探す。
• 修正計画を出す。
• patchの下書きを生成する（提案済みの変更差分）。
• テスト案を提示する。

しかし、直接次のことはできない。

• main branchへpushする。
• pull requestをmergeする。
• production config（本番環境向け設定）を変更する。
• packageを公開する。

文書agentも同じだ。下書きと差分要約は作れるが、正式文書を直接上書きしてはいけない。dry-runの結果を5〜10回確認し、失敗パターンを予測できるようになってから、次の段階を開くか検討する。

4. 「停止条件」をif–thenで書く

停止条件は抽象的な注意書きにしない。if–thenで書く。

• そのタスクの階層で承認済みの token またはコスト上限を超える見込みなら、まず提案だけを出し、完全実行には入らない。たとえば L2 の上限が 60,000 tokens の場合、上限に達する前に止めて責任者が範囲を縮めるべきか判断する。
• タスクがその階層で承認された再試行上限に達しても完了しない場合は、直ちに停止し、最後のエラーを記録する。責任者が範囲を縮小するか、別の方法を使うか、タスクを終了するかを決める。L1 と L3 は 1 回の再試行後も失敗すれば停止し、L2 は最大 2 回、L4 は自動再試行を認めない。
• もしallowlist（許可済みデータソース一覧）にないデータソースを読む必要があるなら、停止し、理由を列挙する。
• もし出力が外部ユーザーに見える内容を変えるなら、下書き状態で止める。
• もしタスク内に支払い、削除、権限昇格、正式な約束が出てくるなら、提案だけを生成し、実行しない。

これらの文は AI エージェントの system prompt（起動時にモデルへ渡すシステム指示）に入れ、モデル自身が停止すべき時点を判断するための注意として使える。ただし、prompt は強制力のある課金メーター、権限システム、確実な停止スイッチではない。実際のトークン、コスト、再試行上限は、モデル外のワークフロー制御機構が強制する必要がある。制御機構は各呼び出しで報告された入力・出力トークン、ツール費用、再試行回数を累計し、次の呼び出し前に残り予算を確認する。残額で次の呼び出しを賄えない場合は要求を送らず、現在の結果と人の判断待ち事項だけを返す。削除、決済、正式送信、公開、権限昇格については実行用の認証情報を最初から与えず、prompt に「実行しない」と書くだけで済ませない。

5. 毎週1つのつまみだけを調整する

試走後には、いくつかのよくある結果が見えてくる。

• タスクが完了する前にtoken上限に当たりがちである。
• コストは低いが、人による検収に時間がかかりすぎる。
• 再試行が多く、総コストを予測しにくい。
• 低リスクタスクは止められすぎる一方、高リスクタスクは次の段階へ進みやすい。

一度にすべてを調整してはいけない。毎週1つのつまみだけを変える。

• L1のtoken上限を20,000から30,000に上げる。
• L2の再試行上限を2回から1回に下げる。
• L3を「patch生成可」から「修正計画のみ」に変更する。
• 外部公開前に責任者確認欄を1つ追加する。

小チームの最大の強みは、大量のガバナンス文書を持つことではない。どの上限が厳しすぎ、どの停止点が緩すぎるかをすばやく観察できることだ。一度に1つだけ変えるからこそ、どの変更が効いたのか分かる。

小チームの最初の実行版

今日1つだけやるなら、「長時間AIタスク申請カード」を作るとよい。新しいツールを買う必要はない。Notion、Google Sheet、Linear、GitHub issue templateで十分だ。

推奨項目は次のとおりである。

1. タスク名：[例：競合他社の発表15件を整理する]
2. タスク段階：[L1 / L2 / L3 / L4]
3. 許可されたデータ：URL やフォルダーを列挙
4. 禁止データ：公開不可な個人情報、支払い情報、秘密鍵、契約書原文など
5. コンテキスト上限：1回実行で最大 10 ファイル、各ファイルは最新 30 行の変更分まで、または入力 40,000 トークン。超過時は先に要約してから責任者に継続可否を確認。
6. token 上限：表の初期値を入れる
7. 1回あたりコスト上限：表の初期値を入れる
8. リトライ上限：0, 1, 2 回
9. 停止条件：少なくとも 3 つの if–then
10. 責任者：誰がレビューして次段階を承認するか
11. 出力ステータス：下書き、提案、patch、正式実行 のいずれか

このカードの目的は事務手続きを増やすことではない。AIがどこまで進めるのか、どこで止まるのか、誰が見るのか、費用がいくらを超えたら続行できないのかを、全員が分かるようにすることだ。

生活四コマ

1. 引っ越し前、3人の友人は部屋にある3箱を見て、今日は無理なく片付けられそうだと考える。
2. ところが、クローゼットや棚を開けると、予想よりはるかに多くの物が出てくる。
3. 3人はいったん手を止め、今日やることを簡単な3項目のチェックリストに絞り、合意した範囲だけを扱う。
4. 合意した箱だけを封じ、残りの物は次回に備えてきれいに整えたまま残す。