パーソナルAIファクトリーの構築

328日前原文(john-rush.com)

概要

AIエージェントを工場のように組み合わせて、コード生成・検証・改善を自動化する手法の紹介。
出力（生成コード）は使い捨て とし、プランやプロンプト（入力）を改善して品質向上を図る考え方。
複数のAIモデル （claude、o3、sonnetなど）を役割ごとに使い分け、並行して機能開発を進行。
ワークフローの自動化・拡張性 を重視し、エージェントの自己改善サイクルを実現。
今後の課題 として、より高度なエージェント連携や抽象度の高い情報活用を目指す。

AIエージェント工場の構築と運用

claude codeを主なインターフェース として利用し、各git-worktreeごとにウィンドウを分割運用。
o3・sonnet 4は計画立案、 sonnet 3.7やsonnet 4は計画実行、 o3は結果検証 を担当。
コード生成に問題があれば、出力を直接修正せず、計画やプロンプトを改善 し再実行。
Factorioのような自己増殖型工場 をAIエージェントで再現し、コード生成・検証・自己改善のループを構築。
複数のclaude codeインスタンスとgit worktree を活用し、並行して複数機能の開発を実現。

基本ワークフロー

Step 1: 計画立案
- 高レベルのタスクをclaude codeに指示
- o3が計画を作成 し、clarificationの質問も実施
- <task>-plan.mdに依頼内容と実装計画を記載
Step 2: 実行
- sonnet 4が計画を検証・タスクリスト化
- claude codeが、sonnet 3.7またはsonnet 4でタスクを実行
- 各ステップごとにコミットを作成 し、ロールバックも容易に
Step 3: 検証とフィードバック
- sonnet 4とo3がコードを計画・依頼内容と照合し検証
- o3は妥協せず不要な互換性コードやlint無視フラグを指摘
- 指摘事項はプランテンプレートに反映し、コード自体は直接修正しない

入力重視の理由と実例

出力は使い捨て、計画・プロンプトは蓄積資産
ソースでのデバッグは将来すべてのタスクに効果を波及
例：CSV全読み込みからストリーミングに変更→以後の計画で自動チェック

工場のスケールアップ

特定タスクごとに専用エージェント（MCP）を用意
- 例：clojureコードのスタイルルール適用専用エージェント
- 例：リトライ処理の共通ライブラリ化
小規模エージェントを組み合わせて複雑なワークフローを構築
- 例：APIドキュメント＋ビジネスケースから統合・テスト・ドキュメントを自動生成
並列実行・反復で効率化
- 複数エージェントを同時実行し、失敗や不足情報は次回にフィードバック
- 出力修正を避け、常に入力（計画・指示）を改善

今後の展望と課題

エージェント間の自動調整・ワークフロー自動化
ビジネスドキュメントの抽象度向上とエージェント活用性の強化
より複雑なワークフロー・多エージェント連携の推進
プロバイダーごとのトークン制限への柔軟対応（claude max/bedrock間の切り替え等）

結論：本質は「入力を直す」こと

工場はコーヒーを淹れている間にコードを出せるレベル に到達
本質は「出力ではなく入力を直す」こと
制約は変わるが、原則は変わらない

Hackerたちの意見

もっと具体的な情報が知りたいな。例えば、Claudeとo3がどうやり取りしてるのか、セッションの例とか。

└

おそらく、Goose経由でMCPを使ってClaude Codeに接続してるんだと思う。>「私もGooseとo3を動かしているローカルMCPを持っている。」

└

私はZen MCPとOpenRouterを使ってる。たまに、私のClaude Codeが「友達に電話」して、Geminiでコードレビューをすることがある。大抵は自分から頼むことはないけど、提案された実装がうまくいくか不安な時に「分析」や「ウルトラスルーキング」をお願いすることがある。無提示で動いてるのを見るのはすごいよ。計画のためには、Geminiに行って作業をチェックしたり、アイデアを出したり、リサーチや完成度の評価をすることが多い。少なくとも私には、その反復が役立ってるみたい。こういうスレッドではみんな「証拠」を求めるけど、何を出せばいいのか分からない。Claudeの計画がどうなってるかのセカンドオピニオンを得るのに4セントかかる感じで、詳細な返答は面白かった。先月OpenRouterに10ドルチャージしたけど、50セントくらい使ったかな。今はClaude Maxを月200ドルで使ってて、GPT Plusも20ドル。OpenRouterのはほんと小銭みたいなもんだね。$0.02 :D

