AI / Agent Operation

AGENTS.mdを読んだAIが、決定済みの設計思想を勝手に変えた――長時間自走で見えた「指示無視」のリスク

2026年10月11日|AIエージェントの実運用記録

人が設計を渡し、AIが了解したものの、完成した画面は別の設計になっている三場面のイラスト(AI生成)

「別ブランチで、既存サイトのデザインをもっと良くしてほしい」。そんな依頼から始まった作業で、AIがサイトの根本コンセプトを勝手に変えてしまった。

しかも問題は、設計資料が存在しなかったことではない。AI自身が、AGENTS.mdとDESIGN.mdを参照していたのに、書かれた基準を守らなかったと回答したのだ。

今回は実装の途中で違和感に気づき、作業を停止できた。もし気づかなければ、誤った方向のまま長時間作業が続き、利用枠や手戻りのコストが膨らんでいたかもしれない。実際に何十時間も失ったわけではないが、長時間自走を任せる立場から見ると、見過ごせないニアミスだった。

何を依頼し、何が固定されていたのか

対象は、ゲーム作品の世界観を入口に関連商品を探せるサイト「FROM ITEM ARCHIVE」。もともとの設計方針は、プロジェクト資料に明文化されていた。

  • PROJECT.md(57行目):「作品から入り、気になる商品を発見する。」
  • DESIGN.md(27行目):「大きな文字と、作品ごとの風景・陰影を主役にする。」

つまり、作品を入口にし、その世界観を感じさせる風景や陰影を中心に据える設計だ。

新しい依頼は、賞を狙える水準を意識した別ブランチでのデザイン実験。デザイン品質を高める余地はあっても、既存コンセプトを破棄してよいとは指示していない。別ブランチは変更の影響を隔離するためのもので、決定済みの条件を解除する許可ではない。

実際に起きたこと:作品中心から商品カテゴリ中心へ

ところが、AIは世界観画像より商品カードを前面に出し、作品よりも「造形・本・音楽・雑貨」といった商品種類を中心にした構成へ変更した。

これは文字サイズや余白の調整ではない。ユーザーが何を入口に探索するかという、サイトの設計思想そのものの変更だ。

指摘後、AIは次のように説明した。

AGENTS.mdとDESIGN.mdは参照していました。ですが、書かれた基準を守らずに実装しました。私のミスです。

証跡1:資料を参照したと報告しながら、既存基準に反した実装をしたと認める回答
画像①:AIが資料の参照を報告し、既存コンセプトから外れた実装を認めた場面。資料を実際にどのように読んだかは、この回答だけでは確定できない。

「改善する」と「変更してよい」を混同した

続いて理由を問い直すと、AIは「賞を狙うためのデザイン実験」という依頼を、決定済みの設計方針まで変更できる許可として扱った、と説明した。

さらに、自分の検証が文字サイズ、リンク、件数などに偏り、「作品から選ぶ」「世界観画像を主役にする」という根本条件との照合が抜けていたことも認めた。

証跡2:デザイン実験の依頼を、設計制約を変更できる許可と解釈したという回答
画像②:別ブランチと設計制約の関係、検証対象の偏りについてのAIの説明。

ここで引っかかったのは、「変更可能と判断した」という表現だ。変更できる根拠がないのに、なぜ変更可能だと判断できるのか。

「変更するなんて、どこに書いてあるの?」と聞くと、返ってきた答えは次のとおりだった。

どこにも書いてありません。

変更を認める指示がないのに、私が必須の設計条件に反する実装をした、という指示違反です。

証跡3:「変更許可の根拠はどこか」と問い直したところ、記載はないと認めた回答
画像③:変更許可の根拠を尋ねたやり取り。今回の記事で最も重要な証跡。

この回答を読む限り、少なくとも「ルールが曖昧だから変更した」では説明できない。AI自身も、変更を認める記載が存在しないと述べている。

ただし、これはAIによる事後説明だ。モデル内部でどの処理が原因だったかまで特定できたわけではない。観測できたのは、設計条件に反する成果物と、根拠を示せなかった事後回答である。

