AIエージェントを使ったコーディングの3つの方法
本記事では、コーディングにおけるAIエージェントの実践的な応用について探求します。筆者は3つのアプローチを紹介しています：1) 複数のコマンドラインインターフェースを起動する、2) AI CLIをヘッドレスモードで実行する、3) 1つのLLMがサブエージェントを作成・管理する。筆者は2番目のアプローチを好み、エージェントの必要性、マルチエージェント連携の課題、今後の計画について議論します。
記事インテリジェンス
要点
- AIエージェントは、LLMの能力を持つソフトウェアプロセスであり、自律的にタスクを実行する。
- エージェンティックコーディングの3つの方法：マルチCLI、ヘッドレスAI CLI、LLM管理のサブエージェント。
- 筆者は複雑さと効果のバランスから2番目の方法を推奨する。
- 複数エージェントの同時作業はファイル競合を引き起こす可能性があり、分離とブランチ管理で緩和できる。
重要な理由
このニュースが重要なのは、AIエージェントは、LLMの能力を持つソフトウェアプロセスであり、自律的にタスクを実行するためです。
技術的影響
モデル選定、推論コスト、プロダクト能力、評価基準に影響する可能性があります。
「AIエージェント」の合理的な定義は、少なくともエージェンティックコーディングの文脈では、次のようになります：LLMの能力を備えたソフトウェアプロセスであり、開始時にタスクを達成するための指示が与えられ、自律的に（人間との対話なしで）長時間実行され、非決定的な動作（指示から逸脱せずに状況に適応する）を行います。これらのプロセスは並行して起動でき、結果を速めたり、より多くのタスクを達成したりできます。
しかし実際には、「エージェント」という用語は上記の定義とは無関係に使われることがよくあります。最新の派手な用語として、実際には「あなたはプロの税務エージェントとして行動し、私の確定申告を手伝ってください」とユーザーが促したChatGPTの会話を指している可能性があります。Pieter Levelsは2025年夏にこの感覚を共有しました：「最近『AIエージェント』という話を聞くと、たいていは危険信号で、彼らはAIニュースを読んでいるだけで実際には何も出荷していない非技術者だとわかる。」
2026年夏に近づいていますが、状況は大きく変わりましたか？筆者のコーディング実践では、上記の定義に沿ったエージェンティックコーディングの方法をいくつか探求しました。以下が試した3つの方法です。
方法1：複数のコマンドラインインターフェースを起動する 筆者は以前こうしていました：サーバーにSSHセッションを開き、Codex CLIを起動し、タスクを説明するプロンプトを書いてGPTに依頼。別のSSHセッションを開き、別のタスクのためにCodex CLIを起動。これを繰り返します。これは非常にローテクですが、うまく機能します。異なるセッションでClaude Code、Codex CLI、Gemini CLIを起動できるため、複数のAIプロバイダーにトークン消費を分散できます。
方法2：AI CLIをヘッドレスモードで起動する この方法は200以上の異なるウェブページ用のクローラーを作成するために使用しました。基本ロジックは：200のウェブサイトのパラメーター（URLなど）を含む1つのJSONファイル、1つのBashスクリプト（スクリプトA）がコマンドラインインターフェースを介してLLMをヘッドレスモードで起動します。ヘッドレスとは、LLMがプロンプトで起動されると、完了するまで実行され、許可やフィードバックを求めないことです。スクリプトAにはLLMに与えるプロンプトが含まれ、プレースホルダーがあり、特定のウェブサイトの情報で置き換えられます。別のスクリプトBがJSONから20のウェブサイトを選び、それぞれに対してスクリプトAを実行します。
このアプローチはうまく機能します。「スクリプトBを起動し、1時間で200のクローラーを書く」ほど簡単ではありませんが、それに近いです。スクリプトAではLLMが各クローラーの単体テストも書くように指示されています。テストは常に合格するわけではありませんが、信頼性が向上します。
方法3：1つのLLMにサブエージェントを作成・管理させる 方法2はBashとUnixに依存しており、メンテナンスが困難です。Cursor、Codex、Google Antigravity、Claude Codeなどのソリューションは、LLMが自分でエージェントを起動することを可能にします。しかし筆者の意見では、現時点ではまだ不十分です。1つのエージェントにサブエージェントへの委任を依頼すると、実際の作業から2段階離れることになり、不整合やエラーを発見しにくくなります。また、特定のソリューションに依存するようになります。そのため、筆者は方法2（単純な場合は方法1）を引き続き使用します。
エージェントは本当に必要か？ ほとんどの場合、不要です。Ethan Mollickはたった1つのプロンプトと4回のフォローアップで完全なWebアプリケーションを作成し、筆者の娘も派手な技術なしで本格的なEコマースプラットフォームを開発しました。LLMは検索時に独自にエージェントを起動して管理することもあります。筆者は、ほとんどの複雑なタスクでもエージェントは不要であり、必要ならLLMが内部で管理すると考えています。
マルチエージェントの衝突問題 複数のエージェントが同時にコードベースに書き込むと、互いに干渉します。解決策は各エージェントを異なるgitブランチで作業させ、完了後にマージすることですが、マージが失敗することも多く、面倒です。方法2では、各クローラーを完全に分離するための準備作業を事前に行い、プロンプトに範囲外のファイルに触れないよう明示的に禁止することで衝突を回避しました。
次のステップ 方法2で数十のクローラーから数百のクローラーへ拡大し、実行すること。この「手製」のマルチエージェント設定に習熟し、必要な場所で再現できるようにすること。
筆者について 筆者は学者であり、独立したWebアプリ開発者です。テキストとネットワークを探求するためのポイントアンドクリックツール、nocode functionsを作成しました。