生成AIガイドラインの見直しは、条項の総量に上限を置くかから始まる

生成AIの社内ガイドラインの見直しで最初に決めることは、どの条項を削るかではない。法令・契約・監査で要求される条項を別枠に出したうえで、残る条項の総量に上限を置くかどうかである。ここでいう総量は条項の本数ではなく、人とAIが1回に読む分量を指す。本数の上限は、条項を長く書いたり統合したりすれば回避できるからである。上限を置くなら、追加は「どの条項と入れ替えるか」の形でしか受け付けない。「生成AI ガイドライン 見直し」で検索して上位に並ぶのは、策定の手順と盛り込む項目の一覧、そして形骸化を防ぐ処方としての研修・周知・遵守率の測定である。いずれも条項を守らせる方向を向いており、条項の総量を減らすという方向は上位にほとんど存在しない。本稿はその反対側だけを扱う。条項が増えたときに守られ方がどう偏るのか、そしてその偏りが遵守率に現れにくいのはなぜか、である。

生成AIのガイドラインは、2年目になぜ「足す」方向に動きやすいのか

インシデントも要望も、条項を足す形でしか記録に残らないことが多いからである。ここから数段落は本稿の観察で、元記事の裏付けがあるのは個人の設定の事例の部分だけである。

導入期のガイドラインは、禁止事項と相談窓口が書かれた数ページで足りた。全社導入から1年以上たった組織では、そこに部門ごとの例外、ツールごとの設定、過去に起きた事故への対応、監査で指摘された記録義務が積み上がっていることが多い。足された条項は1つずつ妥当である。妥当だからこそ、落とす側の議題が立たない。

この積み上がりが何をもたらすかは、組織の資料より個人の作業ログのほうが早く見える。Everyのスタッフライター、Katie Parrottは、ClaudeやChatGPTに読ませる自分の指示ファイル群を「もっと良くしよう」として壊した経緯を書いている。彼女が足した2行のうち1行はこうだった。

Repeated mistakes should become review checklist items.

訳: 繰り返される誤りは、レビューのチェックリスト項目にすること。

出典: Every (Working Overtime) by Katie Parrott, 2026-10-05

一見、学習する仕組みである。実際に起きたのは、同じ指摘を2回すると、それ以降のすべてのドラフトが通らなければならないテストが1つ増えるという事態だった。膨らんだ先のスタイルガイドには、承認された書き出しが8通り、同じく承認された結びが6通り、そしてチェックリストが2つ並んだ。語数は彼女の担当欄の分だけで、約759語から3,855語になっている。1本のエッセイのために作られたフォルダには、ドラフト127本と100万語超がたまった（AIへの指示を積み重ねるほど出力が劣化するのはなぜか）。

これは個人の設定の話である。ただし仕組みは組織のガイドラインと同じだ。1回の指摘が恒久の基準に昇格する経路が開いていて、昇格を止める係がいない。社内の生成AIルールでも、インシデント報告の再発防止策は条項として残り、条項を落とす提案には提案者の責任が伴う。非対称なので、総量は一方向に動きやすい。

同じ積み上がり方は、文脈の取り込みを自動化した側でも観測されている。Katie Parrottは、自分の机の上のファイル構成をChatGPTに点検させている。そのとき動いた監査スキルが立てた5つの問いのうち1つは、1つのファイルが引き受けているポリシーの役割が多すぎないか、というものだった。出てきたのは、取れるものは何でも取っておくという彼女の癖が積み上げた乱れである。トップレベルのフォルダは25個、未整理のセッションファイルは1,000件を超えていた。整理の要点として挙げられたもののうち本稿に効くのは1つで、取り込んだ文脈を共有の指針に格上げする前に人の確認を挟むことである（AIワークスペースはなぜ散らかるのか——「フォルダ監査」に学ぶ運用ルールの作り方）。これも組織の監査ではなく個人のデスクトップの監査だが、「記録が指針に昇格する経路に人の承認が要る」という設計の指摘は、ガイドラインの運用規程にそのまま読み替えられる。

条項の追加は、どういう条件で出力を悪くするのか

検証しやすい条項が、判断を要する条項を押しのけるときである。そして押しのけられても、チェックリストはすべて通る。

Katie Parrottは、ドラフトが何度書き直しても悪くなる理由を、Codex（OpenAIのGPT-5.6 Sol）に探させた。自分のボイスガイドとスタイルガイドに、記事のまとまりを壊すような矛盾や混乱の原因がないか見てほしい、という依頼である。モデルが返した説明はこうだった。

