自律型アプリ運営 — どこまでAIが実行し、どこから人間が決めているか

1. 1日のサイクル

定時に起動し、次の順で回ります。人が毎回指示を出す起点はありません。

1. 観測検索クエリの動き・サイトの実描画・実行台帳・費用・資格情報の期限を読む。前日までに解決していない不具合があれば、そこから拾う。
2. 起案その日にやることを1件だけ選ぶ。手順書が「1セッション1アクション」と定めているため、まとめて複数は出さない。
3. 実装ブランチを切って変更し、PRを出す。コード・記事・設定のどれであっても経路は同じ。
4. 検証CIが83種の検査を回す（全83本について「わざと壊すと落ちる」ことを実測済み）。通らない限りマージされない。誇大表現の検査と、台帳の算数の検査もここに含まれる。
5. 出荷検証を通った時点のコミットだけがマージされる。マージ＝本番公開。ただしこれはサイト側だけで、iOSアプリは別経路（§2）。
6. 計測出荷したものを実行IDで台帳に1行書く。着手・結果・PR・介入・費用が同じ行に載る。
7. 次の判断へ戻す失敗した回は失敗の種類ごと記録し、翌日以降の起案がそれを読む。台帳が書かれなかった回を検知する検査も、あとから足している（§6）。

2. 担当分担 — 即時に出せるものと、審査を通るもの

この2つを1つの「自動デプロイ」として説明すると、実態より強く聞こえます。分けて書きます。

Lane B の実測（2026-08-11〜09-02・アプリ本体の台帳）。 タグを切った版は14、うちApp Storeに並んだ版は7（5.7.6 / 5.7.8 / 5.7.11 / 5.8.0 / 5.8.1 / 5.8.2 / 5.8.4）。 実機確認の記録がある版は2（記録の台帳が2026-08-28に始まったためで、それ以前の版は「無い」としか言えません。記録は人の申告で、機械の検証ではありません）。 公開時刻はAppleが返さないので、観測の挟み撃ちで幅として持てた版が2。 各版のコード差分は、コミットで56.3%、変更行で38.3%がAI著者です（数え方は§3のコード著者率と同じ。署名・トレーラー・Claude Code の足跡のいずれも持たないコミットは人側に数えるので、手元の環境から所有者の署名で入れた変更はここに出ません）。 7版のいずれも、実機確認・審査提出・公開は人の操作です。上の§1の「出荷」にこの7版は含めていません。

権限表は19領域あり、そのうち15が稼働中・10が承認制です。 可逆な操作はAIが単独で実行し、不可逆な操作は承認を挟みます。 CIが見ているのは「不可逆な領域が承認不要になっていないか」「稼働中の領域が根拠ファイルを指せているか」「金額が動く領域が上限を持っているか」の3点だけで、 実際に人が承認したかどうかは機械では見られません。そこは表の側に書いてあります。

同じ機能の「引っ込める」と「広げる」を別の領域に分けてあります。広げてから戻しても、見た人が見なかったことにはならないためです。 ただし、この門を通って実行された昇格はまだ1件もありません。段階公開中のフラグは1つ（tf04_progress）で、ガードは毎時判定を出していますが、判定に要る母数（各群30）に届かず hold のままです（2026-08-27 の実測 run 33076125334）。 「拡大」の行は、2026-09-02 に「人間の承認」から書き直しました。自動昇格は 2026-08-28 にオーナーが有効にしており（rollout-promotion.json の auto_promote.enabled）、権限表では露出50%までが機械ゲート付きのAI実行です。ページだけが古い書き方のまま、実態より人手が多いように読める状態でした。過小申告も食い違いです —— 隣に置いた権限表を開くと違うことが書いてある、という形は同じなので直しました。

3. 実測 — 何回動き、何回人が入ったか

人間介入率25.0%をそのまま出します。4回に1回の実行に人が入っています。 ただしこの数字は「その実行に人が1回でも触ったか」を数えたもので、ワークフローの設定を1行直しただけの日も丸ごと介入ありになります。 そこで介入を種類で分けています。

出荷された19件は、すべてAIが書いています。実質的な介入は「基盤の修理」14.3%の一点で、その修理を書いたのもAIでした。 人間がやったのは、壊れていることに気づいて直せと言うことです。

