AI PMの1年史 3：AIが朝に報告する会社
AI PMの1年史 3：AIが朝に報告する会社
この時期に起きたこと（2026年5月〜7月）
3月までは、AIは私が呼んだときに動くものだった。5月になると、使い方の向きが変わった。AIが常駐し、私が頼む前に動いて、結果を報告してくる。
- 5月14日：Webサイト、書籍、動画、業務資料、エージェントの定義を、1つのリポジトリ（全社モノレポ）にまとめた
- 5月中旬：朝7時と夕方19時に、予定・メール・開発の状況をまとめて通知する常駐プロセスを動かし始めた（開始日は5月16日ごろと推測している）
- 5月16日：メールの送信権限は取らない、と決めた。送信は人が行う
- 6月14日：業務管理を担うエージェントの層を足し、承認を4段階に分けた
数字では、この時期は静かに見える。メッセージ数は5月が238,511、6月が170,106、7月が246,518で、最多の2月の半分以下だった。それでも、全社モノレポのコミットは、5月の15件から7月の220件へ増えた。会話の量が減り、残るものの量が増えた時期だったと見ている。これは数字の並びからの推測である。
（出典：自社のAI利用統計 2026-10-14 までの3台合算、git 履歴。コミット数は1リポジトリ分）
朝の報告に、確定した数字を書かせない
6月2日、朝の報告に載せる情報を増やした。メールは2つのアカウントを合算し、開発の状況には未完了の課題の数を足した。数は、プログラムが先に数えて確定させたものだ。それをAIへの指示文に「この確定ブロックをそのまま使うこと」と書いて渡した。AIはそれを無視したり、書き換えたりした。指示を強めても、直らなかった。
直し方は、AIに数字を書かせるのをやめることだった。確定した数字は、AIを通さず、常駐プロセスが報告の末尾に直接足す。AIが書くのは、予定の優先順位や所感のような、数字でない部分に限った。数えることはプログラムが得意で、読みやすく書き直すことはAIが得意である。逆にすると、AIは数字をそれらしく整える。
（出典：自社の運用記録 2026-06-02）
承認を4段階に分けた
外部に影響する操作を、AIがどこまでやってよいか。6月14日に、手順書に4つの段階として書いた。
| 段階 | 意味 | 例 |
|---|---|---|
| 知らせる | 進捗の通知だけ。承認は要らない | 日次の進捗報告 |
| 見てもらう | 成果物ができたので、人が見て直す | メールの下書き保存、PR の作成 |
| 承認が要る | 外部に影響がある。人が明示的に承認する | 予定の作成・更新・削除、記事の公開 |
| 必ず止める | 取り消せない。実行前に必ず止まる | メールの送信、ファイルの削除、データベースの構造変更 |
境目は、外部の誰かに見えるかどうかで決めた。ただし弱点が1つあった。この4段階は、手順書に書いた約束だった。守るかどうかは、AIの判断に預けていた。実際に、後の時期に約束は破られ、9月に「人が押すまで書き込めない」仕組みに置き換わった。
（出典：自社の承認の段階表）
自分の本を点検し、費用と同居の穴を踏んだ
事実確認：6月16日、書籍の全14章を、5体のAIに並列で点検させた。存在しない型番、料金プランの取り違え、すでに施行されている国内の法律を「未整備」とした記述、意味を逆にして訳した統計が見つかった。誤りの多くは、もっともらしい数字や固有名詞の出典に集まっていた。直す作業は、機械的に直せるもの、著者にしか分からないもの、方針の承認が要るものの3種類に分けた。AIが見つけられるのは「この数字は怪しい」までで、どれが本当の値かは、記録を持つ本人にしか決められなかった。
画像生成の費用：7月5日、スタンプ制作で画像を1枚ずつ作り直し、2日で約5,000円を使って、途中で残高が尽きた。最初からグリッドで1回に生成していれば、数十分の1で済む作業だった。既定はグリッド方式にし、まとめて生成する前に「何枚、概算いくら」を出して承認を得ることにした。
同居の設定ミス：7月27日、複数のアプリで共有しているデータベースで、1つのアプリの設定ミスにより、同居している別のアプリが約20分止まった。費用を下げるために集約した設計の代償は、認証のユーザー、ファイルの置き場の名前、データ取得の窓口の設定、計算の資源を、同居するアプリ全員で共有することだった。分けられるのは、業務のテーブル、アクセス制限、関数までである。以降、ファイルの置き場の名前に接頭辞を付ける、アクセス制限を「認証されていれば許可」にしない、といった同居の作法を規約に書いた。
二重実装：7月31日、2日前に起票済みで設計まで書かれていた課題を見落とし、同じ機能を二重に実装した。確認の手順は手順書にあったが、手順書を経由しない依頼では素通りした。課題の確認は、手順書ではなくフックで強制するようにした。
（出典：自社の運用記録 2026-06〜07）
この時期に残ったルール
| 起きたこと | 残ったルール | 守らせ方 |
|---|---|---|
| メールの送信は取り消せない | 送信権限は取らない。下書きまでAIが作り、送るのは人 | 権限を渡さない |
| 朝の報告で、確定データが改変された | 確定した数字はAIを通さず、プログラムが直接足す | コードで決める |
| 外部に影響する操作の扱いが曖昧だった | 承認を4段階に分ける | 手順書（のちに仕組みへ） |
| 画像の個別再生成で2日約5,000円 | 既定はグリッド1生成。生成前に枚数と概算を出す | 手順 |
| 同居の設定ミスで約20分停止 | 同居の作法を規約に書く。設定でなく実測で確かめる | 規約と実測 |
| 起票済みの課題の見落とし | 課題の確認を、フックで強制する | フック |
表の右端を縦に読むと、「手順」と「規約」が並ぶ上のほうから、「コード」「フック」「権限を渡さない」が並ぶ下のほうへ、守らせ方が移っている。書いた約束は、事故のたびに仕組みへ置き換わった。
明日からやること
- AIの報告に載る数字のうち、確定したものをAIに書かせていないか確認する
- 外部に影響する操作を、4段階のどこに置くか一覧にする
- 共有している基盤（データベース、契約、認証）に、何が同居しているかを書き出す
- 費用が発生する作業の前に、概算を出す手順を作る
- 手順書に書いただけの約束を1つ選び、仕組みに移せないか考える
まとめ
確定した数字はAIに書かせない。取り消せない操作は、人に残す。
