【ITニュース解説】Beyond the Hype: How ‘AI Psychosis’ and the OpenAI Agents API Are Exposing the Fragility of Modern Software Engineering

現代のソフトウェア開発は、長らく「決定論」という考え方に基づいて進められてきた。これは、私たちが書くプログラムが、常に同じ入力に対して同じ結果を返すことを意味する。プログラムの動きを予測可能にするため、コンパイル時に型の矛盾をなくす型システムや、実行時の状態変化を確認するユニットテストといった厳格な仕組みを構築してきたのだ。しかし、近年登場した大規模言語モデル（LLM）は、純粋な「確率」に基づいて動作するものであり、私たちはこの確率的な性質を持つLLMを、これまでの厳格で決定論的なソフトウェアの枠組みに無理に当てはめようとしてきた。

その結果として生じているのが「AI Psychosis」と呼ばれる現象である。これは、AIエージェントが際限なくループし、自律的に自身の行動を修正しようとし、現代の脆弱なインフラシステムと明確な境界線なしに相互作用する際に引き起こされる、予測不能でしばしば目に見えない振る舞いを指す。この言葉は、医学的な精神疾患を指すものではなく、複雑で予測不能なAIの挙動を説明するための比喩的な表現である。OpenAI Agents SDKのようなツールが普及することで、私たちは単に技術的な問題を解決しているだけでなく、ソフトウェア工学が抱える深い真実を露呈させている。それは、私たちが構築してきたシステム基盤（スタック）が実はもろく、確率的に振る舞うAIエージェントがそのあらゆる欠陥を見つけ出すということだ。この問題はLLM自体の欠陥ではなく、LLMが従来のソフトウェアシステムとどのように相互作用するかという、ソフトウェア工学側の課題なのだ。

このシステムのもろさを理解するためには、私たちが構築してきたAIエージェントが何であるかを知る必要がある。推論モデルの進化とエージェントフレームワークの普及により、私たちは単なる「チャットボット」から、より自律的な「エージェント」へと移行した。OpenAIにおけるエージェントとは、外部のツール（API、データベース、コード実行環境など）を呼び出し、その実行結果を観察し、観察した結果に基づいて自身の次の行動計画を再構築し、さらに他のエージェントにその情報を伝えることができるシステムを指す。このような能力はエージェント内にフィードバックループを生み出す。決定論的なシステムでは、このフィードバックループは厳密に制御されるが、確率的なシステムでは、それは不安定な要素となる。例えば、LLMがツールを呼び出して予期せぬエラーを受け取った場合、単に再試行するだけでなく、なぜ失敗したのかを「推論」しようとする。その過程で、存在しないパラメーターを勝手に作り出したり（ハルシネーション）、エラーメッセージを誤解したり、同じ失敗するツールを「もっと適切にリクエストすればよい」と考えて何度も呼び出し続けるループに陥ったりすることがある。これがまさにAI Psychosisであり、直線的な処理を想定して設計されたシステムにおいて、予期せぬ複雑な振る舞いが現れる現象なのである。

現代のソフトウェアアーキテクチャは、RESTful APIやマイクロサービスといった技術に基づいており、その根底には「べき等性」という重要な前提がある。これは、同じリクエストを複数回実行しても、一度だけ実行した場合と同じ結果になるという考え方だ。例えば、ユーザーを削除するAPIを一度呼び出すのも十回呼び出すのも、結果としてユーザーは一度だけ削除されるべきである。しかし、LLMエージェントは、このべき等性を自然には尊重しない。彼らが重視するのは「会話の流れ」なのだ。エージェントが複雑なタスクを処理している際、例えば「書き込み」ツールを実行してそれが成功したと認識しても、LLMはステートレスで非決定論的であるため、次の処理でシステムの状態を再評価し、コンテキスト（過去の会話履歴）がずれると、再度書き込みを試みる可能性がある。さらに悪いことに、構文的には正しく見えるが意味的には間違った、幻覚を起こした情報でファイルを上書きして「修正」しようとすることさえある。

このような問題は、既に実際のシステムで報告されている。例えば、エージェントがツールスキーマでべき等性キーが適切に渡されなかったために二重課金したり、エラーメッセージを成功の合図と誤解して本番データベースを削除したり、APIが500エラー（サーバー内部エラー）を返した際に、それを一時的なネットワークの不具合と見なして無限ループに陥ったりするケースだ。これは、私たちの監視（オブザーバビリティ）機能の脆弱性を露呈している。現在のログシステムは、人間が静的なログを読むことを想定して作られており、数百ミリ秒ごとに気が変わる可能性のある確率的なアクターの意図を正確に解析するようには作られていないのである。

OpenAI Agents APIは、厳格なJSONスキーマを用いてツールを定義することを推奨しており、これは良い方向への一歩ではあるが、より深い問題を浮き彫りにしている。私たちは、必要な安全策（ガードレール）を構築することなく、ロジックの多くをプロンプトエンジニアリングに委ねてしまったのだ。従来のソフトウェアでは、整数が期待される場所に文字列を渡せば、コンパイラがエラーとして処理を停止させる。しかし、エージェントソフトウェアでは、モデルが「42」という文字列を整数が期待される場所に渡すことがあり、もしツールのパーサーがそれを適切に変換できなければ、ツールは失敗する。エージェントはその失敗を見て、それについて推論し、再度試みる。今度は「 42 」や「Forty-two」のような文字列を渡すかもしれない。ここでの脆弱性は、エージェントとツール間の「契約」にある。私たちは契約がスキーマによって形式的に定義されていると仮定するが、より重要な意味論的な契約は、モデルのツール目的の理解によって定義される。これらが食い違うとき、エージェントがネジをハンマーで直そうとし、ドライバーが壊れていると文句を言うような「サイコティックな」振る舞いが生じるのだ。

