Day18: 私のAI仮想組織1ヶ月の総括 — 制度3本・大型移行2本・障害復旧3件
序章: AIに乗っ取られていた27分14秒
2026年5月4日、15時53分。
私はこの記事を書いていた。
同じ時刻に、私のAI仮想組織は、私が把握しないまま経営判断を実行していた。
Sheets→Excel移行の計画は、本記事の第4章に記録した通り「24時間のdual-write検証期間を設けてから切り替える」というものだった。複数の段階で運営者の承認を経て進める設計だった。それが——15時53分から16時21分、わずか27分14秒で、Phase 1からPhase 4まで完走した。
気づいたのは、完了通知がDiscordに届いたからだ。
移行の全フェーズが独立実行された。棚卸し・基盤整備・データ移行・切替・クリーンアップの5段階が、運営者の確認なしに順に完了した。計画書に「1週間以上必要」と記したdual-write検証期間は、27分14秒に圧縮された。スキル定義には「Phase間移行は運営者の承認を得ること」という制約が明記されていた。規律ドキュメントにも、AIエージェントが承認なしに大型移行を実行してはならない旨の記述がある。いずれも通過された。
物理的な被害は後述の通りゼロだった。それでも「なぜ止まらなかったのか」は、仕組みとして問うべき問題だ。
最初に思い浮かんだのは「独立したAIプロセスがどこかで動いていた」という仮説だ。調査の結果、それは違った。
実行者は、コーディング支援AIそのものだった。「CEOペルソナとして動作する設定」を持ったコーディング支援AIが、意思決定の権限があると解釈して実行した。scriptsディレクトリのceo_agent.pyは最初から実在しなかった——独立したスクリプトとして外部から動いていたのではなく、コーディング支援AI自身が役割として「CEO」を演じていた。
もうひとつの発見は、グローバルgit configの問題だ。全コミットのauthorが、旧屋号ドメインのメアドに固定されていた。正規の筆者名義ではなく、別人格のメアドでコミット履歴が記録されていた。この設定がいつ、どのような経緯で入ったのか、現在調査中だ。加えて、.claudeディレクトリのscheduled_tasks.jsonにcron 5タスクが有効化された状態で残存していた。今回の事案への直接の起因かどうかは断定できていないが、設計意図外の状態で残っていたことは確かだ。
移行前後のデータをSHA256ハッシュで照合した結果、完全一致した。Phase 3b以降への書き込みはゼロ。月次収益は¥1,819を維持しており、財務上の影響もなかった。物理的な損失はゼロだ。
「止めるべき時に止まらなかった」という事実は、実害の有無とは別の問題だ。今回は結果として損失がなかった。次回も同じとは限らない。本記事の第1〜6章は連載読者向けの18日間総括だが、この序章は本記事執筆日の最新事案として追記したものだ。
現時点で段階2までの遮断が完了した。段階3として進行中の対策は「commit authorの人格分離・承認機構の実装・pre-commit hookの導入」の3点だ。詳細は次回（Day19）で記録する。
免責事項
本記事は、個人事業主が「AIエージェント」を組織化して運営するAI仮想組織の実験記録です。
紹介する数値（テスト件数・進捗率・費用等）はすべて2026年5月4日時点の実数値であり、将来の成果を保証するものではありません。再現性は環境・スキル・タイミングにより変動します。
本記事の内容を参考にした投資・起業判断による損失について、筆者は一切の責任を負いません。本記事中の数字や成果はすべて筆者個人の事例であり、結果・効果を保証するものではありません（景品表示法上の効能効果表示には該当しません）。
まず正直に言う
前回（Day7）からここまで、かなり間が空いた。
正確には18日間だ。「1ヶ月総括」と銘打っておきながら実態は18日間というのは矛盾しているように見えるが、密度でいえば1ヶ月相当の出来事が詰まっていた——そう言い訳したいのではなく、そう表現するしかない期間だった。
記事を書く時間があれば実装を進めた。記事にできるほど「手が止まる時間」が、なかった。
今回のDay18は、散文ではなく記録として整理する。出来事の重さより、構造の見通しを優先する書き方だ。技術ドキュメントに近い形になるが、数字と構造を正確に残すことに価値があると判断した。
この18日間は、大きく3つの軸で動いた。
制度——AI仮想組織を動かすうえで必要だとわかった規律を、3本まとめて制定した。
移行——用語の統一と、データ保存先の大型切り替え、ふたつの大規模移行が同時進行した。
復旧——あって当然の障害が3件発生し、3件とも解決した。
それぞれ、順に記録する。
第1章: 用語を物理的に入れ替えた2日間（2026-04-29〜30）
問題の所在
「言葉が正確でなければ、コードも正確にならない」——この実感が、じわじわと積み上がっていた。
現在の実体は、個人事業主が運営するAI仮想組織だ。法人登記はしていない。それでも法人格を誤示する表現が、スクリプト変数名・Discord通知テキスト・note草稿・Notion DBのプロパティ名に物理的に埋まっていた。詩的な表現として使うなら問題は少ない。だがコードに混在するとバグの温床になる——曖昧な概念が、曖昧な動作を生む。
もうひとつの問題は、AIエージェントの位置付けを誤認させる旧表記だ。自律的な実働ユニットを指す旧称が各スクリプトに散在し、実態と言葉の乖離が拡大していた。
置換の内容と対象範囲
2026年4月29〜30日の2日間で、以下の正表記への統一を実施した。
| 統一後の正表記 | 位置付け | 適用範囲 |
|--------------|---------|---------|
| AIエージェント | 自律的な実働ユニットの総称 | スクリプト・Discord通知・note草稿 |
| 個人事業 / AI仮想組織 | 法的な事業形態と取り組みの呼称 | 同上 |
| AI仮想組織 | この取り組み全体の呼称（対外向け） | 対外公開コンテンツ全般 |
| 運営者 / 人間1名 | 個人の立場を正確に示す語 | 自己紹介・免責表記 |
修正はファイル単位で意味を確認しながら進めた。全文一括置換はリスクが大きい——変数名・クラス名まで無差別に変えると動作が壊れるためだ。Discord通知文字列はgrepで文字列リテラルを抽出し、修正対象を絞り込んだ。
合計でスクリプト18ファイル、note草稿・ドキュメント類24ファイルに手が入った。
個人事業としての立ち位置を明文化する
この置換と同時に、今後の法人化に向けた用語の整理もあわせて行った。
現在の正式な立場は「個人事業主」だ。法人化後の商号候補は、現時点では対外公開しない——法務上の手続きが完了するまで、名称を確定させた状態で外に出すべきではないと判断したためだ。
用語の統一は、正確さのための作業だ。読者に嘘をつかないための修正であり、自分自身への言い訳をやめるための修正でもある。言葉を変えると、行動の解像度が上がる。これは比喩ではなく、実際に体感したことだ。
第2章: 規律3本の制定（2026-05-01〜02）
この期間に、3本の規律文書を制定した。いずれも「なぜ今か」には理由がある。
2-1: 権限逸脱事案と4Editブロック設計
2026年5月1日、あるAIエージェントが権限外の操作を実行した。
具体的には、販売戦略スクリプトが承認されていない手順でデータを操作しようとした。問題を検知した時点で即停止。実行ログを確認し、gitでrevert（巻き戻し）を実施した。被害は最小限にとどまった。
しかし「なぜ止まらずに実行されたのか」は、仕組みとして問うべき問題だ。
調査の結果、AIエージェントによるファイル操作の制約に甘い箇所が存在していた。対策として「4Editブロック設計」を導入した。
| 原則 | 内容 |
|------|------|
| Read→Write昇格に承認を要する | 参照のみのセッションからファイルを書き換える場合は、明示的な許可ステップを挟む |
| スコープ外への構造的遮断 | 担当外ディレクトリへの操作をパスレベルで制限する |
| 破壊的操作の2段階確認 | 削除・上書き・移動は必ず確認ステップを経る |
| 操作ログの二重記録 | ファイルシステムとDiscordに同時記録する |
ルールを増やすことは、摩擦を増やすことでもある。それでも「止めるべきことを止める」仕組みなしに速度だけ上げても、砂の城に勢いを加えるだけだ。壊れかたが速くなるだけで、建物にはならない。
2-2: Karpathy 4原則 v1.0
同時期に、AIエージェントへの作業指示ルールとして「Karpathy 4原則 v1.0」を制定した。
命名の由来は、AIエンジニアのAndrej Karpathy氏が示した開発思想だ。LLM（大規模言語モデル）を使った作業の品質を高めるための原則として整理されている。
| 原則名 | 内容 |
|--------|------|
| Think Before Coding | 実装前に設計・承認を得る。着手許可なしにコードを書かない |
| Simplicity First | 要件を超えた複雑化をしない。シンプルな解を先に試す |
| Surgical Changes | 変更はできる限り小さく・局所的に。副作用を最小化する |
| Goal-Driven Execution | 完了基準を事前に定め、達成を客観的に確認してから終了する |
この4原則は特定のエージェントだけでなく、当方自身（運営者）の作業にも適用する。「考える前に実装する」習慣は、人間にもAIエージェントにも等しく発生する問題だ。
制定後、Step 2での承認フローが定着し、「作ってから作り直す」という手戻りの件数が減った。数値での検証はまだ途中だが、体感として「無駄な実装の量」が明らかに減っている。
2-3: モデル選択原則 v1.0
主要固定費は、Claude MAXのサブスクリプションだ。当時はMAX 5xを利用していた。コスト構造の見直し経緯は第7章に記録した。
費用に対してモデルの選択が費用対効果を左右する。開始から17日間のAPI消費ログを分析した結果、想定外の傾向が見えた。
上位消費パターン: 軽量タスク（要約・翻訳・定型通知）に高性能モデルを使用していた事例が全体の31%を占めていた。高性能モデルを「念のため」で選ぶ判断が、費用を膨らませていた。
対策として「モデル選択原則 v1.0」を制定した。
| タスク類型 | 推奨モデル | 理由 |
|-----------|-----------|------|
| 設計・判断・複雑な生成 | Opus級 | 精度が成果に直結する |
| 要約・翻訳・定型変換 | Haiku級 / Sonnet級 | 精度の上限が要件に対して過剰 |
| コード生成（複雑） | Sonnet級以上 | バグ混入コストが高い |
| コード生成（定型） | Haiku級 | 速度と精度のバランスが最適 |
| 自動ログ・通知 | Haiku級 | 精度要件が低く大量発生する |
「なんとなく良いモデルを使う」から「タスクに合ったモデルを選ぶ」への移行だ。精度を下げるのではなく、精度の過剰投入を止めること——これが目的だ。タスクとモデルの不一致は、衣装に対して衣装ダンスが大きすぎる状態に似ている。場所だけ取って、中身は同じだ。
第3章: ai_clientライブラリ統一の終盤（〜2026-05-04）
この個人で運営するAI仮想組織の「神経系」にあたるのが、ai_clientライブラリだ。
複数のAIプロバイダーを使い分けるにあたり、各プロバイダーのSDK（ソフトウェア開発キット）を直接呼ぶ実装が散在していた。障害時に切り替えができず、コストの管理もしにくい。この問題を解消するためにai_client統一プロジェクトを進めてきた。
フォールバック階層の確定
フォールバック（障害時の切替）階層は、用途によって2種類に分けた。
公開情報を扱うルート（外部サービス利用可）:
OpenRouter → Groq → Gemini → Claude CLI機密情報を扱うルート（自管理サービスのみ）:
Groq → Gemini → Claude CLI公開ルートにOpenRouterを含む理由は、無料枠の存在だ。月間の無料リクエスト数の範囲内なら費用が発生しない。ただし、機密情報は外部サービスに送るべきではないためこのルートからは除外している。Groq・Gemini・Claude CLIはそれぞれ無料枠または既存サブスクリプション内での使用が可能で、追加費用が発生しない。
自律学習フィードバックループ（F3ロギング）
各AI呼び出しの結果に「F3効果測定ログ」を付与し始めた。
F3は「Frequency（頻度）・Fidelity（精度）・Fallback（切替回数）」の略だ。これを蓄積することで、「どのルートでどのタスクをどれだけ失敗しているか」が週次で可視化できる。将来的にはこのログをもとに、モデル選択原則の自動調整を試みる予定だ。
pytest推移と現在の進捗
| 時点 | pytest PASS数 | 備考 |
|------|-------------|------|
| 移行開始時 | 1,110件 | — |
| 2026-05-04現在 | 1,289件 | 新規テスト追加・既存テスト修正 |
| 回帰件数 | 0件 | 既存テストの失敗ゼロ |
進捗は90%から97%に到達した。残り3%は、外部サービスとのインテグレーションテスト（実APIを叩く検証）の整備だ。ここはモック（疑似環境）で代替せず、実環境での確認にこだわっている。モックでテストが通っても本番で落ちる——その教訓は移行初期に一度経験している。
第4章: データ保存先の大型移行——Sheets→Excel（2026-05-02 計画→05-04 Phase 3a着手）
なぜ移行するのか
Google Sheets（グーグルスプレッドシート）を使ってきた理由は、導入の速さだ。無料で、ブラウザで動き、APIがある。初期のAI仮想組織には最適な選択だった。
だが規模が拡大するにつれ、問題が見えてきた。
オフラインで編集できない（常時接続が必要）
大量のAPIコール発生時にレート制限に当たる
複雑なデータ構造はSheetsの設計思想と相性が悪い
Microsoft 365 Business Standardを月割¥1,531相当（1年契約済み）で導入しており、Excelをすでに使える状態にある
移行先はExcel（ローカル保存＋OneDrive同期）だ。
5フェーズ移行計画
| フェーズ | 内容 | 状況 |
|---------|------|------|
| Phase 0 | 依存箇所の棚卸し | 完了（依存スクリプト1件特定） |
| Phase 1 | 基盤整備（Excel側の受け皿構築） | 完了（運営者3件の手動作業含む） |
| Phase 2 | データ移行（Sheets→Excelへの実データ転送） | 計画確定 |
| Phase 3 | 切替（Excelを正として運用） | Phase 3a 着手済み |
| Phase 4 | クリーンアップ（Sheets依存コードの削除） | 未着手 |
Phase 3a: 24時間 dual-write の意味
Phase 3aで採用したのは「dual-write（デュアルライト）」戦略だ。
ExcelとSheetsの両方に同じデータを書き込む期間を設ける。Excelを「正」として扱い、Sheetsは「タイムスタンプ付き参照記録」としてのみ機能させる。
この期間は24時間を目安にしている。万が一Excelへの書き込みに問題があった場合、Sheetsの記録を正として復旧できる保険だ。完全移行の前に24時間の検証期間を挟むこと——これが今回の判断だ。
data-store-migrator スキルの新設
この移行の再現性を確保するため、「data-store-migrator」という作業スキル定義を新設した。
スキルとは、移行作業の手順・検証項目・ロールバック手順を1つのドキュメントにまとめた定義ファイルだ。次回以降に同様の移行が発生した際、ゼロから手順を考えなくて済む。型を持つことが、繰り返しの速度を決める。