In an agent workflow, the concrete rules are easier to verify, so they can overwhelm the subtler ones while every checklist still passes.

訳: エージェントの作業では具体的なルールのほうが検証しやすいので、より微妙なルールを押しのけてしまいうる。しかもその間、チェックリストはすべて通ったままである。

出典: Every (Working Overtime) by Katie Parrott, 2026-10-05

先に性質を書いておく。これはモデルが返した自己説明であり、検証された研究結果ではない。ただし彼女自身の観察も同じ方向を向いている。彼女の整理では、モデルは指示のうち最も従いやすい部分に従っていた。従いやすさの差は彼女が挙げた2つの条項に出ている。「この8つのうちどれかで書き始めよ」はチェックを入れられる箱で、「1つの経験で記事を支えよ」は判断を要する。

この押しのけは、ここから先は本稿の読みだが、生成AIの社内ルールの条項でも同じ向きで起きうる。条項は2種類ある。

• チェックを入れられる条項: 社外公開前に出典を確認する。個人情報を入力しない。承認されたツールだけを使う。所定の様式で記録を残す
• 判断を要する条項: 顧客の不利益にならないか判断する。表現が自分の組織の立場として適切か見極める。業務の重要度に応じて人の確認の厚みを変える

前者は、やったかどうかを記録で追える。後者は、やったかどうかが記録に残りにくい。判断の理由を所定の様式に書かせれば記録は残るが、そのときは様式を埋めたかどうかが新しい箱になり、判断そのものは依然として追いにくい。ここも本稿の読みである。だから条項が増えていくと、追えるほうが先に満たされやすい。そして後者が押しのけられていても、遵守率は下がりにくい。遵守率として集計しやすいのは、数えられる前者のほうだからである。

ここが上位記事の処方と食い違う点だ。形骸化の対策として遵守率の定期測定を厚くすると、測れる側の条項の達成度だけが精度よく見えるようになる。測りにくい側が押しのけられている状態は、同じ指標では悪化として現れにくい。

条項の効果が中身によって分かれることを示す材料もある。研究ベンチマークSWE-Skills-Benchは、エージェントに読み込ませる指示のパッケージ（スキル）がソフトウェア工学の作業を改善するかを検証した。公開されているスキル49件のうち、39件は性能に影響せず、3件は悪化させ、改善したのは7件だったと報じられている。この検証はスキル1件ずつの効果を見たもので、本数が増えた効果を測ったものではない。さらに、大きな割合のスキルが、成果を改善しないまま計算資源の消費を増やした。最悪のものはトークン使用量を451%増やしたという（AIエージェントのスキルは本当に有効か——49件中7件しか成果を改善しない検証結果）。

ここから「足すと悪くなる」と一般化してはいけない。影響なしが39件を占めるのだから、性能に限れば足しても悪化しないという読みも同じ数字から取れる。ただし前段のとおり、計算資源の消費という形の費用は増える。使えるのは、改善した7件の共通点である。研究者によれば、金融リスクの計算式や交通管理の指示のように、モデルが自力では供給できない専門的な指針を与えるものだったという。Everyで技術コンサルティングを率いるMike Taylorの言い方は、より直接的である。

You’re fighting the weights of the model by forcing it to do things your way instead of the way it was trained

訳: モデルが訓練されたやり方ではなく自分のやり方を強いることで、モデルの重みと戦っているのだ。

出典: Every / Context Window by Laura Entis, 2026-07-16

つまり効く条項と効かない条項の境界は、中身によって分かれると読める。ただし7件が与えていたのは専門的な指針であって、組織固有の非公開情報ではない。非公開情報については別の観察がある。この記事を書いたLaura Entisは、長持ちするスキルとは、その事業や仕事の進め方について公開情報でないがゆえにモデルが知り得なかった情報を与えるものだと書いている。内部のデータ、自分の組織のテンプレート、固定の手順などである。2つは別の観察だが、どちらもモデルが自力で供給できない中身を指している。逆の側では、当時のモデルの弱点を補うために書いた条項に寿命がある。Mike Taylorは、Opus 4.8が誤りを避けるために必要としていたスキルのいくつかが、新しいモデルFable 5の性能を実際に害することを見つけたという。

