「結局、自分が一番のボトルネックだった」
ある海外の開発者が、こんな告白をしていました。
半年間Claude Codeで個人開発を続けてきた人物の言葉です。
本記事は、Redditで公開されたこの投稿が題材です。
そして、そこに寄せられた議論も併せて整理します。
投稿者の体験には、興味深いポイントが詰まっています。
AIを業務に取り入れている人なら、誰もが頷く内容です。
さらに、コメント欄での冷静な批判や別解の提示も示唆に富みます。
順に見ていきましょう。
投稿者が直面した「本当のボトルネック」
この開発者は、半年にわたりClaude Codeを使い続けてきました。
自分のプロダクトを出荷し、コンテンツ運用やローンチ業務まで手がけてきたそうです。
ところが、うまく回らない原因は意外なところにありました。
AIの性能ではなかったのです。
人間側の運用が問題でした。
具体的にはこうです。
調査結果をライターに渡す。
書いたものをレビュー担当に流す。
コードを書かせて、レビューに回す。
こうした受け渡しの度に、開発者本人がセッション間でコンテキストをコピー＆ペーストしていました。
つまり、自分自身がAIチームの「ディスパッチャー」になっていたのです。
最初に試したのは、別の既存ツールでした。
役割分担の概念は良かったものの、結局はスラッシュコマンドを順番に叩き続ける必要があったといいます。
「office-hours」「plan-eng-review」「review」「ship」と、毎ステップで指示を出すのは人間でした。
9体のエージェントによる体制づくり
そこで開発者は、週末を使ってワークフローを移植します。
新しく組んだ体制は2部門編成です。
エンジニアリングとコンテンツ生成で、計9体のエージェントが配置されました。
エンジニアリング部門は4体で構成されています。
- arch：アーキテクチャ上の意思決定を担当。コード着手前に変更案をレビューする。「『10倍規模で何が壊れるか』を最初に問う上級エンジニア」という人格を与えられている
- backend：APIとサービス層を担当。archのGOサインが出てから実装に入る
- frontend：Web部分を担当。バックエンド側でAPI仕様が固まったタイミングで作業を引き継ぐ
- review：あらゆるPRを人間より先に読む役。雑な変更を捕捉してくれる
コンテンツ／グロース部門は5体です。
- research：MCP経由でキーワードや市場機会を分析する。分析結果は戦略担当に引き渡される
- strategist：リサーチを読み込み、キャンペーンの企画書を書く。コピー本文には手を出さず、切り口の設計に専念する
- writer：戦略担当の指示を受けてブログ記事を起草。過去の修正履歴をメモリとして参照し、同じミスを避けてくれる
- editor：事実確認と語り口の調整を担当。ブランドのスタイルガイドをメモリに保持している
- SEO：完成原稿にメタデータを付与。ブログ用に構造化する
何が変わったのか：エージェント同士の直接対話
この体制で決定的に変わった点があります。
エージェント間の直接コミュニケーションです。
バックエンドがAPI変更を出荷するとします。
すると、フロントエンドに直接メッセージが飛びます。
ライターが下書きを完成させると、エディタに通知が届く仕組みです。
archが変更をブロックする場合はどうでしょう。
チャット上で理由が説明され、バックエンドが調整に入ります。
これらのやり取りはキャンバス上で可視化されています。
開発者は会話の流れを見守るだけになりました。
「魂」「目的」「記憶」を各エージェントに持たせる
投稿者が特に効果を実感した点があります。
各エージェントに永続的なSoul（人格）、Purpose（目的）、Memory（記憶）を持たせた点でした。
3週間ほど使い込むと、変化が現れたといいます。
editorは自社の文体を覚え込んでくれました。
archも、先月決めたキャッシュ方針を忘れていません。
加えて、ナレッジベースが自動で蓄積される設計でした。
戦略担当は過去の好調記事のパターンを記憶しており、それを踏まえてブリーフィングを書きます。
利用したツールはPentagonというサービスです。
投稿者は約3〜4週間使った段階で、満足度はおよそ80%だと述べていました。
コミュニティの冷ややかな反応：「マネージャーAIを増やせばいい」
ここで興味深いのが、コメント欄の反応です。
最も上位に来たコメントは、皮肉めいた一言でした。
「マネージャーエージェントを追加すればいい、当たり前だろ」というものです。
その下に付いたリプライがさらに鋭い。
「マネージャーがちゃんと働かなかったら、マネージャーのマネージャーを足せばいい」
これは単なるジョークではありません。
多エージェント構成が抱える本質的な課題を、笑い飛ばす指摘でした。
階層を増やしても、問題は解消しない。
そんなメッセージが込められています。
実際にマネージャー型を試した別のコメント投稿者は、こう打ち明けていました。
マネージャー役は長時間動かす間に厳格なルールを守る必要がある。
けれど、コンテキストが他の情報で埋まっていく。
そして、忘れっぽくなってしまう。
最終的には、管理処理をサーバーに書き出すことになる。
考える必要のない処理なので、不安定なうえにトークンの無駄になる──というのです。
「管理こそが本当の難題」という指摘
多くの支持を獲得したコメントも示唆に富む内容でした。
自分も同じものを何度も作ってきた。 けれど、本当の問題は常に『管理』にある。 チーム編成は速く組めるが、各エージェントが自律的にきちんと仕事をこなしているかを担保することこそが、本物の課題だ
これに対して、投稿者本人が回答しています。
Purpose（目的）とSoul（魂）の定義ファイルを手書きで全部書き下ろした、と。
そして、何度も微調整を繰り返したとも述べています。
出力品質80%という数字は、その試行錯誤の結果でした。
別の参加者の表現が印象的です。
エージェント間の協調レイヤを組み、人間がループに残るべき20%がどこなのかを把握しておく。 それが今の業界の到達点なんだ
別解：「AIをAIで解決するのではなく、手続き的なコードで縛る」
もうひとつ、本質的な対立軸を提示したコメントがありました。
「あなたはAIの問題を、さらに多くのAIで解こうとしている。私は同じ問題を、手続き的なコードで解いている」
この投稿者の主張はこうです。
エージェント同士の対話を洗練させるのが正解ではない、と。
むしろ、特定の手順を強制する「ハーネス（拘束具）」のような層を入れる方が効果的だ、という立場でした。
エージェントが自由に会話して脱線するリスクは無視できません。
それを構造化された受け渡しと中間生成物で縛り上げる。
そういうアプローチです。
正解はひとつではありません。
「自由に話させる」派と「手続きで縛る」派は、それぞれの現場で異なる最適解を見出しています。
この事例から読み取れること
海外コミュニティのこの議論から、いくつかの実用的な視点が得られます。
第一に、AIワークフローの真のボトルネックは、しばしば人間側の運用に潜んでいます。
エージェントの性能が問題ではないのです。
コンテキストの受け渡し作業が積み重なり、生産性を蝕んでいきます。
第二に、エージェント間メッセージングは生産性を押し上げる可能性を秘めています。
ただし、銀の弾丸ではありません。
第三に、各エージェントに人格と目的、記憶を与える設計には時間がかかります。
投稿者も認めていました。
「Soul/Purposeのドキュメント調整に最も長い時間を費やした」と。
第四に、満足度80%という数字をどう捉えるかです。
残り20%は人間が介在すべき領域だと割り切る。
それとも、もう一段の自動化を追求するか。
これは現場の判断に委ねられます。
まとめ
9体のエージェントが互いに会話する開発チーム──聞くと近未来的に響きます。
けれど、現実には地味で泥臭い調整作業の積み重ねでした。
この投稿が示しているのは、シンプルな物語ではありません。
ツールを揃えれば自動化が完成する、というほど甘くないのです。
エージェントの人格設計、メモリ運用、人間が介入すべき境界の見極め。
これら全てを地道に詰めた人だけが、80%の自動化に辿り着いています。
そして、忘れてはならない視点があります。
コメント欄の冷静な指摘です。
「マネージャーを増やせば解決」というジョークは、安易な階層化への警告でもありました。
「管理こそが本当の難題」という言葉も心に留めておきたいところです。
手続き的なコードで縛る別解も、検討に値する選択肢のひとつでしょう。
AIエージェントの導入を考えている方へ。
ツール選びの前に、まず自分の業務フローを観察してみてください。
どこで人間が「ディスパッチャー」になっているか。
そこにこそ、自動化で最大の効果が得られる領域が眠っています。
