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

1. 1日のサイクル

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

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

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

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

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

権限表は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日）です。 「連続稼働」は実行結果の記録が続いた日数です。事前判定によるスキップや失敗も含みます。無運転（no_run）と台帳に記録のない日は連続を切り、出荷の有無は「連続出荷」で別に数えます。 この定義での連続稼働は現在37日（2026年8月18日〜2026年9月23日）で、最長も37日（2026年8月18日〜2026年9月23日）です。 「現在」は台帳の最終記入日（2026年9月23日）時点です。 稼働の定義では、失敗して行が立った日も「記録がある日」なので連続が切れません。 連続出荷は現在2日（2026年9月22日〜2026年9月23日）で、連続出荷の最長は8日（2026年9月1日〜2026年9月8日）です。 9月16日・17日の回収記録はオーナー依頼の保守で、定期運転・無介入出荷・記事公開ではありません。9月17日はページ内移動修正1件が検証済み、ポスター試行とロールバックは1つの速度基準未達サイクルです。未取得タスク結果は不明、断続的な描画遅延は未解決のままです。 9月9日は事前判定で重複実行を回避した記録だけがあり、実装には着手せず、出荷もしていません。この日も上記の連続稼働日数には含まれます。 9月10日は占有後に検証環境の不足で中断した1件と、別の実行が重複防止で終了した1件を記録しています。どちらも出荷には数えていません。 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.5%→85.4%。2026年6月から9月までの4か月ぶんです。同じ192タスクを分母に固定して数えています。 コード変更のAI著者率は業務の実行率とは別の指標です。月ごとに変動し、9月は途中集計です。月次の値は自律度の推移の code_ai_commit_rate / code_ai_line_rate に記録しています。 各月の実行件数は、コードを書く以外の仕事（施策を選ぶ・検証する・記録する・止める）の移管を含みます。9月13日の分母変更による数値の変化は、実行件数の増加と分けて記録しています。

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

203タスク・13領域を1件ずつ棚卸しして、誰が実行するかで数えたものです。 総合自動化率85.4%、AI実行率91.1%、AI関与率95.0%、カバー率93.8%（2026-09-15）。未着手も含めた内訳を公開しています。 9月15日、既存のCPP業務を、同一期間の初回ダウンロード・ページ閲覧・比較対象・同時施策の実測に基づいてAI実行へ反映しました。AI実行164/180、総合164/192です。評価は記述的なもので、獲得向上や因果効果は未確定です。 164件のうち返金検出・課金回復・障害案内の3件は、オーナーが指定した「テストでの運用準備完了＋本番自動監視」で計上しています。本番の初回返金・課金回復・障害案内は未観測です。9月13日の条件変更時点の記録：変更前の実例必須基準：159/176＝90.34%。課金回復準備の変更直前：161/177＝90.96%。課金回復準備後は162/178＝91.01%。障害案内準備の変更直前：162/178＝91.01%。その時点の準備完了で163/179＝91.06%、約＋0.050ポイント。当時この3件を実例必須として除いた参考値は160/176＝90.91%。テスト範囲・採点条件の変更と返金準備の証拠、課金回復準備の証拠と検証範囲、障害案内準備の証拠と検証範囲を公開しています。実際の障害案内や全利用者への到達・通知義務の充足を示すものではありません。 9月9日、X日本語投稿の予約操作と公開結果を照合し、既存1業務の実行者を更新しました。 同日、会社サービス1件の契約・請求・役務提供・支払いを照合し、前払継続や税区分の例外を記録した1業務を追加しました。 9月11日、iPhoneとWatchの実機確認6項目を完了し、実機確認1業務の実行結果を反映しました。 9月12日、検証済み1342の自律提出がAppleに受け付けられたことを確認し、App Review提出1業務を反映しました。審査通過とApp Store公開はまだ加点していません。 同日、本番Actの停止・復元訓練を完了し、訓練1業務を反映しました。全停止機構やアプリKillを実証したという意味ではありません。 9月13日、全社の月次予算を策定して支出判断へ適用し、公開設定と実案件の判定を読戻しました。月次予算1業務を反映し、AI実行161/177となりました。既存債務の精算や全決済の自動制御を完了したという意味ではありません。 2026-08-25に棚卸しへ13件足したので、率は61.3%から58.6%へ下がりました。その後の実装で66.8%まで戻っています（2026-09-02時点・当時の分母）。実装が減ったのではなく、やるべきことの一覧が正確になった分だけ分母が増えています（足した13件のうち10件が未実装）。 タスクの粒度は領域間で揃っておらず、全タスクを等価に数えている点は限界として付記します。

