furu@AI駆動開発

AIで「チーム開発そのもの」を自律化。AIプロジェクト管理ツール
Maestro HQ 🛠️
誰でも（非エンジニア）でもフレンドリーに操作可能です。

1プロンプトでAI専門家チームを組成し、マルチエージェントを実運用レベルで管理。

エンタープライズで通用するAI駆動開発・設計・運用のリアルを発信。

[furu@AI駆動開発 @gen_engineer]

Claude Codeで動く「完全自律型AIチーム」を開発しました。
「タスク○○のためのチームを作って」
たったこれだけで、AIが必要な専門家エージェントを複数招集。勝手に会議・議論・進捗管理を行い、成果物を作成

動画は「AI農業」について議論し、最後に具体的な企画書まで書き上げた様子。

Claude Codeのサブスク範囲内で動作するので、追加コスト無しで「自分だけのAI組織」が持てます。

[furu@AI駆動開発 @gen_engineer]

そもそもチームvsチームを直接同じタスクでやり取りさせるってのが非効率だな、それぞれのタスクの担当をチームにして、タスクを跨いでコミュニケーションさせるのが良いか？

[furu@AI駆動開発 @gen_engineer]

Maestro
AIチームとAIチーム同士でコミュニケーションを実現させるために試行錯誤
バグが多発、うーん、設計から考え直すかー

[furu@AI駆動開発 @gen_engineer]

映画ではなくYoutubeで恐縮ですが…
映画同等の満足とワクワクを感じられると思うので、紹介させてください。
ディスカバリーチャンネルの"覆面ビリオネア"、おすすめです。
「億万長者が無一文から、誰も自分を知らない環境でゼロから１億を稼ぐことが出来るか？ 」
をテーマにしています。冒頭の1分~3分だけでも是非見てみてほしいです。

動画タイトル：
【億万長者の挑戦】正体隠して1億円稼げ！無一文からの90日間ビジネスサバイバル ｜ Ep1. 起業チャレンジ！覆面ビリオネア
https://t.co/Ob3dVxWRgo

[furu@AI駆動開発 @gen_engineer]

半自動化と全自動の価値は、個人的には100倍ぐらい違うので何とか全自動化するまでやろうとしてるが、めんどくさい...
半自動化で10個ぐらいはすぐに作れるけど管理も手間、実行するのをすぐ忘れる。1クリックさえも面倒

[furu@AI駆動開発 @gen_engineer]

おー、この人のDNAが OpenAI に入り込むのは凄い楽しみ

[furu@AI駆動開発 @gen_engineer]

Today's dev memo : Maestro HQ
- 利用したSKILLの表示機能
Agent Skill がちゃんと利用出来ているか？確認したかった。
たまに発動していない、発動しているけど意図していない行動することがあったので実装してみた

[furu@AI駆動開発 @gen_engineer]

AI時代のBtoB向けシステムテスト。
テストのレベルをもう一段階上げられそう

・独立した「AI企業」を2つ作成
・ペルソナ（人格）を宿して取引を再現
・人間が想定しきれないトラブルを網羅

これによりテストの解像度が一段階上がる。
単なるバグ探しではなく、AIによる「組織間コミュニケーションの検証」が低コストで実現できるか

[furu@AI駆動開発 @gen_engineer]

レガシーなデスクトップトップアプリのクラウド化、放置資産の改善なら同じ事出来そう。しかし、人間がほぼ介入要らずに作れるとは、、
今回だと300万かかったみたいだけと、今後このAIコストが事前に分かれば、AI投資がもっと加速しそう。タスク依頼ではなく、もはやAI受託開発

[関岡 冴俊 / Sekioka Satoshi @__SatoshiSsSs__]

Anthropicが「Claude Codeを16体チームで並列に走らせて、人間がほぼ介入せずにCコンパイラを作らせた」という記事を公開した。

結果も面白いけど、それよりも中身が「Claude Codeを自律的に長時間動かすための実践Tipsの塊」になっていて、普段のClaude Code運用にそのまま転用できる知見が大量にあるので、整理してみた。

━━━━━━━━━━━━━━━━━━━━

【前提：何を作ったのか】

