結論から言うと
個人開発でAI社員はほぼ不要
です。
個人開発でアプリやWebサービスを作るだけなら、AI社員のような複数エージェント構成は基本的に不要だと思っています。
理由は単純で、普通に生成AIへ実装を依頼する場合と比べて、トークンの使用量と実装完了までの時間が増えやすいからです。
もちろん、AI社員そのものに意味がないわけではありません。
大規模な開発や、複数の役割を分けて継続的に開発する環境では役立つ可能性があります。
ただ、予算やトークンに限りがある個人開発では最初から大がかりな仕組みを作る必要はないと思います。
AI社員とは複数の生成AIに役割を与える仕組み
この記事でいうAI社員とは、生成AIに複数の役割を与えそれぞれに仕事を分担させる仕組みです。
例えば、次のような構成です。
- プロジェクトマネージャー（人間）
- リーダー
- フロントエンド担当
- バックエンド担当
- コードレビュー担当
- テスト担当
人間がリーダー役のAIに指示を出し、リーダーが作業内容を判断して、それぞれの担当AIに仕事を振り分けます。
実際の会社に近い役割分担を生成AIで再現するようなイメージです。
一見すると便利そうですが人開発ではこの分業そのものが余計な工程になる場合があります。
AI社員は処理のたびにトークンを消費する
通常の生成AIを使った個人開発であれば次のような指示で済むことが多いです。
この機能を、この仕様で実装してほしい
この場合、生成AIの主な処理は次の2つです。
- 仕様を整理する
- コードを実装する
もちろん、実際には既存コードの確認や修正もありますが、基本的には依頼者と実装担当の間で作業が完結します。
一方、AI社員を構築すると、次のような流れになりやすいです。
- 人間がリーダーAIに指示する
- リーダーAIが依頼内容を分析する
- 担当するAIを判断する
- 担当AIへ作業内容を引き継ぐ
- 担当AIが仕様を確認する
- コードを実装する
- レビュー担当AIが確認する
- テスト担当AIがテストする
- 修正があれば再び担当AIへ戻す
実装以外の工程がかなり増えます。
それぞれのAIが既存コードや仕様書を読み、判断結果や作業内容を文章として出力するためそのたびに入力トークンと出力トークンが発生します。
役割を細かく分けるほど、引き継ぎに通常の何倍もトークンを使用してしまう可能性が出てきます。
同じ情報を複数のAIが読み直すことになる
AI社員で見落とされやすいのが同じ情報を複数のAIが読むことです。
例えば、ログイン機能を修正する場合を考えます。
実装担当だけでなく、リーダー、レビュー担当、テスト担当もログイン機能の仕様や既存コードを確認することになります。
各担当者が独立したコンテキストで動く構成なら、同じファイルや仕様を何度も入力しなければなりません。
人間の会社であれば、役割を分けることで品質や責任範囲を管理できます。
ただ、生成AIの場合は役割を分けるほどコンテキストの再読み込みや情報の引き継ぎが増えます。
小さな機能を実装するために、複数のAIが同じコードを読み直すのであれば個人開発では効率が良いとは言いにくいです。
テスト担当のAIは特にトークンを使いやすい
AI社員の中でも、テスト担当はトークンの使用量が増えやすい役割だと実際に作成してみて思いました。
テストを行うには、最低でも次の情報が必要です。
- 新規実装、変更した機能の仕様
- 実装されたコード
- 影響する既存機能
- 想定される正常系
- 想定される異常系
これら全てを読み込んだうえで、テストケースを作成しコードを確認します。
そのため実装と同じくらい、場合によっては実装以上のトークンを使う可能性があります。
ただし、テスト担当AIが行う作業の多くはコードや文章を確認する静的なテストです。
実際にアプリを起動し、画面を操作して、不自然な表示や操作感を確する動的テストは行われません。
もちろん、ブラウザ操作やエミュレーター操作ができる環境を組み合わせれば実際の画面を使ったテストも可能だと思います。
ただ、そこまで構築すると今度はテスト環境の準備や保守が必要になるうえに、そこに割くトークンもまた使用してしまいます。
なので、個人開発で小さなアプリを作るために、AI社員というそこまでの仕組みが必要とはやはり個人的には思えません。
AI社員は実装完了までの時間も長くなりやすい
AI社員はトークンだけでなく実装完了までの時間も増えやすいです。
通常であれば、生成AIへ直接実装を依頼し、コードを確認して修正すれば終わります。
しかし、AI社員の場合はリーダーによる判断 → 担当者への振り分け → 実装 → レビュー → テストという工程を通します。
処理を並列化できる作業であれば、時間を短縮できる可能性はありますが、このAI社員による実装は並列処理ができません（僕がやり方を知らないだけかもしれないですが）
一方で、一つ前の作業が終わらないと次へ進めない処理では単純に待ち時間が増えます。
そういったことからも小規模な実装や修正では分業の効果がほとんどありません。
ボタンの表示を変えるだけなのに、リーダーAIが担当者を決め、実装担当が修正し、レビュー担当とテスト担当が確認するというのは明らかに工程が重すぎます。
役割を増やしても品質が必ず上がるわけではない
レビュー担当やテスト担当を追加すれば、必ず品質が上がると思われるかもしれません。
しかし役割の数と品質は単純には比例しません。
全てのAIが同じ生成AIモデルを使い、同じような情報を読み、似た判断をするのであれば、担当名だけを変えても異なる視点が得られるとは限りません。
（これはルール次第で大分変わってくると思っていますが）
なので、実装担当が見落とした問題をレビュー担当も同じように見落とす可能性は十分にあり得ます。
また、AI同士の引き継ぎが不十分だとリーダーが意図した内容と、実装担当が理解した内容がずれることもあると思っています。
人間でも伝言ゲームが起きる様にAI社員でも同じ事象が起きるとも思っています。
そういったことから役割を増やすよりも一つの生成AIに明確な仕様、完了条件、禁止事項を与えた方が安定するケースも多いはずです。
個人開発では一つのAIに役割を切り替えさせるほうが現実的
個人開発なら複数のAI社員を常時動かすより、一つの生成AIに必要な役割を順番に担当させる方が現実的だと思います。
例えば、次のように進めます。
- 最初に仕様を整理させる
- 合意した仕様をもとに実装させる
- 実装後にコードレビューを依頼する
- 必要な部分だけテストケースを作らせる
- 最後は人間が実際の画面を確認する
これなら、作業ごとに必要な情報だけを与えられます。
簡単な修正であればレビューやテストを省略し、影響範囲の大きな修正だけ確認を増やすこともできます。
もちろんこれもルール化しなければいけないので、そこが面倒かつ大変なところではありますが。
何でも組織化するのではなく作業の大きさに応じて工程を変える、という訳です。
僕はこの方法の方がトークン、時間、品質のバランスを取りやすいと思っています。
当然AI社員が向いている開発もある
ここまでAI社員は個人開発では不要だと書きましたが、すべての開発で不要という意味ではありません。
次のような環境では、AI社員を構築する意味があると思います。
- プロジェクトの規模が大きい
- フロントエンドとバックエンドの役割が明確になっている
- 複数のタスクを並列で処理したい
- コーディング規約や責任範囲が明確になっている
- トークン使用量を細かく気にする必要がない
- AIの出力を検証できる人間がいる
- 長期間運用する前提がある
- 自律的な開発ループを検証したい
大規模な開発では、さすがに一つのAIだけで全ての仕様やコードを扱うことが難しくなります。
その場合は担当範囲を分割し、それぞれに必要な情報だけを持たせる構成が有効になる可能性があります。
ただし、AI社員を作れば勝手に開発が進むわけではありません。
役割、権限、参照できるファイル、変更してよい範囲、完了条件などを細かく決める必要があります。
その設計や保守にも時間がかかるので、スキルを作って簡単に作成できるようにしておき、必要であれば構築し、不要であれば削除する、くらいの感覚でいいかもしれません。
AI社員を作ることで生成AIのルールは学べる
個人開発では費用対効果が悪い一方でAI社員を構築すること自体にはメリットがあります。
それは、使用している生成AIや開発ツールのルールを詳しく学べることです。
AI社員をまともに動かすには、単に「あなたはリーダーです」とプロンプトへ書くだけでは足りません。
次のような内容を理解する必要があります。
- グローバルルールの適用範囲
- ワークスペースルールの適用範囲
- プロジェクト固有ルールの置き場所
- ルールファイルの優先順位
- 各AIが参照できるファイル
- 変更を許可するフォルダ
- 役割ごとの禁止事項
- AI同士で情報を引き継ぐ方法
- タスクの完了条件
- レビューやテストを開始する条件
このあたりを調べていくと普段の生成AIへの指示も改善できます。
・どのフォルダにルールファイルを置けばよいのか
・どの程度具体的に指示すべきなのか
・どの情報を常時読み込ませるべきなのか
が分かってくるからです。
AI社員を実際の開発で使わなかったとしても、学習用として構築する価値はあると思っています。
AI社員は目的ではなく手段
AI社員という言葉は分かりやすく、仕組みとしても面白いです。
ただ、個人開発の目的はAI社員を作ることではなくアプリやサービスを完成させることです。
AI社員を導入した結果、トークン使用量が増え、完成までの時間が延び、設定ファイルの管理ばかりに時間を使うのであれば手段と目的が逆になっています。
個人開発では最初から複数のAI社員を作るのではなく、一つの生成AIへ直接依頼する形から始めるほうが良いと思います。
そのうえで作業量が増え、一つのAIだけでは管理しにくくなった段階で役割を分ければ十分です。
・小規模な開発では、単純な構成のほうが早くてトークン消費量も少ない。
・大規模な開発では役割分担が品質や管理に役立つ可能性がある。
AI社員を使うかどうかは流行で決めるのではなく分業によって減る作業と、追加されるトークンや管理コストを比較して判断したほうが良いのではないかと個人的には思います。
コメント