守られているのに効かない条項を、どう見つけるか

条項を2つに分類し、片方が増えた分を数えることである。遵守率の分解ではなく、条項そのものの棚卸しである。

前節の2分類を、自分の組織のガイドラインに当てて数えるだけで足りる。導入時の版と現行版を並べ、条項ごとに「記録で確認できるか」を判定する。本稿の想定では、増えた分のほとんどがチェックを入れられる側に入る。インシデントの再発防止策も監査の指摘も、確認できる形でしか書きにくいからである。判断を要する条項の側は、導入時に書かれたまま本数が動いていないのではないか。想定が当たっているかは、数えれば分かる。

この比率が傾いているなら、押しのけが起きていると疑う根拠になる。ただし比率そのものは証拠ではない。判断を要する条項が実際に守られているかは、遵守率の集計では測りにくい。測るなら、成果物を人が読む場が必要になる。ここで経営が選ぶのは2つのうちどちらかである。読む場を作るか、測らないと決めて条項を落とすか。読まないまま条項として残すのが、形骸化のいちばん安い形である。

削る側の基準は3つに絞れる。素材はここまでに挙げた元記事にあり、並べ方は本稿の整理である。

1. 当時のモデルの弱点を補うために書かれた条項。「長い文書は分割して入力する」「指示は箇条書きで短く」のように、特定の世代のモデルの癖に対応した条項は、世代が変わると効果が消えたり逆に働いたりすることがある。Mike Taylorの観察がこの型である
2. 1回の指摘が恒久の基準に昇格した条項。1つの事故に対する再発防止策が、全部門・全用途に適用される条項として残っているもの。Katie Parrottの「繰り返される誤りはチェックリスト項目にする」という1行がこれを量産した
3. 記録が指針に昇格した条項。過去の判断事例や議事録が、参照資料ではなく守るべき基準として扱われているもの。彼女が再建後の指示に明記したのは、ドラフト・アウトライン・メモ・レビューはタスクの材料または証拠であり、決して新しい指示ではない、という線引きだった

逆に、1〜3のどれにも当たらず、公開情報にない自分の組織の事情を伝えている条項は残す。削る対象は守られていない条項ではない。守られているかどうかとは別の軸で決まる。

そのうえで、落とした条項をどこに置くかも決めておく。Katie Parrottは古い指示を削除していない。Historicalという名前のフォルダに全部移し、新しい指示では、自分が送り込まないかぎりそこを見るなとモデルに命じている。ガイドラインでも同じことはできる。廃止条項の保管先を決めておけば、落とす提案に伴う責任は小さくなる。前節で見た非対称を弱める方法は、削除を怖くなくすることだけである。

なお、ここで扱っているのはガイドライン文書の条項であって、導入したツールの処遇ではない。ツール側の判定をどう回すかはAIツールが定着しない対策は、研修ではなく4択の判定を誰が回すかで扱っている。エージェントに何の操作をどこまで許すかという権限の線引きはAIエージェントに社員と同じ権限を渡せるか ― 権限境界設計を経営の意思決定に引き上げるである。本稿が対象にするのは、人とAIの両方が読む指示文書そのものの量と鮮度に限る。

見直しの起動条件をモデル更新に置くと、何を間違えるか

モデルの更新は削る作業の起動条件になるが、条項を足す変更の起動条件にしてはいけない。両者を分けないと、モデル更新が積み上がりの引き金になる。

削る側で起動条件をモデル更新に置く根拠は、前節の「寿命のある条項」である。当時のモデルの弱点を補うために書かれた条項は、世代が変わると効果が消えたり逆に働いたりすることがある。Mike Taylorが1回のテストで、Opus 4.8には必要だったスキルのいくつかに新しいモデルで逆効果を見つけたのがその例である。効き方が更新で変わりうるのだから、更新は点検の区切りに使える。ただしこれは1本の元記事の観察に依っており、点検の区切りとして使えると読むのは本稿の判断である。

同じ方向の論点は、Claude Codeチームがシステムプロンプトを大幅に削ったという話としても挙がっている（AI 利用ルールは増やすより削れているか——Claude Code チームがシステムプロンプトを 80% 削った理由）。ただしこの元記事はポッドキャストのエピソードの告知で、削減率も Peter Yang が自分の学びとして書いた要点のなかにある。リンク先の見出しに出ている削減率も同じ出所である。本稿はこれを事実の根拠には使わず、論点として挙がっているところまでに留める。