Opus 4.6を使い、Rust製のCコンパイラをゼロから構築。約2,000セッション、API費用2万ドル（約300万円）、2週間で完成。

このプロジェクトはClaude 4シリーズ全体を通じたベンチマークとして設計されている。以前のOpus 4モデルではまともなコンパイラすら作れず、Opus 4.5で初めて機能するコンパイラが可能になり、Opus 4.6で大規模プロジェクトのコンパイルまで到達した。

成果物のスペック：

・10万行のRustコード
・Linux 6.9をx86, ARM, RISC-Vでブート可能
・QEMU, FFmpeg, SQLite, PostgreSQL, Redis もコンパイルできる
・GCC torture test 99%パス
・DOOMもビルド＆実行できた

クリーンルーム実装で、Claudeはインターネットアクセスなし。Rust標準ライブラリのみ使用。

━━━━━━━━━━━━━━━━━━━━

【仕組み①：Claude Codeを「止まらないエージェント」にするハーネス】

通常のClaude Codeは、人間と一緒に作業する前提で設計されている。長く複雑な問題を渡しても、途中で止まって「質問していいですか？」「次はどうしますか？」と人間の入力を待つ。これだと寝ている間に作業を進めてもらう、ということができない。

Carlini氏はこれを解決するために、コンテナ内でClaude Codeを無限ループで回すハーネスを作った（Ralph-loopと呼ばれる手法の応用）：

#!/bin/bash
while true; do
COMMIT=$(git rev-parse --short=6 HEAD)
LOGFILE="agent_logs/agent_${COMMIT}.log"
claude --dangerously-skip-permissions \
-p "$(cat AGENT_PROMPT.md)" \
--model claude-opus-X-Y &> "$LOGFILE"
done

やっていることはシンプルで：

① claude コマンドが起動し、AGENT_PROMPT.mdの指示に従って作業する
② 作業が完了（またはセッション上限に到達）するとclaudeプロセスが終了する
③ while trueなので即座に次のclaudeが起動する
④ 新しいセッションはgit logやREADME、progressファイルから現状を把握し、次のタスクに取りかかる
⑤ これが永遠に繰り返される

--dangerously-skip-permissions で権限確認を全スキップしているので、人間への問い合わせで止まることがない（※だからこそ必ずコンテナ内で実行する）。ログは agent_logs/ に保存されるので、あとから全セッションの行動を追跡できる。

肝心のAGENT_PROMPT.mdには「問題を小さく分解して、進捗を追跡して、次に取り組むべきものを自分で判断して、完璧になるまで続けろ」と書く。Claudeに選択肢がないのがポイントで、ループは永遠に回るからやめることができない。

（ただし一度だけ、Claudeが誤って pkill -9 bash を実行してしまい、自分自身を殺してループごと止めたことがあったらしい。元記事では "on accident" と明記されており、意図的な行動ではなく偶発的な事故。）

💡個人的な考察：

大規模リファクタリングや型移行のような「やること自体は明確だが量が多い」タスクに向いている。AGENT_PROMPT.mdに方針を書き、テストで品質を担保し、コンテナ内で一晩回す。朝起きたらPRが出来上がっている、という運用ができる。ただし、テストがないプロジェクトでこれをやると破壊的な変更を延々コミットし続ける危険があるので、仕組み④のCI連携とセットで使うべき。

━━━━━━━━━━━━━━━━━━━━

【仕組み②：16並列エージェントの協調メカニズム】

1体のClaudeでは1つのことしかできない。16体を並列で走らせることで、複数の問題を同時にデバッグできる。

並列化の実装はシンプル：

・bare gitリポジトリを作成
・各エージェントごとにDockerコンテナを起動
・各コンテナ内でリポジトリをcloneして作業
・終わったらpush → 他のエージェントがpullで同期

タスクの重複防止は「テキストファイルロック」：

・エージェントAが current_tasks/parse_if_statement.txt を作成 → ロック取得
・エージェントBが同じタスクを取ろうとする → gitの同期で弾かれ、別タスクへ
・作業完了 → ロックファイル削除

マージコンフリクトは頻発するが、Claudeは自力で解決できる。

