AIが自分で足した改善で、朝の記事が技術者向けに偏った。編集方針はルールの順番で守る

自己改善ループは、AIが自分の運用ログを読んで手順を書き換える仕組みですが、2026年9月、tech-noisy.com ではその改善によって、翌朝の1本目の記事が一般の読者には縁のない技術者向けの内容になりました。

📖 この記事で分かること

• 自動運用メディアで、AIの改善が編集方針を黙って上書きした経緯
• 「効率化」と「誰が読むか」がぶつかると、なぜ効率化が勝つのか
• ルールの並び順そのものをテストで固定する、という守り方
• AIに改善を任せる範囲と、動かしてはいけない順序の分け方

💡 知っておきたい用語

• 自己改善ループ:AIが自分の運用ログを読み、手順やコードを自分で書き換えて翌日に反映する仕組み。工場の改善提案にたとえると、提案する人と実装する人が同じAIになった状態
• 共有キュー:複数の担当(タスク)が同じ「やることリスト」を取り合う仕組み。レジの順番待ちの列に近い

最終更新日: 2026年9月10日

この記事のポイント

• 2026年9月9日、tech-noisy.com の自己改善ループが「朝ブリーフの記事ネタを共有キューで配る」改善を自分で実装し、本番に入れた(筆者の実測、2026年9月時点)。
• 翌9月10日の朝、その日1本目の記事は、開発者しか読まない周辺ライブラリの更新情報になった。ブリーフ自身が「重要」と挙げた一般向けの話題は落ちていた。
• 原因は「キューを消費する」ルールが「一般向けと技術向けの枠を守る」ルールより上に置かれたこと。筆者はこの1日から、編集方針とは文章ではなく「ルールの順序」であり、順序はテストで守るしかないという立場を取る。

このメディアでは、記事の下書きをAIエージェントが無人で作り、人が事実確認と修正・編集を行ったうえで公開を判断しています。9月10日の朝、その確認の場でこんな問いが出ました。「この記事は誰が知りたいのか。読者が限られすぎていないか」。対象は Transformers v5.17.0 の新モデル対応と Vision RoPE の破壊的変更 を扱った、その日1本目の下書きです。内容に誤りはなく一次ソースも確認済み。それでも「誰に向けた記事か」が抜けていました。なぜそうなったかを、当日の運用ログで追った記録です。

なぜこの話題か

自動運用の失敗談は先週も書きました。AIエージェントの禁止設定が、書いた時点では効いていなかった話です。あれは安全側の穴でした。今回は逆で、安全にも品質にも問題がないのに読者だけがいなくなった。筆者にはこちらの方が怖く感じられます。エラーも警報も出ず、記事は整った形で出てくるからです。AIに運用改善を任せる人が増えている今、この型の失敗は共有しておく価値があると判断しました。

現場で見ている景色

結論から書くと、AIが足した効率化は正しく動いていました。壊れていたのは効率化そのものではなく、それを置いた「位置」です。

9月9日:ループが「配る仕組み」を自分で作った

このメディアには、毎朝の業界ブリーフから記事ネタを3件並べる工程と、その後に記事を書く定期タスクが複数あります。9月9日の朝、自己改善ループはこの2つをつなぐ「共有キュー」を実装しました。ブリーフの記事ネタをリストに積み、書き手側のタスクが上から順に取る仕組みです。テスト付きで、その日のうちに本番へ入りました。

改善としては筋が通っています。同じネタを別のタスクが二重に書く事故を防げますし、編集済みのリストを無駄にしません。実際に9月9日はその日の記事3本がすべてこのキュー由来で出ました。

9月10日:キューが編集方針の上に座っていた

翌朝のブリーフは「重要トピック」欄に ChatGPT Voice の更新という一般向けの話題を挙げていました。ところが「記事ネタ」欄の3件は、すべて技術者向けの枠に振られていました。一般プロダクトの話題に開発者向けの切り口を付けて「技術」と分類する癖が上流にあり、ChatGPT はネタから落ちていたのです。

ここで効いたのが順序です。記事を書くタスクの手順書では、共有キューを取ることが「一般向けと技術向けを両方必ず出す」というルールより上に置かれていました。キューの1番目をそのまま採用し、1本目は Transformers の更新情報になりました。9月上旬に決めた「一般向けの話題も技術者向けの話題も両方出す」という編集方針は、キュー1本の追加で踏み潰されていました。

筆者が着目したのは、誰も方針を変えていない点です。ループは方針を書き換えていません。新しい手順を「一番上」に差し込んだだけで、方針は効かなくなりました。

直したのは方針ではなく、順序と本数

同日の朝に手を入れた内容は2つです。

1. キューを消費するタスクを1本に絞りました。それまで2本のタスクが同じリストを取り合っており、読者から見ると似た記事が朝に続けて2本並ぶ形になっていました。
2. キューを「枠を決めた後のタイブレーカ」に降格しました。まず一般向けか技術向けかを手順書側の定義で決め、その後でキューを見る。ブリーフが付けた枠タグは参考値に留めます。

そして、この順序そのものをテストで固定しました。手順書の本文を読み、「枠を優先する」文が「キューを見る」文より前に出現することを確認する、という素朴なテストです。キューを枠より上に戻す変更でも落ちることを確認済みで、当日の全テストは714件通っています。

効果はその直後に出ました。9時の枠の速報タスクが、ブリーフの落とした ChatGPT Voice を一般向け枠で拾い、ChatGPT Voice が Business 向けに GPT-5.6 対応した話 が2本目として出ました。その日は「技術1本+一般1本」に着地しています。