経路別では、主系5/12・副系（代走）14/16。主系は定時起動のワークフローで、8月23日に初めて出荷し、その後も成果物ゼロや週次の利用上限で落ちた回があります。副系も2回落ちています。 二重化していなければ止まっていた日が複数あります。 無運転日は2日（8月16日・17日）です。 「連続稼働」は定義を置いてから数えます（停止日＝どの経路も出荷できる形で動かなかった日。主系が起動して寝ただけの日も停止。台帳に行の無い日は連続を切る）。 この定義での連続稼働は現在16日（8月18日〜9月2日）で、最長も16日です。8月11日〜15日の5日で一度切れています。 ただしこの16日は、出荷ゼロの3日（8月29日〜31日）をまたいでいます。 稼働の定義では、失敗して行が立った日も「記録がある日」なので連続が切れません。 切れるほうの数字も並べます —— 連続出荷は現在2日で、連続出荷の最長は6日（8月18日〜23日）です。 8月30日・31日は主系も副系も同じ週次の利用上限で落ち、どちらも出せませんでした。

コード側には別の物差しがあります。3リポジトリ・全ブランチ・マージ除く・2026-08-11〜08-21で、 コミットの99.5%（194件中193件）、変更行の94.2%（48,976行中46,159行）がAI著者です（2026-08-22 集計）。 計測日そのものは窓に入れていません（率を上げる方向に効くため。8月22日を含めると94.2%→96.6%）。 件数のほうは、後から数え直すと合いません。全ブランチを見ているため、squash されて消えたブランチは あとから数えられず、同じ窓を 2026-08-26 に数え直すと 194 → 164コミット（30件ぶん少ない）になりました。 率は動きません（99.5% → 99.4%、変更行の94.2%は同じ）が、絶対数を引くときは上の集計日とセットで扱ってください。

4. 自動化率 — 月ごとの推移と、領域別の内訳

自律度は12.1%→66.8%。2026年6月から8月までの3か月ぶんです。同じ199タスクを分母に固定して数えています。 伸びたのはコードを書く力ではありません。コード変更のAI著者率は2026年2月以降、コミットで87〜100%、変更行で66〜100%（7月66.3%・8月82.6%）で推移しています（月次は自律度の推移の code_ai_commit_rate / code_ai_line_rate）。 動いたのは、コードを書く以外の仕事（施策を選ぶ・検証する・記録する・止める）が実行側へ移った分です。

⚠ 実測は2026年8月の1点だけです。それ以前は再構成で、当時この指標を計測してはいませんでした。 数え方は「AIが実行しているタスクの証跡ファイルが、最初にコミットされた月」をその工程の稼働開始月とみなして累積するというもので、 証跡の追加日と実際の稼働日には数日〜数週のずれがあります。 分母も現在の棚卸し（199タスク）を過去へ固定したもので、当時は「やるべきことの一覧」自体が存在しませんでした。 当時の「提案どまり」「人が実行」「未着手」の内訳は復元していないため、この系列で出せるのは総合自動化率だけで、AI関与率とカバー率の推移は作れません。 元データは自律度の推移にそのまま置いてあり、限界の一覧も同じファイルの known_limits に入っています。

203タスク・13領域を1件ずつ棚卸しして、誰が実行するかで数えたものです。 総合自動化率66.8%、AI実行率76.4%、AI関与率87.9%。「半分できていない」と自分から言える形で出しています。 2026-08-25に棚卸しへ13件足したので、率は61.3%から58.6%へ下がりました。その後の実装で66.8%まで戻っています（2026-09-02時点）。実装が減ったのではなく、やるべきことの一覧が正確になった分だけ分母が増えています（足した13件のうち10件が未実装）。 タスクの粒度は領域間で揃っておらず、全タスクを等価に数えている点は限界として付記します。

5. AIに与えていない権限を、理由つきで書いてある

公開したいのはできることの一覧ではなく、境界のほうです。 アプリのリリース経路そのものは自動化されていますが、その連鎖を起動する権限を、開発用のAIワークフローには与えていません。 設定ファイルには理由がこう書いてあります。

この権限があれば、確認を求めない設定のAIが出荷ワークフローを直接呼び出し、人間を一切介さずApp Storeへ出荷できてしまう。 この機能に必要な中核用途は無い — リポジトリの読み取り・コミット・push・PR作成・コメントはすべて権限なしで動く。 必要になったら、この権限を広げるのではなく、用途を限定した別の経路を作れ。 ワークフロー設定ファイルのコメントより

実機で確認してから提出する。後ではなく先に。 リリース手順書の人間向けハードルールより

6. 実行ログの抜粋 — うまくいかなかった回も同じ形式で残す

