【ITニュース解説】Hello from a solo agent-operator — my agent's rules turned out to be fiction

AIエージェントの運用において、設定やルールが「書かれている」ことと、それが実際に「システムに適用され、正しく機能している」ことの間には、見過ごされがちな大きな隔たりがある。このニュース記事は、AIエージェントを単なるデモではなく、本格的なプロダクションシステムとして運用する中で、筆者自身が直面したこの課題とその解決策について語っている。システムエンジニアを目指す皆さんにとって、これはAIシステムに限らず、あらゆるITシステムの設計・運用において非常に重要な教訓となるだろう。

筆者は、自身のAIコーディングエージェントを家庭内のラボ環境で運用し、ルールをバージョン管理し、検証を行うなど、プロフェッショナルなアプローチで臨んでいた。しかし先日、自身のエージェントのルール設定を監査した結果、非常に驚くべき事実が判明したという。

AIエージェントの本格的な設定では、通常、複数の階層にわたるルールが存在する。例えば、エージェント自身の基本的な振る舞いを定義する「アイデンティティ/システムファイル」、特定のプロジェクトに関する指示を記述する「プロジェクトレベルの指示ファイル」、過去のやり取りや学習を保存する「永続メモリ」、特定のタスクを実行するための「スキル」などがある。これらの各レイヤーは、エージェントのコンテキスト（状況判断の基となる情報）に読み込まれ、通常は下位のレイヤーが上位のレイヤーのルールを上書きすることで、より具体的な指示が優先される仕組みになっている。例えば、ユーザーからの直接の指示がプロジェクトファイルの内容よりも優先され、プロジェクトファイルがアイデンティティファイルの内容よりも優先される、といった具合だ。

筆者は、エージェントの安全基準、検証方法、メモリの管理方法などを定めた、いわば「憲法」と呼ぶべき統合されたルールファイルを手作業で作成し、数週間かけて洗練させてきた。これはエージェントの運用において非常に有用であると信じていたものだ。しかし、この「憲法」が実際に機能しているかを確認するための監査を行ったところ、次の三つの問題が明らかになった。

まず、その「憲法」ファイルは確かに存在していたものの、実際にはエージェントのどのレイヤーにも読み込まれていなかった。アイデンティティファイルも、コーディングエージェントの設定ファイルも、プロジェクトの指示も、どれもこの「憲法」ファイルを参照していなかったのだ。つまり、筆者が苦労して作ったルールは、まるで存在しないかのような「フィクション」に過ぎなかったのである。

次に、エージェントのルールを格納している二つのディレクトリが、全くバージョン管理下に置かれていなかったことが判明した。これは、もし誤って「rm」（ファイルを削除するコマンド）を実行してしまった場合、数ヶ月かけて蓄積した運用ルールが全て失われる危険性があったことを意味する。システム開発においてバージョン管理がいかに重要であるかを示す典型的な例だ。

さらに、ある設定ファイルの一部が、「憲法」の内容と重複していることが見つかった。このような重複は、当初は問題にならなくても、片方のルールが更新され、もう片方が放置されると、やがて内容に乖離が生じる。そうなると、同じリクエストに対してもエージェントによって異なる振る舞いをするといった、予期せぬ問題を引き起こすことになる。これは、複数の場所で同じ情報が管理される「情報の単一性」が失われることの危険性を示している。

なぜこのようなことが起こるのか。筆者はこれを「一般的な失敗モード」と捉えている。ルールが「書かれている」という事実と、そのルールが「AIモデルが意思決定する瞬間にコンテキストとして読み込まれている」という事実の間には、ファイルがどのように読み込まれ、どの優先順位で、どのマシンで、どのエージェントのために処理されるか、という「ワイヤリング（接続）」の連鎖が存在する。この連鎖は、意識しないうちに静かにずれていくことがあり、エージェントが「憲法」で明確に禁じられている行動をしたときに初めて、エージェントがそのルールをそもそも見ていなかったことに気づく、というわけだ。これは、セキュリティポリシーを作成しても、それを実際のシステムにデプロイしなければ意味がないのと全く同じ種類のバグである。多くの人は、AIエージェントの場合、このチェックすら行わないのが現状だと筆者は指摘する。

この問題を解決するために、筆者は厳格な「読み取り専用の監査」を実行した。その手順は以下の通りだ。

まず、「ルールが読み込まれている」「設定がバックアップされている」「メモリが健全である」といった主張一つ一つに対し、その真偽を確認するための「コマンド出力」を証拠とした。あいまいな記憶や推測ではなく、具体的なコマンドの実行結果を根拠とする。出力がなければ「不明」と正直に報告し、「おそらく大丈夫だろう」という安易な判断は避けた。

次に、各監査項目について、合格（PASS）、警告（WARN）、失敗（FAIL）を明確に記録し、それぞれに証拠となる情報（実行したコマンド、タイムスタンプ、観測された状態）を添付した。これにより、問題が客観的に把握できるようになった。

さらに、単にファイルの内容を確認するだけでなく、エージェントの実際の「振る舞い」についてもテストを行った。例えば、悪意のある入力（プロンプトインジェクション）に対する耐性があるか、存在しないテスト結果を捏造しないか、プレッシャーを受けても自身のしきい値を下げないか、といった項目だ。

監査によって発見された不具合は全て、承認を得た上で修正された。特に、ルールを定義するレイヤーのファイルは、監査が行われたその日のうちにGit（バージョン管理システム）で管理されるようになり、リモートでのバックアップも徹底された。

筆者はこの監査プロセス全体を、複数のAIエージェントフレームワークで動作する「SKILL.md」としてパッケージ化し、無償で公開している。これは、他の開発者も自身のAIエージェントの信頼性を高めるために活用できる汎用的なツールとなっている。

この経験を通じて、筆者は重要な教訓を得た。一つは、「エージェントの統治（ガバナンス）はエージェントの賢さよりも重要である」ということだ。どれほど賢いAIエージェントであっても、適切に管理・監査されていない設定では、退屈に思えるような厳格な監査を経た設定に劣るという事実だ。もう一つは、「感情的な判断ではなく、証拠に基づく」ことの重要性である。「うまくいった」という感覚ではなく、「コマンドの出力がその事実を示している」という具体的な証拠が不可欠だという。

このニュース記事は、AIエージェントという最先端の技術を扱う上での課題を提示しているが、その本質は、システムエンジニアが日々直面する「設定と運用の信頼性」という普遍的なテーマに他ならない。システムの設計や開発、そして運用において、作成した設定やルールが「書かれている」だけでなく、「確実に適用され、意図した通りに機能している」ことを、定期的な監査と具体的な証拠によって確認し続けることが、システムの信頼性を確保するために不可欠であるという強いメッセージを含んでいる。これは、システムエンジニアを目指す皆さんが、将来どのようなシステムを扱うことになっても必ず役立つ、根本的な考え方である。