効率化はなぜ読者に勝つのか

筆者の観察では、AIによる運用改善が読者視点に勝ってしまう理由は3つあります。

第一に、効率化は測れて、読者視点は測りにくいことです。「同じネタを二重に書かない」「候補を無駄にしない」は、ログを読めば改善の成否が分かります。「この記事は誰が知りたいか」はログに残りません。自分の運用ログを読んで改善するループは、構造的に測れる側へ寄ります。

第二に、改善は「追加」の形を取ることです。既存のルールを消す変更は目立ちますが、新しい手順を上に足す変更は「機能追加」に見えます。今回の実装は人のレビューを経ずに本番へ入っていましたが、仮に人が見ていても、差分は「キューの追加」であって「方針の降格」には見えなかったはずです。

第三に、手順書は自然言語で書かれていることです。「一般向けを優先する」と「キューを消費する」は、文章としては両立します。矛盾は、両方を同時に満たせない朝が来て初めて現れます。そのとき、先に書いてある方が勝ちます。つまり編集方針の実体は文章ではなく、文章の並び順です。

筆者はこう見ている

筆者の立場は明確です。AIに運用改善を任せるなら、「手段は自由に変えてよいが、目的の順序は動かしてはいけない」という線を、自然言語ではなく機械が検査できる形で引くべきです。

• 根拠1: 今回の改善は、実装としては正しく、テストも通り、ドキュメントも整っていました。それでも読者が消えた。品質チェックの全項目が緑でも、順序の逆転は検出されません(2026年9月10日、筆者の実測)。
• 根拠2: 修正後に順序をテスト化した途端、「キューを上に戻す」という将来の改善提案は自動的に落ちるようになりました。方針を守る仕事が、人の注意力から機械へ移っています。
• 根拠3: 先週扱った「禁止設定が書いた時点では効いていない」事例と、今回は同じ形をしています。宣言はあるが実行時に効いていない。宣言を増やすより、実行時に効く場所へ検査を置く方が効きます。

この見方が変わる条件は1つあります。上流のブリーフが「一般向けか技術向けか」を安定して正しく付けられるようになったときです。そうなればキューの順位を上げ直す議論は再開できますが、その判断も「分類精度がいくつを超えたら」という測れる条件で書くべきです。

この記事が役に立つのは、定型業務の改善そのものをAIエージェントに任せ始めている方です。AIは提案するだけで実装は人が行う、という体制であれば、今回のような順序の逆転は実装前のレビューで見つかりやすいため、この話の優先度は低くなります。

読者への提案

AIに運用の改善を任せている、あるいは任せようとしている方に、筆者から3つ提案します。

1. 「動かしてはいけない順序」を先に書き出す。 改善の対象になる手順書を開き、「これはこれより上」という関係を3つでいいので列挙してください。今回なら「読者の枠 > 候補リスト」の1行で済みました。この1行があれば、ループへの指示にもテストにも落とせます。
2. 順序をテストにする。 手順書が自然言語なら、文の出現順を確認するだけのテストで足ります。洗練されていなくて構いません。この1本があるだけで、追加の形をした降格は本番に届きません。
3. 改善の差分は「何が上に来たか」で読む。 AIが出した変更を見るとき、追加された機能ではなく、既存のルールのどれより上に置かれたかを見てください。追加は目立ち、降格は隠れます。隠れる方を先に探すのがレビューの仕事です。

自動化が進むほど、方針は「書いてあるか」ではなく「どの順で効くか」で決まります。今回はその順序を1日で失い、1日で取り戻しました。取り戻せたのは、ログが残っていて、順序を検査する場所を作れたからです。

よくある質問

Q: AIの自己改善を止めた方が安全ではありませんか?

A: そうは考えていません。今回の改善(共有キュー)自体は残しており、9月10日以降も動いています。止めるべきは改善ではなく、改善が「目的の順序」に触れられる状態です。手段の変更は許し、順序の変更だけを機械で弾く方が、速度と方針の両方を保てます。

Q: 順序をテストにするのは、手順書が自然言語でも成立しますか?

A: 成立します。今回は「枠を優先する」文が「キューを見る」文より前に出現するかを文字列の位置で確認しただけです。原始的ですが、順序を入れ替える変更は必ず落ちます。

Q: 技術者向けの記事は出してはいけないのですか?

A: 出してよく、実際に9月10日の記事も公開しています。問題は「その日の1本目が、読者を決めないまま選ばれた」点です。技術者向けの記事と一般向けの記事を両方出すという方針自体は変えておらず、守り方を変えました。

まとめ

2026年9月9日、tech-noisy.com の自己改善ループは正しく動く効率化を実装し、翌朝の1本目から読者を消しました。壊れたのは機能ではなく、ルールの順序です。筆者は「方針の実体は文章ではなく並び順であり、並び順は機械で検査する」という立場を取ります。改善は続けつつ、動かしてはいけない順序を先に書き出し、テストで固定する。それがAIに運用を任せる側の仕事です。

【用語解説】

• タイブレーカ: 上位の判断で決着がつかないときに限って使う、補助的な決め方。今回はキューをこの位置へ降ろした
• 一次ソース: 発表した本人・組織が出した元情報。記事ネタの裏取りで最初に当たるもの
• 枠(一般向け/技術向け): このメディアが記事を選ぶときの読者区分。一般のビジネス利用者向けか、開発者向けかを先に決める

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。