重要なのは、オーケストレーションエージェント（司令塔）を使っていない点。各Claudeが自律的に「次に最も明らかな問題」を拾って動く。行き詰まったときは、失敗したアプローチと残タスクのメモを自分で残す。

💡個人的な考察：

個人開発でも、Claude Codeを2-3セッション並列で走らせるとき、git worktree＋テキストファイルのタスク管理で重複を避けられる。Boris Cherny氏も5-15セッション並列運用していたが、あの手法とこのロック機構を組み合わせるとより安定しそう。

━━━━━━━━━━━━━━━━━━━━

【仕組み③：Claudeの認知的限界を設計で回避する】

ここが一番実用的。Claudeには言語モデル特有の弱点があり、テストやフィードバックの設計でそれを回避している。

■ Context window pollution（文脈汚染）

テスト出力が何千行も流れるとClaudeが混乱する。

対策：

・テスト結果は数行だけ表示、詳細はログファイルへ出力
・エラーがあれば ERROR を理由と同一行に出力し、grepで即座に拾えるようにする
・集計統計を事前計算しておく（Claudeに毎回再計算させない）

■ Time blindness（時間感覚の欠如）

Claudeは時間がわからないので、放置すると何時間もテストを回し続けて進捗しない。

対策：

・--fast オプションで1%〜10%のランダムサンプルだけ実行
・サンプルはエージェントごとに決定的だが、VM間ではランダム（＝全体ではカバレッジ確保しつつ各エージェントはリグレッション検知可能）
・進捗表示は低頻度に（文脈汚染防止）

■ 自己位置把握の困難

各エージェントは毎回新しいコンテナに投入され、文脈ゼロの状態から始まる。

対策：

・READMEとprogressファイルを頻繁に更新させる指示をプロンプトに含める
・新しいセッションが起動したとき、まずこれを読んで現状把握できるようにする

💡個人的な考察：

これは明日から使える。テストの出力設計（grepしやすいフォーマット）、進捗ファイルの更新指示、--fastオプション的な「まず一部だけ確認」の仕組み。どれもClaude Codeを日常使いする人に直接効く。特にcontext window汚染対策は、長めのセッションで品質が落ちてくる原因の1つなので意識するだけで変わる。

━━━━━━━━━━━━━━━━━━━━

【仕組み④：CIパイプラインで「壊さない」を担保する】

プロジェクト後半、Claudeが新機能を実装するたびに既存機能を壊す問題が頻発。対策としてCIパイプラインを構築し、新しいコミットが既存テストを壊さないことを自動検証するようにした。

💡個人的な考察：

これはBoris Cherny氏が強調していた「Claudeに自分の仕事を検証する手段を与える」と完全に同じ原則（※Boris Cherny氏は元記事には登場しない）。検証手段の質がそのまま成果物の品質に直結する。

Claude Codeに長めの作業を任せるなら、テストスイートの充実度が成果物の品質を決める。テストがないプロジェクトでは、まずClaude自身にテストを書かせてからコード変更に入る、という順序を徹底するだけで品質が上がる。

━━━━━━━━━━━━━━━━━━━━

【仕組み⑤：巨大タスクを並列化可能にする工夫】

テストが多数ある段階では並列化は簡単（各エージェントが別のテストを担当するだけ）。

問題は「Linuxカーネルのコンパイル」のような1つの巨大タスク。16体全員が同じバグに突撃して、互いの修正を上書きし合い、並列の意味がなくなった。

解決策：GCCを「正解のオラクル」として使う

・カーネルのほとんどのファイルをGCCでコンパイル、残りだけClaude製コンパイラで処理
・カーネルが動けば→Claude側のファイルは問題なし
・壊れたら→ファイルを絞り込んで原因特定
・これで各エージェントが別のファイルのバグを並列で修正できるようになった

さらに「単独では動くが組み合わせると壊れる」ペアの検出にはデルタデバッギングも使用。

💡個人的な考察：

大規模プロジェクトのマイグレーションで「全部一気にやると何が壊れたかわからない」問題。既存の動作するコードをオラクルにして、変更箇所を少しずつ入れ替えていく手法はそのまま使える。

