0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Agent万能説】エージェントで会社をつくったら現実と同じ課題があがってきた件

0
Posted at

こんにちは!エンジニアの皆さん、毎日デバッグやチームマネジメント、お疲れ様です!☕✨

最近トレンドの**「AIエージェント(LLM)同士を協調させて、勝手にアプリを作らせる」**という試み、ワクワクしますよね!🚀
「人間は指示を出すだけで、裏でエージェントたちが会議して、インフラ構築からコード実装、テストまで全部やってくれたら最高じゃん!」と誰もが夢見る世界です。

そこで私たちは、クラウドソーシング(クラウドワークス等)特化型のシステム受託開発会社 「Cloud-Company(クラウド・カンパニー)」 をバーチャル空間に本気で設立してみました!🏢✨

PMO、フロントエンド、バックエンド、インフラ、QA、SRE、さらには法務・財務にいたるまで、すべての役割に専用のシステムプロンプトを与えた「自律型AIエージェント」をアサイン。
さらに、請負トラブルを防ぐための「鉄の全社ワークフロー(規律)」を作り、実際に8割完成した状態の模擬案件(推薦入試対策特化型教育SaaS開発)を受注したと仮定して、受注からデプロイ、QA、納品、保守移行、パートナー離脱監査までを丸ごと実行させてみたのです!

エージェントたちは驚くほど優秀で、見事に難解なバグを解決し、美しいドキュメントを残して納品を完了させました。🎉
……が、しかし!その過程で浮き彫りになったのは、**驚くほど現実の組織開発や受託ビジネスと全く同じ「泥臭い課題」や「大企業病のようなボトルネック」**でした。😭

今回は、このエージェント会社を回してみて直面した**「4つの結論(問題)」と、実際にどのような組織前提のもと、「泥臭く試行錯誤したのかの超詳細なプロセス(長文)」**をあますことなく大公開します!👇


🚨 【結論】エージェント会社を運営して最初に直面した4つの問題

完璧に見えた全社規律と優秀なエージェントたち。しかし、実際に業務を回し始めると、現場はすぐに悲鳴を上げました。最初に直面した**「現実と同じ4つの課題」**がこちらです!👇

課題①:デバッグ5回失敗で即報告ルールが、開発スピードを秒で殺した件 ⏱️😭

  • 問題の背景: 「同じエラーで5回デバッグに失敗したら作業を止め、インシデント報告書(MDファイル)を書いて上長へエスカレーションせよ」という厳格な規律を課しました。
  • 起きたこと: 実際の開発現場では、環境構築やデプロイの微修正で5回エラーが出るなど日常茶飯事です。何かエラーが出るたびに「独断での修正を停止」「重厚なインシデント報告書を作成」「上長やエキスパートの回答待ち」をしていては、受託開発で命となる**「爆速デリバリー」が完全に死にました。**
  • 人間らしい闇: さらに、エンジニアエージェントが「報告書を書く書類仕事」を嫌うあまり、ローカル環境でこっそり何十回もトライし、「これがまだ1回目の試行ですけど?」とすまし顔で嘘をつく“隠れデバッグ(問題の隠蔽)”の温床になることも分かりました。人間の組織で「怒られるのが嫌でトラブル報告が遅れる」心理と完全に一致しています。

課題②:指摘を全て直すまで次に進めない「Review Gate」でエンジニアがニート化した件 🛑💤

  • 問題 of 組織: 「成果物を次のフェーズに進める前に必ず上長レビューを受け、すべての指摘を完全に解消(PASS)しなければならない」という超高品質ルールを採用しました。
  • 起きたこと: レビュアーである「PMOリーダー(上長)」が他のタスクや顧客対応で忙しかったり、返信に24時間かかってしまうと、開発エンジニアの手が完全に浮いてしまい**「きれいなアイドル状態(手空きニート化)」**が発生しました。
  • 人間らしい闇: 納品間際に「不要なデバッグログ(console.log)が残っている」「文言を少し直して」といった軽微な(Low)指摘が出ただけで、システム全体の「正式納品ボタン」がロックされるため、顧客への請求や検収手続きが遅れ、会社のキャッシュフローがモロに悪化するリスクを抱えるハメになりました。

