Insights

コーディングエージェントのハーネスから見る、
AIエージェントの現在

2026.07.28 | 大嶋勇樹

2026年7月28日に開催された「Coding Agentのハーネスについて考える - W&Bミートアップ #28」で、株式会社ジェネラティブエージェンツ取締役CTO/Co-founderの大嶋勇樹が登壇しました。

読み込み中...

LLMベースのAIエージェントは、エージェントループ、MCPやスキルによるツール拡張、コンテキストエンジニアリングなど、さまざまな観点から進化してきました。そのなかで、現在の代表格となっているのがコーディングエージェントです。

本稿では、オープンソースのコーディングエージェント「OpenDev」の実装を手がかりに、モデルを取り囲む「ハーネス」を整理しながら、AIエージェントの現在地を見ていきます。

AIエージェントの「ハーネス」とは何か

株式会社ジェネラティブエージェンツで、大規模言語モデルを組み込んだアプリケーションやAIエージェントの開発に取り組んでいます。LangChainの公式アンバサダーとして活動しながら、この分野でいくつか書籍も書かせていただいています。

会社としては「AIエージェントがハブとなり、人間とAIエージェントの協働が当たり前になる世界を実現する」ことを掲げています。創業したのは2024年3月14日、GPT-4が出たちょうど1年後です。創業当初は「AIエージェント」と言ってもまだ伝わらないことが多かったのですが、最近は注目も高まってきていて、うれしい限りです。

今日は「コーディングエージェントのハーネスから見る、AIエージェントの現在」というテーマでお話しします。

LLMベースのAIエージェントは、実装面ではエージェントループが中心にあります。その周辺にMCPやスキルがあり、さらにコンテキストエンジニアリングというキーワードも出てきている。そうした観点で進化してきたわけです。

いま、そのAIエージェントの代表格がコーディングエージェントです。そしてモデルを取り囲む実装部分は、最近では「ハーネス」と呼ばれるようになっています。

最初に、AIエージェントのハーネスとは何かを簡単に振り返ります。その後、OpenDevというコーディングエージェントからハーネスの構成を見て、そもそもコーディングエージェントとは何なのか、AIエージェントはいまどこが熱いのかを考えていきます。

エージェントハーネスという言葉は、いろいろな場所で使われています。Anthropicのブログでは、エージェントハーネスを「モデルをエージェントとして機能させるためのシステム」と説明しています。入力を処理し、ツール呼び出しを調整し、結果を返す。エージェントを評価するときには、ハーネスとモデルが連携して動作する全体を評価することになります。

LangChainのブログでも、「Agent = Model + Harness」という整理がされています。AIエージェントのうち、モデルではない部分をハーネスと呼ぶ、という考え方です。

もうひとつ、最近よく見かける整理として、Martin Fowlerの記事に出てくる「ユーザーハーネス」と「ビルダーハーネス」があります。モデルのすぐ外側にある、Claude CodeやCodexのようなエージェントのコア実装部分がビルダーハーネス、さらにその外側でAGENTS.mdやスキルを付けて動かす部分がユーザーハーネス、と整理されることがあります。

OpenDevから見る、エージェントハーネスの構成

ここからは、OpenDevを手がかりにハーネスの構成を見ていきます。

OpenDevは、オープンソースのコーディングエージェントです。OpenCodeなど、ほかにもオープンソースのコーディングエージェントはいろいろありますが、OpenDevは実装を整理した論文を出していて、システムアーキテクチャの図が話の取っかかりとしてちょうどいいんですね。

その図では、左側にエントリー&UIレイヤー、真ん中にエージェントレイヤーがあります。さらにツール実行レイヤー、コンテキストエンジニアリングレイヤー、永続化などが整理されています。

一番中心にあるのが、エージェントレイヤーです。コーディングエージェントやAIエージェントの中心には、エージェントループと呼ばれるループがあります。LLMを使ったAIエージェントは、指示を受けるとモデルが考え、ツールを使い、その実行結果をプロンプトに追記して、次にどのアクションをするかをまた考える。これを繰り返して最後に止まる、という仕組みです。

コーディングエージェントであれば、ファイルの読み込み、書き込み、コマンド実行、Web検索などのツールを呼び出します。本当にミニマムに実装するなら、while ループの中でモデルを呼び、アクションを実行し、その結果を読ませる。このループがAIエージェントの一番コアな動きです。

ツール実行レイヤーも、いま盛り上がっている領域です。コーディングエージェントはだいたい、ファイル操作、コマンド実行、Web検索などができるようになっています。

MCPは、このツール拡張の仕組みとして使われることが多いものです。MCP自体はもっと幅広いことができますが、現状ではツールの追加に使われるケースが多いと思います。

エージェントスキルも、ツールに近い発想です。エージェントに対して、<スキル名>/SKILL.md のようなファイルで機能や専門知識を提供します。システムプロンプトにあらゆる知識を全部入れてしまうと性能が落ちる可能性があるため、必要なときに必要な知識を読ませる。これがスキルの特徴です。