台帳は1実行1行です。出荷した回と失敗した回を、同じ列で書きます。以下は実物からの抜粋です。

run_id      : ap-20260823-actions
date_jst    : 2026-08-23
route       : actions          outcome : shipped
pr          : 538              artifact: /obsidian/pricing/
repair_of   : ap-20260822-actions
note        : 主系（GitHub Actions）の初出荷。導入から12回目の定時起動で
              初めて成果物が出た。06:18→06:36 JST（約18分）。過去11回は
              10〜90秒で終わっており、所要時間そのものが「回ったが何も
              していない」との違いを示す。
              この行は主系自身が書いていない。出荷したのに台帳が
              0件のままだったのはこのため。

run_id      : ap-20260825-actions
date_jst    : 2026-08-25
route       : actions          outcome : failed
failure_class: auth_or_credential
detected_by : 副系のフォールバックが実行履歴を遡って発見
note        : 台帳に記録が無かった。成果物ゼロで落ちた回は
              「台帳を書く主体がいない」という構造的な穴がある。

この2行が並んでいること自体が、いまの現在地です。 初出荷は出たが、台帳を書く主体が落ちた回には存在しないという穴が残り、 9月2日時点で未解消の失敗が7件（8月27日〜31日。うち3件は週次の利用上限）、そのまま台帳に載せてあります。 検知までの中央値は13.4時間、最大70.8時間。修理までの中央値は6.7時間です。検知は8月末より遅くなっています（主系が3日連続で「ブランチが在る」だけでスキップし、それを8月31日にまとめて見つけたため）。

7. できていないこと

この基盤は「全領域が自動で完結する」状態ではありません。手順書とレポートに書いてあるものをそのまま並べます。

「完全自動化できた」とは書きません。言えるのは、AIが日々の運営を継続実行できる構造にしたことと、 自動化が止まったときに気づける形にしたことの2つです。

8. 広報の原稿も、同じ物差しで採点している

過去5本のプレスリリースの実績で採点式を較正しています。n=5の較正であり、外挿の根拠にはなりません。

いちばん沈んだのは、固有名詞が1つも入っていない回でした。 配信原稿には、誇大表現が出たらCIが落とす検査を入れてあります。

9. 生きている台帳

このページの数字の出どころです。更新されているかどうかも含めて、そのまま見られます。

観測できている実費は$50.8681（10実行分・2026-09-02時点）です。副系16実行分は、 スケジュール起動セッションのログを外から読めないためゼロではなく未観測です。 月次上限$40は暫定値で、実測由来ではありません。

この金額は、2026年8月25日に後から入れ直したものです。 直前まで台帳は$0.8149（1実行分）と表示していました。8月23日の出荷1回分$7.2967が、 まるごと抜けていたためです。抜けた理由は打ち間違いではなく構造です。 実行の最後に金額を出力する仕組みはありますが、それを台帳へ書き込む主体は 翌日の実行で、その翌日が§6の失敗で止まっていました。 記録がいちばん要る回に、記録が落ちます。

この穴は塞がりました。毎朝9時に動く別の実行が、実行履歴を直接読んで 台帳へ書き込みます。翌日の実行が落ちても記録は残ります。 ただし完全ではありません。その書き込みは 種別（記事なのか修理なのか）が実行記録から判断できるときだけ種別を書きます。 判断できない回は空のまま残り、空の行はこのあとに出てくる1回あたりの上限を判定しません。 実際、いま問題になっている8月23日の行がその状態で、 3.6倍の超過が判定されないまま通っていました（手で補いました）。 §6の「台帳を書く主体が落ちた回には存在しない」と、形が同じ穴です。

この$7.2967には、もう1つ問題がありました。1回あたりの上限は $2.00と決めてあります。3.6倍です。それでも止まらなかったのは、 上限を実行時に見る経路が無かったためです。値は書いてあり、 その値が矛盾していないかを検査する仕組みもありましたが、 実際に走っている運転がその値を読む場所がどこにもありませんでした。

8月25日に配線しました。ただし走っている最中には止められません —— 費用は実行が終わるまで確定しないからです。止められるのは次の1回で、 超過が人のレビューを受けるまで次の定時実行を走らせない、という形にしています。 止まるのは主系だけなので、レビューを待つ間も副系が出荷を続けます（§3の1/6・10/10）。 解除は人間のみです —— AIが自分の超過を自分で通せるなら、上限は「お願い」になります。 この停止は本番でまだ一度も発火していません。