「Claude Code×GPT」自律ループが凄すぎ、仕事が“3つ”に減る5ステップ(2/3)

「指示出し」すらAIが自動化…人間がやればいい「たった3つ」のタスク

　筆者の環境を具体的に紹介しよう。中心はClaude Codeだ。まず、CLAUDE.mdという設定ファイルに開発の原則を明文化してある。「最小の実装から始める」「仕様を推測せず、必ず検証する」「基盤部分に仮のデータを使わない」といった、AIが迷ったときの判断基準だ。

　次に、要件定義書、設計書、実装計画書などの開発文書の名称と役割を決め、AIに必ず作らせ、参照させている。これらの文書がAIの外部記憶として働く。AIが一度に覚えられる情報量には上限があるが、状態をファイルに書き出しておけば、次に立ち上げたAIが読んで引き継げる。状況が変われば、AIはこの「記憶」を自分で書き換えて更新する。

　さらに、設計の担当、テストしながら実装する担当、レビューの担当という具合に、仕事別の「サブエージェント（SubAgent）」を作る。レビューは開発元の違うGPT系モデルに任せ、作った本人に採点させない。

　仕上げが「/issue-to-merge」という自作コマンド（スキル）だ。課題ファイルを読み、実装計画を立て、複数のAIが手分けして実装し、GPTのレビューを受け、テストと本番反映と動作確認を済ませ、完成したコードを本体に組み込むところまで自動で進む。このスキル自体もClaude Codeに書かせた。人間が書いたのは課題とゴールの説明だけである。

　約1年運用して、筆者の仕事は3つに絞られた。


　この3つだけだ。人間は開発の流れに常時付き添う操作員ではなく、ゴールを決めて例外だけに対応する監督になった。コードを書かなくなったことよりも、うまく回っている限り人間が工程から抜けていることこそが大事だと考えている。


　強調したいのは、最初からループエンジニアリングを目指したわけではない点だ。毎回の面倒な作業を1つずつ自動化した結果、振り返るとこの形になっていた。だから読者も、一歩ずつなら同じ道をたどれるはずだ。

　バイブコーディングをしない読者にも、この話は無縁ではない。AIに仕事を任せる場面では、資料作りでも調査でも、「どこまで任せ、どう確認し、いつ止めるか」という同じ設計の問題が必ず現れるからだ。

「いきなり全自動化」はNG？ 成功に導く“5つ”のステップ

　では、何から始めればよいか。多くの人は最初に「全自動で回るコマンド」を作りたがる。順番は逆だ。判断の原則と検証の仕組みがない状態で自動化すると、間違った方向へ高速で突き進むシステムができあがる。筆者の経験から、次の5ステップを勧めたい。

■Step1：判断の原則を書く
　CLAUDE.mdのような設定ファイルに「迷ったときのルール」を10～20個書き出す。筆者なら「仕様を推測で変更しない。まず既存の仕組みを調べる」といった具合だ。自動化の第一歩はAIを動かすことではなく、AIの判断基準を固定することである。

■Step2：文書をAIの外部記憶にする
　要件定義書・設計書・実装計画書の3点を毎回作る決まりにする。記憶がファイルに残れば、開発は中断をまたいで続く。

■Step3：作る係と評価する係を分ける
　設計・実装・レビューを別のサブエージェントに割り当て、自分の宿題を自分で採点させない。AIは自分の作ったものを甘く評価しがちなので、ここが品質を守る生命線になる。

■Step4：合格を機械が判定できるようにする
　テストや文法チェックを、コマンド一発で実行できる状態に整える。テスト駆動開発を採用していれば、そのテストがそのまま「終わってよいか」を判定する客観的な停止条件になる。

■Step5：繰り返す作業を標準手順書にする
　画面作り、データベース変更などの頻出作業を、「スキル（Agent Skill）」として登録しておく。

　最後に外側のループをつなぐ。ここまで部品がそろっていれば、工程を順につないだ自動コマンドはAI自身に書かせられる。

　この最終段階で重要なのが「終わり」の定義だ。「ログイン機能を完成させろ」だけの指示は抽象的で悪いゴールだ。AIが「できました」と言えば終わってしまうからだ。「テスト42件がすべて通り、文法チェックのエラーが0件になるまで修正する。5回試して駄目なら、状況を報告して止まる」ならAIは正しく動く。しかし、そんな指示は人間には面倒すぎる。

　ここで「コンテキストエンジニアリング」が重要になる。正しいコンテキスト（詳しい目的や背景事情）がAIに共有されていれば「ログイン機能を完成」に必要な機能とテストをAIが自分で設計し、実装からレビューまで完遂できる。必要十分なゴール条件も自分で設定させ、完了したか自分でチェックさせる。このゴール判定の精度こそがループエンジニアリングの肝なのだ。

　もう1つが「人間の関与」の設計だ。完全無人化は目標ではない。筆者も本番反映の直前だけは自分で判断すると決めている。システム上は反映できる状態でも、業務の都合で触れないときがあるからだ。人間をどの工程から外し、どこに残すか。それを決めること自体がループエンジニアリングなのだ。

　最後にコストにも触れておきたい。ループ化するとAIの利用料は増える。Anthropicも、定型作業には安価なモデルを、重要な判断には高性能なモデルを充てるよう推奨している。以前の記事で紹介した「ハイローMIX」と相性の良い考え方だ。 【次ページ】「最強AI」でも成功率25％…「完全自動化」はまだまだ幻想と言えるワケ