ツール呼び出しの問題と、Programmatic Tool Calling

従来のツール呼び出しには、実は根本的な問題があります。

たとえばGitHubツールとJiraツールをエージェントに設定して、「GitHubのIssueを全部Jiraに移行してください」と頼むとします。これは、あまりおすすめできないやり方です。GitHubから読み込んだ内容をJiraに書き込む間に、不必要な情報の読み込みが発生し、コンテキスト汚染や性能低下につながります。

さらに、GitHubから読み込んだ情報をJiraに書き込むだけなのに、その間にAIの料金が発生します。しかも、こういう処理をやらせると、50件中10件だけで止まる、途中で「以下省略」してしまう、ということも起きがちです。

そこで最近広まりつつあるのが、Programmatic Tool Calling、PTCです。AnthropicやOpenAIのAPIでは、こうした機能がサポートされ始めています。

「このサービスにあるチケットを、別のサービスに全部移行してください」と頼んだときに、モデルがコードを書いてくれる。コードの中からツールを呼び出せる。そういう仕組みです。

さらに応用として、Claude CodeにはDynamic Workflowという機能があります。ワークフローをコードとしてエージェントが書き、その中でサブエージェントを呼び出して、大規模な処理を組み立てるというものです。このあたりは、エージェントの再帰呼び出しに関する論文なども出ていて、注目されている領域です。

コンテキストエンジニアリング

次に、コンテキストエンジニアリングです。

この言葉が流行ったきっかけは、Cognitionのブログだと思っています。プロンプトエンジニアリングが「タスクに対していい感じのプロンプトを書く」ことだとすれば、コンテキストエンジニアリングはそれを動的なシステムの中で行う、という話です。

LangChainのブログでも、コンテキストエンジニアリングとは「動的なシステムを作ること」だと説明されています。LLMがタスクを達成できるように、適切な情報やツールを適切な形式で提供する。そういう動的なシステムを構築することです。

コンテキストエンジニアリングのサーベイ論文でも、プロンプトエンジニアリングではコンテキストを静的なテキストとして扱っていたのに対して、コンテキストエンジニアリングではコンテキストを動的な情報コンポーネントの集合として捉え直す、と説明されています。

図解すると、プロンプトを組み立てるときには、いろいろな部品があります。システム的な指示、ユーザーのクエリ、会話履歴、環境の情報、ナレッジ、ツール、記憶などです。

それぞれの部品を、ユーザークエリや会話履歴、環境の情報をもとに組み立て、さらに全体のコンテキストとして結合する。この部品そのものを最適化することではなく、部品を組み立てる関数を最適化することが、コンテキストエンジニアリングです。

そう考えると、AIエージェントの動きや実装は、ほとんどコンテキストエンジニアリングをやっているとも言えます。

エージェントのUIとエントリーポイント

ここまで、エージェントレイヤー、ツール実行レイヤー、コンテキストエンジニアリングレイヤーを見てきました。ただ、これだけではありません。OpenDevの図にあるエントリー&UIレイヤーも、最近かなり熱い要素だと思っています。

AIエージェントの定番UIはいくつか確立されつつあります。まずはWeb、TUI、Slackなどのチャットです。

ほかにも、アプリの右側にチャット欄を置き、そこにエージェントが住んでいるようなUIがあります。CursorやDia Browserなどは、まさにこのパターンです。

エージェントから人間に「これをチェックしてください」とタスクを渡す、エージェントインボックスのようなUIもあります。さらに最近では、Kanbanもかなり流行っています。OpenAIのSymphonyなども有名ですが、コーディングエージェントを看板でうまく働かせる、という活用が広がっています。

有名なAIエージェントに、OpenClawがいます。OpenClawは、エントリーポイントの観点で注目されたのだと考えています。DiscordやSlackと接続できることに加えて、Heartbeatという機能を搭載しました。定期的にエージェントを動かし、常駐させ、同じ指示で働かせ続けるというパターンです。

同じころ、Claude Codeを2週間走らせ続けてCコンパイラを実装した事例も話題になりました。実際にできたものは「Hello, World!」すらコンパイルできないというIssueも上がっていたので、プログラミングが何でもできるようになった、という話ではありませんが、長時間エージェントを走らせ続ける事例として注目されました。

どう実現したかというと、無限ループです。Claude Codeを同じプロンプトで働かせ続けた。「状況を確認して続きの実装をして」といったプロンプトを想像すると分かりやすいと思います。こうした長時間実行やループの設計は、最近「ループエンジニアリング」と呼ばれ始めています。

コーディングエージェントは、もはや開発者だけのものではない

ここで改めて、コーディングエージェントとは何なのかを考えてみます。ここからは、私の私見がだいぶ入るところです。

先月、OpenAIから「The Shift to Agentic AI: Evidence from Codex」という論文が出ました。Codexの利用状況から、Agentic AIへのシフトを見るという内容です。

