ソフトウェアを実際に作って出荷するAIエージェントの設計：Jobbitのアーキテクチャ徹底解説

ほとんどの「AIエージェント」は会話で止まってしまいます。質問に答えるだけで、実際の作業は人間がやる。本当に面白く、そして本質的に難しいエンジニアリング課題は、作業そのものをこなすエージェントを作ることです。フルスタックアプリを書き、実行し、自分のミスを修正し、本番環境へデプロイする——。これこそJobbitとそのR&D部門であるJobbit Labs（jobbitlabs.com）のエンジニアリングチームが日々取り組んでいる問題です。

この記事は、ソフトウェアを作って出荷するAIエージェントの背後にあるパターン——アーキテクチャ、失敗モード、そしてそこから得た教訓——をエンジニアリングの観点から掘り下げる解説です。意図的に実践的かつプロバイダー非依存の内容にしています。LLM、マルチエージェント・オーケストレーション、ツール呼び出し（tool calling）、あるいはRAGのどれを使って構築していても、これらの原則は応用が利きます。

チャットボットは答え、エージェントは行動する

チャットボットからエージェントへの飛躍は、テキストを生成することから世界に対して行動を起こすことへの飛躍です。エージェントは複数ステップのタスクを計画し、ツールを呼び出し、その結果を読み取り、次に何をすべきかを判断する——そしてゴールに到達するまでこれを繰り返さなければなりません。このループはエージェントループ（agentic loop）（あるいは推論・行動ループ）と呼ばれることが多く、システムの心臓部です。

エンジニアリング上の難しさは、あらゆるステップが失敗しうるという点にあります。モデルは存在しない関数をハルシネーションで生成したり、コンパイルできないコードを書いたり、ツールの出力を読み違えたり、いつのまにかタスクから逸脱したりします。間違ったチャットボットは悪い一文を生み出すだけですが、間違ったエージェントは壊れたデプロイを生み出します。本物のエンジニアリング課題は、生の能力ではなく信頼性にあるのです。

アーキテクチャ：プランナー、エグゼキューター、ツール

堅牢なエージェントプラットフォームは計画（planning）と実行（execution）を分離します。計画レイヤーはゴール（「決済機能付きの予約アプリを作る」）を具体的なステップへと分解し、実行レイヤーは各ステップをツールを使って遂行します。この関心事を分けておくことで、システムはデバッグ可能になります。各ステップがどう実行されたかとは独立して、計画そのものを検証できるからです。

ツール利用（tool use）は、エージェントが「手」を得る部分です。ツールとは、モデルが呼び出せる明確に定義された関数のことです——ファイルを読む、コードを書く、ビルドを実行する、データベースに問い合わせる、デプロイする。ここで問われるエンジニアリングの規律はインターフェース設計です。各ツールには、引き締まった曖昧さのないスキーマ、検証された入力、そしてモデルが確実にパースできる構造化された出力が必要です。緩いツールインターフェースはエージェントの失敗の最大級の原因であり、逆に引き締まったインターフェースは最も安価に手に入る信頼性の向上策です。

複雑なジョブでは、単一のエージェントはマルチエージェント・オーケストレーションへと道を譲ることがよくあります——計画、コード作成、レビュー、検証をそれぞれ担当する専門エージェント群を、オーケストレーターが調整するのです。分解によって得られるのは、フォーカス（各エージェントが狭い役割と狭いコンテキストを持つ）と並列性（独立したサブタスクが同時に走る）です。トレードオフは調整コストなので、オーケストレーション層は、決定論的にできるところは決定論的に、そうできないところは耐障害性を持たせて設計する必要があります。

実際のコードを安全に実行・デプロイする

ソフトウェアを書くエージェントは、そのソフトウェアを実行しなければなりません——そしてモデルが生成したコードを実行することは、何よりもまずセキュリティの問題です。その答えがサンドボックスでのコード実行（sandboxed code execution）です。信頼できないコードは、リソースが制限され、秘密情報へのアクセスがなく、ネットワーク境界が厳格に管理された隔離環境で実行されます。サンドボックスがあるからこそ、エージェントはプラットフォームや他のユーザーをリスクにさらすことなく反復——コンパイル、テスト、エラーの読み取り、修正——できるのです。

デプロイは、生成されたアプリをプロダクトへと変えるステップです。本物のAIアプリビルダーは、コードからライブURLまでの道のりを丸ごと担います。ビルドし、ホスティングをプロビジョニングし、ドメインを割り当て、TLSを終端する。これをうまく設計するとは、デプロイを再現可能かつ可逆（repeatable and reversible）にすることを意味します——同じ入力は同じ結果を生み、悪いデプロイはロールバックできる。冪等性（idempotency）とクリーンなロールバックは派手ではありませんが、自律的なデプロイを信頼に足るものにするのはまさにこれです。

コンテキスト、メモリ、検索

LLMのコンテキストは有限であり、現実のプロジェクトはそこに収まりません。だからこそ真剣なエージェントシステムはコンテキストエンジニアリング（context engineering）に大きく投資します——各ステップでモデルに何を見せるかを決めるのです。すべてをプロンプトに詰め込むのは高コストであるうえに逆効果でもあります。無関係なコンテキストが多すぎると推論の質が劣化します。

ここでRAG（検索拡張生成）とベクトルデータベースがその真価を発揮します。コードベース全体をコンテキストに放り込む代わりに、システムは現在のステップに関連する数個のファイル、シンボル、ドキュメントだけを検索して取り出します。これを構造化されたメモリ——意思決定の記録、進化していく仕様、すでに試したこと——と組み合わせることで、検索はコンテキストウィンドウを溢れさせることなく、長いタスクを通じてエージェントを地に足のついた状態に保ちます。優れた検索は、しばしばより大きなモデルよりも大きな品質改善のレバーになります。

