【ITニュース解説】What it costs to run a self-verifying AI agent on a CPU-only laptop

AIエージェント、特に自己検証を行うAIエージェントという言葉を聞いて、すぐにその具体的なイメージを掴むのは難しいかもしれない。しかし、この記事は、システム開発の現場で直面する根本的な問題と、それを解決するための実用的なアプローチについて、システムエンジニアを目指す人にとって非常に重要な示唆を与えている。

AIエージェントとは、人間から指示を受け、複数のツールを自律的に使いこなし、目標達成に向けて一連の作業を実行するプログラムのことだ。例えば、「このデータファイルを分析して、レポートを作成し、結果をデータベースに保存せよ」といった指示に対し、エージェントはファイルを開き、分析プログラムを実行し、レポート生成ツールを使い、データベース接続ツールを操作するといった一連のタスクをこなす。

多くの人がAIエージェントの開発と聞くと、高性能なグラフィックス処理装置（GPU）やクラウド上の大規模なサーバーを想像しがちだ。しかし、この記事で紹介されているOpenAmerのプロジェクトは、ごく普通のWindowsノートパソコン、それもGPUを使わずCPUだけでAIエージェントを動かしている点が特徴的である。彼らが最も驚いたのは、エージェントが実際に動作するコストではなく、エージェントが「自分が指示された通りにタスクを完了した」と、自分自身で検証する部分の重要性とコストだったという。

では、なぜAIエージェントの自己検証が必要なのだろうか。記事では、この問題を「エージェントが『完了』と言っても、それが真実ではない場合がある」と指摘している。人間がエージェントに五つのタスクを依頼したとしよう。エージェントは「すべて成功しました」と報告するかもしれないが、実際にはいくつかのタスクが失敗している可能性があるのだ。例えば、使用したツールがエラーを発生させたにもかかわらず、エラーメッセージを単なる文字列として返し、プログラム自体は停止しなかった場合。あるいは、ファイルを書き込む際にリトライ処理が行われた結果、同じファイルが二重に書き込まれてしまった場合。また、あるタスクが別のタスクの完了を前提としていたが、その前提が誤って満たされていると判断され、タスクがスキップされてしまった場合などがある。

これらの失敗は、エージェントとのチャット履歴には現れないし、一般的なプログラムの単体テストでも見つけにくい。なぜなら、失敗の原因は、複数の異なるシステムやツールが連携する「統合の境界」と呼ばれる部分で発生しているからだ。エージェント自身が自分の作業内容を報告する際に、作業を実行したのと同じ仕組みを使うと、その報告は単なる「主張」に過ぎなくなってしまう。主張には、それを裏付ける「証拠」が必要なのだ。

この問題に対し、OpenAmerは「台帳（ledger）」というシンプルな解決策を導入した。これは、エージェントが完了したタスクごとに、一行のJSON形式のデータをファイルに追記していく仕組みだ。このJSONデータには、タイムスタンプ（ts）、実行したタスク（task）、目標（goal）、エージェントの名前（agent）、成功したかどうか（passed）、そして失敗した場合はその理由（why）といった、非常に基本的な情報が含まれている。

重要なのは、成功したタスクと失敗したタスクを別々の場所で記録するのではなく、すべて同じ台帳ファイルに一元的に記録している点である。失敗も成功と同じ「行」として扱われ、「why」フィールドに何が問題だったかが記録される。もし成功はダッシュボードに表示され、失敗はログファイルに埋もれてしまうような仕組みだと、ダッシュボードは成功を誇示するだけの「マーケティング」になり、本当に問題を見つけたいときはログを詳しく調べる手間が発生する。しかし、一つの追記専用ファイルにすべてが記録されていれば、全体の状況が同じ会計帳簿のように確認できるというわけだ。

実際にOpenAmerがこの台帳を運用して得られた数値は非常に示唆に富んでいる。ある期間の実行データを見ると、台帳には合計1,312行のタスク記録があった。そのうち、成功と判断されたタスクは388行に過ぎず、失敗と記録されたタスクはなんと924行もあったのだ。これは、約7割ものタスクが失敗しているという衝撃的な事実を示している。OpenAmerは、この高い失敗率を隠すのではなく、むしろそれを重要な情報として提示している。台帳の目的は、成功したタスクを記録することだけでなく、「失敗を検知すること」にあるからだ。もしエージェントが「95%成功した」と自己報告している場合、それは測定すべき対象を誤っている可能性が高いと彼らは指摘する。

なぜCPUのみで開発を進めたのか、という点も興味深い。彼らは「制約が正直さを生む」と述べている。高性能なGPUがあれば、処理の遅延を並列処理の多さでごまかす「スループット」で隠すことができるかもしれない。しかしCPUのみではそれができないため、エージェントのメインの処理ループも、タスクの検証も、可能な限り安価で効率的に、そして「同期的に」実行する必要があった。ここでいう「同期的に」とは、次のステップに進む前に、必ず現在のステップの検証を行い、その結果を台帳に書き込むという意味だ。もし検証が後回しにされて、まとめてバッチ処理されるような仕組みだと、それは単なる事後報告になってしまう。しかし、次のアクションの「ゲート」として検証を機能させることで、エージェントは常に自分の行動が正しいかを確認しながら進むことができる。

さらに、CPUのみで動作するということは、特別な高性能ハードウェアやクラウド環境を準備する必要がなく、手元のノートパソコンで全体が動くというメリットも大きい。高額なサーバー費用を気にすることなく、開発や実験を進められる点は、システムエンジニアを目指す初心者にとっても非常に魅力的だろう。

このプロジェクトは、AIエージェントがユーザーのパソコン上で動作する際にも配慮している。通常のWindowsセッション上で、マウスのクリックやキーボード入力、ウィンドウの読み取りといった操作を行うが、ユーザーのカーソルや現在フォーカスしているウィンドウを奪うことはない。これにより、ユーザーは自分の作業を続けながら、エージェントをバックグラウンドで動作させることが可能だ。これは単なる「こうなるはずだ」という主張ではなく、実際にテストスイートを使って、ライブのデスクトップ環境でエージェントのアクションを実行し、その影響を検証することで、この機能が保証されている。

OpenAmerのプロジェクトはまだ若く、世界最高レベルの性能を誇るわけではない。記事に示された高い失敗率は、このプロジェクトがまだ「やるべきことリスト」を抱えている証拠であり、決して達成を祝うトロフィーではないと彼らは正直に語る。しかし、このプロジェクトが提供する最も重要なアイデアは、AIエージェントを開発するシステムエンジニアにとって非常に価値のあるものだ。それは、「タスクごとに一行の記録を書き、失敗も成功と同じファイルに含め、その記録を単なる領収書ではなく、次のアクションを制御する『ゲート』として機能させる」という考え方である。このアプローチを取ることで、システムのダッシュボードは派手さを失うかもしれないが、システム全体はより正直になり、問題の発見と改善に繋がりやすくなるだろう。これは、AIに限らず、あらゆるシステムの信頼性を高める上で非常に重要な視点と言える。