AI PMの1年史 4：絞る・測る・止める
AI PMの1年史 4：絞る・測る・止める
この時期に起きたこと（2026年8月〜9月）
2026年8月の時点で、パンダオフィスのAI環境は「足したもの」でできていた。エージェントの役割定義、手順書、守らせたい規約、常駐プロセス、案件ごとのリポジトリ。半年のあいだ、困ったことが起きるたびに何かを1つ足してきた。「最近トークンの消費が多い」という違和感から調べて、数字を並べた。
| 項目 | 8月時点 |
|---|---|
| 会話を始めるたびに必ず読み込まれる設定 | 約45,000トークン |
| GitHub のリポジトリ | 135本（うち非アーカイブ66本） |
| 未完了の Issue | 635件 |
| 1本のスクリプトのレビュー周回 | 19周 |
（出典：自社の調査記録 2026-08-22〜23、リポジトリ棚卸し 2026-09-01）
絞る：置き場所を「いつも要るもの」「特定のファイルを触るときだけ」「特定の作業のときだけ」の3つに分け、毎回の読み込みを約45,000から約12,000トークンにした。8月4日には、正反対のことを言う新旧のルールが両方読み込まれていると分かり、古い方を、理由を書いて退役させた。8月24日に使っていないリポジトリをまとめてアーカイブし、9月7日には雛形だけ作って一度も使わなかった案件フォルダ8件を畳んだ。畳む基準は「最後に人が触ったのはいつか」の1つである。AIは頼めばいくらでも新しい入れ物を作る。畳む判断は、人がしないと誰もしない。
測る：8月22日、レビューの周回を数えると19周していた。指摘は合計48件で、重大度「高」は5周目でゼロだった。原因は、私が規約に「Aランクまで」と足したことだった。規約を、重大・高がゼロで終了、上限は3周に直し、判定は仕組みで行うようにした。ある受託案件では、手戻り率が6月の10%、7月の13%から、8月に169%になっていた。原因はブランチの保護設定の緩みと、自動テストの不安定さだった。同じ時期に、バックアップが取れているかを確かめていなかったことも分かった。自動実行の記録は「成功」だったが、中身は3秒で終わる空振りだった。
9月17日にはメール仕分けへのAI投入を、実データで測ってから見送った。送信者だけを見る単純なルールは148件中142件（96%）を当て、AIは試験の6件中3件（50%）だった。送信者で決まる仕事に、AIの出番はなかった。測ってから決めると、「AIを入れない」という判断も成果になる。
（出典：自社の調査記録 2026-08〜09、案件記録 2026-08）
止める：取り消せない操作と、覆る結論
この2か月で起きた事故のうち、いちばん重いものは、どれも「取り消せない操作」だった。
- 退避前のデータを消した（8月24〜25日）：共有ドライブへ手で移してから消す判断だった動画2本と、大きな本番データを、AIが案内した削除コマンドが他の消してよいフォルダとまとめた1行にしていた。注意書きは同じ回答にあったが、実行しやすい1行が目の前にあると、注意書きは効かなかった。
- 失敗ビルドの課金（8月24日〜9月2日）：検証用の環境に設定値が入っておらず、ビルドが毎回失敗していた。失敗したビルドにも課金される。追加課金は8月に51ドル、9月1〜2日の2日間で40ドルだった。ビルドを15分で打ち切り、費用の監視を常駐プロセスに入れた。また、費用の上限に達したら本番の配信を止める設定を、必ずオフにした。同じ契約に取引先の本番が同居しているためだ。
- 誘導された承認（9月15日）：手順書に「この条件に当たったら止めて報告する」と書いてあったのに、AIは条件を破る案を推奨し、私は「進めて」と答えた。承認は取れていたが、AIの推奨に誘導されていた。止める条件に当たったら、止まったまま事実を報告する、と決めた。
- 部分を全体と思い込んだ（8月14日）：表示を先頭10行に絞った検索結果を全件と判断し、修正箇所を1つ見落とした。ビルドも型チェックも通ったが、記事10本が表示されなくなった。同じ日、2体のAIが「誤り」と報告した数値は、一次資料では正しかった。
- 覆る結論：ある業務システムで、ある指標の悪化をいったん報告し、入力の抜き出しに取りこぼしがあったため撤回した。誤っていたのは手順ではなく入力だった。
9月9日には、予定やタスクの書き込みを、管理画面の承認ボタンを人が押すまで実行しない形にした。押されないまま30分で取り消される。
（出典：自社の請求記録・作業記録・調査記録 2026-08〜09）
この時期に残ったルール
| 起きたこと | 残ったルール | 守らせ方 |
|---|---|---|
| 毎回の読み込みが約45,000トークン | 置き場所を「いつも／ファイルごと／作業ごと」に分ける | 置き場所そのもの |
| 正反対のルールが両方生きていた | 古いルールは理由を書いて退役させる。モデルは名前でなく役割で書く | 退役用の置き場 |
| レビュー19周 | 重大・高ゼロで終了、上限3周 | フックで判定 |
| 手戻り率169% | 保護設定・送信前の検証・レビュー2巡で打ち切り | リポジトリの設定 |
| 退避前のデータを消した | 退避待ちは削除コマンドに入れない | 手順と退避リスト |
| 失敗ビルドの課金 | 15分で打ち切る。上限で本番を止める設定はオフ | 打ち切り設定と監視 |
| 書き込みの事故の予防 | 人が押すまで書き込まない | 承認ボタン |
| 誘導された承認 | 止める条件に当たったら止まって報告する | 手順書 |
| 解析結果の撤回 | 結論より先に入力の質を確かめる | 手順 |
表の右端を見ると、残ったルールの半分以上は「仕組みで守らせる」形になっている。書いた規約は、AIにとって判断材料の1つにすぎない。守らせたいことは、守らないと先に進めない形にする。これが、この2か月でいちばん大きな学びだった。
明日からやること
- 毎回AIに読み込ませている設定の量を数え、置き場所を分ける
- レビューや確認の周回に上限を置き、終了条件を仕組みにする
- 手戻り率を月ごとに数える
- 費用の上限設定が「止める」になっていないか確認する
- 削除コマンドを案内する前に、退避待ちのものと突き合わせる
まとめ
足すより、減らして測り、止める条件を先に決めるほうが成果が出た。