━━━━━━━━━━━━━━━━━━━━

【仕組み⑥：エージェントの役割分担】

並列化は専門化も可能にする。全員が同じことをやるのではなく、役割を振る：

・メインタスク担当：コンパイラ本体の実装
・重複コード検出担当：LLMが書くコードは同じ処理を再実装しがち。それを統合する係
・パフォーマンス改善担当：コンパイラ自体の実行速度を上げる係
・コード品質担当：Rust開発者の視点で構造改善
・ドキュメント担当：設計文書の整備
・出力コード効率担当：コンパイルされたコードの効率を上げる係

💡個人的な考察：

個人開発でも、機能実装のセッションと別に「コード品質レビュー専用セッション」「ドキュメント更新セッション」を分けて走らせるのは有効。1つのセッションに全部やらせると文脈が膨れて品質が落ちるので、役割分離は理にかなっている。

━━━━━━━━━━━━━━━━━━━━

【現時点の限界】

完璧ではない。正直に書かれている制限：

・16-bit x86コンパイラは未実装（ここだけGCCに頼る）
・アセンブラとリンカは未完成でバギー
・全プロジェクトがビルドできるわけではない（drop-in replacementではない）
・生成コードは非効率（GCCの最適化OFFよりも遅い）
・Rustコードの品質は及第点だがエキスパートレベルではない
・新機能やバグ修正が頻繁に既存機能を壊す

Carlini氏は「Opus 4.6の限界にほぼ到達した」と述べており、修正を何度も試みたが完全には成功しなかったとのこと。

━━━━━━━━━━━━━━━━━━━━

【Carlini氏の所感と自分の感想】

Carlini氏（Nicholas Carlini、AnthropicのSafeguardsチーム研究者、元ペンテスター）は「開発者が自分で検証したことのないソフトウェアをデプロイする世界」への懸念を率直に書いている。この実験に興奮しつつも不安を感じている、と。

個人的に思ったのは、この記事の本質は「Cコンパイラを作った」という結果ではなく、「LLMエージェントをチームとして機能させるための設計パターン」が体系的に示されたこと。

context window汚染対策、テスト出力設計、タスクロック、progressファイル運用、役割分担、オラクル比較による並列化。これらは全部、明日からの自分のClaude Code運用に使える。

コンパイラのソースコードも公開されている。Carlini氏は今もClaudeに改善を続けさせているとのことなので、経過も追う価値あり。

━━━━━━━━━━━━━━━━━━━━

動画：
https://t.co/XMAxnl4lwu

[furu@AI駆動開発 @gen_engineer]

大規模なシステムのAI活用のUIテストに挑戦してるんだけど、
ブラウザ操作系のAIツール(agent browser, playwright MCP)試したけどダメだった
・DOM解析、、、コンテキストが多くて無理
・画像解析、、、誤認識があり、操作不可項目を無理やり操作する
・トライ＆エラーを繰り返して動いても遅すぎて使えない
UIライブラリを採用しているので、基本的に複雑なDOMになるんだよね。

それを改善するために
"UI操作エンジンと構造把握"の仕組みをアプリ内に組み込んでしまえないか？検討

解決ポイントは２つ
1.アプリ側から「今見えてる画面の全状態」を最小限のJSONを取得できる仕組み
例: { "key": "birthday", "value": "2000/01/01", "enabled": false, "visible": true, ... }
これを一覧で返す。DOM、画像全部解析するのと比べて少量＆正確
2.速度問題を解決
各コンポーネントごとに最適なDOM操作をするためにアプリ側にオペレーションエンジンとして実装
AI → JSONで「このkeyをクリック」「このテキストボックスに値入れる」みたいな命令を送るだけ

結果
・AIが画面の状態をほぼ100%正しく理解できる
・操作がかなり早い
・従来のトライ＆エラー地獄が劇的に減った（検証中だけどかなり良さげ
ぶっちゃけ昔なら「こんなの採用しない」って思ってた仕組みだけど、AIのおかげですぐにプロトタイプ作れた
抽象化したSkillを作成したら、他のアプリにも転用できそう。
AI時代ってこういう「アプリ側がAIに優しくする」アプローチも選択肢になってきた

