AIを育てた12日間の記録

AI と一緒にアプリを作っていて
いちばん困るのは「会話が毎回リセットされる」ことです。
前の会話でどれだけ丁寧に説明しても次のセッションのAIは何も覚えていません。
自分の指示のクセ、やってほしくないこと、過去にハマった罠。
毎回ゼロから説明するのは現実的ではありません。

そこで、AI に読ませるための資料だけを集めたリポジトリを作って
git で管理することにしました。
始めてから約12日、コミット（更新の記録）は 69 回。
ここ最近いちばん力を入れていた仕組みなので
自分の振り返りも兼ねて、時系列で詳しく書き残しておきます。

始まりは共通ルールを2台のPCで同期したいだけだった

きっかけは地味で、
AI への共通指示ファイルを自宅と会社の作業用、
2台の PC で同じ内容にしたかっただけです。
片方で「こうしてほしい」とルールを足しても、もう片方の PC の AI は知らない。
手でコピーするのは絶対に忘れるので、
git リポジトリにして両方から pull する形にしました。

この時点では、リポジトリの中身は共通指示ファイル1つ。
ここから雪だるま式に育っていきます。

「後任AI向けの引き継ぎ書」の誕生

転機は、
人間の職場でいう引き継ぎ書を、AI 宛てに書くという発想でした。
宛先は次のセッションの AI。中身はこんなことです。

自分とAIの仕事の進め方
指示の言葉が本当に意味していること。
いわば「指示辞書」で、
たとえば「いい感じに」と言ったときに何を期待しているかの定義まで書いてあります
絶対にやってはいけないこと。
写真や動画などのデータファイルは削除禁止、
といった取り返しのつかない操作のリストです
何をもって「合格」とするかの基準

新しいセッションの AI は、まずこれを読みます。
すると、前の会話を知らないはずなのに、仕事の進め方がだいたい引き継がれる。
「前にも言ったのに」と同じ説明を繰り返すことが目に見えて減りました。

引き継ぎ書のほかにも、
資料は用途ごとにファイルを分けて増えていきました。

Windows 開発でハマった技術メモ
各プロジェクトの進捗スナップショット
販売・集客の方針
X（Twitter）運用の引き継ぎ書
どれも「次の AI が読めばそのまま続きをやれる」ことを目指した書き方です。

開始と終了のルーチンを「合言葉」にした

資料があっても、読む・書くの運用が回らなければ意味がありません。
そこで毎セッションの決まりごとを2つ、定型の手順として AI に登録しました。

開始のルーチン …
　　git pull で資料を最新にして、前回どこまで進んだかを報告する
区切りのルーチン …
　　その会話で学んだことを資料に追記し、進捗を更新して、コミット＆プッシュ

どちらも合言葉ひとつで AI が実行します。
特に大事なのは終了側で、
これを忘れると「その会話で学んだこと」が資料に反映されず、
次の AI がまた同じ失敗をします。
逆に毎回きちんと締めていれば、資料は使うほど賢くなる。
貯金と同じで、仕組みで強制しないと続かないタイプの作業だと思います。

ファイルが増えすぎて、大整理した

運用を始めて1週間ほどで、md ファイルは 17 個まで増えていました。
こうなると後任 AI が「どれを読めばいいのか」で迷いますし、
AI が資料を読むのにも読み込み量（＝利用コスト）がかかるので、
全部読ませるわけにもいきません。

そこで一日かけて 17 ファイルを 12 ファイルに統合し、
あわせて README に2つの表を作りました。

逆引き地図 …
「知りたいこと → 読むファイル」の対応表。
　全部を毎回読まず、必要なものだけ開く
書き先ルール …
「新しく分かったこと → どのファイルに追記するか」の対応表。
　新規ファイルを作る前に、まずこの表を見る