こういうセットアップを評価するのは、結果のコードがどう使われているか知らないと難しいよね。個人用のスタンドアロンアプリで使うなら、納得できるけど。複雑なプロダクションシステムで高品質なコードを書くのは、ちょっと信じがたいな。

└

この記事やそのワークフローはちょっと曖昧で、よく分からないな。でも、私は複数のエージェントが互いに話し合ったり、非同期エージェントやgitワークツリーを使ったりして、複雑なプロダクションシステムで日常的に作業してる。出力を全く変えないわけではないけど、望んでる出力が得られないときは、ワークフローを見直す必要がある信号だと思ってる。

└

その通り。私はコーディングの大幅なスピードアップのためにClaude Codeを使ってるけど、すべてのコード変更には目を光らせて、最適なシステムを作るようにしてる。数回だけ放置して動かしたことがあるけど、その結果、顧客が対処しなきゃいけないバグが出たことがあった。

まとめありがとう！「Vibe Specs」についての投稿で、似たような、でもちょっとシンプルなワークフローについて話したよ。https://lukebechtel.com/blog/vibe-speccing 今はこれらのルールをすべてのコードベースで使ってる。基本的にAIに2つのことを違うやり方でやらせるんだ：(1) まず私に質問させる (2) コードを書く前に spec.md ドキュメントを作成する。あなたのとあまり変わらない気がするけど、私は一つのLLMに限定してる。

└

たくさんの人がこれを試してると思う（当然だけど）、ソロ開発者としてエンジニアリングファーストの考え方で、ガジェットを生み出す機械や工場を作ってる。私はまだゴールには到達してないけど、私にとっての聖杯は、エージェントが生成したe2eテストを通じて得られるコードの自信なんだ（実装とは別にね）。

└

Claude Codeは今や「プランモード」でこれをネイティブに扱えるようになったね。手動で.mdファイルを扱うのはちょっと遅くて面倒だと思う。

この記事は、まだClaude Codeで「アハ！」って瞬間を経験していない人には、ほとんど理解できないんじゃないかな。あの瞬間は、「claude --dangerously-skip-permissions」を使って難しい問題に取り組ませて、数分間いろんなツールを使って自動で解決するのを見守るときだよ。今日は486アセンブリでマンデルブロ集合の生成器をコンパイル、実行、デバッグさせてみたんだけど、MacのDocker上で動かしてみたら、すごくうまくいったよ！ https://gist.github.com/simonw/ba1e9fa26fc8af08934d7bc0805b9...

└

がんばれ！ここはYCだよ！なんでまだユニコーンになってないの？

└

誰かの役に立てばいいな。私はClaude maxからプロに20ドルでダウングレードしたけど、使用制限がかなり良いよ。彼らはGemini cliと競争しようとしてるみたいで、今は安く済んで嬉しい。

└

こういうIDEが簡単にこなせるのは、かなりトリビアルな例だね。アセンブリは確実に彼らのトレーニングセットに入ってるし、もちろんDockerもそう。私のコードベースで遊ばせたら、カーソルがめちゃくちゃになったのを見たよ。早く実用化されると思うけど、まだそこには至ってないね。

└

これはすごくシンプルな例/コンテキストで、ほとんどのLLMは簡単にこなせると思う。私はもっと複雑なRustの依存関係のアップグレードを、30回以上のイテレーションでやったことがある（wasmのやつで、トレーニングデータは多分少ない）。Claudeはcontext7やmcp-lspに詳細を聞いてた。でも、しばらく使ってると限界が見えてきて、もっと厳しく使うとその限界がわかるよね。

└