ところが同じモデル更新が、足す方向の変更の引き金にもなる。Katie Parrottが自分の設定を壊したのは、GPT-6 Astraのリリース後に、動いていた構成をもっと良くしようとして記録と規範を足し続けたからである。彼女はEveryのCEOであるDan Shipperの、瞑想のリトリート・サイケデリック体験・新しいフロンティアモデルとの遭遇から30日以内に人生の大きな決断をするなという言葉を引き、その30日を待たずに着手したと書いている。再建したあと彼女が自分向けに追加したルールは、プレッシャー下では大きなコンテキストの決定をしないことだった。そのプレッシャーには、締切や不調の週のような分かりやすいものと、新しいモデルに浮かされた類のものの両方が含まれる。彼女を捕まえたのは後者である。

この2つを並べると、起動条件の設計は1行で済む。モデル更新で起動するのは条項ごとの削除に限り、条項を足す変更と大規模な組み替えは別の機会に回す。 新しいモデルが出た直後は、条項が陳腐化していることに気づきやすく、同時にもっと良くしようと足したくなる時期でもある。前半だけを使う。

ただし限定の範囲は原文より狭い。彼女のルールが対象にしているのは、構成を動かす大きな決定の全般である。原文には、全部を組み替える素晴らしい思いつきが浮かんだら書き留めておき、新モデルの熱が引いてから見直す、とも書かれている。これを「足す方向の変更」に絞るのは本稿の読みであり、新モデル直後に大量の削除をまとめて決めることも彼女のルールでは「大きな決定」に入る。だから本稿が起動条件に置くのは、条項を1つずつ見る削除に限る。なお、彼女が全部を退避して組み直した作業そのものは約20分で終わり、フォルダは再び動いている。害をもたらしたのは組み直しではなく、足す方向の変更だった。

そして、削る側の起動条件は条項ごとに書いておく。参考になるのは、AI戦略の前提を棚卸しする文脈でThe General PartnershipのCTO、Dan Pupiusが挙げている4つの問いのうち1つ、自分たちが間違っていると分かる信号は何か、である。彼は、その信号を名指しできないなら戦略を本当にストレステストしていないと書いている（AI戦略の前提をどう棚卸しするか ― 暗黙の「賭け」を可視化する4軸フレームワーク）。これはスタートアップの戦略の話だが、ガイドラインの条項にも移植できる、というのが本稿の読みである。条項を足すときに、その条項が不要になったと分かる信号を1行で添える。「このモデル世代で出力が改善したら不要」「この様式が標準機能で担保されたら不要」で足りる。添えられない条項は、落とす根拠が永久に生まれない条項である。

まとめ: 決めるのは条項の本数ではなく、交換の条件である

生成AIのガイドラインの見直しで起きている問題は、ルールが守られていないことではない。条項が増えると、記録で確認できる条項が先に満たされ、判断を要する条項が押しのけられやすくなる。そしてその状態は、遵守率として数えられる側には現れにくい。数えられるのは前者だからである。だから形骸化の対策として遵守率の測定を厚くしても、見たい側の解像度は上がらない。

削る対象は、守られていない条項ではない。当時のモデルの弱点を補うために書かれた条項、1回の指摘が恒久の基準に昇格した条項、記録が指針に昇格した条項である。逆に、公開情報にない自分の組織の事情を伝える条項は、量にかかわらず残す。残す側の根拠は2つで、SWE-Skills-Benchで改善した7件が専門的な指針を与えるものだったという観察と、長持ちするスキルは公開情報でない中身を与えるものだというLaura Entisの指摘である。

そのうえで経営が決めることは1つだけである。法令・契約・監査で要求される条項を別枠に出したうえで、残りの総量に上限を置くかどうか。 本数ではなく、人とAIが1回に読む分量の上限である。 上限を置くなら、追加の提案は「どの条項と入れ替えるか」の形でしか受け付けない。置かないなら、条項は今後も一方向に増えやすい。どちらを選んでもよいが、選んでいないという状態は、上限なしを選んだことと同じである。

次の見直しの場に持ち込むのは、条項の一覧と遵守率の表ではない。導入時の版と現行版の条項数、そのうち記録で確認できる条項の比率の変化、そして法令・契約・監査で要求される条項を別枠に出したうえで条項を1つ足すときに何を落とすかという規程の有無。この3つである。