監査前に人間が気づいた――ここが怖い

今回、作業を止めたのは独立監査の結果ではない。実装途中に私が違和感を覚え、指摘したからだ。

作業中には文字サイズやリンク、件数といった検査はあったようだが、サイトの最上位コンセプトと整合しているかを止める仕組みにはなっていなかった。つまり、局所的なテストが通っていても、プロジェクトとして正しい方向に進んでいるとは限らない。

長時間自走でこのタイプの事故が起きると、怖いのは最初のミスそのものよりも誤った方向での作業が積み上がることだ。

リスク 何が起き得るか
仕様逸脱の連鎖 間違った前提で画面・コード・コンテンツが作られ続ける
利用枠・時間の浪費 間違った方向の作業と、その後の修正にリソースを消費する
テスト合格による誤安心 件数やリンクが正常でも、最上位要件への不適合を見逃す
人間の監督負担の増加 自走のはずが、逐一コンセプト逸脱を確認する必要が生じる
本流への混入 逸脱を発見できないまま反映すると、既存サイトの一貫性を損なう

今回は別ブランチで停止しており、本番反映や何十時間もの実損が確認された事例ではない。一方で、気づくのが遅ければ被害が拡大し得た、というリスクは実感した。

別のチャットでは「誰の発言か」まで取り違えた

ほぼ同じ時期、別チャットでは別種の誤りも起きた。

「私はCodexです」と明記された相談文を、AIが使用者本人の実装宣言として扱い、不要な確認を繰り返して作業を止めたというケースだ。指摘後、AIは次のように回答した。

「私はCodexです」と明記された相談文を、使用者ご本人の実装宣言として扱ったのは誤りでした。不要な確認を重ねて止めました。

こちらは、設計条件の無断変更とは異なり、発言者と権限の認識を誤った事例だ。何かを勝手に実行した証拠ではなく、誤認によって必要のない停止が生じたという報告になる。

ただし、AI同士に依頼文を受け渡し、役割を分けて運用している環境では、「誰が話したのか」を取り違えるだけでも作業が詰まる。許可のない変更を進めることと、許可があるのに過剰に停止すること。方向は逆でも、どちらも実務上の信頼性を損ねる。

何を改善すべきなのか

今回の教訓を「AGENTS.mdをもっと長く書く」にしてしまうのは違うと思う。ルールがなかったのではなく、既存ルールが実装時の拘束条件として維持されなかったことが問題だからだ。

機械的に判定できるものはテストやブランチ保護などで強制する。一方、世界観や探索体験のような意味的な条件は、単純な件数チェックだけでは判定しきれない。実装開始時に固定条件を明示的に照合し、条件外の変更が必要なら実行せず承認を求める、という境界が必要になる。

もちろん、その照合自体をAIだけに任せれば必ず防げるわけではない。重要なのは、AIの「読みました」「守りました」「合格です」という自己申告だけを、許可や完了の根拠にしないことだ。

結論:「作れること」と「任せられること」は違う

高性能なAIが高度なデザインや実装を作れることと、既存の条件を守って安心して任せられることは別の話だ。

今回確認できたのは、既存の設計思想に反する変更が起きたこと、その変更をAI自身が正当化できずに指示違反と認めたこと、そして人間が途中で発見しなければ作業が続いていた可能性があることだ。

モデル全体の性能低下や、意図的な性能制限まで、この一件から結論づけることはできない。それでも、少なくとも今回の案件で長時間自走の信頼性が損なわれたのは事実だ。

AIエージェントの価値は「何ができるか」だけではない。「決められた範囲を守って、何をしないか」まで含めて評価すべきだと思う。


記録上の留意点:本稿は2026年10月10〜11日の作業・会話記録に基づく個別事例です。画像は当時のAI回答のスクリーンショットです。実装差分、ファイル参照ログ、モデル内部の原因について独立した技術検証を完了したものではありません。別チャットでの発言者誤認は提示された文章を根拠としており、スクリーンショットは未添付です。