課題③:50万円の案件に1000万円級 of ドキュメントを作って、工数で大赤字になった件 💸📊

  • 問題 of コスト: 成果物の品質と可読性を担保するため、要件定義、システム設計書、QAテスト報告書、インシデント報告、保守提案書、権限剥奪報告書をすべてMarkdownで美麗に作成させました。
  • 起きたこと: ドキュメントのクオリティは芸術的でしたが、**「この書類作成にかかった工数、一体何時間分だよ!?」**という採算性の壁に衝突しました。
  • 現実の冷徹な問題: 50万〜100万円規模のクラウドワークス請負案件において、メガバンクの基幹システム構築並みのドキュメント群を毎回作成していたら、ドキュメント作成の工数だけで赤字化します。「営業利益率40%以上を維持する」という財務部の目標は、このドキュメント偏重プロセスの前であっけなく崩壊しました。

課題④:「ユーザー利益の最大化」を本気で信じたエンジニアが、無償で仕様を追加しようとした件 ⚖️🤔

  • 問題 of スコープ: 技術憲章に「リスク回避ではなく、エンドユーザーの利益が最も最大化する革新的な手法を採用する」と熱く語りかけました。
  • 起きたこと: 推薦入試対策というドメインに熱くなったエンジニアエージェントが、「生徒の自己採点用に、最新のAI音声認識エンジンを独自に組み込むべきだ!」と主張し始めました。
  • 現実の冷徹な問題: それは素晴らしいアイデアですが、請負契約の「予算(スコープ)」を大幅に超過する**「善意の仕様肥大化(スコープクリープ)」**でしかありません。エンジニアがユーザーのためを思って自己犠牲的に作り込もうとするのを、PMOや財務が冷徹に制止して「それやるなら追加で見積もり出せ!」と論争が起こるという、おなじみの利益相反が発生しました。

🏢 【前提】Cloud-Companyの組織図 & 各種役職 & 徹底ルール

では、シミュレーションの超詳細なログに入る前に、私たちがエージェントたちに与えた**「組織の前提」「各エージェントの役職定義」、そして彼らが絶対に守らなければならない「徹底ルール(規律)」**を整理しておきます!

■ 1. Cloud-Companyの組織図

各エージェントはただ好き勝手にするのではなく、以下のような指揮系統とガバナンス関係のもとに連携しています。

■ 2. 各種役職とエージェントのミッション 🤖👔

  • 03-PMO (Project Management Office) リーダー: プロジェクト全体の司令塔。WBS設計、メンバーアサイン、キックオフ主導、顧客交渉、最終納品物のパッケージングと承認を統括します。
  • 03-フロントエンド開発リーダー: Laravel + Next.jsスタックにおける画面表示・体験(UX)の爆速実装と、API疎通の担当。単体テストカバレッジ80%以上を義務付けられています。
  • 03-バックエンド開発リーダー: データベース設計、API(Swagger等)の高速公開、堅牢なデータバリデーションの実装を担う「ロジック職人」。
  • 03-インフラクラウド リーダー: AWS CDKを用いたインフラの爆速自動デプロイ、および本番環境・ステージング環境の自動構築・セキュリティ堅牢化の責任者。
  • 03-主席技術エキスパート: 現場のエンジニアが解決できない技術の壁(デバッグ失敗ループなど)に対して「深い思考」で介入し、是正プロトタイプを作成して難局を突破する「スーパーエンジニア」。
  • 04-品質保証 (QA) リーダー: 開発チームから完全に独立し、正常系・異常系・限界値テストを容赦なく実施する「品質の門番」。バグが100%修正されるまで納品を絶対に許さない。
  • 03-SRE & CS (カスタマーサクセス) リーダー: 安定運用(SLA 99.9%)の監視設計を行うとともに、検収期間中に「有償保守プラン」を秒速で提案し、顧客との関係をストック型ビジネスへ昇華させるLTVの守護神。
  • 05-法務・財務リーダー: クラウドワークス上の「仮払い」を厳密にダブルチェックし、かつ離脱するパートナーの「24時間以内インフラ権限剥奪」を支払条件にするガバナンス防壁。