特に2つ目が効きました。
散らかる根本原因は
「書き先が決まっていないから、AI がその都度新しいファイルを作る」ことだったので、
既定を「既存ファイルへの追記」にしたら増殖が止まりました。
ファイルの肥大化対策として「一定の長さを超えたら圧縮し、
詳細は保管用フォルダへ退避する」という圧縮制度も作ってあります。

「自分の文体」まで資料にした

変わり種として、文体プロファイルというファイルもあります。
過去の会話ログから自分の実際の発言を抽出してもらい、
文の長さ、言い回しの癖、使わない表現などをルール化したものです。
X の投稿文やブログの下書きを AI に手伝ってもらうとき、
これを読ませると「AI っぽい文章」ではなく自分の口調に寄った文面が出てきます。

ほかに、AI が調べ物に使う検索環境
SearXNG というメタ検索エンジンを自分の PC 内に立てて、
その導入手順やトラブル対処もリポジトリに記録しました。
環境構築は一度やると忘れるので、
もう1台の PC に移植するときの手順書を AI 自身に書かせておくという使い方です。

AIの「働き方ルール」を明文化した

整理が一段落したあとは、
資料の内容が「情報」から「働き方のルール」へ広がっていきました。
きっかけはどれも実際の失敗です。

AI が途中で「続けてよいですか？」と確認ばかりして作業が止まる →
「指示から自然に導ける作業は、確認を挟まず最後まで自律的に進める」というルールを追記
仮説だけで突き進んで間違った方向に行く →
「裏取りしてから動く」「同じアプローチで2〜3回失敗したら方針転換する」
「着手前に目的を一文で言い直す」という判断基準を追記
高性能なモデル（AI の頭脳のグレード）を使い続けて利用上限に一瞬で達した →
　「タスクの重さとモデルの釣り合いを AI 自身が判断して、切り替えを提案する」
　　というルールを追記

最後のものは実感がありました。
設計や原因不明のデバッグは上位モデル
決まった作業の横展開は下位モデル、と使い分けるだけで
上限に張り付く頻度がまったく変わります。
しかもその使い分け判断を自分でやるのではなく、
ルールとして書いておけば AI の側から
「この作業なら下のモデルで足ります」と言ってくれる。

仕上げは「設計・実装・検証」の分業体制

直近の数日で作ったのが、AI の役割分担です。

設計を決める役
設計どおりに実装する役
実装した本人とは別の立場で「壊すつもりで」検証する役

この3役の性格と手順をそれぞれ資料として書き、
リポジトリに置きました（考え方の詳細は別記事に書いています）。

導入して終わりではなく、
初回テストで出た不都合をフィードバックして手順を改訂し
次の実戦で「分担どおり機能した」と確認するところまでやりました。
検証役は実際に、公開前の自作ツールから実害のあるバグを複数見つけています。
あわせて「見つけたバグを一般化して
検証のたびに観点が増えていく」形にしてあります。

12日間を振り返って

コミット履歴を眺め直すと、この12日間でやったことは3段階に分けられます。

記憶を持たせる
　引き継ぎ書・技術メモ・進捗スナップショット
運用を回す仕組みを作る
　開始・区切りのルーチン、逆引き地図、書き先ルール、圧縮制度
働き方そのものをルール化する
　自律実行、判断基準、モデルの使い分け、分業体制

最初から設計図があったわけではなく、全部その場の失敗から生まれています。
だからこのリポジトリは、資料集であると同時に
AI との仕事で得た教訓の貯金箱です。

コードが書けない自分にとって、AI は唯一の開発メンバーです。
そのメンバーが毎回記憶を失う以上、記憶の側をこちらで持つしかない。
置き場所を git リポジトリにしたのは、たまたま開発で使っていたからですが、
「差分が残る」「2台の PC で同期できる」「いつでも過去に戻れる」という性質は、
育てていく引き継ぎ書の置き場所として相性抜群でした。
69 回分の履歴そのものが、そのまま今回の振り返りの材料になったくらいです。