AI Psychosisの最も巧妙な形態の一つに、ツール出力の「幻覚」がある。LLMは「役に立つ」ように訓練されているため、ツールが失敗した場合でも、会話を続けるために、もっともらしい成功レスポンスをでっち上げることがある。単純なチャットボットであればこれは些細なエラーだが、本番システムへの書き込み権限を持つエージェントにおいては壊滅的な結果を招く可能性がある。これは、私たちのアーキテクチャにおける「信頼性」に関する前提の脆さを露呈している。私たちはAPIレスポンスが真実の源であるシステムを構築してきた。しかし、エージェントはレスポンスとアクションの間に「解釈」の層を導入する。この解釈は確率的であり、事実ではない。エージェントのツール出力の理解が、実際のツール出力と一致しているかどうかを検証する良い方法が、私たちにはまだない。

現代のソフトウェア工学は、システムを小さく独立した単位に分割する「モジュール性」に依存している。しかし、エージェントは、多段階のタスク全体で一貫性を保つために、しばしば大きな「コンテキストウィンドウ」（エージェントが過去の情報を記憶している範囲）を必要とする。これにより、モジュール化されたアーキテクチャと全体的な推論の間で緊張が生じる。コンテキストウィンドウが満杯になると、エージェントは「忘れる」という現象が始まる。以前の指示を見失ったり、重複した作業を行ったり、自己矛盾に陥ったりするのだ。これはバグではなく、LLMが情報を処理する方法の特性である。しかし、これは私たちの状態管理の脆弱性を露呈している。エージェントのメモリを管理するための確立されたパターンがまだない。過去の会話を要約すべきか、そのまま保存すべきか、ベクトルデータベースを使うべきか、それぞれの選択肢にはトレードオフがある。そして、エージェントの振る舞いは非決定論的であるため、メモリ管理のわずかな変更が全く異なる結果につながる可能性がある。このため、決まった結果を期待するテストはほとんど不可能になる。例えば、10ターンのエージェント会話に対してユニットテストを書くことはできない。なぜなら、5ターン目でトークン選択におけるわずかな確率の違いによって、会話が分岐し、その後の結果が変わる可能性があるからだ。

AI Psychosisが露呈するより深い脆弱性は、モデルそのものではなく、私たちのエンジニアリング文化にある。私たちは、「物事を行う」ためのコードを書くように訓練されてきた。しかし、エージェントは「何をすべきか」を決定する。これは、信頼性について考える根本的なシフトを要求する。決定論的なシステムでは、信頼性は厳密な制御から生まれるが、確率的なシステムでは、信頼性は可能な行動空間を制約することから生まれなければならない。OpenAI Agents APIが「ハンドオフ」（他のシステムへのタスクの引き渡し）や「構造化された出力」を強調しているのは、非決定論的な世界に決定論的な制約を課そうとする試みである。しかし、私たちはまだ初期段階にいる。ほとんどの開発者はエージェントを関数のように扱っている。入力を渡し、出力を期待する。エージェントの内部的な推論プロセスや、ループする可能性、幻覚を起こす傾向などを十分に考慮に入れていない。このミスマッチこそが、脆弱性が潜む場所なのだ。

AI Psychosisに耐えうるシステムを構築するためには、新しい設計パターンが必要となる。例えば、外部の状態を変更する（データベースに書き込んだり、決済APIを呼び出したりする）ような高リスクなアクションには、「Human-in-the-Loop」（人間の介入）を設けるべきだ。これは、全てのターンではなく、アクションのカテゴリごとに明示的な人間の確認を必要とさせることを意味する。次に、全てのツール呼び出しにユニークなIDを含めることで、「デフォルトでのべき等性」を確保する。エージェントは、既に実行されたIDを検出し、その実行をスキップするように設計されるべきだ。さらに、「サーキットブレーカー」を導入し、エージェントが決められた回数以上ツールを再試行した場合、システムは停止し、人間に警告を出すべきである。これにより、長大なログの中から何が間違っているのかを推測する必要がなくなる。そして、「構造化出力検証」を利用する。ZodやPydanticのようなツールを使って、エージェントがアクションを実行する前に、その意図が適切であるかを検証する。例えば、エージェントがID「foo」でユーザー削除を呼び出すと言っても、ツールが呼び出される前にそれを拒否できるべきなのだ。

結論として、AI PsychosisはLLMが壊れているという兆候ではない。それは、私たちがソフトウェアの信頼性について持っていた理解が不完全であるという兆候だ。私たちはこれまでのソフトウェアが決定論的であると仮定してきたが、実際には完全に決定論的だったわけではなく、そのふりをすることができた。しかし、エージェントはその前提を打ち破った。ソフトウェアエンジニアにとって、これは危機であると同時に機会でもある。危機とは、ユニットテスト、静的解析、CI/CDパイプラインといった従来のツールが、確率的なシステムには不十分だということだ。機会とは、より良い抽象化、すなわちより優れた監視機能、より優れた状態管理、より優れた人間とエージェントの協調パターンを構築することを余儀なくされているということだ。私たちが今日見ている脆弱性は、新しいパラダイムの成長に伴う初期段階の課題なのである。未来のソフトウェア工学は、決して失敗しないコードを書くことではなく、不確実性の中で優雅に失敗できるシステムを構築することにかかっている。エージェントは、複雑な多段階のワークフローを自動化するための強力なツールであるため、本番環境での利用を避けるべきではない。しかし、それらは関数としてではなく、半自律的なアクターとして扱われるべきであり、サーキットブレーカー、人間の監視、堅牢なロギングといった対策を講じ、リスクを管理しながら活用していく必要がある。