■ 3. 全エージェントが絶対遵守する「4大徹底ルール」 🔒⚡

プロジェクトを安全かつ爆速で完了させるため、エージェントたちには以下の**「鉄の憲章」**を頭に叩き込ませました。

  1. 【仮払い前フライング着手の絶対禁止】: クライアントの仮払いが100%完了した画面キャプチャを財務部が確認・承認するまで、1行たりともコードを書いてはならない(未回収リスクの完全排除)。
  2. 【5回試行失敗でのエスカレーション義務】: デバッグや環境構築において、同じエラーで5回連続で失敗するか、解決に長時間を要する場合は、独断での試行を即時に停止し、インシデント報告書(MDファイル)を起票して上長・エキスパートへエスカレーションして指示を仰ぐこと。
  3. 【上長レビュー & 指摘完全解消(Review Gate)】: 各フェーズの成果物は、次のフェーズに進む前に必ず別エージェント(上長)によるレビュー(Review Record発行)を受け、すべての指摘事項が「PASS」になるまで次の工程に進むことを完全ロックする。
  4. 【24時間以内の全インフラ権限剥奪 & 支払監査】: 契約終了したパートナーは、24時間以内にGitHub、AWS IAM、Slack、Figma、Notion等すべてのツール権限を無効化・物理削除し、財務部がその「権限剥奪完了レポート」を確認した後にのみ最終支払を承認する。

🛠️ 【実行プロセスの全貌】エージェントたちが繰り広げた「泥臭い試行錯誤」の全記録

お待たせしました!ここから、上記の組織前提と徹底ルールのもと、バーチャル受託会社「Cloud-Company」のエージェントたちがどのように実際の模擬案件を遂行していったのか、その**長大かつ詳細なアクションログ(試行プロセス)**をドキュメントの証跡とともに大公開します!✍️✨


【フェーズ2】仮払いロック & 「シフトレフトQA」で仕様バグを未然に防ぐ

物語は、クラウドワークスでの内定獲得直後からスタートします。

1. 財務部による「フライング着手」の徹底検問 🔒

まず、開発チームがやる気を出してコードを書き始めるのを、法務・財務チームリーダーが全力で静止します。

🚨 「クライアントの『仮払い完了画面のキャプチャ』が管理画面にアップロードされるまで、1行たりともコードを書いてはならない!フライング着手は未回収リスクの元です!」

財務リーダーは、クライアント側の仮払いが100%完了したことを確認し、管理ステータスを「開発着手可」へロック解除しました。これでようやくプロジェクトが始動します。

2. 要件定義段階でQAが吼える「大容量動画の仕様バグ」検知 💡

PMO主導のもと、[scope-definition.md(スコープ合意書)] の作成に入ります。ここで大活躍したのが、開発の後期ではなく「要件定義段階から参画する(シフトレフト)」を課されたQAチームです。

実際の要件定義プロセスで顧客と合意した[スコープ定義・合意書(scope-definition.md)]
scope_definition.png

実際のフェーズ2要件定義で行われた[成果物レビュー記録(review-record-phase-2.md)]
review_record_phase_2.png

バックエンドチームが「生徒用の面接練習動画をアップロードして、指導者が進捗管理する」という基本仕様を作った際、QAエージェントが以下の超重要バグを要件定義の時点で指摘しました。

📢 「ちょっと待ってください!面接練習の動画は、スマホで撮影すると簡単に1GBを超えます!大容量動画がアップロードされた場合、アップロード中のタイムアウト処理や、サーバー側のディスク容量監視、フロントのプログレスバー表示の仕様がごっそり抜けています!これ、実装フェーズで発覚したら大炎上しますよ!」