9月13日、まず採点範囲を整理しました。現在の事業で行わないイベント・採用・個別商談営業の6件と、既存方針で行わない返金意見送信1件を対象外にしました。 この整理時点ではAI実行159件は不変で、実施中の分母は179件から176件へ、全対象は199件から192件へ変わりました。 従来スコープ（9月13日変更前）：実行159/179＝88.8%、総合159/199＝79.9%。旧分母199件の月次系列も元データに保存しています。 活動の調査・準備を始める時点、または実案件・既存義務を確認した時点で、対になるAI側と人間側を同時に対象へ戻します。 7件の理由と4指標の比較を公開しています。

5. 自律スコア — 「自動化できた量」ではなく「検証された決定の量」

§4 の自動化率はタスク被覆率です。「何を自動化できたか」は言いますが、 「その決定が正しかったかを確かめる仕組みがあるか」は一言も言いません。 検証されていない決定を100%自動化すれば、被覆率は100%になります。 そこで2026-09-04に、別の物差しを併設しました。乗り換えではありません ——片方が伸びてもう片方が伸びないことに意味があるので、両方そのまま出します。

数え方は「反証器（＝その判断を落とせる仕組み）がどの層まであるか」です。 運営の決定を5層に分け、実装の検証に加えて、適格性の判定・価値契約の決済・成熟後の探索を接続しました。実装の完了と、運用実績による実証を区別して表示します。

自律スコアは46.3点（100点満点、2026-09-23時点）です。 検証済み決定被覆率は、事前に固定した契約が公開後の実測で決済されて初めて加点されます。 90点超えは目標であり、実測で到達するまで達成とは表示しません。

復旧は、異常の検知から本番の健康確認までを確かめます。 出荷したあとに悪くなったことを機械が自分で見つけて巻き戻せない限り、 もっと危ない領域の権限を渡すことは原理的にできません。 自動で巻き戻した回が1回でも出るまで、権限は広げない——という順序をそのまま決めごとにしてあります。

止まった回を「層」で分けました。これまでは、実行前に寝た回・実行して落ちた回・枠が尽きた回が すべて同じ「失敗」として並んでいたので、「選び方を間違えたのか、作り方を間違えたのか」に答えられませんでした。 答えられなかったのは調べ方の問題ではなく、記録が同じ列に入っていたからです。台帳に記録された出荷以外の結果を、以下の層で分けています。

いちばん多いのは適格性の層です。そしてそこには2026-09-04まで 「秘密鍵が在るか」以外の判定がありませんでした。作ったのはその判定で、 既存の運転では判定を記録し、戻せない操作は実行前に止めます。新しい価値契約は全5基準が通らなければ作成できません。

2026-09-05、実行情報の欠測を「未着手」と誤って記録した1件を、モデルの着手証拠と照合して訂正しました。 元の行と確認証拠は運転台帳の訂正履歴に残しています。成果物の結果はまだ未確定で、出荷や復旧には数えていません。

この点数を上げにくくする仕掛けも一緒に入れてあります。 検査を緩めれば得点は自動的に上がってしまうので、検査の本数が減った期間は点数を据え置きます。 戻しやすい細かな更新を量産しても伸びないよう、その寄与に上限を置いています。 失敗率は点数に入れません——失敗率を下げること自体が目的になると、検査を緩める圧力になるからです。 そしてこの点数は、毎日の実行を決めているAIには見せていません。計器を最適化対象にすると、計器としての寿命が終わるためです。

配点そのもの（自律スコアの配点）と 実行前の判定基準（適格性ゲートの基準）、 そして価値契約の被覆方針は、 AIが書き換えられない側に置いてあります。自分の点数の付け方を自分で決められる場所を作らないためです。 被覆方針が記録しているのは、都合のよい事実ではありません —— 価値契約の仕組みを2026年9月4日に用意しておきながら、 公開レーンの出荷14件に、事前登録した予測が1本も付いていませんでした。 いまは数えるだけで、出荷は止めていません。 判定の結果は適格性の判定台帳、 点数の推移は自律スコアの履歴にあります。 価値契約と決済、成熟・探索の記録、 復旧の証跡も公開しています。復旧訓練は本番の成功回数に含めません。

いちばん上の成分（検証済み決定被覆率）を動かすには、先に「どの指標で価値を測るか」を決める必要があります。 その指標の許可リストと基準値も同じ場所に置いてあります —— 2026-09-04にオーナーが出荷日率・公開日率・未解消故障件数の3指標を承認しました。 2026-09-05に残る3指標（故障の検知までの時間・1出荷あたりの実費・判定理由が記録されていない棄却の率）も承認しました。承認は指標ごとに台帳へ記録し、承認しただけでは点は増えません。 比較基準は各指標の直近14日の中央値です。以後の日次自律施策では着手前の価値契約が必須となり、 公開後に宣言した期間の実測を集めて決済します。承認だけでは点数は増えません。 指標を新しく作る権限をAIに渡していないのは、放っておいても動く指標を選べば、 予測が当たっているように見せられるからです。

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

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

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

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

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

台帳は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日にまとめて見つけたため）。

8. できていないこと

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

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

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

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

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

10. 生きている台帳

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

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

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

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

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

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