- 複数のAIエージェント（claude/o3/sonnet など） を活用し、コード生成から検証までを自動化する個人用「AIファクトリー」ワークフローを運用している
- 問題発生時にコード（Output）を直接修正せず、プラン、プロンプト、エージェント構成などの入力（Input）を改善して自動化レベルを高める方式が中核となる
- このように入力を反復的に改善すると、エージェントが継続的に進化し、反復作業の生産性を最大化できる
- 各エージェントの役割分担: 計画立案（o3/sonnet4）、実行（sonnet3.7/4）、検証（o3/sonnet4）などに分け、並列処理と自動フィードバックループを実現
- コードエラーやスタイル上の問題も計画テンプレートに反映し、次回の生成から改善されるよう設計することで、反復的な入力改善によりファクトリー自体が成長する
AIファクトリーの概要と中核原則
- 複数の claude code ウィンドウを異なる git-worktree 上で動かし、分離された作業環境を維持する
- o3 と sonnet 4 はプラン立案に使われ、sonnet 3.7 または sonnet 4 は実行を、o3 は結果評価を担当する
- 計画立案、実行、検証をエージェントごとに並列分担して効率化する
中核原則 – 「結果（Output）の修正ではなく入力（Input）そのものを改善する」**
- 問題が起きても生成されたコードを直接パッチせず、プラン、プロンプト、エージェントの配分を調整して自動化された改善を目指す
- Factorio のゲームのように、自動で成長する工場型AIエージェントネットワークを作るというコンセプトである
- この構造では、計画-コーディング-検証-改善までのループが循環し、AIエージェントが自らコードを生産・検証・改善する環境を構築する
日常ワークフロー – ファクトリーの構造
- メインインターフェースは claude code であり、ローカルでは mcp や Goose（Azure OpenAI モデル接続用）、o3 などを活用する
1段階: 計画（Planning）
- claude code に高レベルの作業（task）を入力 → o3 が追加質問の後、計画案（<task>-plan.md）を生成
- 計画案には元の要求事項と実装プランが含まれる
2段階: 実行（Execution）
- sonnet 4 が計画をレビューした後、タスクリストに変換
- claude code が作業を実行し、課題の複雑さに応じて sonnet 3.7 または 4 を使用する
- claude は各作業ステップごとにコミット履歴を残すため、問題発生時に容易にロールバックできる
3段階: 検証とフィードバック（Verification → Feedback）
- sonnet 4 が生成コードをプランに照らして初期検証を行う
- 続いて o3 がプランおよび最初の要求事項と比較し、より厳格に検証する
- o3 は不要なコード（例: lint ignore フラグ）や古い構造を厳しく指摘する
- 検証で明らかになった問題はコードを直接修正するのではなく、計画テンプレートの改善として反映する
- git worktree を活用して複数の claude code インスタンスを並列運用し、同時マルチタスクを可能にする
「入力」が「出力」より重要な理由
- 成果物（Output）は捨てられても、計画/プロンプト（入力）は継続的に蓄積・改善される累積資産である
- 入力部（プラン、プロンプト）でデバッグすれば、今後のすべての作業へ拡張できる
- エージェントを単なる生成器ではなく、自ら学習し協調する存在へと変化させる
- 例: CSV 全体をメモリに載せるコードをストリーム処理に変更させ、その後はすべての CSV にそのパターンをプランへ反映して、以後の自動検証を可能にする
ファクトリー拡張とエージェント協調
- MCP により専門化されたエージェントを異なる作業に割り当て、並列化する
- 例: Clojure コード全体を集めてローカルのスタイルルール適用専用エージェントを運用し、claude が lint/test/debug サイクルで発生させるスタイル問題を補正する
- 内部ライブラリコードでも、旧来のコードにある retry や
Thread/sleep の使用を独自の retry ライブラリへ置き換えるなど、生産性と一貫性を強化する
- 小さな単位のエージェントを複数構築し、特定の小作業ごとに組み合わせることで、複雑なワークフローも自動化できる
- 例: API 仕様とビジネスケースから、エージェントの組み合わせによって統合、テスト、文書化まで自動処理する
- 中核は、入力を継続的に修正しながら繰り返し実行し、失敗・停滞・文脈欠落があれば次の試行でフィードバックを反映して改善すること
- コード自体は消耗品であり、本当の資産は指示内容（入力）とエージェント構成である
- 失敗・停滞・文脈不足など、あらゆる問題から得た教訓を次の入力に反映し、ファクトリーループを完成させる
次の段階と今後の方向性
- エージェント間の全体コーディネーションを強化し、ワークフロー全体の追跡と自動化導入を進める
- ビジネス文書とエージェント情報を適切に結び付け、より高水準の抽象情報を中心にキャプチャして、さらに効果的に活用できるよう改善する
- ますます複雑なワークフローの実装を目指しており、エージェント間の協調や複雑な相互作用を拡大していく
- 複数ベンダーのトークン割り当てを最大限活用し、容易に切り替えられる仕組み（特に bedrock sonnet 4 のトークン制限への対応）も模索している
結論
- 現在のAIファクトリーでは自動コード生成・検証が日常化しており、コーヒーを一杯飲む間にもコードをデプロイできる
- まだ完全自動化の段階ではないが、**「出力修正ではなく入力改善」**という原則がファクトリーの本質として定着している
1件のコメント
Hacker Newsのコメント
この記事は、Claude Codeで「あっ」となる瞬間を体験したことがない人には、ほとんど理解しづらい内容だと思う。
claude --dangerously-skip-permissionsで権限制限を外して複雑な問題を任せると、Claudeがさまざまなツールを自由に使って問題を解決する様子を見ることができる。今日もDockerで486 assemblyのマンデルブロ集合フラクタル生成器を自分でコンパイルし、実行し、デバッグまでさせてみた。
本当に見事に処理していた。
gistリンク
これはこうしたIDEやLLMにとってはかなり簡単な例だと思う。
アセンブリは学習データセットにも十分含まれているし、Dockerも同様だ。
Cursorを自分のコードベースで好きに走らせてみたこともある。
最新ツールがいつか本当にそこまで到達することは期待しているが、まだその段階には来ていないと感じる。
Dagger（とDockerの創業者）がAI Engineerカンファレンスで発表したこの動画も追加でおすすめしたい。
この動画もやや難解かもしれない。
もしかしたら参考になるかもしれないので書いておく。
私はClaude maxからproに下げたが、月20ドルで利用制限も十分に余裕がある。
Gemini CLIと競争しているようで、今は支払う額が減ってうれしい。
この程度の例や文脈なら、ほぼすべてのLLMが特に苦労せず解けると思う。
私はもっと複雑なRust依存関係のアップグレードを30回以上繰り返し、custom wasmコードで処理した経験がある。
Claudeはcontext7やmcp-lspなど複数のツールをつなぎ、詳細情報を集める。
ただ、使い続けると限界に突き当たるので、もっと精密かつ難しい問題をぶつけると弱点が見えてくる。
「
claude --dangerously-skip-permissionsで複雑な問題を任せると複数のツールを活用して問題を解決する」という文言について。私はClaudeが1時間以上、間違ったやり方でコードを直そうと奮闘しているのを見たことがある。
結局こちらが介入して、「まず単体テストを書き、そのテストが通ったらコードを書いて、終わったらまた知らせてくれ」と指示した。
Claude Codeは本当に素晴らしいツールだが、基本的なアーキテクチャの地図は繰り返し与え続けなければならないのが現実だ。
コードの成果物が実際にどう使われるのか分からなければ、こうしたセットアップを評価するのは難しいと思う。
個人的に使うvibe codingアプリの話なら本当に信じやすいが、
複雑な本番環境で高品質なコードを書くという話は簡単には納得しづらい。
完全に同意する。
私はClaude Codeでコーディング速度を大きく上げているが、コード変更のたびに必ず自分で確認し、最適なシステムができているかを確かめている。
ただ回しっぱなしにした数回の試みでは、ユーザーにバグを届けることになった。
正直、この投稿で説明しているワークフローや概念があまりよく分からない。
少し曖昧な説明だからだと思う。
私は日常的に、複数のエージェントが互いに会話する構造や、非同期エージェント、git work treeのようなものを使って複雑な本番システムを扱っている。
出力結果をまったく変えないわけではないが、望む結果が出なければ、それを自分のワークフロー改善のシグナルとして受け取るようにしている。
私も似たワークフローを試しているので、自分の経験を共有したい。
私が扱っているGoコードベースは数十万行規模で、実際に数万〜数十万人のB2Cユーザーが使っている。
パフォーマンスには余裕があるが、正確性と信頼性が非常に重要なファイナンス分野だ。
私はOpenAIキーだけを使う環境なので、codex-cliと簡単なスクリプトでリポジトリ複製、エージェント構成、プロンプト実行などの基本セットアップだけを使っている。
codexインスタンスがシステム通知で自分の番を知らせ、fzfを使って必要なときにtmuxセッションへアタッチする。
まだMCPは使ったことがないが、関心リストには入っている。
こうしたやり方は小さく散発的なタスクを処理するときには非常に役立ち、今では細かなPRをずっと多く作れるようになった。
「cattle not pets」というメタファーは今でも当てはまり、小さな作業は素早くプロンプトを投げて気の散りを減らしている。
もっと大きな仕事にはまだあまり合っていないようで、たぶん私自身が十分なコンテキストのフライホイールを作れていないのかもしれない。
ほとんどの場合、結果のコードは必ず自分で読んで手を入れてからコードレビューに出す。
変更管理もほぼすべて手動で行い、ブランチ作成・コミット・プッシュも自分でやる。
自動化ツールもいくつか試したが、完全には移行できていない。
「出力ではなく入力を直せ」という考え方には100%共感する。
AIがなくても非常に強力な原則であり、業界でも徐々に受け入れられつつある。
LLMのような非決定的プロセスでは適用が簡単ではなく、科学というより練習に近いと感じる。
良い記事をありがとう。
私は「Vibe Specs」という記事で、似ているが少し単純なワークフローを紹介している。
関連ブログ記事
私はコードベース全体にこのルールを使い、AIに2つの点で異なる振る舞いをさせている。
(1) 何よりも先に質問をさせる。
(2) コーディングの前に
spec.mdドキュメントを作らせる。問題意識は似ているが、私は1つのLLMだけに限定している。
たぶん私たちの大半が似たようなことを試している。
個人開発者として、エンジニアリング中心の発想でさまざまな生産自動化を実験している。
私にとって究極の目標は、エージェントが自動生成したe2eテストからコードへの信頼を得ることだ（実装そのものとは切り離して）。
まだ完全には成功していない。
今ではClaude Codeも「plan mode」でこうしたフローをネイティブにサポートしている。
.mdファイルを手作業で作るのは、実際のところ遅くて面倒に感じる。
基本的な考え方は、システムがどう動くべきか（高レベルなことも細かな機能も）、どうやってその動作を証明するか、さらにはアーキテクチャやコードスタイルといった実装方法まで、継続的に文書化できるという点にある。
複数モデルを使う理由は、バイアスを減らし、特定の作業に合った微調整の選択肢を増やすためだ。
いつの日か、大規模で複雑なシステムも要件セットをもとに再構築できるようになり、そのとき初めてソフトウェアが要求仕様と本当に一致するようになるだろう。
そのとき残る「レガシーコード」は、レガシーな仕様書だけになる。
生成されたコードではなく、要求仕様を直せという視点だ。
関連ミーム画像
いったい実際には何を作っているのか気になる。
AIワークフローについて語るたびに、半分は夢のようなフローの話なのか、それとも本当に生産的に使っているのか分かりにくい。
LLMがコードを全部書いてくれると、むしろ興味が薄れる。
50個ほどあるプロジェクトのうち、LLMで作ったのは2つだけで、それも自分で手を入れた。
残りは「こういうものがあったらいいな」と思っていただけで、実際には結果にそれほど関心がなかった。
結局、複数のモデルや実装の細部と格闘しながら、望んだ動作が出ないと設計文書、プロンプト、サンプルデータを次々投入してコンピュータと戦うループに閉じ込められる。
単にコード入力を少しずつ補完してもらう程度のほうが、ずっと速くてストレスも少ない。
振り返ると、時間とコストだけを使って、成果物はどうにか動くソフトウェアにすぎなかったと思う。
明確な要件や既存コードベースがあり、自分が主導してガイドするならエージェントはかなり役立つが、vibe codingのような流れは、小さなスクリプトやニッチなアプリでもない限り、まったく面白くないし、望む品質もなかなか出ない。
高すぎるうえに、コードも依然として散らかっている。
結局、コンピュータと終わりのない議論に時間を費やしている感じだ。
それなら自分でやったほうがずっといい。
複数のエージェントがそれぞれのwork treeで作業するときの問題は、各エージェントが細部に至るまで互いにまったく違うアイデアを出すので、ユーザー体験がまるで統一されないことだ。
たとえばDocumentsダッシュボードとDesignダッシュボードを作るエージェントが、完全に異なる観点から設計してしまう。
デザインの一貫性も、構造も、DBスキーマやAPI設計も、どれも統一感がない。
入力が同じでも出力が違う。
結局、一貫性のためにinstructionファイルを増やしていくと、大規模プロジェクトでは数千行が当たり前になり、context windowも足りなくなる。
結論として、特定のルールやスキーマだけを学習した小さなLLMを使うほうが適していると思う。
プロンプトで宇宙のように広いアイデアを扱う大型LLMより、小型LLMのほうが正解かもしれない。
エージェントごとにまったく違う結果になり、デザインにも一貫性がない。
結局、シニアはやはり必要だ。
AIであれ人間であれ、望む方向へ動かすための最低限の構造と柔軟性は、こちらが自分で与えるしかない。
構造がないなら、自分でコーディングしたほうがずっといい。
私は最初のバージョンを自分で作ってから、その後の作業はClaude Codeに「この例のように作れ」と伝えると、一貫性を保ちやすかった。
ADHD的なコーディングで、とにかくプロダクト生成を試して、合うまで繰り返すやり方？
それなら将来拡張できるコードを自分で書いたほうがいいのではないか。
わざわざカーボンフットプリントを増やす必要はないという立場だ。
最終目標は、このプロセスから開発者を排除することだ。
ビジネスオーナーが新しいCRUDアプリを要求したら、そのまま即座に本番へ載せる段階だ。
もちろん成果物はバグだらけで遅く、認証されていないDBに保存することになるが、それは自分の仕事ではない、というマインドだ。
最後は熱いお茶をがぶ飲みするような激しい表現で締めくくっている。
プログラミングは永遠に変わってしまったので、その変化を早く受け入れるべきだ。
「ただコードを書け」というのは、みんなで自分の馬車を手入れしようと言っているようなものだ。
車も壊れるのだから、昔のやり方に固執しようというのと大差ない。
なぜいつも「将来拡張できるコードをただ自分で書け」という話になるのか不思議だ。
今どきのコーディングアシスタントはzero-shotでも拡張可能で保守しやすいコードを書けるのに、実際にそう頼んでみたことがあるのかと聞きたい。
人間も結局はtrial and errorで答えを探し続けている点では同じだ。
経験が多いほど頭の中でのシミュレーションの程度が違うだけだ。
カーボンフットプリントを問題にするなら、AIデータセンターが再生可能エネルギーで動けばそれでいいのか、という見方もある。
AIをワークフローにより効果的に統合する方法を見つける必要があると思う。
積極的にAIを導入してきた人たちは似た悩みを抱えているはずだが、まだ確かな解決策はない。
この段階では、AIに最小限の役割だけを正確に割り当てるのが重要だと思う。
たとえば株式リサーチに使うエージェントワークフローとして、「Bullish Guy」と「Bearish Guy」という2つのAIを作り、1つの銘柄について長所と短所を議論させる。
こうして互いに反対の立場で調査させると、より包括的で深みのある分析結果が出てくる。
このアイデアは、実際にソーシャルメディアで論争している様子を見て思いついたものだ。
vibe-codingでは、成果物が自己参照的な話以上のものになることはあまりなく、結局は3Dプリンティングの後継となる高価な趣味、そして延々とおもちゃを作り続ける活動のように見える。
最近のvibe codingで「benchy」のように使われる例は、todoアプリ程度ではないかと思う。
製品を自分で設計したりエンジニアリングしたりする人なら、みんな使っている。
一般消費者が活用しない唯一の理由は、必要なプラスチック製品のほぼすべてをAmazonですぐ注文できるからだ。
オンラインショッピングがない時代なら、平均的な人にとってずっと有用だっただろう。
今後は、カスタムファイルを自分で設計できる人にとってだけ、本当に必要な技術になるのかもしれない。