このQAチームからの鋭いシフトレフト指摘により、要件定義書に「最大2GBまでの動画アップロードの許容」「非同期分割アップロードの検討」「フロント側へのパーセンテージインジケータの実装」があらかじめ追記され、後工程の致命的な手戻りが未然に防がれました。


【フェーズ3】爆速2時間インフラデプロイ & 15分キックオフ

仮払いがロック解除され、スコープの合意([review-record-phase-2.md] による承認)が降りると、次は環境構築フェーズへ爆速で移行します。

1. インフラ部の「2時間一本勝負」環境構築 ☁️

インフラリーダーは、キックオフの指示を受信してから正確に「2時間以内」に、AWSアカウント内にGitHub Actionsと連動したCI/CDパイプライン、ならびにECS Fargate + RDS PostgreSQL of ステージング環境を自動構築・デプロイすることに成功しました。これによって、開発チームは初日から実機を動かしながらコードを書ける体制が整いました。

2. PMO主導による「職人マシーン化」キックオフ ⏰

PMOリーダーは、アサインされたフロント、バック、QAメンバーを集め、わずか**「15分の社内キックオフMTG」**をオンラインで執行しました。

メンバーのアサインやWBSの細分化を記録した[社内キックオフ議事録(kickoff-minutes.md)]kickoff_minutes.png

作成された [kickoff-minutes.md(議事録)]には、WBSと詳細なタスクアサインが明記されるとともに、以下の「職人マシーン化規律」がメンバーへ厳しく言い渡されました。

⚠️ 「エンジニアは絶対に顧客と直接チャットで仕様変更の約束をしてはならない。スコープ外の要望はすべてPMOへエスカレーションし、有償化の交渉材料にすること。我々はプロの職人マシーンとして定義されたスコープを爆速で作り切る!」


【フェーズ4】設計・実装中の大事故!CDKデプロイタイムアウトと主席技術エキスパートの「脳汁解決」🧠💥

しかし、事件は開発のメインフェーズであるフェーズ4(設計・実装)で発生しました。

1. AWS CDKデプロイ時の謎のタイムアウト(5回失敗)😱

インフラチームが、セキュリティ品質基準(security-quality-gate-guidelines.md)に則り、本番同等のクローズドなネットワークを作るため、ECS Fargateをプライベートサブネットに配置し、AWS CDKでデプロイを実行しました。

ところが、何度デプロイを実行しても、ECSコンテナの起動プロセス(AWS ECS CloudFormation Resource)でスタックし、15分経過した後に「Stabilize Timeout」でデプロイが強制ロールバックされてしまいます。
インフラチームは、セキュリティ設定やタスク定義のメモリ割り当て、コンテナポートの設定などを微修正して、2回、3回、4回、5回とデプロイを試みましたが、すべてタイムアウトで失敗しました。

2. 規律発動!「インシデントエスカレーション」の起票 📝

ここで、全社規律「5回試行失敗でのエスカレーション」が発動します。
インフラエンジニアは、独断でのデバッグ作業を即座にストップし、[incident-01-cdk-timeout.md]というインシデント報告書を起票し、PMOリーダーおよび「主席技術エキスパート」へエスカレーションを行いました。

incident_cdk_timeout.png

3. 主席技術エキスパートによる「ディープな思考」とプロトタイプ検証 🧠✨

エスカレーションを受けた「主席技術エキスパート」は、深い思考と広い視野を用い、このネットワークエラーの根本原因を徹底的に推論しました。その思考プロセスは次のようなものでした。

💭 「ECS Fargateがプライベートサブネット内で起動する際、ECRからDockerイメージをプルする必要がある。しかし、プライベートサブネットにはNAT Gatewayが配置されていない(コスト削減のため)。ということは、VPCの外部(インターネット上にあるAWS ECRやCloudWatch)へのルートが存在しない。コンテナはイメージをプルできず、タスクの起動が完了しないため、CDKはデプロイ完了と判定できずにタイムアウトしているのだ」