それが「claude --dangerously-skip-permissions」を使って難しい問題に取り組ませて、数分間いろんなツールを使って自力で解決するのを見守る瞬間だよ。うーん、Claudeがコードを間違って修正しようと1時間かけてるのを見てた。最終的に何が起きてるのか気づいて、介入してユニットテストをいくつか書くように頼んで、ユニットテストに対してコードを動かすようにしてから、また連絡してもらうようにした。Claude Codeはすごいけど、基本的なアーキテクチャのガイダンスを何度も与えなきゃいけないんだよね。

└

https://youtu.be/bUBF5V6oDKw AIエンジニア会議のこのビデオも追加したいんだけど、Daggerの人たちが作ったもので、もしかしたら難解かもしれない。

└

Codexよりそんなに良いの？

ADHDでコード書いて、うまくいくまで無理やりプロダクト作ってるの？カーボンフットプリント増やすんじゃなくて、将来的に拡張や修正ができるコードを書けばいいじゃん。

└

最終的な目標は、開発者をこの方程式から外すことだよ。ビジネスオーナーが新しいCRUDアプリを求めたら、すぐに稼働するって感じ。もちろん、バグだらけで、シロップみたいに遅くて、認証なしの公開データベースに保存されるけど、それは私の知ったことじゃないし 熱いお茶を飲み込む

└

いや、プログラミングは永遠に変わったよ。これに気づくのが早いほど、君にとってはいいことだ。「コードを書け」って言うのは、馬に靴を履かせる代わりに、壊れるかもしれない新しい車を扱うように人に言ってるようなもんだ。

└

未来に拡張・修正できるコードを書いてくれよ。なんでいつもこの議論になるの？最近のコーディングアシスタントに0shotで拡張可能でメンテナンスしやすいコードを書かせるのがそんなに難しいと思う？ただそのタイプのコードをお願いしてみたことある？

基本的なアイデアは、システムが何をすべきか（高レベルと詳細な機能）、それをどう証明するか、オプションでどうやってやりたいか（アーキテクチャやコードスタイルなど）を継続的に文書化できるってこと。マルチモデルAIの部分は、バイアスを避けて特定のタスクのために微調整された選択をするための（現在の）ツールに過ぎない。最終的には、大規模で複雑なシステムが要求仕様から構築され、ソフトウェアが最終的にその要求に合致するようになるよ。唯一の「レガシーコード」はレガシーな要求仕様になる。生成されたコードを直すんじゃなくて、要求を直せ。

└

ごめん、でもまた… https://i.pinimg.com/736x/03/af/06/03af0602a8caa51507717edd6...

自己言及的でない結果についてはあまり言及されてないね。 vibe-codingは次の3Dプリンティングになるかもね：無限にいじくるのに最適な高価な趣味。今日のvibe codingの「ベンチー」に相当するものは何だろう？Todoアプリ？

└

3Dプリンティングって実際めっちゃ役立つよね。基本的に、製品をデザインしたりエンジニアリングする人はみんな使ってる。一般消費者に広まらなかったのは、欲しいプラスチックのゴミみたいなデザインがもうアマゾンで手に入るからだと思う。オンラインショッピングが普及する前だったら、3Dプリンティングはもっと一般の人にとって便利だったはず。これからは、自分でファイルをデザインできる人にしか本当に役立たない感じだね。