この論文で重要なことの1つは、Codexの利用がソフトウェア開発者以外にも広がっているという点です。Claude Codeを業務活用しよう、Codexをいろいろな仕事に使おう、という話はかなり定着しつつあります。

では、なぜコーディングエージェントは、いろいろな用途に使われるのでしょうか。何が便利なのでしょうか。

たぶん、こういうことだと思っています。コーディングエージェントは、ファイルの読み書き、コード実装、コマンド実行ができます。つまり、コンピュータでできることは何でもできる。

一方で、そもそもAIエージェントに何をしてほしかったのか。最初からそうだったと言えばそうですが、AIエージェントには、コンピュータで行うあらゆる仕事をしてほしかったわけです。

この2つが噛み合ったんですね。コーディングエージェントは、ファイル操作、コード実装、コマンド実行によってコンピュータを自由に操作できる。AIエージェントには、コンピュータで行う仕事をしてほしい。だから、AIエージェントに求める能力を持つ存在として、コーディングエージェントがAIエージェントのデファクトスタンダードになりつつあるのだと思います。

AIエージェントは、パーソナルアシスタントからチームメイトへ

私たちの会社では、そもそも「AIエージェントと働く」とはどういうことかをテーマにしています。既製品のエージェントをうまく使うこともそうですし、必要ならAIエージェントを作ることも含めて、日々考えています。

ここで話しておきたいのが、パーソナルアシスタントとチームメイトという違いです。

いま、Claude CodeやCodex、ChatGPTなどのAIは、基本的にはパーソナルアシスタントとして使われています。一人ひとりの仕事量を増やす。AIを使わない場合の何倍もの仕事ができるようにする。これは、パーソナルアシスタントとしての活用です。

一方で、AIエージェントがチームメイトとして働く方向もあると思っています。

私たちの会社には、教育・研修事業の事務担当エージェント「manabu-kun」がいます。これは私個人のAIエージェントではなく、チームの一員のような位置づけです。Slackにいて、研修の予定や対応状況を覚えていてくれる。こちらから「この対応は終わったよ」と伝えておいたり、「そろそろこれをやったほうがいいよ」というリマインドがmanabu-kunからあったりします。

AIエージェントには、人間と働くのに近い感覚で働いてほしい。人間同士で仕事をするとき、「あの仕事どうなったっけ」と確認しますよね。AIエージェントにも同じように聞けて、わかることは答えてほしい。答えられなければ、「担当の誰々に聞いておきますね」と動いてほしい。

そういう意味で、AIエージェントには業務の中心という立場を担ってほしいと思っています。一人ひとりを強くするだけでは、本当のボトルネックが消えないかもしれない。これはコーディングにも、それ以外の業務にも言えることです。

重要になりつつある「コーディングエージェントのデプロイ」

一方で、いま最も役立つAIエージェントはコーディングエージェントです。この話を組み合わせると、AIエージェントの活用や開発で重要なことのひとつは、コーディングエージェントをデプロイすること、つまり共有環境で動かすことではないかと思っています。

ただ、考えどころがあります。

やってはいけないのは、通常のWebアプリケーションやWeb APIのサーバーに、ファイル操作、コード実装、コマンド実行ができるエージェントを同梱して、そのまま動かすことです。あるユーザーからのリクエストに対する処理でファイル操作やコマンド実行が行われると、ほかのユーザーの処理に影響する可能性があります。そのため、情報漏洩が簡単に起きる可能性があります。

そこで、いろいろな会社がAIエージェント向けのサンドボックスを提供しています。隔離したサンドボックスでコーディングエージェントを動かす。ユーザーやセッションごとにサンドボックスを起動すれば、ファイル操作やコード実行を分離できます。

ただし、この構成ではサンドボックスを起動してからエージェントが考え始めるため、レスポンスが遅くなります。

そこで、サンドボックスの使い方にはもうひとつのパターンがあります。エージェントをサンドボックスの中に入れるのではなく、エージェントにサンドボックスをツールとして渡す。ハーネスとサンドボックスを分離する構成です。

こうすると、モデルの推論開始時にサンドボックスの起動を待たなくてよくなります。サンドボックスに障害が起きた場合も、モデルから見ると「ツール呼び出しが失敗した」と扱えるので、復帰しやすいというメリットがあります。

サンドボックスは、モデルにコンピュータを与えるようなものです。人間がPCを受け取り、ターミナルでコマンドを実行したり、ファイルを操作したりする。それと同じことをモデルにもさせる、という話です。

ただ、そうなると今度は、実行できるコマンドをどう制御するのか、通信先をどう制限するのか、外部サービスにアクセスするAPIキーをエージェントに見せたくない場合はどうするのか、といった議論が出てきます。

NVIDIAのOpenShellやNemoClawのように、コーディングエージェントを安全に動かすためのツールも出てきています。人間が使うPCと同じように、エージェントに渡すマシンにも改ざん検知やプロキシ経由の通信制御を入れる。そうすれば、許可リストにあるコマンドの改ざんを防いだり、APIキーの保護や通信先の制限をしたりできます。