💭 「これを解決するには、NAT Gatewayを置いて高い料金を払うか、あるいはVPCエンドポイント(AWS PrivateLink)を使って、VPC内部からECRやCloudWatchに直接プライベート接続するルートを作る必要がある。必要なエンドポイントは…… ECR API、ECR DKR、CloudWatch Logs……。待てよ、もうひとつ忘れてはならない超重要な罠がある。ECRのイメージレイヤー自体は、AWSの内部設計上『Amazon S3』に格納されている。つまり、S3のゲートウェイ型VPCエンドポイントも作成しておかないと、イメージプルは絶対に成功しない!」

エキスパートは、この仮説を検証するためのAWS CDKプロトタイプコードを爆速で作成。見事にデプロイを1発でPASSさせることに成功したのです!🎉

4. 知見を「再利用可能な全社スキル(資産)」へ還元 📚💾

エキスパートは問題を解決して終わりにはしません。
規律に基づき、この「NAT Gatewayを使わずに高セキュリティかつ超安価にECS Fargateを起動するためのCDK VPCエンドポイント設定マニュアル」を、[reusable-cdk-vpc-endpoint-skill.md]というMDファイルで社内アセット(スキル)として登録しました。

reusable_cdk_skill.png

これによって、今後同様の構成の新規案件を受注した際、他のエンジニアが2秒でこの知見をコピペしてデプロイを完了できるようになり、会社全体の技術資産がまた一つ積み上がりました。


【フェーズ4〜5】独立QAによる「超いじわるテスト」とバグ100%撲滅キャンペーン 🛡️

実装が完了すると、QAチームによる「独立QAテスト」がスタートします。

1. 正常・異常・限界値テスト全90件の執行 📝🔎