私も似たようなワークフローを試していて、経験をシェアしたいと思った。多くのエージェントクラスターの証言と比べると、細かいところにこだわりすぎかもしれないけど、著者とは違って、私が作業しているコードベースは数十万行のGoで、実際に高い5桁から低い6桁のB2Cユーザーがいるって言えるよ。パフォーマンスの要件はゆるいけど、正確さと信頼性はめっちゃ重要。今は、リポジトリをクローンしてエージェントを設定して、tmuxセッションでプロンプトに対して実行するという基本的なスクリプトのセットアップを使ってる。OpenAIのキーしかもらってないから、主にcodex-cliに頼ってる。codexのインスタンスが私のシステム通知で順番が来たら教えてくれるから、ターミナルをクイックモードで表示させてセッションに接続するのも簡単。MCPにはまだ手を出してないけど、気にはなってる。ビジョンはなんとなく見えてきた。小さくて気を散らすようなタスクにはすごく役立ってて、今は（ほぼ）受動的にコードベースの細かい修正をたくさん作ってる。「家畜はペットではない」って考え方は今でも大事で、ちょっと気が散りそうになったらすぐにプロンプトを投げるようにしてる。もっと複雑なタスクにはあまり効果を感じてないかな。もしかしたら、まだ十分なコンテキストのフライホイールが回ってないのかもしれないけど、ほとんどの場合は自分で介入しなきゃいけない。作業中の変更でも、生成されたコードを最初に読んで、提出する前に自分の好みに合わせて編集するから、出力は自分の責任だと思ってる。変更管理プロセスもほとんどマイクロマネジメントしてるし（ブランチ作成、コミット、プッシュ）。自動化できるツールにも手を出してみたけど、まだ実行できてない。入力を直すべきって考え方には100%共感する。AIなしでもすごく強力で、私たちの業界は少しずつだけど、もっと多くの場所でそれを取り入れてきてる（静的型付け、DevOps、IACなど）。でも、LLMのような非決定的なプロセスでは、達成するのがすごく難しいと感じる。もっと練習のようなもので、科学とは違うね。

└

最近、コンテキスト管理についての話がたくさんあるけど（「最近」とはエージェント分野では数日を指す）、これらの方法を使うときに自分のコンテキストを管理するのが一番難しい。

「入力を直す」 => 完璧な入力があれば、ちょうど欲しいものが得られるって前提があるよね。小さな入力やトレーニングデータでよく表現されているタスクにはうまくいくと思う（よくあるドメインのコードを書くみたいに）。でも、古いコードや大規模なコードベース、緊急時にはどうなるの？ - 昔みたいにシステムを「学ぶ」ことはできるの？ - コードベースを通して作業する経験を感じないと、リファクタリングをどう考えるの？全体的には、私は好きだよ。再発明する必要がないコードにはスピードを加えると思う。でも、新しいドメインや新しいツール、物事をモデル化する新しい方法、開発者にとって楽しい部分は、まだ私たちが倒さなきゃいけないモンスターだね。

└

でも、古いコードや大規模なコードベース、緊急時にはどうなるの？実際にClaude Codeを試したことある？私の古いコードや中規模のSaaSコードベースではかなりうまく機能してるよ。一つか二つのプロンプトで、バックエンド、フロントエンド、データ移行、テストを含む全機能を一気に作ってくれたこともある。

俺は今、Claudeにbooking.comみたいな見栄えのいい検索バーを作らせようと奮闘中なんだけど、個人的な使い方に合わせて調整が必要なんだ。まあまあうまくいくけど、最終的な結果にはたどり着かないし、Tailwindの知識を復習したら手動でコーディングするよりもずっと遅く感じた。まるで別の世界にいるみたい。

└

コーディングアシスタントはまだUI/UXが得意じゃないと思う。彼らは視覚的に見えないから、左/右/明るい/暗いの理解はCSSチュートリアルに付いてるテキストの説明から推測してるだけで、実際に作業しているものの見た目を想像してるわけじゃない。CursorにCSSグリッドを何度も修正させては失敗させて、結局HTMLテーブルに切り替えたらブラウザがレイアウトを処理してくれるようになった。「左端」から「行の最初のセル」に視覚から意味に切り替えた途端、エージェントはすぐにタスクを正しくこなすようになった。今はバックエンドやライブラリのタスクに任せておくのがいいと思う。企業はすでにブラウザページのスナップショットを取得して、それをマルチモーダルモデルにフィードバックして「見る」ことが何を意味するのかを理解させる作業を進めているはずだ。

└

俺はClaudeとCursorを並行して使ってる。CursorはUIの部分で素晴らしい働きをしてくれて、変更したい内容を指示するためにサクッとスクリーンショットを撮ったら、ちゃんと反映してくれた。

ハクソク