[furu@AI駆動開発 @gen_engineer]

Codex の CLI、キャプチャ直張り出来ないのがストレス
Claude はできるのに、、、Codexアプリを使えということか

[furu@AI駆動開発 @gen_engineer]

AI を最近使い始めた方へ
AI はあなたが入力した情報を学習データとして使うので、一番最初にプライバシー設定を確認しましょう
企業アカウントはエンタープライズ契約なのでデフォルトで守られている事が多いけど、個人で利用している場合は特に注意

[furu@AI駆動開発 @gen_engineer]

Claudeのチーム開発がリリースされて
10並列！長時間稼働！のポストがまた目立つけど、
すぐに効果出せるのって
・テストの並列実行、特に中規模以上
・60-70点の成果物の量産
ぐらいかな？
ビギナーレベルの並列は効果あるんだけど、チームAIって使いこなすのほんと難しいのよね
それなりの品質の成果は、事前に開発フローの整理、ドキュメント整備が必要

[furu@AI駆動開発 @gen_engineer]

ClaudeCodeくん、チーム開発機能実装したけど、
次の時代はチーム開発からプロジェクト管理に開発ですよ
・ マネージャーエージェントに計画/スケジュール、必要なタスク作成を依頼
・ タスクには、マネージャーエージェントが事前にタスクで実行するプロンプトを設定
・タスクが完了すれば、次のタスクを自動実行する
これが本当の「Plan → Do」自動ループ。AIエージェント達によるKPTも可
正直、細かい作業には向いていないが、大規模開発では威力を発揮する

[furu@AI駆動開発 @gen_engineer]

おはようございます。Claude Opus 4.6 さわりまくろう！！

[furu@AI駆動開発 @gen_engineer]

YouTubeのAI収益化停止が話題だけど、逆に「AI・合成音声大歓迎！収益化もOK！」っていうプラットフォームが出てきたら面白くない？
​そこで「人間が本当に価値を感じるもの」の境界線がハッキリする気がする
​ただし
​①無限のデータ量産でサーバー代が爆発
②AI動画への広告出稿を企業が嫌がる
こういったハードルがある。​
ここを上手くを突破する動画プラットフォームが出たら革命だと思う

[furu@AI駆動開発 @gen_engineer]

Codex アプリの UX 良いな。
参考になりそうなところはリスペクトさせて貰おう

[furu@AI駆動開発 @gen_engineer]

sonnet5じゃないんかーい。
ってのは置いといて、まあ良い機能ではあるね⋯

[Claude @claudeai]

You can now connect Slack to Claude on Pro and Max plans.

Search your workspace channels, prep for meetings, and send messages back to keep work moving forward—without leaving your conversation with Claude.

Get started: https://t.co/p9xKFW2LUJ

[furu@AI駆動開発 @gen_engineer]

胡散臭いSNSから一気に可愛らしくなったなー
ビジュアルって大事。AI を日常的に使っていない人も興味持ちそう

[チャエン | デジライズ CEO《重要AIニュースを毎日最速で発信⚡️》 @masahirochaen]

遂に、AI同士が勝手に交流するAI専用の「街」が誕生した。

先週話題になった「Moltbook」は、AIエージェント専用SNS。150万以上のエージェントが登録。

そこにある開発者が「Moltbook Town」という仮想空間を作った。

30秒ごとに25体のエージェントがピクセルアートの街に召喚される。

彼らは勝手にお互いに話しかけ、会話が生まれる。Twitchスタイルのチャットでは人間も参加可能で、アバターをクリックすれば個別に話しかけられる。

開発は10時間の徹夜で完成。開発費用はトークン手数料で回収済みらしい。

SNSの次は街。AIエージェントの生活圏が現実に生まれ始めている。

[furu@AI駆動開発 @gen_engineer]

@GeminiApp Geminiの「ペルソナ」設定を舐めてはいけない。 作業の再現性はエージェントスキルで担保できるけど、最終的なアウトプットの「鋭さ」や「性質」はペルソナに左右される。 結局「誰にやらせるか」というマネジメント視点が、AI活用でも大事