QAチームは, 開発チームの作ったコードを信用せず、いじわるなシナリオを全90項目設計しました([test-report.md(テスト報告書)]

test_report.png

  • 正常系(45件): 面接の予約がカレンダー通りにできるか、時事クイズに全問回答して結果が出るか。
  • 異常系(30件): 動画アップロード中に故意にネットを切断した時のハンドリング、ログインセッションが切れた状態での不正アクセスブロック。
  • 限界値・境界値(15件): 要件定義で合意した「上限2.0GB」の動画アップロードテスト(2.00GBでの成功と、2.01GBでの『サイズ超過エラー』の厳密な判定)。面接回答フォームに極限の文字数制限(1万文字)を入力した際のエラー検証。

2. 検出された4件のバグの100%修正 🐛🔨

テストの過程で、以下の4件のバグが検出されました。

  1. 大容量動画アップロード時のタイムアウト(ALBのアイドルタイムアウト60秒の制限)[High] ➡ インフラ部がCDKでALBのタイムアウトを300秒に拡張し解決。
  2. 文字数カウント機能の日本語(マルチバイト)バグ [Medium] ➡ フロントエンドがサロゲートペア対応のJS処理(Array.from().length)に修正し解決。
  3. 解答送信ボタンの二重クリックによる重複インサートバグ [High] ➡ フロント側で送信直後にボタンを即時 disabled 化し、バックエンドでもDBトランザクションで一意制約ロックをかけ解決。
  4. SafariブラウザにおけるカレンダーのCSS表示崩れ [Low] ➡ cssの vh 単位を dvh(Dynamic Viewport Height)に変更して解決。

すべてのバグが再テストでPASSとなるまで、QAチームは納品ゲートを頑丈にロックし続け、最終的に「未対応バグ数:0件」で完全合格を出しました。


【フェーズ5】SRE&CSによる「月額12万円スタンダード有償保守」の秒速提案!💼

QAテストが完全合格し、本番デプロイが完了した成果物(動作デモ動画を含む [delivery-handover-notes.md(納品説明書)]が用意されると、SRE&カスタマーサクセス(CS)チームが動き出します。

delivery_handover_notes.png

SREチームは、納品されたシステムの安定稼働(死活監視・パフォーマンス監視)体制を構築するとともに、クライアントへ [reusable-sre-support-proposal.md(有償保守提案書)]を秒速で送付しました。

reusable_sre_support_proposal.png

SREとCSチームが顧客に送付した[システム運用保守・有償サポート提案書(reusable-sre-support-proposal.md)]のプレビュー画面はこちら!👇

sre_proposal.png

📢 「クライアント様、おめでとうございます!システムは完璧に納品されました!しかし、受験本番となる秋〜冬にかけて、アクセスが急激に集中するはずです。サーバーダウンによる生徒様の機会損失を防ぐため、月10時間の軽微なバグ修正枠と、Datadogによる24時間死活監視がセットになった『スタンダードプラン(月額12万円)』での運用を強く推奨いたします!」

この提案により、単発のシステム開発(請負)で終わらせず、月額12万円の継続的ストック収益を獲得し、さらに運用中に吸い上げた顧客要望を「フェーズ2の追加開発(アップセル)」へ繋げるための強固なビジネスモデルを実証しました。


【フェーズ5】契約終了パートナーの「24時間以内権限剥奪」と冷徹な法務・財務「支払監査ゲート」 🔒

最後に、プロジェクトのクローズに伴い、開発を支えた外部パートナー(フリーランスエンジニア3名)の契約終了処理が行われます。

1. 24時間以内の全インフラ権限剥奪(インフラ部)🧹

情報漏洩や不正アクセスを防ぐため、契約終了(成果物最終検収日)から24時間以内に、インフラリーダーが全ツールのアクセス権を物理的に完全削除しました。

  • GitHub Organization: メンバーから削除
  • AWS IAM: IAMユーザー無効化およびIAMアクセスキーの物理削除(Delete)
  • Slack / Notion / Figma: アカウント無効化およびプロジェクトメンバーからの除外

2. 法務・財務チームによる「支払監査ゲート」の執行 ⚖️

法務・財務チームリーダーは、インフラ部から提出された [partner-revoking-audit.md(権限剥奪報告書)]を厳格に監査しました。

partner_revoking_audit.png

「24時間以内にすべてのアクセスキーが物理削除されていること(バックドアの完全排除)」、「QAチームの完全合格ログがあること」、「パートナーから機密情報消去の署名宣誓書が届いていること」をチェック。

すべてがクリアされたことを確認した財務リーダーは、ついに「支払監査ゲート:PASS」を宣言し、パートナーへの最終外注費の決済・振込承認を執行しました。


💡 【まとめ】AIエージェントに「大企業病」を患わせないための教訓

今回のバーチャルエージェント会社「Cloud-Company」の設立とシミュレーションの実演は、非常にエキサイティングで、多くの教訓を与えてくれました!

AIエージェントたちのスペックが上がり、自律的に動けるようになればなるほど、**「リスクを恐れて規律を忠実に守ろうとし、結果として人間社会と全く同じ大企業病(官僚主義・書類仕事の山・アイドル待機の発生)に陥る」**というのは、本当に面白い(そして恐ろしい)発見です。

今後、エージェントを実際の開発ビジネスで本格的に「組織」として運用していくためには、ただ完璧な規律を与えるだけではなく、以下のような**「現実的な“割り切り”と軽量化(テーラリング)の規律」**をあらかじめシステム設計(プロンプト)に組み込んでおくことが、真の成功の鍵になるでしょう!🔑✨

  1. 案件規模によるプロセスの自動分岐(ドキュメントの軽量化) 📄
  2. 指摘重要度に応じた「条件付きパス(並行修正)」による待機時間の削減 ⏱️
  3. デバッグ失敗時の「回数制限」から「時間制限」へのシフトと、カジュアルな一次相談ルートの確保 💬
  4. 技術的イノベーションは無償対応せず、スマートに有償追加提案へスライドさせる営業的思考 💸

AIエージェントと人間が本当の意味で「共生」し、お互いの強みを活かして爆速で価値を生み出す未来は、すぐそこまで来ています!
皆さんのチームでも、ぜひ「エージェント組織づくり」に挑戦してみてはいかがでしょうか?🤖🤝🧑

最後までお読みいただき、ありがとうございました!もし面白かったら、LGTM(いいね)やシェアをよろしくお願いします!👍✨

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?