突然ですが皆様、自分の代わりにAIが色々やってくれないかなと思ったことはございますか？
私は毎日思っています。
ただし、楽をするには、自分の思想を反映したツールを作る必要があります。
しかし、AI を活用するだけでは、開発の負荷はそれほど下がりません。
なぜなら、多くの負担は 思考の再構築 にあります。
プロジェクトを再開するたび、
・どこまで進んでいたか
・次に何をすべきか
・今の仕様は正しいか
といった情報を、人間が毎回思い出す必要があるからです。
そこで、本連載では「AI を動かすための環境（母艦）」を整備し、AI を半自律的に動かすことで、開発の継続性と再現性を高める方法を解説していきます。
第1回のテーマは 自律エージェントという発想の重要性 です。
codex に代表される自律型 AI は、人手を置き換える存在ではなく、「状況把握」や「整理」や「次の一手の選定」といった、負荷が大きいものの反復可能な作業を肩代わりする存在として機能します。
この視点を理解すると、AI の使い方そのものを一段階変えられそうでしたので、共有します。
第1章 開発における本当の負荷
開発作業の大半は、コードを書くことそのものでしょうか？
私はエンジニアでない素人であり、主観にすぎませんが違うと思っています。
個人的には、①要件定義 ②過去の状態を思い出す作業 の2つに割かれると考えます。
①については仕組みの要であり、なぜ自分が開発したいのかに絡む部分なのでなかなかAI丸投げは難しいですが、②に関しては案外反復作業と言えます。
例えば、一週間ぶりにプロジェクトを開いた瞬間に必要になるのは、
・前回どこまで進んでいたのか
・どの関数や仕様が古くなっているのか
・テストはどこまで整備したのか
・次に片付けるべきタスクは何か
こうした情報の再構成です。そして、この再構成こそが認知負荷の中心にあります。
さらに厄介なのは、この作業が毎回発生することです。
どれだけ経験があっても、コンテキスト復元には一定の労力が必要です。
ここに AI をそのまま投入しても、効果は限定的です。
理由は明確で、チャットの文脈だけではプロジェクト全体の状況を把握できないためです。
そこで必要になるのが、人間の記憶を肩代わりする外部記憶です。
すなわち、
project_brain（プロジェクトの憲法）
WBS（タスク分解）
queue（進行状況の記録）
daily_progress（作業ログ）
といった母艦ファイル群です。
これらに状況把握のコストを移し、AI が読める形式で管理することで、
コンテキスト復元の負荷を低減できると思われます。
第2章 AI に任せる部分と任せない部分の境界線
AI には得意な領域と不得意な領域があり、この境界の設計を誤るとトラブルを招きます。
(筆者はAIに任せすぎた結果、重要な部分のコードを消してしまい、戻せなくなりました)
反省を生かし、codex の自律開発設定では、この境界を policies として明文化しています。
まず、AI に任せてよい作業は次の通りです。
● AI に任せてもよい領域
WBS に基づくタスク選定（High/Mid 判定）
スモークテストや静的解析など安全なコマンド
queue.md への進捗反映
daily_progress の生成・追記
調査・観点整理・方針検討
既存ファイルへの安全な追記
ログ・報告書の整形
これらは反復可能で再現性の高い領域であり、AI が最も力を発揮する作業といえるでしょう。好みの書き方も指定できます。
一方で、AI が勝手に行うと危険な作業もあります。
● AI に任せてはいけない領域
src/** や tests/** の直接編集
ファイル作成や削除など構造に影響する操作
pip install や pyproject.toml の変更
仕様変更や設計の大幅な書き換え
破壊的な git コマンド（commit/push/reset など）
外部サービスへの送信や大規模自動化
これらはプロジェクトの基盤そのものを揺らす可能性があり、AI の独断では危険です。
codex の自律開発設定では、こうした危険操作が予兆として現れた場合、
AI は QUESTION.txt に提案を退避するよう設定し、処理はそこで止まります。
つまり、AI が勝手に壊したり暴走したりせず、
安全性と連続性を両立させる仕組みになっています。
第3章 Codex が自律型の開発エージェントへ変わるとき
通常の AI は、質問に対して答えるところで役割が終わります。
しかし、母艦構造を整えた codex は、役割を終えないよう工夫しました。
たとえば short_run に対して「30分だけ回して」と伝えると、
codex は次の一連の行動を自律的に実行します。
状態同期（WBS / queue / defaults / project_brain）
morning_scan（タスク選定）
work_loop（作業の実施）
testing_and_review（安全な範囲でのテスト）
queue.md の更新
today-progress の更新
5〜10行のまとめをコンソールに表示
つまり、人間が席を外している間でも、プロジェクトが前へ進みます。
codex が「道具」から「働く仲間」へ変わる瞬間です。
daily_routine を活用すれば、
プロジェクト全体を毎日少しずつ進める仕組みも構築できます。
第4章 母艦モードがもたらす継続性と成果
自律エージェントの価値は、短期的効率よりも継続性にあります。
母艦モードを導入すると、次のようなメリットが生まれます。
1. 毎回のコンテキスト復元が不要になる
queue.md と日報がすべてを保持するため、
どれだけ間が空いても AI は次の行動を理解しています。
2. 反復作業を AI に任せられる
テスト、報告、整理といった、手間はあるが価値は薄い作業を自動化できます。
3. 短時間でも成果が積み重なる
30 分の short_run でも、一つは確実にタスクが前進します。
4. 人間は判断だけに集中できる
仕様決定、優先度調整、設計の分岐など、
価値の高い判断に集中できる環境が整います。
5. プロジェクトが自然と前へ進む
複数のプロジェクトを同時に抱える場合でも、
停滞しにくい状態を維持できます。
母艦モードは AI の能力を引き出す仕組みであると同時に、
人間の認知資源を守り、作業に向き合う負荷を減らすための構造化でもあるといえるでしょう。
これでもなお、yes, proceedで聞いてこようとすることはありますが、だいぶ少なりましたね...。
《離席後にcodex が実施した固定資産判定プロジェクトの進捗》
おわりに
AI の可能性にはモデルの強さも重要ですが、改めて「やらせないこと」を決めるのが重要だなと感じました。
環境（母艦）が整っているかどうかが、AI の実力を比較的左右すると痛感しました。
ただ、これは結局人間でも同じ気がします。
筆者が昔よく通っていた焼肉店では、いつも学生バイトの方が迅速に注文を取り、配膳し、網を交換し、食べ終われば皿を下げ、と全員テキパキしておりました。
家族とも「人が替わってもデキるバイトの子がすぐ入ってくるね」と話していました。
今思い返すと、彼らの役割は明確に整理されており、やらないことを決めた結果、専念すべきオペレーションが洗練されていたのだなと感じます。
多くの場合混乱を招くのは優先順位が狂う場面ですが、その店舗は早く来店した客から全てを提供していく先手必勝・弱肉強食システムで解決していました。
少し話がそれました。
今回のcodex 自律開発設定は、AI が動き続けられる器を整えてみるという発想です。
・状態を外部に記録し
・AI が読める構造で残し
・危険操作を排除し
・タスクと進捗を AI が自動管理し
・短時間でも確実に成果が積み上がる
この仕組みが整うと、プロジェクトは自然に前へ進みます。
前に進んでいる感がないと、私は面白く感じられません。そういう意味では自分向きのツールになったと思います。