信頼性：評価（eval）、検証、ガードレール

本番のエージェントエンジニアリングをデモから分け隔てる一つの考えがあるとすれば、それはこれです——測定できないものは出荷できない。エージェントシステムは確率的なので、信頼性は評価（eval）を通じて設計します——代表的なタスクでエージェントを採点し、ユーザーより先にリグレッションを捕まえる自動テストスイートです。「なんとなく良くなった気がする」けれど評価スコアを下落させる変更は、出荷すべきでない変更です。

評価の上に、ランタイムのガードレールと検証（verification）が乗ります。最も効果的なパターンは敵対的な自己チェック（adversarial self-checking）です。エージェントが結果——コード片、計画、修正——を生成したあとに、別の検証パスがそれを反証しようと試みるのです。コードはコンパイルできるか？ テストは通るか？ 出力はスキーマと一致するか？ 検証を独立した懐疑的なステップとして扱うことで、自信たっぷりの一回のパスなら見逃していたであろう失敗の大部分を捕まえられます。残りはバックオフ付きのリトライ、サーキットブレーカー、人間へのエスカレーションが処理します。

デバッグできる可観測性

自律システムがタスクごとに何十もの意思決定を行うとき、あなたはそれらを見える化する必要があります。可観測性（observability）——あらゆるプロンプト、ツール呼び出し、結果の構造化されたトレース——は必須条件であって妥協の余地はありません。エージェントが間違ったとき、トレースこそが、逸脱した正確なステップを見つけ、再現し、根本原因を修正する手段になります。エージェントのトレースを一級のテレメトリとして扱うエンジニアリングチームは数分でデバッグし、そうしないチームは数日かけてデバッグします。

エッジと弾力的なスケール

エージェントのワークロードはバースト的でレイテンシに敏感なので、エッジコンピューティングが自然にマッチします。ユーザーの近く——Cloudflare Workersやエッジのデータストアといったプラットフォーム上——で実行することで、往復のレイテンシを削減し、需要に応じて弾力的にスケールできます。Jobbit Labsは、データおよびプロダクトのインフラの一部でこのエッジファーストのアプローチを活用しています。グローバルに分散し、オートスケールし、使った分だけ支払う仕組みなので、キャパシティは遊休状態でとどまるのではなく負荷に追従します。

ヒューマン・イン・ザ・ループのレイヤー

アーキテクチャの最後のピースは、ほとんどのエージェントプラットフォームに欠けているものです——ヒューマン・イン・ザ・ループ（human-in-the-loop）の経路です。AIは量とスピードをさばきますが、一部の意思決定——セキュリティに敏感なロジック、法的な文言、デザインの判断——は人間に委ねるべきものです。これを設計するとは、審査を通過した人間の専門家が介入できるクリーンな引き継ぎポイントを構築し、エスクローで取引を保護することを意味します。エージェントと人間のネットワークは競合するレイヤーではありません。それらは、システム全体を安心して頼れるものにするための、設計に組み込まれたフォールバックなのです。

エージェントを作るエンジニアへの教訓

エージェントシステムを構築しているなら、投資の何倍にもなって返ってくる原則がいくつかあります。

引き締まったツールインターフェースを設計する。 ほとんどのエージェントの失敗は曖昧なツールに行き着きます。厳格なスキーマと検証された入出力は、買える信頼性の中で最も安いものです。

敵対的に検証する。 自信たっぷりの最初のパスを信用してはいけません。結果を反証することを役割とする独立したステップを追加しましょう。

評価（eval）で測定する。 エージェントをスケールさせる前に評価ハーネスを構築すること。採点できないものは改善できません。

コンテキストは設計するもので、放り込むものではない。 関連するものを検索し、重要なものを記憶する。より大きなプロンプトは、より良いプロンプトではありません。

信頼できないものはすべてサンドボックス化する。 エージェントがコードを実行するなら、隔離は機能ではなく前提条件です。

人間の経路を残す。 最も安全な自律システムとは、いつ人に尋ねるべきかを知っているシステムです。

よくある質問

AIエージェントはチャットボットと何が違うのですか？

チャットボットはテキストを生成します。一方AIエージェントは計画を立てて行動を起こします——ツールを呼び出し、コードを実行し、ゴールに向かって反復します。エンジニアリング上の難しさは、たった一つのエラーが結果を台無しにしうる多数のステップにわたって信頼性を保つことです。

AIが生成したコードはどうやって安全に実行するのですか？

サンドボックスでのコード実行を使います。信頼できないコードを、リソースが制限され、秘密情報へのアクセスがなく、ネットワークが制約された隔離環境で実行することで、エージェントはプラットフォームをリスクにさらすことなくコンパイル、テスト、修正ができます。

なぜ評価（eval）はエージェントシステムにとってそれほど重要なのですか？

エージェントは確率的だからです。代表的なタスクで品質を測定し、出荷前にリグレッションを捕まえるために、自動化された評価（eval）が必要です。それがなければ、「改善」はただの当て推量です。

Jobbit Labsは何をしているのですか？

Jobbit Labs（jobbitlabs.com）はJobbitを支えるR&Dおよびデータ部門で、より重量級でデータ集約的かつエンタープライズ向けのエンジニアリング——研究、データプラットフォーム、そしてプロダクトの基盤となるエージェントの土台——に注力しています。

ソフトウェアを出荷するエージェントの背後にあるエンジニアリングに興味がありますか？ jobbit.ukとjobbitlabs.comをぜひご覧ください。